Guía de Data Engineering: De Excel a Pipelines Profesionales

TL;DR

Data Engineering = construir la infraestructura para que los datos fluyan
No es Data Science (ellos analizan, nosotros construimos las tuberías)
El 80% del trabajo es limpiar datos, no hacer cosas glamurosas
Stack básico: SQL + Python + algún orquestador (Airflow, Prefect)
Si vienes de Excel/Power BI, ya tienes más base de la que crees

Qué es Data Engineering (de verdad)

Un Data Engineer construye y mantiene la infraestructura que permite que los datos vayan del punto A al punto B de forma fiable.

Punto A: Bases de datos, APIs, archivos, sensores, logs, lo que sea. Punto B: Data warehouses, dashboards, modelos de ML, aplicaciones.

Tu trabajo es que ese flujo funcione. Siempre. Sin errores. A escala.

Lo que NO es

No es Data Science: Ellos construyen modelos predictivos. Tú construyes el pipeline que alimenta esos modelos.
No es Data Analysis: Ellos extraen insights de los datos. Tú te aseguras de que tengan datos limpios para analizar.
No es DBA: Ellos optimizan bases de datos. Tú mueves datos entre sistemas.

Hay solapamiento, especialmente en empresas pequeñas. Pero la especialización es real.

El día a día real

Si crees que un Data Engineer pasa el día diseñando arquitecturas elegantes… no exactamente.

Lo que hago el 80% del tiempo

1. Limpiar datos

Fechas en 15 formatos diferentes
Campos que deberían ser numéricos pero tienen “N/A”, ”-”, ” ”
Duplicados que no sabes si son duplicados o registros diferentes
Encoding roto (adiós ñ, hola Ã±)

2. Debuggear pipelines

“El dashboard de ayer está vacío” → el SFTP del proveedor cambió de IP
“Los números no cuadran” → alguien cambió una columna en el ERP
“El proceso tardó 6 horas” → una query sin índice

3. Convencer a la gente

“Pero mi Excel funciona bien” → hasta que no funciona
“¿Por qué no podemos usar Google Sheets?” → porque 500MB de datos
“Esto es urgente” → todo es urgente

4. Documentar (o lamentar no haberlo hecho)

“¿Qué hace este script de 2019?” → nadie sabe, el autor se fue

Lo que hago el 20% del tiempo

Diseñar nuevos pipelines
Evaluar herramientas
Optimizar procesos existentes
Aprender cosas nuevas

Ese 20% es lo divertido. Pero el 80% es lo que paga las facturas.

El stack moderno (2026)

Nivel 1: Lo mínimo que necesitas

Herramienta	Para qué
SQL	Consultar y transformar datos en bases de datos
Python	Scripts, automatización, APIs
Git	Control de versiones (sí, también para datos)
Terminal/Bash	Automatización básica

Con esto puedes hacer el 70% del trabajo. En serio.

Nivel 2: El stack típico de empresa

Categoría	Opciones populares
Orquestación	Airflow, Prefect, Dagster
Transformación	dbt, Spark, pandas
Almacenamiento	Snowflake, BigQuery, Databricks, Redshift
Ingesta	Fivetran, Airbyte, Singer
Calidad	Great Expectations, dbt tests, Soda

Nivel 3: Lo que las empresas grandes añaden

Data Catalog: Datahub, Amundsen, Atlan
Gobernanza: Collibra, Alation
Monitoreo: Monte Carlo, Bigeye
Streaming: Kafka, Kinesis, Flink

Mi recomendación para empezar

SQL sólido (no básico, sólido)
Python con pandas y requests
Un orquestador (Prefect es más fácil que Airflow)
dbt para transformaciones
Un warehouse (BigQuery tiene free tier generoso)

Con eso puedes trabajar en el 90% de las empresas.

ETL vs ELT: El cambio de paradigma

ETL (Extract, Transform, Load) - El enfoque clásico

Fuente → [Transformar] → Data Warehouse

Transformas los datos ANTES de cargarlos. Requiere saber qué necesitas de antemano.

Ventajas: Menos datos en el warehouse, más control. Desventajas: Menos flexible, pipelines más complejos.

ELT (Extract, Load, Transform) - El enfoque moderno

Fuente → Data Warehouse → [Transformar]

Cargas todo y transformas DENTRO del warehouse usando SQL.

Ventajas: Más flexible, herramientas como dbt lo hacen fácil. Desventajas: Más datos almacenados, costes de storage.

La realidad

La mayoría de proyectos modernos usan ELT porque:

El storage es barato
Los warehouses modernos son muy rápidos
dbt hace las transformaciones elegantes
Puedes iterar sin rehacer pipelines

Pero ETL sigue teniendo sentido para:

Datos sensibles que no deben llegar crudos
Volúmenes muy grandes donde el transform reduce mucho
Sistemas legacy que no soportan el enfoque moderno

