Хороший, плохой, злой: база данных, data catalog и AI

Одним из направлений деятельности компании Lasmart всегда было внедрение и развитие DWH. В какой-то момент мы задумались о том, чтобы оптимизировать отдельные аспекты нашей работы. И первым инструментом сделали генерацию бизнес-описания на основе AI. Решение получило название Datadesc (data + description). Об этом опыте и пойдет речь в этой статье.

Давайте честно: если вы еще раз услышите фразу про «данные — это новая нефть», у вас скорее всего глаз задергается. «Для компании нет развития, если она не пользуется данными», это и так понятно. Все кивают, когда говорят про data governance. Мало кто реально это делает.

Любой data governance начинается с data catalog. Не знаем, почему так повелось. И если данные — это новая нефть, то data catalog — карта месторождений. Без него вы будете копать там, где копать совсем не нужно. И вот многие решили data catalog внедрять. Даже на секунду, не задумываясь, что им он совсем не нужен: у них одна 1С и с десяток отчетных витрин. А те, которым действительно он нужен, внедряют его для галочки. То есть, поставили, метаданные загрузили и на этом все. Есть ли хоть какая-то польза от «голых» метаданных? Просто список таблиц и столбцов? Пользы как с козла молока.

Важно описание этих метаданных, их смысл и что они реально означают. Вот тогда и будет польза, вот тогда и начнете качать нефть на полную.

Сперва, как раньше было? Раньше мы документацию к базам данных или к DWH вели в Excel-ках. Называли то карта отображения, то source-to-target (s2c). Выкладывали файлики на шару (SharePoint) и никаких бед не знали. Потом Confluence или Google sheets, все примерно то же самое только с более навороченным функционалом для совместной работы. Некоторые вообще в word-е все описывали (прости, господи) и на сетевой диск. Вот так выглядела (и выглядит у многих сейчас) работа по документированию баз данных. Но это все работает, когда у вас таблиц не так много, или источников, или сотрудников. Да и задач не так много. Все эти файлики с документацией писались, конечно же, вручную. И, следовательно, времени съедали весьма много. Сколько мы потратили на s2c времени даже представить страшно. А времени сейчас ни у кого нет. Нужно как-то автоматизировать. И придумали как.

Появляются data catalog. Представьте себе библиотечный каталог, в котором вы с легкостью можете найти нужную вам книгу. Тут тебе и совместная работа, и автоматический сбор метаданных, и указание владельцев данных, и бизнес-глоссарий, и даже качество данных! Ну просто песня! Для IT-шника (и для меня в том числе!) все эти штучки-фьючки вызывали и вызывают восторг.

Но забыли о том, что нужен смысл данных. Метаданные мы собрали, но ведь нужно их описать. Как мы описывали в тех самых Excel-ях. Нужно и муторно сидеть и описывать. А если у вас несколько сотен таблиц или даже тысяч?

Недавно общались с CDO, у которого около 3 млн. объектов (таблицы + столбцы). И что в этом случае делать? Народ, естественно, боится такого объема ручной работы и даже не приступает к наполнению бизнес-описанием каталогов. И стоят внедренные и никем неиспользуемые каталоги пустые, с надеждой ожидая своего часа.

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

AI идеально подходит для рутины! Теперь осталось разобраться, как прикрутить LLM и получить качественный результат.

Спойлер: 100% корректный результат вы не получите! Всегда LLM нужно валидировать вручную.

Если вы думали, что LLM-ке можно просто отдать список таблиц и столбцов и она даст описание этой меты, то вы сильно ошибаетесь.

Самая главная проблема — недостаточность контекста. Чем больше контекста вы даете LLM, тем качественнее получаете результат. А просто метаданных порой бывает совсем недостаточно.

К примеру, название столбца CLIENT_NAME еще можно как-то угадать. И то, бывает пишут NAME, а хранится там ФИО. Но может встречаться что-то из разряда n24id. Поэтому просто DDL-скрипта недостаточно. Приходится смотреть глубже: типы данных, связи, ограничения, а главное — реальные значения в таблицах, n-ое количество значений из столбца.

И все равно этого может недостаточно. Представьте: таблица n24, столбец n24id, внутри столбца целочисленные значения, — здесь никакой магии не произойдет. ИИ не сможет дать к этому бизнес-описание. Получается все зависит от качества метаданных и самих данных. На наших проектах мы получали примерно 95% корректно описанных объектов (сверено с самим заказчиком).

Дополнительный контекст дает бизнес-глоссарий. Каждая компания говорит на своем языке, использует свои термины. И желательно, чтобы эти термины использовались в бизнес-описании. Также дополнительным контекстом будет описание деятельности самой компании и, еще лучше, описание бизнес-процессов и основных подразделений. Есть идеи (мы правда пока этого не реализовали) скармливать wiki, если оно есть и в актуальном состоянии, в качестве дополнительного контекста.

С таблицами более-менее все понятно. Но в наших базах и dwh есть еще объекты, которым хотелось бы также добавить бизнес-смысла.

Вот есть у нас SQL-процедура, скрипт или dbt-модель. Несколько сотен, а то и тысяч строк кода. Комментарии к SQL оставляют редко (либо мы просто с такими скриптами работали). И разобраться, что там происходит совершенно непонятно. Можно конечно SQL отдать ChatGPT, но: а) по головке за такое ИБ точно не погладят, б) с высокой вероятностью не будет хватать контекста. Опять этот контекст…

Не будет хватать описания таблиц и столбцов и поэтому объяснение SQL у вас получится весьма и весьма кривое. Но имея такое описание (как его сделать автоматически мы проговорили ранее) у вас значительно повысится качество описания SQL.

