caching - sirve - tipos de memoria cache y su capacidad

¿Es el caché la única ventaja de la chispa sobre el mapa reducido? (5)

Empecé a aprender sobre Apache Spark y estoy muy impresionado con el marco. Aunque una cosa que me sigue molestando es que en todas las presentaciones de Spark hablan de cómo Spark almacena en memoria caché los RDD y, por lo tanto, las operaciones múltiples que necesitan la misma información son más rápidas que otros enfoques como Map Reduce.

Entonces, la pregunta que tuve es que si este es el caso, simplemente agregue un motor de almacenamiento en caché dentro de los marcos de MR como Yarn / Hadoop.

¿Por qué crear un nuevo marco en conjunto?

Estoy seguro de que me estoy perdiendo algo aquí y usted podrá señalarme alguna documentación que me enseñe más sobre la chispa.

Así que es mucho más que un simple almacenamiento en caché. Aarónman lo cubrió mucho, tan enfermo solo agregue lo que se perdió.

El rendimiento sin procesar sin almacenamiento en caché es de 2 a 10 veces más rápido debido a un marco generalmente más eficiente y bien archeteado. Por ejemplo, 1 jvm por nodo con hilos akka es mejor que realizar un proceso completo para cada tarea.

API de Scala. Scala es sinónimo de lenguaje escalable y es claramente el mejor idioma para el procesamiento paralelo. Dicen que Scala reduce el código de 2 a 5 veces, pero en mi experiencia de refactorizar el código en otros idiomas, especialmente el código de java mapreduce, es más como un código de 10 a 100 veces menos. En serio, he refactorizado cientos de LOC de Java en un puñado de Scala / Spark. También es mucho más fácil de leer y razonar. Spark es aún más conciso y fácil de usar que las herramientas de abstracción de Hadoop como pig & hive, es incluso mejor que Scalding.

Spark tiene un repl / shell. Se elimina la necesidad de un ciclo de compilación-despliegue para ejecutar trabajos simples. Uno puede jugar de forma interactiva con datos al igual que uno usa Bash para hurgar en un sistema.

Lo último que viene a la mente es la facilidad de integración con Big Table DBs, como cassandra y hbase. En cass para leer una tabla para hacer un análisis, uno solo hace

sc.cassandraTable[MyType](tableName).select(myCols).where(someCQL)

Se esperan cosas similares para HBase. ¡Ahora intenta hacer eso en cualquier otro marco de MPP!

ACTUALIZAR el pensamiento de señalar que esto es solo las ventajas de Spark, hay algunas cosas útiles en la parte superior. Por ejemplo, GraphX para el procesamiento de gráficos, MLLib para un fácil aprendizaje automático, Spark SQL para BI, BlinkDB para consultas de apprx increíbles y, como se mencionó, Spark Streaming

Creo que hay tres razones principales.

Las dos razones principales se derivan del hecho de que, por lo general, una no ejecuta un solo trabajo MapReduce, sino más bien un conjunto de trabajos en secuencia.

Una de las principales limitaciones de MapReduce es que persiste el conjunto de datos completo a HDFS después de ejecutar cada trabajo. Esto es muy costoso, ya que incurre en tres veces (para la replicación) el tamaño del conjunto de datos en la E / S del disco y una cantidad similar de E / S de red. Spark tiene una visión más holística de una tubería de operaciones. Cuando la salida de una operación debe alimentarse a otra operación, Spark pasa los datos directamente sin escribir en el almacenamiento persistente. Esta es una innovación sobre MapReduce que proviene del papel Dryad de Microsoft y no es original de Spark.
La principal innovación de Spark fue introducir una abstracción de almacenamiento en caché en memoria. Esto hace que Spark sea ideal para cargas de trabajo donde múltiples operaciones acceden a los mismos datos de entrada. Los usuarios pueden indicar a Spark que almacene en la memoria caché los conjuntos de datos de entrada, por lo que no es necesario leerlos en el disco para cada operación.
¿Qué pasa con los trabajos de Spark que se reducirían a un solo trabajo de MapReduce? En muchos casos, también se ejecutan más rápido en Spark que en MapReduce. La principal ventaja que tiene Spark aquí es que puede iniciar tareas mucho más rápido. MapReduce inicia una nueva JVM para cada tarea, que puede demorar unos segundos en cargar JARs, JIT, analizar la configuración XML, etc. Spark mantiene una JVM ejecutora ejecutándose en cada nodo, por lo que iniciar una tarea es simplemente una cuestión de hacer un RPC y pasar un Runnable a un grupo de subprocesos, que toma los dígitos únicos de milisegundos.

