Поделиться через

Добавочное обновление для материализованных представлений

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

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

Обновления выполняются на бессерверных вычислительных ресурсах

Операции обновления выполняются на бессерверных конвейерах независимо от того, была ли операция определена в Databricks SQL или в декларативных конвейерах Spark Lakeflow.

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

Для материализованных представлений, определенных с помощью декларативных конвейеров Lakeflow Spark, необходимо настроить конвейер для бессерверного использования. См. раздел "Настройка бессерверного конвейера".

Что такое семантика обновления для материализованных представлений?

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

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

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

Note

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

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

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

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

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

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

Important

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

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

  • Для запросов, где полное обновление будет слишком дорогим, используйте потоковые таблицы для обеспечения точной единовременной обработки. Примеры включают очень большие таблицы.
  • Не определяйте материализованное представление для источника данных, если записи должны обрабатываться только один раз. Вместо этого используйте потоковые таблицы. Ниже приведены примеры.
    • Источники данных, которые не сохраняют журнал данных, например Kafka.
    • Операции импорта, такие как запросы, использующие Auto Loader для импорта данных из облачного хранилища объектов.
    • Любой источник данных, в котором планируется удалить или архивировать данные после обработки, но необходимо сохранить сведения в подчиненных таблицах. Например, таблица с секционированием дат, в которой планируется удалить записи старше определенного порогового значения.
  • Не все источники данных поддерживают добавочное обновление. Следующие источники данных поддерживают добавочное обновление:
    • Таблицы Delta, включая таблицы, управляемые Unity Catalog, и внешние таблицы, поддерживаемые Delta Lake.
    • Материализованные представления.
    • Потоковые таблицы, включая цели операций AUTO CDC ... INTO.
  • Для некоторых операций добавочного обновления требуется включить отслеживание строк в запрашиваемых источниках данных. Отслеживание строк — это функция Delta Lake, поддерживаемая только таблицами Delta, которые включают материализованные представления, потоковые таблицы и управляемые таблицы каталога Unity. См. Отслеживание строк в Databricks.
  • Источники данных с фильтрами строк или масками столбцов, которые определены, не поддерживают инкрементальное обновление. См. фильтры строк и маски столбцов

Оптимизация материализованных представлений

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

Эти функции можно задать во время создания или позже с помощью инструкции ALTER TABLE. Рассмотрим пример.

ALTER TABLE <table-name> SET TBLPROPERTIES (
  delta.enableDeletionVectors = true,
  delta.enableRowTracking = true,
  delta.enableChangeDataFeed = true);

Типы обновления материализованных представлений

При обновлении материализованного представления можно указать обновление или полное обновление.

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

Сведения о том, какой тип обновления используется, см. в разделе Определение типа обновления.

Обновление по умолчанию

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

Note

Azure Databricks применяет полное или добавочное обновление. Решение основано на том, какой вариант является более экономичным и поддерживает ли запрос добавочное обновление. Чтобы изменить это поведение, ознакомьтесь с политикой обновления.

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

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

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

Сведения о том, какой тип обновления используется, см. в разделе Определение типа обновления.

Полное обновление

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

Чтобы выполнить полное обновление материализованных представлений, определенных с помощью Databricks SQL, используйте следующий синтаксис:

REFRESH MATERIALIZED VIEW mv_name FULL

Для материализованных представлений, определенных в декларативных конвейерах Spark Lakeflow, можно выполнить полное обновление выбранных наборов данных или всех наборов данных в конвейере. См. семантику обновления конвейера .

Important

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

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

В следующей таблице перечислена поддержка добавочного обновления по ключевым словам или предложениям SQL. Для проверки инкрементальности определенного запроса можно использовать EXPLAIN CREATE MATERIALIZED VIEW.

Important

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

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

Ключевое слово или предложение SQL Поддержка пошагового обновления
SELECT Выражения* Да, поддерживаются выражения, включая детерминированные встроенные функции и неизменяемые определяемые пользователем функции .UDFs.
GROUP BY Yes
WITH Да, поддерживаются распространенные табличные выражения.
UNION ALL* Yes
FROM Поддерживаемые базовые таблицы включают разностные таблицы, материализованные представления и потоковые таблицы.
WHERE, HAVING* Предложения фильтров, такие как WHERE и HAVING, поддерживаются.
INNER JOIN* Yes
LEFT OUTER JOIN* Yes
FULL OUTER JOIN* Yes
RIGHT OUTER JOIN* Yes
OVER Yes. PARTITION_BY столбцы должны быть указаны для инкрементализации оконных функций.
QUALIFY Yes
EXPECTATIONS Да, материализованные представления, включающие ожидания, можно постепенно обновлять. Однако добавочное обновление не поддерживается для следующих случаев:
  • Когда материализованное представление считывается из представления, содержащего ожидания.
  • Когда материализованное представление имеет ожидаемое значение DROP и включает столбцы NOT NULL в свою схему.
Недетерминированные функции Недетерминированные функции времени поддерживаются в WHERE предложениях. К ним относятся такие функции, как current_date(), current_timestamp()и now(). Другие недетерминированные функции не поддерживаются.
Источники, отличные от Delta Такие источники, как тома, удалённые расположения и зарубежные каталоги, не поддерживаются.

Определение типа обновления

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

Technique Пошаговое обновление? Description
FULL_RECOMPUTE No Материализованное представление было полностью перекомпилировано
NO_OP Неприменимо Материализованное представление не было обновлено, так как не было обнаружено никаких изменений в базовой таблице.
Любой из:
  • ROW_BASED
  • PARTITION_OVERWRITE
  • WINDOW_FUNCTION
  • APPEND_ONLY
  • GROUP_AGGREGATE
  • GENERIC_AGGREGATE
 Yes Материализованное представление было постепенно обновлено с помощью указанного метода.

См. также политику обновления.

Чтобы определить используемую технику, выполните запрос к журналу событий Декларативных конвейеров Spark Lakeflow, где event_type является planning_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> на полное имя материализованного представления, включая каталог и схему.

Пример выходных данных для этой команды:

    • timestamp
    • message
    • 2025-03-21T22:23:16.497+00:00
    • Flow 'sales' has been planned in :re[LDP] to be executed as ROW_BASED.

См. журнал событий конвейера.

Политика обновления

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

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

С помощью REFRESH POLICYэтого параметра можно настроить систему следующим образом:

  • AUTO (по умолчанию) — используйте автоматический выбор на основе затрат. Databricks выбирает добавочное или полное обновление на основе возможностей эффективности и запросов. Рекомендуется для большинства пользователей.
  • INCREMENTAL — предпочитать инкрементальное обновление. Databricks выполняет добавочное обновление по возможности. Он возвращается к полному обновлению, если план запроса больше не поддерживает добавочное обновление.
  • INCREMENTAL STRICT — строго требует добавочного обновления. Добавочное обновление требуется во время обычной операции. Если добавочная инкрементализация невозможна, операция обновления или создания завершается сбоем.
  • FULL — Всегда выполняйте полные обновления. Databricks никогда не выполняет инкрементальное обновление, даже если запрос можно инкрементализировать.
-- Create a materialized view with an incremental refresh policy
CREATE MATERIALIZED VIEW IF NOT EXISTS my_mv
REFRESH POLICY INCREMENTAL
AS SELECT a, sum(b) FROM my_catalog.example.my_table GROUP BY a;

Оптимальная политика обновления зависит от характеристик рабочей нагрузки:

  • AUTO подходит для большинства рабочих нагрузок. Он балансирует затраты и производительность и автоматически адаптируется при изменении поведения запросов.
  • INCREMENTAL полезен, когда добавочное обновление дает определенные преимущества, однако для Azure Databricks допустимо выполнять полные обновления в случаях, когда добавочное обновление временно недоступно (например, при отключении отслеживания строк в исходной таблице).
  • INCREMENTAL STRICT следует использовать, если требуется добавочное обновление для соответствия ограничениям по затратам, производительности или SLA, и ситуация, когда случаются непредвиденные полные обновления, неприемлема. Эта политика рекомендуется, если пользователи предпочитают, чтобы обновление не удалось, позволяя им устранить проблему, а не выполнять полное обновление.
  • FULL подходит, если добавочное обновление дает мало преимуществ, набор данных мал или структура запросов часто изменяется способами, которые препятствуют добавочной инкрементализации.
  • Last updated on