Инкрементные refresh для материализованных views

В этой статье описываются семантика и требования к инкрементальным обновлениям для материализованных views, а также определяются операции SQL, ключевые слова и операторы, поддерживающие инкрементальные refresh. Он включает в себя обсуждение различий между инкрементными и полными обновлениями данных, а также содержит рекомендации по выбору между материализованными views и потоковой tables.

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

Бессерверные конвейеры необходимы для добавочных refresh

Добавочные refresh для материализованных views требуют бессерверных конвейеров.

Refresh операции для материализованных views, определенных в Databricks SQL, всегда выполняются с помощью бессерверных конвейеров.

Для материализованных views, определенных с помощью конвейеров Delta Live Tables, необходимо настроить конвейер для бессерверного использования. См. настройка бессерверного конвейера Delta Live Tables.

Какова семантика refresh для материализованных views?

Материализованные представления views гарантируют результаты, эквивалентные пакетным запросам. Например, рассмотрим следующий агрегатный запрос:

SELECT account_id,
  COUNT(txn_id) txn_count,
  SUM(txn_amount) account_revenue
FROM transactions_table
GROUP BY account_id

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

Примечание.

Некоторые продукты Azure Databricks кэшируются автоматически внутри сеансов или между сеансами, если источники данных не изменились после выполнения последнего запроса. Поведение автоматического кэширования отличается от материализованных views.

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

CREATE OR REPLACE MATERIALIZED VIEW transation_summary AS
SELECT account_id,
  COUNT(txn_id) txn_count,
  SUM(txn_amount) account_revenue
FROM transactions_table
GROUP BY account_id

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

Рекомендации по источнику данных для материализованных views

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

Внимание

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

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

• Для запросов where полный refresh будет затратным, используйте потоковую tables для обеспечения обработки ровно один раз. Примеры включают очень большие tables.
• Не определяйте материализованное представление для источника данных, если записи должны обрабатываться только один раз. Вместо этого используйте потоковую tables. Ниже приведены примеры.
  • Источники данных, которые не сохраняют журнал данных, например Kafka.
  • Операции приема, такие как запросы, использующие автозагрузчик для приема данных из облачного хранилища объектов.
  • Любой источник данных where, который вы планируете удалить или архивировать после обработки, но необходимо сохранить информацию в последующих процессах tables. Например, в секционированных по дате tablewhere вы планируете удалить записи, которые старше определенного порогового значения.
• Не все источники данных поддерживают добавочное обновление. Следующие источники данных поддерживают инкрементный refresh:
  • Delta tables, включая Unity Catalog управляемые tables и внешние tables, поддерживаемые Delta Lake.
  • Материализовалось views.
  • Потоковая передача tables, включая цели операций APPLY CHANGES INTO.
• Для некоторых добавочных refresh операций требуется включить отслеживание строк в запрашиваемых источниках данных. Отслеживание строк — это функция Delta Lake, поддерживаемая только Delta tables, которая включает в себя материализованные views, потоковые tablesи управляемые Unity Catalogtables. См. раздел Использование отслеживания строк для Delta tables.

Optimize материализовались views

Чтобы get лучшую производительность, Databricks рекомендует включить следующие функции для всех материализованных источников представления tables:

• Векторы удаления
  • Отслеживание строк
  • Изменение веб-канала данных

Типы Refresh для материализованных views

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

Чтобы определить, какой refresh тип используемого update, см. определение типа refreshupdate.

Полная refresh

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

При необходимости можно принудительно заставить полную refresh. Для материализованных views, определённых с помощью Databricks SQL, используйте следующий синтаксис:

REFRESH MATERIALIZED VIEW mv_name FULL

Для материализованных views, определённых в потоковой обработке Delta Live Tables, можно выполнить полную refresh для выбранных наборов данных или всех наборов данных в потоковой обработке. См. семантика конвейера refresh.

Внимание

Когда полный запуск refresh происходит по источнику данных where, записи могут быть удалены из-за порога хранения данных или удаления вручную. Удалённые записи не учитываются в расчётных результатах. Возможно, не удается восстановить старые данные, если данные больше не доступны в источнике.

Примечание.

При необходимости можно отключить полные обновления в table, table установив для свойства pipelines.reset.allowedpipelines.reset.allowed свойство .

Добавочные refresh

Добавочный refresh обрабатывает изменения в базовых данных после последнего refresh, а затем добавляет эти данные в table. В зависимости от базовой tables и включенных операций можно постепенно обновлять только определенные типы материализованных views.

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

При создании материализованных views с помощью хранилища SQL или бессерверного конвейера Delta Live Tables они автоматически инкрементально обновляются, если их запросы поддерживаются. Если запрос содержит неподдерживаемые выражения для добавочного refresh, выполняется полная refresh, что может привести к дополнительным затратам.

поддержка добавочного refresh материализованного представления

В следующем table перечислена поддержка инкрементного refresh с использованием ключевого слова или конструкции SQL.

Внимание

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

Эти ключевые слова и предложения помечены звездой (*) в следующем разделе table.

Ключевое слово или предложение SQL	Поддержка добавочных refresh
SELECT Выражения*	Да, поддерживаются выражения, включая детерминированные встроенные функции и неизменяемые определяемые пользователем функции .UDFs.
GROUP BY	Да
WITH	Да, поддерживаются распространенные выражения table.
UNION ALL*	Да
FROM	Поддерживаемые базы данных tables включают Delta tables, материализованную viewsи потоковую tables.
WHERE, HAVING*	Предложения фильтров, такие как WHERE и HAVING поддерживаются.
INNER JOIN*	Да
LEFT OUTER JOIN*	Да
FULL OUTER JOIN*	Да
RIGHT OUTER JOIN*	Да
OVER	Да. PARTITION_BY columns необходимо указать для инкрементализации функций window.
QUALIFY	Да
EXPECTATIONS	№ Материализованные views, которые основываются на ожиданиях, всегда полностью обновляются.

Примечание.

Недетерминированные функции, например, CURRENT_TIMESTAMPне поддерживаются.

Определение типа refreshupdate

Чтобы optimize производительность материализованного представления обновляется, Azure Databricks использует модель затрат для select техники, используемой для refresh. В следующих table описаны следующие методы:

Методика	Добавочные refresh?	Description
FULL_RECOMPUTE	No	Материализованное представление было полностью перекомпилировано
NO_OP	Нет данных	Материализованное представление не было обновлено, так как не было обнаружено никаких изменений в базовом table.
ROW_BASED или PARTITION_OVERWRITE	Да	Материализованное представление было постепенно обновлено с помощью указанного метода.

Чтобы определить используемый метод, запросите журнал событий Delta Live Tableswhereevent_typeplanning_information:

SELECT
  timestamp,
  message
FROM
  event_log(TABLE(<fully-qualified-table-name>))
WHERE
  event_type = 'planning_information'
ORDER BY
  timestamp desc;

Замените <fully-qualified-table-name> полным именем материализованного представления, включая catalog и schema.

См. Что такое журнал событий Delta Live Tables?.