ETL vs ELT Moderno: dbt, Airbyte y Fivetran
Las pipelines de datos son el sistema circulatorio de toda arquitectura data-driven. Sin un flujo fiable, documentado y probado de datos desde la fuente al warehouse, los modelos de machine learning producen predicciones erróneas, los informes de negocio muestran números inconsistentes y las decisiones estratégicas se basan en fundamentos inestables. Sin embargo, en la mayoría de las empresas, las pipelines de datos siguen siendo una maraña de scripts SQL programados con cron, hojas Excel actualizadas a mano y procesos ETL construidos hace décadas que nadie se atreve a tocar.
El panorama ha cambiado radicalmente en los últimos cinco años. La idea de la computación en la nube ha revitalizó el paradigma fundamental del movimiento de datos: no hay forma de transformar los datos antes cargarlos en el portátil, como se hace con el ETL tradicional, cuando el La potencia informática en la nube está disponible a costos insignificantes y puede implementarse en la computadora moderna. Completa las transformaciones para continuar. Así nació el paradigma ELT (Extraer, Carga, transformar), que invierte el orden de las operaciones transfiriendo la transformación dentro de su almacén.
El mercado de las pipelines de datos refleja esta transformación: el segmento ELT crece al 26% anual, con el mercado global de data pipeline tools estimado en $12 mil millones en 2024 y proyectado a $48 mil millones para 2030. Fivetran, el principal actor ELT managed, ha alcanzado $300 millones de ARR con un crecimiento del 50% año tras año. No se trata de un nicho: es el nuevo estándar.
En este artículo exploraremos ambos paradigmas en profundidad, analizaremos las herramientas que dominan el mercado (dbt, Airbyte, Fivetran), construiremos una arquitectura de referencia completa y proporcionaremos recomendaciones prácticas para elegir el stack adecuado en función del tamaño y las competencias del equipo.
Lo que aprenderás en este artículo.
- Las diferencias fundamentales entre ETL tradicional y ELT moderno, con pros/contras y casos de uso
- Cómo funciona dbt (Data Build Tool): modelos SQL, testing, documentación, lineage
- dbt Core vs dbt Cloud: cuál elegir y a qué coste
- Airbyte: conectores open-source, arquitectura y deployment para self-hosting
- Fivetran: el modelo SaaS managed y el nuevo pricing MAR (2025)
- Comparación detallada entre las tres herramientas para distintos escenarios empresariales
- Arquitectura ELT moderna de referencia: Airbyte/Fivetran + Warehouse + dbt + BI
- Mejores prácticas para testing, documentación y orquestación de pipelines
ETL Tradicional: Cómo Funciona y por qué Ya No Es Suficiente
Durante casi treinta años, el ETL (Extract, Transform, Load) ha sido el paradigma dominante para el movimiento de datos empresariales. El proceso se articula en tres fases secuenciales:
- Extract (Extracción): Los datos se extraen de los sistemas fuente, típicamente bases de datos OLTP (ERP, CRM, e-commerce), archivos planos (CSV, XML) o APIs externas. Esta fase lee los datos sin modificarlos.
- Transform (Transformación): Los datos extraídos se transforman en un sistema intermedio, llamado staging area o ETL engine, separado tanto de la fuente como del destino. Las transformaciones incluyen limpieza, normalización, enriquecimiento, agregación y conformación a los estándares del warehouse.
- Cargar (Cargar): Los datos transformados se almacenan en el almacenamiento de datos. del destino. La estructura de tus datos es la definitiva, optimizada para consultas analíticas.
Las Herramientas ETL Tradicionales
| Herramienta | Vendor | Coste Indicativo | Target |
|---|---|---|---|
| SSIS | Microsoft | Incluido en SQL Server | PYMES con ecosistema Microsoft |
| Informatica PowerCenter | Informatica | $50.000-$500.000/año | Enterprise banking/insurance |
| Oracle Data Integrator | Oracle | Incluido con Oracle DB | Ecosistema Oracle |
| Talend Open Studio | Qlik | Free (core) / $1.170+/mes | PYMES, open source |
| Pentaho Data Integration | Hitachi Vantara | Free (CE) / Custom (EE) | PYMES, open source |
Estas herramientas funcionan. Han sido (y en muchos casos siguen siendo) la columna vertebral de sistemas críticos que mueven miles de millones de euros en transacciones cada día. Pero tienen límites estructurales que el paradigma cloud ha hecho cada vez más evidentes.
Los Límites Estructurales del ETL Clásico
Por Qué el ETL Tradicional Tiene Dificultades en el Contexto Moderno
- Compute externo costoso: Las transformaciones se realizan en un servidor separado (ETL server), que debe dimensionarse para el pico de carga. Si el batch nocturno procesa 100 millones de filas, el servidor debe ser lo suficientemente potente para sostener esa ventana temporal, aunque durante 22 horas al día permanezca casi inactivo.
- Rigidez y coste del cambio: Añadir un campo a una transformación SSIS requiere modificar el flujo visual, probarlo en staging, coordinar el despliegue con quien gestiona el warehouse de destino. En equipos estructurados, esto requiere semanas.
- Sin versión nativa: Las transmisiones ETL no cumplen con el código versionable como el software de aplicación. La gobernanza se está volviendo difícil: esto ha cambiado esta transformación? ¿Cuándo? ¿Por qué?
- Debug complejo: Cuando una transformación produce resultados inesperados, rastrear el problema a través de un flujo ETL visual puede requerir horas. No existe un "data lineage" estándar que muestre de dónde viene cada columna.
- Pérdida de energía del almacén: Se invierte en un Snowflake o un BigQuery de decenas de miles de euros al año por su potencia computacional, pero luego se procesan los datos en un servidor separado. El paradigma ELT reconoce que el propio warehouse es el motor de transformación más eficiente.
ELT moderno: por qué la nube lo cambió todo
El ELT (Extract, Load, Transform) invierte el orden de las dos últimas fases: los datos se extraen primero de las fuentes y se cargan en el warehouse en su forma bruta, y solo posteriormente se transforman utilizando la potencia de cálculo del propio warehouse.
Este cambio de paradigma ha sido posible gracias a tres factores convergentes:
- Storage cloud económico: Amazon S3, Azure Blob Storage y Google Cloud Storage cuestan $20-23 por TB al mes. Ya no tiene sentido ser austero con el almacenamiento: mejor cargar todo y decidir después qué transformar.
- Computadora elástica: Snowflake, BigQuery y Databricks escalan automáticamente la computadora. Se debe realizar una consulta de transformación completa a su debido tiempo. grupos de cientos de nudos, pagando sólo por el tiempo de ejecución real.
- SQL como lenguaje universal: Los data analysts conocen SQL mucho mejor que las herramientas ETL propietarias. Con ELT, las transformaciones son simples consultas SQL que cualquiera del equipo puede leer, modificar y revisar.
Comparación ETL vs ELT: Tabla Decisional
ETL vs ELT: Comparación Completa
| Dimensión | ETL Tradicional | ELT Moderno |
|---|---|---|
| de donde se produce la transformación | Servidor ETL dedicado (externo al warehouse) | Dentro del data warehouse (SQL nativo) |
| Cuándo transformar | Antes de cargar | Retire la carga de capa cruda. |
| Volumen de datos soportado | Limitado por la capacidad del servidor ETL | Escalar con la bolsa (potencialmente ilimitado) |
| Datos no estructurados | Difícil o imposible | Soportado (JSON nativo, semi-structured) |
| Lenguaje | GUI propietaria / Java / Python | SQL estándar (+ Jinja en dbt) |
| Versionado | Difícil, a menudo ausente | Git nativo (los modelos son archivos .sql) |
| Testing | Manual o limitado | Framework de test integrado (dbt test) |
| Data lineage | A menudo ausente o manual | Automático (DAG visual en dbt) |
| Seguridad / Compliance | Datos sensibles nunca en el warehouse en claro | Raw data en el warehouse: se necesita masking y governance |
| Latencia de transformación | Depende del ETL server | Depende del warehouse (batch o on-demand) |
| Curva de aprendizaje | Alta (GUIs propietarias) | Baja para quien conoce SQL |
| Ideal para | Datos sensibles, sistemas legacy, compliance estricta | Cloud-first, equipos SQL, alto volumen de datos |
Cuándo Elegir ETL vs ELT
- Elige ETL cuando: tienes requisitos de compliance que prohíben cargar datos brutos en el cloud (ej: PII sin anonimización), trabajas con sistemas legacy on-premise donde el warehouse está demasiado lejos de la fuente, o tienes transformaciones computacionalmente intensivas que no se benefician del warehouse SQL.
- Elige ELT cuando: tu warehouse es cloud (Snowflake, BigQuery, Databricks, Redshift), el equipo tiene competencias SQL sólidas, quieres versionar las transformaciones con Git, trabajas con volúmenes de datos crecientes y quieres aprovechar la elasticidad del cloud.
- Énfasis híbrido: Muchas empresas adoptan un enfoque mixto: ETL para la anonimización de datos sensibles antes de la carga, ELT para todas las transformaciones analítica posterior.
dbt: La capacidad de transformación de la batería moderna
dbt (Data Build Tool) es la herramienta que ha definido el paradigma ELT moderno. Creado por dbt Labs en 2016, dbt transforma la forma en que los data analysts escriben las transformaciones: en lugar de procedimientos SQL dispersos sin estructura, dbt introduce un framework de desarrollo inspirado en la ingeniería de software, con modelos versionados, tests automáticos y documentación generada automáticamente.
El concepto fundamental es simple: caer El modelo dbt es un archivo .sql. que contiene un SELECCIONAR. dbt es responsable de crear la tabla o vista en el almacén, gestionando las dependencias. ingresar modelos y construir un DAG (gráfico acíclico dirigido) de las transformaciones.
Arquitectura dbt: Cómo Funciona
dbt no tiene un runtime de cálculo propio: utiliza el compute del warehouse de destino. Funciona como un compilador SQL + orquestador: toma los archivos .sql con las macros Jinja, los compila en SQL puro, y los ejecuta en el warehouse en el orden correcto basándose en las dependencias declaradas. El resultado es una serie de tablas y views en el warehouse, construidas de manera reproducible.
-- models/staging/stg_orders.sql
-- Modelo de staging: limpieza y estandarización de los pedidos
-- dbt crea una view (o tabla) llamada 'stg_orders' en el warehouse
WITH source AS (
-- Referencia a la tabla fuente raw (cargada por Airbyte/Fivetran)
SELECT * FROM {{ source('erp', 'raw_orders') }}
),
cleaned AS (
SELECT
order_id::BIGINT AS order_id,
customer_id::INT AS customer_id,
product_id::INT AS product_id,
quantity::INT AS quantity,
unit_price::DECIMAL(10, 2) AS unit_price,
COALESCE(discount, 0.0)::DECIMAL(5, 2) AS discount,
CAST(order_date AS TIMESTAMP) AS order_date,
LOWER(TRIM(status)) AS status,
-- Importe neto calculado
quantity * unit_price * (1 - COALESCE(discount, 0))
AS net_amount,
-- Metadatos de auditoría
_loaded_at AS ingested_at
FROM source
WHERE order_id IS NOT NULL
AND customer_id IS NOT NULL
AND quantity > 0
AND unit_price > 0
)
SELECT * FROM cleaned-- models/marts/finance/fct_orders_monthly.sql
-- Modelo de hechos: agregación mensual para el equipo de finanzas
-- Depende de stg_orders y dim_customers (resolución automática de dependencias)
{{ config(
materialized='table',
schema='finance',
tags=['finance', 'monthly']
) }}
WITH orders AS (
SELECT * FROM {{ ref('stg_orders') }}
),
customers AS (
SELECT * FROM {{ ref('dim_customers') }}
),
monthly_metrics AS (
SELECT
DATE_TRUNC('month', o.order_date) AS month,
c.region,
c.segment,
COUNT(DISTINCT o.order_id) AS total_orders,
COUNT(DISTINCT o.customer_id) AS unique_customers,
SUM(o.net_amount) AS gross_revenue,
AVG(o.net_amount) AS avg_order_value,
SUM(o.quantity) AS units_sold
FROM orders o
LEFT JOIN customers c ON o.customer_id = c.customer_id
GROUP BY 1, 2, 3
)
SELECT
*,
gross_revenue / NULLIF(unique_customers, 0) AS revenue_per_customer
FROM monthly_metrics
ORDER BY month DESC, gross_revenue DESCTesting en dbt: Garantizar la calidad de los datos
Uno de los puntos más importantes de DBT es su sistema de cabezal nativo. Los tests en dbt
Son claros: se definen en un archivo YAML y se ejecutan automáticamente cada vez.
ejecutar con el comando dbt test.
# models/staging/schema.yml
# Definición de los tests para el modelo stg_orders
version: 2
models:
- name: stg_orders
description: >
Pedidos limpios y estandarizados del sistema ERP fuente.
Cargados cada hora por Airbyte, transformados por este modelo.
columns:
- name: order_id
description: "Identificador único del pedido (PK)"
tests:
- unique # No se admiten duplicados
- not_null # Cada fila debe tener un order_id
- name: customer_id
description: "Referencia a la dimensión de clientes"
tests:
- not_null
- relationships: # Referential integrity check
to: ref('dim_customers')
field: customer_id
- name: status
description: "Estado del pedido"
tests:
- accepted_values:
values: ['pending', 'confirmed', 'shipped', 'delivered', 'cancelled']
- name: net_amount
description: "Importe neto del pedido (cantidad * precio * (1 - descuento))"
tests:
- not_null
- dbt_utils.expression_is_true:
expression: "net_amount >= 0"
- name: order_date
description: "Fecha y hora del pedido"
tests:
- not_null
- dbt_utils.expression_is_true:
expression: "order_date <= CURRENT_TIMESTAMP"
- name: fct_orders_monthly
description: "Agregaciones mensuales para el reporting de finanzas"
columns:
- name: month
tests:
- not_null
- name: gross_revenue
tests:
- not_null
- dbt_utils.expression_is_true:
expression: "gross_revenue >= 0"
sources:
- name: erp
description: "Datos brutos cargados desde el ERP a través de Airbyte"
schema: raw_erp
tables:
- name: raw_orders
loaded_at_field: _loaded_at
freshness:
warn_after: {count: 12, period: hour}
error_after: {count: 24, period: hour}dbt Core vs dbt Cloud
dbt existe en dos variantes: núcleo dbt (código abierto, gratis) y nube dbt (Administrado SaaS, pago). La elección depende de las necesidades. del equipo en términos de infraestructura y funciones avanzadas.
dbt Core vs dbt Cloud: Comparación Completa
| Funcionalidad | dbt Core (Open Source) | dbt Cloud Team | dbt Cloud Enterprise |
|---|---|---|---|
| Coste | Gratuito | $100/seat/mes + $0.01 por modelo más allá de 15.000 | Personalizado (contacto con proveedores) |
| Ejecución de jobs | Manual / Orquestador externo (Airflow, Dagster) | Scheduler nativo, CI/CD integrado | Scheduler avanzado + SLA monitoring |
| IDE web | No (solo editor local) | dbt Cloud IDE (browser-based) | dbt Cloud IDE |
| Documentación | Generada localmente (dbt docs generate) | Alojada automáticamente | Alojada + Data Catalog avanzado |
| Lineage visual | Local | Cloud hosted, compartible | Cloud hosted + Cross-project lineage |
| Colaboración en equipo | A través de Git (manual) | Multi-user, PR-based workflow | RBAC, SSO, audit logs |
| Semantic Layer | No | Incluido (5.000 métricas/mes) | Incluido (20.000 métricas/mes) |
| dbt Mesh | No | Limitado | Completo (referencias entre proyectos) |
| SOC 2 compliance | N/A (self-managed) | Incluido | Incluido + PrivateLink |
| Ideal para | Equipos técnicos, presupuesto limitado, ya tienen Airflow | Equipos de 2-20 personas sin infraestructura ETL | Enterprise, multi-equipo, compliance estricta |
Recomendación práctica: Las PYMES deberían trabajar con un equipo de 1-3 ingenieros de datos con dbt Core + Airflow o Dagster, lo que ofrece total flexibilidad a los costes. Si el equipo crece o si quieres evitar la gestión de la infraestructura de orquestación, nube dbt Es conveniente utilizarlo con 2-3 botones de cambio.
Airbyte: límite de almacenamiento de código abierto
Sí, él se hace cargo de ello. T (transformación) en el ELT, bytes de aire gestionar el E (extracción) y la L (carga). Financiado en 2020 y hoy con más Con una financiación de 180 millones de dólares, Airbyte es la plataforma de integración de datos de código abierto más adoptada del mercado, con Más de 600 conectores prediseñados. y un SDK de Python para construir Conectores personalizados.
El punto fuerte principal de Airbyte respecto a los competidores es la combinación de open-source (cero vendor lock-in, código modificable) con una arquitectura cloud-native que soporta Change Data Capture (CDC) para la réplica en tiempo real de las bases de datos.
Arquitectura de Airbyte
Airbyte está compuesto por varios componentes que trabajan en conjunto. Cada sincronización se ejecuta por un Worker que instancia dos contenedores Docker separados: el Source Connector (que lee de la fuente) y el Destination Connector (que escribe en el destino). Los datos fluyen entre ambos a través del Airbyte Protocol, un formato JSON estándar.
# Ejemplo: Configuración de conector Airbyte via API (YAML/JSON)
# Creación de una conexión PostgreSQL -> Snowflake
# 1. Configuración Source (PostgreSQL)
POST /api/v1/sources/create
{
"sourceDefinitionId": "decd338e-5647-4c0b-adf4-da0e75f5a750",
"connectionConfiguration": {
"host": "db.produccion.miempresa.es",
"port": 5432,
"database": "erp_production",
"username": "airbyte_reader",
"password": "{{ secrets.POSTGRES_PASSWORD }}",
"schemas": ["public", "orders"],
"replication_method": {
"method": "CDC",
"replication_slot": "airbyte_slot",
"publication": "airbyte_publication"
}
},
"name": "ERP Production PostgreSQL",
"workspaceId": "workspace-uuid"
}
# 2. Configuración Destination (Snowflake)
POST /api/v1/destinations/create
{
"destinationDefinitionId": "424892c4-daac-4491-b35d-c6688ba547ba",
"connectionConfiguration": {
"host": "abc12345.eu-west-1.snowflakecomputing.com",
"role": "AIRBYTE_ROLE",
"warehouse": "AIRBYTE_WH",
"database": "RAW_DATA",
"schema": "erp",
"username": "airbyte_user",
"credentials": {
"auth_type": "key_pair",
"private_key": "{{ secrets.SNOWFLAKE_PRIVATE_KEY }}"
}
},
"name": "Snowflake Production",
"workspaceId": "workspace-uuid"
}
# 3. Creación de la conexión
POST /api/v1/connections/create
{
"sourceId": "source-uuid",
"destinationId": "destination-uuid",
"syncCatalog": {
"streams": [
{
"stream": {"name": "orders", "namespace": "public"},
"config": {
"syncMode": "incremental",
"destinationSyncMode": "append_dedup",
"cursorField": ["updated_at"],
"primaryKey": [["order_id"]]
}
},
{
"stream": {"name": "customers", "namespace": "public"},
"config": {
"syncMode": "full_refresh",
"destinationSyncMode": "overwrite"
}
}
]
},
"scheduleType": "cron",
"scheduleData": {"cron": {"cronExpression": "0 */1 * * *", "cronTimeZone": "Europe/Rome"}},
"namespaceDefinition": "customformat",
"namespaceFormat": "raw_{{SOURCE_NAMESPACE}}"
}Airbyte: Deploy Options
Airbyte ofrece tres formas de implementación, cada una con características distintas en términos de costes, control y mantenimiento:
Airbyte: Open Source vs Cloud vs Enterprise
| Aspecto | Open Source (Self-hosted) | Airbyte Cloud | Airbyte Enterprise |
|---|---|---|---|
| Coste | Gratuito (infraestructura a tu cargo) | Pago por uso (crédito de $2,50 a $10) | Personalizado (contacto con proveedores) |
| Mantenimiento | A cargo del equipo | Gestionado por Airbyte | Gestionado por Airbyte |
| Conectores | 600+ | 600+ | 600+ + conectores certificados premium |
| CDC | Soportado | Soportado | Soportado + CDC avanzado |
| RBAC | Básico | Incluido | Avanzado (SSO, audit logs) |
| SLA | N/A | 99.9% uptime | 99.99% uptime |
| Ideal para | Equipos técnicos, presupuesto limitado, datos sensibles | PYMES que quieren velocidad sin ops | Empresa con estricta satisfacción. |
# Deploy Airbyte Open Source con Docker Compose
# Requisitos previos: Docker, Docker Compose, 8GB RAM, 20GB disk
# 1. Clona el repositorio
git clone --depth=1 https://github.com/airbytehq/airbyte.git
cd airbyte
# 2. Inicia Airbyte (primera ejecución: ~15 minutos para descargar imágenes)
./run-ab-platform.sh
# Airbyte es accesible en http://localhost:8000
# Username: airbyte / Password: password (¡cambiar en producción!)
# 3. Para deployment en producción sobre Kubernetes con Helm
helm repo add airbyte https://airbytehq.github.io/helm-charts
helm install airbyte airbyte/airbyte \
--namespace airbyte \
--create-namespace \
--set global.state.storage.type=MINIO \
--set global.storage.bucket.log=airbyte-logs \
--values custom-values.yaml
# 4. Configuración de variables de entorno para producción (.env)
# DATABASE_URL=postgresql://airbyte:password@postgres:5432/airbyte
# SECRET_PERSISTENCE=GOOGLE_SECRET_MANAGER
# LOG_LEVEL=INFO
# TRACKING_STRATEGY=segmentFivetran: la simplicidad de la administración SaaS
Mientras Airbyte apuesta por la flexibilidad y el control open-source, Fivetran ha elegido el camino opuesto: máxima simplicidad, cero mantenimiento, conectores enterprise-grade gestionados completamente por el vendor. Fundado en 2012, Fivetran es hoy el líder del segmento ELT managed con $300 millones de ARR, 6.300+ clientes y una valoración de $5.6 mil millones.
La propuesta de valor de Fivetran es clara: un conector Fivetran sostiene Salesforce, Shopify Cualquier otro sistema SaaS es mantenido por un equipo dedicado de ingenieros de Fivetran que Gestionan cada cambio de API de origen, cada cambio importante, cada actualización. esquema. El cliente no tiene que hacer nada.
El Nuevo Modelo de Pricing de Fivetran 2025
En marzo de 2025, Fivetran actualizó significativamente su modelo de precios. Los aviones de despliegue inicial y privado fueron eliminados y reemplazados en cuatro niveles: Gratis, estándar, emprendedor y crítico para la tienda.. La métrica de facturación sigue siendo el MAR (líneas activas mensuales), pero el cálculo ha cambiado: ahora cae la conexión se realiza por separado, pero no combinada por nombre.
Fivetran: Planes y Precios 2025
| Plan | MAR incluidos | Coste adicional | Features clave |
|---|---|---|---|
| Free | 500.000 MAR/mes | N/A | Todas las features Standard, hasta 5.000 model runs |
| Standard | Ilimitado (pago por uso) | $5 base/conexión + MAR pricing | 600+ conectores, CDC, dbt integration, scheduling |
| Enterprise | Negociable | Custom (descuento por volumen) | SSO/SAML, RBAC, VPN, priority support, SLA |
| Business Critical | Negociable | Custom | PrivateLink, HIPAA compliance, dedicated support, 99.99% SLA |
Cómo Funciona el Cálculo MAR en Fivetran
El MAR (Monthly Active Row) cuenta las filas distinto sincronizado en un mes del calendario, seguido de la clave principal. Una fila editada 30 veces en un mes Comprobado el 1 de marzo, no el 30 de marzo. Pago: el costo no desaparece con la frecuencia de sincronización, incluido con el número de registros únicos que cambian.
Ejemplo práctico: Una empresa con 50.000 pedidos activos al mes 500.000 productos en el catálogo (rara vez actualizados) pagan principalmente 50.000 pedidos que cambian de estado cada mes, no para el catálogo completo de productos.
dbt vs Airbyte vs Fivetran: ¿Cuál Elegir?
Es importante comprender que DBT, Airbyte y Fivetran no son hardware alternativo si mutuamente excluyentes: resuelven distintos problemas dentro de la misma pila. dbt si A cargo de las transformaciones, Airbyte y Fivetran se encargan de la ingesta. la solicitud correcto por ejemplo: ¿Es seguro Airbyte vs Fivetran?
Airbyte vs Fivetran: Comparación por Escenarios
| Dimensión | Airbyte Open Source | Airbyte Cloud | Fivetran Standard |
|---|---|---|---|
| Coste base | $0 (infraestructura aparte) | Pay-per-use | $5/conexión/mes + MAR |
| Conectores | 600+ (community maintained) | 600+ | 650+ (enterprise-grade) |
| Mantenimiento de conectores | Community / equipo interno | Equipo Airbyte | Equipo Fivetran (SLA garantizado) |
| CDC | Soportado (Debezium) | Soportado | Soportado (log-based) |
| Conectores custom | SDK Python (free) | SDK Python | Custom connector SDK (de pago) |
| Data residency | Completo (autohospedado) | Region-specific | Region-specific |
| Setup time | 1-4 horas (infraestructura) | 30 minutos | 15 minutos |
| dbt integration | Manual / Airflow | Nativa | Nativa (dbt Cloud) |
| Ideal para | Equipos técnicos, fuentes custom, GDPR local | PYMES tech-savvy, presupuesto variable | PYMES/Enterprise con fuentes SaaS estándar |
Regla Práctica para la Elección
- Utilice Fivetran Estas fuentes son SaaS estándar (Salesforce, HubSpot, Shopify, Stripe, Google Analytics, Facebook Ads) y el equipo no quiere hacerse cargo de mantenimiento de los conectores. La calidad del producto vale el costo.
- Usa la nube de Airbyte Tiene una combinación de fuentes estándar y personalizadas, o sí Estás ocupado y quieres consultar tus costes con el pago por uso.
- Usa Airbyte Open Source si tienes requisitos GDPR/data residency que impiden el tránsito de datos a través de infraestructuras de terceros, o si tienes fuentes altamente custom que requieren conectores escritos internamente.
Arquitectura ELT Moderna de Referencia
Uniendo todos los componentes, aquí está la arquitectura ELT moderna que las empresas líderes adoptan hoy. Cada capa del stack tiene un propósito preciso y herramientas de referencia.
El Stack ELT Moderno: Capa por Capa
| Capa | Función | Herramientas Principales |
|---|---|---|
| 1. Ingesta | Extraer y cargar datos brutos en el warehouse | Fivetran, Airbyte, Stitch, custom scripts |
| 2. Storage (Raw) | Datos brutos sin modificar (Bronze layer) | Snowflake, BigQuery, Databricks, Redshift |
| 3. Transformación | Modelos SQL, testing, documentación, lineage | dbt Core, dbt Cloud |
| 4. Serving (Gold) | Tablas optimizadas para analytics y ML | Snowflake, BigQuery, Databricks (warehouse) |
| 5. Orquestación | Scheduling, dependencias, monitoring de pipelines | Airflow, Dagster, Prefect, dbt Cloud |
| 6. BI y Reporting | Dashboards, consultas ad hoc, self-service analytics | Looker, Metabase, Power BI, Tableau |
| 7. Data Quality | Monitoring, alerting, anomaly detection | dbt tests, Great Expectations, Monte Carlo |
# Ejemplo: Pipeline ELT completa orquestada con Dagster
# Dagster define los jobs como grafo de assets
from dagster import asset, AssetIn, define_asset_job, ScheduleDefinition
# Asset 1: Raw data (cargado por Fivetran/Airbyte - externo a Dagster)
# Dagster puede "observar" las tablas cargadas por Fivetran como assets externos
@asset(
group_name="raw",
description="Pedidos brutos cargados por Fivetran (ERP)"
)
def raw_orders():
# Fivetran escribe aquí automáticamente cada hora
# Este asset "declara" la tabla para el lineage visual
pass
# Asset 2: dbt staging (transformación con dbt)
@asset(
group_name="staging",
deps=["raw_orders"],
description="Pedidos limpios y estandarizados (modelo dbt stg_orders)"
)
def stg_orders(context):
# Ejecuta el modelo dbt stg_orders
context.log.info("Running dbt model: stg_orders")
# En la práctica: dbt_cloud_run_op o subprocess dbt run --select stg_orders
return {"rows_processed": 15000}
# Asset 3: dbt marts (modelo gold listo para el negocio)
@asset(
group_name="marts",
ins={"staging": AssetIn("stg_orders")},
description="Facturación mensual para el reporting de finanzas"
)
def fct_orders_monthly(context, staging):
context.log.info(f"Building monthly metrics from {staging['rows_processed']} rows")
# dbt run --select fct_orders_monthly
return {"mart_rows": 360} # 30 días * 12 segmentos regionales
# Scheduling: ejecuta cada hora, actualiza todos los assets
elt_pipeline_job = define_asset_job(
name="elt_pipeline",
selection=["stg_orders", "fct_orders_monthly"]
)
elt_schedule = ScheduleDefinition(
job=elt_pipeline_job,
cron_schedule="0 * * * *", # Cada hora
execution_timezone="Europe/Rome"
)Mejores Prácticas para Pipelines de Datos Fiables
Crear un canal ELT que funcione para demostración es fácil. Construir un drenaje de canalización escala, que puede ser monitoreada y mantenida por un equipo durante todo el tiempo que requiere disciplina y la aplicación de prácticas de ingeniería consolidadas.
1. Estratificación y Naming Convention
Adopte una estructura de directorios clara y coherente que refleje la arquitectura. en capas (Medallón o equivalente):
# Estructura de proyecto dbt recomendada
dbt_project/
├── models/
│ ├── staging/ # Capa Silver: limpieza de fuentes
│ │ ├── erp/
│ │ │ ├── stg_orders.sql
│ │ │ ├── stg_customers.sql
│ │ │ └── schema.yml # Tests + documentación
│ │ ├── crm/
│ │ │ ├── stg_contacts.sql
│ │ │ └── schema.yml
│ │ └── ecommerce/
│ │ ├── stg_sessions.sql
│ │ └── schema.yml
│ ├── intermediate/ # Modelos intermedios (joins complejas)
│ │ ├── int_customer_orders.sql
│ │ └── schema.yml
│ └── marts/ # Capa Gold: listos para el negocio
│ ├── finance/
│ │ ├── fct_orders_monthly.sql
│ │ ├── fct_revenue_by_product.sql
│ │ └── schema.yml
│ ├── marketing/
│ │ ├── fct_campaign_performance.sql
│ │ └── schema.yml
│ └── operations/
│ ├── fct_fulfillment_kpis.sql
│ └── schema.yml
├── seeds/ # Datos estáticos (tablas de lookup, mapping)
│ ├── country_codes.csv
│ └── product_categories.csv
├── snapshots/ # SCD Type 2 (Slowly Changing Dimensions)
│ └── snap_customers.sql
├── tests/ # Tests custom SQL
│ └── assert_revenue_positive.sql
├── macros/ # Macros Jinja reutilizables
│ ├── generate_schema_name.sql
│ └── audit_columns.sql
└── dbt_project.yml # Configuración global2. Testing Como Contrato de Calidad
Los tests dbt no son opcionales: son el contrato que garantiza que las transformaciones produzcan datos fiables. Cada modelo debería tener al menos estos tests:
- único + not_null en la clave principal: Garantizar la integridad de cada modelo.
- relaciones: Verificar la integridad de las referencias entre modelos.
- valores_aceptados: Asegúrese de que los campos categóricos contengan solo valores válidos.
- freshness en source: Avisa si los datos no se actualizan en los tiempos previstos.
- dbt_utils.expression_is_true: Para restricciones específicas del negocio (ej: revenue >= 0).
3. Versionado y CI/CD para las Pipelines de Datos
# .github/workflows/dbt-ci.yml
# CI/CD para validar los modelos dbt en cada PR
name: dbt CI Pipeline
on:
pull_request:
branches: [main]
paths:
- 'dbt_project/**'
jobs:
dbt-lint-and-test:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Setup Python
uses: actions/setup-python@v4
with:
python-version: '3.11'
- name: Install dbt
run: |
pip install dbt-snowflake==1.8.0
pip install sqlfluff==3.0.0
- name: dbt debug (connection test)
run: dbt debug
env:
DBT_SNOWFLAKE_ACCOUNT: {{ secrets.SNOWFLAKE_ACCOUNT }}
DBT_SNOWFLAKE_USER: {{ secrets.SNOWFLAKE_USER }}
DBT_SNOWFLAKE_PASSWORD: {{ secrets.SNOWFLAKE_PASSWORD }}
DBT_SNOWFLAKE_DATABASE: DBT_CI_DB
DBT_SNOWFLAKE_SCHEMA: CI_{{ github.event.pull_request.number }}
- name: sqlfluff lint (SQL style check)
run: sqlfluff lint models/ --dialect snowflake
- name: dbt compile (syntax check)
run: dbt compile
- name: dbt run (solo modelos modificados)
run: dbt run --select state:modified+
env:
DBT_DEFER_TO_PROD: true
- name: dbt test (tests sobre modelos modificados)
run: dbt test --select state:modified+
- name: dbt docs generate
run: dbt docs generate
- name: Cleanup CI schema
if: always()
run: dbt run-operation drop_schema --args '{"schema": "CI_{{ github.event.pull_request.number }}"}'4. Data Freshness Monitoring
Un tubo ELT redondo que cualquiera sabe que ser redondo es mejor que tener un tubo. El seguimiento proactivo de la actualización de los datos debe ser una parte integral del stack:
Anti-Patrones a Evitar en las Pipelines ELT
- Modelos sin pruebas: A dbt model unless at least a unique + not_null test Es una bomba de tiempo. Más tarde o más tarde producirá datos duplicados o nulos que invalidarán la información.
- Ausencia de schema.yml: Sin documentación, los modelos se vuelven incomprensibles para cualquiera que no los haya escrito, incluido su autor después de 6 meses.
- Full refresh siempre: Recargar siempre la tabla completa en lugar de hacer append/upsert incremental es costoso y frágil para datasets grandes.
- Lógica de negociación en la puerta del escenario principal: El staging debe solo limpiar y estandarizar. Agregaciones y lógica de negocio van en los marts. Mezclar los niveles crea dependencias difíciles de gestionar.
- Ignora la línea de datos: Cuando un informante muestra un número incorrecto, sin línea de documento revise el problema ahora. Con dbt docs, estás conectado a la fuente en unos pocos clics.
- Sin alertas sobre freshness: Si Fivetran deja de sincronizar por la noche y nadie lo monitoriza, los informes de la mañana mostrarán datos de ayer sin ningún aviso visible para los usuarios de negocio.
Recomendaciones para las PYMES
El panorama de los oleoductos dados puede parecer un brumador para una PYME con Recursos limitados y equipos pequeños. La buena noticia es que no es fácil utilizar la batería sola. Un día aquí tienes una progresión progresiva en tres fases:
Ruta de Adopción para PYMES (3 Fases)
| Fase | Timeline | Stack Recomendado | Coste Mensual Indicativo |
|---|---|---|---|
| Fase 1: Fundamentos | Mes 1-3 | Fivetran Free + BigQuery sandbox + dbt Core | €0 - €200 |
| Fase 2: Producción | Mes 4-9 | Fivetran Standard + Snowflake/BigQuery + dbt Core + Airflow managed | €800 - €3.000 |
| Fase 3: escalar | Mes 10+ | Fivetran Enterprise + Snowflake + dbt Cloud + Dagster Cloud | €3.000 - €15.000 |
Fase 1 - Fundamentos: Regístrate en el plan Fivetran gratuito (500.000 MAR/mes) para conectar 2-3 fuentes críticas (ERP, CRM, comercio electrónico). Usa BigQuery en esta versión Sandbox (gratis con 10 GB de almacenamiento + 1 TB de consultas/mes). Instalar dbt Core localmente y tenga en cuenta los primeros 10-15 modelos. El objetivo es conocer a los mecenas y demostrar valor. a la tienda sin inversión inicial.
Fase 2 - Producción: Cuando el concepto haya demostrado su valor, ampliarlo. Fivetran Standard para gestionar más conexiones y actualizar un ordenador en la nube con SLA (producir Snowflake o BigQuery) y también realizar pedidos con la administración de Airflow (Cloud Composer en GCP o MWAA en AWS). Los costes mensuales están contenidos y el impacto Es engañado en el taller.
Fase 3 - Escalar: Cuando el equipo asignado crezca a 3-5 personas, valdrá la pena. acepta dbt Cloud para IDE colaborativo y CI/CD automático, y Dagster Cloud para una orquestación más sofisticada con observabilidad. En este punto la tubería es adecuada. en un activo empresarial estratégico gestionado con estándares de ingeniería profesionales.
Conclusiones y Próximos Pasos
La evolución de ETL a ELT no es simplemente un cambio en el orden de las letras: es un Transformación fundamental en la forma de diseño, implementación y mantenimiento de oleoductos. de datos empresariales. La nube ha provocado que el ordenador sea elástico y barato, dejándolo obsoleto El modelo de transformación está precargado con servidores dedicados.
El stack moderno dbt + Airbyte/Fivetran + warehouse cloud representa el estado del arte de 2025 y es adoptado por miles de empresas, desde startups hasta Fortune 500. Las ventajas concretas son medibles: pipelines versionables como código, tests automáticos que garantizan la calidad de los datos, documentación y lineage generados automáticamente, y costes escalables que crecen con el negocio en lugar de requerir inversiones upfront.
Puntos Clave a Recordar
- ETL no ha muerto: sigue teniendo sentido para datos sensibles que no deben transitar en claro por el cloud o para fuentes legacy on-premise con baja latencia requerida.
- ELT es el nuevo estándar para arquitecturas cloud-first: carga todo en bruto, transforma donde tienes más potencia (el warehouse).
- dbt es la capa de transformación: aporta las mejores prácticas de ingeniería de software (versionado, testing, documentación) al mundo SQL.
- bytes de aire Es la selección de código abierto para equipos técnicos con fuentes personalizadas. o Requisitos de residencia de datos del RGPD.
- Fivetran es la elección managed para quien quiere cero mantenimiento en los conectores hacia fuentes SaaS estándar (Salesforce, HubSpot, Shopify, etc.).
- Para las PYMES: empieza con Fivetran Free + BigQuery + dbt Core para validar el valor antes de invertir en la infraestructura completa.
El próximo artículo de la serie profundiza en ello. investigación de oleoductos: Comparación entre Airflow, Dagster y Prefect. Sí, este es el motor de transformación y Airbyte/Fivetran Conozco el sistema de ingesta, el orquestador es el cerebro que coordina todo: ¿qué hace esto? cuándo, en qué orden y qué hacer cuando algo falla. Un componente crítico que se necesita un tratamiento dedicado.
Ejercicio Práctico: Setup dbt Core en 30 Minutos
Antes de pasar al siguiente artículo, intenta configurar dbt Core sobre un warehouse existente (incluso BigQuery sandbox gratuito):
# 1. Instala dbt con el perfil para tu warehouse
pip install dbt-bigquery # para BigQuery
# o: pip install dbt-snowflake, dbt-redshift, dbt-duckdb
# 2. Crea un nuevo proyecto dbt
dbt init mi_proyecto_dbt
# 3. Configura el perfil (~/.dbt/profiles.yml para BigQuery)
# mi_proyecto_dbt:
# target: dev
# outputs:
# dev:
# type: bigquery
# method: oauth
# project: mi-proyecto-gcp
# dataset: dbt_dev
# threads: 4
# timeout_seconds: 300
# 4. Prueba la conexión
cd mi_proyecto_dbt
dbt debug
# 5. Crea tu primer modelo
cat > models/staging/stg_example.sql << 'EOF'
SELECT
id,
name,
created_at,
UPPER(TRIM(email)) AS email_normalized
FROM {{ source('raw', 'users') }}
WHERE id IS NOT NULL
EOF
# 6. Ejecuta y prueba
dbt run
dbt test
dbt docs generate
dbt docs serve # Abre el lineage visual en http://localhost:8080