ES A2 ESPAÑA 11. Número de publicación: Número de solicitud: G06F 9/00 ( )

Transcripción

1 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA Número de publicación: Número de solicitud: Int. CI.: G06F 9/00 ( ) 12 SOLICITUD DE PATENTE A2 22 Fecha de presentación: Fecha de publicación de la solicitud: Solicitantes: TELEFONICA S.A. (0.0%) GRAN VIA, MADRID ES 72 Inventor/es: URRUELA PLANAS, Andreu; GUNNAR ZANGELIN, Ken y ESCALADA SARDINA, José Gregorio 74 Agente/Representante: ARIZTI ACHA, Monica 4 Título: MÉTODO Y SISTEMA DE PROCESAMIENTO EN FLUJO CONTINUO EN UNA PLATAFORMA DE CÁLCULO DISTRIBUIDA DE MAPEO Y REDUCCIÓN 7 Resumen: Un método y un sistema de procesamiento en flujo continuo en una plataforma de cálculo distribuida de mapeo y reducción. El método comprende dicha plataforma de cálculo distribuida que comprende al menos un agrupamiento con una pluralidad de nodos con capacidad de cálculo, usando el método información relativa a un estado asociado a al menos operaciones de reducción, el método comprende generar dicho estado como resultado de una operación de reducción realizada por un nodo, en forma de una cola de salida, y usar dicho estado como cola de entrada de una operación de reducción posterior realizada por dicho nodo, formando dicha coa de salida y dicha cola de entrada una única cola que se actualiza tras el procesamiento de operación de reducción. El sistema está dispuesto para implementar el método de la presente invención. ES A2

2 DESCRIPCION Método y sistema de procesamiento en flujo continuo en una plataforma de cálculo distribuida de mapeo y reducción. Campo de la técnica La presente invención se refiere en general, en un primer aspecto, a un método de procesamiento en flujo continuo en una plataforma de cálculo distribuida de mapeo y reducción (map and reduce), y más específicamente a un método para optimizar el rendimiento del procesamiento de un flujo de datos continuo en una plataforma de cálculo distribuida. Un segundo aspecto de la invención se refiere a un sistema dispuesto para implementar el método del primer aspecto. Por estado, se entenderá cualquier información de interés que debe mantenerse y actualizarse de manera continua su evolución a lo largo del tiempo (por ejemplo un perfil de usuario para recomendaciones). Este estado contendrá toda la información relevante para cada elemento que va a modelarse. Estado de la técnica anterior La gran cantidad (creciente) de datos generados y disponibles en la actualidad ha llevado al desarrollo de paradigmas, plataformas y aplicaciones para procesar y crear valor de toda esta información. Este proceso se ha estimulado por la aparición del paradigma MapReduce (o map and reduce, MR) y su implementación en un proyecto de fuente abierta (Apache Hadoop) y un ecosistema de productos orientado a soluciones para grandes datos. En este ecosistema, también pueden encontrarse soluciones NoSQL. Pero cada vez más, grandes no sólo significa gran cantidad sino también requisitos más estrictos en otras dimensiones del espacio de solución. Apache Hadoop es óptimo para tareas simples de procesamiento por lotes con terabytes y petabytes de datos implicados, pero las empresas e instituciones se enfrentan a tareas más complejas: cálculo de gráficos, análisis interactivo, uniones complejas, requisitos de atomicidad, consistencia, aislamiento y durabilidad (ACID), requisitos en tiempo real o la necesidad de actualizaciones crecientes continuas (manteniendo todas ellas la necesidad de procesar el volumen de información relevante generada). Estos requisitos se cubren con diferentes estrategias: evoluciones del paradigma MapReduce y su implementación, soluciones especializadas para procesamiento de gráficos, soluciones de procesamiento de eventos complejos (CEP), e incluso una tendencia a la innovación en SQL [1] En 2004, Google presentó el paradigma MapReduce [2], un modelo de programación para expresar cálculos distribuidos en conjuntos de datos masivos y un marco de ejecución para procesamiento de datos a gran escala. Permite distribuir problemas de datos muy grandes en un agrupamiento de máquinas. La teoría sobre procesamiento distribuido y paralelo ha estado en el centro de la ciencia de la información durante mucho tiempo (y MR se basa en principios de programación funcional), aunque la nueva propuesta llegó justo a tiempo para solucionar un problema en crecimiento de manejar nuevas fuentes de datos y extraer información y el valor de las mismas. Mucho antes, ya existía la necesidad de trabajar con grandes conjuntos de datos [3]. RDBMS también han evolucionado a sistemas cada vez más grandes. Los sistemas CEP han tenido su sitio durante algunos años, y recientemente, cada vez más se están ampliando para hacer frente a los problemas de grandes datos Pero MR todavía constituye el núcleo del procesamiento de grandes datos, y está desarrollándose para solucionar los nuevos problemas que surgen. Al principio existía la necesidad de procesar una gran cantidad de datos de manera distribuida para obtener soluciones en un tiempo razonable, y el paradigma MR en 2004 y su implementación de fuente abierta con Apache Hadoop constituyeron la solución óptima. Entonces el espacio distribuido de clave-valores resultaron ser útiles para almacenar y recuperar información de manera económica. Este fue el origen de las soluciones BigTable y Dynamo, y una serie de productos (Cassandra, MongoDB...). Ahora la atención se dirige al procesamiento en tiempo real. Este camino proporciona nuevas soluciones basándose en MR (Google s Percolator, Yahoo s S4) y una serie de evoluciones MR para mejorar el tiemporespuesta. La solución propuesta también es una evolución de MR, de modo que estos antecedentes técnicos presentarán en más detalle esta tecnología. 0 Implementación de MapReduce y Apache Hadoop MapReduce (MR) es un paradigma que ha evolucionado a partir de la programación funcional y que se aplica a sistemas distribuidos. Se presentó en 2004 por Google [2]. Está previsto para procesar problemas cuya solución puede expresarse en funciones conmutativas y asociativas. 2

3 En esencia, MR ofrece una abstracción para procesar grandes conjuntos de datos en un conjunto de máquinas, configurado en un agrupamiento. Con esta abstracción, la plataforma puede resolver fácilmente el problema de sincronización, liberando así al desarrollador de tener que pensar en este tema Todos los datos de estos conjuntos de datos se almacenan, procesan y distribuyen en forma de pares de clavevalor, en los que tanto la clave como el valor pueden ser de cualquier tipo de datos. A partir del campo de programación funcional, se demuestra que cualquier problema cuya solución puede expresarse en términos de funciones conmutativas y asociativas, puede expresarse en dos tipos de funciones: mapeo (también denominado mapeo en el paradigma de MR) y pliegue (denominado reducción en el paradigma de MR). Cualquier trabajo debe expresarse como una secuencia de estas funciones. Estas funciones tienen una restricción: operan en algunos datos de entrada, y producen un resultado sin efectos secundarios, es decir sin modificar ni los datos de entrada ni ningún estado global. Esta restricción es el punto clave para permitir una fácil paralelización. Dada una lista de elementos, el mapeo toma como argumento una función f (que toma un único argumento) y lo aplica a todos los elementos en una lista (la parte superior de la figura 1), que devuelve una lista de resultados. La segunda etapa, pliegue, acumula un nuevo resultado mediante iteración a través de los elementos en la lista de resultados. Toma tres parámetros: un valor de base, una lista, y una función, por ejemplo. Normalmente, mapeo y pliegue se usan en combinación. La salida de una función es la entrada de la siguiente (puesto que la programación funcional evita datos mutables y de estado, todo el cálculo debe progresar pasando resultados de una función a la siguiente), y este tipo de funciones puede realizarse en cascada hasta finalizar la tarea. En el tipo de mapeo de la función, se aplica un cálculo especificado por usuario en todos los registros de entrada en un conjunto de datos. Como el resultado depende sólo de los datos de entrada, la tarea puede dividirse entre cualquier número de instancias (los mapeadores), trabajando cada uno de los mismos en un subconjunto de los datos de entrada, y puede distribuirse entre cualquier número de máquinas. Estas operaciones se producen en paralelo. Se procesa cada par de clave-valor de los datos de entrada, y pueden producir ninguno, uno o múltiples pares de clave-valor, con la misma o diferente información. Dan lugar a una salida intermedia que luego se envía a las funciones de reducción. La fase de reducción tiene la función de agregar los resultados diseminados en la fase de mapeo. Con el fin de realizar esto, todos los resultados de todos los mapeadores se clasifican por el elemento clave del par de clavevalor, y la operación se distribuye entre varias instancias (los reductores, que también se ejecutan en paralelo entre las máquinas disponibles). La plataforma garantiza que todos los pares de clave-valor con la misma clave se presentan al mismo reductor. Esta fase tiene entonces la posibilidad de agregar la información emitida en la fase de mapeo. El trabajo que va a procesarse puede dividirse entre cualquier número de implementaciones de estos ciclos de dos fases La plataforma proporciona el marco para ejecutar estas operaciones distribuidas en paralelo en varias CPU. El único punto de sincronización es en la salida de la fase de mapeo, en la que todos los pares de clave-valor deben estar disponibles para clasificarse y redistribuirse. De esta manera, el desarrollador sólo tiene que preocuparse por la implementación (según las limitaciones del paradigma) de las funciones de mapeo y reducción, y la plataforma oculta la complejidad de distribución y sincronización de datos. Básicamente, el desarrollador puede acceder a recursos combinados (CPU, disco, memoria) de toda la agrupación, de una manera transparente. La utilidad del paradigma surge cuando se trata con problemas de datos grandes, en los que una única máquina no tiene suficiente memoria para gestionar todos los datos o su disco local no sería lo suficientemente grande y rápido para afrontar todos los datos. Todo el proceso puede presentarse en un ejemplo sencillo y típico: el cálculo de frecuencia de palabras en un conjunto grande de documentos. Se muestra un algoritmo de recuento de palabras sencillo en MapReduce en la figura 2. Este algoritmo cuenta el número de apariciones en cada palabra en una recopilación de texto. Los pares de clave-valor de entrada adoptan la forma de pares (docid, doc) almacenados en el sistema de archivos distribuidos, en los que el primero es un identificador único para el documento, y el último es el contenido del documento. El mapeador toma un par de clave-valor de entrada, analiza mediante testigos el documento, y emite un par de clave-valor intermedio para cada palabra. La clave sería una cadena (la propia palabra) mientras que el valor es el recuento de las apariciones de la palabra (un número entero). En una aproximación inicial, será un 1 (indicando que se ha observado la palabra una vez). El marco de ejecución de MapReduce garantiza que todos los valores asociados con la misma clave se reúnen en el reductor. Por tanto, el reductor simplemente necesita sumar todos los recuentos (unos) asociados con cada palabra, y emitir pares de clave-valor finales con la palabra como la clave, y el recuento como el valor. Este paradigma ha tenido una serie de diferentes implementaciones: la ya presentada por Google, patente US , el proyecto de fuente abierta de Apache Hadoop, que es la implementación más destacada y ampliamente usada, y una serie de implementaciones del mismo concepto: Sector/Sphere (escrito en Erlang). 3

