¿Sigue limpiando a mano en SQL los esquemas que Fivetran carga de forma automática?
Fivetran carga cada fuente en un esquema predefinido por el proveedor. Las claves de negocio, los campos personalizados y las estructuras históricas deben remodelarse mediante SQL manual que se rompe cuando el conector cambia. La solución no es un script más elaborado, sino un modelo que gobierne la estructura.
La plataforma de automatización de data warehouse en la que confían equipos de datos de todos los sectores
¿Le suena familiar?
- Cada conector genera su propio esquema cerrado, y los joins entre distintas herramientas se escriben a mano, fuente a fuente, en SQL posterior.
- Una actualización en el conector añadió o renombró columnas, o alteró tipos de datos, y rompió los modelos analíticos en producción.
- Los informes de BI están conectados directamente a las tablas de staging del conector porque el equipo no dio abasto para modelar una capa intermedia.
- El linaje de datos se detiene en la tabla del conector; no hay documentación que explique cómo se transformaron las claves hasta llegar al modelo del negocio.
La gran promesa de la ingesta gestionada es la inmediatez: conectar una aplicación y ver aparecer sus tablas organizadas en el almacén de datos. Esta facilidad se apoya en una decisión técnica rígida: el proveedor impone la estructura de las tablas de destino.
Por qué los esquemas rígidos generan fricción
- El esquema responde a la API de la fuente, no a su negocio. La estructura de Salesforce, HubSpot o NetSuite refleja la arquitectura interna de esas aplicaciones, que rara vez coincide con los conceptos con los que trabaja su comité de dirección.
- El SQL posterior se convierte en el verdadero modelo no gobernado. Para conciliar los clientes de tres herramientas diferentes, los analistas terminan escribiendo complejas sentencias SQL llenas de conversiones de tipos, joins y deduplicaciones que nadie documenta.
- Fragilidad ante cambios del conector. Cuando el proveedor actualiza la versión de la API o añade campos por su cuenta, los scripts intermedios pueden fallar de forma imprevista.
- Falta de historización consistente. Muchos conectores solo ofrecen una fotografía del estado actual de los registros, con lo que se pierde la evolución temporal indispensable para auditorías y reporting regulatorio.
Dónde debe definirse la estructura de los datos
Un data warehouse ágil requiere que la organización sea dueña de su propio modelo de información:
- Desacoplamiento total. Las tablas de origen se cargan en staging sin modificar. El modelo del almacén se diseña en torno a conceptos empresariales permanentes (clientes, productos, contratos).
- Armonización en el modelo, no en scripts. La unificación de claves de negocio procedentes de distintos orígenes se resuelve de forma declarativa en hubs y links.
- Gestión automática de la evolución. Si un campo de texto crece o se agrega un atributo, la plataforma ajusta la estructura de la base de datos de forma desatendida.
Qué aporta Datavault Builder
Datavault Builder reemplaza los scripts posteriores manuales por una capa Data Vault 2.0 totalmente automatizada y guiada por modelos:
- Estructura unificada e inmune a cambios. Las modificaciones en los esquemas de los conectores se absorben en los satélites sin romper las relaciones ni las vistas de entrega.
- Unificación natural de identidades. Clientes procedentes de múltiples sistemas se integran en un hub común, conservando la trazabilidad de cada sistema de origen.
- Generación uniforme de cargas. Todas las cargas comparten los mismos estándares de calidad, rendimiento y control de errores.
- Documentación y linaje vivos. Cada transformación se documenta automáticamente a partir del propio modelo, facilitando auditorías de cumplimiento normativo.
Evaluación recomendada
Revise el inventario de scripts y consultas SQL creados exclusivamente para limpiar y remodelar las tablas depositadas por sus conectores automáticos. Si esa lógica manual se ha convertido en un cuello de botella para publicar nuevos datos, la automatización del modelado es la solución.
Véalo funcionando con una de sus fuentes de datos
Reserve una demo gratuita y traiga el conector que más le cuesta, en dinero o en tiempo.
Tres pasos hacia un pipeline que usted controla
-
Separar la ingesta de la integración
Trate las tablas del conector estrictamente como datos brutos en staging. Nunca permita que los informes lean directamente de esquemas de proveedores.
-
Modelar según un estándar de negocio
Mapee visualmente las tablas de staging a entidades Data Vault 2.0 independientes del origen.
-
Automatizar la adaptación a cambios
Permita que la plataforma amplíe columnas y gestione tipos automáticamente sin necesidad de refactorizar scripts de carga.
Cómo Datavault Builder elimina las fricciones en la ingesta
-
La ingesta viene integrada
Cargas batch, delta y CDC desde bases de datos, archivos, APIs REST, fuentes NoSQL y Python, recibiendo flujos como Kafka en micro-batches. La misma plataforma que genera el warehouse, sin una segunda factura.
-
Su propio esquema, no el del proveedor
Las tablas de origen se mapean a un modelo Data Vault 2.0 diseñado por usted. Una nueva columna o una tabla renombrada modifica un mapeo, no una cadena de scripts post-carga.
-
Solo se mueven los deltas
Los hubs, links y satélites cargan lo que ha cambiado. Las recargas completas permanecen en staging en lugar de reprocesarse aguas abajo cada noche.
-
El historial se conserva por diseño
Cada cambio se retiene según llega, por lo que el reporting histórico funciona incluso cuando el origen sobrescribe sus propios registros.
-
Código que nunca tendrá que escribir a mano
La carga, historización y linaje se generan desde el modelo en tiempo real y se ejecutan de forma nativa en Snowflake, Databricks, BigQuery, SQL Server, Fabric, Oracle o PostgreSQL.
-
Una plataforma, hasta nueve herramientas menos
Modelado, ETL, CI/CD, documentación y linaje en un solo lugar. Eso es lo que hace posible pasar del requerimiento a producción en 14,7 minutos.
Reconocido por BARC en The Data Fabric Survey 26
Hable con nuestro experto
Veinte minutos con nuestro Sales Director y una respuesta honesta sobre si esto encaja con su arquitectura.
Matt Collett
Sales Director
Perfecto, elija un horario que le venga bien:
Otros problemas que cubre esta serie
-
¿Problemas de coste y rigidez de esquema en Fivetran? La automatización del modelado es la respuesta
El ELT plug and play es rápido de iniciar y complejo de controlar a escala. Dos factores se degradan con el tiempo: el coste del pipeline y el control sobre la estructura de los datos. Una capa de Data Vault automatizada recupera ambos sin renunciar a los conectores existentes.
-
¿Provocan las Monthly Active Rows (MAR) de Fivetran sustos en su presupuesto mensual?
Fivetran factura por Monthly Active Rows (MAR): filas insertadas o actualizadas en cada mes. Una actualización masiva en el origen, una migración o una recarga histórica multiplican el recuento y disparan la factura. La ingesta directa en el warehouse, unida a un vault que solo mueva deltas, mantiene los costes predecibles.
Preguntas y respuestas
- dbt sustituye la escritura artesanal de consultas sueltas por proyectos versionados en Git, pero el trabajo de diseñar y programar los modelos de staging, la armonización de claves y la historización sigue haciéndose a mano. Datavault Builder genera la capa de integración de forma automatizada a partir de un modelo visual, y las tablas resultantes pueden consumirse directamente o integrarse en proyectos existentes de dbt.
- En una capa manual, las consultas dependientes pueden fallar de inmediato. En Datavault Builder, una nueva columna en el origen se detecta en la interfaz y se incorpora al satélite correspondiente mediante una actualización de mapeo visual, sin alterar las relaciones existentes ni los data marts del negocio.
- La capa base es Data Vault 2.0, que es precisamente lo que le permite absorber los cambios en los orígenes sin romper el historial. Por encima, Datavault Builder genera data marts dimensionales o en 3FN, por lo que el negocio consume un esquema en estrella (star schema) tradicional.