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

Однако внутренняя эффективность компаний при работе с данными (трансакционные издержки) остается все еще «темной материей». Time-2-market для релиза цифровых решений по-прежнему велико, документация устаревает быстрее среднего срока работы специалиста по данным в компании, а приоритезация бэклога, выбор способа расчета метрик и т. д. принимаются на основе экспертизы, эскизов в Miro и тысяч внутренних Excel-таблиц, которые переделываются при каждой смене лидеров направлений. Все это — скрытые внутренние издержки, которые негативно сказываются на марже компании в долгосрочном периоде.

Об авторах

Всем привет, хотим представиться:

Руслан Ахметзянов — лидер стрима Data Governance в компании Лемана Тех. В зону моей ответственности входит развитие культуры работы с данными в компании, создание ее ценности, развитие принципов win-win, внедрение индикаторов и экономики здоровья данных. Для этого я развиваю сообщество менеджеров по управлению данными, метрики культуры работы с ними, являюсь ключевым заказчиком развития проф. инструментов (каталога данных и системы контроля качества данных), был их тех. лидером на этапе создания.  

Анна Чернобай — последние полгода исполняю функции владельца продукта, являюсь системным аналитиком на проекте и лидирую команду разработки каталога данных. Также активно участвую в развитии процессов управления метаданными.

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

Вызовы стрима Data Governance

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

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

1. Синхронизация с бизнес-целями компании. Отделы по работе с данными часто отдают приоритет тактическим задачам (сбор данных, отчетность) в ущерб согласованию инициатив в области больших данных с бизнес-целями. Часто причина этого несоответствия — отсутствие порядка в системе целей. Исполнители знают свои задачи и задачи следующего уровня, но у них нет четкой картины, на решение каких бизнес-потребностей (и с каким приоритетом) они работают.

2. Отсутствие карты знаний. Существует «синдром изобретения велосипеда»: если нет выстроенной функции по созданию единого информационного поля (глоссарии, отчеты, данные), это приводит к дублирующимся накладным расходам. Распределенные команды, не найдя нужные данные или метаданные, могут разрабатывать их самостоятельно.

3. Отсутствие выстроенных процессов и ролевой ответственности. Отделы по работе с данными пренебрегают ролевыми разрешениями на создание и редактирование метаданных между бизнес-единицами и IT. В результате действует функция «запрещать все, кроме», и тогда аналитики не могут обновлять глоссарии без согласований, что замедляет коллаборацию между командами и гасит инициативы. Как следствие, возникают теневые хранилища данных с неточными или рассинхронизированными метаданными. Либо, наоборот, работает принцип «разрешено все, кроме», и тогда непонятно, а кто же действительно отвечает за тот или иной набор метаданных.

4. Отсутствие стандартов. Что серьезно замедляет согласованную работу команд, так это отсутствие многоразовых шаблонов. Отделы по работе с данными часто не предоставляют стандартизированных шаблонов для документирования активов (например, для метаданных типа «бизнес-процесс»), корпоративная модель данных отсутствует. Как следствие, смена ответственных лиц приводит к тому, что документация по проекту начинается с нуля, что увеличивает сроки и риски. Успешные практики не могут быть масштабированы на другие отделы. 

Часто в угоду «быстрых побед», а потом и гнета вендорских решений и возникает внутренняя черная дыра, поглощающая впустую ресурсы, снижающая мотивацию и вызывающая ощущение постоянного дискомфорта при работе с данными.

В начале было... Collibra...

Итак, цель есть, что по инструментам? В конце 2021 года, когда мы делали, по сути, первую стратегию по данным, у нас был проприетарный каталог данных — Collibra. По некоторым причинам его политически нельзя было заменить на другой.

Что нам понравилось в решении:

1. Универсальная метамодель — можно было создать актив любого типа с метой любого типа без доработок.

2. Гибкая ролевая модель (ну почти) — можно было создать любые роли и привязать различные роли и workflow в каталоге.

3. Бэк, выполненный по принципу «API-first». Можно было автоматизировать заполнение меты своими процессами. Правда, смущало отсутствие полноценных batch-методов.

Из плюсов, пожалуй, все. Что нам решительно не нравилось в каталоге:

1. Отвратительный UX / UI — застрявший в начале нулевых неинтуитивный интерфейс с кучей мелких переключателей, в которые надо было попасть мышкой (нам было больно, да, и это еще до выхода на массового пользователя).

2. Отсутствие экстракторов метаданных, или, по-другому, интеграций, автоматически извлекающих метаданные из систем-первоисточников — состава BI-отчетов и их меты с серверов BI, состава таблиц баз данных и пр. Точнее, экстракторы в проприетарном инструменте есть, но по определенным причинам мы не могли их использовать. Приходилось делать экстракторы самим «сбоку», используя API Collibra.

3. Слишком костыльный метод получения меты из репозитория Collibra для аналитики. Мы решили это цепочкой ETL-а с 4-5 шагами, на каждом шаге своя технология промежуточного хранения (файлы, s3, google bigquery, postgresql). Усугубленное разделенной ответственностью (облако вендора, облако головной компании, наш контур), это было крайне нестабильное решение.

4. Общее свойство для проприетарных решений, разработанных в США, — космически долгий путь по исправлению багов и игнорирование наших запросов на доработки.

Наша культурная среда

Прежде чем перейти к техническим вопросам, рассмотрим культуру компании, которая создала необходимые условия для перехода к техническим и методологическим решениям по организации процесса управления метаданными. Прежде всего, у топ-менеджмента есть осознание потенциальных проблем, которые могут возникнуть, если культура работы с данными не находится на достаточно высоком уровне. Это и технологическое отставание, и увеличенный time-2-market в будущем ради быстрых побед сегодня. Это также негативное влияние на имидж бренда Лемана Тех как работодателя. Забегая вперед, скажем, что крайне важно лицам, принимающим решения о приоритезации бэклога, постоянно демонстрировать эффекты, выраженные в метриках, связанные с незрелой культурой работы с данными (тех. долг) и лучше, если эти потери будут выражены в деньгах.

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

В Лемана Тех оба условия были выполнены. Взаимодействие с ЦК жизненно необходимо, поскольку программа управления данными без поддержки со стороны IT, бизнеса и архитектуры обречена на провал. Более того, чем глубже компания погружается в успешное управление данными, тем больше областей того самого колеса DMBOK оно охватывает.

Turning point

В 2023 году возникла задача заменить наш проприетарный каталог данных.

Мы хотели сохранить лучшие аспекты Collibra, исправив отсутствующие или неудобные моменты. В итоге мы сформировали следующие базовые архитектурные требования, которые должны войти чуть ли не с первой версии импортозамещенного решения. В довесок, важным требованием к поставленной задаче было сохранить имеющийся контент в каталоге «без потерь».

Для того, чтобы понять примерные объемы контента для каталога, укажем основные параметры информационного ландшафта Лемана Тех и Лемана ПРО:

• Количество различных систем (цифровых решений) достигает 400-450. И лишь около 10-15% из них - вендорские решения, остальное - самописные решения;

• 19 бизнес-департаментов, 112 магазинов, 40000+ сотрудников;

• 600+ бизнес-функций (по TOGAF);

• 1200 - кол-во ежедневных ETL-процессов в корпоративное озеро данных;

• 700+ - кол-во схем данных в КХД на базе Greenplum.

У нас получился следующий список наших базовых хотелок к каталогу.

Гибкая метамодель. Процессы постоянно совершенствуются, и мы должны быстро адаптировать решения к хранению самых разных метаданных под требования ЦК. Поэтому ключевая особенность — возможность описать произвольный артефакт или единицу знаний (в дальнейшем будем именовать это понятие «активом») без команды разработки. Это вообще основа управления метаданными. Вся информация должна быть представлена в виде стандартизованных шаблонов (типов активов) для возможности их повторного использования как людьми, так и автоматизированными системами. По мере роста культуры данных в компании внедряется все более сложная метамодель. Граф знаний состоит из элементов, основанных на уникальных возможностях компании — приоритетах, ключевых сотрудниках и т. д. Никто не может заранее предсказать етамодель знаний, пригодную для всех организаций. И, возможно, именно поэому не существует универсального решения среди каталогов данных. От разрозненных точечных практик работы с метаданными в различных процессах работы с данными мы приходим к тому, что зрелые прцессы управления метаданными трансформируются в единые подходы управления знаниями.

