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

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

Общие сведения об обновлении конвейеров см. в статье "Как обновить конвейеры?".

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

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

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

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

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

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

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

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 кэшируются автоматически внутри сеансов или между сеансами, если источники данных не изменились после выполнения последнего запроса. Поведение автоматического кэширования отличается от материализованных представлений.

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

SQL

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

Python

@dp.materialized_view()
def transaction_summary():
  return (spark.read.table("transactions_table")
    .groupBy("account_id")
    .agg(
      count("*").alias("txn_count"),
      sum("txn_amount").alias("account_revenue")
    )
  )

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

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

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

Important

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Note

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

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

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

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

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

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

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

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

REFRESH MATERIALIZED VIEW mv_name FULL

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

Important

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

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

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

Important

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

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

Ключевое слово или предложение SQL	Эквивалент DataFrame в PySpark	Поддержка пошагового обновления
SELECT Выражения*	df.select() или df.selectExpr()	Да, поддерживаются выражения, включая детерминированные встроенные функции и неизменяемые определяемые пользователем функции .UDFs.
GROUP BY	df.groupBy().agg()	Yes
WITH	Связывание переменных DataFrame.	Да, поддерживаются распространенные табличные выражения.
WITH RECURSIVE	N/A	Нет. Материализованные представления, использующие рекурсивные ОПВ, не имеют права на инкрементальное обновление и возвращаются к полному пересчету.
UNION ALL*	df.union или df.unionAll	Yes
FROM	df = spark.read...	Поддерживаемые базовые таблицы включают таблицы Delta, таблицы Iceberg, управляемые каталогом Unity, материализованные представления и потоковые таблицы.
WHERE, HAVING*	df.filter(), df.where(), df.groupBy().filter()	Предложения фильтров, такие как WHERE и HAVING, поддерживаются.
INNER JOIN*	df.join()	Yes
LEFT OUTER JOIN*	df.join(... how="left")	Yes
FULL OUTER JOIN*	df.join(... how="full")	Yes
RIGHT OUTER JOIN*	df.join(... how="right")	Yes
OVER	df.over(window.partitionBy) функции	Да. PARTITION_BY столбцы должны быть указаны для инкрементализации оконных функций.
QUALIFY	df.over(w).filter(...)	Yes
EXPECTATIONS	@dp.expect	Да, материализованные представления, включающие ожидания, можно постепенно обновлять. Однако добавочное обновление не поддерживается для следующих случаев: Когда материализованное представление считывается из представления, содержащего ожидания. Когда материализованное представление имеет ожидаемое значение DROP и включает столбцы NOT NULL в свою схему.
UDFs	UDFs	Azure Databricks пытается определить, когда поведение UDF изменяется и выполняет полное обновление. Тем не менее определяемые пользователем функции (UDF), которые вызывают другие функции или используют библиотеки, могут изменять поведение таким образом, что Azure Databricks не сможет это распознать. Если поведение UDF изменяется, вы несете ответственность за полное обновление, чтобы применить обновленный UDF к полному материализованному представлению.
Недетерминированные функции	Недетерминированные функции	Недетерминированные функции времени поддерживаются в WHERE предложениях. К ним относятся такие функции, как current_date(), current_timestamp()и now(). Другие недетерминированные функции не поддерживаются.
Недетерминированные типы данных	Недетерминированные типы данных	Агрегации, суммирующие значения с плавающей запятой, такие как SUM, AVG и ковариация, могут давать недетерминированные результаты для столбцов типа FLOAT или DOUBLE и требовать полного обновления. Приведите эти столбцы к типу DECIMAL в выражении (например, SUM(CAST(revenue AS DECIMAL(18,2)))), чтобы разрешить инкрементальное обновление.
Неподдерживаемые источники	Неподдерживаемые источники	Такие источники, как тома, удалённые расположения и зарубежные каталоги, не поддерживаются. Внешние таблицы Iceberg не поддерживаются. Управляемые каталогом Unity таблицы Iceberg поддерживаются.

Сведения о поэтапном внедрении

Когда вы разрабатываете конвейер в редакторе конвейера или отслеживаете обновление конвейера, панель Таблицы включает столбец Инкрементальная обработка, который показывает, как каждое материализованное представление было обработано при последнем обновлении:

Status	Description
Добавочное	Материализованное представление было постепенно обновлено.
Полный пересчёт	Материализованное представление было полностью перекомпилировано.
Без изменений	Не обнаружены изменения исходных данных, поэтому материализованное представление не было обновлено.

Когда Azure Databricks обнаруживает проблему, из-за которой материализованное представление не удалось инкрементально обновить или которая может помешать этому при будущем обновлении, и если для неё есть рекомендуемое исправление, рядом с состоянием появляется подсказка Выберите его, чтобы открыть панель Проблемы, отфильтрованную по этому материализованному представлению. Каждый вывод объясняет причину и рекомендует способ устранения. Ниже перечислены распространенные исправления.

• Включите отслеживание строк или векторы удаления в исходных таблицах. См. статью "Оптимизация материализованных представлений".
• Переопределите неподдерживаемый оператор в определении материализованного представления. См. Поддержка инкрементального обновления материализованных представлений.
• Настройте конвейер для использования бессерверных вычислений.

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

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

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

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

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

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

Чтобы определить используемую методику, выполните запрос к журналу событий конвейера 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 to be executed as ROW_BASED.

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

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

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

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

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

• AUTO (по умолчанию) — используйте автоматический выбор на основе затрат. Databricks выбирает добавочное или полное обновление на основе возможностей эффективности и запросов. Рекомендуется для большинства пользователей.
• INCREMENTAL — предпочитать инкрементальное обновление. Databricks выполняет добавочное обновление по возможности. Он возвращается к полному обновлению, если план запроса больше не поддерживает добавочное обновление.
• INCREMENTAL STRICT — строго требует добавочного обновления. Добавочное обновление требуется во время обычной операции. Если добавочная инкрементализация невозможна, операция обновления или создания завершается сбоем.
• FULL — Всегда выполняйте полные обновления. Databricks никогда не выполняет инкрементальное обновление, даже если запрос можно инкрементализировать.

SQL

-- 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;

Python

from pyspark import pipelines as dp

@dp.materialized_view(
  refresh_policy = 'incremental_strict'
)
def my_mv():
  return spark.read("main.default.source_table")

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

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

Дополнительные сведения и синтаксис смREFRESH. в разделе POLICY (для каналов обработки данных), или если набор данных определен в Databricks SQL, в разделе POLICYREFRESH.