El Problema de la Dispersión de Datos que Toda Empresa en Crecimiento Enfrenta

Si has trabajado en una empresa que escaló rápidamente, conoces el dolor. Los datos viven en todas partes: bases de datos de producción, clústeres ClickHouse, streams Kafka, object storage y un montón de pipelines. Cada sistema tiene sus propias credenciales, lenguaje de consulta y política de retención. Hacer una pregunta simple como '¿Cuántos dominios que se registraron hoy están en el Top 100 por tráfico?' requiere conocimiento tribal: saber qué sistema consultar, qué joins hacer y si los datos están frescos o muestreados.

Cloudflare enfrentó exactamente este desafío procesando más de mil millones de eventos por segundo en 330+ ciudades. Su solución no fue otra herramienta de BI — fue repensar completamente su infraestructura de datos. Construyeron dos cosas: Town Lake, una interfaz SQL unificada para todo lo que Cloudflare sabe, y Skipper, un agente de IA que permite a cualquiera hacer preguntas en inglés simple y obtener respuestas auditables en segundos.

Este es un análisis profundo de cómo construyeron ambos, las decisiones arquitectónicas que importan y las lecciones difíciles que aplican a cualquier esfuerzo serio de plataforma de datos.

Analyst querying unified data platform with SQL interface across multiple data sources System Abstract Visual

Town Lake: La Arquitectura Data Lakehouse

Town Lake está construido sobre el patrón data lakehouse: un motor de consulta leyendo de object storage, con una capa de metadatos que hace que el almacenamiento se comporte como una base de datos. Los componentes principales son:

Motor de Consulta: Apache Trino

Trino permite que una sola consulta SQL haga join entre una tabla Postgres, una tabla ClickHouse y una tabla Iceberg en R2 sin materializar resultados intermedios. Una consulta como 'top 100 clientes pagantes por solicitudes Workers esta semana' compila a un plan que empuja filtros a ClickHouse, hace join con dimensión de cuentas en Postgres y rankea contra rollups de facturación en R2 — todo de una vez.

Almacenamiento: R2 + Apache Iceberg

Datos fríos y templados viven en R2 vía su servicio gestionado Iceberg. Iceberg proporciona evolución de esquema, time travel y evolución de particiones. El insight clave es compactación en capas: datos por minuto se convierten en por hora, luego por día, conforme envejecen. Los costos de almacenamiento disminuyen con la edad de los datos manteniendo la capacidad de consulta.

Metadatos: DataHub

Cada tabla, columna, dueño y linaje vive en DataHub. Cuando Skipper necesita entender dim.accounts, obtiene el esquema, descripciones de columnas, equipo dueño y dependencias upstream/downstream.

Control de Acceso: Lifeguard

Lifeguard almacena reglas de acceso en D1, obtiene dinámicamente membresías de grupos y renderiza una política JSON combinada que Trino lee vía HTTP. La decisión crítica: gobernanza cerrada por defecto. Las tablas son inaccesibles hasta que sean revisadas.

-- Ejemplo: Consultando Town Lake con redacción automática de PII
-- Las columnas PII se redactan por defecto a menos que se active flag de sesión
SET SESSION townlake.redact_pii = TRUE;

SELECT account_id, email, usage_amount
FROM townlake.fct.billings_allocated
WHERE date >= CURRENT_DATE - INTERVAL '30' DAY
ORDER BY usage_amount DESC
LIMIT 10;
-- la columna email será redactada (ej.: '***@***.com')

Detección de PII: Skimmer

Skimmer continuamente muestrea filas de cada columna y usa Workers AI para clasificar PII en dos pasadas. Primero, un clasificador rápido por columna; luego, si algo es señalado, una segunda pasada agéntica con contexto completo de la tabla. Hallazgos fluyen a DataHub y a la allowlist de Lifeguard para revisión humana.

Cloud architecture diagram showing data lakehouse with query engine and metadata catalog IT Technology Image

Skipper: El Agente de Datos con IA

