Big Data: Hadoop y Spark ¿Competencia o complemento?

Hadoop y Spark

Se trata de dos diseños tecnológicos que, aunque parecen alternativos, en realidad fueron diseñados con la idea de operar en un mismo contexto. Según lo plantea Ken Hess en una columna de Datamation, una comparación entre Hadoop y Spark es algo difícil porque los dos realizan muchas cosas similares aunque tienen algunas zonas en las que sus funcionalidades no se superponen.

Para comenzar, Hess resalta el hecho de que Spark no tiene su propia administración de archivos y por eso debe apoyarse en el HDFS (Hadoop´s Distributed File System) o alguna otra solución sustitutiva. Lo más indicado sería comparar a Hadoop Map Reduce con Spark, ya que son más comparables en su carácter de motores de procesamiento de datos.

Hess prosigue diciendo que a medida que la ciencia de datos ha ido madurando en los últimos años, lo mismo ha ocurrido con la necesidad de contar con nuevas formas para el manejo de los datos en “big” escala. Existen aplicaciones comerciales en las que Hadoop supera a la performance del recién llegado Spark, pero a su vez, Spark tiene su propio lugar en el espacio de big data debido a su velocidad y facilidad de uso. El análisis que realiza Hess examina los conjuntos de atributos que les son comunes a cada plataforma, incluyendo performance, tolerancia a fallos, costo, facilidad de uso, procesamiento de datos, compatibilidad y seguridad.

Hess nos dice que los más importante a tener en cuenta en relación a Hadoop y Spark es que su utilización no depende de un escenario de uno-u-otro ya que no son mutuamente excluyentes. Ninguno de los dos es un reemplazo total del otro. Los dos son compatibles entre sí y eso hace que, si se los aparea, se esté frente a una solución extremadamente poderosa en una variedad de aplicaciones big data.

Antes de proseguir con su análisis, Hess considera importante que repasemos la definición de uno y otro diseño, el de Hadoop y el de Spark.

Hadoop

Hadoop es un projecto de Apache.org y se trata de una librería de software y un marco (framework) de acción que permite el procesamiento distribuido de grandes conjuntos de datos, conocidos como big data, a través de millares de sistemas convencionales que ofrecen potencia de procesamiento y espacio de almacenamiento. Hadoop es, en esencia, el diseño más poderoso en el espacio de los analíticos big data.

En la creación de su framework participan varios módulos y entre los principales encontramos a los siguientes:

Hadoop Common (Utilidades y librerías que dan soporte a otros módulos Hadoop)

Hadoop Distributed File Systems (HDFS)

Hadoop YARN (Yet Another Resource Negociator), tecnolkogía de administración de clústeres.

Hadoop Mapreduce (modelo de programación que soporta la computación paralela masiva)

 

Si bien los cuatro módulos arriba citados componen el núcleo central de Hadoop, existen otros más. Entre ellos, tal como lo cita Hess, están Ambari, Avro, Cassandra, Hive, Pig, Oozie, Flume y Sqoop. Todos ellos sirven para ampliar y extender la potencia de Hadoop e incluirse en aplicaciones big data y procesamientos de grandes conjuntos de datos.

Muchas compañías utilizan Hadoop para sus grandes conjuntos de datos y analíticos. Se ha convertido en el estándar de facto en las aplicaciones big data. Hess destaca que Hadoop fue originalmente diseñado para manejar funciones de crawling (exploración de sitios Web) y realizar la búsqueda de millones de páginas Web mientras recolectaba información en una base de datos. El resultado de ese deseo de explorar y buscar en la Web terminó siendo Hadoop HDFS y su motor de procesamiento distribuido, MapReduce.

Según Hess, Hadoop resulta útil para las empresas cuando los conjuntos de datos son tan grandes y tan complejos que las soluciones con las que ya cuentan no pueden procesar la información en forma efectiva y en lo que las necesidades del negocio definen como tiempos razonables.

