Como persona de negocio, CEO o director de tu área deberías conocer y tener claro para qué sirven cada una de las tecnologías que vamos a ver a continuación y cuándo es adecuado utilizarlas. De esta manera podrás identificar de manera ágil qué caso de uso necesitas desarrollar para satisfacer tus necesidades de análisis de datos.
Se trata de tecnologías OpenSource, es decir, no comerciales, aunque en el mercado existen sus equivalentes comerciales en Oracle, Microsoft, etc.
Todos estos nuevos componentes fueron concebidos para solventar las carencias que tenía Hadoop frente a las diferentes necesidades que se fueron experimentando, por eso nosotros le llamamos con cariño el “Titanic tecnológico”.
Vamos a ver algunos componentes para la ingesta y procesamiento de datos en batch y tiempo casi real:
Ingesta de Datos
Una de las características de la arquitectura Big Data es que debe ser capaz de analizar distintos tipos de información, tanto estructurada (tablas con filas y columnas) como desestructurada (artículo de un blog o comentarios en redes sociales), por lo que vamos a ver tres componentes que complementan a Hadoop para realizar una ingesta de datos óptima:
FLUME, ingesta de datos no estructurados
Suele utilizarse para la ingesta de datos no estructurados en tiempo real como son los datos de Social Media, la geolocalización, los sensores IOT, logs (registros) que son archivos de texto en el que constan cronológicamente los eventos que han ido afectando a un sistema y los cambios que se han ido produciendo, etc.
SQOOP, ingesta de datos estructurados
Sqoop accede y carga fuentes de datos estructurados (DWH, Datamart, CRM…) en el entorno Big Data. Utiliza el mítico truco de dividir y paralelizar al igual que Hadoop.
KAFKA, para casos de uso de tiempo real (funciona bastante bien con Storm del que hablaremos más tarde)
Kafka es un software de enrutamiento distribuido ¿Cómo te quedas? Básicamente lo que hace es coger la información de las fuentes de datos, las categoriza y las almacena temporalmente hasta que llega alguno de los componentes de los que estamos hablando en este artículo y consume la información de la categoría que le interese. Esto supone una gran flexibilidad para organizar la entrada de información al entorno Big Data.
Procesamiento batch
El procesamiento batch consiste en procesar grandes volúmenes de información sin la necesidad de que sea en tiempo real:
HIVE, el amor a primera vista de los analistas
¿Qué carencias/problemas de Hadoop soluciona Hive?
1.Puede organizar la información en Hadoop desde una lógica más cercana a negocio como en los DWH.
2.La programación en MapReduce es todo un infierno. Hive permite hacer queries en SQL, lo transformará en MapReduce y buscará la información sobre la consulta en el sistema de almacenamiento HDFS.
Por estas dos razones, más de un analista ha pedido matrimonio a Hive. Fue todo un amor a primera vista.
TEZ e IMPALA, interactuar con los datos en segundos
Cuando se trata de Data Discovery, y un analista está realizando una consulta tras otra para sacar el máximo partido a los datos, los tiempos de respuesta no deben ser rápidos, si no super rápidos ¡El tiempo es oro! Hive logró agilizar las consultas de días a horas y siempre llevando a cabo análisis sobre procesos ya conocidos por lo que la operativa era sota, caballo y rey pero cuando llegaba la hora de ir un paso más allá y realizar consultas interactivas, Hive no era suficiente por lo que aparecieron Tez o Impala para hacer análisis en segundos.
PIG ¡Bendito cerdito!
A veces se confunden Pig y Hive dado que ambos nacieron para hacernos la vida más fácil con el tortuoso MapReduce pero son ligeramente diferentes.
Como ya sabes, Hive nos ayuda a hacer consultas en SQL tradicional mientras que PIG está hecho para afrontar cadenas de procesos en la transformación de datos, crear otras variables, etc.
Si a Hive muchos analistas le han pedido matrimonio a PIG tampoco le han faltado pretendientes.
Procesamiento de datos en tiempo real: STORM Y NoSQL
Como supondrás, existen casos de uso donde los análisis son en tiempo real como por ejemplo la publicidad en tiempo real de una web, la probabilidad de fraude de una operación, la monitorización de riesgos de accidente o el control de mercancías.
Flume o Kafka hemos visto que se desenvuelven bien en estos casos de uso pero también contamos con otros componentes como STORM o las bases de datos NoSQL:
STORM
Storm cuenta con dos componentes principales: Spouts, conectores a las fuentes de datos y los Bolts, unidades de procesamiento.
El funcionamiento consiste en que cada conjunto organizado de datos realiza una serie de operaciones que le mandará el resultado al siguiente componente, de esta manera se resuelven procesos complejos en tiempo real.
CASO DE USO MARKETING: Hiperpersonalización Publicitaria web
Un conjunto de datos está compuesto por una serie de Spouts que recogen información de la navegación en tiempo real del cliente y otros recogen información histórica almacenada en una base de datos NoSQL. Mientras tanto, otros Spouts recogen el número de clicks, analizan con text mining las webs visitadas y extraen tags mientras que finalmente otros Spouts crean un modelo predictivo que crea el anuncio más adecuado para ese usuario en ese momento concreto.
BASES DE DATOS NoSQL (Not only SQL)
Al igual que el resto de componentes que hemos visto, fueron concebidas para resolver problemas que Hadoop no puede resolver.
En este caso hablaremos de la poca o inexistente escalabilidad de Hadoop, nuestro “Titanic tecnológico”. Es super malo a la hora de guardar y leer un dato determinado de manera puntual, de hecho, funciona como las antiguas imprentas, que solo las arrancaban cuando había que hacer miles y miles de copias pero para hacer solo algunas copias no compensaba encender toda la maquinaria.
En una arquitectura Big Data, las bases de datos NoSQL nos dan la capacidad de consultar y escribir con accesos aleatorios en tiempo real sin esquemas prefijados ni las restricciones de las bases de datos relacionales.
Existen cuatro tipos de bases de datos NoSQL:
Base de datos Clave-Valor
Son bases de datos muy sencillas, ideales para realizar consultas o escribir datos.
Siguiendo con el ejemplo de la hiperpersonalización publicitaria, podríamos tener una serie de insights en el histórico de clientes almacenados en NoSQL de tal manera que Storm puede recuperar en tiempo real estos datos de los clientes permitiéndonos una rápida toma de decisiones.
La más conocida es Redis.
Bases de datos Columnares
Organizan la información en columnas lo cual las hace muy eficientes para consultas y agregación de grandes volúmenes de información. Presentan una estructura similar a las clave-valor pero se desenvuelven en escenarios más complejos.
Las más conocidas son Cassandra o Hbase.
Bases de datos Documentales
Almacenan la información en formatos de documento como XML o JSON. Funcionan muy bien con las clave-valor o análisis más complejos y son ideales para analizar información no estructurada como mensajes en redes sociales, textos de páginas web, etc.
La más conocida es MondoDB
Grafos
Organizan la información como una red, con nodos y relaciones. Son muy eficientes para ciertos casos de uso porque utilizan la teoría de grafos para optimizar las consultas como en la optimización de rutas, análisis de fraude o análisis de Social Media.
La más conocida de este tipo es Neo4j.
Ya conoces la foto general de todo el ecosistema Hadoop y cómo todos estos componentes han ido tapando sus carencias pero ahora nos toca pasar a la siguiente generación: Spark.
Referencias:
Medios: Revista Cloud Computing, Big Data Ticbyte, ESIC
Libro: González Díaz, I. «Big Data para Ceos y Directores de Marketing», (2017). Puedes adquirirlo aquí