Почему бизнесу стоит присмотреться к своим метаданным: опыт «Арнест ЮниРусь»
Чем дольше компания откладывает формализацию структуры данных и правил управления ими, тем дороже в дальнейшем обходится исправление накопленных противоречий. С ростом числа источников и объектов данных усложняются их связи, а отсутствие системной работы с метаданными приводит к ошибкам и удорожанию изменений. В такой момент важно не пытаться двигаться дальше по инерции, а вернуться на шаг назад и выстроить управление метаданными, превратив хранилище из точки консолидации данных в полноценную управляемую аналитическую платформу. Именно так поступила команда компании «Арнест ЮниРусь» — рассказываем, как это помогло навести порядок в данных и упростить дальнейшее развитие системы.
Метаданные — это важно
В любой крупной компании информация разбросана по десяткам систем: продажи — в одной базе, логистика — в другой, финансы — в третьей. Хранилище данных собирает все это в единое пространство, очищает, сопоставляет и превращает в основу для отчетности и аналитики. Если информационные системы, поддерживающие операционную деятельность компании, отвечают на вопрос «что происходит сейчас», то хранилище данных создает возможность для того, чтобы ответить на вопрос «почему это происходит и что будет дальше». Это не просто склад цифр, записей и неструктурированных данных, а управляемая аналитическая среда, на базе которой корректируют стратегию, планируют производство, управляют ассортиментом и прогнозируют спрос.
Но в этой среде должна быть рабочая система обозначений для качественной навигации. В мире данных эту роль выполняют метаданные: описания таблиц, полей, алгоритмов расчета, связей между объектами. Именно они объясняют, как формируется показатель, откуда берется та или иная цифра в отчете, какие допущения заложены в расчет.
В 2023 году в «Арнест ЮниРусь» завершился масштабный проект по локализации корпоративного хранилища данных (DWH, data warehouse). Компания в сжатые сроки перешла на отечественную платформу, спроектировала новую архитектуру, запустила витрины данных и автоматизировала подготовку управленческой отчетности.
Хранилище росло быстрее, чем формализовывались требования к его описанию. В период миграции, в условиях жёстких сроков, команды опирались на согласованный минимальный набор требований к оформлению объектов. Описания велись в виде Markdown‑шаблонов через интерфейс GitLab, а их актуальность поддерживалась за счёт локальных договорённостей внутри команд.
В результате разные команды по‑разному интерпретировали структуру шаблонов и глубину детализации: отличались состав атрибутов, правила заполнения и формат описаний.
Поскольку проект миграции необходимо было выполнить быстро, то часть объектов была перенесена из предыдущего ИТ‑ландшафта вместе с исторической логикой расчетов. Их техническая реализация сохранялась, но бизнес‑контекст (исходные допущения, ограничения и трактовки показателей) часто существовал лишь в рабочей переписке и в понимании отдельных специалистов.
По мере перехода хранилища в фазу активного развития это стало системным фактором. Любая доработка начиналась с реконструкции существующей логики: аналитики поднимали код, восстанавливали взаимосвязи, уточняли логику с бизнес‑пользователями, оформляли пояснения и только затем формировали требования на изменение.
Time‑to‑Market увеличивался не из‑за сложности алгоритмов, а из‑за необходимости каждый раз заново интерпретировать уже реализованные решения. Компания столкнулась не с дефицитом данных, а с дефицитом формализованного знания о них — что естественно для этапа быстрого технологического перехода, но впоследствии требует отдельной управленческой настройки. Для бизнеса это означало затяжную приемку результатов: из‑за отсутствия понятных описаний алгоритмов бизнес‑специалистам приходилось тратить дополнительное время на их разбор и проверку, а согласование отдельных изменений занимало месяцы. Для ИТ используемый формат описания был трудоемким: в отдельных случаях на подготовку описаний приходилось до 30% общего объема работ.
Подход к снаряду
По мере роста хранилища и увеличения числа объектов, первоначального подхода стало недостаточно, и требования к оформлению пришлось пересматривать.
Попытка вручную актуализировать весь массив метаданных под новые требования не увенчалась успехом. Вскоре стало очевидно, что если аналитики сосредоточатся на обновлении документации в соответствии с текущим процессом, то разработка новых объектов практически остановится.
Также существовала необходимость ужесточения единого контроля за соответствием стандартам именования объектов и правил проектирования. Разные команды по‑разному называли таблицы, поля и показатели, по‑разному структурировали слои хранилища и реализовывали типовые сущности.
При отсутствии встроенных механизмов проверки и единых правил валидации это приводило к появлению дублирующих объектов, полей с похожими названиями, но разным содержанием, или, наоборот, одинаковых по смыслу показателей, реализованных под разными именами. На короткой дистанции такие расхождения почти незаметны, однако, по мере роста объема данных и числа команд они накапливаются и усложняют каждую новую доработку, увеличивая стоимость изменений.
Фактически компания оказалась перед выбором: либо принять растущие издержки как неизбежную плату за масштаб, либо встроить управление метаданными в саму ткань процесса разработки. Стало понятно, что метаданные более не обслуживающая функция, а инфраструктурный актив.
Новый подход к старым метаданным
Поэтому был переосмыслен сам подход к управлению метаданными. Было принято решение создать единую среду, в которой описание объектов, правила их проектирования, контроль качества и согласование изменений станут частью рабочего процесса, а не внешней надстройкой.
В основе новой модели лежала централизованная платформа управления метаданными Dat.ax Meta, дополненная ИИ‑модулем, встроенным непосредственно в процессы разработки. Платформа стала точкой сборки: здесь фиксируются требования в соответствии с централизованным форматом описания объектов, формируются спецификации, проверяются Naming Convention (набор формализованных правил, по которым называются все объекты хранилища) и типы данных, отслеживается соответствие архитектурным правилам. Искусственный интеллект не заменяет эксперта, но берет на себя рутинную часть контроля и анализа.
Он проверяет постановки на полноту, выявляет логические несоответствия, предлагает корректные наименования, помогает формировать описания объектов в режиме as is и проектировать будущие состояния to be.
Одним из наиболее ощутимых изменений стала автоматическая генерация спецификаций и технических заданий на основе SQL‑кода. Ранее подготовка такого документа могла занимать дни, требуя ручного анализа и сверки. Теперь значительная часть работы формируется автоматически, а бизнес получает прозрачное описание алгоритма расчета в понятном формате. Это позволило убрать промежуточный этап разъяснений между ИТ и заказчиком и перейти к обсуждению сути изменений, а не их расшифровки.
Важным элементом стала перестройка workflow. Появились автоматические проверки, которые не позволяют создать объект без соблюдения корпоративных правил. Финальное согласование со стороны дата‑стюарда закрепило ответственность за архитектурную целостность. Дополнительно дата‑стюард получил возможность самостоятельно разрабатывать новые шаблоны описания объектов в формате Jinja и выполнять массовую перегенерацию карточек при изменении требований. Процесс стал более формализованным, но при этом и более быстрым: контроль встроен в систему, а адаптация форматов перестала требовать постоянного ручного вмешательства.
Еще один вызов заключался в интеграции нового контура в уже сложившийся ИТ‑ландшафт. Необходимо было обеспечить бесшовное взаимодействие платформы управления метаданными с другими компонентами экосистемы заказчика (база данных, платформа для управления задачами и репозиториями), каждый из которых имел свои API и модели данных. Это потребовало разработки комплекса кастомных коннекторов и обеспечения согласованности данных в реальном времени.
Особое внимание уделялось корректности переноса исторических метаданных. Перенос и парсинг описаний, накопленных за несколько лет, выявил проблему их несогласованности и низкого качества. Чтобы привести метаданные к единому стандарту, потребовалось создать специальные скрипты валидации, а также провести ручные проверки. Этот этап оказался не менее значимым, чем сама автоматизация: без очищенного и унифицированного фундамента новая система не дала бы ожидаемого эффекта.
Измеряем эффекты
Изменения довольно быстро перешли в плоскость измеримого эффекта. Когда контроль за качеством метаданных стал встроенной частью процесса, снизилась нагрузка на ключевых специалистов, а скорость подготовки изменений заметно выросла. По итогам проекта трудозатраты ИТ‑команды сократились примерно на 7%, что эквивалентно около 150 человеко‑дням в год. Для компании это высвобожденный ресурс, который можно направить на развитие аналитики и новые инициативы.
Особенно ощутимый результат дала автоматизация подготовки спецификаций. Если раньше формирование документа по одному объекту могло занимать до нескольких дней, то после внедрения платформы этот процесс сократился в несколько раз. Внутренние замеры показали кратный прирост производительности: сценарии генерации документации позволили сократить время с многочасового ручного анализа до автоматизированной процедуры с последующей проверкой.
Аналогичный эффект проявился и в проверке постановок: часть задач, которые ранее требовали вовлечения дата‑стюарда, теперь проходит через автоматические и интеллектуальные фильтры, что позволило сократить загрузку сотрудников примерно на 30%.
Для бизнеса наиболее заметным стал рост прозрачности. Появилась возможность самостоятельно читать и понимать алгоритмы формирования витрин, не привлекая каждый раз аналитиков для расшифровки SQL‑кода.
Это сократило дистанцию между запросом и изменением, ускорило подготовку регламентной отчетности и улучшило общий пользовательский опыт работы с данными. В результате скорость вывода изменений на рынок выросла примерно на 15% — показатель, который напрямую влияет на конкурентоспособность в условиях высокой динамики FMCG‑рынка.
***
Фактически проект стал точкой зрелости для всей data‑функции. Бизнес получил инструмент, который снижает зависимость от ИТ в вопросах интерпретации данных, ИТ — механизм контроля и масштабирования без пропорционального роста штата, а компания в целом — более предсказуемую и управляемую цифровую инфраструктуру.
Для команды внедрения наработанные подходы рассматриваются как масштабируемые: логика интеллектуальной проверки, генерации спецификаций и контроля качества может применяться не только в DWH, но и в других доменах разработки, где высока доля ручных интеллектуальных задач.
Источник: osp.ru