Добавочное обновление для материализованных представлений
В этой статье описываются семантика и требования к добавочным обновлениям для материализованных представлений, а также определяются операции SQL, ключевые слова и предложения, поддерживающие добавочное обновление. Он включает в себя обсуждение различий между добавочными и полными обновлениями, а также содержит рекомендации по выбору между материализованными представлениями и таблицами потоковой передачи.
При выполнении обновлений для материализованных представлений с помощью бессерверных конвейеров многие запросы можно постепенно обновлять. Добавочное обновление экономит затраты на вычисления путем обнаружения изменений в источниках данных, используемых для определения материализованного представления и добавочного вычисления результата.
Бессерверные конвейеры требуются для добавочного обновления
Добавочное обновление для материализованных представлений требует бессерверных конвейеров.
Операции обновления для материализованных представлений, определенных в Databricks SQL, всегда выполняются с помощью бессерверных конвейеров.
Для материализованных представлений, определенных с помощью конвейеров Delta Live Tables, необходимо настроить конвейер для бессерверного использования. См. статью "Настройка конвейера бессерверных динамических таблиц Delta Live Tables".
Что такое семантика обновления для материализованных представлений?
Материализованные представления гарантируют эквивалентные результаты пакетным запросам. Например, рассмотрим следующий агрегатный запрос:
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 кэшируются автоматически внутри сеансов или между сеансами, если источники данных не изменились после выполнения последнего запроса. Поведение автоматического кэширования отличается от материализованных представлений.
В следующем примере этот пакетный запрос преобразуется в материализованное представление:
CREATE OR REFRESH 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
При обновлении материализованного представления вычисляемый результат идентичен семантике пакетного запроса. Этот запрос является примером материализованного представления, которое может быть добавочно обновлено, то есть операция обновления делает лучшие усилия для обработки только новых или измененных данных в источнике transactions_table
для вычисления результатов.
Рекомендации по источнику данных для материализованных представлений
Хотя можно определить материализованное представление для любого источника данных, не все источники данных хорошо подходят для материализованных представлений. Рассмотрим следующие предостережения и рекомендации.
Внимание
Материализованные представления делают лучшие усилия для добавочного обновления результатов для поддерживаемых операций. Для некоторых изменений в источниках данных требуется полное обновление.
Все источники данных для материализованных представлений должны быть надежными для полной семантики обновления, даже если запрос, определяющий материализованное представление, поддерживает добавочное обновление.
- Для запросов, в которых полное обновление будет дорогостоящим, используйте потоковые таблицы для обеспечения точной обработки. Примеры включают очень большие таблицы.
- Не определяйте материализованное представление для источника данных, если записи должны обрабатываться только один раз. Вместо этого используйте таблицы потоковой передачи. Ниже приведены примеры.
- Источники данных, которые не сохраняют журнал данных, например Kafka.
- Операции приема, такие как запросы, использующие автозагрузчик для приема данных из облачного хранилища объектов.
- Любой источник данных, в котором планируется удалить или архивировать данные после обработки, но необходимо сохранить сведения в подчиненных таблицах. Например, таблица с секционированием дат, в которой планируется удалить записи старше определенного порогового значения.
- Не все источники данных поддерживают добавочное обновление. Следующие источники данных поддерживают добавочное обновление:
- Разностные таблицы, включая управляемые таблицы каталога Unity и внешние таблицы, поддерживаемые Delta Lake.
- Материализованные представления.
- Потоковая передача таблиц, включая целевые объекты операций
APPLY CHANGES INTO
.
- Для некоторых операций добавочного обновления требуется включить отслеживание строк в запрашиваемых источниках данных. Отслеживание строк — это функция Delta Lake, поддерживаемая только таблицами Delta, которые включают материализованные представления, потоковые таблицы и управляемые таблицы каталога Unity. См. раздел "Использование отслеживания строк" для таблиц Delta.
Оптимизация материализованных представлений
Чтобы получить лучшую производительность, Databricks рекомендует включить следующие функции во всех материализованных таблицах исходного представления:
Типы обновления для материализованных представлений
Обновления для материализованных представлений являются полными или добавочными. Для всех операций результаты добавочного обновления и полного обновления одинаковы. Azure Databricks выполняет анализ затрат, чтобы определить, требуются ли изменения источников данных для полного обновления.
Сведения о том, какой тип обновления используется, см. в разделе "Определение типа обновления" обновления.
Полное обновление
Полное обновление перезаписывает результаты материализованного представления путем повторной обработки всех данных, доступных в источнике. Все материализованные представления могут быть полностью обновлены при любом обновлении в зависимости от того, как изменились источники данных.
При необходимости можно принудительно выполнить полное обновление. Для материализованных представлений, определенных с помощью Databricks SQL, используйте следующий синтаксис:
REFRESH MATERIALIZED VIEW mv_name FULL
Для материализованных представлений, определенных в конвейере разностных динамических таблиц, можно выполнить полное обновление выбранных наборов данных или всех наборов данных в конвейере. Узнайте, как разностные динамические таблицы обновляют таблицы и представления.
Внимание
Если полное обновление выполняется в источнике данных, где записи были удалены из-за порога хранения данных или удаления вручную, удаленные записи не отражаются в вычисляемых результатах. Возможно, не удается восстановить старые данные, если данные больше не доступны в источнике.
Примечание.
При необходимости можно отключить полное обновление таблицы, задав для свойства таблицы значение pipelines.reset.allowed
false
.
Добавочное обновление
Добавочное обновление обрабатывает изменения базовых данных после последнего обновления, а затем добавляет эти данные в таблицу. В зависимости от базовых таблиц и включенных операций можно обновлять только некоторые типы материализованных представлений.
Только материализованные представления, обновленные с помощью бессерверных конвейеров, могут использовать добавочное обновление. Материализованные представления, которые не используют бессерверные конвейеры, всегда полностью обновляются.
При создании материализованных представлений с помощью хранилища SQL или конвейера бессерверных разностных динамических таблиц они автоматически обновляются при поддержке запросов. Если запрос содержит неподдерживаемые выражения для добавочного обновления, выполняется полное обновление, что может привести к дополнительным затратам.
Поддержка добавочного обновления для материализованного представления
В следующей таблице перечислены поддержку добавочного обновления ключевым словом ИЛИ предложением SQL.
Внимание
Для некоторых ключевых слов и предложений требуется включить отслеживание строк в запрашиваемых источниках данных. См. раздел "Использование отслеживания строк" для таблиц Delta.
Эти ключевые слова и предложения помечены звездой (*) в следующей таблице.
Ключевое слово или предложение SQL | Поддержка добавочного обновления |
---|---|
SELECT Выражения* |
Да, поддерживаются выражения, включая детерминированные встроенные функции и неизменяемые определяемые пользователем функции .UDFs. |
GROUP BY |
Да |
WITH |
Да, поддерживаются распространенные табличные выражения. |
UNION ALL * |
Да |
FROM |
Поддерживаемые базовые таблицы включают разностные таблицы, материализованные представления и потоковые таблицы. |
WHERE , HAVING * |
Предложения фильтров, такие как WHERE и HAVING поддерживаются. |
INNER JOIN * |
Да |
LEFT OUTER JOIN * |
Да |
FULL OUTER JOIN * |
Да |
RIGHT OUTER JOIN * |
Да |
OVER |
Да. PARTITION_BY столбцы должны быть указаны для добавочной обработки в функциях окна. |
QUALIFY |
Да |
EXPECTATIONS |
№ Материализованные представления, использующие ожидания, всегда полностью обновляются. |
Примечание.
Недетерминированные функции, например, CURRENT_TIMESTAMP
не поддерживаются.
Определение типа обновления обновления
Чтобы оптимизировать производительность материализованных обновлений представления, Azure Databricks использует модель затрат для выбора метода, используемого для обновления. В следующей таблице описаны следующие методы:
Методика | Добавочное обновление? | Description |
---|---|---|
FULL_RECOMPUTE |
No | Материализованное представление было полностью перекомпилировано |
NO_OP |
Нет данных | Материализованное представление не было обновлено, так как не было обнаружено никаких изменений в базовой таблице. |
ROW_BASED или PARTITION_OVERWRITE |
Да | Материализованное представление было постепенно обновлено с помощью указанного метода. |
Чтобы определить используемый метод, выполните запрос к журналу событий Delta Live Tables, где находится: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>
полное имя материализованного представления, включая каталог и схему.
См. раздел " Что такое журнал событий Delta Live Tables?".