Ingeniero de datos sustituye complejos stacks de big data por DuckDB y DuckLake

Tras casi dos décadas en ingeniería de datos, Matt Martin ha abandonado los pesados frameworks de computación distribuida en favor de herramientas más simples basadas en SQL. En un reciente caso de estudio publicado por el equipo de DuckDB el 29 de octubre de 2026, Martin explica cómo reemplazó infraestructuras complejas con DuckDB y su nuevo formato de tabla, DuckLake. Su trayectoria destaca una tendencia creciente entre ingenieros que priorizan la facilidad de uso y el menor mantenimiento frente a una escala bruta que sus cargas de trabajo no requieren realmente.

Qué ocurrió

La carrera de Martin comenzó con la manipulación manual de hojas de cálculo y macros VBA antes de evolucionar hacia pipelines automatizados de SQL. A medida que crecían los volúmenes de datos, adoptó herramientas estándar de la industria para big data como Teradata, Google BigQuery y Apache Spark. Aunque potentes, estos sistemas introdujeron una fricción operativa significativa. Describe pasar horas alineando versiones de la Java Virtual Machine y descifrando largas trazas de pila (stack traces) para tareas que a menudo no necesitaban procesamiento paralelo masivo. La complejidad de mantener clústeres de Spark para informes rutinarios se convirtió en un cuello de botella en lugar de un facilitador.

Alrededor de 2022, Martin descubrió DuckDB, una base de datos analítica embebida que se ejecuta localmente sin dependencias externas. Descubrió que podía consultar archivos CSV, Parquet e Iceberg directamente usando SQL estándar, eliminando la necesidad de gestión de clústeres. Esta simplicidad lo llevó a adoptar DuckLake, un nuevo formato de tabla que almacena metadatos en una base de datos SQL en lugar de numerosos archivos pequeños. Martin informa que las operaciones de catálogo que previamente tomaban segundos con Apache Iceberg ahora se resuelven en menos de un milisegundo con DuckLake, acelerando significativamente la planificación y ejecución de consultas.

Detalles clave

• Martin pasó de Apache Spark y Google BigQuery a DuckDB para reducir la sobrecarga de infraestructura en cargas de trabajo que no alcanzan petabytes.
• DuckLake almacena los metadatos de las tablas en una base de datos SQL, evitando la degradación del rendimiento causada por miles de pequeños archivos de metadatos en formatos como Iceberg.
• La próxima versión alpha de DuckDB v2.0 introduce E/S asíncrona, que Martin benchmarkéa como un 67% a 70% más rápida para leer grandes cantidades de archivos desde almacenamiento en la nube.
• Las sentencias ATTACH dinámicas en v2.0 permiten extraer cadenas de conexión y credenciales de variables de entorno en tiempo de ejecución, mejorando la seguridad y flexibilidad.
• El protocolo remoto Quack permite que instancias de DuckDB sirvan datos sobre HTTP, habilitando el acceso seguro a tablas DuckLake sin exponer credenciales de la nube a los usuarios finales.
• Martin enfatiza que la mayoría de los equipos no necesitan procesamiento en tiempo real para informes mensuales, desafiando la suposición común de que las herramientas de big data siempre son necesarias.

Contexto

Las arquitecturas tradicionales de big data a menudo dependen de sistemas distribuidos como Apache Spark para procesar datos en muchos servidores. Estos sistemas sobresalen en el manejo de petabytes de datos pero requieren configuración cuidadosa, gestión de versiones y recursos computacionales significativos para iniciarse y funcionar. La gestión de metadatos en formatos de tabla abiertos como Apache Iceberg implica escribir múltiples archivos JSON y manifest por cada transacción. A medida que crecen los conjuntos de datos, aumenta el número de estos archivos de metadatos, ralentizando el tiempo que el sistema tarda en planificar consultas porque debe leer y reconciliar todos estos archivos primero.

DuckDB adopta un enfoque diferente al ejecutarse como un único proceso, similar a SQLite pero optimizado para análisis. Puede leer datos directamente desde almacenamiento de objetos como Amazon S3 sin moverlos a un almacén propietario. DuckLake se basa en esto utilizando una base de datos relacional para rastrear los metadatos de las tablas. Dado que las bases de datos relacionales están altamente optimizadas para indexar y consultar datos estructurados, la búsqueda de información de tablas se vuelve casi instantánea, independientemente de cuántas transacciones hayan ocurrido. Esta arquitectura reduce la carga operativa para los equipos de ingeniería mientras mantiene un alto rendimiento para consultas analíticas típicas.

Por qué importa

Para los equipos que alojan su propio software o gestionan plataformas internas de datos, la complejidad operativa es un importante motor de costos. Mantener clústeres de Spark o gestionar metadatos de Iceberg requiere conocimiento especializado y atención constante. Si una herramienta puede ofrecer el rendimiento requerido con menos infraestructura, libera tiempo de ingeniería para el desarrollo de funcionalidades en lugar del mantenimiento de la plataforma. La experiencia de Martin sugiere que muchas organizaciones sobreingenierizan sus stacks de datos, pagando por una escala que nunca usan. Adoptar herramientas más ligeras como DuckDB puede reducir las facturas de la nube y simplificar los pipelines de despliegue.

Las mejoras en DuckDB v2.0 también abordan puntos dolorosos comunes en entornos nativos de la nube. La E/S asíncrona significa que leer miles de archivos de registro de S3 ya no bloquea el hilo principal, haciendo viable el análisis local para tareas que previamente requerían un clúster distribuido. La capacidad de adjuntar catálogos dinámicamente usando variables de entorno mejora la seguridad al mantener los secretos fuera de los repositorios de código. Para los líderes de TI, esto significa una conformidad más fácil y una automatización más segura. El protocolo Quack simplifica aún más el control de acceso, permitiendo a los equipos exponer servicios de datos sin gestionar federaciones de identidad complejas ni otorgar permisos amplios en la nube.

Qué puedes hacer

• Audita tus cargas de trabajo actuales de datos para identificar informes o análisis que no requieran procesamiento en tiempo real o throughput a escala de petabytes.
• Prueba DuckDB localmente instalando el paquete y consultando un archivo CSV o Parquet de muestra para evaluar la facilidad de uso frente a tu stack actual.
• Experimenta con DuckLake adjuntando un bucket de S3 usando los comandos SQL proporcionados para comparar el rendimiento de metadatos con tu formato de tabla existente.
• Revisa tus scripts de pipeline para credenciales codificadas rígidamente y planifica migrar a sentencias ATTACH dinámicas una vez que DuckDB v2.0 sea estable.
• Considera usar el protocolo Quack para servir dashboards internos, reduciendo la necesidad de acceso directo al almacenamiento en la nube para los usuarios finales.
• Sigue el Substack de Martin para obtener benchmarks detallados y ejemplos de configuración si decides pilotar estas herramientas en tu entorno.