Especificación de la tabla de Apache Iceberg v3: celebramos el éxito compartido de la comunidad de código abierto

El proyecto Apache Iceberg™ ejemplifica el espíritu del código abierto y demuestra lo que es posible cuando una comunidad se une con un objetivo común: impulsar una tecnología hacia adelante. Con la misión de aportar fiabilidad, rendimiento y apertura a las analíticas a gran escala, el proyecto Iceberg sigue evolucionando y ofreciendo numerosas ventajas gracias a las diversas voces y contribuciones de su comunidad.

El hito más reciente de Iceberg, la ratificación de la especificación de la tabla v3, es mucho más que una simple actualización técnica. Es el resultado de un diseño minucioso, debates rigurosos y la colaboración entre decenas de organizaciones y cientos de personas. La especificación de la tabla v3 refleja una inversión compartida en el futuro de las arquitecturas de datos abiertas y el compromiso de mantener Iceberg verdaderamente neutral respecto a proveedores, flexible e impulsado por la comunidad.

En esta entrada de blog, destacamos las principales características de la especificación de la tabla v3 y ponemos en valor el trabajo colectivo que ha hecho posible esta versión.

Desarrollo impulsado por la comunidad

En los dos últimos años, Iceberg se ha consolidado como un estándar líder para formatos de tabla abiertos, lo que permite tanto a usuarios como a proveedores acordar una estructura común para sus datos y beneficiarse así de la interoperabilidad que esta ofrece. Solo gracias a las contribuciones de toda la comunidad puede el proyecto Iceberg prosperar y ofrecer todas las ventajas —apertura, neutralidad respecto a proveedores e interoperabilidad— que lo hacen valioso.

En el código abierto, cualquiera puede proponer una nueva función, desarrollarla y colaborar con otros contribuidores para incorporarla al proyecto. Las funciones incorporadas a la última especificación de tabla de Iceberg son el resultado de numerosos debates con proveedores y usuarios que explicaron qué necesitaban de Iceberg para seguir utilizando o adoptar la tecnología. Por ejemplo, los proveedores con formatos de tabla propietarios podían proponer añadir determinadas funciones a Iceberg por coherencia, pero solo se incorporarían si toda la comunidad consideraba que aportaban valor al proyecto. Eso es código abierto.

Contar con un gran número de usuarios, contribuidores y proveedores que respaldan Iceberg significa que las funciones propuestas y las mejoras sugeridas incorporan perspectivas diversas y dan lugar a implementaciones más sólidas, lo que nos lleva a la especificación de la tabla v3.

Descripción general de la especificación de la tabla v3

La especificación de la tabla v3 supone un hito clave para la tecnología, ya que incorpora numerosas funciones innovadoras y abre innumerables casos de uso para los usuarios. 

Valores predeterminados

Qué hace: Con los valores predeterminados, los usuarios de Iceberg pueden gestionar valores nulos y valores ausentes en sus tablas v3. 

Cómo funciona: Los valores predeterminados son posibles gracias a la incorporación de dos nuevas configuraciones de tabla. Con write-default, los usuarios pueden controlar cómo los procesos de escritura gestionan los valores ausentes en los campos; para mayor flexibilidad, esta configuración puede modificarse en cualquier momento. Por otro lado, initial-default, que se define una sola vez por tabla, ofrece un mecanismo para sustituir los valores nulos existentes por un valor especificado. 

Quién lo hizo posible:

• Shenoda Guirguis, propuesta original de la especificación

• Limian (Raymond) Zhang, especificación final

• Implementación

  • Ryan Blue, Iceberg PMC Chair

  • Walaa Eldin Moustafa

Vectores de eliminación

Qué hace: Los vectores de eliminación son el nuevo mecanismo predeterminado para gestionar eliminaciones por posición en Iceberg. Los usuarios ya no tienen que asumir los compromisos habituales al configurar las eliminaciones por posición, es decir, elegir entre reducir el número de archivos pequeños (habilitando granularidad a nivel de partición) o lograr lecturas más eficientes (habilitando granularidad a nivel de archivo). 

