Реализация слоя каталога

В этой главе рассматриваются

Определение требований к каталогу по результатам аудита
Роль слоя каталога в Apache Iceberg
Оценка реализаций каталогов Apache Iceberg
Применение спецификации REST Catalog ради совместимости
Выбор подходящего каталога для вашей организации

Мы разобрали базовые компоненты lakehouse на Apache Iceberg, включая хранение и приём данных. Теперь обратимся к слою каталога - неотъемлемой части любого развёртывания Iceberg. Слой хранения управляет физическими данными, слой приёма их преобразует и загружает, а каталог даёт метаданные и координацию, без которых вся система не сможет надёжно работать на масштабе.

Слой каталога - это место, где таблицы Iceberg регистрируются, отслеживаются и организуются. Он ведёт метаданные таблиц, управляет пространствами имён и служит точкой координации операций с данными. Выбор подходящего каталога - не только техническое, но и стратегическое решение. Он влияет на управление данными, совместимость, масштабируемость и интеграцию с более широкой экосистемой.

У каждой организации свои архитектурные ограничения, требования комплаенса и эксплуатационные цели. Эта глава начинается с разбора требований, которые должны направлять выбор каталога, на основе выводов, полученных в ходе аудита из главы 4. Затем мы изучим, как работает интерфейс каталога Iceberg, включая поддержку растущего числа реализаций: Apache Polaris, Nessie, AWS Glue Data Catalog, S3 Tables, каталога Dremio, Snowflake Open Catalog и других.

Мы также разберём спецификацию Apache Iceberg REST Catalog - недавнюю разработку, призванную унифицировать подключение движков и инструментов к сервисам каталогов. Наконец, мы пройдём по нескольким реалистичным сценариям принятия решений, чтобы увидеть, как разные возможности каталогов соотносятся с конкретными приоритетами организаций.

К концу этой главы вы будете знать, как выбрать и настроить каталог, отвечающий потребностям вашего lakehouse, и сможете уверенно адаптироваться по мере изменения этих потребностей.

7.1 Роль каталога в lakehouse на Apache Iceberg

Apache Iceberg обеспечивает надёжный параллельный доступ к аналитическим наборам данных через атомарную версионируемую модель метаданных. Каждое зафиксированное изменение таблицы - добавление данных, удаление строк или эволюция схемы - порождает новую версию метаданных таблицы, ссылающуюся на соответствующие файлы данных и вспомогательные файлы. Эти версии метаданных неизменяемы и образуют линейную историю состояний таблицы. Такое устройство позволяет пользователям запрашивать согласованные представления таблицы, совершать путешествия во времени и откатываться к более ранним версиям, не мешая параллельным читателям и писателям. Вместо традиционных блокировок баз данных Iceberg достигает этих гарантий через атомарную замену метаданных таблицы, что в сочетании с протоколами коммитов на уровне движка даёт основу для семантики ACID.

Каталог связывает эти версии метаданных в единую систему (см. рис. 7.1). Он выступает координационным слоем lakehouse, отслеживая таблицы Iceberg и определяя, какая версия метаданных представляет текущее состояние таблицы. В отличие от традиционных баз данных, где метаданные жёстко связаны с одним движком исполнения, Iceberg делегирует эту ответственность каталогу, позволяя множеству вычислительных движков согласованно и транзакционно обнаруживать, читать и обновлять состояние таблиц.

Рис. 7.1 Каталог позволяет инструментам, обращающимся к таблицам lakehouse, проверять права и находить соответствующие данные в озере.

Как показано на рис. 7.2, каталог управляет расположением таблиц, организует таблицы по пространствам имён и координирует транзакционные обновления всех объектов метаданных Iceberg, включая те, что не порождают новых снимков. Такое разделение хранения, вычислений и координации метаданных позволяет Iceberg масштабироваться между инструментами, средами и облаками, сохраняя совместимость.

Рис. 7.2 Каталог Apache Iceberg сопоставляет каждому имени таблицы расположение её последнего файла метаданных, который служит точкой входа для инструментов, начинающих сканирование и работу с таблицей.

Разберём конкретные обязанности каталога, отметим его место в архитектуре Iceberg и посмотрим, как движки опираются на него при разрешении таблиц, планировании запросов и выполнении обновлений. Понимание этих обязанностей необходимо перед сравнением реализаций каталогов: оно поможет прояснить, какие возможности критичны именно для вашего сценария.

7.1.1 Обязанности каталога

Каталог в Apache Iceberg служит авторитетным указателем всех метаданных таблиц. Файлы данных живут в облачном или распределённом хранилище, запросы выполняются движками вроде Spark, Flink или Trino, а каталог связывает всё воедино. Он позволяет движкам безопасно и согласованно находить, интерпретировать и изменять таблицы Iceberg.

Каталог решает четыре ключевые задачи:

Регистрация и обнаружение таблиц - каталог отслеживает все зарегистрированные таблицы Iceberg в заданном пространстве имён. Когда пользователь обращается к таблице, движок запрашивает у каталога преобразование имени таблицы в расположение метаданных. Это позволяет множеству движков использовать общий каталог таблиц, обеспечивая согласованный доступ в пакетных и потоковых задачах.
Управление расположением метаданных - каждая таблица Iceberg представлена набором объектов метаданных: определениями схемы, спецификациями партиционирования, манифестами и ссылками на снимки. Вместо опоры на единственный фиксированный корень метаданных каталог выступает арбитром того, какие объекты метаданных связаны с данным идентификатором таблицы в каждый момент времени, транзакционно обновляя эту связь при коммитах. Такая косвенность обеспечивает версионируемую историю таблиц Iceberg и поддерживает путешествия во времени и откат. По мере развития реализаций каталогов, особенно на основе REST, координация состояния таблицы всё больше становится ответственностью самого каталога, а не транзакционной записи единственного файла metadata.json.
Организация пространств имён - каталоги группируют таблицы по пространствам имён, которые часто отражают организационные или предметные границы. Например, таблица может быть зарегистрирована как analytics.marketing.sales_data. Эта иерархия упрощает поиск таблиц и контроль доступа, особенно в больших средах с сотнями и тысячами таблиц.
Координация транзакций - при операциях записи Iceberg использует оптимистичную модель конкурентного доступа, координируемую каталогом, как показано на рис. 7.3. Операция записи подготавливает предлагаемый набор изменений метаданных, представляющий новое состояние таблицы, и передаёт его каталогу в рамках транзакционного коммита. Каталог проверяет, что состояние таблицы не было конфликтующим образом изменено другой параллельной операцией, прежде чем принять обновление. При обнаружении конфликта коммит отклоняется, и движок должен повторить попытку с актуальным состоянием таблицы. Такая координация через каталог гарантирует, что параллельные писатели не смогут повредить метаданные таблицы, независимо от того, опирается ли реализация каталога на файловые метаданные, реляционное хранилище или REST-сервисы.

Рис. 7.3 Оптимистичные коммиты позволяют движкам записать данные и метаданные, а затем определить успешность коммита, проверив своё место в последовательности коммитов в метаданных до и после записи файлов и фиксации. Если предполагаемый порядковый номер изменился между двумя проверками, значит, прошла другая транзакция и текущую нужно повторить.

Некоторые реализации каталогов предлагают и дополнительные возможности - журналирование аудита или историю версий. Но именно эти четыре базовые обязанности определяют то, что должны поддерживать все совместимые с Iceberg каталоги. Каждый запрос, обновление или изменение схемы проходит через этот слой, что делает его одним из самых критичных компонентов архитектуры Iceberg.

7.1.2 Взаимодействие каталога с движками запросов и обработки

Каталог - первая точка контакта, когда движок запросов или задача обработки начинает работать с таблицей Iceberg. Выполняет ли пользователь интерактивный SQL-запрос или запускает задачу потокового приёма, движок должен обратиться к каталогу, чтобы разрешить имя таблицы, загрузить её метаданные и спланировать операцию.

Это взаимодействие обычно следует предсказуемой последовательности, хотя по мере того, как каталоги с поддержкой REST становятся нормой, всё больше этой работы централизуется в самом каталоге:

Рис. 7.4 Движки запрашивают таблицы у каталогов, а каталоги возвращают расположение метаданных.

Разрешение таблицы - движок запрашивает у каталога таблицу по имени. Каталог возвращает ссылку на последний файл метаданных этой таблицы, как показано на рис. 7.4. Файл метаданных таблицы включает схему, партиционирование, сведения о снимках и манифесты файлов.

2. Планирование по снимку - по метаданным, показанным на рис. 7.5, движок определяет, какие файлы данных читать или записывать. Метаданные Iceberg включают статистику и метаданные уровня файлов, поддерживающие пропуск данных и проталкивание предикатов. Это сокращает объём сканируемых данных и повышает производительность.

Рис. 7.5 Метаданные дают разные уровни детализации, чтобы движок мог определить снимок и решить, какие файлы данных в этом снимке нужно сканировать.

3. Координация коммита - при операциях записи движки формируют новые метаданные, которые могут включать добавленные или удалённые файлы, обновлённые схемы и новые снимки. Сформировав их, движки пытаются зафиксировать эти метаданные, атомарно обновив указатель каталога. Если за это время таблицу обновила другая операция, коммит завершается неудачей, что обеспечивает согласованность и исключает гонки.
4. Управление схемой и её эволюцией - движки также используют полученные метаданные, чтобы понимать текущую и предыдущие схемы.
5. Путешествия во времени и откат - если пользователь запрашивает предыдущий снимок, движок видит историю снимков в файле метаданных вместе со схемой, соответствующей той версии таблицы, что и обеспечивает путешествия во времени и откат.

Именно эти взаимодействия позволяют Iceberg работать как многодвижковый универсальный формат lakehouse. Используете ли вы Spark для ETL, Flink для потоковой обработки или Trino для ad hoc аналитики, каталог даёт единое представление метаданных, удерживающее операции в согласии.

7.2 Оценка требований к каталогу

Прежде чем выбирать каталог, важно прояснить, что нужно от него вашей организации. Слой каталога - больше, чем технический компонент; он определяет, как команды находят данные, обращаются к ним и управляют ими в масштабах lakehouse. Расхождение между возможностями каталога и требованиями организации ведёт к пробелам в управлении данными, проблемам интеграции или эксплуатационной неэффективности.

В главе 4 я описал, как интервью с заинтересованными сторонами и технические аудиты помогают выявить требования к платформе. Теперь эти выводы вступают в игру. В этом разделе рассматриваются ключевые требования, которые стоит учесть при оценке вариантов каталога: производительность, доступность, управление метаданными, безопасность и совместимость со средами развёртывания.

