El 7 de mayo de 2020, Ibon Bolaños nos contó como Hadoop no es un ecosistema cerrado y que son muchas las herramientas que pueden interactuar con el. Se hizo una breve exposición de como Hadoop se está quedando atrás en detrimento de Spark. Y por último, se dieron unas pinceladas de en qué momento puede ser interesante plantearse ir a la nube
Archivo de la etiqueta: hadoop
Big Data: la posición más difícil de cubrir en España
El pasado 7 de marzo, Cinco Días, publicaba esta noticia: «Big data, el perfil más difícil de cubrir en España«. Según el artículo y sus fuentes, las profesiones asociadas con las tecnologías de Big Data son las más difíciles de cubrir. Su fuente principal es el informe EPYCE 2017: Posiciones y Competencias más demandadas, elaborado por EAE Business School junto con la Asociación Española de Directores de Recursos Humanos (AEDRH), la CEOE, el Foro Inserta de la Fundación Once y Human Age Institute.
En un blog como éste, donde hablamos tanto del paradigma del Big Data y sus múltiples implicaciones en nuestras sociedades, naturalmente, no podíamos dejar sin sacar esta noticia. Llevamos años ya formando perfiles de Big Data en nuestros Programas de Big Data en Bilbao, Donostia y Madrid.
El informe original contiene aún más información. Aspecto que recomiendo revisar, para que se entienda bien no solo la metodología, sino los contenidos (datos) analizados. Miren por ejemplo esta gráfico que adjunto:
Con un nivel de detalle mayor, lo que vemos es que no solo la parte tecnológica (que siempre está en el top de los ranking de bajo desempleo), sino también la ciencia de datos (que son nuestras dos patas fundamentales en nuestros programas), son las más demandadas. En general, hay numerosas profesiones técnicas demandadas en todo el ranking y el informe. Lo cual nos viene a confirmar que efectivamente estamos viviendo una transformación tecnológica y digital en múltiples planos.
Lo que parece que viene a confirmar este informe es que estamos viviendo cierta brecha entre los perfiles que demandan las empresas y lo que realmente se dispone luego en el mercado de trabajo. Parece real esa velocidad a la que se está efectuando esta transformación digital de la sociedad, que está provocando que muchos perfiles no puedan seguirla, y no les dé tiempo a actualizar sus competencias y habilidades. El Big Data, la revolución de los datos, parece que ha venido para quedarse.
No obstante, en relación a todo esto, creo que cabría introducir tres elementos de reflexión. A buen seguro, a cualquier lector o lectora de estas estadísticas, le interesará conocer qué hay más allá de estas gráficas. Básicamente, porque la gestión de expectativas laborales en los programas formativos, creo que debe caracterizarse por la honestidad, para que luego no produzca frustraciones. Estos tres puntos son: (1) Descripción de «supermanes» y «superwomanes» en los puestos de trabajo de las empresas; (2) el concepto «experiencia» en las organizaciones; (3) el talento cuesta dinero.
En relación al (1), darse una vuelta por Linkedin suele ser muy ilustrativo a estos efectos. Las empresas, cuando buscan perfiles «de Big Data» (así en genérico y abstracto), suelen hacerlo solicitando muchas habilidades y competencias que me parece difícil que lo cubra una misma persona: conocimientos de programación (R, Python, Java, etc.), conocimiento de los frameworks de procesamiento de grandes volúmenes de datos y sus componentes (Spark y Hadoop, y ya de paso Storm, Hive, Sqoop, etc.), que sepa administrar un clúster Hadoop, que sepa cómo diseñar una arquitectura de Big Data eficiente y óptima, etc. Una persona que en definitiva, dé soporte a todo el proceso de un proyecto de Big Data, desde el inicio hasta el final. Este enfoque es bastante complicado de cubrir: para una persona manejar todo eso es realmente complicado, dado que no solo los códigos de pensamiento, sino también las habilidades, no suelen estar relacionadas.
En cuanto al (2), que se pida para estos puestos experiencia, me parece un poco temeroso. Estamos hablando de un paradigma que irrumpe con fuerza en 2013. Por lo que estar pidiendo experiencias de más de 2-3-4 años, es literalmente imposible de cubrir. Y menos en España donde todavía no hay tantas realidades en proyectos de Big Data como se cree. ¿Quizás la falta de cobertura de vacantes tenga que ver precisamente con esta situación? Por ello sería bueno saber realmente qué es lo que no están encontrando: ¿el puesto necesario? ¿el puesto definido por las empresas? ¿las expectativas mal gestionadas? Quizás sería bueno, y los empleadores bien saben que siempre les digo, que la formación es un buen mecanismo para poder prescindir de este factor de experiencia. Ahora mismo estamos colaborando con importantes empresas y organizaciones que están formando a varios perfiles a la vez porque son conocedores del límite de la experiencia del que hablamos.
Por último, en cuanto al (3). Hay una expresión inglesa que me gusta rescatar cuando hablo de esto: «You get what you pay«. Una expresión muy común también últimamente en el sector tecnológico. No podemos pretender pagar salarios bajos y que luego tengamos esos supermanes y superwomanes que decía anteriormente. Tenemos que ser coherente con ello. Nuestro conocimiento tecnológico, el talento técnico que formamos en España, está muy bien valorado en muchos lugares de Europa (Dublin, Londres, Berlín, etc.) y el mundo (San Francisco, New York, Boston, etc.). Es normal que en muchas ocasiones este talento se quiera ir al extranjero. ¿Pudiera estar aquí también parte de la explicación de la dificultad para cubrir puestos?
Tecnologías de ingesta de datos en proyectos «Big Data» en tiempo real
Cuando hablamos de las etapas que componían un proyecto de Big Data, y sus diferentes paradigmas para afrontarlo, una cuestión que cité fue la siguiente:
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”.
Hadoop, que marcó un hito para procesar datos en batch, dejaba paso a Spark, como plataforma de referencia para el análisis de grandes cantidades de datos en tiempo real. Y para que Spark traiga las ventajas que solemos citar (100 vez más rápido en memoria y hasta 10 veces más en disco que Hadoop y su paradigma MapReduce), necesitamos sistemas ágiles de «alimentación de datos». Es decir, de ingesta de datos.
Es el proceso por el cual los datos que se obtienen en tiempo real van siendo capturados temporalmente para un posterior procesamiento. Ese momento «posterior» es prácticamente instantáneo a efectos de escala temporal. Esto se está produciendo mucho, por ejemplo, en el mundo de los sensores y el IoT (Internet of Things). No podemos lanzar alarmas en tiempo real si no contamos con una arquitectura como esta. Muchos sectores son ya los que están migrando a estas arquitecturas de ingesta de datos en un mundo en tiempo real.
Y es que el «tiempo real», el streaming, comienza ya desde la etapa de ingestión de datos. Tenemos que conectarnos a fuentes de datos en tiempo real, como decíamos, para permitir su procesamiento instantéano. En la era del Business Intelligence, e incluso en la era del «Big Data batch», los ETL eran los que permitían hacer estas cosas. Hemos hablado ya de su importancia. Sin embargo, son herramientas que en tiempo real, no ofrecen el rendimiento esperado, por lo que necesitamos alternativas.
Estas son el tipo de cosas que permiten hacer Spark y Storm, cuyo paradigma en tiempo real ya comentamos en su día. Aparecen, junto a ellos, 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.
- 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). Es un sistema distribuido de colas, el más conocido actualmente, pero existen otros como RabbitMQ, y soluciones en la cloud como AWS Kinesis.
- Sistemas de procesamiento de logs, donde podemos encontrar tecnologías como LogStash, Chukwa y Fluentd.
Con estas principales tecnologías en el menú, LogStash y Flume, se han convertido en las dos principales soluciones Open Source para lo que podríamos bautizar como «ETL en tiempo real». Es decir, para la necesidad de recoger datos en tiempo real. La ingesta de datos como etapa de un proyecto de Big Data.
Y, de este modo, nacen «packs tecnológicos» alternativos al ETL como es EFK, acrónimo de Elastic Search + Flume + Kibana. Se trata de una plataforma para procesar datos en tiempo real, tanto estructurados como no estructurados. Todo ello, con tecnologías Open Source, lo que podría venir a animar a muchas empresas que lean esta noticia, y entiendan el valor que tiene esto para sus seguras necesidades (cada vez más) en tiempo real.
- Elastic Search: motor de búsqueda, orientado a documentos, basado en Apache Lucene.
- Flume: ejcución de procesos de extracción, transformación y carga de datos de manera eficiente.
- Kibana: dashboards en tiempo real, procesando y aprovechando los datos en tiempo real indexados vía Elastich Search.
Con todo esto, quedarían esquemas tecnológicamente muy enriquecidos y útiles para necesidades de negocio como el que se presenta a continuación:
Como podéis apreciar, en estos ecosistemas, los ETL ya no cumplen la función que han venido desempeñando históricamente. Su rendimiento en tiempo real es realmente bajo. Por lo que tenemos que dar un paso más allá. E introducir nuevas tecnologías de ingestión de datos. Kakfa, Flume, Elastic Search, etc., son esas tecnologías. Si tu empresa está empezando a tener problemas con el datamart tradicional, o si la base de datos ya no da mucho más de sí, quizás en este ecosistema tecnológico tengamos la solución.
Nosotros, en nuestro Programa de Big Data, todo esto lo vemos durante 25 horas, montando una arquitectura en tiempo real que dé respuesta a las necesidades de empresas que cada vez necesitan más esto. Las tecnologías de ingesta de datos al servicio de las necesidades de negocios en tiempo real.
El «mercado de Hadoop» y MapR: el valor de las tecnologías Big Data
En un artículo anterior, hablábamos del nacimiento de esta era del Big Data. Y comentábamos, que el framework Hadoop había jugado en ello un papel fundamental. Desde entonces, su uso no ha dejado de crecer en el mundo empresarial.
El «mercado de Hadoop» está en pleno crecimiento. Hablamos de un mercado en el que las empresas, cogen el framework open source del que hablábamos, y desarrollan sus propias soluciones. Es una carrera entre tres principales «players»:
- MapR: valorada ya en más de 1.000 millones de dólares. Es noticia, porque ha conseguido más financiación aún.
- Cloudera: la empresa a la que se fue en 2009 «Doug» Cutting, el creador de Hadoop. En financiación, ha conseguido capital ya por 1.000 millones de dólares.
- Hortonworks: en bolsa desde 2014, y con una valoración bursátil actual de 435 millones de dólares.
Con estas cifras, además de entender el dinamismo del sector ahora mismo, se deja entrever que las valoraciones de las que estamos hablando de tecnologías Big Data, no son nada pequeños. Y si utilizamos estas cifras para aproximarnos a su verdadero valor, creo que podemos pensar que valor, existe.
Vamos a hablar de MapR, solo por la reciente noticia del aumento de su capital nuevamente. Y lo haremos como excusa para entender qué empresas están detrás de todo ello, y cuál es su base de clientes. Una tecnología de procesamiento de datos masivos que se asienta sobre el paradigma MapReduce, y que ofrece a las empresas la posibilidad de procesamiento Batch y Tiempo real (ya hablaremos de ello).
Ellos se autodefinen como plataforma de datos de convergencia, en el sentido que te permite hacer «de todo» con los datos con un mismo paquete de módulos tecnológicos. Una empresa que ha duplicado en el último trimestre su cartera de clientes, que ya incluyen a empresas del tamaño de American Express, Audi, Ericsson, NTT, Philips o el banco Mizuho. Su modelo de negocio se asienta sobre las licencias y los servicios de soporte. Representan un 90% de sus ingresos totales. Y esto es lo que exponen en su propia web:
MapR proporciona, en el marco del universo Hadoop, una plataforma unificada que dispone de funcionalidades de misión crítica, que permite realizar desarrollos de producción en tiempo real. MapR cuenta con cerca de 700 clientes de los sectores de finanzas, gobierno, salud, Internet, industria, medios, retail y telecomunicaciones. Amazon, Cisco, Google, Teradata y HP también forman parte del ecosistema de partners de MapR.
¿Y cuál es su propuesta de valor? Básicamente, sobreponerse a las restricciones que tiene la distribución estándar de Hadoop, pero bajo una licencia que sigue siendo Apache. En lugar del HDFS del que hablábamos, ofrece MapRFS para una gestión de datos más eficiente, confiable y fácil de usar. Por ello, suelen decir que está más orientada a la «producción empresarial» que las dos anteriores.
Además, su módulo de integración de datos es realmente eficiente, permitiendo a las organizaciones integrar y procesar datos «legacy» así como nuevos, procedentes de diferentes plataformas. Una vez hecho esto, igualmente proveen soluciones de analítica avanzada.
El procesamiento de datos en el mundo de las empresas está en tanta transformación, que todas estas empresas proveedoras de soluciones de procesamiento de grandes volúmenes de datos, seguirán registrando cifras récord. La tendencia así parece demostrarlo. Aquellas que más están cambiando (aquellas que más competitividad están consiguiendo), son clientes de MapR, Hortonworks o Cloudera. Por ello, nada hace pensar que esta tendencia va a cambiar.
Arquitectura Lambda para sistemas Big Data (y III)
(venimos de una serie hablando de los tres paradigmas, para haber hablado luego del paradigma batch y luego del tiempo real)
Terminamos esta serie de artículos, hablando de las arquitecturas Lambda. Y es que una de las cosas que decíamos a la hora de procesar flujos de datos en tiempo real, es que se puede no renunciar a la aproximación batch. Es decir, que podemos diseñar sistemas de Big Data que los integren a ambos, dando así una opción genérica y que para cada necesidad concreta, pueda emplear las tecnologías Batch o Tiempo Real.
Nathan Marz publicó el libro «Big Data: Principles and best practices of scalable realtime data systems» en abril de 2015 para explicar todo esto (aquí está el primer capítulo, gratis). Lo resumió en «la Arquitectura Lambda«, que representamos a continuación:
En la web http://lambda-architecture.net/ se puede comprobar como son muchos los casos de aplicación de este paradigma que se han producido en los últimos tiempos.
El problema ante el que nos solemos encontrar al tratar con grandes volúmenes de datos es que no existe una técnica predefinida para hacerlo. Ya hemos visto con los paradigmas anteriores que el enfoque a adoptar para el procesamiento puede ser diferente. En esta ocasión, el creador de este paradigma Lambda, propone descomponer el problema en tres capas: Batch, Serving y Speed.
En este paradigma todo comienza con una ecuación que podríamos formular de la siguiente manera: query = function(all data). Consiste en que en esa capa Batch inicial que veíamos, disponer de vistas indexadas de datos que han sido pre-computadas, de tal manera que cuando tenga una necesidad en tiempo real, no necesite procesar todo el largo conjunto de datos, sino simplemente acceder a la vista de datos que tuviera pre-computada. De esta manera, me adelanto a la necesidad de consultar datos, disponiendo de largos subconjuntos de los mismos ya pre-computados, de tal manera que se trataría de localizar los mismos. Es importante entrever que estas pre-consultas son aleatorias, por lo que para analizar todo el dataset tendríamos que lanzar varias consultas.
Supongamos que tenemos un proyecto de análisis de datos de una web con Google Analytics. Dejamos así «preparada» una función con todas las métricas que quisiéramos consultar (páginas vistas, visitantes únicos, búsquedas orgánicas, etc.) en una función con (URL, día). De esta manera, cuando queramos lanzar una consulta para un día determinado, solo necesitaríamos consultar la vista del rango de día donde hubiera caído el día concreto que nos interesa, y así, ágilmente, conseguir la información que nos interesa. En esta capa intervienen Hadoop o Spark.
Posteriormente, tenemos la capa de servicio. La capa anterior, creaba esas vistas con los datos pre-computados. Pero, siempre necesitaremos una capa que cargue esas vistas en algún lugar que luego permita se puedan consultar. Esto se hace en la capa de servicio. Indexa las vistas creadas en la capa batch, las actualiza cada vez que llegan nuevas versiones de la capa batch. Dado que no recibe escrituras de datos «aleatorias» (que suele ser el factor que hace realmente lenta una Base de Datos tradicional), esta capa es realmnete robusta, predecible, fácil de configurar y operar. Ya ven, un problema habitual de las bases de datos, resuelto no tanto con tecnología (que también), sino con enfoques de tratamiento de datos. En esta capa, destaca ElaphantDB, por ejemplo.
Y, por último, aparece la capa de velocidad. Cuando alguien quiere acceder a una consulta de datos, lo hace a través de una combinación de la capa de servicio y de la capa de velocidad. Esto lo podemos ver en el siguiente gráfico:
La capa de velocidad es similar a la batch en el sentido que produce vistas a partir de los datos que recibe. Ahora bien, hay algunas diferencias clave. La más importante es que para conseguir altas velocidades, esta capa no mira a todos los nuevos datos de golpe. Solo actualiza aquellos nuevos datos que recibe, lo que le permite ofrecer de manera efectiva consultas de datos en tiempo real. Por eso se suele decir que esta capa actúa con actualizaciones incrementales, solo marcando como nuevo aquello que sea estrictamente necesario para ofrecer al usuario una vista en tiempo real.
Y todos esos módulos y funcionalidades es lo que nos permite disponer de una arquitectura Lambda que de manera completa representamos en la siguiente figura. Nada mejor para seguir ampliando conocimientos que leer el libro de Nathan Marz, que lo explica realmente bien y al detalle.
Con este artículo, cerramos esta serie en la que hemos hablado de los diferentes paradigmas para afrontar un proyecto de Big Data real. Como veis, muchas novedades, y mucha cabeza puesta en hacer sistemas realmente eficientes y ágiles para las organizaciones.
Paradigma batch para sistemas Big Data (I)
(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.
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
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/ 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
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«.
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.
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.
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 scoring bancario en los tiempos del Big Data
Con este artículo vamos a abrir una serie de cinco artículos donde expondremos las cinco ponencias y sus preguntas asociadas del pasado workshop celebrado el 27 de Octubre en la Universidad de Deusto.
El workshop, titulado como «Aplicación del Big Data en sectores económicos estratégicos«, tenía como principal objetivo mostrar la aplicación del Big Data en varios sectores estratégicos para la economía Española (finanzas, sector público, cultura, inversión y turismo). La primera de las intervenciones corrió a cargo de Jorge Monge, de Management Solutions, que nos expuso cómo elaborar un scoring financiero y su relevancia en la era del Big Data.
La revolución tecnológica se produce a magnitudes nunca antes observadas. El sector financiero no es ajeno a ese cambio, conjugando una reestructuración sin precedentes, con un cambio de perfil de usuario muy acusado. Así, se está pasando de la Banca Digital 1.0 a la 4.0, una innovación liderada por el cliente, y donde la analítica omnicanal con datos estructurados y no estructurados se torna fundamental.
Las entidades financieras, gracias a esta transformación digital, disponen de gran cantidad de información pública, con la que hacer perfiles detallados no solo a sus clientes actuales, sino también a sus clientes potenciales. Dado que la capacidad de procesamiento se ha visto multiplicado por las nuevas arquitecturas del Big Data, esto tampoco supone un problema. Los modelos de scoring (como el que Jorge expuso) pertenecen al ámbito de riesgos de las entidades bancarias, intentando clasificar a los clientes potenciales en función de su probabilidad de impago. Nos contó un proyecto real en el que con datos anonimizados de una cartera de 72.000 clientes potenciales, se mezclaron datos tradicionales de transacciones, con datos de redes sociales, para conformar un modelo analítico. Éste, conformado por variables significativas de cara a evaluar el incumplimiento, permitía mejorar el poder precitivo del scoring bancario.
El reto actual radica en la gran cantidad de datos. Jorge señaló cómo aunque se genere gran cantidad de información, esta no sería útil si no pudiera procesarse. Sin embargo, la capacidad de procesamiento se ha visto multiplicada por las nuevas arquitecturas de Big Data. Destacó, aquí, Hadoop, Hive, Pig, Mahout, R, Python, etc. Varias de las herramientas que ya comentamos en un post pasado.
Por último, destacaba, que el reto ya no es tecnológico. El reto es poder entender el procesamiento que hacen estas herramientas. Así, ha surgido un nuevo rol multidisciplinar para hacer frente a este problema: el data scientist, que integra conocimientos de tecnología, de programación, de matemáticas, de estadística, de negocio, etc. Hablaremos de este perfil más adelante. Y, cerraba la sesión, destacando la importancia de la calidad de la información, el reto que suponen las variables cualitativas y la desambiguación.
Os dejamos, para finalizar el artículo, la presentación realizada por Jonge Monge. Aprovechamos este artículo para agradecerle nuevamente su participación y aportaciones de valor.
Eligiendo una herramienta de Analítica: SAS, R o Python
(Artículo escrito por Pedro Gómez Tejerina, profesional del sector financiero, y profesor de nuestro Programa de Big Data y Business Intelligence)
Probablemente si estás leyendo este blog tengas un problema analítico que quieras resolver con datos. Es posible también que tengas unos conocimientos de estadística que quieras poner en práctica, así que es hora de elegir una herramienta analítica. Así que vamos a intentar orientaros en la elección, aunque las tres herramientas de analítica nos van a permitir hacer en general los mismos análisis:
- Conocimientos previos de programación. Si sabes programar y vienes de un entorno web, probablemente Python sea el más fácil de aprender. Es un lenguaje más generalista que los otros dos y solamente tendrás que aprender el uso de las librerías para hacer análisis de datos (Pandas, Numpy, Scipy, etc.). Si no es el caso y lo tuyo no es programar, SAS es más fácil de aprender que R, que es el lenguaje más diferente de los tres, dado su origen académico-estadístico.
- Herramientas User Friendly y GUI: Tanto SAS (SAS Enterprise Guide, SAS Enterprise Miner, SAS Visual Analytics) como R (Rattle, RStudio, Rcommander) tienen buenas interfaces visuales que pueden resolver problemas analíticos sin tener la necesidad de programar. Python dispone de menos (Orange), aunque dispone de una buena herramienta de enseñanza: los notebooks.
- Coste de las herramientas. SAS es un software comercial y bastante caro. Además el uso de cada una de sus capacidades se vende por paquetes, así que el coste total como herramienta analítica es muy caro. La parte buena es que tienes un soporte. Por el contrario, tanto R como Python son gratuitos, si bien es cierto que empresas como Revolution Analytics ofrecen soporte, formación y su propia distribución de R con un coste bastante inferior a SAS. Normalmente sólo las grandes empresas (bancos, compañías telefónicas, cadenas de alimentación, INE, etc.) disponen de SAS debido a su coste.
- Estabilidad de la herramienta. Al ser un software comercial, en SAS no hay problemas de compatibilidad de versiones. R al tener un origen académico ofrece distintas librerías para hacer un mismo trabajo y no todas funcionan en versiones anteriores de R. Para evitar estos problemas en una gran empresa recomendaría utilizar alguna distribución comercial de Revolution Analytics por ejemplo.
- Volumen de datos. Las única diferencia es que SAS almacena los datos en tu ordenador en vez de en memoria (R), si bien es cierto que las 3 tienen conexiones con Hadoop y las herramientas de Big Data.
- Capacidad de innovación. Si necesitas utilizar las últimas técnicas estadísticas o de Machine Learning SAS no es tu amigo. Es un software comercial que para garantizar la estabilidad de uso entre versiones retrasa la incorporación de nuevas técnicas. Aquí el líder es R seguido de Python.
Conclusión: no es fácil quedarse con una herramienta de analítica y las personas que trabajamos en grandes compañías estamos habituados a trabajar con varias. SAS ofrece soluciones integradoras a un coste elevado. R tiene muchas capacidades de innovación debido a su origen y Python tiene la ventaja de ser un lenguaje de programación generalista que además puede servir para hacer Data Mining o Machine Learning. La elección dependerá de lo que estés dispuesto a pagar y tus necesidades específicas. Yo tengo la suerte o desgracia de trabajar en una gran empresa, así que dispongo de las 3.
Más información en:
- http://www.analyticsvidhya.com/blog/2014/03/sas-vs-vs-python-tool-learn/
- http://blog.datacamp.com/r-or-python-for-data-analysis/