4 Microsoft también ha desarrollado un marco para el cálculo en paralelo, Dryad, que es una especie de superconjunto de MapReduce Estas implementaciones se han desarrollado para resolver una serie de problemas (planificación de tareas, escalabilidad, tolerancia a fallos...). Un problema de este tipo es cómo garantizar que cada tarea tenga los datos de entrada disponibles tan pronto como sea necesario, sin que la entrada/salida del disco y la red provoquen un cuello de botella en el sistema (una dificultad inherente en problemas de grandes datos). La mayoría de estas implementaciones (Google, Hadoop, Sphere, Dryad...) se basan en datos de un sistema de archivo distribuido para gestión de datos. Los archivos de datos se dividen en grandes segmentos (por ejemplo de 64 MB), y estos segmentos se almacenan y replican para dar una serie de nodos de datos. Las tablas muestran un seguimiento de la manera en que los archivos de datos se dividen y dónde reside la réplica para cada segmento. Cuando se planifica una tarea, puede consultarse el sistema de archivo distribuido para determinar el nodo que tiene los datos requeridos para cumplir con la tarea. Se selecciona el nodo que tiene los datos (o uno cercano) para ejecutar la operación, reduciendo el tráfico de red. El problema principal de este modelo es la latencia aumentada. Los datos pueden distribuirse y procesarse en un número muy grande de máquinas, y la sincronización se proporciona mediante la plataforma de una manera transparente al desarrollador. Pero esta facilidad de uso tiene un precio: no puede iniciarse ninguna operación de reducción hasta que todas las operaciones de mapeo hayan finalizado y sus resultados se encuentren en el sistema de archivo distribuido. Estas limitaciones aumentan el tiempo de respuesta, y este tiempo de respuesta limita el tipo de soluciones al que puede aplicarse una solución MR convencional. Éste es el motivo principal para una serie de evoluciones del modelo, centradas en mejorar el tiempo de respuesta. Las principales propuestas de modificación son: Twister: Las implementaciones originales [4] se centran en realizar MapReduce de una etapa (cálculos que implican sólo una aplicación de MapReduce) con mejor tolerancia a fallos, y por tanto almacenan la mayoría de las salidas de datos en alguna forma de sistema de archivo en todo el cálculo. La aplicación repetitiva de MR crea nuevas tareas de mapeo/reducción en cada iteración cargando o accediendo a cualquier dato estático de manera repetida. Esta estrategia introduce sobrecargas de rendimiento considerables para muchas aplicaciones iterativas. Twister es una ejecución de MapReduce mejorada que usa infraestructura de mensajería para transferencias de datos y comunicación, y soporta tareas de mapeo/reducción de larga ejecución. Los datos intermedios se mantienen en la memoria. MapReduce en línea []: Otro factor con un impacto directo en la latencia es la necesidad de sincronización al comienzo de la operación de reducción. No puede iniciarse hasta que todas las tareas de mapeo hayan finalizado, de modo que el tiempo de respuesta es muy sensible a los rezagados. Además, como toda la salida de cada tarea se materializa en un archivo local (o distribuido), no es posible devolver los resultados de una consulta hasta que haya finalizado toda la tarea. En esta evolución, la arquitectura propuesta canaliza los datos entre operadores, mientras se conservan las interfaces de programación y modelos de tolerancia a fallos del marco original. MapReduce basado en hash [6]: las implementaciones de MapReduce requieren que se cargue todo el conjunto de datos en el agrupamiento antes de ejecutar consultas analíticas, incurriendo así en largas latencias y haciéndolas inadecuadas para producir resultados incrementales. Para soportar un análisis incremental, deben evitarse operaciones de bloqueo y cuellos de botella de cálculo y E/S. En esta solución, se sustituye una implementación de clasificación-fusión por un marco puramente basado en hash, que se diseña para abordar los problemas de la clasificación-fusión. Procesamiento en masa con estado [7]: Ésta es la implementación de arquitectura para un procesamiento en masa continuo (CBP). El núcleo es un operador de procesamiento por grupos flexible, que toma el estado como una entrada explícita. Una programación con estado unificadora con un operador de datos en paralelo logra oportunidades para minimizar el movimiento de datos en el sistema de procesamiento subyacente. Este nuevo operador realiza una traslación. Se ejecuta de manera repetida, permitiendo a los usuarios almacenar y recuperar fácilmente el estado cuando llegan nuevas entradas de datos. El modelo se implementa sobre una plataforma MapReduce (Hadoop). Pero no es suficiente una emulación de caja negra, porque da como resultado un movimiento de datos y uso de espacio excesivo. Así las modificaciones se realizaron en la implementación de Hadoop para soportar el modelo de CPB completo y para optimizar el tratamiento del estado: múltiples entradas y salidas organización incremental para flujos en bucle acceso aleatorio de estado al índice encaminamiento de multidifusión y difusión 4

