Data Engineering — Career Path 2026

01

Nivel 1

Trainee

Cimentación sin atajos. Antes de construir pipelines, hay que entender cómo los datos se representan en memoria y en disco, cómo se consultan con SQL eficientemente y cómo Linux orquesta procesos. Todo el ecosistema de data engineering descansa sobre estos pilares.

Área	Tema Específico	Objetivo	Dif.	Recursos	Proyecto / Validación	Criterio de Éxito
Python para Datos	Python: tipos, I/O, manejo de archivos y entornos virtuales CSV · JSON · tipos mutables/inmutables · pathlib · context managers · uv · pyproject.toml · type hints básicos	Usar Python como lengua franca de datos: leer, transformar y escribir ficheros de distintos formatos sin depender de librerías externas, con entornos reproducibles desde el primer día.	Fácil	Harvard CS50P (Python fundamentos) uv — Python package manager	ETL script en Python puro: leer CSVs de múltiples fuentes con `pathlib`, combinarlos, limpiar nulos y exportar en JSON. Proyecto con `uv` + `pyproject.toml` reproducible en una VM limpia.	PythonUsa `pathlib.Path` en vez de `os.path`; cierra archivos con context managers; `uv sync` replica el entorno en otra máquina sin errores; type hints en todas las funciones públicas.
SQL Fundamentos	SQL: SELECT, JOINs, GROUP BY, subqueries y filtrado avanzado INNER / LEFT / RIGHT JOIN · agregaciones · HAVING · subqueries correlacionadas · CASE WHEN · NULL handling · DISTINCT · ORDER BY Python I/O (los datos que se consultan)	Dominar la herramienta de acceso a datos más universal — SQL se usa en todos los niveles de data engineering desde el primer día hasta el último.	Fácil	Mode SQL Tutorial SQLZoo (ejercicios interactivos)	Resolver 30 ejercicios progresivos en SQLZoo/Mode: desde SELECT básico hasta subqueries correlacionadas; documentar qué hace cada cláusula y por qué se eligió el tipo de JOIN.	30 ejercicios completados; cada solución con comentario de lógica; sin `SELECT *` innecesario; NULL manejado explícitamente con `COALESCE` o `IS NULL`.
SQL Avanzado	Window functions, CTEs y análisis de planes de ejecución ROW_NUMBER · RANK · LAG/LEAD · SUM OVER (PARTITION BY) · WITH (CTE) · CTEs recursivas · EXPLAIN básico · índices y por qué importan SQL fundamentos (JOINs + GROUP BY)	Escribir consultas analíticas complejas con window functions —el caballo de batalla de cualquier transformación en dbt, BigQuery o Snowflake— y leer un plan de ejecución básico.	Medio	Use The Index, Luke! windowfunctions.com (interactivo)	Analizar un dataset de ventas de e-commerce: top-3 productos por categoría por mes (window function), 7-day rolling average de revenue (LAG), clientes con compra consecutiva (CTE recursiva).	Todas las queries con window functions correctas y verificadas contra resultado esperado; EXPLAIN muestra uso de índices en al menos una query; CTEs nombradas descriptivamente.
Linux y Bash	Linux esencial para datos: bash scripting, cron y pipes pipes · grep/awk/sed · cron expressions · find · sort/uniq · gzip/tar · chmod · variables de entorno · script con exit codes Python (conceptos de scripting previos)	Operar en entornos de servidor donde viven los pipelines: mover, comprimir y filtrar datos con herramientas nativas sin levantar Python; programar ejecuciones periódicas con cron.	Fácil	The Linux Command Line (W. Shotts) crontab guru (editor visual)	Script bash que descarga un archivo CSV diario, lo valida (líneas > 0, header correcto), lo comprime y lo mueve a una carpeta de archivos procesados, con logs y exit codes semánticos.	Script retorna exit 1 ante cualquier fallo y exit 0 ante éxito; cron job programado a las 2am con log capturado en archivo rotante; sin hardcodear paths, usa variables de entorno.
Modelado de Datos	Modelado relacional: ER diagrams, normalización y claves Entidades y relaciones · 1NF / 2NF / 3NF · primary key · foreign key · cardinalidad · índices básicos · cuándo y por qué desnormalizar SQL fundamentos (las tablas que se modelan)	Diseñar esquemas que garanticen integridad de datos a nivel de base de datos — la base sobre la que todo modelo dimensional y toda pipeline se construyen.	Medio	Lucidchart: ER Diagram Guide PostgreSQL Foreign Key Tutorial	Diseñar el esquema de una plataforma de e-commerce (usuarios, productos, categorías, órdenes, ítems) en 3NF con diagrama ER; justificar por qué no normalizar la tabla de eventos de click.	Diagrama ER con cardinalidades correctas; todas las FKs definidas; justificación documentada de la decisión de desnormalización; esquema implementado en PostgreSQL y verificado con datos de prueba.
Formatos de Datos	Formatos de almacenamiento: CSV, JSON, Avro y Parquet Row vs columnar · schema-on-read vs schema-on-write · compresión Snappy/ZSTD · predicado pushdown · Parquet con pyarrow · Avro con fastavro Python I/O (lectura y escritura) + Modelado (schemas)	Elegir el formato correcto según el patrón de acceso (analítico vs transaccional) para reducir el costo de storage y la latencia de queries — decisión crítica en cualquier lakehouse.	Medio	PyArrow Docs Apache Parquet Format Spec	Convertir un dataset de 1M de filas de CSV a Parquet con compresión Snappy; comparar tamaño en disco y tiempo de lectura de una sola columna entre CSV y Parquet. Documentar el resultado con números.	PythonParquet al menos 5x más pequeño que CSV; lectura de columna única con predicado pushdown al menos 10x más rápida; benchmark reproducible con `time.perf_counter()` en Python.
Git para Datos	Git workflow: commits semánticos, branching y .gitignore para datos Conventional Commits · feature branches · rebase interactivo · .gitignore para datasets y credenciales · DVC conceptos · pre-commit hooks Python + Linux (entornos de trabajo)	Versionar código de pipelines con historial limpio y nunca exponer datos sensibles o credenciales en un repositorio — error crítico en data engineering.	Fácil	Conventional Commits Spec pre-commit framework	Proyecto de datos con +15 commits semánticos, pre-commit hook con detect-secrets que bloquea credenciales, y .gitignore que excluye datasets, archivos .env y outputs intermedios.	Hook bloquea commit con API key antes de que llegue al repo; datasets nunca versionados en git; historial legible con mensajes tipo `feat(ingestion): add retry logic for API calls`.
Cloud Fundamentos	AWS S3 e IAM: almacenamiento de objetos y gestión de acceso Buckets · prefijos · políticas de IAM · least privilege · AWS CLI · boto3 básico · storage classes · lifecycle policies · presigned URLs Python (boto3) + Linux (AWS CLI) + Formatos (lo que se guarda en S3)	Operar S3 como capa de almacenamiento universal de un data lake — la base de toda arquitectura moderna de datos en AWS (usado por Airbnb, Netflix y Uber como store primario).	Fácil	AWS S3 Docs boto3 Docs	Script Python con boto3 que sube Parquet files a S3 en estructura de partición por año/mes/día, configura lifecycle policy para mover a S3 Glacier después de 90 días y crea URLs firmadas de descarga.	PythonIAM role con permisos mínimos (no access keys hardcodeadas); estructura de partición Hive-compatible `year=2026/month=02/day=22/`; lifecycle policy verificada en consola AWS.
Conceptos ETL	ETL vs ELT: batch vs streaming y el ecosistema moderno de datos ETL tradicional · ELT cloud-native · batch vs micro-batch vs streaming · data warehouse vs data lake vs lakehouse · herramientas clave del modern data stack Todos los temas anteriores (punto de síntesis del nivel Trainee)	Comprender el mapa conceptual completo del ecosistema de data engineering para poder elegir la herramienta correcta para cada problema sin sesgos de herramienta.	Fácil	dbt Labs: ETL vs ELT Databricks: Medallion Architecture	Diagrama comparativo de 3 arquitecturas (ETL clásico, ELT cloud-native, Lakehouse) con trade-offs de costo, latencia y complejidad; presentación de 5 minutos explicando cuándo elegir cada una.	Diagrama con flujo de datos completo para cada arquitectura; trade-offs documentados con ejemplos de empresas reales; justificación de herramienta para un caso de negocio dado.

