Собирай, структурируй, управляй, находи

Каким сайтом каждый из нас(вне зависимости от отношения к интернету, возраста, пола, религии ) практически вне зависимости ни от чего пользуется парочку раз в день?

Поисковиком, все мы ищем информацию.

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

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

Статья будет состоять из 5 блоков.

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

Почему это важно(цель)?
Что это такое?(не забудьте открыть таблицу в конце статьи)
С чего начать?
Как “продать” это руководству?
В чем для меня успех?

Почему это важно?

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

Вот эти вопросы:

Как не допустить превращения хранилища данных в DATASWAMP(болотце данных)?

Что считаешь залогом успеха внедрения бизнес глоссария?

Википедия научила меня, что «мета-» означает «о себе». А на Украине главный поисковик не так давно назывался Мета. Это к тому, что качественный поиск не только у меня ассоциируется с системы сбора мета информации.

Данные это актив с большими к нему ожиданиям, data driven быть не столько модно, сколько практически необходимо. Если 10 лет назад хранилища себе могли позволить только корпорации, то сейчас всё open source и cloud. И в тоже время какими бы замечательными не были технологичные технологии, данные ничего не стоят без людей, которые вкладывают в них свой опыт и знания и заставляют их работать на компанию.

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

Что это такое система управления метаданными?

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

Например, активный клиент - совершивший покупку не более чем 3 мес назад.

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

Про логическую модель данных рассказывала в предыдущем посте. Если кратко отображение связей, ключей между сущностями, их кардинальности. Многие действительно ведут такую модель и описание терминов хранят в объектах таблиц.

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

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

Абсолютно убеждена, что вся нужная метаинформация уже рождается в ЖЦ работы с данными, просто за счет отсутствия адекватных стандартов работы и сложности распространения методологии управления данными - это информация вовремя не структурируется, не оформляется, и не сохраняется в едином и удобном для поиска формате.

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

Про какие метаданные идет речь:

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

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

Вот отличная статья от яндекса https://habr.com/ru/company/yandex/blog/557060/ - почему зоопарк бывает не только историческим наследием, но и обдуманным стратегическим шагом. Правда, как я понимаю, ребята как раз имеют некий единый управляющий механизм. В любом случае создание среды интеграции логов, структурирование идентификаторов потоков и общие справочники упростят lineage анализ, хоть и не сделают его 100% прозрачным.

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

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

Инструмент должен быть гибок в доработке и умение интегрироваться с гигантами case средств и lineage движков. Дело в том что большинство удобных и продуманных функций уже сделано в других инструментах(powerdesigner, confluence итд) и на это потрачено не один год опыта. В действительности я, конечно, систем не проектировала(только dwh), но по моему вполне возможно продумать api, позволяющие быстро “заливать” различные метаданные в единую визуализацию.

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

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

С чего начать?

Ответ на этот вопрос сильно зависит от стадии ЖЦ, уровня автоматизации, размера компании, и также вашей в ней роли.

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

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

Если не выходит, поймите какие данные максимально используемые в компании, поищите резонансные проблемные кейсы. Проблемы поднятые до уровня руководства, например, мы тут ошиблись в расчетах и потеряли млн. Ну а дальше кто с ними работает и возвращаемся к первому совету.

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

Как “продать” это руководству?

Планирую однажды ответить - позовите меня!

В интернете много статей от крупнейших компаний говорящих о необходимости построения таких систем, например, от Ростелеком https://habr.com/ru/company/rostelecom/blog/495934/ и чуть более короткая от Убер https://eng.uber.com/databook/.

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

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

В чем для меня успех ?

А вот тут вступает в дело вопрос моего другого коллеги “ как не превратить хранилище данных в болото?”

Ответ - внедрить систему управления метаинформаций и над ней инструменты и алгоритмы, которые позволили бы в автоматизированным виде, регулярно расчищать болото. Например, мониторить нагрузку на использование тех или иных данных - часто это называется тепловыми картами. Это трудозатратно с точки зрения ресурсов, выделяемых на дополнительного логирование, но без этого не актуальные для потребителей расчеты,

Так же успех в том:

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

что нет потребности ежегодно увеличивать “железо” в разы, только если ваша компания не увеличивается в эти же разы

что молодым аналитики могут не за месяц (а хотя бы за 2-3 дня) найти нужные им данные

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

Описание таблицы с типовыми метаданными (стадия жизненного цикла, объект управления и описания, сами метаданные, как использовать)

Стадия ЖЦ данных	Объект управления и описания	Описание метаданных	Как использовать
Первичный анализ	задача	описания требований в свободном формате	часто получение требований происходит по телефону или на встречах - но иногда можно в целом на базе протокола встречи написать тз фиксация ожиданий и феномен того что люди воспринимают все по разному и когда что-то фиксируешь письменно появляется автоматический стимул расписать детали
		заказчик и его контакты	а вот это кстати, далеко не всегда очевидный момент, и если в начале не осознать, кто твой конечный заказчик и чем же он все таки с точки зрения бизнеса занимается - можно сделать совсем не то (“испорченный телефон”) эта информация пригодится для дальнейшего взаимодействие по sla tla проблемы с данными и уточнение тз
		функциональное подразделение или бизнес процесс пользователь	считаю эти параметры зачастую наиболее эффективными чем понятие предметной области, в будущем это поможет разложить данные на крупные папки создав некий верхний уровень группировки данных
		цель создания или бизнес драйвер	обоснование стоимости и приоритета работ, а так же end to end понимание аналитиком задачи
		условия и требования к обновлению и эксплуатации ( tla sla)	capacity managment, управление нагрузкой на железо, режим сопровождения, планирование сервисных работ end to end понимание аналитиком задачи понимание клиентом текущих технических ограничений(особенно актуально, если заказчик далек от ИТ)
		историчность и глубина данных	стоимость хранения данных и объем требуемого в будущем места
		критичные моменты в качестве данных	целостность и интероперабельность данных