5 También hay otras soluciones que, aunque inspiradas por MR, son una ruptura completa con este modelo. También abordan el problema de larga latencia, y cada vez más se orientan a un análisis en tiempo real: Dryad: El cálculo está estructurado como un grafo directo: los programas son vértices del grafo, mientras que los canales son las aristas del grafo. Un trabajo de Dryad es un generador de grafos que puede sintetizar cualquier grafo acíclico dirigido. Estos grafos pueden incluso cambiar durante la ejecución, en respuesta a eventos importantes en el cálculo. Dryad es bastante expresivo. Subsume completamente otros marcos de cálculo, tales como mapeo-reducción de Google, o el álgebra relacional. Además, Dryad maneja la creación y gestión de tareas, gestión de recursos, monitorización y visualización de tareas, tolerancia a fallos, reejecución, planificación y contabilidad. Percolator [8]: Después de presentar map&reduce para crear el índice web para su servicio de búsqueda, Google observó que la construcción del índice completo desde cero producía una gran latencia: deben rastrear toda la web, y entonces procesarla con cientos de ciclos map&reduce. El reprocesamiento de toda la web descartó el trabajo realizado en ejecuciones anteriores e hizo la latencia proporcional al tamaño del repositorio, en lugar del tamaño de una actualización. Construyeron Percolator, un sistema para procesar de manera incremental actualizaciones para un gran conjunto de datos, y sobre el mismo el sistema de indexación Caffeine. Percolator proporciona una interfaz para acceder al sistema de almacenamiento distribuido Bigtable [9]. Bigtable proporciona operaciones de consulta y actualización, y transacciones con operaciones leer-modificar-escribir atómicas en filas individuales. Percolator mantiene la esencia de la interfaz de Bigtable: los datos se organizan en filas y columnas de Bigtable, almacenándose los metadatos de Percolator unos al lado de otros en columnas especiales. Pero Percolator proporciona las características que Bigtable no proporciona: transacciones de múltiples filas y el marco para ejecutar operaciones complejas en forma de observadores, partes de código que se invocan por el sistema siempre que cambie una columna especificada por el usuario. Las aplicaciones de Percolator están estructuradas como una serie de observadores; cada observador completa una tarea y crea más trabajo para observadores en cascada al escribir en la tabla. System S Streams (flujos continuos de Sistema S) (InfoSphere Streams, flujos continuos InfoSphere): System S (también denominado flujos continuos InfoSphere) es un middleware de procesamiento de flujo continuo de datos distribuido a gran escala. En esencia, un CEP mejorado, pero ofrece: Escalabilidad horizontal Soporte para tipos de datos complejos 30 3 Seguridad y robustez industrial general La arquitectura InfoSphere Streams representa un cambio significativo en capacidad y organización de sistema de cálculo. Aunque tenga cierta similitud con los sistemas de procesamiento de eventos complejos (CEP), se construye para soportar tasas de transmisión de datos mayores y un espectro más amplio de modalidades de datos de entrada. También proporciona un soporte de infraestructura para abordar las necesidades de escalabilidad y adaptabilidad dinámica, como planificación, equilibrio de carga, y alta disponibilidad. En InfoSphere Streams las aplicaciones continuas están compuestas por operadores individuales, que se interconectan y operan en múltiples flujos continuos de datos. Los flujos continuos de datos pueden proceder del exterior del sistema o producirse internamente como parte de una aplicación En este marco, SPADE [] proporciona un juego de herramientas de tipo genérico, operadores de procesamiento de flujo continuo integrados (también proporciona un lenguaje intermedio para la descomposición flexible de grafos de flujo de datos distribuidos y en paralelo, y un conjunto de adaptadores de flujo continuo para ingerir y publicar datos). Las aplicaciones desarrolladas y optimizadas con SPADE se ejecutan de manera natural en el núcleo de procesamiento de flujo continuo. Los datos a partir de flujos continuos de datos de entrada que representan miles de tipos y modalidades de datos fluyen al sistema. El esquema de las operaciones realizadas en esos datos de flujo continuo se determina mediante componentes de sistema de alto nivel que trasladan los requisitos del usuario a aplicaciones de ejecución. S4: S4 es una plataforma de propósito general, distribuida, escalable, parcialmente tolerante a fallos, conectable que permite a los programadores desarrollar fácilmente aplicaciones para procesar flujos continuos ilimitados de datos. S4 se desarrolló inicialmente para personalizar productos de publicidad de búsqueda en Yahoo!, que operan a una tasa de transmisión de miles de eventos por segundo. En S4, los eventos de datos codificados se encaminan con afinidad a elementos de procesamiento (PE), que consumen los eventos y realizan uno o ambos de los siguientes emiten uno o más eventos que pueden consumirse por otros PE,

