For the last two years, if you wanted to work with "Big Data", the default answer was to spin up a Hadoop cluster and write MapReduce jobs. I've tried it, and I assure you it's one of the most frustrating experiences. You have to write 50 lines of verbose Java code (creating Mapper and Reducer classes) just to count the words in a log file. And the worst part: it is desperately slow because it writes the intermediate results to the hard drive (HDFS) constantly.
But last month, the Apache Software Foundation officially released version 1.0 of a project that was born at UC Berkeley: Apache Spark. I've spent the weekend trying it out locally and I think I've just seen the light.
The in-memory processing revolution
The key concept in Spark is the RDD (Resilient Distributed Datasets). Instead of writing to disk at every step like Hadoop does, Spark keeps the data in the cluster's distributed RAM throughout the entire operations flow, falling back to disk only if it doesn't fit.
Also, you don't necessarily have to learn Java or compile heavy .jar files. Spark comes with first-class APIs for Scala and, thank Goku, for Python (PySpark). The code to process a massive log and filter errors goes from being a Java behemoth to a few elegant lines of pure functional programming.
Look at this beauty in PySpark:
from pyspark import SparkContext
# Iniciamos el contexto de Spark usando todos los núcleos locales
sc = SparkContext("local[*]", "AnalisisDeLogs")
# Cargamos un log de servidor enorme
lineas_log = sc.textFile("/datos/servidor/access.log")
# Transformaciones (perezosas): filtramos las líneas con error 404
errores_404 = lineas_log.filter(lambda linea: " 404 " in linea)
# Mapeamos para quedarnos solo con la IP (asumiendo que es el primer elemento)
ips_error = errores_404.map(lambda linea: linea.split(" ")[0])
# Acción: recolectamos resultados o los guardamos
# (Aquí es cuando realmente Spark ejecuta todo el grafo de operaciones)
for ip in ips_error.take(10):
print ip
It is intuitive. It is fast. It is concise. Operations like filter or map are not executed immediately; Spark builds an "execution graph" in the background (DAG) and mathematically optimizes how to process the data as efficiently as possible before launching the final action.
Reflection: The hard drive is the new magnetic tape
Hadoop popularized the idea of distributing data on cheap hardware, but its disk-based execution no longer makes sense. Today, setting up servers with 256 GB of RAM is economically viable.
MapReduce is a heavy dinosaur that will soon be relegated to ultra-low-priority nightly batch tasks. Spark, with its speed (they promise to be up to 100 times faster than Hadoop) and its ability to integrate with Machine Learning libraries (MLlib), is going to be the absolute standard. I'll have to start learning Scala if I want to squeeze the most out of the native engine, because there is no stopping this.