Построение приборных панелей на семантическом слое с помощью Superset и Cube

Что может быть более тревожным и ужасающим для пользователя Apache Superset, чем алое сообщение об ошибке, показывающее, что базовый набор данных поврежден, и диаграммы не смогут дать никаких выводов в ближайшее время? Вздох.

Действительно, современные конвейеры данных состоят из множества подвижных и порой хрупких деталей. Superset, швейцарский нож для исследования и визуализации данных, заслуживает надежных источников данных, но в реальном мире неизбежны изменения в потоке данных. Они могут быть связаны как с незрелыми технологиями в стеке данных, так и с постоянно меняющимися бизнес-требованиями и балканизированным владением конвейерами данных.

В течение нескольких минут на Slack или GitHub компании Superset можно обнаружить разговоры, вращающиеся вокруг выявления неработающих приборных панелей и поиска способов уменьшить их влияние на пользователей:

Я рад поделиться тем, что решение существует. Вы можете использовать Cube вместе с Superset и определять свои наборы данных на слое моделирования данных (или семантическом слое), а не на необработанных данных:

В этом руководстве мы рассмотрим, как Cube, безголовая BI-платформа, может быть использована вместе с Superset для создания надежных и прочных визуализаций данных поверх семантического слоя. Вы узнаете о методах предотвращения сбоев в работе ваших информационных панелей и инструментах, которые будут уведомлять вас о несовместимых изменениях в данных еще до того, как это заметят ваши пользователи.

Что такое Headless BI?

Cube — это платформа Headless BI с открытым исходным кодом и почти 13 000 звезд на GitHub на сегодняшний день. Ее можно разделить на четыре слоя, которые дополняются головкой или несколькими головками, например Apache Superset, другим BI-инструментом или внешним приложением со встроенной аналитикой. Вот эти слои:

• Моделирование данных. Содержит согласованные определения метрик и обеспечивает представление исходных данных в терминах мер и измерений. Делает данные семантическими.
• Контроль доступа. Защищает доступ к данным и обеспечивает безопасность на уровне строк, доступ на основе ролей и многопользовательский доступ. Делает данные безопасными.
• Кэширование. Ускоряет доступ к данным и делает приложения для конечных пользователей отзывчивыми и удобными в использовании. Делает приложения быстрыми.
• API. Предоставляет данные последующим приложениям через REST, GraphQL или SQL API. Делает данные доступными.

Вы можете настроить Cube для подключения к любой базе данных, декларативно определить свои метрики и мгновенно получить API, который можно использовать с Superset или многими другими инструментами BI.

В случае любого изменения в системе (будь то переименованный столбец, удаленная таблица или перенесенный источник данных) вы можете обновить модель данных в Cube и сохранить сотни диаграмм и десятки приборных панелей в вашей установке Superset. Звучит освежающе, да?

Давайте попробуем использовать Superset с Cube и посмотрим, как это работает!

Запуск Cube с Superset

Чтобы все упростить и сэкономить время, мы запустим Cube и Superset в полностью управляемых средах: Cube Cloud и Preset Cloud. Обратите внимание, что оба инструмента имеют щедрые бесплатные уровни, например, на тарифном плане Starter вы можете бесплатно использовать Preset Cloud вечно. (Если вы хотите запустить Cube или Superset локально с помощью Docker, смотрите инструкции по Cube и Supeset соответственно).

Запуск Cube. Сначала перейдите на страницу регистрации Cube Cloud и заполните свои данные. Обратите внимание, что Cube Cloud поддерживает регистрацию с помощью вашей учетной записи GitHub. Через несколько секунд вы попадете в свой аккаунт, где сможете создать свое первое развертывание Cube:

Укажите имя развертывания, выберите облачного провайдера и регион:

На следующем этапе выберите Create, чтобы начать новый проект Cube с нуля. Затем выберите Postgres, чтобы перейти к экрану, где вы можете ввести следующие учетные данные:

Hostname:  demo-db-examples.cube.dev
Port:      5432
Database:  ecom_superset
Username:  cube
Password:  12345

Cube подключится к общедоступной базе данных Postgres, которую я уже настроил.

Последняя часть конфигурации — это схема данных, которая декларативно описывает метрики, которые мы будем выводить на приборную панель. На самом деле, Cube может сгенерировать ее за нас! Выберите из списка базу данных верхнего уровня public и выберите только таблицу «orders»:

Через некоторое время ваше развертывание Cube будет готово к работе:

Определение метрик. Перейдите на вкладку «Схема». Вы увидите файл Orders.js в папке «schema». Давайте рассмотрим его.

Этот файл определяет метрики в кубе «Заказы». Он отличается от того, который используется в Cube Cloud, но мы разберемся с этим позже.

cube(`Orders`, {
  sql: `SELECT * FROM public.orders`,

  dimensions: {
    id: {
      sql: `id`,
      type: `number`,
      primaryKey: true
    },

    // 'processing', 'shipped', or 'completed'
    status: {
      sql: `status`,
      type: `string`
    },

    createdAt: {
      sql: `created_at`,
      type: `time`
    },

    shippedAt: {
      sql: `shipped_at`,
      type: `time`
    },

    completedAt: {
      sql: `completed_at`,
      type: `time`
    },

    // Calculated, uses SQL functions and column references
    daysBeforeShipped: {
      sql: `EXTRACT(DAYS FROM (shipped_at - created_at))`,
      type: `number`
    },

    // Calculated, uses SQL functions and column references
    daysBeforeCompleted: {
      sql: `EXTRACT(DAYS FROM (completed_at - created_at))`,
      type: `number`
    }
  },

  measures: {
    count: {
      type: `count`
    },

    // Calculated, uses a dimension reference
    avgDaysBeforeShipped: {
      sql: `${daysBeforeShipped}`,
      type: `avg`
    },

    // Calculated, uses a dimension reference
    avgDaysBeforeCompleted: {
      sql: `${daysBeforeCompleted}`,
      type: `avg`
    }
  },
});

Ключевые выводы:

• куб — это логическая сущность на уровне домена, которая включает меры и измерения
• с помощью оператора sql этот куб определяется над всей таблицей public.line_items; на самом деле кубы могут быть определены над произвольными SQL-операторами, которые выбирают данные
• измерения (качественные характеристики данных) определяются по текстовым, временным или числовым столбцам в наборе данных
• меры (количественные характеристики данных) определяются как агрегации (например, count, avg и т.д.) по столбцам или измерениям в наборе данных
• вы можете определять сложные меры и измерения с помощью пользовательских операторов sql или ссылок на другие меры и измерения.

Режим разработки. Теперь давайте обновим файл схемы в Cube Cloud, чтобы он соответствовал вышеуказанному содержимому. Сначала нажмите Enter Development Mode, чтобы разблокировать файлы схемы для редактирования. По сути, это создает «вилку» Cube API, которая отслеживает ваши изменения в схеме данных.

Перейдите к Orders.js и замените его содержимое приведенным выше кодом. Затем сохраните изменения, нажав Save All, чтобы применить изменения к версии API для разработчиков. Вы можете применить столько изменений, сколько захотите, но на данный момент мы закончили. Нажмите Commit & Push, чтобы объединить изменения с основной веткой:

На вкладке «Обзор» вы увидите развернутые изменения:

Теперь вы можете изучить метрики на вкладке «Playground»:

Когда вы будете готовы, перейдите на вкладку «Overview», нажмите «Deploy SQL API» и вскоре после этого воспользуйтесь ссылкой «How to connect your BI tool».

Через несколько мгновений вы увидите учетные данные, которые мы будем использовать для подключения хранилища метрик, созданного с помощью Cube, к Superset. Как?

