Introducción a las Arquitecturas Big Data

Comenzamos la serie de artículos sobre arquitecturas Big Data, donde veremos sus principales características, tecnologías implicadas, herramientas, arquitecturas que usan las empresas, profesionales implicados y un desglose de los principales componentes. En este primer artículo de introducción a las Arquitecturas Big Data veremos qué son, cuáles son sus características, necesidades, principales tipos y profesionales implicados.

Este artículo forma parte de nuestra serie donde te contamos todo lo que necesitas saber para diseñar e implementar Arquitecturas Big Data.

¿Para quién va dirigida esta serie? Especialmente para aquellos Arquitectos de Soluciones que tengan que diseñar un entorno Big Data, pues se van a mostrar todos los procesos a que hay que desarrollar con los pros y contras de elegir ciertos diseños y tecnologías. Por otro lado, también resulta una serie interesante para todo aquel usuario de un entorno Big Data, ya que no todo va a ser analítica y movimiento de datos. Si no sabemos cómo funcionan estas herramientas, ni como están conectadas, cualquier problemática que surja implicará parar el trabajo y depender 100% de otros equipos.

¿Qué es y para qué necesitas una arquitectura Big Data?

Vamos a comenzar viendo por qué surgen estas arquitecturas, y las necesidades que viene a cubrir. Normalmente en este tipo de artículos de lo que más se habla es de sus tecnologías, sus características, ventajas e inconvenientes. Si comenzásemos de esta manera estaríamos adelantando la solución, cuando todavía ni tenemos definido el problema.

Challenges y necesidades de Arquitecturas Big Data

Veamos el por qué de estas arquitecturas y qué challenges del mundo del Big Data vienen a solucionar.

1. Tipos de los datos. ¿Cómo son tus fuentes? Datos estructurados, archivos, objetos, grafos… Si es una o varias fuentes. Latencia de los datos. Fuentes externas o internas. Ahora tenemos datos en muchos más formatos: archivos JSON, XML, video, audio, imágenes.
2. Evolución de las fuentes de datos. Ten en cuenta que tus fuentes de datos van a aumentar y a cambiar en unos meses o años. Piensa en posibles fuentes que puedas incorporar a tus sistemas en un futuro. Incluso te puede servir observar qué está haciendo la competencia, de donde saca los datos, conocer si tienen servicios de terceros contratados. Tu arquitectura tiene que ser escalable y flexible.
3. Integración de fuentes de datos: Las organizaciones a menudo tienen datos dispersos en diferentes sistemas y fuentes. Dependerá mucho del tamaño de la empresa. Cuanto más grande la compañía, mayor cantidad de fuentes de datos y más probable es la formación de silos de información. Una arquitectura de Big Data tiene que integrar todas estas fuentes para poder combinarlas cuando sea necesario.
4. Volumen de datos. Aquí ya no vale tener unas tablitas en un Data Warehouse. Hay que prepararse para lidiar con terabytes, petabytes y exabytes. La computación distribuida será tu mejor aliado. Tendrás que escoger sistemas de computación preparados para el procesado masivo de datos. Gracias a este tipo de herramientas vamos a poder utilizar los históricos de años de antigüedad.
5. Latencia y velocidad de procesado. Tienes que conocer en qué momento los consumidores necesitan los datos. Si es un monitoreo real-time, si tienen que analizar los datos del día anterior a primer hora, o si hay que actualizar alguna base de datos o algoritmo de Machine Learning en batches de una hora… Esto será determinante a la hora de diseñar tus pipelines de datos. Conoce quienes son tus consumidores.
6. Costes. Hay que realizar un plan de arquitectura (y evolutivos) que vaya de la mano con el presupuesto del departamento. El uso de herramientas en la nube, licencias y salarios implica un coste, que se puede optimizar con los conocimientos necesarios. El software open-source es de libre uso, pero el despliegue y mantenimiento implica un coste en horas de trabajo e infraestructura. Las plataformas Cloud nos pueden ahorrar ese tiempo a cambio de un precio. Como siempre, hay que encontrar el equilibrio entre tiempo y dinero.
7. Gobernanza. Cuando una empresa empieza a tener cierta cantidad de empleados y departamentos dedicados a trabajar con los datos, comienzan a surgir las ineficiencias, duplicidades y silos de información. Es por ello que se necesitan políticas de gobernanza de datos para mejorar los procesos, la integración, cultura y trazabilidad del dato.
8. Privacidad de los datos. ¿Ya sabes qué tipo de datos vas a manejar? ¿Son sensibles? Quizá no todos los miembros de la organización deberían acceder a todas las fuentes de datos. Debes diseñar políticas de explotación y acceso que garanticen la seguridad de los datos y la privacidad de los propietarios de los mismos, es decir, de tus usuarios.
9. Analítica avanzada: Con una arquitectura Big Data, las organizaciones van más allá de un análisis o una proyección de ventas, sino que existen técnicas avanzadas para clusterizar clientes, predicción de impagos, stock o la elaboración de dashboards de seguimiento del negocio en tiempo real. Son sólo algunos ejemplos del impacto de las nuevas herramientas de analítica que han surgido en los últimos años y que necesitan de una información estructurada y confiable.
10. Toma de decisiones basada en datos: Este es el punto más importante. ¿Para qué necesitamos gastarnos miles de euros en un entorno Big Data? Para poder tomar decisiones basadas en datos, en la realidad de tu negocio, y no en suposiciones.

