Archivo de la etiqueta: apache

Paradigma tiempo real para sistemas Big Data (II)

1 comentario

(venimos de una serie de un artículo introductorio a los tres paradigmas, y de uno anterior hablando del paradigma batch)

Decíamos en el artículo anterior, que a la hora de procesar grandes volúmenes de datos existen dos principales enfoques: procesar una gran cantidad de datos por lotes o bien hacerlo, en pequeños fragmentos, y en «tiempo real». Parece, así, bastante intuitivo pensar cuál es la idea del paradigma en tiempo real que trataremos en este artículo.

Este enfoque de procesamiento y análisis de datos se asienta sobre la idea de implementar un modelo de flujo de datos en el que los datos fluyen constantemente a través de una serie de componentes que integran el sistema de Big Data que se esté implatando. Por ello, se le como como procesamiento «streaming» o de flujo. Así, en tiempos muy pequeños, procesamos de manera analítica parte de la totalidad de los datos. Y, con estas características, se superan muchas de las limitaciones del modelo batch.

Por estas características, es importante que no entendamos este paradigma como la solución para analizar un conjunto de grandes datos. Por ello, no presentan esa capacidad, salvo excepciones. Por otro lado, una cosa es denominarlo «tiempo real» y otra es realmente pensar que esto se va a producir en veradero tiempo tiempo. Las limitaciones aparecen por:

  • Se debe disponer de suficiente memoria  para almacenar entradas de datos en cola. Fíjense en la diferencia con el paradigma batch, donde los procesos de Map y Reduce podrían ser algo lentos, dado que escribían en disco entre las  diferentes fases.
  • La tasa de productividad del sistema debería ser igual o más rápida a la tasa de entrada de datos. Es decir, que la capacidad de procesamiento del sistema sea más ágil y eficiente que la propia ingesta de datos. Esto, de nuevo, limita bastante la capacidad de dotar de «instantaneidad al sistema».
