Big Data y Hadoop

Big Data es el paradigma que hace posible recopilar, almacenar, gestionar, analizar y visualizar, incluso en condiciones de tiempo real, grandes conjuntos de datos de características heterogéneas.

La definición que más se pregunta añade un criterio que conviene subrayar, porque es lo que distingue Big Data de «muchos datos»: se habla de Big Data cuando el conjunto ya no admite un tratamiento convencional, porque desborda lo que son capaces de capturar, gestionar y procesar las herramientas de software habituales. No es una cifra concreta de terabytes: es el punto en el que lo de siempre deja de servir.

Y tiene un objetivo declarado: analizar esa gran cantidad de datos para encontrar patrones repetitivos, y obtener con ellos información suficiente para que la toma de decisiones pueda hacerse de forma automática.

Lo que define Big Data no es el tamaño en sí, sino que las herramientas convencionales ya no dan abasto con él.

Las características de Big Data se resumen en cinco palabras que empiezan por uve. Las tres primeras son las clásicas y las dos últimas se añadieron después, cuando quedó claro que acumular datos no sirve de nada si no son fiables ni útiles.

Volumen, Variedad, Velocidad, Veracidad y Valor. Las tres primeras describen el dato; las dos últimas, si merece la pena.

Hadoop es la plataforma de referencia para procesar Big Data. La idea que lo sostiene es sencilla de enunciar: si los datos son tan grandes que moverlos cuesta más que procesarlos, entonces no se llevan los datos al programa, se lleva el programa a las máquinas donde ya están los datos.

Para eso se apoya en HDFS, el Sistema de Ficheros Distribuido de Hadoop. HDFS reparte cada fichero en bloques grandes entre los nodos del clúster y guarda varias copias de cada bloque en máquinas distintas, de modo que si un nodo cae los datos siguen disponibles y el trabajo se relanza en otro que tenga la copia.

Por encima está el gestor del clúster, que es quien decide qué trabajo se ejecuta en qué máquina y con cuánta memoria y cuántos procesadores. En Hadoop ese papel lo desempeña YARN, y una alternativa que se cita a su lado es Mesos. Es la capa de reparto de recursos: sin ella, los trabajos competirían entre sí sin control.

El perfil de trabajo de Hadoop es el proceso por lotes, o batch. Ofrece una potencia de cómputo enorme sobre datos distribuidos en los nodos de HDFS, donde la información vive como ficheros, y está pensado para tareas que tardan minutos u horas y devuelven un resultado completo, no para contestar en milisegundos.

HDFS guarda y replica los ficheros; YARN, o Mesos, reparte los recursos del clúster. Son dos capas distintas y se preguntan por separado.

MapReduce es el modelo de programación con el que se procesa la información repartida. Su nombre son sus dos fases, y se entiende mejor si se piensa en qué hace cada una con los datos.

1. 1Map: cada nodo recorre el trozo de datos que tiene almacenado y emite pares de clave y valor. Como cada nodo trabaja solo sobre lo suyo, esta fase se paraleliza sin coordinación.
2. 2Reduce: los pares se agrupan por clave y, para cada clave, una función recorre todos sus valores y calcula el resultado final, que suele ser un agregado: una suma, un máximo, un recuento.

Entre las dos fases hay un paso implícito de reparto y ordenación por clave, que es lo que garantiza que todos los valores de una misma clave acaben en el mismo reductor. Ese trasiego por red suele ser la parte más cara del proceso.

// Objetivo: cuántas preguntas se han fallado en cada tema,
// con los intentos repartidos entre muchos nodos.

map(clave, intento):
    emitir(intento.tema, intento.fallos)

// El sistema agrupa por tema y entrega a reduce
// todos los valores de un mismo tema.

reduce(tema, lista_de_fallos):
    emitir(tema, suma(lista_de_fallos))

Map trocea y etiqueta en paralelo; Reduce agrupa por clave y calcula. La potencia viene de que la fase map ocurre donde ya están los datos.

Escribir cada análisis como un programa MapReduce es lento y repetitivo, así que sobre Hadoop se montaron capas que permiten consultar los datos con un lenguaje de más alto nivel y que se encargan de traducir la consulta a trabajos distribuidos.

• Hive: expone los ficheros de HDFS como si fueran tablas y se consulta con un dialecto de SQL. Es la puerta de entrada para quien viene del mundo relacional.
• Pig: usa un lenguaje propio de flujo de datos, en el que el análisis se escribe como una secuencia de transformaciones encadenadas. Encaja mejor cuando el proceso es una tubería de pasos que cuando es una consulta.
• Spark SQL: la capa de consulta de Spark, un motor que trabaja en memoria en lugar de escribir en disco entre fase y fase, lo que lo hace mucho más rápido que MapReduce en procesos iterativos.

Al lado de estas tres, y con otro cometido, está Mahout: una biblioteca de algoritmos de aprendizaje automático (machine learning) preparados para ejecutarse de forma distribuida, con implementaciones de clasificación, agrupamiento y recomendación.

Hive, Pig y Spark SQL sirven para consultar los datos; Mahout no consulta, aprende de ellos. Es la distinción que suele decidir la pregunta.

Hadoop y NoSQL no compiten: resuelven momentos distintos del mismo problema. La diferencia principal entre los dos está en el tiempo de respuesta. Hadoop procesa por lotes grandes volúmenes que viven en ficheros de HDFS y devuelve resultados completos al cabo de un rato; una base NoSQL está delante de la aplicación y tiene que contestar a cada petición al instante.

Como en un sistema real hacen falta las dos cosas, el problema pasa a ser cómo mantenerlas al día entre sí. Ahí entra Apache Kafka, la pieza que mantiene enlazados ambos mundos y sincroniza entre ellos la información.

Kafka funciona como un registro de eventos por el que pasa lo que ocurre en la plataforma. Quien produce un dato lo publica una sola vez, y cada sistema interesado lo consume a su ritmo: la base NoSQL lo aplica de inmediato para poder servirlo, y el clúster de Hadoop lo va acumulando para analizarlo después. Así ninguno de los dos tiene que llamar al otro ni esperarlo.

Kafka es el enlace entre el mundo de respuesta inmediata y el de análisis por lotes: los dos leen del mismo flujo de eventos, cada uno a su velocidad.

Frente al perfil por lotes de Hadoop, lo que caracteriza a un sistema NoSQL es el otro extremo: escrituras rápidas, lecturas rápidas, capacidad de trabajar en tiempo real y uso interactivo, es decir, con una persona esperando la respuesta al otro lado.

La conclusión de todo el tema tiene nombre propio: persistencia políglota. Consiste en aceptar que no existe un único almacén bueno para todo y usar en la misma aplicación el que conviene a cada caso de uso, en lugar de forzar todos los datos dentro del mismo motor.

Una plataforma real puede acabar con un relacional para la facturación, donde hacen falta transacciones; una base documental para el catálogo, donde el esquema cambia; Redis para las sesiones y las cachés; y un clúster de Hadoop para el análisis histórico. El coste de esa decisión es operar y sincronizar varios sistemas a la vez, y por eso solo compensa cuando los casos de uso son de verdad distintos.

La persistencia políglota no es una tecnología, es una decisión de arquitectura: se paga con más sistemas que mantener y se cobra en que cada dato vive donde rinde.