Construye tu plataforma de bigdata con la solución Galeo Data platform

Galeo, impulsado por la creciente demanda de las plataformas de datos en la nube, ha diseñado una solución con servicios de Azure, fácil de gestionar, escalable y con software de código abierto para aquellos servicios no generalizados entre los proveedores de la nube. La arquitectura está diseñada para soportar cualquier reto o caso de uso que se presente en el futuro.

En este post os vamos a detallar los diferentes componentes de la arquitectura, sus funcionalidades y las tecnologías utilizadas.

1. EXTRACCIÓN desde diferentes fuentes

Dentro de una plataforma de datos, las fuentes pueden ser muy diversas dependiendo de cada caso de uso.

Podemos encontrarnos eventos, que pueden estar entrando en streaming desde dispositivos físicos o desde una base de datos propia a través de un CDC. Una arquitectura basada en eventos se basa en el principio de publicación-suscripción. Los mensajes son enviados una vez a un tema y podemos tener N suscriptores consumiendo ese mismo mensaje. Los productores y los consumidores están totalmente desacoplados.

Podemos tener fuentes de datos que entrarían más en el mundo batch o micro-batch, como una extracción masiva de una base de datos, un CRM, SAP, etc. o cualquier tipo de consulta periódica a APIs.

2. BATCH INGESTION AND STREAMING

2.1 Streaming Ingestion

Aquí las casuísticas dependerían principalmente de la fuente de datos y del caso de uso en concreto. Por ejemplo, podemos tener entradas de datos en streaming desde un CDC como Debezium, que es un proyecto open-source que nos permite detectar y transmitir en forma de eventos los cambios en una base de datos, así como cualquier otro conector desarrollado por Galeo o de cualquier otro proveedor.

Para esto se elige Azure Kubernetes Services, ya que nos aporta:

  • Escalabilidad
  • Aislamiento de aplicaciones
  • Facilidades para el despliegue
  • Alta disponibilidad
  • Capacidad de probar nuevas tecnologías fuera del ámbito Azure

Para eventos producidos por dispositivos IoT, nuestro punto de partida sería el Azure IoT Hub gracias a su fácil integración con otros recursos de Azure como Azure Event Hub, Azure Event Grid o Azure Logic Apps.

Una vez tenemos la carga inicial en streaming realizada, nuestros eventos pasarían a un gestor de mensajería basado en temas como Azure Event Hub:

  • Escalable, en función del rendimiento y su necesidad de uso
  • Seguro, ya que protege los datos en tiempo real.
  • Con posibilidad de particionar los mensajes por una clave en particiones

2.2 Batch Ingestion

Para el mundo batch, se ha elegido Databricks para la gran mayoría de casos motivados por:
La facilidad de gestión que tiene

  • La facilidad de gestión que tiene
  • Aceleración del desarrollo en Spark gracias a notebooks como herramienta de apoyo
  • Su motor de SQL, así como la posterior posibilidad de trabajar en tablas Delta, que soluciona el eterno problema de las actualizaciones de datos intra-partición en los data lakes.
  • Programar cargas de trabajo (Jobs) que se ejecutan en clusters dedicados para ello, que tienen un coste mucho menor que los clusters interactivos para el desarrollo.
  • Reutilización del recurso para distintos perfiles (Data Engineers, SQL Analysts, ML Engineers)

Hay en casos, como las extracciones nativas de Office 365 o actividades puntuales de copia de datos, en los que también podría utilizarse Azure Data Factory.

3. LAKE HOUSE

Es la piedra angular de una plataforma de datos, aquí converge toda la información, nuestros inputs depositan los datos en crudo (raw data) para posteriormente ser leídos, transformados y procesados en una solución final.

El Lake House nos permite guardar la siguiente información:

  • Datos estructurados (relacionales, SQL).
  • Datos semi-estructurados (No-SQL).
  • Datos no estructurados o binarios (documentos, vídeo, imágenes).