Otros factores

Estos han sido los challenges más genéricos que tienen que afrontar las empresas cuando se enfrentan a un proyecto de Big Data. Ahora bien, habrá que tener en cuenta no solo estos factores, sino los contextuales de cada empresa o departamento, pues cada caso tiene sus recursos, procesos, cultura y normas.

1. Tamaño de la empresa. Tanto en la cantidad de desarrolladores que van a trabajar en procesos del entorno Big Data, como los consumidores de los datos. Normalmente en empresas pequeñas y medianas los empleados desempeñan parcialmente múltiples roles. Por otro lado, también es importante conocer el alcance geográfico de la compañía, por si hubiese que configurar replicación geográfica en los recursos del cloud.
2. Sector de la empresa. Tendrás que adaptar a tu empresa las arquitecturas estándares. Hay componentes en común, pero entre sectores hay una gran diferencia respecto al tipo, formato y maneras de presentar los datos. Empresas de banca o telco tienen mucha relación con el regulador, y por tanto gran cantidad de auditorias. Por tanto, la trazabilidad del dato, governanza y reporting son factores clave. O empresas de IoT, necesitan poner mucho foco en el real-time.
3. Expectativas. En primer lugar hay que tener claro qué es un entorno de Big Data y para qué lo vamos a usar. De lo contrario estaremos tirando el dinero en procesamiento en la nube, equipos y salarios/consultoría. Por otro lado, es fundamental llevar un roadmap, fijar unos objetivos con sus respectivos plazos, así como enseñar a los departamentos consumidores (y potenciales consumidores) de datos qué es un entorno Big Data y cómo les puede ayudar en su trabajo.
4. Cultura. La introducción de un Data Lake supone un gran cambio en las políticas y procesos de la empresa, sobre todo si tiene varias décadas de antigüedad. Esto no tiene por qué ser malo, sino que simplemente los cambios irán más lentos y requiere de un periodo de adaptación.
5. Migraciones. Lo más probable es que ya haya bases de datos montadas en la empresa, por lo que tendrás que enterarte bien de qué tipo son y cuál es el proveedor de BBDD, para poder adaptarlo o migrarlo al Data Lake.
6. Cloud vs On Premise. En algunos casos podría ser interesante on premise, pero lo normal es trabajar en la nube, particularmente si se trata de una arquitectura nueva. Va a aportar más flexibilidad, ahorro de costes, escalabilidad y cambios respecto al gasto (capex vs opex).
7. Equipos implicados. ¿Cuántas personas trabajarán con el Data Lake? ¿Qué departamentos se beneficiarán? Es fundamental para dimensionar los recursos y estimar el coste de salarios, servicios de consultoría, recursos cloud y licencias software. Por suerte, el escalado de recursos de IT se ha simplificado muchísimo con la nube.
8. Conocimientos y recursos humanos. Si ya tienes claro qué quieres montar, ¿quién lo va a montar? ¿quién lo va a explotar? ¿quién será el encargado de la automatización? De las ETLs, productivización de los modelos… ¿Qué conocimientos hace falta para todo esto? Una vez desplegada la solución, ¿cómo se va a documentar?

Estos serían los aspectos más importantes a tener en cuenta para cuando vayas a diseñar un Data Lake. No son pocos, y es importante mantener siempre el foco de lo que estamos desarrollando para que todo tenga un sentido y vayan todos los departamentos alineados.

