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

Создание метрик

Как создать метрики​

  • 💹 Начнем с одной из самых важных метрик для любого бизнеса: выручка.
  • 📖 На данный момент наша метрика для выручки будет определена как сумма итогов заказов без учета налогов.

Определение выручки​

  • 🔢 Метрики имеют четыре основных свойства:
    • name: Мы будем использовать 'revenue' для обозначения этой метрики.
    • description: Для документации.
    • label: Отображаемое имя метрики в последующих инструментах.
    • type: один из simple, ratio или derived.
  • 🎛️ Каждый тип имеет разные type_params.
  • 🛠️ Сначала мы создадим простую метрику, чтобы освоиться, а затем перейдем к метрикам типа ratio и derived.
  • 📏 Простые метрики строятся на одной мере, определенной как параметр типа.
  • 🔜 Определение мер как их собственных отдельных компонентов в семантических моделях критически важно для обеспечения гибкости более сложных метрик, хотя простые метрики в основном действуют как передаточные, предоставляющие возможности фильтрации и маркировки.
models/marts/orders.yml
metrics:
  - name: revenue
    description: Sum of the order total.
    label: Revenue
    type: simple
    type_params:
      measure: order_total

Запрос вашей метрики​

Вы можете использовать Cloud CLI для проверки метрик или выполнения запросов на этапе разработки с помощью набора подкоманд dbt sl. Ниже приведены несколько полезных примеров:

dbt sl query revenue --group-by metric_time__month
dbt sl list dimensions --metrics revenue # список всех доступных измерений для метрики выручки
  • Лучшей практикой при любом обновлении кода Semantic Layer является запуск dbt parse, чтобы обновить семантический манифест для среды разработки.
  • Команда dbt sl query обычно не используется в продакшене — там за это отвечают возможности Semantic Layer в dbt. Эта команда предназначена для тестирования результатов различных запросов к метрикам в процессе разработки, именно так, как мы используем её сейчас.
  • Обратите внимание на структуру приведённого выше запроса. Мы выбираем метрику(и), которые нам нужны, и измерения, по которым хотим их агрегировать. Для обозначения временных измерений или других неуникальных измерений, которым требуется явное указание пути сущности для разрешения, мы используем dunders (двойное подчёркивание, например metric_time__[time bucket]). Например, если у вас есть измерение локации для заказов и измерение локации для сотрудников, и оба называются location, вам потребуется использовать dunders, чтобы явно указать orders__location или employee__location.

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

0
Loading