Начнём с того, что сформулируем эти требования вокруг типичных корпоративных забот - ожиданий по задержкам, региональной доступности, контроля доступа и отслеживания схем. Затем посмотрим, как эти заботы превращаются в конкретные возможности каталогов и как взвешивать компромиссы с учётом вашей архитектуры, требований комплаенса и планов роста.

7.2.1 Производительность, доступность и масштаб

По своей сути каталог позволяет движкам запросов и инструментам обработки находить таблицы Iceberg и обращаться к их метаданным. Это взаимодействие часто лежит на критическом пути операций чтения и записи, что делает производительность каталога важным фактором. Ответы с высокой задержкой замедляют планирование таблиц и выполнение запросов, особенно в нагрузках с частыми обращениями к метаданным или параллельными записями.

Не менее важна доступность. Если каталог недостижим, пользователи не смогут ни запросить, ни обновить таблицы, даже если нижележащее хранилище полностью работоспособно. Это делает доступность каталога базовой зависимостью всего lakehouse. В промышленных средах высокая доступность обычно означает целевые показатели 99,9% (примерно 8,8 часа простоя в год) или лучше. Критически важные системы часто ориентируются на 99,99%, допуская менее часа простоя в год. Чтобы соответствовать этим ожиданиям, оцените, поддерживает ли ваш каталог отказоустойчивые схемы развёртывания: кластеризацию, межрегиональную репликацию или управляемые механизмы переключения при отказе.

Масштабируемость тоже играет критическую роль по мере роста платформы. В мультиарендных средах или организациях, управляющих сотнями и тысячами таблиц Iceberg и обслуживающих десятки и даже сотни одновременных пользователей, каталог должен выдерживать высокий поток запросов к метаданным, не превращаясь в узкое место. Речь не только о пропускной способности чтения, где зрелые каталоги нередко обрабатывают тысячи обращений к метаданным в секунду, но и о параллельных операциях записи, расширении пространств имён и разрешении метаданных снимков с низкой задержкой. Некоторые промышленные развёртывания сообщают об обслуживании более 10 000 таблиц и миллионов обращений к каталогу в сутки.

Оценивая варианты каталогов, задайте следующие вопросы:

Справляется ли каталог с высоким потоком запросов, отвечая с низкой задержкой?
Предлагает ли он отдельную базу данных-бэкенд для хранения метаданных?
Может ли каталог масштабироваться под рост нагрузки добавлением вычислительных ресурсов, а не развёртыванием новых экземпляров каталога?
Есть ли у него отказоустойчивые режимы развёртывания?
Оптимизирован ли он под чувствительные к задержкам нагрузки - интерактивные запросы или приём, близкий к реальному времени, либо в реальном времени?
Открыт ли каталог и совместим ли он с экосистемой используемых вами инструментов?

Ни одна метрика не отражает готовность каталога целиком, но понимание и тестирование ожидаемых нагрузок - пакетных против интерактивных, тестовых против промышленных - поможет понять, способен ли кандидат стабильно соответствовать целям по производительности, доступности и масштабируемости.

7.2.2 Управление метаданными и происхождение данных

Каталог не просто хранит расположение таблиц - он становится основой управления данными во всём lakehouse. В большинстве организаций каталог служит системой учёта того, где находятся данные, какова их структура и у кого есть к ним доступ. Поэтому управление метаданными - одно из самых критичных измерений при выборе каталога.

Как минимум ваш каталог должен поддерживать пространства имён и контроль доступа, как показано на рис. 7.6. Пространства имён позволяют логически группировать связанные таблицы, часто в соответствии с предметными областями или подразделениями. Однако надёжное управление данными требует возможностей, выходящих за рамки базовых ограничений доступа.

Рис. 7.6 У каталогов могут быть разные уровни контроля доступа, позволяющие управлять тем, кто имеет доступ к каким пространствам имён или таблицам.

Во-первых, каталоги должны интегрироваться с внешними провайдерами идентификации - OAuth, LDAP, SAML или корпоративными системами SSO. Эти интеграции позволяют каталогу наследовать идентификаторы пользователей и контексты доступа, обеспечивая согласованность прав платформы с более широкими корпоративными политиками.

Во-вторых, каталоги должны поддерживать детализированные модели авторизации - ролевое управление доступом (RBAC) и атрибутное (ABAC). RBAC назначает права по ролям пользователей (например, аналитик, инженер), тогда как ABAC принимает решения по атрибутам пользователя - подразделению или местоположению. Эти модели критичны для строгого контроля над тем, кто может читать, записывать или администрировать конкретные таблицы и пространства имён.

В-третьих, некоторые каталоги реализуют выдачу временных учётных данных (credential vending) - механизм безопасности, при котором каталог выдаёт клиентам короткоживущие ограниченные учётные данные. Это гарантирует, что клиент получает доступ только к тем путям в хранилище, которые нужны для его запроса, сокращая радиус поражения и упрощая аудит.

Вместе эти возможности позволяют каталогу обеспечивать безопасность и на уровне метаданных, и на уровне хранения. Но управление данными требует ещё и отслеживания происхождения данных - возможности проследить, как данные движутся через системы во времени. Происхождение связывает идентификаторы, права и операции в цепочку ответственности, поддерживающую комплаенс, проверяемость и анализ первопричин. Для компаний, подпадающих под регуляторные рамки вроде GDPR, HIPAA или SOC 2, эта возможность не опциональна - она необходима.

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

Сравнивая реализации каталогов, рассмотрите следующие вопросы:

Поддерживает ли он подключение к внешнему провайдеру идентификации?
Позволяет ли задавать детализированный контроль доступа?
Предлагает ли выдачу временных учётных данных для всех систем хранения, которые вы планируете использовать (S3, ADLS, GCS)?
Журналирует ли он операции с метаданными и позволяет ли их аудировать?
Есть ли у него возможности отслеживания происхождения метаданных?

Сильные средства управления данными не только закрывают внешние обязательства, но и повышают внутреннюю надёжность, упрощают отладку и снижают риск несанкционированных изменений, способных нарушить целостность данных.

7.2.3 Безопасность и соответствие требованиям

Безопасность - фундаментальное требование любой современной платформы данных. Как центральная точка контроля метаданных и обнаружения таблиц, каталог играет критическую роль в применении политик безопасности и обеспечении соответствия требованиям. Apache Iceberg даёт гарантии в части соблюдения схемы и транзакционной целостности, но именно каталог определяет, кто какие таблицы видит, какие действия им разрешены и как метаданные доступны и управляемы.

В большинстве организаций уже есть системы управления идентификацией и доступом (IAM). Каталоги, интегрирующиеся с ними - Amazon IAM, LDAP, OAuth или собственные сервисы токенов, - упрощают управление пользователями и согласуют Iceberg с корпоративными практиками безопасности. Такая интеграция также обеспечивает детализированные права, гарантируя, что разные роли могут администрировать, запрашивать или изменять метаданные только в положенных пределах.

Шифрование при передаче и при хранении - ещё одна ключевая забота. Слой хранения обычно шифрует файлы данных, но метаданные каталога тоже нужно защищать, особенно когда они включают историю снимков, значения партиций или записи об эволюции схемы. Каталоги должны использовать защищённые протоколы связи (HTTPS или gRPC поверх TLS) и поддерживать шифрование хранимого состояния.

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

Вот ключевые вопросы, которые стоит задать:

Поддерживает ли каталог интеграцию с вашими существующими системами IAM или SSO?
Шифруются ли операции с метаданными и безопасно ли они хранятся?
Может ли каталог обеспечить необходимые аудиторские следы и средства контроля для соответствия нормативным требованиям?

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

7.2.4 Гибкость развёртывания и совместимость с экосистемой

По мере того как архитектуры данных становятся всё более распределёнными и разнородными, гибкость каталога становится необходимой. Охватывает ли ваша платформа локальные кластеры, несколько облачных провайдеров или гибридные среды, каталог должен надёжно работать через эти границы. Гибкость развёртывания и совместимость с экосистемой определяют, насколько легко каталог встроится в вашу инфраструктуру и будет взаимодействовать с другими инструментами.

Гибкость развёртывания описывает возможность запускать каталог в разных средах в зависимости от инфраструктуры организации. Одни каталоги тесно интегрированы с конкретными вычислительными движками или экосистемами хранения, другие работают как самостоятельные сервисы. Такие автономные каталоги можно размещать у себя или получать как управляемый сервис от поставщика. Каталоги на основе REST особенно привлекательны, поскольку предоставляют единообразный интерфейс, позволяя инструментам и сервисам взаимодействовать с каталогом независимо от языка программирования и облачной платформы.

REST-интерфейсы делают каталоги независимыми от среды, но сам сервис каталога всё равно где-то физически работает - локально, в облачном регионе или распределённо. На практике для взаимодействия с каталогом пропускная способность и параллелизм обычно важнее «сырой» задержки запроса. Большинство операций с каталогом включает относительно немного вызовов метаданных по сравнению со стоимостью чтения файлов данных из хранилища, а значит, разница между единицами и десятками миллисекунд редко влияет на сквозную производительность запроса. Но устойчивая пропускная способность становится критичной на масштабе, особенно в средах со множеством параллельных писателей, частыми коммитами или большим числом таблиц и снимков. Поэтому размещение в сети стоит оценивать с точки зрения надёжности, полосы пропускания и способности каталога обрабатывать параллельные операции с метаданными, а не только минимизации времени кругового обхода. В отдельных случаях - при конвейерах с очень интенсивной записью или крупномасштабном обнаружении таблиц среди тысяч наборов данных - расстояние и сетевые характеристики всё же становятся фактором, но рассматривать их следует в контексте общей пропускной способности системы и шаблонов нагрузки.

Не менее важна совместимость с остальной частью вашего стека. Каталог должен беспрепятственно работать с движками обработки вроде Apache Spark, Flink, Trino или Dremio. Он должен поддерживать одинаковые модели разрешения таблиц и транзакций во всех этих движках, обеспечивая согласованное поведение независимо от среды исполнения. Каталоги, реализующие спецификацию Apache Iceberg REST, обычно дают более широкую совместимость между инструментами и поставщиками.

Ещё одно соображение - насколько хорошо каталог поддерживает автоматизацию и интеграцию с фреймворками оркестрации. Конвейерам CI/CD, реестрам схем и инструментам управления метаданными полезны каталоги, предоставляющие API, поддерживающие декларативную конфигурацию и выдающие машиночитаемые метаданные.

Вот ключевые вопросы для оценки:

Можно ли развернуть каталог в предпочитаемой вами среде (облако, локальная инфраструктура, контейнеры)?
Поддерживает ли он все движки запросов и обработки, используемые вашими командами?
Совместим ли он с REST или иным образом хорошо документирован для интеграции с внешними системами?

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

7.2.5 Стоимость и эксплуатационные издержки