¿Qué es una Arquitectura de Big Data?

Por tanto, una arquitectura de Big Data es una estructura y diseño organizado de sistemas y procesos que permiten la captura, almacenamiento, procesamiento y análisis eficiente de grandes volúmenes de datos, tanto estructurados como no estructurados, con el objetivo de obtener información valiosa y conocimiento significativo.

Una arquitectura de Big Data está diseñada para permitir a las organizaciones gestionar y aprovechar de manera efectiva los datos a gran escala, con el objetivo de tomar decisiones informadas, identificar patrones, tendencias y oportunidades, y mejorar su comprensión del entorno empresarial y del usuario.

Características de una Arquitectura Big Data

Características imprescindibles

Ya hemos visto qué especificaciones tenemos que cubrir cuando diseñamos una arquitectura Big Data. Veremos ahora las características técnicas que debería tener todo Data Lake para poder cubrir dichas necesidades.

1. Desacoplado. Divide y vencerás. Huimos de arquitecturas monolíticas, y pasamos a diseñar arquitecturas con múltiples componentes, aislados e independientes, que cumplan una función concreta y sin dependencias entre ellos. En un sistema desacoplado, se utilizan interfaces bien definidas y protocolos de comunicación estandarizados para permitir la interacción entre los componentes. Cada componente puede ser responsable de una función específica o de un conjunto de tareas.
2. Flexibilidad. Hay que reducir el número de dependencias lo máximo posible y facilitar la migración y el cambio de componentes. Utilizar tecnologías open source ayuda en la transición de tecnologías, ya que por ejemplo lenguajes como Python o R se pueden usar en una gran cantidad de herramientas de analítica y BI, por lo que desarrollar en estos lenguajes nos va a dar la flexibilidad de reutilizar el código ante un cambio de plataforma.
3. Escalabilidad. Tanto horizontal como vertical. El aumento en volumen de datos, de usuarios y de exigencia de cómputo debería tener el mínimo impacto en el rendimiento del Data Lake. Hoy en día podemos conseguir esto de una forma sencilla con el autoescalado en la nube.
4. Disponibilidad. Los datos y servicios ofrecidos en el Data Lake tienen que estar disponibles y funcionando un 99,99% del tiempo. Por tanto, debemos diseñar los sistemas anti caídas para que se recupere con el menor impacto posible. Al emplear arquitecturas desacopladas, tendremos servicios independientes por lo que el fallo en uno no tiene por qué afectar a los demás. Incluso hay recursos Big Data como el ecosistema de Hadoop y Spark que tienen protocolos de recuperación ante caídas, totalmente transparentes para el usuario.
5. Herramientas adecuadas. Existen una gran cantidad de herramientas de procesado, analítica, ingesta y monitorización, por lo que hay que estudiar muy bien las necesidades del Data Lake (volumen de los datos, variedad, perfiles de explotación, latencia y conexiones) a la hora de elegir tecnologías sin tener que pagar grandes facturas.
6. Gobierno del dato. Con el paso del tiempo la cantidad de datos de un Data Lake aumenta considerablemente, así como los miembros de la empresa que se quieren beneficiar de los mismos. Por tanto, es fundamental tener un sistema de gestión de los datos, de permisos, de privacidad de los datos, documentación y buscador de metadatos.
7. Serverless. Dicho de forma muy resumida, los servicios serverless que ofrecen las plataformas cloud se ocupan de toda la infraestructura, aprovisionamiento de recursos y escalabilidad automática, permitiendo al desarrollador focalizarse únicamente en el desarrollo de la aplicación. Supone una forma muy sencilla de desarrollar y desplegar aplicaciones en la nube, eliminando la necesidad de administrar la infraestructura subyacente.
8. Simplicidad. Menos es mas. Hay que intentar simplificar al máximo las arquitecturas para que sean más sencillas de entender, manejables y flexibles a la hora de realizar cambios. En ocasiones esto implica más costes, puesto que tecnologías como los orquestadores simplifican mucho la arquitectura, al tener una pieza central de comunicación y reparto de trabajo entre componentes. Centralizar todo en una nube, compartir librerías de código entre equipos, realizar comités del dato interdepartamentales o desarrollar una metodología de trabajo entre equipos, son algunas opciones para simplificar un Data Lake.

