¿MapReduce es adecuado para mí?

Question

Estoy trabajando en un proyecto que trata sobre el análisis de una gran cantidad de datos, así que descubrí MapReduce bastante recientemente, y antes de profundizar más en él, me gustaría asegurarme de que mis expectativas sean las correctas.

La interacción con los datos se realizará desde una interfaz web, por lo que el tiempo de respuesta es crítico aquí, estoy pensando en un límite de 10-15 segundos. Suponiendo que mis datos se cargarán en un sistema de archivos distribuido antes de realizar cualquier análisis sobre él, ¿qué tipo de rendimiento puedo esperar de él?

Digamos que necesito filtrar un archivo XML simple de 5GB que está bien formado, tiene una estructura de datos bastante plana y 10,000,000 de registros en él. Y digamos que la salida dará como resultado 100.000 registros. ¿Son 10 segundos posibles?

Si es así, ¿qué tipo de hardware estoy mirando? Si no, ¿por qué no?

Pongo el ejemplo abajo, pero ahora deseo que no lo haya hecho. 5GB era solo una muestra de la que estaba hablando, y en realidad estaría lidiando con una gran cantidad de datos. 5 GB pueden ser datos durante una hora del día, y es posible que desee identificar todos los registros que cumplan ciertos criterios.

Una base de datos realmente no es una opción para mí. Lo que quería saber es cuál es el rendimiento más rápido que puedo esperar al usar MapReduce. ¿Siempre es en minutos u horas? ¿Nunca es segundos?

Answer 1

MapReduce es bueno para escalar el procesamiento de grandes conjuntos de datos, pero no pretende ser sensible. En la implementación de Hadoop, por ejemplo, la sobrecarga del inicio generalmente toma solo unos minutos. La idea aquí es tomar un trabajo de procesamiento que tomaría días y reducirlo al orden de horas, u horas a minutos, etc. Pero no comenzaría un nuevo trabajo en respuesta a una solicitud web y esperaría que terminara en tiempo para responder

Tocar sobre por qué este es el caso, considerar la forma en que funciona MapReduce (, visión general de alto nivel):

• Un grupo de nodos recibir porciones de los datos de entrada (llamadas fracturas) y hacer algún procesamiento (el paso mapa)

• los datos intermedios (salida de el último paso) se reparticionará tales que los datos con teclas como termina juntos. Esto generalmente requiere un poco de transferencia de datos entre nodos.

• La reducir nodos (que no son necesariamente distintos desde el asignador de nodos - una sola máquina puede hacer varios trabajos en sucesión) realizar la etapa de reducir.

• Los datos de resultados se recopilan y se fusionan en para generar el conjunto final de resultados.

Mientras Hadoop, et al tratar de mantener localidad de datos lo más alto posible, todavía hay una buena cantidad de arrastrar los pies en torno a que se produce durante el procesamiento. Esto solo debería impedirle respaldar una interfaz web receptiva con una implementación distribuida de MapReduce.

Editar: como Jan Jongboom señaló, MapReduce es muy bueno para el preprocesamiento de datos de modo que las consultas web pueden ser rápidas PORQUE no tienen que participar en el procesamiento. Considere el famoso ejemplo de crear un índice invertido a partir de un gran conjunto de páginas web.

Answer 2

Una aplicación distribuida de MapReduce como Hadoop no es una buena opción para el procesamiento de un XML 5GB

• Hadoop funciona mejor en grandes cantidades de datos. Aunque 5GB es un archivo XML bastante grande, se puede procesar fácilmente en una sola máquina.
• Los archivos de entrada a los trabajos de Hadoop deben poder dividirse para que se puedan procesar diferentes partes del archivo en diferentes máquinas. A menos que su xml sea trivialmente plano, la división del archivo no será determinista, por lo que necesitará un paso de procesamiento previo para formatear el archivo para dividirlo.

Si tenía muchos archivos de 5GB, entonces podría usar hadoop para distribuir la división. También puede usarlo para fusionar resultados entre archivos y almacenar los resultados en un formato de consulta rápida para su interfaz web, como lo han mencionado otras respuestas.

Answer 3

Parece que lo que puede querer es una buena base de datos antigua. No es tan moderno como map/reduce, pero a menudo es suficiente para trabajos pequeños como este. Dependiendo de qué tan flexible debe ser su filtrado, puede importar su archivo de 5GB en una base de datos SQL, o puede implementar su propio esquema de indexación, ya sea almacenando registros en diferentes archivos, almacenando todo en la memoria en una tabla gigante, o lo que sea apropiado para sus necesidades.

Answer 4

MapReduce es un término genérico. Probablemente quiera preguntar si un marco de MapReduce completo con control de trabajo, como Hadoop, es adecuado para usted. La respuesta aún depende del marco, pero generalmente, las funciones de control de trabajo, red, replicación de datos y tolerancia a fallas de un marco MapReduce lo hacen adecuado para tareas que toman minutos, horas o más, y esa es probablemente la respuesta corta y correcta. para ti.

El paradigma MapReduce puede ser útil para usted si sus tareas se pueden dividir entre trazadores independientes y combinadas con uno o más reductores, y el lenguaje, el marco y la infraestructura que tiene disponible le permiten aprovechar eso.

No existe necesariamente una distinción entre MapReduce y una base de datos. Un lenguaje declarativo como SQL es una buena forma de abstraer el paralelismo, como lo son los frameworks MapReduce consultables como HBase. This article discute las implementaciones de MapReduce de un algoritmo k-means, y termina con un ejemplo de SQL puro (que asume que el servidor puede paralelizarlo).

Idealmente, un desarrollador no necesita saber demasiado sobre la fontanería en absoluto. A Erlang examples les gusta mostrar cómo las funciones del lenguaje funcional manejan el control del proceso.

Además, tenga en cuenta que existen formas livianas de jugar con MapReduce, como bashreduce.

Answer 5

Recientemente trabajé en un sistema que procesa aproximadamente 120 GB/hora con 30 días de historia. Terminamos usando Netezza por razones de organización, pero creo que Hadoop puede ser una solución adecuada dependiendo de los detalles de sus datos y consultas.

Tenga en cuenta que XML es muy detallado. Uno de sus principales costos será leer/escribir en el disco. Si puede, elija un formato más compacto.

La cantidad de nodos en su clúster dependerá del tipo y número de discos y CPU. Puede suponer para un cálculo aproximado que estará limitado por la velocidad del disco. Si su disco de 7200rpm puede escanear a 50MB/sy desea escanear 500GB en 10s, entonces necesita 1000 nodos.

Es posible que desee jugar con el EC2 de Amazon, donde puede hacer frente a un clúster de Hadoop y pagar por minuto, o puede ejecutar un trabajo de MapReduce en su infraestructura.