Происхождение данных

Кратко Apache Doris извлекает сведения о происхождении данных на уровне столбцов из проанализированного плана Nereids для каждого оператора INSERT, INSERT OVERWRITE и CREATE TABLE AS SELECT, включая зависимости JOIN, FILTER, GROUP BY, WINDOW и CASE WHEN. Через SPI события передаются выбранному получателю сведений о происхождении данных: собственному модулю отправки, приёмнику OpenLineage, Apache Atlas или DataHub. Для отслеживания происхождения данных на уровне таблиц в произвольных запросах системная таблица audit_log фиксирует исходные таблицы и выбранные материализованные представления для каждого запроса.

Зачем отслеживать происхождение данных в Apache Doris?

Механизм отслеживания происхождения данных в Apache Doris предоставляет зависимости на уровне столбцов, уже вычисленные планировщиком, поэтому для анализа влияния изменений и ответов на вопросы аудита не нужно писать парсер SQL в инструменте управления данными. Вы меняете тип столбца в базовой таблице, а через четыре часа дашборд начинает возвращать значения NULL. Или кто-то спрашивает, откуда на самом деле берётся значение в tgt_region_revenue.revenue, и честный ответ звучит так: «где-то среди операторов INSERT за три года». Зависимости существуют, а SQL хранится в системе, но никто не собрал из них граф, к которому можно обращаться с запросами. Операции записи, которые используют федерацию нескольких Catalog или записывают данные в инкрементальные материализованные представления, делают граф ещё больше.

Писать собственный парсер SQL в инструменте управления данными — неверное решение. База данных уже выполнила разбор SQL. Нужно, чтобы она передала обнаруженные зависимости на уровне столбцов вместе с преобразованием, сформировавшим каждый выходной столбец. Тогда сведения о происхождении данных будут соответствовать тому, что было выполнено, а не статическому разбору DDL.

Типичные вопросы, на которые это позволяет ответить:

• Если удалить orders.o_discount, для каких зависимых таблиц и столбцов это приведёт к ошибкам?
• Откуда взялось это число на дашборде?
• К каким таблицам, на которые распространяются нормативные требования, этот пользователь обращался на прошлой неделе?

Что представляет собой отслеживание происхождения данных в Apache Doris?

Отслеживание происхождения данных в Apache Doris включает извлечение зависимостей на уровне столбцов, встроенное в планировщик Nereids, и SPI, который передаёт извлечённые события в используемую вами систему управления данными. Встроенного средства просмотра нет. Apache Doris выступает источником событий, а ваш существующий инструмент (Atlas, DataHub, OpenMetadata, внутренний сервис) — их потребителем. Для восстановления происхождения данных на уровне таблиц по истории запросов таблица audit_log уже фиксирует исходные таблицы и все подобранные материализованные представления для каждого запроса, поэтому можно построить укрупнённый граф, вообще не разрабатывая плагин.

Основные термины

• LineageInfo: формат события в памяти. Для каждого выходного столбца он содержит тип прямой зависимости (IDENTITY, TRANSFORMATION, AGGREGATION) и исходное выражение, а также косвенные зависимости на уровне набора данных (JOIN, FILTER, GROUP_BY, SORT) и на уровне отдельного столбца (WINDOW, CONDITIONAL).
• LineagePlugin: интерфейс SPI, который нужно реализовать для получения событий LineageInfo. Обнаруживается через ServiceLoader в classpath либо как внешний jar в $plugin_dir/lineage/.
• activate_lineage_plugin: параметр конфигурации FE, в котором задаются имена плагинов, получающих события. По умолчанию пуст, поэтому планировщик не занимается отслеживанием происхождения данных, пока вы не включите плагин.
• audit_log.queried_tables_and_views: столбец типа ARRAY<STRING> в __internal_schema.audit_log, содержащий имена таблиц с указанием Catalog, к которым обращается каждый запрос.
• audit_log.chosen_m_views: сопутствующий столбец со списком материализованных представлений, которые оптимизатор использовал при переписывании запроса.

