Использование автономных материализованных представлений

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

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

Сведения о создании и обновлении автономных материализованных представлений с Python из записной книжки см. в статье "Использование Python с автономными конвейерами".

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

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

Материализованные представления хорошо подходят для обработки данных, таких как извлечение, преобразование и загрузка (ETL). Материализованные представления предоставляют простой декларативный способ обработки данных для соответствия, исправлений, агрегаций или общего захвата измененных данных (CDC). Материализованные представления также позволяют легко использовать преобразования путем очистки, обогащения и денормализации базовых таблиц. Путем предварительного вычисления дорогостоящих или часто используемых запросов материализованные представления снижают задержку запросов и потребление ресурсов. Во многих случаях они могут постепенно вычислить изменения из исходных таблиц, повысить эффективность и взаимодействие с конечным пользователем.

Ниже приведены распространенные случаи использования материализованных представлений.

  • Поддержание актуальной информационной панели бизнес-аналитики с минимальной задержкой запросов конечных пользователей.
  • Сокращение сложной оркестрации ETL с помощью простой логики SQL.
  • Создание сложных, многоуровневых преобразований.
  • Любые варианты использования, которые требуют стабильной производительности с up-to-date insights.

При создании материализованного представления в хранилище SQL Databricks создается бессерверный конвейер для обработки создания и обновления в материализованном представлении. Состояние операций обновления можно отслеживать в обозревателе каталогов. Смотрите сведения о просмотре с помощью DESCRIBE EXTENDED.

Требования

Сведения о параметрах вычислений, разрешениях и других требованиях для создания, обновления и запроса автономных материализованных представлений см. в разделе "Требования к автономным конвейерам".

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

Создание материализованного представления

Операции с автономным материализованным представлением CREATE используют хранилище Databricks SQL для создания материализованного представления и загрузки в него данных. Создание материализованного представления — это синхронная операция, что означает, что команда CREATE MATERIALIZED VIEW блокирует до тех пор, пока материализованное представление не будет создано и начальная загрузка данных не закончится. Бессерверный конвейер автоматически создается для каждого автономного материализованного представления. При обновлении материализованного представления конвейер выполняет процесс обновления.

Чтобы создать материализованное представление, используйте инструкцию CREATE MATERIALIZED VIEW . Чтобы отправить инструкцию создания, используйте SQL-редактор в интерфейсе Azure Databricks, Databricks SQL CLI или Databricks SQL API.

Пользователь, создающий материализованное представление, является владельцем материализованного представления.

Материализованное представление по запросу

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

-- This query defines the materialized view:
CREATE OR REPLACE MATERIALIZED VIEW mv1
AS SELECT
  date,
  sum(sales) AS sum_of_sales
FROM
  base_table1
GROUP BY
  date;

Материализованное представление на основе триггера

В следующем примере создается материализованное представление, которое автоматически обновляется при изменении вышестоящих исходных данных с помощью TRIGGER ON UPDATE. Используйте этот подход для рабочих нагрузок, особенно если вышестоящие зависимости не выполняются по прогнозируемым расписаниям.

-- Refresh automatically when the source table is updated.
CREATE OR REPLACE MATERIALIZED VIEW mv_trigger
  TRIGGER ON UPDATE
AS SELECT
  date,
  sum(sales) AS sum_of_sales
FROM
  base_table1
GROUP BY
  date;

Запланированное материализованное представление

В следующем примере создается материализованное представление с ежедневным расписанием CRON для обновления в 3:30 UTC. Выражения и агрегаты в SELECT предложении должны использовать псевдонимы. GROUP BY Ссылки на столбцы не требуют псевдонимов.

-- Refresh nightly at 3:30 AM UTC.
-- The cron expression uses six space-separated fields: seconds minutes hours day-of-month month day-of-week
-- Use '?' for either day-of-month or day-of-week to leave it unspecified.
CREATE OR REPLACE MATERIALIZED VIEW daily_revenue_by_region
  SCHEDULE CRON '0 30 3 * * ?' AT TIME ZONE 'UTC'
AS SELECT
  date_trunc('day', order_time) AS sales_date,
  region,
  sum(revenue) AS total_revenue,
  count(*) AS order_count
FROM
  orders
GROUP BY sales_date, region;

Дополнительные параметры планирования, включая синтаксис SCHEDULE EVERY и дополнительные примеры CRON, см. в разделе Настройка обновлений по расписанию.

При создании материализованного представления с помощью CREATE OR REPLACE MATERIALIZED VIEW инструкции начальное обновление данных и заполнение начинается немедленно. Это не использует вычислительные ресурсы хранилища SQL. Вместо этого бессерверный конвейер используется для создания и последующих обновлений. См. Как обновляются автономные материализованные представления?

Примечания столбцов в базовой таблице автоматически распространяются в новое материализованное представление только в момент создания. Чтобы добавить расписание, ограничения таблицы или другие свойства, измените определение материализованного представления (SQL-запрос).

Тот же SQL-запрос обновляет материализованное представление при повторном вызове или по расписанию. Обновление, выполняемое таким образом, действует как любое другое обновление. Дополнительные сведения см. в разделе "Обновление материализованного представления".

Дополнительные сведения о настройке материализованного представления см. в статье "Настройка автономных материализованных представлений". Дополнительные сведения о полном синтаксисе создания материализованного представления см. в статье CREATE MATERIALIZED VIEW. Сведения о загрузке данных в разных форматах и разных местах см. в статье "Загрузка данных в конвейерах".

Загрузка данных из внешних систем

Материализованные представления можно создавать на внешних данных с помощью Федерации Lakehouse для поддерживаемых источников данных. Для получения информации о загрузке данных из источников, не поддерживаемых федерацией Lakehouse, смотрите параметры формата данных. Общие сведения о загрузке данных, включая примеры, см. в разделе "Загрузка данных в конвейерах".

Скрытие конфиденциальных данных

Материализованные представления можно использовать для скрытия конфиденциальных данных от пользователей, обращаюющихся к таблице. Один из способов сделать это — создать запрос, чтобы он не включал эти данные в первую очередь. Но вы также можете маскировать столбцы или фильтровать строки в зависимости от разрешений пользователя, выполняющего запрос. Например, можно скрыть tax_id столбец для пользователей, не входящих в группу HumanResourcesDept. Для этого используйте ROW FILTERMASK синтаксис во время создания материализованного представления. Дополнительные сведения см. в статьях "Фильтры строк" и маски столбцов.

Обновить материализованное представление

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

При определении материализованного представления оператор CREATE OR REPLACE MATERIALIZED VIEW используется как для создания представления, так и для его обновления в случае запланированных обновлений. Можно также использовать инструкцию REFRESH MATERIALIZED VIEW для обновления материализованного представления, не требуя повторного предоставления запроса. Для получения подробной информации о синтаксисе и параметрах SQL этой команды см. REFRESH (MATERIALIZED VIEW или STREAMING TABLE). Дополнительные сведения о типах материализованных представлений, которые можно добавочно обновить, см. в разделе добавочное обновление для материализованных представлений.

Чтобы отправить инструкцию обновления, используйте редактор SQL в пользовательском интерфейсе Azure Databricks, записную книжку, подключенную к хранилищу SQL, Databricks SQL CLI или Databricks SQL API.

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

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

REFRESH MATERIALIZED VIEW mv1;

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

REFRESH MATERIALIZED VIEW mv1 ASYNC;

Сведения о планировании обновления см. в разделе "Расписание обновлений".

Как обновляются автономные материализованные представления?

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

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

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

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

  • Добавочное обновление . Система оценивает запрос представления, чтобы определить изменения, которые произошли после последнего обновления и объединяют только новые или измененные данные.
  • Полное обновление . Если добавочное обновление не может быть выполнено или не является дорогостоящим, система выполняет весь запрос и заменяет существующие данные в материализованном представлении новыми результатами.

Структура запроса и тип исходных данных определяют, поддерживается ли добавочное обновление. Для поддержки добавочного обновления исходные данные должны храниться в таблицах Delta с включенным отслеживанием строк. Рекомендуется включить поток данных об изменениях для повышения производительности инкрементального обновления. Чтобы узнать, является ли запрос добавочным, используйте инструкцию Databricks SQL EXPLAIN CREATE MATERIALIZED VIEW . После создания материализованного представления можно отслеживать его поведение обновления, чтобы проверить, обновляется ли оно постепенно или через полное обновление.

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

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

Асинхронные обновления

По умолчанию операции обновления выполняются синхронно. Вы также можете задать операцию обновления для асинхронного выполнения. Это можно задать с помощью команды обновления с ключевым словом ASYNC . См. REFRESH (MATERIALIZED VIEW или STREAMING TABLE). Поведение, связанное с каждым подходом, выглядит следующим образом:

  • синхронный: синхронное обновление не позволяет продолжать другие операции до завершения обновления. Если результат необходим для следующего шага, например при последовательности операций обновления в средствах оркестрации, таких как Задания Lakeflow, используйте синхронное обновление. Для управления материализованными представлениями посредством задания используйте тип задачи SQL. Смотрите Задания Lakeflow.
  • Асинхронное: асинхронное обновление запускает фоновое задание на бессерверных вычислениях при начале обновления материализованного представления, что позволяет команде вернуться до завершения загрузки данных. Этот тип обновления может сэкономить на затратах, так как операция не обязательно хранит вычислительные мощности в хранилище, где инициируется команда. Если обновление становится неактивным, а другие задачи не выполняются, хранилище может завершить работу, пока обновление использует другие доступные вычислительные ресурсы. Кроме того, асинхронные обновления поддерживают запуск нескольких операций параллельно.

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

Это важно

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

Замечание

  • Для использования инструкции REORG с материализованным представлением требуется Databricks Runtime 15.4 или более поздней версии.
  • Оператор REORG можно использовать с любым материализованным представлением, но он необходим только когда записи удаляются из материализованного представления с включенными векторами удаления. Команда не действует при использовании с материализованным представлением, если векторы удаления не включены.

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