6 publican resultados, posiblemente para un consumidor o almacenamiento de datos externo. La arquitectura se parece al modelo Actors [2], que proporciona una semántica de encapsulación y transparencia de ubicación, permitiendo así que las aplicaciones sean simultáneas de manera masiva mientras que se expone una única interfaz de programación para desarrolladores de aplicación. Esta elección de diseño también hace relativamente fácil razonar acerca de la exactitud debido a la ausencia general de efectos colaterales. S4 es lógicamente un sistema de paso de mensaje: unidades de cálculo, denominadas elementos de procesamiento (PE), mensajes de envío y recepción (denominados eventos). El marco de S4 define una API que todo PE debe implementar, y proporciona facilidades que ejemplifican PE y para transportar eventos. Los eventos en S4 son objetos Java arbitrarios que pueden pasarse entre PE. Los adaptadores convierten fuentes de datos externos en eventos que S4 puede procesar. Puede accederse a los atributos de los eventos a través de elementos de extracción de PE. Éste es el modo exclusivo de comunicación entre PE. Los eventos se distribuyen en denominados flujos continuos determinados. Estos flujos continuos están identificados por un nombre de flujo continuo con valor de cadena. 1 Los elementos de procesamiento (PE) son las unidades de cálculo básicas en S4. Consumen eventos y a su vez pueden emitir nuevos eventos y actualizar su estado. Cada instancia de un PE se identifica de manera única por cuatro componentes: su funcionalidad según se define por una clase de PE y configuración asociada, el flujo continuo determinado que consume, el atributo codificado en esos eventos, y 20 2 el valor del atributo codificado en eventos que consume. Cada PE consume exactamente aquellos eventos que corresponden al valor con respecto al que se codifica. Puede producir eventos de salida. Obsérvese que se instancia un PE para cada valor del atributo de clave. Esta instanciación se realiza por la plataforma. Por ejemplo, en una aplicación de recuento de palabras imaginaria, WordCountPE se instancia para cada palabra en la entrada. Cuando se observa una nueva palabra en un evento, S4 crea una nueva instancia del PE que corresponde a esa palabra. Varios PE están disponibles para tareas convencionales tales como recuento, agregar, unir, etc. Pueden lograrse muchas tareas usando PE convencionales lo que no requiere ninguna codificación adicional. La tarea se define usando un archivo de configuración. Los PE personalizados pueden programarse fácilmente usando las herramientas de desarrollo de software de S Problemas con las soluciones existentes Como se ha mostrado, el paradigma MapReduce original y su implementación de fuente abierta (Apache Hadoop) son bastante adecuados para un procesamiento por lotes, tomar una cantidad muy grande de datos como entrada, procesarlos y generar una salida. El problema de larga latencia de estas soluciones no es un obstáculo grave, siempre que se usen en los escenarios para los que se diseñaron. Pero cuando se necesita una respuesta rápida, y cuando las soluciones deben mantener un estado actualizado con los nuevos datos, este modelo empieza a ser ineficaz. Incluso frente a la falta de un modelo para soportar un estado interno (la única solución disponible en esta tecnología es procesar datos de entrada, emitir datos de estado como cualquier otro dato de salida, y cuando se finaliza todo el procesamiento por lotes, volver a leer el estado como entrada. Puesto que estos problemas de la solución convencional ya se asumen y se detallan en la mayoría de las referencias de las soluciones existentes (puesto que todos presentan soluciones a estos problemas), este documento no profundizará en los mismos. El análisis se centrará en las nuevas soluciones propuestas. Hay un número bastante grande de soluciones propuestas para resolver el problema de proceso en tiempo real o flujo continuo en un escenario de grandes datos. Para simplificar el análisis, se agruparán por la tecnología subyacente: 4 RDBMS tradicional Sistemas basados en implementación de MapReduce y Apache Hadoop Procesamiento de eventos complejos orientado a soluciones Otros paradigmas 6

7 RDBMS tradicional Los sistemas de gestión de flujo continuo de datos se centran en un procesamiento casi en tiempo real de datos que llegan de manera continua, de modo que deben ser próximos al procesamiento de flujo continuo. De hecho, se usan soluciones y estrategias de bases de datos en paralelo en el núcleo de las plataformas de procesamiento de flujo continuo, como Percolator. Pero si no se construye ninguna otra inteligencia alrededor de la base de datos, para que esta solución sea eficaz, los registros deben residir en la memoria, que limita (o encarece o hace imposible) la disponibilidad para problemas de datos muy grandes. Puesto que se han diseñado para proporcionar una respuesta rápida a consultadas realizadas por un operador humano, los sistemas de base de datos tienden a enfatizar la latencia sobre el rendimiento global, de modo que habitualmente no puede funcionar con la tasa de transmisión de entrada de datos requerida. Este límite también se ve afectado por el requisito de ACID. Soluciones basadas en MapReduce 1 20 La mayoría de las soluciones basadas en MapReduce se implementan en la plataforma de Apache Hadoop, así, aunque todas ellas logran una mejor respuesta frente a una latencia inferior, aún tienen que hacer frente a una arquitectura diseñada para trabajar con problemas de procesamiento por lotes bastante grandes. Y no hay ninguna implementación en la arquitectura de Apache Hadoop para soportar un estado distribuido, accesible y actualizable para todas las tareas. Las soluciones propuestas que ofrecen un estado deben basarse en un objeto estático y/o un almacenamiento externo para proporcionarlo. Twister optimiza iteraciones en tareas de MapReduce, permitiendo un acceso a un estado estático. Las tareas de mapeo y reducción pueden persistir a través de iteraciones, amortizando el coste de carga del estado estático. Sin embargo, el estado no puede cambiar durante la iteración. Otra limitación es que el estado debe encajar en la memoria, puesto que se trata como datos estáticos y no se gestiona por la plataforma distribuida. MapReduce en línea permite ejecutar tareas de manera continua, pero de nuevo el estado debe ser una estructura interna a cada tarea, y debe encajar completamente en la memoria. 2 El procesamiento de bloques con estado es la solución existente más cercana a la invención propuesta. El estado se dota de BIPtables, con acceso aleatorio por indexación. Ésta es una solución eficaz cuando la actualización afecta a una parte muy pequeña del estado. Soluciones orientadas a CEP 30 Los sistemas de CEP (System S, S4) se centran en digerir y procesar eventos de entrada a medida que llegan. No hay un concepto explícito de estado, y aunque puede implementarse como almacenamiento local en memoria asociado a los nodos de procesamiento, no escala: todo el estado debe encajar en la memoria, puesto que no hay ningún soporte para distribuir el estado entre las máquinas en el agrupamiento. El problema principal de las soluciones orientadas a CEP (System S, S4) es la necesidad de todo el estado de encajar en la memoria. Otro 3 40 Dryad, aunque más flexible, con respecto a los requisitos de procesamiento en flujo continuo, utiliza la misma estrategia que map&reduce convencional. Las soluciones propuestas [11] para reducir la latencia son para identificar automáticamente el cálculo redundante; oculta resultados anteriores para evitar la reejecución de las fases o fusionar los cálculos con una nueva entrada. Pero esta solución está fuera del control del programador, de modo que no es posible recuperar y trabajar en este pseudoestado. Dryad no ofrece una base para la gestión de estados. Una solución que aplica un enfoque diferente a MapReduce y que no sufre de la limitación de estado en memoria es Percolator de Google. 4 0 De la misma manera que MapReduce se diseñó para construir su índice web, esta plataforma se ha diseñado para actualizarlo cuando se ha rastreado una parte muy pequeña de la web. El tema principal es la consistencia del estado (el índice). Consume incluso más recursos que el MapReduce original (aunque la manera incremental de trabajar y la reducción en la latencia hacen que los recursos adicionales valgan la pena). Percolator de Google es la solución adecuada para el problema de actualizar de manera continua el índice de web, pero puede ser inadecuada para los problemas típicos a los que se enfrentaría operador de telecomunicaciones: actualizar de manera continua el perfil de usuario basándose en registros de datos de llamada (CDR), información de red móvil, logaritmos de navegación, etc. Por un lado, el dominio del problema no es tan grande como generar un índice web, de modo que el agrupamiento grande necesario por Percolator puede no ser económicamente eficaz para problemas de tipo de telecomunicaciones. Por otro lado, Percolator ha mostrado ser menos eficaz que construir de nuevo todo el índice desde cero cuando la tasa de actualización es significativamente alta. Esto se debe a que la consulta a Bigtable para recuperar la 7

8 información de estado para cada clave es mucho más lenta que leer todo el estado como un conjunto de datos. Esta ineficacia no es un problema con el trillón de páginas web en la web (y así el repositorio de índice), porque cada actualización afectará sólo a una fracción muy pequeña de éstas. Pero tal como ya se mencionó, los problemas de grandes datos de las compañías de telecomunicaciones pueden suponer una gran parte del estado visitado de nuevo en cada acción de ejecución, de modo que esta solución puede ser muy ineficaz. Descripción de la invención Es necesario ofrecer una alternativa al estado de la técnica que cubra las lagunas halladas en la misma, particularmente en relación con la falta de propuestas que realmente permitan la optimización para realizar el procesamiento de un flujo de datos continuo en una plataforma de cálculo distribuida Con ese fin, la presente invención proporciona, en un primer aspecto, un método de procesamiento en flujo continuo en una plataforma de cálculo distribuida de mapeo y reducción, comprendiendo dicha plataforma de cálculo distribuida al menos un agrupamiento con una pluralidad de nodos con capacidad de cálculo, usando el método información relativa a un estado asociado a al menos operaciones de reducción. Al contrario de las propuestas conocidas, el método del primer aspecto de la invención, comprende generar dicho estado como resultado de una operación de reducción realizada por un nodo, en forma de una cola de salida, y usar dicho estado como cola de entrada de una operación de reducción posterior realizada por dicho nodo, formando dicha cola de salida y dicha cola de entrada una única cola que se actualiza tras el procesamiento de operación de reducción. Otras realizaciones del método del primer aspecto de la invención se describen según las reivindicaciones adjuntas 2 a 12, y en una sección posterior relacionada con la descripción detallada de varias realizaciones. Un segundo aspecto de la presente invención comprende en general un sistema de plataforma de cálculo distribuida para procesamiento en flujo continuo de mapeo y reducción, comprendiendo dicha plataforma de cálculo distribuida al menos un agrupamiento con una pluralidad de nodos con capacidad de cálculo y configurado para realizar al menos operaciones de reducción usando información relativa al estado asociado a las mismas. Al contrario de las propuestas conocidas, en el sistema del segundo aspecto de la presente invención al menos uno de dichos nodos comprende al menos una cola de estado de entrada y al menos una cola de estado de salida, dicho al menos un nodo está configurado para generar dicho estado como resultado de una operación de reducción realizada por dicho al menos un nodo y proporcionar dicho resultado a dicha al menos una cola de salida de estado, y dichas colas de estado de entrada y de salida están interconectadas formando una única cola de modo que hay una realimentación desde dicha cola de estado de salida a dicha cola de estado de entrada. Otras realizaciones del segundo aspecto de la invención se describen según las reivindicaciones adjuntas 14 a 18, y en una sección posterior relacionada con la descripción detallada de varias realizaciones. Breve descripción de los dibujos 3 Las ventajas y características anteriores y otras se entenderán más completamente a partir de la siguiente descripción detallada de realizaciones, con referencia a los dibujos adjuntos, que deben considerarse de una manera ilustrativa y no limitativa, en los que: la figura 1 muestra un ejemplo de un diagrama de programación funcional, con funciones de mapeo (f) y pliegue (g). 40 La figura 2 muestra un ejemplo de la implementación del algoritmo de recuento de palabras en MapReduce. La figura 3 muestra la gestión lógica del flujo de datos usada en un modo de procesamiento por lotes. La figura 4 muestra el diagrama de distribución de datos usado en el modo de procesamiento por lotes. 4 La figura muestra el flujo de datos lógico en la salida de una operación distribuida. Se envía información inmediatamente al nodo trabajador de destino, en lugar de almacenarse localmente como en la implementación de Hadoop. La figura 6 muestra un ejemplo de la consolidación de claves-valores. La figura 7 muestra un ejemplo de la estructura de archivos de datos local. La figura 8 muestra un ejemplo de la lectura de claves-valores con grupo hash HG2 asociado en un conjunto de datos con tres archivos en el disco local del nodo trabajador. 8

9 La figura 9 muestra un ejemplo de la implementación de una operación de reducción de múltiples entradas/salidas. La figura muestra el esquema lógico del planificador de operación y la gestión de datos en las colas (bloques). La figura 11 muestra el flujo de datos en el modo de procesamiento en flujo continuo. La figura 12 muestra el flujo de datos en el modo de procesamiento en flujo continuo para un modo. La figura 13 muestra el flujo de datos en el modo de procesamiento en flujo continuo para múltiples nodos trabajadores. La figura 14 muestra la estrategia del gestor de bloque (BlockManager), según una realización de la presente invención. La figura 1 muestra el gestor de bloque en la arquitectura de nodo. La figura 16 muestra el modelo de estado de flujo continuo con una operación de reducción de 2 entradas, según una realización de la presente invención. La figura 17 muestra un ejemplo de la interpretación de una operación de reducción con estado como un sistema de CEP. 1 La figura 18 representa la distribución de estados y bloques en compartimentos, según una realización de la presente invención. La figura 19 ilustra cómo los bloques de datos de entrada se acumulan en compartimentos según las claves de los datos que contienen. La figura 20 representa un ejemplo del módulo de ruptura de bloque (BlockBreak). 20 Descripción detallada de varias realizaciones La invención propuesta propone una extensión de la tecnología de MapReduce que reduce eficazmente la latencia, implementa un procesamiento de continuo, flujo de datos continuo, y permite desarrollar soluciones con un estado que puede actualizarse a la tasa de transmisión de datos de llegada. 2 La invención también incluye un nuevo módulo para gestionar los bloques de pares de clave-valor. Este módulo mantiene en la memoria los próximos bloques necesarios que van a ejecutarse, y garantiza que se realizará una copia de seguridad de los bloques inactivos en el disco. Los objetivos principales resueltos por la invención son: Procesamiento de flujo continuo: las operaciones pueden planificarse en colas de datos, y pueden ejecutarse automáticamente cuando hay datos de entrada disponibles. 30 o Las colas pueden controlarse para especificar una latencia máxima. o Las colas pueden controlarse para especificar si los datos de entrada deben borrarse después del procesamiento, o si deben conservarse (por ejemplo, una cola con información estática que va a usarse en una operación de reducción de tipo JOIN). 3 o Latencia baja muy eficaz con un módulo de gestor de bloque que optimiza los recursos para mantener activos los bloques de datos en la memoria. Incluye el concepto de estado en la plataforma de MapReduce. o Este estado puede actualizarse de manera continua con los datos de entrada. o Para actualizar el estado de manera eficaz, se organiza como una división de los intervalos clave, de modo que sólo se procesa cuando hay datos para procesar. 40 o Los intervalos de grupos hash asignados a los compartimentos están distribuidos dinámicamente para mantener el tamaño del compartimento siempre bajo control. o La distribución de datos en compartimentos puede incluir una marca de tiempo, que puede proporcionar un manejo de datos más eficaz, y permite olvidar y borrar entradas de estado sin usar. 4 o El estado puede compartirse entre cualquier número de operaciones de reducción. 9

10 o El estado (y cualquier otra cola dinámica) puede congelarse en una base de datos estática, que va a procesarse más adelante en modo por lotes. La invención consiste en un sistema y un método para implementar una nueva capacidad de procesamiento de flujo continuo en plataformas de grandes datos de tamaño medio que trabajan con el paradigma MapReduce. Este nuevo sistema permite el desarrollo de soluciones con estado, en las que el estado puede actualizarse de manera continua y eficazmente a medida que llegan los datos de entrada. El nuevo sistema toma como base un método de gestión de datos que permite una implementación muy eficaz y de baja latencia de operaciones MapReduce en modo de procesamiento por lotes. El nuevo sistema absorbe y extiende este modelo para dar una nueva plataforma orientada al procesamiento de flujo continuo. Para explicar las características innovadoras de la nueva plataforma, se presentará el método de gestión de datos básico, aunque ya sea objeto de una solicitud de patente en tramitación. Gestión de operaciones en modo de procesamiento por lotes: 1 El escenario es una plataforma que implementa el paradigma MapReduce. Cualquier operación (mapeo, reducción) se distribuye entre los nodos en el agrupamiento. Cada nodo (o nodo trabajador) ejecuta una serie de instancias de estas operaciones. Cada una de estas instancias implica una secuencia de suboperaciones: 1. Se leen datos de entrada. Si es necesario (para operaciones de reducción), se realiza una clasificación en la clave. 2. Se ejecuta el propio grueso de la operación. Ésta es la parte de código escrita por el desarrollador que forma parte de una solución particular Se distribuyen datos de salida a los nodos de la plataforma. 4. En cada nodo, se recopilan y se almacenan localmente los datos generados de todos lados. Las primeras tres etapas se realizan distribuidas a través de todos los nodos trabajadores en la plataforma. Con la invención propuesta, siempre se garantiza que los datos y el procesamiento siempre son locales para el nodo trabajador, y la distribución de los datos se realiza en la memoria. 2 La invención se basa en cómo se realizan las suboperaciones 1), 3) y 4) y en cómo se crean, se distribuyen y se leen los conjuntos de datos, que consisten en grupos de pares de clave-valor. Las secuencias lógicas de gestión y distribución de datos se representan en la figura 3 y se explican en la siguiente sección de gestión de conjuntos de datos. Gestión de conjuntos de datos en modo de procesamiento por lotes 30 Se distribuyen los datos de salida a los nodos de la plataforma: En la salida de una operación (o bien el mapeo o bien la reducción), se generan pares de clave-valor y se emiten a un conjunto de datos específico (en la invención propuesta, una operación puede tener múltiples conjuntos de datos de salida, de modo que pueden producirse diferentes tipos de pares de clave-valor a partir de la misma operación) Se distribuyen pares de clave-valor para su nodo de almacenamiento sin pasar por el disco local del nodo de emisión, puesto que esta suboperación se realiza en la memoria y los datos se envían a través de la capa de red de plataforma. Este proceso se realiza sin necesidad de comunicarse con un controlador central, puesto que hay una estrategia fija para la distribución de datos en la plataforma, y cada nodo trabajador tiene esta estrategia. El esquema se muestra en la figura 4. Cuando una instancia de una operación (análisis sintáctico, mapeo o reducción) que se ejecuta en un nodo trabajador (n.º 2, por ejemplo) genera y emite un par de clave-valor (línea discontinua), se distribuye a través de la capa de red de plataforma al nodo de almacenamiento final (o nodos, si se está realizando redundancia). El criterio de distribución se basa en el campo de clave. Se calcula una función hash en la clave. El espacio de posibles resultados de la función hash se divide en partes con el fin de gestionar un número más práctico de grupos. Después de que las funciones de hash en la clave y división en partes, el par de clave-valor tiene un número asociado, que se usará para identificar a qué nodo trabajador va a enviarse, y también determinará cómo se almacenará en el mismo. Este número se denomina el grupo hash. Puede usarse una función convencional para calcular el hash y para realizar la división en partes de los datos, optimizada y asociada globalmente con el tipo de la clave, o puede proporcionarse por el usuario. Esto proporciona al desarrollador la libertad controlar la distribución de datos (y por tanto la tarea) para problemas específicos.

