Roadmap de Data Engineering

La Ingeniería de Datos es la disciplina que permite a las organizaciones gestionar y maximizar el valor de sus datos. Se enfoca en la arquitectura, diseño y gestión de la infraestructura de datos, con el objetivo de analizar, limpiar y procesar datos masivos de manera eficiente.

Los Data Engineers son responsables de diseñar, construir, mantener, monitorear y optimizar los procesos ETL/ELT (pipelines de datos). Para eso combinan habilidades como programación (Python, Java, SQL), bases de datos relacionales y no relacionales, procesos ETL, tecnologías de Big Data (Hadoop, Spark, Kafka), cloud computing (AWS, GCP, Azure), modelado de datos, sistemas distribuidos y automatización.

Un pipeline de datos moderno suele seguir cinco etapas: recolección (streams, apps, archivos), ingesta (batch o eventos), almacenamiento (data lake, warehouse o lakehouse), procesamiento (batch o streaming) y consumo (BI, analytics, data science, IA/ML), todo esto envuelto en capas transversales de orquestación, gobierno, calidad y catálogo de datos.

OLTP vs. OLAP

Son dos enfoques fundamentales pero distintos para el procesamiento de datos. OLTP (Online Transaction Processing) maneja las operaciones diarias de una organización: transacciones en tiempo real, alta concurrencia de usuarios, datos actuales y detallados. Ejemplos típicos son sistemas de reservas, procesamiento de pedidos o banca en línea.

OLAP (Online Analytical Processing), en cambio, se centra en el análisis de datos históricos para la toma de decisiones: consultas complejas y multidimensionales sobre datos agregados, optimizadas para lectura más que para escritura. Se usa en reportes financieros, análisis de tendencias y planificación estratégica.

La mayoría de las organizaciones modernas usan ambos sistemas de manera complementaria: OLTP para operar el negocio día a día, OLAP para entenderlo y proyectarlo.

ETL vs. ELT

La integración de datos consolida información de múltiples fuentes en una vista unificada. Existen dos enfoques principales:

ETL (Extract, Transform, Load): los datos se extraen, se transforman para cumplir los requisitos del destino y luego se cargan. Garantiza calidad y consistencia antes del almacenamiento, pero puede ser lento y costoso en infraestructura intermedia. Herramientas típicas: Informatica, Talend, SSIS.

ELT (Extract, Load, Transform): los datos se cargan primero en el destino y se transforman ahí, aprovechando la capacidad de cómputo de plataformas cloud modernas. Es más eficiente para grandes volúmenes y reduce infraestructura intermedia, pero exige sistemas de destino potentes y más cuidado con seguridad y cumplimiento. Herramientas típicas: Snowflake, BigQuery, Redshift.

Tip: si la calidad y consistencia de los datos son la prioridad, o el sistema destino es limitado, ETL suele ser la mejor opción. Si el volumen es grande y trabajás sobre un warehouse cloud potente, ELT es más eficiente y escalable.

Data Lake vs. Data Warehouse vs. Lakehouse

En la era del Big Data existen distintas soluciones de almacenamiento, cada una con ventajas y casos de uso propios:

• Data Lake: repositorio centralizado que almacena datos en su forma cruda (estructurados, semi-estructurados y no estructurados). Es flexible, escalable y económico, pero sin buena gobernanza puede convertirse en un "Data Swamp" (pantano de datos difíciles de encontrar y usar). Ideal para Big Data, Machine Learning e IoT. Ejemplos: Amazon S3, Azure Data Lake Storage, HDFS.
• Data Warehouse: sistema optimizado para datos estructurados, con consultas rápidas, alta calidad y consistencia, pero más rígido y costoso de mantener. Ideal para reporting empresarial y decisiones estratégicas. Ejemplos: Snowflake, BigQuery, Redshift.
• Data Mart: subconjunto especializado de un Data Warehouse orientado a un departamento (finanzas, marketing, ventas). Rápido de implementar y económico, aunque limitado en alcance y con riesgo de duplicar datos entre distintos marts.
• Lakehouse: arquitectura híbrida que combina la flexibilidad del Data Lake con la gestión y optimización del Data Warehouse, permitiendo ingesta de datos crudos y análisis estructurado sobre la misma infraestructura. Requiere una curva de aprendizaje mayor, pero reduce duplicación de sistemas. Ejemplos: Databricks Delta Lake, Snowflake, BigLake, Azure Synapse.