Мы это проверили на своих проектах. В итоге, если давать в качестве контекста (через RAG) описанные ранее таблицы, то получаем весьма понятное бизнес-описание. Прямо по шагам расписываются все SQL-преобразования.

Особенно полезно, когда нужно legacy-скрипты разобрать или вообще мигрировать старое хранилище с сохранением логики.

Пока мы реализовали в своем решении это на хранимых процедурах. В ближайших планах, конечно же, dbt или загрузка SQL-скриптов вручную.

И наверное, не стоит говорить, что не только таблицы описываются, но и представления, и даже функции. Концепция их описания совершенно такая же, как у таблиц и SQL-процедур, поэтому детально останавливаться на этом не будем.

Наверное, это тема для отдельной статьи, но все же вкратце ее здесь упомянем. Бизнес-описание таблиц и SQL это конечно хорошо, но часто бывает недостаточно. Вот захотели мы дополнительно Data lineage. Причем и тут мы хотим, чтобы задача решалась максимально автоматически. Стали смотреть на рынок и поняли, что решения есть, но как это обычно бывает с open-source — сырые и мало какие сценарии покрывают.

За основу взяли data lineage из OpenMetadata и доработали под себя. Причем там пришлось достаточно много дорабатывать.

Сам же принцип автоматизации data lineage, если кратко, следующий: вы сперва парсите SQL-процедуры и view (или другой доступный SQL), а затем берете SQL из кеша запросов. Второй шаг на тот случай, когда ваши ETL выполняются в каком-нибудь стороннем инструменте (не все же пользуются dbt или хранимыми процедурами). Правда здесь огромное количество ограничений, о которых постараемся подробно расписать в следующих статьях. Самое серьезное ограничение — это когда ETL на своей стороне делает все преобразования, а к базе обращается только для чтения или записи данных. Тем самым, вы мало что увидите в кэше запросов.

Вот поэтому мы очень любим dbt. И да, мы знаем, что там тоже можно сразу делать lineage, но он далеко не автоматический.

Все автоматически сгенерированное отправляется прямиком в data catalog. На текущий момент умеем с OpenMetadata и Datahub. Таким образом у нескольких наших заказчиков наполнили до этого пустующие каталоги, которые они не использовали.

Не у всех есть data catalog, и не всем он нужен. Поэтому, чтобы была ценность от документации на тех проектах, где каталога нет, мы реализовали собственный несложный GUI для взаимодействия с метаданными и их бизнес-описанием. Я бы назвал это мини-каталогом.

Также мы научили Datadesc обновлять документацию: автоматически определять новые или измененные объекты (в том числе и SQL-процедуры) и доописывать их. Чуть ниже расскажем, как это ложится на процесс актуализации документации с учетом того, что документация должна валидироваться человеком.

Сегодня многие куда угодно хотят прикручивать своих ассистентов. Вот и мы не остались в стороне. Раз у нас есть бизнес-описание, то хорошо бы было максимально демократизировать поиск данных. Заходит пользователь в ассистент, спрашивает своими словами «Где лежат данные по выручке?» и получает список таблиц, столбцов и т. д. Даже если слово «выручка» не фигурирует в бизнес-описании, а используется его какой-нибудь синоним («доход»).

Весьма удобно, и мы на себе убедились насколько быстро ускоряется поиск.

Конечно, в нашем получившемся решении есть ограничения, о которых стоит поговорить подробнее.

Уже упоминали, но еще раз сказать лишним не будет. AI нужно проверять. Если вы отдаете абсолютно все на откуп AI, ждите последствий.

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

После согласования бизнес-описание к условной таблице фиксируется и более не переописывается.

Многое зависит от качества метаданных. А точнее, от их «понятности».

Если вы когда-нибудь залезали в базу какой-нибудь АБС (автоматизированная банковская система) или 1С, то знаете, как там совсем непонятно называются таблицы. Как говорится, без бутылки документации от вендора не разберешься. Как в нашем примере выше, всякие таблицы n24, abc123, xyz — там всего этого навалом. И если посмотреть данные самой таблицы, увидите множество ссылок, хэшей и целочисленных значений, которые ни о чем вам не говорят. Поэтому какую-то часть, конечно, AI опишет, но далеко не те 95%, которые мы получали на проектах наших заказчиков.

99% компаний не захотят отправлять свои метаданные в облако, то есть пользоваться какими-либо облачными, даже российскими LLM. Поэтому решение должно быть локальное.

Да и ладно, подумаете вы. Возьму вон Ollama да и прикручу к ней open-source модель. Потом через python буду метаданные передавать. Наверное, так тоже можно, но будет ли это работать на реальных примерах.

У нас вышла довольно непростая архитектура с несколькими LLM, отвечающими за различные задачи, AI-агентом по вызову других моделей, векторной базой для хранения эмеддингов и базой для, собственно, хранения бизнес-описаний.

И все это крутится не на дешевом железе. Минимальное требование к оперативной памяти к примеру — 32 ГБ, если использовать небольшие LLM. И конечно, очень желательно, чтобы была графическая карта.

Подводим итоги небольшим хвастовством.

Мы на своих проектах и у наших клиентов видим следующие метрики:

В других статьях подробнее опишем техническую составляющую: архитектуру, инструменты и с какими вызовами столкнулись.

Подытоживая, видим тренд увеличения недоверия к AI. И не зря. Галлюцинации, низкое качество из-за недостатка контекста, а главное — непонимание у людей, где и как его применять. Везде пытаются его впихнуть. Наше скромное мнение, надо отдавать AI рутину. Те задачи, с которыми вы точно справитесь сами, но потратите много времени. Вот как с бизнес-описанием и документацией.

Но когда вы хотите, чтобы AI за вас все DWH разработал … Ну что ж. Не завидуем вам.