Apache Spark procesa terabytes sin que se te derrita el cluster

Che, antes de arrancar tengo que hacer una aclaración honesta, porque en esta serie la transparencia es sagrada: el análisis automático que me pasaron para este post hablaba de "memory layer para AI agents", vector DBs y persistencia de contexto cross-session. Eso no tiene nada que ver con lo que es realmente Apache Spark. Esa descripción corresponde a otra herramienta — probablemente algo como Mem0 o similar — y se cruzó mal en el pipeline de curación. Pasa, los sistemas automáticos a veces mezclan metadata. Por eso el veredicto humano todavía dice "pendiente": acá está, hecho a mano, con la data real.

Lo que sí tengo confirmado: Apache Spark aparece en 3 awesome lists independientes y tiene años de historia en producción en empresas que procesan volúmenes enormes de datos. La descripción oficial del repo lo define como un framework de "micro-batch processing for streams", con "stateful exactly-once semantics". En criollo: es el motor que entra en escena cuando tu volumen de datos supera lo que un solo servidor puede manejar en memoria, sin importar cuánta RAM le metas.

Pensalo así: tenés logs de una app que generan 500 GB por día, y necesitás calcular métricas agregadas — usuarios únicos, latencias promedio, detección de anomalías — sin esperar 14 horas a que termine un script de Python corriendo en un solo core. Ahí es donde Spark deja de ser una curiosidad académica y se convierte en la herramienta que te salva el sprint.

Qué hace

Apache Spark es un motor de procesamiento distribuido de datos, escrito originalmente en Scala, que corre sobre la JVM (sí, otra vez la JVM — por algo la menciono tanto en esta serie). Nació en el AMPLab de Berkeley como respuesta directa a las limitaciones de Hadoop MapReduce: Spark procesa en memoria en vez de escribir a disco en cada paso intermedio, lo que lo hace órdenes de magnitud más rápido para cargas de trabajo iterativas (pensá en algoritmos de ML, que necesitan pasar por los mismos datos una y otra vez).

El concepto central es el RDD (Resilient Distributed Dataset): una colección de datos particionada entre los nodos del cluster, inmutable, y que sabe reconstruirse sola si un nodo se cae (de ahí lo de "resilient"). Sobre eso se montan capas más amigables como DataFrames y Datasets, que te dan una API tipo SQL/Pandas pero distribuida.

// Ejemplo clásico: contar palabras en un dataset gigante
// distribuido entre todos los nodos del cluster
import org.apache.spark.sql.SparkSession

val spark = SparkSession.builder()
  .appName("ContadorDePalabras")
  .getOrCreate()

val textFile = spark.read.textFile("hdfs://logs/*.txt")

val conteo = textFile
  .flatMap(linea => linea.split(" "))   // separamos en palabras
  .groupByKey(identity)                  // agrupamos por palabra
  .count()                               // contamos ocurrencias

conteo.show()
spark.stop()

Lo interesante es que ese mismo código corre igual en tu notebook con 4 GB de RAM que en un cluster de 200 nodos en AWS EMR. Spark se encarga de particionar los datos, distribuir las tareas, y manejar los fallos — vos solo describís qué querés hacer, no cómo distribuirlo.

La parte de streaming (la que mencionaba la descripción oficial del repo, "micro-batch processing for streams... stateful exactly-once semantics") es Spark Structured Streaming: en vez de procesar evento por evento como Kafka Streams o Flink, Spark agrupa los eventos en micro-batches (cada pocos segundos) y los procesa con la misma API que usás para batch. Eso te da "exactly-once" — ningún evento se procesa dos veces ni se pierde, ni aunque un nodo explote en el peor momento.

# Streaming en PySpark: contamos eventos por ventana de tiempo
# leyendo de un topic de Kafka en tiempo real
df = spark.readStream \
    .format("kafka") \
    .option("kafka.bootstrap.servers", "localhost:9092") \
    .option("subscribe", "eventos") \
    .load()

conteoPorVentana = df \
    .groupBy(window(df.timestamp, "1 minute")) \
    .count()

query = conteoPorVentana.writeStream \
    .outputMode("update") \
    .format("console") \
    .start()

query.awaitTermination()

El proyecto es open source bajo licencia Apache 2.0, mantenido por la Apache Software Foundation, con soporte oficial para Scala, Java, Python (PySpark) y R. El repo está en github.com/apache/spark.

Por qué está en la lista

Que aparezca en 3 awesome lists independientes es un dato a favor, aunque no deja de ser una métrica de curación, no una prueba de calidad técnica en sí misma. Lo que sí puedo decir con base en la documentación oficial y años de adopción documentada en la industria: la combinación de velocidad en memoria, una API unificada para batch y streaming, y un ecosistema de librerías integradas (MLlib para machine learning distribuido, GraphX para grafos, Spark SQL para queries estilo base de datos) es lo que lo diferencia de alternativas como Hadoop MapReduce (su predecesor directo, mucho más lento porque escribe a disco en cada paso) o Dask (más pythonico pero con un ecosistema y madurez muy por debajo).

Si venís de mi historia con infraestructura — Linux, redes, servidores — vas a entender rápido por qué Spark me genera respeto: no es magia, es ingeniería de sistemas distribuidos bien hecha, con dos décadas de papers académicos atrás (el paper original de RDDs de Zaharia et al. es lectura obligada si te gusta entender el por qué, no solo el qué).

Cuándo NO usarlo

Ahora la parte honesta, porque en esta serie no vendemos humo: si tu dataset entra cómodo en la RAM de una sola máquina (digamos, menos de 10-20 GB dependiendo del hardware), montar un cluster de Spark es usar una grúa para levantar una lata de gaseosa. Pandas, Polars o incluso DuckDB te van a dar resultados más rápido y con una fracción de la complejidad operativa.

Tampoco es la mejor opción si necesitás latencia sub-segundo real en streaming — ahí Apache Flink le gana de mano porque procesa evento por evento, no en micro-batches. Y si tu equipo no tiene experiencia operando clusters distribuidos (YARN, Kubernetes, o Databricks como capa managed), el costo de mantenimiento puede comerte cualquier ganancia de performance. Spark no es "instalá y listo": requiere entender particionamiento, shuffle, memoria de executors — cosas que se aprenden a los golpes.

Cierre

Este es el post #13 de "Awesome Curated: The Tools", la serie donde desmenuzamos herramientas que pasaron el filtro de nuestro sistema de curación — cross-referencia entre awesome lists, análisis de IA, y veredicto humano final. Spark es de esas herramientas que no tienen el brillo de lo nuevo, pero que siguen ahí, aguantando el peso real de la industria, mucho después de que el hype se fue a otra parte.

Si te interesó el lado de infraestructura y sistemas, dale una vuelta al post sobre Node.js y el runtime que cambió el backend o al de Sniffnet para monitorear tu red. Y si querés ver el arco completo de la serie, la lista entera está en /blog/series/awesome-curated-tools.