Производительность, управление данными и совместимость обычно на первом плане, но именно стоимость и эксплуатационная нагрузка тихо определяют долгосрочную жизнеспособность каталога. Сюда входят не только прямые расходы вроде лицензий или потребления облачных ресурсов, но и усилия, необходимые для развёртывания, мониторинга и сопровождения каталога во времени.

У самостоятельно управляемых каталогов, включая многие открытые решения из этой главы, может не быть лицензионных платежей, но они требуют инженерных усилий на развёртывание, настройку, защиту и обновление. Эти усилия растут с масштабом, особенно в средах, требующих высокой доступности или межрегионального развёртывания. Управляемые сервисы, напротив, снижают эксплуатационную сложность, но привносят привязку к поставщику или затраты по потреблению, растущие со временем.

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

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

Чтобы оценить стоимость и издержки каталога, рассмотрите эти вопросы:

Каковы инфраструктурные и кадровые затраты на эксплуатацию каталога на масштабе?
Предлагает ли он мониторинг, журналирование и автоматическое восстановление?
Насколько активно сообщество разработчиков или канал поддержки поставщика?

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

7.2.6 Федерация каталогов и mesh-архитектуры

Организационные структуры, требования комплаенса и ограничения регионального развёртывания часто вынуждают использовать несколько каталогов, каждый из которых работает независимо, но всё же должен участвовать в единой экосистеме. Здесь и становятся необходимыми федерация каталогов и mesh-архитектуры.

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

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

Типичные причины перехода к mesh-архитектуре каталогов:

Регуляторные границы, требующие, чтобы данные оставались в определённых юрисдикциях
Децентрализованные команды, работающие по разным моделям управления
Развёртывания под конкретное облако, где сервисы привязаны к нативным каталогам провайдера (например, AWS Glue, Azure Purview)
Эксплуатационный масштаб, при котором единственный каталог становится узким местом или единой точкой отказа

Для поддержки федерации каталоги должны реализовать следующее:

Единообразные API (REST или gRPC) для доступа к метаданным и синхронизации
Стратегии разрешения пространств имён, различающие локальные и удалённые ресурсы
Распространение идентичности и политик безопасности для сохранения целостности контроля доступа между каталогами
Механизмы распространения изменений - событийную синхронизацию или репликацию метаданных, - удерживающие федеративные каталоги в согласии без конфликтов и устаревших состояний

Оценивая реализации каталогов, рассмотрите эти вопросы:

Может ли он участвовать в слое федерации или интегрироваться с внешними сервисами обнаружения?
Как между узлами сети управляются конфликты, обновления и права доступа?

Хорошо спроектированная федерация каталогов позволяет организациям масштабировать lakehouse на Iceberg, не жертвуя автономией, соответствием требованиям и прозрачностью. Она отражает переход от централизованного контроля к распределённой координации - необходимую эволюцию по мере усложнения экосистем данных.

7.3 Спецификация Apache Iceberg REST Catalog

Центральное обещание архитектуры lakehouse - совместимость: возможность множеству движков и инструментов безопасно работать с одними и теми же наборами данных через общие стандарты. Apache Iceberg обеспечивает это на уровне табличного формата, но до недавнего времени совместимость каталогов отставала. Ранние интеграции каталогов сильно зависели от клиентских библиотек под конкретные движки, часто реализованных на одном языке и неравномерно сопровождаемых в разных экосистемах. Что важнее, значительная часть ответственности за координацию коммитов и обновление метаданных ложилась на сам клиент. Каждому движку приходилось корректно реализовывать логику коммитов, обрабатывать параллельные обновления и записывать артефакты метаданных, что вело к несогласованности между версиями, тонким ошибкам корректности и разнобою в поведении инструментов. Отсутствие стандартизованной серверной модели коммитов делало многодвижковую совместимость хрупкой на практике. Современные проекты каталогов движутся к полному отделению логики коммитов от клиентов, централизуя транзакционную ответственность в самом сервисе каталога. Этот сдвиг вместе с общими API - критический шаг к тому, чтобы сделать Iceberg по-настоящему совместимым фундаментом, и он отражает более широкое направление развития экосистемы.

Появление спецификации Apache Iceberg REST Catalog стало серьёзным шагом вперёд. Определив единообразный HTTP-интерфейс для операций каталога, она отделяет клиента от реализации каталога. Это упрощает комбинирование движков запросов и сервисов каталога, позволяя организациям развивать архитектуру без привязки к конкретному поставщику или языковой экосистеме, как показано на рис. 7.7.

Рис. 7.7 Благодаря спецификации REST Catalog клиент, написанный на любом языке, может общаться со всеми каталогами независимо от того, на каком языке написан сервер каталога, что улучшает совместимость.

В этом разделе обсуждаются фрагментированная среда, существовавшая до спецификации REST Catalog, техническое обоснование её создания и ценность, которую она даёт и пользователям Iceberg, и разработчикам каталогов. Мы также отметим растущую экосистему сервисов каталогов, поддерживающих REST-интерфейс, и то, что это значит для кроссплатформенных развёртываний lakehouse.

7.3.1 До появления спецификации Apache Iceberg REST Catalog

До появления спецификации Apache Iceberg REST Catalog ландшафт интеграций с каталогами был фрагментированным и несогласованным. Функциональность каталога - перечисление пространств имён, регистрация таблиц, фиксация изменений - была жёстко связана с клиентскими библиотеками под конкретные языки. Каждому поставщику каталога обычно приходилось реализовывать и сопровождать клиентские библиотеки на нескольких языках: Java, Python, Go, Rust. Но уровень поддержки и полнота возможностей сильно различались между этими реализациями.

Такая несогласованность создавала множество трудностей и поставщикам каталогов, и пользователям Iceberg, причём самой серьёзной заботой была корректность. Каталог мог иметь надёжную поддержку на одном языке, скажем Java, и при этом демонстрировать неполное или едва заметно иное поведение в Python или Go. Поскольку координация коммитов и обновление метаданных выполнялись в клиентских библиотеках, каждый движок фактически переизобретал части транзакционной логики Iceberg. Даже небольшие расхождения в версиях клиентов, разрешении зависимостей или конфигурации classpath могли привести к неверному обнаружению конфликтов, потерянным обновлениям или несогласованному состоянию таблиц. Эти проблемы часто проявлялись как ошибки времени выполнения, но опаснее были незаметные ошибки корректности, когда запись выглядела успешной, но нарушала ожидаемые транзакционные гарантии. Это делало многодвижковые среды хрупкими, вынуждая команды жёстко контролировать версии и интеграции ради сохранности данных.

Более того, необходимость встраивать логику каталога в каждую клиентскую библиотеку дублировала усилия и замедляла развитие. Каждую новую возможность каталога приходилось заново реализовывать и тестировать во всех поддерживаемых языках клиентов, как показано на рис. 7.8. Из-за этого поставщикам каталогов было трудно обеспечить согласованное поведение и производительность в разных движках.

Рис. 7.8 До спецификации REST Catalog каждый сервис каталога должен был поддерживать собственные клиентские библиотеки на каждом языке, создавая фрагментированную и трудно сопровождаемую среду.

Проблема была не в том, что движки вроде Spark, Flink или Trino вовсе не могли общаться с каталогами: большинство сред стандартизировались на Hive Metastore (HMS), дававшем широкую, пусть и несовершенную, совместимость. Более глубокая проблема состояла в том, что корректность и транзакционное поведение жили преимущественно в клиентских реализациях, а не в самом каталоге. Каждый движок и каждая клиентская библиотека отвечали за корректную и согласованную реализацию логики коммитов, обнаружения конфликтов и обновления метаданных. По мере роста внедрения Iceberg и увеличения конкурентности и числа задействованных движков эта модель становилась всё более хрупкой. Поддерживать все клиенты обновлёнными, согласованными по поведению и свободными от тонких транзакционных ошибок на масштабе оказалось трудно. Растущая сложность обнажила потребность в более централизованном, независимом от движка подходе, где корректность и координация коммитов решались бы один раз и единообразно, а не переизобретались каждым клиентом.

7.3.2 Решение

Чтобы устранить проблемы совместимости и сопровождения, порождённые фрагментированными клиентскими библиотеками каталогов, сообщество Iceberg представило спецификацию Apache Iceberg REST Catalog. Она определяет единообразный, независимый от движка HTTP-API для взаимодействия с каталогами. Вместо встраивания логики в каждую клиентскую библиотеку движки и приложения теперь общаются с любым совместимым каталогом через общий, не зависящий от языка протокол.

Спецификация REST Catalog стандартизирует такие операции, как получение метаданных таблицы, перечисление пространств имён, регистрация новых таблиц и фиксация изменений. Это упрощает клиентские реализации и обеспечивает единообразное поведение разных каталогов и движков. Приняв REST-интерфейс, сервисы каталогов больше не должны создавать и поддерживать обширные клиентские библиотеки под каждый язык, как показано на рис. 7.9. Вместо этого движки вроде Spark, Flink, Trino и другие интегрируются напрямую через общий интерфейс.

Рис. 7.9 Со спецификацией REST Catalog одна и та же клиентская библиотека годится для всех каталогов, что снижает фрагментацию и улучшает совместимость между каталогами Iceberg.

Этот подход приносит немедленные и долгосрочные выгоды и пользователям, и поставщикам каталогов. Пользователи могут выбирать каталог, лучше всего подходящий их среде, не ограничиваясь языковыми привязками или клиентскими реализациями под конкретный движок. Что важнее, модель на основе REST позволяет Apache Iceberg постепенно переносить всё больше ответственности с отдельных движков на сам каталог. Такие API, как планирование сканирования, снимают с клиентов необходимость разбираться в низкоуровневых деталях вроде разбора манифестов или планирования на уровне файлов, а централизованные API коммитов позволяют транзакционной логике и разрешению конфликтов жить в одном месте. Это создаёт единый авторитетный слой для обеспечения корректности. Поставщикам каталогов такой сдвиг позволяет последовательно реализовывать более глубокие возможности - детализированный контроль доступа, применение политик и функции управления данными, - одновременно снижая сложность и хрупкость тяжеловесных клиентских библиотек по всей экосистеме.

Спецификация REST Catalog быстро набрала популярность, и её поддерживают уже несколько крупных каталогов: AWS Glue Data Catalog, Apache Polaris, Apache Gravitino, Lakekeeper, Nessie, каталог Dremio и Snowflake Open Catalog. По мере роста внедрения организации получают свободу развивать инфраструктуру данных без переделки окружающих инструментов и конвейеров.

По сути, спецификация REST превращает слой каталога Iceberg из жёстко связанной точки интеграции в открытый компонуемый интерфейс. Это повышает модульность и долговечность архитектур lakehouse и обеспечивает настоящую совместимость на уровне метаданных.

