El problema fundamental que aborda este artículo es cómo gestionar el crecimiento exponencial del volumen de datos en un sistema distribuido global sin incurrir en un crecimiento lineal o superlineal de los recursos de hardware. En entornos de hyperscaler, la eficiencia de los recursos es crítica; un aumento constante del tráfico requiere innovaciones continuas para mantener los costos operativos bajo control y la sostenibilidad de la infraestructura.
Históricamente, los sistemas de datos a gran escala a menudo comienzan con arquitecturas monolíticas que, si bien son simples inicialmente, se vuelven ineficientes a medida que la diversidad y el volumen de datos aumentan. La necesidad de procesar, almacenar y replicar cada byte de datos, independientemente de su relevancia para un consumidor específico o su potencial de consolidación, conduce rápidamente a cuellos de botella en la red, la CPU y la memoria. Este desafío se agrava en redes globales donde el tránsito de datos entre regiones es costoso y latente. La solución no reside en una única optimización, sino en una serie de intervenciones estratégicas a lo largo de todo el pipeline de datos, aplicando principios de computación distribuida y procesamiento de flujos para reducir la 'cantidad de trabajo' por evento.
La relevancia actual de este problema es innegable, ya que la digitalización y la proliferación de servicios en línea continúan generando volúmenes de datos sin precedentes. Empresas como Cloudflare, que operan en la intersección de millones de sitios web y usuarios, son un caso de estudio clave para entender cómo escalar la infraestructura de datos de manera sostenible. Las técnicas presentadas aquí son aplicables a cualquier organización que enfrente desafíos similares de crecimiento de datos y optimización de recursos en sistemas distribuidos.
Arquitectura del Sistema
El pipeline de datos de Cloudflare comienza con el servicio Logfwdr, que recolecta datos de fuentes distribuidas (Workers, FL) y los envía a centralized receivers. Estos receptores, a su vez, empujan los datos a un sistema de buffering distribuido llamado Buftee. Finalmente, los consumidores extraen datos de Buftee y los distribuyen a destinos finales como ClickHouse.
Las optimizaciones implementadas son multifacéticas. En 2022, se desmanteló un monolithic data schema único, reemplazándolo por product-specific schemas. Esto redujo el ancho de banda de la red troncal al evitar que los consumidores ingirieran campos irrelevantes. En 2024, la compresión se actualizó de LZ4 a zstd, logrando una reducción del 40% en el rendimiento del tráfico comprimido con un impacto mínimo en la CPU, lo que permitió manejar 1.5 veces más tráfico con la misma capacidad de red.
Para 2026, se introdujeron cambios significativos en la replicación y el procesamiento. La double-writing de eventos para resiliencia regional fue reemplazada por un modelo de shared ingest pool (similar a Logpush), donde Logfwdr envía cada evento una sola vez a un receptor centralizado disponible. La replicación se pospuso (late replication) hasta después de que los datos aterrizan en Buftee, con remote inserters transmitiendo copias entre centros de datos. Esta estrategia, combinada con el sampling temprano y la uniform partitioning de datos, redujo el tráfico de tránsito en 36 GB/s. El sampling se descentralizó, moviéndose a Logfwdr además de los receptores centralizados, utilizando un algoritmo de muestreo basado en la raíz cuadrada para mantener la representatividad mientras se reduce la cantidad de eventos transmitidos y almacenados. Finalmente, la aggregation se descentralizó y se aplicó en múltiples etapas del pipeline (Logfwdr, receivers, buffers, ClickHouse con aggregating table engines), consolidando eventos antes de su transmisión y almacenamiento, lo que resultó en una reducción del 80% para datasets de alta cardinalidad.
Flujo de Datos Original (Pre-2026)
- 1 Logfwdr Recolecta datos de fuentes distribuidas.
- 2 Logfwdr Doble escritura de eventos a dos regiones centralizadas para resiliencia.
- 3 Centralized Receivers (Región A) Ingesta y procesamiento de datos.
- 4 Centralized Receivers (Región B) Ingesta y procesamiento de datos.
- 5 Buftee (Región A) Buffering de datos.
- 6 Buftee (Región B) Buffering de datos.
- 7 ClickHouse (Región A) Almacenamiento y consulta final.
- 8 ClickHouse (Región B) Almacenamiento y consulta final.
Flujo de Datos Optimizado (Post-2026)
- 1 Logfwdr Recolecta datos y aplica sampling descentralizado.
- 2 Logfwdr Envía evento una sola vez a un receptor centralizado disponible (shared inges...
- 3 Centralized Receivers Aplica sampling adicional y agregación parcial.
- 4 Buftee Buffering de datos. Remote inserters replican datos entre regiones (late repl...
- 5 ClickHouse Inserters Lee en batches, aplica agregación adicional.
- 6 ClickHouse Almacenamiento final con aggregating table engines.
| Capa | Tecnología | Justificación |
|---|---|---|
| data-processing | Logfwdr | Servicio de recolección de datos distribuidos en el borde de la red, punto de entrada del pipeline. |
| data-processing | Centralized Receivers | Componentes intermedios que reciben datos de Logfwdr, aplican procesamiento inicial (sampling, agregación) y los envían al sistema de buffering. |
| messaging | Buftee | Sistema de buffering distribuido que retiene datos temporalmente, desacoplando productores de consumidores y facilitando la replicación tardía. Retención de buffer para recuperación de fallos. |
| storage | ClickHouse | Base de datos analítica columnar utilizada para el almacenamiento final y la consulta de datos. Uso de 'aggregating table engines' para consolidar datos. |
| networking | zstd | Algoritmo de compresión de datos utilizado para reducir el ancho de banda de la red troncal. vs LZ4 |
Trade-offs
Ganancias
- ▲▲ Reducción de ancho de banda de la red troncal
- ▲ Reducción de uso de CPU y memoria en centros de datos centralizados
- ▲ Capacidad para manejar mayor volumen de tráfico con el mismo hardware
- ▲ Sostenibilidad del crecimiento de la infraestructura
Costes
- △ Mayor complejidad del pipeline de datos
- △ Posible pérdida de granularidad en datos muestreados (para ciertos casos de uso)
- △ Mayor uso de CPU en el borde para sampling/agregación (compensado por reducción de red)
Fundamentos Teóricos
La gestión de datos a escala de hyperscaler se basa en principios fundamentales de la computación distribuida y el procesamiento de flujos. La desagregación de esquemas y la optimización de la compresión se relacionan con la eficiencia de la transmisión de datos, un tema central en redes y sistemas distribuidos, donde la minimización de la carga de red es un objetivo constante. La elección de algoritmos de compresión como zstd sobre LZ4 implica un trade-off clásico entre la relación de compresión y el uso de CPU, un concepto bien estudiado en la teoría de la información y la ingeniería de rendimiento.
La estrategia de late replication y shared ingest pool es una aplicación práctica de los principios de eventual consistency y load balancing en sistemas distribuidos. Al desacoplar la ingesta de la redundancia de la base de datos, se optimiza el uso del ancho de banda de la red de área amplia, un concepto explorado en trabajos sobre sistemas de almacenamiento distribuido y replicación de datos. El muestreo descentralizado y la agregación temprana son técnicas fundamentales en el procesamiento de flujos de datos y la computación de approximate queries. Estos métodos tienen raíces en la estadística y la algoritmia para stream processing, donde algoritmos como count-min sketch o reservoir sampling permiten estimaciones eficientes sobre flujos de datos masivos con recursos limitados. La idea de aplicar agregaciones en múltiples etapas del pipeline resuena con el patrón de map-reduce y los principios de dataflow programming, donde las operaciones se distribuyen y combinan para reducir la cantidad de datos que fluyen a través del sistema.