Nuestra elección dentro del ecosistema Azure ha sido el servicio de Azure Data Lake Storage Gen2. Este recurso nos arroja bastantes funcionalidades:

  • Espacio de nombres jerárquico: esta diferencia frente al Blob Storage clásico nos permite una optimización significativa del trabajo con macrodatos en herramientas como Hive, Spark, etc… A su vez, la disminución de la latencia de trabajo equivale a la reducción del coste.
  • Acceso compatible con Hadoop: esto nos permite montar un sistema de archivos distribuido de Hadoop (HDFS).
  • Permisos POSIX: nos da la posibilidad de definir un modelo de seguridad compatible con los permisos de ACL y POSIX a nivel de directorio o archivo.
  • Volumen: es capaz de almacenar y procesar gran cantidad de datos, con una latencia baja.

Azure Data Lake Storage Gen2 junto con Databricks, nos da la posibilidad de tener nuestro Lake House con tablas en formato Delta. ¿Qué ventajas nos da esto?

  • Transacciones ACID (Atomic, Consistent, Isolated, Durable): esto garantiza la coherencia con las partes que leen o escriben datos al mismo tiempo.
  • Schema Evolution: admite la evolución y cumplimiento del esquema, admitiendo arquitecturas de esquema DW como los de estrella/copo de nieve.
  • Time Travel: versionado de tablas. Como un repositorio de código, los usuarios pueden tener versiones de sus datos cada vez que el conjunto de datos cambie.
  • Compatibilidad con diversos tipos de datos, desde datos no estructurados hasta datos estructurados.
  • Soporte para herramientas BI: nos permite usar herramientas directamente en los datos de origen.

Como no necesitamos un metastore compartido, utilizaremos el Hive Metastore propio de Databricks para persistir la metadata de las tablas Delta.

Dividiremos nuestros datos a su vez, en tres capas:

  • Zona de bronce: aquí convergen los datos en raw tanto de la parte de streaming como de la parte batch.
  • Silver zone: se limpian y procesan las tablas para poder dejarlas consultables (proceso de normalizado).
  • Zona dorada: aquí depositamos las tablas agregadas que contienen el cálculo de los KPIs de cada caso de uso.

Añadido a esto, utilizaremos la herramienta DBT, desplegada sobre nuestro AKS. DBT es una herramienta para organizar y documentar las transformaciones realizadas sobre nuestra Lake House. La forma en la que opera es la siguiente:

  • Cada consulta es un modelo. Por ejemplo «SELECT A, B FROM LAKE_DATA».
  • Este modelo se puede materializar en una tabla o una vista.
  • A esta tabla o vista, le corresponde un bloque de documentación para asociar la descripción de la consulta, la descripción de cada campo y tests sobre los datos.

En DBT, con Spark, podemos tener modelos incrementales sobre las tablas, ya sea insertando nuevos registros (append) o sobreescribiendo estos(insert_overwrite), ya sea sobre una partición o sobre la tabla entera.

Utilizando las tablas Delta, tenemos un tipo de modelo más, el cual puede actualizar registros antiguos e insertar nuevos a la vez(merge), basado en una clave única(unique_key).

4. DATA WAREHOUSE

Un Datawarehouse es un repositorio unificado para los datos que se recogen de los diversos sistemas de una empresa.

En nuestra arquitectura utilizamos Snowflake como herramienta auxiliar al Lake House para cargar ahí los datos que deben ser leídos desde Power BI.

Databricks posee un conector nativo para Power BI con tablas Delta, pero no es suficientemente operativo si no tienes el clúster levantado constantemente, ya que cada vez que necesites actualizar los datos, vas a tener que esperar el cluster up time y poner un low auto-off time para no estar generando sobrecoste por cada actualización que hagas.

Existe también la posibilidad de montar un SQL Endpoint, con los mismos problemas comentados anteriormente. Seguiríamos necesitando un serverless data warehouse o tener un endpoint cluster siempre activo, a menos que se desarrolle una versión serverless de esta función en Azure.

