Big Data vs Data Warehouse
En este artículo descubrirás cómo implementar soluciones de data warehousing moderno en cloud, haciendo un recorrido por todas las capas, desde los procesos ELT que realizan la ingesta de datos en origen en un data lake, pasando por diferentes estados de calidad y gobernabilidad del dato, hasta finalizar en un data warehouse corporativo optimizado para grandes volúmenes de datos.
Durante años, el mundo del data warehousing ha ido adaptándose a las necesidades que iban surgiendo utilizando diferentes estrategias como la escalabilidad vertical de los servidores, el particionamiento o la propia evolución de los modelos de datos (estrella, copo de nieve, data vault…), todo para poder ir haciendo frente a los diferentes escenarios que el creciente volumen de datos iba proponiendo. Sin embargo, la explosión de las tecnologías big data y la nube nos han permitido evolucionar más allá de simplemente añadir más capacidad a los sistemas tradicionales.
Arquitectura Data Warehouse en la nube
Ante esta situación, hoy en día encontramos soluciones adaptadas para poder construir un datawarehouse moderno con total garantía de éxito. Para alcanzar dicho éxito tenemos que alejarnos un poco de las mejoras a nivel de estructura de datos en el propio modelo (que sigue siendo importantísimo) y plantear cambios directamente en la arquitectura del procesamiento y almacenamiento de los datos.
Las piezas que intervienen en esta nueva arquitectura de procesamiento y almacenamiento de datos para data warehouse son las siguientes:
- Capa de origen: esta capa siempre contiene piezas “externas” al modelo, ya que su heterogeneidad hace que en este punto se puedan insertar diferentes piezas de distintas índoles como podrían ser, además de las que se muestran en la imagen, logs, fotos, diferentes bases de datos (sql data warehouse, postgres, Elastic, Mongo, Casandra…), xmls, etc.
- Capa de ingesta y procesamiento: la potencia que nos ofrece spark para el procesamiento masivo en paralelo se hace imprescindible en esta capa, ya que el volumen de datos a tratar es posible que sea muy elevado. Esta capa interactúa con la siguiente de manera cíclica para poder ir procesando los datos, modelandolos y aportandoles calidad.
- Capa de almacenamiento: la utilización en esta capa de un sistema de archivos como DataLake nos proporcionará varias ventajas (profundizaremos en este punto más adelante).
- Capa de servicio: en esta capa es crucial contar con una base de datos optimizada para data warehouse que nos permita almacenar los datos particionados y distribuidos en diferentes nodos para procesar consultas, utilizando paralelismo y que la velocidad de respuesta sea la mínima posible. Además, también se debe contar con alguna herramienta que permita explotar los datos del DWH para crear informes y dashboards.
La importancia del Data Lake
Como hemos comentado antes, vamos a hablar de la importancia de construir un buen Data Lake como repositorio de datos. En una arquitectura clásica de DWH, existían diferentes capas dentro de la propia base de datos que nos permitían almacenar datos sin adaptarlos al modelo específico para DWH, como pueden ser las capas de ODS (Operational Data Store) o de Staging. Dichas capas, en un DWH moderno son sustituidas por el Data Lake, lo cual conlleva varias ventajas:
- Al tratase de un sistema de archivos es más rápido acceder a su información, ya que se pueden usar herramientas de procesamiento en paralelo.
- La utilización del mismo como repositorio de datos, teniendo así un único punto centralizado donde se encuentran todos los datos de la compañía.
- Derivado del punto anterior, otra ventaja es que hace que se produzca un cambio importante en la ingesta de archivos conforme a la forma “clásica”, donde los procesos seguían una estructura ETL (Extract-Transform-Load). Sin embargo, ahora gracias al uso del Data Lake como repositorio de datos, se utiliza la forma ELT (Extract-Load-Transform) ya que es posible dejar los ficheros sin formatear ni normalizar en el Data Lake y luego realizar transformaciones sobre ellos, así sobrecargamos lo menos posible los sistemas de origen.
- Poder dar acceso a dicho repositorio a diferentes aplicaciones o personal de la compañía (data scientists) para poder explotar dichos datos.
- Al tratarse de un sistema de archivos, también es más barato el coste de almacenamiento que en una base de datos.
- Nos permite crear niveles de organización de los datos según su calidad y madurez.
Centrémonos en este último punto, ya que el hecho de poder estructurar distintos niveles de madurez del dato nos va a permitir asegurar mejor que la información que llegará al usuario final es fiable.
En este caso, hemos identificado tres niveles distintos de madurez que siguen los siguientes criterios:
- Nivel 1 – Raw: este primer nivel almacenará los datos en crudo, tal y como vienen en sus sistemas de origen.
- Nivel 2 – Common: en el segundo nivel es donde se le aplicarán a los datos las reglas de calidad y gobierno del dato que se definan, para poder obtener así fuentes fiables de información.
- Nivel 3 – Trusted: en el último nivel estarán los datos ya modelados, con las reglas de calidad pasadas (evitando los valores nulos o mal informados, por ejemplo), lo que permitirá acceder a los mismos de manera fácil y estructurada para hacer análisis de los mismos
Debido a la implementación de dichos niveles, la arquitectura requiere, como comentábamos antes, de una interacción cíclica entre esta capa de almacenamiento en Data Lake y la capa de procesamiento con Spark.
Conclusiones
Hemos repasado a grandes rasgos los cambios y evoluciones que el mundo del Data Warehouse ha tenido que ir dando para adaptarse a las particularidades que el Big Data ha traído al mundo de la tecnología. Gracias a estas adaptaciones podemos hoy en día construir un DWH con la seguridad de que va a ser fiable, seguro y rápido, una garantía de éxito.
* Nota 1. Para este artículo hemos simplificado la arquitectura a lo más básico posible. Podríamos aumentar la complejidad de la misma metiendo más herramientas para tratamiento de eventos en tiempo real por ejemplo, herramientas de gobernanza de datos, herramientas para hacer cubos OLAP en la capa de servicios, etc.
* Nota 2. Como podéis ver, hemos utilizando las herramientas de Azure para este ejemplo concreto, pero cada nube tiene herramientas específicas que podrían sustituirse por las de Azure para obtener los mismos resultados. Incluso también podría hacerse con herramientas on-premises.
