Представления метрик модели

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

Основные компоненты, которые вы определяете, являются источниками, соединениями, фильтрами, полями и мерами.

Полный пример с соединениями, полями, мерами и метаданными агента см. в руководстве по созданию представления метрик с помощью объединения и моделирования данных.

Основные компоненты

Представление метрик состоит из следующих элементов:

Компонент	Description	Example
Источник	Базовая таблица, представление или SQL-запрос, содержащий данные.	samples.tpch.orders
Joins	Связи между таблицами, представлениями и представлениями метрик для обогащения данных.	Присоединение orders таблицы с customers таблицей в customer_key
Фильтры	Условия, применяемые к исходным данным для определения области.	status = 'completed' order_date > '2024-01-01'
Поля	Столбцы, используемые для группировки, фильтрации и агрегирования метрик. Включает категориальные столбцы и неагрегированные числовые столбцы. Также известны как измерения.	Категория продукта, месяц заказа, цена единицы
Меры	Агрегаты столбцов, которые создают метрики.	COUNT(o_orderkey) как число заказов, SUM(o_totalprice) как общий доход

Определение источника

Вы можете использовать табличный ресурс или SQL-запрос в качестве источника для представления метрик. У вас должны быть по крайней мере SELECT права доступа к любому ссылаемому ресурсу.

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

Используйте табличный ресурс в качестве источника

Чтобы использовать табличный ресурс в качестве источника, укажите полное имя. Например: samples.tpch.orders.

Использование представления метрик в качестве источника

В качестве источника для нового представления метрик можно использовать существующее представление метрик:

version: 1.1

source: views.examples.source_metric_view

fields:
  - name: Order month
    expr: '`Order Month`'

measures:
  - name: Latest order month
    expr: MAX(`Order month`)
  - name: Latest order year
    expr: "DATE_TRUNC('year', MEASURE(`Latest order month`))"

При использовании представления метрик в качестве источника применяются те же правила компостности для ссылок полей и мер. См. статью "Компонуемость".

Использование SQL-запроса в качестве источника

Чтобы использовать SQL-запрос, напишите текст запроса непосредственно в YAML:

version: 1.1

source: SELECT * FROM samples.tpch.orders o LEFT JOIN samples.tpch.customer c ON o.o_custkey
  = c.c_custkey

fields:
  - name: Order key
    expr: o_orderkey

measures:
  - name: Order Count
    expr: COUNT(o_orderkey)

Note

При использовании SQL-запроса в качестве источника с JOIN предложением задайте ограничения первичного и внешнего ключа в базовых таблицах и используйте RELY опцию для оптимальной производительности запросов. См. раздел "Объявление первичного ключа", внешнего ключа и уникальных ограничений иоптимизации запросов с помощью первичных и уникальных ограничений.

Разрешить массивы и отображения в исходном коде

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

Ни один набор данных в samples каталоге не содержит столбца массива, поэтому примеры в этом разделе используют orders представление с line_items массив структур. Используйте следующий пример, чтобы создать представление с полем, которое является массивом. Замените catalog.schema каталог и схему, в которую хотите писать. Для создания объектов в этой схеме должны быть разрешения.

CREATE OR REPLACE VIEW catalog.schema.orders AS
SELECT
  o.o_orderkey,
  o.o_custkey,
  o.o_orderdate,
  o.o_orderstatus,
  collect_list(named_struct(
    'product_id', l.l_partkey,
    'quantity', cast(l.l_quantity as int)
  )) AS line_items
FROM samples.tpch.orders o
JOIN samples.tpch.lineitem l ON o.o_orderkey = l.l_orderkey
GROUP BY o.o_orderkey, o.o_custkey, o.o_orderdate, o.o_orderstatus;

Сравняйте массив на строки

Чтобы проанализировать каждый элемент массива как отдельную строку, используйте explode() запрос source для распаковки массива. Каждый элемент становится отдельной строкой, а остальные столбцы исходной строки повторяются для каждого элемента. См. Вложенные элементы из карты или массива.

Следующий пример распаковывает line_items массив так, что каждый элемент становится строкой:

version: 1.1
source: |
  SELECT o_orderkey, o_custkey, item.product_id, item.quantity
  FROM catalog.schema.orders
  LATERAL VIEW explode(line_items) AS item

fields:
  - name: Product
    expr: product_id

measures:
  - name: Total quantity
    expr: SUM(quantity)
  - name: Line item count
    expr: COUNT(1)

Взрыв массива в множение source исходных строк, поэтому агрегация, такая как COUNT(1) считает элементы массива, а не исходные строки. Чтобы также измерить исходные строки без расширения, смоделируйте взорванную таблицу как one_to_many объединение. См. соединения "один ко многим".

