Hadoop Medio Móvil

David, Sí, MapReduce está diseñado para operar en una gran cantidad de datos. Y la idea es que en general, el mapa y las funciones de reducción no deberían cuidar cuántos mapeadores o cuántos reductores hay, esa es sólo la optimización. Si piensas cuidadosamente sobre el algoritmo que publiqué, puedes ver que no importa qué asignador obtiene qué partes de los datos. Cada registro de entrada estará disponible para cada operación de reducción que lo necesite. Ndash Joe K Sep 18 12 at 22:30 En el mejor de mi entendimiento el promedio móvil no está bien mapas al paradigma de MapReduce ya que su cálculo es esencialmente la ventana deslizante sobre datos ordenados, mientras que MR es el procesamiento de los rangos no intersectados de los datos ordenados. Solución que veo es como sigue: a) Para implementar particionador personalizado para poder hacer dos particiones diferentes en dos ejecuciones. En cada ejecución, los reductores obtendrán diferentes rangos de datos y calcularán el promedio móvil cuando sea apropiado. Voy a tratar de ilustrarlo: En la primera ejecución, los datos de los reductores deberían ser: R1: Q1, Q2, Q3, Q4 R2: Q5, Q6, Q7, Q8 . Aquí usted cacluate el promedio móvil para algunos Qs. En la próxima ejecución, los reductores deberían obtener datos como: R1: Q1. Q6 R2: Q6. Q10 R3: Q10..Q14 Y caclular el resto de promedios móviles. A continuación, tendrá que agregar los resultados. Idea de particionista personalizado que tendrá dos modos de funcionamiento - cada vez que se divide en rangos iguales, pero con algún cambio. En un pseudocódigo se verá así. Partición (keySHIFT) / (MAXKEY / numOfPartitions) donde: SHIFT se tomará de la configuración. MAXKEY valor máximo de la clave. Supongo que por simplicidad empiezan con cero. RecordReader, IMHO no es una solución ya que se limita a la división específica y no se puede deslizar sobre el límite de divisiones. Otra solución sería implementar la lógica personalizada de dividir datos de entrada (es parte del InputFormat). Se puede hacer para hacer 2 diapositivas diferentes, similar a la partición. Respondió Sep 17 12 at 8: 59I tropezó con este artículo: que menciona cómo calcular el promedio móvil utilizando Hadoop. Tenga en cuenta que todos los registros de una tecla deben ser ordenados y luego reducidos. Supongamos ahora que los registros de una CLAVE en particular se extienden por todos los fragmentos del cluster Mongo. En tal caso, ¿sería posible calcular el promedio móvil entiendo que Mongo hace que el mapa se reduzca en cada nodo. El principal requisito para resolver este problema es asegurarse de que todas las emisiones de un mapa se reduzcan en una única fase de reducción. Si ese es el caso, Mongo Map Reduce nunca será capaz de resolver estos problemas. ¿Hay algún malentendido básico También, con miles de millones de filas y petabytes de datos, ¿por qué es que la fase de Hadoop Reduce falla de memoria, ya que tiene que tratar con al menos varios TBs de datos mapeados. Preguntamos 16 de mayo 13 a las 7:31 ¿Puede explicar por qué Hadoop no se bloquea de memoria para tal cálculo? De mi comprensión, toda la reducción ocurrirá en un nodo, donde todos los registros de una tecla se reducirá. Esto debería dar lugar a una enorme sobrecarga de memoria en ese nodo, ya que los TB de datos deben estar presentes allí. Creo que, a diferencia de MongoDB, hadoop, al igual que SQL al procesar una unión grande, escribirá las cosas en el disco y leer sólo cuando sea necesario con El sistema operativo utilizando swap como titular de memoria temporal para ciertas cosas probablemente. MongoDB hace más en RAM antes de escribir en el disco como tal que fácilmente rescatar ndash Sammaye 16 de mayo 13 a las 8:37 Calcular promedios móviles con Hadoop y Map-Reduce Tenga en cuenta que el artículo de Attain tecnologías es una copia directa de este artículo. Este artículo, el que usted está leyendo, es el original y fue publicado el 29 de agosto de 2012. No le di permiso a él y solo lo descubrí por accidente. Un promedio móvil, también llamado media deslizante o media móvil, es una técnica para suavizar la variación a corto plazo en los datos con el fin de revelar tendencias. Tiene usos en procesamiento de señales, análisis de datos y estadísticas. En términos de ingeniería es como un filtro finito de respuesta al impulso, mientras que matemáticamente es una convolución. Para grandes conjuntos de datos este suavizado puede tomar mucho tiempo y tratarlo como un gran problema de datos puede permitir un tiempo más rápido, posiblemente en tiempo real, suavizar los datos. El estándar De Facto para procesar Big Data es Hadoop, aunque otros marcos pueden ser superiores en términos de desarrollo, tiempo de mantenimiento y rendimiento. Algunos incluso pretenden permitir el procesamiento en tiempo real de datos grandes en un portátil estándar. Hadoop se centra en el paradigma de mapa-reducción, un paradigma que es más grande que Hadoop, y puede en cierta medida ser implementado con la cola basada en la comunicación del hilo. El código presentado aquí es una prueba de concepto de código Java para Hadoop desarrollado en parte como un ejercicio de aprendizaje y en parte como una manera de salir de la jaula Big Data en la que Map-Reduce actualmente reside. Como tales detalles necesarios para los sistemas de producción, tales como la capacidad de elegir la longitud de la ventana, la requantise de los datos o los promedios ponderados y exponenciales no han sido discutidos. El código aquí será actualizado a la luz de los comentarios de los usuarios y el desarrollo futuro. El deslizamiento significa que conocí por primera vez la media deslizante en el contexto de análisis de datos de telemetría. Los datos fueron contaminados por el ruido de varias fuentes: vibración, ruido eléctrico y así sucesivamente. Una solución fue suavizar los datos. Como el tiempo de los eventos era importante y los datos podían estar sujetos a sesgos sistemáticos, y el ruido no, por lo tanto, se centró alrededor de un valor medio, los datos suavizados tuvieron que ser desplazados para compensar. Para ser concreto, considere una secuencia de mil puntos de datos ruidosos, que son números enteros entre 0 y 128. Se calcula un promedio de deslizamiento con una ventana de muestra de 9 puntos (La razón de 9 no diez se explica a continuación) Puntos 1 a 9 y colocándolo en la posición 1 de los datos suavizados, calculando entonces el promedio de los puntos 2 a 10 y poniéndolo en la posición 2 y así sucesivamente hasta que se llene el conjunto suavizado. Si los datos no están centrados en torno a un valor medio, el promedio se desplaza al último punto de datos por la mitad de la longitud de la ventana. A veces no se desea el cambio de tiempo implícito en el último párrafo, en este caso se calcula la media móvil central: en este caso la secuencia suavizada comienza en la posición 5 y termina en la posición 995 con los puntos finales normalmente descartados. Una pizca de matemáticas La media de deslizamiento es sólo una convolución 2 o un ligero manchado de la serie temporal con un pulso cuadrado, es decir, una función que es cero fuera de la ventana de muestra. Como tal, una forma de calcular el promedio de deslizamiento es tomar la Transformada de Fourier Rápida (FFT) de los datos y multiplicarla por la FFT del pulso cuadrado (o en el caso de medios ponderados por la FFT de la función de ponderación) . En términos computacionales, el esfuerzo de calcular la FFT puede compensar el ahorro hecho sustituyendo división por multiplicación. Perseguir la noción de Media deslizante como convolución conduce a áreas como el Cálculo Fraccional 3 y está fuera del alcance de esta nota. El uso del método de convolución conduce a la observación de que el pulso cuadrado del promedio móvil simple tiene una transformada de Fourier que se desprende rápidamente a altas frecuencias, por lo que el suavizado elimina las altas frecuencias. Cuanto mayor sea la ventana de muestra, menor será la frecuencia máxima que se pasa. Esto es intuitivamente obvio, pero es bueno tenerlo confirmado por un análisis más riguroso. Cómo llegan los datos Hay básicamente dos situaciones, la primera es donde está disponible toda la secuencia, por ejemplo datos de post-prueba de sistemas electromecánicos y la situación donde Los puntos de datos llegan uno por uno, posiblemente en momentos aleatorios. Aquí se supone que los datos llegan a tiempos fijos. Un caso intermedio es donde los datos se almacenan en un búfer con datos antiguos que se eliminan a medida que llegan nuevos datos. Aquí el suavizado debe ser lo suficientemente rápido para asegurar que todos los datos se procesan antes de que lleguen nuevos datos, aunque esto signifique que el sistema esté inactivo esperando nuevos datos. Con el fin de desarrollar la prueba de concepto rápidamente los datos de prueba se almacenaron en un archivo de texto, un valor a una línea, simulando así la situación en la que los valores de datos llegan uno por uno. Debido a que los datos no están todos disponibles a la vez, la técnica estándar de calcular un total una vez y luego seguir adelante restando el punto más antiguo y añadiendo el punto más nuevo no fue posible. En cambio, se desarrolló una técnica esencialmente similar al método add () de una lista circular para su uso en la clase Mapper con la lista que se convierte en una cadena y se envía al reductor con cada nuevo punto que se añade después de que la lista se llene. Una vez que el código evoluciona métodos más inteligentes se utilizará y el código aquí actualizado. Codigo de muestra