Что такое data lineage и анализ зависимостей данных — простыми словами

В отчёте — цифра, и она выглядит неправильно. Открываете SQL витрины: пять JOIN'ов, три подзапроса. Откуда это поле? Идёте в процедуру, что наполняет таблицу, оттуда — в следующую. Сорок минут спустя — всё ещё не уверены, что нашли источник.

Это и есть data lineage. Только вручную — на ощупь, с фонариком в чужом коде.

Дальше — о том, как перестать делать это руками. Без воды: что такое анализ зависимостей данных, чем уровень колонок отличается от уровня таблиц, чем lineage отличается от каталога данных и откуда вообще берётся граф.

Что такое data lineage

Data lineage — это знание о том, откуда данные пришли, как менялись и куда идут. Не диаграмма ради диаграммы. Ответ на один вопрос: тронь это — и что изменится ниже по течению?

У термина три имени, и это одно и то же:

• data lineage — международный, его и гуглят;
• происхождение данных — русская калька, встречается в документации;
• анализ зависимостей данных — то же по-русски, ближе к делу.

Дальше пользуемся всеми тремя как синонимами.

Зачем это нужно: три знакомые боли

Хотя бы одну вы узнаете.

Корень один: зависимости живут в головах, а не в системе. Это и решает анализ зависимостей данных.

Таблицы или колонки: где настоящая ценность

Lineage бывает двух уровней. Разница между ними — это разница между «таблицы как-то связаны» и «вот это поле превращается вот в то».

-- finance.report
SELECT
    o.customer_id,
    SUM(o.amount - o.discount)            AS revenue,
    SUM(o.amount - o.discount - o.cost)   AS margin
FROM orders o;

Кто-то меняет смысл orders.discount: раньше была сумма, стал процент. Что изменится ниже по течению?

• Table-level скажет одно: «finance.report читает orders». Дальше — сами.
• Column-level покажет точно: затронуты два поля — revenue и margin, — а с ними всё, что от них зависит: витрина finance.report и дашборд «Маржинальность».

Вот это — «изменили orders.discount, поехали revenue, margin и дашборд» — и есть рабочий импакт-анализ. Он живёт только на уровне колонок. Правило простое: если инструмент не доходит до полей, он отвечает «связаны ли таблицы», а не «откуда эта цифра».

Почему «просто grep» не работает

Резонный вопрос: зачем сложности, если можно грепнуть имя таблицы по всем .sql? Затем, что настоящий SQL так не читается:

• подзапросы и CTE прячут зависимости на нескольких уровнях;
• псевдонимы — FROM orders o — и grep по orders уже не находит o.amount;
• динамический SQL собирается строкой в рантайме; как текста его в коде нет;
• представления и пакеты ссылаются друг на друга по цепочке.

Поэтому зависимости извлекают настоящим парсером грамматики — разбором в AST, а не регулярками. Разница принципиальная: regex даёт дырявый граф, и хуже того — вы об этом не узнаете, пока что-нибудь не сломается в проде.

Откуда берётся граф: код, а не документация

Главная идея: происхождение данных выводят из кода, а не описывают руками. Документация устаревает; код — это правда. Собрать граф можно двумя способами, и лучше совмещать.

• Статический разбор SQL. Парсер разбирает DDL, процедуры и представления в AST и достаёт зависимости: какие таблицы читаются, какие пишутся, как колонки переходят одна в другую.
• Сбор в рантайме (OpenLineage). События о происхождении собираются прямо из пайплайнов в открытом стандарте — особенно там, где логика складывается на лету: dbt, Airflow, Spark и другие оркестраторы.

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

Чем data lineage отличается от data catalog

Их постоянно путают. Это разные вещи, отвечающие на разные вопросы.

• Data catalog отвечает «что у нас есть»: реестр таблиц, описания, владельцы, теги, глоссарий. Инвентаризация.
• Data lineage отвечает «что от чего зависит»: как данные связаны и что сломается при изменении.

Не конкуренты — дополняют друг друга. Многие каталоги (DataHub, OpenMetadata, Collibra) показывают lineage как одну из функций, но обычно до уровня таблиц; для legacy-диалектов вроде Oracle PL/SQL и для уровня колонок специализированные инструменты идут глубже. Ориентир простой: вопрос «что у нас есть» — нужен каталог; вопрос «что сломается» — нужен lineage.

Где применяют анализ зависимостей данных

• Impact-анализ — что сломается перед изменением таблицы, колонки, процедуры.
• Root-cause — почему в отчёте неверная цифра; идёте по графу вверх, к источнику.
• Миграции и рефакторинг — переносите и переписываете, зная всю цепочку.
• Чужое legacy — въехать в незнакомую схему за минуты, а не за недели, и перестать бояться её трогать.
• Онбординг — новый человек в команде сразу видит, как всё связано.

Data lineage и методологии хранилищ

Каким бы методом ни строили хранилище — Inmon, Kimball, Data Vault, Anchor — схема обрастает зависимостями, и любая методология упирается в ту же стену: что сломается, если тронуть? Lineage — не альтернатива методологии, а её продолжение. Подробный разбор подходов — в статье «Методологии хранилищ: Inmon, Kimball, Data Vault, Anchor».

Как это выглядит на практике

Современный анализ зависимостей данных устроен так: отдаёте инструменту свой SQL (PL/SQL, PostgreSQL, ClickHouse), он парсит код и строит интерактивный граф происхождения до уровня колонок. Клик по таблице — видно всё, что её читает и пишет. Импакт-анализ — перед изменением. Ответ «откуда эта цифра» — за секунды.

Так работает Сейдр Студия — анализ зависимостей данных из SQL до уровня колонок, self-hosted, с импакт-анализом и живым графом. Поддерживаемые диалекты: PL/SQL, PostgreSQL, ClickHouse.

FAQ

Коротко

• Data lineage = происхождение данных = анализ зависимостей данных — откуда данные пришли, как менялись и что от них зависит.
• Настоящая ценность — на уровне колонок, а не таблиц.
• Граф выводят из кода (AST-парсинг + OpenLineage), а не грепом и не вручную.
• Каталог отвечает «что есть», lineage — «что от чего зависит».