11 Conociendo el grupo hash de la clave, la plataforma (y cada nodo trabajador) también conoce a qué nodo trabajador pertenecen los datos (y por tanto, qué nodo debe ejecutar las operaciones en los datos con este mismo grupo hash). Los datos se envían por tanto al nodo trabajador (o nodos trabajadores) predefinido (figura ). La salida se gestiona en la memoria, y luego se envía a través de la red, sin escribirse al disco. Éste es uno de los aspectos principales de la invención. En otras soluciones ([2]), la salida de la operación se escribe en el disco local. Luego se clasifica, se organiza y se copia al sistema de archivos distribuidos, en el que se fusiona. Este movimiento de datos adicional tiene un gran impacto sobre el rendimiento. Por el contrario, la distribución de datos en memoria tiene el inconveniente de que si hay un fallo en la máquina, toda la operación debe ejecutarse de nuevo desde cero. Así la nueva solución no es muy adecuada para entornos en los que un fallo en la máquina pueda ser frecuente (agrupaciones muy grandes, con miles de máquinas). En cada nodo, los datos generados de todos lados, se recopilan y se almacenan localmente: En cada nodo (figura 6), los pares de clave-valor producidos en las instancias de operación que se ejecutan en los otros nodos trabajadores (y en sí mismo), con un grupo hash asignado a ese nodo trabajador, se reciben mediante un proceso dedicado (consolidador). Para cada grupo hash, los pares de clave-valor se mantienen en la memoria hasta que o bien se terminan las operaciones de fuente que se ejecutan en los nodos trabajadores, o bien se ha recopilado una parte lo suficientemente grande para enviarse a un archivo (es decir, 1 GByte). Todos los pares de clave-valor deben estar disponibles en la memoria porque tienen que escribirse en el archivo de disco como un todo, y deben clasificarse anteriormente. Entonces es posible enviarlos a un archivo de disco, de modo que se crea un archivo local que contiene todos los pares de clave-valor acumulados que van a procesarse (o replicarse) en el nodo trabajador. Si hay más pares de clave-valor pendientes, se acumularán en el próximo archivo. El uso de esta limitación de tamaño de archivo (es decir, 1 GB) puede producir una fragmentación de conjuntos de datos, se proporciona una orden de compactación que puede leer de nuevo todos los archivos de conjuntos de datos generados en cada nodo trabajador, y reorganizar los grupos hash en un nuevo conjunto de archivos de disco. La fragmentación de los grupos hash entre un gran número de archivos de disco puede tener un impacto negativo sobre el rendimiento, de modo que esta operación es muy útil cuando se use el mismo conjunto de datos como entrada a diferentes operaciones. La estrategia de distribución de pares de clave-valor, conjuntamente con esta posibilidad de compactar grupos hash, son la base de permitir adiciones al conjunto de datos manteniendo al mismo tiempo un buen rendimiento. La distribución conocida anteriormente (aunque flexible y modificable) de valores de grupo hash entre los nodos trabajadores garantiza la ubicación de operaciones y sus datos de entrada correspondientes. Esto simplifica la tarea de distribución y refuerza el rendimiento. Éste es otro aspecto principal de la invención. Se leen datos de entrada: 3 Se ha diseñado la estructura de los archivos de disco que contienen los conjuntos de datos para ofrecer el mejor rendimiento para la suboperación de lectura de datos de entrada. La estructura de un archivo de datos local es la misma para todos los nodos trabajadores y para todos los conjuntos de datos de clave-valor (figura 7). El archivo tiene tres partes: Una cabecera con información acerca del contenido de archivo y su tipo y codificación. 40 Una estructura por identificador de grupo hash (normalmente 636, pero este número puede cambiarse en la plataforma cuando se trata con conjuntos de datos muy grandes). Cada estructura tiene: O El desplazamiento a la sección de archivo en el que se almacenan los pares de clave-valor que corresponden al grupo hash seleccionado. 4 O El tamaño del conjunto de pares de clave-valor que pertenece al grupo hash (esta información podrá calcularse a partir del desplazamiento del próximo grupo hash, pero el coste de tamaño adicional simplifica la gestión). Toda la secuencia de pares de clave-valor que corresponde a los grupos hash representados en el archivo. 0 Se pretende que los archivos tengan un tamaño de 1 GB (configurable). Si los pares de clave-valor de conjunto de datos que van a procesarse por el nodo trabajador son más grandes que el tamaño de archivo, su sección del conjunto de datos se contendrá en más de un archivo. Si no hay suficientes pares de clave-valor para llenar el archivo de 1 GB, puede ser más pequeño. Tal como se presenta en la figura 7, para todos los archivos de conjunto de datos en cada nodo trabajador, se reserva espacio para representar todos los posibles grupos hash (desde 0 hasta 636). La estrategia de 11

