Ruta hacia la ingeniería de datos

El almacenamiento de datos es la base de todo lo demás. La pregunta central que estructura este espacio es: ¿para qué sirve cada sistema? No existe un tipo de base de datos "mejor", sino el más adecuado para cada caso de uso.

La distinción más importante: OLTP vs OLAP

Como ingeniero de datos no gestionas sistemas transaccionales (OLTP), pero debes entender perfectamente cómo funcionan porque de ahí vienen tus datos. Tu terreno es OLAP: sistemas diseñados para leer grandes volúmenes y hacer análisis. Conocer la diferencia en profundidad — índices B-tree vs columnar, row store vs column store — te permite tomar decisiones de diseño inteligentes.

Sistemas relacionales y data warehouses

Almacenamiento masivo y analítico

Conceptos clave

Herramientas y decisiones de diseño

Explicación de cada área

SQL avanzado es no negociable

No SQL básico de SELECT y JOIN, sino window functions (ROW_NUMBER, LAG, LEAD, RANK), CTEs recursivos, optimización de queries con EXPLAIN ANALYZE, gestión de índices compuestos y particionado. El 80% de las entrevistas de data engineering avanzado tienen preguntas de SQL complejo.

El paradigma lakehouse es el presente

La industria está convergiendo hacia arquitecturas donde el object storage (S3/GCS) actúa como capa de almacenamiento universal, y tecnologías como Delta Lake o Apache Iceberg añaden propiedades ACID, time travel y evolución de esquemas encima. Entender Delta Lake y especialmente Iceberg es hoy prácticamente obligatorio en puestos senior.

El modelado dimensional sigue siendo fundamental

Aunque parezca anticuado, el esquema estrella de Kimball — tablas de hechos más dimensiones — sigue siendo la base de casi todos los data warehouses empresariales. dbt lo ha popularizado enormemente. Entender cuándo usar un esquema estrella frente a Data Vault o un modelo plano es una decisión arquitectónica que marca la diferencia.

Formatos de fichero: Parquet es el rey, pero debes conocer los demás

Parquet (columnar, comprimido) es el estándar de facto para analítica. Avro es mejor para streaming y evolución de esquemas. ORC es habitual en ecosistemas Hive/Hadoop. Entender por qué un fichero Parquet de 1 GB se lee 10 veces más rápido que el mismo CSV de 5 GB te hace mejor ingeniero.

El procesamiento es donde vive la mayor parte del trabajo diario de un data engineer. La clave para entenderlo todo es una distinción fundamental: batch vs streaming. Todo lo demás se construye sobre esa base.

Procesamiento batch

Grandes volúmenes, latencia tolerada (minutos a horas).

Procesamiento streaming

Eventos en tiempo real, latencia de milisegundos a segundos.

Motores SQL analíticos

Query engines sobre data lakes y warehouses.

Ruta recomendada: Spark (PySpark) + dbt → Spark Structured Streaming → Flink → Trino / DuckDB

Explicación de cada framework

Apache Spark es el centro del universo

No hay ningún otro framework con su combinación de adopción, versatilidad y profundidad. Lo que necesitas dominar de Spark no es solo la API, sino entender cómo funciona por dentro: el plan lógico y físico que genera Catalyst, por qué un shuffle es caro, qué son las particiones y cómo afectan al rendimiento, y cuándo usar cache() vs persist(). Un Spark avanzado es lo que separa a un engineer mid de uno senior.

dbt es el segundo imprescindible, y muchos lo subestiman

dbt ha cambiado la forma en que se hacen transformaciones en el warehouse: introduces tests de calidad de datos, documentación automática, linaje de modelos y CI/CD de transformaciones SQL. Su modelo de modelos en SQL con Jinja, los tests integrados y el lineage automático lo hacen esencial en cualquier stack moderno.

Batch antes que streaming, siempre

El 70% de los pipelines en producción son batch. El streaming añade complejidad operacional enorme — latencia de red, gestión de estado, semánticas de entrega exactamente una vez — que solo tiene sentido asumir cuando el caso de uso lo justifica de verdad.

DuckDB es la sorpresa de los últimos años

Un motor OLAP embebido que corre en local, lee Parquet directamente de S3, y puede procesar cientos de millones de filas en segundos en un portátil. Es ideal para exploración, pipelines pequeños y como alternativa ligera a Spark para volúmenes modestos.

La orquestación es el sistema nervioso de tu stack de datos — sin ella, tienes herramientas potentes pero sin coordinación. Es lo que convierte pipelines individuales en sistemas fiables y observables. La idea central es responder a: ¿qué se ejecuta?, ¿cuándo?, ¿en qué orden? y ¿qué pasa si falla?