7.4 Варианты каталогов: обзор экосистемы

Apache Iceberg поддерживает гибкий интерфейс каталога, и экосистема реализаций продолжает расширяться. Эти каталоги различаются архитектурой, операционной моделью и глубиной интеграции, но все стремятся выполнить описанные ранее базовые обязанности: управлять метаданными таблиц, координировать транзакции и обеспечивать доступ к данным из множества движков.

Каталоги делятся на несколько широких категорий. Одни, как каталоги Hadoop и JDBC, встроены в библиотеки Iceberg и не требуют дополнительных сервисов, кроме JDBC-совместимой базы данных. Они подходят для более простых развёртываний или сред разработки, где внешние зависимости стоит минимизировать.

Другие - Apache Polaris, Project Nessie, Apache Gravitino и Lakekeeper - открыты и управляются самостоятельно. Эти каталоги рассчитаны на продвинутые возможности работы с метаданными: доступ по REST, контроль версий и мультиарендные среды. Они дают больше гибкости и расширяемости, но требуют планирования инфраструктуры и эксплуатационного контроля.

Наконец, ряд каталогов предоставляют и сопровождают облачные и аналитические поставщики. Сюда входят AWS Glue Data Catalog, каталог Dremio (на базе Apache Polaris) и Snowflake Open Catalog (тоже на базе Polaris). Эти управляемые сервисы обычно тесно интегрированы со своими платформами, предлагая упрощённую настройку, встроенную безопасность и масштабирование. Но они могут ограничивать кастомизацию и переносимость.

В этом разделе мы пройдём по этим типам каталогов, отметив их архитектуры, возможности и компромиссы, часть которых сведена в табл. 7.1. Сравнив их возможности и модели развёртывания, вы получите контекст, необходимый для согласования выбора каталога с целями и ограничениями вашей организации.

Таблица 7.1 Сравнение каталогов Apache Iceberg

Название	Открытый код	REST-каталог	Особенности
Hadoop	Да	Нет	Не требует сервиса; возможны проблемы с согласованностью
JDBC	Да	Нет	Каталогом может служить любая база данных с JDBC
Hive	Да	Нет	Использование существующего каталога Hive
Apache Polaris	Да	Да	RBAC; федерация каталогов; мультиарендность
Project Nessie	Да	Да	Версионирование каталога в духе Git
Apache Gravitino	Да	Да	Федерация с Hive; геораспределённый каталог
Lakekeeper	Да	Да	На Rust; поддержка контрактов на данные
AWS Glue Data Catalog	Нет	Да	Интегрирован в инструментарий AWS
Каталог Dremio	На базе Polaris	Да	Коммерческий сервис на Apache Polaris с автоматическим обслуживанием таблиц; оплата по вычислениям на обслуживание; внешние запросы не тарифицируются
Snowflake Open Catalog	На базе Polaris	Да	Коммерческий сервис на Polaris; оплата за запросы к каталогу
Databricks Unity	Нет (у OSS-версии другая кодовая база)	Да	Поддерживает Iceberg и Delta Lake

7.4.1 Каталог Hadoop

Каталог Hadoop - один из простейших способов управлять метаданными Iceberg. Встроенный прямо в библиотеку Apache Iceberg, он не требует внешнего сервиса или отдельного компонента времени выполнения. Вместо этого он хранит метаданные таблиц в структурированной иерархии каталогов в совместимой с Hadoop файловой системе - HDFS, Amazon S3 или Azure Data Lake Storage.

Метаданные каждой таблицы хранятся в отдельном подкаталоге под общим корнем warehouse. Каталог сопоставляет имена таблиц этим каталогам и управляет ссылками на их метаданные локально. Поскольку метаданные хранятся рядом с самими данными, как показано на рис. 7.10, такой подход прост в настройке и понятен.

Рис. 7.10 В каталоге Hadoop для обнаружения файла метаданных используется файл VERSION-HINT.TEXT вместо сервиса каталога, которому вы бы отправляли запрос.

Ключевые характеристики:

Локальное управление состоянием - все операции каталога основаны на файловой системе. Регистрация таблиц, обновления и удаления выполняются прямыми манипуляциями с файлами метаданных.
Отсутствие внешних зависимостей - нет сервера для развёртывания и сервиса для сопровождения. Каталог работает целиком в том же контексте, что и клиент (например, Spark или Flink).
Поддержка пространств имён - имена таблиц организуются в логические пространства имён через иерархию каталогов (например, warehouse/analytics/marketing/sales_data).

Сильные стороны:

Быстро настраивается, полезен для локальной разработки и изолированных сред
Подходит для однопользовательских или жёстко контролируемых нагрузок
Минимальные эксплуатационные издержки, отдельный сервис метаданных не нужен

Ограничения:

Нет централизованной координации транзакций для параллельных записей из разных движков
Не поддерживает удалённый доступ и REST API, что затрудняет интеграцию между средами и командами
Плохо подходит для мультиарендных или межрегиональных lakehouse, где нужны контроль доступа и отслеживание происхождения данных
Объявлен устаревшим, его использование с Apache Iceberg не рекомендуется

Каталог Hadoop лучше рассматривать как унаследованный или переходный вариант, а не как рекомендуемый выбор для современных развёртываний Iceberg. Он всё ещё встречается в примерах и исторических конфигурациях, но ему недостаёт масштабируемости, гарантий корректности и централизованной координации, необходимых в реальной промышленной эксплуатации. Для любого развёртывания с несколькими инструментами, параллельными писателями или общей инфраструктурой сервисный каталог не просто предпочтителен - он фактически обязателен.

7.4.2 Каталог Hive

Каталог Hive позволяет Apache Iceberg использовать существующий Hive Metastore (HMS) в качестве бэкенда каталога. Это делает его привлекательным вариантом для организаций, много вложивших в платформы данных на Hive и желающих постепенно перейти на Iceberg, не перестраивая инфраструктуру управления метаданными.

При использовании каталога Hive таблицы Iceberg регистрируются в HMS, а движки вроде Spark, Trino и Flink работают с каталогом через свои слои интеграции с Hive. Такая совместимость делает относительно простым внедрение Iceberg рядом с унаследованными таблицами Hive в ходе постепенной миграции.

Преимущества:

Использует существующую инфраструктуру HMS
Хорошо поддерживается популярными движками - Spark, Flink и Trino
Привычные схемы интеграции для команд, уже работающих с Hive

Компромиссы:

Нет поддержки некоторых возможностей Iceberg, зависящих от более современных функций каталога, - операций с пространствами имён и детализированного ролевого контроля доступа
Не поддерживает REST Catalog API, что ограничивает совместимость с новыми инструментами
Подвержен ограничениям и проблемам масштабируемости HMS

Каталог Hive стоит считать исторической точкой интеграции, а не рекомендуемым вариантом для новых развёртываний Iceberg. Он сыграл важную роль на раннем этапе внедрения, позволяя опираться на HMS, но современные реализации HMS сами предоставляют REST-интерфейсы. В результате использование плагина Hive Catalog для Apache Iceberg добавляет лишнюю косвенность и сложность. Командам, внедряющим Iceberg сегодня, сервисные каталоги с REST API Iceberg дают более чистый, корректный и устойчивый к будущим изменениям фундамент, чем унаследованные интеграции на Hive.

7.4.3 Каталог JDBC

Каталог JDBC - ещё один встроенный вариант, предоставляемый Apache Iceberg. Вместо хранения указателей на метаданные в файловой системе он использует реляционную базу данных для ведения состояния каталога. Сведения о таблицах и пространствах имён сохраняются в наборе служебных таблиц, а все операции - создание, обновление или удаление таблиц Iceberg - выполняются через стандартные SQL-транзакции.

Поддерживаются PostgreSQL, MySQL и другие базы с JDBC-совместимыми драйверами. Этот подход даёт более строгие транзакционные гарантии, чем каталог Hadoop, и позволяет нескольким вычислительным средам использовать общее централизованное хранилище метаданных.

Ключевые характеристики:

Хранилище метаданных на SQL - указатели на метаданные и иерархии пространств имён хранятся в структурированных таблицах базы данных.
Гарантии ACID - SQL-транзакции обеспечивают атомарные обновления и снижают риск несогласованности метаданных при параллельных операциях.
Одноузловая архитектура - сервер каталога встроен в клиента (задачу Spark или приложение), но общее хранилище обеспечивает разделяемое состояние между задачами.

Сильные стороны:

Прост в настройке, если JDBC-совместимая база данных уже есть
Легче масштабируется, чем каталог Hadoop, при доступе из нескольких движков
Поддерживает параллельную запись с транзакционной целостностью, что делает его пригоднее для совместной работы

Ограничения:

Клиент каталога всё ещё работает внутри контекста каждого движка, поэтому масштабирование зависит от производительности нижележащей базы данных.
Без встроенного REST-интерфейса удалённый доступ и межъязыковая интеграция должны идти через клиентскую библиотеку Iceberg.

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

7.4.4 Apache Polaris

Apache Polaris - открытая реализация каталога для Apache Iceberg на основе REST. Спроектированный для многодвижковых сред, Polaris выступает централизованным слоем координации метаданных таблиц Iceberg, обеспечивая согласованный защищённый доступ из движков вроде Spark, Flink, Trino и Snowflake.

Polaris опирается на спецификацию Apache Iceberg REST Catalog, обеспечивая развязанный доступ к метаданным, соответствующий облачным архитектурам. Он поддерживает внутренние и внешние каталоги и вводит продвинутые понятия: сервисные принципалы, RBAC и выдачу временных учётных данных.

Polaris работает как самостоятельный сервис, обычно развёрнутый в защищённой среде с доступом к облачному объектному хранилищу (S3, ADLS или GCS). Каждый настроенный в Polaris каталог сопоставляется с определённым расположением в облачном хранилище и управляет указателями на метаданные одной или нескольких таблиц Iceberg.

Polaris может работать с внутренними и внешними каталогами:

Внутренние каталоги полностью управляются Polaris. Таблицы регистрируются, обновляются и становятся доступны через API Polaris, а данные и метаданные лежат в вашем облачном хранилище.
Внешние каталоги позволяют Polaris синхронизировать метаданные из каталогов, управляемых в другом месте (Glue или Dremio). Внутри Polaris такие таблицы доступны только для чтения, что делает эту модель полезной для централизованной видимости без принятия на себя контроля над операциями записи.

Polaris обеспечивает безопасность через многоуровневую систему RBAC:

Сервисные принципалы представляют пользователей или системы (например, задачи Spark, BI-дашборды).
Роли принципалов группируют сервисные принципалы с общими требованиями к доступу.
Роли каталога определяют привилегии на уровне каталога, пространства имён и таблицы и назначаются ролям принципалов.

