Apache Iceberg es un formato de código abierto de alto rendimiento para tablas analíticas masivas, que facilita el uso de tablas SQL para big data y la integración segura de esas tablas con motores como Apache Spark, Trino, Flink, Presto, Hive e Impala.
Además de su especificación de formato de tabla abierta, Iceberg también incluye un conjunto de API y bibliotecas que permiten a los motores de almacenamiento, de consulta y de ejecución interactuar sin problemas con las tablas que siguen ese formato.
El formato de tabla Iceberg se ha convertido en una parte integral del ecosistema de big data, en gran parte debido a su capacidad de proporcionar funciones que normalmente no están disponibles con otros formatos de tabla. Al utilizar una serie de metadatos guardados en cada tabla, Iceberg permite la evolución del esquema y de las particiones y la reversión de las versiones de la tabla sin necesidad de costosas reescrituras o migraciones de tablas. Es completamente independiente del sistema de almacenamiento, con soporte para varias fuentes de datos y sin dependencias del sistema de archivos.
Originalmente creado por ingenieros de datos de Netflix y Apple en 2017 para abordar las deficiencias de Apache Hive, Iceberg se hizo de código abierto y se donó a la Apache Software Foundation al año siguiente. Se convirtió en un proyecto Apache de primer nivel en 2020.
La velocidad, la eficiencia, la fiabilidad y la facilidad de uso general de Apache Iceberg ayudan a simplificar y coordinar el proceso de datos a cualquier escala. Estos puntos fuertes lo han convertido en el formato de tabla preferido por varios de los principales almacenes de datos, data lakes y lakehouses de datos, incluyendo IBM® watsonx.data, Netezza y Db2 Warehouse.
Manténgase al día sobre las tendencias más importantes e intrigantes del sector en materia de IA, automatización, datos y mucho más con el boletín Think. Consulte la Declaración de privacidad de IBM.
Iceberg es uno de los pocos formatos de tabla de código abierto que permite las transacciones ACID: intercambios de datos que preservan la precisión al garantizar la atomicidad, la coherencia, el aislamiento y la durabilidad.
La génesis de Iceberg fue un esfuerzo por abordar las limitaciones prácticas de las tablas Apache Hive en un entorno de gran data lake. Según Ryan Blue, presidente del PMC del proyecto Apache Iceberg y anteriormente ingeniero sénior de Netflix, "muchos servicios y motores diferentes utilizaban tablas Hive. Pero el problema era que no teníamos esa garantía de corrección. No teníamos transacciones atómicas", dijo en una conferencia en 2021. "A veces, los cambios de un sistema hacían que otro obtuviera los datos incorrectos y ese tipo de problema hacía que nunca usáramos estos servicios, que no hiciéramos cambios en nuestras tablas, solo para estar seguros".1
El propio Apache Hive se originó como un medio para hacer que los clusters de Apache Hadoop funcionaran de forma similar a las bases de datos relacionales accesibles por SQL. Aunque funciona de forma eficaz para los datos estáticos, se adapta mal a los conjuntos de datos cambiantes: los cambios deben coordinarse manualmente entre las distintas aplicaciones y usuarios, o de lo contrario se corre el riesgo de que los grandes conjuntos de datos se corrompan y resulten imprecisos.
Para garantizar la precisión en un entorno dinámico, Iceberg se diseñó para garantizar que cualquier transacción de datos exhiba las cuatro propiedades ACID:
Todos los cambios en los datos se realizan como si fueran una sola operación, es decir, se ejecutan todos los cambios o no se ejecuta ninguno de ellos. Por ejemplo, en una transacción de datos financieros, la atomicidad garantiza que cualquier débito realizado desde una cuenta tenga su correspondiente abono realizado en la otra cuenta.
No hay contradicciones entre el estado general de los datos antes y después de la transacción. Siguiendo con el ejemplo de la transacción financiera, la coherencia garantiza que los fondos combinados existentes entre las dos cuentas sean los mismos después de la transacción que antes de ella.
El estado intermedio de cualquier transacción es invisible para otras transacciones; las transacciones concurrentes (transacciones que operan de forma simultánea sobre el mismo conjunto de datos) se tratan como si estuvieran serializadas. En esta transacción financiera, el aislamiento garantiza que cualquier otra transacción pueda ver los fondos transferidos en la cuenta de cargo o en la de abono, pero no en ambas (ni en ninguna).
Tras una transacción efectuada con éxito, cualquier cambio en los datos persistirá incluso en caso de fallo del sistema. En nuestro ejemplo financiero, esto significa que la transacción se mantendrá completa aunque se produzca un apagón en todo el sistema inmediatamente después.
El formato de tabla Apache Iceberg se compara a menudo con otras dos tecnologías de datos de código abierto que ofrecen transacciones ACID: Delta Lake, una capa de almacenamiento optimizada creada originalmente por Databricks que amplía los archivos de datos de Parquet con un registro de transacciones basado en archivos y un tratamiento de metadatos escalable, y Apache Hudi (abreviatura de "Hadoop Upserts Deletes and Incrementals"), que Uber desarrolló originalmente en 2016.
Un estudio de 2022 realizado por Synvert generó datos aleatorios y los almacenó en formato JSON en un bucket de AWS S3 para utilizarlos en la evaluación comparativa de las tres tecnologías. Sus pruebas demostraron finalmente que el formato de tabla optimizado de Iceberg produjo un rendimiento superior al de Delta Lake y Apache Hudi en todas las métricas probadas2.
Almacenamiento: los tamaños de archivo resultantes de las tablas Iceberg eran significativamente más pequeños que los de Delta Lake o Hudi, lo que proporciona una gran ventaja para la optimización del almacenamiento.
Operaciones de inserción: para las operaciones de inserción, Iceberg también tuvo el rendimiento más rápido, es decir, el tiempo de ejecución más corto. Tanto Iceberg como Delta Lake fueron significativamente más rápidos que Hudi.
Operaciones de actualización: para las operaciones de actualización, Iceberg resultó mucho más rápido que Delta Lake y Hudi. Cabe destacar que, a diferencia de sus contrapartes, el tiempo de ejecución de Iceberg no aumentó significativamente con el número total de registros: en las cargas de trabajo máximas probadas en el estudio (500 millones de registros), Iceberg fue casi 10 veces más rápido que Delta Lake.
Operaciones de eliminación: del mismo modo, Iceberg fue varias veces más rápido que ambas alternativas en las operaciones de eliminación.
Iceberg implementa una jerarquía de tres capas de archivos de metadatos para garantizar la corrección y coordinación de los datos de la tabla en diversos formatos de archivo y cambios constantes.
Escrito en Java y Python y también ofrecido en una API de Scala, Iceberg es compatible con una variedad de formatos de archivos de big data, incluidos Apache Parquet, Apache Avro y Apache ORC. Ofrece una funcionalidad similar a la de las tablas SQL de las bases de datos tradicionales de forma independiente del formato de archivo y del proveedor, lo que permite que varios motores operen con el mismo conjunto de datos.
La arquitectura de una tabla Iceberg consta de tres capas: el catálogo Iceberg, la capa de metadatos y la capa de datos.
El catálogo Iceberg propiamente dicho se asienta sobre la capa de metadatos y los datos posteriores, del mismo modo que la punta de un iceberg se asienta sobre la superficie del agua. Almacena los punteros de metadatos actualizados (o "actuales") que asignan el nombre de una tabla determinada a la ubicación de sus archivos de metadatos actuales. Además de su catálogo integrado, Iceberg es compatible con otros marcos de catálogo como Hive MetaStore o AWS Glue.
Las operaciones a nivel de catálogo Iceberg son atómicas, ya que esto es esencial para garantizar la corrección de las transacciones en curso.
De este modo, un motor de consulta inicia cualquier consulta SELECT en el catálogo Iceberg, que proporciona la ubicación del archivo de metadatos actual de la tabla que el motor de consulta busca leer.
La capa de metadatos Iceberg incluye (en orden descendente) archivos de metadatos, listas de manifiestos y archivos de manifiestos.
Los archivos de metadatos almacenan los metadatos de una tabla, incluidos el esquema de la tabla, la información de la partición, su instantánea actual y las instantáneas de los estados anteriores. Tras apuntar al archivo de metadatos actual desde la entrada de la tabla en el catálogo Iceberg, el motor de consultas utiliza el valor [current-snapshot-id] para encontrar su entrada en la matriz [snapshots]. Desde allí, puede localizar y abrir la lista de manifiesto de la tabla.
La lista de manifiestos es simplemente una lista de archivos de manifiesto e información importante para cada archivo de datos que contiene, como su ubicación, la instantánea a la que está asociado y las particiones a las que pertenece. Ciertas optimizaciones y funciones de filtrado están disponibles en esta etapa.
Los archivos de manifiesto rastrean los archivos de datos y sus detalles, metadatos y estadísticas asociados. Esto impulsa una de las ventajas fundamentales del formato de tabla Iceberg sobre el formato Hive: su capacidad para rastrear datos a nivel de archivo. En esta etapa, los valores de [file-path] para cada objeto [data-file] pueden utilizarse para encontrar y abrir ese archivo.
La capa de datos, como su nombre indica, reside debajo de la capa de metadatos y contiene los archivos finales.
Apache Iceberg ofrece una serie de características útiles para mejorar y simplificar la gestión de datos.
Iceberg se encarga de todos los detalles de partición y consulta bajo el capó. El particionamiento oculto de Iceberg ahorra a los usuarios el trabajo de proporcionar información sobre el diseño de las particiones al consultar las tablas. Los usuarios no necesitan mantener las columnas de partición por sí mismos, ni siquiera comprender el diseño de la tabla física, para obtener resultados de consulta precisos.
Esto no solo hace que las particiones de Iceberg sean muy fáciles de usar, sino que también permite cambiar los diseños de las particiones con el tiempo sin interrumpir las consultas preescritas. Cuando las especificaciones de las particiones evolucionan, los datos de la tabla (y sus metadatos) no se ven afectados. Solo los datos nuevos, escritos en la tabla tras la evolución, se particionan con la nueva especificación y los metadatos de estos nuevos datos se guardan por separado.
Iceberg proporciona soporte nativo para la evolución del esquema. Esto permite a los usuarios modificar los esquemas de las tablas sin necesidad de realizar complejas migraciones de datos, lo que racionaliza enormemente la adaptación a la evolución de las estructuras de datos.
Iceberg permite a los usuarios viajar en el tiempo a través de instantáneas de los datos de Iceberg en diferentes momentos. Esto es valioso para una variedad de casos de uso, incluyendo auditorías, depuración y controles de cumplimiento.
Iceberg ofrece una serie de capacidades de indexación que ayudan a optimizar el rendimiento de las consultas, como opciones de compactación para fusionar archivos más pequeños en otros más grandes para reducir la sobrecarga de metadatos y filtros Bloom para reducir la lectura innecesaria de datos durante la ejecución de la consulta.
Ponga sus datos a trabajar, residan donde residan, con el lakehouse de datos híbrido y abierto para IA y análisis.
Resuelva los retos que presentan los datos hoy en día con una arquitectura lakehouse. Conéctese a los datos en minutos, obtenga rápidamente información fiable y reduzca los costes de su almacén de datos.
Desbloquee el valor de los datos empresariales con IBM Consulting y cree una organización impulsada por conocimientos que ofrezca ventajas empresariales.
1 “Apache Iceberg: The Hub of an Emerging Data Service Ecosystem?”. Datanami. 8 de febrero de 2021.
2 “Clash of ACID Data Lakes: Comparing Data Lakehouse Formats”. synvert, a GlobalLogic company. 9 de agosto de 2022.