Hadoop: Arquitectura

Comenzamos aquí una serie de posts para presentar, de manera sencilla, clara y breve, las principales características, componentes y arquitecturas relacionadas con los sistemas Big Data actuales. Este primer post versa sobre Hadoop.
Empecemos recordando algunos términos básicos. Un sistema distribuido consta de nodos, donde cada uno de ellos es un ordenador. A un conjunto de nodos almacenados físicamente y conectados en el mismo switch de red, se llama rack. Lógicamente el ancho de banda entre dos nodos de un mismo rack será muchísimo mayor que si están en diferentes racks. Un cluster de Hadoop es una colección de racks.

Hadoop tiene dos principales componentes en su arquitectura:
  • HDFS (Hadoop Distributed File System): sistema de ficheros distribuidos
  • MapReduce : Framework para realizar operaciones sobre los datos del HDFS

HDFS se ejecuta sobre todos los nodos de un cluster Hadoop, y está diseñado específicamente para gestionar eficientemente replicación de datos, obteniendo así un alto porcentaje de tolerancia a fallos. Hadoop funciona mejor sobre ficheros de gran tamaño ya que así debe gastar menos tiempo en buscar los fragmentos en los discos. Su diseño se beneficia de accesos secuenciales o por streaming, en vez de aleatorios. 
Hadoop usa bloques (tamaño por defecto: 64 Mbs, aunque la mayoría de sistemas reales usan 128Mbs o más) para almacenar las partes de un fichero. Estos bloques son de tamaño fijo y esto es una gran ventaja para calcular cuántos se necesitan según lo que ocupan nuestros ficheros, y además es sencillo relativamente situarlos en distintos clusters. Los bloques son replicados en múltiples nodos, asegurando así que si un cluster falla se recupera desde otro cluster. Existen múltiples parámetros de configuración en Hadoop que permiten ajustar eficientemente estas situaciones.

MapReduce se diseñó para procesar enormes conjuntos de datos en entornos distribuidos, usando muchísimos nodos. Como su nombre indica, un programa MapReduce consiste en dos transformaciones básicas, aplicadas a los datos de forma continuada: asignar (Map) y reducir (Reduce).

Pero, ¿qué componentes internos tiene HDFS más concretamente, y cómo usan todos ellos y qué papel juegan, cuando se ejecuta algún MapReduce job?
Podríamos clasificar en HDFS, las siguientes tipologías principales de nodos:
  • NameNode :  sólo existe uno en el cluster e informa del estado del contenido al resto, ya que contiene los metadatos de los distintos ficheros del cluster. Se recomienda asignarle la máxima RAM posible, para agilizar la gestión de dichos metadatos del sistema.
  • DataNode : almacén de Datos. Un típico cluster HDFS tiene muchos DataNodes.
  • Secondary NameNode : nodos auxiliares para el NameNode.
  • JobTracker : sólo existe uno en el cluster y recibe peticiones de clientes para gestionar las tareas MapReduce en los correspondientes TaskTrackers.
  • TaskTracker : nodo donde residen los datos de los jobs y se monitorizan para en caso de fallo, reasignar algún otro TaskTracker. Usan JVMs (máquinas virtuales Java) para correr la tarea de asignación o reducción. Son claves para la ejecución en paralelo de tareas.
  • Checkpoint Node : nodos generales de control.
  • Backup Node : almacén de copias de seguridad.
Cuando algún proceso cliente inicia una petición, lo atiende un JobTracker, aunque también puede comunicarse directamente con un NameNode o DataNode para recuperar partes de un fichero.


Big Data

Ya hace tiempo vino para quedarse un nuevo término, que a todos los analistas de negocio, ingenieros de datos, en definitiva, a todos los que lidiamos a diario con información (¿no somos todos realmente?), nos atrae, nos confunde, nos apasiona. El Big Data.


¿Pero qué es realmente? Es una plataforma. ¿Sólo eso? No, por supuesto. Es mucho más. Si pensamos en la cantidad de información que se genera por segundo en Internet o en las actividades relacionadas con alguna actividad diaria, como puede ser el tráfico en una ciudad, podemos darnos cuenta que dicho volumen no hace más que crecer: más sensores, más datos, más factores a tener en cuenta, más fuentes de datos, etc. Y la información que viene de dichas fuentes puede venir estructurada, o en la mayoría de las veces, no cuenta con un formato claro. Y ya no nos sirven los tradicionales RDBMS, ni tampoco los modelos de análisis y reporting de antaño, el Online Analytic Processing (OLAP). Ahora, por ejemplo, queremos procesar millones de tweets y posts con las opiniones de nuestros clientes en las Redes Sociales, porque con ello podremos evaluar la satisfacción, la opinión, hacer estimaciones, etc de forma mucho más acertada.

De cómo procesar en tiempo real una información tan masiva de Pentabytes (y creciendo), procedente de múltiples fuentes de datos (que también suelen ir variando conforme pasa el tiempo) y que a la vez nos permite confiar en dichos orígenes, es lo que nos ofrece Big Data, integrando datos variopintos en las operaciones diarias del business, en los data-warehouses, en las aplicaciones, en todos los procesos. Aplicando más analítica sobre más datos, y que éstos serán usados por más usuarios progresivamente.

