В компании уже больше сотни таблиц и dbt-моделей, и аналитики тратят много времени, вручную выясняя, что сломается при изменении конкретной таблицы. Нужно ли внедрять специализированный инструмент для data lineage, и как принять это решение?

Короткий ответ

Единственно верного ответа нет — при умеренном масштабе (десятки-сотни моделей в dbt) часто достаточно lineage, встроенного в сам инструмент трансформации (dbt docs/dbt Cloud), а выделенный каталог данных (DataHub, OpenLineage-based решения) оправдан, когда источники трансформаций разнородны (не только dbt) или организации нужен единый lineage через множество инструментов и команд.

Как это работает подробнее

dbt автоматически строит lineage-граф моделей на основе ref()/source() зависимостей в коде, и это покрывает lineage внутри dbt-проекта почти бесплатно; специализированные каталоги данных дополнительно умеют связывать lineage между разными инструментами (например, от сырых логов через Spark-джобы до dbt-моделей и дальше до BI-инструмента) и добавляют поиск, владение, глоссарий терминов.

Пример кода

architecture.txtКопировать

dbt lineage graph (бесплатно): raw.orders -> stg_orders -> mart.daily_revenue -> (BI tool, вручную отслеживается)
Каталог данных (например, OpenLineage): raw.orders -> Spark job -> stg_orders -> dbt models -> BI dashboard (автоматически, сквозной граф)

Что использовать на практике

• На практике. Перед покупкой/внедрением отдельного инструмента стоит оценить, где на самом деле теряется lineage-видимость — если весь путь трансформации уже внутри dbt, встроенного решения может хватить; если данные проходят через несколько независимых систем (стриминг, несколько ETL-инструментов, разные команды с разными стеками), только выделенный каталог даст сквозную картину.
• Проверка. посчитать, сколько инцидентов за последний квартал были вызваны именно «невидимым» downstream-эффектом за пределами dbt-графа — если таких случаев много, это аргумент в пользу выделенного инструмента; если почти все укладываются внутри dbt-проекта, встроенного lineage достаточно.

Подводные камни

• Частые ошибки. Внедряют тяжёлый корпоративный каталог данных «на вырост» при небольшом и однородном стеке, тратя месяцы на интеграцию ради функциональности, которая уже покрывается dbt docs; либо, наоборот, годами полагаются только на «знания в головах» нескольких senior-аналитиков без какого-либо автоматического lineage, что создаёт риск потери знаний при уходе этих людей.
• Компромисс. Встроенный lineage dbt дёшев и достаточен для однородного стека, но не видит зависимости за пределами dbt (например, от сырых источников до staging через внешний Spark-джоб или от витрины до конкретных BI-чартов). Выделенный каталог даёт более полную картину и дополнительные возможности (поиск владельца, глоссарий), но требует значимых инвестиций в интеграцию и поддержку. Решение зависит от реальной неоднородности стека трансформаций и от того, насколько дорого обходятся компании инциденты «сломали, не предупредив» в текущем масштабе — универсального порога внедрения нет.