La comunidad de Apache Iceberg aprobó el 31 de agosto la especificación de restricciones de lectura de grano fino para el catálogo REST. La votación, con voto vinculante de Yufei Gu y respaldo de varios contribuidores del proyecto, cierra una propuesta que Prashant Singh venía empujando durante semanas de reuniones específicas. Es un cambio pequeño en apariencia y grande en consecuencias: las restricciones a nivel de columna y de fila pasan a aplicarse en el catálogo, no en el motor de consulta.
Hasta ahora, en un lakehouse con varios motores —Spark, Trino, Flink, DuckDB o motores propietarios leyendo las mismas tablas Iceberg— cada uno resolvía el filtrado por su cuenta. El resultado práctico era que la política de acceso se definía tantas veces como motores hubiera, con el riesgo evidente de que una de esas implementaciones acabara siendo más permisiva que las demás. Al mover la aplicación al catálogo, la política se define una vez y se impone en el punto por el que pasan obligatoriamente todos los clientes.
Antes de la votación se cerraron dos flecos. El primero, cómo tratar las proyecciones de columnas solapadas en tipos anidados: se resolvió prohibiendo el solapamiento tanto en el catálogo como en el cliente, lo que evita ambigüedades de interpretación. El segundo, y quizá más importante para quien tenga que implementarlo, es que la propuesta incorpora un kit de compatibilidad. Las implementaciones tienen ahora un conjunto de pruebas contra el que validarse, en lugar de una especificación en prosa y buena voluntad —una tendencia que se repite esta temporada en Parquet y Arrow, donde las suites de conformidad están sustituyendo al texto como definición vinculante.
La semana ha sido movida en el ecosistema: también se publicó PyIceberg 0.12 el 1 de septiembre, con mejoras en la resolución de conflictos, y el 2 de septiembre salió la versión 1.0 del proveedor de Terraform para Iceberg, primera entrega de este nuevo subproyecto. En paralelo, Apache Polaris prepara su versión 1.8.0 y ha creado el repositorio para su propio proveedor de Terraform.
Para un equipo de datos, la lectura es que el catálogo deja de ser un simple registro de metadatos y se convierte en un componente de seguridad. Eso cambia los criterios de elección: al evaluar un catálogo Iceberg —Polaris, uno gestionado por el proveedor cloud o el que venga incluido en la plataforma— habrá que preguntar por su soporte de esta especificación y por su resultado en el kit de compatibilidad, no solo por su rendimiento o su integración. Y conviene planificar la adopción con calma, porque el soporte llegará de forma escalonada a motores y catálogos: durante un tiempo convivirán los dos modelos de aplicación de políticas.
Más en Dataprix: Guía de arquitectura de datos
Fuente: Apache Data Lakehouse Weekly
Contenido elaborado con asistencia de inteligencia artificial y revisado editorialmente por el equipo de Dataprix.