OpenLineage на собеседовании Data Engineer

Почему OpenLineage спрашивают

Как только пайплайнов в компании становится больше десятка, возникает вопрос: откуда взялась эта таблица, кто её сломал и что упадёт, если я поменяю вон ту витрину. Это и есть data lineage — происхождение данных. OpenLineage спрашивают на собесе DE, чтобы понять, знаете ли вы, как lineage собирают автоматически, а не рисуют вручную в Confluence раз в полгода.

Интервьюер обычно проверяет два уровня. Первый — понимаете ли вы, зачем вообще нужен lineage: для отладки сломанных пайплайнов, анализа влияния изменений (impact analysis), расследования инцидентов с качеством данных и требований регуляторов. Второй — знаете ли вы, что OpenLineage — это открытый стандарт, а не очередной вендорский продукт, и чем он отличается от конкретных каталогов вроде DataHub.

Эта статья закрывает базовые вопросы: что такое OpenLineage, как устроена его модель событий, что такое Marquez и через что он собирает lineage.

Что такое OpenLineage

OpenLineage — это открытый стандарт для сбора метаданных о происхождении данных (data lineage). Он описывает единый формат событий, которые инструменты обработки данных отправляют в момент запуска, завершения или падения задачи.

Ключевое слово — «vendor-neutral», не привязанный к вендору. Раньше каждый каталог данных (DataHub, Amundsen, OpenMetadata) собирал lineage по-своему, и переезд с одного на другой означал переписывание всех интеграций. OpenLineage разделяет две стороны: инструменты-источники (Airflow, dbt, Spark) отправляют события в общем формате, а бэкенды-приёмники их принимают и визуализируют. Стандарт развивается под эгидой LF AI & Data Foundation.

Airflow → отправляет → событие OpenLineage → DataHub / Marquez → визуализация графа lineage

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

Модель событий OpenLineage

В основе стандарта — событие (RunEvent) в формате JSON. Пайплайн отправляет такое событие на каждый значимый момент жизни задачи. У события есть несколько обязательных частей:

• Run — конкретный запуск задачи с уникальным runId. Один и тот же job запускается много раз, каждый запуск — отдельный run.
• Job — сама задача, идентифицируется парой namespace + name (например, ETL-джоб process_orders).
• Inputs / outputs — датасеты, которые задача прочитала и записала. Именно из этих связей и строится граф lineage.
• Run state — состояние запуска: START, COMPLETE, FAIL или ABORT. Одна задача за свою жизнь порождает несколько событий с разными состояниями.
• Facets — расширяемые блоки метаданных: схема датасета, статистика по столбцам, версия кода, SQL-запрос. Через facets стандарт наращивают, не ломая обратную совместимость.

{
  "eventType": "COMPLETE",
  "job": {"namespace": "etl", "name": "process_orders"},
  "run": {"runId": "abc-123"},
  "inputs": [{"namespace": "raw", "name": "orders_raw"}],
  "outputs": [{"namespace": "warehouse", "name": "silver_orders"}]
}

Из потока таких событий бэкенд собирает граф: orders_raw → process_orders → silver_orders. Когда silver_orders завтра окажется пустой, по этому графу видно, какой job её наполняет и из какого источника он читал.

Marquez

Marquez — референсная (эталонная) реализация OpenLineage с открытым исходным кодом. Это сервис, который показывает стандарт в действии:

• Принимает события OpenLineage по HTTP.
• Хранит метаданные в PostgreSQL.
• Показывает граф lineage в веб-интерфейсе — какие датасеты во что превращаются и какие джобы их обрабатывают.

Marquez часто берут для пилота или демонстрации: он лёгкий и заводится за пару часов. В продакшене же lineage обычно направляют в более полноценный каталог — DataHub или OpenMetadata, которые тоже умеют принимать события OpenLineage, но вдобавок дают поиск, документацию, владельцев данных и разграничение доступа.

Интеграции

Сила стандарта в том, что для популярных инструментов уже готовы интеграции — писать код руками почти не нужно:

• Airflow. Провайдер OpenLineage отправляет события автоматически: он оборачивает операторы и вытаскивает inputs/outputs из выполненного SQL и датасетов.
• dbt. Пакет dbt-openlineage разбирает манифест и результаты прогона dbt run, превращая модели и их зависимости в события lineage.
• Spark. Агент OpenLineage для Spark перехватывает планы выполнения запросов и извлекает из них источники и приёмники данных.
• Flink. Отдельный плагин отправляет lineage для потоковых джобов.
• Custom. Если готовой интеграции нет, события можно отправлять вручную через клиентский SDK (Python, Java) — просто сформировать RunEvent и отослать на бэкенд.

В России OpenLineage внедряют постепенно: многие команды пока используют собственные, самописные решения для lineage. Поэтому на собесе полезно уметь объяснить не только «как включить провайдер», но и «зачем стандарт вообще нужен» — это отличает кандидата, который понимает проблему, от того, кто заучил название инструмента.

Частые ошибки

• Путать OpenLineage с каталогом данных. OpenLineage — это стандарт и формат событий, а не хранилище. DataHub, Marquez, OpenMetadata — это бэкенды, которые эти события принимают. Кандидат должен разделять протокол и приёмник.
• Считать lineage только «красивой картинкой». Основная ценность — отладка, impact analysis и расследование инцидентов, а не диаграмма для презентации. Граф нужен, чтобы за минуту понять, что сломается при изменении витрины.
• Забывать про состояния запуска. Lineage — это не только «что во что превратилось», но и START/COMPLETE/FAIL. По событиям падений строят мониторинг и SLA пайплайнов.
• Думать, что всё придётся писать вручную. Для Airflow, dbt и Spark интеграции уже готовы. Ручной emit через SDK нужен только для нестандартных инструментов.

Связанные темы

• Data lineage для DE
• Airflow на собесе DE
• dbt на собесе DE
• Spark RDD vs DataFrame для DE
• Подготовка к собесу Data Engineer

FAQ

Чем OpenLineage отличается от DataHub?

OpenLineage — это открытый стандарт и формат событий lineage, а DataHub — каталог данных, то есть готовый продукт с хранилищем, поиском и UI. Они не конкуренты, а дополняют друг друга: DataHub умеет принимать события OpenLineage. Проще говоря, OpenLineage — это «язык», на котором инструменты рассказывают о происхождении данных, а DataHub — один из «слушателей».

Зачем нужен data lineage на практике?

Три главных сценария. Отладка: витрина оказалась пустой — по графу видно, какой job её наполняет и что он читал. Impact analysis: перед изменением таблицы видно, какие отчёты и модели на неё завязаны. Комплаенс и качество данных: для аудита и расследования инцидентов нужно доказать, откуда взялось конкретное значение.

OpenLineage работает в реальном времени или батчами?

События отправляются в момент наступления, то есть по мере выполнения задач: START при запуске, COMPLETE или FAIL при завершении. Для батчевых пайплайнов это выглядит как поток событий на каждый прогон DAG. Стандарт подходит и для стриминга (например, Flink), где джоб долгоживущий, а события отражают его состояние.

Нужно ли писать код, чтобы собирать lineage?

Для популярных инструментов — почти нет. У Airflow есть провайдер, у dbt — пакет, у Spark — агент; их достаточно подключить и настроить адрес бэкенда. Ручная отправка через клиентский SDK нужна только для самописных или экзотических источников, у которых нет готовой интеграции.

Что такое facets в OpenLineage?

Facets — это расширяемые блоки метаданных, которые прикрепляются к событиям, датасетам и джобам. Через них передают схему таблицы, статистику по столбцам, версию кода, текст SQL-запроса или качество данных. Механизм facets позволяет наращивать стандарт новыми полями, не ломая обратную совместимость с существующими интеграциями.

Это официальная информация?

Нет. Статья основана на спецификации OpenLineage и документации Marquez. Конкретный стек и глубина вопросов зависят от компании и уровня позиции.

Тренируйте Data Engineering — откройте тренажёр с 1500+ вопросами для собесов.