Как работает отслеживание происхождения данных в Apache Doris?

Apache Doris подключается к планировщику Nereids до оптимизации, обходит проанализированный план, чтобы проследить каждый выходной столбец до его источников, фиксирует зависимости JOIN/FILTER/GROUP BY/WINDOW/CASE WHEN и передаёт событие каждому зарегистрированному LineagePlugin вне потока выполнения запроса.

1. Подключение к планировщику. Каждая команда записи (INSERT INTO, INSERT OVERWRITE, CTAS) регистрирует обработчик этапа анализа плана. Он получает проанализированный LogicalPlan до оптимизации, поэтому ссылки на столбцы ещё содержат исходные слоты, а сведения о происхождении данных соответствуют SQL, написанному пользователем.
2. Извлечение прямых зависимостей. LineageInfoExtractor обходит план и прослеживает каждый выходной столбец до его исходных выражений. Простая ссылка на столбец получает тип IDENTITY. Скалярное выражение получает тип TRANSFORMATION. Агрегатная функция получает тип AGGREGATION. Слоты потребителей CTE заранее сопоставляются со слотами производителей, чтобы цепочка не обрывалась на границе предложения WITH.
3. Извлечение косвенных зависимостей. Ключи JOIN, предикаты фильтрации и столбцы GROUP BY фиксируются как косвенные зависимости на уровне набора данных, поскольку они влияют на весь результат. Ключи разбиения WindowExpression и ветви CaseWhen/If/Coalesce фиксируются для каждого выходного столбца, чтобы можно было проследить, почему конкретное значение было получено именно таким путём.
4. Асинхронная передача. Единственный рабочий поток обрабатывает ограниченную очередь (lineage_event_queue_size, по умолчанию 50000) и последовательно передаёт каждое событие всем активным плагинам. Плагины работают вне потока выполнения запроса, поэтому медленная внешняя система замедляет обработку очереди, а не запрос, результата которого ждёт пользователь.
5. Пропуск несущественных операций. Вставки, использующие только VALUES, и операции записи в __internal_schema отфильтровываются до извлечения зависимостей. Оптимизатор не тратит ресурсы на ненужные события.

Для произвольных запросов SELECT, результаты которых не записываются, всё проще. Журнал аудита уже фиксирует исходные таблицы и все подобранные материализованные представления для каждого запроса, а по этим записям можно восстановить происхождение данных на уровне таблиц.

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

-- 1. Enable the audit plugin so query-level lineage is recorded.
SET GLOBAL enable_audit_plugin = true;

-- 2. Run a query that joins two base tables.
SELECT n.n_name, SUM(o.o_totalprice)
FROM orders o JOIN nation n ON o.o_custkey = n.n_nationkey
GROUP BY n.n_name;

-- 3. Read the lineage out of the audit log.
SELECT time, queried_tables_and_views, chosen_m_views, stmt_id
FROM   internal.__internal_schema.audit_log
WHERE  user = CURRENT_USER() AND is_query = 1
ORDER  BY time DESC LIMIT 5;

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