12 distribución garantiza que en cada nodo trabajador, sólo llegarán y se almacenarán pares de clave-valor que tienen grupos hash específicos, y de ese modo sólo se usará un subconjunto de este espacio (diferente subconjunto en diferentes nodos trabajadores). Esto representa una pequeña penalización, pero simplifica la gestión de datos y ofrece una manera sencilla para trabajar con archivos duplicados a través de los nodos de agrupación, y de ese modo proporciona algo de tolerancia de fallos. Cuando deben leerse los pares de clave-valor, con el fin de procesarse, el nodo trabajador recupera sus grupos hash designados. Conociendo el tamaño de los datos asociados a cada grupo hash, y el tamaño de memoria disponible para la operación, lee el tamaño máximo de pares de clave-valor en una sola parte, reduciendo de ese modo el número de operaciones E/S y maximizando el rendimiento global. En cada archivo, la parte correspondiente a los pares de clave-valor solicitados es lo suficientemente grande para permitir una implementación eficaz de la función de lectura. En la figura 8, los pares de clave-valor de un conjunto de datos se han almacenado en tres archivos en el disco local del nodo trabajador. Con el fin de recuperar los datos correspondientes a un conjunto de grupos hash (desde el grupo hash N hasta el grupo hash N+k, para un tamaño total de 1 GB) la plataforma debe leer en los tres archivos. A medida que un grupo hash se distribuye entre cada vez más archivos de disco, la función de lectura puede ser cada vez menos eficaz (muchas lecturas de tamaño pequeño). La funcionalidad de compactación presentada anteriormente realiza una desfragmentación de la distribución de grupo hash, y permite recuperar la eficacia de lectura. Si es necesario (si la operación que va a ejecutarse es una reducción), se ejecuta una clasificación local en cada grupo hash. Cada operación de clasificación es muy eficaz puesto que se realiza con los pares de clave-valor a partir de cada grupo hash, y se realiza en la memoria después de leer el grupo hash. Con esta arquitectura, no hay restricción al número de conjuntos de datos de entrada que puede tener una operación. En particular, esta propiedad simplifica y acelera operaciones tales como operaciones JOIN, muy frecuentes y en aplicaciones de datos grandes orientadas a bases de datos. Esta estructura es clave para la gestión de datos en la plataforma. Esta funcionalidad se describe completamente en la próxima sección, puesto que constituye una de las reivindicaciones principales de la invención. Operaciones de entradas múltiples, salidas múltiples: En la sección anterior, se ha presentado una nueva estrategia de gestión de datos para conjuntos de datos de clave-valor de MapReduce, con pares de clave-valor fijos distribuidos por grupo hash. 30 Esta estrategia de distribución garantiza que todos los pares de clave-valor con una clave común, a partir de todos los conjuntos de datos en la plataforma, se almacenan en el disco local de la misma máquina. Otra innovación en esta implementación de MapReduce es permitir que cualquier operación de mapeo o reducción tenga varios conjuntos de datos de entrada o salida (las operaciones de mapeo de múltiples entradas no tienen mucho sentido) Una consecuencia inmediata de tener todos los pares de clave-valor con una clave común, a partir de todos los conjuntos de datos en la plataforma, almacenados en el disco local de la misma máquina, es que es muy sencillo y eficaz implementar operaciones de reducción de múltiples entradas (figura 9). Todos los pares de clave-valor de todos los conjuntos de datos en la plataforma, con una clave común, se mantienen en la misma máquina, de modo que las operaciones de reducción siempre tendrán acceso local a cualquier conjunto de datos requerido. Obviamente, el único requisito es que todos los conjuntos de datos de entrada deben tener el mismo tipo de datos como clave, de modo que la clave puede compararse entre los mismos. Implementación de operaciones JOIN: 4 0 Como resultado de ambas innovaciones anteriores, las operaciones de reducción con varios conjuntos de datos de entrada tendrán los conjuntos de datos automáticamente divididos en partes y clasificados de la misma manera, de modo que la condición básica para realizar una operación de tipo JOIN se cumple automáticamente en la plataforma. Esto es posible porque la estrategia de distribución de conjuntos de datos ha puesto todos los pares de clave-valor con una clave común, a partir de sus conjuntos de datos de entrada, en el disco local de la misma máquina. Por tanto no hay conflicto (como sería en una plataforma basada en un sistema de archivos distribuidos, como Apache Hadoop y HDFS) al asignar reductores a máquinas en las que habitan datos locales. Esta implementación de operaciones JOIN es tan eficaz como una operación de reducción convencional y no tiene restricciones de tamaño (a diferencia de operaciones JOIN de lado de mapeo o de lado de reducción en Hadoop). 12

13 Gestión de operaciones en modo de procesamiento de flujo continuo: Basándose en la infraestructura de gestión de datos descrita y la latencia muy baja obtenida, se ha diseñado una nueva manera de procesar operaciones MapReduce, el procesamiento de flujo continuo, que puede ser lo más cercano al tiempo real que se desee. Los datos se manejan en colas, en lugar de en conjuntos de datos, y cuando llegan nuevos datos a una cola, puede ejecutarse cualquier número de operaciones para procesarlos. Los datos de salida se emiten entonces a otras colas, y se ejecutan nuevas operaciones en cascada. Las operaciones se planifican con una orden que define la operación que va a ejecutarse y las colas de entrada y salida procesadas: add_stream_operation parse page.parse_graph graph.txt graph Por ejemplo, esta orden planifica una operación de análisis sintáctico (parse) de flujo continuo (este nombre identifica la operación junto con su conjunto de colas de entrada y salida), que ejecutará una operación de mapeo page.parse_graphs que lee pares de clave-valor a partir de una cola de entrada graph.txt y los emite a la cola graph. Pueden definirse una serie de propiedades en esta operación_flujo continuo para controlar esta planificación: latencia_máx 1 tamaño_cola_entrada_mín tamaño_mín_entre_planificaciones número_máx_operaciones_paralelas tamaño_cola_salida_máx cualquier otra clase de restricción para controlar la ejecución de la operación. 20 Hay un planificador de tareas de flujo continuo que siempre que se cumplan estas propiedades, prepara la operación que va a ejecutarse. Una vez que se consumen todos los datos de entrada, la operación termina y el planificador de tareas continúa evaluando los parámetros relevantes. Se presenta un esquema lógico del planificador de operación y la gestión de los datos en las colas (bloques) en la figura Que se elimine o no la cola de datos de entrada después del procesamiento, se determina por una opción de configuración; por defecto el comportamiento deseado es limpiar la cola, pero en algunos casos puede ser útil tener colas estáticas, como catálogos o diccionarios. En la figura 11, se presenta un flujo continuo típico. Para tener en cuenta todas las demás máquinas que funcionan en el agrupamiento, se presenta una descripción más detallada en la figura 12 y la figura 13. La distribución de pares de clave-valor a través de la plataforma es la misma que la presentada en las secciones anteriores. Un mecanismo para la suscripción a cualquier cola en la plataforma permite que los clientes reciban contenido y actualizaciones desde cualquier cola en la plataforma. Mejora de latencia. Gestión de bloques En el nuevo procesamiento orientado a flujo continuo, puesto que hay un flujo de datos continuo en la cadena de operaciones, el escenario ideal sería mantener todos los bloques de datos en memoria, y la referencia a esta memoria se pasa entre las operaciones. Si hay suficiente memoria, no hay ningún requisito para descargar los bloques de datos al disco local. En datos grandes, habitualmente no habrá suficiente memoria para manejar todos los datos que van a procesarse. Así se ha incluido un nuevo módulo de gestor de bloque en el sistema. Este módulo optimiza y minimiza el uso de disco, garantizando que todos los bloques de datos necesarios para ejecutar el próximo conjunto de tareas estén disponibles en la memoria. Si hay suficiente memoria en el sistema, los bloques de datos se mantienen en memoria sin la necesidad de cargarse en el disco. Cuando el sistema experimenta una contienda de memoria debido a la falta de memoria, el gestor de bloque cargará en el disco los bloques de datos menos útiles. Cuando estos bloques se requieran de nuevo, el gestor de bloque los cargará desde el disco. En el caso del mejor escenario, no es necesario copiar los bloques de datos al disco, y en el peor de los casos, estas copias se optimizan y se minimizan (figura 14). 13