Запускаем Superset. Перейдите на страницу регистрации Preset и заполните свои данные. Обратите внимание, что Preset Cloud поддерживает регистрацию с помощью учетной записи Google. Через несколько секунд вы попадете в свой аккаунт с доступным рабочим пространством:

Переключившись на это рабочее пространство, вы увидите несколько примеров приборных панелей, которые вы сможете просмотреть позже.

Подключите Superset к Cube. Перейдите в Data / Databases через верхнее меню, нажмите + Database, выберите MySQL и введите учетные данные вашего экземпляра Cube Cloud — или используйте приведенные ниже учетные данные:

• Хост: green-yak.sql.aws-us-east-2.cubecloudapp.dev.
• Порт: 3306
• Имя базы данных: db
• Имя пользователя: cube@green-yak
• Пароль: 82e26064349b19c340f8b074dfcee4af
• Отображаемое имя: Cube Cloud (это важно).

Теперь вы можете нажать Connect.

Определите наборы данных. Перейдите в Data / Datasets через верхнее меню, нажмите + Dataset и заполните следующие учетные данные:

• База данных: Cube Cloud (та, которую мы только что создали).
• Схема: db.
• См. схему таблицы: Orders.

Теперь вы можете нажать Add. Затем наведите курсор на только что добавленный набор данных и нажмите на значок карандаша в колонке «Действия». Нам нужно убедиться, что Superset распознает несколько мер. Сначала перейдите на вкладку «Колонки» и снимите флажок «Является измерением» для avgDaysBeforeShipped и avgDaysBeforeCompleted:

Затем переключитесь на вкладку «Метрики» и добавьте эти два параметра:

• Метрика: avgDaysBeforeShipped; SQL-выражение: AVG(avgDaysBeforeShipped).
• Метрика: avgDaysBeforeCompleted; SQL выражение: AVG(avgDaysBeforeCompleted).

В конце нажмите Save. Фух, все готово! Теперь давайте отобразим данные на графике.

Постройте приборную панель. Перейдите в Charts через верхнее меню, нажмите + Chart и используйте следующую конфигурацию для вашего первого графика:

• Выберите набор данных: Orders (тот, который мы только что создали).
• Выберите тип диаграммы: Таблица.

Когда все готово, нажмите Создать новый график. Не стесняйтесь экспериментировать с параметрами на этом экране и нажмите Run Query, чтобы изучить данные. Чтобы продолжить, настройте график следующим образом:

• Тип визуализации: Таблица.
• Временной столбец: createdAt
• Временное зерно: любое значение
• Группировка по: status
• Метрики: COUNT(*), avgDaysBeforeShipped, avgDaysBeforeCompleted.

Вот таблица данных, которую вы получите:

Вы можете нажать Save, чтобы дать вашей диаграмме имя и добавить ее в новую приборную панель:

Выглядит хорошо? Теперь у нас есть приборная панель в Superset, отображающая диаграмму, которая запрашивает данные из Cube, используя меры и измерения в модели данных Cube.

Cube переводит запросы, поступающие из Superset, в запросы к вышестоящему источнику данных. Что произойдет, если что-то случится в вышестоящем источнике данных? Вот когда начинается все самое интересное!

Казус 1: переименование или удаление столбца

Допустим, однажды вы (или ваши пользователи) открываете приборную панель и видите это оранжевое введение в несколько менее продуктивных рабочих часов. Очевидно, колонка «статус» больше не присутствует в источнике данных, и несколько необоснованных бизнес-решений могут быть приняты (или отложены), пока ваша команда не выяснит обстоятельства удаления.

Что можно сделать, чтобы смягчить эту ситуацию? Сначала воспроизведем эту ситуацию. Вы можете сделать это, перейдя в Cube Cloud, переключившись в режим разработки и отредактировав файл Orders.js. Просто измените SQL-выражение, чтобы оно ссылалось на таблицу orders_wo_status, которая, что вполне очевидно, имеет точно такие же данные, как и таблица orders, но столбец «status» удален:

Затем вы можете сохранить и зафиксировать изменения:

После того, как развертывание Cube Cloud будет развернуто через несколько мгновений, вы можете обновить свою приборную панель в Superset, чтобы перевести ее в раздражающее оранжевое состояние. (Если приборная панель не ломается, попробуйте нажать кнопку с тремя точками в правом верхнем углу и попросить обновить приборную панель).

Разблокировка приборной панели, простой способ. Допустим, столбец «статус» был удален, потому что он избыточен: его значения можно рассчитать, используя значения столбцов «создан_ат», «отгружен_ат» и «завершен_ат». Как же исправить приборную панель после удаления столбца?

Один из способов сделать это — отредактировать набор данных в Superset. Вы можете удалить отсутствующий столбец и добавить его обратно как вычисляемый, используя семантический слой Superset. (Если вы хотите углубиться, ознакомьтесь с этой статьей в блоге Preset).

Однако есть несколько недостатков: во-первых, этот вычисленный столбец не будет виден в SQL-редакторе Superset, где вы можете выполнять SQL-запросы для исследования данных; во-вторых, вычисления не будут распространяться вверх по течению. Если Superset — не единственный инструмент, который вы используете (или когда-либо будете использовать) для исследования данных, лучше применить исправление выше по течению, чем дублировать исправления в разных инструментах.

Разбивка приборной панели, лучший способ. Альтернативный способ — заменить столбец «статус» вычислением в модели данных Cube. Тогда Superset и все остальные инструменты будут работать так, как будто этот столбец никогда не удалялся, и ваша приборная панель никогда не ломалась.

Вы можете вернуться в Cube Cloud, переключиться в режим разработки и снова отредактировать файл Orders.js. Давайте заменим измерение «status» следующим фрагментом кода:

    status: {
      case: {
        when: [
          { sql: `completed_at IS NOT NULL`, label: `completed` },
          { sql: `shipped_at IS NOT NULL`, label: `shipped` },
        ],
        else: { label: `processing` },
      },
      type: `string`,
    },

Вы можете сохранить и развернуть свои изменения. Обратите внимание, что мы используем измерение case, которое обеспечивает некоторый синтаксический сахар по сравнению с обычным CASE... WHEN... THEN... ELSE... END SQL-оператора и предоставляет возможность ссылаться на другие измерения:

Поздравляем! Без каких-либо изменений в Superset ваша приборная панель вернулась в здоровое состояние:

Более того, если вам когда-нибудь понадобится ввести более сложный расчет в любое измерение или показатель, вы всегда сможете сделать это в Cube Cloud и при этом вам не придется ничего менять в инструментах, потребляющих данные, включая Superset.

Ошибка 2: Изменение или удаление таблицы

Допустим, вы (или ваши пользователи) открываете приборную панель и снова видите это злополучное оранжевое уведомление. Очевидно, столбец «shipped_at» не существует:

Причина в том, что разработчики вышестоящей системы решили реализовать паттерн проектирования событийного сорсинга, а это означает, что таблицы «заказы» больше не существует. Вместо нее существует таблица «orders_events», которая, что вполне очевидно, содержит точно такие же данные, но полностью преобразованные в поток событий, связанных с изменением статуса заказов. В этой таблице каждая строка представляет лишь частичную информацию о заказе, а столбец «timestamp» заменяет ранее существовавшие столбцы «created_at», «shipped_at» и «completed_at». Вот оператор DDL:

create table orders_events
(
    order_id  integer,
    user_id   integer,
    status    text,
    timestamp timestamp
);

Хотите попробовать это сами? Вы можете сделать это, перейдя в Cube Cloud, переключившись в режим разработки и отредактировав файл Orders.js. Просто измените SQL-выражение, чтобы оно ссылалось на таблицу orders_events:

