Cómo Netflix Resolvió el Problema de Particiones Anchas en Cassandra para Series Temporales

El Desafío de las Particiones Anchas

Cuando almacenas petabytes de datos de series temporales en Apache Cassandra, pocas cosas pueden arruinarte el día como una partición ancha. A medida que los eventos se acumulan con el tiempo, las particiones pueden crecer hasta gigabytes, causando picos de latencia de lectura de segundos, timeouts e incluso inestabilidad en el clúster.

El equipo de TimeSeries Abstraction de Netflix enfrentó exactamente este problema. Su sistema ingiere millones de eventos por segundo, y aunque Cassandra maneja admirablemente la escritura, el lado de la lectura comienza a sufrir cuando ciertas particiones se vuelven demasiado grandes. La respuesta típica sería tirar más hardware al problema, pero eso es costoso y no resuelve la causa raíz.

En cambio, construyeron un sistema de particionamiento dinámico que detecta y divide automáticamente particiones anchas a nivel de ID individual. Este enfoque redujo la latencia promedio de lectura para particiones anchas de segundos a dígitos dobles bajos en milisegundos, y la latencia de cola de varios segundos a alrededor de 200ms.

Por Qué las Particiones Anchas Son un Problema

Cassandra está diseñado para alto rendimiento de escritura, pero las lecturas pueden volverse problemáticas cuando una sola partición contiene demasiados datos. Esto es lo que pasa:

• Alta latencia de lectura: Leer una partición de varios gigabytes requiere escanear muchos datos, empujando la latencia a los segundos.
• Pausas de Garbage Collection: Las asignaciones grandes de heap durante las lecturas pueden causar pausas frecuentes de GC.
• Cola de hilos: Cuando muchas solicitudes apuntan a la misma partición ancha, los hilos se acumulan esperando que termine el escaneo.

Estos problemas pueden convertirse en timeouts e incluso indisponibilidad. Para datos de series temporales, las particiones crecen naturalmente con el tiempo, lo que lo convierte en un desafío persistente.

Solución 1: Re-particionamiento por Time Slice

El primer enfoque fue ajustar el particionamiento a nivel de tabla. Netflix usa time slices discretos, donde cada slice puede tener su propia estrategia de particionamiento. Monitoreando los tamaños de las particiones mediante nodetool tablehistograms de Cassandra, pudieron detectar cuándo las particiones eran demasiado pequeñas o demasiado grandes.

Un worker en segundo plano calcula un factor de ajuste y actualiza el intervalo de time bucket para slices futuros. Aquí hay un ejemplo simplificado de cómo podría funcionar la lógica de detección y ajuste:

import subprocess
import json

def get_partition_histogram(table_name):
    """Obtiene histograma de tamaño de partición de nodetool"""
    output = subprocess.check_output(["nodetool", "tablehistograms", table_name])
    return parse_histogram(output)

def adjust_time_bucket(histogram, target_size_mb):
    """Calcula nuevo intervalo de time bucket basado en tamaños observados"""
    p99_size_mb = histogram["p99"] / (1024 * 1024)
    if p99_size_mb < target_size_mb:
        # Aumenta intervalo para hacer particiones más grandes
        new_interval = current_interval * (target_size_mb / p99_size_mb)
    else:
        # Disminuye intervalo para hacer particiones más pequeñas
        new_interval = current_interval / (p99_size_mb / target_size_mb)
    return new_interval

Esto funcionó bien para datasets donde la mayoría de las particiones estaban mal configuradas. Pero falló cuando solo un pequeño porcentaje de IDs generaba datos excesivos. En esos casos, re-particionar toda la tabla sobre-particionaría la mayoría de los IDs normales.

Solución 2: Particionamiento Dinámico por ID

Para el problema de los outliers, Netflix construyó un pipeline asíncrono que divide particiones anchas a nivel de ID. Tiene tres etapas:

1. Detección: Cada lectura rastrea bytes leídos por partición. Si los bytes exceden un umbral, se envía un evento a Kafka.
2. Planificación y División: Un planificador lee toda la partición para calcular un plan de división óptimo, y luego delega la división a una estrategia que distribuye los datos entre múltiples buckets.
3. Sirviendo Lecturas: El servidor usa filtros Bloom para verificar rápidamente si una partición ha sido dividida, y luego enruta las lecturas a los trozos más pequeños.

Aquí hay un ejemplo conceptual del evento de detección y los metadatos de la división:

{
  "time_slice": "data_20260328",
  "time_series_id": "profileId:123",
  "time_bucket": 7,
  "event_bucket": 2,
  "immutable": true,
  "version": "0"
}

{
  "pre_split_data": {
    "time_slice": "data_20260328",
    "time_series_id": "6313825",
    "time_bucket": 0,
    "event_bucket": 2
  },
  "post_split_data": {
    "time_slice": "wide_data_20260328_0",
    "event_bucket_partition_strategy": {
      "target_event_buckets": 2,
      "start_event_bucket": 32
    }
  }
}

Los checksums garantizan la integridad de la división, y la partición original nunca se elimina, proporcionando un fallback seguro.

Lecciones Aprendidas y Conclusiones

El viaje de Netflix ofrece valiosas ideas para cualquiera que enfrente desafíos similares de escalabilidad:

• Reduce la superficie de ataque: Comienza con soluciones más simples que aún tengan impacto. Ellos primero intentaron el re-particionamiento a nivel de tabla antes de abordar la división por ID.
• Construye confianza: Invierte en mecanismos de validación como checksums y despliegues por fases para garantizar la corrección antes de la implementación completa.
• Monitorea y adapta: Usa herramientas de introspección para monitorear continuamente la salud de las particiones y ajustar las estrategias dinámicamente.

Limitaciones y Consideraciones

Este enfoque no es una bala de plata. Dividir particiones mutables aún es complejo y no está soportado. Además, la detección depende de las lecturas, por lo que hay una ventana corta donde algunas lecturas aún pueden golpear la partición ancha. Para casos extremos, implementaron una función 'Partial Return' que aborta solicitudes que exceden los SLOs de latencia.

Próximos Pasos para Aprender

Si estás lidiando con particiones anchas en Cassandra, comienza monitoreando los tamaños de las particiones y las latencias de lectura. Considera si puedes ajustar tu estrategia de particionamiento a nivel de tabla primero. Si tienes IDs outliers, piensa en implementar un pipeline similar de detección y división. Para más sobre la estrategia de particionamiento subyacente, consulta el Netflix Tech Blog.

También explora temas relacionados como novedades de Python 3.15 Alpha 5 o destacados de Python 3.14.3 para más insights técnicos.