Эта структура позволяет тонко делегировать права - например, дать доступ только для чтения специалистам по data science, обеспечив при этом полное управление таблицами инженерам данных. Выдача временных учётных данных гарантирует, что движки запросов получают доступ на время выполнения, без прямого раскрытия учётных данных облачного хранилища.

Polaris спроектирован независимым от движка запросов. С ним может работать любой движок, поддерживающий REST-протокол Iceberg. Polaris также поддерживает продвинутые иерархии пространств имён, интроспекцию метаданных и версионированный доступ к таблицам Iceberg, обеспечивая надёжное управление жизненным циклом.

Сильные стороны:

Централизованная координация метаданных по REST между движками
Встроенная поддержка мультиоблачных бэкендов хранения
Детализированный контроль доступа через RBAC
Поддержка внешних каталогов ради единой видимости метаданных
Безопасная выдача временных учётных данных, снижающая риски раскрытия
Поддержка разных бэкендов хранения состояния (Postgres и др.)

Ограничение:

Требует развёртывания инфраструктуры и эксплуатационного управления

Polaris идеален для организаций, которым нужна централизованная плоскость метаданных с поддержкой множества вычислительных движков и последовательным управлением данными. Соответствие стандартам и расширяемая архитектура делают его сильным кандидатом для промышленных lakehouse на Iceberg, охватывающих несколько команд и облачных сред.

7.4.5 Project Nessie

Project Nessie - открытая реализация каталога, привносящая в data lake семантику контроля версий в духе Git. Он работает как слой координации метаданных для Apache Iceberg, обеспечивая атомарные, изолированные и проверяемые изменения одной или нескольких таблиц. Построенный как REST-сервис с клиентскими библиотеками на нескольких языках, Nessie поддерживает разные бэкенды и напрямую интегрируется с такими инструментами, как Spark, Flink и Trino. Nessie также поддерживает интерфейс Apache Iceberg REST Catalog.

В своей основе Nessie ведёт версионируемую историю операций с метаданными. Каждое изменение таблицы - добавление файлов, изменение схем, удаление партиций - фиксируется как коммит. Эти коммиты группируются по веткам, как в Git, позволяя экспериментам, подготовке и промышленным изменениям сосуществовать без конфликтов. Теги дают неизменяемые ссылки на конкретные моменты времени.

Nessie выступает только слоем координации; он не управляет метаданными таблиц и файлами данных напрямую. Вместо этого он делегирует хранение метаданных и операции с таблицами Iceberg, поддерживая при этом согласованное представление их эволюции через собственный журнал версий. Такое разделение обеспечивает огромную масштабируемость и производительность.

Одна из отличительных черт Nessie - поддержка ветвления и слияния изменений данных на уровне каталога. Аналитические задачи или конвейеры приёма могут работать изолированно, записывая данные в выделенную ветку. После успешного завершения все изменения атомарно сливаются в основную линию. Эта модель не даёт увидеть неполные данные и предоставляет мощные возможности отката и отладки.

Nessie обеспечивает транзакции, охватывающие несколько таблиц, - задача, традиционно трудная в распределённых средах data lake. Группируя изменения нескольких таблиц в один коммит или слияние выделенной рабочей ветки, Nessie обеспечивает согласованность и атомарность. Это особенно ценно там, где эволюция схемы или приём данных должны происходить одновременно в связанных наборах данных.

При использовании с REST-протоколом Iceberg Nessie может передавать конфигурацию и временные учётные данные клиентским движкам вроде Spark или Trino. Такой подход избавляет эти движки от необходимости иметь прямые учётные данные облачного хранилища, повышая безопасность и упрощая развёртывание. Например, учётные данные объектного хранилища можно безопасно выдавать через подписывание запросов во время выполнения.

Nessie рассчитан на высоконагруженные среды и поддерживает тысячи коммитов в секунду и крупномасштабные операции с метаданными. Его можно развернуть в Docker или контейнерных платформах с поддержкой подключаемых бэкендов метаданных вроде DynamoDB, PostgreSQL и Cassandra. REST API Nessie также позволяет интегрировать его с конвейерами CI/CD или собственными приложениями управления данными.

Сильные стороны:

Контроль версий в духе Git для data lake
Ветки и теги для изолированной разработки и воспроизводимости
Нативная поддержка транзакций над несколькими таблицами и отката
REST API и клиенты на многих языках
Совместимость с Iceberg REST и интеграция с движками вроде Spark и Trino

Ограничение:

Требует отдельного развёртывания и эксплуатационного сопровождения

Nessie лучше всего подходит организациям, которые ценят воспроизводимость данных, безопасные эксперименты и надёжное управление. Его модель наводит мост между традиционным контролем версий и растущими потребностями крупных data lake, что делает его убедительным вариантом для современных архитектур на Iceberg.

7.4.6 Apache Gravitino

Apache Gravitino - федеративное геораспределённое озеро метаданных, обеспечивающее единый доступ и управление широким кругом активов данных и ИИ. Как проект Apache, Gravitino предлагает расширяемую платформу, способную управлять метаданными в разных системах хранения, регионах и форматах данных. Он служит и каталогом метаданных, и слоем управления, глубоко интегрируясь с Apache Iceberg через интерфейс REST-каталога.

Gravitino вводит многослойную архитектуру управления метаданными:

Metalake - контейнер верхнего уровня, часто используемый для разграничения метаданных по организационной группе или арендатору.
Каталоги подключаются к конкретным источникам данных (Iceberg, Hive, Kafka, HDFS) и предоставляют их метаданные через Gravitino.
Схемы и таблицы представляют структурированные объекты метаданных для табличных источников, тогда как filesets, модели и топики поддерживают неструктурированные и связанные с ИИ метаданные.

Эта гибкая объектная модель позволяет Gravitino управлять метаданными data lake, систем обмена сообщениями и артефактов машинного обучения в едином домене управления.

Gravitino реализует интерфейс Apache Iceberg REST Catalog, обеспечивая совместимость с любым движком, знающим Iceberg. Он также предоставляет коннекторы к Hive, MySQL, PostgreSQL и другим, позволяя выступать централизованным хабом метаданных в гибридных средах.

Его REST API, Java SDK и Python SDK делают его доступным с самых разных платформ, а веб-интерфейс и CLI упрощают администрирование. Gravitino можно запускать локально, в контейнерах или разворачивать в нескольких облачных регионах с поддержкой георепликации.

Gravitino включает встроенные возможности управления метаданными:

Контроль доступа поддерживает ролевые политики для всех каталогизированных активов.
Управление тегами обеспечивает классификацию и обнаружение.
Журналирование аудита и средства безопасности интегрируются с корпоративными методами аутентификации, включая OAuth и Kerberos.

Эти возможности обеспечивают согласованную безопасность и прозрачность в распределённых доменах метаданных.

Gravitino особенно хорошо подходит организациям с

разнородными системами хранения, требующими единого доступа к метаданным;
глобальными операциями, которым выгодно федеративное развёртывание каталога;
разнообразными активами, охватывающими табличные данные, неструктурированные файлы и модели ИИ.

Сильные стороны:

Единая каталогизация метаданных таблиц, файлов и моделей ИИ
REST-совместимая интеграция каталога Iceberg
Веб-интерфейс, CLI и SDK для полноценного администрирования
Расширяемость на гибридные облака и межрегиональные сценарии

Ограничения:

Всё ещё в инкубации и развивается, часть корпоративных возможностей может быть на ранней стадии
Георепликация и продвинутые средства контроля доступа ещё дозревают
Эксплуатационная сложность может быть выше из-за широкого охвата и гибкости

Gravitino занимает уникальную нишу в ландшафте каталогов метаданных, предлагая широкую горизонтальную интеграцию между форматами и доменами. Для развёртываний Iceberg, сосуществующих с широким кругом систем данных, Gravitino даёт централизованную плоскость доступа к метаданным и применения политик, что делает его ценным вариантом для сложных федеративных lakehouse.

7.4.7 Lakekeeper

Lakekeeper - лёгкая, безопасная и расширяемая реализация спецификации Apache Iceberg REST Catalog. Написанный на Rust, Lakekeeper предлагает быстрый вариант развёртывания без JVM для сред Iceberg. Он поддерживает детализированный контроль доступа, выдачу учётных данных хранилища и интеграцию с современными системами аутентификации вроде OpenID Connect и сервисных аккаунтов Kubernetes. С нативной поддержкой Trino, Spark, PyIceberg и StarRocks Lakekeeper даёт готовый к промышленной эксплуатации масштабируемый каталог, подходящий широкому кругу сценариев lakehouse.

Lakekeeper работает как самостоятельный бинарный файл, избегая накладных расходов сред JVM или Python. Он рассчитан на развёртывание в контейнерных средах через Docker или Helm и легко встраивается в инфраструктуру на Kubernetes. В своей основе Lakekeeper обслуживает два API:

Iceberg REST API (по пути /catalog) - для клиентских движков запросов.
Management API (по пути /management) - для настройки сущностей Lakekeeper: проектов, warehouse, ролей и прав.

Lakekeeper использует PostgreSQL для хранения каталога и поддерживает внешние хранилища секретов (например, Vault) и хранилища событий (Kafka, NATS) для безопасных и проверяемых операций.

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

Детализированный контроль доступа обеспечивается через интеграцию с OpenFGA или собственные авторизаторы. Пользователи и роли управляются извне, а аутентификация делегируется провайдерам идентификации, совместимым с OpenID. Права применяются к каталогам, пространствам имён, таблицам и представлениям. Lakekeeper также поддерживает рекурсивное и принудительное удаление через API, позволяя безопасно и гибко управлять защищёнными иерархиями.

Lakekeeper включает несколько продвинутых возможностей управления данными:

Мягкое удаление - таблицы можно пометить на удаление, но сохранять в течение настраиваемого срока, что позволяет восстановление и безопасные откаты.
Хуки согласования изменений - интеграции могут перехватывать и отклонять изменения, нарушающие контракты на данные или пороги качества.
Удалённое подписывание и выдача учётных данных - клиенты получают временные учётные данные во время запроса, что снижает риски, связанные с долгоживущими учётными данными хранилища.

Эти механизмы повышают эксплуатационную безопасность и закрепляют лучшие практики защищённого и управляемого использования data lake.

Сильные стороны:

Лёгкое развёртывание на Rust без требования JVM
Полная реализация интерфейса Iceberg REST Catalog
Встроенные выдача учётных данных хранилища и механизмы мягкого удаления
Тесная интеграция с Kubernetes и аутентификация на основе OpenID
Высокая настраиваемость через подключаемые интерфейсы и расширения на трейтах

Ограничение:

Сейчас поддерживает только PostgreSQL как бэкенд

