● Bitácora de a bordo · Tablero de control · Semantic Data Layer
El Data Lake Hundido
Cómo Campelsoft reflotó —en 6 días— un Data Lake de AWS con 976 tablas y lo conectó con los usuarios y tableros que llevaban 7 meses esperando en silencio: una capa semántica consultable por API, para humanos y para IA.
SectorLogística (LATAM)
IslaIsla de los Datos · Semantic Layer
BitácoraAnonimizada · sin datos del cliente
CapitánAbraham Juárez · Junio 2026
Nota de anonimización
Caso de estudio divulgativo. Se removieron o sustituyeron nombre del cliente, dominios, nombres reales
de bases y tablas, y datos de negocio. Los ejemplos técnicos son ilustrativos
(modelos genéricos como flota.unidades, métricas como mantenimiento.costo_total).
01El reto: aguas profundas, ni una respuesta
El mar rojo que originó la travesía.
Un grupo de logística había hecho la inversión correcta: centralizar su data en un Data Lake sobre AWS — 20 bases y 976 tablas en S3 (Parquet), catalogadas en Glue y consultables vía Athena. La data estaba completa y al día. Pero solo podía sondearla quien supiera SQL y además supiera cuál de las 976 tablas usar, cómo cruzarlas y qué arrecifes evitar. Es decir: casi nadie.
Desde noviembre buscaban cómo conectar esa data con los usuarios y los tableros. Tenían herramientas BI de licencia con conexión al lake, pero este año decidieron eliminarlas y apostar por un modelo de consumo con IA. La travesía se quedó a medias: lograron un dash que construía paneles e indicadores, pero nadie aterrizaba el modelo de consulta — así que la data se le resubía a mano, en Exceles. Un mar de 976 tablas, alimentando tableros por copy-paste.
↓ El Reto
El Data Lake resolvió el almacenamiento, no el acceso. Entre 976 tablas y una pregunta de negocio ("¿cuántas unidades activas tengo por territorio?") falta una traducción completa: qué tabla, qué joins, qué filtros, y cómo se define cada métrica. Sin esa carta de navegación, una IA no puede consultar el lake: o inventa SQL sobre tablas que no entiende, o alguien le resube la data en Excel. Hacía falta una capa semántica: definir la traducción una sola vez, y que todo lo demás —tableros, IA, partners— la consuma por API.
02La aventura: qué reflota el tablero
Las capacidades que entrega el tablero de control.
Habla negocio, no SQL
El consumidor pide flota.unidades por flota.territorio. Nunca escribe SQL ni toca una tabla.
Una sola definición de la verdad
Cada métrica vive una vez en un modelo YAML versionado. Los conteos inflados por snapshots diarios se resuelven de raíz.
Compila, no improvisa
La consulta semántica se compila a SQL parametrizado: identificadores solo del YAML validado, valores como bind params. Anti-inyección por diseño.
Para humanos y para IA
La IA lee el catálogo de métricas y arma un JSON — no inventa SQL ni alucina nombres de columnas.
Un hub, dos audiencias
Front interno con JWT; partners externos con API key, alcance por modelo y límite de consultas.
Rápido y barato
Cache Redis por consulta compilada: menos latencia y menos costo de Athena, que cobra por datos escaneados.
976
Tablas en el lake (20 bases)
150
Modelos semánticos definidos
7 meses
A la deriva, sin conexión
6 días
De zarpar a backend + tablero a puerto
03La ruta: del archivo en el mar a la decisión
El recorrido, del archivo en el lake a la decisión de negocio.
Data Lake
S3 · Parquet, zonas crudo y curado — intacto
→
Catálogo
Glue + Athena: 20 bases, 976 tablas inventariadas
→
Modelo semántico
Métricas, dimensiones y joins en YAML — una sola vez
→
Compilador
Consulta semántica → SQL de Athena, parametrizado
→
API · FastAPI
Permisos, cache Redis, rate limiting
→
Tablero KPI
KPIs en vivo desde 2 fuentes del lake — sin Exceles
+ La Aventura
Probaron BI de licencia conectado al lake, y luego un dash con IA: ninguno llegó a puerto. Conectar directo al lake obliga a cada consumidor a saber cuál de las 976 tablas usar, cómo cruzarlas y cómo esquivar los snapshots duplicados — y una IA sin carta de navegación termina alimentada con Exceles resubidos a mano. El tablero de control invierte el rumbo: la lógica vive una sola vez en la capa semántica y los tableros (y la IA) se vuelven clientes ligeros de una API estable. Lo que llevaba 7 meses a la deriva quedó navegando en 6 días.
04El navío: stack tecnológico
Construido sobre el Data Lake existente del cliente — sin migrar ni duplicar la data.
Data Lake (existente)
AWS S3 · ParquetGlue Data CatalogGlue CrawlerAthena · Trino SQL
Python · FastAPIPydanticJWT (compartido con el front)API keys · scopes
Performance & seguridad
Redis · cache + rate limitBind params (anti-inyección)Keys con hash, nunca en claro
Tablero KPI
Next.js · ReactChart.js · Recharts2 fuentes del lake, en vivo
Capa de IA
Catálogo de métricas para LLMsDashBuilder con IAClaude · OpenAI
05Cómo está aparejada la aventura
Tres cubiertas: el mar del cliente, el hub semántico de Campelsoft, y el consumo.
1 · Data Lake (infraestructura del cliente)
Sistemas origen
20 bases de los sistemas del negocio
S3 · zonas crudo y curado
976 tablas en Parquet — la data no se mueve ni se duplica
Glue + Athena
Catálogo de esquemas y motor de consulta sobre el lake
▼
2 · Tablero de control — Semantic Layer Hub (Campelsoft)
Registro de modelos
150 modelos YAML: métricas, dimensiones, joins — recargables en caliente
Compilador semántico
De pregunta de negocio a SQL parametrizado de Athena
API consultable
Consulta semántica, dry-run y catálogo de métricas
Permisos
JWT interno · API keys externas con alcance por modelo
Cache + rate limit
Redis: respuestas rápidas y costo de Athena bajo control
Ingesta
Crawler de Glue y carga de Excel/CSV desde el panel
▼
3 · Consumo (usuarios del negocio)
Tablero KPI
KPIs ejecutivos en vivo desde 2 fuentes del lake — listo para crecer por perspectiva
Partners externos
Consumen por API key solo los modelos de su alcance
Agentes de IA
Eligen métricas del catálogo y arman la consulta — sin inventar SQL
06El botín: resultados
A la deriva
Con el tablero de control
976 tablas accesibles solo para quien escribiera SQL
Métricas de negocio por nombre, consultables por API
Conteos distintos según quién consultara (snapshots diarios)
Una definición por métrica, en YAML versionado — todos ven el mismo número
Cada tablero reinventaba la lógica y se rompía con cambios del lake
Los tableros son clientes ligeros de una API estable
Acceso a datos vía SQL crudo, expuesto a inyección
SQL compilado y parametrizado; identificadores solo del modelo validado
El dash con IA construía paneles, pero la data se resubía a mano en Exceles
KPIs conectados en vivo al lake — cero copias manuales
7 meses buscando la conexión: BI de licencia, luego IA sin modelo de consulta
Backend + tablero operando en 6 días
Data invisible para herramientas de IA
La IA consulta el catálogo y arma JSON — data gobernada, sin alucinar columnas
Cartas de navegación para cualquier organización
Un data lake no es un proyecto terminado. Almacenar resuelve la mitad del problema; el valor aparece cuando el negocio puede preguntar y obtener respuesta.
No conectes tableros directo al lake. Cada conexión directa duplica lógica de negocio y se rompe con cada cambio. La lógica va en una capa, una sola vez.
La definición del KPI es el activo. Si "unidades de flota" se calcula distinto en cada tablero —y los snapshots diarios duplican vehículos—, no tienes data: tienes discusiones.
La capa semántica es el prerequisito de la IA. Un agente de IA sin capa semántica inventa SQL sobre tus tablas — o te condena a resubirle la data en Excel. Con ella, elige métricas de un catálogo gobernado, con permisos y contexto de negocio.
¿Tu data lake responde preguntas, o solo guarda náufragos?
Campelsoft construye el tablero de control sobre tu data lake existente — sin migrar ni duplicar tu data: una capa semántica consultable por API que conecta tu inversión en datos con tus usuarios, tus tableros, tus partners y tus agentes de IA. Te mostramos, sobre tu propio mar, qué tan lejos estás de la primera respuesta.
Juárez, A. (2026). El Data Lake Hundido: una capa semántica sobre un data lake de 976 tablas. Campelsoft — La Gran Ruta. https://campelsoft.com/casos/cortex.html