Гибкая ролевая модель. Сопряженной с предыдущим требованием является концепция гибкой ролевой модели. ЦК должны легко управлять не только шаблонами, но и ролями — кто способен выполнять те или иные действия при работе с активами знаний. По этой причине нельзя использовать для ведения метаданных, например, облачные spreadheets. Центр компетенций может установить правило, что только специалист по информационной безопасности может менять уровень конфиденциальности объекта данных, но не изменять другие свойства элемента знаний. И эта функция также должна быть частью настроек, а не вопросом разработки системы управления метаданными.

Подход «API-first», публичные API и доступный репозиторий. Подход «API-first» позволил бы нам обеспечить автоматизацию рутинных процессов, которые внедряют центры компетенций в компании. А доступный репозиторий поможет быстро визуализировать необходимые метрики для руководства и центров компетенций. Подход «data governance by design» требует интеграции инструментов создания активов данных, JIRA/трекеров и систем управления знаниями, поэтому публичные API необходимы для бесшовной работы стейкхолдеров.

Автоматическое извлечение метаданных. Поскольку многие элементы знаний создаются в специализированных системах, должны быть возможности для извлечения этих метаданных. Например, таблицы и представления — это структуры данных, которые рождаются в базах данных; бизнес-процессы и элементы архитектуры могут управляться в средах, адаптированных под архитекторов. Существует множество способов, с помощью которых системы предоставляют свои метаданные. Очереди сообщений, инстансы репозиторий, API-эндпоинты и другие являются типичными источниками для системы управления метаданными знаний. И наша задача — автоматизировать сбор таких метаданных. 

Базовые опции чтения, редактирования и удаления записей через UI. Для каждого актива должна быть возможность применения опций CRUD через интерфейс, что существенно снижает порог входа в процессы управления знаниями. Особенно актуально это требование в контексте того, что на практике не под любой тип актива целесообразно покупать свое собственное решение. Да, в идеале для управления орг. структурой должно быть свое приложение, обеспечивающее бесшовный клиентский путь, для управления бизнес-функций — свое, но на практике бюджет лимитирован.

Широкие возможности поиска. Для решения потребностей различных стейкхолдеров инструмент должен обладать не только понятной группировкой и иерархией знаний, но и продвинутым поиском — как полнотекстовым, так и настраиваемым по необходимым пользователю измерениям.

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

Естественно, все эти технические решения должны сопровождаться благоразумным UI/UX-м, позволившим бы пользователям каталога работать по возможности без дополнительных инструкций и обучений.

Turning point

Около трех месяцев в 2023 г. мы потратили на анализ возможных вариантов — сравнивали возможности opensource и доступных проприетарных решений, риски при реализации собственного решения с использованием opensource компонентов при ограничениях в бюджете и ресурсах.

Говоря о покупке проприетарного решения — на тот момент на российском рынке было доступно одно полноценное , однако при всех его неплохих возможностях смущало ограничение на количество редакторов (а прайсинг за анлим пользователей улетал бы по бюджету в космос), при этом, естественно, кодовая база была закрыта.

При анализе opensource-решений мы рассматривали трех кандидатов: Atlas, OpenMetadata и DataHub. Однако, посмотрев ядро этих решений, мы поняли, что допиливать под наше ключевое требование — гибкую метамодель — будет достаточно дорого и сложно. По предварительным расчетам подгонка под целевое состояние требовала сопоставимых затрат ресурсов, включающих изучение «серых» ящиков, — код в github-е не выглядел органичным и архитектурно продуманным.