Lakekeeper идеален командам, которым нужен безопасный, масштабируемый облачный сервис каталога, простой в развёртывании и тесно интегрированный с современной инфраструктурой. Он особенно хорошо подходит организациям, желающим встроить строгие практики управления данными и интегрироваться с процессами CI/CD и собственными системами согласования.

7.4.8 AWS Glue Data Catalog

AWS Glue Data Catalog - управляемый сервис метаданных от Amazon и популярный выбор для реализации каталогов Iceberg в облачных архитектурах lakehouse. У каждого аккаунта AWS есть один Glue Data Catalog на регион, служащий централизованным масштабируемым хранилищем метаданных по базам данных и таблицам. Благодаря интеграции с сервисами Amazon вроде Athena, Redshift Spectrum, SageMaker Unified Studio, S3 Tables и EMR Glue даёт целостную среду для обнаружения, преобразования и управления данными.

AWS Glue Data Catalog может служить каталогом метаданных для Apache Iceberg, позволяя регистрировать таблицы Iceberg и управлять ими через Glue Catalog. Эта интеграция достигается настройкой вычислительных движков на подключение к REST-эндпоинту Glue, что позволяет им читать таблицы Iceberg и писать в них, когда метаданными управляет AWS.

Отдельно версии движка AWS Glue Spark 3.0 и 4.0 включают нативную поддержку транзакционных табличных форматов вроде Apache Iceberg. Это значит, что движок уже укомплектован нужными библиотеками для распознавания таблиц Iceberg и работы с ними без дополнительной настройки. Для сценариев, требующих конкретных версий Iceberg или продвинутой функциональности, поведение по умолчанию можно переопределить, подключив собственные JAR-файлы или коннекторы в конфигурации задачи.

Чтобы настроить Iceberg с движком AWS Glue, обычно выполняют такие шаги:

Задать --datalake-formats iceberg для включения нативной поддержки.
Указать реализацию org.apache.iceberg.aws.glue.GlueCatalog.
Использовать org.apache.iceberg.aws.s3.S3FileIO для оптимизированного ввода-вывода на S3.

Эти настройки можно применять через визуальные инструменты, ноутбуки или задачи Glue на основе скриптов.

AWS Glue Data Catalog тесно интегрируется с AWS Lake Formation и управлением идентификацией и доступом (IAM), предлагая детализированный контроль доступа. С этой моделью предприятия могут безопасно публиковать данные и делиться ими между подразделениями, ограничивая доступ к чувствительной информации. В сочетании с AWS CloudTrail Glue Data Catalog обеспечивает надёжную проверяемость изменений метаданных и схем.

AWS Glue Data Catalog служит опорой метаданных для нескольких аналитических и ML-сервисов AWS. Он выступает базовым каталогом сервиса SageMaker Lakehouse, позволяя пользователям SageMaker Studio создавать таблицы Iceberg и работать с ними. К этим таблицам также можно обращаться через Amazon Athena, Amazon Redshift и сам SageMaker, унифицируя доступ для аналитических и ML-нагрузок. Кроме того, возможность S3 Table напрямую интегрируется с каталогом Glue, позволяя определять совместимые с Iceberg таблицы на Amazon S3 привычными командами DDL без управления внешними сервисами метаданных.

Сильные стороны:

Полностью управляемое хранилище метаданных с глубокой интеграцией в экосистему AWS
Нативная поддержка Iceberg в средах Spark с AWS Glue Data Catalog
Развитые средства безопасности, аудита и контроля доступа через IAM и Lake Formation

Ограничения:

Региональный охват ограничивает совместное использование метаданных между регионами без дублирования.
Glue тесно связан с экосистемой AWS.
Меньше контроля над внутренним устройством по сравнению с самостоятельно управляемыми каталогами.

AWS Glue Data Catalog хорошо подходит организациям, уже связавшим себя с инфраструктурой AWS. Он упрощает настройку и эксплуатацию, особенно командам, которым нужны бессерверная интеграция данных и управление доступом без администрирования инфраструктуры. Но командам, которым нужны мультиоблачная переносимость или полный контроль над внутренним устройством каталога, могут подойти другие варианты.

7.4.9 Каталог Dremio

Каталог Dremio - управляемый каталог Iceberg, встроенный в корпоративную платформу Dremio и построенный поверх Apache Polaris, открытой реализации спецификации Iceberg REST Catalog. Созданный, чтобы упростить развёртывание lakehouse корпоративного уровня, каталог Dremio снимает трение, часто связанное с управлением и эксплуатацией самостоятельных каталогов.

Apache Polaris, представленный в 2024 году, быстро набирает популярность как нейтральный к поставщикам, REST-совместимый каталог для Apache Iceberg. Как ключевой компонент каталога Dremio, Polaris позволяет Dremio предоставлять совместимый защищённый доступ к таблицам Iceberg из движков вроде Spark, Flink и Trino. Эта открытая основа позволяет читать и записывать таблицы Iceberg любым совместимым движком, централизованно управляя метаданными в Dremio.

Dremio расширяет Polaris возможностями корпоративного уровня, рассчитанными на промышленные нагрузки:

Детализированный контроль доступа - поддержка RBAC, фильтров на уровне строк и маскирования столбцов обеспечивает безопасный доступ к данным.
Происхождение метаданных и обнаружение - встроенные инструменты помогают аналитикам понимать зависимости данных и прослеживать преобразования по графам происхождения.
Обнаружение на естественном языке - бизнес-пользователи могут исследовать и понимать наборы данных через аннотации метаданных и описательные метки.

Dremio автоматизирует критически важные операции обслуживания Iceberg - компактизацию и очистку (vacuum). Это снижает эксплуатационную нагрузку и помогает поддерживать производительность без внешней оркестрации. Каталог поддерживает ключи кластеризации для лучшей оптимизации раскладки данных и полностью интегрирован в интерфейс и средства запросов Dremio, что упрощает регистрацию таблиц Iceberg, управление ими и обращение к ним.

Каталог Dremio встроен во все корпоративные развёртывания Dremio. Отдельная инфраструктура для операций каталога не нужна. Каждую подпапку каталога можно сопоставить со своим хранилищем, а нативные средства контроля доступа Dremio беспрепятственно распространяются на все управляемые таблицы и представления.

Сильные стороны:

Встроен и полностью управляется внутри развёртываний Dremio
Работает на Apache Polaris, обеспечивая широкую совместимость
Безопасность и управление метаданными корпоративного уровня
Автоматизированное обслуживание Iceberg и настройка производительности

Ограничения:

Требует внедрения платформы Dremio (хотя с каталогом можно использовать и другие движки)
Ограниченная гибкость каталога за пределами экосистемы Dremio

Каталог Dremio хорошо подходит организациям, стандартизирующимся на платформе Dremio и стремящимся минимизировать издержки на управление каталогом. Он даёт готовый к промышленной эксплуатации совместимый каталог, упрощающий внедрение Iceberg и ускоряющий выпуск продуктов данных.

7.4.10 Snowflake Open Catalog

Snowflake Open Catalog - полностью управляемая реализация спецификации Apache Iceberg REST Catalog, размещённая в инфраструктуре Snowflake и работающая на Apache Polaris. Хотя её сопровождает Snowflake, вы не ограничены вычислительным движком Snowflake. Внешние движки запросов - Apache Spark, Flink, Trino или Dremio - могут подключаться к Open Catalog через REST-интерфейс, чтобы читать таблицы Iceberg и писать в них. Такая архитектура обеспечивает безопасный управляемый доступ к таблицам Iceberg, хранящимся в Amazon S3, Azure или Google Cloud, что делает её гибким вариантом для гибридных и многодвижковых сред.

Snowflake Open Catalog поддерживает REST-протокол Iceberg, позволяя любому совместимому движку, включая Apache Spark, Flink и Trino, обращаться к таблицам и управлять ими. Это соответствует принципу lakehouse о разделении хранения и вычислений и поощряет доступ множества движков к согласованным метаданным.

Snowflake Open Catalog поддерживает и внутренние, и внешние каталоги:

Внутренние каталоги полностью управляются Snowflake. Движки запросов читают и пишут в них, используя выданные временные учётные данные.
Внешние каталоги синхронизируются из других реализаций каталогов (например, Snowflake, Dremio Arctic). С точки зрения движков, отличных от Snowflake, они доступны только для чтения.

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

Snowflake Open Catalog использует централизованную модель RBAC:

Роли принципалов назначаются сервисным принципалам для движков вроде Spark или Flink.
Роли каталога определяют права на ресурсы каталога и выдаются ролям принципалов.

Такое разделение даёт детальный централизованный контроль доступа к метаданным и расположениям данных. Выдача временных учётных данных дополнительно упрощает безопасный доступ, динамически предоставляя движкам запросов временные учётные данные.

Snowflake Open Catalog рассчитан на отдачу данных из таблиц Iceberg в разные вычислительные среды. Пользователи настраивают сервисные подключения для каждого движка (приём через Flink, ETL на Spark, BI через Trino) и назначают им сервисные принципалы с ограниченными привилегиями. Такая структура обеспечивает безопасное многодвижковое взаимодействие с общим каталогом.

Сильные стороны:

Полностью управляемый сервис на стороне Snowflake, минимизирующий эксплуатационные издержки
REST-совместимость для межмашинной совместимости движков
Высокий уровень безопасности с интеграцией IAM и применением RBAC
Поддержка мультиоблачного хранения с динамической выдачей учётных данных

Ограничения:

Сейчас доступен только в коммерческих регионах, но не в государственных облаках
Ограниченный доступ на запись для внешних каталогов, синхронизируемых от других поставщиков
Запросы к API метаданных каталога тарифицируются

Snowflake Open Catalog - сильный вариант для предприятий, вложившихся в Snowflake и желающих унифицировать метаданные между инструментами, сохраняя контроль над данными в собственной облачной инфраструктуре. Открытость на основе REST, фундамент Polaris и встроенные средства безопасности делают его подходящим для масштабируемых управляемых развёртываний lakehouse на Iceberg.

7.4.11 Databricks Unity Catalog

Databricks Unity Catalog - единое решение Databricks для управления данными, метаданными и политиками доступа в рамках их платформы. Изначально спроектированный для централизованного контроля над таблицами Delta Lake, Unity Catalog теперь поддерживает чтение и запись таблиц Apache Iceberg, предлагая новый уровень совместимости организациям, которые используют Databricks, стандартизируясь при этом на Iceberg.

С Unity Catalog пользователи Databricks получают единообразный интерфейс управления структурированными и неструктурированными активами во всех рабочих пространствах. Он централизует контроль доступа, аудит, происхождение данных и их обнаружение через общий слой каталога, обеспечивая согласованный опыт управления для инженеров данных, аналитиков и команд машинного обучения. Сюда входит детализированный контроль доступа по идентичности и роли, применяемый в SQL, Python и других поддерживаемых языках.