Аналитика	задача	источники данных	планирование миграции систем, зависимости от ошибок и изменений на источниках, lineage
		использование ранее разработанных dataset	экономия мощностей и интероперабельность, непротиворечивость итоговой отчетности
		soulution архитектура и инструменты	управление производительностью, стандартизация подходов разработки и сопровождения, проведения анализа инфраструктурных ошибок и ошибок внешнего программного обеспечения
	задача -> data set	логическая модель и связи с бизнес терминами и сами термины	продвинутый уровень, эти метаданные увы не всегда типовое явление, но в переписках бизнес в основном оперирует именно методологией и ключевые термины бизнес сущностей просто необходимы в системе для нормального поиска
Прототипирование	data set	физическая модель	контроль изменений, генерация тестовых данных
		name convention	структуризация, ускорение процесса написания аналитических запросов, простота интерпретации показателей в таблицах, конечно, она сама по себе не появится - но зачастую имеет место быть как стандарт разработки
		инструменты загрузки	тут могут быть перечислены как etl средства, так и какие то кастомные инструменты, так и просто написанные классы библиотек кода так же это может быть ссылка на некий внутренний справочник - по которому можно почитать пояснения по инструментам, инструкции по эксплуатации и проч
Разработка	data set	идентификатор витрины	наверное, самый сложный вопрос, что такое витрина! я пробовала ответить на него в предыдущей статье, но в рамках системы управления - это максимально удобный объект управления
		ссылка на версионный репозиторий хранения кода	тут все понятно, нет разработки - нет данных
		профилирование данных	это редкая история, но суть в том, чтобы понимать на уровне самих данных ( а не структур наполнения) паттерны данных в таблицах, это поможет в создание тестовых данных и отслеживание изменений паттернов на источниках
		s2t. и соотв состав описаний и таблиц	ключевой документ описывающий логику преобразования данных , пригодится всегда и везде - чтобы рассказать что у в витрине, от чего она зависит, как рассчитывается показатель, чтобы запланировать миграцию данных, сгенерировать целостные тестовые данные часто в подобных документах так же указывается уровень чувствительности данных
		контакт аналитик	контакты для логики сбора данных и других деталей
		как получить доступ	это удобно как и внутри команды, когда приходят новые люди так и для пользователей. в зависимости от ит уровня зрелости вариантов заполнения поля может быть много от простой инструкции до ссылки на какого нибудь телеграм бота, который задаст вопросы - и выдаст права
	data set-> потоки	дерево или последовательность загрузок	понимание структуры расчета витрин и последовательности потоков загрузки - оно заложено в коде витрины, но визуализации помогает быстро ориентироваться - "где застряли". иногда дерево можно сформировать автоматически из логов завершения потоков
	поток (часто привязан к таблицам, а не к витрине в целом)	название	бизнес название, например, отображающее этапность загрузки, по которому команда может быстро ориентироваться на какой стадии расчета витрина
		актуальность обновления	понимание даты обновления данных говорит потенциальным пользователям, насколько витрина в целом актуальна и можно ли завязываться на эти расчеты, а так же можно понять фактическую частоту расчета . Это техническая информация - которая точно есть в системы - каким загрузчиком вы бы не пользовались, но простота сбора этой информации сильно зависит от количество различных инструментов загрузки и стандартизации подходов.
		статус	потоки могут быть "задизейблены" - обычно это технический статус из управляющего механизма. или, например, витрина может считаться не целиком - это тоже важная информация
Внедрение	релиз	бизнес результат	это сильно перекликается с пунктами выше про общее назначение данных, но в релизе требуется указывать именно инкремент изменение - например, добавили расчет такого-то показателя. кроме экономического обоснования, это может служить важным фактором в сопровождение релиза и витрины в целом
		ответственные команды	информация для сопровождения витрины при возникновение проблем
		среды на которых проводилась отладка - даты отладки	удобно для выпуска новых релизов
		тестовые (функциональные и бизнес) скрипты	обычно бывают крайне удобны для регресс тестирования и просто поиска ошибок, обычно источники также живой организм и эти скрипты точно пригодятся, как и референсные значения по их выполнению на этапе прохождения промышленных испытаний
Эксплуатация	data-set часто в интерпретации набора потоков	TLA и SLA	технические и бизнес условия по уровню эксплуатации сервиса - многие живут без них, но иногда люди не совсем могут выровнять ожидания к тому как потоки должны работать, и как быстро их должны чинить
		Владелец и ответственный за развитие	на стадии вывода потока этих людей не может не быть, другой вопрос - что они могут меняться и как отслеживать эту информацию это еще тот квест
		Потребители	перечень реальных потребителе, получивших доступ, как бизнес пользователи, так и автоматизированные (сюда можно навертеть всяких рюшечек активность потребителей и тепловые карты, но пора мне остановится)