В итоге при поддержке коллег из корпоративной архитектуры мы пошли ва-банк, выбрав вариант с собственной разработкой, который отличался наибольшей гибкостью и возможностями, но в долгосрочной перспективе. Ва-банк — потому что на старте у нас из ресурсов был доступен один бэкенд-разработчик, остальные роли мы взяли на себя, привлекали коллег на добровольных началах. Чуть позже команда проекта стала больше (забегая вперед, это было верное решение).

Решение Лемана Тех

Итак, что же у нас получилось за 2 года от точки старта разработки до решения, удовлетворяющего заявленным функциональным требованиям.

Архитектура решения

Диаграмма C4 для платформы управления метаданными представлена ниже.

Metadata Management Backend (Java Spring)

Это основной сервис для операций CRUD, который обрабатывает все операции создания, чтения, обновления и удаления через веб-приложение или через API. Данный фреймворк отлично подошел для реализации гибкой ролевой модели при взаимодействии с API и необходимой метамодели активов метаданных в каталоге, обеспечивая соответствие всех изменений заданным шаблонам.

Metadata Management UI (React)

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

Search service (Elasticsearch)

Все активы из репозитория метаданных были проиндексированы, и по ним настроен полнотекстовый поиск с фасетной фильтрацией. Поиск — основная точка входа в каталог для большинства пользователей, и мы старались сделать его гибким и учитывающим всю доступную информацию об активе. Однако нам потребовалось несколько итераций, чтобы эта точка входа перестала спустя несколько нерелевантных поисковых выдач превращаться в точку выхода. При всей гибкости и возможностях elasticseach первые версии поиска некорректно работали с точными совпадениями по словосочетаниям, опечатками, метаграммами, а также неудачно ранжировали найденные результаты (например, когда в одном из результатов совпадение было в названии, а в другом — в описании или синонимах). В последующих версиях индекса данные проблемы удалось решить.

Metadata repository (PostgreSQL)

Реляционная база данных, которая служит основным хранилищем для всех данных системы. Она хранит информацию о пользователях, их ролях и правах доступа, активах метаданных, их атрибутах, связях между ними, а также системные настройки.

Graph database (ArangoDB)

Нам было важно дать пользователям возможность быстрой визуализации lineage, логической модели данных и иных связей между активами с опциями поиска конкретных активов в общем графе и импакт-анализом без излишней нагрузки на основной репозиторий метаданных. Для данного функционала решили использовать ArangoDB (opensource графовая база данных с развитым комьюнити) как отдельное хранилище для оптимизации запросов к графам сложных связей. БД хранит подмножество данных из основного репозитория метаданных, которые преобразуются в коллекции.

 

Metadata Message Broker (Kafka)

Стандартный компонент, являющийся брокером сообщений между системой управления метаданными и различными источниками данных, такими как реляционные и нереляционные базы данных, API-эндпоинты, BI-системы. В топики сбрасываются сообщения с активами метаданных, которые консьюмятся бэкендом и используются для поддержания активов в системе в актуальном состоянии. Каждый топик соответствует определенному типу источника данных. 

Data Sources extractor API (Java Spring)

Это отдельно выделенный бэк для специализированного сервиса обработки сообщений из топиков Kafka. Сервис использует сообщения для вычисления дельты между состояниями активов в источниках данных и тех же активов в системе управления метаданными. Полученные дельты прогоняются через батч-методы основного бэкенд-сервиса. Компонент оптимизирован для потребления и обработки большого объема сообщений (до одного миллиона на источник данных).

Metadata Extraction Service (Airflow)

Этот компонент оркестрирует процесс импорта метаданных. Он планирует и управляет автоматизированными заданиями, которые извлекают метаданные активов из источников данных и отправляют их в топики Kafka. Один DAG Airflow соответствует одному источнику данных.

Модель данных репозитория

Ядро модели данных решения построено вокруг концепции «Актив». Неважно, является ли объект физическим или логическим, — все типы артефактов (база данных, таблица, отчет, метрика) являются активом.

Каждый актив имеет:

• Фактическое имя, совпадающее с его именем в исходной системе (например, таблица «dict_stores» или отчет «Динамика GMV») или именем логической сущности.

