Data lineage показывает путь цифры до источника: агенты связывают изменения загрузок с отчётами

Откуда взялась цифра? Название исходной таблицы даёт только начало ответа. До поля отчёта данные могли пройти через отбор строк и расчёт.

Data lineage описывает этот путь. Можно идти назад от показателя к источнику или вперёд от изменённой загрузки к отчётам, которые она питает.

Карта таблиц слишком крупная для проверки отдельного показателя. Связь «продажи питают отчёт» не объясняет, почему выручка изменилась, а количество заказов осталось прежним.

Редакционная схема приёмки, 08.10.2026, на основе модели OpenLineage и документации dbt. Это требования к разработке, не готовая возможность любого инструмента.

Связь поля не равна доказательству суммы. Граф показывает зависимость. Чтобы объяснить изменение значения, нужны входные данные и выполненный расчёт.

В OpenLineage задача обработки и её отдельный запуск описываются раздельно. К задаче можно приложить местоположение и версию кода. А запуск связать с прочитанными и записанными наборами данных.

Если формула живёт внутри отчёта, путь продолжается до неё. Цепочка, которая заканчивается на таблице витрины, оставляет последний расчёт без проверки.

Возьмём учебный отчёт «Оплаченные продажи». В нём сумма собирается из платежей за выбранный период, а статус платежа решает, какие строки попадут в расчёт.

Переименование поля суммы меняет адрес связи. А если в отборе к статусу «оплачен» добавили «ожидает», в отчёт попадут ещё не оплаченные платежи.

Искать только поля, которые участвуют в сложении, недостаточно. Поле статуса не входит в формулу суммы, но от него зависит её результат.

Учебный пример редакции, 08.10.2026. Последствия перечислены как сценарии проверки, не как результаты замера.

У готового инструмента тоже есть граница. Документация dbt отдельно предупреждает: column-level lineage в Catalog отражает поля SELECT, но не их использование в фильтрах и соединениях. Эти зависимости надо проверять дополнительно.

Что поручать агенту? В задаче для ИИ-агента нужен проверяемый результат. Здесь это список связей с местом в коде, а не просьба «объяснить данные».

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

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

Редакционные критерии приёмки, 08.10.2026. Способ подтверждения выбирается под код клиента.

Автоматический разбор не закрывает любую цепочку. В документации dbt названы ошибки разбора сложного SQL и ограничения Python-моделей. Такой участок остаётся неизвестным до отдельной проверки, даже если соседние связи найдены.

Однажды нарисованная карта протухает с первой правкой. Это технический долг в описании: код уже считает иначе, а руководитель смотрит на прежнюю цепочку.

Наше предложение для приёмки: в одной правке должны ехать код загрузки, изменение связей и проверка показателя. Версия карты должна позволять найти код, по которому её построили.

Редакционная схема, 08.10.2026. Разделение описания и выполнения опирается на JobEvent и RunEvent в OpenLineage.

Приёмка изменений защищает от поломки, но не выбирает определение выручки. Владелец показателя утверждает смысл расчёта, инженер проверяет код; ответственность за ошибки агентов разбирается отдельно.

Что из этого мы проверяли на себе? Инженер ведёт машину агентов на vibecoding.ru; открытая карта проекта показывает устройство работы и историю изменений. Это наш собственный продукт.

Описание рядом с кодом помогает агенту продолжать работу с проверяемой опорой. А правила для ИИ-агентов полезны, когда изменение поля запускает проверку всех мест, где его передают.

Записи журналов машины от 31.07 и 02.09.2026, перечитаны 08.10.2026. Публичная поверхность работы: /open.

Оба урока применимы к приёмке lineage. Передача поля требует проверки пути, а ошибка загрузки требует отдельного состояния вместо подставленного значения.

Эти истории не измеряют качество внедрения lineage у заказчика. На учебном отчёте полезность схемы проверяется иначе: намеренная правка фильтра должна появиться в списке влияния и в результате пересчёта.

С чего начинать закупку? С показателя, который уже трудно объяснить после доработки. Попросите подрядчика пройти его путь до источника и показать, как цепочка обновится при следующем изменении.

Предлагаемый редакцией пилот, 08.10.2026. Срок и окупаемость не измерены.

У пилота должно быть условие «готово». От изменённого участка загрузки можно дойти до поля отчёта, каждую связь подтвердить, а расхождение воспроизвести на контрольном входе. Для «Оплаченных продаж» платёж со статусом «ожидает» должен остаться за пределами суммы.

Если вести такую работу внутри компании некому, агентная разработка по подписке стоит 250 000 ₽ в месяц за «Один проект» на 8 октября 2026. Инженер ведёт машину агентов, готовые изменения приходят в репозиторий клиента; одна задача в работе, пауза в любой месяц.

Начать обсуждение можно с разбора вашей задачи. Пришлите название спорного показателя и описание последней правки загрузки: они зададут границу первого этапа.

1. Путь показателя продолжается до формулы в отчёте. Включите её в границу работы.

2. Фильтры и соединения тоже меняют итог. Проверяйте их вместе с полями суммы.

3. Связь без доказательства остаётся предположением. Требуйте место в коде или подтверждение запуска.

4. Карта и код должны иметь связанную версию. Принимайте их вместе с контрольным пересчётом.

5. Начните с одного спорного показателя. Оставьте проверку для следующих изменений.