Plataforma de analítica Big Data en tiempo real (Fuente: https://infocus.emc.com/wp-content/uploads/sites/8/2013/02/Real-time-Analytic-Platforms-Enable-New-Value-Creation-Opportunities.png)
Plataforma de analítica Big Data en tiempo real (Fuente: https://infocus.emc.com/wp-content/uploads/sites/8/2013/02/Real-time-Analytic-Platforms-Enable-New-Value-Creation-Opportunities.png)

Uno de los principales objetivos de esta nueva arquitectura es desacoplar el uso que se hacía de Hadoop MapReduce para dar cabida a otros modelos de computación en paralelo como pueden ser:

  • MPI (Message Passing Interface): estándar empleado en la programación concurrente para la sincronización de procesos ante la existencia de múltiples procesadores.
  • Spark: plataforma desarrollada en Scala para el análisis avanzado y eficiente frente a las limitaciones de Hadoop. Tiene la habilidad de mantener todo en memoria, lo que le da ratios de hasta 100 veces mayor rapidez frente a MapReduce. Tiene un framework integrado para implementar análisis avanzados. Tanto Cloudera, como Hortonworks, lo utilizan.

Y, con estos nuevos modelos, como hemos visto a lo largo de esta corta pero intensa historia del Big Data, aparecen una serie de tecnologías y herramientas que permiten implementar y dar sentido a todo este funcionamiento:

  • Flume: herramienta para la ingesta de datos en entornos de tiempo real. Tiene tres componentes principales: Source (fuente de datos), Channel (el canal por el que se tratarán los datos) y Sink (persistencia de los datos). Para entornos de exigencias en términos de velocidad de respuesta, es una muy buena alternativa a herramientas ETL tradicionales.
Flume (Fuente: http://blog.cloudera.com/wp-content/uploads/sites/8/2012/10/fig.png)
Flume (Fuente: http://blog.cloudera.com/wp-content/uploads/sites/8/2012/10/fig.png)
  • Kafka: sistema de almacenamiento distribuido y replicado. Muy rápido y ágil en lecturas y escrituras. Funciona como un servicio de mensajería y fue creado por Linkedin para responder a sus necesidades (por eso insisto tanto en que nunca estaríamos hablando de «Big Data» sin las herramientas que Internet y sus grandes plataformas ha traído). Unifica procesamiento OFF y ON, por lo que suma las ventajas de ambos sistemas (batch y real time). Funciona como si fuera un cluster.
Apache Kafka (Fuente: https://unpocodejava.files.wordpress.com/2012/12/image0019.jpg?w=780)
Apache Kafka (Fuente: https://unpocodejava.files.wordpress.com/2012/12/image0019.jpg?w=780)
  • Storm:  sistema de computación distribuido, por lo que se emplea en la etapa de análisis de datos (de la cadena de valor de un proyecto de Big Data). Se define como un sistema de procesamiento de eventos complejos (Complex Event Processing, CEP), lo que le hace ideal para responder a sistemas en los que los datos llegan de manera repentina pero continua. Por ejemplo, en herramientas tan habituales para nosotros como WhatsApp, Facebook o Twitter, así como herramientas como sensores (ante la ocurrencia de un evento) o un servicio financiero que podamos ejecutar en cualquier momento.

Vistas estas tres tecnologías, queda claro que la arquitectura resultante de un proyecto de tiempo real quedaría compuesto por Flume (ingesta de datos de diversas fuentes) –> Kafka (encolamos y almacenamos) –> Storm (analizamos).

Fuente: http://www.slideshare.net/Datadopter/the-three-generations-of-big-data-processing
Fuente: http://www.slideshare.net/Datadopter/the-three-generations-of-big-data-processing

Vistas todas estas características, podemos concluir que para proyectos donde el «tamaño» sea el *verdadero* problema, el enfoque Batch será el bueno. Cuando el «problema» sea la velocidad, el enfoque en tiempo real, es la solución a adoptar.

(continuará)

Paradigma batch para sistemas Big Data (I)

1 comentario

(venimos de un artículo introductorio a los tres paradigmas)

Cuando hablamos del verdadero momento en el que podemos considerar nace esta «era del Big Data», comentamos que se puede considerar el desarrollo de MapReduce y Hadoop como las primeras «tecnologías Big Data». Estas tecnologías se centraban en un enfoque de Batch Processing. Es decir, el objetivo era acumular todos los datos que se pudieran, procesarlos y producir resultados que se «empaquetaban» por lotes.

Con este enfoque, Hadoop ha sido la herramienta más empleada. Es una herramienta realmente buena para almacenar enormes cantidades de datos y luego poder escalarlos horizontalmente mientras vamos añadiendo nodos en nuestro clúster de máquinas.

Big Data Batch Processing (Fuente: http://www.datasciencecentral.com/profiles/blogs/batch-vs-real-time-data-processing)
Big Data Batch Processing (Fuente: http://www.datasciencecentral.com/profiles/blogs/batch-vs-real-time-data-processing)

Como se puede apreciar en la imagen, el «problema» que aparece en este enfoque es que el retraso en tiempo que introduce disponer de un ETL que carga los datos para su procesamiento, no será tan ágil como hacerlo de manera continua con un enfoque de tiempo real. El procesamiento en trabajos batch de Hadoop MapReduce es el que domina en este enfoque. Y lo hace, apoyándose en todo momento de un ETL, de los que ya hablamos en este blog.

Hasta la fecha la gran mayoría de las organizaciones han empleado este paradigma «Batch». No era necesaria mayor sofisticación. Sin embargo, como ya comentamos anteriormente, existen exigencias mayores. Los datos, en muchas ocasiones, deben ser procesados en tiempo real, permitiendo así a la organización tomar decisiones inmediatamente. Esas organizaciones en las que la diferencia entre segundos y minutos sí es crítica.

Hadoop, en los últimos tiempos, es consciente de «esta economía de tiempo real» en la que nos hemos instalado. Por ello, ha mejorado bastante su capacidad de gestión. Sin embargo, todavía es considerado por muchos una solución demasiado rígida para algunas funciones. Por ello, hoy en día, «solo» es considerado el ideal en casos como:

  • No necesita un cálculo con una periodicidad alta (una vez al día, una vez al de X horas, etc.)
  • Cálculos que se deban ejecutar solo a final de mes (facturas de una gran organización, asientos contables, arqueos de caja, etc.)
  • Generación de informes con una periodicidad baja.
  • etc.

Como el tema no es tan sencillo como en un artículo de este tipo podamos describir, en los últimos años han nacido una serie de herramientas y tecnologías alrededor de Hadoop para ayudar en esa tarea de analizar grandes cantidades de datos. Para analizar las mismas -a pesar de que cada una de ellas da para un artículo por sí sola-, lo descomponemos en las cuatro etapas de la cadena de valor de un proyecto de Big Data:

1) Ingesta de datos

Destacan tecnologías como:

  • Flume: recolectar, agregar y mover grandes cantidades de datos desde diferentes fuentes a un data store centralizado.
  • Comandos HDFS: utilizar los comandos propios de HDFS para trabajar con los datos gestionados en el ecosistema de Hadoop.
  • Sqoop: permitir la transferencia de información entre Hadoop y los grandes almacenes de datos estructurados (MySQL, PostgreSQL, Oracle, SQL Server, DB2, etc.)

2) Procesamiento de datos 

Destacan tecnologías como:

  • MapReduce: del que ya hablamos, así que no me extiendo.
  • Hive: framework creado originalmente por Facebook para trabajar con el sistemas de ficheros distribuidos de Hadoop (HDFS). El objetivo no era otro que facilitar el trabajo, dado que a través de sus querys SQL (HiveQL) podemos lanzar consultas que luego se traducen a trabajos MapReduce. Dado que trabajar con este último resultaba laborioso, surgió como una forma de facilitar dicha labor.
  • Pig: herramienta que facilta el análisis de grandes volúmenes de datos a través de un lenguaje de alto nivel. Su estructura permite la paralelización, que hace aún más eficiente el procesamiento de volúmenes de datos, así como la infraestructura necesaria para ello.
  • Cascading: crear y ejecutar flujos de trabajo de procesamiento de datos en clústeres Hadoop usando cualquier lenguaje basado en JVM (la máquina virtual de Java). De nuevo, el objetivo es quitar la complejidad de trabajar con MapReduce y sus trabajos. Es muy empleado en entornos complejos como la bioinformática, algoritmos de Machine Learning, análisis predictivo, Web Mining y herramientas ETL.
  • Spark: facilita enormemente el desarrollo de programas de uso masivo de datos. Creado en la Universidad de Berkeley, ha sido considerado el primer software de código abierto que hace la programación distribuida accesible y más fácil para «más públicos» que los muy especializados. De nuevo, aporta facilidad frente a MapReduce.

3) Almacenamiento de datos

Destacan tecnologías como:

  • HDFS: sistema de archivos de un cluster Hadoop que funciona de manera más eficiente con un número reducido de archivos de datos de gran volumen, que con una cantidad superior de archivos de datos más pequeños.
  • HBase: permite manejar todos los datos y tenerlos distribuidos a través de lo que denominan regiones, una partición tipo Nodo de Hadoop que se guarda en un servidor. La región aleatoria en la que se guardan los datos de una tabla es decidida, dándole un tamaño fijo a partir del cual la tabla debe distribuirse a través de las regiones. Aporta, así, eficiencia en el trabajo de almacenamiento de datos.

4) Servicio de datos

En esta última etapa, en realidad, no es que destaque una tecnología o herramienta, sino que destacaría el «para qué» se ha hecho todo lo anterior. Es decir, qué podemos ofrecer/servir una vez que los datos han sido procesados y puestos a disposición del proyecto de Big Data.

Seguiremos esta serie hablando del enfoque de «tiempo real», y haciendo una comparación con los resultados que ofrece este paradigma «batch».

Procesando «Big Data»: paradigmas batch, tiempo real y Lambda

15 comentarios

Lo que podemos llamar como la cadena de valor de un proyecto Big Data consiste básicamente en recopilar/integrar/ingestar, procesar, almacenar y servir grandes volúmenes de datos. Eso es, en esencia, lo que hacemos en un proyecto de BIg Data. Para ejecutar esas funciones, como hemos comentado en este blog en varias ocasiones, tenemos una serie de tecnologías, que suelen ser citadas en ocasiones en relación a la función que ejercen. Es lo que aprendemos en nuestro módulo M2.2 del Programa de Big Data y Business Intelligence de nuestra universidad.

Dado el interés que está despertando en los últimos años la parte «procesamiento» (debido fundamentalmente a cómo se origina esto del Big Data) es interesante hablar de las diferentes alternativas tecnológicas que existen para procesar «Big Data». Ya saben, datos que se disponen en grandes volúmenes, que se generan a gran velocidad y con una amplitud de formatos importante.

Esta etapa de la cadena de valor es la responsable de recoger los datos brutos y convertirlos/transformarlos a datos enriquecidos que pueden dar respuesta a la pregunta que nos estamos haciendo. Y para enfrentar esta etapa, en los últimos años, se han desarrollado dos paradigmas fundamentales:

  • Paradigma «Batch Processing«: son procesos que se asientan fundamentalmente en el paradigma MapReduce, que ya explicamos en un artículo anterior, y que decíamos, permitió comenzar esta apasionante carrera alrededor del Big Data. Siguen el modelo «batch» que tan importante resultó en el mundo de la informática original: se ejecutan de manera periódica y trabajan con grandísimos volúmenes de datos.
    Existen varias alternativas para proveer de estos servicios: la más importante es Hadoop MapReduce, que funciona dentro del framework de aplicaciones de Hadoop. Se apoya en el planificador YARN. Dado el bajo nivel con el que trabajan estas tecnologías, estos últimos años han nacido soluciones de más alto nivel para ejecutar estas tareas, tales como Apache Pig.
    Estamos hablando de tecnologías que funcionan realmente bien con grandes cantidades de datos. Sin embargo, los procesos de Map y Reduce pueden ser algo lentos cuando estamos hablando de cantidades realmente «BIG», dado que escriben en disco entre las diferentes fases. Por ello, como siempre, se produce una evolución natural, y aparecen tecnologías que resuelven este problema, entre las que destaca Apache Spark.
    Haremos un artículo separado, dada su importancia, para hablar exclusivamente y en detalle de este paradigma «Batch Processing«.
  • Paradigma «Streaming Processing«: a diferencia del enfoque «batch» anterior, el «streaming», como su propio concepto describe, funciona en tiempo real. Si antes decíamos que un proyecto «Big Data» consta de cuatro etapas –(1) Ingestión; (2) Procesamiento; (3) Almacenamiento y (4) Servicio-, con este enfoque, nada más ser «ingestados», son transferidos a su procesamiento. Esto, además, se hace de manera continua. En lugar de tener que procesar «grandes cantidades», son, en todo momento, procesadas «pequeñas cantidades».
    Como con el enfoque batch, hay una serie de tecnologías que permiten hacer esto. Se pueden clasificar en dos familias: 1) Full-streaming: Apache Storm, Apache Samza y Apache Flink; y 2) Microbatch: Spark Streaming y Storm Trident.
    Son tecnologías que procesan datos en cuestión de mili o nanosegundos. Se diferencian entre ellas por las garantías que aportan ante fallos en la red o en los sistemas de información. La siguiente tabla resume muy bien estas diferencias. Por lo tanto, más que por «gustos», la diferencia puede radicar en cuanto a su «sistema de garantías»:

    Fuente: http://madrid.bigdataweek.com/2015/11/18/tecnologias-en-el-mundo-del-big-data/
    Fuente: http://madrid.bigdataweek.com/2015/11/18/tecnologias-en-el-mundo-del-big-data/

    Haremos un artículo separado, dada su importancia, para hablar exclusivamente y en detalle de este paradigma «Streaming Processing«.

A estos dos, podemos añadir la arquitectura Lambda, la más reciente en llegar a este mundo de necesidades en evolución de las diferentes alternativas de procesar datos. Provee parte de solución Batch y parte de solución en Tiempo Real. Como su propio creador Nathan Marz explica aquí:

The lambda architecture solves the problem of computing arbitrary functions on arbitrary data in real time by decomposing the problem into three layers: the batch layer, the serving layer, and the speed layer.

Estamos hablando de diferentes paradigmas; esto es, de diferentes maneras de afrontar el problema. Y dada la importancia de cada uno de ellos, he considerado interesante hacer un artículo monográfico de cada una de ellas. Paradigmas que nos van a ayudar a procesar las grandes cantidades de datos de un proyecto de Big Data. Y conocer y empezar a dominar así las tecnologías que disponemos para cada paradigma.

El Big Data en los Papeles de Panamá

4 comentarios

No creo que a estas alturas, a usted, estimado lector de cualquier parte del mundo del que lea esto, le tenga que contar nada sobre los «Papeles de Panamá». Unos documentos filtrados, en el que se dice la mayor filtración periodística de toda la historia. En el contenido de los mismos se puede encontrar a personas de todo el mundo aprovechando los paraísos fiscales para ocultar su dinero en el pago de impuestos. Nada que la ética no pueda explicar por si sola les voy a contar.

Pero de lo que se ha hablado menos es de cómo se produce. Como quizás también sepan, todo se produce a partir de la extracción de unos documentos de dos sitios web de la empresa Mossack Fonseca: la web que sirve como descripción de sus servicios -un WordPress- y un portal interno de clientes donde se podía compartir información sensible de todos ellos -un Drupal-. Uno, lo primero que podría pensar s que entonces la «culpa» es de la falta de seguridad tecnológica. Y efectivamente, al parecer, la falta de actualización del portal interno y un plugin de WordPress habrían expuesto toda esa documentación.

Pero, una vez obtenidos los documentos, hay que analizarlos para extraer inteligencia de los mismos. Vamos, un proyecto de Big Data, en definitiva, porque la cantidad documental de la que estamos hablando es realmente grande (2.6 terabytes, y 11,5 millones de documentos -Wikileaks, para que se hagan a la idea, fueron 1,7 GB «solo»-). El Big Data en los Papeles de Panamá ha jugado un papel nuclear.

La escala de los
La escala de los «Papeles de Panamá» (Fuente: http://www.alternet.org/files/screen_shot_2016-04-04_at_12.01.06_pm.png)

Lo interesante del caso para la temática de este blog es la parte que viene después de la obtención de la «puerta de entrada a los datos». Un proyecto de Big Data, literal:

  • Fuentes de datos: la heterogeneidad -una de las famosas 5 Vs- de las fuentes de datos es muy importante: cinco millones de emails, tres millones de ficheros de bases de datos, dos millones de PDFs, un millón de imágenes, más de 320.000 documentos de texto y 2.242 archivos de otro tipo no clasificados. Un reto de extracción de las fuentes de datos importante.
  • Integración de datos: para poder procesar esta heterogeneidad de las fuentes de datos, es preciso integrar todos estos datos en un mismo modelo de datos. Y claro, mientras hay documentos medianamente sencillos para ello (las bases de datos o los documentos de texto e emails por ejemplo -gracias a tecnologías de procesamiento de lenguaje natural-), tenemos también grandes retos como los PDF y las imágenes: deben primero pasarse a un formato de caracteres para luego poder disponerse para su explotación. Ya hablamos en este blog de la aportacióin de las herramientas ETL en ello.
  • Gestión de la calidad de los datos: hay que tener en cuenta que como «filtración» que es, los datos, obviamente, no están preparados para su explotación. Entre el mar de datos, muchos son totalmente irrelevantes y no hacen más que aportar una mala calidad a los datos de entrada. Esto, ya dijimos, era crítico de solucionar ex-ante.
  • Procesamiento de los datos para la extracción de inteligencia: una vez que los datos están preparados, se deben procesar, en este caso, buscando relaciones entre entidades y acciones. Para ello, estructurar anteriormente la información de una manera que permita navegar entre la información de manera ágil y eficiente, resulta clave. Y por ello, se procesó la información estructurada en grafas, que además de tener un buen rendimiento, permite extraer mucha inteligencia. Ya hablamos de ello.
  • Visualización de datos, obtención de inteligencia: la visualización analítica, eficiente e inteligente de datos es la que permite sacar conclusiones y tomar decisiones de manera ágil.  También lo comentamos. Para ello, es preciso visualizar los datos de una manera apropiada para obtener inteligencia de los mismos.
  • Y por debajo de todas estas etapas, una infraestructura tecnológica realmente potente: para poder hacerlo a una velocidad medianamente razonable se emplearon hasta 30 servidores en paralelo. Y, sobre estos servidores, mucho software de «Big Data», tal y como detalló Mar Cabra -responsable del área de Investigación y Datos del consorcio de periodistas ICIJ, que estaba a la cabeza de esta investigación. Incluye una lista de Software Libre y también propietario, que cedieron licencias por la causa, que ha sido adaptado por el propio consorcio para sus labores de Investigación.
    • Neo4j, tecnología que vemos en nuestro Programa de Big Data y Business Intelligence, fue la base datos de nueva generación (ya hablé de ella en otro artículo), donde se almacenaron las relaciones y coincidencias entre los documentos. Esta tecología, como ya expliqué, permite modelar la información a partir de conexiones entre entidades,  lo cual facilita mucho poder luego estudiar estos flujos de datos para detectar e inferir conocimiento. Aquí lo describe la propia empresa.
    • Nuix, un software de gestión documental, que permite indexar y categorizar información rápida y ágilmente. Aquí la noticia de ellos mismos hablando sobre el caso.
    • Con Apache Solr y Apache Tika, se puso a disposición de la búsqueda y recuperación la información contenida en los documentos de manera centralizada. Es la parte más relacionada con la integración de datos. Aquí explicado.
    • Linkurious,  la herramienta para trazar y visualizar los vínculos de la documentación obtenida por temas y sujetos de investigación. Aquí lo describen ellos mismos.

Obviamente, como solemos decir, la tecnología, por muy buena que sea, no descubre por sí sola. Por un lado, alguien debe hacerle las preguntas más acertadas, y en segundo lugar, alguien tiene que entender los resultados que nos devuelve. Ahí está la formidable labor realizada por los periodistas. Sin conocer el contexto bien, es difícil hacer un proyecto de Big Data de este calibre. Por ello, el futuro del periodismo con un importante soporte en datos y tecnologías que le permita acelerar su proceso de investigación se me antoja cada vez más cercano.

El «Big Data», como paradigma habilitante que es, permite cambiar las reglas de juego de diferentes sectores de actividad. En este caso, hemos visto cómo ayudó al caso de los «Papeles de Panamá». Y es que este método de trabajo que hemos visto (extracción, integración, depuración, procesamiento y visualización), con el apoyo de las mejores tecnologías para ello, ha venido para quedarse. El Big Data en los papeles de Panamá ha sido un paradigma muy habilitante.