• Полное имя, которое является уникальным среди всех активов метаданных и следует определенным правилам именования в зависимости от типа актива. Оно также может быть источником дополнительной информации об активе и полезно для индексации в поисковой системе (например, для упомянутой таблицы «dict_stores» полным именем будет конкатенация базы данных, схемы и имени таблицы — «adb.dds.dict_stores»).

Дополнительно каждый актив имеет два статуса:

• Статус жизненного цикла (Lifecycle) — показывает, существует ли актив в исходной системе или нет. Примеры значений этого статуса: «В разработке», «Активный», «Устаревший».

• Статус описания (Stewardship) — показывает, насколько хорошо актив задокументирован в системе и на каком статусе workflow описания он находится. Примеры значений этого статуса: «Черновик», «На проверке», «Подтвержден».

Каждый актив обладает набором атрибутов, которые его описывают. Типы атрибутов (например, описание, уровень конфиденциальности, график обновления и т. д.) определяются типом актива. Они бывают разными: некоторые имеют простой числовой или расширенный текстовый формат, другие — более сложные и могут быть настроены с заранее определенным списком значений или маской валидации, которая используется для проверки и подтверждения вводимых пользователем данных (например, cron-формат для атрибутов, связанных с расписанием, или заданный отделом информационной безопасности список уровней конфиденциальности данных для таблиц).

Активы могут быть связаны друг с другом посредством отношений, формируя единый граф знаний компании в метамодели по типу онтологии.

Например:

• BI-отчет может зависеть от витрины данных (то есть витрина данных служит источником для отчета) — и эта связь определена в метамодели.

• Бизнес-термин имеет физическое представление в виде какой-либо таблицы в объектно-ориентированном слое хранилища данных.

Все отношения между активами являются двунаправленными. Отношение может состоять из двух или более активов. Количество активов и типы активов, допустимые в конкретном отношении, определяются типом отношения. Со стороны подобный подход, когда в каталоге связь состоит, например, из трех активов, может показаться избыточным, однако на практике вполне применим в сценарии привязки метрики GMV, которая берется в конкретных разрезах (тип клиента B2C, B2B, Profi), к отчету Bestseller. Отпадает необходимость создавать отдельные версии метрики для каждого разреза, достаточно настроить связь между активами — метрика GMV, классификатор Тип клиента, отчет Bestseller.

Каждому активу может быть назначена определенная ответственность — пользователь или группа пользователей с определенной ролью в отношении данного актива. Каждая роль имеет набор разрешений, которые позволяют выполнять определенные действия с активом, его атрибутами, отношениями и назначением ответственных. Это представляет собой максимально детализированную гранулярную RBAC-модель, которая может быть синхронизирована с любым провайдером аутентификации.

Каждое разрешение представляет собой комбинацию четырех параметров:

• Тип действия — вид выполняемого действия. Эти типы соответствуют операциям CRUD.

• Тип сущности — определяет, над какой сущностью можно или нельзя выполнить действие. Типами сущностей являются: Актив, Отношение, Атрибут, Ответственность и т. д.

• Тип объекта в рамках типа сущности — определяет область применения действия: распространяется ли оно на все объекты данного типа сущности или только на объекты с определенными типами. Например, для разрешения с типом сущности «Атрибут» можно задать область действия так, чтобы пользователь с определенной ролью мог создавать и изменять только атрибуты с типом «Описание» или «Расписание», но не «Уровень конфиденциальности» или «Статус проверки отчета». 

В Collibra гранулярность ролевой модели ограничивалась типом сущности, однако нам такая детализация показалась недостаточной. Например, в процессе ревью отчета только разработчик-ревьювер должен иметь возможность изменять в каталоге атрибут отчета «Статус проверки отчета», однако у разработчика — технического владельца отчета должно быть разрешение менять все остальные атрибуты отчета за исключением статуса проверки. Механизм детализации разрешения до уровня объекта позволил гибкую настройку роли под конкретный процесс и избавил команду data governance от необходимости делать периодический аудит по активам на предмет изменений конкретных полей в обход согласованных процессов.

