Spark nace en la Universidad de California-Berkeley como el núcleo del proyecto de investigación doctoral de Matei Zaharia dirigido por Ion Stoica. Como se explica en este artículo divulgado en 2010, el objetivo con el que se diseña Spark es proporcionar una mejor alternativa para el procesamiento de datos masivos ante determinados casos de uso en los que MapReduce no se mostraba del todo eficiente. La alternativa se apoya en el uso de memoria principal en vez de almacenamiento en disco (gracias al abaratamiento de la memoria y por tanto a su disponibilidad en grandes cantidades en los clústers de máquinas utilizados para procesar Big Data). Disponer de memoria donde almacenar datos masivos evita el problema de lentitud que surge al tener que leer y escribir grandes cantidades de datos en disco.
Los casos de uso en los que este problema se hace especialmente patente (y que Spark busca solucionar de manera más eficiente gracias a un mayor uso de la memoria) son principalmente dos:
Para implementar este esquema, Spark maneja una abstracción de los datos llamada Resilient Distributed Datasets (RDD), colecciones de datos que están segmentados y repartidos a lo largo de un clúster de máquinas y que podrán estar almacenados tanto en disco como en memoria. Así, las tareas de procesamiento de datos masivos que se programan sobre Apache Spark se construyen como una combinación de operaciones sobre estos RDD. Spark dispone de un amplio conjunto de dichas operaciones que se dividen en transformaciones y acciones, con la característica clave (que recuerda a la manera en que también lo resuelve Apache Pig) de que las transformaciones (map, filter, distinct, …) construyen una cadena de procesamientos en los datos que no son efectivamente ejecutados hasta que se lanza una acción (reduce, take, collect, …) que consolida el resultado de las transformaciones anteriores.
Los casos de uso en los que este problema se hace especialmente patente (y que Spark busca solucionar de manera más eficiente gracias a un mayor uso de la memoria) son principalmente dos:
- Procesos iterativos, que deben ir procesando repetidamente los datos en sucesivas iteraciones. Una aproximación basada en MapReduce requeriría almacenar los datos en disco tras cada iteración y volver a leerlos en la siguiente. Con el uso de memoria para ese almacenamiento entre iteraciones el proceso completo se acelera enormemente.
- Procesos intensivos en consultas, donde hay muchas interacciones para obtener datos, lo que en un escenario con MapReduce requeriría volver a leer los datos de disco cada vez que se lanza la consulta. Si los datos una vez procesados se dejan disponibles en memoria, las consultas que accedan a ellos podrán resolverse más rápido.
Para implementar este esquema, Spark maneja una abstracción de los datos llamada Resilient Distributed Datasets (RDD), colecciones de datos que están segmentados y repartidos a lo largo de un clúster de máquinas y que podrán estar almacenados tanto en disco como en memoria. Así, las tareas de procesamiento de datos masivos que se programan sobre Apache Spark se construyen como una combinación de operaciones sobre estos RDD. Spark dispone de un amplio conjunto de dichas operaciones que se dividen en transformaciones y acciones, con la característica clave (que recuerda a la manera en que también lo resuelve Apache Pig) de que las transformaciones (map, filter, distinct, …) construyen una cadena de procesamientos en los datos que no son efectivamente ejecutados hasta que se lanza una acción (reduce, take, collect, …) que consolida el resultado de las transformaciones anteriores.
Excelente blog, muchas gracias
ResponderEliminar¡Gracias a ti, Eric! Me alegro de que te resulte de interés.
Eliminar