Cómo convertirse en Data Engineer

Qué hace un Data Engineer, y qué no

Un Data Engineer construye y sostiene los caminos por donde viaja el dato: lo saca de donde nace, lo deja en un formato que se pueda consultar, y se asegura de que eso vuelva a pasar mañana sin que nadie lo empuje a mano.

Lo que no hace, aunque los avisos de empleo lo mezclen todo:

• No entrena modelos. Eso es el Data Scientist o el ML Engineer. Vos le dejás los datos listos.
• No arma el tablero. Eso es el analista. Vos hacés que la tabla que consulta el tablero exista, esté actualizada y no mienta.
• No administra el servidor. Eso es infraestructura o plataforma, aunque en equipos chicos te toque igual.

La diferencia práctica: al analista le preguntan qué dicen los datos; al Data Engineer le preguntan por qué el número de ayer cambió y por qué el proceso de las 3 a.m. no corrió. Si esa segunda pregunta te da curiosidad en vez de fastidio, es tu rol.

Lo que no necesitas para empezar

Esta lista existe porque cada punto frena a alguien todos los días:

• Un máster. El portafolio pesa más que el título en casi todos los procesos de selección de este rol.
• Saber Spark el primer mes. El procesamiento distribuido resuelve un problema que todavía no tenés. Cuando lo tengas, se aprende.
• La nube antes que los fundamentos. Los servicios administrados cambian de nombre cada dos años; SQL y el modelado de datos, no.
• Veinte herramientas. Nadie las usa todas. Un equipo real usa cuatro o cinco, y cambian de empresa a empresa. Lo que se transfiere es el criterio, no la marca.

Tampoco hay un número honesto de meses. Depende de cuántas horas reales por semana le pongas y de cuánto código escribas — no de cuántos cursos abras.

Cómo está armada esta ruta

Tres niveles. Cada uno tiene qué aprender, un proyecto que lo cierra y cómo saber que ya lo tenés: un criterio que se puede comprobar, no una sensación.

Si querés el mapa de habilidades del rol en vez de la secuencia, está en las 5 habilidades de un Data Engineer, con autoevaluación. Esta guía es el orden; esa página es el mapa.

Nivel 1 — Responder una pregunta con datos que no armaste vos

Es el piso. Sin esto, todo lo demás es cargo cult.

Qué aprender

• SQL, en serio. No SELECT *: joins, agregaciones, funciones de ventana, y sobre todo modelado — por qué una tabla está partida en tres y cuándo eso te ayuda o te estorba.
• Una base de datos de verdad. PostgreSQL es el estándar honesto para aprender. DuckDB te deja practicar analítica sin instalar un servidor.
• Python suficiente. Leer un archivo, llamar una API, transformar y escribir. No hace falta programación orientada a objetos avanzada.
• Línea de comandos y Git. Si tu código no está versionado, no es código: es un borrador.

Proyecto que lo cierra

Tomá un dataset público que te importe de verdad — presupuesto municipal, precios, clima, transporte — cargalo a Postgres con un script propio, y respondé cinco preguntas que no se contesten con una sola tabla. Escribí las cinco consultas en un repo, con un README que explique de dónde salieron los datos y qué limpiaste.

Cómo saber que ya lo tenés

Podés mirar un esquema desconocido de ocho tablas y, en media hora, decir cuál es la tabla de hechos, cuáles las de referencia y qué join te va a duplicar filas.

Nivel 2 — Que el dato llegue solo

Acá empieza el oficio. La diferencia entre un script que corriste una vez y un proceso en el que alguien confía.

Qué aprender

• Transformación versionada con dbt. Es el punto de entrada más rentable del nivel: convierte SQL suelto en un proyecto con dependencias, pruebas y documentación.
• Ingesta. Airbyte para conectores que no vale la pena escribir; Python propio cuando la fuente es rara.
• Orquestación. Airflow es lo que más vas a encontrar publicado; Dagster modela los datos que producís en vez de solo las tareas, y suele entenderse más rápido. Aprendé uno bien antes de mirar el otro.
• Formatos y almacenamiento. Por qué Parquet y no CSV, y qué cambia cuando el archivo vive en almacenamiento de objetos como MinIO.
• Docker. No para producción todavía: para que tu proyecto corra igual en la máquina de otra persona.

Proyecto que lo cierra