Conceptos fundamentales en cualquier orquestador

Principales herramientas

Herramientas complementarias

Patrones esenciales

Empresa grande / legacy → Airflow | Startup / equipo pequeño → Prefect | Equipos maduros → Dagster | Solo SQL → dbt Cloud

Explicación de cada herramienta

Airflow es obligatorio conocerlo

Está en el 70-80% de las empresas medianas y grandes. Su modelo mental es simple: defines un DAG en Python, declaras tareas y sus dependencias, y el scheduler se encarga del resto. Lo que tienes que dominar en profundidad son los operators, los sensors y los XComs para pasar datos pequeños entre tareas.

Prefect resuelve la fricción de desarrollo

Decorar una función con @flow y @task y ya tienes un pipeline observable. Su concepto de "deployment" separa la definición del pipeline de cuándo y dónde se ejecuta. Si empiezas un proyecto nuevo o estás en un equipo pequeño, Prefect tiene una experiencia de desarrollo mucho más agradable.

Dagster representa el paradigma más moderno

Su idea central es que lo importante no son las tareas sino los assets: los artefactos de datos que produces. Dagster deriva el scheduling del linaje de assets. Esto lo hace extremadamente potente para equipos data maduros porque el linaje, la observabilidad y los tests están integrados desde el diseño.

Los patrones importan más que la herramienta

Tres principios fundamentales: idempotencia (tu pipeline debe poder ejecutarse dos veces sobre el mismo periodo y producir el mismo resultado), backfill (la capacidad de reejecutar periodos históricos cuando cambias la lógica), y separación entre orquestación y ejecución (el orquestador no debería hacer el trabajo pesado, solo coordinar).

Como data engineer, no gestionas servidores — diseñas sistemas de datos que viven en la nube. Lo que necesitas es entender los servicios suficientemente bien para elegir los correctos, conectarlos y optimizar su coste.

Equivalencias por proveedor

Infraestructura como código (IaC)

Redes y seguridad de datos

Optimización de costes

Ruta recomendada: 1. Elige UN proveedor principal (AWS es el más demandado) | 2. Domina S3 + Glue/EMR + Redshift + IAM | 3. Terraform para desplegar infra como código | 4. Docker imprescindible; K8s útil pero no urgente | 5. Certifícate: AWS Data Analytics Specialty o GCP DE Professional

Principios clave

La optimización de costes es el diferenciador que nadie enseña

En cloud, el coste lo controla quien diseña la arquitectura. Un pipeline que lee una tabla completa de 10 TB en BigQuery cuando podría leer solo la partición del día cuesta 50 veces más de lo necesario. Entender storage tiers en S3, usar instancias spot para jobs de Spark, particionar y hacer clustering en BigQuery es lo que hace que los equipos confíen en ti para decisiones de arquitectura.

Terraform es el salto que te convierte en senior

Saber describir toda tu infraestructura de datos en Terraform — buckets, roles, clusters, bases de datos — y desplegarla en minutos en cualquier entorno es lo que diferencia a un engineer que escala de uno que no. Es una habilidad muy valorada porque muy pocos data engineers la tienen.

La gobernanza y calidad del dato es el área más infravalorada del stack — y paradójicamente, la que más separa a los ingenieros mediocres de los realmente buenos. Cualquiera puede escribir un pipeline que mueve datos. Muy pocos saben garantizar que esos datos son correctos, trazables y confiables. La idea central: los datos son un producto, y como todo producto necesita control de calidad, documentación y responsables claros.

Las 6 dimensiones de calidad del dato

Herramientas de calidad y testing de datos

Linaje del dato

Normativa y privacidad

Conceptos clave en profundidad

El testing de datos tiene capas que debes conocer

Los unit tests comprueban que una transformación concreta produce el resultado correcto dado un input conocido. Los integration tests verifican que el pipeline completo funciona de extremo a extremo. Los contract tests comprueban que el schema de salida no ha roto a los consumidores. Los data quality tests comprueban que los datos reales cumplen las expectativas de negocio. Un data engineer experto tiene las cuatro capas.

Los data contracts son el artefacto de gobernanza más poderoso

Un data contract es un acuerdo formal entre el productor de un dato y sus consumidores: define el schema, las garantías de calidad, la frecuencia de actualización y quién es responsable. Convierte dependencias implícitas en acuerdos explícitos, versionados y verificables automáticamente.

GDPR tiene implicaciones técnicas directas