Como evolución adicional aparece el Data Mesh, una arquitectura descentralizada donde cada dominio de negocio es dueño de sus propios datos como producto, en lugar de centralizarlos en un único equipo o repositorio. Gana en escalabilidad y agilidad organizacional, pero suma complejidad de gobierno.

Batch vs. Streaming

Son los dos grandes paradigmas de procesamiento de datos:

Batch: recolecta y procesa grandes volúmenes de datos en intervalos (diario, semanal, mensual). Es económico y simple, ideal para informes financieros, ETL y análisis histórico. Una variante intermedia es el micro-batch, que procesa en ventanas de minutos u horas.

Streaming: captura y analiza datos en tiempo real a medida que se generan. Es indispensable cuando la inmediatez importa: monitoreo de sistemas, IoT, trading, redes sociales. Existe también el enfoque near real-time, con latencia baja pero no instantánea, útil como balance entre costo e inmediatez.

Herramientas de referencia: Spark (batch y micro-batch) sobre EMR o Glue; Kafka, Flink y Kinesis para streaming. La elección depende de cuánto necesitás de inmediatez versus cuánto podés/querés invertir en infraestructura.

Modelado de datos

El modelado de datos define cómo se capturan, almacenan y usan los datos en una organización, estableciendo relaciones entre entidades. Existen cuatro niveles: conceptual (estructura lógica de negocio), lógico (relaciones y atributos), físico (implementación en el motor de base de datos) y dimensional (orientado a análisis, con hechos y dimensiones).

En el modelo dimensional, las tablas de hechos almacenan medidas numéricas del negocio (ventas, costos) y se conectan a tablas de dimensiones, que aportan contexto descriptivo (producto, cliente, ubicación). Existen además tablas de relación (para vínculos muchos-a-muchos) y tablas de stock (para saldos o inventarios en un punto del tiempo).

Sobre esa base surgen dos esquemas clásicos:

• Esquema estrella: una tabla de hechos central conectada directamente a las dimensiones. Simple, rápido de consultar (menos joins), pero con redundancia de datos.
• Esquema copo de nieve (snowflake): normaliza las dimensiones en subtablas relacionadas. Reduce redundancia y modela mejor jerarquías complejas, a costa de más joins y mayor complejidad de diseño.

Una técnica avanzada clave son las Dimensiones Cambiantes Lentamente (SCD), que manejan cómo evoluciona un atributo en el tiempo: desde sobrescribir el valor (Tipo 1) hasta agregar una fila nueva por cada cambio para preservar historial completo (Tipo 2), o guardar un número limitado de versiones en columnas adicionales (Tipo 3). Otras técnicas relevantes son las tablas de hechos sin hechos (para registrar eventos o relaciones sin medidas numéricas), las dimensiones degeneradas (identificadores que viven directamente en la tabla de hechos) y metodologías como Data Vault (con Hubs, Links y Satellites, pensada para flexibilidad y trazabilidad a largo plazo) o el modelado en grafos, útil para datos altamente interconectados como redes sociales o detección de fraude.

Normalización y denormalización

Son dos enfoques de diseño de bases de datos con efectos opuestos sobre rendimiento, integridad y redundancia.

La normalización organiza las tablas para reducir redundancia y dependencias, siguiendo las formas normales (1NF, 2NF, 3NF): eliminar grupos repetitivos, asegurar que los atributos dependan completamente de la clave primaria y eliminar dependencias transitivas. Es el enfoque típico en sistemas OLTP, porque favorece escrituras rápidas y consistentes.