Для физического удаления записей:

  1. Запустите оператор REORG для материализованного представления, указав параметр APPLY (PURGE). Например, REORG TABLE <materialized-view-name> APPLY (PURGE);. См. REORG TABLE.
  2. Дождитесь прохождения периода хранения данных материализованного представления. Срок хранения данных по умолчанию составляет семь дней, но его можно настроить с помощью свойства таблицы delta.deletedFileRetentionDuration. См. Настройка сохранения данных для запросов по временному перемещению.
  3. REFRESH материализованное представление. См. Обновите материализованное представление. В течение 24 часов после операции задачи обслуживания конвейера, включая REFRESH операцию, необходимую для окончательного VACUUM удаления записей, выполняются автоматически.

Удалить материализованное представление

Замечание

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

Чтобы удалить материализованное представление, используйте инструкцию DROP VIEW. Чтобы отправить инструкцию DROP, можно использовать редактор SQL в пользовательском интерфейсе Azure Databricks, API SQL Databricks SQL CLI или API SQL Databricks SQL. В следующем примере будет удалено материализованное представление mv1.

DROP MATERIALIZED VIEW mv1;

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

  1. Щелкните значок данных.Каталог на боковой панели.
  2. В дереве обозревателя каталогов слева откройте каталог и выберите схему, в которой находится материализованное представление.
  3. Откройте элемент Таблиц в выбранной схеме, а затем щелкните материализованное представление.
  4. На иконке меню кебаб выберите Удалить.

Общие сведения о затратах на материализованное представление

При запуске CREATE MATERIALIZED VIEW или REFRESH MATERIALIZED VIEW Azure Databricks автоматически создает и запускает бессерверный конвейер для обработки операции. Этот конвейер не зависит от хранилища Databricks SQL или вычислительного ресурса, из которого была отправлена команда. Размер кластера хранилища не ограничивает вычислительные ресурсы или затраты, используемые обновлением.

  • Конвейер обновления использует бессерверные вычислительные ресурсы, тарифицируемые в DBU бессерверных конвейеров Lakeflow.
  • Бессерверный конвейер отделен от вашего хранилища. Вычисления из хранилища используются только для координации операции, а не для обработки данных.
  • Затраты масштабируются с объемом обработанных данных, а не размером хранилища SQL.
  • Чтобы отслеживать затраты на обновление материализованного представления, используйте системные таблицы. См. раздел "Что такое потребление DBU материализованного представления или потоковой таблицы?".
  • Чтобы просмотреть основной конвейер, который обеспечивает управление материализованным представлением:
    1. Щелкните Задачи & трубопроводы в левой боковой панели рабочей области Azure Databricks.
    2. Нажмите кнопку "Тип конвейера". Затем выберите MV/ST , чтобы просмотреть автономные материализованные представления.

Замечание

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

Включение отслеживания строк

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

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

ALTER TABLE source_table SET TBLPROPERTIES (delta.enableRowTracking = true);

Дополнительные сведения см. в статье Отслеживание изменений строк в Azure Databricks

Ограничения

  • Сведения о параметрах вычислений и требованиях к рабочей области см. в разделе "Требования к автономным конвейерам".
  • Дополнительные требования к обновлению см. в разделе Добавочное обновление для материализованных представлений.
  • Материализованные представления не поддерживают столбцы идентичности или суррогатные ключи.
  • Если материализованное представление использует агрегирование суммы по столбцу NULL, и в этом столбце остаются только значения NULL, результирующее агрегатное значение материализованного представления будет равно нулю вместо NULL.
  • Вы не можете читать поток данных об изменениях из материализованного представления, если только не включите поток данных об изменениях для каждого материализованного представления, для которого он нужен. См. Чтение потока данных изменений из материализированного представления (Beta).
  • Запросы, использующие функцию перемещения во времени, не поддерживаются в материализованных представлениях.
  • Базовые файлы, поддерживающие материализованные представления, могут включать данные из вышестоящих таблиц (включая возможные личные сведения), которые не отображаются в определении материализованного представления. Эти данные автоматически добавляются в базовое хранилище для поддержки добавочного обновления материализованных представлений. Поскольку базовые файлы материализованного представления могут рисковать раскрытием данных из исходных таблиц, не входящих в схему материализованного представления, Databricks рекомендует не предоставлять общий доступ к базовому хранилищу ненадежным нижестоящим потребителям. Например, предположим, что определение материализованного представления включает условие COUNT(DISTINCT field_a). Несмотря на то, что определение материализованного представления включает только агрегатное COUNT DISTINCT предложение, базовые файлы содержат список фактических значений field_a.
  • Вы можете нести некоторые бессерверные затраты на вычислительные ресурсы, даже если эти функции используются для выделенных вычислений.
  • Если вам нужно использовать подключение Приватный канал Azure к материализованному представлению, обратитесь к представителю Databricks.

Доступ к материализованным представлениям от внешних клиентов

Чтобы получить доступ к материализованным представлениям из внешних клиентов Delta Lake или Iceberg, которые не поддерживают открытые API, можно использовать режим совместимости. Режим совместимости создает версию материализованного представления только для чтения, доступ к которому может получить любой клиент Delta Lake или Iceberg.

Дополнительные ресурсы

  • Last updated on