Каталоги Iceberg: Руководство для инженеров данных

Учебники
AWS

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

Что такое каталог Iceberg?

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

Основные обязанности каталога Iceberg

Фундаментальные обязанности каталога Iceberg включают:

  1. Сопоставление путей таблиц: Связывание пути таблицы (например, “db.table”) с соответствующим метафайлом.
  2. Поддержка атомарных операций: Обеспечение согласованного состояния таблицы во время одновременных чтений/записей.
  3. Управление метаданными: Хранение и управление метаданными, обеспечивая доступность и согласованность.

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


Типы каталогов Iceberg

1. Каталог Hadoop

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

Пример конфигурации

Чтобы настроить каталог Hadoop с Apache Spark:

SQL

 

Другой способ установить каталог непосредственно в самом задании Spark:

SQL

 

В приведенном выше примере мы установили имя каталога на “local”, как настроено в Spark “spark.sql.catalog.local“. Это может быть вашим выбором имени.

Плюсы:

  • Простая настройка, не требуется внешнее хранилище метаданных.
  • Идеально подходит для разработки и тестирования.

Минусы:

  • Ограничен одной файловой системой (например, одним ведром S3).
  • Не рекомендуется для производственного использования

2. Каталог Hive

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

Пример конфигурации

Чтобы использовать каталог Hive в Spark:

SQL

 

Плюсы:

  • Высокая совместимость с существующими инструментами больших данных.
  • Независимость от облака и гибкость как для локальных, так и для облачных настроек.

Минусы:

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

3. Каталог AWS Glue

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

Пример конфигурации

Чтобы настроить AWS Glue с Iceberg в Spark:

SQL

 

Плюсы:

  • Управляемый сервис, снижающий накладные расходы на инфраструктуру и обслуживание.
  • Сильная интеграция с сервисами AWS.

Минусы:

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

4. Каталог Project Nessie

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

Пример конфигурации

Чтобы настроить Nessie в качестве каталога:

SQL

 

Плюсы:

  • Предоставляет функциональность «данные как код» с контролем версий.
  • Поддерживает многотабличные транзакции.

Минусы:

  • Требует самостоятельного хостинга, добавляя сложность инфраструктуры.
  • Ограниченная поддержка инструментов по сравнению с Hive или AWS Glue

5. JDBC Каталог

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

Пример конфигурации

SQL

 

Плюсы:

  • Легко настраивается с существующей инфраструктурой RDBMS.
  • Высокая доступность и независимость от облака.

Минусы:

  • Нет поддержки многотабличных транзакций.
  • Увеличивает зависимость от JDBC-драйверов для всех инструментов доступа

6. Каталог Snowflake

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

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

  • Бесшовная интеграция: Объединяет производительность и возможности запросов Snowflake с открытым форматом таблиц Iceberg, облегчая эффективное управление данными.
  • Полная поддержка платформы: Предоставляет полноценный доступ на чтение и запись, а также функции, такие как транзакции ACID, эволюция схемы и временные путешествия.
  • Упрощенное обслуживание: Snowflake обрабатывает задачи жизненного цикла, такие как компактация и сокращение операционной нагрузки.

Недостатки:

  • Ограничения облака и региона: Внешний объем должен находиться в том же облачном провайдере и регионе, что и учетная запись Snowflake, ограничивая конфигурации между облаками или регионами.
  • Ограничение формата данных: Поддерживает только формат файла Apache Parquet, который может не соответствовать всем предпочтениям организационного формата данных.
  • Ограничения сторонних клиентов: Запрещает сторонним клиентам изменять данные в таблицах Iceberg, управляемых Snowflake, что может повлиять на рабочие процессы, зависящие от внешних инструментов.

7. REST-ориентированные каталоги

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

Проблемы с традиционными каталогами

  1. Сложность на стороне клиента: Традиционные каталоги часто требуют конфигураций и зависимостей на стороне клиента для каждого языка (Java, Python, Rust, Go), что приводит к несоответствиям между различными языками программирования и движками обработки. Узнайте больше об этом здесь.
  2. Ограничения масштабируемости: Управление метаданными и операциями с таблицами на уровне клиента может создавать узкие места, влияя на производительность и масштабируемость в больших объемах данных.

Преимущества принятия REST каталога

  • Упрощенная интеграция с клиентом: Клиенты могут взаимодействовать с REST каталогом, используя стандартные HTTP протоколы, что устраняет необходимость в сложных конфигурациях или зависимостях.
  • Масштабируемость: Архитектура REST каталога на стороне сервера позволяет управлять метаданными с учетом масштабируемости, accommodating growing datasets and concurrent access patterns.
  • Гибкость: Организации могут реализовать кастомную логику каталога на серверной стороне, адаптируя REST каталог для удовлетворения конкретных требований без изменения клиентских приложений.

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

  • Gravitino: Открытый сервис REST каталога Iceberg, который упрощает интеграцию с Spark и другими движками обработки, предлагая простую настройку для управления таблицами Iceberg.
  • Tabular: Управляемый сервис, предоставляющий интерфейс REST каталога, позволяющий организациям использовать возможности Iceberg без дополнительных затрат на управление инфраструктурой каталога. Читайте больше на Tabular.
  • Apache Polaris: Открытый, полнофункциональный каталог для Apache Iceberg, реализующий REST API для обеспечения бесшовной многомеханической совместимости на таких платформах, как Apache Doris, Apache Flink, Apache Spark, StarRocks и Trino. Читайте больше на GitHub.

Один из моих любимых и простых способов попробовать REST каталог с таблицами Iceberg – это использование обычной реализации REST на Java. Пожалуйста, проверьте ссылку на GitHub здесь.

Заключение

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

  • Каталог Hadoop: Лучше всего подходит для разработки и тестирования из-за своей простоты. Однако в производственных сценариях с параллельной записью могут возникнуть проблемы с согласованностью.
  • Каталог Hive Metastore: Идеально подходит для организаций с существующей инфраструктурой Hive. Предлагает совместимость с широким спектром инструментов для обработки больших данных и поддерживает сложные операции с данными. Однако поддержка сервиса Hive Metastore может добавить операционной сложности.
  • Каталог AWS Glue: Оптимален для тех, кто сильно заинтересован в экосистеме AWS. Обеспечивает безшовную интеграцию с услугами AWS и уменьшает необходимость в самостоятельном управлении метаданными. Однако он ориентирован на AWS, что может ограничить гибкость кросс-облака.
  • Каталог JDBC: Подходит для сред, предпочитающих реляционные базы данных для хранения метаданных и позволяющий использовать любую базу данных, совместимую с JDBC. Это предлагает гибкость и использует существующую инфраструктуру СУБД, но может внести дополнительные зависимости и потребовать тщательного управления соединениями с базой данных.
  • Каталог REST: Идеален для сценариев, требующих стандартизированного API для операций с каталогом, улучшая совместимость между различными движками обработки и языками. Отделяет детали реализации каталога от клиентов, но требует настройки службы REST для обработки операций с каталогом, что может добавить сложности в начальной настройке.
  • Каталог проекта Nessie: Это идеально подходит для организаций, которым требуется контроль версий над своими данными, аналогично Git. Он поддерживает ветвление, тегирование и многотабличные транзакции. Он предоставляет надежные возможности управления данными, но требует развертывания и управления сервисом Nessie, что может добавить операционные расходы.

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

Source:
https://dzone.com/articles/iceberg-catalogs-a-guide-for-data-engineers