Apache Iceberg se ha convertido en una opción popular para gestionar grandes conjuntos de datos con flexibilidad y escalabilidad. Los catálogos son fundamentales para la funcionalidad de Iceberg, lo cual es vital en la organización de tablas, consistencia y gestión de metadatos. Este artículo explorará qué son los catálogos de Iceberg, sus diversas implementaciones, casos de uso y configuraciones, proporcionando una comprensión de las soluciones de catálogo más adecuadas para diferentes casos de uso.
¿Qué es un catálogo de Iceberg?
En Iceberg, un catálogo es responsable de gestionar las rutas de las tablas, apuntando a los archivos de metadatos actuales que representan el estado de una tabla. Esta arquitectura es esencial porque permite la atomicidad, consistencia y consultas eficientes al garantizar que todos los lectores y escritores accedan al mismo estado de la tabla. Diferentes implementaciones de catálogos almacenan estos metadatos de diversas formas, desde sistemas de archivos hasta servicios de metastore especializados.
Responsabilidades principales de un catálogo de Iceberg
Las responsabilidades fundamentales de un catálogo de Iceberg son:
- Mapeo de rutas de tablas: Vincular una ruta de tabla (por ejemplo, “db.tabla”) al archivo de metadatos correspondiente.
- Soporte de operaciones atómicas: Garantizar el estado consistente de la tabla durante lecturas/escrituras concurrentes.
- Gestión de metadatos: Almacenar y gestionar los metadatos, garantizando su accesibilidad y consistencia.
Los catálogos Iceberg ofrecen diversas implementaciones para adaptarse a diversas arquitecturas de sistemas y requisitos de almacenamiento. Veamos estas implementaciones y su idoneidad para diferentes entornos.
Tipos de Catálogos Iceberg
1. Catálogo Hadoop
El Catálogo Hadoop suele ser el más fácil de configurar, ya que solo requiere un sistema de archivos. Este catálogo gestiona metadatos buscando el archivo de metadatos más reciente en el directorio de una tabla según las marcas de tiempo de los archivos. Sin embargo, debido a su dependencia de operaciones atómicas a nivel de archivo (que algunos sistemas de almacenamiento como S3 no tienen), el catálogo Hadoop puede no ser adecuado para entornos de producción donde las escrituras concurrentes son comunes.
Ejemplo de Configuración
Para configurar el catálogo Hadoop con 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
Una forma diferente de establecer el catálogo en el trabajo de Spark mismo:
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")
En el ejemplo anterior, establecemos el nombre del catálogo en “local” como se configura en Spark “spark.sql.catalog.local“. Esto puede ser una elección de su preferencia.
Pros:
- Configuración sencilla, no se requiere un metastore externo.
- Ideal para entornos de desarrollo y pruebas.
Contras:
- Limitado a sistemas de archivos individuales (por ejemplo, un único bucket de S3).
- No recomendado para producción
2. Catálogo Hive
El catálogo Hive aprovecha el Metastore Hive para gestionar la ubicación de metadatos, lo que lo hace compatible con numerosas herramientas de big data. Este catálogo es ampliamente utilizado para producción debido a su integración con la infraestructura existente basada en Hive y su compatibilidad con múltiples motores de consulta.
Ejemplo de configuración
Para usar el catálogo Hive en 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>
Pros:
- Alta compatibilidad con herramientas de big data existentes.
- Agnóstico de la nube y flexible en configuraciones locales y en la nube.
Contras:
- Requiere mantener un Hive metastore, lo que puede agregar complejidad operativa.
- Carece de soporte de transacciones multi-tabla, limitando la atomicidad para operaciones entre tablas
3. Catálogo AWS Glue
El Catálogo AWS Glue es un catálogo de metadatos gestionado proporcionado por AWS, lo que lo hace ideal para organizaciones fuertemente invertidas en el ecosistema de AWS. Maneja metadatos de tablas Iceberg como propiedades de tabla dentro de AWS Glue, permitiendo una integración sin problemas con otros servicios de AWS.
Ejemplo de configuración
Para configurar AWS Glue con Iceberg en 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
Pros:
- Servicio gestionado, reduciendo la infraestructura y los costos de mantenimiento.
- Integración sólida con servicios de AWS.
Contras:
- Específico de AWS, lo que limita la flexibilidad entre nubes.
- Sin soporte para transacciones multi-tabla
4. Catálogo de Proyecto Nessie
El proyecto Nessie ofrece un enfoque de “datos como código”, permitiendo el control de versiones de datos. Con sus capacidades de ramificación y etiquetado similares a Git, Nessie permite a los usuarios gestionar ramas de datos de manera similar al código fuente. Proporciona un marco robusto para transacciones de múltiples tablas y declaraciones múltiples.
Ejemplo de Configuración
Para configurar Nessie como el catálogo:
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>
Pros:
- Proporciona funcionalidades de “datos como código” con control de versiones.
- Soporta transacciones de múltiples tablas.
Contras:
- Requiere autoalojamiento, añadiendo complejidad a la infraestructura.
- Soporte limitado de herramientas en comparación con Hive o AWS Glue
5. Catálogo JDBC
El Catálogo JDBC te permite almacenar metadatos en cualquier base de datos compatible con JDBC, como PostgreSQL o MySQL. Este catálogo es independiente de la nube y asegura alta disponibilidad al utilizar sistemas RDBMS confiables.
Ejemplo de Configuración
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>
Pros:
- Fácil de configurar con la infraestructura RDBMS existente.
- Alta disponibilidad e independiente de la nube.
Contras:
- No hay soporte para transacciones de múltiples tablas.
- Aumenta las dependencias de los controladores JDBC para todas las herramientas de acceso
6. Catálogo Snowflake
Snowflake ofrece un sólido soporte para tablas Apache Iceberg, permitiendo a los usuarios aprovechar la plataforma de Snowflake como catálogo Iceberg. Esta integración combina el rendimiento y la semántica de consulta de Snowflake con la flexibilidad del formato de tabla abierto de Iceberg, lo que permite una gestión eficiente de grandes conjuntos de datos almacenados en almacenamiento en la nube externo. Consulte la documentación de snowflake para más configuraciones en el enlace
Pros:
- Integración sin fisuras: Combina el rendimiento y las capacidades de consulta de Snowflake con el formato de tabla abierto de Iceberg, facilitando la gestión eficiente de datos.
- Soporte completo de plataforma: Proporciona acceso completo de lectura y escritura, junto con características como transacciones ACID, evolución de esquema y viaje en el tiempo.
- Mantenimiento simplificado: Snowflake maneja tareas de ciclo de vida como compactación y reducción de la sobrecarga operativa.
Contras:
- Restricciones de nube y región: El volumen externo debe estar en el mismo proveedor de nube y región que la cuenta de Snowflake, lo que limita las configuraciones entre nubes o regiones cruzadas.
- Limitación de formato de datos: Solo admite el formato de archivo Apache Parquet, lo que puede no coincidir con todas las preferencias de formato de datos organizativos.
- Restricciones del Cliente de Terceros: Impide que los clientes de terceros modifiquen datos en tablas Iceberg gestionadas por Snowflake, lo que podría afectar los flujos de trabajo que dependen de herramientas externas.
7. Catálogos basados en REST
Iceberg admite catálogos basados en REST para abordar varios desafíos asociados con las implementaciones de catálogos tradicionales.
Desafíos con los Catálogos Tradicionales
- Complejidad del Lado del Cliente: Los catálogos tradicionales a menudo requieren configuraciones y dependencias del lado del cliente para cada lenguaje (Java, Python, Rust, Go), lo que conduce a inconsistencias entre diferentes lenguajes de programación y motores de procesamiento. Lee más al respecto aquí.
- Limitaciones de Escalabilidad: Gestionar metadatos y operaciones de tabla a nivel de cliente puede introducir cuellos de botella, afectando el rendimiento y la escalabilidad en entornos de datos a gran escala.
Beneficios de Adoptar el Catálogo REST
- Integración Simplificada del Cliente: Los clientes pueden interactuar con el catálogo REST utilizando protocolos HTTP estándar, eliminando la necesidad de configuraciones o dependencias complejas.
- Escalabilidad: La arquitectura del catálogo REST en el lado del servidor permite la gestión de metadatos escalable, adaptándose a conjuntos de datos en crecimiento y patrones de acceso concurrentes.
- Flexibilidad: Las organizaciones pueden implementar lógica de catálogo personalizada en el lado del servidor, adaptando el catálogo REST para cumplir con requisitos específicos sin alterar las aplicaciones cliente.
Han surgido varias implementaciones del catálogo REST, cada una adaptada a necesidades organizativas específicas:
- Gravitino: Un servicio de catálogo REST Iceberg de código abierto que facilita la integración con Spark y otros motores de procesamiento, ofreciendo una configuración sencilla para gestionar tablas Iceberg.
- Tabular: Un servicio gestionado que proporciona una interfaz de catálogo REST, permitiendo a las organizaciones aprovechar las capacidades de Iceberg sin la sobrecarga de gestionar la infraestructura del catálogo. Más información en Tabular.
- Apache Polaris: Un catálogo de código abierto y con todas las funciones para Apache Iceberg, implementando la API REST para garantizar una interoperabilidad multi-motor sin problemas en plataformas como Apache Doris, Apache Flink, Apache Spark, StarRocks y Trino. Más información en GitHub.
Una de mis formas favoritas y sencillas de probar el catálogo REST con tablas Iceberg es utilizando una implementación REST en Java simple. Por favor, consulta el enlace de GitHub aquí.
Conclusión
Seleccionar el catálogo de Apache Iceberg apropiado es crucial para optimizar tu estrategia de gestión de datos. Aquí tienes un resumen conciso para guiar tu decisión:
- Catálogo de Hadoop: Mejor adecuado para entornos de desarrollo y prueba debido a su simplicidad. Sin embargo, pueden surgir problemas de consistencia en escenarios de producción con escrituras concurrentes.
- Catálogo de Hive Metastore: Ideal para organizaciones con infraestructura de Hive existente. Ofrece compatibilidad con una amplia gama de herramientas de big data y soporta operaciones de datos complejas. Sin embargo, mantener un servicio de Hive Metastore puede agregar complejidad operativa.
- Catálogo de AWS Glue: Óptimo para aquellos que están fuertemente invertidos en el ecosistema de AWS. Proporciona integración fluida con los servicios de AWS y reduce la necesidad de servicios de metadatos autogestionados. Sin embargo, es específico de AWS, lo que puede limitar la flexibilidad entre nubes.
- Catálogo JDBC: Adecuado para entornos que prefieren bases de datos relacionales para el almacenamiento de metadatos, permitiendo el uso de cualquier base de datos compatible con JDBC. Esto ofrece flexibilidad y aprovecha la infraestructura existente de RDBMS, pero puede introducir dependencias adicionales y requerir una gestión cuidadosa de las conexiones a la base de datos.
- Catálogo REST: Ideal para escenarios que requieren una API estandarizada para operaciones de catálogo, mejorando la interoperabilidad entre diversos motores de procesamiento y lenguajes. Desacopla los detalles de implementación del catálogo de los clientes, pero requiere configurar un servicio REST para manejar las operaciones del catálogo, lo que puede agregar complejidad inicial en la configuración.
- Catálogo del Proyecto Nessie: Esto es perfecto para organizaciones que necesitan control de versiones sobre sus datos, similar a Git. Soporta ramificación, etiquetado y transacciones de múltiples tablas. Ofrece capacidades robustas de gestión de datos, pero requiere desplegar y gestionar el servicio Nessie, lo que puede añadir una carga operativa.
Entender estas opciones de catálogo y sus configuraciones te permitirá tomar decisiones informadas y optimizar la configuración de tu lago de datos o casa de lago para satisfacer las necesidades específicas de tu organización.
Source:
https://dzone.com/articles/iceberg-catalogs-a-guide-for-data-engineers