La denormalización agrega redundancia de forma controlada —combinando tablas, duplicando columnas o creando tablas de resumen— para acelerar las lecturas. Es la norma en sistemas OLAP, donde priorizás reportes rápidos sobre volúmenes grandes de datos, sacrificando algo de espacio y complejidad de actualización.

Tip: empezá siempre con un diseño normalizado y aplicá denormalización solo cuando el rendimiento lo justifique, no de forma anticipada.

Particionado, indexación y bucketing

Tres técnicas complementarias para organizar datos a gran escala:

• Particionado: divide un conjunto de datos grande en partes más chicas según una o más columnas (por ejemplo, año y mes), reduciendo la cantidad de datos que hay que escanear en cada consulta y facilitando el ciclo de vida de los datos. Es la técnica de elección para filtrado por rangos grandes, como series históricas.
• Indexación: estructuras adicionales que aceleran búsquedas puntuales, sin dividir físicamente los datos. Ocupan espacio extra y requieren mantenimiento, pero son muy efectivas en cargas OLTP.
• Bucketing: agrupa datos en "cubos" según el hash de una columna, logrando una distribución más uniforme. Es especialmente útil para joins y agregaciones frecuentes.

Estas técnicas no son excluyentes: es común combinarlas según el patrón de consulta. Una mala práctica frecuente es sobre-particionar, generando demasiadas particiones pequeñas que terminan penalizando el rendimiento en vez de mejorarlo.

Formatos de tabla modernos: Iceberg y afines

Los formatos de tabla open source como Apache Iceberg (originado en Netflix) resolvieron un problema clásico de los data lakes: la falta de transacciones ACID, evolución de esquema segura y "time travel" sobre archivos Parquet/ORC crudos. Iceberg aporta control de versiones, particionamiento oculto (gestionado automáticamente sin exponer detalles al usuario) y compatibilidad con motores como Spark, Flink, Trino o Athena. Junto con alternativas como Delta Lake, es la base técnica que hizo posible la arquitectura Lakehouse.

Orquestación y DataOps

Los pipelines de datos rara vez son un único paso: encadenan extracción, transformación, validaciones y cargas que dependen unas de otras. La orquestación —con herramientas como Airflow, Dagster o Prefect— se encarga de programar, secuenciar, reintentar y monitorear esas tareas, garantizando que cada pipeline corra en el orden correcto y que los fallos se detecten a tiempo.

DataOps aplica los principios de DevOps al mundo de los datos: integración y entrega continua de pipelines, automatización de pruebas de calidad, versionado de esquemas y colaboración estrecha entre equipos de datos y de operaciones. El objetivo es el mismo que en DevOps —mayor velocidad y confiabilidad— pero aplicado a la infraestructura y los flujos de datos.

Ruta de aprendizaje sugerida (2025)

Como punto de partida práctico, un camino razonable combina: SQL y Python como base, control de versiones con Git, librerías de procesamiento como pandas, Polars o DuckDB, orquestadores como Airflow, transformación con dbt, y motores de cómputo distribuido como Spark. Sobre esa base se apoyan las plataformas cloud (BigQuery, Redshift, Snowflake, Databricks) y los formatos de tabla modernos (Parquet, Iceberg, Delta Lake) para almacenamiento.

En resumen

La Ingeniería de Datos no es una única tecnología sino un conjunto de decisiones de arquitectura: cuándo usar OLTP o OLAP, ETL o ELT, lake o warehouse, batch o streaming, normalizar o denormalizar. Ninguna de estas decisiones es universal — dependen del volumen de datos, la latencia que necesita el negocio y el presupuesto disponible. Entender el trade-off detrás de cada par de conceptos es, en la práctica, el verdadero trabajo de un Data Engineer.