Data Quality: El 80% del trabajo

El dato más bonito no sirve si está mal.

Los problemas típicos

Problema	Ejemplo
Completitud	30% de emails vacíos
Unicidad	Duplicados de clientes
Consistencia	”España”, “ES”, “esp”, “ESPAÑA”
Validez	Fechas futuras en “fecha de nacimiento”
Precisión	Redondeos incorrectos
Actualidad	Datos de hace 3 meses como “actuales”

Cómo lo atacamos

1. Validación en la ingesta

# Ejemplo simple con Great Expectations
expect_column_values_to_not_be_null("email")
expect_column_values_to_match_regex("email", r".*@.*\..*")

2. Tests en las transformaciones

-- dbt test
SELECT * FROM customers
WHERE created_at > CURRENT_DATE  -- No debería haber registros

3. Monitoreo continuo

Alertas cuando métricas se desvían
Dashboards de calidad de datos
Anomaly detection automático

4. Ownership claro

¿Quién es responsable de cada dataset?
¿Quién aprueba cambios en definiciones?
¿Quién responde cuando algo falla?

Si vienes de Excel/Power BI

Buenas noticias: ya tienes más base de la que crees.

Lo que ya sabes (aunque no lo llames así)

En Excel/Power BI	En Data Engineering
BUSCARV, INDEX/MATCH	JOINs
Tablas dinámicas	GROUP BY, agregaciones
Power Query	ETL/ELT
Relaciones entre tablas	Modelado dimensional
Macros/VBA	Scripts de Python
Conexiones de datos	Data ingestion

El camino de transición

Paso 1: SQL profundo

No solo SELECT, sino window functions, CTEs, subqueries
Optimización de queries
Diferentes dialectos (SQL Server, PostgreSQL, BigQuery)

Paso 2: Python básico

pandas para manipulación de datos
requests para APIs
Automatización de tareas repetitivas

Paso 3: Un proyecto real

Automatiza algo que haces manualmente
Mueve datos de A a B con un script
Programa una ejecución diaria

Paso 4: El ecosistema

Git para versionar tu código
Un orquestador para programar jobs
Un warehouse para almacenar resultados

Power Query es literalmente una herramienta de ETL. Si lo dominas, ya entiendes los conceptos. Solo te falta traducirlos a herramientas de “adultos”.

El futuro: Data Engineering + IA

2026 está cambiando el rol:

Lo que la IA ya hace bien

Generar queries SQL básicas
Escribir transformaciones simples
Documentar código existente
Detectar anomalías en datos

Lo que sigue siendo humano

Entender el negocio
Diseñar arquitecturas que escalen
Debugging de problemas complejos
Decidir qué datos importan

Mi predicción

El Data Engineer junior que solo sabe ejecutar queries tiene los días contados. El que entiende el negocio, diseña sistemas, y usa IA como herramienta… ese tiene futuro.

Cómo empezar (plan de 3 meses)

Mes 1: Fundamentos

SQL avanzado (window functions, CTEs)
Python básico (pandas, archivos, APIs)
Git básico

Mes 2: Herramientas

Un orquestador (Prefect o Airflow)
dbt para transformaciones
Un warehouse (BigQuery free tier)

Mes 3: Proyecto real

Elige un problema real (tus datos, datos públicos)
Pipeline completo: ingesta → transformación → output
Documentación y tests básicos

Al final de 3 meses tendrás algo que mostrar en entrevistas.

Recursos recomendados

Para empezar

Mode SQL Tutorial - SQL gratis y bien explicado
Dataquest - Python para datos
The Data Engineering Handbook - Recurso comunitario

Para profundizar

“Fundamentals of Data Engineering” (Reis & Housley) - El libro de referencia
dbt Learn - Cursos oficiales gratuitos
Data Engineering Zoomcamp - Bootcamp gratuito

Comunidades

Data Engineering Discord
r/dataengineering en Reddit
Locally Optimistic (Slack)

Conclusión

Data Engineering es construir la infraestructura que hace que los datos fluyan. El 80% es limpiar datos y debuggear pipelines. El 20% es diseñar cosas elegantes.

Si vienes de Excel/Power BI, ya tienes la mentalidad. Te falta aprender las herramientas profesionales: SQL sólido, Python, un orquestador, dbt.

El campo está creciendo, los salarios son buenos, y la IA no va a reemplazarte si entiendes el negocio además de la tecnología.

Empieza con SQL. De verdad. Todo lo demás viene después.

¿Quieres entender arquitecturas más avanzadas? Lee sobre Data Fabric.

¿Por qué el 80% del trabajo es limpiar? Porque el 90% de tus datos son basura.

¿Ya usas Power BI? Lee qué es Power Query para ver cómo conecta con Data Engineering.