После развертывания Cube Cloud вы можете обновить свою приборную панель в Superset, чтобы перевести ее в раздражающее оранжевое состояние. (Если приборная панель не ломается, попробуйте нажать кнопку с тремя точками в правом верхнем углу и попросить обновить приборную панель).

Отключение приборной панели, сложный способ. Один из способов сделать это — внедрить в конвейер данных инструмент преобразования данных (если вы его не используете), который преобразует данные в нужное состояние.

Однако здесь есть несколько минусов: во-первых, это больше похоже на месячный проект, чем на быстрое решение проблемы конвейера данных; во-вторых, это может привнести ненужную и нежелательную сложность в ваш технологический стек. (Обратите внимание, что если вы действительно используете dbt или dbt Metrics, Cube имеет интеграцию).

Разрушение приборной панели, лучший способ. Альтернативный способ заключается в обновлении модели данных Cube для преобразования данных в нужное состояние. Тогда Superset и все остальные инструменты будут работать так, как будто таблица никогда не удалялась, и ваша приборная панель никогда не ломалась.

Вы можете вернуться в Cube Cloud, перейти в режим разработки и еще раз отредактировать файл Orders.js. Давайте заменим исходный код файла следующим фрагментом кода:

cube(`Orders`, {
  sql: `
    WITH bareOrders AS (
        SELECT order_id AS id, user_id
        FROM public.orders_events
        GROUP BY order_id, user_id
    ),

    orders AS (
        SELECT
          bareOrders.*,
          (CASE WHEN completed.timestamp IS NOT NULL THEN completed.status ELSE (CASE WHEN shipped.timestamp IS NOT NULL THEN shipped.status ELSE processing.status END) END) AS status,
          COALESCE(processing.timestamp, shipped.timestamp, completed.timestamp) AS created_at,
          COALESCE(shipped.timestamp, completed.timestamp) AS shipped_at,
          completed.timestamp AS completed_at
        FROM bareOrders
        LEFT JOIN public.orders_events AS processing
          ON bareOrders.id = processing.order_id AND processing.status = 'processing'
        LEFT JOIN public.orders_events AS shipped
          ON bareOrders.id = shipped.order_id AND shipped.status = 'shipped'
        LEFT JOIN public.orders_events AS completed
          ON bareOrders.id = completed.order_id AND completed.status = 'completed'
    )

    SELECT * FROM orders
  `,

  dimensions: {
    id: {
      sql: `id`,
      type: `number`,
      primaryKey: true
    },

    // 'processing', 'shipped', or 'completed'
    status: {
      sql: `status`,
      type: `string`
    },

    createdAt: {
      sql: `created_at`,
      type: `time`
    },

    shippedAt: {
      sql: `shipped_at`,
      type: `time`
    },

    completedAt: {
      sql: `completed_at`,
      type: `time`
    },

    // Calculated, uses SQL functions and column references
    daysBeforeShipped: {
      sql: `EXTRACT(DAYS FROM (shipped_at - created_at))`,
      type: `number`
    },

    // Calculated, uses SQL functions and column references
    daysBeforeCompleted: {
      sql: `EXTRACT(DAYS FROM (completed_at - created_at))`,
      type: `number`
    }
  },

  measures: {
    count: {
      type: `count`
    },

    // Calculated, uses a dimension reference
    avgDaysBeforeShipped: {
      sql: `${daysBeforeShipped}`,
      type: `avg`
    },

    // Calculated, uses a dimension reference
    avgDaysBeforeCompleted: {
      sql: `${daysBeforeCompleted}`,
      type: `avg`
    }
  },
});

Как вы можете видеть, модель данных Cube достаточно гибкая и позволяет определять кубы с помощью произвольных выражений SQL, которые могут содержать выражения общих таблиц (CTE), объединения, соединения и т.д. Эмпирическое правило для структурирования модели данных в Cube заключается в том, что кубы, меры и измерения должны иметь смысл на логическом уровне домена. И если ваши данные хранятся по-другому, вы можете смело менять их форму в модели данных Cube.

