О MetricFlow

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

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

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

• Определяйте метрики в YAML и выполняйте запросы к ним, используя эти новые спецификации метрик.
• Для использования MetricFlow у вас должна быть версия dbt 1.6 или выше.
• Используйте MetricFlow с Snowflake, BigQuery, Databricks, Postgres (только dbt Core) или Redshift.
• Исследуйте данные и выполняйте запросы к метрикам с помощью Semantic Layer и широкого набора доступных интеграций.

MetricFlow

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

• Он работает на основе YAML-файлов, в которых семантический граф связывает бизнес-термины с данными. Этот граф состоит из семантических моделей (точек входа в данные) и метрик (функций для расчёта количественных показателей).
• MetricFlow разрабатывается и поддерживается в рамках инициативы Open Semantic Interchange (OSI).
• MetricFlow совместим с dbt версии 1.6 и выше.
• MetricFlow распространяется по лицензии Apache 2.0. Специалистов по данным и энтузиастов активно приглашают к участию в разработке. Подробнее читайте об истории лицензирования MetricFlow.
• Являясь частью Semantic Layer, MetricFlow позволяет организациям определять метрики с использованием YAML-абстракций.
• Для выполнения запросов к измерениям метрик, значениям измерений и проверки конфигураций используйте команды MetricFlow.

примечание

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

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

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

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

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

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

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

Семантические модели являются отправными точками данных и соответствуют моделям в вашем проекте 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

Расчет с помощью MetricFlow

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

Пример дохода

В этом примере мера с именем order_total определяется на основе колонки order_total в таблице orders.

Измерение времени metric_time обеспечивает дневную детализацию и может быть агрегировано в недельные или месячные периоды. Кроме того, категориальное измерение под названием is_new_customer указано в семантической модели customers.

semantic_models:
  - name: orders    # Имя семантической модели
    description: |
      Модель, содержащая данные о заказах. Зерно таблицы — это идентификатор заказа.
    model: ref('orders') # Имя модели и схемы dbt
    defaults:
      agg_time_dimension: metric_time
    entities: # Сущности, которые обычно соответствуют ключам в таблице.
      - name: order_id
        type: primary
      - name: customer
        type: foreign
        expr: customer_id
    measures:   # Меры, которые являются агрегациями на колонках в таблице.
      - name: order_total
        agg: sum
    dimensions: # Измерения могут быть категориальными или временными. Они добавляют дополнительный контекст к метрикам, и типичный шаблон запроса — Метрика по Измерению.
      - name: metric_time
        expr: cast(ordered_at as date)
        type: time
        type_params:
          time_granularity: day
  - name: customers    # Имя второй семантической модели
    description: >
      Таблица измерений клиентов. Зерно таблицы — одна строка на клиента.
    model: ref('customers') # Имя модели и схемы dbt
    defaults:
      agg_time_dimension: first_ordered_at
    entities: # Сущности, которые обычно соответствуют ключам в таблице.
      - name: customer 
        type: primary
        expr: customer_id
    dimensions: # Измерения могут быть категориальными или временными. Они добавляют дополнительный контекст к метрикам, и типичный шаблон запроса — Метрика по Измерению.
      - name: is_new_customer
        type: categorical
        expr: case when first_ordered_at is not null then true else false end
      - name: first_ordered_at
        type: time
        type_params:
          time_granularity: day

Пример с дополнительными измерениями

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

semantic_models:
  - name: orders
    description: |
      Модель, содержащая данные о заказах. Зерно таблицы — это идентификатор заказа.
    model: ref('orders')  # Имя модели и схемы dbt
    defaults:
      agg_time_dimension: metric_time
    entities: # Сущности, которые обычно соответствуют ключам в таблице
      - name: order_id
        type: primary
      - name: customer
        type: foreign
        expr: customer_id
    measures: # Меры, которые являются агрегациями на колонках в таблице.
      - name: order_total
        agg: sum
    dimensions: # Измерения могут быть категориальными или временными. Они добавляют дополнительный контекст к метрикам, и типичный шаблон запроса — Метрика по Измерению.
      - name: metric_time
        expr: cast(ordered_at as date)
        type: time
        type_params:
          time_granularity: day
      - name: is_food_order
        type: categorical

Продвинутый пример

Представьте, что требуется еще более сложная метрика, например, сумма денег, заработанных каждый день от заказов на еду от возвращающихся клиентов. Без MetricFlow исходный SQL специалиста по данным может выглядеть так:

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

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

metrics:
  - name: food_order_pct_of_order_total_returning
    description: Доход от заказов на еду от возвращающихся клиентов
    label: "Процент еды от общего заказа"
    type: ratio
    type_params:
      numerator: food_order
      denominator: order_total
    filter: |
      {{ Dimension('customer__is_new_customer') }} = false

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

 Нужно ли нормализовать мои наборы данных?

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

Рекомендуется обеспечивать качество и согласованность данных на уровне вышестоящих приложений — например, отфильтровывать некорректные данные, нормализовать общие объекты, а также выполнять моделирование ключей и таблиц. Semantic Layer более эффективен для денормализации данных, чем для их нормализации.

Если вы пока не инвестировали в обеспечение согласованности данных, это не проблема. Semantic Layer позволяет использовать SQL‑запросы или выражения для определения согласованных наборов данных.

 Почему нормализованные данные являются идеальным входом?

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

 Почему бы просто не сделать метрики такими же, как меры?

Одним из принципов MetricFlow является уменьшение дублирования логики, иногда называемого Don't Repeat Yourself (DRY).

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

Кроме того, не все метрики строятся на основе мер. Например, метрика конверсии, вероятно, определяется наличием или отсутствием записи события после некоторой другой записи события.

 Как dbt Semantic Layer обрабатывает join-ы?

dbt Semantic Layer, работающий на базе MetricFlow, строит join-ы на основе типов ключей и параметров, передаваемых в сущности (entities). Чтобы лучше понять, как формируются join-ы, ознакомьтесь с нашей документацией по типам join-ов.

Вместо описания произвольной логики соединений MetricFlow фиксирует типы каждого идентификатора и помогает пользователю выбирать корректные варианты join-ов. Это позволяет избегать fan-out и chasm join-ов, а также генерировать более понятный и читаемый SQL.

 Являются ли сущности и ключи соединения одним и тем же?

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

 Может ли таблица без первичных или уникальных сущностей иметь измерения?

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

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

• Соединения
• Валидации

Нашли ошибку?

Создать GitHub Issue