О каталогах Iceberg
Технический каталог данных — это уровень управления метаданными, который позволяет пользователям и инструментам программно обнаруживать, изучать и контролировать ресурсы данных, доступные на различных платформах данных и в различных движках выполнения запросов.
История развития
В начале 2010-х годов, с появлением Hadoop и озёр данных, Hive Metastore стал стандартом для управления метаданными схем в экосистемах Hadoop. Хотя Hive Metastore эффективно поддерживал первые распределённые движки выполнения запросов с разделением вычислений и хранения, такие как Apache Spark и Trino, он ограничен в типах структурных метаданных, с которыми может работать, и в целом медленнее и дороже современных технических каталогов.
В последние годы появление стандарта Iceberg и его широкое принятие привели к развитию существующих каталогов данных (таких как Unity Catalog) и созданию новых каталогов с открытым исходным кодом (включая Polaris и Lakekeeper).
Важно отметить, что технические каталоги данных и бизнес-каталоги решают разные задачи, хотя и те и другие полезны командам по работе с данными:
-
Технические каталоги данных: Сосредоточены на структурных метаданных, включая такие сведения о данных, как имена таблиц и столбцов, типы данных, расположение хранилищ (что особенно важно для открытых форматов таблиц) и правила управления доступом. Они могут быть встроены в существующую платформу данных и не требовать настройки — как Databricks Unity Catalog или Snowflake Horizon Catalog — либо управляться отдельно и интегрироваться с каждым движком выполнения запросов. Эти движки используют каталог для поиска, чтения и записи данных.
-
Бизнес-каталоги данных: Предназначены для более широкого круга пользователей организации (например, BI-аналитиков и менеджеров продуктов). Они дополняют технические метаданные бизнес-контекстом: метриками, определениями бизнес-понятий, показателями качества данных, сведениями о характере использования и владельцах данных.
Почему каталоги данных важны для dbt
Для пользователей dbt, работающих с архитектурой lakehouse или архитектурой с несколькими движками, каталоги данных могут решать две задачи:
-
Обнаружение таблиц: Модели dbt материализуются в открытом формате таблиц (часто Iceberg) и регистрируются в каталоге. Понимание структуры каталога критически важно для управления наборами данных и предоставления dbt сведений о том, что уже создано и где находится.
-
Совместимость между движками: Каталоги Iceberg позволяют читать наборы данных, созданные одним вычислительным движком, с помощью другого, без репликации. Это основа кроссплатформенного dbt Mesh.
Без каталога метаданные каждой таблицы Iceberg необходимо регистрировать в движке выполнения запросов отдельно, что требует множества дополнительных запросов create iceberg table и alter ... refresh. При использовании каталога метаданные каждой таблицы регистрируются и обновляются автоматически, а сведения обо всех таблицах доступны через единую конечную точку.
За последний год поставщики платформ данных начали добавлять поддержку «связывания» или «федерации» каталогов — механизма, при котором платформа данных управляет синхронизацией метаданных между внешними каталогами данных и собственным управляемым каталогом данных. Это означает, что таблица Iceberg, записанная одним движком выполнения запросов в один каталог, автоматически становится доступной для чтения другому движку. См.: базы данных Snowflake, связанные с каталогом, федерация каталогов Databricks, федерация каталогов AWS Glue, федерация каталогов BigQuery.
Как dbt работает с каталогами Iceberg
dbt использует каталоги Iceberg, определённые в catalogs.yml, чтобы:
-
Материализовывать модели: Когда dbt материализует модель в виде таблицы или представления, при наличии объявленной интеграции с каталогом используемый адаптер (например, Spark, Trino или Snowflake) создаёт запись о таблице Iceberg в указанном каталоге — встроенном или внешнем.
-
Разрешать ссылки: Когда dbt читает модель, материализованную в каталоге, он использует «физическое» расположение, определённое активным адаптером (новая спецификация) или интеграцией записи (старая спецификация). Это позволяет ссылаться на модель (таблицу Iceberg) и читать её в одном движке выполнения запросов, даже если изначально она была материализована (записана) другим движком, при условии, что оба движка интегрированы с одним и тем же каталогом.
Ограничения
За последние несколько лет многие платформы данных, движки выполнения запросов и каталоги данных существенно расширили поддержку стандартов Iceberg — однако это по-прежнему не гарантирует совместимость любого хранилища данных с любым каталогом данных.
Даже если такая поддержка есть, она может быть ограниченной. Например, большинство каталогов Iceberg поддерживают только таблицы (материализации table + incremental в dbt), но не представления. Они могут не поддерживать атомарные операторы create table as, а значит, dbt приходится обновлять таблицы с помощью нескольких операторов без гарантий ACID.
Benoit (специалист по взаимодействию с разработчиками в dbt Labs) создал полезную визуализацию (также доступную в виде увлекательной интерактивной игры), которая показывает текущее состояние совместимости хранилищ данных и каталогов. (Заметили неточность или устаревшую информацию? Создайте issue или PR в репозитории.)
