DataHub + MCP: подключаем ИИ к управлению метаданными

Чем больше данных в компании, тем критичнее становится понимание того, где именно они хранятся и как изменяются при обновлениях. В «Островке» мы пользуемся дата-каталогами, но в какой-то момент решили пойти чуть дальше: объединили DataHub с генеративным ИИ через Model Context Protocol, чтобы сделать работу с метаданными более интерактивной и быстрой.

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

Под катом делимся опытом внедрения связки DataHub + MCP, рассказываем об архитектуре решения и показываем реальные примеры, как ИИ становится практическим помощником в управлении метаданными.

Меня зовут Алексей Чумагин, я Data Quality & Governance Tech Lead в Островке. В одном из прошлых материалов я уже рассказывал, как DataHub помогает ориентироваться в большом и постоянно растущем ландшафте данных: датасетах, пайплайнах, дашбордах и владельцах. Сегодня хочу сделать следующий логичный шаг и показать, как этот же DataHub начинает работать в паре с генеративным ИИ — и почему это заметно меняет сам подход к работе с метаданными.

Если упростить идею до одного предложения, она звучит так: вместо того чтобы вручную искать таблицу, открывать lineage, сопоставлять зависимости и гадать, что именно «упадёт» после изменений, можно просто задать вопрос ИИ. Например: «Если я удалю эту таблицу, кто пострадает?» — и получить понятный, аргументированный ответ.

Звучит впечатляюще, но на практике за этим стоит вполне приземлённая архитектура.

Проблема интеграций: почему «просто подключить ИИ»  — не так просто

Почти в любой компании сегодня есть несколько источников данных и несколько LLM-моделей. С одной стороны — базы данных (Postgres, ClickHouse), каталоги метаданных (DataHub), документы в Google Drive, корпоративные чаты. С другой — модели: GPT, Claude, локальные LLM.

Если пытаться соединять всё это напрямую, очень быстро возникает «вавилонская башня» интеграций. Чтобы модель могла работать с новым источником, нужно писать отдельный коннектор, поддерживать его, обновлять при изменениях API. Подключили Claude к Postgres — отлично. Теперь нужен GPT к DataHub — снова разработка. Это дорого, долго и плохо масштабируется.

В 2024 году Anthropic предложили альтернативный подход — Model Context Protocol (MCP). Он меняет саму логику интеграций: вместо множества «точка‑точка» появляется схема «один сервер — много клиентов». Если источник данных умеет говорить по MCP, любая модель, поддерживающая протокол, может с ним работать без дополнительной разработки.

Как DataHub и MCP работают вместе

В нашей архитектуре получилось четыре ключевых компонента.

1. MCP-клиент — это интерфейс, через который пользователь общается с моделью. Это может быть Claude Desktop или Claude Code, Cherry Studio или корпоративный AI-чат.

2. MCP-сервер — промежуточный слой, который знает, как именно обращаться к DataHub и какие данные из него можно получить.

3. Сам DataHub — источник истины о данных: метаданные, lineage, описания, владельцы и документация.

4. LLM — «дирижёр» всей системы. Она читает описание доступных инструментов и сама решает, какие вызовы сделать, чтобы ответить на вопрос пользователя.

В итоге это похоже на работу с опытным коллегой: вы формулируете вопрос, а он при необходимости сам идёт «посмотреть в систему», уточняет детали и возвращается с выводами.

Что умеет DataHub MCP-сервер: с примером

MCP-сервер для DataHub предоставляет не один абстрактный метод, а полноценный набор действий. Через него можно:

•  искать сущности по фильтрам

•  получать детальную информацию по конкретному URN

• смотреть схему таблиц, связанные SQL-запросы и lineage — как upstream, так и downstream

Отдельно поддерживаются запросы для построения полных цепочек lineage между сущностями, что особенно полезно для impact analysis.

Фактически DataHub из «каталога для просмотра» превращается в API для расследований и анализа последствий изменений.

Рассмотрим живой пример с тем же impact analysis.

Типичная ситуация: вы дата-инженер и смотрите на таблицу public.booking, которую давно пора либо удалить, либо переписать.

Раньше сценарий выглядел примерно так: открыть DataHub, найти таблицу, вручную изучить lineage, прокликать зависимости, выписать downstream-таблицы и дашборды, затем написать владельцам и попытаться собрать общую картину. Даже если всё делать аккуратно, это легко превращается в часы работы.

С MCP процесс радикально упрощается. Вы просто задаёте вопрос в чате: «Если я удалю public.booking, кто расстроится?»

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

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

Пример ответа: 

По ощущениям это действительно похоже на разговор с тимлидом, который «и так всё знает». Экономятся часы времени, а ожидания пользователей от работы с метаданными начинают меняться.

Практика и грабли: как не навредить себе

Довольно быстро стало понятно, что MCP — это мощный инструмент, но обращаться с ним нужно аккуратно. Вот несколько правил, которые мы учитываем при каждой рабочей итерации. 

• MCP не предназначен для батч‑процессинга. Запросы вроде «перечисли все 5000 таблиц в DataHub и их владельцев» приведут к огромному расходу токенов, медленной работе и высоким затратам. Гораздо лучше формулировать вопросы в аналитическом ключе: «Дай краткую сводку по домену Finance Analytics: ключевые датасеты и ответственные команды».

• Используем жёсткие системные промпты. Модель явно инструктируется всегда опираться на инструменты DataHub для фактологии и не полагаться на догадки. Любое утверждение должно быть подтверждено данными из каталога.

• Проверка всё ещё необходима. Даже с MCP модели иногда ошибаются: могут неверно интерпретировать названия таблиц или сделать ложные выводы. Для критичных изменений мы всегда перепроверяем результаты.

• Отдельный вопрос — выбор модели. Для сложных аналитических рассуждений лучше подходят модели уровня GPT‑5.2 или Claude 4.5 Sonnet. На практике мы выяснили , что Claude 4.5 лучше справляется с вызовом тулов, поэтому быстрее приходит к ответу. Для простых вопросов можно использовать более лёгкие варианты, но качество выводов и генерации SQL при этом может пострадать.

Масштабируем инструмент на всю компанию: Remote MCP

Локальный запуск MCP-сервера через stdio отлично подходит для прототипирования и экспериментов. Но он плохо масштабируется на всю компанию: не каждый аналитик или менеджер готов устанавливать Python, клонировать репозиторий и настраивать окружение.

Поэтому следующим шагом стал переход к архитектуре Remote MCP. Вот как это реализовано.

1. Централизованный сервер. Мы развернули MCP-сервер DataHub на отдельной виртуальной машине внутри нашего контура и сделали его веб-сервисом с использованием Server-Sent Events.

2. Подключение в один клик. Продвинутые пользователи, использующие локальные клиенты (например, Claude Desktop, Claude Code или Cherry Studio), могут просто указать URL нашего сервера. Им больше не нужно ничего настраивать локально.

3. Интеграция с корпоративным чатом. Самое важное — мы интегрировали этот сервер в корпоративный AI-чат в режиме инструментов.

Для пользователя всё выглядит максимально просто. Любой сотрудник заходит в чат, выбирает модель и задаёт вопрос о данных. Ему не нужно знать, что такое MCP, токены или API. Инструменты DataHub подключены «из коробки», и модель сама решает, когда к ним обращаться. По сути, мы получили полноценный self-service data discovery.

Когда стандартного MCP уже мало: ReAct-агент

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

Так появился наш AI DataHub ReAct Agent — дополнительный «мозг» поверх MCP. Он работает по классической схеме ReAct: сначала анализирует вопрос и планирует действия, затем вызывает нужные инструменты, обрабатывает результаты и повторяет цикл до получения финального ответа.

Агент умеет:

• семантически ранжировать таблицы по релевантности

• строить расширенный lineage

• анализировать SQL и извлекать бизнес-логику

• корректно работать с русским языком, аббревиатурами и внутренними терминами

Для этого у него есть набор собственных аналитических инструментов (например, rank_tables_by_relevance, fetch_lineage, analyze_sql_code) и обёртки над MCP-методами DataHub (mcp_datahub_search, mcp_datahub_get_entity и т.д.).

Вот несколько реальных примеров того, ReAct-агент помогает нам в задачах (ответы приведены частично):

1. «Покажи lineage для таблицы analytics.extranet_availability» 

2. «Расскажи, как считается поле line_of_business в таблице sales_structure»

3. «Как собирается витрина, которая лежит под дашбордом “Why Not Selling”?»

Развиваем подход: Code Execution с MCP и другие улучшения

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

Одна из самых интересных новинок Anthropic — возможность code execution. Теперь модель может не просто вызывать инструменты, а писать код, который делает это за неё.

Например, если попросить построить график частоты обновлений таблиц домена Marketing за месяц, модель не будет тащить в контекст десятки мегабайт JSON. Вместо этого она напишет Python-скрипт, который в цикле вызовет search и get_entity, агрегирует данные локально и вернёт только итоговый результат.

Пока мы только экспериментируем с новинкой, но перспектива очевидна: в некоторых сценариях Code Execution позволяет сокращать расход токенов до 90%, что критично для сложных аналитических задач.

При этом оптимизация токенов — лишь часть картины. Дальше для нас важнее развивать саму связку DataHub и MPC. В 2026 мы планируем подключать несколько MCP-серверов одновременно (например, DataHub и Postgres), расширять возможности за счёт DDL и метрик качества данных и глубже вплетать ИИ в процессы планирования изменений. По сути, мы постепенно выходим за рамки экспериментов и движемся к инфраструктуре, способной закрывать более широкие сценарии внутри компании.

***

И уже сейчас DataHub для нас — гораздо больше, чем просто дата-каталог. В связке с Remote MCP, корпоративным чатом и code execution он работает как живой помощник: берёт на себя рутину, помогает инженерам быстрее понять картину целиком и увереннее принимать решения, не утопая в метаданных.

Онбординг новичков стал заметно проще, аналитики глубже погружаются в LLM-домен, а агенты начинают обмениваться знаниями через единый каталог. Конкретный недавний кейс: DataHub + MPC помог нашей BI-команде сэкономить, предположительно, недели работы, поскольку они автоматизировали нахождения корневых таблиц для каждого дашборда.

Экономический эффект пока скромный (мы в начале пути), но ощущение работы с передовой технологией — мотивирует. О том, куда придём в итоге, расскажу в будущих статьях!

TG-канал Ostrovok! Tech