Недавно добавленная нативная поддержка Iceberg расширяет возможности Unity Catalog за пределы Delta Lake. Она позволяет организациям регистрировать внешние таблицы Iceberg, хранящиеся в облачном объектном хранилище (например, S3 или ADLS), или создавать новые таблицы Iceberg прямо в ноутбуках и задачах Databricks. Это позволяет командам работать с общим lakehouse на Iceberg изнутри среды Databricks, сохраняя совместимость с внешними инструментами, которые тоже поддерживают формат Iceberg.

Возможности Unity Catalog в части Iceberg относительно новы, но развиваются быстро. Это делает Unity Catalog жизнеспособным вариантом для организаций, желающих стандартизировать управление и безопасность для нескольких форматов данных, включая Delta и Iceberg, не дробя эксплуатацию платформы.

Рассматривая Unity Catalog для Iceberg, организациям стоит задать себе такие вопросы:

Строится ли ваша существующая платформенная стратегия уже вокруг Databricks?
Нужны ли вам централизованное управление и отслеживание происхождения данных сразу для Delta и Iceberg?
Работаете ли вы в одном облаке, где размещаемая природа Unity Catalog соответствует вашей модели развёртывания?

Поддержка Iceberg в Unity Catalog отражает более широкий отраслевой тренд к открытым табличным форматам и совместимости. Пользователям Databricks она даёт удобный путь к внедрению Iceberg с сохранением единых средств контроля доступа, каталогизации и аудита.

7.5 Выбор подходящего каталога: оценка вариантов через сценарии

При широком выборе реализаций каталогов - от управляемых поставщиками сервисов и открытых проектов до лёгких встроенных библиотек - выбор подходящего каталога для вашего развёртывания Iceberg может оказаться нетривиальным. Списки возможностей полезны, но они редко охватывают весь спектр эксплуатационных, архитектурных и стратегических соображений, возникающих при проектировании lakehouse.

Вместо того чтобы предписывать единственный «лучший» каталог, этот раздел проходит по набору иллюстративных сценариев. Эти примеры помогут очертить круг вопросов и компромиссов, возникающих при реальном выборе каталога. Они показывают, как на выбор влияют требования к управлению данными, предпочтения по инфраструктуре, навыки команды, облачная среда и чувствительность к затратам.

Важно: эти сценарии не рекомендации и не одобрение конкретных решений. Ландшафт каталогов продолжает быстро меняться, и лучший для вас вариант сегодня может отличаться от завтрашнего. Используйте приведённые примеры как модели для осмысления собственных требований и оценки сильных и слабых сторон каждого каталога.

Просматривая эти сценарии, учитывайте следующее:

Совместимость - поддерживает ли каталог спецификацию Iceberg REST Catalog? Можно ли использовать его из разных движков и языков?
Управление данными и контроль доступа - какие инструменты он даёт для защиты и аудита метаданных?
Эксплуатационные издержки - придётся ли вашей команде управлять каталогом самостоятельно или это можно передать поставщику?
Производительность и масштаб - выдержит ли он ваши требования к параллелизму и задержкам на масштабе?
Сообщество и поддержка - насколько активна экосистема и какой уровень поддержки доступен?

В следующих подразделах приведены конкретные примеры того, как разные варианты каталогов соотносятся с разными архитектурными контекстами и эксплуатационными целями.

7.5.1 Сценарий: команда данных среднего размера мигрирует с Hive

Аналитическая команда среднего размера в розничной компании мигрирует с унаследованного хранилища данных на Hadoop, использующего Hive Metastore (HMS). Команда опытна в Spark и уверенно управляет инфраструктурой. Сейчас они эксплуатируют локальный кластер Hadoop и планируют постепенный переход к облачному lakehouse в течение ближайших 12–18 месяцев.

Требования:

Беспрепятственная совместимость с существующим HMS
Поддержка таблиц Iceberg в Spark и Flink
Вариант с самостоятельным управлением на этапе первоначальной миграции
Минимум нарушений в текущих конвейерах данных
Путь к эволюции в сторону облачной и управляемой архитектуры

Оценка

Сначала команда рассматривает каталоги Hive и Hadoop. Каталог Hive даёт преимущество прямой интеграции с текущим HMS, позволяя начать использовать Iceberg без изменения слоя метаданных. Это снижает трение и риски при переходе.

Каталог Hadoop, напротив, предлагает простой самодостаточный подход с хранением метаданных прямо в файловой системе. Он избавляет от зависимости от HMS, но потребует больше изменений в процессах управления метаданными.

Итог

Команда решает начать с каталога Hive. Это позволяет использовать существующую инфраструктуру метаданных и внедрить Iceberg немедленно с минимальными нарушениями. По мере продвижения облачной миграции они планируют пересмотреть выбор каталога, рассматривая варианты вроде Nessie или Polaris ради более сильного управления данными, поддержки множества движков и совместимости через REST API. Такой поэтапный подход даёт гибкость и показывает, как выбор каталога может меняться вслед за архитектурой и требованиями к управлению данными.

7.5.2 Сценарий: быстро растущий облачный стартап

Быстрорастущий финтех-стартап строит платформу данных с нуля на облачном стеке. Компания полностью полагается на управляемые сервисы и ставит во главу угла скорость, масштабируемость и управляемость. Они активно используют AWS, опираются на Spark и Flink для обработки и планируют добавить нагрузки ИИ с SageMaker и большими языковыми моделями.

Требования:

Полностью управляемое облачное решение для метаданных
Беспрепятственная интеграция с сервисами AWS
Поддержка чтения и записи из нескольких движков
Детализированный контроль доступа и проверяемость
Совместимость с REST ради будущей интеграции

Оценка

Команда рассматривает AWS Glue Data Catalog и каталоги на базе Polaris, такие как каталог Dremio. AWS Glue Data Catalog даёт глубокую интеграцию с AWS IAM, Lake Formation и сервисами Athena, EMR и Redshift. Его бессерверная модель и поддержка Apache Iceberg делают его естественным выбором для стартапа, желающего минимальных эксплуатационных издержек.

Они также изучают каталоги на базе Polaris за соответствие спецификации Iceberg REST и приверженность открытым стандартам. AWS Glue Data Catalog предлагает сильный детализированный контроль доступа через Lake Formation и поддерживает совместимость с множеством движков, но привязан к экосистеме AWS. Polaris, напротив, даёт независимый от облака, полностью управляемый REST-совместимый каталог, что привлекательно организациям, которым нужно согласованное управление метаданными у нескольких облачных провайдеров или которые предполагают выйти за пределы AWS в будущем.

Итог

Команда выбирает AWS Glue Data Catalog за нативную интеграцию с экосистемой AWS, встроенную поддержку Iceberg и полностью управляемую бессерверную работу. Это позволяет сосредоточиться на выпуске продуктов данных, не управляя инфраструктурой каталога. Но они также осознают важность облачной переносимости и предвидят необходимость обслуживать клиентов у разных облачных провайдеров. Поэтому они планируют вернуться к независимым от облака вариантам вроде Polaris или другим REST-совместимым каталогам по мере роста и диверсификации платформы.

7.5.3 Сценарий: транснациональная корпорация со строгим управлением данными

Транснациональная корпорация в сфере здравоохранения работает под строгими требованиями к локализации данных, приватности и комплаенсу. Её инфраструктура охватывает несколько регионов и облачных провайдеров: часть нагрузок локальна, часть в облаке. Она использует разнообразные движки, включая Spark, Trino и Flink, и ей нужно согласованное управление метаданными во всех средах.

Требования:

Межрегиональное геораспределённое управление метаданными
Строгий контроль доступа и аудит
Поддержка множества движков и типов данных
Открытые API и расширяемость для собственных интеграций
Федеративный доступ к разнородным источникам метаданных

Оценка

Организация оценивает Apache Gravitino, дающий геораспределённое федеративное озеро метаданных с поддержкой метаданных реляционных, файловых, событийных и ИИ-активов. Единый слой управления и реализация REST-каталога делают его подходящим для сложных корпоративных сред. Организация также рассматривает Lakekeeper и Nessie, но широкая модель метаданных и экосистема коннекторов Gravitino лучше отвечают задачам федеративного управления.

Итог

Они выбирают Apache Gravitino за федеративные возможности, единую модель доступа и расширяемую систему управления данными. Gravitino позволяет им консолидировать метаданные между регионами и обеспечивать согласованные политики, поддерживая при этом таблицы Iceberg через спецификацию REST Catalog. Поддержка разных доменов метаданных (включая модели и потоки) помогает объединить управление активами данных и ИИ.

7.5.4 Сценарий: SaaS-стартап, ставящий во главу угла простоту эксплуатации

SaaS-стартап с небольшой командой данных строит новую аналитическую платформу на AWS. Они хотят использовать Apache Iceberg ради производительности и возможностей управления данными, но у них ограничены ресурсы на администрирование инфраструктуры. Их нагрузки в основном сводятся к пакетному приёму через Spark и SQL-аналитике через Athena.

Требования:

Полностью управляемый сервис каталога
Интеграция с нативными инструментами AWS (Athena, Redshift, Glue ETL)
Минимум настройки и эксплуатационных издержек
Нативная поддержка Apache Iceberg
Безопасный масштабируемый контроль доступа

Оценка

Они рассматривают AWS Glue Data Catalog как вариант по умолчанию: он глубоко интегрирован в экосистему AWS и теперь поддерживает Apache Iceberg через нативный Data Catalog и задачи Glue ETL. Он упрощает управление метаданными, поддерживает бессерверный ETL и беспрепятственно интегрируется с Athena и Redshift Spectrum. Они бегло рассматривают Lakekeeper и каталог JDBC, но те потребовали бы больше администрирования инфраструктуры.

Итог

Они выбирают AWS Glue Data Catalog за управляемый каталог и возможности ETL, позволяющие сосредоточиться на создании продуктов данных, а не на администрировании инфраструктуры метаданных. Команда ценит централизованное управление, обнаружение схем краулерами и беспрепятственный доступ к запросам через Athena.

7.5.5 Сценарий: крупное предприятие с мультиоблачной и федеративной моделью управления

Глобальная компания финансовых услуг работает в нескольких регионах и в разных регуляторных юрисдикциях. Она внедряет стратегию lakehouse на Apache Iceberg, чтобы модернизировать аналитическую платформу, обеспечив при этом строгое управление данными и соответствие требованиям. Её нагрузки охватывают Spark, Flink и Trino, и ей нужно решение для каталога, поддерживающее распределённые развёртывания, единое управление и доступ разных движков в разных облаках.

Требования:

Федеративное управление метаданными между регионами и облаками
Поддержка множества движков запросов и типов метаданных
Централизованные безопасность и управление данными
Совместимость через поддержку Iceberg REST
Открытый код и расширяемость

