Всех приветствую! Меня зовут Павел, работаю в компании Lasmart. Одно из направлений деятельности всегда было внедрение и развитие DWH. В какой-то момент задумались о том, чтобы оптимизировать прежде всего свою работу в некоторых аспектах. И первым инструментом сделали генерацию бизнес-описания на основе AI. Назвали Datadesc (data + description). Об этом опыте и пойдет речь в этой статье.
Данные – новая нефть и бла-бла-бла
Давайте честно: если вы еще раз услышите фразу про «данные — это новая нефть», у вас скорее всего глаз задергается. «Для компании нет развития, если она не пользуется данными», это и так понятно. Все кивают, когда говорят про Data governance. Мало кто реально это делает.
Любой data governance начинается с data catalog. Не знаю, почему так повелось. И если данные – это новая нефть, то data catalog – карта месторождений. Без него вы будете копать там, где копать совсем не нужно. И вот многие решили data catalog внедрять. Даже на секунду, не задумываясь, что им он совсем не нужен: у них одна 1С и с десяток отчетных витрин. А те, которым действительно он нужен, внедряют его для галочки. То есть поставили, метаданные загрузили и на этом все. Есть ли хоть какая-то польза от «голых» метаданных? Просто список таблиц и столбцов? Пользы как с козла молока.
Важно описание этих метаданных, их смысл и что они реально означают. Вот тогда и будет польза, вот тогда и начнете качать нефть на полную.
Data catalog или не Data catalog?
Сперва совсем кратко, что такое каталог, с чем его едят и нужно ли его вообще употреблять?
Сперва, как раньше было? Раньше мы документацию к базам данных или к DWH вели в Excel-ках. Называли то карта отображения, то source-to-target (s2c). Выкладывали файлики на шару (SharePoint) и никаких бед не знали. Потом Confluence или Google sheets, все примерно то же самое только с более навороченным функционалом для совместной работы. Некоторые вообще в word-е все описывали (прости, господи) и на сетевой диск. Вот так выглядела (и выглядит у многих сейчас) работа по документированию баз данных. Но это все работает, когда у вас таблиц не так много, или источников, или сотрудников. Да и задач не так много. Все эти файлики с документацией писались, конечно же, вручную. И, следовательно, времени съедали весьма много. Сколько я потратил на s2c времени даже представить страшно. А времени сейчас ни у кого нет. Нужно как-то автоматизировать. И придумали как.
Появляются data catalog. Представьте себе библиотечный каталог, в котором вы с легкостью можете найти нужную вам книгу. Тут тебе и совместная работа, и автоматический сбор метаданных, и указание владельцев данных, и бизнес-глоссарий, и даже качество данных! Ну просто песня! Для IT-шника (и для меня в том числе!) все эти штучки-фьючки вызывали и вызывают восторг.
Но забыли о том, что нужен смысл данных. Метаданные мы собрали, но ведь нужно их описать. Как мы описывали в тех самых Excel-ях. Нужно и муторно сидеть и описывать. А если у вас несколько сотен таблиц или даже тысяч?
Недавно общался с CDO, у которого около 3 млн. объектов (таблицы + столбцы). И что в этом случае делать? Народ, естественно, боится такого объема ручной работы и даже не приступает к наполнению бизнес-описанием каталогов. И стоят внедренные и никем неиспользуемые каталоги пустые, с надеждой ожидая своего часа.
Автоматическое наполнение и AI
Не буду создавать интригу. Мы решили использовать AI для этой задачи. Сделали свое коробочное решение и начали сперва применять на проектах заказчиков. В первую очередь, чтобы сократить собственные трудозатраты.
AI идеально подходит для рутины? Теперь осталось разобраться, как прикрутить LLM и получить качественный результат.
Спойлер: 100% корректный результат вы не получите! Всегда LLM нужно валидировать вручную.
Если вы думали, что LLM-ке можно просто отдать список таблиц и столбцов и она даст описание этой меты, то вы сильно ошибаетесь.
Самая главная проблема – недостаточность контекста. Чем больше контекста вы даете LLM, тем качественнее получаете результат. А просто метаданных порой бывает совсем недостаточно.
К примеру, название столбца CLIENT_NAME еще можно как-то угадать. И то, бывает пишут NAME, а хранится там ФИО. Но может встречаться что-то из разряда n24id. Поэтому просто DDL-скрипта недостаточно. Приходится смотреть глубже: типы данных, связи, ограничения, а главное — реальные значения в таблицах, n-ое количество значений из столбца.
И все равно этого может недостаточно. Представьте: таблица n24, столбец n24id, внутри столбца целочисленные значения, - здесь никакой магии не произойдет. ИИ не сможет дать к этому бизнес-описание. Получается все зависит от качества метаданных и самих данных. На наших проектах мы получали примерно 95% корректно описанных объектов (сверено с самим заказчиком).
Дополнительный контекст дает бизнес-глоссарий. Каждая компания говорит на своем языке, использует свои термины. И желательно, чтобы эти термины использовались в бизнес-описании. Также дополнительным контекстом будет описание деятельности самой компании и, еще лучше, описание бизнес-процессов и основных подразделений. Есть идеи (мы правда пока этого не реализовали) скармливать wiki, если оно есть и в актуальном состоянии, в качестве дополнительного контекста.
Описание SQL
С таблицами более-менее все понятно. Но в наших базах и dwh есть еще объекты, которым хотелось бы также добавить бизнес-смысла.
Вот есть у нас SQL-процедура, скрипт или dbt-модель. Несколько сотен, а то и тысяч строк кода. Комментарии к SQL оставляют редко (либо я просто с такими скриптами работал). И разобраться, что там происходит совершенно непонятно. Можно конечно SQL отдать ChatGPT, но: а) по головке за такое ИБ точно по головке не погладят, б) с высокой вероятностью не будет хватать контекста. Опять этот контекст…
Не будет хватать описания таблиц и столбцов и поэтому объяснение SQL у вас получится весьма и весьма кривое. Но имея такое описание (как его сделать автоматически мы проговорили ранее) у вас значительно повысится качество описания SQL.
Мы это проверили на своих проектах. В итоге, если давать в качестве контекста (через RAG) описанные ранее таблицы, то получаем весьма понятное бизнес-описание. Прямо по шагам расписываются все SQL-преобразования.
Особенно полезно, когда нужно legacy-скрипты разобрать или вообще мигрировать старое хранилище с сохранением логики.
Пока мы реализовали в своем решении это на хранимых процедурах. В ближайших планах, конечно же, dbt или загрузка SQL-скриптов вручную.
И наверное, не стоит говорить, что не только таблицы описываются, но и представления, и даже функции. Концепция их описания совершенно такая же, как у таблиц и SQL-процедур, поэтому детально останавливаться на этом не буду.
Автоматический data lineage
Наверное, это тема для отдельной статьи, но все же вкратце ее здесь упомяну. Бизнес-описание таблиц и SQL это конечно хорошо, но часто бывает недостаточно. Вот захотели мы дополнительно Data lineage. Причем и тут мы хотим, чтобы задача решалась максимально автоматически. Стали смотреть на рынок и поняли, что решения есть, но как это обычно бывает с open-source – сырые и мало какие сценарии покрывают.
За основу взяли data lineage из OpenMetadata и доработали под себя. Причем там пришлось достаточно много дорабатывать.
Сам же принцип автоматизации data lineage, если кратко, следующий: вы сперва парсите SQL-процедуры и view (или другой доступный SQL), а затем берете SQL из кеша запросов. Второй шаг на тот случай, когда ваши ETL выполняются в каком-нибудь стороннем инструменте (не все же пользуются dbt или хранимыми процедурами). Правда здесь огромное количество ограничений, о которых я постараюсь подробно расписать в следующих статьях. Самое серьезное ограничение – это когда ETL на своей стороне делает все преобразования, а к базе обращается только для чтения или записи данных. Тем самым, вы мало что увидите в кэше запросов.
Вот поэтому я очень люблю dbt 😊. И да, я знаю, что там тоже можно сразу делать lineage, но он далеко не автоматический.
Интеграция с data catalog и обновления
Все автоматически сгенерированное отправляется прямиком в data catalog. На текущий момент умеем с OpenMetadata и Datahub. Таким образом у нескольких наших заказчиков наполнили до этого пустующие каталоги, которые они не использовали.
Не у всех есть data catalog, и не всем он нужен. Поэтому, чтобы была ценность от документации на тех проектах, где каталога нет, мы реализовали собственный несложный GUI для взаимодействия с метаданными и их бизнес-описанием. Я бы назвал это мини-каталогом.
Также мы научили Datadesc обновлять документацию: автоматически определять новые или измененные объекты (в том числе и SQL-процедуры) и доописывать их. Чуть ниже расскажу, как это ложится на процесс актуализации документации с учетом того, что документация должна валидироваться человеком.
AI-ассистент
Сегодня многие куда угодно хотят прикручивать своих ассистентов. Вот и мы не остались в стороне. Раз у нас есть бизнес-описание, то хорошо бы было максимально демократизировать поиск данных. Заходит пользователь в ассистент, спрашивает своими словами «Где лежат данные по выручке?» и получает список таблиц, столбцов и т.д. Даже если слово «выручка» не фигурирует в бизнес-описании, а используется его какой-нибудь синоним («доход»).
Весьма удобно, и мы на себе убедились насколько быстро ускоряется поиск.
Ограничения
Конечно, в нашем получившемся решении есть ограничения, о которых стоит поговорить подробнее.
Нужно проверять
Уже упоминал, но еще раз сказать лишним не будет. AI нужно проверять. Если вы отдаете абсолютно все на откуп AI, ждите последствий.
Как я говорил ранее, наше решение умеет автоматически актуализировать бизнес-описания. И поэтому здесь мы осознали, что обязательно должен быть процесс, в рамках которого человек валидирует получившийся результат и корректирует его, если потребуется. Процесс простой и выглядит следующим образом:
· AI сгенерировал бизнес-описание для таблицы
· Ответственному приходит уведомление, что появились новые объекты, требующие валидации
· Ответственный валидирует бизнес-описание, корректирует его при необходимости и согласовывает
После согласования бизнес-описание к условной таблице фиксируется и более не переописывается.
Качество метаданных
Многое зависит от качества метаданных. А точнее, от их «понятности».
Если вы когда-нибудь залезали в базу какой-нибудь АБС (автоматизированная банковская система) или 1С, то знаете, как там совсем непонятно называются таблицы. Как говорится, без бутылки документации от вендора не разберешься. Как в моем примере выше, всякие таблицы n24, abc123, xyz – там всего этого навалом. И если посмотреть данные самой таблицы, увидите множество ссылок, хэшей и целочисленных значений, которые ни о чем вам не говорят. Поэтому какую-то часть, конечно, AI опишет, но далеко не те 95%, которые мы получали на проектах наших заказчиков.
Системные требования и архитектура
99% компаний не захотят отправлять свои метаданные в облако, то есть пользоваться какими-либо облачными, даже российскими LLM. Поэтому решение должно быть локальное.
Да и ладно, подумаете вы. Возьму вон Ollama да и прикручу к ней open-source модель. Потом через python буду метаданные передавать. Наверное, так тоже можно, но будет ли это работать на реальных примерах.
У нас вышла довольно непростая архитектура с несколькими LLM, отвечающими за различные задачи, AI-агентом по вызову других моделей, векторной базой для хранения эмеддингов и базой для, собственно, хранения бизнес-описаний.
И все это крутится не на дешевом железе. Минимальное требование к оперативной памяти к примеру – 32 ГБ, если использовать небольшие LLM. И конечно, очень желательно, чтобы была графическая карта.
Что в результате?
Подводим итоги небольшим хвастовством.
Мы на своих проектах и у наших клиентов видим следующие метрики:
сократили свои трудозатраты по наполнению каталога на ~80%
точность бизнес-описаний – 90-95% (но все зависит от метаданных!)
кратно быстрее ищем данные – теперь примерно за 1-5 минут.
В других статьях подробнее опишу техническую составляющую: архитектуру, инструменты и с какими вызовами столкнулись.
Подытоживая, вижу тренд увеличения недоверия к AI. И не зря. Галлюцинации, низкое качество из-за недостатка контекста, а главное – непонимание у людей, где и как его применять. Везде пытаются его впихнуть. Мое скромное мнение, надо отдавать AI рутину. Те задачи, с которыми вы точно справитесь сами, но потратите много времени. Вот как с бизнес-описанием и документацией.
Но когда вы хотите, чтобы AI за вас все DWH разработал … Ну что ж. Не завидую вам.
