Что такое data lineage: происхождение данных

Что такое data lineage? Это происхождение данных и запись их пути: где данные возникли, как менялись в ETL- и ELT-процессах и куда в итоге попали внутри пайплайна. Так описывает предмет статья IBM о data lineage. Дальше — уровни, учебный граф полей и разбор влияния изменения.

Определение и уровни lineage

IBM определяет data lineage как процесс отслеживания потока данных во времени: он даёт ясное понимание того, где данные возникли, как изменились и каково их конечное назначение внутри пайплайна. Инструменты lineage ведут запись данных на протяжении жизненного цикла, включая сведения об источнике и преобразованиях, применённых в ETL- или ELT-процессах. Это определение задаёт три обязательных элемента любой карты: источник, преобразование, назначение.

В этом разборе сравним два уровня детализации. Dataset-level lineage показывает связь таблиц и файлов: таблица A попала в таблицу B. Column-level lineage показывает связь конкретных полей: orders.amount превратился в gross. Документация Google Cloud по Knowledge Catalog описывает column-level lineage как отдельный слой со своими ограничениями, а в модели данных lineage вообще оперирует сущностями process, run и event. Process — это определение преобразования, run — одно исполнение процесса, event — запись перемещения данных во время run. Такая трёхуровневая модель отвечает на разные вопросы: «какая логика существует», «когда она выполнялась», «что именно перетекло».

Практический вывод для читателя: начинайте с dataset-level, чтобы увидеть маршрут, и спускайтесь к column-level, когда нужно понять судьбу конкретного поля отчёта. Общую карту таблиц можно раскрывать до полей, сохраняя понятный масштаб детализации.

Отдельно стоит зафиксировать, чем lineage не является. Документация Google Cloud прямо указывает: lineage записывает метаданные о перемещении данных и не захватывает сами данные. Карта зависимостей и запланированное преобразование не доказывают, что задание действительно выполнилось. Это ограничение снимает иллюзию, будто граф lineage подтверждает корректность чисел.

Источники и преобразования

Источники lineage — это системы, откуда приходят данные и откуда приходит сама запись о движении. Документация Google Cloud перечисляет три способа наполнения: автоматически из интегрированных сервисов Google Cloud, вручную через Data Lineage API для произвольных источников и импортом событий по стандарту OpenLineage. Для BigQuery автоматическая запись охватывает новые таблицы, созданные заданиями copy, load и query, а также существующие таблицы при операциях DML: INSERT SELECT, MERGE, UPDATE, DELETE. Каждое такое задание представлено как process, и в атрибутах процесса сохраняется job_id.

Преобразования — это то, что меняет данные между источником и назначением. В модели Google Cloud преобразование описывается процессом, а конкретное перемещение — событием со списком links, где каждая связь задаёт один путь от сущности-источника к сущности-назначению. Сущность идентифицируется Fully Qualified Name, а одно событие может содержать несколько связей — типичный случай при соединении таблиц, когда несколько источников питают одну цель.

Microsoft Purview в своей документации описывает ту же идею другими словами: datasets — это узлы, а processes — рёбра. Датасетом считается таблица SQL, blob или файл, процессом — активность вроде копирования в Data Factory. Системы-источники lineage Purview делит на три группы: системы обработки данных, системы хранения и системы аналитики и отчётности. Power BI, например, отдаёт lineage по датасетам, потокам данных, отчётам и дашбордам.

В объектной модели OpenLineage dataset и job идентифицируются именем в пределах namespace. Run представляет отдельное исполнение job и получает runId в формате UUID. Событие RunEvent фиксирует исполнение задания во время работы, а JobEvent и DatasetEvent описывают статичные метаданные на этапе проектирования. Это различие важно: статичное описание задания и факт его запуска — разные записи.

Учебный граф полей

Разберём учебный граф, где все имена, строки и суммы вымышлены для обучения. Схема такая: CRM.orders.amount попадает в staging_orders.amount, затем в daily_gross.gross = sum(amount), затем в dashboard.gross. Параллельная ветка: refunds.amount питает daily_net.net = daily_gross.gross − sum(refunds.amount), и результат уходит в dashboard.net.

Строки учебного дня: заказы 100 + 40 = 140, возвраты 20, отсюда gross 140 и net 120. Эти числа — условный вход примера; измерения не проводились. Они нужны, чтобы увидеть, как арифметика графа превращается в конкретные значения на дашборде.

Поле refunds.reason в арифметике не участвует. По этой карте оно не влияет на gross и net: причина возврата хранится рядом, но в формулу не входит. Так выглядит практический вывод из column-level lineage — видно, какие поля реально определяют число, а какие просто лежат в той же таблице.

Отдельная ветка помечена как UNKNOWN. Ручная корректировка net в Excel обозначена этим статусом: автоматический граф не доказывает её происхождение. Это честная позиция карты — там, где автоматический сбор не видит связи, остаётся пробел, и его нужно закрывать вручную или признавать открытым.

Граф показывает зависимость, но не подтверждает, что сумма 140 финансово верна. Для этого нужен отдельный тест или сверка. Точность column-level lineage зависит от поддерживаемых источников и преобразований, и неизвестное ребро нельзя дорисовать произвольно.

Учебный граф полей (все имена и суммы вымышлены)

CRM.orders.amount
  → staging_orders.amount
  → daily_gross.gross = sum(amount)
  → dashboard.gross

refunds.amount
  → daily_net.net = daily_gross.gross − sum(refunds.amount)
  → dashboard.net

Строки дня: orders 100 + 40 = 140; refunds 20; gross 140, net 120.
Поле refunds.reason в арифметике не участвует.
Ручная правка net в Excel: статус UNKNOWN.

Анализ влияния изменения

Анализ влияния отвечает на вопрос: что сломается, если поменять значение или поле. В учебном графе заменим orders.amount на 100 + 50. Тогда gross становится 150, а net — 130, потому что net считается как gross минус возвраты. Одно изменение в источнике прошло через staging, агрегат и дошло до двух чисел дашборда.

IBM описывает impact analysis как штатный сценарий: инструменты lineage дают видимость последствий конкретных бизнес-изменений, включая нижележащую отчётность. Если меняется имя элемента данных, lineage помогает понять, сколько дашбордов это затронет и сколько пользователей обращается к такой отчётности. Там же указано, что lineage помогает оценить влияние ошибок данных и их распространение по организации.

Документация Google Cloud формулирует ту же задачу через управление изменениями: прежде чем менять или удалять часть данных, например колонку в таблице, команде нужно знать каждый нижележащий отчёт или модель, которые от неё зависят, чтобы не сломать критичные системы. Для глубокого анализа документация предлагает метод SearchLineageStreaming с обходом до 100 уровней, а для немедленных одноуровневых запросов — SearchLinks. Направление задаётся явно: UPSTREAM для источников, DOWNSTREAM для назначений.

Порядок действий при оценке влияния выглядит так. Сначала найдите поле-кандидат на изменение в графе. Затем пройдите вниз по связям и выпишите все узлы, где это поле участвует в формуле. После этого отметьте узлы со статусом UNKNOWN — там влияние не доказано и требует ручной проверки. В конце сверьте числа на дашборде с ожидаемыми: в примере это 150 и 130.

Ошибка, которую легко допустить: считать, что изменение поля затрагивает все поля той же таблицы. В учебном графе refunds.reason лежит рядом с refunds.amount, но в арифметику не входит, поэтому по этой карте изменение причины возврата не сдвинет gross и net. Границы влияния определяют по формуле.

Автосбор и пробелы

Автосбор lineage строится на интеграциях. Документация Google Cloud перечисляет поддерживаемые сервисы: BigQuery, Dataflow, Dataform, Looker, Managed Service for Apache Airflow, Managed Service for Apache Spark, Vertex AI Feature Store и Vertex AI Pipelines. Для части сервисов интеграцию можно включать и выключать на уровне окружения. Пользовательские источники закрываются через Data Lineage API с ручной записью, а события рекомендуется импортировать в формате OpenLineage.

