Traducido del inglés al español - www.onlinedoctranslator.
com
Spark: computación en clúster con conjuntos de trabajo
Matei Zaharia, Mosharaf Chowdhury, Michael J. Franklin, Scott Shenker, Ion Stoica
Universidad de California, Berkeley
Abstracto
MapReduce y sus variantes han tenido mucho éxito en la
implementación de aplicaciones intensivas en datos a gran
escala en clústeres de productos básicos. Sin embargo, la
mayoría de estos sistemas se basan en un modelo de flujo de
datos acíclico que no es adecuado para otras aplicaciones
populares. Este documento se centra en una de esas clases
de aplicaciones: aquellas que reutilizan un conjunto de datos
de trabajo en múltiples operaciones paralelas. Esto incluye
muchos algoritmos iterativos de aprendizaje automático, así
como herramientas interactivas de análisis de datos.
Proponemos un nuevo marco llamado Spark que admite
estas aplicaciones mientras conserva la escalabilidad y la
tolerancia a fallas de MapReduce. Para lograr estos objetivos,
Spark presenta una abstracción llamada conjuntos de datos
distribuidos resilientes (RDD). Un RDD es una colección de
objetos de solo lectura particionados en un conjunto de
máquinas que se pueden reconstruir si se pierde una
partición.
1. Introducción
Un nuevo modelo de computación en clúster se ha vuelto muy popular, en
el que los cálculos paralelos de datos se ejecutan en clústeres de máquinas
poco confiables mediante sistemas que proporcionan automáticamente
programación consciente de la localidad, tolerancia a fallas y balanceo de
carga. MapReduce [11] fue pionero en este modelo, mientras que sistemas
como Dryad [17] y Map-Reduce-Merge [24] generalizaron los tipos de flujos
de datos admitidos. Estos sistemas logran su escalabilidad y tolerancia a
fallas al proporcionar un modelo de programación donde el usuario crea
gráficos de flujo de datos acíclicos para pasar datos de entrada a través de
un conjunto de operadores. Esto permite que el sistema subyacente
administre la programación y reaccione ante fallas sin la intervención del
usuario.
Si bien este modelo de programación de flujo de datos es útil para una
amplia clase de aplicaciones, hay aplicaciones que no se pueden expresar
de manera eficiente como flujos de datos acíclicos. En este documento, nos
centramos en una de esas clases de aplicaciones: aquellas que reutilizan un
conjunto de trabajode datos a través de múltiples operaciones paralelas.
Esto incluye dos casos de uso en los que hemos visto a usuarios de Hadoop
informar que MapReduce es deficiente:
• Trabajos iterativos:Muchos algoritmos comunes de aprendizaje
automático aplican una función repetidamente al mismo conjunto de
datos para optimizar un parámetro (p. ej., a través del descenso de
gradiente). Si bien cada iteración se puede expresar como un
1
MapReduce/Dryad, cada trabajo debe recargar los datos del disco, lo
que genera una penalización significativa en el rendimiento.
• Análisis interactivo:Hadoop se usa a menudo para ejecutar
consultas exploratorias ad-hoc en grandes conjuntos de datos, a
través de interfaces SQL como Pig [21] y Hive [1]. Idealmente, un
usuario podría cargar un conjunto de datos de interés en la
memoria de varias máquinas y consultarlo repetidamente. Sin
embargo, con Hadoop, cada consulta incurre en una latencia
significativa (decenas de segundos) porque se ejecuta como un
trabajo de MapReduce independiente y lee datos del disco.
Este documento presenta un nuevo marco de computación en
clúster llamado Spark, que admite aplicaciones con conjuntos de
trabajo y proporciona propiedades de escalabilidad y tolerancia a
fallas similares a las de MapReduce.
La principal abstracción en Spark es la de unconjunto de datos
distribuido resiliente(RDD), que representa una colección de objetos
de solo lectura particionados en un conjunto de máquinas que se
pueden reconstruir si se pierde una partición. Los usuarios pueden
almacenar en caché explícitamente un RDD en la memoria en todas
las máquinas y reutilizarlo en múltiples aplicaciones similares a
MapReduce.operaciones paralelas. Los RDD logran tolerancia a fallas
a través de una noción delinaje: si se pierde una partición de un RDD,
el RDD tiene suficiente información sobre cómo se derivó de otros
RDD para poder reconstruir solo esa partición. Aunque los RDD no
son una abstracción general de memoria compartida, representan un
punto óptimo entre la expresividad por un lado y la escalabilidad y
confiabilidad por el otro, y los hemos encontrado muy adecuados
para una variedad de aplicaciones.
Spark se implementa en Scala [5], un lenguaje de
programación de alto nivel tipificado estáticamente para Java
VM, y expone una interfaz de programación funcional similar a
DryadLINQ [25]. Además, Spark se puede utilizar de forma
interactiva desde una versión modificada del intérprete de Scala,
que permite al usuario definir RDD, funciones, variables y clases
y utilizarlos en operaciones paralelas en un clúster. Creemos que
Spark es el primer sistema que permite el uso interactivo de un
lenguaje de programación eficiente y de propósito general para
procesar grandes conjuntos de datos en un clúster.
Aunque nuestra implementación de Spark aún es un prototipo, la
experiencia inicial con el sistema es alentadora. Mostramos que Spark
puede superar a Hadoop en 10 veces en cargas de trabajo iterativas de
aprendizaje automático y se puede usar de forma interactiva para escanear
un conjunto de datos de 39 GB con una latencia inferior a un segundo.
Este artículo está organizado de la siguiente forma: La sección 2 describe
Modelo de programación de Spark y RDD. La sección 3 muestra algunos
trabajos de ejemplo. La Sección 4 describe nuestra implementación,
incluida nuestra integración en Scala y su intérprete. La Sección 5 presenta
los primeros resultados. Examinamos el trabajo relacionado en la Sección 6
y terminamos con una discusión en la Sección 7.
2 Modelo de programación
Para usar Spark, los desarrolladores escriben unprograma de
controladorque implementa el flujo de control de alto nivel de su
aplicación y lanza varias operaciones en paralelo. Spark proporciona
dos abstracciones principales para la programación paralela:
conjuntos de datos distribuidos resilientesyoperaciones paralelasen
estos conjuntos de datos (invocado al pasar una función para aplicar
en un conjunto de datos). Además, Spark admite dos tipos
restringidos devariables compartidasque se puede usar en funciones
que se ejecutan en el clúster, que explicaremos más adelante.
2.1 Conjuntos de datos distribuidos resilientes (RDD)
Un conjunto de datos distribuido resistente (RDD) es una colección de
objetos de solo lectura particionados en un conjunto de máquinas que se
pueden reconstruir si se pierde una partición. No es necesario que los
elementos de un RDD existan en almacenamiento físico; en cambio, un
identificador de un RDD contiene suficiente información paracalcularel
RDD a partir de datos en almacenamiento confiable. Esto significa que los
RDD siempre se pueden reconstruir si los nodos fallan.
En Spark, cada RDD está representado por un objeto Scala. Spark
permite a los programadores construir RDD de cuatro maneras:
• A partir de unafileen un sistema de archivos compartido, como el Sistema
de archivos distribuidos de Hadoop (HDFS).
• Por“paralelizar”una colección de Scala (p. ej., una matriz) en
el programa del controlador, lo que significa dividirla en una
serie de segmentos que se enviarán a varios nodos.
• Portransformandoun RDD existente. Un conjunto de datos con
elementos de tipoAse puede transformar en un conjunto de
datos con elementos de tipoBusando una operación llamada
FloridaenMapa, que pasa cada elemento a través de una función
de tipo proporcionada por el usuarioA⇒Lista[B].1Otras
transformaciones se pueden expresar usandoFloridaenMapa,
incluidomapa (pasar elementos a través de una función de tipoA
⇒B) yfifiltro(elegir elementos que coincidan con un predicado).
• Al cambiar elpersistenciade un RDD existente. Por defecto, los
RDD son perezosos y efímeros. Es decir, las particiones de un
conjunto de datos se materializan a pedido cuando se usan en
una operación paralela (p. ej., al pasar un bloque de un archivo a
través de una función de mapa) y se descartan de la memoria
después de su uso.2Sin embargo, un usuario puede alterar la
persistencia de un RDD a través de dos acciones:
– ElcacheLa acción deja el conjunto de datos perezoso, pero
sugiere que debe mantenerse en la memoria después de la
primera vez que se calcula, porque se reutilizará.
1mapa planotiene la misma semántica que elmapaen MapReduce, peromapa
generalmente se usa para referirse a una función uno a uno de tipoA⇒Ben Scala.
2Así es como funcionan las “colecciones distribuidas” en DryadLINQ.
2
– Elahorraraction evalúa el conjunto de datos y lo escribe en
un sistema de archivos distribuido como HDFS. La versión
guardada se utiliza en futuras operaciones sobre ella.
Hacemos notar que nuestrocacheLa acción es solo una sugerencia: si no hay
suficiente memoria en el clúster para almacenar en caché todas las particiones
de un conjunto de datos, Spark las volverá a calcular cuando se usen. Elegimos
este diseño para que los programas de Spark sigan funcionando (con un
rendimiento reducido) si los nodos fallan o si un conjunto de datos es demasiado
grande. Esta idea es vagamente análoga a la memoria virtual.
También planeamos ampliar Spark para admitir otros niveles de
persistencia (p. ej., replicación en memoria en varios nodos). Nuestro
objetivo es permitir que los usuarios compensen entre el costo de
almacenar un RDD, la velocidad de acceso a él, la probabilidad de
perder parte de él y el costo de volver a calcularlo.
2.2 Operaciones paralelas
Se pueden realizar varias operaciones paralelas en los RDD:
• reducir: combina elementos del conjunto de datos usando una función
asociativa para producir un resultado en el programa controlador.
• recolectar: envía todos los elementos del conjunto de datos al
programa controlador. Por ejemplo, una forma sencilla de actualizar
un arreglo en paralelo es paralelizar, mapear y recopilar el arreglo.
• para cada: pasa cada elemento a través de una función proporcionada
por el usuario. Esto solo se hace por los efectos secundarios de la
función (que podría ser copiar datos a otro sistema o actualizar una
variable compartida como se explica a continuación).
Notamos que Spark actualmente no admite una operación de
reducción agrupada como en MapReduce; Los resultados de
reducción solo se recopilan en un proceso (el controlador).3
Planeamos admitir reducciones agrupadas en el futuro usando una
transformación "shuffle" en conjuntos de datos distribuidos, como se
describe en la Sección 7. Sin embargo, incluso usar un solo reductor
es suficiente para expresar una variedad de algoritmos útiles. Por
ejemplo, un artículo reciente sobre MapReduce para el aprendizaje
automático en sistemas multinúcleo [10] implementó diez algoritmos
de aprendizaje sin admitir la reducción paralela.
2.3 Variables compartidas
Los programadores invocan operaciones comomapa,fifiltroyreducir
pasando cierres (funciones) a Spark. Como es típico en la
programación funcional, estos cierres pueden referirse a variables en
el ámbito donde se crean. Normalmente, cuando Spark ejecuta un
cierre en un nodo trabajador, estas variables se copian en el
trabajador. Sin embargo, Spark también permite a los programadores
crear dos tipos restringidos devariables compartidaspara admitir dos
patrones de uso simples pero comunes:
• Variables de difusiónNota: si se utiliza una gran cantidad de
datos de solo lectura (p. ej., una tabla de búsqueda) en varias
operaciones paralelas, es preferible distribuirla a los trabajadores
solo una vez en lugar de empaquetarla con cada cierre. Spark le
permite al programador crear una "variante de transmisión".
3Sin embargo, primero se realizan reducciones locales en cada nodo.
 capaz” que envuelve el valor y asegura que solo se
