Replicar SAP a BigQuery se resuelve hoy con un patrón maduro: Fivetran Managed Data Lake Service (MDLS) lee los cambios desde SAP por log-based CDC, los aterriza en un bucket GCS como Parquet, y BigLake los expone como tablas BigQuery vivas. Sin impacto sobre el ERP, sin reescritura completa cada noche, con latencia de minutos y costo predecible.
El problema de mover SAP
SAP es un sistema rico y caro de leer: miles de tablas, esquema propietario, claves complejas, joins entre header e items, conversión de pools y clusters. Cualquier extracción mal hecha impacta el ECC, rompe SLAs y genera quejas del equipo de Basis. Por eso la migración a BigQuery se hace casi siempre vía un layer intermedio que no toca el origen en caliente.
Por qué Fivetran MDLS para este caso
Fivetran HVR (lo que ahora se ofrece como MDLS dentro de Fivetran) hace log-based CDC sobre SAP ECC y S/4HANA, soporta extracción de tablas pool/cluster, maneja delta keys y reinicios, y aterriza en GCS en formato Parquet particionado. La diferencia con Fivetran SaaS clásico es que MDLS está pensado para volúmenes SAP y tiene los conectores nativos.
La arquitectura de referencia
- Fuente: SAP ECC o S/4HANA (RISE o on-prem).
- Captura: Fivetran HVR / MDLS con CDC log-based sobre Oracle/HANA detrás de SAP.
- Aterrizaje: bucket GCS con Parquet particionado por fecha.
- Exposición: BigLake apuntando al bucket, tablas externas en BigQuery.
- Consumo: dbt para modelado, Looker / Tableau para BI, Vertex AI y Merlina para IA.
Caso real: Caja Los Andes con Evolve
Caja Los Andes corría SAP en modalidad RISE y necesitaba habilitar analítica avanzada sin esperar a que el roadmap de SAP lo permitiera nativamente. Evolve diseñó e implementó la replicación con Fivetran MDLS hacia GCS, exposición vía BigLake en BigQuery, y modelado en dbt sobre una arquitectura Iceberg. El resultado: capa analítica viva, sin impacto en SAP, lista para alimentar agentes de IA y herramientas de BI.
Lo que típicamente se subestima
Tres cosas suelen romper estos proyectos cuando se hacen sin método. Primero, los permisos en SAP: la cuenta que lee logs necesita roles muy específicos y suele tardar más en habilitarse que el propio pipeline. Segundo, el modelado: replicar tablas crudas no sirve, hay que modelar con dbt en capas (raw, staging, marts). Tercero, gobierno: catalogar, documentar y aplicar políticas de calidad desde el día uno.
Costo y tiempo realistas
Para un alcance de unas 80 tablas SAP críticas (FI, CO, MM, SD), el setup típico es de 6 a 10 semanas si los permisos vienen rápido. El costo running depende del volumen de cambios; con CDC log-based suele ser una fracción del costo de soluciones batch o de scripts custom mantenidos por equipos internos.