Snowflake, en cambio, tiene la ventaja de ser serverless y los datos de nuestras tablas Delta pueden ser transformados y cargados fácilmente desde Databricks.

5. DATA STORAGE

5.1 Low Latency & operational

Para operaciones que requieren de una latencia muy baja, con una gran cantidad de consultas de datos concretos en tiempo real, utilizamos las bases de datos No-SQL.
Dependiendo del caso de uso, podemos utilizar Redis Cache o CosmosDB.

¿Qué es Azure Cosmos DB?

Es un servicio de base de datos NoSQL totalmente administrado, creado para un rendimiento rápido y predecible, alta disponibilidad, escalabilidad elástica, distribución global y facilidad de desarrollo.

¿Qué es Redis?

Es una base de datos en memoria que persiste en el disco. Es un avanzado almacén open source key-value. A menudo se le denomina servidor de estructura de datos, ya que las claves pueden contener cadenas, hashes, listas, etc.

Como comentábamos, dependería del caso de uso concreto. En cuanto a tema de costes, Redis suele ser más barato que CosmosDB, sobre todo cuando hay muchas transacciones, ya que Redis factura por tamaño de caché y cantidad de nodos, mientras que CosmosDB factura por rendimiento (Request Unit per second).

6. Visualización (Web App)

Dependiendo de nuestro caso de uso, podemos tener un servicio web y una herramienta de reporting como Power BI. Aunque estos dos recursos pueden convivir perfectamente, teniendo un servicio web que sólo sea accesible por determinados usuarios, donde puedan realizarse, por ejemplo, actividades sobre otros recursos de Azure a través de llamadas API y también tenga un apartado de visualización de informes que salgan de Power BI.

Nuestra solución elegiría el despliegue de la parte web sobre nuestro AKS, aprovechando:

  • Hiper Escalabilidad.
  • Control total sobre las máquinas virtuales.
  • Uso de herramientas como Apache Kudu, que es una herramienta de código abierto que ofrece lecturas de baja latencia junto con patrones de acceso analítico eficientes sobre datos estructurados. Además, puede utilizarse junto a Apache Spark para acceder a los datos.
  • Bajo coste respecto al App Service de Azure.

Para almacenar los metadatos y tokens de cualquiera de nuestras aplicaciones, ya sea de la web o de cualquier recurso que lo necesite, utilizaremos un pequeño PostgreSQL.

7. CATÁLOGO y calidad del dato

Cada vez es más importante disponer de un catálogo de datos dentro de una gran plataforma. Los datos ofrecen cada vez más oportunidades para las estrategias empresariales. Sin embargo, a menudo el escaso conocimiento de los datos y su falta de disponibilidad impiden a los usuarios aprovechar al máximo su valor. Un catálogo de datos pretende llenar este vacío.
Hemos elegido DataHub para esto gracias a:

  • Búsqueda end-to-end: capacidad de integrarse con bases de datos, datalakes, plataformas de BI, ETLs, etc.
  • Comprensión sencilla del recorrido de los datos de un extremo a otro gracias a sus dashboards.
  • Proporciona perfiles de conjuntos de datos para comprender cómo ha evolucionado ese conjunto de datos en el tiempo.
  • Gobernanza de datos y controles de acceso.
  • Análisis de uso de la plataforma.

Además de esto, utilizaremos Great Expectations para validar, documentar y perfilar nuestros datos. Great Expectations nos brinda la posibilidad de automatizar pruebas para detectar problemas de datos rápidamente, son básicamente pruebas unitarias. Aparte de esto, también podemos crear documentación e informes de calidad a partir de esas expectativas. Es bastante útil para monitorizar ETLs que adquieren datos en un Datalake o Datawarehouse.

Estas herramientas serían desplegadas en nuestro AKS junto con los conectores de entrada, DBT, el PostgreSQL para los metadatos, la web y todas las demás herramientas open source necesarias de desplegar en un futuro.

Si quieres saber más sobre la solución o deseas ver una demo, nuestros expertos estarán encantados de atenderte.

Llámanos al teléfono +34 665 22 35 67