copie a cada trabajador una vez.
• Acumuladores: Estas son variables que los trabajadores solo
pueden "agregar" usando una operación asociativa, y que solo el
controlador puede leer. Se pueden usar para implementar
contadores como en MapReduce y para proporcionar una
sintaxis más imperativa para sumas paralelas. Los acumuladores
se pueden definir para cualquier tipo que tenga una operación
de "sumar" y un valor "cero". Debido a su semántica de "solo
agregar", son fáciles de hacer tolerantes a fallas.
3 ejemplos
Ahora mostramos algunos ejemplos de programas Spark. Tenga en cuenta que
omitimos los tipos de variables porque Scala admite la inferencia de tipos.
3.1 Búsqueda de texto
Supongamos que deseamos contar las líneas que contienen errores en un archivo de
registro grande almacenado en HDFS. Esto se puede implementar comenzando con un
objeto de conjunto de datos de archivo de la siguiente manera:
archivo val = chispa.textFile("hdfs://...")
val errs = archivo.filtro(_.contains("ERROR"))palabra en Scala es azúcar sintáctico para invocar elpara cada
val unos = errs.map(_ => 1) val cuenta método de una colección con el cuerpo del bucle como cierre. Es
= unos.reduce(_+_) decir, el códigopara (p <- puntos){cuerpo}es equivalente
alente apuntos.foreach(p =>{cuerpo}). Por lo tanto,
Primero creamos un conjunto de datos distribuido llamadoarchivo
que representa el archivo HDFS como una colección de líneas.
Transformamos este conjunto de datos para crear el conjunto de
líneas que contienen "ER-ROR" (errar),y luego asigne cada línea a un 1
y sume estos usandoreducir. Los argumentos afifiltro,mapay reducir
son sintaxis de Scala para literales de función.
Tenga en cuenta quese equivocayunosson RDD perezosos que nunca se
materializan. En cambio, cuandoreducirse llama, cada nodo de trabajo
escanea bloques de entrada en forma de transmisión para evaluar
unos,los agrega para realizar una reducción local y envía su recuento
local al controlador. Cuando se usa con conjuntos de datos perezosos
de esta manera, Spark emula de cerca a MapReduce.
Donde Spark difiere de otros marcos es que puede hacer que
algunos de los conjuntos de datos intermedios persistan entre
operaciones. Por ejemplo, si quisiera reutilizar else equivoca
conjunto de datos, podríamos crear un RDD en caché a partir de él de la siguiente manera:
val cachedErrs = errs.cache()
Ahora seríamos capaces de invocar operaciones paralelas en
cachedErrso en conjuntos de datos derivados de él como de costumbre,
pero los nodos almacenarían en caché particiones decachedErrsen la
memoria después de la primera vez que los calculan, lo que acelera
enormemente las operaciones posteriores en él.
3.2 Regresión logística
El siguiente programa implementa la regresión logística [3], un
algoritmo de clasificación iterativo que intenta encontrar un
hiperplanowque separa mejor dos conjuntos de puntos. El
algoritmo realiza un descenso de gradiente: comienzawen un
valor aleatorio, y en cada iteración, suma una función de
3
wsobre los datos para moverwen una dirección que lo mejore. Por lo tanto, se
beneficia enormemente del almacenamiento en caché de los datos en la
memoria a lo largo de las iteraciones. No explicamos la regresión logística en
detalle, pero la usamos para mostrar algunas características nuevas de Spark.
// Leer puntos de un archivo de texto y almacenarlos en caché
val points = spark.textFile(...)
. mapa (punto de análisis). caché ()
// Inicializar w a un vector D-dimensional aleatorio var w =
Vector.random(D)
// Ejecutar múltiples iteraciones para actualizar w
para (i <- 1 a ITERACIONES) {
val grad = chispa.acumulador(nuevo Vector(D)) para (p <-
puntos) { // Se ejecuta en paralelo
val s = (1/(1+exp(-py*(w dot px)))-1)*py grad += s * px
}
w -= grad.value
}
Primero, aunque creamos un RDD llamadopuntos,lo
procesamos ejecutando unparabucle sobre él. Elparallave-
estamos invocando el paralelo de Sparkpara cadaoperación.
En segundo lugar, para resumir el gradiente, usamos una variable
acumuladora llamadadegradado (con un valor de tipoV ector). Tenga en
cuenta que el bucle se suma adegradadoutilizando un sobrecargado
+ =operador. La combinación de acumuladores ypara
La sintaxis permite que los programas Spark se parezcan mucho a los
programas seriales imperativos. De hecho, este ejemplo difiere de
una versión en serie de regresión logística en solo tres líneas.
3.3 Mínimos cuadrados alternos
Nuestro ejemplo final es un algoritmo llamado mínimos cuadrados
alternos (ALS). ALS se usa para problemas de filtrado colaborativo, como
predecir las calificaciones de los usuarios para películas que no han visto
en función de su historial de calificación de películas (como en Netflix
Challenge). A diferencia de nuestros ejemplos anteriores, ALS requiere un
uso intensivo de la CPU en lugar de un uso intensivo de los datos.
Esbozamos brevemente ALS y remitimos al lector a [27] para obtener
más detalles. Supongamos que quisiéramos predecir las calificaciones detu
usuarios parametropelículas, y que teníamos una matriz parcialmente llena
Rque contiene las calificaciones conocidas para algunos pares de películas
de usuario. modelos ALSRcomo el producto de dos matricesMETRO ytude
dimensionesmetro×kyk×turespectivamente; es decir, cada usuario y cada
película tiene unak"vector de funciones" bidimensional que describe sus
características, y la calificación de un usuario para una película es el
producto escalar de su vector de funciones y el de la película. ALS resuelve
paraMETROytuusando las calificaciones conocidas y luego calculaMETRO×
tupara predecir las desconocidas. Esto se hace usando el siguiente proceso
iterativo:
1. InicializarMETROa un valor aleatorio.
2. OptimizartudadoMETROpara minimizar el error enR.
3. OptimizarMETROdadotupara minimizar el error enR.
4. Repita los pasos 2 y 3 hasta la convergencia.
ALS se puede paralelizar actualizando diferentes usuarios/películas
en cada nodo en los pasos 2 y 3. Sin embargo, debido a que todos los
pasos usanR, es útil hacerRuna variable de difusión para que no se
vuelva a enviar a cada nodo en cada paso. A continuación se muestra
una implementación de Spark de ALS que lo hace. Tenga en cuenta
que nosotrosparalelizarla colección0 hasta tu
(un objeto de rango de Scala) yrecolectarpara actualizar cada matriz:
val Rb = chispa.broadcast(R) para (i <-
1 a ITERACIONES) {
U = chispa.paralelizar (0 hasta u)
. map(j => actualizarUsuario(j, Rb, M))
. recolectar()
M = chispa.paralelizar (0 hasta m)
. map(j => actualizarUsuario(j, Rb, U))
. recolectar()
} interfaz de RDD. Por ejemplo, para unHdfs-TextFile, las particiones
4 Implementación
Spark se basa en Mesos [16, 15], un "sistema operativo de clúster"
que permite que varias aplicaciones paralelas compartan un clúster
de manera detallada y proporciona una API para que las aplicaciones
inicien tareas en un clúster. Esto permite que Spark se ejecute junto
con los marcos de computación en clúster existentes, como los
puertos Mesos de Hadoop y MPI, y comparta datos con ellos. Además,
construir sobre Mesos redujo en gran medida el esfuerzo de
programación que tuvo que realizar Spark.
El núcleo de Spark es la implementación de conjuntos de datos
distribuidos resilientes. Como ejemplo, supongamos que definimos un
conjunto de datos en caché llamadocachedErrsque representan mensajes
de error en un archivo de registro, y que contamos sus elementos usando
mapayreducir, como en la Sección 3.1:
archivo val = chispa.textFile("hdfs://...")
val errs = archivo.filtro(_.contains("ERROR"))Los seguros son objetos de Java y se pueden serializar utilizando el software de Java.
val cachedErrs = errs.cache() val ones =
cachedErrs.map(_ => 1) val count =
ones.reduce(_+_)
Estos conjuntos de datos se almacenarán como una cadena de objetos cap-
girando ellinajede cada RDD, que se muestra en la Figura 1. Cada
objeto de conjunto de datos contiene un puntero a su padre e
información sobre cómo se transformó el padre.
Internamente, cada objeto RDD implementa la misma
interfaz simple, que consta de tres operaciones:
• obtenerparticiones, que devuelve una lista de ID de partición.
• getIterator(partición), que itera sobre una partición.
• getPreferredLocations(partición), que se utiliza para
programación de tareas para lograr la localidad de datos.
Cuando se invoca una operación paralela en un conjunto de datos, Spark
crea untareapara procesar cada partición del conjunto de datos y
envía estas tareas a los nodos trabajadores. Tratamos de enviar cada
4
HdfsTextFile
archivo:
ruta = hdfs://…
Conjunto de datos filtrados
errores:
func = _. contiene (…)
errores en caché: CachedDataset
MappedDataset
unos:
función = _ => 1
Figura 1: Cadena de linaje para los objetos del conjunto de datos distribuidos
definidos en el ejemplo de la Sección 4.
tarea a una de sus ubicaciones preferidas usando una técnica llamada
programación de retraso [26]. Una vez lanzada en un trabajador, cada
tarea llamagetIteratorpara comenzar a leer su partición.
Los diferentes tipos de RDD difieren solo en cómo implementan la
son ID de bloque en HDFS, sus ubicaciones preferidas son las
ubicaciones de bloque ygetIterator abre una secuencia para leer un
bloque. en unMappedDataset, las particiones y las ubicaciones
preferidas son las mismas que para el padre, pero el iterador aplica la
función de mapa a los elementos del padre. Finalmente, en un
CachedDataset, el getIteratorEl método busca una copia en caché
local de una partición transformada, y las ubicaciones preferidas de
cada partición comienzan igual que las ubicaciones preferidas de los
padres, pero se actualizan después de que la partición se almacena
en caché en algún nodo para preferir reutilizar ese nodo. Este diseño
hace que las fallas sean fáciles de manejar: si un nodo falla, sus
particiones se vuelven a leer desde sus conjuntos de datos principales
y finalmente se almacenan en caché en otros nodos.
Por último, enviar tareas a los trabajadores requiere que se les envíen
cierres, tanto los cierres que se usan para definir un conjunto de datos
distribuido como los cierres que se transfieren a operaciones como reducir.
Para lograr esto, nos basamos en el hecho de que Scala Clo-
rialización; esta es una característica de Scala que hace que sea
relativamente sencillo enviar un cálculo a otra máquina. Sin embargo,
la implementación de cierre incorporada de Scala no es ideal, porque
hemos encontrado casos en los que un objeto de cierre
hace referencia a variables en el ámbito externo del cierre que no se
utilizan realmente en su cuerpo. Hemos presentado un informe de
error sobre esto, pero mientras tanto, hemos resuelto el problema
realizando un análisis estático de byte de clases de cierre.
código para detectar estas variables no utilizadas y establecer los
campos correspondientes en el objeto de cierre paranulo.omitimos
los detalles de este análisis por falta de espacio.
Variables compartidas:Los dos tipos de variables compartidas en
Spark, variables de difusión y acumuladores, se implementan
Mented usando clases con formatos de serialización personalizados.
Cuando uno crea una variable de difusiónbcon un valorv,
vse guarda en un archivo en un sistema de archivos compartido. La forma
serializada debes una ruta a este archivo. Cuandobse consulta el valor
en un nodo trabajador, Spark primero verifica sivestá en un caché
local y lo lee desde el sistema de archivos si no lo está. Inicialmente
usamos HDFS para transmitir variables, pero estamos desarrollando
un sistema de transmisión de transmisión más eficiente.
Los acumuladores se implementan utilizando un "truco de
serialización" diferente. Cada acumulador recibe una identificación
única cuando se crea. Cuando se guarda el acumulador, su forma
serializada contiene su ID y el valor "cero" para su tipo. En los
trabajadores, se crea una copia separada del acumulador para cada
subproceso que ejecuta una tarea utilizando variables locales del
subproceso y se restablece a cero cuando comienza una tarea.
Después de que se ejecuta cada tarea, el trabajador envía un mensaje
al programa controlador que contiene las actualizaciones que realizó
en varios acumuladores. El controlador aplica actualizaciones de cada
partición de cada operación solo una vez para evitar el doble conteo
cuando las tareas se vuelven a ejecutar debido a fallas.
Integración del intérprete:Por falta de espacio, solo
esbozamos cómo hemos integrado Spark en el intérprete de
Scala. El intérprete de Scala normalmente opera compilando
una clase para cada línea escrita por el usuario. Esta clase
incluye un objeto singleton que contiene las variables o
funciones en esa línea y ejecuta el código de la línea en su
constructor. Por ejemplo, si el usuario escribevar x = 5seguido
porimprimir(x),el intérprete define una clase (digamos
Línea 1)que contieneXy hace que la segunda línea se com-
apilar aprintln(Línea1.getInstance().x).Estos
las clases se cargan en la JVM para ejecutar cada línea. Para que
el intérprete funcione con Spark, hicimos dos cambios:
1. Hicimos que el intérprete envíe las clases que define a un sistema de
archivos compartido, desde el cual los trabajadores pueden cargarlas
utilizando un cargador de clases Java personalizado.
2. Cambiamos el código generado para que el objeto singleton de
cada línea haga referencia directamente a los objetos singleton
de las líneas anteriores, en lugar de pasar por el código estático.
obtener Instanciamétodos. Esto permite que los cierres capturen
el estado actual de los singletons a los que hacen referencia cada
vez que se serializan para enviarlos a un trabajador. Si no
hubiéramos hecho esto, entonces se actualiza a los objetos
singleton (por ejemplo, una configuración de líneax = 7en el
ejemplo anterior) no se propagaría a los trabajadores.
5 resultados
Aunque nuestra implementación de Spark aún se encuentra en una etapa
temprana, relacionamos los resultados de tres experimentos que muestran
su promesa como marco de computación en clúster.
Regresión logística:Comparamos el rendimiento de
el trabajo de regresión logística en la Sección 3.2 a una
implementación de regresión logística para Hadoop, utilizando un
conjunto de datos de 29 GB en 20 nodos EC2 "m1.xlarge" con 4
adoo
núcleos cada uno. Los resultados se muestran en la Figura 2.durazno
Con H
la iteración tarda 127 s, porque se ejecuta como un pendiente
independiente
trabajo de MapReduce. con chispa , el primera iteración n tomar es
(probablemente debido al uso de Scala ins té de Java), pero t sub consecuente
4000
Tiempo de ejecución (s)
3000
2000 Hadoop
1000 Chispa - chispear
0
1 5 10 20 30
Número de iteraciones
Figura 2: rendimiento de la regresión logística en Hadoop y Spark.
las iteraciones toman solo 6 segundos, cada una porque reutilizan los datos almacenados en
caché. Esto permite que el trabajo se ejecute hasta 10 veces más rápido.
También hemos intentado bloquear un nodo mientras se ejecutaba el
trabajo. En el caso de 10 iteraciones, esto ralentiza el trabajo en 50
segundos (21 %) en promedio. Las particiones de datos en el nodo perdido
se vuelven a calcular y se almacenan en caché en paralelo en otros nodos,
pero el tiempo de recuperación fue bastante alto en el experimento actual
porque usamos un tamaño de bloque HDFS alto (128 MB), por lo que solo
había 12 bloques por nodo y el proceso de recuperación no pudo utilizar
todos los núcleos del clúster. Los tamaños de bloque más pequeños
producirían tiempos de recuperación más rápidos.
Mínimos cuadrados alternos:Hemos implementado el trabajo de
mínimos cuadrados alternos en la Sección 3.3 para medir el beneficio
de las variables de difusión para trabajos iterativos que copian un
conjunto de datos compartido en múltiples nodos. Encontramos que
sin usar variables de transmisión, el tiempo para reenviar la matriz de
calificacionesRen cada iteración dominaba el tiempo de ejecución del
trabajo. Además, con una implementación ingenua de transmisión
(usando HDFS o NFS), el tiempo de transmisión creció linealmente con
la cantidad de nodos, lo que limita la escalabilidad del trabajo.
Implementamos un sistema de multidifusión a nivel de aplicación
para mitigar esto. Sin embargo, incluso con transmisión rápida,
reenviarRen cada iteración es costoso. almacenamiento en cachéR en
la memoria de los trabajadores que usan una variable de transmisión
mejoró el rendimiento en 2,8 veces en un experimento con 5000
películas y 15000 usuarios en un clúster EC2 de 30 nodos.
Chispa interactiva:Usamos el intérprete de Spark para cargar
un volcado de Wikipedia de 39 GB en la memoria en 15
máquinas EC2 “m1.xlarge” y consultarlo de forma interactiva. La
es
primera vez que los datos consultado, se tarda aproximadamente 35
onds, comparable t o rusegundos en ejecutar un trabajo de Hadoop. Cómo-
nunca, posterior qu eries tomar sólo 0,5 a 1 segundo, incluso
si escanean todo el d ata.Esto proporciona una diferencia
fer entexperiencia omp cualitativa al trabajo con datos locales.
6 Trabajo relacionado
di stribShar usado mi d Memoria:El resistente dis-
tributed n ser visto como una tracción para dis-
conjuntos de datos ca abdominales
tributed memoria compartida ory (DSM), que se ha estudiado s
174s extensión muy [20]. R DDdifieren de las interfaces DSM en
dosAy sí. Primero, R. DD Provide un mucho más restringido
5
modelo de programación, pero uno que permite que los conjuntos de
datos se reconstruyan de manera eficiente si fallan los nodos del clúster.
Mientras que algunos sistemas DSM logran tolerancia a fallas a través de
puntos de control [18], Spark reconstruye particiones perdidas de RDD
usando información de linaje capturada en los objetos RDD. Esto significa
que solo es necesario volver a calcular las particiones perdidas, y que se
pueden volver a calcular en paralelo en diferentes nodos, sin necesidad de
que el programa vuelva a un punto de control. Además, no hay gastos
generales si no falla ningún nodo. En segundo lugar, los RDD impulsan el
cálculo a los datos como en MapReduce [11], en lugar de permitir que los
nodos arbitrarios accedan a un espacio de direcciones global.
Otros sistemas también han restringido el modelo de
programación DSM para mejorar el rendimiento, la confiabilidad y la
programabilidad. Munin [8] permite a los programadores anotar
variables con el patrón de acceso que tendrán para elegir un
protocolo de consistencia óptimo para ellas. Linda [13] proporciona
un modelo de programación espacial de tuplas que puede
implementarse con tolerancia a fallas. Thor [19] proporciona una
interfaz para objetos compartidos persistentes.
Marcos de computación en clúster:Las operaciones paralelas de
Spark encajan en el modelo MapReduce [11]. Sin embargo,
operan en RDD que pueden persistiral otro lado deoperaciones.
Twister [6, 12], un marco de MapReduce que permite que las
tareas de mapas de larga duración mantengan datos estáticos en la
memoria entre trabajos, también reconoció la necesidad de ampliar
MapReduce para admitir trabajos iterativos. Sin embargo, Twister
actualmente no implementa tolerancia a fallas. La abstracción de
Spark de conjuntos de datos distribuidos resilientes es tolerante a
fallas y más general que MapReduce iterativo. Un programa Spark
puede definir múltiples RDD y alternar entre ejecutar operaciones en
ellos, mientras que un programa Twister tiene solo una función de
mapa y una función de reducción. Esto también hace que Spark sea
útil para el análisis de datos interactivo, donde un usuario puede
definir varios conjuntos de datos y luego consultarlos.
Las variables de transmisión de Spark brindan una función similar a la
caché distribuida de Hadoop [2], que puede distribuir un archivo a todos
los nodos que ejecutan un trabajo en particular. Sin embargo, las variables
de difusión se pueden reutilizaral otro lado deoperaciones paralelas.
Integración de idiomas:La integración del lenguaje de Spark es similar
a la de DryadLINQ [25], que utiliza el soporte de .NET para consultas
integradas del lenguaje para capturar un árbol de expresión que
define una consulta y ejecutarlo en un clúster. A diferencia de
DryadLINQ, Spark permite que los RDD persistan en la memoria en
operaciones paralelas. Además, Spark enriquece el modelo de
integración de idiomas al admitir variables compartidas (variables de
transmisión y acumuladores), implementadas mediante clases con
formularios serializados personalizados.
Nos inspiramos para usar Scala para la integración de lenguajes
por SMR [14], una interfaz de Scala para Hadoop que usa cierres para
definir mapas y reducir tareas. Nuestras contribuciones sobre SMR
son variables compartidas y una implementación más robusta de
serialización de cierre (descrito en la Sección 4).
Finalmente, IPython [22] es un intérprete de Python para la ciencia.
6
tists que permite a los usuarios iniciar cálculos en un clúster utilizando una
interfaz de cola de tareas tolerante a fallas o una interfaz de paso de
mensajes de bajo nivel. Spark proporciona una interfaz interactiva similar,
pero se enfoca en cálculos intensivos en datos.
Linaje:La captura de información de linaje o procedencia para conjuntos de
datos ha sido durante mucho tiempo un tema de investigación en los
campos de bases de datos y computación científica, para aplicaciones tales
como explicar resultados, permitir que otros los reproduzcan y volver a
calcular datos si se encuentra un error en un paso de flujo de trabajo o si
se pierde un conjunto de datos. Remitimos al lector a [7], [23] y [9] para
una revisión de este trabajo. Spark proporciona un modelo de
programación paralelo restringido donde el linaje detallado es económico
de capturar, de modo que esta información se puede usar para volver a
calcular los elementos perdidos del conjunto de datos.
7 Discusión y trabajo futuro
Spark proporciona tres abstracciones de datos simples para la
programación de clústeres: conjuntos de datos distribuidos resistentes
(RDD) y dos tipos restringidos de variables compartidas: variables de
transmisión y acumuladores. Si bien estas abstracciones son limitadas,
hemos descubierto que son lo suficientemente potentes como para
expresar varias aplicaciones que plantean desafíos para los marcos de
computación en clúster existentes, incluidos los cálculos iterativos e
interactivos. Además, creemos que la idea central detrás de los RDD, de un
identificador de conjunto de datos que tiene suficiente información para
(re)construir el conjunto de datos a partir de datos disponibles en un
almacenamiento confiable, puede resultar útil para desarrollar otras
abstracciones para programar clústeres.
En el trabajo futuro, planeamos centrarnos en cuatro áreas:
1. Caracterizar formalmente las propiedades de los RDD y
otras abstracciones de Spark, y su idoneidad para varias
clases de aplicaciones y cargas de trabajo.
2. Mejorar la abstracción de RDD para permitir a los programadores
intercambiar entre el costo de almacenamiento y el costo de reconstrucción.
3. Definir nuevas operaciones para transformar los RDD, incluida una
operación de "reproducción aleatoria" que reparte un RDD por
una clave determinada. Tal operación nos permitiría
implementar group-bys y joins.
4. Proporcione interfaces interactivas de nivel superior
además del intérprete de Spark, como SQL y R [4] shells.
8 Agradecimientos
Agradecemos a Ali Ghodsi por sus comentarios sobre este
documento. Esta investigación fue apoyada por California
MICRO, California Discovery, el Consejo de Investigación de
Ingeniería y Ciencias Naturales de Canadá, así como los
siguientes patrocinadores de Berkeley RAD Lab: Sun
Microsystems, Google, Microsoft, Amazon, Cisco, Cloudera, eBay,
Facebook, Fujitsu, HP, Intel, NetApp, SAP, VMware y Yahoo!.
Referencias
[1] Colmena Apache. http://hadoop.apache.org/hive.
 [2] Tutorial de Hadoop Map/Reduce. http://hadoop.apache.org/
common/docs/r0.20.0/mapred tutorial.html.
[3] Regresión logística – Wikipedia. http://
en.wikipedia.org/wiki/Regresión logística.
[4] El proyecto R para computación estadística.
http://www.r-project.org.
[5] Lenguaje de programación Scala. http://www.scala-lang.org.
[6] Twister: MapReduce iterativo.
http://iterativemapreduce.org.
[7] R. Bose y J. Frew. Recuperación de linaje para el procesamiento de datos
científicos: una encuesta.Encuestas informáticas de ACM, 37:1–28, 2005.
[8] JB Carter, JK Bennett y W. Zwaenepoel.
Implementación y ejecución de Munin. EnSOSP '91.
ACM, 1991.
[9] J. Cheney, L. Chiticariu y W.-C. Broncearse. Procedencia en bases de
datos: por qué, cómo y dónde.Fundamentos y Tendencias en Bases
de Datos, 1(4):379–474, 2009.
[10] CT Chu, SK Kim, YA Lin, Y. Yu, GR Bradski,
AY Ng y K. Olukotun. Map-reduce para aprendizaje automático en
multinúcleo. EnPINZAS '06, páginas 281–288. Prensa del MIT, 2006.
[11] J. Dean y S. Ghemawat. MapReduce: Procesamiento de datos
simplificado en grandes clústeres.común MCA, 51(1):107–
113, 2008.
[12] J. Ekanayake, S. Pallickara y G. Fox. MapReduce para análisis
científicos intensivos en datos. EnESCIENCIA '08, páginas 277–
284, Washington, DC, EE. UU., 2008. IEEE Computer Society.
Procesando. EnSIGMOD '08. ACM, 2008.
[22] F. Pérez y BE Granger. IPython: un sistema para
computación científica interactiva.computar ciencia Ing.,
9(3):21–29, mayo de 2007.
[23] YL Simmhan, B. Plale y D. Gannon. Una encuesta sobre la
procedencia de los datos en e-ciencia.Rec. SIGMOD.,
34(3):31–36, 2005.
[24] H.-c. Yang, A. Dasdan, R.-L. Hsiao y DS Parker. Map-reduce-
merge: procesamiento de datos relacionales simplificado en
grandes clústeres. EnSIGMOD '07, páginas 1029–1040. ACM,
2007.
[25] Y. Yu, M. Isard, D. Fetterly, M. Budiu, Ú. Erlingson,
PK Gunda y J. Currey. DryadLINQ: un sistema para computación
paralela de datos distribuidos de propósito general que utiliza un
lenguaje de alto nivel. EnOSDI '08, San Diego, CA, 2008.
[26] M. Zaharia, D. Borthakur, J. Sen Sarma, K. Elmeleegy,
S. Shenker y I. Stoica. Programación diferida: una técnica
simple para lograr localidad y equidad en la programación
de grupos. EnEuroSys 2010, abril de 2010.
[27] Y. Zhou, D. Wilkinson, R. Schreiber y R. Pan. Filtrado
colaborativo paralelo a gran escala para el premio Netflix.
EnAAIM'08, páginas 337–348, Berlín, Heidelberg, 2008.
Springer-Verlag.

