Introducción

En esta entrada (y como continuación a Apache Hadoop) se empleará Apache Hadoop para realizar procesamiento de grandes cantidades de datos en sistemas de archivos distribuidos usando Spring y MapReduce.

Descripción

MapReduce es un framework (modelo de programación) utilizado para dar soporte a la computación paralela sobre grandes colecciones de datos en grupos de computadoras; es por esta razón por la que este framework suele ejecutarse en sistema de archivos distribuidos (HDFS).

Función Map()

Map toma uno de estos pares de datos con un tipo en un dominio de datos, y devuelve una lista de pares en un dominio diferente:

La función map(): se encarga del mapeo y es aplicada en paralelo para cada ítem en la entrada de datos. Esto produce una lista de pares (k2,v2) por cada llamada.

Función Reduce()

La función reduce es aplicada en paralelo para cada grupo, produciendo una colección de valores para cada dominio:

Intruduccion

Hadoop es un framework que permite el procesamiento distribuidor de una gran cantidad de datos atraves de clusters usando un modelo simple de programación. Hadoop puede ser visto también como un sistema de archivos distribuido.

Hadoop tiene como objetivo solucionar el problema de almacenar la información que supera las capacidades de una única máquina, para lo cual, hadoop gestionará y permitirá el almacenamiento de la información en diferentes máquinas conectadas a través de una red.

HDFS es un sistema de archivos pensado para el almacenamiento de archivos "grandes" (por encima de 100 MB) y en la que el acceso a esa información está orientado hacia procesamiento en batch o lectura de tipo "write once"-"read-many-times" (ideal para temas de MapReduce -concepto que detallaré más en proximos articulos-) y cuyo diseño está pensado para ser ejecutado en máquinas "baratas".

En un cluster de HDFS encontramos dos tipos de nodos diferentes:

• Namenodes: son los encargados de gestionar el espacio de nombres del sistema de archivos
• Datanodes: son los que almacenan los bloques de información y los recuperan bajo demanda

Antes que otra cosa, debo aclarar que este, como el post anterior sobre DSL, no prentende ser un tutorial completo de como crear un DSL como gradle; mas bien, intenta dar una mirada y explicar como comenzar para entonces SI, llegar a crear un DSL.

Comenzare con el siguiente ejemplo :

Tal vez algunos pregunten "y por que querria hacer esto con un Integer si ya cuenta con un metodo toString() ?", la respuesta seria: "no se", pero sirve como ejemplo para resolver otros problemas o necesidades sobre clases (incluso finales como String) del JDK.

Ahora, "¿la sobreescritura de un método del JDK tiene efecto desde todas las clases, o solo durante el código donde se ejecuta?", la respuesta es: si, tiene efecto en toda la máquina virtual, pero solo dentro del código de las clases de Groovy, nunca dentro de una clase Java.

Groovy ofrece varias opciones para crear tu propio DSL, siendo una de ellas, y el tema de este artículo, los Builders ("Constructores").

Los builders permiten construir estructuras jerárquicas de manera natural, eliminando la complejidad de que el desarrollador administre la creación de la estructura al mismo tiempo que el código de negocio.

Groovy ofrece 3 opciones para que puedas crear tus propios builders:

• extendiendo GroovyObjectSupport, es tu responsabilidad alambrar la lógica al sobreescribir invokeMethod/methodMissing principalmente
• extendiendo BuilderSupport, la manera estandar de muchos builders que existen en la distribución de Groovy
• extendiendo FactoryBuilderSupport, la manera mas moderna, aumenta los mecanismos provistos por BuilderSupport

Supongamos que necesitamos una clase que obtenga un SQL desde un archivo properties y que nos regrese una cadena con dicho SQL

Primero, debemos definir nuestro builder: