О каталогах Iceberg
Каталоги данных в последнее время оказались в центре внимания индустрии данных, особенно на фоне ажиотажа вокруг Iceberg и управления данными для AI. Этот термин стал чрезмерно употребляемым и теперь обозначает очень широкий набор инструментов. Поэтому, прежде чем углубляться в каталоги Iceberg, давайте начнём с самого начала.
О каталогах данных
Короткий ответ — это данные о ваших данных.
Каталог данных — это централизованный слой управления метаданными, который позволяет пользователям и инструментам находить, понимать и эффективно управлять данными. В своей основе он организует метаданные о наборах данных, включая информацию о схемах, lineage (происхождении данных), правах доступа и бизнес-контексте, помогая как техническим, так и нетехническим пользователям работать с данными более эффективно.
История каталогов данных
Каталоги данных — не новая концепция.
Словари данных (data dictionaries) были самыми ранними формами каталогов и являлись частью реляционных баз данных. Эти словари хранили метаданные на уровне схемы (например, имена таблиц). Они не предназначались для бизнес-пользователей и требовали значительного ручного сопровождения.
Перенесёмся в начало 2010-х годов, когда индустрия начала активно осваивать Hadoop и data lake. Hive Metastore стал стандартом для управления метаданными схем в экосистемах Hadoop. Однако он по-прежнему был ограничен структурными метаданными, так как в нём отсутствовали lineage, возможности поиска и бизнес-контекст.
Далее появилось поколение open source технических каталогов, таких как Iceberg, Polaris и Unity Catalog, а также бизнес-каталоги, например Atlan. В эпоху AI как никогда важно иметь каталоги, которые могут поддерживать как структурные метаданные, так и бизнес-логику.
Для команд, работающих с данными, каталоги обычно делятся на две категории:
-
Технические каталоги данных: фокусируются на структурных метаданных, включая информацию о таблицах и колонках, типах данных, местах хранения (что особенно важно для open table formats) и правах доступа. Обычно они либо «встроены» (не требуют настройки), либо управляются отдельно и интегрируются в платформу данных. Такие каталоги используются вычислительными движками для поиска и взаимодействия с данными.
-
Бизнес-каталоги данных: ориентированы на более широкий круг пользователей в организации (BI-аналитиков, продакт-менеджеров и т.д.). Они обогащают технические метаданные бизнес-контекстом в виде метрик, бизнес-определений, индикаторов качества данных, паттернов использования и информации о владельцах данных.
Почему каталоги данных важны для dbt
Для пользователей dbt, работающих в архитектуре lakehouse или с несколькими вычислительными движками, понимание и использование каталогов данных критически важно по нескольким причинам, включая:
-
Обнаружение таблиц: модели dbt регистрируются в каталогах. Понимание структуры каталога необходимо для управления наборами данных и для того, чтобы dbt знал, что уже создано и где это находится.
-
Междвижковая совместимость: каталоги Iceberg позволяют наборам данных, созданным одним вычислительным движком, быть прочитанными другим. Именно на этом основана кросс-платформенная функциональность dbt Mesh.
О каталогах Iceberg
Apache Iceberg — это open table format, разработанный для аналитических наборов данных петабайтного масштаба. Он поддерживает эволюцию схем, time travel, pruning партиций и транзакционные операции в распределённых вычислительных движках.
Каталоги Iceberg — это критически важный слой абстракции, который сопоставляет логические имена таблиц с расположением их метаданных и предоставляет механизм пространств имён. Они отделяют вычислительные движки от физического расположения данных, позволяя нескольким инструментам последовательно и согласованно работать с одним и тем же набором данных.
Существует несколько типов каталогов Iceberg:
- Iceberg REST
- Iceberg REST compatible
- Delta/Iceberg Hybrid*
Гибридные каталоги поддерживают хранение дублирующихся метаданных таблиц в форматах Iceberg и Delta Lake, что позволяет реализовывать сценарии, при которых, например, Iceberg-движок читает данные из Delta Lake или наоборот. При этом будут существовать ограничения, зависящие от конкретной реализации платформы.
Как dbt работает с каталогами Iceberg
dbt взаимодействует с каталогами Iceberg через адаптеры двумя способами:
-
Материализация моделей: когда dbt материализует модель в виде таблицы или представления, при объявленной интеграции с каталогом соответствующий адаптер (Spark, Trino, Snowflake и т.д.) создаёт запись таблицы Iceberg в указанном каталоге — как встроенном, так и внешнем.
-
Интеграция с каталогом: в рамках первоначального релиза нового фреймворка каталогов пользователи могут указывать, в какой каталог будут записываться метаданные таблицы.
Почему это важно? dbt использует и создаёт значительное количество метаданных. Перед каждым запуском dbt необходимо знать, что уже существует, чтобы корректно скомпилировать код (например, разрешить {{ref()}} в фактическое имя таблицы) и определить, где материализовать объект. Поддерживая эти два механизма, dbt может гибко адаптироваться в зависимости от окружения, логики кода и сценариев использования, определённых в вашем dbt-проекте.
Ограничения
Чтобы вычислительный движок имел доступ к каталогу, необходимо корректно настроить сетевое взаимодействие и права доступа. Это означает, что если вы используете X warehouse с Y catalog, но хотите читать Y catalog из Z warehouse, необходимо убедиться, что Z warehouse может подключаться к Y catalog. Если включены IP-ограничения, их нужно устранить — либо убрав allowlisting (возможно только в том случае, если warehouse поддерживает статические IP-адреса), либо настроив такие механизмы, как Privatelink, для обеспечения доступа.