Оценка

Они оценивают Apache Gravitino за федеративную архитектуру и поддержку межрегионального управления метаданными. REST-совместимый каталог Gravitino и богатые возможности управления - контроль доступа, теги, единые интерфейсы - позволяют им единообразно управлять активами данных и ИИ. Поддержка разных коннекторов (Hive, Hudi, Iceberg, Kafka и других) и движков запросов соответствует их разнородной среде. Они также рассматривают Nessie и Polaris, но федеративная модель метаданных и расширяемость Gravitino лучше отвечают сложным регуляторным и организационным требованиям.

Итог

Они внедряют Apache Gravitino, чтобы создать федеративное озеро метаданных с согласованным управлением и обнаружением данных для глобальных команд. REST API Gravitino позволяет интегрироваться со всеми их движками, а поддержка метаданных моделей и обмена сообщениями хорошо готовит их к будущим инициативам в области ИИ.

7.5.6 Сценарий: финансовая компания, которой нужно ежедневное клонирование окружений для стресс-тестирования

Финансовое учреждение ежедневно проводит регуляторные стресс-тесты, моделирующие неблагоприятные рыночные условия и анализирующие устойчивость компании. Ради точности и изоляции эти симуляции должны работать на точном снимке промышленных данных, не мешая работе в реальном времени. Команде нужен способ быстро создавать и обслуживать тестовые окружения без физического копирования больших наборов данных, что было бы долго и дорого.

Требования:

Возможность клонировать всё промышленное окружение без дублирования данных
Путешествия во времени и версионирование ради воспроизводимости
Лёгкая изоляция метаданных на основе веток
Совместимость с существующим конвейером на Spark
Поддержка непрерывной интеграции с версионируемыми данными

Оценка

Они рассматривают несколько вариантов каталогов. AWS Glue Data Catalog и Polaris поддерживают интеграцию по REST, но ни один не даёт семантики ветвления и тегов на уровне каталога, отвечающей их потребности в клонировании нескольких таблиц без копирования. Apache Gravitino и Lakekeeper обеспечивают федерацию метаданных и совместимость с REST, но не сосредоточены на семантике ветвления.

Nessie выделяется возможностями ветвления и тегирования в духе Git, позволяющими команде создавать изолированные представления метаданных без дублирования данных. С Nessie они могут ответвляться от промышленных данных в начале каждого цикла тестирования, запускать симуляции на ветке и затем отбрасывать или сливать результаты. Это даёт точное и экономичное стресс-тестирование и эксперименты.

Итог

Компания внедряет Nessie для управления своим каталогом Iceberg. Они автоматизируют создание ежедневных веток для стресс-тестирования и встраивают жизненный цикл веток в процессы CI/CD. Это позволяет поддерживать согласованные тестовые окружения, выполнять требования проверяемости и совершенствовать процедуры тестирования, не затрагивая промышленные данные.

Примечание. Этот сценарий показывает, как версионирование данных и изоляция на основе веток могут быть критичны там, где важнее всего воспроизводимость, изоляция и скорость. Nessie даёт изящное решение этих задач.

7.5.7 Сценарий: поэтапная миграция на Iceberg с федерацией запросов к унаследованным системам

Крупное предприятие проводит стратегическую миграцию со смеси унаследованных хранилищ данных и data lake на Hadoop к lakehouse на Apache Iceberg. Их экосистема данных включает системы Hive, Teradata и Oracle, а миграция спланирована поэтапно, чтобы минимизировать сбои в бизнесе. В ходе перехода компания должна сохранять непрерывность аналитики, позволяя пользователям обращаться к данным и в унаследованных системах, и в Iceberg.

Требования:

Федерация запросов к нескольким системам, включая Hive, Oracle и Iceberg
Центральный каталог, упрощающий управление метаданными на время перехода
Возможность управлять продуктами данных на Iceberg и показывать их
Беспрепятственный доступ для потребителей данных на всех этапах миграции
Минимум эксплуатационных издержек со встроенными средствами управления данными

Оценка

Они изучают несколько вариантов каталогов. Каталоги Hadoop и JDBC не подходят, поскольку не дают федерации запросов и инструментов управления данными. Polaris и Gravitino обеспечивают хорошую совместимость с REST, но потребуют дополнительной интеграционной работы под нужды федерации запросов. AWS Glue Data Catalog предлагает интеграцию с ETL, но лишён встроенной федерации по разнородным источникам.

Каталог Dremio, работающий на Apache Polaris, оказывается практичным выбором. Он поддерживает совместимость с Iceberg по REST и тесно интегрирован с движком запросов Dremio, который отлично федерирует запросы к разрозненным источникам. Это позволяет аналитикам создавать единые представления, охватывающие и унаследованные системы, и таблицы Iceberg, не перемещая и не дублируя данные на ранних этапах миграции.

Итог

Предприятие принимает каталог Dremio как основу миграции к lakehouse. Dremio позволяет им постепенно подключать таблицы Iceberg, сохраняя аналитикам доступ к унаследованным системам через единый SQL-интерфейс. Благодаря встроенным средствам управления - безопасности на уровне строк, происхождению данных и поддержке ключей кластеризации - каталог Dremio обеспечивает соответствие требованиям и сопровождаемость на всём протяжении перехода.

7.5.8 Сценарий: облегчённое внедрение lakehouse с каталогом Hadoop и Python

Растущий стартап работал в основном с базами данных уровня приложения вроде PostgreSQL и SQLite. По мере того как объёмы данных начали превышать то, с чем эти системы справляются эффективно, особенно в аналитических сценариях, компания начала искать варианты масштабирования инфраструктуры данных. Команда обсуждает переход на традиционное облачное хранилище данных, но опасается привязки к поставщику, роста затрат и негибкого инструментария.

Требования:

Малозатратный и недорогой вход в масштабируемую аналитику
Полный контроль над метаданными и хранилищем
Возможность работать прямо с машин разработчиков
Предпочтение открытым стандартам и инструментам, соответствующим их инженерной культуре
Сильная поддержка Python, поскольку большая часть их инженерии данных на Python

Оценка

Они изучают облачные хранилища данных, но модели ценообразования и ограниченная прозрачность разделения хранения и вычислений не отвечают их целям. Каталоги корпоративного класса вроде Polaris и Glue дают богатые возможности, но больше, чем нужно команде на старте. REST-каталоги также потребовали бы больше инфраструктуры для развёртывания и настройки.

Вместо этого команда обнаруживает, что каталог Hadoop, встроенный в Apache Iceberg, позволяет обращаться к таблицам Iceberg напрямую по путям в файловой системе. В сочетании с PyIceberg они могут начать создавать таблицы Iceberg на Amazon S3 и управлять ими, не разворачивая дополнительных сервисов.

Они могут запускать простые скрипты на Python на своих ноутбуках, выполняя преобразования данных и операции с метаданными и сохраняя результаты в формате Iceberg прямо в S3. Такая схема даёт масштабируемые возможности открытого табличного формата при минимальной эксплуатационной сложности.

Итог

Стартап принимает архитектуру lakehouse с каталогом Hadoop и PyIceberg как начальным каталогом и способом доступа. Он хранит данные в формате Iceberg в имеющемся облачном хранилище и обращается к ним через инструменты и библиотеки Python. Это решение позволяет масштабироваться постепенно, а при необходимости позже перейти на REST-каталог или каталог корпоративного уровня, не меняя раскладку таблиц и не переписывая конвейеры.

7.6 Управление доступом на основе каталога

По мере того как lakehouse на Iceberg развиваются в сторону многодвижковых, многокомандных и мультиоблачных развёртываний, контроль доступа всё активнее переносится из систем хранения и отдельных движков запросов в сам каталог. Это принципиальное изменение по сравнению с ранними архитектурами data lake, где права приходилось дублировать и синхронизировать между политиками объектного хранилища, ролями конкретных движков и учётными данными пользователей.

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

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

Эта модель также улучшает переносимость и совместимость. Поскольку решения о доступе принимаются на слое каталога, множество движков может работать с одними и теми же таблицами Iceberg, не имея каждый собственной модели прав и стратегии управления пользователями. Движки сосредоточены на выполнении запросов, а каталог последовательно применяет правила управления по всем путям доступа.

При этом контроль доступа на основе каталога всё ещё развивается. Сегодня большинство каталогов сосредоточены на крупногранулярных механизмах: правах на уровне пространств имён и таблиц. Детализированный контроль доступа - безопасность на уровне строк или столбцов - пока не стандартизирован в экосистеме Iceberg. Активные предложения и текущая работа в сообществах Apache Iceberg и Apache Polaris нацелены на то, чтобы в будущем определить совместимые механизмы описания и применения политик FGAC на уровне каталога.

Пока такие стандарты не утверждены и широко не приняты, лучшая практика - переносить в каталог как можно больше контроля доступа, признавая при этом несколько необходимых исключений. При использовании систем хранения или каталогов без поддержки выдачи временных учётных данных часть контроля доступа по-прежнему придётся обеспечивать на слое хранения. Точно так же отдельные детализированные политики могут временно оставаться внутри движков запросов. Их следует рассматривать как переходные меры, а не как долгосрочные архитектурные цели.

На практике направление ясно: каталог становится плоскостью управления безопасностью lakehouse. Централизация RBAC, динамическая выдача ограниченных учётных данных и минимизация прямого доступа к хранилищу упрощают управление, повышают безопасность и закладывают основу для совместимого детализированного контроля доступа во всей экосистеме Iceberg.

Итоги

Слой каталога служит опорой метаданных lakehouse на Apache Iceberg, обеспечивая надёжное обнаружение данных, управление ими и совместимость.
Встроенные каталоги вроде Hadoop и JDBC дают простоту, но ограниченную гибкость в масштабировании и интеграции.
Открытые и самостоятельно управляемые каталоги - Polaris, Gravitino, Nessie и Lakekeeper - предоставляют кастомизацию и продвинутые возможности для сложных развёртываний.
Управляемые поставщиками каталоги вроде AWS Glue Data Catalog, каталога Dremio и Snowflake Open Catalog дают готовую инфраструктуру со встроенной безопасностью и корпоративной поддержкой.
Спецификация Apache Iceberg REST Catalog обеспечивает стандартизованное взаимодействие между вычислительными движками и каталогами, улучшая совместимость между движками.
Выбор каталога должен соответствовать операционной модели вашей платформы, требованиям комплаенса, облачной стратегии и планам роста.
Независимые от облака каталоги становятся всё важнее для организаций, планирующих мультиоблачные или гибридные развёртывания.
Технологии каталогов и интеграции быстро развиваются, поэтому пересматривать принятые решения по мере взросления архитектуры необходимо.