Archivo por meses: agosto 2016

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.

Cuándo empieza esta era del Big Data: MapReduce

8 comentarios

Comentábamos en un artículo anterior, que fue allá por 2012 cuando se empieza a popularizar el término Big Data en el acervo popular. Pero eso no quiere decir, que sea entonces cuando podamos decir que comienza esta era del Big Data. De hecho, los orígenes son bastante anteriores.

Dos ingenieros de Google, Jeffrey Dean y Sanjay Ghemawat, allá por 2004, publican un artículo titulado «MapReduce: Simplified Data Processing on Large Clusters«.

Dean Ghemawat

Hablan de un nuevo modelo de programación que permite simplificar el procesamiento de grandes volúmenes de datos. Lo bautizan como MapReduce. Básicamente es la evolución natural y necesaria que tenían dentro de Google para procesar los grandes volúmenes de datos que ya por aquel entonces manejaban (documentos, referencias web, páginas, etc.). Lo necesitaban, porque a partir de toda esa información, sacaban una serie de métricas que luego les ayudó a popularizar industrias como el SEO y SEM. Vamos, de lo que hoy en día vive Google (Alphabet) y lo que le ha permitido ser la empresa de mayor valor bursátil del mundo.

La idea que subyace a este nuevo modelo de programación es el siguiente: ante la necesidad de procesar grandes volúmenes de datos, se puede montra un esquema en paralelo de computación que permita así distribuir el trabajo (el procesamiento de datos) entre diferentes máquinas (nodos dentro de una red) para que se pueda reducir el tiempo total de procesamiento. Es decir, una versión moderna del «divide y vencerás«, que hace que ese trabajo menor en paralelo, reduzca sustantivamente lo que de otra manera sería un único, pero GRAN trabajo.

