Un poco de Historia
Como sabrás Apache Software Foundation es un proyecto que recoge distintas iniciativas de código abierto (Open Source) y Hadoop es una de esas iniciativas. El corazón de lo que es hoy Hadoop se inspiró en dos proyectos de Google que tenían su origen en la ambición de indexar el contenido de la WWW en que estaba embarcada la compañía. Los dos proyectos eran:
- Google File System (GFS), un nuevo sistema de archivo distribuido recogido en una publicación de los ingenieros de Google en octubre de 2003 (Si no has leído el post sobre los sistemas distribuidos y no estás familiarizado con el concepto quizá quieras hacerlo ahora antes de continuar).
- Map Reduce publicado en diciembre del siguiente año y que recoge los principios de un modelo de programación para trabajar con grandes volúmenes de datos y que permite el procesado de los datos en paralelo.
Doug Couttling es la brillante mente detrás Hadoop que surgió como un subproducto de Nutch, que a su vez era un proyecto dentro de Apache Lucene. Yahoo! demostró tener una gran visión cuando contrató a Couttling con el objetivo de crecer el proyecto y que fuese capaz de escalar para abarcar toda la inmensidad de la web.
Mr. Couttling no sólo ha sido una de las principales figuras del desarrollo de Hadoop sino que además es uno de los fundadores y Arquitecto Jefe de Cloudera, una de las soluciones comerciales de Hadoop líderes en el mercado.
Como curiosidad el nombre y el logo de Hadoop hacen honor a un muñeco de peluche con forma de elefante del hijo de Couttling con el que aparece en la foto.
Hoy día Hadoop es la infraestructura sobre la que sustentan su negocio empresas tan dispares, y tan enormes, como Facebook , Criteo, eBay o Netflix.
¿Qué es Hadoop?
Quizá la mejor manera de explicar que es Hadoop sea usando la propia descripción que hacen en la web de Apache (traducción libre):
[well][dropcap]L[/dropcap]a librería de software de Apache Hadoop es un framework que permite el procesamiento distribuido de grandes conjuntos de datos a través de clusters de ordenadores usando modelos de programación sencillos. Está diseñado para escalar desde un sólo servidor hasta miles de máquinas, cada una ofreciendo capacidad de procesado y almacenamiento a nivel local. En lugar de confiar en Hardware para ofrecer una alta disponibilidad, la librería está diseñada para ser capaz de detectar y gestionar fallos en la capa de aplicación, permitiendo entregar un servicio de alta disponibilidad sobre un cluster de ordenadores, cada uno de los cuales puede estar sujeto a errores.[/well]Y creo que es un buen comienzo porque recoge todos los elementos que han convertido Hadoop es estándar para trabajar en Big Data:
- En primer lugar Hadoop no es una bases de datos, es un framework que incluye diferentes elementos y librerías de software, entre ellos un nuevo sistema de archivos como veremos más adelante.
- En segundo lugar la escalabilidad de Hadoop le permite multiplicar su capacidad añadiendo más máquinas en un proceso distribuido de almacenamiento y procesado de datos.
- Por último la alta disponibilidad se basa en el diseño de Hadoop para ser capaz de gestionar de manera automática una caída de un nodo, o la imposibilidad de comunicar con él, a través de un sistema de réplicas de la información.
Aunque Hadoop tiene un amplio ecosistema de aplicativos y librerías de software existen al menos dos componentes esenciales para empezar a conocerlo. En el post de hoy voy a centrarme en intentar desgranar los elementos básicos de HDFS.
HDFS (Hadoop Distributed File System)
Hablamos de HDFS para referirnos a un nuevo sistema de archivos diseñado para trabajar con inmensos volúmenes de datos y que puede trabajar en clusters prácticamente con cualquier tipo de servidores, incluso aunque se trate de servidores muy antiguos. Como ya he mencionado se basa en el proyecto GFS de Google.
Por poner orden de magnitud cuando hablamos de grandes volúmenes de datos sólo nuestros amigos de Facebook son capaces de almacenar en Hadoop más de 240.000 millones de fotos con un crecimiento estimado de 7 petabytes al mes.
HDFS se basa en el principio de que resulta más sencillo trabajar con un modelo donde la escritura de datos se realiza una sóla vez y la lectura de datos tantas veces como se necesite. En este modelo no es tan importante la velocidad de acceso al primer dato como el tiempo que requiere recorrer todos los nodos para acceder a todo el conjunto de datos distribuido entre el conjunto de nodos.
Sharding
Se denomina Sharding al método por el que se divide un conjunto de datos en varias partes para almacenarlas en múltiples bases de datos. Este método es requerido cuando hablamos de conjuntos de datos tan grandes que exceden la capacidad de almacenamiento de una sola base de datos. También se denomina a este proceso partición horizontal, un concepto que viene del modelo de filas y columnas de las tablas en las bases de datos relacionales.
Un Shard o clave de partición (Partition key) es una parte de la clave principal que determina como se van a distribuir los datos en el sistema. La clave de partición nos sirve para recuperar y modificar datos eficientemente al permitirnos dirigir la petición a la ubicación correcta. Las entradas de la base de datos que compartan una misma clave de partición se alojarán dentro de un mismo nodo.
Existen diversas maneras de hacer esta partición de un conjunto de datos en bloques, HDFS utiliza un método denominado dynamic sharding. En este método de partición el sistema establece un servicio que se encarga de guardar la ubicación de todos los shards denominado NameNode, como veremos a continuación.
El modelo de HDFS crea por defecto una réplica de cada fichero en tres nodos distintos, lo que le confiere una alta resistencia a posibles fallos en el sistema, como la rotura de un enlace o la caída de uno de los nodos, una de las características de esta filosofía de gestión de archivos. En caso de que alguna pieza del sistema falle, y tarde o temprano alguno lo hará, siempre habrá una réplica a la que recurrir. De hecho la tolerancia a los fallos está en el corazón de este sistema.
NameNodes y DataNodes
Cada uno de los bloques que componen un mismo fichero se almacena en múltiples nodos dentro de un cluster. Hay dos tipos de nodos en cada cluster: NameNode (master) y DataNode (workers).
El NameNode mantiene el árbol de nodos del sistema de archivos y gestiona los metadatos para todos los ficheros y directorios en el árbol. El NameNode también guarda información de donde están todos los bloques que conforman un determinado fichero.
Los DataNodes son los auténticos caballos de batalla del sistema de archivos. Almacenan y recuperan los bloques cuando se lo pedimos y además le reportan al NameNode periódicamente un listado de los bloques que almacenan.
A partir de estos reportes el NameNode trata de garantizar que, cuando cualquier fallo en el sistema haya resultado en que el número de réplicas de un fichero esté por debajo del factor de replicación definido, por defecto 3, programará una nueva réplica y volverá a poner a nivel el sistema.
Otra diferencia fundamental del sistema de archivos de HDFS frente a sistemas tradicionales es el tamaño de los bloques con los que trabaja. Un bloque se puede definir como la cantidad de datos que puede leer y escribir. Los bloques de un disco físico andan en torno a los 512 bytes mientras que HDFS, que también trabaja el concepto de bloque, utiliza bloques de 128 MB por defecto. Parece ser que la utilización de bloques tan grandes es uno de los elementos que le permite optimizar los tiempos de búsqueda en el sistema.
Hasta aquí lo que vamos a ver de HDFS, en el próximo post hablaré de MapReduce, otro de los componentes fundamentales para entender el ecosistema Hadoop.
Atribución de la imagen de cabecera:
http://www.dbta.com/BigDataQuarterly/Articles/Reflections-on-10-Years-of-Hadoop-and-Big-Data-109236.aspx