Skipper es un agente de IA conversacional que va de pregunta en lenguaje natural a respuesta validada, fundamentada en datos reales, código y conocimiento institucional. La arquitectura usa Workers, Workers AI, Durable Objects y D1.

Cinco Capas de Contexto (El Secreto)

El mayor desafío era prevenir joins alucinados y respuestas incorrectas. La solución es contexto en capas:

  1. Metadatos de esquema y uso de DataHub
  2. Anotaciones humanas como 'Una fila por account_id'
  3. Conocimiento derivado de código: el SQL real que produce una tabla (ej.: alloc_amount = billed_amount / 12 for annual)
  4. Modelos de datos curados: documentos escritos por humanos describiendo cómo pensar sobre facturación, clientes, etc.
  5. Introspección en runtime: DESCRIBE table, SELECT DISTINCT col LIMIT 20 como red de seguridad

Code Mode: Repensando Herramientas MCP

En lugar de exponer 30 herramientas individuales, Skipper expone dos: search y execute. El modelo escribe JavaScript que llama a todo el conjunto programáticamente:

// Ejemplo: Análisis de datos multi-paso en una sola ida y vuelta
const datasets = await skipper.search_datasets({ query: "billing product revenue" });
const queryId = await skipper.start_query({ 
  sql: "SELECT region, SUM(usage_amount) FROM fct.billings_allocated GROUP BY region" 
});
const results = await skipper.fetch_results({ queryId, mode: "inject" });
return skipper.create_chart({ chartType: "bar", data: results.rows });

Este JavaScript corre en un isolate Dynamic Worker en sandbox. Workflows complejos ocurren en una sola ida y vuelta, son más rápidos, más baratos y auditables como código.

Developer chatting with AI data agent to generate SQL queries and visualize results Development Concept Image

Lecciones Clave y Limitaciones

Lo Que Funcionó

  • Menos prompting es más: Prompts de sistema prescriptivos empeoraron la calidad. Guía de alto nivel permite mejor razonamiento del modelo.
  • Superposición de herramientas es veneno: Consolida herramientas; cada herramienta debe tener una sola razón de existir.
  • Código, no metadatos, captura significado: Las mayores ganancias de precisión vinieron de ingerir el SQL real que produce tablas.
  • La memoria importa más de lo esperado: Una capa de memoria para correcciones recurrentes hace al agente monótonamente mejor.

Limitaciones y Consideraciones

  • La infraestructura aburrida es la parte difícil: Control de acceso por fila, allowlisting cerrado por defecto y logging de auditoría son lo que hacen segura una plataforma de datos. No lo saltes.
  • Contexto en runtime es caro: Consultas de introspección en vivo cuestan dinero y tiempo; úsalas con moderación.
  • Modelo de seguridad = modelo de datos: Todo lo que Skipper hace corre como el usuario que llama. Sin escalamiento de privilegios, punto.

Próximos Pasos para tu Aprendizaje

  1. Empieza con un lakehouse pequeño: Monta Trino + Iceberg en object storage. Familiarízate con el motor de consulta.
  2. Implementa gobernanza cerrada por defecto: Construye detección automatizada de PII y allowlisting de tablas desde el día uno.
  3. Capas de contexto para tu agente de IA: Empieza con metadatos de esquema, luego anotaciones humanas, luego conocimiento derivado de código.
  4. Estudia el patrón MCP: El enfoque Code Mode es una forma novedosa de reducir idas y vueltas en workflows agénticos.

Para más sobre infraestructura de datos a gran escala, mira esta guía sobre migración de sistemas de ingesta a escala petabyte. Y si estás construyendo interfaces de agentes de IA, este análisis del directorio de adaptadores Chat SDK de Vercel ofrece patrones útiles.

Este contenido fue redactado con la asistencia de herramientas de IA, basándose en fuentes confiables, y fue revisado por nuestro equipo editorial antes de su publicación. No reemplaza el asesoramiento de un profesional especializado.