Cómo funciona: Una vez implementados, los vectores de eliminación sustituirán a las eliminaciones por posición. El diseño contempla almacenar múltiples vectores de eliminación como mapas de bits roaring en archivos Puffin, un tipo de archivo de alto rendimiento ya utilizado en el proyecto Iceberg, al que se puede acceder de forma eficiente mediante un índice. Curiosamente, “Iceberg v2 ya contemplaba una noción de [vectores de eliminación], pero se utilizaban en memoria”, explica Anton Okolnychyi, miembro del Comité de Gestión de Proyectos (PMC) de Iceberg y Senior Staff Software Engineer en Databricks. “En disco había archivos Parquet; en memoria, mapas de bits. Cuando empezamos a diseñar la v3, queríamos explorar qué podíamos hacer de forma diferente para evitar la sobrecarga de esa conversión”. 

La decisión de la comunidad de utilizar archivos Puffin en lugar de la implementación existente basada en Parquet aporta mejoras de rendimiento y puede resultar especialmente beneficiosa en casos de uso de baja latencia. En definitiva, los vectores de eliminación ofrecen lo mejor de ambos mundos: las eliminaciones por posición se aplican con granularidad a nivel de archivo para optimizar las lecturas, pero se almacenan físicamente en archivos Puffin consolidados para reducir el número de archivos pequeños.

Quién lo hizo posible:

• Cambios en la especificación

  • Renjie Liu, miembro del PMC de Iceberg, propuesta original

  • Anton Okolnychyi, cambios finalizados

• Implementación

  • Amogh Jahagirdar, miembro del PMC de Iceberg

  • Eduard Tudenhoefner, miembro del PMC de Iceberg

Tipos de datos geoespaciales

Qué hace: Iceberg ahora admite dos nuevos tipos de datos geoespaciales, geometry y geography, lo que lo alinea mejor con otros proyectos y permite a los usuarios ampliar las funcionalidades relacionadas con datos cartográficos y de localización. 

Según Jia Yu, presidente del PMC de Apache Sedona y cofundador de Wherobots, la funcionalidad final es el resultado de una intensa investigación por parte de la comunidad. Revisaron numerosos proyectos y tecnologías con compatibilidad geoespacial, como “Sedona, Databricks, Snowflake, BigQuery, pandas” y otros, que “tienen definiciones distintas de los datos geoespaciales… distintos tipos… y comportamientos realmente diferentes”. 

Cómo funciona: Más allá de hacer accesibles los tipos de datos geoespaciales en Iceberg, el cambio en la especificación también aborda cuestiones complejas, como la gestión de la partición y el filtrado de campos geoespaciales, así como la definición de métricas a nivel de columna para estos tipos. Predicate pushdown y las métricas estándar a nivel de columna siguen estando disponibles para los tipos geoespaciales, con recuadros delimitadores descritos por puntos geoespaciales que actúan como valores máximos y mínimos. 

Quién lo hizo posible:

• Cambios en la especificación

  • Szehon Ho, miembro del PMC de Iceberg

  • Gang Wu

• Kristin Cowalcijk, implementación

• Mención especial a todo el equipo de Wherobots, que implementó la compatibilidad geoespacial en su propio fork de Iceberg antes de aportar su experiencia a la comunidad, liderando e implementando esta funcionalidad en el proyecto Iceberg.

Transformaciones multiargumento

Qué hace: Las transformaciones multiargumento permiten realizar transformaciones sobre varios campos con fines de particionado y ordenación en Iceberg. Antes de la especificación de la tabla v3, solo se podía transformar un único campo con estos fines.

Quién lo hizo posible:

• 叶先进, cambios en la especificación

• Implementación

  • Fokko Driesprong, miembro del PMC de Iceberg

  • JB Onofré, miembro del consejo de la ASF

Linaje de filas

Qué hace: El linaje de filas facilita a los usuarios el seguimiento de cómo han evolucionado las filas de una tabla de Iceberg a lo largo del tiempo, lo que habilita numerosos casos de uso, como la mejora de los flujos de captura de datos de cambios (CDC), auditorías más sencillas y un mantenimiento más eficiente de vistas materializadas. En última instancia, la incorporación del linaje de filas en Iceberg “significa que los usuarios podrán determinar con precisión el historial de cualquier fila de sus tablas”, afirma Russell Spitzer, miembro del PMC de Iceberg y Principal Software Engineer en Snowflake. “Antes solo podíamos hacer estimaciones basadas en columnas de identidad definidas por el usuario; ahora está integrado directamente en el propio formato”.

Cómo funciona: Cada fila de una tabla de Iceberg incluye dos campos adicionales, _row_id y _last_updated_sequence_number. La comunidad Iceberg logró implementarlo de forma que no todas las filas tengan que almacenar explícitamente valores en estos campos. Para ahorrar espacio, los valores de columna se infieren hasta que se materializan mediante una consulta de lectura; solo entonces se propagan a través de la capa de metadatos (Metadata.json → Snapshot → Manifest → Datafile → Row).

Quién lo hizo posible:

• Cambios en la especificación

  • Russell Spitzer

  • Nileema Shingte

  • Attila-Péter Tóth

• Implementación

  • Russell Spitzer, núcleo 

  • Ryan Blue, núcleo 

  • Amogh Jahagirdar, Spark 

Cifrado de tablas

Qué hace: La última actualización en materia de cifrado de tablas habilita el cifrado del lado del cliente en tablas de Iceberg, lo que permite cifrar todos los datos y metadatos. Las tablas completas pueden cifrarse con una única clave o el acceso puede controlarse a nivel de instantánea. 

Cómo funciona: Para habilitar el cifrado del lado del cliente en Iceberg, los usuarios pueden asociar instantáneas individuales de tablas con claves de cifrado almacenadas en un almacén de claves de terceros. Para acceder a los datos de una instantánea concreta, los clientes deben tener acceso a dicho almacén y a la clave de cifrado para descifrar y acceder a la lista de manifiestos de la instantánea. A partir de ahí, las listas de manifiestos siguen un mecanismo similar para descifrar los archivos de manifiesto y, finalmente, estos incluyen una clave de cifrado de archivos de datos que permite a los clientes acceder a los propios archivos de datos. 

Quién lo hizo posible:

• Cambios en la especificación e implementación

  • Gidon Gershinsky

  • Russell Spitzer

  • Ryan Blue

Tipo de datos variant

Qué hace: El tipo variant permite gestionar conjuntos de datos semiestructurados menos uniformes, en los que determinados campos se utilizan de forma intermitente. Por ejemplo, en datos de sensores: todos pueden informar de ubicación y marca de tiempo, pero algunos incluyen temperatura, otros humedad, etc. En palabras de Aihua Xu, Senior Software Engineer en Snowflake y uno de los contribuidores de variant: “Añadir [variant] a la especificación Iceberg v3 implicaba adaptarse a la realidad de los datos actuales. La compatibilidad nativa con [variant] permite a Iceberg representar y procesar este tipo de datos de forma eficiente, aportando rendimiento y flexibilidad sin comprometer la estructura”.

Cómo funciona: El tipo de datos variant permite almacenar tipos y campos variables en tablas de Apache Iceberg™, donde los nombres de los campos y sus tipos se extraen como metadatos y campos de valor y se almacenan en formato binario. La lectura de los datos implica su deserialización. Para mayor eficiencia, una función adicional denominada “shredding” permite extraer los campos coherentes (como ubicación y marca de tiempo en el ejemplo anterior), y sus tipos, y almacenarlos en Parquet; los campos restantes se almacenan como metadatos y campos de valor, tal como se ha descrito. 

Quién lo hizo posible:

• Cambios en la especificación

  • Tyler Akidau, propuesta original 

  • Aihua Xu, cambios finalizados

• Implementación

  • Aihua Xu, implementación principal

  • Ryan Blue, núcleo

  • David Cashman, shredding

  • Gene Peng, codificación y contribución clave al tipo de datos variant en Apache Spark

  • Neil Chao, Apache Arrow 

Dónde estamos y qué está por venir

Ninguna de las funcionalidades descritas habría sido posible sin el arduo trabajo y la colaboración continua de toda la comunidad Iceberg. El trabajo realizado para esta última especificación es un auténtico reflejo del espíritu del código abierto y demuestra cómo individuos, proveedores y usuarios pueden unirse para impulsar una tecnología en su conjunto. 

Queremos expresar nuestro más sincero agradecimiento a todas las personas que han contribuido a Iceberg y han hecho posible la especificación de la tabla v3, tanto las mencionadas anteriormente como todas las demás.

Actualmente, la diversidad del proyecto Iceberg, tanto a nivel individual como empresarial, refleja la solidez de su comunidad y su ecosistema. Su éxito continuado dependerá de una adopción amplia de la especificación de la tabla v3 y de su integración generalizada con tecnologías existentes y nuevas. Afortunadamente, esto ya está ocurriendo, con un número creciente de tecnologías, empresas y proveedores que respaldan Iceberg cada día.