Una ruta de escritura, múltiples entradas: cómo Rippling utiliza Apache Iceberg™ administrado por Unity Catalog

Esta es una publicación invitada de Tae Lee, Staff Engineer de Data Platform en Rippling

En Rippling, el motor que escribe una tabla no siempre es el que la lee. Un trabajo de Databricks puede producir una tabla, pero el consumidor downstream puede ser la capa de consulta basada en Trino de Rippling Data Cloud, Snowflake u otro lector de lakehouse. Esto hace que la decisión del catálogo sea más que un detalle de metadatos: determina quién puede escribir la tabla, quién la mantiene y cómo la leen otros motores.

Esto significa que el objetivo no es forzar cada carga de trabajo a un solo motor o catálogo. El objetivo es permitir que cada productor utilice la plataforma donde funcione mejor, al mismo tiempo que se publican tablas gobernadas que los sistemas downstream puedan consumir sin duplicación.

Las tablas de Iceberg gestionadas por Unity Catalog son el patrón que utilizamos para la parte de esa arquitectura producida por Databricks.

La propiedad del catálogo sigue al escritor

Nuestra estrategia de catálogo comienza con una regla simple: el catálogo debe seguir al escritor.

Para el cómputo nativo de AWS, utilizamos AWS Glue Data Catalog. Es la opción natural para las cargas de trabajo escritas por motores de AWS como Glue, Athena, EMR o infraestructura relacionada.

Para las cargas de trabajo producidas por Databricks, utilizamos Unity Catalog. Esto es especialmente importante para Apache Iceberg™. Databricks puede leer tablas externas de Iceberg mediante federación, pero esas tablas no son lo mismo que las tablas de Iceberg gestionadas por Unity Catalog. Si Databricks necesita escribir en la tabla, o si la carga de trabajo depende en gran medida del rendimiento y la gobernanza de Databricks, la tabla debe estar gestionada por UC.

Para los datos producidos por Snowflake que deben compartirse entre plataformas, utilizamos Snowflake Horizon Catalog con tablas de Iceberg gestionadas por Snowflake. Esa es una decisión de catálogo independiente impulsada por Snowflake como productor.

Esta es la distinción importante: Iceberg nos ofrece un formato de tabla abierto, pero el catálogo sigue siendo el propietario de las confirmaciones de metadatos (metadata commits), los permisos y el ciclo de vida de la tabla. La portabilidad del formato y la propiedad del catálogo están relacionadas, pero no son lo mismo.

Por qué usar Iceberg gestionado para las cargas de trabajo de Databricks

Antes de este patrón, un resultado producido por Databricks que debía consumirse en otro lugar solía implicar una transferencia adicional: exportar una segunda copia después de la escritura de Databricks, o escribir directamente en el sistema de consumo y volver a leerlo a través de un conector o una ruta de federación cuando Databricks lo necesitara de nuevo. Ambos enfoques funcionan, pero añaden una materialización duplicada, cómputo adicional y límites específicos del conector. 

Iceberg gestionado por Unity Catalog nos proporciona un límite más claro.

Databricks escribe la tabla de forma nativa. Unity Catalog es el propietario de los metadatos de la tabla, el modelo de acceso y el ciclo de vida. Los datos de la tabla y los metadatos de Iceberg se almacenan en el almacenamiento S3 propiedad de Rippling. 

Los motores externos se conectan a través de la API de Iceberg REST Catalog o de la federación de catálogos. La entrega de credenciales (credential vending) otorga a esos motores un acceso acotado al almacenamiento subyacente. Luego, los motores leen los archivos Parquet directamente desde S3 utilizando su propio cómputo. 

Esa es la propiedad clave para nosotros. Un trabajo de Databricks puede producir la tabla una vez, y un motor downstream como Trino, Snowflake, Spark, Athena o EMR puede consumir la misma tabla a través de patrones de acceso estándar de Iceberg. El consumidor no tiene que enviar cada consulta a través del dialecto SQL o la capa de ejecución de otro motor, lo que reduce la dependencia de la traducción entre motores, el comportamiento de pushdown, la limitación de velocidad (throttling) y el cómputo del lado del productor para las lecturas downstream. 

No es una exportación de Databricks. Es una tabla abierta de Iceberg con un productor nativo de Databricks.

De los resultados de ML a Data Cloud

El patrón es más útil cuando un resultado producido por Databricks debe formar parte de un producto o una superficie analítica más amplia.