14 El gestor de bloque (figura 1) mantiene una lista de los bloques en el nodo trabajador. Ésta se clasifica según la información contenida en la planificación de tareas; los bloques que serán necesarios por las operaciones que van a ejecutarse anteriormente y mantenerse primero. Los últimos bloques en la lista se planifican para descargarse al disco local, con una prioridad baja. Cuando una tarea está lista para ejecutarse, el gestor de bloque garantiza que todos los bloques necesarios estén disponibles en memoria. Si el bloque se ha copiado al disco, y se ha liberado su memoria, el gestor de bloque pide al gestor de disco que lo recupere. Si no hay suficiente memoria para copiarlo, se explorarán los bloques ya descargados para liberar su memoria asociada, si aún no se ha hecho. Procesamiento de flujo continuo con estado La tecnología de MapReduce estaba orientada a resolver problemas en modo de procesamiento por lotes: a recopilar una enorme cantidad de datos, procesarlos desde cero, y obtener un resultado. Pero en muchos casos, los datos no proceden de una fuente estática, sino que más bien son una muestra de una fuente que cambia constantemente. En este modelo, el proceso debe ejecutarse de nuevo completamente, con datos nuevos y acumulados, a una frecuencia conveniente (una vez al mes, una vez a la semana...). O el desarrollador debe incorporar los resultados del lote anterior a mano, cuando la tarea ha finalizado por completo, y los resultados se han exportado al almacenamiento externo. En cualquier caso, son soluciones ineficaces, con una latencia muy larga. Muchas de las soluciones relevantes para los negocios de telecomunicaciones podrían representarse como un estado interno que se adapta de manera continua con nuevos datos. Basándose en el mismo principio para gestionar pares de clave-valor en la plataforma distribuida, a través de la distribución de grupo hash, el método de procesamiento de flujo continuo puede extenderse fácilmente para incorporar un estado que puede tratarse como una clase especial de cola. El estado de salida es una cola mediante una operación de reducción que tiene 2 entradas, una que es la salida de un ciclo anterior (figura 16). Como se presentó anteriormente, las operaciones de reducción con múltiples entradas permiten una implementación sencilla de JOIN. Esta misma interpretación puede extenderse para actualizar el estado, porque la operación de reducción se llamará automáticamente con la información de estado y los registros de datos de entrada con la misma clave. Esta operación con estado interno podría interpretarse como un sistema de CEP, con un nodo para cada una de las claves en los datos (figura 17). Cada uno de estos nodos debe mantener el valor asociado a su clave. Tal como ya se presentó acerca de sistemas de CEP, esta estrategia tendría problemas de escalabilidad a medida que crece el estado (el número de posibles claves). Uno de los problemas de implementar un estado en una plataforma de tipo MapReduce es la necesidad de evaluar de nuevo todo el estado con cada llegada de nuevos datos de entrada. Una solución extrema sería la estrategia de leer de nuevo el estado como una entrada (esta tiene otros problemas, principalmente la latencia muy larga, porque el estado de resultado debe calcularse completamente por todos los nodos trabajadores antes de emitirse como salida y estar disponible como entrada). En el otro extremo, estaría la solución de acceder a la entrada individual que va a actualizarse con cada par de clave-valor de entrada (esta clase de solución sería la usada en el sistema Percolator [8], o en el modelo de CBP [7]), a través del uso de algún tipo de indexación. Esta segunda opción es más eficaz cuando la parte de estado que va a actualizarse es una pequeña fracción del tamaño de estado total. Si no es así, la sobrecarga de cálculo de índice puede ser mayor que actualizar todo el estado. Para la mayoría de los problemas típicos en telecomunicaciones, donde el estado puede ser una descripción relacionada con la actividad del usuario, una parte significativa del estado de los usuarios puede verse afectada con bastante frecuencia (cada ó minutos). Así se ha diseño una nueva solución intermedia para trabajar óptimamente cuando se actualiza una gran cantidad del estado, y para evitar la ineficacia cuando se actualiza un pequeño conjunto. Éste es el escenario en el que se centra la innovación propuesta. Además, esta interpretación innovadora del estado como una única cola tratada simultáneamente como entrada y como salida, junto con la actividad del gestor de bloque, ofrece un rendimiento óptimo, puesto que la mayoría de bloques del estado probablemente siempre se mantendrán en la memoria (al tamaño de memoria máximo disponible), mejorando la latencia global, puesto que no es necesario detener la plataforma para consolidar el estado en el disco (se realizará por el gestor de bloque cuando las operaciones de disco requeridas lo permitan). Una solución similar a la distribución de datos por el grupo hash, descrita anteriormente para la gestión de datos a través de la plataforma, puede extenderse para organizar la información de estado. En cada nodo trabajador, el estado se divide en una serie de intervalos de grupos hash clave, o compartimentos (el intervalo de grupos hash ya está dividido entre los nodos trabajadores). Cuando un bloque de datos de entrada llega desde una cola, se asigna al compartimento de estado correspondiente de la clave (figura 18), y se acumula hasta que se procesa. Para realizar una actualización de estado eficaz, es conveniente que el tamaño de los datos se procese para ser al menos similar al tamaño del 14

15 compartimento, entonces los bloques de datos de entrada se acumulan hasta que se haya llenado la memoria asignada Sin embargo, los bloques de datos de entrada habitualmente contienen una mezcla de pares de clave-valor correspondientes a varios compartimentos de estado (figura 19) (aunque todos deben corresponder a la parte del estado almacenada en el nodo trabajador actual). La solución más sencilla es enviar el bloque de datos de entrada a todos los compartimentos con al menos un grupo hash de clave común, en los que se procesarán automáticamente, a través de la operación de reducción; los pares de clave-valor exteriores se ignorarán. Esto ha demostrado ser más rápido, los bloques de datos se mantienen en memoria, como referencia. Pero esta estrategia implica que en cada compartimento, (dependiendo de la creación de bloques y el número de compartimentos) se mantenga mucha información inútil, los pares de clave-valor que no van a procesarse en ese compartimento. Cuando el número de compartimentos crece, el tamaño de pares de clave-valor locales (al contrario de los pares de clave-valor que se procesarán en otro compartimento) se reduce, para el mismo límite de memoria, entonces el impacto de rendimiento aumenta. Cuando se detecta esta situación (evaluando el tamaño relativo de pares de clave-valor locales con respecto a la memoria total ocupada por los bloques de datos), entra en juego un nuevo módulo que rompe y compacta los bloques de datos en grupos de pares de clave-valor cuyo grupo hash corresponde a sólo un compartimento (figura 20). De esta manera, a costa de dividir el bloque de datos data y conservar una copia adicional de la memoria, los datos de entrada en los compartimentos se compactan, y las operaciones pueden completarse y la memoria liberarse. Inicialmente, el estado se divide en tantos compartimentos como procesadores se definen en la plataforma (este parámetro es común a cada nodo trabajador). Como pueden crecer, o bien porque hay nuevas claves, o bien porque hay más información asociada a las claves, se ha incluido un mecanismo para dividir grandes compartimentos en unos nuevos, manteniendo su tamaño bajo control, y permitiendo así la eficacia en operaciones de actualización. Cuando un compartimento ha crecido y debe dividirse, se detiene la entrada de nuevos datos y su operación de actualización; se crean nuevos compartimentos, y el grupo hash asociado al compartimento se divide. Hay diferentes estrategias para realizar la división de compartimentos. Si existe una pequeña variación en la distribución de tamaño de compartimentos y todos los compartimentos están próximos a su capacidad, se realiza una operación de división general en todos los compartimentos (una división cuaternaria). Se detienen todas las operaciones relacionadas con el estado. Si sólo un compartimento es demasiado grande, entonces sólo se divide ese compartimento. Aunque sólo es necesario detener un compartimento, la gestión es más complicada, y no es tan eficaz. Realizaciones de la invención: 3 La invención se ha implementado en una plataforma de grandes datos, un marco de MapReduce (en un estado de prototipo experimental). Con este marco, se han programado y evaluado diferentes problemas relevantes en el negocio de las telecomunicaciones y otros problemas típicos. Algunos ejemplos de problemas implementaron: Análisis de red social (SNA): Análisis de CDR para detectar comunidades de usuarios. 40 Top_hits: Análisis de registros de navegación web, con el fin de detectar los resultados más activos por categoría, y recomendarlos según el perfil de usuario. Tráfico de navegación (OSN): Análisis de patrones de navegación en usuarios móviles, clasificados por tipo de URL, tipo de dispositivo, etc. Movilidad: Análisis de CDR para detectar patrones de movilidad. Posicionamiento de la página con rastreo de web incremental. 4 Procesamiento y distribución de flujos de datos de flujo continuo. Última posición conocida basándose en información de establecimiento de red móvil. Ventajas de la invención 0 La invención pretende resolver, de una manera muy eficaz, el problema de procesamiento de un flujo de datos continuo, que tiene resultados actualizados, y sin la necesidad de acumular y volver a procesar todos los datos, tal como se requeriría en plataformas de MapReduce orientadas a lotes. 1

