Data catalog есть, а пользы нет: Частые ошибки внедрения

Всех приветствую! Зовут меня Павел, работаю в Lasmart и веду направление разработки решения по автоматизации описания метаданных с AI (Datadesc). Часто сталкиваемся с каталогами данных и вот решили про них написать.

Data governance, data mesh, modern data stack, data lineage – столько разных data, столько разных популярных подходов и инструментов. Лидером по популярности (на мой скромный взгляд) среди всех них является data catalog. Многие говорят о нем, многие хотят его, многие уже внедрили. Но внедрить это одно дело, а вот получить от него пользу – дело совсем другое.

Амазон проводил исследование, в котором говорится, что всего 18% компаний о том, что их сотрудники пользуются дата каталогами после внедрения. Получается, каталог то есть, а вот пользы от него либо мало, либо совсем нет. Как избежать этого?

В этой статье рассмотрим следующие:

• кому действительно нужен data catalog?

• какие частые ошибки совершаются при внедрении?

• как вообще его правильно внедрять?

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

Когда вам нужен Data catalog?

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

Здесь же я постараюсь рассмотреть самое важное – когда этот каталог нужен? А точнее, действительно ли он нужен? Потому как открою вам секрет, далеко не каждая компания в нем нуждается.

Много-много данных

Большое количество метаданных: таблиц, отчетных витрин, ETL-процедур, BI-дашбордов, учетных и информационных систем, - наверное, самая банальная проблема, из которой следует, что эти самые метаданные где-то нужно хранить и описывать. Именно эта проблема является катализатором всех остальных проблем. И наоборот, если у вас данных мало, высокая вероятность, что вам data catalog не так уж и необходим.

Конечно, само слово «много» весьма абстрактное, и для разных компаний границы этого «много» разные. Поэтому я здесь специально не буду указывать каких-то цифр. Вы сами их для себя определите.

Много-много времени

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

Много-много зависимостей

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

И да, каталоги данных содержат в себе такой функционал отображения data lineage, хоть и базовый.

Много-много требований

Мое любимое, о котором мало кто говорит, но самое важное. Это требования регуляторов. К примеру, 152-ФЗ обязывает знать, где лежат персональные данные. То есть, по-хорошему в компании все персональные данные должны быть описаны и указано место, где они хранятся. К тому же, данная «карта персональных данных» должны быть актуальная. И регулятор периодически может ее запрашивать.

Много-много data governance

Здесь много пояснять не буду. Если вы решили внедрять data governance, то, во-первых, вы знаете что это такое и зачем оно нужно, а, во-вторых, вы скорее всего начнете именно с data catalog-а. Что такое data governance и зачем уже оно нужно – тема для отдельной статьи.

P.S. У меня кстати была статья на vc про data governance, но довольно бизнесовая и простым языком.

А теперь самое интересное, когда каталог НЕ НУЖЕН? А все очень просто, если ни одной из перечисленных проблем у вас нет, то и каталог вам скорее всего не требуется.

Частые ошибки внедрения

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

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

Низкий уровень принятия пользователями

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

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

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

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

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

2. Сложный UX. Сам я считаю эту проблемы незначительной, но в исследовании ей много внимания уделяется. Действительно у многих data catalog сложный и непонятный UI и опыт пользователя в части поиска данных может быть не совсем простым.

3. Нет участия в рабочем процессе. Самая важная проблема, на мой взгляд. Если четко не указать сотрудникам, как они могут (или должны!) использовать каталог в своих рабочих процессах, никто сам не удосужиться думать на этот счет. Если вы просто дадите сотруднику какой-то инструмент без изменения их рабочих процессов, никто и пальцем не пошевельнет, чтобы эти самые процессы поменять. Потому как любое изменение процесса может его усложнить. А любой сотрудник боится увеличения и усложнения свох задач. И это нормально!

Неполнота и неактуальность метаданных

Вторая по популярности проблема, которая также встречается практически в каждом кейсе внедрения наших коллег и у нас. Наверное, не будет для вас секретом, что даже если мы говорим только про техническую составляющую внедрения, интегрировать data catalog с вашими системами и наполнить его метаданными – это далеко не такая важная задача. Самая важная задача при наполнении каталога – дать внятные бизнесовые описания этим самым метаданным. Какая польза от «голых» метаданных без бизнес-описания? Да никакой.

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

Очень много ручного труда

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

Весьма часто именно из-за высоких трудозатрат каталоги после внедрения стоят пустые, без бизнес-описания. Потому что data-команда понимает, как много «угрохает» она своих сил, а других приоритетных задач много (их никогда мало не бывает).

Не определены цели

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

Кто является чаще всего инициатором внедрения? Понятное дело, ИТ-отдел. Бизнес порой и не знает, что такое data catalog (и не должен!). Я сразу извиняюсь и подчеркиваю, что говорю далеко не про всех айтишников и основываюсь на своем субъективном опыте. Для айтишника главное набор фичей. Он смотрит на то, что умеет каталог, сравнивает решения, тестирует их между собой и т.д. Но не отвечает на самый главный вопрос – а зачем все это нужно?

Ого, в data catalog можно строить data lineage! Можно качество данных проверять! Есть различные интеграции. А зачем все это?

Некоторые ответят весьма популярным ответом. Как же так? Мы определили цель. Описать как можно больше данных, которые у нас есть. Хорошая цель, важная. А зачем вам описанные данные? Вот тут-то и происходит ступор.

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

Оставшиеся проблемы

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

Не редко упоминается проблема качества данных. То есть, у нас имеется описание данных и указание ответственного, но этого недостаточно. Мне, как потребителю данных, требуется знать когда данные обновлялись и, самое главное, какого они качества. Могу ли я их вообще использовать?

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

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

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

AI и автоматизация

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

Мы сами «заманались» актуализировать бизнес-описания на своих проектах вручную, и решили привлечь работягу, который никогда не откажет – AI. Ведь он идеально подходит для такой задачи. Определять семантику и смысл метаданных – да его хлебом не корми, дай таким позаниматься. Сделали собственное решение Datadesc и сейчас достаточно успешно применяем его на проектах.

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

• AI может не хватать контекста

• Зависимость от качества метаданных

• Нетривиальная архитектура и долгая «подгонка» промптов

• Системные требования к железу

Да, мы много времени потратили на разработку Datadesc (прям действительно не мало), зато теперь можем похвастаться следующими результатами:

• сократили свои трудозатраты по наполнению каталога на ~80%

• точность бизнес-описаний – 90-95% (но все зависит от метаданных!)

• кратно быстрее ищем данные – теперь примерно за 1-5 минут

• быстро выявляем зависимости с помощью автоматического data lineage

Заключение

Если после прочтения статьи у вас сложилось ощущение, что внедрение data catalog — это сложно, долго и больно, то… вы все правильно поняли. Это действительно непростая история.

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

Важно честно ответить себе на несколько вопросов:

• Есть ли у нас реальная боль?

• Готовы ли мы менять процессы?

• Готовы ли мы инвестировать время в поддержку каталога?

• Понимаем ли мы, какую бизнес-ценность хотим получить?

А дальше уже вопрос подхода:

• либо продолжать описывать тысячи таблиц вручную и надеяться, что энтузиазм команды не закончится (а он закончится)

• либо искать способы сократить рутину и оставить людям интеллектуальную работу

Закончу банальностью. Data catalog сам по себе пользы не приносит. Пользу приносит только правильно выстроенный процесс работы с данными.