Si ves un roadmap para ser Analytics Engineer que dice:
Python → SQL → Power BI → Spark → Kafka → AWS → Machine Learning
hay un problema.
Estás intentando aprender tres profesiones a la vez.
Un Analytics Engineer no necesita saber todo sobre Data.
Necesita dominar una parte muy específica de la cadena:
convertir datos crudos en datos confiables, entendibles y listos para que el negocio tome decisiones.
Y en 2026 eso incluye algo nuevo:
Preparar esos datos no solo para humanos.
También para agentes de IA que necesitan entender qué significan rentabilidad, abandono, clientes activos o margen bruto sin inventárselo.
Snowflake, Databricks y dbt están llevando las métricas y la semántica a objetos gobernados precisamente por esta razón.
Entonces, ¿qué deberías aprender?
1. SQL. Mucho SQL.
No:
SELECT *
FROM sales;
SQL de verdad:
- CTEs.
- Window functions.
- Joins.
- Aggregations.
- Subqueries.
- Deduplicación.
- Incremental logic.
- Optimización de queries.
- Manejo de fechas.
- Granularidad.
Pero hay algo todavía más importante.
Aprender a pensar en datos.
2. Aprende Data Modeling
Esta es la diferencia más importante entre alguien que sabe SQL y un buen Analytics Engineer.
Debes entender:
- Facts.
- Dimensions.
- Star Schema.
- Slowly Changing Dimensions.
- Surrogate Keys.
- Grain.
- Kimball.
- OBT.
- Normalización vs. desnormalización.
Porque tu trabajo no se limita a consultar datos.
Es diseñarlos para que otras personas puedan consultarlos correctamente.
Por ejemplo:
raw.orders
↓
stg_orders
↓
int_orders_enriched
↓
fct_orders
↓
dim_customers
↓
marts_sales
Ahora tienes una capa de datos diseñada para que la empresa tome decisiones basadas en datos de manera confiable.
3. Aprende dbt como ingeniería, no como herramienta
Aquí ocurre la transición hacia Analytics Engineering.
dbt te permite llevar prácticas de Ingeniería de Software al trabajo analítico:
SQL + Git + Testing + Documentation + CI/CD + Lineage
No te quedes solo con:
dbt run
Aprende:
- Models.
- Sources.
ref().- Tests.
- Documentation.
- Macros.
- Incremental models.
- Snapshots.
- Materializations.
- Model contracts.
Las pruebas de datos de dbt permiten convertir supuestos sobre tus datos en validaciones ejecutables, mientras que contratos, accesos y versiones permiten tratar modelos importantes como productos estables entre equipos.
Ahí está la diferencia.
Un Analytics Engineer construye un producto de datos que debe seguir funcionando mañana.
4. Escoge UN Data Warehouse
No necesitas aprender Snowflake + BigQuery + Redshift + Databricks simultáneamente.
Escoge uno.
Por ejemplo:
Snowflake o BigQuery o Databricks
Aprende:
- Warehouses / compute.
- Schemas.
- Roles y permisos.
- Partitioning / clustering.
- Query performance.
- Costos.
- Cómo cargar datos.
- Cómo funciona ELT.
Después cambiar de plataforma, resulta más fácil.
Los conceptos importan más que memorizar dónde está cada botón.
5. Aprende Git + CI/CD
Aquí muchos roadmaps están mal.
Te enseñan otra herramienta de visualización cuando deberían enseñarte:
branch
→ change
→ test
→ pull request
→ review
→ deploy
Tus transformaciones de datos son código.
Trátalas como tal.
Debes sentirte cómodo con:
- Git.
- Branches.
- Pull Requests.
- Code Reviews.
- Dev / Staging / Production.
- CI pipelines.
Si cambiar una métrica de revenue puede afectar 15 dashboards, deja de ser una buena idea hacer cambios en producción.
6. Aprende sobre capas semánticas
Este sería mi gran cambio para el Roadmap 2026-2027.
Antes podías terminar aquí:
Warehouse
↓
dbt
↓
Power BI / Tableau / Looker
Ahora necesitas entender también:
Warehouse
↓
Data Models
↓
Semantic Layer
↓
Metrics
↓
BI + AI Agents
Una capa semántica te permite definir conceptos como:
Rentabilidad, Clientes Activos, MRR, Abandono, Margen Bruto
una sola vez.
Y reutilizarlos en diferentes herramientas.
No es casualidad que dbt esté evolucionando su capa semántica, que Snowflake tenga Semantic Views y que Databricks haya incorporado Metric Views en Unity Catalog.
La razón es importante:
Con IA generando SQL, la definición correcta del negocio se vuelve todavía más importante.
El problema ya no es si:
¿Puede el modelo escribir SQL?
Sino:
¿Sabe qué significa "cliente activo" para la empresa?
Ese conocimiento reside en la capa semántica.
7. Aprende negocio
Este punto no aparece lo suficiente en los roadmaps que vemos en internet.
Puedes dominar dbt y seguir siendo un Analytics Engineer mediocre.
Porque alguien tiene que transformar:
“Queremos entender mejor a nuestros clientes”
en algo como:
Customer
├── Acquisition Date
├── First Purchase
├── Revenue
├── Orders
├── AOV
├── Retention
└── Churn
Eso requiere entender:
- KPIs.
- Métricas.
- Finanzas básicas.
- Producto.
- Marketing.
- Operaciones.
- Cómo una empresa toma decisiones.
El objetivo es construir una representación confiable del negocio utilizando datos
Entonces, ¿cuál es mi roadmap?
1. SQL
↓
2. Data Warehousing
↓
3. Data Modeling
↓
4. dbt
↓
5. Snowflake / BigQuery / Databricks
↓
6. Git + CI/CD + Testing
↓
7. Semantic Layer + Metrics
↓
8. BI
↓
9. Business
↓
10. AI-assisted Analytics Engineering
¿Y Python?
Apréndelo.
Te será útil para automatización, APIs, validaciones y casos en los que SQL deja de ser suficiente.
Pero no retrasaría seis meses mi entrada a Analytics Engineering porque todavía no domino Python avanzado.
SQL + Data Modeling + dbt deberían recibir más atención.