Кажется, о внедрении каталога данных не написал только ленивый. Каждая крупная компания так или иначе к этому (каталогу) приходит. Пробует разные решения и методологию. У кого-то успешно только на презентации для совета директоров (чаще всего), у кого-то на деле.
Здесь же я хочу рассказать не о том, как заполнять каталог или какой выбрать. А о том, что нужно сделать, прежде чем переходить к покупке/запуску этого каталога. Для тех, кто уже имеет такого зверя в своем зоопарке, но с ним что-то не так, думаю, тоже будет полезно.
Если вы один из счастливчиков, у кого каталог действительно взлетел, можете дальше не читать. Однако что-то мне подсказывает, что таких будет не много.
Осторожно, статья-детектор.
С чего обычно все начинается или как делать не надо
Сначала с помпой запускается сам каталог
Затем всех палкой пытаются туда загнать
Следом начинают рассказывать, как его заполнять
Назначают кому-от роль data steward, который должен вносить описания
Все эти процессы ужасно хромают
Никто не хочет к нему подключаться (задавая неудобные вопросы о том, зачем вообще это нужно, небезосновательно сомневаясь в ценности)
Подключившись, никто не хочет добавлять в каталог описания
На всяких презах и видео людям пытаются показать, как это круто, удобно, но показывают синтетические примеры, потому что реальных нет
Через время в каталоге таки появляются описания, и даже много, но они не имеют никакой ценности. Они поверхностные и бессмысленные, из разряда
customer_id = ИД клиентаи у самой таблицы customers описание очень лаконичное, даже не поспоришь,таблица клиентов.Часики тикают, а ощутимого результата все нет.
Чтобы хоть как-то всё сдвинулось с мертвой точки, следующим шагом начинается попытка прикрутить к каталогу LLM. Раз уж никто не хочет заполнять каталог, так пусть хоть алгоритм заполнит. Быть может так получится выжать ценность. А есть ли она там вообще?
Почему же все так
А все дело в современном подходе организационной логики с размытыми зонами ответственности. Они настолько разделили зоны ответственности в погоне за прибылью, вводя все новые и новые роли/должности, что сами стали заложниками этой ситуации. Сначала разделили деятельность рук и одна рука перестала понимать, что делает другая. Но они пошли дальше, разделяя деятельность пальцев на одной руке. Если раньше за управление двумя руками отвечал один человек, то теперь за каждый палец отвечает свой специалист. Непонятно написал?
Приведу аналогию, которая покажет всю абсурдность ситуации
Представим, что есть водители, которые не соблюдают ПДД и им это официально разрешено.
Город так живет годами неизвестно с каких времен и всем это давно кажется нормой, хотя это бесит каждого. В городе постоянно пробки, аварии, но они не из-за узких улиц или плохого покрытия, а просто потому что на каждом перекрестке водители спорят между собой у кого из них преимущество. Хотя есть и светофоры, и знаки, и все водители даже когда-то получили удостоверения, но давно забыли, что там было на экзамене. Да оно и не нужно (это удостоверение), потому что все так ездят (почему-то вспомнился фильм Город Эмбер, как задумывали отцы-основатели и к чему все в результате пришло).
Когда-то департамент перевозок (бизнес) сказал, что ПДД можно пренебречь, если они мешают вовремя доставлять груз. И звучал этот лозунг так: "Работающий продукт важнее исчерпывающей документации" (Agile Manifesto). Поэтому даже маршрут можно рисовать в общих чертах, указывая на карте примерное направление — куда-то туда. Ну экспедитор же сказал водителю куда ехать и водитель знает этот адрес. Всё, логистика поперла. Завтра уволится экспедитор, а через время водитель. Когда возьмут нового водителя, ему придется долго узнавать куда же нужно возить груз.
ГАИ лишь занимается тем, что смотрит за асфальтным покрытием и чтобы светофоры были как можно новее, ну, как минимум не хуже тех, о которых пишут на хабрах. В идеале, чтобы как в самом лучшем городе. Чтобы грузовики не устаревали, а то легаси и вот это все. Нафиг это старьё, скорее надо пересесть на новый грузовик, о котором пишут в блестящем журнале. ГАИ могут оштрафовать, если кто-то поедет по грунтовке (воспользуется старой технологией), а не по асфальту, но за нарушение ПДД они не штрафуют. И самое забавное, что самих ГАИшников такой вариант тоже устраивает. Они давно забыли, что такое стоять на морозе с полосатой палочкой. Теперь они сидят в теплых офисах и смотрят видео камеры, чтобы никто не ездил по грунтовкам. Вернее уже даже не смотрят, а за них смотрит автоматика (пайплайны), но почему-то контролирует только грунтовки. У многих водителей, конечно, осталось в памяти одно правило, которое они все же стараются соблюдать — не давить пешеходов (делать code review).
Градоначальник от этого устал и пытается найти решение. Он где-то в интернетах читал, что если бы водители ездили по правилам, то город в целом функционировал бы лучше и казна получала бы больше денег. Кажется это называется data-driven или нечто подобное.
В один прекрасный день на пороге появляются лекари, которые говорят градоначальнику, что мы знаем, как это исправить, сейчас это последний писк моды. Но, надо понимать, что это стоит недешево.
Основная мысль в том, что нужно открыть специальное подразделение (data governance), которое будет подсказывать водителям, как надо соблюдать ПДД.
Рядом с каждым водителем должен находиться специальный консультант (data steward), который будет подсказывать водителю, где он нарушил ПДД. Водитель должен слушать рекомендации консультанта, но не обязан. Штрафовать нельзя. Можно только слегка пожурить. Ведь водителю платит бизнес (департамент перевозок, которому, в свою очередь, деньги дает градоначальник), а бизнесу надо вовремя доставить груз и правилами можно пренебречь, как вы помните.
Ну да ладно, это лирика. Давайте пойдем дальше.
Открываются школы, в которых обучают консультантов, кружки по интересам. По телевизору показывают научпоп передачки, как надо соблюдать ПДД. Водителей заманивают туда печеньками, рассказывая как круто живут города, в которых соблюдаются ПДД.
И вот градоначальник уже платит департаменту перевозок с одной стороны, ГАИшникам с другой стороны, ну, и консультантам с третьей.
Согласитесь, полный абсурд. И здесь очевидно, что нужно просто заставить водителей соблюдать ПДД, вернуть ГАИ их прежнюю функцию в полном объеме, чтобы не только грунтовки контролировали, но и проезд на красный вместе со знаками (отсутствие документации и описаний к базам данных).
Мы разрешаем разработчикам не заполнять описание базы данных, потому что это якобы тратит их дорогостоящее время. Но понимаем, что описание нам вроде как нужно, поэтому нанимаем отдельную службу, чтобы она это делала за разработчиков. При этом отвлекая самих разработчиков на то, чтобы те сказали, как это описать, да еще и задним числом, когда уже никто не помнит зачем точно была нужна (а может уже не нужна) эта таблица. То есть нужно лезть в код, но в код никто не полезет. Вот и поговорили.
Краткий вывод
Весь парадокс ситуации в том, что код вылизывают чаще и проводят ревью, чем уделяют столько же внимания базе данных. Если в коде можно найти зависимости и проследить цепочки вызовов (IDE + ваш любимый JetBrains это прекрасно позволяют), то в базе данных все намного сложнее. А без кода бэка (с бизнес логикой) и описания в самой БД, эта самая БД становится черным ящиком. Просто какая-то мусорная коробка, в которой лежат офисные бумажки после шредера.
Да и самим разработчикам потом после кого-то ковырять эту базу разве не приходилось? Когда какая-то таблица заполняется каким-то джобом, который когда-то настроила эксплуатация и вы не знаете как именно она заполняется. Взять значение из нее нужно, но страшно, а джоб это SQL листинг на 1000+ строк с несколькими вложенными запросами, переменными и процедурами.
Архитекторы рисуют стрелочки с квадратиками; решают, использовать json или yaml, rabbit или kafka.
Разработчики это реализовывают и комитят в гит
Дизайнеры придумывают UI
Тестировщики куют тест-кейсы
Техписари пишут доку в конфлюенсе
Скрамы двигают таски
А кто описывает БД? DBA? А он у вас есть?
Я это говорю потому, что прямо сейчас создаются тысячи новых микросервисов с сотнями мелких баз данных, в которых 10 таблиц, но не описано ни одно поле. Да, конкретно вы, возможно, описываете всё, но ведь есть же много других, которые этого не делают. Затем data steward пытается это описать в каталоге данных.
Внедрение каталога на этом этапе приведет к тому, что я уже описал в начале статьи.
Если кому-то показалось, что я предлагаю отказаться от DataGov, то это не так.
Я предлагаю переосмысление/сдвиг в сознании и изменение точки приложения усилия.
Правило простое:
Описание должно создаваться в тот же момент, тем же человеком и в том же комите, что и само поле. Иначе контекст утекает, а практика превращается в бюрократию.
Концепция
Решение, в первую очередь, должно быть со стороны пайплайнов и code review. Именно там должна быть блокировка, не допускающая создание нового поля в БД без его исчерпывающего описания.
Если компания задумывается о каталоге, значит, она достаточно крупная и у нее уже точно есть бигдата/DWH. У бигдаты продуктом являются их витрины. Они заинтересованы в этом в первую очередь. Это самая лояльная и погруженная в тему данных команда. Внедрение нужно начинать именно с бигдаты. Каталог должен стать их энциклопедией. Методологии нужно обкатывать на бигдате. Вырабатывать шаблоны описаний и пробовать пайплайны, чтобы это все автоматически приезжало в каталог.
У DataGov есть методики из DAMA, но они общие и без привязки к контексту. Коробочный каталог тоже часто универсальный. У бигдаты уже есть весь контекст специфики компании. Обкатка в этом подразделении поможет адаптировать практики и инструмент (каталог) под эту специфику.
Только когда у бигдаты все получилось и каталог наполнен, отстроен и работает идеально; Все, что есть у бигдаты, без труда находится и попадает в первые строки выдачи каталога, только тогда можно это масштабировать на другие подразделения.
DataGov нужен, чтобы объяснить, как должно выглядеть правильное описание, но объяснять они должны не для data steward, а для разработчика, который будет это описание делать. data steward, если такая роль есть, может делать code review.
Не у каждого получается писать красивые тексты и именно здесь на помощь приходит LLM, чтобы отшлифовать описание. Не создать его с нуля, а именно отшлифовать.
Может даже в процессе диалога модель опросит разработчика:
— зачем поле?
— почему оно именно так называется?
— кто им будет пользоваться? и т.д.
— (LLM, зная всё, что есть в каталоге, способна увидеть связь с чем-то еще и сразу уточнить) а вот в базе другого микросервиса есть поле Х, не для расширения ли его свойств ты добавил это новое поле?
— да, для этого
— ок (и добавит какую-то метку для связки)
После чего сформулирует описание.
Все эти вопросы в режиме диалога с моделью или в виде чеклиста должны быть выработаны на этапе обкатки в бигдате.
Но повторюсь, самое первое (еще до бигдаты) — пайплайны с блокировкой DDL-комитов без описаний и code review, это можно сделать уже сейчас. Если хотите, то с проверкой описаний с помощью той же LLM прямо в пайплайне.
Заключение
Каталог — витрина дисциплины, а не её заменитель
Смысл рождается у автора изменения
Стюард проверяет качество, а не восстанавливает смысл задним числом
LLM полирует формулировки, а не выдумывает описания
Описание — это часть схемы. Нет описания по шаблону — нет поля
Дорого отвлекать разработчиков? Но еще дороже бесхозная схема и фиктивный каталог