Материализация для представлений метрик

Материализация метрик ускоряет выполнение запросов, используя материализованные представления для предварительных вычислений агрегатов. Конвейеры Lakeflow оркестрируют определённые пользователем материализованные представления для заданного представления показателей. Во время запроса оптимизатор запросов направляет запросы к лучшему материализованному представлению, используя автоматическое сопоставление запросов с учетом статистических данных (перезапись запросов). Вы запрашиваете представление метрик как обычно без дополнительных усилий вручную. Databricks обновляет материализации, чтобы поддерживать их в актуальном состоянии. Он также выбирает, какое материализованное представление использовать для выполнения запроса, чтобы выполнять запросы быстрее и с меньшими затратами.

Принцип работы материализации

Материализация для представлений метрик включает два этапа: определение материализации и выполнение запросов к нему.

Этап определения

При определении представления метрик с материализацией вы указываете поля, меры и расписание обновления в представлении метрик YAML. На основе этого определения Databricks создает управляемый конвейер Lakeflow, который формирует и поддерживает материализованные представления.

Это позволяет отделить определение метрик от того, как он хранится:

• Представление метрик — это объект каталога Unity, который определяет поля, меры и соединения метрик, а также конфигурацию материализации (расписание и детализацию). Это единственный источник истины для того, что означает метрика.
• Конвейер материализует это определение в одно или несколько материализованных представлений, каждое из которых предварительно вычислено на определённом уровне детализации. Databricks выбирает, какой из них следует читать во время запроса.

Выполнение запросов

При запуске SELECT ... FROM <metric_view>оптимизатор запросов использует перезапись агрегатных запросов для оптимизации производительности:

• Быстрый путь: считывается из предварительно вычисляемых материализованных представлений при наличии подходящей материализации.
• Резервный путь: читает данные непосредственно из источника, если подходящая материализация недоступна.

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

Требования

Чтобы использовать материализацию для представлений метрических данных:

• В вашем рабочем пространстве должны быть включены serverless-вычислительные процессы для запуска Lakeflow конвейеров.
• Хранилище SQL или вычислительный ресурс под управлением Databricks Runtime 17.3 или более поздней версии. Метрические просмотры без материализации поддерживаются, начиная с Databricks Runtime 16.4. Сведения о минимальной версии среды выполнения для каждой функции см. в разделе Доступность функций представления метрик.

Справочник по конфигурации

Вы настраиваете материализацию в поле materialization верхнего уровня в YAML-определении представления метрик. Это поле задает перезапись запроса mode (всегда relaxed), необязательное обновление schedule и список materialized_views для поддержки. Каждое материализованное представление — это либо aggregatedпредварительно вычисляющее определенные измерения и меры, либо unaggregatedматериализующее полную модель данных.

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

Пример определения

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

version: 1.1

source: prod.operations.orders_enriched_view

filter: revenue > 0

fields:
  - name: category
    expr: substring(category, 5)

  - name: color
    expr: color

measures:
  - name: total_revenue
    expr: SUM(revenue)

  - name: number_of_suppliers
    expr: COUNT(DISTINCT supplier_id)

materialization:
  schedule: every 6 hours
  mode: relaxed

  materialized_views:
    - name: baseline
      type: unaggregated

    - name: revenue_breakdown
      type: aggregated
      dimensions:
        - category
        - color
      measures:
        - total_revenue
      cluster_by:
        cols:
          - category
          - color
      partition_by:
        - category

    - name: suppliers_by_category
      type: aggregated
      dimensions:
        - category
      measures:
        - number_of_suppliers

Материализация revenue_breakdown использует cluster_by и partition_by для управления тем, как материализованные данные физически размещаются, аналогично предложениям CLUSTER BY и PARTITION BY в материализованном представлении. Полные спецификации полей см. в разделе "Материализация".

CREATE OR REPLACE VIEW catalog.schema.orders_materialized WITH METRICS LANGUAGE YAML AS
$$
  version: 1.1

  source: prod.operations.orders_enriched_view

  filter: revenue > 0

  dimensions:
    - name: category
      expr: substring(category, 5)

    - name: color
      expr: color

  measures:
    - name: total_revenue
      expr: SUM(revenue)

    - name: number_of_suppliers
      expr: COUNT(DISTINCT supplier_id)

  materialization:
    schedule: every 6 hours
    mode: relaxed

    materialized_views:
      - name: baseline
        type: unaggregated

      - name: revenue_breakdown
        type: aggregated
        dimensions:
          - category
          - color
        measures:
          - total_revenue

      - name: suppliers_by_category
        type: aggregated
        dimensions:
          - category
        measures:
          - number_of_suppliers
$$

Режим переписывания запросов

В режиме relaxed автоматическая перезапись запросов только проверяет, содержат ли потенциальные материализованные представления необходимые поля и показатели для выполнения запроса.

Следующие проверки пропускаются:

• Свежесть: Это не проверяет актуальность материализации.
• Параметры SQL: не проверяет, совпадают ли такие параметры, как TIMEZONE или ANSI_MODE.
• Детерминизм: не проверяет, что материализованные результаты полностью детерминированы.

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