Агрегировать массив в одно значение

Чтобы уменьшить массив до одного значения на строку источника без изменения количества строк, в запросе применяется функция скалярного массива source , например aggregate(), array_size(), или reduce(). Каждая исходная строка сохраняет свою зернистость, а вычисленный столбец доступен для полей и измерений.

Следующий пример вычисляет количество элементов и общее количество line_items массива по порядку:

version: 1.1
source: |
  SELECT o_orderkey, o_custkey,
    array_size(line_items) AS item_count,
    aggregate(line_items, 0, (acc, x) -> acc + x.quantity) AS total_quantity
  FROM catalog.schema.orders

measures:
  - name: Total quantity
    expr: SUM(total_quantity)
  - name: Average items per order
    expr: AVG(item_count)

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

Разрешить массив в объединённой таблице

То же правило действует, когда массив находится в таблице, к которой вы хотите присоединиться, а не в верхнем исходном коде. Объединение работает с плоскими столбцами, поэтому разрешите массив в собственном source подзапросе объединённой таблицы перед объединением. Запишите объединение source как SQL-запрос, который выравнивает или агрегирует массивы, затем соединяйте полученные столбцы. См. Соединения в метрических представлениях.

Следующий пример использует customer в качестве источника и соединяет orders представление с cardinality: one_to_many. Join source агрегирует массив line_items каждого заказа до скаляра total_quantity перед объединением, чтобы метрика могла суммировать данные для каждого клиента без дублирования строк клиента:

version: 1.1
source: samples.tpch.customer

joins:
  - name: orders
    source: |
      SELECT o_orderkey, o_custkey,
        aggregate(line_items, 0, (acc, x) -> acc + x.quantity) AS total_quantity
      FROM catalog.schema.orders
    on: orders.o_custkey = source.c_custkey
    cardinality: one_to_many

fields:
  - name: Customer name
    expr: c_name

measures:
  - name: Total quantity
    expr: SUM(orders.total_quantity)
  - name: Order count
    expr: COUNT(orders.o_orderkey)

Вместо этого рассматривать каждый элемент массива как отдельную строку в объединённой таблице, можно сравнять массив с explode() в соединении source таким же образом. См. Расплющить массив на строки.

Поля

Поля, также называемые измерениями, — это столбцы представления метрик, которые можно использовать в предложениях SELECT, WHERE и GROUP BY при выполнении запроса. Поле может быть категориальным столбцом, например регионом или состоянием, или нерегрегированным числовым столбцом, например ценой или количеством, которые можно агрегировать во время запроса. Каждое выражение поля должно возвращать скалярное значение. Он может ссылаться на столбцы из исходных данных или полей, определенных ранее в представлении метрик. Каждое поле состоит из двух компонентов:

• name: псевдоним столбца
• expr: выражение SQL, ссылающееся на исходные данные или ранее определенные поля в представлении метрик

Предупреждение

Поля представления метрик, подобные строке, всегда всегда STRING, даже если исходный столбец имеет CHAR или VARCHAR. Поскольку CHAR(n) заполнение пробелами утрачивается, сравнения могут давать разные результаты. Например, column = 'COLLEGE' соответствует значению CHAR(10) в исходной таблице (дополненному пробелами), но не в поле представления метрики.

Меры

Меры — это выражения, которые создают результаты без предварительно определенного уровня агрегирования. Они должны быть выражены с помощью агрегатных функций. Чтобы ссылаться на меру в запросе, используйте функцию MEASURE . Показатели могут ссылаться на базовые столбцы в исходных данных, ранее определённые поля или ранее определённые показатели. Каждая мера состоит из следующих компонентов:

• name: псевдоним меры
• expr: статистическое выражение SQL, которое может включать агрегатные функции SQL

В следующем примере показаны распространенные шаблоны мер для анализа данных о заказах и доходах. В этих примерах используется таблица заказов TPC-H, содержащая данные о транзакциях продаж, включая цены на заказы (), идентификаторы клиентов (o_totalprice), ключи заказа (o_custkeyo_orderkey), даты заказа (o_orderdate) и уровни приоритета (o_orderpriority):