Un pipeline diario que se despierta solo: baja datos de una API pública, los guarda en Parquet, los transforma con dbt con al menos tres pruebas de calidad, y falla ruidosamente cuando la fuente cambia. Todo orquestado y todo en Docker.

Cómo saber que ya lo tenés

Rompés la fuente a propósito — cambiás un nombre de columna — y tu pipeline se detiene con un error que dice qué pasó, en vez de escribir datos malos sin avisar.

Nivel 3 — Que aguante y que se pueda confiar

Esto ya no se estudia en abstracto: se aprende cuando el volumen o el equipo lo piden. Metelo cuando tengas el problema, no antes.

Qué aprender

• Escala. Spark cuando los datos no entran en una máquina; Kafka cuando el dato tiene que llegar en el momento y no mañana.
• Lakehouse. Iceberg o Delta Lake sobre almacenamiento de objetos, consultados con Trino. Es la arquitectura que más aparece hoy en ofertas serias.
• Calidad como código. Great Expectations: las expectativas sobre los datos se declaran y se prueban, igual que el código.
• Gobierno y catálogo. OpenMetadata para que alguien que no sos vos pueda averiguar de dónde salió una tabla sin preguntarte.

Proyecto que lo cierra

Un lakehouse mínimo: datos en Parquet sobre MinIO, tabla Iceberg encima, consultas con Trino, y linaje visible en el catálogo. No tiene que ser grande — tiene que estar completo de punta a punta.

Cómo saber que ya lo tenés

Podés explicarle a alguien, sin diagramas, por qué elegiste tabla de formato abierto en vez de un almacén tradicional, y en qué caso esa decisión habría estado mal.

El portafolio: qué convence y qué no

Lo que no convence: veinte repos con el mismo tutorial terminado, notebooks sin README, certificados de cursos.

Lo que sí:

• Dos proyectos, terminados. Uno del nivel 2 y uno del nivel 3 valen más que diez a medias.
• Un README que explique decisiones. Por qué esa herramienta, qué descartaste, qué rompiste y cómo lo arreglaste. Es lo único que demuestra criterio, y el criterio es lo que se contrata.
• Datos de los que puedas hablar. Un dataset de tu ciudad o de tu industria anterior te da una entrevista mejor que uno genérico.
• Que corra. docker compose up y funciona. Si tenés que explicar cómo instalarlo, nadie lo va a probar.

La búsqueda: cómo leer una oferta

El título del aviso miente seguido. Leé la lista de tecnologías:

• Si pide SQL, un orquestador y un almacén → es Data Engineer de verdad.
• Si pide Power BI o Tableau primero → es analista con otro nombre.
• Si pide Kubernetes, Terraform y guardias → es plataforma o DevOps de datos.
• Si pide las once herramientas → o no saben qué necesitan, o sos el único del área. Preguntá en la entrevista cuántas personas hay en el equipo de datos. La respuesta te dice más que el aviso completo.

Lo que suelen preguntar en la entrevista técnica: SQL con funciones de ventana, modelado (diseñá el esquema para este caso), y una pregunta de diseño abierta — cómo cargarías esto todos los días. Esa última no busca una herramienta: busca que menciones qué pasa cuando falla, cuándo reprocesás y cómo te enterás.

Recursos externos

Curados, gratuitos salvo donde se indica, y con la fuente a la vista:

• Data Engineering Zoomcamp (DataTalksClub) — curso libre y completo, con proyecto final. El punto de partida más sólido si querés estructura.
• Data Engineering Wiki — recursos mantenidos por la comunidad, ordenados por tema.
• The Data Engineering Cookbook (Andreas Kretz) — mapa de conceptos y preguntas de entrevista.
• SQLBolt y Select Star SQL — SQL desde cero, en el navegador.
• Documentación de dbt — fuente oficial; el tutorial de la propia herramienta es mejor que la mayoría de los cursos sobre ella.
• Start Data Engineering — artículos sobre decisiones de diseño, no sobre sintaxis.
• Designing Data-Intensive Applications (Martin Kleppmann, de pago) — el libro que separa a quien usa las herramientas de quien entiende por qué existen. No es para el nivel 1.

Cada herramienta nombrada en esta guía tiene su ficha en el kiosko: qué es, para qué sirve, cuándo no usarla y el enlace a su documentación oficial.