Планирование обновлений

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

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

Создание расписания

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

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

Обновление вручную

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

заявление REFRESH

Обновление конвейера с помощью Databricks SQL:

1. На Редактор SQL выполните следующую инструкцию:

   REFRESH MATERIALIZED VIEW <table-name>;
   

   Для потоковых таблиц используйте REFRESH STREAMING TABLE.

Дополнительные сведения см. в разделе REFRESH (MATERIALIZED VIEW или STREAMING TABLE).

Пользовательский интерфейс рабочей области

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

1. В рабочей области Azure Databricks щелкните Задания и конвейеры.
2. Выберите конвейер, который нужно обновить из списка.
3. Нажмите кнопку Пуск.

При обновлении конвейера в пользовательском интерфейсе отображаются обновления.

Триггер при обновлении

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

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

Ограничения

• Ограничения внешних зависимостей: поток данных может отслеживать не более 10 внешних таблиц и 30 внешних представлений. Чтобы управлять дополнительными зависимостями, следует распределить логику по нескольким конвейерам.
• Ограничения рабочей области: для каждой рабочей области может существовать не более 1000 конвейеров TRIGGER ON UPDATE . Обратитесь в службу поддержки Databricks, если требуется более 1000.
• Минимальный интервал: минимальный интервал триггера составляет 1 минуту.

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

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

Чтобы создать поток данных, который обновляется автоматически при изменении исходных данных, добавьте TRIGGER ON UPDATE в инструкцию CREATE.

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

CREATE OR REFRESH STREAMING TABLE catalog.schema.customer_orders
  TRIGGER ON UPDATE
AS SELECT
    o.customer_id,
    o.name,
    o.order_id
FROM catalog.schema.orders o;

Частота обновления регулирования

Если исходные данные часто обновляются, используйте AT MOST EVERY, чтобы ограничить частоту обновления представления и снизить затраты на вычисления. Это полезно, если исходные таблицы часто обновляются, но подчиненные потребители не нуждаются в данных в режиме реального времени. Ключевое INTERVAL слово необходимо перед значением времени.

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

CREATE OR REFRESH STREAMING TABLE catalog.schema.customer_orders
  TRIGGER ON UPDATE AT MOST EVERY INTERVAL 5 MINUTES
AS SELECT
    o.customer_id,
    o.name,
    o.order_id
FROM catalog.schema.orders o;

Запланированное обновление

Расписания обновления можно определить непосредственно в определении конвейера, чтобы обновить представление с фиксированным интервалом времени. Этот подход полезен, когда частота обновления данных известна и при необходимости предсказывать время обновления.

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

Databricks поддерживает два синтаксиса планирования: SCHEDULE EVERY для простых интервалов и SCHEDULE CRON для точного планирования. Ключевые слова SCHEDULE и SCHEDULE REFRESH семантически эквивалентны.

Дополнительные сведения о синтаксисе и использовании предложения смотрите в предложении SCHEDULE или CREATE STREAMING TABLE.

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

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

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

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

Планирование каждого интервала времени

В этом примере обновление запланировано каждый час. Условие EVERY поддерживает почасовые, дневные и недельные интервалы. Для подчасовых интервалов используйте вместо этого SCHEDULE CRON.

CREATE OR REPLACE MATERIALIZED VIEW catalog.schema.hourly_metrics
  SCHEDULE EVERY 1 HOUR
AS SELECT
    date_trunc('hour', event_time) AS hour,
    count(*) AS events
FROM catalog.schema.raw_events
GROUP BY 1;

Планирование использования cron

Этот пример планирует обновление каждые 15 минут в квартале часового пояса UTC:

CREATE OR REPLACE MATERIALIZED VIEW catalog.schema.regular_metrics
  SCHEDULE CRON '0 */15 * * * ?' AT TIME ZONE 'UTC'
AS SELECT
    date_trunc('minute', event_time) AS minute,
    count(*) AS events
FROM catalog.schema.raw_events
WHERE event_time > current_timestamp() - INTERVAL 1 HOUR
GROUP BY 1;

Задача SQL в задании

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

Существует два способа создания задания для обновления потоковых таблиц:

• В редакторе SQL: напишите REFRESH команду и нажмите кнопку "Расписание ", чтобы создать задание непосредственно из запроса.
• В пользовательском интерфейсе заданий: создайте новое задание, добавьте тип задачи SQL и присоедините SQL-запрос или блокнот REFRESH с помощью команды.

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

REFRESH STREAMING TABLE catalog.schema.sales;

Этот подход подходит, когда:

• Сложные многошаговые конвейеры имеют зависимости между системами.
• Требуется интеграция с системами существующей оркестрации заданий.
• Требуется оповещение уровня задания и мониторинг.

Задачи SQL используют как хранилище SQL, присоединенное к заданию, так и бессерверные вычисления, выполняющие обновление. Если планирование на основе определения потоковой таблицы соответствует требованиям, переключение на TRIGGER ON UPDATE или SCHEDULE может упростить рабочий процесс.

Добавление расписания в существующий конвейер

Чтобы задать расписание после создания, используйте ALTER STREAMING TABLE или ALTER MATERIALIZED VIEW. Рассмотрим пример.

-- Alters the schedule to refresh the streaming table when its upstream
-- data gets updated.
ALTER STREAMING TABLE sales
  ADD TRIGGER ON UPDATE;

Изменение существующего расписания или триггера

Если конвейер уже имеет расписание или триггер, используйте ALTER SCHEDULE или ALTER TRIGGER ON UPDATE, чтобы изменить конфигурацию обновления. Это относится к изменению одного расписания на другой, одному триггеру или переключению между расписанием и триггером.

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

ALTER STREAMING TABLE catalog.schema.my_table
  ALTER SCHEDULE CRON '0 */5 * * * ?';

Удаление расписания или триггера

Чтобы удалить расписание, используйте ALTER ... DROP:

ALTER STREAMING TABLE catalog.schema.my_table
  DROP SCHEDULE;

Отслеживание состояния обновления

Состояние обновления можно увидеть, проверив конвейер в интерфейсе конвейеров или просмотрев сведения об обновлении, возвращаемые DESCRIBE EXTENDED командой для набора данных.

DESCRIBE TABLE EXTENDED <table-name>;

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

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

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

• Обновление состояния и истории
• Схема таблицы
• Примеры данных (требуется активный вычислительный ресурс)
• Разрешения
• Происхождение, включая таблицы и другие конвейеры, от которых зависит этот набор данных
• Аналитические сведения об использовании
• Мониторы, созданные для этого набора данных

Остановить активное обновление

Чтобы остановить активное обновление в пользовательском интерфейсе Azure Databricks, на странице сведений о конвейере нажмите кнопку "Остановить ", чтобы остановить обновление конвейера. Вы также можете остановить обновление с помощью интерфейса командной строки Databricks или POST /api/2.0/pipelines/{pipeline_id}/stop в REST API конвейеров.

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

При открытии набора данных в обозревателе каталогов область сведений справа от рабочей области отображает расписание обновления. Щелкнув ссылку "Расписание" (например, " Каждые 1 час") вы перейдете на страницу задания (управляемого системой) задания, выполняющего расписание. Вы можете видеть историю запусков, включая график последних 48 часов, результаты которых, включая успешные и неудачные, и затраченное время. Чтобы получить дополнительные сведения, щелкните на конкретный запуск.

Вы не можете изменить это управляемое системой задание. Чтобы внести изменения в расписание, измените определение конвейера с помощью CREATE OR REFRESH или ALTER. См. статью "Изменение существующего расписания или триггера".

Таймауты для обновления данных

Обновления конвейера выполняются с таймаутом, ограничивающим продолжительность их выполнения. Для автономных конвейеров, созданных или обновленных 14 августа 2025 г. или позже, значение тайм-аута сохраняется при обновлении с помощью команды CREATE OR REFRESH:

• STATEMENT_TIMEOUT Если задано значение, используется это значение. См. STATEMENT_TIMEOUT.
• В противном случае используется время ожидания из хранилища SQL, используемого для выполнения команды. Время ожидания инструкции см. в разделе "Время ожидания инструкции".
• Если в хранилище не настроено время ожидания, применяется значение по умолчанию 2 дня.

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

Для таблиц потоковой передачи, которые были обновлены до 14 августа 2025 г., время ожидания — 2 дня.

Пример. Установка времени ожидания обновления Вы можете явно контролировать время выполнения обновления, задав время ожидания уровня инструкции при создании или обновлении набора данных:

SET STATEMENT_TIMEOUT = '6h';

CREATE OR REFRESH MATERIALIZED VIEW my_catalog.my_schema.my_mv
  SCHEDULE EVERY 12 HOURS
AS SELECT * FROM large_source_table;

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

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

Тайм-ауты синхронизируются только при явном запуске CREATE OR REFRESH.

• Запланированные обновления продолжают использовать таймаут, записанный во время последнего CREATE OR REFRESH.
• Изменение тайм-аута хранилища не влияет на существующие запланированные обновления.

Получение уведомлений о запланированных обновлениях

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

• Запланированное задание. Чтобы получить уведомления из задачи SQL в Заданиях Lakeflow, измените задачу и добавьте уведомления. См. задачу SQL для работ.

  У вас есть широкий спектр вариантов получения уведомлений и способ их получения. См. добавление уведомлений на задание

• Запланировано с условиемSCHEDULE: чтобы получать уведомления из конвейера, запланированного с помощью SCHEDULE условия в определении SQL, измените его в Обозревателе Каталогов:

  1. Откройте набор данных в обозревателе каталогов.

  2. На вкладке "Обзор" в разделе " Расписание обновления" щелкните Чтобы изменить расписание, для которого вы хотите получать уведомления.

  3. В разделе "Дополнительные параметры" добавьте или измените уведомления.

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

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

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

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

Для конвейеров, запланированных в определении SQL, можно выбрать бессерверный режим производительности вычислений с помощью параметра, оптимизированного для производительности , в обозревателе каталогов. Если этот параметр отключен (по умолчанию), конвейер использует стандартный режим производительности. Стандартный режим производительности предназначен для снижения затрат на рабочие нагрузки, в которых допустима небольшая задержка запуска. Бессерверные рабочие нагрузки, использующие стандартный режим производительности, обычно начинаются в течение четырех–шести минут после активации в зависимости от доступности вычислений и оптимизированного планирования.

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

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

По умолчанию конвейеры используют оптимизированный для производительности режим при интерактивном выполнении в пользовательском интерфейсе, параметр оптимизированного для производительности задания при планировании задачи SQL и стандартный режим при планировании. Чтобы задать режим работы для конвейеров, запланированных предложением SCHEDULE в определении, измените расписание в Catalog Explorer:

1. Откройте набор данных в обозревателе каталогов.
2. На вкладке "Обзор" в разделе " Расписание обновления" щелкните Чтобы изменить расписание, которое нужно изменить.
3. Проверьте Оптимизация производительности, чтобы использовать режим оптимизации производительности при будущих запланированных обновлениях.