Las características teóricas subyacentes en Big Data son la famosas 4 V´s: Volumen, Velocidad, Variedad y Veracidad.

Los perfiles de analistas de negocio, ingenieros de datos, etc están evolucionando inexorablemente hacia la nueva profesión: el Data Scientist. El trabajo que haremos en los próximos años, cómo lo haremos y con qué herramientas, nada tendrá que ver con el actual. Con una formación técnica, matemática, mente analítica enfocada a encontrar los problemas verdaderos y cómo resolverlos, será el prototipo de dicho científico. Y también debe estar enfocado al Business porque realmente debe querer aprender y brindar cambios a la organización, proponiendo recomendaciones a sus líderes.

En próximos posts iremos conociendo un poco más en detalle la plataforma Big Data, que entre otros componentes puede incluir, aunque no limitado a ello: Data-warehouses, sistemas de computación en streaming (analizadores de datos generados masivamente por streaming, en tiempo real), y aceleradores (librerías software que nos aportan configuraciones específicas para distintas áreas, como análisis de texto, data mining, servicios financieros, etc).

SQL Server: ejecutar sentencias con número variable de parámetros

Hace algún tiempo escribí una breve introducción de cómo ejecutar SQL dinámico, y lo sencillo que era. Ahora bien, para evitar tener que escribir funciones y sentencias cuando usamos infinidad de tablas, campos y parámetros distintos, hoy me vino la idea de crear una única función que nos haga el trabajo, da igual el número y tipo de parámetros a ejecutarse, y que todas las llamadas a esta función sean parametrizadas y customizadas de forma que centralizamos la ejecución, evitamos duplicar código, etc.
Os dejo una función, la más simple que se me ocurre possible, y quedo a la espera de vuestros comentarios y sugerencias:



Algunos ejemplos de llamadas al procedimiento podrían ser:



D2B Express C: función CONCAT, ordenación de registros y valores NULL

Tres aspectos prácticos básicos cuando tenemos que trabajar con BDs son poder unir cadenas, concatenando sus valores, así como ser capaces de ordenar por distintas columnas (ascendente y descendentemente) y cómo manejar valores vacíos (NULL).
Veamos en el siguiente ejemplo formas idénticas de unir cadenas, bien con la función CONCAT o con el separador "||":
Ahora vamos a recuperar aquellos empleados con el campo SEPDATE a un valor vacío (NULL):


Y por último recordemos cómo podemos ordenar por un campo (o varios) y ascendentemente (ASC o no especificado ya que es el tipo de ordenación por defecto) o descendentemente (DESC):


En la última imagen hemos ordenado primero los empleados primero por fecha de nacimiento y además a su vez por apellido pero descendentemente. En el segundo caso hemos hecho lo contrario: ordenar primero por fecha de nacimiento descendentemente (es decir los más jóvenes primero) y a la vez por apellido ascendentemente.  Un recurso a veces olvidado, es que también es posible especificar la/s columna/s por las que queremos ordenar usando el valor numérico de esa columna entre los valores devueltos, es decir, en el ejemplo anterior hubiera sido equivalente usar "ORDER BY 5, 2 desc" y "ORDER BY 5 desc, 2" (ya que la 5ª columna del recordset es el Birthdate, y la 2ª columna es LastName).
Y por último en este post vamos a recordar el uso de las funciones de agregado: SUM, COUNT, AVG, MAX, MIN, etc, es decir aquellas que tras agrupar registros nos interesa obtener el valor máximo o mínimo, la media, contar dichos registros, sumarlos, etc. Empecemos con nuestra tabla empleados, agregando una nueva columna para indicar el salario y actualicemos los registros existentes:
Y ahora vamos a ejecutar como ejemplo algunas de las funciones de agregado para conocer su funcionamiento: sumar los salarios de todos los empleados contratados según su año de alta, y después obtener el salario más bajo de cada año de contratación.

D2B Express C: uso avanzado de SELECT

Creo que ya tenemos un conocimiento suficiente para poder explotar bien cualquier base de datos en DB2, sabiendo que en la principal sentencia para recuperar los datos (SELECT), debemos incluir sólo las columnas que se necesiten, para una mayor rendimiento del motor, y que además en las condiciones WHERE podemos buscar valores entre rangos (BETWEEN), que estén incluidos en una lista (IN), o no (NOT IN), usar los caracteres de comparación (<, >, >=, <=, =), etc.


Además, hoy veremos cómo funciona la potente cláusula LIKE, básicamente para poder hacer búsquedas con "comodines" y que los valores que nos interesa recuperar siguen un "patrón". Si quisiéramos indicar un único carácter en ese patrón debemos usar el símbolo "_".Veamos un ejemplo para recuperar los empleados en cuyo nombre aparezca una letra "n":

Otro punto que seguro nos será útil será, respecto a comparaciones de campos fecha (DATE), es si queremos listar registros entre años, para lo cual usaremos WHERE YEAR(nombre campo de tabla) BETWEEN [desde año] AND [hasta año]
Además, siempre que nos interese, podemos crear ALIAS para las columnas que recuperemos (la palabra AS, como veremos, es opcional). Un ejemplo, traduciendo algunos de los nombres de campos de nuestra BD pruebas, al español:


Buscar en el Blog: