Por dónde empezar en ingeniería de datos (sin ahogarte en herramientas)

Buscas "ingeniería de datos" y te cae encima un diagrama con doscientos logos. Spark, Airflow, Kafka, dbt, Snowflake, Databricks, Iceberg, Flink. La reacción natural es sentir que llegaste tarde a algo.

No llegaste tarde. Ese diagrama es un catálogo de proveedores, no un plan de estudios. Las herramientas cambian cada tres años; lo que hay debajo lleva décadas igual.

Uno: SQL, hasta que te aburra

No SQL "básico". SQL a un nivel donde puedas leer una consulta de sesenta líneas ajena y entender qué hace.

Concretamente: JOINs y por qué no son diagramas de Venn, funciones de ventana, CTEs, agregaciones con GROUP BY y HAVING, y saber leer un plan de ejecución.

Las funciones de ventana en particular son el punto donde mucha gente se detiene, y son justo las que separan a quien puede resolver un problema real:

-- Venta de cada mes contra el mes anterior, sin auto-JOIN.
SELECT
  mes,
  venta,
  LAG(venta) OVER (ORDER BY mes)                      AS venta_mes_previo,
  venta - LAG(venta) OVER (ORDER BY mes)              AS diferencia
FROM ventas_por_mes
ORDER BY mes;

Si esto todavía no te sale de memoria, aquí es donde conviene invertir el tiempo. Ninguna herramienta te va a salvar de no dominar SQL, porque todas terminan generando SQL.

Dos: Python, pero solo la parte que se usa

No necesitas ser desarrollador de software. Necesitas: leer y escribir archivos, consumir una API, manipular datos con pandas o polars, manejar errores y escribir una función que otro pueda leer.

import requests

def traer_pagina(url: str, pagina: int) -> list[dict]:
    respuesta = requests.get(url, params={"page": pagina}, timeout=30)
    respuesta.raise_for_status()   # falla fuerte y temprano, no en silencio
    return respuesta.json()["datos"]

Ese raise_for_status() vale más que muchos tutoriales de arquitectura. Un pipeline que falla ruidosamente es infinitamente mejor que uno que carga datos incompletos sin decir nada.

Tres: modelado

Aquí es donde se decide si tu almacén sirve o estorba, y donde casi nadie empieza porque no tiene logo bonito.

Aprende el modelo estrella, la diferencia entre hechos y dimensiones, y qué hacer cuando los atributos cambian con el tiempo (dimensiones de cambio lento).

Cuatro: una nube, una sola

Escoge una —AWS, GCP o Azure— y aprende su almacenamiento de objetos, su almacén analítico y cómo correr algo en un horario. Ignora las otras dos por ahora. Los conceptos se transfieren; los nombres de los servicios no importan.

Cinco: orquestación

Cuando ya tengas tres o cuatro procesos que dependen entre sí, vas a necesitar algo que los coordine, reintente lo que falle y te avise. Ahí entra Airflow, Dagster o Prefect.

Antes de eso no. Instalar Airflow para correr un script diario es como comprar una grúa para cambiar un foco.

Lo que no necesitas todavía

Kafka y el procesamiento en tiempo real, Spark, Kubernetes, y la mitad de los logos del diagrama. Todos resuelven problemas de escala que aún no tienes. Van a seguir ahí el día que los necesites.

El proyecto que sí sirve para el portafolio

Uno solo, terminado y honesto:

1. Toma datos de una API pública que te interese de verdad.
2. Guárdalos crudos en algún lado, sin transformar.
3. Modélalos en estrella con al menos dos dimensiones.
4. Que corra solo cada día y que sea idempotente — córrelo dos veces y comprueba que no se duplique.
5. Escribe un README explicando por qué tomaste cada decisión.

Ese último punto es el que separa un repositorio de un portafolio. Cualquiera copia un pipeline; explicar por qué elegiste ese grano y ese modelo es lo que demuestra que entiendes.