Вы можете сохранить и развернуть свои обновления в Cube Cloud. И снова, без каких-либо изменений в Superset, ваша приборная панель вернулась в здоровое состояние:

Неисправность 3: Изменение источника данных

Допустим, произошло что-то редкое, но важное: команда решила обновить конвейер данных, внедрить новые инструменты и т.д. В конечном итоге данные перейдут с Postgres на BigQuery, будут использоваться новые инструменты ETL и преобразования данных. Что мы можем сделать, чтобы предотвратить поломку приборных панелей или избежать перестройки приборных панелей в Superset?

Поскольку мы уже подключили Superset к Cube, мы можем разобраться со всем на стороне Cube. Как и Superset, Cube поддерживает множество источников данных, и экземпляр Cube может одновременно использовать любое подмножество этих источников данных.

Разбивка приборной панели. Вот как можно настроить Cube на подключение к Postgres и BigQuery и обновление модели данных, чтобы данные о заказах считывались из BigQuery.

В Cube Cloud вам нужно переключиться в режим разработки. Сначала давайте обновим Orders.js, чтобы он соответствовал следующему фрагменту. Обратите внимание на новую опцию dataSource и обновленные определения для daysBeforeShipped и daysBeforeCompleted, которые используют специфическую для BigQuery функцию TIMESTAMP_DIFF вместо специфической для Postgres функции EXTRACT:

cube(`Orders`, {
  dataSource: 'bigquery',

  sql: `SELECT * FROM superset_examples_2.orders`,

  dimensions: {
    id: {
      sql: `id`,
      type: `number`,
      primaryKey: true
    },

    // 'processing', 'shipped', or 'completed'
    status: {
      sql: `status`,
      type: `string`
    },

    createdAt: {
      sql: `created_at`,
      type: `time`
    },

    shippedAt: {
      sql: `shipped_at`,
      type: `time`
    },

    completedAt: {
      sql: `completed_at`,
      type: `time`
    },

    // Calculated, uses SQL functions and column references
    daysBeforeShipped: {
      sql: `TIMESTAMP_DIFF(shipped_at, created_at, DAY)`,
      type: `number`
    },

    // Calculated, uses SQL functions and column references
    daysBeforeCompleted: {
      sql: `TIMESTAMP_DIFF(completed_at, created_at, DAY)`,
      type: `number`
    }
  },

  measures: {
    count: {
      type: `count`
    },

    // Calculated, uses a dimension reference
    avgDaysBeforeShipped: {
      sql: `${daysBeforeShipped}`,
      type: `avg`
    },

    // Calculated, uses a dimension reference
    avgDaysBeforeCompleted: {
      sql: `${daysBeforeCompleted}`,
      type: `avg`
    }
  }
});

Далее отредактируем файл cube.js так, чтобы он соответствовал следующему фрагменту:

// Cube.js configuration options: https://cube.dev/docs/config

const PostgresDriver = require('@cubejs-backend/postgres-driver');
const BigQueryDriver = require('@cubejs-backend/bigquery-driver');

module.exports = {
  contextToAppId: ({ dataSource }) => dataSource,

  dbType: ({ dataSource }) => {
    return dataSource === 'bigquery'
      ? 'bigquery'
      : 'postgres';
  },

  driverFactory: ({ dataSource }) => {
    return dataSource === 'bigquery'
      ? new BigQueryDriver()
      : new PostgresDriver();
  }
};

Обратите внимание на точку расширения driverFactory, где происходит выбор базы данных: для кубов с источником данных bigquery будет использоваться BigQuery, в противном случае — Postgres. Также обратите внимание, что нам не нужно явно указывать учетные данные для Postgres и BigQuery, поскольку они надежно хранятся в настройках Cube Cloud. Не делюсь с вами учетными данными BigQuery, потому что кто бы мог это сделать?

С этими изменениями в Cube Cloud и без каких-либо изменений в Superset ваша приборная панель вернется в здоровое состояние:

О, и еще кое-что! Cube также поддерживает федерацию данных, что означает, что при необходимости вы можете объединить данные из разных источников данных, например, из Snowflake и Athena. Чтобы реализовать это, вы можете использовать предварительные агрегации и декларативно настроить предварительную агрегацию rollupJoin, которая будет легко объединять данные из нескольких источников данных под капотом.

Вишенка на вершине: Оповещения

Во всех приведенных выше примерах либо мы, либо наши пользователи должны были обнаружить неработающую приборную панель. В производственных сценариях этого точно не должно происходить. Что мы можем сделать, чтобы получить уведомление до того, как пользователи увидят неработающую приборную панель?

Поскольку мы решили запустить Cube в Cube Cloud, мы можем использовать функцию Alerts (не путать с функцией Alerts and Reports от Superset, которая представляет собой удобный способ отправки отчетов с данными приборной панели по электронной почте). Условия оповещений проверяются каждую минуту. Если срабатывает оповещение, настроенные получатели получат уведомления по электронной почте.

Вы можете настроить оповещения для таких событий, как недоступность базы данных или ошибки сборки предварительных агрегаций. В производственных сценариях Cube всегда используется с предварительными агрегациями. Это означает, что если база данных станет недоступной или данные в базе изменятся таким образом, что Cube не сможет перестроить предварительную агрегацию, вы мгновенно получите уведомление.

Настройка оповещений. Вы можете зайти в Cube Cloud, нажать на свой аватар в правом верхнем углу, нажать «Alerts», чтобы перейти на страницу Alerts, затем нажать New Alert, чтобы настроить одно из них.

Давайте воспользуемся почти стандартными настройками:

• Тип события: Сбой предварительной сборки.
• Развертывания: All.
• Отправлять оповещения: Все пользователи на этой учетной записи.

Теперь вы можете нажать Добавить.

Тестирование оповещений. Самый простой способ протестировать только что настроенное оповещение — это настроить предварительные агрегации, а затем нарушить модель данных, например, изменить имя таблицы на неправильное.

Вы можете вернуться в Cube Cloud, переключиться в режим разработки и еще раз отредактировать файл Orders.js. Давайте обновим самое начало файла таким образом:

cube(`Orders`, {
  dataSource: 'bigquery',

  // An utterly wrong table name
  sql: `SELECT * FROM superset_is_not_great`,

  // A simple pre-aggregation scheduled to refresh every hour
  preAggregations: {
    main: {
      refreshKey: {
        every: '1 hour'
      },
      dimensions: [
        status
      ]
    }
  },

// Dimensions and measures go below

После того, как вы развернете изменения, Cube Cloud попытается построить предварительную агрегацию, вероятно, он не найдет таблицу с таким замудренным именем, и в ваш почтовый ящик придет уведомление:

Если у вас нет тысяч активных пользователей Supserset, есть шанс, что вы узнаете о поломке приборной панели намного раньше своих пользователей. (Встроенный механизм кэширования Superset также может помочь в течение некоторого времени предоставлять пользователям неработающие панели).

Подведение итогов

Спасибо, что прослушали это руководство. Я искренне надеюсь, что теперь вы гораздо лучше понимаете эти темы:

• Как инструменты Headless BI (и Cube в частности) могут быть полезны для создания семантического слоя и управления моделью данных перед Superset.
• Как Cube может помочь сделать ваши приборные панели Superset надежными и неломающимися — и заранее сообщить вам, если что-то сломается.

Пожалуйста, не стесняйтесь поставить лайк, добавить эту заметку в закладки, написать комментарий и поставить звезду Cube и Superset на GitHub. Я надеюсь, что эти инструменты станут частью вашего набора инструментов.

Удачи и веселья!