Бизнес просит изменить логику расчёта поля status в промежуточной таблице staging.orders. Как с помощью data lineage оценить, какие отчёты и дашборды это может затронуть, прежде чем вносить изменение?

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

Нужно построить (или посмотреть в уже существующем каталоге lineage, например dbt docs) граф зависимостей «вниз по течению» (downstream) от staging.orders.status — все модели, витрины и дашборды, которые читают это поле напрямую или через цепочку трансформаций.

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

Lineage-граф строится либо автоматически (инструменты вроде dbt парсят SQL-зависимости между моделями), либо вручную через поиск по кодовой базе трансформаций и запросам дашбордов на предмет использования staging.orders.status.

Пример кода

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

staging.orders.status
  -> mart.daily_orders_status (SQL model использует status в WHERE)
  -> dashboard "Operations Overview" (фильтр по status='completed')
  -> dashboard "Finance Revenue" (считает revenue только для status='completed')

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

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

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

• Частые ошибки. Меняют логику в staging-слое, протестировав только «ближайшую» витрину, которую сам аналитик использует, и не проверив более дальние отчёты, которые читают ту же таблицу через несколько слоёв трансформаций — в результате они ломаются без предупреждения через несколько дней.