MapReduce es una excelente motor de procesamiento de textos y eso se debe a que tanto el crawling como la búsqueda en la Web, sus primeros desafíos, son tareas basadas en texto.

 

Definición de Spark

Apache Spark es un framework open source de computación que originalmente fue diseñado por la Universidad de California, en Berkeley. Hess nos explica que sus desarrolladores lo presentan como “un motor general y rápido para el procesamiento de datos en gran escala.” Si bien los expertos y a veces críticos de Spark admiten que su procesamiento in-memory es muy rápido (Hasta 100 veces más que Hadoop MapReduce), no están muy dispuestos a reconocer que Spark puede ser hasta diez veces más rápido que MapReduce cuando trabaja en discos duros. Spark también puede realizar procesamiento batch pero sin embargo, su performance se luce cuando se trata de cargas tipo streaming, consultas interactivas y lo que denominamos aprendizaje basado en máquinas.

Para Hess, la gran consigna de Spark es la de su capacidad de procesamiento de datos en tiempo real, lo que compara con el desempeño de MapReduce basado en discos como motor de procesamiento batch (en lotes). Spark es compatible con Hadoop y sus módulos. De hecho, en la página del proyecto Hadoop, Spark figura como uno de los módulos.

Hess nos explica que Spark tiene su propia página debido a qué, si bien puede funcionar en los clústeres Hadoop mediante YARN (Yet Another Resource Negociator), también cuenta con un modo standalone (de funcionamiento autónomo). El hecho de que pueda funcionar como módulo de Hadoop y como solución standalone hace que sea algo engañoso comparar ambos diseños y contrastarlos. Sin embargo, recuerda Hess, a medida que el tiempo pasa, algunos científicos de datos esperan que Spark comience a divergir de Hadoop y tal vez llegue a reemplazarlo. Y eso será especialmente en aquellos casos en los que sea necesario y crítico tener un acceso más veloz a los datos procesados.

Spark es un framework de computación en cluster. Esto equivale a decir que compite más bien con MapReduce que con todo el ecosistema Hadoop. Por ejemplo, Spark no tiene su propio sistema de archivos distribuidos, pero puede usar HDFS.

Spark utiliza memoria y puede usar también discos para el procesamiento de datos, mientras que MapReduce es por el momento una tecnología basada estrictamente en discos, nos explica Hess. La principal diferencia entre MapReduce y Spark consite, en que MapReduce utiliza almacenamiento persistente y Spark utiliza RDDs (Resilient Distributed Datasets), algo relacionado con tolerancia a fallos y que Hess contempla más adelante.

 

Performance

En la red se encontrará gran cantidad de información respecto a cómo compara Spark con MapReduce en términos de velocidad. El problema con esta comparación, según Hess, es que ambos realizan el procesamiento de datos en forma diferente y lo veremos más adelante bajo el título “Procesamiento de Datos.” La razón por la que Spark es tan veloz está en que procesa todo en memoria. También puede utilizar discos cuando todos los datos no caben en la memoria.

El procesamiento in-memory de Spark permite contar con analíticos en tiempo casi real. Esto es útil para campañas de marketing, aprendizaje de máquinas, sensores de IoT (Internet of Things), monitoreo de actividad de logs, analíticos de seguridad y sitios de medios sociales. MapReduce, por su parte, utiliza procesamiento batch (en lotes) y no fue, según Hess, creado para tener una velocidad deslumbrante. Fue originalmente establecido para recoger información de sitios Web en forma continua y no existía la necesidad de tener esos datos en tiempo real o casi real.

 

Facilidad de Uso

Spark ha ganado reconocimiento por su velocidad y también es algo conocida su facilidad de uso gracias a su API (Application Programming Interface) amigable para SCALA, su lenguaje nativo y también para Java, Python y Spark SQL. Spark SQL es muy parecido a SQL 92, de modo que prácticamente no existe una curva de aprendizaje para utilizarlo.