• Тип разрешения — указывает, разрешено или запрещено действие, указанное в разрешении.

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

Для соответствия требованиям чувствительного к роли представления активов был реализован механизм настраиваемых представлений (custom view). Для примера рассмотрим таблицу в реляционной базе данных. Для инженера данных, который исследует систему в поиске источников для новой витрины, важно видеть структуру таблицы и типы данных ее столбцов именно такими, как они есть в базе данных, примеры запросов к этой таблице, график обновления данных и другие технические детали. Для аналитика, изучающего ту же таблицу в системе, эти технические детали не очень полезны, но информация о связанных метриках и бизнес-сущностях, хранящихся в этой таблице, нужна больше. Цели и задачи, для решения которых пользователь взаимодействует с системой, варьируются в зависимости от его ролей.

Чтобы помочь пользователям решать их задачи, ввели механизм агрегации информации об активе — его атрибутов, связанных активов (включая транзитивные связи), атрибутов этих связанных активов и так далее — по более длинным цепочкам. Используется аналогия с построением сложных утверждений на основе набора базовых утверждений в онтологическом графе.
 
Технически custom view — это визуальное отображение запроса над данными, состоящее из:

• типа актива, который указывает, что данное представление используется для активов этого типа;

• роли, для которой это представление актива будет использоваться;

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

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

Базовая ER-диаграмма системы с основными сущностями представлена на схеме 2.

Полная ER-диаграмма в Postgres базе сложнее, с большим количеством внешних ключей, итого состоит из 45 таблиц (включая «таблицы-линки» — т. н. «assignments» на типы активов, типы атрибутов, типы отношений, а также история изменений).

Схема экстрактора метаданных

Теперь рассмотрим архитектуру подсистемы экстрактора метаданных. Поток обработки метаданных организован следующим образом:

1. Данные извлекаются путем выполнения запросов к базам данных или вызовов API.

2. Apache Airflow оркестрирует обработку этих данных, а затем отправляет результаты в виде сообщений в топик Kafka.

3. Приложение-consumer получает эти сообщения из Kafka для дальнейших действий.

4. Отдельные планировщики управляют общей обработкой и задачами очистки для этого потока данных.

Источники данных классифицируются по типам: реляционные базы данных, API, отчеты и хранилища «ключ-значение». Каждый тип далее делится на подтипы, что определяет конкретный механизм извлечения данных и формат сообщения для Kafka. Для добавления нового источника данных создается новый DAG, который генерируется из файла конфигурации. Единая конфигурация включает: учетные данные (ссылку на секрет в Vault), тип источника, правила планирования и фильтры для данных, которые необходимо извлечь из источника. Существует два типа сообщений: сообщения об объектах-источниках и сообщения с метаданными.

Метаданные отправляются в выделенный топик Kafka (общий для всех сообщений с метаданными) после завершения всей обработки данных. Сообщение содержит контрольные суммы и метаданные источника. Для каждого типа источника данных предназначены собственные топики Kafka. Для источников типа API каждый новый источник получает свой собственный новый топик Kafka. Количество потребителей для топика определяется типом источника. Из каждого сообщения с метаданными создается задание и соответствующие объекты. Из сообщений об изменениях создаются таблицы с сырыми данными.

Основные процедуры предназначены для обработки данных заданий, успешно прошедших проверку контрольной суммы. Эти процедуры используют сырые данные для вычисления разниц (дельт) между данными в источнике и данными в каталоге, которые были преобразованы и сопоставлены с целевой структурой Решения. Основная цель этих вычислений — последующее применение рассчитанных дельт через вызовы API к основному репозиторию Postgres.

Целевая структура системы организована вокруг трех основных сущностей: активы, связи между этими активами и конкретные атрибуты каждого актива. Все обнаруженные изменения систематически классифицируются на три отдельных типа операций: Insert (новые записи), Update (изменения существующих записей) и Delete (удаление записей). Каждый тип операции сопоставляется с соответствующим HTTP-методом для взаимодействия по API: для операций Insert используются конечные точки POST, для Update — PATCH, а для удаления сущностей — DELETE. Такой структурированный подход гарантирует, что все изменения точно применяются через API системы.

