LLM строит data lineage из SQL за секунды: как заменить недели ручного разбора

Зачем вообще нужен data lineage?

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

• Какие витрины и отчёты зависят от конкретного источника?
• Какие преобразования нужно проверить или перенастроить?
• Откуда в новой системе взять корректные данные?

Традиционный подход, вручную поддерживать документацию или проводить реверс-инжиниринг SQL-кода хранилища. Оба пути дороги и ненадёжны: спецификации устаревают, а SQL-скрипты в промышленных хранилищах содержат вложенные подзапросы, CTE (общие табличные выражения, когда сложный запрос разбивают на именованные блоки для удобства), оконные функции и UNION ALL. Разобрать такой код вручную, задача на дни.

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

Что понадобится

• Доступ к API языковой модели, заточенной на код. В описанном подходе использовали GigaChat от Сбера, доступный в России без VPN.
• Python 3.8+ и библиотеки: langchain_gigachat (доступ к модели), langchain (построение цепочек вызовов).
• Набор SQL-скриптов, которые нужно разобрать. Подойдут реальные скрипты наполнения таблиц из вашего хранилища.
• Время: настройка окружения и первый прогон занимают от часа до двух, дальше каждый скрипт обрабатывается за секунды.

Пошаговая инструкция

1. Установите зависимости. В терминале выполните:

pip install langchain langchain-gigachat

1. Получите ключ API GigaChat. Зарегистрируйтесь в программе для разработчиков Сбера, создайте проект и скопируйте токен авторизации.

2. Напишите системный промпт (system prompt, инструкция, которая задаёт модели роль и формат ответа). Промпт должен чётко описать задачу: определить целевую таблицу (target) и таблицы-источники (sources) из SQL-запроса, вернуть результат в JSON, использовать полные имена вида схема.таблица, игнорировать алиасы и временные объекты, корректно обрабатывать UNION ALL и вложенные подзапросы.

Ты — эксперт по SQL. Проанализируй запрос и верни JSON:
{"target": "схема.таблица", "sources": ["схема.таблица1", "схема.таблица2"]}
Правила:

- Используй полные имена (схема.таблица), без алиасов.
- Игнорируй временные объекты и CTE.
- Корректно обрабатывай UNION ALL и вложенные подзапросы.
- Не добавляй пояснений, только JSON.

1. Создайте класс-обёртку. Используйте LangChain Expression Language (LCEL), чтобы выстроить цепочку: форматирование промпта, передача в модель, парсинг результата в структурированный JSON.

from langchain_gigachat import GigaChat
from langchain.prompts import ChatPromptTemplate
from langchain.output_parsers import JsonOutputParser

llm = GigaChat(credentials="ВАШ_ТОКЕН", model="GigaChat-Pro")

prompt = ChatPromptTemplate.from_messages([
    ("system", "СИСТЕМНЫЙ ПРОМПТ ИЗ ШАГА 3"),
    ("human", "{sql_query}")
])

chain = prompt | llm | JsonOutputParser()

1. Подайте SQL-запрос на вход цепочки.

result = chain.invoke({"sql_query": "INSERT INTO схема.целевая SELECT ... FROM схема.источник ..."})
print(result)

1. Проверьте результат вручную на нескольких скриптах. Сравните ответ модели с реальной структурой зависимостей. Именно ручная сверка первых результатов покажет, насколько точен промпт и нужна ли доработка.

2. Масштабируйте. Прогоните все скрипты хранилища пакетом и соберите карту data lineage целиком.

{
  "target": "s_grnplm_vd_t_bvd_db_dmslcl.d_agr_cred_agr_collat_core",
  "sources": ["s_grnplm_vd_t_bvd_db_dmslcl.d_agr_cred_agr_collat"]
}

Что делать с результатами, по ролям

Аналитику данных и инженеру хранилища. Собранный data lineage покажет, какие отчёты и витрины «сломаются» при замене источника. Перед миграцией в облако прогоните все скрипты и получите реестр зависимостей за часы, а не за недели.

Автору Дзена и контент-маркетологу. Если пишете про данные, аналитику или импортозамещение ИТ, этот кейс даёт конкретный пример того, как LLM решает рутинную задачу в российских реалиях. GigaChat работает без VPN и подписок на зарубежные сервисы.

Руководителю или предпринимателю. При замене устаревших систем (legacy) главный риск, потерять связность отчётности. Автоматический data lineage снижает этот риск и сокращает сроки проекта.

Карта происхождения данных, которую раньше рисовали неделями, теперь собирается за один прогон по SQL-скриптам, и для российских компаний, меняющих инфраструктуру, это не теоретическая возможность, а рабочий метод с конкретным стеком: Python, LangChain, GigaChat.