Введение и проблематика

В первой части мы описали архитектуру Озера данных информационной безопасности (Security Data Lake, SDL): как разрозненные источники данных ИБ были объединены в единую аналитическую платформу на базе Kafka, Airflow и ClickHouse. После запуска SDL инфраструктура данных ИБ заработала: Airflow собирает данные из источников, Kafka передает данные между сервисами, ClickHouse хранит слои от сырых до витрин, Superset визуализирует данные. Данных в озере становится много, как таблиц, так и колонок, откуда они появились, кто их потребитель с течением времени становится сложно определить. Чтобы озеро данных не превратилось в болото, необходимо работать с метаданными всех объектов хранилища: обеспечить контроль схемы данных, учесть версионность, понимать откуда и какие данные извлекаются, и кто их конечный потребитель. Но это непростая задача.

Ключевые проблемы

• Непрозрачное происхождение данных. Знание о том, откуда берётся таблица, хранится в голове разработчика или закопано в коде DAG-а. При изменении схемы в источнике невозможно быстро оценить на какие объекты хранилища это может повлиять.
• Отсутствие ответственных. Таблиц становится всё больше. Не понятно кто владелец каждой, а кто-то принимает решение при об изменениях?
• Нет единого стандарта DAG (Directed Acyclic Graph). Каждый DAG создавался под конкретную задачу. Нет единой модели описания: у одних явно указаны источники, у других логика трансформации скрыта в Python-коде.
• Сложный поиск информации. Нет описания таблиц и колонок данных. Необходимо найти таблицу. Где искать? Что значит каждое поле? Единого ответа нет - нужно спрашивать у команды.

Именно здесь возникает потребность в DataOps-подходе: принципах управляемости, автоматизации и воспроизводимости, применённых к данным. Мы решили стандартизировать потоки и внедрили каталог данных.

Место OpenMetadata в архитектуре SDL

При выборе каталога данных мы протестировали множество решений, но остановились на OpenMetadata.

OpenMetadata не заменяет ни один из уже работающих компонентов SDL и не встраивается в цепочку движения данных. Это платформа-наблюдатель: она подключается к Airflow, ClickHouse, Kafka и BI-инструментам, читает их метаданные и выстраивает единую карту данных.

Ключевой принцип

OpenMetadata не участвует в движении данных — она описывает его. Данные по-прежнему идут по ETL цепочке: Источники → Airflow → ClickHouse → BI. OpenMetadata наблюдает за этой цепочкой сверху: читает метаданные каждого компонента, фиксирует схемы, связи и историю изменений, предоставляя единый каталог.

Архитектура

Технологический стек

Стандартизация Airflow DAG

Интеграция с OpenMetadata начинается не с подключения коннектора - она начинается со стандартизации самих пайплайнов. Без единой структуры DAG-ов автоматическое извлечение метаданных невозможно: OpenMetadata не умеет анализировать произвольный Python-код в поисках источников и приёмников данных.

Решение: Собственный стандарт DAG

Нами был разработан и внедрён обязательный стандарт создания DAG. Каждый пайплайн следует единой структуре и включает явно объявленные параметры «источник» и «назначение»

Помимо обязательных полей, каждый DAG содержит:

• Единую структуру и нотацию именования функций;
• Стандартизированную обработку ошибок и повторных операций;
• Контроль изменений схемы источника;
• Автоматическое формирование и обновление метаданных в каталоге данных;
• Журналирование всех событий и оповещения при сбоях.

Почему это важно для OpenMetadata

Стандартизированные параметры «источник» и «назначение» - это основа автоматической регистрации потоков данных. Благодаря единой структуре каждый DAG превращается в декларативное описание: откуда данные поступают и куда записываются. На этой основе OpenMetadata формирует каталог.

Интеграция с OpenMetadata

После стандартизации DAG интеграция с OpenMetadata становится логичным следующим шагом. Унифицированные параметры «источник» и «назначение» позволяют автоматически регистрировать потоки данных и связывать их с конкретными таблицами и сервисами в каталоге.

Происхождение данных (Data Lineage)

OpenMetadata собирает метаданные со всех слоев SDL и строит сквозную карту объектов - не участвуя в движении данных, а читая информацию о нём. Происхождение таблиц формируется на этапе создания, когда в ClickHouse создаётся новая таблица. OpenMetadata автоматически фиксирует ее схему и регистрирует связи с источниками.

DAG-и встраиваются в графовую модель благодаря стандартизированным параметрам. В результате появляется возможность проследить путь данных от момента их создания до использования в отчётах: от исходной системы через Kafka и слои ClickHouse - до финальных графических визуализаций.

Метаданные и управление

• Потоки данных. Каждый Airflow DAG регистрируется как объект с источниками и точками назначения. Статус последнего запуска, расписание, связанные таблицы - всё в одном месте.
• Таблицы ClickHouse. Все слои видны в каталоге. Схема таблицы, описания колонок, теги, классификации чувствительных данных.
• Визуализация. Grafana и Superset подключаются как сервисы. Каждая графическая визуализация имеет путь происхождения данных до таблиц-источников - видно, на каких данных она построена.
• Владельцы. Каждый объект - таблица, топик, график - имеет назначенного ответственного. При необходимости сразу известно, кто принимает решение.

Построение каталога данных SDL

По мере накопления метаданных OpenMetadata превращается в централизованный каталог всей экосистемы SDL. В нём регистрируются не просто технические объекты, но и их семантика, бизнес-контекст и связи с процессами ИБ.

Обнаружение данных

Аналитик ИБ ищет таблицу с данными об уязвимостях. Вместо обращения к разработчику он открывает каталог, находит таблицу, видит её схему, происхождение и знает, какой DAG её формирует. Время от вопроса до ответа - секунды.

Контроль качества данных

OpenMetadata позволяет настраивать проверки качества прямо на уровне каталога: уникальность идентификаторов, отсутствие null в критичных полях, диапазоны допустимых значений. Нарушения фиксируются и уведомления отправляются владельцам таблиц.

Классификация и теги

Колонки, содержащие персональные данные или учётные записи, помечаются тегами. Это основа для управления доступом и соответствия требованиям регулятора. Каталог перестаёт быть техническим реестром и становится инструментом Data Governance.

Управление изменениями

При изменении схемы источника Airflow фиксирует версию схемы и обновляет метаданные в каталоге. Через OpenMetadata сразу видно: какие таблицы и пайплайны могут быть затронуты, кто их владелец и кого нужно уведомить.

SDL + OpenMetadata: единая карта данных

Интеграция превращает SDL из набора технических компонентов в управляемую платформу, где каждый объект данных от топика Kafka до итогового дашборда - имеет известное происхождение, ответственного и описание. Данные становятся не просто доступными, но и понятными - как инженерам, так и аналитикам ИБ.

Выводы и результаты

Внедрение OpenMetadata изменило не только то, как команда находит данные, но и то, как она управляет инфраструктурой в целом.

Общий вывод

Эволюция от стандартизации DAG-ов к полноценному каталогу данных демонстрирует переход от изолированного оркестратора задач к управляемой DataOps-платформе. Стандартизированные параметры обеспечивают формализованное описание потоков данных на уровне пайплайнов, а фиксация происхождения таблиц создаёт устойчивую основу для достоверной карты данных.

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