В Островке мы строим экосистему вокруг данных — от хранилищ и пайплайнов до систем мониторинга и каталогов. Но когда всё только начиналось, под часть наших процессов просто не существовало готовых решений. Так появился наш собственный дата-каталог DataPortal — лёгкий, быстрый и идеально подходящий для небольшой компании.
Со временем всё изменилось: объём данных вырос в десятки раз, появились новые команды, и вместе с этим начали звучать вопросы вроде «где лежат данные для этого дашборда?», «кому писать, если он упал?» и «можно ли этим данным доверять?». Так мы поняли, что пора взрослеть — и искать инструмент, который поможет масштабировать не только инфраструктуру, но и дата-культуру.
Мы выбрали DataHub — open-source каталог, обещавший прозрачность, автоматизацию и гибкость. Развернули, подключили источники, построили lineage, и даже порадовались, что всё заработало с первого раза. А потом стало ясно: DataHub не заменил наш DataPortal. Более того, оба инструмента отлично дополнили друг друга — инженерное ядро и удобное окно в данные для бизнеса.
Почему два дата-каталога оказались лучше одного, как это повлияло на культуру работы с данными и что нам дал DataHub помимо красивых графов lineage — рассказываем под катом.
Привет, Хабр! Я Алексей Чумагин, Data Quality Team Lead в Островке. В недавнем посте я рассказал об инструментах, с помощью которых мы обеспечиваем качество данных в компании. Сегодня сделаю акцент на управлении метаданными: поделюсь историей нашего пути от собственного каталога DataPortal до опенсорсного DataHub.
Дальше — практический разбор: где наш дата-каталог перестал справляться с инженерными задачами, какие грабли нас ждали при переходе на DataHub и как в итоге родилась двухуровневая архитектура каталогов (спойлер: сейчас она работает для нас лучше, чем любое «универсальное» решение).
Дата-каталогов не бывает много?
Когда в компании только формировалась культура работы с данными, DataPortal реально выручал. Он был лёгким, понятным и по-домашнему удобным: открыл — нашёл нужное, не утонул в настройках. Благодаря этому быстро стал точкой входа для аналитиков и инженеров.
Данных становилось всё больше, и для оптимизации их хранения мы решили переехать с Vertica на Ozone S3. Тогда-то и начали проявляться технические ограничения DataPortal:
второй источник данных подключить оказалось нетривиально;
с ростом количества объектов потребовался продвинутый поиск;
lineage отсутствовал как класс;
никакого внешнего API (значит, никакой автоматизации);
К тому же регулярно приходили новые сотрудники, не знакомые с внутренним инструментом, а это осложняло онбординг.
Чем чаще аналитики спрашивали «где лежат новые данные?», «кто отвечает за витрину, построенную на DBT?», «можно ли ей доверять с точки зрения Data Governance?» — тем чётче мы понимали, что DataPortal больше не масштабируется архитектурно.
На старте это выглядело как локальные неудобства. Но по факту это был сигнал зрелости: мы выросли из инструмента, который был идеален для небольшого, стабильного ландшафта.
Почему не «допилить своё» и почему DataHub
Первый импульс был предсказуемым: «Ну мы же уже всё написали — давайте добавим ещё пару фич». Но быстро стало понятно, что дорабатывать решение, в силу специфики его архитектуры, будет экономически невыгодно.
Чтобы не городить вечный ремонт, мы сформулировали критерии, которые должны были решить проблему не на полгода, а на годы вперёд:
несколько источников данных out-of-the-box;
автоматизация ingestion, а не скрипты-коннекторы;
полноценный lineage;
API-first подход, чтобы метаданные можно было использовать дальше в экосистеме;
домены/глоссарии как фичи платформы, а не отдельно существующие сервисы.
Выбирали прежде всего среди open-source-решений с развитым комьюнити — расчёт на перспективу предполагает, что и инструмент не должен стоять на месте. В шорт-листе у нас оказались OpenMetadata и DataHub — у первого более подробная документация, но мы рассудили, что в эпоху LLM вопрос документации уже не стоит так остро.
В целом DataHub оказался «золотой серединой»: достаточно инженерный, чтобы расширять, и достаточно зрелый, чтобы не писать пол-системы самим.
Как проходила миграция: первые успехи и «подводные камни»
Когда мы развернули DataHub, взяли и подключили готовые коннекторы, наступил тот редкий момент в жизни дата-инженера, когда что‑то действительно «завелось с первого раза». Сложности начались, когда мы начал делать lineage, и когда источников стало не два, а десять.
DataHub отлично работает, пока метаданных мало. Но когда ingestion-пайплайны начали собирать сотни объектов из разных систем, performance неожиданно стал первой болью. Мы старались оптимизировать нагрузку: совершать меньше запросов к самому DH и делать ingestion только тогда, когда метаданные реально менялись.
С чем ещё столкнулись в процессе?
Грабли №1: колоночный профайлинг. В теории он красивый, в практике — он съедал ресурсы так, что ingestion шёл часами. Мы в итоге просто вырубили его и оставили только табличный. Сразу стало легче. Но мы продолжаем думать над тем, как нам делать колоночный профайлинг, поскольку он важен для ряда юзеров.
Грабли №2: коннекторы «не из коробки». Документация DataHub местами есть, а местами «тут должен быть текст». Когда писали свой ingestion для одной из внутренних систем, половину API приходилось буквально раскапывать в исходниках.
Грабли №3: поиск «похудел» после миграции. Наши пользователи привыкли к режиму «пишешь public. — и сразу видишь public.orders». DataHub ранжирует объекты иначе, и первые пару недель люди реально думали, что таблицы «пропали».
После этого стало понятно: само развёртывание — это только прогрев. Настоящая работа начинается, когда люди приходят в систему жить, а не смотреть демо.
Как мы стабилизировали ingestion и не утонули в метаданных
Когда мы поняли, что «оно работает» ≠ «оно тянет прод», начался тюнинг.
Первое решение было почти терапевтическим: мы отключили колоночный профайлинг и оставили только табличный. Это был тот случай, когда «выключить фичу» даёт больше пользы, чем её «оптимизировать». Вздохнули все — и DataHub, и мы.
Второе — мы перестали бороться с ограничениями DataHub в плане ограничений ingestion и часть метаданных продолжаем обогащать собственными пайплайнами. Встроенная магия работает хорошо до определённого масштаба, дальше нужен ремесленный напильник.
Далее — Kubernetes. Мы развернули DataHub с автоскейлингом и наконец перестали думать, «а не задохнёмся ли мы завтра». Спойлер: без автоскейлинга — задохнулись бы.
И наконец, осознание: DataPortal не надо выключать. Его надо превратить из «отдельного каталога» в «партнёра» DataHub. По факту, DataHub стал бэкендом, а DataPortal — тонким фронтом для бизнес-пользователей. И внезапно пазл сложился.
Почему мы оставили два инструмента — и это не костыль
Когда DataHub заработал в проде, у нас был соблазн: «ну всё, старый портал можно выключать». Но реальность быстро нас вернула на землю. DataPortal был уже не просто «инструментом» — он стал мышечной памятью команд.
А дальше произошёл интересный сдвиг: мы перестали думать «как заменить одно другим» и начали думать «какую задачу закрывает каждый слой». В итоге получилась двухуровневая архитектура, которая решает разные типы сценариев без компромиссов.
Вот как это выглядит вживую:
Сценарий |
DataPortal |
DataHub |
Найти таблицу/витрину и понять, можно ли её использовать |
✅ мгновенно |
⚙️ можно, но дольше |
Посмотреть lineage и цепочку преобразований |
❌ нет |
✅ это его стихия |
Узнать владельца/зону ответственности |
✅ (через синхронизацию) |
✅ первоисточник |
Автоматизировать обновления / описания через API |
❌ |
✅ |
Быстро «пригласить в контекст» аналитика или продакта |
✅ всё на одной странице |
❌ слишком технично |
Типичные запросы наших аналитиков в DataHub: «если я удалю эту витрину, то кто пострадает?», «кто владелец этого дашборда?», «сколько у него просмотров?», «из какого продукта мы забираем данные для этого дашборда?»
Типичные запросы наших бизнес-юзеров в DataPortal: «какие дата-продукты у нас есть?», «какие дашборды популярны?», «какая основная информация есть по этой странице?»
Проще говоря: DataPortal — это быстрый интерфейс «узнать и принять решение», DataHub — инженерное ядро правды о данных и связях между ними.
Что реально изменилось после внедрения (помимо красивых графов)
Lineage как «рентген данных»: теперь видно, что откуда течёт. Раньше вопрос «а откуда эти цифры?» означал SQL‑археологию и поиски владельца в чатах. Теперь — одна кнопка и наглядный граф: от внешнего API до BI-дашборда. Самый частый фидбэк от инженеров был в духе «почему мы не сделали это два года назад?».
Observability без шаманства: если ingestion умер — мы знаем об этом сразу. В DataPortal падение коннектора могло обнаружиться через неделю, когда кто-то пожалуется. В DataHub ingestion стал наблюдаемым процессом: статусы, алерты, логика повторных запусков. Мы перестали «угадывать состояние системы по настроению пайплайна».
API-first вместо ручных правок: метаданные теперь живут сами. Описания намного меньше редактируются вручную в интерфейсе. Пришёл новый owner — он подтянулся через ingestion. Таблица устарела — автоматом получает deprecated. Меньше человеческого фактора, больше воспроизводимости.
Shift-left: качество начали закладывать до инцидентов. Когда у команды есть прозрачность и цепочка зависимостей, они автоматически думают на шаг вперёд. Проверки начинают появляться «в момент появления данных», а не когда аналитик уже пожаловался.
Самый нетехнический эффект, но самый ценный: ownership. У каждой таблицы появился реальный владелец, которого легко найти. Не «коллективный соседний чат», а конкретный человек/команда. Это резко сократило время до ответа и, что важнее, сняло эффект «ничейности». В этот момент мы поняли, что каталог — это не про метаданные, а про ответственность.
Наконец, мы в полной мере осознали объём наших данных и их источников — просто потому, что это теперь хорошо видно.
Как мы добивались adoption: инструмент сам себя не продаст
Неожиданным оказалось то, что техническая часть внедрения была проще, чем человеческая. DataHub стоял, lineage строился, ingestion летал — а люди продолжали жить в DataPortal. И не потому что «так удобнее», а потому что привычка всегда побеждает фичи.
Первые недели были похожи на мини-революцию. Я в какой-то момент понял, что стал не Data Quality Lead, а евангелистом DataHub: демо, ответы в чатах, «а покажи ещё раз, где теперь владельцы», «а почему поиск так странно работает».
Что реально сработало:
внутренние «чемпионы» — не формальные «амбассадоры», а реальные инженеры и аналитики, которые первыми нашли пользу и начали показывать другим;
короткие видео-демо по 2–3 минуты, не длинные лекции — ровно под конкретный сценарий («как понять, кто владелец», «где искать lineage»);
публичные кейсы побед: мы начали отмечать случаи, когда DataHub реально спас время/нервы (сломанную витрину нашли за 10 минут вместо дня расследований).
А что не сработало? «Методички». Их тупо никто не читал. Живые примеры били любые внутренние инструкции.
Когда adoption пошёл вверх, стало видно главное: DataHub — это не «второй каталог», это новый способ думать о данных. Появилась новая привычка — прежде чем задать вопрос в чат, сначала открыть DataHub. Теперь вместо «Где лежат эти данные?» чаще спрашивают «Кто владелец этого домена?» или «Как часто обновляется эта таблица?». Фокус сместился с поиска данных на понимание их контекста — именно этого мы и добивались.
Как мы измеряем успех: если инструмент не используют — его нет
Мы решили не усложнять метрики и выбрали главный показатель — MAU (Monthly Active Users). Если люди возвращаются в DataHub, значит, платформа действительно решает их задачи.
Вокруг MAU строим дополнительную аналитику: считаем количество подключённых источников, измеряем скорость загрузки главной страницы, анализируем востребованные фичи и регулярно собираем обратную связь через короткие опросы в интерфейсе.
За последние месяцы мы вырастили MAU с 60 до 150, цель на ближайший квартал — +30%.
Рост достигаем, расширяя аудиторию: подключаем не только аналитиков, но и разработчиков, архитекторов, владельцев сервисов. Каждое новое подключение — не просто источник, а новая точка на общей карте данных. И если DataPortal показывал 5000 объектов из одного источника, то в DataHub у нас — 40 000+ объектов из 14 видов источников.
Что дальше: DataHub как центр Data Observability и AI Governance
Стартовали мы с простой цели — навести порядок в метаданных. Теперь понимаем: это была лишь подготовка к следующему этапу. DataHub стал не просто каталогом, а центром наблюдаемости данных: здесь видно, как данные появляются, живут и используются — от источника до аналитики и ML-моделей.
Сегодня мы уже используем DataHub для мониторинга ingestion-процессов, обновлений и статуса метаданных. Следующий шаг — объединить наблюдаемость данных и метаданных:
интегрировать результаты data quality-тестов прямо в карточки объектов;
визуализировать SLA на уровне доменов и витрин;
добавить алерты о деградации качества;
построить дашборды, показывающие здоровье не только отдельных таблиц, но и целых доменов.
DataHub становится панелью мониторинга всей data-экосистемы: видно не только «что есть», но и «насколько это живое».
Параллельно компания активно внедряет AI-решения — от рекомендательных систем до внутренних ассистентов. Чем больше моделей, тем актуальнее принцип Garbage In, Garbage Out: если данные или метаданные некачественные, никакая модель не спасёт. Поэтому связка Data Portal/DataHub — не просто каталоги, а фундамент AI Governance. Она позволяет контролировать происхождение данных, их владельцев, уровень доверия и ограничения. Мы видим, какие источники используются в моделях, как часто обновляются, кто отвечает за корректность. Так выстраивается прозрачная цепочка ответственности — от данных до принимаемых на их основе решений.
В техническом плане планируем:
улучшить архитектуру вокруг DataHub: использовать ресурсы компании для стабилизации DataHub вместо ресурсов самого инструмента;
вынести часть injections из DataHub на AirFlow; запускать профайлинг асинхронно, чтобы не блокировать ingestion;
развивать API и систему тегов, чтобы DataHub мог автоматически интегрироваться с CI/CD, мониторингом, ML Feature Store, AI-агентами.
Это движение от каталога к платформе данных, где всё связано и управляется через метаданные.
Но главный результат — не в технологиях. В процессе мы кристаллизировали data-культуру: привычку документировать, делиться знаниями, видеть взаимосвязи.
А как у вас в компании работают с метаданными? Какие решения и подходы применяете? Обсудим в комментах!
***