02

Nivel 2

Junior Data Engineer

De scripts a pipelines. El Junior construye ingestas, transforma datos con dbt, orquesta con Airflow y los sirve desde un data warehouse real. La fiabilidad es el diferenciador: pipelines con reintentos, tests de calidad y observabilidad básica desde el primer deploy.

Área	Tema Específico	Objetivo	Dif.	Recursos	Proyecto / Validación	Criterio de Éxito
PostgreSQL Avanzado	PostgreSQL: EXPLAIN ANALYZE, índices avanzados, particionado y VACUUM EXPLAIN ANALYZE · B-tree vs BRIN · índices parciales · particionado por rango/hash · VACUUM/AUTOVACUUM · pg_stat_statements · UPSERT con ON CONFLICT SQL avanzado + Modelado relacional	Operar PostgreSQL como almacén transaccional y fuente de datos de pipelines con fluencia: diagnosticar queries lentas, diseñar índices correctos y mantener la salud de las tablas.	Medio	explain.depesz.com (visualizador) PostgreSQL Tutorial	Optimizar una query de análisis de órdenes de 5s a <200ms en una tabla de 10M filas; documentar EXPLAIN ANALYZE antes/después; implementar UPSERT idempotente para ingesta diaria.	PythonEXPLAIN ANALYZE evidencia ≥10x mejora; sin Seq Scan tras optimización; UPSERT idempotente verificado con test que re-ejecuta la misma ingesta dos veces y obtiene resultado idéntico.
Python para Datos	pandas, polars y DuckDB para transformaciones en memoria pandas I/O y operaciones core · polars lazy API · DuckDB SQL sobre DataFrames · agrupaciones · merge/join · apply vs vectorización · memoria eficiente Python fundamentos + SQL avanzado + Formatos (Parquet)	Transformar datasets de millones de filas en memoria con pandas/polars y SQL analítico con DuckDB sin salir de Python — la navaja suiza de transformación del data engineer moderno.	Medio	Polars User Guide DuckDB Python API	Pipeline que lee 5M filas de Parquet, ejecuta joins y window functions con polars lazy API y DuckDB SQL, exporta resultados; benchmark vs pandas mostrando diferencia de velocidad y memoria.	PythonPolars/DuckDB al menos 3x más rápido que pandas equivalente; uso de memoria constante con lazy API; sin `.apply()` de Python en hot paths; benchmark con `memory_profiler` como evidencia.
Ingesta de Datos	Extracción de datos: APIs REST, webhooks y conectores con Python Paginación · rate limiting · OAuth2 · reintentos con backoff · schemas variables · incremental vs full load · checkpointing · dlt (data load tool) Python avanzado (httpx/requests) + Cloud S3 (destino) + Git (versionar extractores)	Construir extractores robustos que soporten fallos de red, cambios de schema y volúmenes variables — la primera etapa del pipeline y la más frágil si no se diseña correctamente.	Medio	dlt (data load tool) Docs Airbyte Docs	Extractor de la API de GitHub con dlt: commits y PRs con paginación automática, incremental load por fecha de última ejecución, checkpoint en caso de fallo, destino en Parquet en S3.	PythonRe-ejecución tras fallo no duplica datos; rate limit de GitHub respetado; schema inferido automáticamente; log con número de filas ingestadas y tiempo de ejecución por run.
Orchestración	Apache Airflow: DAGs, operadores, XCom, sensores y reintentos DAG definition · PythonOperator · BashOperator · S3Sensor · XCom para pasar datos · retries con exponential backoff · catchup · SLA miss alerts Python (los DAGs son código Python) + Linux/cron (reemplaza cron) + S3 (fuente/destino de tareas)	Orquestar pipelines complejos con dependencias explícitas, reintentos automáticos y visibilidad de estado — Airflow fue creado en Airbnb y es el estándar de facto de la industria.	Medio	Apache Airflow Official Docs Astronomer Docs (Airflow managed)	DAG de ingesta diaria: S3Sensor espera el archivo fuente → extracción Python → validación → carga a DW; retry 3x con backoff exponencial; alerta por email si SLA de 2h no se cumple.	PythonPipeline completo visible en Airflow UI con dependencias; retry recupera exitosamente un fallo simulado; XCom pasa row count entre tareas; ningún secret hardcodeado en el DAG.
Data Warehouse	Snowflake o BigQuery: arquitectura, virtual warehouses y clustering Separación storage/compute · virtual warehouses · auto-suspend · clustering keys · Time Travel · COPY INTO · query cost estimation · roles y grants SQL avanzado + Cloud S3 (staging area) + Formatos Parquet (lo que se carga)	Operar un data warehouse cloud-native con fluidez: cargar datos eficientemente, controlar costos y entender la arquitectura que permite escalar compute independientemente del storage.	Medio	Snowflake Docs BigQuery Docs	Cargar el dataset de GitHub (Parquet en S3) a Snowflake con COPY INTO; crear clustering key en columna de fecha; medir créditos consumidos antes/después del clustering en una query analítica.	Carga COPY INTO exitosa con validación de row count; clustering reduce particiones escaneadas ≥60% medido con EXPLAIN; roles con least privilege separados por entorno (dev/prod).
Transformación	dbt Core: models, sources, tests genéricos y documentación `ref()` · `source()` · Materializations (view/table/incremental) · tests: not_null, unique, accepted_values · docs generate · lineage graph SQL avanzado + Data Warehouse (donde corren los models) + Git (control de versiones de SQL)	Transformar datos en el data warehouse con prácticas de software engineering: modularidad, testing, documentación y linaje automático — el estándar de transformación en 2026.	Medio	dbt Core Docs dbt Fundamentals (curso gratuito)	Proyecto dbt con capa staging → intermediate → marts para el dataset de GitHub; tests genéricos en todas las columnas PK; documentación navegable con `dbt docs serve`; gráfico de linaje completo.	Python`dbt test` pasa en 100% de los models; linaje completo desde `source()` hasta mart; ningún model sin descripción en `schema.yml`; `dbt compile` sin warnings.
Arquitectura de Datos	Medallion Architecture: capas Bronze / Silver / Gold Raw ingesta (Bronze) · datos limpios y validados (Silver) · agregados de negocio (Gold) · naming conventions · idempotencia por capa · particionado por ingesta date Airflow (orquesta cada capa) + dbt (transforma Silver → Gold) + S3 (almacena Bronze/Silver) + DW (sirve Gold)	Estructurar el data lake con un patrón de capas que garantice reproducibilidad, trazabilidad y recuperación ante fallos — patrón adoptado por Databricks, Netflix y Airbnb.	Medio	Databricks: Medallion Architecture Delta Lake Intro	Pipeline end-to-end con 3 capas en S3: Bronze (raw JSON sin tocar), Silver (Parquet limpio y validado), Gold (tabla agregada en Snowflake consumible por BI); re-ejecutar Silver desde Bronze sin pérdida de datos.	Bronze nunca modificado tras ingestión; re-proceso de Silver idempotente verificado con test; Gold en Snowflake actualizado en <30 min tras nueva ingesta; arquitectura documentada con diagrama.
Data Quality	Calidad de datos: Great Expectations y tests personalizados en dbt Expectations: not_null · unique · between · regex · Great Expectations con Airflow · dbt singular tests (SQL custom) · alertas ante degradación dbt (tests genéricos ya vistos) + Airflow (donde se ejecutan las validaciones) + Medallion (qué capa validar)	Detectar datos corruptos antes de que lleguen a capas Gold y a analistas — "bad data is worse than no data" y es la queja número uno de equipos de analytics según State of Data Quality 2025.	Medio	Great Expectations Docs dbt: Data Tests	Suite de validaciones en Silver: nulls en columnas críticas, rangos de fechas razonables, FK integridad; alerta en Slack si un batch falla más del 1% de expectativas; test singular dbt para duplicados por ventana temporal.	PythonAlerta de Slack enviada en <5 min ante fallo de expectativa; test singular detecta duplicados reales plantados; 0 datos corruptos en capa Gold verificado con query de auditoría.
Docker para Datos	Docker y Docker Compose para pipelines de datos locales Dockerfile multi-stage para Airflow local · Compose con Airflow + PostgreSQL + LocalStack (mock S3) · volúmenes para datos · healthchecks Airflow (servicio a contenerizar) + PostgreSQL (backend de Airflow) + S3 (mock con LocalStack)	Levantar el stack completo de data engineering localmente en un comando para onboarding rápido y reproducibilidad total del entorno de desarrollo.	Medio	Airflow: Docker Compose Quickstart LocalStack Docs (mock AWS)	Compose con Airflow + PostgreSQL + LocalStack que levanta el stack completo en <3 min; DAG de ingesta funciona apuntando a LocalStack S3; dev corre pipelines localmente sin acceso a AWS real.	Stack levantado desde cero en <3 min con `docker compose up`; pipeline completo corre contra LocalStack; datos persisten entre reinicios con volúmenes; onboarding documentado en README de <10 pasos.