Система управления метаданными в корпоративной архитектуре

Далее мы кратко опишем, как система управления метаданными встраивается в общий ландшафт решений компании. Это не конкретная C4-диаграмма, на которой видны связи системы управления метаданными с другими цифровыми решениями, а скорее шаблон того, как мы позиционируем такой инструмент. Концепция проиллюстрирована на схеме 3:

Для проприетарных решений, управляющих метаданными, наша система отвечает за создание экстракторов для импорта запрошенных метаданных. Источниками обычно являются BI-инструменты, базы данных, унаследованные решения для сотрудников, отделов и т. д. Методы импорта метаданных разнообразны — это могут быть JDBC-коннекторы к репозиториям метаданных, брокеры сообщений или API-эндпоинты, предоставляющие метаданные.

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

Сопутствующие методологические аспекты внедрения зрелых процессов по управлению метаданными

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

Поддержка и продвижение метамодели данных

У нас есть центральная команда, которая сопровождает правила формирования шаблонов и управляет развитием метамодели (это и есть центр компетенций Data Governance). Обеспечиваем определенный уровень сервиса, который обслуживает потребности центров компетенций, а также служит координирующим центром, внедряющим в компании единую метамодель. Кроме того, этот управляющий центр обеспечивает регулярный обмен лучшими практиками между центрами компетенций для достижения совокупного эффекта за счет использования шаблонов и репозитория метаданных.

Анимация метрик системы на всех уровнях

Важный аспект поддержки процессов управления метаданными — визуализация KPI и метрик, требуемых центрами компетенций. Например, центры компетенций по аналитике могут быть заинтересованы в среднем времени стадии аналатики в процессе разработки фичи, в то время как архитекторы решений будут заинтересованы в наличии актуальной C4-архитектуры новых решений.

Эти метрики, собираемые и отслеживаемые на различных уровнях — от отдельных сотрудников до подразделений — получают поддержку высшего руководства, даже если темпы улучшения самих метрик будут отставать.

Примеры метрик включают:

• доля изолированных хранилищ данных, не интегрированных с центральной Платформой данных;

• доля промаркированных датасетов в корпоративном хранилище данных;

• долю сертифицированных отчетов и дашбордов.

Чуть позже мы опубликуем отдельную статью об аналитике данных.

Постоянное обучение и вовлечение бизнеса

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

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

Синергетические эффекты и изменение культуры данных

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

1. Автоматизированные проверки качества данных. Например, если мы знаем метрики, собираемые в отчете или дашборде и их источники, мы можем автоматически проверять достоверность метрик, соединяя логическую природу их расчета через модель данных и физические реализации.

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

Перечислим эффекты для центров компетенций, которые мы наблюдаем на опыте Лемана Тех с ее платформой управления метаданными. Как ключевые стейкхолдеры, они получают следующие эффекты от общего подхода и методик:

• ЦК могут совершенствовать свои шаблоны знаний, просто реализуя настройки в платформе управления метаданными, — таким образом, они могут без ожиданий совершенствовать свои процессы.

• ЦК могут достаточно быстро интегрировать свои решения или рабочие процессы с достоверными метаданными.

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

• ЦК получают уверенность в том, что другие центры компетенций стремятся поддерживать свои активы в актуальном состоянии (культура здоровой конкуренции).

Ниже продемонстрируем некоторые цифры, основанные на эксплуатации платформы управления метаданными за 2 года. 

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

В итоге нам удалось реализовать инструмент с мощной основой для дальнейшего развития полноценной практики управления знаниями и данными в компании. Благодаря универсальной основе мы без труда готовы к обслуживанию новых возникающих процессов по работе с метаданными — без длинных бэклогов, а прямо здесь и сейчас. И это же позволяет нам уже сегодня получать продвинутую аналитику по нашим данным и показателям культуры работы с данными.  Впереди нас ждет долгий путь достижения состояния true data-driven.