Claves del funcionamiento de un sistema de ficheros distribuidos (GFS, HDFS)

La definición del framework MapReduce abrió la puerta a toda una serie de innovaciones que han ido marcando la pauta de lo que hoy etiquetamos como Big Data. La principal virtud de MapReduce era que resolvía muchos de los retos a los que debía hacer frente el procesamiento de enormes volúmenes de datos (causados por las limitaciones en las capacidades de almacenamiento y transmisión de datos), ofreciendo un framework en el que todas esas complejidades quedaban resueltas y el programador de aplicaciones sólo tenía que preocuparse de concretar el propósito de las funciones Map y Reduce. La pieza clave de ese entramado en el que se soporta MapReduce (y que resuelve los citados retos sin que el programador tenga que ocuparse de ello) es el uso de un sistema de ficheros distribuidos (GFS en el caso de Google, HDFS en el caso de Apache Hadoop).

La principal característica de uno de estos sistemas es su adaptación a contextos en los que contamos con un conjunto de múltiples máquinas (cluster) que se van a repartir las tareas tanto de almacenamiento como de procesamiento de los datos. En un sistema de ficheros distribuidos, los ficheros se guardan "partidos" en trozos (chunks) de los que se guardan varias réplicas a lo largo de las máquinas que componen el cluster. Esta redundancia de datos es lo que le permite al sistema aumentar su tolerancia a fallos ya que, al tener gran cantidad de máquinas, la probabilidad de que una cualquiera de ellas falle en un momento dado no es un factor despreciable, y por tanto la existencia de esas réplicas asegura la disponibilidad de los datos en todo momento.

Otra característica importante es que las máquinas no son meros almacenes de datos, a la espera de que estos sean enviados a algún nodo central donde ser procesados, sino que a su vez se convierten en "centros de proceso" de las tareas que sean necesarias sobre los datos que almacenan. De alguna manera podríamos decir que los sistemas de ficheros distribuidos le dan la vuelta al planteamiento y consiguen que "Mahoma vaya a la montaña" (la tarea, procesamiento o cómputo a realizar se "acerca" a los datos), ya que lo contrario supondría muchísimo tiempo perdido en las tareas de transmisión de datos, sobre todo teniendo en cuenta que hablamos de contextos con enormes cantidades de los mismos.

De esta manera, los elementos que gestionan el funcionamiento de todo el framework (el nodo maestro del sistema de ficheros distribuidos que tiene la información de dónde están qué datos, el programador de tareas para indicar dónde se ejecutarán qué tareas, ...) resuelven toda la "magia" por debajo de un programa MapReduce. Así, por ejemplo, las tareas Map (que se lanzarán en paralelo para trabajar con todos los trozos de datos al mismo tiempo) le serán encargadas a cada máquina sobre su porción de datos en particular. El momento donde sí habrá un cierto "trasiego de datos" será el paso intermedio entre la finalización de esas tareas Map (que guardarán sus resultados en el nodo donde se han ejecutado) y el inicio de las tareas Reduce, ya que para que éstas puedan iniciar su trabajo es necesario concentrar en el mismo nodo aquellos datos generados en el paso anterior que ahora deban ser procesados conjuntamente (es decir, los que compartan clave).