Перейти к основному содержимому

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

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

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

  • Динамические таблицы — это встроенная возможность Snowflake, которая позволяет поручить хранилищу поддержание таблицы в актуальном состоянии. Вы определяете, какие данные должна содержать таблица, а хранилище автоматически поддерживает их актуальность.
  • Материализованные представления — это встроенная возможность хранилища, которая позволяет сохранять результаты запроса для ускорения чтения и обновлять их при изменении исходных данных. Обратите внимание, что конкретное поведение зависит от хранилища.
  • Инкрементальные модели — это возможность dbt, которая позволяет обновлять таблицу, обрабатывая только новые данные. Вы указываете в SQL-коде инкрементальной логики, как следует добавлять новые данные, а dbt выполняет соответствующий SQL-код при построении модели.

Когда стоит рассмотреть встроенные возможности хранилища​

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

  • Ваше требование — «данные всегда отстают от реального времени не более чем на X минут», и вам не нужен точный контроль над расписанием.
  • Вы хотите упростить эксплуатацию, передав логику обновления хранилищу.
  • Ваши преобразования относительно просты.
  • Вы готовы пожертвовать частью контроля ради удобства.

Продолжайте использовать инкрементальные модели, если:

  • Вам нужен детальный контроль над расписанием и логикой обновления.
  • У вас сложные бизнес-правила, требующие настраиваемых инкрементальных стратегий (например, микропакетной обработки).
  • Вам нужно координировать обновления нескольких моделей в определённом порядке.

Динамические таблицы​

Поддержка в хранилищах

Динамические таблицы в настоящее время поддерживаются в Snowflake; аналогичные возможности доступны в других хранилищах под другими названиями. Сведения об их доступности см. в документации вашего хранилища.

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

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

{{ config(
    materialized = 'dynamic_table',
    target_lag = '5 minutes',
    snowflake_warehouse = 'TRANSFORM_WH'  -- Snowflake syntax
) }}

select
    event_id,
    event_ts::timestamp_ntz as event_ts,
    to_date(event_ts) as event_date,
    user_id,
    event_type,
    payload
from {{ source('raw', 'events') }}
where event_ts >= current_timestamp() - interval '7 days';

Настройка target_lag​

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

Например:

  • target_lag = '1 minute' — хранилище поддерживает отставание таблицы от исходных данных в пределах одной минуты, автоматически обновляя её по мере необходимости.

  • target_lag = '5 minutes' — таблица может отставать от своих источников не более чем на пять минут.

  • target_lag = 'downstream' — таблица обновляется только тогда, когда это требуется зависящей от неё нижестоящей таблице.

  • target_lag = '1 minute' — данные обновляются так, чтобы отставание от источника не превышало 1 минуты

  • target_lag = '5 minutes' — отставание данных не превышает 5 минут

  • target_lag = 'downstream' — обновление выполняется, когда оно требуется нижестоящим таблицам

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

Преимущества​

  • Декларативное задание актуальности: укажите, «насколько актуальными должны быть данные», а не «когда их обновлять»
  • Оптимизация на стороне хранилища
  • Предсказуемость затрат: обновления выполняются только тогда, когда это необходимо для соблюдения target_lag
  • Простота настройки

Ограничения​

  • Меньше контроля над точным временем выполнения и логикой оркестрации
  • Затраты может быть сложнее прогнозировать, чем при использовании заданий dbt, выполняемых по расписанию
  • Меньше прозрачности в принятии решений об обновлении по сравнению с явно заданной инкрементальной логикой dbt
  • На данный момент зависят от хранилища (реализация различается в зависимости от платформы)

Материализованные представления​

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

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

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

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

{{ config(
    materialized = 'materialized_view'
) }}

select
    user_id,
    date_trunc('hour', event_ts) as event_hour,
    count(*) as event_count
from {{ source('raw', 'events') }}
group by 1, 2;

Материалы по хранилищам​

Ниже приведены полезные материалы для каждого хранилища:

BigQuery​

Databricks​

Postgres​

Redshift​

Snowflake​

Связанная документация​

Нашли ошибку?

0
Loading