Título: Yo RDD (Resilient Distributed Datasets) con la Bujía (SPARK

Título: Yo RDD (Resilient Distributed Datasets) con la Bujía (SPARK)!!!
Autor: Dr. Gabriel Guerrero
Ref: www.saxsa.com.mx/articulos/RDD
Descripción: Una breve introducción al concepto de Conjuntos Distribuidos
Resilientes como una abstracción para ofrecer mecanismos tolerantes a fallas
(fault-tolerant abstraction) para el cómputo en memoria en una red (in-memory
cluster computing), basada en las enseñanzas y sistemas desarrollados en la
Universidad de California Berkeley en el laboratorio AMPLab (Algorithms Machines
and People).
Introducción
En los años 2000 al 2006 se acelera la generación de contenido en Internet y se
promueve ampliamente el uso de buscadores que ofrecen de forma casi
instantánea una respuesta.
Los grandes competidores de este mecanismo promueven la investigación,
innovación y desarrollo de nuevos paradigmas para:
1) la extracción de contenido en los diferentes sitios de Internet,
2) el almacenamiento del contenido en varias máquinas conectadas en red, o
"cluster", es decir el almacenamiento distribuido
3) el ordenamiento del contenido de forma óptima para la búsqueda, utilizando
mecanismos de llave,valor "key-value", con Arboles Binarios Balanceados (BTree)
4) el procesamiento en varias máquinas conectadas en red, "cluster", con
mecanismos distribuidos, es decir el cómputo distribuido
5) el estudio de mecanismos de utilización de los miles de millones de registros de
contenido heterogéneo. Es decir, la minería de datos y análisis predictivo.
Esto siguiendo los pasos clásicos de la investigación: Observar, Describir, Operar,
Predecir
Así surgen conceptos y sistemas como BerkeleyDB para la instrumentación de
Arboles Binarios Balanceados (BTree), Google File System (GFS) para el
almacenamiento distribuido, el marco de referencia Mapeo/Reducción
(Map/Reduce Framework) de Google, el sistema Apache Hadoop y muchos más
que hoy se denomina el ecosistema Hadoop.
Así a partir del 2006, el mecanismo de procesamiento distribuido MapReduce se
populariza como un mecanismo para simplificar enormemente el análisis en
grandes volúmenes de datos almacenados en máquinas conectadas en red
("BigData analysis on large clusters").
Así surge el nuevo "Paradigma del Manejo de Grandes Volúmenes de Datos"
("BigData Paradigm") y con ello el surgimiento de desarrolladores y compañías
que ofrecen "Soluciones maravillosas con Grandes Volúmenes de Datos que
resuelven CASI TODO LO INIMAGINABLE, gracias al nuevo paradigma".
Sin embargo, dada la gran ebullición del mundo de Grandes Volúmenes de Datos
y las promesas que casi todo lo podía hacer, los corporativos empezaron a
solicitar cada día más soluciones a problemas complejos.
Así se inicia una era de aplicaciones más complejas con varias etapas que
requieren algoritmos más elaborados enfocadas al USO y en particular al aspecto
PREDICTIVO con grandes volúmenes de datos.
Por ejemplo, algoritmos de Aprendizaje automatizado (Machine Learning, ML) con
varias etapas que requieren algoritmos iterativos. Es decir, que se realice un
cálculo y que éste sea el dato inicial de otro cálculo y así sucesivamente.
También se requieren aplicaciones que estudien las relaciones de datos, por
ejemplo en las aplicaciones que surgen de redes sociales como LinkedIn un sitio
web fundado en 2002, Twitter en 2006, Facebook en 2006 y otras.
En este contexto se cuenta con la Teoría de Grafos y los sistemas de
procesamiento de grafos (Graph processing) que requieren manejar miles de
millones de datos y relaciones entre estos.
Así mismo, las búsquedas iniciales se elaboran con más detalle y se necesitan
mecanismos de Elaboración de Solicitudes (Queries) más complejos e iterativos,
por lo que se requiere un lenguaje "SQL en los Grandes Volúmenes de Datos"
(BigData SQL).
Estas características de los procesos de Grandes Volúmenes NO SE OFRECIAN
en los desarrollos de los años 2006 - 2008, por lo que surgen grupos de
investigadores de universidades que enfocan desde otro punto de vista la
problemática BigData, alejados de los intereses de grandes grupos del BigData
comercial como Google, Yahoo, Twitter, IBM, SAS, SAP, Cloudera, y todas las
compañías que han surgido alrededor del BigData.
Así surgen en febrero 2011, en particular en la Universidad de California en
Berkeley un grupo de profesores y tesistas de doctorado que enfocan el problema
del Almacenamiento y Computo Distribuido de Grandes Volúmenes desde una
perspectiva diferente y se funda el Laboratorio AMPLab, ("Algorithms, Machines,
and People") que tiene como objetivo convertir los datos en información ("turning
data into information"). Entre los principales patrocinadores comerciales de inicio
en 2011, se cuenta con: Google, SAP, Amazon.com, EBAY, HUAWEI, IBM, Intel,
Microsoft, NetApp, NEC, VMware y Cloudera.
En su sitio ("https://amplab.cs.berkeley.edu/about/") podemos leer:
"For years, research in fields such as machine learning (ML), data mining,
databases, information retrieval, natural language processing, and speech
recognition have steadily improved their techniques for revealing the information
lying within otherwise opaque datasets."
Durante varios años, la investigación en campos como el Aprendizaje Automático
(ML), minería de datos, bases de datos, recuperación de información,
procesamiento del lenguaje natural y reconocimiento de voz han mejorado
constantemente sus técnicas para revelar la información que se encuentra
inmersa en los conjuntos de datos, que de otra manera permanecería opaca.
En el AMPLab se dan cita ciencias de la computación y dominios de aplicaciones
con gran volúmenes de datos para abordar el problema del estudio analítico de
Grandes Volúmenes de Datos ("Big Data analytics").
Sin embargo, tiempo atrás en ámbito de tesis doctorales ya se tenía un gran
avance y así desde 2009 se tienen contribuciones por ejemplo en el aspecto de
Administración de Recursos Compartidos de una red de computadoras o "cluster"
y un sistema operativo que los administre, que se denomina MESOS.
Por lo que en 2009 nace el proyecto de investigación SPARK en la Universidad
de California en Berkeley, y que se declara como código abierto en 2010 y en junio
de 2013 se integra como un proyecto de la organización Apache
Algunos datos de MESOS
Leemos en su página
"Mesos is a cluster management platform that manages distributed hardware
resources into a single pool of resources that can be used by application
frameworks to efficiently manage workload distribution for both batch jobs and
long-running services"
Mesos es una plataforma de gestión de clúster que gestiona distribuye los
recursos de hardware en un único conjunto (pool) de recursos que pueden ser
utilizados por los entornos de aplicaciones(frameworks) para gestionar de manera
eficiente la distribución de la carga de trabajo tanto para los trabajos por lotes y
como para los servicios de larga duración.
Mesos permite el desarrollo y ejecución de sistema distribuidos con administración
eficiente de recursos ("Develop and run resource-efficient distributed systems").
Características (Features)
1) Permite tener un nodo Maestro (master) duplicado con tolerancia a fallos
utilizando ZooKeeper
("Fault-tolerant replicated master using ZooKeeper")
2) Escalabilidad a más de 10,000 nodos
("Scalability to 10,000s of nodes")
3) Aislamiento entre tareas con utilizando el mecanismo Linux Containers
("Isolation between tasks with Linux Containers")
4) Planificación de multi-recursos, teniendo en cuenta la memoria y el CPU
("Multi-resource scheduling, memory and CPU aware")
5) Interfaces de programación (APIs) en Java, Python y C ++ para el desarrollo de
nuevas aplicaciones paralelas
("Java, Python and C++ APIs for developing new parallel applications")
6) Interfaz de Usuario basada en Web, que permite monitorear el estado del
clúster
("Web UI for viewing cluster state")
Hoy existe un gran número de instituciones que utilizan Mesos, entre las más
famosas tenemos a Twitter y otras:
1) Conviva: (http://www.conviva.com) Conviva’s real-time big data processing
platform enables the delivery of a TV-quality experience over the Internet. Any
network. Any device. Any time.
2) eBay. (http://www.ebay.com) ebay es un sitio destinado a la subasta de
productos a través de Internet.
3) Netflix. Netflix, Inc. es una empresa comercial americana de entretenimiento
que proporciona mediante tarifa plana mensual streaming (flujo) multimedia
(principalmente, películas y series de televisión) bajo demanda por Internet y de
DVD-por-correo, donde los DVD se envían mediante Permit Reply Mail.
4) PayPal. PayPal es una empresa estadounidense cofundada por entre otros
Peter Thiel y Elon Musk, independiente y perteneciente al sector del comercio
electrónico por Internet que permite la transferencia de dinero entre usuarios que
tengan correo electrónico, una alternativa al tradicional método en papel como los
cheques o giros postales. PayPal también procesa peticiones de pago en
comercio electrónico y otros servicios web, por los que cobra un porcentaje al
vendedor. La mayor parte de su clientela proviene del sitio de subastas en línea
eBay.
5) Vimeo. Vimeo es una red social de Internet basada en videos, lanzada en
noviembre de 2004 por la compañía InterActiveCorp (IAC). El sitio permite
compartir y almacenar videos digitales para que los usuarios comenten en la
página de cada uno de ellos. Los usuarios deben estar registrados para subir
videos, crear su perfil, cargar avatares, comentar y armar listas de favoritos.
En los sistemas de administración de Grandes Volúmenes (BigData) tenemos
entre otros:
1) Cassandra es una base de datos distribuida de alta disponibilidad y desempeño
con tolerancia a fallos.
2) Hypertable un sistema de distribuido de almacenamiento y procesamiento de
datos estructurados y no estructurados de alto rendimiento y escalable
Es un sistema de código abierto basado en el sistema propietario de Google
BigTable.
El modelo de datos RDD y su instrumentación en un ambiente MESOS
Desde el surgimiento del marco de referencia MapReduce se tiene un conjunto de
aplicaciones de Grandes Volúmenes de Datos que requieren compartir datos en
varias iteraciones entre cada una de éstas. En este modelo, la única forma es
crear un archivo en disco. Este mecanismo no permite la construcción sencilla ni
eficiente de algoritmos iterativos.
En MapReduce, la única forma de compartir datos entre trabajos es el uso de
memoria estable por lo que esto es muy lento.
En este contexto y dado que hoy la memoria RAM (In-memory) es más accesible y
se tienen equipos con gran capacidad de memoria RAM, se analiza utilizar la
memoria RAM como un mecanismo para compartir datos.
La RAM es de 10 a 100 veces más rápida que la red o el disco duro. Sin embargo,
los conceptos de datos en Hadoop Distributed File Systems (HDFS) no la utilizan
por lo que una área de innovación es la utilización de la memoria RAM para la
construcción de sistemas distribuidos tolerantes a fallas que sean muy eficientes.
Este es un reto donde se tienen experiencias pasadas como RAMCloud, Piccolo y
otros modelos basados en actualización a nivel del registro (fine-grained). Estos
modelos para lograr la tolerancia a fallas utilizan la técnica de replicación de datos
en disco.
Reto: ¿Cómo diseñar un concepto de memoria RAM distribuida que sea
tolerante a fallas?
Se define un concepto denominado Conjuntos Resilientes de Datos Distribuidos,
(en inglés Resilient Distributed Datasets, RDD), que tiene limitaciones como:
1) NO PUEDE CAMBIARSE, es decir es inmutables
2) Es una colección particionada de registros
3) Solo se puede construir con transformaciones predefinidas que actúan sobre
TODO el conjunto (coarse-grained), como un mapeo (map), un filtrado (filter) una
unión (join), y otras transformaciones predefinidas dentro del modelo.
4) NO EXISTE replicación para ofrecer la tolerancia a fallas, sino se define un
mecanismo de LINAJE (lineage) en donde se genera una bitácora (log) de las
transformaciones que permitieron su creación. Se almacena el grafo de las
transformaciones que se utilizaron para construir la partición del RDD que se
perdió. Si fallara una partición del conjunto, entonces se re-ejecuta el cómputo
cuando sea necesario para regenerar la partición perdida.
Este es un modelo de almacenamiento distribuido con tolerancia a fallas que es
general y que permite expresar otros modelos actualmente en uso de algoritmos
paralelos.
Por ejemplo, es posible unificar con el modelo RDD, los conceptos de BigData
como los modelos de flujo de datos (Data flow models) MapReduce, Dryad,
Pregel de Google, y otros más.
El sistema SPARK
Para instrumentar el concepto de RDD, se genera un sistema denominado SPARK
que tiene varias capas y en particular una biblioteca de programación API, con la
filosofía del DryadLINQ con el lenguaje de programación SCALA.
Recordemos que DryadLINQ es un ambiente de programación propuesto por
Microsoft (ref: http://research.microsoft.com/en-us/projects/dryadlinq) para escribir
aplicaciones en paralelo con datos de gran volumen que se ejecutan en una red
de PC. ("large-scale data parallel applications running on large PC clusters"). El
ambiente consta de un motor de ejecución distribuida llamado Dryad ("distributed
execution engine") y el lenguaje de solicitudes integrado (LINQ) ("Language
Integrated Query").
El proyecto Dryad fue abandonado por Microsoft en 2011, para enfocar su
estrategia de BigData en el proyecto Apache Hadoop.
Una aplicación en el ambiente Dryad se modela como un grafo acíclico dirigido
("directed acyclic graph DAG"). El grafo DAG define el flujo de datos de la
aplicación ("dataflow of the application"), en donde los vértices del grafo definen
las operaciones que se llevan a cabo en los datos.
En SPARK se tiene un intérprete interactivo construido en base al intérprete de
SCALA.
Para realizar la operación o uso de un RDD se tienen dos conceptos:
1) el concepto de transformación que construye un nuevo RDD ("build new
RDDs")
2) el concepto de acción en donde a partir de un RDD se realizan cálculos y se
ofrecen resultados ("compute and output results")
Un concepto fundamental en SPARK es el particionamiento de un RDD ("RDD's
partitioning"), es decir el control de cómo se particiona a lo largo de los nodos
("layout across nodes")
Otro concepto estratégico es su persistencia ("persistence"), es decir en donde
se almacena si en la RAM, o en el disco, o en otro lado.
Otros modelos de cómputo distribuido que pueden instrumentarse con SPARK
Por medio del concepto RDD es posible expresar modelos como
1) MapReduce, DryadLINQ. Para el procesamiento distribuido en HDFS
2) PREGEL. Para el procesamiento de grafos, el modelo de Google PREGEL
3) Iterative MapReduce. En el procesamiento iterativo Iterative MapReduce
4) Hive SQL. Para la instrumentación de un lenguaje SQL en BigData
La gran ventaja de SPARK, es que estos modelos de cómputo distribuido de
unifican y es posible MEZCLARLOS eficientemente para compartir los datos entre
todos éstos de forma transparente.
El trabajo de SPARK está inspirado en técnicas como:
1) RAMCloud, Piccolo, GraphLab, parallel DBs. Inconvenientes: Requieren
escrituras al registro ("fine-grained"), por lo que se necesita la replicación de datos
2) Pregel, iterative MapReduce. Inconvenientes: Son modelos especializados que
no facilitan la ejecución de queries arbitrarios o particulares
3) DryadLINQ, FlumeJava. Inconvenientes: Es un API que no permite compartir
conjuntos de datos de forma eficiente entre varios queries iterativos
4) Nectar. Manejo automático de Datos y Computo en Centros de Datos
("Automatic Management of Data and Computation in Datacenters").
Inconvenientes: Se ofrece el cache de expresiones, pero solo en un sistema de
archivos distribuido y no en HDFS.
En Nectar, los datos y su cómputo se tratan de manera indistinta. Los conjuntos de
datos construidos por cómputos, se identifica de forma inequívoca por los
programas que los generan. Estos conjuntos pueden regenerarse fácilmente a
partir de los programas que los identifican.
(ref: www.usenix.org/events/osdi10/tech/full_papers/Gunda.pdf)
5) PACMan. Parallel All-or-nothing Cache MANager, un sistema de cache en RAM
para trabajos en paralelo ("an in-memory caching system for parallel jobs")
desarrollado en AMPLab en la Universidad de Berkeley con la participación de Ion
Stoica. Inconvenientes: Se tiene un manejo de memoria cache en HDFS, pero se
escribe a disco duro
(ref: https://www.usenix.org/conference/nsdi12/technicalsessions/presentation/ananthanarayanan)