Gartner [1] define los sistemas Big Data con las “tres uves”: grandes volúmenes, alta velocidad y gran variedad de activos de información. A medida que estos tres componentes crecen, la variedad se convierte en el factor más decisivo a la hora de evaluar una inversión en Big Data.
En algunas encuestas realizadas en el 2016 entre los responsables de los departamentos de Big Data [2], se destacó la variedad de los datos como el factor más importante, seguido por el volumen (25%), y finalmente la velocidad (6%). La tendencia en 2017, destaca que la gran oportunidad se encuentra en la integración de más fuentes de datos, no de cantidades mayores, sino de diferentes fuentes de datos. Es decir, destaca la característica de la variedad como la característica más importante, relegando a un segundo lugar la característica del volumen. Por esto las empresas se enfocan en identificar nuevas fuentes y en integrar fuentes de datos que tradicionalmente han sido utilizadas para otros fines, como es el soporte de sus aplicaciones: Aprovechar más las fuentes de datos ha surgido como el nuevo reto dentro del mundo corporativo.
Al diseñar arquitecturas Big Data, nos encontramos con un stack de herramientas muy amplio y en constante crecimiento que muchas veces nos hace sentir abrumados a la hora de enfrentarnos a este tipo de retos, y porque creo que este sentimiento en algún momento lo hemos tenido todos, he decidido escribir este artículo, con el fin de ayudaros o por lo menos de orientaros a la hora de plantear arquitecturas Big Data.
Antes de empezar a adentraros en el post, no quiero que penséis que después de leerlo tendréis la solución a vuestra arquitectura, no tendréis esa “foto” de la arquitectura que debéis utilizar, ya que no hay una arquitectura única que cubra todos los casos de uso, pero si quiero que con este artículo sepamos: qué preguntarnos y qué cosas tenemos que tener en cuenta a la hora de diseñar una solución.
¿Qué características tiene que tener tu sistema Big Data?
Normalmente lo que nos encontramos es que cuando implantamos una nueva arquitectura Big Data, lo hacemos para un “pequeño objetivo“, es decir, surge de la necesidad de dar solución a un caso de uso concreto. Por un lado, esto es algo positivo y algo que en otras ocasiones hemos recomendado encarecidamente: “Centra tu objetivo“. Sin un objetivo claro es posible que tu solución fracase, pero por otro lado, hay que tener en cuenta que la arquitectura crecerá y deberá ser capaz de soportar futuros casos de uso.
Una de las cosas más importantes es que definas las “capas” a alto nivel que poseerá tu arquitectura, y que ninguna de tus capas se base en una herramienta concreta, porque muchas veces la arquitectura necesitará de diferentes tipos de herramientas para cubrir las distintas problemáticas a las que debe dar respuesta. Veamos un pequeño ejemplo:
Nuestra arquitectura Big Data debe tener un punto de entrada de los datos o lo que muchas veces se denomina como “Data Ingestion layer“, si a priori nuestro caso de uso necesita adquirir los datos de bases de datos relacionales, es posible que decidas utilizar “Sqoop” como herramienta. ¿Qué pasa cuando en un futuro necesites leer ficheros, logs, e-mails? Tendrás que incorporar nuevas herramientas como Flume, Nifi, etcétera.
Este tipo de situaciones no sólo se darán en tu “Data Ingestion Layer” sino que te pasará en las diferentes capas de tu arquitectura, por lo que mi recomendación es que no diseñes partiendo de una herramienta, en lugar de eso intenta que tu arquitectura se base en nodos modulares que formen parte de cada una de las capas de la arquitectura. Esto hará de tu diseño una arquitectura escalable y modular.
El uso de diferentes herramientas te permitirá dar soluciones a más casos de uso, eso sí, esto no significa que lo uses todo. Procura evaluar las herramientas antes de incorporarlas y piensa a futuro, ya que un sistema con herramientas muy variadas aumentará su complejidad en cuanto a gestión y administración.
Entre las características que debe poseer tu arquitectura, nos encontramos con:
- Escalabilidad: debe ser capaz de aumentar las capacidades hardware de cada una de las capas del sistema, en algunos casos aumentando su capacidad de procesamiento y en otros casos de almacenamiento.
- Tolerancia a fallos: ante la caída de alguno de los servidores o nodos el sistema debe garantizar su disponibilidad, evitando la pérdida de datos y esto, aplicado a cada una de las capas de tu arquitectura.
- Distribución de los datos: ten en cuenta que debido al gran volumen de información, estos sistemas distribuyen los datos y para ello, necesitas dotar a tu arquitectura de diferentes nodos que alberguen la información. Este tipo de soluciones distan de las tradicionales cuyo paradigma se basaba en la centralidad de los datos.
- Procesamiento distribuido: a la hora de procesar estos volúmenes de información y aplicar algoritmos más o menos complejos, estas soluciones se basan en la distribución del procesamiento para optimizar los tiempos de ejecución. Esto implica que tu diseño debe estar preparado para tener diferentes nodos donde distribuir el procesamiento de los datos y tener la capacidad de escalar.
- Localidad del dato: este término muy utilizado en sistemas Big Data, se refiere a la cercanía entre los procesos analíticos y los datos que se procesan y estas arquitecturas deben favorecer la localidad de los datos para evitar el trasiego de red, que en sistemas tradicionales no se considera un punto crítico pero en estos sistemas puede penalizar los tiempos de ejecución.
A la hora de elegir tecnologías no te abrumes, ve poco a poco, aquí te dejo consejos que te podrán ayudar en tu diseño:
- En la ingesta de información: evalúa tus tipos de fuentes, no todas las herramientas sirven para cualquier fuente, y en algún caso te encontrarás que lo mejor es combinar varias herramientas para cubrir todos tus casos.
- En el procesamiento: evalúa si tu sistema tiene que ser streaming o batch. Algunos sistemas que no se definen como puramente streaming utilizan lo que denominan micro-batch que suele dar respuesta a problemas que en el uso cotidiano del lenguaje se denomina como streaming.
- En la monitorización: ten en cuenta que estamos hablando de multitud de herramientas y que su monitorización, control y gestión puede llegar a ser muy tedioso, por lo que independientemente de que te decidas por instalar un stack completo o por instalar herramientas independientes y generar tu propia arquitectura combusto, te recomiendo además queutilices herramientas para controlar, monitorizar y gestionar tu arquitectura, esto te facilitará y centralizará todo este tipo de tareas.
No desvíes tu camino, hay cosas que debemos tener siempre presentes:
Seguramente según vayas adquiriendo experiencia en el diseño de arquitecturas Big Data, puedas ir aportándome ideas en este tema, pero por el momento desde mi punto de vista, estas son algunas de las principales respuestas que debes conocer antes de comenzar a diseñar una solución.
- Enfoca tus casos de uso, cuando tengas tus objetivos claros sabrás que debes potenciar en tu arquitectura. ¿Volumen, variedad, velocidad, .. realmente lo necesitas todo?
- Define tu arquitectura: ¿batch o streaming?¿Realmente necesitas que tu arquitectura soporte streaming?
- Evalúa tus fuentes de datos: ¿Cómo de heterogéneas son tus fuentes de datos? ¿soportan las herramientas elegidas todos los tipos de fuentes de datos que tienes?
