.png)
Articulo original en japones: AWS Lambda DuckDB PyIceberg ETL con enrutamiento dinamico
Introduccion
Soy Aki AWS Community Builder. En los ultimos años los data pipelines tienden a consolidar datos de multiples fuentes en un data lake. Sin embargo cuando cada origen requiere un procesado distinto o escribe en tablas objetivo diferentes el ETL tradicional pierde flexibilidad y encarece el mantenimiento. Incluso con ETL ligeros basados en AWS Lambda es habitual crear una funcion por fuente o por tabla lo que complica las actualizaciones de tiempo de ejecucion y versiones de librerias. En este articulo presento un ETL con enrutamiento dinamico que resuelve ese problema almacenando la configuracion en DynamoDB para que Lambda decida automaticamente la tabla de destino y el SQL a ejecutar.
Concepto de enrutamiento dinamico
En ETL tradicionales se codifican en el propio codigo las tablas destino y las consultas para cada origen lo que obliga a modificar el codigo al añadir nuevas fuentes. Con enrutamiento dinamico Lambda puede cambiar la tabla Iceberg objetivo y ejecutar SQL diferentes por fuente sin tocar el codigo. Basta con actualizar la configuracion.
Arquitecturas usadas
Enrutamiento por bucket: se decide el destino a partir del nombre del bucket de entrada util cuando llegan datos de sistemas distintos.
Enrutamiento por carpeta: se usa la ruta del objeto en S3 por ejemplo el primer segmento del key util cuando un mismo sistema tiene multiples tablas origen y se distinguen por subcarpetas.
Flujo de proceso
1 Se sube un archivo a S3 y se dispara Lambda. 2 Lambda extrae una clave de enrutamiento desde el bucket o desde la ruta. 3 Lambda consulta en DynamoDB la tabla destino y el SQL asociado. 4 Se carga el Parquet en DuckDB y se ejecuta el SQL. 5 El resultado se inserta por append en una tabla Iceberg a traves de PyIceberg.
Librerias clave
DuckDB motor SQL embebido muy rapido ideal para analitica en memoria y ETL por lotes. PyArrow formato de columnas de alto rendimiento para mover datos eficientemente entre sistemas. PyIceberg implementacion Python de Apache Iceberg para leer escribir y gestionar tablas en data lakes usando por ejemplo AWS Glue Catalog.
Sobre las librerias
DuckDB es un motor OLAP embebido ligero que funciona muy bien en entornos restringidos como Lambda y se adapta de forma excelente a cargas de analitica por lotes y ETL. Sitio oficial: duckdb.org
PyArrow expone en Python Apache Arrow un formato de memoria columnar optimizado para analitica y computacion distribuida que permite transferencias rapidas y de bajo overhead entre procesos y lenguajes. Sitio oficial: arrow.apache.org
PyIceberg es la implementacion Python del formato de tablas Apache Iceberg pensado para grandes data lakes en la nube. Permite a aplicaciones Python leer escribir y administrar tablas Iceberg de forma transparente con catálogos como AWS Glue. Sitio oficial: py.iceberg.apache.org
Codigo de ejemplo explicado
La funcion Lambda obtiene del evento S3 el bucket y el object key y construye la ruta s3. La clave de enrutamiento puede ser el nombre del bucket para enrutamiento por bucket o el primer segmento del object key para enrutamiento por carpeta segun la estructura de S3. Con esa clave consulta en DynamoDB la entrada que contiene dos valores principales target_table y query_sql. El SQL de consulta se formatea con la ruta s3 de entrada y se ejecuta en DuckDB cargando los datos desde Parquet mediante el conector httpfs. El resultado se recupera como tabla Arrow. Para escribir en Iceberg se usa PyIceberg con AWS Glue Catalog realizando append sobre la tabla objetivo e incorporando una logica de reintentos exponenciales para gestionar conflictos de commit y cambios concurrentes en la rama principal. Las variables de entorno permiten definir nombre del catalogo region tabla de enrutamiento y es recomendable parametrizar los limites y tiempos de los reintentos.
Tabla de enrutamiento en DynamoDB
La tabla de configuracion utiliza una particion identificada por PartitionKey que representa la clave de enrutamiento por ejemplo nombre de bucket o carpeta. Cada item almacena al menos target_table la tabla Iceberg completa con su namespace y query_sql el SQL parametrizado que usa el marcador s3_input_path. Añadiendo o modificando items se pueden habilitar nuevas rutas sin desplegar codigo.
Resultados de ejecucion
Al subir un archivo a un primer bucket se resolvio el enrutamiento y se insertaron filas en la tabla Iceberg objetivo correctamente. Al repetir la prueba con un segundo bucket se escribio sin errores confirmando que Lambda cambia de destino segun la configuracion de DynamoDB.
Ventajas
Agregar nuevas fuentes o destinos solo requiere ajustar triggers de S3 y entradas en DynamoDB. El codigo de Lambda se mantiene simple y unico evitando multiples funciones por ruta y facilitando upgrades de runtime o librerias.
Limitaciones
DynamoDB puede convertirse en un unico punto de fallo si no se planifica alta disponibilidad y monitorizacion. El tamaño de memoria de Lambda limita el volumen por lote y el tiempo maximo de ejecucion es 15 minutos. La logica compleja mas alla de SQL es dificil por lo que encaja especialmente en pasos de aterrizaje y bronce.
Alternativas de enrutamiento
Enrutamiento basado en metadatos del propio Parquet o en columnas internas. Es flexible e independiente de los nombres y rutas aunque requiere que dichos metadatos esten presentes y estandarizados.
Conclusion
Implementamos un ETL ligero con enrutamiento dinamico sobre AWS Lambda combinando DuckDB PyArrow y PyIceberg que centraliza la logica dispersa reduce el coste de mantenimiento y permite añadir rutas con rapidez. Este ejemplo es conceptual y debe adaptarse a los requisitos especificos evaluando ventajas e inconvenientes antes de su uso en produccion. Esperamos que sirva como referencia para equipos que exploran ETL ligeros y escalables en la nube.
