Основы каталога данных

Введение

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

Что такое каталог данных

Каталог данных (Data Catalog) — это централизованный реестр метаданных организации с поиском, классификацией и социальными функциями. Каталог объединяет технические метаданные (схемы, lineage), бизнес-метаданные (описания, владельцы, теги) и операционные метаданные (свежесть, качество).

Каталог данных решает три задачи:

1. Data Discovery — найти нужные данные за минуты, а не недели
2. Data Understanding — понять контекст, владельца, качество, связи
3. Data Governance — контролировать классификацию, доступ, compliance

Архитектура каталога данных

Современный каталог данных состоит из четырёх слоёв:

Hands-On Lab: Catalog Lab

Practice these concepts with a real OpenMetadata instance and e-commerce dataset:

cd labs/catalog && cp .env.example .env && docker compose up -d

Open JupyterLab at http://localhost:18888 and complete Notebook 01: Catalog Exploration — navigate the OpenMetadata UI, set up a PostgreSQL connector, and discover table metadata.

Requirements: Docker Desktop with 6+ GB RAM allocated. See labs/catalog/README.md for full setup.

Ingestion: автоматический сбор метаданных

Каталог подключается к источникам данных через коннекторы (connectors):

# Пример: конфигурация коннектора для PostgreSQL
source:
  type: postgres
  config:
    host: "postgres.datatech.local"
    port: 5432
    database: "production"
    schema_filter: "public|analytics"
    include_views: true
    include_stored_procs: false
    profile_sample: 10   # профилирование 10% данных
schedule:
  cron: "0 3 * * *"      # ежедневно в 03:00

Коннектор собирает:

• Технические метаданные: таблицы, колонки, типы, индексы, foreign keys
• Операционные метаданные: row count, размер таблицы, статистика колонок
• Lineage (если доступен): зависимости между таблицами и моделями

Metadata Store: граф метаданных

Каталог хранит метаданные как граф: узлы (таблицы, колонки, дашборды, пользователи) и связи (owns, depends_on, derived_from, tagged_with). Графовая модель позволяет:

• Traversal: “покажи все таблицы, зависимые от raw_customers”
• Impact Analysis: “что сломается, если я изменю колонку email?”
• Discovery: “найди все PII-таблицы, которыми владеет customer-team”

Структура каталожной записи

Каждый data asset в каталоге описывается стандартной записью:

{
  "table": "orders",
  "schema": "public",
  "database": "production_postgresql",
  "description": "Customer orders with payment and shipping status",
  "owner": "order_management_team",
  "tags": ["transactional", "customer-facing", "pci-relevant"],
  "classification": "confidential",
  "columns": [
    {"name": "order_id", "type": "bigint", "description": "Unique order identifier", "pii": false},
    {"name": "customer_id", "type": "bigint", "description": "Reference to customer", "pii": false},
    {"name": "email", "type": "varchar", "description": "Customer email for order", "pii": true},
    {"name": "total_amount", "type": "decimal", "description": "Order total in RUB", "pii": false},
    {"name": "status", "type": "varchar", "description": "Order status", "pii": false},
    {"name": "created_at", "type": "timestamp", "description": "Order creation time", "pii": false}
  ],
  "freshness_sla_hours": 1,
  "quality_score": 0.94
}

Ключевые элементы записи:

• owner — команда или человек, ответственный за данные
• tags — классификационные метки для governance-политик
• classification — уровень конфиденциальности (public, internal, confidential, restricted)
• columns.pii — маркер персональных данных на уровне колонок
• freshness_sla_hours — SLA обновления для мониторинга
• quality_score — агрегированная оценка качества

OpenMetadata: каталог для DataTech

# docker-compose.yml (OpenMetadata 1.3.x)
services:
  openmetadata-server:
    image: openmetadata/server:1.3.4
    ports:
      - "8585:8585"
    environment:
      DB_HOST: mysql
      DB_PORT: 3306
    depends_on:
      - mysql
      - elasticsearch

  openmetadata-ingestion:
    image: openmetadata/ingestion:1.3.4
    depends_on:
      - openmetadata-server

  mysql:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: openmetadata_password

  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.16.3

Сценарий: DataTech vs FinSecure

Сценарий: DataTech Solutions (ДатаТех Солюшенз)

DataTech оценивает каталоги данных для своих 200+ таблиц в PostgreSQL и ClickHouse. Критерии:

• Бюджет: минимальный (нет отдельной статьи на governance-инструменты)
• Стек: PostgreSQL 15, ClickHouse 23.8, Airflow 2.7, dbt Core 1.7, Metabase 0.47
• Команда: 7 человек, нет выделенного администратора каталога

OpenMetadata выбран как оптимальный: open-source, поддерживает весь стек DataTech, развёрнется за 1 день.

Для сравнения: ФинСекьюр Банк

FinSecure (ФинСекьюр Банк) уже использует OpenMetadata 1.2, но каталогизировано только 40% датасетов. Основная проблема — Oracle 19c с 800+ таблицами: коннектор есть, но без бизнес-метаданных запись бесполезна. FinSecure выделяет 2 Data Stewards на курирование, но при 800 таблицах каждый должен описать 400 таблиц. Без приоритизации (Tier-1 таблицы первыми) процесс займёт годы.

Итоги

• Каталог данных объединяет технические, бизнес и операционные метаданные в единый поисковый интерфейс
• Архитектура: Sources -> Ingestion -> Metadata Store (graph) -> UI/API
• Каталожная запись включает: owner, tags, classification, PII-маркеры, SLA, quality score
• OpenMetadata — open-source каталог с встроенным glossary и 20+ коннекторами
• Техническая каталогизация — автоматическая, бизнес-метаданные — ручное курирование (bottleneck)

В следующем уроке мы рассмотрим Data Lineage (происхождение данных) — как отслеживать путь данных от источника до потребителя.