⏱️ Lectura: 17 min
Te asignan a un proyecto de datos y en la primera reunión escuchás ETL, warehouse, dbt y reverse ETL en la misma frase. Bienvenido al vocabulario diario de las herramientas de datos que usa cualquier equipo de datos moderno.
📑 En este artículo
- TL;DR
- Los cuatro roles del ecosistema de herramientas de datos
- El ciclo de vida del dato: de la fuente al dashboard
- Ejemplos prácticos: de la consulta SQL al pipeline orquestado
- Cómo empezar: montá tu propio mini stack de datos
- Casos de uso reales
- Errores comunes y buenas prácticas
- Comparativa: ETL, ELT y reverse ETL
- Profundizando: lakehouse, data mesh y streaming
- Preguntas frecuentes
- ¿Cuál es la diferencia entre un data analyst y un data scientist?
- ¿Qué es un data warehouse y en qué se diferencia de un data lake?
- ¿Necesito saber Python para trabajar con herramientas de datos?
- ¿Por qué dbt reemplazó tanto SQL suelto?
- ¿Qué es exactamente reverse ETL y por qué no es simplemente ETL al revés?
- ¿Por dónde empiezo si soy developer y me asignan a un proyecto de datos?
- Referencias
Este artículo mapea las herramientas de datos que vas a encontrarte: quién hace qué en el equipo, por dónde entra la información, dónde vive y cómo llega a un dashboard o a un modelo de machine learning. Con ejemplos de código en SQL, Python y dbt para que puedas seguir el hilo desde el primer día.
TL;DR
- Vas a distinguir los 4 roles de un equipo de datos (analyst, scientist, engineer, ML engineer) y qué herramienta usa cada uno.
- Vas a entender la diferencia entre ETL, ELT y reverse ETL, y cuándo conviene cada enfoque.
- Vas a saber cuándo usar un data warehouse, un data lake o un lakehouse según el tipo de dato.
- Vas a escribir tu primer modelo dbt y tu primer DAG de Airflow con ejemplos reales.
- Vas a montar un mini stack de datos local con DuckDB en minutos, sin infraestructura cloud.
- Vas a identificar errores comunes al diseñar pipelines: schema drift, falta de tests y jobs no idempotentes.
- Vas a poder leer un diagrama de arquitectura de datos y ubicar dónde encaja cada herramienta que mencionan tus colegas.
Los cuatro roles del ecosistema de herramientas de datos
En una empresa mediana, el equipo de datos rara vez es una sola persona con un único perfil. Son roles que se solapan, sobre todo en equipos chicos, y entender la diferencia te ahorra confusiones cuando alguien te dice “eso lo tiene que ver el data engineer” o “esa pregunta es para el analyst”.
Analytical: el que interpreta
El perfil analítico convierte datos crudos en respuestas para el negocio. Domina SQL y hojas de cálculo, y trabaja con herramientas de business intelligence (BI) como Tableau, Looker o Metabase. Un día típico: extraer datos de clientes con una consulta SQL, calcular la tasa de abandono por región, armar un dashboard en Tableau y presentarlo al equipo de marketing con una recomendación concreta.
Scientific: el que predice
El perfil científico va más allá del reporte: aplica estadística, construye modelos y corre experimentos. Suele programar en Python con pandas y scikit-learn, y vive dentro de notebooks (Jupyter, Deepnote, Google Colab). Un día típico: tomar los mismos datos de clientes, buscar qué variables correlacionan con el abandono, entrenar un modelo que estime la probabilidad de fuga por cliente y diseñar un A/B test para una campaña de retención.
Engineering: el que construye la tubería
El data engineer hace posible que los otros dos perfiles tengan datos limpios y accesibles. Construye y mantiene los pipelines que extraen información de fuentes distintas (bases transaccionales, APIs, eventos de producto), la estandarizan y la cargan en un warehouse o un lake. También administra bases de datos y otras piezas de infraestructura de datos, y suele trabajar con Python, Apache Spark, warehouses en la nube y orquestadores como Airflow.
ML engineering: el que pone modelos en producción
Un cuarto perfil, cada vez más común, es el ML engineer: toma el modelo que entrenó el data scientist en un notebook y lo convierte en un servicio confiable, versionado y monitoreado en producción. Se apoya en MLOps: registro de modelos, pipelines de reentrenamiento y observabilidad de métricas como el drift de datos.
El ciclo de vida del dato: de la fuente al dashboard
Todas las herramientas de datos que vas a escuchar nombrar encajan en alguna etapa de un mismo ciclo: extracción, carga, transformación y consumo. Ese orden, o su variante con la transformación antes de la carga, define si estás frente a un pipeline ETL o ELT.
Las fuentes son bases de datos transaccionales (Postgres, MySQL), APIs de terceros (Stripe, HubSpot), eventos de producto (clicks, sesiones) o archivos planos. Herramientas como Fivetran, Airbyte o Meltano se conectan a esas fuentes y replican los datos hacia un destino central sin que tengas que escribir un conector a mano por cada API.
Ese destino central es el warehouse (Snowflake, BigQuery, Redshift) o, si los datos son menos estructurados, un data lake sobre almacenamiento de objetos (S3, GCS) con formatos como Parquet. Ahí entra la transformación: convertir datos crudos en tablas limpias, documentadas y listas para que un analyst arme un dashboard sin adivinar qué significa cada columna.
flowchart TD
A["Fuentes: APIs, bases transaccionales, eventos"] --> B["Ingestion: Fivetran, Airbyte, Meltano"]
B --> C[("Data warehouse o data lake")]
C --> D["Transformación: dbt"]
D --> E["BI: Tableau, Metabase, Looker"]
D --> F["ML: notebooks, modelos en producción"]El último tramo es el consumo: dashboards de BI para el perfil analítico, notebooks y pipelines de features para el perfil científico, y en muchos casos un viaje de vuelta hacia las herramientas operativas (CRM, email marketing) que se conoce como reverse ETL. Ese patrón se repite en la sección de casos de uso.
Ejemplos prácticos: de la consulta SQL al pipeline orquestado
Extraer y explorar con Python
El punto de entrada más simple para cualquier developer es un script de Python que lee un archivo y calcula algo. No hace falta un warehouse para empezar a pensar como un analyst.
import pandas as pd
df = pd.read_csv("customers.csv")
churned = df[df["status"] == "churned"]
churn_rate = len(churned) / len(df) * 100
print(f"Tasa de abandono: {churn_rate:.2f}%")Este script lee un CSV local con pandas, filtra los clientes marcados como churned y calcula el porcentaje sobre el total. Con un dataset de ejemplo de 5.000 filas, la salida sería algo como Tasa de abandono: 4.32%. Es el mismo cálculo que haría un analyst en Tableau, solo que en código en vez de una interfaz visual.
Transformar con SQL directamente en el warehouse
Cuando los datos ya viven en un warehouse, la transformación más simple es una consulta SQL con agregaciones. No hay ETL de por medio: es una vista que corre sobre datos que otro pipeline ya cargó.
SELECT
region,
COUNT(*) AS total_clientes,
SUM(CASE WHEN status = 'churned' THEN 1 ELSE 0 END) AS clientes_perdidos,
ROUND(100.0 * SUM(CASE WHEN status = 'churned' THEN 1 ELSE 0 END) / COUNT(*), 2) AS tasa_abandono
FROM analytics.customers
GROUP BY region
ORDER BY tasa_abandono DESC;La consulta agrupa clientes por región, cuenta el total y calcula qué porcentaje quedó marcado como churned. El resultado es una tabla con una fila por región y su tasa de abandono ordenada de mayor a menor, lista para pegar en un dashboard.
Modelar con dbt: SQL versionado y testeable
El problema de escribir consultas SQL sueltas es que nadie las versiona ni las testea. dbt (data build tool) resuelve eso: tratás cada transformación como un modelo SQL con referencias explícitas a otros modelos, control de versiones en Git y tests automáticos de calidad de datos.
-- models/marts/customer_churn.sql
with customers as (
select * from {{ ref('stg_customers') }}
),
orders as (
select
customer_id,
max(order_date) as ultima_compra
from {{ ref('stg_orders') }}
group by customer_id
)
select
c.customer_id,
c.region,
o.ultima_compra,
case
when o.ultima_compra < current_date - interval '90 days' then true
else false
end as en_riesgo_de_churn
from customers c
left join orders o using (customer_id)Este modelo combina dos tablas de staging (clientes y órdenes) y agrega una columna calculada: en_riesgo_de_churn, que marca como true a cualquier cliente sin compras en los últimos 90 días. Al correr dbt run, dbt compila el SQL final, resuelve las referencias con {{ ref(...) }} y crea o actualiza la tabla customer_churn en el warehouse.
Orquestar el pipeline completo con Airflow
Ni la extracción ni la transformación corren solas: alguien tiene que dispararlas en orden y en un horario. Ese es el trabajo de un orquestador como Apache Airflow, que define el pipeline completo como un grafo de tareas (un DAG).
from airflow import DAG
from airflow.operators.bash import BashOperator
from datetime import datetime
with DAG(
dag_id="pipeline_customers",
schedule="0 6 * * *",
start_date=datetime(2026, 1, 1),
catchup=False,
) as dag:
extraer = BashOperator(
task_id="extraer_customers",
command="airbyte-cli sync --connection customers-postgres-to-warehouse",
)
transformar = BashOperator(
task_id="transformar_dbt",
command="dbt run --select customer_churn",
)
extraer >> transformarEste DAG corre todos los días a las 6 AM: primero sincroniza los datos de clientes desde Postgres hacia el warehouse con Airbyte, y recién cuando esa tarea termina (por el operador >>) dispara el modelo dbt customer_churn. Si el paso de extracción falla, Airflow no ejecuta la transformación y podés configurar una alerta.
Cómo empezar: montá tu propio mini stack de datos
No necesitás una cuenta de Snowflake ni un cluster de Spark para practicar. DuckDB es un motor de SQL analítico que corre embebido, sin servidor, y lee CSV o Parquet directamente desde el disco. Es el warehouse de bolsillo perfecto para entender el flujo sin pagar nada.
1. Instalar DuckDB
- macOS (Homebrew):
brew install duckdb - Linux:
curl https://install.duckdb.org | sh - Windows (winget):
winget install DuckDB.cli
2. Verificar la instalación
duckdb --versionDebería imprimir algo como v1.x.x. Si el comando no se reconoce, cerrá y volvé a abrir la terminal para que el PATH se actualice.
3. Consultar un CSV sin cargarlo a ninguna base
duckdb -c "SELECT region, COUNT(*) AS total FROM read_csv_auto('customers.csv') GROUP BY region;"DuckDB infiere el esquema del CSV automáticamente con read_csv_auto y corre la agregación en memoria. Es el mismo patrón mental que un data warehouse en la nube, pero corriendo en tu laptop en segundos.
4. Dar el siguiente paso: dbt sobre DuckDB
pip install dbt-duckdb
dbt init mi_proyecto_datosCon el adaptador dbt-duckdb podés escribir los mismos modelos SQL de la sección anterior y correrlos localmente, sin depender de un warehouse pago, antes de migrar el proyecto a Snowflake o BigQuery en producción.
💡 Tip: DuckDB también lee Parquet directo desde S3 con read_parquet('s3://bucket/archivo.parquet'), útil para explorar un data lake sin montar infraestructura.
Casos de uso reales
Dos ejemplos conectan todo lo anterior con un problema de negocio real: el análisis de abandono de clientes (churn) y el camino de vuelta de los datos hacia las herramientas operativas.
De un pipeline de churn a una campaña de retención
El data engineer mantiene el pipeline que trae datos de clientes desde Postgres, Stripe y el CRM hacia el warehouse todas las noches. El data analyst usa esa tabla para calcular la tasa de abandono por región en un dashboard de Tableau. El data scientist toma la misma tabla base, entrena un modelo que predice qué clientes activos tienen alta probabilidad de cancelar el próximo mes, y ese resultado (un score por cliente) se vuelve a escribir en el warehouse como una tabla más.
Reverse ETL: cuando el dato vuelve a las herramientas operativas
El score de riesgo de churn no sirve de nada guardado en el warehouse: el equipo de marketing necesita verlo dentro del CRM para lanzar una campaña. Ahí entra el reverse ETL: herramientas como Hightouch o Census toman una tabla del warehouse y la sincronizan hacia un sistema operativo (CRM, herramienta de email, ads).
sequenceDiagram
participant W as Warehouse
participant R as Reverse ETL
participant C as CRM
W->>R: exporta score de riesgo de churn
R-->>C: sincroniza campo custom por cliente
Note over W,C: el equipo de marketing ve el score sin tocar SQLEs la misma tubería de datos, pero recorrida en sentido contrario: en vez de que el analyst vaya a buscar el dato al warehouse, el dato viaja solo hasta donde el equipo de negocio ya trabaja todos los días.
Errores comunes y buenas prácticas
- Schema drift silencioso: una fuente cambia el nombre o el tipo de una columna y el pipeline sigue corriendo, pero con datos corruptos. Mitigalo con tests de esquema en cada carga.
- SQL sin versionar: consultas copiadas y pegadas entre dashboards que nadie sabe quién escribió ni por qué. Un proyecto dbt en Git resuelve esto de raíz.
- Jobs que no son idempotentes: correr el mismo pipeline dos veces duplica filas en vez de sobrescribirlas. Diseñá las cargas para que correr el job N veces dé el mismo resultado que correrlo una sola vez.
- Confundir ETL con ELT: transformar antes de cargar tiene sentido cuando el volumen es chico y el destino no puede procesar SQL pesado; con un warehouse moderno, casi siempre conviene cargar crudo y transformar después (ELT).
- Sobrediseñar el primer pipeline: no hace falta Spark ni Kafka para un dataset de 200.000 filas. Empezá con DuckDB o un script de Python y escalá cuando el volumen lo exija de verdad.
Comparativa: ETL, ELT y reverse ETL
| Enfoque | Qué hace | Herramientas típicas | Cuándo usarlo |
|---|---|---|---|
| ETL (extract, transform, load) | Transforma los datos antes de cargarlos al destino | Talend, Informatica, scripts de Python a medida | Volúmenes chicos o destinos sin capacidad de cómputo propia |
| ELT (extract, load, transform) | Carga los datos crudos y transforma dentro del warehouse | Fivetran o Airbyte + dbt | Warehouses modernos con cómputo elástico (Snowflake, BigQuery) |
| Reverse ETL | Sincroniza datos ya transformados de vuelta a herramientas operativas | Hightouch, Census | Cuando un equipo de negocio necesita el dato dentro de su CRM o ads, no en un dashboard |
| CDC / streaming | Captura cambios en tiempo casi real en vez de por lotes | Debezium, Kafka, Fivetran CDC | Casos donde la latencia de horas de un batch job no es aceptable |
Profundizando: lakehouse, data mesh y streaming
La frontera entre warehouse y data lake se volvió difusa con el lakehouse: almacenamiento de objetos barato, como un lake, con transacciones, versionado de esquema y queries SQL rápidas, como un warehouse. Formatos de tabla abiertos como Apache Iceberg, Delta Lake o Apache Hudi hacen posible esa combinación: agregan una capa transaccional sobre archivos Parquet en S3 o GCS.
flowchart TD
subgraph Warehouse
W1["Datos estructurados"] --> W2["Motor SQL propietario"]
end
subgraph "Data lake"
L1["Datos crudos: JSON, logs, Parquet"] --> L2["Almacenamiento de objetos"]
end
subgraph Lakehouse
H1["Almacenamiento de objetos"] --> H2["Capa transaccional: Iceberg, Delta"]
H2 --> H3["Motor SQL"]
endEl data mesh, en cambio, no es una herramienta sino una forma de organizar equipos: en vez de un único equipo central de datos dueño de todo el warehouse, cada equipo de producto es dueño de sus propios datasets y los expone como un producto de datos con contrato y documentación. Resuelve un problema de escala organizacional más que técnico, cuando un equipo central se vuelve cuello de botella para decenas de equipos de producto.
El streaming, con herramientas como Kafka o Kinesis, reemplaza el patrón de lotes (correr un pipeline cada hora) por un flujo continuo de eventos. Tiene sentido cuando la decisión de negocio depende de segundos, no de horas: detección de fraude en el momento del pago, por ejemplo. Para la mayoría de los dashboards de negocio, un batch job nocturno sigue siendo más simple y más barato de mantener.
Por último, la calidad de datos se volvió su propia disciplina dentro del ecosistema de herramientas de datos: proyectos como Great Expectations validan que una tabla cumpla reglas (columnas no nulas, rangos esperados, unicidad) como parte del pipeline, en vez de descubrir el problema cuando el dashboard ya muestra un número imposible.
⚠️ Ojo: migrar a streaming o a un lakehouse antes de tener el problema de escala real que resuelven agrega complejidad operativa sin beneficio medible.
📖 Resumen en Telegram: Ver resumen
Tu próximo paso: descargá un CSV público de Kaggle, instalá DuckDB y corré una consulta GROUP BY sobre él en tu terminal antes de escribir tu primer modelo dbt.
Preguntas frecuentes
¿Cuál es la diferencia entre un data analyst y un data scientist?
El analyst interpreta datos existentes con SQL y BI para responder preguntas del negocio. El scientist va más allá: aplica estadística y modelos para predecir o explicar, y suele trabajar en notebooks con Python.
¿Qué es un data warehouse y en qué se diferencia de un data lake?
Un warehouse guarda datos estructurados y optimizados para consultas SQL rápidas (Snowflake, BigQuery). Un data lake guarda cualquier tipo de dato, estructurado o no, en almacenamiento de objetos barato, sin imponer un esquema al momento de escribir.
¿Necesito saber Python para trabajar con herramientas de datos?
No para todos los roles. Un data analyst puede resolver la mayoría de su trabajo con SQL y una herramienta de BI. Python se vuelve necesario apenas entrás al perfil científico o de engineering, donde vas a transformar datos con pandas o escribir pipelines.
¿Por qué dbt reemplazó tanto SQL suelto?
Porque le da a las transformaciones lo que le falta al SQL copiado y pegado en un dashboard: control de versiones en Git, referencias explícitas entre modelos y tests automáticos que fallan el pipeline si un dato no cumple una regla.
¿Qué es exactamente reverse ETL y por qué no es simplemente ETL al revés?
Técnicamente sí mueve datos en sentido contrario al pipeline tradicional, del warehouse hacia una herramienta operativa como un CRM. Se lo nombra aparte porque resuelve un problema distinto: no analizar datos, sino operacionalizarlos para que un equipo de negocio actúe sobre ellos sin tocar SQL.
¿Por dónde empiezo si soy developer y me asignan a un proyecto de datos?
Instalá DuckDB, conseguí un CSV real (de tu propio producto o de un dataset público) y recorré las cuatro etapas del ciclo con tus propias manos: leelo con pandas, consultalo con SQL, transformalo con un modelo dbt y, si tu equipo usa Airflow, mirá un DAG existente antes de escribir uno propio.
Referencias
- Sinja.io: Guide to data tools landscape for developers: el artículo original en el que se basa esta guía, escrito por un software engineer que se sumó a un equipo de datos.
- Documentación oficial de dbt: referencia completa de modelos, tests y el sistema de referencias
ref(). - Apache Airflow: documentación del orquestador de pipelines usado en el ejemplo del DAG.
- DuckDB: motor SQL analítico embebido usado en la sección “Cómo empezar”.
- Apache Iceberg: formato de tabla abierto detrás de la mayoría de las implementaciones de lakehouse.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Imagen destacada: Foto de Luke Chesser en Unsplash
0 Comentarios