Spark también tiene un modo interactivo con el que tanto desarrolladores como usuarios por igual pueden tener respuestas inmediatas para consultas u otras acciones. Hess prosigue explicando que MapReduce no tiene modo interactivo, aunque con algunos add-ons como Pig o Hive, se logra que MapReduce sea un poco más sencillo para ser usado.

 

Costos

Hess nos recuerda que ambos productos son proyectos de Apache.org. Esto significa que son productos open source de software libre. Si bien no existe costo por el software, existen costos asociados a la utilización de cualquiera de las dos plataformas en términos de personal y hardware. Los dos productos han sido diseñados para funcionar en hardware estándar o commodity, tal como lo son los sistemas llamados de caja blanca (compatibles) o servidores de bajo costo.

MapReduce y Spark corren sobre el mismo tipo de hardware, por lo que las diferencias de costos entre las dos soluciones tiene que ver con el funcionamiento de cada uno. Hess nos dice que MapReduce utiliza cantidades de memoria habituales en los servidores porque trabaja en discos. Una compañía tendrá que comprar muchos y más veloces discos para utilizar MapReduce. MapReduce también requiere mayor cantidad de sistemas para poder distribuir la actividad de Input/Output de disco en múltiples sistemas.

Por su parte, prosigue Hess, Spark requiere enormes cantidades de memoria pero puede funcionar con espacios de disco considerados estándar en términos de capacidad y velocidad. Algunos usuarios, según Hess, se han quejado de la sobrecarga que representa la limpieza de los archivos temporarios. Estos archivos temporarios generalmente se guardan por siete días con el objeto de acelerar el eventual procesamiento con conjuntos de datos ya utilizados. El espacio de disco es de menor costo y como Spark no utiliza el Input/Output de disco para procesar, el espacio de disco utilizado puede ser bien aprovechado tanto en esquemas SAN (Storage Area Networks) como NAS (Network Attached Storage).

Lo cierto es que los sistemas para Spark cuestan más porque necesitan grandes cantidades de memoria RAM. Pero también es cierto que la tecnología de Spark reduce la cantidad de sistemas para funcionar. Por eso, se termina teniendo una menor cantidad de sistemas que cuestan más. Posiblemente haya un punto de inflexión el que Spark reduzca los costos por unidad de computación aun con la memoria RAM adicional que requiere.

Hess nos ilustra con una cita: “Spark ha sido preparado para trabajar bien con petabytes de datos. Ha sido usado para clasificar 100 TB de datos en forma 3 veces más veloz que MapReduce en una décima parte de la cantidad de máquinas requeridas. Este hecho permitió que Spark ganar la edición de 2014 Daytona GraySort Benchmark.

 

Compatibilidad

MapReduce y Spark son ambos compatibles entre sí y Spark comparte todas las compatibilidades de MapReduce para fuentes de datos, formatos de archivos y herramientas de BI (Business Intelligence) vía JDBC (Java Database Connectivity) y ODBC (Open Database Connectivity).

 

Procesamiento de Datos

Tal como lo explicó Hess, MapReduce es un motor de procesamiento batch. Opera en etapas secuenciales leyendo los datos del cluster, realizando sus operaciones en los datos y escribiendo los datos nuevamente en el cluster; leyendo los datos actualizados en el cluster, realizando la siguiente operación de datos, grabando esos resultados nuevamente en el cluster y así sucesivamente. Spark realiza similares operaciones pero lo hace en un mismo paso y trabajando en memoria. Lee los datos del cluster, hace las operaciones con los datos y luego graba los resultados en el mismo.

Spark también incluye su propia librería de computación Graph: GraphX. GraphX permite que los usuarios puedan ver los mismos datos como graphs y como colecciones. También pueden transformar y unir graphs con Resilient Distributed Datasets (RDDs), que se verán en bajo el título Tolerancia a Fallos.

 

Tolerancia a Fallos

Hess explica que MapReduce y Spark resuelven la tolerancia ante fallos de dos formas diferentes. MapReduce utiliza TaskTrackers que le suministran “latidos” al módulo JobTracker. Si un latido se pierde, el JobTracker reprograma todas las operaciones pendientes y en ejecución para otro TaskTracker. Este método es efectivo para lograr tolerancia ante fallas pero puede incrementar notablemente los tiempos de ejecución de operaciones que han sufrido aunque sea una falla.