Пробелы автосбора задокументированы конкретными продуктами. В Knowledge Catalog column-level lineage не собирается для заданий load в BigQuery и для routines, включая многооператорные скрипты и инкрементальные таблицы Dataform. Column-level lineage не собирается, если задание создаёт больше 1500 связей уровня колонок — тогда остаётся только табличный уровень. Связи не переносятся при переименовании таблиц через ALTER TABLE RENAME. Поддержка ограничена колонками верхнего уровня: вложенные поля сложных типов вроде STRUCT и JSON не покрываются. Обход графа в консоли ограничен глубиной 20 уровней и 10 000 связей в каждом направлении.

Microsoft Purview в своей документации тоже фиксирует ограничения: представления базы, используемые как источник активности процесса, записываются как объекты-таблицы, и при сканировании базы представление может появиться отдельным активом с тем же именем. Хранимые процедуры с операторами drop или create в lineage не попадают. Ручное добавление lineage в Purview ограничено: выбор актива идёт по одному за раз, а column-level вручную поддерживается между двумя активами данных и не поддерживается, когда между ними стоит процесс.

Важное уточнение по статусу продуктов. Документация Microsoft сообщает, что классические возможности управления данными Purview выводятся из эксплуатации, новые аккаунты не создаются, а существующие функции остаются в режиме поддержки до 12 ноября 2027 года. Для новых внедрений классический интерфейс не подходит. Документация Google Cloud отмечает, что с 10 апреля 2026 года Dataplex Universal Catalog называется Knowledge Catalog, при этом имена API, клиентских библиотек, CLI и IAM остаются прежними.

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

IBM описывает lineage, provenance и governance как близкие термины, которые слоями накладываются друг на друга. Governance создаёт структуру управления данными: определяет владельцев, бизнес-термины, правила, политики и процессы на протяжении жизненного цикла. Lineage помогает командам governance проверять соответствие этим стандартам, давая видимость того, как данные меняются в пайплайне. Provenance применяется в контексте lineage и указывает на первое появление данных, то есть на источник.

Каталог данных работает с той же информацией иначе. IBM поясняет: инструменты lineage показывают эволюцию данных во времени через метаданные, а каталог использует те же сведения, чтобы построить доступный для поиска инвентарь всех активов данных организации. Вместе они дают понимание значимости разных элементов данных для результата.

Data quality — отдельная дисциплина. IBM связывает lineage с качеством данных так: документация пути позволяет проверять точность и согласованность, а также прослеживать ошибки до первопричины. Lineage даёт аудиторский след на очень детальном уровне, что помогает инженерам данных быстрее находить причины сбоев. При этом сам граф не измеряет качество: он показывает зависимость, а проверка корректности значений остаётся задачей тестов и сверок.

Практический вывод: держите эти слои раздельно в голове и в инструментах. Lineage отвечает на вопрос «откуда пришло число», quality — на вопрос «правильное ли оно», catalog — на вопрос «что у нас есть». Смешение приводит к ожиданию, что граф сам подтвердит корректность отчёта.

Частые вопросы

Что такое data lineage простыми словами?

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

Чем dataset-level lineage отличается от column-level?

Dataset-level показывает связь таблиц и файлов, column-level — связь конкретных полей. Документация Google Cloud описывает column-level как отдельный слой со своими ограничениями. Для поиска источника конкретного числа нужен именно уровень колонок.

Как построить граф полей для отчёта?

Начните с поля в отчёте и двигайтесь вверх по связям до источника, затем проверьте формулы на каждом узле. В учебном примере orders.amount проходит через staging и агрегат до dashboard.gross. Отмечайте узлы со статусом UNKNOWN как требующие ручной проверки.

Что произойдёт с отчётом при изменении поля?

Зависит от того, входит ли поле в формулу нижележащих узлов. В учебном графе замена orders.amount на 100 + 50 меняет gross на 150 и net на 130. Поля рядом, не участвующие в арифметике, значения не сдвигают.

Почему в графе lineage появляются пробелы?

Автосбор покрывает только поддерживаемые источники и преобразования. Документация Knowledge Catalog перечисляет случаи без column-level: load-задания, routines, переименования таблиц, вложенные поля. Пробелы закрывают ручной записью или признают открытыми.