Distribución de trabajo a través del modelo MapReduce (Fuente: http://www.admin-magazine.com/HPC/Articles/MapReduce-and-Hadoop)
Distribución de trabajo a través del modelo MapReduce (Fuente: http://www.admin-magazine.com/HPC/Articles/MapReduce-and-Hadoop)

En aquel entonces, estos grandes «visionarios del Big Data» (luego volvemos a ello), se dieron cuenta que este problema que tenía Google en esos momentos, lo iban a tener otras cuantas aplicaciones. Así que decidieron desarrollar un modelo de programación que se desacoplara de las necesidades concretas de Google, y se pudiera generalizar a un conjunto de aplicaciones que pudieran luego reutilizarlo. Pensaron en un inicio a todos los problemas que pudiera tener el propio buscador. Pero se dan cuenta que quizás todavía hay un universo más amplio de problemas, por lo que se abtsrae y generaliza aún más.

De hecho, lo simplificaron tanto que dejaron la preocupación del programador en dos funciones:

  • Map: transforma un conjunto de datos de partida en pares (clave, valor) a otro conjunto de datos intermedios también en pares (clave, valor). Un formato, que hará más eficiente su procesamiento y sobre todo, más fácil su «reconstruccón» futura.
  • Reduce: recibe los valores intermedios procesados en formato de pares (clave, valor) para agruparlos y producir el resultado final.

Este paradigma lo adoptó Google allá por 2004. Y dado el rendimiento que tenía, se comenzó a emplear en otras aplicaciones (como decíamos ahora). Se comienzan luego a desarrollar versiones de código abierto en frameworks. Esto hace muy fácil su rápida adopción, y quizás deja una lección para la historia sobre cómo desarrollar rápidamente un paradigma.

Uno de los frameworks que comienza a ganar en popularidad es Apache Hadoop. Y, para muchos, aquí nace esta era del «Big Data». El creador del framework Hadoop se llama «Doug» Cutting, una persona con una visión espectacular. En cuanto leyó la publicación de Dean y Ghemawat se dio cuenta que si crease una herramienta bajo el paradigma MapReduce, ayudaría a muchos a procesar grandes cantidades de datos. Cutting acabó luego trabajando en Yahoo!, que es donde realmente empujó el proyecto Hadoop (qué vueltas da la vida…).

El ecosistema Hadoop consta de una serie de módulos como los que se pueden encontrar en la imagen debajo de estas líneas. Pero en su día, fueron dos sus principales componentes, y los que dan otro nuevo empuje a esta era del Big Data:

  • HDFS: una implementación open-source de un sistema distribuido de ficheros (que ya había descrito Google en realidad).
  • MapReduce: utilizando HDFS como soporte, la implementación del modelo de programación que hemos descrito al comienzo.
Ecosistema Apache Hadoop (Fuente: https://opensource.com/sites/default/files/resize/styles/image-full-size/public/images/life-uploads/hadoop-EcoSys_yarn-640x418.PNG)
Ecosistema Apache Hadoop (Fuente: https://opensource.com/sites/default/files/resize/styles/image-full-size/public/images/life-uploads/hadoop-EcoSys_yarn-640×418.PNG)

La historia sobre el origen y verdadero impulso a esta era del «Big Data», puede cerrarse con la salida de Yahoo! de Cutting en 2009. Se incorpora a Cloudera, empresa que comienza a dar servicio, soporte y formación de Hadoop a otras empresas. Para esa fecha, Hadoop ya era un ecosistema de módulos y aplicaciones, que merecen cada una un hilo aparte para entender las grandes aportaciones que hicieron las personas que hemos comentado en este artículo. Por cierto, mucha de esta historia la cuenta el propio Cutting en este hilo de Quora.

En definitiva, primero MapReduce, y luego el framework Hadoop, pueden ser considerados como el origen de esta era Big Data de la que tanto hablamos hoy en día. Y, las empresas de Internet (Google, Yahoo, hablaremos luego de Twitter, Facebook, Linkedin, etc.), las que propician la aparición de tecnologías de Big Data que luego son llevadas a otros sectores.

El abuso de la palabra «Big Data»

1 comentario

Es innegable que la palabra «Big Data» lleva ya tiempo con nosotros y está de moda. Su uso no ha parado de crecer desde mediados de 2012, que es cuando aparecen varios artículos que comienzan a popularizar el paradigma.

 

Es tanto su uso, que ha dado un salto desde los foros más tecnológicos a los más populares. Son varios periódicos generalistas que se atreven a encabezar sus noticias con titulares como éstos:

Fuente: http://economia.elpais.com/economia/2016/06/30/actualidad/1467300223_055396.html
Fuente: http://economia.elpais.com/economia/2016/06/30/actualidad/1467300223_055396.html
Fuente: http://www.elmundo.es/economia/2016/06/07/57569c8722601d712e8b45ab.html
Fuente: http://www.elmundo.es/economia/2016/06/07/57569c8722601d712e8b45ab.html
Fuente: http://www.expansion.com/juridico/actualidad-tendencias/2016/06/05/5751c298268e3ea50d8b4660.html
Fuente: http://www.expansion.com/juridico/actualidad-tendencias/2016/06/05/5751c298268e3ea50d8b4660.html

Este tipo de titulares, ha provocado que ahora todo el mundo diga que «hace Big Data» o que todos los problemas de una empresa «se arreglen haciendo Big Data«. Ojo, no con esto se debe quitar valor a lo que hacen. Lo que ocurre, es que quizás no estén poniendo en valor el paradigma del Big Data. Sino que puede que estén haciendo un proyecto de Data Mining o Minería de datos de toda la vida. Pero de eso, no se habla en las noticias. En la siguiente gráfica de Google Trends podéis ver cómo para la categoría de «Noticias», últimamente se cita mucho «Big Data», pero bastante menos «Data Mining» o «Minería de Datos».

Creo que debiéramos empezar a ser un poco más rigurosos en su uso. Es decir, debiéramos empezar a preguntarnos si es «Big Data» todo lo que decimos que lo es. Y es que sino a este paso, ocurrirá como ya pasó con términos como «calidad» o «innovación«, que de tanto uso, ahora la gente se muestra reacia al valor que aportan disponer de importantes equipos de calidad e innovación.

Y es que el uso de los métodos de análisis de datos para la mejora de la competitividad y el día a día de las organizaciones no es nada nuevo. Hace décadas que llevamos haciendo uso de estas técnicas. Quizás no en todos los sectores (lo que ahora sí podemos decir está ocurriendo). Pero en el sector financiero o asegurador, llevan décadas empleando técnicas de minería de datos para sacar valor de sus grandes volúmenes de datos. Lo han empleado siempre para la detección de fraudes, perfiles de propensión al impago o para el scoring en la concesión de créditos.

Sí que es cierto que estos métodos, ahora son más sofisticados. Pero eso realmente no se debe a la evolución de los algoritmos solo, sino a la existencia de una mayor cantidad de datos, de muy diferentes fuentes, almacenados en muy diferentes formatos y sobre todo, generados a gran velocidad. Y esto último sí que hace distinguir un proyecto de Big Data de otro que no lo es.

Lo que ocurre en un momento determinado en el tiempo es que se empieza a popularizar el término «Big Data» cuando otro tipo de empresas no financieras ni aseguradoras, especialmente las grandes tecnológicas, comienzan a aplicar esas técnicas de minería de datos. Pero se dan cuenta que muchas de las técnicas que se venían empleando no son válidas. Básicamente por:

  • El gran volumen de datos que disponen
  • La gran variedad de formatos de datos
  • La velocidad a la que generan nuevos datos

Sí, estamos hablando de las famosas 3 «V» que se concibieron inicialmente, que son las 3 (por mucho que ahora haya una burbuja de «V») que creo siguen caracterizando y definiendo mejor a este paradigma del «Big Data». Volumen, Variedad y Velocidad. Y son estas 3 «V», las que hace que nos demos cuenta que lo que veníamos haciendo hasta la fecha no es válido. Se necesitan nuevas tecnologías. Y se desarrollan varias nuevas tecnologías que hacen más fácil tan ardua labor, especialmente el modelo MapReduce y los sistemas de ficheros distribuidos. Y, el trabajo que anteriormente era imposible o muy difícil hacerlo, ahora se hace posible gracias a un conjunto de máquinas (clústers) que se distribuyen el trabajo, y que en agregado, superan a cada máquina que anteriormente existía.

Por todo ello, creo que es compartido por todos afirmar que no todas las empresas que hagan uso de técnicas de minería de datos están haciendo uso del Big Data. Como paradigma que es, existen una seria de condicionantes del problema que lo hacen singular y diferente.  Y por ello, es importante dejar claro que, por favor, no usemos el término allí donde no aplique. Y aplica, en aquellos contextos que se rigen por ese paradigma de las 3 «V» que caracterizan muy bien los retos que tienen muchas empresas por delante.