Что делать, если ваши данные разбросаны по десятку систем, и вы уже не помните, кто и когда менял ту табличку с выручкой, из-за чего отчёт показывает цифры, которые никто не может объяснить?…

OpenMetadata — это инструмент, который буквально вчера взлетел на GitHub с +776 звёздами за сутки, и теперь у него уже больше 13 тысяч. Сначала я подумала: «Опять какой-то корпоративный монстр для энтерпрайза, будет тяжёлый и неповоротливый». Но потом разобралась. Это open-source платформа для управления метаданными, созданная бывшими инженерами Uber и Hortonworks. Проще говоря — это как «Google Maps» для ваших баз данных. Она показывает, где что лежит, кто за это отвечает, и главное — куда именно пошла цифра, прежде чем попасть в ваш дашборд. Причём написана она на TypeScript, что для мира data-инженерии необычно — обычно такие штуки делают на Python, так что если у вас в команде есть фронтендеры, им будет комфортно ковыряться в коде.

Чем это реально полезно? Во-первых, data discovery — то есть поиск данных. Забудьте про чаты «а где у нас таблица с активными пользователями за март». Во-вторых, lineage — это когда вы видите полную цепочку: из каких сырых таблиц пришли данные, какие SQL-скрипты их преобразовывали, не было ли там дубликатов или ошибок. Я погуглила — это называется «родословная данных». В-третьих, governance — управление доступом и соответствие нормам вроде GDPR, когда нужно понимать, где у вас персональные данные, кто к ним имеет доступ, и не нарушаете ли вы случайно закон, используя чужие email в аналитике.

Но вот что меня насторожило. Это не «установил и забыл». Для команды из трёх человек, которая только начинает работу с данными — это, честно, оверкилл. Нужно поднимать Docker-контейнеры (а это значит, что вам понадобится человек, который разбирается в DevOps), настраивать коннекторы к PostgreSQL, BigQuery, Snowflake или чему вы там пользуетесь. И самое сложное — нужна культура документирования. Если аналитики не будут заполнять описания к таблицам, не указывать владельцев, не помечать чувствительные данные — получится красивая пустая коробка. Я бы проверила, готова ли ваша команда тратить по полчаса в день на поддержание порядка в метаданных, иначе это станет просто ещё одной обязаловкой.

Что можно сделать прямо сейчас? Не надо сразу покрывать всю компанию. Разверните локально через Docker Compose, подключите одну тестовую базу — например, ваш основной PostgreSQL. Выберите три самые важные таблицы и пропишите для них владельцев и описания. Посмотрите, как строится lineage — как данные течут от источников к отчётам, где узкие места. Если лень поднимать самостоятельно — есть облачная версия для теста. Это займёт вечер, но вы сразу поймёте, работает ли это для вашей архитектуры, или получится как всегда: красивый интерфейс, который никто не заполняет.

OpenMetadata — это не игрушка. Это серьёзный инструмент для тех, кто уже чувствует, что данные в компании превращаются в неуправляемый хаос, когда аналитики тратят больше времени на поиск таблиц, чем на анализ. Если у вас болит именно это — попробуйте. Начните малого: одна база, три таблицы, чёткие владельцы. Это бесплатно, open-source, и сообщество растёт быстро. Главное — не превратить это в бюрократическую машину для заполнения пустых форм, а использовать по делу, чтобы наконец перестать теряться в своих же данных.

https://github.com/open-metadata/OpenMetadata

OpenSource #DataEngineering #DevTools

Практический вывод простой: если это закрывает твою задачу, забирай репозиторий в работу, поднимай демо на своих данных и смотри по факту, а не по красивому описанию.