Метаданные - это не приложение к данным
Почему каталог данных и владение метаданными - это инфраструктурный вопрос, а не бюрократия.
Когда в компании начинается разговор про управление данными, метаданные почти всегда оказываются в конце списка. Сначала хранилище, потом ETL, потом дашборды - а каталог данных и описания полей "сделаем потом". Это "потом" в большинстве случаев не наступает.
Результат я вижу регулярно: аналитики тратят по несколько часов в неделю на выяснение того, что означает конкретное поле в базе или какой именно расчёт стоит за метрикой в отчёте. Люди спрашивают людей вместо того, чтобы читать документацию.
Что такое метаданные на практике
Метаданные - это ответы на вопрос "что это такое и откуда это взялось". Для таблицы в базе данных - это описание столбцов, источник данных, частота обновления, кто владелец. Для показателя в отчёте - это формула расчёта, период, исключения.
Без метаданных данные есть, но пользоваться ими сложно. Каждый человек, который сталкивается с полем "sum_net" в первый раз, должен идти и спрашивать. Или угадывать. Оба варианта плохи.
Почему это важно не только аналитикам
Когда данные используют только аналитики - проблема терпима. Можно держать знание в двух-трёх головах и переспрашивать друг у друга.
Но как только данные начинают использоваться шире - в моделях машинного обучения, в интеграциях с другими системами, в автоматических отчётах для руководства - отсутствие метаданных превращается в системный риск. Модель обучается на поле, значение которого никто не задокументировал. Интеграция перекладывает данные, предполагая одно, хотя источник имел в виду другое.
Ошибки такого рода сложно заметить сразу. Они обнаруживаются позже - когда результат уже использован в решении.
Кто должен отвечать за метаданные
Техническая запись метаданных - задача инженеров. Но содержательная часть - что означает показатель, как он считается, какие у него ограничения - это знание живёт у бизнеса.
Это значит, что управление метаданными не может быть чисто ИТ-проектом. Это совместная работа: бизнес даёт определения и правила, инженеры фиксируют их в системе и поддерживают актуальность.
Когда этой совместной работы нет - ИТ пишет технические описания, которые бизнес не понимает, или не пишет ничего вообще.
Каталог данных: когда он нужен
Небольшой команде с парой десятков таблиц достаточно структурированного Wiki или простого документа. Каталог данных как инструмент нужен тогда, когда источников становится много, когда одни и те же данные используются в разных командах, когда нужно понимать, откуда пришло конкретное значение в конкретной таблице.
Инструмент решает только часть задачи. Главное - договорённость о том, кто поддерживает описания и что происходит, когда поле меняет смысл.
Несколько практических вопросов
Если вы не уверены, насколько серьёзна проблема в вашей компании, попробуйте ответить на следующее:
- Если новый аналитик начинает работу завтра - есть ли документ, который объясняет ключевые показатели и источники данных?
- Если поле в базе данных изменит логику заполнения - кто об этом узнает и как быстро?
- Есть ли в компании показатель, по поводу которого разные люди дают разный ответ - и оба считают, что правы?
- Когда последний раз ИТ и бизнес совместно разбирали, что означает конкретная метрика?
Если третий пункт - это знакомая ситуация, разговор про метаданные давно назрел. Это не бюрократия. Это инфраструктура, без которой данные остаются сырьём, а не ресурсом.