Por su parte, nos dice Hess, Spark utiliza RDDs que son colecciones de elementos con tolerancia a fallos y que pueden ser operados en paralelo. Los RDDs pueden referenciar a un conjunto de datos en un sistema externo de almacenamiento, tal como un file system compartido, HDFS, HBase o cualquier otra fuente de datos que tenga el InputFormat de Hadoop. Spark puede crear RDDs desde cualquier fuente de almacenamiento soportada por Hadoop, incluyendo file systems locales u otros de los antes mencionados.

Un RDD cuenta con las siguientes propiedades:

Una lista de particiones

Una función de computar cada Split

Una lista de dependencias con otros RDDs

Opcionalmente, un Particionardor para los RDDs con valor de clave.

Oprcionalmente, una lista de ubicaciones preferenciales para computar cada Split (por ejemplo, en un block de archivo HDFS)

Los RDDs puede ser persistentes y guardar un conjunto de datos en cache durante las operaciones. Esto permite que las futuras acciones sean mucho más fáciles. El caché de Spark es tolerante a fallos en cuanto si alguna partición o RDD se pierde, automáticamente será reprocesada utilizando las transformaciones originales.

Para ampliar estos conceptos, recomendamos visitar Apache.org y repasar los términos ya que la traducción literal (más la falta de experiencia en el tema) puede ser confusa en este artículo.

 

Escalabilidad

Hess señala que tanto MapReduce como Spark son escalables utilizando HDFS. La pregunta es qué tan grande puede llegar a ser un cluster Hadoop, por ejemplo. Tenemos el caso de Yahoo, que tiene un cluster Hadoop de 42.000 nodos, por lo que no se puede decir que exista un límite para MapReduce. Por el lado de Spark, el cluster más grande conocido es de 8.000 nodos, pero a medida que big data crece, es de esperar que esos tamaños de cluster sigan creciendo para mantener las expectativas de performance.

 

Seguridad

Hadoop soporta autenticación Kerberos, que es algo difícil de administrar. Sin embargo, existen algunos proveedores que han facilitado el aprovechamiento de Active Directory Kerberos y LDAP para autenticación. Esos mismos proveedores ofrecen encriptado de datos para datos en reposo y en movimiento.

Hadoop Distributed File System soporta ACL (Access Control Lists) y el modelo tradicional de permisos de acceso a archivos. Para el control de usuarios y lanzamiento de procesos, Hadoop cuenta con Service Level Authorization, que asegura que los clientes tengan los permisos correctos.

En cambio, prosigue diciendo Hess, la seguridad de Spark es un poco más escasa en términos de recursos. Actualmente sólo soporta autenticación vía paswords. Si se corre Spark sobre HDFS, se pueden usar los permisos HDFS ACL y a nivel de archivo. Además, Spark puede utilizar a YARN para alcanzar la capacidad de utilizar autenticación Kerberos.

 

Resumen

Finalmente, Hess concluye en que, en panorámica, Spark debería ser la elección por defecto para cualquier aplicación big data. Sin embargo, ese no es el caso. MapReduce ha logrado afianzarse en el mercado de big data para empresa que necesitan manejar grandes conjuntos de datos y tenerlos bajo control en sistemas estándar. La velocidad de Spark, su agilidad y relativa facilidad de uso son complementos excelentes para el bajo costo de operación de MapReduce.

Para Hess, la verdad es que MapReduce y Spark tienen relaciones simbióticas. Hadoop ofrece elementos que Spark no tienen, tal como sistemas de archivos distribuidos y Spark ofrece procesamiento in-memory en tiempo real para aquellos conjuntos de datos que así lo requieran. El escenario perfecto de big data es el que sus diseñadores pensaron, el de Hadoop y Spark trabajando juntos en un mismo equipo.