Cuando estés trabajando en una arquitectura de Big Data, estas serían las bases sobre las que tienes que apoyar los cimientos. Ahora bien, ¿son las únicas? Lo cierto es que no. Y va a depender de tu presupuesto, tipo de negocio y equipo de trabajo.

Características recomendables

A continuación se presentan algunas de las características de un entorno Big Data, que si bien no son las primeras en las que pensar cuando estemos desarrollando una arquitectura, sí que conviene tenerlas en cuenta tras ese primer MVP.

1. Real-time. Se trata de una necesidad concreta de un negocio. Empresas dedicadas al trading, o al IoT necesitan analizar los datos en ventanas temporales muy cortas, por lo que van a necesitar soluciones en la nube que les permita recibir una cola de mensajes y procesarlos en poco tiempo.
2. Monitoring. Toda aplicación automática debería tener un sistema de monitoreo y alertas. No es precisamente lo primero que se desarrolla cuando se crea un Data Lake, pero nos va a ahorrar mucho tiempo y quebraderos de cabeza cuando haya algún bug o problema con los datos del Data Lake. Igualmente ten en cuenta que todas las plataformas cloud tienen su propio sistema de logging y monitoring, que cubre perfectamente las necesidades básicas.
3. Dev-Ops. Es una metodología y cultura de trabajo que busca la integración y colaboración entre los equipos de desarrollo de software (Dev) y operaciones de IT (Ops). Este enfoque promueve la implementación ágil, la resolución rápida de problemas y la mejora continua, permitiendo un ciclo de desarrollo más eficiente y una mayor capacidad para adaptarse a los cambios y requisitos del negocio.

Obviamente cada empresa es un mundo y tendrán necesidades diferentes. Eso no quiere decir que las características de este apartado sean menos importantes que las del apartado anterior, pero quizá estas no sean tan prioritarias en un estado inicial del proyecto. Dependerá mucho del tamaño y recursos de la empresa. Hay que intentar mantener la arquitectura lo más simple posible, por lo que diseños sencillos con pocos componentes probablemente no necesiten de primeras un sistema de monitoreo ni un equipo de Dev-Ops.

¿Cuáles son los principales tipos de Arquitecturas Big Data?

La arquitectura Lambda y la arquitectura Kappa son dos enfoques para el procesamiento de datos.

Arquitectura Lambda

1. Batch y Stream Processing: En la arquitectura Lambda, los datos se procesan en dos flujos paralelos: uno para el procesamiento en batch y otro para el procesamiento en tiempo real. Esto permite manejar tanto datos históricos como eventos en tiempo real.
2. Almacenamiento: Los datos se almacenan en dos capas separadas: un almacenamiento de datos en bruto (data lake) y un almacén de procesamiento en tiempo real. Esto puede llevar a cierta duplicación de datos.
3. Procesamiento: En el procesamiento por lotes, se ejecutan tareas periódicas para procesar y transformar los datos en bruto en datos listos para el análisis. En el procesamiento en tiempo real, se utilizan sistemas como Apache Kafka para manejar flujos de eventos.
4. Complejidad: La arquitectura Lambda tiende a ser más compleja debido a la gestión de dos flujos de procesamiento y dos capas de almacenamiento.

Arquitectura Kappa

1. Stream Processing Único: En la arquitectura Kappa, los datos se procesan solo en tiempo real, eliminando la necesidad de procesamiento por lotes. Los datos se ingieren en un flujo continuo y se transforman a medida que fluyen.
2. Almacenamiento: Los datos se almacenan en un flujo continuo en un sistema de almacenamiento, como Apache Kafka, y se transforman en el momento de la ingestión.
3. Procesamiento: El procesamiento en tiempo real se realiza utilizando herramientas como Apache Kafka Streams o Apache Flink, permitiendo el análisis inmediato de eventos a medida que ocurren.
4. Simplicidad: La arquitectura Kappa tiende a ser más simple al eliminar la complejidad del procesamiento por lotes y las capas de almacenamiento separadas.

En resumen, la elección entre la arquitectura Lambda y la arquitectura Kappa depende de los requerimientos específicos del proyecto, la complejidad deseada y las necesidades de procesamiento en tiempo real. Cada enfoque tiene sus ventajas y desafíos, y la elección dependerá de factores como la escala del proyecto, los recursos disponibles y los objetivos de análisis de datos.

Profesionales implicados