El "derecho al olvido" significa que debes ser capaz de borrar todos los datos de una persona de todos tus sistemas, incluyendo snapshots históricos, backups y logs. Eso requiere haber diseñado los pipelines con esto en mente desde el principio.

Un pipeline roto es visible: falla y lo arreglas. Un pipeline con datos incorrectos es invisible: nadie lo detecta hasta que el negocio toma malas decisiones.

El streaming es el salto conceptual más grande en data engineering. No es solo "batch más rápido" — es un paradigma completamente diferente. En batch, los datos ya existen y los procesas. En streaming, los datos llegan continuamente y los procesas a medida que aparecen. Eso cambia todo: cómo almacenas el estado, cómo manejas errores, cómo defines "cuándo está listo" un resultado.

Apache Kafka — arquitectura interna

Kafka no es una base de datos, es un log distribuido. Los mensajes se añaden siempre al final y nunca se modifican. Cada consumidor mantiene su propio offset de forma independiente.

Conceptos Kafka esenciales

El problema del tiempo en streaming

En streaming hay dos relojes que no siempre coinciden: el event time (cuándo ocurrió el evento en la realidad) y el processing time (cuándo llegó a tu sistema). Un pedido hecho a las 23:59 puede llegar a tu pipeline a las 00:03 por latencia de red.

Regla de oro: siempre usa event time si puedes. Processing time es más simple pero produce resultados incorrectos cuando hay latencia de red o datos desordenados.

Comparativa de motores de procesamiento

Conceptos avanzados

El stateful processing es lo que hace el streaming realmente difícil

Contar eventos por minuto es fácil (stateless). Pero calcular el total acumulado de ventas por usuario, o detectar si un usuario ha hecho más de 5 intentos de login en 10 minutos, requiere recordar eventos anteriores. Ese estado se almacena en memoria distribuida entre los workers, y la pregunta es: ¿qué pasa si un worker falla? Flink brilla aquí: sus checkpoints periódicos guardan el estado completo en almacenamiento duradero.

Exactly-once es más difícil de lo que parece

Las tres semánticas de entrega son: at-most-once (puede perderse algún evento), at-least-once (puede procesarse dos veces), y exactly-once (cada evento se procesa exactamente una vez). Flink con Kafka lo consigue mediante transacciones distribuidas. Spark Structured Streaming lo aproxima con micro-batch e idempotencia.

DataOps y MLOps no son herramientas — son filosofías de ingeniería aplicadas al mundo del dato y del machine learning. DevOps transformó el desarrollo de software añadiendo automatización, CI/CD y cultura de colaboración. DataOps hace lo mismo para pipelines de datos. MLOps extiende esa idea a modelos de machine learning.

DataOps — ingeniería de datos con mentalidad DevOps

MLOps — el rol del data engineer en el ciclo de ML

Conceptos clave

DataOps cambia la pregunta de "¿funciona?" a "¿es fiable de forma sostenible?"

La práctica más transformadora es el CI/CD de datos: cada cambio en un modelo dbt o en un pipeline de Spark dispara automáticamente una batería de tests antes de llegar a producción. Si los tests fallan, el despliegue se bloquea. Igual que en software, pero para datos.

El rol del data engineer en MLOps es muy específico

No entrenas modelos — garantizas que los datos para entrenarlos son correctos, frescos y reproducibles. Lo que construyes es la infraestructura de datos que hace posible que los modelos funcionen bien: los pipelines de feature engineering que transforman datos crudos en variables útiles, el feature store que garantiza que esas mismas variables se calculan igual en entrenamiento y en producción.

El training-serving skew es el problema más insidioso del ML

Ocurre cuando los datos con los que se entrenó un modelo se calculan de forma distinta a los datos que recibe ese modelo en producción. El modelo funciona perfectamente en desarrollo y falla silenciosamente en producción. El feature store elimina este problema porque centraliza el cálculo de features para ambos contextos.

La arquitectura de datos es donde dejas de ser alguien que implementa pipelines y te conviertes en alguien que diseña sistemas. Hay tres preguntas que estructuran todo este espacio: ¿cómo organizo mis datos internamente?, ¿con qué tecnología los almaceno?, y ¿cómo organizo los equipos alrededor de los datos?

Arquitectura medallion — organización interna de los datos

El principio clave: cada capa es inmutable respecto a la anterior. Si algo falla en Silver, puedes re-procesar desde Bronze sin perder datos originales. El dato crudo siempre se conserva.

Data warehouse vs Data lake vs Lakehouse

Data mesh — organización de equipos alrededor de los datos

Data mesh no es una tecnología — es una forma de organizar equipos y responsabilidades. Sus cuatro principios fundamentales:

El concepto de "data product" es la contribución más importante del data mesh

Un data product no es simplemente una tabla o un pipeline — es un artefacto de datos que tiene un dueño, un SLA de calidad y frescura, documentación, interfaces descubribles y un ciclo de vida gestionado. Esta forma de pensar, aplicada incluso sin implementar data mesh completo, eleva drásticamente la calidad del ecosistema de datos.

Cómo combinar los tres patrones en la práctica

En una arquitectura madura, los tres coexisten: arquitectura medallion para organizar las capas de datos dentro de cada dominio, lakehouse como tecnología de almacenamiento subyacente que da ACID y time travel sobre S3, y data mesh como modelo organizativo que define quién es responsable de qué. No son alternativas — son respuestas a preguntas diferentes.

La optimización no es un tema de rendimiento abstracto: es la diferencia entre un pipeline que cuesta 500 €/mes y uno que cuesta 50 €/mes haciendo exactamente lo mismo. La mentalidad del experto: nunca optimices sin medir primero. El 80% de los problemas de rendimiento están en el 20% del código.

Cómo piensa un motor de queries

El plan de ejecución es tu mapa — léelo siempre antes de optimizar. En Spark usas .explain(mode="formatted"), en BigQuery el Query Plan, en Snowflake el Query Profile.

Técnicas de optimización de almacenamiento

El small file problem

El enemigo silencioso del rendimiento. Miles de ficheros pequeños generan overhead de metadatos enorme. El objetivo es ficheros de 128-512 MB.

Estructuras auxiliares de búsqueda

Optimización avanzada de Spark

Flujo de diagnóstico del experto: Spark UI → identifica stage lento → EXPLAIN → localiza shuffle/skew → aplica la técnica correcta → mide de nuevo.

El shuffle es el villano principal del rendimiento en Spark

Cada vez que Spark necesita redistribuir datos entre workers — en un join, en un groupBy, en un distinct — mueve datos por la red. Ese movimiento es lento, caro y no paralelizable eficientemente. La estrategia más potente no es hacer el shuffle más rápido, sino eliminarlo. El broadcast join es tu primera línea: si una de las dos tablas cabe en memoria de cada worker, Spark la envía a todos y evita el shuffle completamente.

En BigQuery y Snowflake el modelo es diferente pero los principios son los mismos

No controlas particiones manualmente de la misma forma, pero sí controlas qué columnas se usan como partition key y clustering key. Leer 1 TB sin particionado cuando podrías leer 10 GB con un filtro sobre la partition date column es exactamente el mismo problema que el shuffle en Spark. La diferencia es que en BigQuery te lo cobran directamente en euros.

SQL es tu lengua materna del dato, Python es tu navaja suiza, y Scala es el bisturí de precisión para cuando el rendimiento importa de verdad. No necesitas dominarlos todos por igual — necesitas entender qué rol juega cada uno y hasta qué profundidad llegar.

SQL — tu lenguaje más importante

Python — tu herramienta universal

Scala — el lenguaje nativo de Spark

Prioridad: 1. SQL avanzado → 2. Python sólido como ingeniero → 3. PySpark en profundidad → 4. Scala (diferenciador senior)

SQL: el nivel de dominio que pocos tienen realmente

La mayoría de data engineers conocen SQL básico. Los expertos conocen SQL como un lenguaje de manipulación de sets, no de filas. Las window functions son el salto más importante: con LAG y LEAD calculas diferencias entre filas consecutivas sin self-joins; con SUM() OVER calculas acumulados sin subqueries; con ROW_NUMBER() OVER deduplicamos conservando la fila más reciente.

Polars está reemplazando a pandas en data engineering

Está escrita en Rust, usa evaluación lazy similar a Spark, maneja datos out-of-core, y es entre 5 y 50 veces más rápida que pandas en operaciones típicas. Para exploración y pipelines de datos medianos — los que no justifican un cluster de Spark — Polars es el estado del arte.

A partir de un cierto nivel técnico, el 80% del impacto viene de habilidades no técnicas. Los ingenieros técnicamente brillantes que no saben comunicar sus decisiones ni influir sin autoridad formal se quedan estancados en roles mid.

Comunicación — traducir entre mundos técnico y de negocio

Liderazgo técnico — influir sin autoridad formal

Gestión de proyectos — entregar con criterio, no con heroísmo

Colaboración interdisciplinar

La habilidad que multiplica todas las demás

Plantear el problema correcto antes de resolver cualquier problema. Un engineer junior construye lo que le piden. Un engineer experto cuestiona si es lo correcto y se asegura de que la solución resuelve el problema real de negocio.

