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


Используйте материализованные представления views в Databricks SQL

Эта статья описывает, как создавать и использовать материализованные объекты views в Databricks SQL для повышения производительности и снижения затрат на обработку и анализ данных.

Примечание.

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

Внимание

Материализованные views, созданные в Databricks SQL, поддерживаются бессерверным конвейером Delta Live Tables. Рабочая область должна поддерживать бессерверные конвейеры для использования этой функции.

Что означает "материализованные" views?

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

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

Материализованные views впервые поддерживались в Azure Databricks при запуске Delta Live Tables. При создании материализованного представления в хранилище SQL Databricks создается бессерверный конвейер для обработки обновлений в материализованном представлении. Вы можете отслеживать состояние операций refresh в пользовательском интерфейсе Delta Live Tables или конвейерах API. См. Просмотрите состояние материализованного представления refresh.

Требования

Чтобы создать или материализовать refreshviews:

  • Необходимо использовать pro-версию SQL-склада или бессерверное хранилище SQL с поддержкой Unity Catalog.

  • Чтобы выполнить действие refresh над материализованным представлением, необходимо находиться в рабочей области, в которой оно было создано.

  • Рабочая область должна находиться в регионе, поддерживающем бессерверные хранилища SQL.

Чтобы выполнить запрос материализованных views:

  • Вы должны быть владельцем материализованного представления или иметь SELECT на материализованном представлении, а также USE SCHEMAUSE CATALOG на своих родителях.
  • Необходимо использовать один из следующих вычислительных ресурсов:
    • Хранилище SQL
    • Интерфейсы Delta Live Tables
    • Вычисление в режиме общего доступа
    • Режим доступа к одному пользователю в Databricks Runtime 15.4 и более поздней версии, если рабочая область включена для бессерверных вычислений. Подробные инструкции по управлению доступом для отдельных пользователей.
    • Только если вы являетесь владельцем материализованного представления: один вычислительный ресурс режима доступа пользователя, на котором выполняется Среда выполнения Databricks в диапазоне от 14.3 до 15.3.

Чтобы узнать о других ограничениях на использование материализованных views, см. раздел Ограничения.

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

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

Чтобы создать материализованное представление, используйте инструкцию CREATE MATERIALIZED VIEW . Чтобы отправить инструкцию создания, используйте редактор SQL в пользовательском интерфейсе Azure Databricks, ИНТЕРФЕЙС командной строки SQL Databricks или API SQL Databricks.

Примечание.

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

  • SELECT привилегии на базу данных tables, на которую ссылается материализованное представление.
  • Привилегии USE CATALOG и USE SCHEMA на catalog и schema, содержащие исходный tables для материализованного представления.
  • Привилегии USE CATALOG и USE SCHEMA на целевые catalog и schema для материализованного представления.
  • CREATE TABLE и CREATE MATERIALIZED VIEW привилегии в schema, содержащей материализованное представление.

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

CREATE MATERIALIZED VIEW mv1
AS SELECT
  date,
  sum(sales) AS sum_of_sales
FROM
  base_table1
GROUP BY
  date;

Column примечания к базовому table автоматически распространяются на новое материализованное представление. Чтобы добавить расписание, table ограничения или другие свойства, измените определение материализованного представления. Сведения о синтаксисе определения материализованного представления см. в CREATE MATERIALIZED VIEW.

Set канал среды выполнения

Материализованные views, созданные с помощью хранилищ SQL, автоматически обновляются с помощью конвейера Delta Live Tables. Конвейеры Delta Live Tables используют среду выполнения в канале current по умолчанию. Ознакомьтесь с заметками о выпуске Tables Delta Live и процессом обновления выпуска, чтобы узнать о процессе выпуска.

Databricks рекомендует использовать current канал для рабочих нагрузок. Новые функции сначала выпускаются в preview канале. Вы можете направить set поток в канал Delta Live Tables предварительной версии, чтобы протестировать новые функции, указав preview как свойство table. Это свойство можно указать при создании table или после создания table с помощью инструкции ALTER.

