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

Transcripción

1 Título: Yo RDD (Resilient Distributed Datasets) con la Bujía (SPARK)!!! Autor: Dr. Gabriel Guerrero Ref: 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

2 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".

3 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).

4 Estas características de los procesos de Grandes Volúmenes NO SE OFRECIAN en los desarrollos de los años , 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 (" 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."

5 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

6 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")

7 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")

8 Hoy existe un gran número de instituciones que utilizan Mesos, entre las más famosas tenemos a Twitter y otras: 1) Conviva: ( 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. ( 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.

9 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.

10 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.

11 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.

12 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: 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.

13 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

14 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.

15 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: 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: