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

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

Кратко Инкрементальное материализованное представление Apache Doris представляет собой партиционированное асинхронное MTMV с PARTITION BY и REFRESH AUTO. Apache Doris отслеживает актуальность каждой партиции, поэтому сегодняшняя загрузка вызывает обновление только сегодняшней партиции представления, а остальные 29 дней остаются без изменений. Запросы, охватывающие дни как с актуальными, так и с устаревшими данными, по-прежнему используют представление: оптимизатор читает актуальные партиции из MV и с помощью UNION ALL объединяет их с данными из базовой таблицы для устаревших партиций.

Инкрементальное материализованное представление Apache Doris: партиционированные асинхронные материализованные представления в режиме REFRESH AUTO перестраивают только те партиции, в которых изменились базовые данные, поддерживая актуальность дашбордов.

Зачем использовать инкрементальные материализованные представления в Apache Doris?​

Инкрементальные материализованные представления Apache Doris поддерживают актуальность дашбордов, использующих партиционированные данные: они пересчитывают только те партиции, в которых изменились базовые данные, вместо повторной агрегации всего представления при каждой загрузке. Допустим, у вас есть таблица фактов, разбитая на партиции по дням, и материализованное представление, которое агрегирует её данные для завтрашнего дашборда. Сегодняшняя загрузка записывает данные только в сегодняшнюю партицию, но при наивном подходе к обновлению всё равно пересчитывается всё представление. Обновление повторно агрегирует данные за 29 дней, которые не изменились, длится час и завершается уже после того, как данные дашборда успели устареть.

  • Таблица фактов с партициями за 30 дней, где каждая загрузка затрагивает только последний день. Полное обновление повторно агрегирует данные за 29 дней, которые не изменились.
  • Дашборды BI, которые отстают от графика загрузки, поскольку обновление MV занимает больше времени, чем интервал между загрузками.
  • Таблицы lakehouse на основе Hive или Iceberg, для которых повторное чтение всех партиций из объектного хранилища требует много времени и ресурсов.

REFRESH AUTO для партиционированного асинхронного MV сокращает эту работу до обработки фактических изменений. Apache Doris отслеживает актуальность каждой партиции, выполняет INSERT OVERWRITE только для партиций с изменившимися базовыми данными и оставляет остальную часть представления без изменений.

Что такое инкрементальное материализованное представление Apache Doris?​

Инкрементальное материализованное представление Apache Doris представляет собой партиционированное асинхронное материализованное представление (MTMV), созданное с REFRESH AUTO. Apache Doris формирует партиции представления на основе одной базовой таблицы, которую вы указываете в PARTITION BY. Необязательная функция DATE_TRUNC позволяет объединять дневные партиции базовой таблицы в месячные партиции представления. Когда данные базовой партиции меняются, только соответствующая ей партиция представления помечается как неактуальная. При следующем обновлении для неактуальных партиций выполняется INSERT OVERWRITE, по одному оператору за раз.

Ключевые термины

  • MTMV: внутренний тип таблицы, на котором основано каждое асинхронное MV. Это OLAP-таблица модели Duplicate, партициями которой управляет задание обновления, а не пользователь.
  • REFRESH AUTO: метод обновления, который сначала пытается выполнить инкрементальное обновление по партициям и переходит к полному обновлению, только если определение MV не позволяет вывести соответствие партиций. Чтобы отказаться от этого поведения, используйте REFRESH COMPLETE.
  • Partition derivation: анализ, который выполняет FE, чтобы по SQL-определению MV установить соответствие между столбцом партиционирования MV и столбцом партиционирования базовой таблицы. Если установить соответствие не удаётся, Doris отклоняет предложение партиционирования при создании представления.
  • Partition invalidation: признак неактуальности отдельной партиции, который устанавливается при изменении лежащих в её основе базовых данных. Его можно увидеть с помощью SHOW PARTITIONS FROM <mv>.
  • Partition-granularity transparent rewrite: механизм переписывания запросов может читать актуальные партиции MV и с помощью UNION ALL дополнять их данными из базовой таблицы для остальных партиций, поэтому одна устаревшая партиция больше не исключает использование всего MV.

Как работает инкрементальное материализованное представление Apache Doris?​

При создании инкрементального материализованного представления Apache Doris сопоставляет каждую партицию MV с базовой партицией. При поступлении данных помечаются только затронутые партиции MV, а при следующем обновлении только они перестраиваются с помощью INSERT OVERWRITE. Ниже описаны пять этапов: объявление, материализация, пометка неактуальных партиций, обновление и переписывание запросов на уровне партиций.

  1. Вы объявляете соответствие партиций. PARTITION BY (DATE_TRUNC(o_orderdate, 'MONTH')) указывает Apache Doris формировать партиции MV на основе orders.o_orderdate. Поддерживаются как внутренние таблицы, так и таблицы Hive; для Iceberg, Paimon и Hudi обновление по партициям появилось в версии 3.1. При этом Iceberg и Paimon также поддерживают автоматическое обнаружение изменений базовых данных, а для Hudi требуется ручное обновление.
  2. Apache Doris создаёт структуру партиций. При создании представления FE обходит базовые партиции, применяет функцию укрупнения и создаёт соответствующие партиции MV. При появлении новых базовых партиций соответствующие партиции MV создаются во время следующего обновления.
  3. Загрузка делает неактуальными отдельные партиции, а не всё представление. Загрузка в партицию таблицы orders с именем p_2026_05_08 помечает только те партиции MV, диапазон ключей которых охватывает этот день. Загрузка в используемые представлением непартиционированные таблицы по умолчанию по-прежнему делает неактуальным всё представление; перечислите эти таблицы в excluded_trigger_tables, если знаете, что в них только добавляются новые строки, а существующие никогда не обновляются.
  4. Задание обновления перестраивает только неактуальные партиции. Для каждой неактуальной партиции выполняется отдельный INSERT OVERWRITE. Свойство refresh_partition_num определяет, сколько партиций обрабатывает один оператор (по умолчанию 1), позволяя выбирать между детализацией транзакций и пропускной способностью. При сбое задача останавливается без отката уже обновлённых партиций.
  5. Оптимизатор переписывает запросы на уровне партиций. Запрос, охватывающий дни как с актуальными, так и с устаревшими данными, читает актуальные дни из MV, а устаревший день из базовой таблицы, объединяя данные через UNION ALL. Задайте grace_period, если хотите, чтобы механизм переписывания допускал использование партиций, данные которых устарели менее чем на N секунд.