03

Nivel 3

Semi-Senior (SSR)

Escala y profundidad técnica. El SSR domina el procesamiento distribuido con Spark, introduce streaming con Kafka, diseña modelos dimensionales y construye pipelines CI/CD para datos. Ya no sólo opera el modern data stack: sabe por qué cada herramienta existe y cuándo no usarla.

Área	Tema Específico	Objetivo	Dif.	Recursos	Proyecto / Validación	Criterio de Éxito
Spark	Apache Spark: arquitectura, PySpark DataFrames y optimización Driver/executor · DAG de jobs · shuffle · particionado · broadcast joins · cache/persist · Adaptive Query Execution (AQE) · catalyst optimizer · Spark UI Python (PySpark es Python) + Formatos Parquet (lo que procesa Spark) + Conceptos ETL (por qué Spark sobre pandas)	Procesar datasets de decenas o cientos de GB con Spark de forma eficiente —herramienta central en Netflix (Iceberg), Airbnb (Spark 3 + Iceberg) y Databricks— sin desperdiciar recursos de cluster.	Difícil	PySpark API Docs Databricks Academy (free)	ETL distribuido de un dataset público de 10GB+ (NYC taxi trips): limpiar, enriquecer con lookup tables usando broadcast join, calcular métricas por zona y escribir en Parquet particionado; analizar Spark UI para identificar y resolver un shuffle costoso.	PythonSin `.collect()` innecesario en hot paths; broadcast join aplicado correctamente; AQE habilitado; Spark UI muestra reducción ≥30% del tiempo tras optimización del shuffle; particionado Hive-compatible.
Table Formats	Apache Iceberg y Delta Lake: ACID, time travel y schema evolution ACID en object storage · snapshot isolation · time travel · schema evolution · partition evolution · compaction · hidden partitioning · Iceberg REST catalog Spark (motor de lectura/escritura) + S3 (storage) + Medallion Architecture (capas que usa Iceberg)	Construir un lakehouse con garantías ACID sobre S3 — el reemplazo moderno de Hive que usan Airbnb (Iceberg + Spark 3), Netflix (Iceberg) y Uber (Delta Lake) para sus pipelines de producción.	Difícil	Apache Iceberg Docs Delta Lake Learn	Migrar el pipeline de NYC taxi trips a tablas Iceberg en S3: demostrar time travel a snapshot de ayer, evolucionar schema añadiendo columna sin downtime, ejecutar compaction y medir mejora de query performance.	PythonTime travel a snapshot previo en <5s; schema evolution sin reescribir datos históricos; compaction reduce número de small files en ≥70%; ACID verificado con escritura concurrente en test.
Streaming	Apache Kafka: topics, particiones, consumer groups y garantías Producers/consumers · partition offset · consumer group rebalancing · at-least-once vs exactly-once · retention · compaction · kafka-python / confluent-kafka Linux (Kafka se opera en servidores) + Python (clientes producer/consumer) + Conceptos ETL (streaming vs batch)	Entender Kafka como plataforma de eventos — usado por Meta (300B eventos/día), Airbnb (35B eventos/día) y Uber — para conectar fuentes de datos en tiempo real con los pipelines de procesamiento.	Difícil	Confluent Developer Courses (free) Apache Kafka Docs	Sistema de eventos de e-commerce: producer Python que publica eventos de órden, consumer group con 3 workers procesando en paralelo; demostrar que al matar un worker el rebalanceo ocurre sin pérdida de mensajes.	Python0 mensajes perdidos en rebalanceo verificado con contador de eventos; offset committido correctamente; consumer group lag visible en Kafka UI; producer con idempotencia habilitada.
Streaming	Spark Structured Streaming: micro-batch, watermarks y stateful ops readStream / writeStream · trigger intervals · watermarks para late data · stateful aggregations · checkpointing · output modes: append/complete/update Spark DataFrames + Kafka (fuente del stream) + Iceberg/Delta (sink de streaming)	Unificar el procesamiento batch y streaming con la misma API de Spark para construir pipelines Lambda/Kappa sin duplicar lógica — estándar en Airbnb y Databricks.	Difícil	Spark Structured Streaming Guide Databricks: Lambda vs Kappa	Pipeline Kafka → Spark Structured Streaming → tabla Iceberg: agregar métricas de órdenes por ventana de 5 min con watermark de 10 min para late data; checkpoint para recuperación ante fallo; latencia end-to-end <30s.	PythonLate data manejado correctamente con watermark; checkpoint permite reinicio sin reprocesar desde cero; latencia P95 <30s medida con timestamps en producer y consumer; 0 pérdida de datos en fallo simulado.
Modelado Dimensional	Kimball: fact tables, dimension tables, SCD Tipo 1/2 y star schema Fact tables (aditivas, semi-aditivas) · dimension tables · SCD Type 1/2/3 · surrogate keys · conformed dimensions · grain · bus matrix Modelado relacional (3NF previo) + Data Warehouse (donde vive el modelo) + dbt (implementación)	Diseñar modelos dimensionales que los analistas puedan consultar sin asistencia técnica — la razón por la que el data warehouse existe según Ralph Kimball, padre del modelado dimensional.	Difícil	Kimball: Data Warehouse Toolkit (libro) dbt: How We Structure Our Projects	Star schema para e-commerce en dbt: `fct_orders` con métricas, `dim_customers` con SCD Tipo 2 para capturar cambios de segmento, `dim_products` y `dim_date`; query de cohort analysis en <5s.	PythonSCD Tipo 2 captura cambios históricos verificado con datos de prueba; surrogate keys generadas con `dbt_utils.generate_surrogate_key()`; query de cohort sin JOINs innecesarios; grano documentado en `schema.yml`.
dbt Avanzado	dbt: modelos incrementales, macros Jinja, snapshots y packages `is_incremental()` · unique_key · `dbt snapshot` (SCD Tipo 2) · Jinja macros reutilizables · `dbt-utils` · `elementary-data` para monitoreo · hooks dbt básico (models + tests) + Modelado dimensional (SCD que implementa snapshot)	Escalar dbt para pipelines de producción con cientos de modelos: redefinir sólo los datos nuevos (incremental), reutilizar lógica como macros y monitorear la calidad con elementary.	Difícil	dbt: Incremental Models Elementary Data Monitoring	Modelo incremental de `fct_orders` que procesa sólo órdenes nuevas por `updated_at`; macro Jinja para calcular métricas de conversión reutilizable en 3 modelos; elementary alertando sobre anomalías de datos.	PythonModelo incremental 10x más rápido que full refresh en dataset de 30 días; macro probada con `dbt test`; elementary detecta y alerta cuando volumen de órdenes cae >20% vs media de 7 días.
Orchestración Avanzada	Airflow avanzado: TaskFlow API, dynamic task mapping y Dagster/Prefect `@task` decorator · dynamic task mapping con `.expand()` · deferrable operators · Airflow 2.x best practices · Dagster assets · Prefect flows como alternativa Airflow básico + Spark (nuevas tareas a orquestar) + dbt (orquestación de modelos)	Construir DAGs mantenibles y escalables usando el paradigma moderno de Airflow (TaskFlow API) y evaluar con criterio cuándo Dagster o Prefect son mejores alternativas arquitectónicas.	Difícil	Airflow: TaskFlow API Dagster Docs	DAG con TaskFlow API que usa dynamic mapping para procesar N archivos en S3 en paralelo (número dinámico); mismo pipeline reimplementado en Dagster assets; ADR documentando qué elegir para un equipo de 5 data engineers.	PythonDynamic mapping escala de 1 a 50 archivos sin cambios de código; ADR con pros/cons de Airflow vs Dagster para el contexto específico; 0 XCom con datos grandes (sólo metadatos).
DataOps	CI/CD para datos: testing de pipelines y GitOps con dbt y Airflow pytest para DAGs y transformaciones · dbt en CI (slim CI) · Datafold para data diffs · GitHub Actions · PR checks · deploy automatizado de DAGs Git + Docker + dbt avanzado + Airflow avanzado + Data quality	Automatizar la validación y el despliegue de cambios en pipelines para que ningún código llegue a producción sin haber sido testeado — las mismas prácticas de software engineering aplicadas a datos.	Medio	dbt: Slim CI Datafold: CI/CD for dbt	Pipeline CI/CD: pytest valida sintaxis de DAGs → dbt slim CI ejecuta sólo modelos afectados → data diff detecta cambios de distribución en columnas clave → deploy a staging antes de prod.	PythonPR sin verde no puede hacer merge; dbt slim CI corre <5 min en proyecto de 100 modelos; data diff alerta si distribución de columna clave cambia >5%; deploy a prod sólo tras aprobación manual.
Linaje y Observabilidad	Data lineage con OpenLineage, Marquez y alertas de pipeline OpenLineage spec · Marquez server · integración Airflow + Spark · linaje columna-a-columna · impact analysis · alertas de SLA por DAG · data freshness Airflow (fuente de eventos de linaje) + Spark (jobs que emiten linaje) + dbt (linaje de modelos)	Responder "¿de dónde viene este dato?" en segundos — el pilar de confianza en datos que reduce el tiempo de investigación de incidentes de horas a minutos en equipos como el de Airbnb.	Medio	OpenLineage Docs Marquez Project	Integrar OpenLineage en Airflow y Spark; visualizar en Marquez el linaje completo desde API de GitHub hasta tabla Gold en Snowflake; impact analysis: dado un cambio en Bronze, identificar todos los modelos dbt afectados en <1 min.	Linaje completo visible en Marquez desde fuente hasta consumidores; impact analysis identifica correctamente los modelos descendientes; alerta automática si un dataset Gold lleva >26h sin actualización.