En Rippling, las cargas de trabajo de ML y AI siguen eligiendo el destino que mejor se adapta al caso de uso: tablas Delta, bases de datos vectoriales, OpenSearch u otros destinos diseñados para un propósito específico. Iceberg gestionado es un patrón de publicación seleccionado, no el destino predeterminado para cada resultado de ML.

Donde Iceberg gestionado realmente importa es en la transferencia. Para resultados seleccionados, un trabajo de Databricks puede publicar una tabla de Iceberg gestionada por Unity Catalog una sola vez. Rippling Data Cloud puede consumir esa misma tabla a través de su capa de consulta, incluidos los patrones de acceso basados en Trino, y utilizarla en transformaciones downstream, tableros (dashboards) y funciones de productos impulsadas por AI.

La arquitectura se ve así:

Eso nos da una tabla gobernada y una ruta de escritura. Los consumidores downstream no necesitan una copia física duplicada, y los Lakeflow Jobs no necesitan escribir por separado en cada sistema de consumo.

Las operaciones importan tanto como la apertura

Los formatos de tabla abiertos son solo una parte de la historia. Las tablas de Iceberg aún necesitan mantenimiento: compactación de archivos, expiración de instantáneas (snapshots), limpieza de archivos huérfanos y estadísticas.

Para las tablas de Iceberg catalogadas en Glue, ese mantenimiento pertenece a la ruta de la plataforma nativa de AWS. Glue tiene funciones de optimización de tablas, pero sigue siendo un modelo operativo independiente: debemos decidir dónde habilitar esas funciones, cómo monitorearlas y cómo validar el comportamiento para las cargas de trabajo que utilizan Glue.

Para Iceberg gestionado por Unity Catalog, Databricks maneja una mayor parte de ese ciclo de vida a través de Predictive Optimization, lo que incluye el mantenimiento automático de tablas, la optimización y compactación de archivos, la recopilación de estadísticas y la optimización del diseño de datos (data layout) para tablas gestionadas. Esto es útil porque la misma plataforma que escribe la tabla también gestiona gran parte de la higiene necesaria para mantener su rendimiento.

Esta es una de las razones por las que no vemos a Iceberg gestionado por UC únicamente como una característica de interoperabilidad. También es un modelo operativo. Para las tablas producidas por Databricks, la ruta de mantenimiento importa tanto como la ruta de lectura.

Ser precisos sobre la dependencia del proveedor (lock-in)

Esta arquitectura reduce la dependencia de datos (data lock-in), pero no elimina todas las dependencias.

La dependencia de datos (data lock-in) es baja. La tabla es Iceberg sobre Parquet en el almacenamiento S3 propiedad de Rippling.

Los motores downstream pueden leer los datos directamente a través de patrones abiertos de Iceberg.

La dependencia del catálogo y la gobernanza es real. Unity Catalog sigue siendo el plano de control para los metadatos, los permisos, el linaje y el comportamiento de las tablas gestionadas. Si dejáramos de usar Databricks, los datos serían portables, pero necesitaríamos reemplazar el catálogo y el sistema de mantenimiento.

Ese es un compromiso (trade-off) aceptable para este tipo de tablas. UC se gana su lugar cuando Databricks es el productor y la tabla necesita ser gobernada, mantenida y legible por otros motores.

El resultado práctico

El valor de Iceberg gestionado por Unity Catalog no es que nos proporcione un único catálogo para cada tabla. No lo hace, y ese no es nuestro objetivo.

El valor es que nos brinda una única ruta de escritura para las tablas producidas por Databricks que requieren un consumo downstream abierto. Databricks obtiene la ruta nativa de escritura y optimización. Los sistemas downstream obtienen acceso directo a los datos abiertos en S3. 

Los motores que acceden a la tabla a través del catálogo REST pasan por la misma capa de metadatos y acceso en lugar de eludir la gobernanza

a través de rutas de almacenamiento sin procesar (raw storage). Ese es el resultado práctico:

"Unity Catalog e Iceberg gestionado nos brindan lo mejor de ambos mundos: rendimiento nativo para nuestras canalizaciones (pipelines) de AI y ML, e interoperabilidad abierta para cada consumidor downstream. Una ruta de escritura, cero duplicación y una capa de gobernanza que todos los motores respetan, incluidos los productos impulsados por AI que estamos creando para Data Cloud de Rippling."

Para Rippling, la interoperabilidad no se trata de hacer que todos los motores sean intercambiables. Se trata de permitir que cada motor haga el trabajo para el que es bueno, manteniendo al mismo tiempo la tabla publicada portable, gobernada y utilizable por los sistemas que la necesitan.

Para obtener más información sobre Unity Catalog y el soporte de Iceberg, visite la página del producto de Unity Catalog. 

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original