MapReduce es un patrón arquitectónico de desarrollo de software , inventado por Google , en el que se realizan cálculos en paralelo y, a menudo, se distribuyen a datos potencialmente muy grandes, generalmente de un tamaño mayor a 1 terabyte .
Los términos " mapear " y " reducir ", y los conceptos subyacentes, se toman prestados de los lenguajes de programación funcional utilizados para su construcción (mapa y reducción de la programación funcional y lenguajes de programación de matrices).
MapReduce permite manipular grandes cantidades de datos distribuyéndolos en un grupo de máquinas para su procesamiento. Este modelo es muy popular entre empresas con grandes centros de datos como Amazon.com o Facebook . También está comenzando a usarse dentro de la computación en la nube . Han surgido muchos marcos para implementar MapReduce. El más conocido es Hadoop, desarrollado por Apache Software Foundation . Pero este marco tiene inconvenientes que reducen considerablemente su rendimiento, especialmente en entornos heterogéneos. De marcos para mejorar el rendimiento de Hadoop o el rendimiento global de MapReduce, tanto en términos de velocidad de procesamiento que el consumo de energía, están empezando a surgir.
MapReduce es un modelo de programación popularizado por Google . Se utiliza principalmente para la manipulación y el procesamiento de una gran cantidad de datos dentro de un grupo de nodos.
MapReduce consta de dos funciones map () y reduce ().
Un clúster MapReduce utiliza una arquitectura de tipo maestro-esclavo donde un nodo maestro dirige todos los nodos esclavos.
MapReduce tiene algunas características:
Una vez que un nodo ha completado una tarea, se le asigna un nuevo bloque de datos. Gracias a esto, un nodo rápido hará muchos más cálculos que un nodo más lento. El número de trabajos de mapa no depende del número de nodos, sino del número de bloques de datos de entrada. A cada bloque se le asigna una única tarea de mapa. Además, no todas las tareas de Map deben ejecutarse al mismo tiempo en paralelo, las tareas de Reducir siguen la misma lógica. Por ejemplo, si los datos de entrada se dividen en 400 bloques y hay 40 nodos en el clúster, la cantidad de trabajos de mapa será 400. Entonces se necesitarán 10 ondas de mapa para realizar el mapeo de datos.
MapReduce apareció en 2004. La tecnología aún es joven. Ella sufre de algunos puntos débiles:
MapReduce deriva su confiabilidad de la distribución, en cada nodo de la red, de las operaciones que se aplicarán al conjunto de datos ; el desarrollador espera que cada nodo devuelva periódicamente el trabajo realizado y los cambios de estado . Si un nodo no devuelve nada durante este intervalo, el nodo maestro (llamado NameNode en Hadoop) (similar al servidor maestro del sistema de archivos de Google ) considera que el nodo está muerto , Y envía los datos asignados a este nodo a otros nodos. . Las operaciones individuales utilizan operaciones atómicas para los nombres de los archivos de salida como una doble verificación para asegurarse de que no haya un conflicto paralelo con un subproceso en ejecución ; cuando se cambia el nombre de los archivos, también es posible copiarlos con otro nombre además del nombre de la tarea (permitido para efectos secundarios ) .
Las operaciones de contracción funcionan de la misma manera, pero debido a sus propiedades inferiores con respecto a las operaciones concurrentes , el nodo maestro intenta programar las operaciones de contracción en el mismo nodo, o lo más cerca posible del nodo que las contiene. procesada. Google prefiere esta propiedad porque no requiere ancho de banda adicional. Esto es una ventaja porque el ancho de banda suele estar limitado en las redes internas de la empresa .
Según un estudio de 2010 de la Universidad Nacional de Singapur , hay cinco factores que influyen en el rendimiento de MapReduce.
El modelo de programación MapReduce fue diseñado para ser independiente del sistema de almacenamiento de datos. Lee pares de <clave, valor> utilizando un lector. El lector recupera cada registro del sistema de almacenamiento, luego los coloca en un par <clave, valor> para que puedan ser procesados durante MapReduce. Aunque MapReduce no depende de un sistema de almacenamiento en particular, tiene dificultades cuando el sistema de almacenamiento es una base de datos. Los sistemas comerciales de bases de datos paralelas utilizan un motor para realizar consultas y un motor de almacenamiento. Para ejecutar una consulta, el motor de consultas lee los datos directamente del motor de almacenamiento. MapReduce primero debe leer el valor y luego almacenarlo en un par usando el lector, razón por la cual MapReduce funciona peor en las bases de datos. Al comparar MapReduce y sistemas de bases de datos paralelos, se destacaron tres factores que pueden afectar el rendimiento de MapReduce:
MapReduce utiliza un sistema de programación para asignar bloques de datos a los nodos disponibles en el clúster. Este sistema incurre en costos de ejecución y puede ralentizar la ejecución de MapReduce. Dos factores pueden influir en el rendimiento de MapReduce:
El lector puede utilizar dos modos de lectura para leer los datos almacenados en un sistema de almacenamiento.
Según las pruebas realizadas en este estudio, la diferencia de rendimiento entre estos dos modos es pequeña (alrededor del 10%).
Análisis de datosCuando la unidad recupera datos del sistema de almacenamiento, debe convertir los datos en un par <clave, valor> para continuar con la ejecución (este proceso se denomina análisis de datos). El análisis consiste en decodificar los datos de su formato de almacenamiento nativo para transformarlos a un formato que pueda ser utilizado por un lenguaje de programación. Hay dos tipos de decodificación, decodificación inmutable y decodificación mutable. La decodificación inmutable es el proceso de transformar datos en objetos inmutables. Los objetos inmutables en la programación orientada a objetos son objetos cuyo estado no se puede cambiar después de su creación, a diferencia de los objetos mutables.
Cuando se utiliza la decodificación inmutable, cada dato se colocará en un objeto inmutable. Por lo tanto, si decodificamos 4 millones de datos, se crearán 4 millones de objetos inmutables. De forma predeterminada, MapReduce de Google utiliza objetos inmutables.
Otro método es utilizar la decodificación mutable. Con esta decodificación, se reutiliza un objeto mutable para decodificar todos los datos. Por lo tanto, la cantidad de datos ya no es importante porque solo se creará un objeto.
Según los estudios, el rendimiento deficiente de análisis se debe a una decodificación inmutable. La decodificación inmutable es más lenta que la decodificación mutable porque produce una gran cantidad de objetos inmutables durante el proceso de decodificación. La creación de todos estos objetos inmutables aumenta la carga de trabajo de los procesadores.
IndexaciónComo MapReduce es independiente del sistema de almacenamiento, no puede tener en cuenta todos los datos de entrada para tener un índice disponible. MapReduce no parece capaz de utilizar índices. Sin embargo, se ha descubierto que tres métodos de uso de índices aumentan la velocidad del proceso de procesamiento de datos.
Para reducir los tiempos de planificación, es posible modificar el tamaño de los bloques de datos que se distribuirán a los nodos del cluster. Si aumentamos el tamaño de los bloques de datos, la planificación será más rápida, porque requerirá menos tareas de mapa. Sin embargo, si el tamaño de los bloques aumenta demasiado, el riesgo de falla es mayor.
MapReduce se puede utilizar para una variedad de aplicaciones, que incluyen grep distribuido , clasificación distribuida, inversión de gráficos de enlaces web, vector de términos por host, estadísticas de acceso web, construcción de índices invertidos, clasificación automática de documentos , aprendizaje automático , traducción automática estadística (grep distribuido, distribuido destino, inversión de gráfico de enlace web, vector de término por host, estadísticas de registro de acceso web, construcción de índice invertido, agrupación de papel , aprendizaje automático , traducción automática estadística ). Más significativamente, cuando MapReduce estuvo terminado, se usó para reconstruir completamente los índices de Internet de Google y reemplazó los viejos programas ad hoc usados para actualizar estos índices y para varios rastreos de estos índices.
MapReduce genera una gran cantidad de intermediarios y archivos temporales, que generalmente se administran y se accede a ellos a través del Sistema de archivos de Google para un mejor rendimiento.
Hadoop es una implementación de código abierto en Java MapReduce distribuida por la Fundación Apache . Fue presentado por importantes jugadores web como Yahoo! y Facebook . Las dos características principales de Hadoop son el marco MapReduce y el sistema de archivos distribuido de Hadoop (que está inspirado en el sistema de archivos de Google ). El HDFS puede distribuir datos y hacer tratamientos efectivos sobre estos datos con MapReduce distribuyendo una operación en múltiples nodos para paralelizarlos.
En Hadoop, el nodo maestro se llama JobTracker y los nodos esclavos se llaman TaskTracker. Cada nodo esclavo contendrá los bloques de datos al replicarlos. El nodo principal conoce las ubicaciones de las diferentes réplicas. El nodo principal secundario se utiliza para realizar copias de seguridad periódicas del nodo principal de modo que pueda reutilizarse en caso de que surja un problema.
Hadoop realiza una tarea de tipo MapReduce dividiendo primero los datos de entrada en un bloque de datos del mismo tamaño. Luego, cada bloque está programado para ser ejecutado por un TaskTracker. El proceso de asignación de tareas se implementa como un protocolo de tipo "latido". Esto significa que TaskTracker notifica a JobTracker que su tarea ha finalizado para que este último le asigne una nueva tarea para ejecutar. Cuando se completa la función de mapa, el sistema reagrupará todos los pares intermedios e iniciará una serie de reducciones para producir el resultado final.
La implementación de 2010 de Hadoop considera que el procesamiento se realiza en un cluster de máquinas homogéneas (es decir, todas tienen las mismas características de hardware). Tampoco toma en cuenta la localidad de los datos, considera que todos los datos son locales. Desafortunadamente, ambos factores pueden influir significativamente en el rendimiento de MapReduce.
En un entorno homogéneo, todos los nodos tienen la misma carga de trabajo, lo que indica que no se deben transferir datos de un nodo a otro. En un entorno heterogéneo, un nodo con alto rendimiento puede completar el procesamiento local más rápido que un nodo con menor rendimiento. Cuando el nodo rápido haya terminado de procesarse, deberá recuperar los datos no procesados de uno o más nodos más lentos. La transferencia de datos de un nodo lento a un nodo rápido tiene un costo elevado.
En las nubes PresentaciónMapReduce surgió en 2004 como un modelo de programación importante para aplicaciones que utilizan grandes cantidades de datos gracias a su eficiente distribución del trabajo en diferentes nodos informáticos. En particular, está comenzando a usarse en Cloud Computing porque la cantidad de datos almacenados y manejados sigue creciendo. Por lo tanto, es necesario tener una forma de mejorar el procesamiento de datos en la nube.
En términos de recursos, la nube se puede caracterizar en tres puntos: una gran capacidad de almacenamiento de datos, potencia de cálculo bajo demanda, utiliza poco ancho de banda. El tamaño de los datos almacenados en la Nube aumenta constantemente, en particular archivos de imagen, video, audio o instrumentos científicos para realizar simulaciones. El procesamiento de estos datos se ha convertido en uno de los principales desafíos del Cloud Computing.
La nube utiliza principalmente máquinas virtuales (VM) para ejecutar aplicaciones. Las máquinas virtuales permiten el uso completo de los recursos del sistema, mejoran la confiabilidad del sistema al realizar una copia de seguridad del estado del sistema mediante la funcionalidad incluida en las máquinas virtuales y reducen el consumo de energía al reducir la cantidad de nodos utilizados para completar las tareas.
Combinar Cloud Computing que usa VM y MapReduce puede ser interesante. Principalmente, porque las tecnologías de virtualización han alcanzado la mayoría de edad. Ya se han utilizado para computar grids para aprovechar al máximo los recursos de los nodos de computación y las aplicaciones de HPC (computación de alto rendimiento). Además, por un lado está la creciente popularidad de la nube (que usa VM), por otro lado, MapReduce está comenzando a ser ampliamente utilizado gracias a sus múltiples fortalezas, particularmente por su escalabilidad y tolerancia a fallas. Por lo tanto, la combinación de estas dos tecnologías crearía una forma eficiente de procesar grandes datos en la nube. A esto se suma el hecho de que MapReduce utiliza tareas especulativas. Estas son tareas que se pueden reiniciar en otro nodo si se detecta que son demasiado lentas. El problema es que reiniciar una tarea puede disminuir el rendimiento al aumentar el tiempo de ejecución, ya que la tarea debe reanudar todo el procesamiento. Gracias a las nuevas tecnologías de VM, como la copia de seguridad y la migración, se mejoran el rendimiento y la confiabilidad de MapReduce. La funcionalidad de copia de seguridad consiste en hacer una copia de seguridad del estado del sistema, para que pueda volver a este estado si encuentra un error grave que le impide funcionar correctamente. La funcionalidad de migración consiste en distribuir una máquina virtual o una aplicación en varios nodos físicos sin detener la aplicación.
RendimientoPara probar MapReduce, las diversas mediciones se realizan en el marco de Hadoop. Las pruebas de rendimiento se realizan en HDFS, ya que juega un papel importante en la ejecución de MapReduce. De hecho, es en particular el HDFS el que se encarga de la distribución de las tareas en los distintos nodos, también decide el tamaño de los datos a procesar por nodo. Se realizarán más pruebas sobre la viabilidad de utilizar VM para mejorar el rendimiento de MapReduce aumentando el uso de recursos (aumentando el número de VM por nodo). El rendimiento se mide utilizando dos puntos de referencia conocidos, el punto de referencia de clasificación y recuento de palabras.
clasificación de referencia este punto de referencia utiliza el marco map / reduce para ordenar los datos de entrada. El punto de referencia "Recuento de palabras" este punto de referencia cuenta el número de apariciones de cada palabra en un archivo y escribe el resultado en el disco local. HDFSLa evaluación del rendimiento de HDFS se realiza en un clúster físico (PH-HDFS) y en un clúster virtual (VM-HDFS al escribir y leer datos para mostrar las diferencias de rendimiento entre un clúster físico y un clúster virtual.
En esta evaluación, se realizan varias transferencias de datos de diferentes tamaños. El PH-HDFS logra mejores tiempos, las brechas se amplían a medida que los datos aumentan de tamaño.
En esta evaluación, se lanzan una o más solicitudes simultáneamente y se mide el tiempo necesario para completar la transferencia de datos. El rendimiento de PH-HDFS es mejor que el de VM-HDFS.
Viabilidad de las máquinas virtualesCon la llegada de los procesadores de múltiples núcleos, es relevante utilizar procesadores de múltiples núcleos en el clúster para instalar múltiples VM por procesador con el fin de utilizar plenamente las capacidades del nodo. Para las pruebas, se configuraron varios clústeres para evaluar el impacto del aumento en la cantidad de VM por nodo:
Como se muestra en esta figura, el "recuento de palabras" de referencia con el Ph-Cluster es más rápido que el V-Cluster. Cuando los datos son de 1 Gb, la diferencia es pequeña. Pero cuando los datos son mucho más grandes (aquí 8 Gb), hay una diferencia significativa. Esto se debe al aumento de las tareas especulativas que provoca un uso ineficiente de los recursos. Por otro lado, los clústeres V2 y V4 son mucho más eficientes que el Ph-Cluster porque hay muchos más cálculos por ciclo.
Cuando se inicia el banco de pruebas de clasificación, el tiempo de ejecución, para la misma distribución de datos, aumenta con el aumento de la cantidad de máquinas virtuales implementadas en un nodo físico. Además, las brechas se amplían a medida que aumenta el tamaño de los datos distribuidos. Esto se debe a 3 razones: el bajo rendimiento de HDFS en las VM durante las operaciones de lectura / escritura (como se vio anteriormente), el aumento en el número de tareas especulativas (Figura 6) y la gran cantidad de datos transferidos durante las etapas intermedias.
Recuerde que Hadoop es un marco basado en el modelo de programación MapReduce. Al ser ampliamente utilizado en los cálculos de grandes masas de datos, han aparecido varias mejoras de este marco. Estas extensiones son marcos: "BlobSeer" modifica el sistema de archivos para mejorar el acceso a los datos, "Phoenix" distribuye las tareas en los procesadores que utilizan MapReduce y "Mars" mejora el cálculo de datos en los procesadores gráficos.
Como se dijo anteriormente, el problema de rendimiento de Hadoop en un entorno heterogéneo se debe a la transferencia de datos entre nodos rápidos y nodos lentos. Cuando se transfiere una gran cantidad de datos, afecta significativamente.
Para mejorar el rendimiento de Hadoop, es necesario minimizar la transferencia de datos entre nodos rápidos y lentos. Para ello, se ha implementado un mecanismo de colocación de datos; distribuye y almacena datos en muchos nodos heterogéneos de acuerdo con sus capacidades. Con esto, la transferencia de datos se puede reducir si la cantidad de datos colocados en el disco de cada nodo es proporcional a la velocidad de procesamiento de los nodos.
La replicación de datos tiene muchas limitaciones. Primero, representa un costo significativo para crear cada réplica de los datos dentro de un clúster que tiene una gran cantidad de nodos. En segundo lugar, distribuir una gran cantidad de réplicas puede sobrecargar el ancho de banda del clúster. En tercer lugar, el almacenamiento de las réplicas requiere discos con una gran cantidad de almacenamiento.
MejoraLos investigadores se han centrado en este problema para producir un mecanismo de ubicación de datos. Para corregir el problema, buscaron la mejor manera de colocar los datos donde los archivos se dividirían y distribuirían en varios nodos sin duplicarlos .
Este mecanismo se basa en 2 algoritmos que se incorporan en Hadoop HDFS:
El primer algoritmo funciona así:
Si consideramos una aplicación, usando MapReduce, y un archivo de entrada en un clúster heterogéneo de Hadoop. La ubicación inicial de los datos no tiene en cuenta el rendimiento del nodo porque Hadoop estima que todos los nodos se ejecutarán y completarán su tarea con, aproximadamente, la misma cantidad de tiempo. Los experimentos han demostrado que, como regla general, el tiempo de procesamiento de cada nodo era estable porque el tiempo de respuesta de cada nodo es linealmente proporcional al tamaño de los datos. Con esto, se puede cuantificar la velocidad de procesamiento de cada nodo en un entorno heterogéneo. El término para definir el rendimiento de cada nodo es "Relación de rendimiento".
La relación de rendimiento de cada nodo se determina mediante este procedimiento:
Tomemos un ejemplo para mostrar cómo se calcula el Rendimiento de la relación. Considere 3 nodos heterogéneos A, B y C en un clúster de Hadoop. Después de ejecutar la aplicación por separado en cada nodo, obtenemos el tiempo de respuesta de cada nodo A, B y C (10 s, 20 sy 30 s respectivamente). El tiempo de respuesta del nodo A es el más corto, por lo tanto, el índice de rendimiento de A es 1. El índice de rendimiento de B y C son 2 y 3 respectivamente. Esto significa que el nodo A podrá administrar 30 fragmentos del archivo de entrada, mientras que el nodo C solo administrará 10.
Después de ejecutar el algoritmo de distribución de fragmentos para lograr la ubicación inicial, los fragmentos pueden corromperse por varias razones:
Para evitar estos problemas, se ha implementado un segundo algoritmo para reorganizar los fragmentos del archivo en función del Performance Ratio de los nodos.
Este algoritmo funciona así:
En el proceso de migración de datos entre 2 nodos (uno sobrecargado y otro con espacio en disco), el servidor transfiere los fragmentos del archivo desde el nodo fuente de la lista de nodos sobrecargados a un nodo que aún tiene espacio. De la lista de subutilizados nodos. Este proceso se repite hasta que el número de fragmentos en cada nodo coincide con su índice de rendimiento.
ActuacionesPara mostrar los resultados de estos algoritmos de este estudio, se realizaron dos pruebas, el Grep y el WordCount. Estas 2 aplicaciones se ejecutan en clústeres de Hadoop. Grep es una herramienta de búsqueda de expresiones regulares en texto. WordCount es un programa que se utiliza para contar palabras en texto.
Los resultados mostraron que estos algoritmos mejoraron el rendimiento de Grep en un 17% en promedio y WordCount en un 7% en promedio.
Hadoop es un marco basado en el modelo de programación Map / Reduce. Y para ello, Hadoop debe confiar en una "herramienta poderosa": su sistema de archivos HDFS. El sistema de archivos HDFS (llamado sistema de archivos distribuido de Hadoop) es un parámetro importante del rendimiento computacional de Hadoop porque es específico para él. Es decir, ha sido diseñado para maximizar el acceso a los datos.
Solo quedan errores cuando varios procesos acceden al mismo archivo. Es el marco de Blobseer el que ofrece una solución a este problema. De hecho, este marco propone modificar el HDFS para reemplazarlo por su propio sistema de archivos, el BSFS (Blobseer File System).
Un nuevo sistema de archivosLas razones para cambiar este sistema de archivos están relacionadas con problemas de acceso concurrente en el mismo archivo. El sistema HDFS fue diseñado para proporcionar el mejor rendimiento informático de Hadoop; sin embargo, esta implementación no es suficiente. El sistema de archivos HDFS no permite mantener una alta velocidad en accesos concurrentes al mismo archivo, además el sistema de archivos actual no permite ciertas funcionalidades como "versionar" o diferentes actualizaciones simultáneas sobre un mismo archivo.
Una de las fortalezas de Hadoop es que rastrea petabytes en solo unas pocas horas, debido al hecho de que los archivos tienen un tamaño de varios cientos de gigabytes. Como resultado, es posible acceder a pequeñas partes del mismo archivo al mismo tiempo. Tenga en cuenta que sería imposible trabajar con millones de archivos pequeños en lugar de uno solo, e incluso si el sistema de archivos lo permite, mantener tasas de bits muy altas no es factible.
Por lo tanto, Blobseer ofrece un sistema de archivos que permite el acceso a partes pequeñas de un archivo grande, lo que permite que miles de "clientes" modifiquen el mismo archivo sin problemas de conflicto. Por tanto, BSFS también permite el "versionado" que permite eliminar cambios no deseados y la creación de ramas independientes que no deberían reducir el rendimiento del cálculo ni la sobrecarga del espacio de almacenamiento que se debería a miles de archivos pequeños.
ActuacionesEl rendimiento del marco se ha probado en grid5000. Blobseer se ha comparado con Hadoop. Para ello, los frameworks se utilizaron en microtareas:
Los registros de rendimiento mostraron que el rendimiento (acceso a datos) es hasta el doble que el de Hadoop. Estos resultados también revelaron que el marco BlobSeer puede admitir hasta el doble de clientes (es decir, el número de visitas en un solo archivo). La relación de rendimiento entre BlobSeer y Hadoop no es más de dos. De hecho, BlobSeer utiliza las mismas capacidades informáticas que Hadoop, excepto que se ha modificado el sistema de archivos.
Phoenix es una API basada en el modelo MapReduce, ofrecido por google. La diferencia es que Phoenix se usa en computadoras multinúcleo y, por lo tanto, no usa servidores sino subprocesos para poder usar MapReduce. Phoenix se basa en un lenguaje funcional, para que la paralelización sea completamente transparente para el usuario. Phoenix se usa en C y C ++.
La estructuraEs una API desarrollada para su uso con código C / C ++, pero se puede exportar fácilmente a java / C #. Los punteros, búfer, subprocesos P se utilizan para aumentar el rendimiento de la API. Los búferes permiten el acceso a los datos en la memoria compartida. Hay dos tipos de búferes: los de entrada / salida son los búferes que contienen los datos de entrada y los datos de salida, es decir, los datos que necesita el usuario, y los demás búferes. Estos son los que se utilizan para crear MapReduce, por lo que son búferes "invisibles" para el usuario. Los punteros se utilizan para evitar tanto como sea posible la no duplicación de los datos, mejorando así significativamente la velocidad de cálculo de los datos. El uso de P-Threads permite que la API distribuya su trabajo entre múltiples procesadores siguiendo el modelo de programación MapReduce.
ActuacionesLos rendimientos se calcularon sobre tareas básicas como:
con como punto de referencia, el rendimiento de p-threads sin el modelo MapReduce.
Los resultados de Phoenix muestran que con un procesador de 4 núcleos, puede acelerar los cálculos en un 40% y con 8 núcleos, puede llegar hasta el 50%. Sin embargo, aunque la velocidad de cálculo aumenta, en máquinas simples sigue siendo equivalente a la de los subprocesos p. De hecho, aunque el modelo MapReduce es muy eficiente en clusters a una escala de millones de datos, la implementación del modelo no es lo suficientemente general como para cubrir todos los programas.
Animado por el éxito del modelo de programación MapReduce, nació el framework Mars, que permitió implementar el modelo MapReduce en procesadores gráficos. Los procesadores gráficos ( GPU ) tienen diez veces el ancho de banda de memoria de las CPU y también son hasta diez veces más rápidos.
ActuacionesPara evaluar este desempeño, se comparó a Marte con Phoenix, en las mismas tareas. Resultó que el rendimiento de Mars es 1,5 veces mejor que el de Phoenix.
MejoramientoMarte aún está en estudio, sin embargo se señalan tres puntos esenciales para una evolución futura:
PQL es un lenguaje implementado como una extensión de Java. Ha sido diseñado para incrementar su expresividad y modularidad, se ha realizado una comparativa entre su implementación y la de java en tareas paralelas similares. La paralelización es un problema de actualidad en la informática, por eso es importante crear lenguajes o bibliotecas para facilitar la paralelización. Sin embargo, no se debe olvidar la programación secuencial, por lo que la implementación de un lenguaje adecuado para la programación paralela y secuencial es fundamental. Todos los programas implementados con PQL se paralelizan gracias a la programación declarativa .
Programación declarativaPQL es un lenguaje basado en programación declarativa , lo que significa que el programador puede especificar lo que quiere hacer sin especificar realmente "cómo" hacerlo. Se implementó PQL para encontrar el método más rápido de realizar. De hecho, sabrá qué fragmento de código se debe paralelizar o no. No depende del desarrollador averiguar cómo optimizar su código. PQL distribuye la carga de trabajo a los procesadores disponibles usando MapReduce. PQL se ha optimizado para tareas paralelas para que el usuario tenga la menor cantidad de manipulación en comparación con el código paralelo escrito por el usuario.
Ilustración de idiomaPQL usa los valores booleanos &&, ||, XAND, XOR, así como palabras clave como reducir, para todos, consultar, existe. El número de palabras clave PQL se reduce explícitamente para mejorar la paralelización tanto como sea posible.
Una consulta se puede implementar con: una Quantify Expression (devuelve una cantidad, usa para todos, existe ...), una Java Expression (código Java), una id (variable, con o sin tipo), una QExpr (combina los casos anteriores ).
Ejemplo:
int[] array = query(Array[x]==y):range(1,1000).contains(x) && y=x*x;La consulta devolverá una matriz de números enteros que contienen los cuadrados de x entre 1 y 1000.
Una expresión de cuantificador se puede escribir en la forma: QUANT-EXPR :: = <QUANT> <ID> ':' <QUERY> consulta '(' <MATCH> ')' ':' <QUERY> (Container queries) reduce ' ('id') '<ID> [sobre <ID-SEQ>]: <QUERY> (Reducciones)
Ejemplo: forall int x: x == x siempre verdadero (cuantificar) (ID) (x == x consulta)
Consultas de contenedor: consulta (Map.get (x) == y): rango (1, 10) .contiene (x) && y == x * x consulta '(' <COMPARTIR> ')' ':' <QUERY> Construirá un mapa que contenga los cuadrados del 1 al 10 (podemos acceder al elemento 0 pero devolverá un nulo)
Operación de reducción:
reduce (sumInt) x : myset.contains(x) cette expression va additionner tous les x contenus dans myset reduce (sumDouble) x over y : set.contains(y) && x == 1.0 / y Additionne les inverses des éléments contenus dans la mapLos tipos se pueden declarar implícitamente (el usuario no necesita declarar el tipo) o explícitamente (el usuario debe declarar el tipo de la variable). PQL lanza las excepciones pero no tenemos garantía del pedido. PQL usa == o = para la igualdad (excepto para cadenas y objetos .equals ()).
El usuario puede crear sus propios descuentos. Deben respetar varias propiedades (método estático, asociativo, conmutativo…). Si no se respetan estas propiedades, se producirán errores.
ActuacionesPara evaluar PQL se han implementado diferentes tareas (cálculo de bonificaciones para un gran número de empleados, encontrar una subcadena en una cadena de cadenas de caracteres, una lista de documentos que se pueden vincular entre sí, el objetivo es encontrar los ciclos, calcular el número de apariciones de todas las palabras en varios textos).
La implementación de soluciones de diferentes formas:
Cuando se implementa con un solo subproceso y PQL, se utilizan variables de entrada pero sin variables temporales, mientras que para otras implementaciones el uso de variables y matrices intermedias era necesario para la comunicación o la optimización. La implementación de SQL es simple pero rápidamente se complica si la mezcla con java.
La implementación de PQL es fácil de escribir porque contiene pocas líneas. De hecho, la solución que contiene el número mínimo de líneas es siempre la que tiene PQL . El segundo es el hilo único (pero no optimizado). Los otros métodos contienen de 5 a 20 veces más filas.
En las 4 tareas, solo la primera no funciona bien porque el tiempo para hacer las operaciones de fusión de los resultados es muy alto. Para otras tareas, PQL puede ir entre 2 y 6 veces más rápido que otras implementaciones. Todas estas pruebas muestran que PQL funciona mucho mejor y usa menos líneas de código. Sin embargo, es necesario recordar que SQL y Hadoop usan una tabla de datos y por lo tanto su tiempo de ejecución se ralentiza por el acceso a esta base de datos. Además, el marco de Hadoop está optimizado para cálculos en clústeres y no en una sola máquina.
El MapReduce fue premiado sobre todo por su flexibilidad y eficiencia. Sin embargo, en un momento en el que la ecología toma un lugar más importante en las nuevas tecnologías, es relevante estudiar el consumo energético de MapReduce y saber cómo reducirlo.
La mayoría de los frameworks que implementan MapReduce, como Hadoop, consideran que el procesamiento se realiza en un entorno homogéneo. De hecho, es muy raro que un clúster contenga las mismas máquinas. Las máquinas varían según diferentes criterios en función del consumo de energía: cantidad de pasta térmica, velocidad del ventilador, tamaño del ventilador, situado más o menos cerca de una unidad de refrigeración, cantidad de polvo. Esto implica que algunas máquinas consumirán más energía que otras para realizar el mismo tratamiento.
Por tanto, se diseñó un framework para poder planificar dinámicamente las tareas según el consumo individual de cada nodo del cluster.
ImplementaciónPara poder planificar dinámicamente, primero tuvimos que desarrollar una forma de conocer el consumo de cada nodo. En este artículo, se ha establecido una correlación entre la temperatura de la CPU y el consumo de energía, sin embargo, esta relación es inexacta. Esto se debe a que una máquina puede consumir una gran cantidad de energía mientras tiene una temperatura baja si está ubicada cerca de una unidad de refrigeración. En general, esta correlación sigue siendo correcta.
Cuando el nodo maestro HDFS ha distribuido los datos, inicia un hilo que medirá la temperatura de cada nodo. Cuando un nodo ha terminado de procesarse, si su temperatura es menor que la temperatura máxima definida por el usuario, entonces se asigna una nueva tarea al nodo, de lo contrario el nodo quedará en espera hasta que su temperatura baje o hasta que se complete el procesamiento. Sin embargo, cuando se hayan distribuido todas las tareas, el módulo de tolerancia a fallos comenzará a funcionar independientemente de la temperatura. De hecho, si todos los nodos se están enfriando, la tarea se bloqueará.
Para reducir el consumo se configurarán dos parámetros: temperatura máxima de un nodo y número de tareas para realizar un tratamiento. En las próximas evoluciones de este marco, cada nodo tendrá su propia temperatura definida porque algunos procesadores tienen una temperatura más alta durante su funcionamiento.
ActuacionesLas mediciones se realizaron sobre el algoritmo WordCount (calcula todas las iteraciones de todas las palabras de un documento) en un medio heterogéneo.
Estudiaremos las variaciones de rendimiento según los dos parámetros mencionados en el capítulo anterior.
Temperatura máximaEl límite de temperatura, al decidir si un nodo puede realizar el procesamiento o no, puede limitar el rendimiento. Las pruebas se llevaron a cabo con tres temperaturas diferentes (80 °, 110 °, 120 °).
En la figura podemos ver que cuanto menor es la temperatura máxima, mayor es el tiempo de ejecución. Si la temperatura máxima está demasiado cerca de la temperatura de las CPU inactivas, muy pocos nodos obtendrán una nueva tarea después de completar la primera. El problema es que esto podría hacer que la tarea actual se cuelgue hasta que un nodo tenga una temperatura por debajo del límite. Al recuperar información del clúster en el que se implementa el marco, podríamos evitar ese riesgo. Una de las informaciones más importantes sería la temperatura de cada CPU en reposo.
Además, notamos que cuanto mayor es el número de tareas por nodo y menor es la temperatura máxima, más aumenta el tiempo de ejecución. Esto se debe al tiempo que tardan los nodos en enfriarse para volver por debajo del límite.
Vemos la misma tendencia para el consumo de energía de cada nodo. Con este marco, si elegimos correctamente la temperatura máxima, es posible realizar importantes ahorros en el consumo de energía al tiempo que se limita la caída en el rendimiento.
Distribución de datosLa distribución de datos en cada nodo también puede influir en el rendimiento y el consumo de MapReduce. Para las medidas, tenemos un ejemplo con un archivo de 500 MB y uno de 1 GB.
En los 2 gráficos, vemos 2 puntos de intersección, el primero ocurre cuando la relación tarea / nodo es 1 (esto significa que hay tantas tareas como nodos). El segundo ocurre cuando la relación es 2. Esto puede explicarse por el hecho de que el tiempo de ejecución entre el nodo más rápido y el nodo más lento es menor que el tiempo de ejecución de la tarea. Esto implica que cada nodo ha recibido dos tareas. Sin embargo, cuando el ratio es 3, las tareas son mucho más cortas, lo que implica que el tiempo de ejecución entre el nodo más rápido y el nodo más lento es mayor que el tiempo de ejecución de la tarea. En el resto del trabajo en este framework, se implementará un método para saber cómo distribuir las tareas de manera eficiente. Podemos notar que la temperatura máxima aún juega un papel muy importante en la velocidad de ejecución.
Demostrar que la temperatura máxima y la distribución de datos influyen en el consumo de energía. Se han realizado mediciones sobre el consumo de energía de un nodo en un clúster.
Podemos ver que hay dos picos de consumo para el archivo de 2 GB cuando la temperatura máxima es de 80 ° C. Esto sucede cuando se reprograma el nodo. Cuando el nodo no se reprograma y las tareas se acortan, la división de tareas aumenta y el consumo de energía disminuye.
Gracias a este marco, el consumo de energía de un nodo se ha reducido en un 36%. Este marco aún está en desarrollo pero ya está mostrando resultados muy interesantes.
Google ha obtenido una patente sobre la función MapReduce, pero se disputa la validez de esta patente.
Idioma | relación de velocidad del grupo | relación de velocidad del procesador | Ahorro de energía | Medio ambiente | |
---|---|---|---|---|---|
Hadoop | Java | 1 | CAROLINA DEL NORTE | CAROLINA DEL NORTE | Grupo |
BlobSeer | Java | 1,35 | CAROLINA DEL NORTE | CAROLINA DEL NORTE | Grupo |
marzo | Programación de GPU | CAROLINA DEL NORTE | 1.1 ~ 4 | CAROLINA DEL NORTE | Procesador de gráficos |
Fénix | C / C ++ | CAROLINA DEL NORTE | 1 | CAROLINA DEL NORTE | Procesador multinúcleo |
Marco ecológico | Java | CAROLINA DEL NORTE | CAROLINA DEL NORTE | 36% | Grupo |