Графы знаний
Enterprise Knowledge Graphs
В 2012 году Google запустил Knowledge Graph с 500 млн сущностями - и за месяц поисковые запросы с ответами прямо на странице выросли на 30%. В 2023 году LinkedIn раскрыл, что DataHub управляет метаданными 200 000 датасетов внутри компании. Корпоративный граф знаний - это инфраструктура масштаба поиска.
- **JPMorgan Chase:** Knowledge graph объединяет данные клиентов из 20+ legacy систем - единый профиль клиента без ETL в единое хранилище
- **Airbnb:** Data Catalog на основе KG помогает 1000+ аналитикам и ML-инженерам находить нужные датасеты среди 20 000+ таблиц Hive
- **GDPR compliance:** column-level lineage позволяет банкам выполнять right-to-erasure запросы за часы вместо недель ручного аудита
Граф как интеграционный слой
JPMorgan Chase обслуживает 80 млн клиентов через 20+ устаревших систем - каждая хранит 'клиента' по-своему. Knowledge graph становится интеграционным слоем: сущности из разных источников связываются через owl:sameAs или кастомные предикаты эквивалентности. Граф не заменяет источники, а создаёт единый взгляд поверх них через виртуализацию или ETL.
Два паттерна интеграции: (1) Virtual KG - SPARQL федерирует запросы к источникам в реальном времени без копирования данных; (2) Materialized KG - ETL копирует данные в граф. Virtual - актуальнее, Materialized - быстрее для аналитики. Гибрид: горячие данные materialized, архив virtual.
В чём принципиальное отличие Virtual KG от Materialized KG при интеграции данных?
Master Data Management через граф
Master Data Management (MDM) - создание 'золотой записи' (golden record) для каждой бизнес-сущности: клиент, продукт, локация. Knowledge graph делает это элегантно: golden record - узел, все источниковые представления - связанные узлы через provenance-предикаты. Система понимает, какой атрибут взят из какого источника, и может разрешать конфликты по правилам.
Entity Resolution (ER) - автоматическое обнаружение, что два узла в графе - один объект. Методы: exact matching (email, ИНН), fuzzy matching (название компании через Jaro-Winkler), embedding similarity (векторное сходство описаний). ML-based ER (Dedupe, Zingg) работает на обучающих парах.
Что такое 'golden record' в контексте Master Data Management?
Enterprise Data Catalog
Data Catalog - граф метаданных: какие датасеты существуют, что они содержат, кто их владелец, как часто обновляются. Крупные компании хранят тысячи таблиц - без каталога аналитики тратят 30-40% времени на поиск нужных данных. Apache Atlas, DataHub, Amundsen - open-source решения на основе KG. Граф связывает таблицы, колонки, владельцев, SLA и downstream-зависимости.
DataHub от LinkedIn хранит метаданные как граф сущностей: Dataset -> Column -> Tag -> Owner -> Policy. Автоматическое обнаружение метаданных через коннекторы к Hive, Snowflake, dbt, Airflow. Граф позволяет отвечать на вопросы: 'Кто использует эту таблицу?', 'Какие датасеты содержат PII?'.
Почему Data Catalog реализуется как knowledge graph, а не как реляционная база метаданных?
Data Lineage: граф происхождения данных
Data Lineage отвечает на вопрос: 'Откуда взялись эти данные?' - и в обратную сторону: 'Что сломается, если изменить эту таблицу?' При обнаружении ошибки в источнике lineage граф позволяет за секунды найти все downstream ML-модели, дашборды и отчёты, которые использовали поражённые данные. Без него - ручной аудит на дни или недели.
Типы lineage: column-level lineage (какая колонка взята из какой колонки источника - нужен для GDPR audit), table-level lineage (какие таблицы использовались в ETL), job lineage (какой Airflow/Spark job трансформировал данные). dbt автоматически генерирует lineage из SQL-трансформаций.
Data lineage нужен только для debugging ошибок в данных
Lineage критичен для трёх сценариев: регуляторный compliance (GDPR, SOX), impact analysis перед изменением схемы, и автоматическое обнаружение деградации данных в downstream системах
Без lineage изменение типа колонки в источнике обнаруживается только когда ML-модель выдаёт неверные предсказания - через дни или недели. С lineage CI/CD может автоматически найти все downstream потребители изменённого датасета и запустить интеграционные тесты до деплоя
Чем column-level lineage принципиально важен для GDPR compliance?
Ключевые идеи
- **Интеграция:** owl:sameAs связывает одну сущность из разных источников; virtual vs materialized - tradeoff между актуальностью и скоростью
- **MDM через граф:** golden record как центральный узел, источниковые записи как периферия с provenance-предикатами и правилами приоритета
- **Lineage = страховка:** column-level lineage позволяет за секунды найти все downstream системы поражённых данных - критично для GDPR и impact analysis
Связанные темы
Enterprise Knowledge Graphs применяют фундаментальные концепции KG к корпоративным задачам:
- KG + LLM: RAG и Grounding — Data Catalog KG становится источником структурированного контекста для LLM-ассистентов аналитиков
- Онтологии и SPARQL — SPARQL - язык запросов для traversal lineage графа и построения impact analysis
Вопросы для размышления
- Virtual KG всегда возвращает актуальные данные, Materialized может отставать. В каких корпоративных сценариях staleness данных в MDM критична - а в каких приемлема ради производительности?
- Entity Resolution автоматически находит дубликаты, но иногда ошибается. Как бы организовали процесс работы с ложноположительными и ложноотрицательными совпадениями в MDM системе?
- Data lineage строится задним числом (post-hoc) из логов и метаданных. Каковы ограничения такого подхода для систем с ad-hoc SQL запросами - и как их преодолеть?