+---------------------+--------------------------------------------+----------------+
| time                | queried_tables_and_views                   | chosen_m_views |
+---------------------+--------------------------------------------+----------------+
| 2026-05-09 10:14:22 | ["internal.tpch.orders","internal.tpch.    | []             |
|                     |  nation"]                                  |                |
+---------------------+--------------------------------------------+----------------+

Строка содержит имена таблиц с указанием Catalog и все MV, использованные оптимизатором при переписывании запроса. Этого достаточно для построения графа зависимостей на уровне таблиц для произвольных запросов. Для отслеживания происхождения данных на уровне столбцов при записи реализуйте LineagePlugin, поместите jar в plugin_dir/lineage/ и добавьте имя плагина в activate_lineage_plugin. После этого каждый INSERT и CTAS будет формировать событие LineageInfo.

Когда стоит использовать отслеживание происхождения данных в Apache Doris?

Отслеживание происхождения данных в Apache Doris подходит для анализа влияния изменений, ведения истории для проверки соответствия требованиям, управления MV и передачи событий на уровне столбцов во внешние каталоги (Atlas, DataHub, OpenMetadata); встроенного средства просмотра происхождения данных нет, а чистые запросы SELECT на уровне столбцов не охватываются.

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

• Анализ влияния изменений схемы. На вопрос «Если удалить orders.o_discount, для каких зависимых таблиц и столбцов это приведёт к ошибкам?» как раз отвечают исходные выражения для каждого столбца.
• Аудит и проверка соответствия нормативным требованиям, когда нужно показать все обращения на чтение к таблице, подпадающей под эти требования, за определённый период. Журнал аудита предоставляет список таблиц для каждого запроса, а также пользователя, время и SQL.
• Управление материализованными представлениями. Сопоставляйте chosen_m_views из журнала аудита с асинхронными материализованными представлениями, чтобы видеть, какие MV действительно используются при обработке запросов, а какие лишь занимают ресурсы.
• Передача во внешний каталог метаданных (Apache Atlas, DataHub, OpenMetadata, внутренний сервис) сведений о происхождении данных на уровне столбцов из LineagePlugin, который отправляет события OpenLineage.
• Отслеживание происхождения данных между разными движками, когда Doris выступает одним из нескольких источников, записывающих сведения в общий каталог.

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

• Встроенное средство просмотра происхождения данных. Doris отправляет события. Визуализацию обеспечивает ваш инструмент управления данными. Если граф нужен уже сегодня, а системы управления данными у вас нет, разверните DataHub или Marquez и настройте плагин на отправку событий в эту систему.
• Отслеживание происхождения данных для чистых запросов SELECT, результаты которых не записываются. Механизм извлечения зависимостей Nereids срабатывает только для INSERT, INSERT OVERWRITE и CTAS. Для запросов только на чтение используйте массив queried_tables_and_views в журнале аудита, чтобы охватить зависимости на уровне таблиц.
• Отслеживание происхождения данных в системах, которые никак не взаимодействуют с Doris. Плагин видит запросы на стороне Doris. Задание Spark, записывающее Parquet, который Doris позднее читает, требует инструментирования на стороне Spark (например, интеграции Spark с OpenLineage), а оба потока событий объединяются в вашем каталоге.
• Хранение метаданных как единого источника достоверной информации. События происхождения данных отправляются, но не сохраняются внутри Doris. Храните их в выбранном каталоге.
• Операции с целевыми объектами в __internal_schema и вставки, использующие только VALUES. Они намеренно отфильтровываются и не формируют событий происхождения данных.

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

• Системная таблица audit_log: полное описание столбцов, включая массивы queried_tables_and_views и chosen_m_views, к которым обращаются для отслеживания происхождения данных на уровне таблиц.
• Плагин журнала аудита: как включить enable_audit_plugin, настроить интервал пакетной обработки и длину SQL, а также исключить внутренних пользователей.
• Асинхронные материализованные представления: механизм переписывания запросов, решения которого отражаются в chosen_m_views, а зависимости от базовых таблиц отслеживаются с помощью MTMVRelationManager.
• Инкрементальное материализованное представление: отслеживание зависимостей на уровне разделов между MV и базовыми таблицами, дополняющее отслеживание происхождения данных на уровне столбцов при записи.
• Спецификация OpenLineage: открытый стандарт для событий происхождения данных на уровне столбцов; подходящая целевая схема для реализации LineagePlugin.
• Управление таблицами озера данных: операции записи в Iceberg, Paimon и Hive также формируют события происхождения данных; в этом материале описаны соответствующие пути записи.
• Обзор Apache Atlas: распространённая внешняя система, которая уже принимает события OpenLineage и отображает граф зависимостей на уровне столбцов.
• Iceberg: внешний формат таблиц, история снимков которого включается в граф происхождения данных наряду с внутренними таблицами Doris.