Hace no mucho organizamos un meetup de introducción cloud con la idea de acercar este concepto tan difuso a la gente. En esta jornada se explicaron muchas dudas sobre el cloud y sobre los proveedores más importantes, pero hubo algo que llamó más la atención que el resto. El Big Data.
Y, ¿qué es eso del Big Data? Lejos de querer embarcarme en un post teórico sobre definiciones, ventajas y desventajas; me gustaría dar una pequeña definición y pasar a los engranajes.
El big data en sí no es más que, tal y como la propia palabra corrobora, grandes volúmenes de datos, pero lo importante no es sólo lo que tenemos, sino cómo sacarle partido. Lo que a priori puede parecer inconexos o incluso de poco valor, bien pulido puede convertirse en una gema en bruto. Y ¿cómo lo pulimos?
En #BigData no solo son importantes los datos, sino cómo sacarle partido Clic para tuitearDe forma genérica el el proceso consiste en las siguientes fases:
Ingesta
A menudo estos datos están dispersos en varios almacenamientos que soportan nuestros procesos y aplicaciones. Ergo, el primer paso consiste en construir un punto donde todos estos datos convivan y se convierta en nuestra fuente de verdad.
Transformación
Muy probablemente estos datos en bruto estén llenos de ruido y/o elementos que no nos aportan valor al caso de uso específico de la solución. Refinando estos datos conseguiremos mejorar el rendimiento de los diferentes procesos que explotarán los mismos.
Análisis
Consiste en la exploración de los datos con el objetivo de sacar conclusiones apoyándose en los mismos. Dada la cantidad de datos que se están manejando se necesitan herramientas y componentes específicos para llevar a cabo esta fase.
Visualización
Finalmente, y una vez estos datos están refinados, se procede a la presentación de los mismos poniendo especial esfuerzo en facilitar la interpretación de los mismos.
Ahora que sabemos por dónde van los tiros, pasemos a analizar las diferentes fases sobre un ejemplo práctico.
Lo que tenemos aquí no es más que una arquitectura típica llamada Arquitectura Big Data Lambda. Cuando procesamos grandes cantidades de datos, a menudo tenemos que hacer un compromiso entre la velocidad en la que disponibilizamos los datos (tiempo real) y la precisión de los mismos (cargas programadas). Esta arquitectura contempla ambos casos de uso, siendo capaz de productivizar los datos tanto a tiempo real como las cargas programadas.
Ingesta
Arquitectura Big Data Lambda para productividad datos en tiempo real y programados.
Hay diversas formas de realizar la ingesta a tiempo real, pero para esta situación optamos por utilizar Kinesis Streams y Firehose, servicios recomendado por AWS para estos casos de uso. Kinesis Data Streams es un servicio que permite la recolección de datos de forma continua y altamente escalable. En el caso de que queramos integrar los datos con los disponibilizados de forma programada, utilizaremos Kinesis Firehose, que nos permite empaquetar los datos para unirlos al datalake.
Kinesis Data Streams y Kinesis Firehose permite empaquetar los datos para unirlos en el datalake.
En el caso de la ingesta programada, podemos utilizar servicios como AWS Glue, AWS Batch o AWS Data Migration Service; en el caso de que queramos replicar los datos desde sistemas como RDBMS, almacenes de datos o NoSQLs. Es interesante analizar las diferentes fuentes de datos para utilizar el mejor servicio en cada caso.
Transformación
Cuando hablamos de la transformación de datos a tiempo real en arquitecturas de AWS, Kinesis Firehose es el rey. Antes hemos visto como Firehose permite empaquetar los datos en la ingesta para unirlos a los ingestados por parte de los procesos programados; sin embargo, podemos hacer más que empaquetar con Kinesis, podemos realizar transformaciones a tiempo real para luego ser utilizados por herramientas de visualización y analítica convencionales o servicios de analítica y visualización a tiempo real como Kinesis Analytics.
Kinesis Firehose empaqueta datos en la ingesta.
El utilizar S3 como datalake nos permite reducir costes (no es necesario tener siempre todos los datos en almacenamientos como Redshift), al mismo tiempo que desacoplamos la arquitectura, pues no siempre nos interesa utilizar las mismas tecnologías para todos los datos.
Si nos decantamos por acumular los datos en el datalake (tanto en el caso de tiempo real como de cargas programadas) tenemos varias alternativas a la hora de “curar” estos datos y prepararlos para su posterior productivización. Estas alternativas (AWS Batch, AWS Glue, AWS EMR) contemplan casos de uso y niveles de personalización y administración diferentes, ofreciéndonos un gran abanico de posibilidades para cubrir las necesidades de diferentes clientes. En algunos casos donde la transformación no es demasiado exigente en términos de CPU, memoria o tiempo es posible lleva a cabo esta fase con AWS Lambda, a este proceso se le llama micro-batching.
El siguiente ejemplo contempla la aplicación de transformaciones con AWS Glue, servicio que permite explotar las funcionalidades de Spark o Scala de una forma totalmente manejada, e incluso nos ofrece ya algunas transformaciones canónicas en su catálogo.
Aplicación de transformaciones con AWS Glue y base de datos Redshift para analítica.
Analítica
Cuando hablamos de analítica entran en juego varias herramientas y varios servicios de AWS. En el caso del ejemplo anterior, podemos observar una base de datos Redshift, la cual nos permite realizar análisis utilizando consultas PSQL para sacarle partido a la gran capacidad de cómputo de esta tecnología. Redshift y Athena nos permiten realizar análisis sobre datos ya transformados, mientras que para los casos específicos de tiempo real podemos utilizar AWS Kinesis, la cual nos permite realizar consultas a tiempo real sobre los datos recibidos.
Visualización
Al final el objetivo es ser capaz de interpretar estos datos de forma rápida y sencilla de cara a ser capaces de sacar conclusiones sobre los mismos que nos ayuden a mejorar nuestro negocio. Para cubrir esta necesidad Amazon Web Services nos provee de un servicio llamado QuickSight, el cual se integra fácilmente con los servicios de almacenamiento de AWS. A través de este servicio podemos construir de forma rápida, y pagando únicamente por las sesiones, paneles informacionales que permitan tomar la mejor decisión en cada situación.
Resultado
Visión de ejemplo de arquitectura Big Data Lambda.
Todo esto da como resultado una arquitectura construida por bloques (intercambiables y reutilizables) que permite las recepción y tratamiento de datos, tanto a tiempo real, como de forma programada. Unificando la cap de procesamiento conseguimos el poder utilizar un único punto de tratamiento para ambas casuísticas.
Imagen: unsplash | nate grant
Cloud Architect en Keepler. "I am specialized in Cloud environments and DevOps culture. I have worked designing and implementing public and hybrid cloud ecosystems for several Ibex 35 companies."
0 comentarios