En el panorama de la ingeniería de datos de 2026, la elección de la arquitectura correcta para el movimiento de datos no es solo una cuestión de rendimiento, sino de cumplimiento normativo, especialmente en el sector financiero. Cuando se diseña una pipeline etl vs elt para una institución Fintech, lo que está en juego incluye la precisión decimal, la auditabilidad completa (Lineage) y la capacidad de calcular el riesgo en tiempo casi real. Esta guía técnica explora por qué el enfoque ELT (Extract, Load, Transform) se ha convertido en el estándar de facto frente al tradicional ETL, utilizando un stack moderno compuesto por Google BigQuery, dbt (data build tool) y Apache Airflow.

ETL vs ELT: El Cambio de Paradigma en Fintech

Durante años, el enfoque ETL (Extract, Transform, Load) ha sido el dominante. Los datos se extraían de los sistemas transaccionales (ej. bases de datos de hipotecas), se transformaban en un servidor intermedio (staging area) y finalmente se cargaban en el Data Warehouse. Este enfoque, aunque seguro, presentaba cuellos de botella significativos: la potencia de cálculo del servidor de transformación limitaba la velocidad y cada modificación en la lógica de negocio requería actualizaciones complejas de la pipeline antes incluso de que el dato aterrizase en el warehouse.

Con la llegada de los Cloud Data Warehouses como Google BigQuery y AWS Redshift, el paradigma se ha desplazado hacia el ELT (Extract, Load, Transform). En este modelo:

• Extract: Los datos se extraen de los sistemas fuente (CRM, Core Banking).
• Load: Los datos se cargan inmediatamente en el Data Warehouse en formato bruto (Raw Data).
• Transform: Las transformaciones ocurren directamente dentro del Warehouse aprovechando su potencia de cálculo masiva (MPP).

Para el sector Fintech, el ELT ofrece una ventaja crucial: la auditabilidad. Dado que los datos brutos están siempre disponibles en el Warehouse, es posible reconstruir la historia de cualquier transacción o recalcular los KPI retroactivamente sin tener que volver a ejecutar la extracción.

Arquitectura de la Solución: El Stack Moderno

Para construir una pipeline robusta para la gestión de hipotecas, utilizaremos el siguiente stack tecnológico, considerado best-practice en 2026:

• Storage & Compute: Google BigQuery (para la escalabilidad serverless).
• Transformation: dbt (para gestionar las transformaciones SQL, la documentación y el testing).
• Orchestration: Apache Airflow (para programar y monitorizar los jobs).

Fase 1: Ingesta y Orquestación con Apache Airflow

El primer paso es llevar los datos al Data Lake/Warehouse. En un contexto Fintech, la inmediatez es fundamental. Utilizamos Apache Airflow para orquestar la extracción desde las bases de datos operacionales (ej. PostgreSQL) hacia BigQuery.

Ejemplo de DAG Airflow para la Ingesta

El siguiente fragmento conceptual muestra cómo configurar una tarea para cargar los datos de las hipotecas en modo “append-only” para mantener el historial completo.

from airflow import DAG
from airflow.providers.google.cloud.transfers.postgres_to_gcs import PostgresToGCSOperator
from airflow.providers.google.cloud.transfers.gcs_to_bigquery import GCSToBigQueryOperator
from airflow.utils.dates import days_ago

with DAG('fintech_mortgage_ingestion', start_date=days_ago(1), schedule_interval='@hourly') as dag:

    extract_mortgages = PostgresToGCSOperator(
        task_id='extract_mortgages_raw',
        postgres_conn_id='core_banking_db',
        sql='SELECT * FROM mortgages WHERE updated_at > {{ prev_execution_date }}',
        bucket='fintech-datalake-raw',
        filename='mortgages/{{ ds }}/mortgages.json',
    )

    load_to_bq = GCSToBigQueryOperator(
        task_id='load_mortgages_bq',
        bucket='fintech-datalake-raw',
        source_objects=['mortgages/{{ ds }}/mortgages.json'],
        destination_project_dataset_table='fintech_warehouse.raw_mortgages',
        write_disposition='WRITE_APPEND', # Crucial para el historial
        source_format='NEWLINE_DELIMITED_JSON',
    )

    extract_mortgages >> load_to_bq

Fase 2: Transformación y Modelado con dbt

Una vez que los datos están en BigQuery, entra en juego dbt. A diferencia de los procedimientos almacenados tradicionales, dbt permite tratar las transformaciones de datos como código de software (software engineering best practices), incluyendo versionado (Git), testing y CI/CD.

Estructura del Proyecto dbt

Organizamos los modelos en tres capas lógicas:

1. Staging (src): Limpieza ligera, renombrado de columnas, casting de tipos de datos.
2. Intermediate (int): Lógica de negocio compleja, joins entre tablas.
3. Marts (fct/dim): Tablas finales listas para BI y reporting regulatorio.

Cálculo de KPI Complejos: Loan-to-Value (LTV) en SQL