Por último, un error común que probablemente vale la pena mencionar es que Spark de alguna manera se ejecuta completamente en la memoria, mientras que MapReduce no lo hace. Esto simplemente no es el caso. La implementación aleatoria de Spark funciona de manera muy similar a la de MapReduce: cada registro se serializa y se escribe en el disco en el lado del mapa y luego se busca y se deserializa en el lado de reducción.

El almacenamiento en caché + en el cálculo de la memoria es definitivamente una gran cosa para la chispa, sin embargo, hay otras cosas.

RDD (conjunto de datos distribuidos resilientes): un RDD es la abstracción principal de la chispa. Permite la recuperación de nodos fallidos mediante el recálculo del DAG y, al mismo tiempo, admite un estilo de recuperación más similar a Hadoop a través del control, para reducir las dependencias de un RDD. Almacenar un trabajo de chispa en un DAG permite un cálculo lento de RDD y también permite que el motor de optimización de chispa programe el flujo de manera que haga una gran diferencia en el rendimiento.

Spark API: Hadoop MapReduce tiene una API muy estricta que no permite tanta versatilidad. Como la chispa extrae muchos de los detalles de bajo nivel, permite una mayor productividad. También cosas como las variables de transmisión y los acumuladores son mucho más versátiles que DistributedCache y los contadores IMO.

Transmisión de chispas: la transmisión de chispas se basa en un flujo de datos discretizados, que propone un nuevo modelo para realizar cálculos de ventana en flujos utilizando micro lotes. Hadoop no soporta nada como esto.

Como producto de la memoria, la chispa actúa como su propio planificador de flujo. Mientras que con MR estándar necesita un programador de trabajos externo como Azkaban u Oozie para programar flujos complejos

El proyecto hadoop se compone de MapReduce, YARN, commons y HDFS; Sin embargo, Spark está intentando crear una plataforma de Big Data unificada con bibliotecas (en el mismo repositorio) para el aprendizaje automático, el procesamiento de gráficos, la transmisión, las bibliotecas de tipo sql múltiples y creo que una biblioteca de aprendizaje profundo está en las etapas iniciales. Si bien nada de esto es estrictamente una característica de spark, es un producto del modelo informático de spark. Tachyon y BlinkDB son otras dos tecnologías que se basan en la chispa.

mucho fue cubierto por Aaronman y Samthebest. Tengo algunos puntos más.

Chispa tiene mucho menor por trabajo y por sobrecarga de tarea. Le permite aplicarla en los casos en que Hadoop MR no es aplicable. Es en los casos en que se necesita respuesta en 1-30 segundos.
La baja sobrecarga por tarea hace que Spark sea más eficiente incluso para trabajos grandes con muchas tareas cortas. Como una estimación muy aproximada, cuando la tarea tarda 1 segundo, Spark será 2 veces más eficiente que Hadoop MR.
La chispa tiene una abstracción más baja que la RM: es un gráfico de cálculos. Como resultado, es posible implementar un procesamiento más eficiente que el MR, específicamente en los casos en que no se necesita una clasificación. En otras palabras, en MR siempre pagamos por la clasificación, pero en Spark no tenemos que hacerlo.

Apache Spark procesa los datos en memoria mientras que Hadoop MapReduce persiste en el disco después de un mapa o acción de reducción. Pero Spark necesita mucha memoria.
Spark carga un proceso en la memoria y lo mantiene allí hasta nuevo aviso, por el bien del almacenamiento en caché.
Conjunto de datos distribuido resistente (RDD) , que le permite almacenar datos de forma transparente en la memoria y conservarlos en el disco si es necesario.
Como Spark usa en la memoria, no hay una barrera de sincronización que lo esté ralentizando. Esta es una razón importante para el rendimiento de Spark.
En lugar de solo procesar un lote de datos almacenados, como es el caso con MapReduce, Spark también puede manipular los datos en tiempo real utilizando Spark Streaming .
La API DataFrames se inspiró en los marcos de datos en R y Python (Pandas), pero se diseñó desde cero como una extensión de la API RDD existente.
Un DataFrame es una colección distribuida de datos organizados en columnas con nombre, pero con optimizaciones más completas bajo el capó que apoyan la velocidad de la chispa.
El uso de RDD s Spark simplifica las operaciones complejas, como unirse y agrupar, y en el backend, se trata de datos fragmentados. Esa fragmentación es lo que permite que Spark se ejecute en paralelo.
Spark permite desarrollar líneas de datos complejas de varios pasos utilizando un patrón de gráfico acíclico dirigido ( DAG ). Admite el uso compartido de datos en memoria a través de DAG, de modo que diferentes trabajos puedan trabajar con los mismos datos. Los DAG son una parte importante de la velocidad de Spark .
La base de código de chispa es mucho más pequeña.

Espero que esto ayude.