Чем дольше компания откладывает формализацию структуры данных и правил управления ими, тем дороже в дальнейшем обходится исправление накопленных противоречий. С ростом числа источников и объектов данных усложняются их связи, а отсутствие системной работы с метаданными приводит к ошибкам и удорожанию изменений. В такой момент важно не пытаться двигаться дальше по инерции, а вернуться на шаг назад и выстроить управление метаданными, превратив хранилище из точки консолидации данных в полноценную управляемую аналитическую платформу. Именно так поступила команда компании «Арнест ЮниРусь» — рассказываем, как это помогло навести порядок в данных и упростить дальнейшее развитие системы.

Метаданные — это важно

«Арнест ЮниРусь»
«Арнест ЮниРусь»

В любой крупной компании информация разбросана по десяткам систем: продажи — в одной базе, логистика — в другой, финансы — в третьей. Хранилище данных собирает все это в единое пространство, очищает, сопоставляет и превращает в основу для отчетности и аналитики. Если информационные системы, поддерживающие операционную деятельность компании, отвечают на вопрос «что происходит сейчас», то хранилище данных создает возможность для того, чтобы ответить на вопрос «почему это происходит и что будет дальше». Это не просто склад цифр, записей и неструктурированных данных, а управляемая аналитическая среда, на базе которой корректируют стратегию, планируют производство, управляют ассортиментом и прогнозируют спрос.

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

В 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, но и в других доменах разработки, где высока доля ручных интеллектуальных задач.