ETL vs ELT: Eligiendo Correctamente
Extract-Transform-Load (ETL) transforma los datos antes de cargarlos al destino. Extract-Load-Transform (ELT) carga primero los datos brutos y los transforma dentro del sistema de destino. La elección correcta depende de la capacidad de cómputo de tu destino y la complejidad de tus transformaciones.
ETL es apropiado cuando tu destino carece de capacidad de procesamiento (por ejemplo, estás cargando en una base de datos ligera o un sistema de archivos planos), o cuando las reglas de privacidad de datos requieren enmascarar PII antes de que llegue al almacén. Los pipelines ETL son más complejos de operar pero te dan un control más estricto.
ELT se ha vuelto dominante con los almacenes de datos en la nube (BigQuery, Snowflake, Redshift) porque estos sistemas tienen cómputo abundante y pueden manejar transformaciones complejas en SQL a escala. Carga datos brutos rápido, luego usa dbt o SQL nativo para transformarlos. Iterar sobre transformaciones es más rápido y barato que reconstruir pipelines ETL.
Patrones de Integración de Fuentes
La extracción basada en API es el patrón más limpio cuando está disponible. Usa paginación basada en cursor (no basada en offset — los offsets se rompen con mutaciones de datos durante la extracción). Implementa extracción incremental mediante timestamps updated_at o números de secuencia de cambio. Las extracciones completas para tablas grandes son costosas e innecesarias una vez que tienes lógica incremental.
La replicación de base de datos mediante Change Data Capture (CDC) es el patrón más potente para bases de datos operacionales. Herramientas como Debezium capturan cambios a nivel de fila del log de transacciones de la base de datos (binlog para MySQL, WAL para Postgres) y los transmiten a Kafka o un bus de mensajes en la nube. Esto te da datos en tiempo casi real con impacto cero en la base de datos fuente.
Las fuentes basadas en archivos (volcados CSV, SFTP, cubos S3) requieren análisis defensivo. Nunca confíes en el esquema. Valida recuentos de columnas, tipos de datos y nulabilidad en cada archivo. Un socio que te envía un CSV con una columna extra o codificación cambiada un domingo romperá tu pipeline si no has incorporado resiliencia.
Transformar y Validar
La validación de calidad de datos no es opcional. Como mínimo, valida: los recuentos de filas coinciden con las expectativas, los campos requeridos son no nulos, los campos de fecha caen dentro de rangos plausibles y las claves foráneas se resuelven. Construye un framework de calidad de datos que se ejecute como parte de tu pipeline y alerte sobre violaciones en lugar de pasar silenciosamente datos malos hacia abajo.
La lógica de transformación debe estar bajo control de versiones, probada e idempotente. Si ejecutas una transformación dos veces sobre la misma entrada, debe producir la misma salida. Esta propiedad es esencial para reejecutar pipelines de forma segura después de fallos.
Usa un patrón de staging: carga los datos brutos en un esquema/tabla de staging primero, valídalos y transfórmalos allí, luego haz upsert en el esquema de producción final. Esto separa los fallos de ingesta de los fallos de transformación y hace que la depuración sea dramáticamente más fácil.
Capa de Almacenamiento y Servicio
Tu estrategia de almacenamiento debe coincidir con tus patrones de consulta. Los datos de series de tiempo con agregaciones continuas pertenecen a un almacén columnar optimizado para escaneos de rango (TimescaleDB, ClickHouse, BigQuery). Los datos centrados en entidades (perfiles de clientes, catálogos de productos) se leen mejor desde almacenes orientados a filas con buen indexado.
Implementa una capa de vistas materializadas para tus agregaciones más comunes. Pre-calcular rollups diarios/semanales/mensuales significa que tus dashboards se ejecutan en milisegundos en lugar de segundos, y tu base de datos no está re-escaneando miles de millones de filas cada vez que un usuario carga un informe.
Diseña tu estrategia de partición antes de que los datos crezcan. Particiona tablas grandes por fecha, tenant o región según tus patrones de filtro más comunes. Una consulta que poda el 99% de las particiones es órdenes de magnitud más rápida que un escaneo completo de tabla, y esta diferencia solo crece a medida que aumenta el volumen de datos.
Scheduling y Monitoreo
Elige tu orquestador según el tamaño del equipo y la complejidad. Para equipos pequeños, los cron jobs con alertas son suficientes para pipelines simples. Para pipelines complejos de múltiples pasos con dependencias, Airflow (o sus alternativas gestionadas: MWAA, Composer, Astronomer) es el estándar de la industria. Para equipos cloud-native, Prefect y Dagster ofrecen mejor experiencia de desarrollo.
Cada ejecución de pipeline debe producir métricas observables: filas extraídas, filas cargadas, filas fallidas, duración de ejecución, frescura de datos. Instrumenta tus pipelines para emitir estos datos a un almacén de métricas y construye dashboards. Los SLAs del equipo de datos dependen de saber cuándo algo va mal antes que tus stakeholders.
Implementa disyuntores y mecanismos de contrapresión. Si una API fuente empieza a devolver errores, no la bombardees con reintentos — retrocede exponencialmente y alerta al equipo. Si tu pipeline se está quedando atrás, libera carga de forma elegante en lugar de cascadear fallos hacia abajo.