Невозможно создать материализацию, если представление метрик или любая из ее исходных таблиц использует следующее:

• Безопасность на уровне строк (RLS),маскирование на уровне столбцов (CLM) или политики ABAC. Предварительно вычисляемые результаты могут обойти элементы управления доступом для каждого пользователя, которые должны применяться во время запроса.
• Выражения, зависящие от вызова, результаты которых изменяются в зависимости от того, кто выполняет запрос (например, current_user() или is_member()). Материализация предварительно вычисляется один раз и затем используется совместно, поэтому если предоставить её другому пользователю, результаты будут неверными или небезопасными.

Databricks проверяет это ограничение при создании, изменении или обновлении материализации. Эти операции завершаются с ошибкой METRIC_VIEW_MATERIALIZATION_WITH_INVOKER_DEPENDENT_EXPRESSIONS_NOT_SUPPORTED (SQLSTATE 42K0E). См. METRIC_VIEW_MATERIALIZATION_WITH_INVOKER_DEPENDENT_EXPRESSIONS_NOT_SUPPORTED.

Виды материализации для метрических представлений

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

Агрегированный тип

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

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

Для оптимальных агрегаций:

• Включите наиболее часто используемые измерения в GROUP BY предложениях.
• Добавьте все потенциальные столбцы фильтрации (столбцы, используемые в WHERE во время выполнения запроса).
• Материализуйте на самом детальном уровне, который требуется вашим запросам. Например, материализация в (region, sku, event_day) может использоваться для всего следующего:
  • GROUP BY region
  • GROUP BY region, event_month
  • GROUP BY sku С WHERE region = 'US'
• Избегайте слишком детализированных измерений, которые приводят к созданию групп, состоящих в основном из одной строки (например, необработанная метка времени с точностью до миллисекунды). Это не имеет преимуществ и раздувает хранилище.
• Следите за неаддитивными мерами. Неаддитивные меры нельзя переагрегировать на основе частичных результатов (например, COUNT(DISTINCT), MEDIAN и процентилей), и они требуют точного соответствия материализации.

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

Нерегрегированный тип

Этот тип материализует всю неагрегированную модель данных (поля source, joins, filter и fields) для более широкого охвата с меньшими затратами производительности по сравнению с агрегированным типом.

Используйте неагрегированный тип, если выполняется хотя бы одно из следующих условий:

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

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

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

Дополнительные сведения о том, как и когда использовать эти типы материализации, см. в разделе Выбор типа материализации для представлений метрик.

Автоматическая перезапись запросов

Когда вы выполняете запрос к представлению метрик, механизм переписывания запросов автоматически перенаправляет его на наилучшую из доступных материализаций. В нём используются три стратегии перезаписи запросов: точное совпадение, совпадение с агрегацией и неагрегированное совпадение.

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

1. Сначала оптимизатор запросов пытается найти точное совпадение.
2. Если точное совпадение отсутствует, оптимизатор запросов пытается найти совпадение по свёртке.
3. Если соответствия со свёрткой нет и существует неагрегированная материализация, оптимизатор запросов пытается найти неагрегированное соответствие.
4. Если нет нерегрегированного совпадения, запрос считывается непосредственно из исходных таблиц.

В следующих разделах объясняется, как работает каждая стратегия.

Точное совпадение

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

Чтобы соответствовать критерию точного совпадения:

• Выражения запроса GROUP BY должны точно соответствовать измерениям материализации.
• Меры запроса должны быть подмножеством мер материализации.

Например, материализация имеет измерения [region, order_date] и меры [total_revenue, order_count]. Запрос, который выполняет группировку по region и order_date и запрашивает total_revenue, является точным совпадением, так как измерения одинаковы, а показатель был предварительно вычислен.

Сводное совпадение

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

Чтобы соответствовать условиям для накопительного пакета:

• Более крупная гранулярность: запрос группирует по меньшему числу измерений или с более широкой временной гранулярностью, чем материализация.
• Все показатели являются аддитивными: каждый показатель, который запрашивает ваш запрос, должен быть таким, чтобы его можно было корректно пересчитать путём объединения частичных результатов (например, SUM по SUM или MAX по MAX). MEDIAN невозможно свернуть, так как это зависит от группового распределения.
• Все участвующие фильтры должны быть детерминированными выражениями: если запрос содержит WHERE предложение, фильтр должен всегда создавать одинаковый результат для одного и того же входного значения. Например, WHERE region = 'US' является детерминированным, а такие выражения, как rand() или uuid(), — нет.

Совпадение rollup не применимо к неаддитивным мерам, поскольку их невозможно корректно переагрегировать на основе частичных результатов. См. дополнительные меры.

Например, при использовании той же материализации с измерениями [region, order_date] и мерами [total_revenue, order_count] запрос, который выполняет группировку только по region и запрашивает total_revenue, является rollup-соответствием. Запросу требуется меньше измерений, чем материализовано, поэтому подсистема сворачивает ежедневные итоги в итоги уровня региона.