En el sector hipotecario, el LTV es un indicador de riesgo crítico. Así es como se ve un modelo dbt (archivo .sql) que calcula el LTV actualizado y clasifica el riesgo, uniendo datos maestros y valoraciones inmobiliarias.

-- models/marts/risk/fct_mortgage_risk.sql

WITH mortgages AS (
    SELECT * FROM {{ ref('stg_core_mortgages') }}
),

appraisals AS (
    -- Tomamos la última valoración disponible para el inmueble
    SELECT 
        property_id,
        appraisal_amount,
        appraisal_date,
        ROW_NUMBER() OVER (PARTITION BY property_id ORDER BY appraisal_date DESC) as rn
    FROM {{ ref('stg_external_appraisals') }}
)

SELECT
    m.mortgage_id,
    m.customer_id,
    m.outstanding_balance,
    a.appraisal_amount,
    -- Cálculo LTV: (Saldo Pendiente / Valor Inmueble) * 100
    ROUND((m.outstanding_balance / NULLIF(a.appraisal_amount, 0)) * 100, 2) as loan_to_value_ratio,
    CASE
        WHEN (m.outstanding_balance / NULLIF(a.appraisal_amount, 0)) > 0.80 THEN 'HIGH_RISK'
        WHEN (m.outstanding_balance / NULLIF(a.appraisal_amount, 0)) BETWEEN 0.50 AND 0.80 THEN 'MEDIUM_RISK'
        ELSE 'LOW_RISK'
    END as risk_category,
    CURRENT_TIMESTAMP() as calculated_at
FROM mortgages m
LEFT JOIN appraisals a ON m.property_id = a.property_id AND a.rn = 1
WHERE m.status = 'ACTIVE'

Data Quality y Auditabilidad: El Corazón del Fintech

En el ámbito financiero, un dato erróneo puede llevar a sanciones. El enfoque ELT con dbt destaca en la Data Quality gracias a los tests integrados.

Implementación de Tests Automáticos

En el archivo schema.yml de dbt, definimos las aserciones que los datos deben cumplir. Si un test falla, la pipeline se detiene o envía una alerta, previniendo la propagación de datos corruptos.

version: 2

models:
  - name: fct_mortgage_risk
    description: "Tabla de hechos para el riesgo de hipotecas"
    columns:
      - name: mortgage_id
        tests:
          - unique
          - not_null
      - name: loan_to_value_ratio
        tests:
          - not_null
          # Custom test: LTV no puede ser negativo o absurdamente alto (>200%)
          - dbt_utils.expression_is_true:
              expression: ">= 0 AND <= 200"

Data Lineage

dbt genera automáticamente un grafo de dependencias (DAG). Para un auditor, esto significa poder visualizar gráficamente cómo se ha derivado el dato “Riesgo Alto” de un cliente: desde la tabla raw, a través de las transformaciones intermedias, hasta el informe final. Este nivel de transparencia es a menudo obligatorio en las inspecciones bancarias.

Gestión de la Infraestructura y Versionado

A diferencia de las pipelines ETL legacy basadas en GUI (interfaces gráficas drag-and-drop), el enfoque moderno es Code-First.

• Version Control (Git): Cada modificación en la lógica de cálculo del LTV es un commit en Git. Podemos saber quién cambió la fórmula, cuándo y por qué (mediante la Pull Request).
• Entornos Aislados: Gracias a dbt, cada desarrollador puede ejecutar la pipeline en un entorno sandbox (ej. dbt run --target dev) sobre un subconjunto de datos de BigQuery, sin impactar en producción.

Troubleshooting Común

1. Schema Drift (Cambio del esquema fuente)

Problema: El Core Banking añade una columna a la tabla de hipotecas y la pipeline se rompe.
Solución: En BigQuery, utilizar la opción schema_update_options=['ALLOW_FIELD_ADDITION'] durante la carga. En dbt, utilizar paquetes como dbt_utils.star para seleccionar dinámicamente las columnas o implementar tests de esquema rigurosos que avisen del cambio sin romper el flujo crítico.

2. Latencia de los Datos

Problema: Los datos de las valoraciones inmobiliarias llegan con retraso respecto a los saldos de las hipotecas.
Solución: Implementar la lógica de “Late Arriving Facts”. Utilizar las Window Functions de SQL (como se vio en el ejemplo anterior con ROW_NUMBER) para tomar siempre el último dato válido disponible en el momento de la ejecución, o modelar tablas snapshot para historificar el estado exacto a fin de mes.

Conclusiones

La transición de una pipeline etl vs elt en el sector Fintech no es una moda, sino una necesidad operativa. El uso de BigQuery para el almacenamiento a bajo coste y la alta capacidad computacional, combinado con dbt para la gobernanza de las transformaciones, permite a las empresas financieras tener datos fiables, auditables y oportunos. Implementar esta arquitectura requiere competencias de ingeniería de software aplicadas a los datos, pero el retorno de la inversión en términos de compliance y agilidad de negocio es incalculable.

Preguntas frecuentes