Para trabajar con un Data Lake serán necesarias mínimo dos personas. Una encargándose de la implementación de recursos y diseño de la arquitectura, y la otra del negocio y pipelines de datos. Ahora bien, en una empresa grande esto no es viable, pues los procesos se multiplican y se necesitan más personas, con perfiles mucho más especializados. Veamos los principales profesionales que van a trabajar con el Data Lake.

Data Architect o Big Data Architect

Juega un papel crucial en el diseño de la estructura y la arquitectura del entorno de almacenamiento de datos. El Data Architect es responsable de definir la forma en que los datos serán adquiridos, almacenados, organizados y accedidos en el Data Lake. Esto incluye determinar el esquema de datos, establecer estándares de nomenclatura, definir las políticas de seguridad y privacidad de los datos, y garantizar la integridad y calidad de los datos. Además, el Data Architect colabora estrechamente con otros roles, como científicos de datos y desarrolladores, para entender las necesidades y requerimientos de la organización y garantizar que el Data Lake cumpla con las demandas de análisis y utilización de datos de manera eficiente y efectiva.

Cloud Solutions Architect

Diseña e implementa soluciones de almacenamiento y procesamiento de datos en la nube. El Cloud Solutions Architect trabaja en estrecha colaboración con los equipos de datos y los arquitectos para identificar las necesidades específicas del Data Lake y desarrollar una arquitectura óptima basada en servicios en la nube. Esto implica seleccionar las tecnologías y servicios adecuados de la nube, como almacenamiento escalable, bases de datos NoSQL, servicios de procesamiento en lotes o en tiempo real, y herramientas de orquestación y monitoreo. El Cloud Solutions Architect también se encarga de garantizar la seguridad, el rendimiento, la escalabilidad y la eficiencia de la solución, así como de optimizar los costos y brindar asesoramiento técnico continuo para mejorar y mantener el Data Lake en la nube.

Data Engineer

Diseña, desarrolla y mantiene la infraestructura y los sistemas necesarios para la gestión eficiente de los datos. El Data Engineer es responsable de construir y mantener los pipelines de datos, que implican la extracción, transformación y carga (ETL) de datos desde diversas fuentes hacia el Data Lake.

Visita nuestro itinerario a seguir para adquirir las competencias necesarias de un Data Engineer.

Data Scientist.

Se enfoca en explorar, analizar y extraer conocimientos valiosos de los datos almacenados en el lago. El Data Scientist utiliza técnicas avanzadas de análisis de datos, aprendizaje automático y estadísticas para descubrir patrones, tendencias y relaciones ocultas en los datos. Su objetivo principal es utilizar estos conocimientos para generar información y tomar decisiones fundamentadas en los datos.

Machine Learning Engineer.

Se centra en desarrollar y desplegar modelos de aprendizaje automático basados en los datos almacenados en el lago. El Machine Learning Engineer trabaja en estrecha colaboración con los equipos de datos y científicos de datos para construir, entrenar y optimizar modelos de aprendizaje automático utilizando algoritmos y técnicas avanzadas.

Data Analyst

Analiza los datos almacenados en el lago para extraer información valiosa y generar insights. Trabaja en colaboración con otros equipos, como científicos de datos y desarrolladores, para comprender las necesidades de análisis, definir métricas y KPIs relevantes, y realizar análisis ad hoc o recurrentes.

Data Steward

Se enfoca en garantizar la calidad, integridad y gobernabilidad de los datos almacenados en el lago. El Data Steward es responsable de establecer y mantener las políticas, estándares y procedimientos para la gestión de datos. El Data Steward se encarga de la documentación y el catálogo de los datos, asegura la seguridad y la privacidad de los datos sensibles, y realiza actividades de monitoreo y control para prevenir la proliferación de datos duplicados o incorrectos.

Se trata de los más habituales que podemos encontrar en un Data Lake, y con los años se han ido especializando más. Algunos que hemos dejado de lado sería el DataBase Admin, DevOps Engineer o el MLOps, entre otros.

Utiliza LinkedIn y Glassdor para ver la demanda y salarios de estos empleos

En este primer capítulo de la serie de Arquitecturas de Big Data hemos visto las necesidades que hay detrás de una infraestructura compleja como es un Data Lake, cómo tiene que ser un Data Lake y los perfiles que trabajan con esta solución.

SIGUIENTE EPISODIO – Te recomendamos que continúes tu travesía por las Arquitecturas de Big Data con nuestro artículo de principales componentes de un Data Lake.