Flujo de los datos

Esta página sigue el recorrido de un dato desde el sistema de origen hasta una respuesta. Hay dos momentos: la configuración inicial de una fuente y las actualizaciones posteriores.

Vista de punta a punta

    flowchart LR
    A[Sistema de origen] -->|1. Extracción| B[Datos crudos]
    B -->|2. Perfilado| C[Hallazgos de calidad]
    B -->|3. Limpieza con IA<br/>validada| D[Datos procesados]
    D -->|4. SQL definido por<br/>el usuario o la IA| E[Tablas de resultados]
    E --> F[Dashboards]
    D & E -->|5. Consulta| G[App, asistente, MCP,<br/>exportación CSV]

1. Conexión

Un administrador del workspace crea una fuente. Para eso elige el tipo de sistema, carga las credenciales y el método de conexión (red privada IPsec, túnel SSH o acceso por Internet con lista blanca de IP; ver Conectividad).

Teramot prueba la conexión y descubre las tablas y vistas disponibles. El usuario elige cuáles incorporar y cómo actualizarlas.

Tip

Credenciales de solo lectura

Teramot solo lee de los sistemas de origen y nunca escribe en ellos. Se recomienda crear un usuario de servicio con permisos de lectura limitados a las tablas que se van a incorporar.

2. Configuración inicial de una fuente

Al publicar una fuente, el orquestador ejecuta esta secuencia:

    sequenceDiagram
    participant O as Orquestador
    participant X as Extractores
    participant L as Data lake
    participant IA as Agentes de IA
    participant M as Motor SQL

    O->>X: Extraer tablas seleccionadas (en paralelo)
    X->>L: Escribir datos crudos (Iceberg)
    O->>M: Perfilar cada tabla
    M-->>O: Estadísticas y hallazgos de calidad
    O->>IA: Proponer limpieza por tabla
    IA->>M: Probar la consulta propuesta
    M-->>IA: Resultado de la validación
    O->>IA: Alinear tipos entre tablas relacionadas
    O->>M: Construir datos procesados
    O->>M: Construir tablas de resultados (si existen)
    O->>IA: Documentar tablas y columnas

Extracción. Cada tabla se lee y se escribe como tabla cruda. Las tablas se procesan en paralelo, salvo en las APIs con límite de tasa.
Perfilado. Se calculan estadísticas por columna y se detectan problemas de calidad: valores atípicos, duplicados, mayúsculas inconsistentes, claves candidatas.
Limpieza. Un agente de IA propone una consulta SQL de limpieza para cada tabla. La consulta se ejecuta y se valida antes de aceptarla (ver Transformaciones).
Reconciliación. Se alinean los tipos de las columnas que sirven para cruzar tablas (por ejemplo, un código de cliente que en una tabla es texto y en otra es número).
Construcción. Se materializan los datos procesados y después las tablas de resultados que dependen de ellos.
Documentación. Se generan descripciones de tablas y columnas para el catálogo del proyecto.

3. Actualizaciones

Una actualización puede dispararse de varias formas:

Programada, según la frecuencia configurada en el proyecto.
Manual, desde la aplicación: de todo el proyecto o de tablas puntuales.
Por API o MCP, por ejemplo desde un asistente de IA con los permisos necesarios.

En cada actualización:

Se extraen los datos nuevos: la tabla completa o solo los cambios (ver Actualización e incremental).
Si cambió el esquema de una tabla (columnas nuevas, eliminadas o con otro tipo), se vuelve a revisar su limpieza. Si no cambió, se reutiliza la consulta ya validada.
Se reconstruyen los datos procesados.
Se recalculan las tablas de resultados que dependen de ellos, incluidas las que cruzan varias fuentes.

4. Consumo

Con los datos procesados y las tablas de resultados listos, los usuarios pueden:

Explorarlos y consultarlos con SQL en la aplicación web.
Preguntar en lenguaje natural al asistente de la aplicación.
Consultarlos desde su propio asistente de IA vía MCP.
Verlos en dashboards.
Exportar tablas de resultados como CSV.

Ver Formas de consumo.

Estado y errores visibles para el cliente

Cada proyecto muestra:

El historial de actualizaciones: tipo, estado y tablas afectadas.
El estado de cada fuente y la hora de la última sincronización.
Los errores clasificados: permisos, credenciales inválidas, conectividad, configuración o error interno. Cada uno trae un mensaje legible y acciones sugeridas.

Si una tabla falla varias veces seguidas, deja de reintentarse automáticamente hasta que se revise su configuración. Así se evita que un error persistente consuma recursos en cada ejecución.

Arquitectura de la plataforma Transformaciones