Biblioteca de streaming
Para distinguir Hadoop y Storm, esta sección responderá las siguientes preguntas:
1. ¿Cuáles son las operaciones de Hadoop y Storm?
2. ¿Por qué es 2. ¿Baofeng lo llama un sistema informático de transmisión?
3.¿Para qué escenarios es adecuado Hadoop y cuándo utilizar Hadoop?
4. ¿Qué es el rendimiento?
En primer lugar, entiéndalo en su conjunto: Hadoop es un cálculo de nivel, los datos están en el disco durante el cálculo y el disco debe leer y escribir Storm es un cálculo a nivel de memoria y los datos se importan directamente a la memoria a través de la red. La lectura y escritura de la memoria es n órdenes de magnitud más rápida que la lectura y escritura del disco. Según el material didáctico Harvard CS61, la latencia del acceso al disco es aproximadamente 75.000 veces mayor que la del acceso a la memoria. Entonces la tormenta es más rápida.
Notas:
1. La latencia se refiere al tiempo desde la generación de datos hasta los resultados del cálculo. "Rápido" debería referirse principalmente a esto.
2. El rendimiento se refiere a la cantidad de datos procesados por el sistema por unidad de tiempo.
La latencia de la transmisión de red directa y el cálculo de la memoria de Storm debe ser mucho menor que la de la transmisión de Hadoop a través de HDFS; cuando el modelo informático es adecuado para el procesamiento de transmisión, el procesamiento de transmisión de Storm ahorra datos en el tiempo de recolección del procesamiento por lotes; Debido a que Storm es un trabajo orientado a servicios, también elimina la demora en la programación del trabajo. Entonces, en términos de latencia, Storm es más rápido que Hadoop.
En principio:
Hadoop M/R se basa en HDFS y necesita dividir datos de entrada, generar archivos de datos intermedios, ordenar, comprimir datos, copiar múltiples copias, etc. y baja eficiencia.
Storm se basa en ZeroMQ, una biblioteca de mensajería de alto rendimiento que no almacena datos de forma persistente.
¿Por qué Storm es más rápido que Hadoop? El siguiente es un escenario de aplicación.
En un escenario típico, miles de productores de registros generan archivos de registro y se requieren algunas operaciones ETL para almacenarlos en la base de datos.
Suponiendo que está utilizando Hadoop, primero debe guardarlo en HDFS y calcularlo en función de la granularidad de cortar un archivo por minuto (esta granularidad es extremadamente fina y, si es más pequeña, habrá ser un montón de archivos pequeños en HDFS). Cuando Hadoop comenzó a calcular, había pasado 1 minuto y luego pasó otro minuto antes de comenzar a programar tareas y luego ejecutar el trabajo. Suponiendo que hay muchas máquinas, costará mucho dinero completarlas y luego llevará mucho tiempo escribir los supuestos de la base de datos.
Cuando se generan datos en la computación en streaming, existe un programa que monitorea la generación de registros en todo momento. Las líneas generadas se envían al sistema de computación en streaming a través del sistema de transmisión, y luego al sistema de computación en streaming. Los procesa directamente y los escribe directamente después del procesamiento. Con recursos suficientes, cada dato se puede completar en milisegundos desde la generación hasta la escritura en la base de datos.
Al mismo tiempo, hablemos de otro escenario:
Si pones el recuento de palabras de un archivo grande en Storm para su procesamiento en streaming, todas las ocurrencias se habrán procesado antes de Storm. Puede generar los resultados. Hay datos, luego puede compararlos con hadoop. En este momento, en realidad no se trata de retraso, sino de rendimiento.
-
El aspecto más importante: Hadoop sirve como medio de intercambio intermedio y los datos de la tormenta siempre fluyen en la memoria.
Los campos a los que se enfrentan no son exactamente los mismos. Uno es el procesamiento por lotes, basado en la programación de tareas; el otro es el procesamiento en tiempo real, basado en secuencias.
Tome el agua como ejemplo. Hadoop se puede considerar como agua pura, que se mueve balde por balde; Storm usa tuberías de agua, que están conectadas topológicamente de antemano, y luego se abre el grifo y sale el agua. sigue fluyendo.
-
Nathan Marz, ingeniero principal de Storm, dijo: Storm puede escribir y escalar fácilmente cálculos complejos en tiempo real en un grupo de computadoras. Storm es para el procesamiento en tiempo real lo que Hadoop es para el procesamiento por lotes. Storm garantiza que todos los mensajes serán procesados y lo hace muy rápidamente: se pueden procesar millones de mensajes por segundo en un clúster pequeño. Aún mejor, puedes desarrollar en cualquier lenguaje de programación.
Las principales características de la tormenta son las siguientes:
1.
De manera similar a cómo MapReduce reduce la complejidad del procesamiento por lotes paralelo, Storm reduce la complejidad del procesamiento en tiempo real.
2. Puedes utilizar varios. Puedes utilizar varios lenguajes de programación con Storm. Clojure, Java, Ruby y Python son compatibles de forma predeterminada. Para agregar soporte para otros idiomas, solo necesitamos implementar un protocolo de comunicación Storm simple.
3. Tolerancia a fallos. Storm gestionará las fallas de los procesos y nodos de los trabajadores.
4. Ampliación horizontal. Los cálculos se realizan en paralelo a través de múltiples subprocesos, procesos y servidores.
5. Procesamiento confiable de mensajes. Storm garantiza que cada mensaje se pueda procesar completamente al menos una vez. Cuando una tarea falla, es responsable de reintentar los mensajes desde la fuente.
6. El diseño del sistema garantiza que los mensajes se puedan procesar rápidamente y se utiliza MQ como cola de mensajes subyacente.
7. Modo local. Storm tiene un "modo local" que emula completamente un clúster de Storm durante el procesamiento. Esto le permite desarrollar y realizar pruebas unitarias rápidamente.
-
En general, bajo el mismo consumo de recursos, la latencia de la tormenta es menor que la de mapreduce. Pero el rendimiento también es menor que el de mapreduce. Storm es un sistema informático de flujo típico y mapreduce es un sistema de procesamiento por lotes típico. El siguiente es el diagrama de flujo del sistema de procesamiento por lotes y computación por convección
Este proceso de procesamiento de datos se puede dividir aproximadamente en tres etapas:
1.
2. Cálculo de datos (el almacenamiento intermedio está involucrado en el cálculo), "qué aspectos se determinan" en la pregunta debe referirse principalmente al método de procesamiento actual.
3. Visualización de resultados de datos (comentarios)
En la etapa 1), la estrategia de procesamiento típica actual: el sistema de generación de datos generalmente proviene del análisis de registros y puntos de página de base de datos, y El cálculo del tráfico recopilará datos en la cola de mensajes (como kafaka, metaQ, timetunle). Los sistemas por lotes suelen recopilar datos en un sistema de archivos distribuido (como HDFS), aunque algunos utilizan colas de mensajes. Llamemos almacenamiento de preprocesamiento del sistema de archivos y cola de mensajes. No hay mucha diferencia entre los dos en términos de latencia y rendimiento, pero hay una gran diferencia desde este almacenamiento de preprocesamiento hasta la etapa de cálculo de datos. La computación en flujo generalmente lee datos de la cola de mensajes y realiza cálculos en tiempo real. Un sistema de procesamiento por lotes generalmente guarda una gran cantidad y luego lo importa al sistema informático (hadoop) en lotes, por lo que el retraso es diferente.
2) En la etapa de cálculo de datos, la baja latencia del sistema informático de flujo (tormenta) tiene principalmente los siguientes aspectos (para la pregunta del tema).
Respuesta: El proceso de tormenta es permanente y los datos se pueden procesar en tiempo real.
Después de guardar un lote de datos de mapreduce, el sistema de gestión de trabajos inicia la tarea, Jobtracker calcula la asignación de tareas y tasktacker inicia el proceso de operación relevante.
b: Los datos entre unidades informáticas STOM se transmiten directamente a través de la red (zeromq).
Los resultados de las operaciones de tareas de mapas de mapreduce deben escribirse en HDFS porque las tareas de reducción se arrastran a través de la red para realizar operaciones. Relativamente hablando, se lee y escribe mucho, pero la velocidad es lenta.
c: Para operaciones complejas
El modelo operativo de Baofeng admite directamente DAG (gráfico acíclico dirigido)
Mapreduce debe estar compuesto por múltiples procesos de MR. Algunas operaciones de mapas. no tiene sentido.
3) Presentación de los resultados de los datos
Los resultados de la operación general de la computación en flujo se retroalimentan directamente al conjunto de resultados final (página de visualización, índice del motor de búsqueda). Mapreduce generalmente requiere la importación por lotes de resultados al conjunto de resultados después de toda la operación.
No existe una diferencia esencial entre la informática de flujo real y los sistemas de procesamiento por lotes. Por ejemplo, el tridente de Baofeng también tiene el concepto de procesamiento por lotes, y mapreduce puede reducir el conjunto de datos para cada operación (como comenzar cada pocos minutos). Puma de Facebook es un sistema informático de transmisión basado en Hadoop.
2. Comparación entre los motores de computación paralela de alto rendimiento Storm y Spark
La idea de Spark es que cuando los datos son enormes, es mejor transferir el proceso de cálculo a los datos que transferirlos al proceso de cálculo.
Cada nodo almacena (o almacena en caché) su conjunto de datos y luego envía tareas a ese nodo.
Entonces esto es pasar el proceso a los datos. ¿Esto no tiene nada que ver con Hadoop? Map/reduce es muy similar, excepto que utiliza activamente la memoria para evitar operaciones de E/S, de modo que el rendimiento de los algoritmos iterativos (la salida del cálculo anterior es la entrada del siguiente cálculo) es mayor.
Shark es solo un motor de consultas basado en Spark (que admite análisis y consultas ad-hoc).
La arquitectura de Storm es opuesta a la de Spark. Storm es un motor informático de flujo distribuido. Cada nodo implementa un proceso computacional básico, con elementos de datos que entran y salen de los nodos de la red interconectados. A diferencia de Spark, esto consiste en pasar datos a un proceso.
Ambos frameworks se utilizan para computación paralela que maneja grandes cantidades de datos.
Storm procesa mejor dinámicamente una gran cantidad de "pequeños fragmentos de datos" generados (como el cálculo en tiempo real de algunas funciones de agregación o el análisis de flujos de datos de Twitter).
Spark funciona en conjuntos de datos existentes (como datos de Hadoop), que se han importado al clúster de Spark. Spark puede escanear flash basándose en la administración de memoria y minimizar las operaciones de E/S globales de algoritmos iterativos.
Pero el módulo de flujo de chispa (¿flujo? Módulo) es similar a Storm (ambos son motores de cálculo de flujo), aunque no exactamente igual.
El módulo Spark Stream primero recopila lotes de datos y luego los distribuye (tratándolos como datos inmutables), mientras que Storm procesa y distribuye datos en tiempo real tan pronto como se reciben.
No estoy seguro de qué método tiene más ventajas en el rendimiento de datos, pero la latencia de cálculo de Storm es menor.
En resumen, Spark y Storm son diseños opuestos, ¿y Spark? La cocción al vapor es similar a la tormenta. El primero tiene una ventana de suavizado de datos (¿deslizante?), mientras que el segundo necesita mantener esta ventana por sí solo.