Перейти к основному содержимому

О MetricFlow

Это руководство вводит в основные идеи MetricFlow для тех, кто только начинает знакомиться с этой функцией. MetricFlow, который поддерживает семантический слой dbt, помогает вам определять и управлять логикой метрик вашей компании. Это набор абстракций с определенной точкой зрения, который помогает потребителям данных быстро и эффективно извлекать наборы данных метрик из платформы данных.

MetricFlow обрабатывает построение SQL-запросов и определяет спецификацию для семантических моделей и метрик dbt. Он позволяет вам определять метрики в вашем проекте dbt и запрашивать их с помощью команд MetricFlow, будь то в dbt Cloud или dbt Core.

Перед началом работы учтите следующие рекомендации:

MetricFlow​

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

  • Он работает через YAML-файлы, где семантический граф связывает язык с данными. Этот граф состоит из семантических моделей (точки входа данных) и метрик (функции для создания количественных показателей).
  • MetricFlow — это пакет BSL с доступным исходным кодом, совместимый с dbt версии 1.6 и выше. Специалисты по данным и энтузиасты настоятельно поощряются к участию.
  • Как часть семантического слоя dbt, MetricFlow позволяет организациям определять метрики, используя абстракции YAML.
  • Для запроса измерений метрик, значений измерений и проверки конфигураций используйте команды MetricFlow.

Примечание — MetricFlow в настоящее время не поддерживает встроенные функции или пакеты dbt, однако поддержка планируется в будущем.

MetricFlow придерживается следующих принципов:

  • Гибкость с полнотой: Определяйте логику метрик, используя гибкие абстракции на любой модели данных.
  • DRY (Don't Repeat Yourself): Минимизируйте избыточность, позволяя определять метрики, где это возможно.
  • Простота с постепенной сложностью: Подходите к MetricFlow, используя знакомые концепции моделирования данных.
  • Производительность и эффективность: Оптимизируйте производительность, поддерживая централизованную инженерию данных и распределенное владение логикой.

Семантический граф​

Мы вводим новую концепцию: "семантический граф". Это отношение между семантическими моделями и конфигурациями YAML, которое создает ландшафт данных для построения метрик. Вы можете думать о нем как о карте, где таблицы подобны местам, а связи между ними (ребра) подобны дорогам. Хотя это скрыто, семантический граф является подмножеством , и вы можете видеть семантические модели как узлы на DAG.

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

Когда MetricFlow генерирует метрику, он использует свой SQL-движок, чтобы определить лучший путь между таблицами, используя фреймворк, определенный в YAML-файлах для семантических моделей и метрик. Когда эти модели и метрики правильно определены, они могут быть использованы далее с интеграциями семантического слоя dbt.

Семантические модели​

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

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

  • Сущности — Ключи соединения вашей семантической модели (думайте о них как о путях перемещения или ребрах между семантическими моделями).
  • Измерения — Это способы, которыми вы хотите группировать или разбивать ваши метрики.
  • Меры — Функции агрегации, которые дают вам числовой результат и могут быть использованы для создания ваших метрик.
Семантическая модель состоит из различных компонентов: Сущности, Меры и Измерения.Семантическая модель состоит из различных компонентов: Сущности, Меры и Измерения.

Метрики​

Метрики, являющиеся ключевой концепцией, это функции, которые объединяют меры, ограничения или другие математические функции для определения новых количественных показателей. MetricFlow использует меры и различные типы агрегации, такие как среднее, сумма и количество уникальных, для создания метрик. Измерения добавляют контекст к метрикам, и без них метрика просто число за все время. Вы можете определять метрики в тех же YAML-файлах, что и ваши семантические модели, или создать новый файл.

MetricFlow поддерживает различные типы метрик:

  • Конверсия — Помогает отслеживать, когда базовое событие и последующее событие конверсии происходят для сущности в заданный период времени.
  • Кумулятивная — Агрегирует меру за заданное окно.
  • Производная — Выражение других метрик, которое позволяет выполнять вычисления на основе метрик.
  • Отношение — Создает отношение из двух мер, например, доход на клиента.
  • Простая — Метрики, которые напрямую ссылаются на одну меру.

Пример использования​

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

Следующий пример данных основан на репозитории Jaffle Shop. Вы можете просмотреть полный проект dbt. Таблицы, которые мы используем в нашем примерной модели:

  • orders — это экспорт производственной платформы данных, который был очищен и организован для аналитического потребления.
  • customers — это частично денормализованная таблица в данном случае с колонкой, полученной из таблицы заказов через некоторый процесс на более высоком уровне.

Чтобы сделать это более конкретным, рассмотрим метрику order_total, которая определяется с использованием SQL-выражения:

select sum(order_total) as order_total from orders Это выражение вычисляет общий доход от всех заказов, суммируя колонку order_total в таблице orders. В бизнес-среде метрика order_total часто рассчитывается по различным категориям, таким как:

  • Время, например date_trunc(ordered_at, 'day')
  • Тип заказа, используя измерение is_food_order из таблицы orders.

Расчет метрик​

Далее мы сравним, как специалисты по данным в настоящее время рассчитывают метрики с помощью нескольких запросов, и как MetricFlow упрощает и оптимизирует этот процесс.

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

Использование следующего запроса создает ситуацию, когда несколько аналитиков работают с одними и теми же данными, каждый используя свой метод запроса — это может привести к путанице, несоответствиям и головной боли для управления данными.

select
    date_trunc('day',orders.ordered_at) as day, 
    case when customers.first_ordered_at is not null then true else false end as is_new_customer,
    sum(orders.order_total) as order_total
from
  orders
left join
  customers
on
  orders.customer_id = customers.customer_id
group by 1, 2

Часто задаваемые вопросы​

 Нужно ли нормализовать мои наборы данных?
 Почему нормализованные данные являются идеальным входом?
 Почему бы просто не сделать метрики такими же, как меры?
 Как семантический слой dbt обрабатывает соединения?
 Являются ли сущности и ключи соединения одним и тем же?
 Может ли таблица без первичных или уникальных сущностей иметь измерения?

Связанные документы​

0
Отредактировать эту страницу