Análisis de datos en acción: Optimizando el crecimiento de Cyclistic
Spark
1. SPARK - RDD
“Resilient Distributed Datasets: A Fault-Tolerant
Abstraction for In-Memory Cluster Computing”
Carmen Alonso Martínez
Manuel Bazaga Fortes
Javier de la Rosa Fernández
Alexandra Conde Herno
Danilo Alencar
2. SPARK
● Introducción
● RDD’s
● Interfaz de programación
● Representación de los RDD’s
● Implementación
● Evaluación
● Comentarios y trabajo actual
● Conclusión
3. Introducción
Framework especializado para computación iterativa y
minería de datos interactiva.
¿Reutilizar resultados intermedios para varios cálculos?
-Queremos crear subconjuntos de datos y realizar varias
‘queries’ sobre ellos
RETO: tolerancia a fallos
4. RDD - Definición
Colección particionada de datos de sólo lectura.
Se crean a partir de operaciones deterministas
sobre:
● Almacenamiento estable
● Otros RDDs
Permiten a los usuarios elegir la estrategia de
almacenamiento.
5. Interfaz de programación Spark
Cada colección de datos se representa como un objeto, y
las transformaciones se invocan utilizando métodos sobre
estos objetos.
Los RDDs son calculados la primera vez que se ejecuta
una acción sobre ellos.
Si no hay suficiente RAM, Spark puede pasar los RDDs a
disco.
7. Ventajas del modelo RDD
Diferencia RDDs vs DSM:
RDD-transf. de granularidad gruesa
DSM-permiten R/W de granularidad fina
● Recuperación: linaje
● Mitigación de nodos lentos
● Programación de tareas
● Degradación gradual cuando falta memoria
8. Aplicaciones no adecuadas para RDDs
Actualizaciones asíncronas de granularidad fina
ie: web crawler, almacenamiento para aplicaciones web
Misma operación a todos los elementos del dataset
Análisis masivos
9. SPARK
● Introducción
● RDD’s
● Interfaz de programación
● Representación de los RDD’s
● Implementación
● Evaluación
● Comentarios y trabajo actual
● Conclusión
10. Spark Programming Interface
● Spark proporciona una API similar a DryadLINQ y a
Flume.
● Los programadores definen los RDD a través de
transformaciones o de datos de almacenamiento
estables.
● A estos RDDs se les aplican acciones
o Acciones: operaciones que devuelven un valor a la
aplicación o exportan datos al sistema de
almacenamiento.
11. Spark Programming Interface
Spark maneja los RDD de forma perezosa, una
transformación no se realiza hasta que una acción no
se ejecuta por primera vez.
Mediante el método persist se puede indicar a Spark
que datos serán reusados
Spark permite almacenar también en disco los RDD
en lugar de en memoria (por defecto).
También se puede establecer prioridades de
persistencia
12. Ejemplo de aplicaciones
Logistic Regression
Al aplicar el algoritmo al mismo conjunto de datos y estar
estos datos en memoria puede aumentar la velocidad 20x.
14. SPARK
● Introducción
● RDD’s
● Interfaz de programación
● Representación de los RDD’s
● Implementación
● Evaluación
● Comentarios y trabajo actual
● Conclusión
15. Representando RDDs
Cada interfaz RDD expone:
● Un conjunto de particiones, que son piezas
atómicas de la base de datos.
● Un conjunto de dependencias de los padres RDDs;
● Una función para calcular el conjunto de datos en
función de sus padres.
● Metadatos sobre su esquema de partición y la
colocación de los datos.
16. Representando RDDs
Existen dos tipos de dependencias RDD:
● Dependencias estrechas, donde cada partición de
la matriz RDD es utilizada como máximo por una
particion hija.
● Dependencias anchas, donde múltiples particiones
secundarias pueden depender de ella.
17. Representando RDDs
Dependencias estrechas vs anchas
● Estrechas
Permite la ejecución en Pipeline
y calcula todas las particiones
del padre (segmentar).
Recuperación tras fallo más
eficiente
Ej: map
● Anchas
Requieren que los datos de todas
las particiones de los padres estén
disponibles.
Podría requerir una re-ejecución
Ej: join
18. Algunas implementaciones RDD
● HDFS: Una posible entrada RDD podría ser un
HDFS. Devuelve una partición por bloque de fichero.
● Map: Devuelve un objeto MappedRDD con las
mismas particiones y preferencias de localización que
su padre.
● Union: La función unión aplicada a dos RDD
devuelve un RDD cuya particiones son la unión de
los dos padres.
19. Algunas implementaciones RDD
● sample: Función similar a la función map. El RDD
guarda un número aleatorio generado por una semilla
para cada partición.
● join: La unión de dos RDD puede conducir a:
o Dos dependencias estrechas
o Dos dependencias anchas
o Combinación de ambas
Pero en cualquier caso la salida es un RDD.
20. SPARK
● Introducción
● RDD’s
● Interfaz de programación
● Representación de los RDD’s
● Implementación
● Evaluación
● Comentarios y trabajo actual
● Conclusión
21. Implementación
- Implementan Spark en 14000 líneas de Scala
- El sistema se ejecuta sobre el administrador de Cluster Mestos
permitiendo compartir recursos con Hadoop, MPI y otras
aplicaciones
- Cada programa de Spark funciona con una aplicación separada
de Mesos, con su propio driver y workers y recursos comparti-
dos entre estas aplicaciones que está manejada por Mesos
- Spark puede leer cualquier datos de entrada de Hadoop usando
APIs del propio Hadoop y ejecutar una versión de Scala sin
cambios
22. Planificación de Tareas
Usa representación de RDDs,
es similar al Dryads pero añade
cuales particiones persistentes
están disponibles en memoria.
Si el usuario ejecuta una
acción (count o save) en el
RDD, el planificador examina
cual línea gráfica del RDD para
construir el DAG de stages
para ser ejecutado
23. Planificación de Tareas
El planificador:
● Ejecuta las tareas de particiones faltosas para cada stage hasta que
esté computada con el objetivo de RDD
● Asigna tarea para cada máquina basada en los datos locales usando
un delay, es decir, si la tarea necesita que la partición sea procesada
en la memoria disponible en un nodo, enviaremos para este nodo, de
lo contrario, si una tarea procesa una partición para algún RDD que
proporcione ubicaciones preferidas (ej.: un archivo de HDFS),
nosotros le enviamos a este.
24. Integración Intérprete
- Shell interactivo similares al de Ruby y Python
- Usuarios ejecutarán Spark interactivamente desde el intérprete para
consultar grandes conjuntos de datos
- El intérprete opera compilando la clase para cada línea tecleada por
el usuario, cargando en el JVM e invocando una función a él
- Esta clase incluye un objeto semifallo que contiene las variables o
funciones en esta línea e que ejecuta el código de línea en el método
de inicialización.
25. Integración Intérprete
Usuario teclea var x = 5 println (x) y el intérprete define
Class Line1 que contiene x y causa que la segunda línea
compile como println(Line1.getInstance().x)
1- Envío de Clase – deja que los nodos worker traigan el
bytecode para las clases creadas en la cada línea usando
HTTP.
2- Generación de código modificado - como el objeto
creado de semifallo se accede por método estático en
su clase correspondiente, Java no se traza a través del
gráfico de objeto para enviar la instancia la Línea 1
envolver alrededor del x. Pero los nodos workers
tampoco recibirán la x. Cambiamos que el código lógico
referencie la instancia para cada línea de objeto
directamente.
26. Administración de memoria
Provee 3 opciones para almacenamiento persistentes de
RDDs:
- En memoria como objeto Java deserializados
- En memoria como datos deserializados
- Almacenamiento en disco
27. Soporte para Checkpointing
- Es útil para estabilizar el almacenamiento
- Es útil para RDD tenga linaje de grafos de
dependencias anchas como los datasets de PageRank
- Spark provee API para este Soporte de Checkpointing
pero deja la decisión de soporte para el usuario.
28. SPARK
● Introducción
● RDD’s
● Interfaz de programación
● Representación de los RDD’s
● Implementación
● Evaluación
● Comentarios y trabajo actual
● Conclusión
29. Evaluación
● Se realizan una serie de experimentos para evaluar Spark y los RDD,:
○ velocidad con respecto a otros sistemas (Hadoop y HadoopBM)
○ evaluación de la escalabilidad
○ tolerancia a fallos
● Amazon EC2:
○ Máquinas xlarge con 4 cores y 15 GB de RAM
○ Hemos usado HDFS con 256 MB de tamaño bloque
30. Aplicaciones iterativas de Machine Learning
Sistemas:
● Hadoop 0.20.2 ( ahora
va por el 2.60)
● HadoopBinMem
● Spark
Datos:
● 100 GB de datos
● Cluster de 100 nodos
Mejora de 20x
31. Ejemplo - Pagerank
Datos:
● 54 GB de Wikipedia
● 10 iteraciones
● 4 millones de artículos
Sistemas:
● Hadoop
● Spark
● Spark + Particiones
Controladas
Mejora de 7.4 X
34. Otras aplicaciones implementadas en Spark
Traffic Modeling:
● 10000 link
● 600000 ejemplos de tramos de
viaje
Spam en Twitter:
● 50GB datos
● 250000 URLs
35. Ejemplo - Minería de Datos
Datos:
● 1TB de logs de Wikipedia
● 2 años de datos)
● 100 4xlarge instancias EC2
● 8 cores y 68GB de RAM
36. Evaluación - conclusiones
● Spark llega a ser hasta 20x en aplicaciones de Machine
Learning Iterativas.
● Aplicaciones de usuarios (video, tráfico,...) llegan a ser 40x más
rápidas que con Hadoop.
● Si un nodo falla, Spark puede recuperarse rápidamente
reconstruyendo sólo los RDDs perdidos.
● Spark puede ser usado para hacer consultas a un conjunto de
datos de 1TB con una latencia de unos 5-7 segundos.
37. SPARK
● Introducción
● RDD’s
● Interfaz de programación
● Representación de los RDD’s
● Implementación
● Evaluación
● Comentarios y trabajo actual
● Conclusión
38. Discusión
Aunque las RDDs parecen ofrecer una interfaz de programación
limitada debido a su naturaleza inmutable y transformaciones de
granularidad gruesa, hemos encontrado que son adecuadas para
una amplia clase de aplicaciones.
Pueden expresar un sorprendente número de modelos de
programación de clúster que hasta el momento se han propuesto
como frameworks separados, lo que permite a los usuarios
componer estos modelos en un programa y compartir datos entre
ellos.
39. Expresando Modelos Existentes
● MapReduce
● DryadLINQ SQL.
● Pregel.
● MapReduce iterativo.
● Procesamiento de flujo por lotes.
40. Aprovechamiento para la depuración
Diseño determinista recomputable para tolerancia a fallos, esta
propiedad también facilita la depuración:
1. Reconstruir estos RDD después y permitir al usuario consultar
de forma interactiva.
1. Volver a ejecutar cualquier tarea desde el trabajo en un
depurador de un solo proceso
41. Trabajo Relacionado
Modelos de Programación de clúster
● A diferencia de MapReduce, Dryad y Ciel representa un
intercambio más eficiente de la abstracción de datos que el
almacenamiento estable porque evitan el costo de replicación
de datos, I/O y serialization.
● DryadLINQ y FlumeJava proporcionan un API de lenguaje
integrado donde el usuario manipula "colecciones paralelas" a
través de operadores como map y join, no pueden compartir
eficientemente datos a través de consultas.
42. Trabajo Relacionado
● Aplicaciones que requieren el intercambio de datos, Pregel es
compatible con aplicaciones de gráficos iterativos, mientras que
en Twister y HaLoop son los tiempos de ejecución de
MapReduce iterativos. RDDs proporcionan una abstracción de
almacenamiento distribuido de forma explícita y por lo tanto
pueden soportar aplicaciones que estos sistemas
especializados no capturan, como la minería de datos
interactiva
43. Trabajo Relacionado
● Algunos sistemas exponen un estado mutable compartido para
permitir al usuario realizar la computación en memoria. Por
ejemplo, Piccolo permite a los usuarios ejecutar funciones
paralelas que leen y actualizan celdas en una tabla hash
distribuida, similar a los sistemas Distribuidos de Memoria
Compartida (DSM) y las stores de clave valor como RAMCloud.
RDDs proporcionan una interfaz de programación de alto nivel
basado en operadores como map, sort y join. Y recuperación de
datos basados en linaje(Piccolo y DSM). también proporcionan
otras ventajas sobre DSM, como la mitigación rezagada
44. Trabajo Relacionado
Sistemas de almacenamiento en caché
● Nectar puede reutilizar los resultados intermedios a través de
trabajos DryadLINQ identificando sub expresiones comunes con
el análisis del programa. No proporciona el almacenamiento en
memoria caché (se coloca los datos en una sistema de datos
distribuido), ni permite a los usuarios controlar de forma
explícita qué conjuntos de datos para persistir y cómo
particionarlos
● Ciel y FlumeJava no proporcionan control sobre lo que se
almacena en memoria caché o que datos son cacheados.
45. Trabajo Relacionado
Linaje
● El mecanismo de recuperación basado en el linaje es similar al
mecanismo de recuperación que se utiliza dentro de un
cómputo (Job) en MapReduce y Dryad, que registra las
dependencias entre un DAG de tareas. en estos sistemas, la
información se pierde después que termina un trabajo, lo que
requiere el uso de un sistema de almacenamiento replicado
para compartir datos a través de cálculos. RDD aplican linaje
para persistir en la memoria los datos eficientemente a través
de cálculos, sin costo de replicación e I/O de disco.
46. Trabajo Relacionado
Bases de datos relacionales
● RDD persistentes asemejan vistas materializadas. Sin embargo,
al igual que los sistemas de DSM, las bases de datos suelen
permitir acceso de grano-fino de lectura y escritura a todos los
registros, lo que requiere el registro de las operaciones y datos
para la tolerancia a fallos y la sobrecarga adicional para
mantener la consistencia. Estos gastos no son necesarios con
el modelo de transformación de grano grueso de RDD
47. SPARK
● Introducción
● RDD’s
● Interfaz de programación
● Representación de los RDD’s
● Implementación
● Evaluación
● Comentarios y trabajo actual
● Conclusión
48. Conclusión
● Son eficientes, de uso general y con tolerancia a fallos para el
intercambio de datos en las aplicaciones del clúster.
● RDD puede expresar una amplia gama de aplicaciones
paralelas (modelos de programación especializados que se han
propuesto para el cálculo iterativo)
● RDD ofrecen una API basada en las transformaciones de
granuralidad gruesa que les permite recuperar datos
eficientemente usando linaje.
● Implementaron RDD en Spark que supera a Hadoop hasta en
un 20 × y se puede utilizar de forma interactiva para consultar
cientos de gigabytes de datos.
Notas del editor
Hay muchos frameworks capaces de trabajar con grandes cantidades de datos, sin embargo se detectó la necesidad de crear uno específicamente para la computación iterativa (por ejemplo, aplicaciones que aplican la misma operación a diferentes conjuntos de datos)
-¿reutilizar...
Hasta Spark, la única manera de hacer queries sobre un subconjunto de datos era escribir tal subconjunto en un almacenamiento externo, lo cual aumentaba mucho el tiempo de ejecución.
El reto que plantea es implementar una interfaz capaz de proveer tolerancia a fallos eficientemente.
Hasta ahora, la manera de implementar tolerancia a fallos era replicar los datos, lo cual resulta caro.
Los RDDs juegan con la granularidad de las operaciones y loguean las transformaciones utilizadas para construir el subconjunto, en lugar de almacenar los datos tal cual.
Como veremos más adelante, jugando en su campo Spark mejora el tiempo de ejecución de Hadoop a la vigésima parte.
Los RDD son colecciones particionadas de datos, construidas a partir de bases de datos mayores u otros RDDs.
Como ya hemos dicho, guardan información de cómo fueron calculados.
Finalmente, los usuarios pueden elegir la estrategia de almacenamiento, es decir la persistencia y el el particionamiento de los RDDs para optimizar la aplicación.
-
Se comienza creando RDDs mediante transformaciones como map o filter, y después se aplican acciones (que son los métodos que devuelven un valor), como count o collect.
Los RDDs son calculados “de manera vaga” la primera vez que se ejecuta una acción sobre ellos.
Si no hay suficiente RAM, Spark puede pasar los RDDs a disco.
Esto también forma parte de la estrategia de almacenamiento que hemos dicho antes que podíamos definir.
Podemos replicar los RDDs en varias máquinas, crearlos sólo en disco o establecer una prioridad acerca de qué RDD debería paginar a disco primero.
ie: un servicio web
En lugar de mirar todos los logs, con Spark podemos cargar en RAM sólo los mensajes de error y hacer queries sobre ellos.
La primera línea crea un RDD a partir de un fichero HDFS, y la segunda línea crea un RDD a partir del RDD anterior. La tercera línea pide que este último RDD persista en memoria.
A partir de aquí se pueden aplicar acciones sobre “errors”.
(Cuando se ejecute la primera acción sobre “errors”, se guardará en memoria para agilizar cómputos posteriores)
El paper compara el modelo RDD con el DSM (Distributed shared memory) que lee y escribe en localizaciones arbitrarias de un espacio de direccionamiento global.
DSM es una abstracción muy generalista, lo cual dificulta su implementación eficiente en “commodity clusters”
La principal diferencia es que los RDDs pueden ser creados a partir de transformaciones de granularidad alta.
Esto restringe el modelo RDD a aplicaciones de escritura masiva, y permite una tolerancia a fallos más eficiente.
Las ventajas propiamente dichas son las siguientes:
-Los RDDs ahorran en overhead y checkpoints, ya que se pueden recuperar a través de su linaje paralelamente en diferentes nodos.
-Para mitigar los nodos más lentos, Spark corre un backup de las tareas más lentas en MapReduce. Este tema de las tareas backup sería muy difícil de implementar en DSM, ya que ambas tareas accederían a la misma memoria.
-Al hacer operaciones en masa sobre RDDs, se pueden programar las tareas basándose en la localidad de los datos para mejorar el rendimiento
-Por último, en ausencia de memoria (como hemos dicho, empezamos a pasar los datos al disco) y la degradación del modelo RDD es gradual
Algunas aplicaciones no son adecuadas para el modelo RDD porque no se benefician de las novedades que trae.
MapReduce: Este modelo se puede expresar mediante las operaciones flatMap y groupByKey en Spark, o reduceByKey si hay un combinador.
DryadLINQ: El sistema DryadLINQ ofrece una gama más amplia de operadores que MapReduce durante el tiempo de ejecución más general Dryad, pero estos son todos los operadores a granel que corresponden directamente a las transformaciones RDD disponibles en Spark (mapa, groupByKey, unir, etc).
SQL: Como expresiones DryadLINQ, consultas SQL realizan operaciones de datos en paralelo en un conjunto de registros.
Pregel: de Google Pregel [22] es un modelo especializado para aplicaciones de gráficos iterativos que a primera vista parece muy diferente de los modelos de programación orientada a conjuntos en otros sistemas. En Pregel, un programa se ejecuta como una serie de “Superpasos” coordinados. En cada superpaso, cada vértice en el gráfico ejecuta una función de usuario que puede actualizar estado asociado con el vértice, cambiar la topología gráfica, y enviar mensajes a otros vértices para usar en el siguiente superpaso. Este modelo se puede expresar muchos algoritmos de grafos, incluyendo caminos más cortos, bipartita matching y PageRank.
MapReduce iterativo: Varios sistemas propuestos recientemente, incluyendo HaLoop y Twister, proporcionan un modelo MapReduce iterativo en el que el usuario le da al sistema una serie de trabajos de MapReduce de bucle. Los sistemas mantienen datos divididos consistentemente a través de iteraciones, y Twister también lo puede mantener en la memoria. Ambos optimizaciones son fáciles de expresar con RDD, y hemos sido capaces de implementar HaLoop como una librería de 200 líneas usando Spark.
Procesamiento de flujo por lotes: Recientemente los investigadores han propuesto varios sistemas de procesamiento adicionales para las aplicaciones que se actualizan el resultado periódicamente con nuevos datos. Estos sistemas realizan operaciones de bulk similares a Dryad, pero almacenando el estado de la aplicación en sistemas de ficheros distribuidos. Colocando el estado intermedio en RDDs aceleraría su procesamiento.