Аддитивные меры

Мера является аддитивной, если её агрегированный результат может быть корректно повторно вычислен путём повторного агрегирования на основе существующих материализованных агрегатов. Это ключевое требование для сопоставления rollup-данных.

Любая агрегатная функция, использующая DISTINCT (например, COUNT(DISTINCT), SUM(DISTINCT)), неаддитивна и не может быть агрегирована на более высоком уровне.

Следующие функции являются аддитивными:

• SUM
• COUNT
• MIN
• MAX
• BIT_AND
• BIT_OR
• BIT_XOR
• BOOL_AND
• BOOL_OR

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

• Определение меры должно содержать ровно одну агрегатную функцию. Показатель, определение которого сочетает несколько агрегатных функций (например, sum(cost) + min(revenue)), не может использоваться для сопоставления при свёртке.
• Если определение меры содержит FILTER предложение, оно должно быть детерминированным.
• Мера не может быть мерой, определяемой оконной функцией (например, скользящей 7-дневной суммой или сравнением год к году, заданным с помощью блока окна).

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

Неагрегированное совпадение

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

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

Например, ваш запрос выполняет группировку по category и запрашивает unique_customers, но ни одно агрегированное материализованное представление не содержит этих полей и мер. Однако существует неагрегированная материализация, содержащая объединённый и отфильтрованный набор данных. Оптимизатор запросов считывает данные из этого подготовленного набора данных и выполняет GROUP BY category, COUNT(DISTINCT customer_id) во время выполнения запроса, вместо того чтобы заново объединять исходные таблицы.

Проверка того, что запрос использует материализованные представления

Существует два способа проверить, использует ли запрос материализованное представление:

• Выполните запрос EXPLAIN EXTENDED , чтобы просмотреть план запроса. Если материализация использовалась, листовой узел включает __materialization_mat_<pipeline ID>___metric_view_mat_ и имя материализации из YAML-файла.
• Просмотрите профиль запроса, как показано ниже.

Жизненный цикл материализации

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

Создание и изменение

При создании или изменении представления метрик (с помощью CREATE, ALTER или Catalog Explorer) его определение немедленно обновляется. Материализованные представления обновляются асинхронно в фоновом режиме с помощью управляемого конвейера.

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

1. Щелкните Материализации.
2. Нажмите кнопку "Расписание", чтобы задать расписание. Можно выбрать периодичность или настроить запуск материализации на определенное время.
3. Выберите тип. Для каждого представления метрик допускается только одна неагрегированная материализация. Дополнительные сведения см. в разделе Типы материализации для представлений метрик.
4. Используйте раскрывающийся список "Поля" , чтобы выбрать поля для включения в материализацию.
5. Используйте раскрывающийся список "Меры" , чтобы выбрать меры для включения.

При создании представления метрик Databricks создает конвейер Lakeflow и сразу планирует первое обновление, если указаны материализованные представления. Метрическое представление остается доступным для запроса без материализации, обращаясь напрямую к исходным данным.

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

Изменение расписания материализации не запускает обновление.

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

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

Проверка базового конвейера

Материализация для представлений метрик реализуется с помощью конвейеров Lakeflow. Доступ к конвейеру можно получить двумя способами:

• В обозревателе каталога: вкладка "Обзор " для представления метрик содержит прямую ссылку в заголовке расписания обновления . Чтобы узнать, как получить доступ к обозревателе каталогов, см. раздел "Что такое обозреватель каталогов?".
• Использование SQL: запуск DESCRIBE EXTENDED. Раздел "Сведения об обновлении" содержит ссылку конвейера и текущее состояние обновления.

DESCRIBE EXTENDED my_metric_view;

Пример выходных данных:

-- Returns additional metadata such as parent schema, owner, access time etc.
> DESCRIBE EXTENDED my_metric_view;
                      col_name                       data_type    comment
 ------------------------------- ------------------------------ ----------
                           ...                             ...        ...

 # Detailed Table Information
                           ...                             ...

                      Language                            YAML
              Table properties                             ...
 # Refresh Information
         Latest Refresh Status                       Succeeded
                Latest Refresh                     https://...
              Refresh Schedule                   EVERY 6 HOURS

Обновление вручную

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

REFRESH MATERIALIZED VIEW <metric-view-name>

Добавочное обновление

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

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

Billing

Обновление материализованных представлений вызывает расходы на использование конвейеров Lakeflow. Чтобы найти потребление DBU конвейера, см. раздел "Что такое потребление DBU бессерверного конвейера?".

Известные ограничения

Следующие ограничения применяются к материализации для представлений метрик:

• Невозможно материализовать представление метрик, определяющее параметры.
• После создания материализации для представления метрик невозможно изменить владельца.
• Databricks не поддерживает групповое владение материализованными представлениями метрик.
• Только точную стратегию сопоставления можно использовать для представлений метрик с соединениями "один ко многим".
• Материализация schedule не поддерживает условие TRIGGER ON UPDATE.