El problema fundamental que resuelve Cloudflare es la fragmentación y la inaccesibilidad de los datos a escala de hyperscaler, un desafío común en organizaciones con crecimiento acelerado. La proliferación de sistemas de almacenamiento y procesamiento de datos heterogéneos (Postgres, ClickHouse, BigQuery, Kafka, R2) conduce a silos de información, inconsistencias, datos muestreados inadecuados para casos de uso críticos como la facturación, y una alta barrera de entrada para los usuarios que necesitan extraer insights.
La solución propuesta, Town Lake y Skipper, busca democratizar el acceso a los datos, transformando la infraestructura de datos de una función de 'back-office' a un componente crítico. Esto se logra mediante la creación de una interfaz unificada (SQL a través de Trino) sobre un data lakehouse (Iceberg en R2) y una capa de inteligencia artificial (Skipper) que traduce el lenguaje natural en consultas ejecutables y auditables. La relevancia actual radica en la creciente demanda de análisis de datos en tiempo real y la necesidad de empoderar a roles no técnicos para interactuar directamente con grandes volúmenes de información, minimizando la dependencia de equipos de ingeniería de datos especializados.
Arquitectura del Sistema
Town Lake se construye sobre una arquitectura de data lakehouse. El componente central es Apache Trino, que actúa como motor de consultas federado, permitiendo uniones y consultas sobre datos distribuidos en diferentes sistemas (Postgres, ClickHouse, Iceberg en R2) sin materialización intermedia. Los datos fríos y cálidos residen en R2, gestionados como tablas Apache Iceberg a través del R2 Data Catalog, lo que proporciona características como evolución de esquema, viaje en el tiempo y compactación de datos por antigüedad. DataHub es el catálogo de metadatos centralizado, almacenando información sobre tablas, columnas, propietarios, linaje y términos de glosario.
La ingesta de datos desde sistemas operacionales se realiza mediante un orquestador de Kubernetes que ejecuta trabajos de extracción, transformación a Parquet y carga en R2 como tablas Iceberg, soportando modos de reemplazo completo o append incremental. La seguridad y gobernanza son gestionadas por Lifeguard, un servicio de control de acceso que almacena reglas en D1 y genera políticas JSON para Trino. Skimmer es un escáner de detección de PII basado en Workers AI que clasifica columnas y alimenta DataHub y Lifeguard. Transformer, el motor ELT, utiliza Workflows para ejecutar DAGs de transformaciones SQL en Trino, con estado gestionado por Durable Objects y definiciones en R2. Skipper, el agente de IA, se construye sobre Workers AI, Durable Objects, D1, R2 y Workflows, utilizando DataHub para el descubrimiento de esquemas y Lifeguard para la gestión de permisos. Emplea un enfoque de 'Code Mode' donde el LLM genera snippets de JavaScript para orquestar llamadas a herramientas internas en un solo viaje de ida y vuelta.
Flujo de Consulta de Datos con Skipper y Town Lake
- 1 Usuario Formula pregunta en lenguaje natural (ej. 'Top 10 clientes por costo R2')
- 2 Skipper (Workers AI) Recibe pregunta, utiliza contexto multi-capa (DataHub, código, anotaciones)
- 3 Skipper (Code Mode) Genera snippet JavaScript para orquestar herramientas (search_datasets, start...
- 4 Skipper (Herramientas) Busca tablas relevantes en DataHub, obtiene esquemas y linaje
- 5 Skipper (Herramientas) Escribe SQL, verifica permisos con Lifeguard
- 6 Trino Ejecuta consulta SQL federada sobre Postgres, ClickHouse, Iceberg en R2
- 7 Skipper Recupera resultados, los presenta como tabla/gráfico
- 8 Usuario Recibe respuesta, puede refinar la pregunta (contexto persistente)
Flujo de Gobernanza de Datos 'Default-Closed'
- 1 Nueva Tabla/DB Se conecta a Trino o se crea
- 2 Skimmer (Workers AI) Escanea filas de columnas, clasifica PII en dos pases
- 3 DataHub Registra hallazgos de PII y estado 'pending' para la tabla/columnas
- 4 Lifeguard Recibe información de acceso y PII, bloquea acceso por defecto
- 5 Usuario Intenta consultar tabla sin acceso, recibe mensaje 'necesita revisión'
- 6 Revisor Humano Aprueba, anula o deniega acceso a tabla/columnas específicas en DataHub
- 7 Lifeguard Actualiza políticas de acceso, permite consultas aprobadas
| Capa | Tecnología | Justificación |
|---|---|---|
| compute | Apache Trino | Motor de consultas SQL federado para unir datos de diversas fuentes (Postgres, ClickHouse, Iceberg en R2) sin materialización intermedia. |
| storage | Cloudflare R2 | Almacenamiento de objetos para datos fríos y cálidos, sirviendo como base para Apache Iceberg, ofreciendo bajo costo y compatibilidad S3. |
| storage | Apache Iceberg | Formato de tabla para data lakes sobre R2, proporcionando evolución de esquema, viaje en el tiempo, particionamiento y compactación de datos. |
| orchestration | Cloudflare Workers | Plataforma de computación serverless para el agente Skipper, Skimmer (detección de PII) y como base para el motor ELT Transformer. |
| orchestration | Cloudflare Workflows | Motor de orquestación para el ELT Transformer, gestionando DAGs de transformaciones SQL. |
| data-processing | Cloudflare Workers AI | Proporciona capacidades de inferencia de modelos de lenguaje grande (LLM) para Skipper (traducción NL a SQL) y Skimmer (detección de PII). |
| storage | Cloudflare D1 | Base de datos relacional serverless para almacenar reglas de control de acceso de Lifeguard y el historial de ejecución de Transformer. |
| storage | Cloudflare Durable Objects | Primitiva de estado distribuido para gestionar el estado de los DAGs de Transformer y la persistencia de contexto en Skipper. |
| security | Lifeguard (servicio interno) | Servicio de control de acceso que almacena reglas en D1, gestiona membresías de grupos y genera políticas JSON para Trino, aplicando un modelo 'default-closed'. |
| data-processing | Skimmer (servicio interno) | Escáner continuo de detección de PII que utiliza Workers AI para clasificar columnas y alimentar DataHub y Lifeguard. |
| data-processing | Transformer (servicio interno) | Motor ELT basado en Workflows que compila y ejecuta DAGs de transformaciones SQL en Trino, con estado en Durable Objects y definiciones en R2. |
| observability | DataHub (servicio interno) | Catálogo de metadatos centralizado para tablas, columnas, propietarios, linaje y glosario, esencial para el contexto de Skipper y la gobernanza. |
Trade-offs
Ganancias
- ▲ Acceso unificado a datos
- ▲ Reducción de la latencia para consultas complejas
- ▲ Democratización del acceso a datos (lenguaje natural)
- ▲ Gobernanza de datos 'default-closed'
- ▲ Reducción de costos de almacenamiento (Iceberg en R2)
Costes
- ▲ Complejidad inicial de construcción de una plataforma interna
- ▲ Necesidad de mantener un catálogo de metadatos robusto
- ▲ Esfuerzo en la detección y gestión de PII
- ▲ Riesgo de 'hallucinations' del LLM sin contexto adecuado
const datasets = await skipper.search_datasets({ query: "billing product revenue" })
const queryId = await skipper.start_query({ sql: "SELECT ..." })
const results = await skipper.fetch_results({ queryId, mode: "inject" })
return skipper.create_chart({ chartType: "bar", data: results.rows, ... })Fundamentos Teóricos
El concepto de unificar el acceso a datos heterogéneos y la federación de consultas tiene raíces en la investigación de sistemas de bases de datos distribuidas y sistemas de información federados de las décadas de 1980 y 1990. Trabajos como 'The Design of the POSTGRES Storage System' de Stonebraker et al. (1987) o 'The Starburst Extensible Relational Database System' de Haas et al. (1990) exploraron la extensibilidad y la capacidad de integrar fuentes de datos diversas. La arquitectura de data lakehouse, que combina la flexibilidad de los data lakes (almacenamiento en objetos) con las capacidades de gestión de datos de los data warehouses (esquema, transacciones), se alinea con la evolución de los sistemas de gestión de datos para manejar el volumen, la velocidad y la variedad de los datos modernos. Apache Iceberg, un pilar de Town Lake, se basa en principios de diseño de tablas de alto rendimiento para data lakes, abordando desafíos como la evolución de esquemas y la consistencia transaccional en almacenamiento de objetos, un área de investigación activa en bases de datos distribuidas y sistemas de archivos.