16 Esta solución ofrece el mejor rendimiento para estos tipos especiales de aplicaciones, que no pueden resolverse de manera eficaz con las soluciones MapReduce disponibles en el mercado. Las principales ventajas de la invención son: 1. El flujo de datos se procesa en modo de flujo continuo, manteniendo la latencia tan baja como se requiera, ya que la latencia se reduce gradualmente con el número de máquinas en el agrupamiento. 2. El desarrollador tiene control sobre la granularidad y latencia de los resultados obtenidos. 3. Un cliente puede suscribirse a cualquier cola para recibir su contenido y actualizaciones. 4. El estado interno se actualiza de manera continua a medida que se procesan nuevos datos, sin la necesidad de almacenar y volver a procesar todos los datos acumulados, como se requeriría en una plataforma de MapReduce orientada a lotes.. El tamaño de estado puede crecer hasta el límite del disco global disponible en la plataforma. 6. La gestión coordinada de memoria y disco garantiza que toda la memoria se use manera eficaz para mantener en la memoria los bloques de datos más proclives a usarse Las operaciones son más rápidas si los datos de entrada están disponibles en memoria y los dados de salida pueden mantenerse también en memoria, sin pasar por el disco. 16

17 SIGLAS ACID CBP CDR CEP BMS GFS HDFS MR Atomicity, Consistency, Isolation, Durability; atomicidad, consistencia, aislamiento, durabilidad Continuous Bulk Processing; procesamiento en masa continuo Call Data Record; registro de datos de llamada Complex Event Processing; procesamiento de eventos complejos Database Management System; sistema de gestión de base de datos Google File System; sistema de archivo de Google Apache Hadoop Distributed File System; sistema de archivo distribuido de Apache Hadoop Map-Reduce; mapeo-reducción NoSQL No SQL o Not only SQL ; No SQL O No sólo SQL RDBMS Relational Database Management System; sistema de gestión de base de datos relacional SNA SQL URL Social Network Analysis; análisis de red social Structured Query Language; lenguaje de consulta estructurada Uniform Resource Locator; localizador uniforme de recursos 17

18 BIBLIOGRAFÍA [1] Brian Babcock et al, Models and Issues in Data Stream Systems, Proceedings of the 21st ACM SIGMOD-SIGACT-SIGART symposium on Principles of database systems, Nueva York, [2] Jeffrey Dean y Sanjay Ghemawat. MapReduce: Simplified data processing on large clusters. In Proceedings of the 6th Symposium on Operating System Design and Implementation (OSDI 2004), páginas , San Francisco, California, [3] Cortes et al., Hancock: A Language for Extracting Signatures from Data Streams, Proc. Sixth International Conference on Knowledge Discovery and Data Mining, Boston, 2000, págs [4] Yunhong Gu, Robert Grossman, Sector and Sphere: The Design and Implementation of a High Performance Data Cloud, 2008 [] CONDIE, T., CONWAY, N., ALVARO, P., AND HELLERSTIEN, J. M. MapReduce online. In 7th NSDI (20). [6] Boduo Li et al, A Platform for Scalable One-Pass Analytics using MapReduce, en SIGMOD 2011, Atenas 1 [7] Dyonisios Logothetis et al, Stateful Bulk Processing for Incremental Analytics, SoCC, Indianápolis, EE.UU., 20. [8] Daniel Peng, Frank Dabek, Large-scale Incremental Processing Using Distributed Transactions and Notifications, 20 [9] F. Chang et al, Bigtable: A distributed storage system for structured data, en 7th OSDI (noviembre de 2006), págs [] Bugra Gedik et al, SPADE: The System S Declarative Stream Processing Engine, en SIGMOD 2008, Vancouver [11] L. Popa et al, DryadInc: reusing work in large-scale computations, en HotCloud Workshop,

19 REIVINDICACIONES 1 1. Método de procesamiento en flujo continuo en una plataforma de cálculo distribuida de mapeo y reducción, comprendiendo dicha plataforma de cálculo distribuida al menos un agrupamiento con una pluralidad de nodos con capacidad de cálculo, usando el método información relativa a un estado asociado a al menos operaciones de reducción, caracterizado porque el método comprende generar dicho estado como resultado de una operación de reducción realizada por un nodo, en forma de una cola de salida, y usar dicho estado como cola de entrada de una operación de reducción posterior realizada por dicho nodo, formando dicha cola de salida y dicha cola de entrada una única cola que se actualiza tras el procesamiento de operación de reducción. 2. Método según la reivindicación 1, que comprende generar una pluralidad de estados como resultado de una pluralidad correspondiente de operaciones de reducción realizadas por una pluralidad de nodos, en forma de datos de cola, y usar dichos estados como entradas de operaciones de reducción posteriores realizadas por los respectivos nodos. 3. Método según la reivindicación 1 ó 2, que comprende almacenar al menos parte de los bloques que forman dicho estado en una memoria local del respectivo nodo, y acceder a y recuperar dichos bloques de estado desde al menos dicha memoria local para dichas operaciones de reducción posteriores. 4. Método según la reivindicación 3, que comprende almacenar todos los bloques que forman dicho estado en la memoria local del respectivo nodo, y acceder a y recuperar dichos bloques de estado desde sólo dicha memoria local para dichas operaciones de reducción posteriores Método según la reivindicación 3, que comprende almacenar en un disco local del respectivo nodo el resto de los bloques que forman dicho estado que no se han almacenado en la memoria local, y acceder a y recuperar dichos bloques de estado desde tanto la memoria local como el disco local, para dichas operaciones de reducción posteriores. 6. Método según cualquiera de las reivindicaciones anteriores, que comprende compartir dicho nodo o al menos uno de dicha pluralidad de nodos su respectivo estado con otros nodos, realizando dichos otros nodos operaciones de reducción usando dicho estado compartido como entrada para las mismas. 7. Método según cualquiera de las reivindicaciones anteriores, que comprende realizar dicho procesamiento de flujo continuo planificando operaciones en colas de datos, y ejecutarlas automáticamente cuando hay disponibles datos de entrada en el respectivo nodo Método según la reivindicación 7, que comprende controlar las colas de datos para especificar una latencia máxima. 9. Método según la reivindicación 7 u 8, que comprende controlar las colas de datos para especificar si los datos de entrada, incluyendo el estado, deben borrarse después del procesamiento, o si deben conservarse para su uso posterior. 3. Método según cualquiera de las reivindicaciones anteriores, que comprende organizar dicho estado como una división de los intervalos clave. 11. Método según cualquiera de las reivindicaciones anteriores, que comprende dividir el estado en varios compartimentos Método según la reivindicación 11 cuando depende de la reivindicación 9, que comprende asignar un sello de tiempo a cada uno de dichos compartimentos, y borrar las entradas de estado sin usar según el sello de tiempo asociado al compartimento que comprende parte del estado. 13. Sistema de plataforma de cálculo distribuida para procesamiento en flujo continuo de mapeo y reducción, comprendiendo dicha plataforma de cálculo distribuida al menos un agrupamiento con una pluralidad de nodos con capacidad de cálculo y configurado para realizar al menos operaciones de reducción usando información relativa al estado asociado a las mismas, caracterizado porque al menos uno de dichos nodos comprende al menos una cola de estado de entrada y al menos una cola de estado de salida, porque dicho al menos un nodo está configurado para generar dicho estado como resultado de una operación de reducción realizada por dicho al menos un nodo y proporcionar dicho resultado a dicha al menos una cola de salida de estado, y porque dichas colas de estado de entrada y de salida están interconectadas formando una única cola de modo que hay una realimentación desde dicha cola de estado de salida a dicha cola de estado de entrada. 14. Sistema según la reivindicación 13, que comprende una pluralidad de nodos, comprendiendo cada uno al menos una cola de estado de entrada y al menos una cola de estado de salida, y configurada para generar dicho estado como resultado de una operación de reducción y proporcionar dicho resultado a dicha al menos una cola de salida de estado, en el que las colas de estado de entrada y de salida de cada nodo están 19

20 interconectadas formando una única cola de modo que hay una realimentación desde dicha cola de estado de salida a dicha cola de estado de entrada. 1. Sistema según la reivindicación 13 ó 14, en el que dicho al menos un nodo o al menos parte de dicha pluralidad de nodos comprenden al menos una memoria local para almacenar/recuperar al menos parte de los bloques que forman el estado del respectivo nodo. 16. Sistema según la reivindicación 1, en el que dicho al menos un nodo o al menos parte de dicha pluralidad de nodos comprenden al menos un disco local para almacenar/recuperar el resto de los bloques que forman el estado que no se han almacenado en la memoria local. 17. Sistema según la reivindicación 1 ó 16, que comprende un módulo de gestor de bloque que optimiza los recursos manejando el almacenamiento/recuperación de bloques de estado en dicha memoria local y/o dicho disco local, para mantener los bloques de datos de estado activos en la memoria local. 18. Sistema según cualquiera de las reivindicaciones 13 a 17, en el que dicho al menos un nodo o al menos parte de dicha pluralidad de nodos implementa el método según cualquiera de las reivindicaciones 1 a