Быстрый старт​

CREATE TABLE lineitem (
  l_orderkey INT, l_extendedprice DECIMAL(15,2),
  l_discount DECIMAL(15,2), l_ordertime DATETIME
) DUPLICATE KEY(l_orderkey)
PARTITION BY RANGE(l_ordertime)
  (FROM ('2026-05-01') TO ('2026-05-09') INTERVAL 1 DAY)
DISTRIBUTED BY HASH(l_orderkey) BUCKETS 3;

CREATE MATERIALIZED VIEW daily_revenue
BUILD IMMEDIATE REFRESH AUTO ON SCHEDULE EVERY 1 HOUR
PARTITION BY (DATE_TRUNC(l_ordertime, 'DAY'))
DISTRIBUTED BY RANDOM BUCKETS 2 AS
SELECT DATE_TRUNC(l_ordertime, 'DAY') AS d,
       SUM(l_extendedprice * (1 - l_discount)) AS revenue
FROM lineitem GROUP BY DATE_TRUNC(l_ordertime, 'DAY');

Ожидаемый результат

После загрузки новых строк только в базовую партицию 2026-05-08 команда SHOW PARTITIONS FROM daily_revenue подтверждает, что обновилась лишь одна партиция MV:

+--------------+--------+---------------------+
| PartitionName| State  | VisibleVersionTime  |
+--------------+--------+---------------------+
| p_20260507   | NORMAL | 2026-05-07 14:00:02 |
| p_20260508   | NORMAL | 2026-05-08 15:00:01 |
+--------------+--------+---------------------+

У более ранних партиций сохранилось прежнее значение VisibleVersionTime, поскольку они не пересчитывались. Была перестроена только p_20260508, одним оператором INSERT OVERWRITE, обрабатывающим данные за один день.

Когда следует использовать инкрементальное материализованное представление Apache Doris?​

Используйте инкрементальные материализованные представления Apache Doris для таблиц фактов, в которые преимущественно добавляются новые строки и которые разбиты на партиции по дням или часам, для многоуровневого моделирования DWD/DWS/ADS и для таблиц lakehouse Hive/Iceberg/Paimon, которые вы хотите материализовать локально. Они не подходят, если данные должны обновляться с задержкой менее секунды (используйте синхронное MV), если базовые таблицы не партиционированы, а также для таблиц Hudi, изменения базовых данных которых Apache Doris не может обнаруживать автоматически.

Подходящие сценарии

  • Таблицы фактов, в которые преимущественно добавляются новые строки и которые разбиты на партиции по дням или часам, с дашбордами, агрегирующими данные по тому же столбцу.
  • Многоуровневое моделирование (DWD, DWS, ADS), в котором часто обновляемый базовый слой передаёт данные в слой представления с более крупной гранулярностью через MV с сопоставленными партициями.
  • Таблицы lakehouse Hive, Iceberg (3.1+) или Paimon (3.1+), которые вы хотите материализовать в локальном хранилище Doris с низкими затратами на инкрементальное обновление.
  • Запросы за длительные периоды, для которых переписывание на уровне партиций позволяет получать результаты из MV, даже когда самая новая партиция на короткое время теряет актуальность.

Неподходящие сценарии

  • Обновление в реальном времени с задержкой в несколько секунд. Используйте синхронное материализованное представление: синхронные MV встроены в процесс записи в базовую таблицу.
  • Таблицы без столбца партиционирования. Без соответствия партиций MV переходит к полному обновлению, и преимущества инкрементального обновления теряются.
  • Определения MV, для которых невозможно вывести соответствие партиций. Apache Doris отклоняет предложение PARTITION BY при создании представления, если нарушено любое из восьми правил вывода: агрегация столбца партиционирования (min(o_orderdate)), его размещение на стороне OUTER JOIN, для которой формируются значения NULL, его отсутствие в GROUP BY или в оконном PARTITION BY, использование функции укрупнения, отличной от DATE_TRUNC, и так далее.
  • Базовые таблицы Hudi. Сейчас Apache Doris не может обнаруживать изменения базовых данных в Hudi, поэтому имеет смысл только ручное обновление, а решение об инкрементальном обновлении не может приниматься автоматически.
  • Таблицы, в которые вы также записываете данные из Spark или Flink в обход Apache Doris. Кэш метаданных не обнаружит эти записи, поэтому MV будет считаться синхронизированным. Принудительно запускайте обновление вручную после каждой внешней записи или выберите другой способ ускорения запросов.

Дополнительные материалы​

Report issue