Data engineering moderno: dbt, Iceberg y el lakehouse se dan la mano
Actualizado: 2026-05-03
La pila de datos analíticos ha pasado la última década prometiendo una separación limpia entre almacenamiento, motor y transformación, pero solo en los últimos doce meses esa promesa ha dejado de sonar a folleto comercial. Apache Iceberg con catálogos REST, dbt como capa declarativa y un motor de consulta intercambiable por debajo se han convertido en el esqueleto real de los nuevos proyectos de analítica. Lo escribo aquí porque el patrón se está repitiendo en demasiados equipos como para ignorarlo, y porque las decisiones tomadas ahora condicionan los próximos cinco años de una plataforma de datos.
Puntos clave
- Iceberg ha ganado la guerra de adopción entre los formatos de tabla abiertos por motivos mundanos más que técnicos: Databricks, Snowflake, BigQuery y Redshift lo soportan nativamente.
- La especificación REST de Iceberg 1.6 estandarizó una API HTTP que cualquier motor puede consumir; hoy Trino, Spark, DuckDB y Python pueden leer y escribir las mismas tablas a través de un único servicio.
- dbt Fusion, la reescritura en Rust de dbt-core, introduce validación estática de columnas y tipos en tiempo de compilación y acepta Iceberg como destino nativo.
- El rendimiento de consultas interactivas sobre Iceberg en un motor abierto sigue siendo inferior al de un almacén cerrado bien ajustado, a veces por un factor de dos o tres.
- El lakehouse abierto con Iceberg y dbt compensa cuando se cumplen tres condiciones a la vez: volumen suficiente, heterogeneidad de cargas y madurez de ingeniería de datos.
Por qué Iceberg se ha llevado el gato al agua
Cuando empezó la conversación del formato de tabla abierto, los tres candidatos eran Iceberg, Delta Lake y Hudi. A finales de 2025 la realidad es que Iceberg ha ganado la guerra de adopción por motivos mundanos más que técnicos:
- Databricks compró Tabular en 2024 y empezó a converger Delta e Iceberg.
- Snowflake, BigQuery y Redshift soportan Iceberg nativamente para lectura y, en varios casos, también para escritura.
- AWS Glue ofrece Iceberg como formato por defecto en catálogos nuevos.
Cuando tus tres almacenes principales y el mayor motor analítico abierto convergen en el mismo formato, la elección deja de ser técnica.
Lo interesante es que Iceberg no es el mejor en ningún aspecto individual. Delta tiene un motor más acoplado y rápido en Databricks, Hudi sigue siendo superior para actualizaciones frecuentes en streaming. Pero Iceberg es el que ha conseguido mantener la abstracción más limpia entre especificación y motor: sus metadatos son JSON y Avro, su modelo de particionado oculto evita los errores clásicos del predicado mal escrito, y su soporte de viajes en el tiempo y esquemas evolutivos es el más riguroso de los tres.
El giro de 2025 ha sido el catálogo REST. La especificación REST de Iceberg 1.6 estandarizó una API HTTP que cualquier motor puede consumir. Hoy puedes tener Trino, Spark, DuckDB y un cliente de Python leyendo y escribiendo las mismas tablas a través de un único servicio, sin que ninguno se lleve más bien con el catálogo que los demás.
dbt encima: lo que cambia con Fusion
La capa de transformación ha evolucionado en paralelo. dbt Labs presentó el motor Fusion, reescritura en Rust de dbt-core que compila el grafo de modelos, valida SQL antes de ejecutarlo y emite planes de ejecución optimizados. El motor antiguo basado en Python sigue funcionando para proyectos existentes, pero Fusion introduce validación estática de columnas y tipos en tiempo de compilación, algo que faltaba y que ha causado muchas horas perdidas persiguiendo errores que un analizador debió haber detectado antes.
Lo relevante no es la velocidad, aunque también. Lo relevante es que dbt Fusion acepta Iceberg como destino nativo en lugar de tratarlo como un adaptador más. Para equipos que hasta ahora estaban en Snowflake o BigQuery puros, esto abre la puerta a desacoplar la plataforma de almacenamiento del motor de consulta sin reescribir modelos.
La combinación dbt más Iceberg resuelve el problema real de la mayoría de plataformas de datos medianas: el bloqueo del proveedor no viene del motor, viene de los datos. Si tus tablas viven en Iceberg con un catálogo REST, migrar de Snowflake a Trino, o probar DuckDB encima del mismo lago, deja de ser una reescritura completa para ser un cambio de conexión. Esto complementa bien los patrones que analizamos en DuckDB en analítica de empresa: el mismo motor embebido que sirve para analítica local puede acceder a las mismas tablas Iceberg en el lake.
Los puntos donde sigue doliendo
No todo está resuelto. El rendimiento de consultas interactivas sobre Iceberg en un motor abierto como Trino sigue siendo inferior al de un almacén cerrado bien ajustado, a veces por un factor de dos o tres. La razón es que Snowflake y BigQuery tienen optimizadores de consulta, caché de resultados y gestión de recursos afinados a lo largo de una década que los motores abiertos no pueden replicar con cuatro ingenieros. Para tableros operacionales con docenas de consultas por segundo, Iceberg abierto sigue siendo demasiado frío.
El segundo punto es la operación del propio catálogo. Un catálogo REST es infraestructura crítica: si se cae, todos los motores pierden la visión coherente de las tablas. Proveedores comerciales como Tabular resuelven esto, pero montarlo tú mismo con Lakekeeper implica alta disponibilidad, copias de seguridad de metadatos y un plan de recuperación que la mayoría de equipos no tenían cuando vivían dentro de Snowflake y el catálogo era parte del servicio.
El tercer frente es el coste de escritura. Iceberg optimiza para lecturas analíticas con muchas particiones y archivos Parquet grandes, pero mantener ese óptimo requiere trabajos de compactación y limpieza regulares. Olvidarse de compactar una tabla con ingesta de streaming lleva en semanas a miles de archivos pequeños y consultas que tardan minutos. Los almacenes cerrados hacen esto por ti en segundo plano; con Iceberg tienes que orquestarlo a mano.
Cuándo compensa dar el paso
El lakehouse abierto con Iceberg y dbt compensa cuando se cumplen tres condiciones a la vez:
- Volumen suficiente para que el coste del almacén cerrado sea una partida significativa del presupuesto, típicamente por encima de los seis dígitos anuales. Por debajo de eso, el ahorro no cubre el coste operativo de mantener el catálogo y los trabajos de compactación.
- Heterogeneidad de cargas. Si todo tu análisis es SQL interactivo sobre datos tabulares, un almacén cerrado te dará mejor experiencia. Iceberg brilla cuando hay que mezclar Python, Spark, SQL interactivo y modelos de aprendizaje automático sobre las mismas tablas sin duplicar datos.
- Madurez de ingeniería de datos para operar infraestructura propia. Iceberg no es Snowflake: no se configura en un panel web y funciona. Equipos que llegan desde el almacén cerrado suelen subestimar esta curva y acaban con un lakehouse peor operado que el almacén que abandonaron.
Ante la duda, empezaría por un piloto pequeño con un dataset no crítico antes de comprometer la plataforma entera.
Conclusión
La pila Iceberg más dbt es hoy la respuesta más sensata para organizaciones que quieren escapar del bloqueo de proveedor sin renunciar a transformaciones declarativas de calidad. Las herramientas han madurado lo suficiente para que la fricción operativa sea razonable, pero la curva de aprendizaje sigue siendo real y no conviene subestimarla.
