parte_36.txt

Gestión de los datos corporativos TEMARIO OPOSICIONES COIICV | TEMA 36 41 • Procesamiento streaming : Su principal orientación es hacia el procesamient o de un flujo continuo de datos, donde prima la velocidad. Son si stemas donde se debe asegurar una baja latencia. • Procesamiento híbrido : El obje...

Gestión de los datos corporativos TEMARIO OPOSICIONES COIICV | TEMA 36 41 • Procesamiento streaming : Su principal orientación es hacia el procesamient o de un flujo continuo de datos, donde prima la velocidad. Son si stemas donde se debe asegurar una baja latencia. • Procesamiento híbrido : El objeto es procesar grandes volúmenes en tiempo real, por lo que deben asegurar baja latencia y escalabilidad. S u infraestructura suele ser híbrida, con un sistema batch para los grandes volúmenes y un sistema streaming para los datos continuos, combinando los resultados a la salida. E ste tipo de sistemas es el que más complejidad inherente presenta. En entornos big data el flujo de procesamiento se divide en tres fases: adquisición de los datos, almacenamiento y análisis. • Adquisición de datos: En el apartado de minería de datos vimos en qué consistía la creación y rellenado de un almacén de datos, así co mo las tareas de preparación de los datos y construcción de características. En esta fa se se preparan los datos para ser distribuidos a la infraestructura de procesamiento. • Almacenamiento de datos: En esta fase los datos se distribuyen y almacenan de manera local (incluso in-memory ) en los diferentes nodos de la infraestructura de procesamiento para que estén disponibles para su procesado. Es lo que se denomina llevar el dato al proceso, a diferencia de los paradigmas clásicos do nde la aplicación iba a buscar al dato. • Análisis de datos: Es la última fase del proceso y consiste en aplicar los algoritmos y técnicas necesarios, algunos de ellos de minería de datos, para obtener los resultados esperados. Existen tecnologías y modelos de procesamiento espe cíficos para cada una de estas fases dependiendo de si se requiere procesamiento batch o en streaming . A continuación hacemos un repaso de algunas de las tecnologías en boga en cad a una de las fases dependiendo del tipo de procesamiento, así como de los paradigmas que hay t ras ellas. 5.2.1. Procesamiento en batch El procesamiento en batch es el que se realiza sobre grandes volúmenes de da tos, sin importar en exceso la latencia, pero asegurando la escalabilida d. Ello va a implicar mover grandes volúmenes de datos y distribuirlos entre diferentes nodos par a procesarlos de manera escalable. Por claridad de conceptos, presentaremos las tecnologías siguien do el orden almacenamiento, adquisición y análisis. 5.2.1.1. Fase de almacenamiento de datos Principalmente son dos las tecnologías utilizadas p ara almacenamiento de los datos en procesamiento batch: HDFS y HBase. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Francisco Manuel Rangel Pardo 42 TEMARIO OPOSICIONES COIICV | TEMA 36 HDFS o Hadoop Distributed File System es el sistema de ficheros proporcionado por Hadoop para distribuir los datos entre sus nodos de procesamien to. HDFS es una arquitectura master-slave, donde el maestro gestiona el acceso a la informació n, así como su estructura en directorios, y los esclavos contienen los datos. Por ello, al maestro se le conoce como el NameNode y a los esclavos los DataNodes. Como vimos en el apartado de almacenamiento, HBase es una base de datos NoSQL distribuida orientada a columnas. HBase proporciona acceso alea torio al dato en tiempo real tanto en lectura como en escritura. 5.2.1.2. Fase de adquisición de datos Como se verá en los siguientes apartados, Hadoop y su sistema de ficheros HDFS es uno de los más utilizados por diferentes tecnologías para alma cenar los datos de manera distribuida y acercarlos a los diferentes nodos de proceso. Así p ues, una de las primeras herramientas las proporciona el propio HDFS a modo de comandos que p ermiten distribuir desde un nodo local la información a los nodos remotos. hadoop dfs -copyFromLocal Ruta local suele ser un directorio en el sistema lo cal y la ruta remota un directorio en el sistema HDFS. Pero en ocasiones los datos se encuentran alm acenados en bases de datos SQL, y es Sqoop la tecnología que permite mover dichos datos entre las bases de datos relacionales (tiene conectores para la mayoría de ellas), y los sistema s de almacenamiento HDFS y HBase. Funciona a partir de comandos como los siguientes: import –connect [cadena de conexión a bbdd] –targ et-dir [ruta hdfs] [opciones] export –connect [cadena de conexión a bbdd] –targ et_dir [ruta hdfs] [opciones] Donde la primera mueve los datos de una base de dat os relacional al sistema HDFS y la segunda mueve los datos de HDFS a la base de datos relacion al. En opciones se indican la tabla o tablas que se desean exportar, así como las credenciales d el usuario. Una de las fuentes de información que más volumen g enera y que en ocasiones es preciso analizar son los logs de los procesos. Para ello, Flume proporciona herr amientas para mover datos de este tipo desde fuentes como Avro, Syslog, NetCa t o cualquier fuente personalizada hacia ficheros, memoria o bases de datos. 5.2.1.3. Fase de análisis de datos MapReduce es el paradigma y framework de procesamie nto distribuido de datos más extendido y conocido. Su filosofía se inspira en el clásico Div ide y Vencerás, para lo que descompone los datos de origen en diferentes subconjuntos (Map) para que los procesen los nodos, y el resultado se retorna para realizar una combinación de los result ados (Reduce). Concretamente: Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Gestión de los datos corporativos TEMARIO OPOSICIONES COIICV | TEMA 36 43 • Map: El proceso Map divide los datos en subconjunto s y los envía a cada nodo de proceso en formato clave-valor <K, V>. • Reduce: Cada nodo retorna el resultado en formato c lave-lista de valores <K, L(V)> y se combinan produciendo el resultado final. Un ejemplo clásico para entender MapReduce es el co nteo de palabras de un texto, que se adapta perfectamente a dicho paradigma. En el proceso Map, se enviará a cada nodo una línea del texto, donde la clave K será el número de línea, y el valo r V será la línea de texto <nºlínea, texto>. El resultado de la tarea será una lista de parejas <pa labra, 1> para cada palabra del texto. El pseudocódigo del proceso Map sería: Map (clave, valor) { Para cada palabra w en valor: retornar (palabra, 1) } El proceso Reduce recogerá todas las salidas de los procesos Map como parejas <clave, valor> o <palabra, 1>, y se encargará de agruparlas en parej as <palabra, ocurrencia> mediante la suma de unos de cada palabra. En pseudocódigo el proceso Re duce sería: Reduce (palabra, lista_de_valores) { Para cada valor v en lista_de_valores: total += v Retornar (palabra, total) } La potencia de MapReduce está en su filosofía Divid e y Vencerás, pero la primera vez que un programador se enfrenta a él, pese a su sencillez c onceptual, le resulta complejo. Es por ello que se han desarrollado tecnologías que proporcionan ca pacidades MapReduce pero con una capa de abstracción por encima. De entre ellas destacan Hiv e, Pig y Cascading: • Hive: No sólo es una capa de abstracción de MapRedu ce sino que además proporciona todo el sistema de almacén de datos completo junto con la posibilidad de ejecutar consultas sobre grandes volúmenes de datos. Hive pr oporciona una versión adaptada de SQL (HiveSQL) para acceder de manera similar a los datos. • Pig: Es una plataforma para analizar grandes volúme nes de datos a partir de una especificación de flujo de datos en lenguaje de alt o nivel (Data flow programming language). • Cascading: Es una plataforma que permite la creació n de flujos MapReduce complejos de manera sencilla mediante un planificador de proceso s de consulta. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Francisco Manuel Rangel Pardo 44 TEMARIO OPOSICIONES COIICV | TEMA 36 Aunque quizás el sistema de computación distribuida que está tomando un papel más relevante es Spark. Spark no es una versión de Hadoop, aunque es compatible con su sistema de ficheros HDFS y funciona de manera similar, permitiendo el d esarrollo de flujos MapReduce escritos en lenguajes Java, Python o Scala. Además de ser más s encillo que Hadoop, entre otras cosas por permitir utilizar su propio lenguaje Scala, o lengu ajes con los que el desarrollador esté familiarizad o como Python o Java, se argumenta que la ejecución e s más rápida que en Hadoop, quizás por mantener los datos en memoria. Esto sin embargo hac e que las necesidades de memoria sean superiores a su equivalente en Hadoop. Al igual que Hive, Spark proporciona un almacén de datos y una capa de abstracción denominada SparkQL que pe rmite acceder a los datos utilizando una variación del lenguaje de consulta SQL. 5.2.2. Procesamiento en streaming El procesamiento en streaming no tiene por qué invo lucrar grandes volúmenes de datos, pero sí una necesidad de consumirlos en tiempo real. 5.2.2.1. Fase de almacenamiento de datos Los almacenes de datos deben propiciar unos tiempos de respuesta y unas latencias bajas, no sólo al momento de consultar el dato, sino especial mente al momento de su inserción, puesto que pueden ser múltiples y desde muchos sitios diferent es. En este sentido, los almacenes de datos suelen actuar a modo de colas donde diferentes agen tes producen datos mientras que otra serie de agentes los consumen, creando así un flujo conti nuo de datos. En este sentido destaca la tecnología Kafka. Kafka es un sistema de colas dist ribuido que permite el trabajo en el modelo productor/consumidor. En este modelo, múltiples pro ductores de datos insertan en las colas los datos que múltiples consumidores recuperarán para e fectuar su procesamiento. Un ejemplo se puede ver en la parte superior de la Figura 6. En ella se muestran múltiples procesos de recuperac ión de datos del streaming API de Twitter (Twitter Stream y Process Local Stream ), que almacenan el resultado en disco local y lanz an trabajos a las colas de proceso ( Massive Queue , Real Time Queue y Specific Queue ). Múltiples procesos de análisis ( Process Remote Stream ) se encargan de recuperar el dato y efectuar su procesamiento, enviando el resultado a la siguiente etapa ( Indexer ), y de ahí a la siguiente (Neo4J ). Ejemplo del análisis realizado, extracción de se ntimiento, extractor de tópicos, de topónimos, de nombres propios ( NER ), construcción de redes y análisis de comunidades, influencia e intermediación ( SNA ), identificación de datos demográficos de los usua rios ( autor profiling ), y un largo etcétera. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Gestión de los datos corporativos TEMARIO OPOSICIONES COIICV | TEMA 36 45 Figura 6: Arquitectura Cosmos Intelligence de Autor itas. Fuente: Elaboración propia Otras tecnologías basadas en colas son Kestrel, Rab bitMQ o SQS de Amazon AWS. 5.2.2.2. Fase de adquisición de datos La adquisición de datos en tiempo real dependerá de l servicio o fuente de datos de la cual se dependa. Así por ejemplo, la mayoría de servicios d e red social actuales permiten recuperar información de su plataforma, aunque sólo algunos l o permiten en streaming . Un ejemplo de este tipo sería la Streaming API de Twitter, o incluso su Firehose . Para extraer datos en tiempo real se debe conectar un proceso directamente a dicha API y procesar toda la información que se genera. En este sentido, se pueden desarrollar pequeñas apl icaciones siguiendo las indicaciones de los manuales de las propias APIs. Sin embargo, de maner a más general, puede interesar la utilización de tecnologías de adquisición de datos, como pueda ser Flume. Flume es un servicio de recolección, agregación y transmisión de datos en t iempo real que permite conectarse a un flujo de datos, transformarlo y almacenarlo, por ejemplo, en un sistema de ficheros HDFS o en una cola Kafka. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Francisco Manuel Rangel Pardo 46 TEMARIO OPOSICIONES COIICV | TEMA 36 5.2.2.3. Fase de análisis de datos A la hora de analizar los datos que nos llegan en streaming , puede resultar interesante utilizar parte de la tecnología utilizada para capturarlos. Este es el caso de Flume, que además de permitir conectarse con diversas fuentes de datos y recupera r en tiempo real, permite conectar interceptores a los datos de entrada, a modo de eve ntos, que lancen la lógica de análisis implementada. Algo más avanzado lo proporciona Storm, que es un s istema de procesamiento en tiempo real escalable y distribuido. Storm permite realizar par a el real time lo que Hadoop permite en los procesos batch . Una de las ventajas de Storm es que permite utili zar cualquier lenguaje de programación, reduciendo el tiempo de aprendizaje, y además se integra con múltiples tecnologías de base de datos distribuidas y sistemas de encolad o. Storm se organiza mediante una topología en forma de grafo. Cada nodo contiene la lógica de aplicación. Existen nodos spout que se conectan a las fuentes de datos streaming y emiten los datos hacia la topología. Los nodos bolts son las unidades de procesamiento, que leen datos d e otros nodos y emiten datos hacia otros nodos. De este modo se puede construir la topología necesaria para aproximar el problema. Son diferentes las tecnologías que se han desarroll ado sobre Storm con el objetivo de abstraer su implementación y simplificar su uso. En este sentid o destaca Trident, que se basa en pequeños procesos batch que implementan operaciones de alto nivel como joins , filtros, proyecciones, agregaciones o diferentes tipos de funciones, y se enlazan para conseguir el flujo de proceso deseado. Sin embargo, su principal limitación es la necesidad de adaptarse a estas funciones, por lo que Storm es más potente. De nuevo Spark destaca por aportar su versión Spark Streaming, para procesamiento en tiempo real. Su funcionamiento es similar a Spark, con peq ueños batch que se concatenan para conseguir el flujo de procesamiento deseado, y que se almacen an en memoria para mejorar el rendimiento, a costa de una mayor necesidad de espacio. Existen otras tecnologías que proporcionan capacida des de análisis en streaming o tiempo real como son S4 (Simple Scalable Streaming System) util izado por Yahoo! o Samza, desarrollado por LinkedIn, que con una perfecta conexión con Kafka - -también utilizado por LinkedIn– permite una integración completa del proceso con la adquisición de datos vía Flume. 5.2.3. Procesamiento híbrido Aunque el procesamiento híbrido está en su infancia , cada vez más las necesidades se dirigen hacia esta línea. Así, una de las primeras arquitec turas definidas es la conocida como Lambda. Lambda es una arquitectura genérica para procesamie nto distribuido que sea escalable, tolerante a fallos y con una baja latencia. La siguiente imagen muestra la arquitectura Lambda: Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Gestión de los datos corporativos TEMARIO OPOSICIONES COIICV | TEMA 36 47 Figura 7: Arquitectura Lambda. Fuente: Lambda Archi tecture En ella se aprecia cómo todos los datos que llegan al sistema [1] se envían tanto a la capa batch [2] como a la capa speed [4]. La capa batch se encarga de almacenar los datos en bruto y de prepararlos para la visualización, mientras que la capa serving [3] se encarga de generar los índices para obtener baja latencia en las consultas . La capa speed reduce la latencia dando acceso únicamente a los datos más recientes. Cuando se produce una consulta por parte del usuario [5], esta se lanza a ambas capas, consiguié ndose una baja latencia por servir primero los datos más recientes de la capa speed , y posteriormente los ya procesados e indexados en la capa serving . Esta arquitectura es utilizada por el motor de bú squeda de Twitter. La arquitectura Kappa por su parte es una simplific ación de la Lambda en la cual se ha eliminado la capa batch . En Kappa los datos se envían directamente a travé s del sistema speed ( streaming ) a modo de un nuevo flujo de información en un regis tro inmutable de información que sólo se añade. Teniendo en consideración las arquitecturas anterio res, se han desarrollado tecnologías que permiten aprovechar las tecnologías existentes tant o para procesamiento batch como en streaming , y construir arquitecturas híbridas de proceso. Un a de las tecnologías que destaca es Lambdoop, que es una capa de abstracción de práctic amente todas las tecnologías vistas hasta ahora: Kafka, Flume, Hadoop, Spark/Spark Streaming y Storm, entre otras. Otra capa de abstracción sobre arquitectura Lambda es Sumingbird, utilizada por Twitter, que permite escribir procesos escritos en Scala en un f ormato similar a MapReduce, y ejecutarlos sobre Hadoop para procesos batch , sobre Storm para procesos stream , o sobre ambos de manera híbrida. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019Francisco Manuel Rangel Pardo 48 TEMARIO OPOSICIONES COIICV | TEMA 36 El proyecto Flink proporciona una implementación de la arquitectura Kappa que únicamente permite realizar procesamiento en streaming . El procesamiento batch se debe realizar como si de un proceso en streaming se tratara, simplificando de este modo la implemen tación. 5.2.4. Resumen de tecnologías Tabla VI: Resumen de tecnologías de procesamiento big data . Fuente: Elaboración propia ADQUISICIÓN ALMACENAMIENTO ANÁLISIS BATCH Comandos HDFS Sqoop Flume HDFS HBase MapReduce Spark, SparkQL Hive Pig Cascading STREAMING Flume Kafka Kestrel RabbitMQ AWS SQS Storm Trident Spark Streaming Samza HÍBRIDO Lambda, Kappa, Summingbird, Lambdoop, Apach e Flink Referencias (1) Aggargal, C. C. (2011). Social network data ana lytics. Springer. (2) Aguilar, F. (1967). Scanning the business envir onment. New York, Macmillan. (3) Alag, S. (2009). Collective intelligence in act ion. Manning Publications. (4) Arjonilla Domínguez, S. J., & Medina Garrido, J . A. (2002). La gestión de los sistemas de información en la empresa. Colección Economía y emp resa/Pirámide. (5) Banker, K. (2012). Mongodb in action. Manning P ublications. (6) Bradley, S.P., Hausman, J.A., Nolan, R.L. (1993 ). Globalization, technology and competition. The fusion of computers and telecommunications in t he 1990’s. Harvard Business School. (7) Chang, F., Dean, J., Ghemawat, S., Hsieh, W. C. , Wallach, D.A., Burrows, M., Chandra, T., Fikes, A., Gruber, R. E. (2008). Bigtable: a distri buted storage system for structured data. ACM Transactions on Computer Systems. Se autoriza el uso exclusivo de este documento a María Amparo Pavía García, DNI 20013968N, a 26 de julio de 2019