[13] D. Gelernter. Comunicación generativa en linda.ACM

Trans. Programa. Idioma sist., 7(1):80–112, 1985.
[14] D. Pasillo. Un lenguaje escalable y un marco escalable.
http://www.scala-blogs.org/2008/09/scalable-
languageand-scalable.html.
[15] B. Hindman, A. Konwinski, M. Zaharia, A. Ghodsi, AD Joseph, RH
Katz, S. Shenker e I. Stoica. Mesos: una plataforma para
compartir recursos de granularidad fina en el centro de datos.
Informe técnico UCB/EECS-2010-87, Departamento de EECS,
Universidad de California, Berkeley, mayo de 2010.

[16] B. Hindman, A. Konwinski, M. Zaharia e I. Stoica. Un sustrato

común para la computación en clúster. EnTaller sobre Temas
Candentes en Computación en la Nube (HotCloud) 2009, 2009.
[17] M. Isard, M. Budiu, Y. Yu, A. Birrell y D. Fetterly. Dryad: Programas
paralelos de datos distribuidos a partir de bloques de construcción
secuenciales. EnEuroSys 2007, páginas 59–72, 2007.
[18] A.-M. Kermarrec, G. Cabillic, A. Gefflaut, C. Morin y
I. Puau. Una memoria compartida distribuida recuperable que integra
coherencia y capacidad de recuperación. EnFTCS '95. Sociedad de
Computación IEEE, 1995.
[19] B. Liskov, A. Adya, M. Castro, S. Ghemawat, R. Gruber,
U. Maheshwari, AC Myers, M. Day y L. Shrira. Uso compartido
seguro y eficiente de objetos persistentes en thor. En SIGMOD
'96, páginas 318–329. ACM, 1996.
[20] B. Nitzberg y V. Lo. Memoria compartida distribuida: una encuesta de
problemas y algoritmos.Computadora, 24(8):52-60, agosto de 1991.

[21] C. Olston, B. Reed, U. Srivastava, R. Kumar y

A. Tomkins. Pig latin: un idioma no tan extranjero para los datos