Всем привет! Меня зовут Саша Балов, я тимлид в DWH MAGNIT OMNI — бизнес-группе ритейлера «Магнит», которая отвечает за развитие омниканального опыта для клиентов.

Недавно ребята из Datalens проводили вебинар в честь выпуска Public API, в котором я принял участие. Эта статья — развернутая версия моего доклада об интеграции Datalens с OpenMetadata.

Что такое OpenMetadata

OpenMetadata умеет собирать технические и бизнес-метаданные из разных систем в единый каталог. Для BI-инструментов это особенно полезно: дашборды, чарты и датасеты перестают жить отдельно от остального ландшафта данных и становятся частью общего графа метаданных.

В «Магните» мы активно используем и OMD и DataLens, поэтому я сделал новый dashboard service и ingestion-коннектор для DataLens. В результате OpenMetadata научилась подтягивать из DataLens дашборды, чарты и датасеты, сохранять ссылки обратно в UI и строить lineage на уровне:

Dashboard -> Chart -> Dataset

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

В статье покажу:

  • что именно пришлось добавить в OpenMetadata;

  • как устроен ingestion для DataLens;

  • какие ограничения всплыли на реальном контуре;

  • что уже работает сейчас и куда это можно развивать дальше.

Зачем вообще тащить DataLens в OpenMetadata

Если BI-слой не описан в каталоге метаданных, он начинает жить в серой зоне: отдельно от таблиц, пайплайнов, владельцев и остального data landscape.

В моем случае цель была очень практической: сделать DataLens частью общего графа метаданных внутри OpenMetadata, чтобы BI-объекты можно было не только искать в каталоге, но и связывать с другими сущностями платформы.

Что хотелось получить в итоге:

  • dashboard service для Yandex DataLens;

  • ingestion дашбордов, чартов и датасетов;

  • source links обратно в DataLens UI;

  • lineage хотя бы до уровня Dashboard -> Chart -> Dataset.

Следующий уровень —

Dashboard -> Chart -> Dataset -> Table

— это уже другая задача, потому что там нужно отдельно восстанавливать связи датасетов с физическими таблицами.

Что пришлось добавить в OpenMetadata

Интеграция затронула сразу несколько слоев:

  • схему подключения DataLensConnection;

  • ingestion source для нового dashboard service;

  • RPC-клиент для API DataLens;

  • auth-логику под iamToken и serviceAccountJson;

  • UI-поля для настройки сервиса;

  • unit-тесты на connection, auth, client и metadata.

Ключевые точки в коде:

По сути, задача была не в том, чтобы «прикрутить пару ручек API», а в том, чтобы встроить DataLens в модель dashboard ingestion, с которой уже работает OpenMetadata.

Как устроен ingestion

Снаружи сценарий выглядит довольно просто:

  1. В OpenMetadata создается dashboard service типа DataLens.

  2. Коннектор ходит в API DataLens.

  3. Из API собираются дашборды, чарты, датасеты, collections и workbooks.

  4. В OpenMetadata создаются dashboard, chart и dashboard data model.

  5. Поверх этого строится lineage.

Но внутри DataLens не отдает весь граф одним запросом, поэтому ingestion собирает его по частям через последовательность вызовов API:

  • /getEntries

  • /getDashboard

  • /getEditorChart

  • /getQLChart

  • /getWizardChart

  • /getDataset

  • /getCollection

  • /getCollectionContent

  • /getWorkbooksList

  • /getWorkbook

  • /getEntriesRelations

В упрощенном виде маршрут такой:

  1. Получить список дашбордов.

  2. Дочитать детали каждого дашборда.

  3. Из виджетов извлечь chart ids.

  4. Дочитать чарты.

  5. Восстановить dataset ids.

  6. Дочитать датасеты.

  7. Отдельно пройти collections и workbooks, чтобы не потерять структуру проекта.

Именно этот обход и превращает набор API-ручек в полноценный ingestion-коннектор.

Что появилось в схеме подключения

Для DataLens пришлось добавить отдельную схему подключения DataLensConnection.

Помимо базовых параметров вроде:

  • organizationId

  • apiURL

  • hostPort

  • iamToken

  • serviceAccountJson

в ней появились и operational-поля:

  • requestDelaySeconds

  • rateLimitRetrySeconds

  • rateLimitMaxRetries

  • collectionNamePattern

  • onlyDashboardsInCollections

    Это важно по двум причинам.

    Во-первых, ingestion для BI-системы почти всегда упирается не только в маппинг сущностей, но и в способ обхода API на реальном объеме.

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

    То есть схема подключения здесь — это уже не только про авторизацию, но и про поведение ingestion в эксплуатации.

    Настройки подключения, которые появились из-за особенностей обхода и scoping
    Настройки подключения, которые появились из-за особенностей обхода и scoping

Что уже работает

После реализации коннектора DataLens появился в OpenMetadata как новый dashboard service, а ingestion стал подтягивать основные BI-сущности.

Сейчас рабочий результат такой:

  • DataLens регистрируется в OpenMetadata как источник дашбордов;

  • ingestion забирает дашборды, чарты и датасеты;

  • сохраняются source links обратно в DataLens UI;

  • строится lineage на уровне Dashboard -> Chart -> Dataset;

  • параметры обхода и ограничения вынесены в конфиг.

То есть это уже не proof of concept «на один объект», а рабочая интеграция, которую можно запускать на реальном контуре и развивать дальше.

Какие ограничения всплыли на практике

Основная сложность оказалась не в моделях OpenMetadata как таковых, а в том, что ingestion для DataLens состоит из длинной цепочки последовательных API-вызовов.

На небольшом объеме это почти незаметно. На большом контуре появляется эксплуатационная сторона вопроса: как часто можно ходить в API, как ограничить поверхность обхода, как переживать throttling и каким токеном вообще запускать сценарий.

Отсюда и появились operational-настройки в коннекторе. Они нужны, чтобы ingestion можно было адаптировать под конкретный контур.

Я специально не хочу превращать эту статью в хронику борьбы с отдельным rate-limit кейсом. Важнее другое: у интеграции быстро появляется эксплуатационная часть, и ее лучше закладывать в коннектор сразу, а не после первого запуска на реальном объеме.

Итоговый lineage для BI-слоя в OpenMetadata
Итоговый lineage для BI-слоя в OpenMetadata

Что можно взять из репозитория уже сейчас

В репозитории есть:

  • схема подключения;

  • ingestion source;

  • клиент для DataLens API;

  • auth-логика;

  • тесты.

То есть это уже материал не только для чтения, но и для повторного использования: можно смотреть реализацию, адаптировать под свой контур и развивать дальше.

Что дальше

Следующий логичный шаг — дотянуть lineage до Table, чтобы можно было идти от BI-объекта вниз до физического источника данных и использовать это уже для impact analysis.

Но даже в текущем виде интеграция уже закрывает полезный сценарий: DataLens перестает быть отдельным BI-островом и становится частью общего каталога метаданных в OpenMetadata.