measures:
  # Simple count measure
  - name: Order Count
    expr: COUNT(1)

  # Sum aggregation measure
  - name: Total Revenue
    expr: SUM(o_totalprice)

  # Distinct count measure
  - name: Unique Customers
    expr: COUNT(DISTINCT o_custkey)

  # Calculated measure combining multiple aggregations
  - name: Average Order Value
    expr: SUM(o_totalprice) / COUNT(DISTINCT o_orderkey)

  # Filtered measure with WHERE condition
  - name: High Priority Order Revenue
    expr: SUM(o_totalprice) FILTER (WHERE o_orderpriority = '1-URGENT')

  # Measure using a field
  - name: Average Revenue per Month
    expr: SUM(o_totalprice) / COUNT(DISTINCT DATE_TRUNC('MONTH', o_orderdate))

См. раздел "Агрегатные функции " для списка агрегатных функций.

Применение фильтров

Фильтр применяется ко всем запросам, ссылающимся на представление метрик. Чтобы определить фильтр в пользовательском интерфейсе, см. шаг 3. Определение фильтра.

Чтобы определить фильтр в определении YAML, напишите логическое выражение. В следующем примере показаны распространенные шаблоны фильтров:

# Single condition
filter: o_orderdate > '2024-01-01'

# Multiple conditions
filter: o_orderdate > '2024-01-01' AND o_orderstatus = 'F'

# IN clause
filter: o_orderstatus IN ('F', 'P') AND o_orderdate >= '2024-01-01'

Работа с соединениями

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

Чтобы определить соединения в пользовательском интерфейсе, см. шаг 2. Добавление соединения. Чтобы определить соединения в определении YAML, используйте шаблоны в следующих разделах.

Note

Объединённые таблицы не могут включать ARRAY или MAP вводить столбцы. Чтобы разрешить массивы или отображения в плоские столбцы перед присоединением, см. раздел «Разрешить массивы и отображения» в исходном коде.

Модели звездчатых схем

В звездной схеме source является таблицей фактов и соединяется с одной или несколькими таблицами измерений с помощью LEFT OUTER JOIN. Представления метрик объединяют таблицы фактов и измерений, необходимые для конкретного запроса, на основе выбранных полей и мер.

Укажите столбцы для соединения с помощью предложения on (логическое выражение) или предложения using (имена общих столбцов). Соединение должно соответствовать связи типа "многие к одному". В случаях отношения «многие ко многим» механизм выбирает первую совпадающую строку из присоединённой таблицы измерений.

Следующий пример объединяет (таблицу фактов orders ) с customer (таблицей измерений) и предоставляет атрибуты клиента в виде полей. Параметр rely.at_most_one_match: true указывает, что соединение является отношением «многие к одному» (у каждого заказа есть ровно один клиент), что позволяет механизму оптимизировать запросы, в которых фильтрация выполняется по полям из присоединённой таблицы.

Предупреждение

Устанавливайте at_most_one_match: true только в том случае, если связь имеет тип «многие к одному». Это свойство не проверяется во время выполнения. Если соединение создает вентилятор, меры возвращают неверные результаты.

См. Оптимизация соединений с rely.

version: 1.1
source: samples.tpch.orders

joins:
  - name: customer
    source: samples.tpch.customer
    on: source.o_custkey = customer.c_custkey

fields:
  - name: Customer name
    expr: customer.c_name

measures:
  - name: Total revenue
    expr: SUM(o_totalprice)

Синтаксис и форматирование YAML

Определения представления метрик соответствуют стандартному синтаксису нотации YAML. См. справочник по синтаксису YAML представления метрик для требуемого синтаксиса и форматирования.

Лучшие практики

Используйте следующие рекомендации при моделировании представлений метрик:

• Атомарные меры модели: сначала определите простейшие меры (например, SUM(revenue), COUNT(DISTINCT customer_id)). Создавайте сложные измерения, используя компонуемость.
• Стандартизируйте значения полей: используйте преобразования (например, инструкции CASE) для преобразования кодов из базы данных в понятные бизнес-наименования (например, преобразуйте статус заказа "O" в "Открыт", а "F" — в "Выполнено").
• Определение области с фильтрами. Если представление метрик должно включать только завершенные заказы, определите этот фильтр в представлении метрик, чтобы пользователи не могли случайно включать неполные данные.
• Используйте четкое именование: имена метрик должны быть распознаваемыми для бизнес-пользователей (например, "Значение времени существования клиента" вместо cltv_agg_measure).
• Отдельные поля времени: включите детализированные поля времени (например, "Дата заказа") и усеченные поля времени (например, "Месяц заказа" или "Неделя заказа") для включения анализа детализации и тренда.

Дополнительные ресурсы

• Объединения в представлениях метрик
• Продвинутые методы для представлений метрик
• Метаданные агента в представлениях метрик
• Материализация для представлений метрик
• Справочник по синтаксису YAML представления метрик