04

Nivel 4

Senior Data Engineer

Arquitecto de plataformas de datos. El Senior diseña contratos de datos, implementa gobernanza con Unity Catalog, introduce streaming a escala con Flink y construye pipelines para ML. Su impacto se mide en la confianza que el negocio tiene en los datos — no en el número de DAGs desplegados.

Área	Tema Específico	Objetivo	Dif.	Recursos	Proyecto / Validación	Criterio de Éxito
Lakehouse a Escala	Unity Catalog y Databricks Lakehouse: gobernanza unificada de datos Unity Catalog: metastore · 3-level namespace · Delta Sharing · row/column-level security · PII tagging · data lineage automático · LakeFlow Declarative Pipelines (DLT) Iceberg/Delta Lake + Spark + Medallion Architecture + Data lineage	Diseñar y operar un lakehouse governado que garantice que los datos correctos llegan a las personas correctas con los permisos correctos — fundamento de cualquier iniciativa de data governance empresarial en 2026.	Experto	Unity Catalog Docs Delta Live Tables Docs	Lakehouse con Unity Catalog: 3 catálogos (dev/staging/prod), PII columns tagged y enmascaradas para roles sin permisos, Delta Sharing para compartir tablas con equipo externo; pipeline DLT con quality constraints que bloquean datos inválidos.	PythonRol sin permisos no ve columnas PII (valores NULL enmascarados automáticamente); Delta Sharing funciona desde un notebook externo sin acceso al lakehouse; DLT rechaza filas con constraint violado y las envía a tabla de quarantine.
Streaming Avanzado	Apache Flink con PyFlink: stateful stream processing a escala DataStream API · Table API · state backends (RocksDB) · exactly-once semantics · Kafka source/sink · windowing avanzado · Flink SQL · savepoints y upgrades sin downtime Kafka (fuente) + Spark Structured Streaming (conceptos análogos) + Iceberg (sink)	Procesar streams de eventos con baja latencia y estado persistente usando Flink —motor que usa Uber para su plataforma de datos en tiempo real con miles de millones de eventos diarios.	Experto	PyFlink Docs Confluent: Apache Flink Course	Pipeline PyFlink de detección de fraude en tiempo real: enriquecer eventos de transacción con estado de usuario (RocksDB), aplicar reglas de detección en ventanas de 1 min, emitir alertas a Kafka; upgrade sin downtime con savepoint.	PythonLatencia P99 <500ms end-to-end; exactly-once garantizado verificado con test de duplicación; upgrade de versión vía savepoint sin perder estado ni mensajes; back-pressure visible en Flink UI.
Data Contracts	Data Contracts: especificación, validación y Schema Registry ODCS (Open Data Contract Standard) · Confluent Schema Registry · Avro/Protobuf schema evolution · backward/forward compatibility · Soda Core para contratos en runtime · breaking change alerts Kafka (Schema Registry) + Data Quality (Great Expectations) + dbt (linaje de contratos) + CI/CD	Formalizar los acuerdos entre productores y consumidores de datos con validación automática — práctica adoptada por Uber, Miro y PayPal para eliminar las roturas silenciosas de schema que degradan la confianza en datos.	Experto	Soda: Data Contracts Confluent Schema Registry Docs	Data contract en YAML para la tabla `fct_orders`: SLA de freshness, columnas garantizadas, tipos, rangos válidos; validación automática en CI antes de merge; Schema Registry con modo BACKWARD_TRANSITIVE para topics Kafka.	PythonPR que viola contrato bloqueado en CI; Soda valida contrato en producción cada hora; Schema Registry rechaza schema incompatible; alert en Slack al consumidor si SLA de freshness se incumple.
Optimización	Spark y query optimization avanzada: Z-ordering, bloom filters y AQE Z-ordering en Iceberg/Delta · bloom filter indexes · AQE (Adaptive Query Execution) · Spark memory tuning · cost-based optimizer · query profiling con Spark UI · partition pruning Spark (fundamentos) + Iceberg/Delta Lake + Data Warehouse avanzado	Reducir el costo y la latencia de queries analíticos en el lakehouse mediante optimizaciones que van más allá del índice básico — la diferencia entre una query de 10 min y 30 seg a escala de petabytes.	Experto	Iceberg Spark Queries Optimization Spark SQL Performance Tuning	Optimizar la query de detección de fraude histórico sobre 2 años de datos: Z-ordering por `user_id` + `event_date`, bloom filter en `merchant_id`; documentar reducción de archivos leídos con Iceberg metadata; query de 8 min a <90s.	PythonIceberg scan stats muestran ≥80% reducción de archivos leídos tras Z-ordering; bloom filter elimina false positives medido con `EXPLAIN`; benchmark antes/después reproducible con Spark History Server.
MLOps / DataOps	Feature stores y pipelines de datos para ML: Feast y MLflow Feature store: offline vs online store · point-in-time correct joins · feature engineering en PySpark · MLflow tracking · dataset versioning · training data pipelines · Metaflow Spark (feature engineering) + Streaming (features en tiempo real) + Iceberg (punto histórico correcto) + dbt (features batch)	Construir pipelines de datos que alimenten modelos de ML con features reproducibles y sin data leakage — la responsabilidad de data engineering en equipos de ML según Netflix (Metaflow) y Uber (Michelangelo).	Experto	Feast Feature Store Docs MLflow Docs	Feature store con Feast: features batch desde Iceberg (user_lifetime_value), features streaming desde Kafka (real-time purchase count); point-in-time correct join verificado; MLflow tracking de experimentos con dataset version.	PythonPoint-in-time join no tiene data leakage verificado con test de holdout; feature online store sirve <10ms P99; MLflow experimento registra dataset hash y schema automáticamente; features versionadas con cambios trazables.
Data Governance	Catálogos de datos: DataHub o Atlan, PII y compliance GDPR/CCPA Metadata management · business glossary · data classification (PII, confidential) · right-to-erasure pipeline · data masking · GDPR Article 17 compliance · access audit logs Unity Catalog (implementación técnica) + Data Contracts (SLAs que documenta el catálogo) + Data Lineage	Implementar gobernanza de datos técnicamente ejecutable que permita cumplir GDPR y CCPA con pipelines automatizados, no con procesos manuales que escalan mal.	Difícil	DataHub Docs GDPR Article 17 (Right to Erasure)	Catálogo DataHub con linaje completo y clasificación PII; pipeline de right-to-erasure en Python: dada una solicitud de usuario, identificar todas las tablas con sus datos y ejecutar borrado en <30 días; audit log de todos los accesos a datos PII.	PythonRight-to-erasure verificado en todas las capas (Bronze, Silver, Gold, feature store); audit log inmutable en S3 con todos los accesos PII; tiempo de borrado documentado para cumplimiento GDPR; sin datos PII en logs de sistema.
FinOps de Datos	Cost optimization: Snowflake credits, Spark cluster sizing y S3 costs Warehouse auto-suspend · clustering vs search optimization service · Spark rightsizing · spot instances · S3 intelligent tiering · query cost attribution · cost per query Snowflake + Spark optimización + S3 (lifecycle policies vistas en Trainee)	Reducir el gasto en infraestructura de datos en ≥30% sin degradar SLAs — competencia que U.S. companies están premiando con bonos según el Data Engineering Roadmap 2026 report.	Difícil	Snowflake Cost Understanding S3 Storage Classes	Auditoría de costos en un data stack real: identificar top-5 queries más costosas en Snowflake, aplicar clustering y auto-suspend; migrar datos cold de S3 Standard a S3 Glacier; documentar ahorro mensual con dashboard de costo por equipo.	PythonScript Python consulta Snowflake QUERY_HISTORY y calcula costo por query/equipo; reducción ≥25% en factura mensual documentada; dashboard de costo actualizado automáticamente; ningún warehouse activo en horario no laboral.
System Design	Data system design: diseñar plataformas end-to-end para casos reales Diseño de sistema de analytics para 100M usuarios · batch vs real-time trade-offs · single-source-of-truth · idempotencia · SLA definition · capacity planning · backfill strategy Todo el nivel SSR + Senior — punto de síntesis arquitectónica	Diseñar plataformas de datos completas articulando los trade-offs técnicos con claridad ejecutiva — habilidad central que separa al Senior Engineer del SSR en todas las entrevistas de empresas top.	Experto	Designing Data-Intensive Applications (Kleppmann) Fundamentals of Data Engineering (Reis & Housley)	Diseñar el sistema de analytics de un marketplace como MercadoLibre: ingesta de 100M eventos/día, latencia de dashboard <2s, backfill de 3 años de histórico, cost target de $10k/mes; ADR con arquitectura elegida y alternativas.	Diagrama de arquitectura con todos los componentes y flujos de datos; ADR con 2 alternativas descartadas con justificación; estimación de costo desglosada por componente; backfill strategy sin impactar pipelines de producción.

05

Nivel 5

Staff / Principal Data Engineer

Influencia multiplicadora y estrategia de plataforma. El Staff Engineer no mide su impacto en pipelines desplegados sino en la velocidad a la que los equipos de producto pueden confiar en sus datos: Data Mesh como organización, IA nativa sobre el lakehouse y estrategia multi-cloud como ventaja competitiva.

Área	Tema Específico	Objetivo	Dif.	Recursos	Proyecto / Validación	Criterio de Éxito
Data Mesh	Data Mesh: dominios, data products y plataforma self-serve Domain ownership · data product thinking · self-serve data platform · federated governance · interoperabilidad · Data Product Spec (port/schema/SLA) · casos de Uber, Netflix y Zalando Data Contracts + Data Governance + CI/CD para datos + Unity Catalog (implementación técnica del mesh)	Escalar la organización de datos más allá de un único equipo centralizado implementando Data Mesh — el modelo adoptado por Uber (Databook), Netflix y Zalando para escalar a cientos de equipos productores de datos.	Experto	Data Mesh Architecture (guía práctica) Martin Fowler: Data Mesh Principles	Diseñar la transición de un data warehouse centralizado a Data Mesh para una empresa de 200 personas: identificar dominios, definir el Data Product Spec estándar, construir el self-serve platform que permite a un equipo publicar su primer data product en <1 día.	Data Product Spec con schema, SLAs, ownership y quality score definido; nuevo equipo publica data product sin intervención del platform team; gobernanza federada: cada dominio aplica políticas pero con estándares comunes.
Real-Time Analytics	ClickHouse y Apache Druid: OLAP en tiempo real a escala de eventos Columnar storage OLAP · ingesta desde Kafka en tiempo real · materialized views · particionado temporal · queries en <1s sobre billones de filas · Druid vs ClickHouse vs Pinot Kafka avanzado (fuente de eventos) + Flink (pre-procesamiento) + Streaming Avanzado + System Design	Habilitar dashboards en tiempo real con latencia de segundos sobre datos de billones de eventos — lo que usa Airbnb con Druid para analytics de búsqueda en tiempo real y Meta con Pinot para feed analytics.	Experto	ClickHouse Docs Apache Druid Docs	Pipeline Kafka → Flink (pre-agregación) → ClickHouse para dashboard de métricas de e-commerce en tiempo real; query de sesiones activas por país en <500ms sobre 1B filas; comparativa de costo vs Snowflake para el mismo caso de uso.	PythonQuery P99 <500ms con 1B filas en ClickHouse; ingesta desde Kafka con lag <5s; análisis de costo documentado: ClickHouse vs Snowflake para queries interactivas de alta frecuencia; script Python de benchmarking reproducible.
IA sobre Datos	AI/LLM data infrastructure: pipelines para entrenamiento y RAG a escala Pipelines de curación de training data · deduplication a escala con Spark · vector embeddings en PySpark · pgvector / Qdrant · chunking strategies · data flywheel · calidad de datos para LLMs Spark optimización + Iceberg lakehouse + Feature stores + Streaming (datos para fine-tuning continuo)	Diseñar la infraestructura de datos que alimenta sistemas de IA en producción — la nueva frontera del data engineering en 2026 donde los equipos de datos son ciudadanos de primera clase en proyectos de IA.	Experto	Qdrant Docs Splink (deduplication a escala)	Pipeline completo de datos para RAG: ingesta de documentos → chunking semántico → embedding con sentence-transformers en PySpark → vector store en Qdrant; deduplication de corpus con Splink; pipeline de actualización incremental ante nuevos documentos.	PythonDeduplication procesa 10M documentos en <2h con Spark; embeddings generados con batching eficiente (GPU si disponible); vector search P95 <100ms; pipeline incremental actualiza Qdrant sin full reindex.
Platform Engineering	Data Platform Engineering: IDP para datos y self-service pipelines Internal Developer Platform para datos · Backstage para catálogo · templates de DAG/dbt · self-service provisioning · developer experience (DX) de datos · NPS de la plataforma Data Mesh (organización) + CI/CD para datos + DataHub/Atlan (catálogo) + Unity Catalog	Construir la plataforma de datos interna que permite a cualquier equipo de producto crear pipelines, publicar data products y confiar en sus datos sin depender del equipo de data engineering para cada tarea.	Experto	Backstage Docs platformengineering.org	Template en Backstage que provisiona: repo de DAGs con CI/CD, catálogo DataHub automático, schema registry configurado, alertas de data quality y data product spec en YAML; nuevo equipo con pipeline en producción en <1 día desde el template.	Tiempo de creación de nuevo data product de días a <1 día; adopción >70% de equipos sin soporte del platform team; developer NPS de la plataforma >30; 0 pipelines sin tests de calidad (enforced por CI).
Multi-Cloud	Estrategia multi-cloud: interoperabilidad, federation y open formats Open table formats como capa de portabilidad · Iceberg REST catalog cross-cloud · Delta Sharing · query federation (Trino/Starburst) · avoid vendor lock-in · data gravity Iceberg/Delta Lake + Unity Catalog + FinOps + System Design	Diseñar arquitecturas de datos que no estén atadas a un único cloud vendor, habilitando consultas federadas entre AWS y GCP sin mover datos — estrategia que siguen Netflix, Airbnb y las empresas de FAANG para evitar lock-in.	Experto	Trino Docs (query federation) Databricks: Delta Sharing	Arquitectura de lakehouse federation: tablas Iceberg en AWS S3 + tablas Delta en GCS, accesibles con Trino sin replicar datos; Delta Sharing para dataset compartido con empresa partner; análisis de costo de egress cross-cloud y mitigación.	PythonQuery Trino cruza AWS y GCP en <10s sobre dataset de prueba; Delta Sharing funciona desde partner sin acceder al storage directamente; análisis de costo de egress documenta la estrategia de co-location de tablas frequently-joined.
Data Engineering Metrics	DORA para datos: pipeline reliability, data SLAs y data quality score Pipeline success rate · data freshness SLA · quality score por dataset · incident MTTR · root cause time · toil elimination · cost per reliable row · stakeholder reporting DataOps CI/CD + Data Contracts (SLAs) + Observabilidad + FinOps	Medir y comunicar la fiabilidad de la plataforma de datos como un producto con SLAs formales — la diferencia entre un equipo de datos que reacciona a quejas y uno que previene degradaciones antes de que impacten al negocio.	Experto	DORA Research Program Monte Carlo: Data Reliability Engineering	Dashboard de data reliability: pipeline success rate por dominio, data freshness SLA compliance por tabla Gold, quality score por data product; reporte mensual automatizado a dirección con trending; toil reducido en >40% en 90 días.	PythonScript Python ingesta métricas de Airflow + dbt + Great Expectations en un único dashboard; SLA compliance >99% documentado; incident MTTR reducido de >4h a <45min; reporte ejecutivo mensual generado automáticamente.
Estrategia Técnica	Estrategia de datos a 18 meses: roadmap, OKRs y gestión de deuda técnica Data strategy document · build vs buy · technical debt ledger para datos · OKR alignment · capacity planning · RFC process · stakeholder alignment · data literacy Data Mesh + DORA Metrics + Platform Engineering + toda la experiencia acumulada	Traducir la estrategia de negocio en inversiones técnicas de datos con impacto medible — la diferencia entre un Staff que ejecuta tareas y uno que define la dirección técnica del equipo.	Experto	The Staff Engineer's Path — T. Reilly Will Larson: Staff Engineer Resources	Documento de estrategia de datos de 18 meses con 3 iniciativas (Data Mesh migration, real-time analytics, AI data infrastructure), OKRs por iniciativa, análisis de deuda técnica con costo estimado y roadmap de amortización aprobado por CTO.	Aprobado en revisión con VPs; cada iniciativa con impacto en métricas de negocio documentado; deuda técnica cuantificada en "engineering days"; tracking trimestral con datos objetivos publicados al equipo.
Community & Open Source	Open source contributions, thought leadership y evangelización Contribuciones a Apache Iceberg / Airflow / dbt / Flink · blog técnico en engineering blog · Data Engineering Summit / Big Data Spain · mentoring · RFC públicas en proyectos CNCF Todo el nivel Staff — impacto acumulado que se amplifica externamente	Amplificar el impacto más allá de la organización construyendo reputación en la comunidad de data engineering que atrae talento, retroalimenta con inteligencia del ecosistema y eleva el nivel de la industria.	Experto	Apache Iceberg Community Data Engineering Summit CFP	Contribución aceptada a Apache Iceberg, Airflow o dbt-core; charla en Data Engineering Summit, Current (Confluent) o conferencia regional; post técnico con >1000 lecturas; 2 data engineers junior mentoreados a nivel SSR en <12 meses.	PythonPR mergeada en proyecto con >1k stars; charla aceptada por CFP con revisión ciega; mentorado alcanza nivel SSR en <12 meses; post técnico compartido en comunidades de data engineering con >1000 lecturas orgánicas.

Data Engineering Career Path

Trainee

Junior Data Engineer

Semi-Senior (SSR)

Senior Data Engineer

Staff / Principal Data Engineer

Data
Engineering Career Path