Parquet.
Apache Parquet es un formato para Hadoop de tipo columnar de código abierto que está optimizado para trabajar con datos complejos y estructurados dando buen tiempo de respuesta. Incluye mecanismos para optimizar el espacio de disco usando compresión y codificación de tipos. Este formato, al ser orientado a columnas, usa menos almacenamiento y tiene mayor rendimiento en las consultas. A diferencia de otros formatos columnares que necesitan aplanar las estructuras complejas para poder guardarlas, Parquet las guarda sin aplanar.
En este sentido, vale destacar que el formato Parquet está constituido por una cabecera, contendiente de 4 bytes y un identificador “PAR” que indica el formato del archivo parquet; un grupo de filas que consisten en una división horizontal lógica de los datos en filas, por tanto, un grupo de filas consiste en un bloque de columna para cada conjunto de datos; trozo columna, la cual contempla un bloque de datos para una columna particular; página en la que los bloques de columnas se dividen en páginas; y por último el pie de página que contiene los metadatos que incluye formato del archivo, esquema, par de clave / valor y la localización de todas las columnas y ubicaciones de inicio de los metadatos de la columna. A continuación, se muestra la estructura descrita, en la que se devela un ejemplo donde hay N columnas divididas en M grupos de fila:
Figura 1 Formato de los archivos Parquet.
En las figuras 1 y 2, se puede evidenciar que los metadatos contienen las ubicaciones de comienzo de los metadatos de las columnas. Estos metadatos se graban en archivos Thrift y se escriben después de los datos para permitir la escritura en una sola pasada. Se espera que quien los lea, revise primero los metadatos para encontrar todos los trozos de las columnas de interés. Estos trozos son leídos de manera secuencial.
ORC.
Apache ORC es un formato de archivo diseñado para cargar trabajos en Hadoop y almacenar colecciones de filas en un archivo. Las filas se graban en formato columnar, lo que permite que sean procesadas de forma paralela a través del clúster. Cada archivo se comprime, optimizando espacio.
A continuación, se muestra la estructura de ORC:
La metadata de ORC es grabada usando el protocolo de protocol buffers que proporciona la capacidad de agregar nuevos campos sin generar problemas de consistencia para los lectores. La lectura del archivo ORC se lee desde atrás: en lugar de hacer muchas lecturas cortas, se leen los primeros 16k bytes del archivo tratando de leer las secciones de pie de página. El último byte del archivo contiene la longitud serializada del PostScript que debe ser menor a 256 bytes.
Una vez conocida la longitud comprimida, el pie de página puede descomprimir y analizar. La estructura del formato tiene las siguientes divisiones: PostScript, la cual proporciona la información necesaria para interpretar el resto del archivo que incluye la longitud de las secciones de pie de página y metadato del archivo, versión del mismo, tipo de compresión (por ejemplo, zlib, snappy). PostScript no se comprime y termina un byte antes del final del archivo.
Asimismo, cuenta con un pie de página el cual contiene la estructura del cuerpo del archivo en función al tipo de esquema, número de filas y estadísticas sobre cada una de las columnas. Además, posee información de la franja, dividiéndose en tres secciones a saber: conjunto de índices para las filas dentro de la franja, los datos y el pie de página de la franja.
Todas las filas de ORC deben tener el mismo esquema. El esquema se presenta como un árbol, donde los tipos compuestos tienen subcolumnas, tal como se muestra a continuación:
Figura 4 Árbol ORC.
AVRO
AVRO es un formato JSON para definir los tipos de datos, protocolos, además serializa y compacta datos en formato binario. Este formato se basa en esquemas: al leerse un archivo, se usa el esquema para obtener el dato y se graba el mismo permitiendo que los datos puedan ser procesados más tarde por cualquier programa que soporte librerías JSON, ya que los esquemas están definidos en esa especificación.
Este formato soporta deserialización parcial, desrealiza sólo la columna que va a procesar y soporta compresión snappy.
Dentro del clúster, tanto Apache Parquet como AVRO y ORC se distribuyen a lo largo del clúster, ofreciendo alta escalabilidad y procesamiento paralelo. Los archivos JSON y XML no pueden dividirse, lo que genera una gran limitación para ser procesados en un clúster de forma paralela. A continuación, se detalla la estructura descrita:
Figura 5 Estructura interna de un archivo AVRO
Capítulo II
APACHE FLINK
- Definición
Apache Flink es un framework para computación, distribuido para la creación de aplicaciones de procesamiento de flujos con estado. La herramienta está creciendo con el apoyo de la comunidad, siendo uno de los motores de flujos más sofisticado. Flink impulsa aplicaciones comerciales a gran escala en empresas de diferentes industrias en todo el mundo. En este capítulo se estudia la capacidad de Flink para procesamiento en batch.
Apache Flink consta de tres componentes distribuidos que deben comunicarse: el JobClient, el JobManager y el TaskManager. El JobClient toma una tarea de Flink y la envía al JobManager, quien es responsable de orquestar la ejecución del trabajo. En primer lugar, asigna la cantidad necesaria de recursos, (esto incluye principalmente los slots de ejecución en los TaskManagers), luego despliega las tareas individuales de la tarea a los respectivos TaskManagers. Al recibir una tarea, el TaskManager genera un hilo que la ejecuta. Los cambios de estado, como el inicio del cálculo o el final del mismo se envían de nuevo al JobManager. Basándose en estas actualizaciones de estado, el JobManager dirige la ejecución de la tarea hasta que esté terminada. El resultado del mismo se envía de nuevo al JobClient y éste lo comunica al usuario, tal como se ilustra a continuación:
Figura 6 Proceso de ejecución del trabajo
- Casos de Uso
Apache Flink es una excelente opción para desarrollar y ejecutar muchos tipos diferentes de aplicaciones debido a su amplio conjunto de características. En tal sentido, se puede afirmar que las características de Flink incluyen soporte para el procesamiento de secuencias y lotes, sofisticada gestión de estados, semántica de procesamiento de tiempo de eventos y garantías de consistencia de una sola vez para el estado.
Además, Flink puede desplegarse en varios gestores de recursos como YARN, Apache Mesos, pero también como clúster autónomo en hardware bare metal (metal desnudo o expuesto), configurado para una alta disponibilidad. Flink fue probado para escalar a miles de núcleos y terabytes de estado de aplicación; ofrece un alto rendimiento y baja latencia.
- Aplicaciones Basadas en Eventos
Una aplicación basada en eventos es una aplicación de estado que ingiere eventos de uno o más flujos de eventos y reacciona a los eventos entrantes activando cálculos, actualizaciones de estado o acciones externas.
Las aplicaciones basadas en eventos son una evolución del diseño de aplicaciones tradicionales con niveles de almacenamiento de datos y computación separados. En esta modalidad, las aplicaciones leen datos y se graban en una base de datos transaccional remota.
Así mismo, las aplicaciones basadas en eventos se sustentan en aplicaciones de procesamiento de flujos de estado. En este diseño, los datos y el cálculo se encuentran en una misma ubicación, lo que permite el acceso local (en memoria o en disco) a los datos. La tolerancia a fallos se consigue escribiendo periódicamente puntos de control en un almacenamiento remoto persistente. La figura 7, muestra la diferencia entre la arquitectura de aplicación tradicional y las aplicaciones basadas en eventos.
Figura 7 Arquitectura de una aplicación tradicional (izquierda) y arquitectura de una aplicación basada en eventos (derecha).
En este mismo orden de ideas, se establece que Apache Flink es capaz de soportar las aplicaciones basadas en eventos. Los límites de las aplicaciones basadas en eventos se definen en función de la capacidad de un procesador de streaming para manejar el tiempo y el estado. Muchas de las características sobresalientes de Flink se centran en estos conceptos.
Flink proporciona un rico conjunto de primitivas de estado que pueden gestionar volúmenes de datos muy grandes (hasta varios terabytes) con garantías de consistencia de una sola vez. Además, el soporte de Apache Flink para el tiempo de evento, la lógica de ventana altamente personalizable y el control detallado del tiempo permiten la implementación de una lógica de negocio avanzada. Además, Flink dispone de una librería de Procesamiento de Eventos Complejos (CEP) para detectar patrones en flujos de datos.
Sin embargo, la característica sobresaliente de Flink para aplicaciones basadas en eventos es la denominada como punto seguro (savepoint). Un punto seguro es una imagen de estado coherente que puede utilizarse como punto de partida para aplicaciones compatibles.
- Aplicaciones de Análisis de Datos
Los trabajos analíticos de datos extraen información y conocimiento de los datos sin procesar. Tradicionalmente, los análisis se realizan como consultas por lotes o aplicaciones en conjuntos de datos limitados de eventos registrados. Para incorporar los últimos datos en el resultado del análisis, hay que añadirlos al conjunto de datos analizado y se vuelve a ejecutar la consulta o aplicación. Los resultados se escriben en un sistema de almacenamiento o se emiten como informes.
Con un sofisticado motor de procesamiento de flujos, el análisis también puede realizarse en tiempo real. En lugar de leer conjuntos de datos finitos, las consultas o aplicaciones de streaming ingieren flujos de eventos en tiempo real y producen y actualizan continuamente los resultados a medida que se consumen los eventos. Los resultados se escriben en una base de datos externa o se mantienen como estado interno. La aplicación Dashboard puede leer los últimos resultados de la base de datos externa o consultar directamente el estado interno de la aplicación. Apache Flink soporta aplicaciones de streaming, así como aplicaciones analíticas por lotes como se muestra en la figura 8.
Figura 8 Arquitectura del análisis en batch (izquierda) y arquitectura del análisis en streaming (derecha).
Apache Flink proporciona un soporte muy bueno para el streaming continuo, así como para el análisis por lotes. Específicamente, cuenta con una interfaz SQL compatible con ANSI con semántica unificada para consultas por lotes y streaming. Las consultas SQL calculan el mismo resultado independientemente de si se ejecutan en un conjunto de datos estáticos de eventos registrados o en un flujo de eventos en tiempo real. La compatibilidad con las funciones definidas por el usuario garantiza que el código personalizado se pueda ejecutar en las consultas SQL. Si se requiere aún más lógica personalizada, la API DataStream de Flink o la API DataSet proporcionan más control de bajo nivel. Además, la biblioteca Gelly de Apache Flink proporciona algoritmos y bloques de construcción para análisis gráficos a gran escala y de alto rendimiento en conjuntos de datos por lotes.
- Aplicaciones de Data Pipelines.
Extract-Transform-Load (ETL) es un enfoque común para convertir y mover datos entre sistemas de almacenamiento. A menudo, los trabajos de ETL se activan periódicamente para copiar datos de sistemas de bases de datos transaccionales a una base de datos analítica o a un almacén de datos.
Las tuberías de datos tienen un propósito similar al de los trabajos de ETL: transforman y enriquecen los datos y pueden moverlos de un sistema de almacenamiento a otro. Sin embargo, funcionan en modo de streaming continuo en lugar de activarse periódicamente. Por lo tanto, son capaces de leer registros de fuentes que continuamente producen datos y moverlos con baja latencia a su destino. La figura 9 devela la diferencia entre los trabajos periódicos de ETL y las tuberías de datos continuos, tal como se muestra a continuación:
Figura 9 Arquitectura de un trabajo periódico (izquierda) y una tubería de datos (derecha).
Fuente: Tomado de
La ventaja de las tuberías de datos continuos sobre los trabajos periódicos de ETL es la reducción de la latencia de mover los datos a su destino. Además, las tuberías de datos son más versátiles y pueden emplearse para más casos de uso porque son capaces de consumir y emitir datos continuamente.
Apache Flink posee la capacidad de soportar tuberías de datos. Muchas de las tareas comunes de transformación o enriquecimiento de datos pueden ser abordadas por la interfaz SQL de Flink (o Table API) y su soporte para funciones definidas por el usuario. Las tuberías de datos con requisitos más avanzados se pueden realizar utilizando la API de DataStream, que es más genérica.
Figura 10 Arquitectura de Apache Flink.
FlinkCEP – Procesamiento de eventos complejos para Flink
Con la ubicuidad de las redes de sensores y los dispositivos inteligentes que recopilan cada vez más datos, el ser humano se enfrenta al reto de analizar un flujo de datos cada vez mayor prácticamente en tiempo real. Ser capaz de reaccionar rápidamente a las tendencias cambiantes o de ofrecer una inteligencia de negocio actualizada puede ser un factor decisivo para el éxito o el fracaso de una empresa.
Un problema clave en el procesamiento en tiempo real es la detección de patrones de eventos en los flujos de datos; el tratamiento de eventos complejos (CEP) aborda exactamente este problema de emparejar continuamente los eventos entrantes con un patrón.
El resultado de una conciliación normalmente concluye en eventos complejos que se derivan de los eventos de entrada. A diferencia de los DBMS tradicionales en los que se ejecuta una consulta en datos almacenados, CEP ejecuta datos en una consulta almacenada. Todos los datos que no son relevantes para la consulta pueden ser descartados inmediatamente. Hay grandes ventajas en este enfoque, dado que las consultas CEP se aplican a un flujo de datos potencialmente infinito. Además, las entradas se procesan inmediatamente: una vez que el sistema ha visto todos los eventos de una secuencia coincidente, los resultados se emiten inmediatamente. Este aspecto conduce efectivamente a la capacidad de análisis en tiempo real de CEP.
En consecuencia, el paradigma de procesamiento de CEP encuentra aplicación en una amplia variedad de casos de uso. Además, se utiliza en el seguimiento y la supervisión basados en RFID, El CEP también puede utilizarse para detectar intrusiones en la red especificando patrones de comportamiento sospechoso de los usuarios.
Apache Flink, con su verdadera naturaleza de streaming y sus capacidades de baja latencia, así como de procesamiento de streaming de alto rendimiento, es una opción natural para las cargas de trabajo CEP. En consecuencia, la comunidad Flink ha introducido la primera versión de una nueva biblioteca CEP con Flink 1.0. Un ejemplo donde se ve el uso eficiente del CEP es en el monitoreo y generación de alertas para centros de datos.
Tabla API y SQL
Apache Flink incluye dos APIs relacionales (la Table API y SQL) para un procesamiento unificado de flujos y lotes. La Table API es una API de consulta integrada en lenguaje para Scala y Java que permite la composición de consultas de operadores relacionales como selección, filtrado y unión de forma muy intuitiva. El soporte SQL de Apache Flink está basado en Apache Calcite el cual implementa el estándar SQL. Las consultas especificadas en cualquiera de las interfaces tienen la misma semántica y especifican el mismo resultado independientemente de si el input es un batch input (DataSet) o un flujo de entrada (DataStream).
Las interfaces Table API y SQL están estrechamente integradas entre sí, así como las API de Flink DataStream y DataSet. El código creado puede ser modificado fácilmente entre todas las APIs y bibliotecas que se basan en las APIs. Por ejemplo, puede extraer patrones de un DataStream usando la librería CEP y luego usar la Table API para analizar los patrones, o puede escanear, filtrar y agregar una tabla de lotes usando una consulta SQL antes de ejecutar un algoritmo de Gelly en los datos pre procesados.
FlinkSQL
Flink SQL es el SDK API para SQL proporcionado por Flink. SQL es una API de nivel superior a la de la tabla. Está integrado en la biblioteca de tablas y puede utilizarse para desarrollar consultas sobre flujos como en lotes. A continuación, se muestra la estructura de FlinkSQL.
Figura 11 Arquitectura de FlinkSQL.
FlinkML
FlinkML es una librería de conjuntos de algoritmos de Machine Learning soportados por Flink que pueden ser utilizados para resolver problemas complejos de uso en la vida real. Los algoritmos están construidos para que puedan usar la potencia de computación distribuida de Flink y hacer predicciones o encontrar clústeres con facilidad. Si bien en este momento sólo se admiten unos pocos conjuntos de algoritmos, la lista se incrementa.
API de gráficos Flink – Gelly
En la era de los medios sociales donde todos están conectados entre sí por algún medio, cada objeto tiene una relación con otro. Facebook y Twitter son excelentes ejemplos, se resalta que son redes sociales, y es a partir de la información extraída de ellas se puede construir de gráficos sociales; donde X es amigo de Y y P sigue a Q, y así sucesivamente. Estas gráficas son tan grandes que se requiere un motor que pueda procesarlas eficientemente.
API de Flink DataStream
Los programas DataStream en Flink son programas regulares que implementan transformaciones en los flujos de datos (por ejemplo: filtrado, estado de actualización, definición de ventanas, agregación). Los flujos de datos se crean inicialmente a partir de varias fuentes (por ejemplo: colas de mensajes, flujos de socket, archivos). Los resultados se devuelven a través de Sinks que pueden escribir los datos en archivos o en una salida estándar (por ejemplo: terminal de línea de comandos). Los programas Flink se ejecutan en una variedad de contextos, de forma independiente o incrustados en otros programas. La ejecución puede ocurrir en una JVM local, o en clúster de muchas máquinas.
Transformaciones de DataStream
Algunas de las transformaciones más usadas en operaciones de flujos son los Map, lo cuales toman un elemento y produce un elemento el cual es resultado de una transformación; los FlatMap que se caracterizan por tomar un elemento y produce cero, uno o más elementos; los Filter que evalúan una función booleana para cada elemento y retiene aquellos para los que la función devuelve verdadero; el Reduce, estableciendo una reducción “rodante” en un flujo de datos clave, además combina el elemento actual con el último valor reducido y emite el nuevo valor y por último el Windows el cual agrupa los datos en cada clave de acuerdo a alguna característica (por ejemplo, los datos que llegaron en los últimos 5 segundos).
API de Flink DataSet
En los siguientes apartados se define de manera directa el término necesario para dar respuesta a esta variable objeto de estudio, se plantea el desarrollo del término transformaciones de DataSet
Transformaciones de DataSet
Entre las transformaciones de DataSet, se distinguen las siguientes:
Tabla 1. Transformaciones de DataSet.
Capítulo III
APACHE SPARK
En el capítulo anterior se desarrollaron todos aquellos términos relacionados con Apache Flink, ahora bien, es necesario desarrollar la teoría con respecto a Apache Spark.
- Definición
Apache Spark es un motor informático unificado y un conjunto de librerías utilizadas para el procesamiento paralelo de datos en clústeres informáticos. Apache Spark es el motor de código abierto más activamente desarrollado, lo cual lo convierte en una herramienta estándar para cualquier desarrollador o científico de datos interesado en datos de gran tamaño.
Apache Spark soporta múltiples lenguajes de programación utilizados de manera masiva (Python, Java, Scala y R), incluye bibliotecas para diversas tareas que van desde SQL hasta flujos y aprendizaje automático. Puede ejecutarse desde cualquier lugar, ya sea desde una computadora portátil hasta un grupo de miles de servidores. Esto hace que sea un sistema fácil de iniciar y escalar hacia un gran procesamiento de datos o a una escala increíblemente grande.
Apache Spark comienza en la Universidad de California en Berkeley en 2009 como el primer proyecto de investigación de Spark. Al año siguiente se publica un artículo titulado “Spark: Clúster Computing with Working Sets” por Matei Zaharia, Mosharaf Chowdhury, Michael Franklin, Scott Shenker, e Ion Stoica de la UC Berkeley AMPlab. En ese momento, Hadoop MapReduce era la programación paralela dominante para clústeres, siendo el primer sistema de código abierto en abordar el procesamiento paralelo de datos agrupados en miles de nodos. El AMPlab está trabajado con múltiples usuarios de MapReduce para entender los beneficios e inconvenientes de este nuevo modelo de programación, y por lo tanto es capaz de sintetizar una lista de problemas de uso en varios casos y comenzar a diseñar a un nivel más general plataformas informáticas. Además, Zaharia también ha trabajado con usuarios de Hadoop en UC Berkeley para entender cuáles son sus necesidades respecto a la plataforma. A través de este trabajo, quedan esclarecidas dos cuestiones. En primer lugar, la computación en clúster tuvo un enorme potencial: en cada organización que utiliza MapReduce, se pueden construir aplicaciones totalmente nuevas utilizando los datos existentes. En segundo lugar, el motor MapReduce hizo que fuera a la vez desafiante e ineficiente construir una gran aplicación.
Por ejemplo, el típico algoritmo de aprendizaje de la máquina puede necesitar hacer 10 o 20 pasadas por encima de los datos, y en MapReduce cada pase tiene que ser escrito como un MapReduce separado. A su vez cada uno debe lanzarse por separado en el clúster y cargar así los datos desde cero.
Para resolver este problema, el equipo de Spark diseña primero una API basada en programación funcional que puede expresar aplicaciones de varios pasos. A continuación, el equipo implementa esta API a través de un nuevo motor que permite compartir datos en memoria de forma eficiente durante todos los pasos de la computación.
También comienza a probarse este sistema tanto con Berkeley como con usuarios externos. La primera versión de Spark sólo soporta aplicaciones por lotes, pero muy pronto otra se hizo evidente: la ciencia de datos interactiva y las consultas ad hoc. Simplemente conectando el intérprete de Scala a Spark, el proyecto puede proporcionar una interfaz interactiva ágilmente utilizable para ejecutar consultas en cientos de máquinas.
3.1 DataFrame
Una de las principales herramientas con las que cuenta Apache Spark son los DataFrame. Estos representan la API estructurada más común y consiste en una tabla de datos con filas y columnas. La lista que define las columnas y los tipos dentro de ellas se denomina esquema. Se puede pensar en un DataFrame como una hoja de cálculo con columnas con nombre con una diferencia fundamental: una hoja de cálculo se almacena en una única computadora, mientras que un Spark DataFrame puede abarcar miles de computadoras. Existen motivos por los que almacenar datos en más de una computadora: o bien los datos son demasiado grandes y no caben en una sola, o requiere demasiado tiempo realizar ese cálculo en una única máquina.
Apache Spark tiene varias abstracciones centrales: Datasets, DataFrames, Tablas SQL y Resilient Distributed Conjuntos de datos (RDDs). Todas estas diferentes abstracciones representan colecciones de datos distribuidos. Los de uso más fácil y eficientes son los DataFrame, que se encuentran disponibles en casi todos los lenguajes de programación.
Particiones
Para permitir que cada ejecutor realice su trabajo en paralelo, Apache Spark divide los datos en trozos llamados particiones. Una partición es una colección de filas que se graban en una máquina física en su clúster. Las particiones de DataFrame representan la distribución física de los datos a través del clúster durante la ejecución. Si sólo existe una partición, Apache Spark emplea el paralelismo de sólo una, incluso si ella tiene miles de ejecutores. Si tiene muchas particiones, pero sólo un ejecutor, puede seguir manteniendo un único paralelismo porque sólo hay un recurso de computación. Una cosa importante a tener en cuenta con respecto a los DataFrame, es que no se manipulan (en su mayor parte) manualmente o individualmente. Simplemente se especifican las transformaciones de alto nivel de los datos en él y Apache Spark determina cómo se ejecuta el trabajo en el clúster.
Transformaciones
En Apache Spark, las estructuras de datos básicos son inmutables, lo que significa que no se pueden modificar luego de ser creadas. Las instrucciones que permiten cambiar un DataFrame se denominan transformaciones. En la figura 12 se muestra una transformación simple para encontrar todos los números pares en el DataFrame actual:
Figura 12 Transformación Simple.
Estos datos no devuelven ninguna salida debido a que sólo se especifica una transformación abstracta, y Apache Spark no actúa sobre las transformaciones hasta ser llamado a la acción. Las transformaciones son el núcleo de la forma en que se expresa la lógica de negocio utilizando dicho framework. Hay dos tipos de transformaciones: las que especifican dependencias estrechas, y las que especifican dependencias anchas. Las transformaciones que consisten en dependencias o transformaciones estrechas son aquellas para las cuales cada partición de entrada contribuye a una sola partición de salida.
Una transformación de estilo de dependencia (o transformación amplia) tiene particiones de entrada que contribuyen a muchas particiones de salida. A menudo esta tarea se conoce como un Shuffle (barajada) en la que Spark intercambia particiones a través del clúster. Con transformaciones estrechas, Spark puede realizar automáticamente una operación llamada pipelining, lo que significa que, si se especifican múltiples filtros en los DataFrames, todos se realizan en memoria.
Arquitectura y Componentes
El componente Spark Core contiene las funcionalidades básicas de Apache Spark indispensable para la ejecución de trabajos y también necesarios por otros componentes. La más importante de ellas es el conjunto de datos distribuidos resilientes (RDD), que es la unidad de trabajo principal de la API de Spark. Es una abstracción de una colección distribuida de ítems con operaciones y transformaciones aplicables al conjunto de datos. Es capaz de reconstruir conjuntos de datos en caso de fallas en los nodos. La figura 14 muestra los distintos componentes que conforman a Spark.
Figura 14. Componentes que conforman a Spark.
Spark Core contiene la lógica para acceder a varios sistemas de archivos, como lo son los del tipo HDFS. Además, proporciona un medio de intercambio de información entre los sistemas informáticos, nodos con variables de emisión y acumuladores. Otras funciones fundamentales, tales como manejo de redes, seguridad, programación y transferencia de datos, también forman parte de Spark Core, como se muestra a continuación
Spark SQL proporciona funciones para manipular grandes conjuntos de datos distribuidos y estructurados utilizando un subconjunto SQL soportado por Spark y Hive SQL (HiveQL). Los DataFrames introducidos en Spark 1.3, y DataSets introducidos en Spark 1.6, simplificaron el manejo de datos estructurados y han permitido optimizaciones radicales en el rendimiento, así Spark SQL se ha convertido en uno de los componentes más importantes de Spark. Otra utilización común está destinada a leer y escribir datos desde (y hacia) diversos formatos estructurados, como es el caso de los archivos JSON (JavaScript Object Notation), archivos de Parquet, bases de datos relacionales, Hive y otros.
Las operaciones en DataFrames y DataSets en determinado momento se traducen en operaciones RDDs y se ejecutan como trabajos normales de Spark. Spark SQL proporciona un marco de optimización de consultas llamado Catalyst que puede ser extendido por reglas de optimización personalizadas. Spark SQL también incluye un servidor Thrift, el cual puede ser utilizado por sistemas externos, tales como el correspondiente a inteligencia de negocios, con el objetivo de consultar datos a través de Spark SQL haciendo uso de los protocolos clásicos JDBCy ODBC. En la figura 16 se puede observar la arquitectura de Spark SQL.
Figura 16. Arquitectura de Spark SQL.
Spark Streaming es un marco de trabajo para la ingesta de datos provenientes de streaming en tiempo real. Estos datos pertenecen a diversas fuentes, las soportadas incluyen HDFS, Kafka, Flume y otras fuentes personalizadas. Las operaciones de Spark Streaming se recuperan de un fallo automáticamente, lo cual es importante para el procesamiento de datos en línea. La transmisión por Spark representa datos de streaming utilizando flujos discretizados (DStreams), quienes periódicamente crean RDDs que contengan los datos que entraron durante la última ventana de tiempo. Spark Streaming puede combinarse con otros componentes de Spark en un solo programa, unificando el procesamiento en tiempo real con tareas de aprendizaje automático, el SQL y las operaciones gráficas. Esto representa algo único en el ecosistema de Hadoop. Desde Spark 2.0, la nueva API estructurada de streaming hace que los programas de streaming de Spark sean más similares a los programas batch de Spark, tal como se ilustra en la figura 17.
Figura 17. Procesamiento de Spark Streaming.
Spark MLlib es una librería de algoritmos de aprendizaje de máquina desarrollados a partir del proyecto MLbase en la Universidad de California en Berkeley. Los algoritmos soportados incluyen regresión logística, clasificación de Naive Bayes, máquinas vectoriales de sporte (SVMs), árboles de decisión, regresión lineal y k-means, tal como se puede observar en la figura 18.
Además, Spark MLlib maneja modelos de aprendizaje de máquina utilizados para la transformación de conjuntos de datos, que se representan como RDDs o DataFrames.
Figura 18 Arquitectura de Spark MLlib.
Las herramientas de extracción, transformación y carga (ETL) proliferaron junto con el crecimiento de los datos de las organizaciones. Trasladar los datos desde una fuente a uno o más destinos, procesándolos antes de que lleguen a destino, comenzando entonces a ser un requisito. En un principio estas herramientas admiten pocos tipos de datos, fuentes y destinos. Esto se debe a las limitaciones mencionadas, puesto que los procesos de transformación de un solo paso se ejecutan en múltiples pasos, de modo que se produce un desperdicio de recursos en términos de eficiencia, tiempo y costos. Debido a ello, muchas organizaciones entran en el bloqueo de proveedores debido a la profunda necesidad de procesar datos. Casi todas las herramientas introducidas antes del año 2005 no utilizan el poder real de la arquitectura multinúcleo de las computadoras, sino que se ejecutan utilizando un solo núcleo, por lo tanto, los trabajos de procesamiento de datos simples pero voluminosos tardan demasiado tiempo en completarse. Apache Spark se ha convertido en un éxito instantáneo en el mercado debido a su capacidad para procesar una gran cantidad de tipos de datos con un número creciente de fuentes y destinos.
La abstracción de datos más importante y básica que proporciona Spark es el conjunto de datos distribuidos (RDD), lo que hace que soporte el procesamiento distribuido en un grupo de nodos dentro de un clúster. Cuando hay un grupo de nodos, existen posibilidades de que alguno de ellos deje de funcionar durante el procesamiento de los datos. La parte resiliente de RDD ha sido diseñada para solventar esta falla.
Si hay una gran cantidad de datos por procesar y hay nodos disponibles en el clúster, el framework debe tener la capacidad de dividir el gran conjunto de datos en trozos más pequeños y distribuirlos para ser procesados en más de un nodo en un clúster, en paralelo. Spark es capaz de realizar esa acción y eso es lo que significa la parte distribuida en el RDD. En otras palabras, Apache Spark está diseñado desde cero para tener su abstracción básica de conjuntos de datos capaz de dividirse en piezas más pequeñas de forma determinística y distribuirse a más de un nodo del clúster para su procesamiento en paralelo, a la vez que maneja con elegancia las fallas en los nodos.
Programación funcional con Spark
La mutación de objetos en tiempo de ejecución y la incapacidad de obtener resultados consistentes de un programa o función debido al efecto secundario que la lógica del programa crea, hace que muchas aplicaciones sean muy complejas. Si las funciones de los lenguajes de programación se comportan exactamente igual que las funciones matemáticas, de tal manera que la salida de la función depende sólo de las entradas, esto da mucha previsibilidad a las aplicaciones. El paradigma de programación de computadoras que otorga demasiado énfasis al proceso de construcción de tales funciones y otros elementos basados en eso, y el uso de esas funciones justo en la forma en que cualquier otro tipo de datos están siendo utilizados, es popularmente conocido como el paradigma de programación funcional. Fuera de los lenguajes de programación basados en JVM, Scala es uno de los más importantes que tiene una capacidad de programación funcional muy fuerte sin perder ninguna orientación a objetos. Spark se escribe predominantemente en Scala. Por eso mismo, Spark ha asimilado muchos conceptos positivos de Scala.
Spark RDD
RDD es la estructura de datos fundamental de Apache Spark. Se trata de una colección de particiones de sólo lectura de registros. Sólo puede ser creado a través de una operación determinista en cualquiera de los dos: Datos en almacenamiento estable, otros RDDs, y paralelización de colecciones ya existentes en el programa de RDD. El mismo refiere a una colección distribuida inmutable de datos, particionada a través de nodos en el clúster que puede ser operada en paralelo con una API de bajo nivel ofreciendo transformaciones y acciones.
La característica más importante que Apache Spark toma de Scala, es la capacidad de usar funciones como parámetros para sus transformaciones y acciones. Muy a menudo, el RDD de Spark se comporta como un objeto de colección en Scala. Por eso, algunos de los nombres de los métodos de transformación de datos de las colecciones de Scala se utilizan en Spark RDD para realizar la misma acción. Este es un enfoque muy limpio y aquellos que tienen experiencia en Scala encontraran el mismo fácil de programar con RDDs.
Algunas de sus características se distinguen en la Tabla 2
La aplicación Spark
Una aplicación Spark corresponde a un conjunto de tareas definidas por un SparkContext en el programa driver. Una aplicación Spark comienza cuando se inicia un SparkContext. Al iniciarlo, se inicia un driver y una serie de ejecutores en los nodos de trabajo del clúster. Cada ejecutor posee su propia máquina virtual Java (JVM), y cada uno no puede abarcar múltiples nodos, aunque si un nodo puede contener varios ejecutores. El SparkContext determina cuántos recursos se asignan a cada ejecutor.
Figura 19. Arquitectura de la ejecución de un SparkContext
Cuando se lanza un trabajo de Apache Spark, cada ejecutor tiene sus slots destinado a ejecutar las tareas necesarias para calcular un RDD. De esta manera, se puede pensar en un SparkContext como un conjunto de configuración de parámetros que tienen como finalidad ejecutar los trabajos de Spark. Estos parámetros se exponen en la sección SparkConf, la cual sirve para crear un SparkContext. Un nodo puede tener varios ejecutores de Spark, pero un nodo no puede abarcar múltiples nodos. Un RDD es evaluado a través de los ejecutores en las particiones. Cada ejecutor puede tener varias particiones, pero una partición no puede extenderse a varios ejecutores.
Limitaciones de los RDD
Apache Spark RDD presenta distintas limitaciones que mediante un uso apropiado de DataFrame y Dataset pueden ser superadas. Entre estas limitaciones se destaca que no tiene un motor de optimización de entrada, en este sentido, partiendo de la base de que no existe ninguna disposición en el RDD para la optimización automática, no puede hacer uso de optimizadores de avance de Spark como el optimizador de Catalyst y el motor de ejecución de tungsteno. Sin embargo, se puede optimizar cada RDD manualmente. Esta limitación se supera en Dataset y DataFrame, ambos hacen uso de Catalyst para generar un plan de consulta lógico y físico optimizado. Además, se puede utilizar el mismo optimizador de código para R, Java, Scala o Python DataFrame/Dataset APIs. Aunque es prudente indicar que esto proporciona un incremento en términos de eficiencia en cuanto al espacio y a la velocidad.
Otra de las limitaciones consiste en la seguridad del tipo de funcionamiento, dado que el RDD se degrada cuando no hay suficiente memoria para almacenar el RDD en memoria o en el disco. El problema de almacenamiento aparece cuando existe una falta de memoria para almacenar el RDD. Las particiones que se desbordan de RAM se pueden almacenar en el disco y proporciona el mismo nivel de rendimiento. Es posible superar este inconveniente aumentando el tamaño de la memoria RAM y del disco.
Asimismo, es necesario destacar la limitación en cuanto a rendimiento, en el sentido que el RDD es un objeto JVM en memoria, implica la sobrecarga del Garbage Collector y la serialización de Java, lo que resulta costoso cuando los datos crecen. Dado que el coste de la recogida de basuras es proporcional al número de objetos Java, el uso de estructuras de datos con menos objetos reducirá el coste. La otra opción posible es persistir en el objeto en forma serializada.
De la misma manera, vale destacar que el manejo de datos estructurados no proporciona una vista de esquema de los datos y tampoco tiene ninguna disposición para el manejo de datos estructurados. Dataset y DataFrame proporcionan la vista esquema de datos, la cual es una colección distribuida de datos organizada en columnas con nombre. Estas representaban las principales limitaciones de RDD en Apache Spark.
Como resultado de las limitaciones de RDD, se devela la necesidad de crear DataFrame y Dataset. De esta manera, el sistema se ha hecho más amigable facilitando el trabajo con un gran volumen de datos.
Agregaciones
La agregación es el acto de resumir y se considera la piedra angular de los grandes análisis de datos. En una agregación, se especifica una clave o agrupación y una función de agregación que especifique cómo debe transformar una o más columnas. Esta función debe producir un resultado con múltiples valores de entrada. Las capacidades de agregación de Spark son sofisticadas, con una variedad de diferentes casos de uso y posibilidades. En general, las agregaciones se utilizan para integrar datos numéricos generalmente por medio de alguna agrupación. Esto puede ser una suma, un producto o un simple conteo, además de trabajar con cualquier tipo de valores.
Agregar a tipos complejos en Spark, puede realizar agregaciones no sólo de valores numéricos utilizando fórmulas, sino que también puede realizarlos en tipos complejos. Por ejemplo, se puede recopilar una lista de valores presentes en un archivo o sólo los valores unívocos recogidos en un set. Puede utilizarlo para llevar a cabo algún acceso más programático más adelante en el pipeline o pasar la colección completa en una función definida por el usuario (UDF).
Funciones de agregación
Todas las agregaciones están disponibles como funciones. Entre estas agregaciones se destaca Sum, la cual constituye una tarea simple que suma todos los valores en una columna y Avg, aunque se puede calcular el promedio dividiendo la suma por el conteo, Apache Spark proporciona una manera fácil de obtener ese valor a través de las funciones AVG o media. En este ejemplo, se usa alias para obtener más y reutilizar fácilmente estas columnas.
Evaluación perezosa
La evaluación de los RDDs es completamente perezosa. Apache Spark no empieza a computar las particiones hasta que se llame a una acción. Una acción es una operación de Spark que devuelve algo que no sea un RDD, desencadenando la evaluación de las particiones, por ejemplo, devolver los datos al driver (con operaciones como count o collect). Las acciones son desencadenadas por el driver, que construye un gráfico acíclico dirigido (llamado DAG), basado en las dependencias entre las transformaciones de los RDDs. En otras palabras, Spark evalúa una acción que consiste en ir hacia atrás para definir qué serie de pasos tiene que dar para producir determinado objeto en cada partición. Entonces, utilizando esta serie llamada plan de ejecución driver, se calcula las particiones que faltan para cada etapa hasta que finalmente se compute el resultado.
Aunque es preciso destacar que no todas las transformaciones en Spark son 100% perezosas, por ejemplo, la función sortByKey necesita evaluar el RDD para determinar que rango de datos va a ordenar. Esto involucra una transformación y una acción.
La evaluación perezosa permite a Apache Spark combinar operaciones que no requieren comunicación con el driver (llamadas transformaciones de dependencia uno a uno) y esto impide que se hagan varias lecturas a los mismos datos. Por ejemplo, si se parte del supuesto de que un programa Spark llama a las funciones Map y a filter para procesar un RDD. Apache Spark puede enviar las instrucciones para map y filter en cada ejecutor, entonces realiza ambas operaciones sobre cada partición y de esta forma acceder a los datos solo una vez. Esto resulta más eficiente que enviar dos conjuntos de instrucciones y acceder a cada partición dos veces. Según la teoría esta acción baja el tiempo computacional a la mitad.
Persistencia en memoria y gestión de la memoria
La ventaja de rendimiento de Spark sobre MapReduce es mayor en casos donde el uso involucre cálculos repetidos. Gran parte de este incremento en el rendimiento se debe de contar con persistencia en memoria. En lugar de escribir en el disco entre cada paso a través de la ventana de diálogo, Spark tiene la opción de mantener los datos de los ejecutores cargados en la memoria. De esta manera, los datos de cada partición están disponibles en memoria cada vez que sea necesario a la que se ha accedido. Apache Spark ofrece tres opciones para la gestión de la memoria: en memoria como datos de serializados, en memoria como datos serializados, y en disco.
La anatomía de un Job de Spark
En el paradigma de evaluación de Spark, una aplicación de Spark no realiza ninguna acción hasta que el programa driver lo inicie. Con cada acción, el programador de Apache Spark crea un gráfico de ejecución y lanza un trabajo. Cada tarea consta de etapas, que son pasos en la transformación de los datos necesarios para materializar el RDD final. Cada operación consiste en un conjunto de tareas que representan un cálculo paralelo y son los ejecutores. La figura muestra un árbol de los diferentes componentes de una aplicación de Apache Spark y cómo corresponden a las llamadas de la API. Cada trabajo puede contener varias etapas que corresponden a cada transformación amplia. A su vez, cada etapa se compone de una o varias tareas que corresponden a una unidad de cálculo realizada en cada etapa. Hay una tarea para cada partición en el RDD resultante de esa etapa. Este proceso se ilustra en la Figura 24
Gráfico acíclico dirigido DAG
Apache Spark viene con un motor de procesamiento de datos DAG (Grafo Acíclico Dirigido) avanzado. Lo que significa que por cada trabajo de Spark, se crea un DAG de tareas para ser ejecutado por el motor. El DAG en lenguaje matemático consiste en un conjunto de vértices y bordes dirigidos que los conectan. Las tareas se ejecutan según la disposición DAG.
En el caso de MapReduce, el DAG consiste en sólo dos vértices, uno para la tarea de mapa y el otro para la tarea de reducir. El borde se dirige desde el vértice del mapa, hacia el vértice de reducción. El procesamiento de datos en memoria combinado con su motor de procesamiento de datos basado en DAG hace que Spark sea muy eficiente.
En el caso de Apache Spark, el DAG de las tareas puede ser tan complicado como sea posible. Apache Spark viene con utilidades que pueden dar una excelente visualización del DAG de cualquier trabajo de Spark que se esté ejecutando.
Fase de Prueba muestra usada
La base de datos de pruebas fue transportada de una base de datos Oracle a un clúster, respetando su formato y su estructura. Para la prueba se utiliza las tablas detalladas a continuación.
Packs: contiene 40 columnas con información acerca del precio, fecha de lanzamiento y nombre comercial del fármaco entre otros detalles sobre el medicamento. Tiene una cantidad de 99.155 registros y los tipos de datos son String. El dato no tiene compresión por lo que se puede ver el contenido de la tabla.
Products: contiene 20 columnas que dan información acerca de los productos que se utilizan para el procesamiento. Esta tabla precisa información descriptiva acerca del país donde se vende el producto, a qué tipo de fármaco pertenece, si es un antibiótico, un antidepresivo, etc. Cuenta con un set de datos tipo String de 81.402 registros. No tiene compresión. Es la entidad más importante ya que el negocio se basa en la venta de productos.
Sell_point: contiene 62 columnas con información de los lugares donde se vende el producto: identificador del país, razón social, si es farmacia o distribuidor, dirección, entre otros datos. Cuenta con un total de 627.432 registros donde cada campo es tipo String y no tiene compresión. Usando esta tabla se puede determinar qué producto se vende más en cada punto de venta y bajo qué forma (Packs).
Details: contiene las transacciones por punto de venta y pack proveedor. La información es transaccional y cuenta con 8.351.286.956 registros, 10 columnas tipo String y un peso de 500MB.
typed_sell_point: contiene los tipos de puntos de venta según su ubicación. Cuenta con 20 registros y siete campos de tipo String sin compresión.
Nidde: tabla auxiliar que contiene el código postal según la zona geográfica. Tiene un total de 1.083.393 registros y un peso de 23.8 MB.
Regions: contiene 28 registros y ubica en qué regiones se venden los productos.
Presentations: indica la presentación del medicamento. Contiene 6042 registros sin compresión.
Resultados
Las agregaciones se dispararon en distintos formatos de archivos Parquet CSV y ORC alcanzando el mejor resultado en ORC con un resultado de punta a punta de 3.8 minutos. para esa volumetria completa para mas informacion visitar la pagina http://sedici.unlp.edu.ar/handle/10915/126780 en el area de pruebas del documento encontrara toda la informacion acerca de la prueba completa.
Conclusiones
Este trabajo aborda la necesidad de indagar en un punto de gran importancia en el área de Big Data referido a la elección idónea del tipo de Framework a usar para realizar procesamiento distribuido, teniendo en cuenta que las empresas disponen de data warehouse y otras fuentes de datos que no son de origen estructurado proveniente de redes sociales como Twitter, Facebook y otras.
De este modo se hace manifiesta la necesidad de disponer de frameworks que se adapten y manipulen estos datos sin mucho esfuerzo; la gran cantidad de datos variados hoy impactan en todas las empresas y es necesario contar con herramientas de este tipo, para que luego otros procesos tomen estos resultados y los muestren en tableros (dashboards) y así se puedan tomar decisiones.
A partir de la creación de Apache Spark en 2014, y a medida que se ha venido popularizando, el desarrollo en ambientes de grandes datos, se modifica para siempre; es por ello que actualmente se plantean estos desarrollos como proyectos de software orientados a datos, en los cuales se cuenta con todas las ventajas que trae trabajar con un proyecto de software.
Previo al surgimiento de estas herramientas, el procesamiento se torna difícil de construir y mantener y básicamente no se creaban piezas software extensible, lo cual implica un problema para las empresas debido a sus altos costos de mantenimiento y operación.
Al comienzo de este proyecto se formulan objetivos específicos fundamentales que motivaron la realización del trabajo. Luego de la investigación y experimentación realizadas y a partir de los resultados obtenidos de las pruebas, queda en evidencia que de tratarse en un estudio temprano en un proyecto que involucre procesamiento por lotes la herramienta a utilizar debe ser Spark porque queda demostrado ser un framework muy simple en cuanto a codificación donde con pocas líneas de código se realizan muchas tareas. También dispone de mucha comunidad, documentación, video, cursos, ejemplos y ha sido creado para procesar información por lotes. No siendo igual en estos temas que son de suma importancia, apache Flink, que resulta ser un framework diseñado para procesamiento de Streaming y en donde su API para procesamiento por lotes carece de comunidad activa, hay pocos ejemplos, y poca bibliografía para procesamiento por lotes, pero por el contrario si hay mucho material cuando se habla de procesamiento de Streaming, donde Flink se destaca.
Ambos son realmente rápidos sin lugar a dudas en la resolución de las agregaciones planteadas como problema para la experimentación, y han ganado popularidad por disponer de la flexibilidad para procesar datos de distintos tipos y grandes en un tiempo récord, siendo Apache Spark el destacado, además de brindar la posibilidad de crear aplicaciones que usen su potencial en distintos lenguajes de programación como R, Python, Scala y Java, teniendo también integración nativa con HDFS, YARN, HIVE, HBASE y una infinidad de herramientas nativas de los ecosistemas de llamados de Big Data.
Flink, en cambio, permite crear aplicaciones en Python, Scala, Java, pero la integración con HDFS, YARN, HIVE no es nativa con los servicios mencionados, y si bien la integración con otras herramientas de los llamados ecosistemas de Big Data está creciendo, todavía no existen muchos conectores con esta herramienta.
A través de la experimentación se observa que los mejores tiempos obtenidos para ambas herramientas se lograron cuando se modifica el storage y se convierte en un formato columnar, lo que indica que por el tipo de procesamiento que este formato mejora los tiempos en comparación con el formato CSV usado en las primeras pruebas. En tal sentido, se desprende que el formato del storage es otro punto a optimizar e indica que dependiendo de la operación a emprender para hacer un formato u otro, ofrecen mejores tiempos de procesamiento.
Por otro lado, se ha encontrado diferencias en cuanto al lenguaje de consulta (SQL) de Flink y de Spark lo que lleva a duplicar el trabajo durante la experimentación y escribir más código para Flink que para spark.
En la creación de la tabla preview durante la primera etapa, Apache Flink ha demostrado hacer mejor uso de recursos de cómputo y obtiene mejor tiempo de respuesta que Apache Spark. No obstante, en la creación de las agregaciones, Apache Flink se devela un mejor uso de los recursos de cómputo, pero penaliza en performance, de modo que Apache Spark resulta ser la mejor opción para cálculos de agregaciones. Ambos frameworks demostraron tener su mejor respuesta con la configuración “contexto2” y Spark tuvo el mejor desempeño.
En la etapa dos, se toma el mejor contexto de la etapa uno, además se reduce a dimensión de las tablas y se convierten los datos a ORC (Formato Columnar) entendiendo que las consultas realizadas bajo este formato responden más eficientemente. Flink logro tener el mejor tiempo respuesta y uso de recursos bajo estas pruebas.
La codificación para Flink resulta ser muy compleja, por la falta de documentación mencionada. Además, se han presentado problemas técnicos muy complejos por esta misma razón. Por otro lado, a la hora de decidir qué framework usar, también se toma en cuenta qué tan complejo es encontrar personal idóneo que pueda integrarse al proyecto de forma rápida, y que disponga de la experiencia y la formación en estos temas. La cantidad de información y la gran comunidad con la que cuenta Spark indica que hay profesionales trabajando de forma activa y de Flink no se puede decir lo mismo.
Como conclusión, se deja que hay una relación directa entre storage y el framework que los procesa. Esto significa que se debe optimizar tanto el framework de procesamiento como los datos a trabajar.
Durante la preparación de la prueba, se observa que Apache Flink no tiene una gran comunidad de desarrolladores, siendo difícil encontrar ejemplos y material de lectura, como documentación técnica y mejores prácticas basadas en la experiencia de la comunidad, que son necesarias para construcción de soluciones de software que trabaje con dicho framework.
Como trabajo futuro se pretende analizar el comportamiento de este tipo de frameworks en arquitecturas de mayor tamaño con mayor cantidad de nodos. Y otra configuración de clúster. Por otro lado, de cara a futuro, se pretende trabajar con agregaciones y ETLs sobre Streaming viendo si este modelo de procesamiento y el escalamiento de más nodos mejora los tiempos de los procesos y da más información para poder seguir comparando ambos frameworks.
Referencias Bibliográficas
- Karau, Holden & Warren, Rachel (2017). High Performance Spark: Best practices for scaling and optimizing Apache Spark. O’Reilly Media, Inc.
- Ryza, S., Laserson, U., Owen, S. & Wills, J. (2017). Advanced Analytics with Spark: Patterns for Learning from Data at Scale. O’Reilly Media, Inc.
- Hurtado, J. (2015). El Proyecto de Investigación. Editorial Quirón.Caracas Venezuela.
- Hueske, F. & Kalavri, V. (2019). Stream Processing with Apache Flink: Fundamentals, Implementation, and Operation of Streaming Applications. O’Reilly Media, Inc.
- Saxena, S. & Gupta, S., (2017). Practical Real-time Data Processing and Analytics: Distributed Computing and Event Processing using Apache Spark, Flink, Storm, and Kafka. Packt Publishing Ltd.
- Deshpande, T. (2017). Learning Apache Flink. Packt Publishing Ltd. UK.
- Avro format https://avro.apache.org/docs/1.8.1/spec.htm
- Parquet Format https://parquet.apache.org/documentation/latest/
- ORC Format https://orc.apache.org/
- Apache Spark References https://spark.apache.org/docs/latest/sql-reference.html. Informacion sustraida en Abril año 2020
- Data Flair https://data-flair.training/blogs/comparison-apache-flink-vs-apache-spark/ . Informacion Sustraida en Enero 2020.
- Apache Flink References https://ci.apache.org/projects/flink/flink-docs-stable/ Informacion Sustraida en Enero 2020.
- Columnar Databases https://www.columnardatabase.com/ Informacion Sustraida en Enero 2020.
- Apache mesos http://mesos.apache.org/documentation/latest/ Informacion Sustraida en Enero 2020.
- Dharmesh Kakadia (2015) Apache Mesos Essentials: Build and execute robust and scalable applications using Apache Mesos
- Architecture of Mesos http://mesos.apache.org/documentation/latest/architecture/
- Apache Hadoop https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/CommandsManual.html Informacion Sustraida en Febrero 2020.
- Mark Grover, Ted Malaska (2015) Hadoop Application Architectures: Designing Real-World Big Data Applications
- Tom White (2015) Hadoop: The Definitive Guide: Storage and Analysis at InternetScale
- Macías Lloret, Mario, Gómez Parada, Mauro, Tous Liesa, Rubén, Torres Viñals, Jordi (2015) Introducción A Apache Spark
