Каталоги Iceberg: инструкция для дата-инженеров
Узнайте о каталогах Apache Iceberg, их типах, конфигурациях и решениях для управления метаданными и большими массивами данных в различных средах.
Apache Iceberg стал популярным решением по управлению большими массивами данных. Каталоги занимают центральное место в функциональности Iceberg, что очень важно для эффективной организации таблиц, обеспечения их согласованности и управления метаданными. В этой статье мы рассмотрим, что такое каталоги Iceberg, их различные реализации, сценарии использования и конфигурации.
Что такое каталог Iceberg?
В Iceberg каталог отвечает за управление путями к таблицам, указывая на текущие файлы метаданных, которые представляют состояние таблицы. Такая архитектура очень важна, поскольку именно она обеспечивает атомарность, согласованность и эффективность запросов, гарантируя, что все читатели и писатели обращаются к одному и тому же состоянию таблицы. Различные реализации каталогов хранят эти метаданные различными способами, от файловых систем до специализированных сервисов метахранилищ.
Ключевые функции каталога Iceberg
За что ответственны каталоги Iceberg:
- Сопоставление путей к таблицам: Связывание пути к таблице (например, «db.table») с соответствующим файлом метаданных.
- Поддержка атомарных операций: Обеспечение неизменного состояния таблицы при одновременном чтении/записи.
- Управление метаданными: Хранение и управление метаданными, обеспечение доступности и согласованности.
Каталоги Iceberg предлагаются различные варианты реализации для различных системных архитектур и требований к хранению данных. Давайте рассмотрим эти реализации и их пригодность для различных сред.
Типы каталогов Iceberg
1. Каталог Hadoop
Каталог Hadoop самый простой в настройке, для него требуется только файловая система. Этот каталог управляет метаданными путем поиска самого последнего файла метаданных в каталоге таблицы на основе временных меток файлов. Однако из-за зависимости от атомарных операций на уровне файлов (которые отсутствуют в некоторых системах хранения, таких как S3) каталог Hadoop может не подойти для производственных сред, где часто происходят одновременные записи.
Пример конфигурации
Настройка каталога Hadoop с помощью Apache Spark:
spark-sql --packages org.apache.iceberg:iceberg-spark-runtime-3.3_2.12:0.14.0 \--conf spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions \--conf spark.sql.catalog.my_catalog=org.apache.iceberg.spark.SparkCatalog \--conf spark.sql.catalog.my_catalog.type=hadoop \--conf spark.sql.catalog.my_catalog.warehouse=file:///D:/sparksetup/iceberg/spark_warehouse
Другой способ задать каталог в самом задании spark:
SparkConf sparkConf = new SparkConf()
.setAppName("Example Spark App").setMaster("local[*]").set("spark.sql.extensions","org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions").set("spark.sql.catalog.local","org.apache.iceberg.spark.SparkCatalog").set("spark.sql.catalog.local.type","hadoop").set("spark.sql.catalog.local.warehouse", "file:///D:/sparksetup/iceberg/spark_warehouse")
В приведенном выше примере мы задали имя каталога «local», как настроено в spark «spark.sql.catalog.local». Вы можете использовать любое другое имя.
За:
- Простая настройка, не требуется внешнего метахранилища.
- Идеально подходит для сред разработки и тестирования.
Против:
- Ограничение на одиночные файловые системы (например, одно ведро S3).
- Не рекомендуется для производственных сред
2. Каталог Hive
Каталог Hive использует метахранилище Hive для управления размещением метаданных, что делает его совместимым с многочисленными инструментами для работы с большими данными. Этот каталог широко используется в производстве благодаря его интеграции с существующей инфраструктурой на базе Hive и совместимости с различными механизмами запросов.
Пример настройки
Для использования каталога Hive в Spark:
spark-sql --packages org.apache.iceberg:iceberg-spark-runtime-3.3_2.12:0.14.0 \--conf spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions \--conf spark.sql.catalog.my_catalog=org.apache.iceberg.spark.SparkCatalog \--conf spark.sql.catalog.my_catalog.type=hive \--conf spark.sql.catalog.my_catalog.uri=thrift://<metastore-host>:<port>
За:
- Высокая совместимость с существующими инструментами для работы с большими данными.
- Гибкость при использовании локальных и облачных систем.
Против:
- Требуется поддержка метахранилища Hive, что может усложнить работу.
- Отсутствует поддержка многотабличных транзакций, что ограничивает атомарность операций над таблицами.
3. Каталог AWS Glue
Каталог AWS Glue - это управляемый каталог метаданных, предоставляемый AWS, что делает его идеальным для организаций, активно инвестирующих в экосистему AWS. Он обрабатывает метаданные таблиц Iceberg как свойства таблиц в AWS Glue, обеспечивая бесшовную интеграцию с другими сервисами AWS.
Пример настройки
Для настройки AWS Glue с помощью Iceberg в Spark воспользуйтесь следующей командой:
spark-sql --packages org.apache.iceberg:iceberg-spark-runtime-x.x_x.xx:x.x.x,software.amazon.awssdk:bundle:x.xx.xxx \--conf spark.sql.catalog.my_catalog=org.apache.iceberg.spark.SparkCatalog \--conf spark.sql.catalog.my_catalog.catalog-impl=org.apache.iceberg.aws.glue.GlueCatalog \--conf spark.sql.catalog.my_catalog.io-impl=org.apache.iceberg.aws.s3.S3FileIO \--conf spark.hadoop.fs.s3a.access.key=$AWS_ACCESS_KEY \--conf spark.hadoop.fs.s3a.secret.key=$AWS_SECRET_ACCESS_KEY
За:
- Управляемый сервис, снижающий затраты на инфраструктуру и обслуживание.
- Стабильная интеграция с сервисами AWS.
Против:
- Заточен на AWS, что ограничивает гибкость при работе с другими решениями и облаками.
- Отсутствует поддержка многотабличных транзакций
4. Каталог Project Nessie
Project Nessie предлагает подход «данные как код», позволяющий контролировать версии данных. Благодаря возможностям тегирования, подобным Git, Nessie позволяет свлоим пользователям управлять ветвями данных по аналогии с исходным кодом. Она обеспечивает надежную основу для работы с несколькими таблицами и транзакциями.
Пример конфигурации
Настройка Nessie как каталога:
spark-sql --packages "org.apache.iceberg:iceberg-spark-runtime-x.x_x.xx:x.x.x" \
--conf spark.sql.catalog.my_catalog=org.apache.iceberg.spark.SparkCatalog \--conf spark.sql.catalog.my_catalog.catalog-impl=org.apache.iceberg.nessie.NessieCatalog \--conf spark.sql.catalog.my_catalog.uri=http://<host>:<port>
За:
- Обеспечивает функциональность «данные как код» с контролем версий.
- Поддержка многотабличных транзакций.
Против:
- Требуется самостоятельное размещение, что усложняет инфраструктуру.
- Ограниченная инструментальная поддержка по сравнению с Hive или AWS Glue
5. Каталог JDBC
JDBC-каталог позволяет хранить метаданные в любой JDBC-совместимой базе данных, например, PostgreSQL или MySQL. Этот каталог не зависит от облака и обеспечивает высокую доступность за счет использования надежных систем РСУБД.
Пример конфигурации
spark-sql --packages org.apache.iceberg:iceberg-spark-runtime-x.x_x.xx:x.x.x \
--conf spark.sql.catalog.my_catalog=org.apache.iceberg.spark.SparkCatalog \--conf spark.sql.catalog.my_catalog.catalog-impl=org.apache.iceberg.jdbc.JdbcCatalog \--conf spark.sql.catalog.my_catalog.uri=jdbc:<protocol>://<host>:<port>/<database> \--conf spark.sql.catalog.my_catalog.jdbc.user=<username> \--conf spark.sql.catalog.my_catalog.jdbc.password=<password>
За:
- Легко настраивается на существующую инфраструктуру РСУБД.
- Высокая доступность, возможность интеграции с облачными системами.
Против:
- Нет поддержки многотабличных транзакций.
- Зависимость от драйверов JDBC
6. Каталог Snowflake
Snowflake предлагает поддержку таблиц Apache Iceberg, позволяя пользователям использовать платформу Snowflake в качестве каталога Iceberg. Эта интеграция сочетает в себе производительность и семантику запросов Snowflake с гибкостью открытого формата таблиц Iceberg, что позволяет эффективно управлять большими массивами данных, хранящимися во внешних облачных хранилищах.
За:
- Бесшовная интеграция: Сочетает производительность и возможности запросов Snowflake с открытым форматом таблиц Iceberg, что способствует эффективному управлению данными.
- Полная поддержка платформы: Обеспечивает полный доступ для чтения и записи, а также такие функции, как транзакции ACID, эволюция схемы и перемещение во времени.
- Упрощенное обслуживание: Snowflake решает задачи жизненного цикла, такие как уплотнение и снижение операционных накладных расходов.
Против:
- Облачные и региональные ограничения: Внешний том должен находиться в том же облачном провайдере и регионе, что и учетная запись Snowflake, что ограничивает конфигурации с пересечением облаков и регионов.
- Ограничение формата данных: Поддерживается только Apache Parquet.
- Ограничения сторонних клиентов: Запрещает сторонним клиентам изменять данные в управляемых Snowflake таблицах Iceberg, что может повлиять на рабочие процессы, основанные на использовании внешних инструментов.
7. Каталоги на основе REST
Iceberg поддерживает каталоги на основе REST, что позволяет решить несколько проблем, связанных с традиционными каталогами.
Трудности, связанные с традиционными каталогами
- Сложность на стороне клиента: Традиционные каталоги часто требуют конфигурации на стороне клиента и зависимостей для каждого языка (Java, Python, Rust, Go), что приводит к несоответствиям между различными языками программирования и процессорами.
- Ограничения масштабируемости: Управление метаданными и операциями с таблицами на уровне клиента может создавать узкие места, влияя на производительность и масштабируемость в крупномасштабных средах данных.
Преимущества использования каталога REST
- Упрощенная интеграция клиентов: Клиенты могут взаимодействовать с REST-каталогом, используя стандартные протоколы HTTP, что устраняет необходимость в сложных конфигурациях или зависимостях.
- Масштабируемость: Серверная архитектура REST-каталога обеспечивает масштабируемое управление метаданными, позволяя учитывать растущие наборы данных и одновременные схемы доступа.
- Гибкость: Организации могут реализовать пользовательскую логику каталога на стороне сервера, адаптируя REST-каталог к конкретным требованиям без изменения клиентских приложений.
Появилось несколько реализаций каталога REST, каждая из которых отвечает специфическим организационным потребностям:
- Gravitino: REST-каталог Iceberg с открытым исходным кодом, который облегчает интеграцию со Spark и другими процессорами, предлагая простую настройку для управления таблицами Iceberg.
- Tabular: Управляемый сервис, предоставляющий интерфейс REST-каталога, позволяющий организациям использовать возможности Iceberg без лишних затрат на управление инфраструктурой каталога.
- Apache Polaris: Полнофункциональный каталог с открытым исходным кодом для Apache Iceberg, реализующий REST API для обеспечения беспрепятственного взаимодействия между такими платформами, как Apache Doris, Apache Flink, Apache Spark, StarRocks и Trino.
Один из моих любимых и простых способов попробовать 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, что может привести к дополнительным операционным издержкам.
Понимание этих вариантов каталога и их конфигураций позволит Вам сделать осознанный выбор и оптимизировать систему «озера данных» или «дома у озера» в соответствии с конкретными потребностями Вашей организации.