В следующем примере кода показано, как set канал для предварительного просмотра в инструкции CREATE:

CREATE OR REPLACE MATERIALIZED VIEW foo.default.bar
TBLPROPERTIES ('pipelines.channel' = 'preview') as
SELECT
  *
FROM
  range(5)

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

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

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

Операция REFRESH обновляет материализованное представление, чтобы отразить последние изменения в базовой table. Операция синхронна по умолчанию, что означает, что команда блокируется до завершения операции refresh. Чтобы создать материализованное представление refresh, используйте оператор REFRESH MATERIALIZED VIEW. Подробности о синтаксисе SQL см. в REFRESH (MATERIALIZED VIEW или STREAMING TABLE), а о этой команде — в parameters. Дополнительные сведения о типах материализованных views, которые могут быть постепенно обновляемых, см. в инкрементальные refresh для материализованных views.

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

Только владелец может REFRESH материализованное представление.

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

REFRESH MATERIALIZED VIEW mv1;

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

Материализованные views автоматически создают и используют бессерверные конвейеры Delta Live Tables для обработки операций refresh. refresh управляется конвейером Delta Live Tables, а update отслеживается хранилищем Databricks SQL, используемым для создания материализованного представления. Материализованные объекты views можно обновить с помощью пакета Delta Live Tables, который выполняется по расписанию. См . раздел "Активировано и непрерывный режим конвейера".

Примечание.

Среда выполнения Delta Live Tables не может обнаруживать изменения в источниках данных, отличных от Delta. table по-прежнему регулярно обновляется, но с более высоким интервалом срабатывания по умолчанию, чтобы предотвратить чрезмерный пересчет, который может затормозить любую инкрементную обработку на вычислительном устройстве.

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

  • синхронный: синхронный refresh предотвращает выполнение других операций до завершения refresh. Если результат необходим для следующего шага, например, при упорядочивании операций refresh в инструментах оркестрации, таких как задания Databricks, используйте синхронную refresh. Чтобы управлять материализованными views в задании, используйте тип задачи SQL. См . инструкции по расписанию и оркестрации рабочих процессов.
  • Асинхронный: Асинхронный процесс refresh запускает фоновое задание на вычислительных мощностях сервиса Delta Live Tables, когда начинается материализованное refresh представление, позволяя команде завершить выполнение до завершения загрузки данных. Этот refresh тип может сэкономить на затратах, так как процесс не обязательно включает удержание вычислительных мощностей в хранилище where в момент, когда инициируется команда. Если refresh становится неактивным, а другие задачи не выполняются, хранилище может завершить работу, пока refresh использует другие доступные вычислительные ресурсы. Кроме того, асинхронные обновления поддерживают запуск нескольких операций параллельно.

Некоторые запросы можно постепенно обновлять. См. дополнительный для материализованных в инкременте. Если добавочная refresh не может быть выполнена, вместо этого выполняется полная refresh.

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

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

При создании расписания новое задание Databricks автоматически настраивается для обработки update.

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

  • Запустите инструкцию DESCRIBE EXTENDED из редактора SQL в пользовательском интерфейсе Azure Databricks.
  • Используйте Catalog Explorer для просмотра материализованного представления. Расписание отображается на вкладке Обзор под статусом Refresh. См. Что такое Catalog Explorer?.

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

Примечание.

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

Вы можете просмотреть состояние материализованного представления refresh, проверив поток, который управляет материализованным представлением в пользовательском интерфейсе Delta Live Tables или просматривая Refresh сведения, возвращенные командой DESCRIBE EXTENDED для материализованного представления.

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

Мониторинг запусков с помощью журнала запросов

Вы можете использовать страницу журнала запросов для доступа к сведениям о запросах и профилям запросов, которые помогают выявлять неэффективные запросы и узкие места в конвейере Delta Live Tables, используемом для выполнения потоковых обновлений table. Общие сведения о типах сведений, доступных для журналов запросов и профилей запросов, см. в разделе "Журнал запросов" и "Профиль запросов".

Внимание

Эта функция предоставляется в режиме общедоступной предварительной версии. Администраторы рабочей области могут включить эту функцию на странице "Предварительные версии". См. статью "Управление предварительными версиями Azure Databricks".

Все выражения, связанные с материализованными views, отображаются в журнале запросов. Чтобы любую команду и проверить связанные запросы, можно использовать раскрывающийся фильтр инструкции . За всеми операторами CREATE следует оператор REFRESH, который выполняется асинхронно в рамках конвейера Delta Live Tables. Инструкции REFRESH обычно включают подробные планы запросов, которые предоставляют аналитические сведения о оптимизации производительности.

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

  1. Щелкните Значок журнала в левой боковой панели, чтобы открыть пользовательский интерфейс журнала запросов.
  2. флажок из раскрывающегося списка инструкции .
  3. Щелкните имя инструкции запроса, чтобы просмотреть сводные сведения, такие как длительность запроса и агрегированные метрики.
  4. Щелкните "Просмотреть профиль запроса", чтобы открыть профиль запроса. Дополнительные сведения о навигации по профилю запроса см. в разделе "Профиль запроса".
  5. При необходимости используйте ссылки в разделе "Источник запросов", чтобы открыть связанный запрос или конвейер.

Примечание.

Материализованное представление должно быть настроено для запуска с помощью канала предварительной версии . См. Set канал среды выполнения.

См. CREATE MATERIALIZED VIEW.

Просмотр состояния refresh в пользовательском интерфейсе Delta Live Tables

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

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

Для асинхронных REFRESH команд, отправленных с помощью редактора SQL в пользовательском интерфейсе Azure Databricks, можно просмотреть состояние refresh, следуя ссылке, показанной на панели результатов .

остановить активный refresh

Чтобы остановить текущий refresh в пользовательском интерфейсе Delta Live Tables, на странице сведений о конвейере щелкните "Остановить", чтобы прекратить работу updateконвейера. Кроме того, можно остановить refresh с помощью Databricks CLI или операции POST /api/2.0/pipelines/{pipeline_id}/stop в API Pipelines.

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

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

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

Примечание.

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

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

DROP MATERIALIZED VIEW mv1;

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

Чтобы получить columns и типы данных для материализованного представления, используйте инструкцию DESCRIBE. Чтобы получить columns, типы данных и метаданные, такие как владелец, местоположение, время создания и статус refresh материализованного представления, используйте DESCRIBE EXTENDED. Чтобы отправить DESCRIBE инструкцию, используйте редактор SQL в пользовательском интерфейсе Azure Databricks, ИНТЕРФЕЙС командной строки SQL Databricks или API SQL Databricks.

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

Вы можете изменить владельца материализованного представления, если вы являетесь администратором хранилища метаданных и администратором рабочей области. Материализованные представления views автоматически создают и используют конвейеры Delta Live Tables для обработки изменений. Чтобы изменить владельца материализованного объекта views, выполните следующие действия.

  • На вкладке "Происхождение" для материализованного представления щелкните "Конвейеры" и щелкните ссылку конвейера.
  • Меню Кебаб Щелкните меню kebab справа от имени конвейера и щелкните "Разрешения". Откроется диалоговое окно разрешений.
  • Щелкните x справа от имени текущего владельца, чтобы remove текущего владельца.
  • Начните вводить текст, чтобы отфильтровать list доступных пользователей. Щелкните пользователя, который должен быть новым владельцем конвейера.
  • Нажмите кнопку "Сохранить", чтобы сохранить изменения и закрыть диалоговое окно.

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

контроль доступа к материализованным данным views

Материализованные views поддерживают разнообразные элементы управления доступом для поддержки обмена данными, избегая раскрытия потенциально конфиденциальных данных. Владелец материализованного представления или пользователь с правами MANAGE может grantSELECT привилегий другим пользователям. Пользователям с SELECT доступом к материализованному представлению не требуется SELECT доступ к tables, на который ссылается материализованное представление. Этот контроль доступа обеспечивает общий доступ к данным при управлении доступом к базовым данным.

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

Чтобы grant доступ к материализованному представлению, используйте инструкцию GRANT:

GRANT
  privilege_type [, privilege_type ] ...
  ON <mv_name> TO principal;

Privilege_type может быть следующим:

  • SELECT — пользователь может SELECT материализованное представление.
  • REFRESH — пользователь может REFRESH материализованное представление. Обновления выполняются с помощью разрешений владельца.

В следующем примере создается материализованное представление и предоставляются привилегии select и refresh пользователю.

CREATE MATERIALIZED VIEW <mv_name> AS SELECT * FROM <base_table>;
GRANT SELECT ON <mv_name> TO user;
GRANT REFRESH ON <mv_name> TO user;

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

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

REVOKE
  privilege_type [, privilege_type ]
  ON <name> FROM principal;

Если привилегии SELECT на базу table отозваны у владельца материализованного представления или другого пользователя, которому были предоставлены MANAGE или SELECT привилегии на материализованное представление, или когда базовая table удаляется, владелец или пользователь, которым был предоставлен доступ, по-прежнему может выполнять запросы к материализованному представлению. Однако происходит следующее поведение:

  • Материализованный владелец представления или другие пользователи, которые потеряли доступ к материализованному представлению, больше REFRESH не может это материализованное представление, и материализованное представление станет устаревшим.
  • Если автоматизировано с расписанием, следующий запланированный REFRESH сбой или не выполняется.

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

REVOKE SELECT ON mv1 FROM user1;

Включение веб-канала изменений

Канал передачи изменений данных необходим для материализованных баз viewstables, за исключением некоторых расширенных вариантов использования. Чтобы включить веб-канал изменений в базовой table, set свойство delta.enableChangeDataFeedtable с помощью следующего синтаксиса:

ALTER TABLE table1 SET TBLPROPERTIES (delta.enableChangeDataFeed = true);

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

Чтобы просмотреть состояние операций REFRESH в материализованном представлении, включая текущие и прошлые обновления, запросите журнал событий Delta Live Tables:

SELECT
  *
FROM
  event_log(TABLE(<fully-qualified-table-name>))
WHERE
  event_type = "update_progress"
ORDER BY
  timestamp desc;

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

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

Ограничения

  • Требования к вычислительным ресурсам и рабочей области см. в разделе "Требования".
  • Материализованные views не поддерживают columns индентификаторы или суррогатные ключи.
  • Если материализованное представление использует агрегирование суммы по NULLcolumn, а только NULLvalues остаются в этом column, материализованное views результирующее агрегатное значение равно нулю вместо NULL.
  • Невозможно прочитать веб-канал измененных данных из материализованного представления.
  • Запросы на перемещение по времени не поддерживаются в материализованных views.
  • Базовые файлы, поддерживающие материализованные views, могут включать данные из вышестоящих tables (включая возможные личные сведения), которые не отображаются в определении материализованного представления. Эти данные автоматически добавляются в базовое хранилище для поддержки инкрементального обновления материализованных views. Databricks рекомендует не предоставлять общий доступ к базовому хранилищу с ненадежными последующими потребителями, так как базовые файлы материализованного представления могут рисковать раскрытием данных из вышестоящего tables, не являющихся частью материализованного представления schema. Например, предположим, что определение материализованного представления включает COUNT(DISTINCT field_a) предложение. Несмотря на то что определение материализованного представления включает только предложение агрегированного COUNT DISTINCT, базовые файлы будут содержать list фактического valuesfield_a.