Archivo de la etiqueta: hbase

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».

Bases de Datos NoSQL de grafos: mejor rendimiento para grandes volúmenes de datos

Deja un comentario

Como saben, la semana pasada, organizamos un evento titulado «Las tecnologías Big Data al servicio de la sociedad«.  Un evento en el que a través del famoso caso de los Papeles de Panamá, tratábamos de divulgar la utilidad que tiene este nuevo paradigma del Big Data -sus métodos y tecnologías- también para beneficio de toda la sociedad.

Iremos, a lo largo de los próximos días difundiendo los contenidos y materiales generados para esa sesión. Empezamos la serie hablando de la intervención de Mario Iñiguez, Co-founder de Adamantas Analytics, que nos explicó cómo poner en valor las tecnologías de Big Data con las Bases de Datos NoSQL de grafos.

Las Bases de Datos NoSQL aparecen a la par de la explosión de la web 2.0. En ese momento, se produce un crecimiento espectacular del volumen de datos. Además, generado por el propio usuario, con información volátil, variada, no estructurada y extensa. Las relaciones se multiplican, no existe una estructuración previa. En este contexto, el paradigma de Bases de Datos Relacional que venimos usando desde los años 70, nos limitaba mucho. Un modelo de datos estático y con dificultad de adaptación a cambios, que dispone de relaciones explícitas entre tablas, es un paradigma que no casa bien con esta explosión de datos no estructurados.

Ahí es cuando empezamos a hablar de la necesidad de disponer de un nuevo paradigma. Lo bautizamos como NoSQL, manifestando claramente su desvinculación de este paradigma relacional que había venido siendo imperante hasta entonces.  Y, aparecen, cuatro nuevos tipos de bases de datos:

  • Clave valor: el más popular, además de ser la más sencilla en cuanto a funcionalidad. Cassandra, BigTable o HBase son ejemplos de este tipo. Son bastante eficientes tanto en lectura como en escritura. En nuestro programa vemos Cassandra.
  • Columnares: las bases de datos, en lugar de estar estructuradas por filas, están estructuradas por columnas. Al tratarse de una sola dimensión, hace más eficiente la recuperación de la información. En nuestro programa, trabajamos con Vertica.
  • Documentos: almacena la información como un documento, permitiendo realizar consultas bastante avanzadas sobre el mismo. Por ello, suele considerarse como el más versátil. MongoDB o CouchDB son ejemplos de ello. Nosotros en nuestro Programa de Big Data hacemos alguna sesión práctica con MongoDB.
  • Grafos: los datos son representados como nodos y aristas que modelizan la relación entre esos nodos. De esta manera, podemos emplear la teoría de grafos -de lo que ya hemos hablado en el pasado– para recorrer y navegar por su contenido. Su principal ventaja es que permite una navegación más eficiente entre relaciones que en un modelo relacional. Neo4J -la empleada en el caso de los Papeles de Panamá- o Virtuoso son ejemplos de ello, siendo Neo4J la que vemos en nuestro programa y sobre la que sacaremos un programa específico el próximo Otoño (dada la relevancia que va adquiriendo, por lo que ya informaremos de ellol).

Este último tipo, el de grafos, fue el que nos introdujo Mario y sobre el que nos contó sus bondades. Uno de los elementos que destacó Mario es cómo esta forma de representar la información se aproxima bastante al pensamiento humano (cómo representamos la información en nuestro cerebro). A través de varios ejemplos (éste de Open Corporates de Goldman Sachs o éste de la complejidad económica del MIT), vimos las principales ventajas de representar la información en grafos. Que, básicamente, se resumen en un tiempo de ejecución bastante menor que una base de datos relacional (en la transparencia 7 de la siguiente presentación podéis ver la comparativa empírica que hizo Mario).

Para concluir, Mario nos resumió las principales utilidades de este nuevo tipo de bases de datos NOSQL de grafos:

  • Disponer de más información con agilidad y eficiencia (lugares más visitados, análisis de sentimiento, rutas y medios, quejas y reclamaciones, círculos de influencia, etc.)
  • Y, desencadenar acciones (mejora de infraestructuras, mejora de servicios, mejora de la oferta turística, oportunidades de negocio, promoción comercio local)

Además, os dejamos un vídeo donde le preguntaba por los principales puntos que trató durante su intervención y que provocó varias preguntas de la audiencia. Como concluíamos, el modelo relacional podría tener sus días contados si las tecnologías de BBDD NoSQL siguen mejorando el rendimiento y resultados de procesar grandes cantidades de datos. Será interesante ver la evolución.