Los ADRs son el artefacto de liderazgo técnico más infravalorado

Un ADR (Architecture Decision Record) es un documento corto — una página — que registra una decisión de arquitectura: cuál era el contexto, qué opciones se consideraron, qué se decidió y por qué. Su valor no está en el momento de escribirlo sino seis meses después, cuando alguien pregunta por qué se tomó una decisión concreta.

Saber decir no — con criterio y alternativa

La respuesta de un engineer experto no es "sí" (entregas algo frágil) ni "no es posible" (cierras la conversación). Es: "puedo entregarte algo funcional en dos días que cubre el 80% del caso de uso, pero tendríamos deuda técnica que necesitaríamos abordar en el sprint siguiente — ¿eso funciona o el 100% es bloqueante?". Eso es negociar scope.

La seguridad no es una capa que añades al final — es una decisión de diseño que tomas desde el principio. Un pipeline diseñado sin seguridad en mente es como una casa construida sin cerraduras: añadirlas después es posible pero caro, incómodo y nunca tan efectivo.

Control de acceso — quién puede ver qué y por qué

Cifrado — datos protegidos en reposo y en tránsito

PII y privacidad

Auditoría y trazabilidad

Los tres errores más comunes: 1. Credenciales hardcodeadas en código o repos Git | 2. Permisos excesivamente amplios: un pipeline de lectura con permisos de escritura | 3. PII en entornos de desarrollo: copiar datos de producción a dev sin anonimizar

El crypto-shredding es la solución más elegante al derecho al olvido

Cifrar los datos de cada usuario con una clave única almacenada en un key-value store separado. Cuando el usuario ejerce su derecho al olvido, borras su clave — el dato sigue físicamente en el fichero Parquet, pero es criptográficamente inaplicable, equivalente a no existir.

La gestión de secretos es donde más vulnerabilidades críticas aparecen

El patrón más peligroso es hardcodear credenciales directamente en el código Python o en ficheros de configuración que acaban en Git. Basta con que ese repositorio sea accidentalmente público durante cinco minutos para que bots automatizados capturen las credenciales. La solución correcta es usar un gestor de secretos y configurar rotación automática.

Sin observabilidad, operas a ciegas: no sabes si tus pipelines funcionan correctamente hasta que alguien se queja de que los datos están mal. La distinción fundamental: monitorización es saber que algo ha fallado. Observabilidad es entender por qué ha fallado sin tener que añadir nuevo código para investigarlo. La primera te alerta; la segunda te da el contexto para resolverlo.

Las tres capas de observabilidad

Métricas de datos — la salud del dato, no solo del pipeline

Herramientas de observabilidad

SLAs de datos — el contrato entre ingeniería y negocio

Un pipeline sin observabilidad es como conducir con los ojos cerrados: funciona hasta que deja de funcionar. La observabilidad no es para cuando algo falla — es para saber que todo va bien antes de que alguien lo note.

La métrica de frescura es la más importante para el negocio

Un analista no sabe si tu Spark job tardó 20 minutos en vez de 10. Sí sabe si el dashboard de ventas muestra datos de ayer cuando debería mostrar los de hoy. La frescura es el puente entre el mundo técnico y el de negocio. Implementarla es simple: en cada tabla añades una columna _updated_at, y una query periódica comprueba que max(_updated_at) > NOW() - INTERVAL threshold.

Los logs estructurados son la diferencia entre debuggear en horas o en minutos

Un log como "ERROR: pipeline failed" no dice nada útil. Un log estructurado en JSON con campos como pipeline_id, run_date, source_table, rows_processed, error_code y duration_seconds se puede filtrar, agregar y correlacionar automáticamente. La regla de oro: cualquier cosa que necesitarías saber para diagnosticar un fallo debe estar en el log desde el principio.

El alert fatigue es el enemigo silencioso de la observabilidad

Si tu sistema dispara 50 alertas al día y la mitad son falsas alarmas, tu equipo aprende a ignorarlas — incluidas las que importan. La disciplina de los tres niveles de severidad es fundamental: P1 son alertas que requieren acción inmediata porque afectan a datos en producción; P2 requieren atención en las próximas horas; P3 son anomalías que revisas en el siguiente ciclo de trabajo.

MTTR y MTBF son las métricas que importan a dirección

El Mean Time To Resolution y el Mean Time Between Failures son los indicadores que traducen la calidad de tu ingeniería a términos comparables entre periodos. Si tu MTTR mejora de 4 horas a 45 minutos en un trimestre, tienes un argumento concreto de impacto para cualquier conversación de desempeño.