Data Lake, Data Warehouse, Data Mesh y Data Lakehouse son conceptos relacionados con el diseño, gestión, explotación y almacenamiento de datos, y cada uno tiene sus propias características y enfoques. En este artículo vamos a describir estas arquitecturas de Big Data, analizando sus pros y sus contras, comparándolas en un cuadro resumen, para entender mejor las principales diferencias entre ambas. Adicionalmente, veremos también otros puntos importantes como qué es un Datamart o para qué se usan los Delta Lake.
Este artículo forma parte de nuestra serie donde te contamos todo lo que necesitas saber para diseñar e implementar Arquitecturas Big Data.
Si quieres más información sobre arquitecturas Big Data, te recomiendo que te leas nuestros artículos de introducción a las arquitecturas Big Data y de componentes de una arquitectura Big Data.
Data Lake
Un Data Lake es un repositorio de almacenamiento centralizado que almacena grandes volúmenes de datos en su formato original, ya sea estructurado, semi-estructurado o no estructurado. Los datos se almacenan sin procesar, y se pueden acceder y analizar de diversas formas, como análisis en tiempo real, análisis avanzado y Machine Learning. Los Data Lakes están desarrollados mediante Hadoop u otras tecnologías de alta escalabilidad en la nube, que permiten almacenar altos volúmenes de data a un precio económico.
La filosofía del Data Lake reside en la ingesta de todos los datos posibles en crudo, sin ninguna estructura o esquema. Esto permite acumular mucha más información proveniente de todas las fuentes digitales de la empresa como una app móvil, web, redes sociales, IoT y fuentes externas. Se ingesta toda la información de manera centralizada, lo que provoca que la compañía pueda obtener una visión 360 del cliente, favoreciendo que exista un único punto de acceso a los datos en toda la organización.
A diferencia de un Data Warehouse, el Data Lake tiene un schema on-read, es decir, descubrimos la estructura de los datos cuando los explotamos, y no en la escritura, como ocurriría en el Data Warehouse, donde hay que diseñar previamente el schema de los datos (schema on-write).
Otro de los beneficios que aporta este enfoque es que las diferentes unidades de negocio pueden establecer estandarizaciones y transformaciones, dependiendo de sus necesidades. No como en un Data Warehouse tradicional, donde los usuarios están limitados a un esquema, y unas únicas transformaciones, agregaciones y estandarizaciones ya aplicadas previamente en los datos en el momento de la escritura. Profesionales como los Machine Learning Engineers necesitan contar con todo el histórico de datos en crudo y con la traza del dato, cosa que se pierde con un Data Warehouse.
Ventajas
- Flexibilidad. Permite almacenar datos con esquemas flexibles, lo que facilita la adaptación a cambios en los requisitos de datos.
- Escalabilidad. Es altamente escalable, y puede manejar grandes volúmenes de datos en constante crecimiento.
- Históricos. Permite la incorporación de gran cantidad de datos desagregados históricos, necesarios para analíticas avanzadas y Machine Learning.
- Integración de datos. Permite almacenar datos de diferentes fuentes y formatos en un único repositorio, facilitando la integración y el acceso a los datos, tanto estructurados, como semiestructurados y desestructurados.
- Costes. El almacenamiento es mucho más económico que en el caso de un Data Warehouse tradicional, a pesar de que la cantidad de datos a almacenar es mucho mayor.
- Real time. La integración de sistemas de almacenaje open source (como Hadoop) en entornos de nube, facilita el poder combinarlas con tecnologías de colas de mensajes y de real-time.
Inconvenientes
- Calidad de datos. Almacenar datos sin procesar puede resultar en problemas de calidad de datos, como datos duplicados o inconsistentes. Y corremos el riesgo de convertir el lago en un pantano.
- Complejidad. La gestión de un Data Lake puede ser compleja, especialmente cuando se trata de mantener la calidad y seguridad de los datos. Igualmente cada análisis de datos implica schema on read, es decir, un mayor trabajo de desarrollo de los Data Scientist, en comparación con un esquema de datos estructurado.
- Creación de silos. Si se deja libre albedrío en el uso del Data Lake, particularmente en empresas grandes con muchos departamentos, cada departamento tenderá a realizar sus analíticas, a aplicar sus filtros, y en definitiva a tener sus propios datos, lo que provoca grandes inconsistencias, pues una métrica de negocio será diferente dependiendo de qué equipo la calcule. Una buena gestión del gobierno del dato es fundamental.
- Seguridad. Al no ser una tecnología madura, como el caso de los DWH, la seguridad en el acceso y en la privacidad de los datos no siempre estará incluida en el Data Lake y tendremos que desarrollar nuestras propias políticas.
En el fondo, un Data Lake no deja de ser en esencia un almacén de datos, sin inteligencia de negocio, pero con mucha más flexibilidad y escalabilidad. En muchas ocasiones lo comparamos con otras herramientas más ligadas al BI, como puede ser un Data Warehouse, con esquemas y datos más estructurados y cercanos a dar respuestas a preguntas de negocio, pero un Data Lake no es más que una capa de almacenaje de datos, previa a otras más complejas, por lo que en raras ocasiones va a convivir el Data Lake en solitario, sin otras capas posteriores para estructurar la información, de cara a su explotación por parte de perfiles no técnicos. A no ser que se utilice únicamente como plataforma analítica para los Data Scientist.
Data Lake vs CPD
Son conceptos bastante diferentes pero que la gente los suele confundir. Un CPD es un lugar físico donde se aloja la infraestructura tecnológica de una organización, mientras que un Data Lake es un enfoque de almacenamiento de datos que permite una gestión más eficiente y escalable de grandes volúmenes de datos en su formato original.
Data Warehouse
Un Data Warehouse (DWH) es una base de datos centralizada que recopila, almacena y gestiona datos históricos y consolidados de diversas fuentes dentro de una organización. Su principal objetivo es proporcionar un entorno optimizado para el análisis y generación de informes, permitiendo a los usuarios acceder y consultar datos de manera eficiente para obtener insights y respaldar la toma de decisiones.
Durante años un data warehouse se ha estado alojando en un servidor corporativo, aunque cada vez se utiliza más la nube. Los datos de diferentes aplicaciones de procesamiento de transacciones (OLTP) y otras fuentes de datos se vuelcan en el DWH y se utilizan posteriormente en aplicaciones analíticas y de consultas por usuarios.
Un Data Warehouse sólo almacena datos que han sido modelados o estructurados, a diferencia de otros sitemas de almacenamiento como el Data Lake, donde se guarda el dato directamente en crudo. Además, el Data Warehouse proporciona un schema on write, es decir, diseña las estructuras de los datos antes de escribirlos en el Data Warehouse, de tal forma que cuando vienen datos nuevos, se tienen que ajustar al schema ya previamente diseñado.
Ventajas
- Datos limpios y estructurados. Los datos en un Data Warehouse suelen estar limpios, estructurados y listos para su análisis.
- Mejora del rendimiento. Al almacenar datos consolidados, el rendimiento de las consultas de análisis puede ser más rápido.
- Facilidad de uso. Los Data Warehouses están diseñados para análisis y generación de informes, lo que facilita el acceso y el análisis de datos para usuarios no técnicos.
- Seguridad. El Data Warehouse existe desde hace décadas, por lo que la capacidad de asegurar los datos en un Data Warehouse es mucho más madura que asegurar datos en un Data Lake.
Inconvenientes
- Flexibilidad. Los Data Warehouses suelen tener una estructura fija, lo que puede dificultar la adaptación a cambios en los requisitos de datos.
- Tiempo en la implementación. Lógicamente, al tener los datos perfectamente estructurados para poder responder rápidamente a las preguntas de negocio, requiere de un tiempo de desarrollo importante, al que se sumará el de mantenimiento y cambio en las estructuras de datos.
- Real-time. No son las fuentes de datos más indicadas para trabajar en real-time.
- Escalabilidad. Puede ser más difícil escalar un Data Warehouse para manejar grandes volúmenes de datos en constante crecimiento, por no hablar de las actualizaciones en los schemas, debido a los cambios en sus fuentes de datos.
- Coste. En comparación con las otras soluciones vistas en este artículo, los Data Warehouse son de pago en muchas ocasiones y los formatos de almacenaje no están hechos para compresiones óptimas de información, por lo que el coste de almacenamiento se encarece.
- Datos no estructurados. Los DWH trabajan con datos transaccionales, tabulares, por lo que resulta difícil ingresas de datos semi y desestructurados, aunque hay productos de DBMS que sí incluyen algunos de estos formatos.
Se ha estado trabajando muy bien con los DWH durante muchos años, pero las nuevas necesidades del Big Data provocan que el DWH se quede desactualizado y se tienda a otro tipo de soluciones más escalables, flexibles y económicas.
Data Mart
Derivado del Data Warehouse, tendríamos los Data Marts, que son bases de datos diseñados para una línea de negocio en particular. Se pueden tener data marts separados para ventas, inventario y compras, por ejemplo, y los usuarios finales pueden acceder a datos de uno o de todos los data marts del departamento.
Data Mesh
Data Mesh supone “la democratización de los datos”: ofrecer a cualquiera de los usuarios de datos de la empresa su acceso de forma rápida, así como una colaboración entre equipos más fluida.
Data Mesh es un enfoque arquitectónico emergente para la gestión de datos en el que la responsabilidad de los datos se distribuye entre los equipos de dominio (es decir, departamentos, unidades de negocio, etc.) en lugar de ser centralizada en una única infraestructura de datos. En vez de construir un único y monolítico Data Warehouse o Data Lake, Data Mesh promueve la idea de que cada equipo de dominio es dueño de sus propios datos, cuenta con un equipo de profesionales que se van a encargar de crear productos de datos y tiene la responsabilidad de definir, gestionar y compartir los datos relevantes para su dominio específico.
El Data Mesh jerarquiza los niveles de datos y, a su vez, hace los procesos más rápidos para las necesidades digitales que demanda el mercado. El objetivo es lograr que cada “producto de datos” sea descubierto y utilizable por los consumidores y otros equipos de dominio.
De esta forma, en un Data Mesh quedarían separados por dominios los datos de ventas, finanzas, RRHH, marketing y otros departamentos. Todos ellos tendrían accesibles los datos de unos y otros si así lo requieren, pero de forma instantánea, cada departamento podría acceder a su información y satisfacer necesidades inmediatas de forma mucho más ágil que mediante otro proceso data.
Es necesario para ello que sean los miembros de cada dominio quienes definan las reglas sobre las políticas, los accesos y el tratamiento que se le dan a los datos que consumen y producen, de forma que no solo tengan la disponibilidad de los datos, sino también su control.
Los dominios deben ser autodescriptivos e interoperables. Descentralización no debe ser sinónimo de aislamiento: que cada dominio pueda actuar con independencia solo es posible si se hace bajo unas reglas comunes que permitan la interoperabilidad y el entendimiento entre ellos. Para ello son necesarios glosarios, controles de accesos y unos estándares previos globales para todos.
Ventajas
- Descentralización de la gestión de datos. Con Data Mesh, los equipos de dominio tienen más autonomía y control sobre sus propios datos, lo que facilita la toma de decisiones y el desarrollo ágil.
- Ventajas del Data Lake. Real time, flexibilidad, escalabilidad, coste reducido del almacenamiento e integración de datos.
- Empoderamiento de equipos. Permite que los equipos de dominio tengan control sobre sus propios datos, lo que puede fomentar la responsabilidad y la propiedad.
- Escalabilidad y flexibilidad. A medida que la organización crece y se agregan nuevos equipos, el enfoque Data Mesh puede escalar de manera más eficiente, permitiendo la incorporación de nuevos datos y dominios sin afectar el rendimiento global.
- Mayor agilidad en el desarrollo. Data Mesh puede acelerar el desarrollo y la implementación de nuevas funcionalidades, ya que cada equipo puede trabajar de manera independiente y tomar decisiones rápidas sobre cómo gestionar sus datos.
- Infraestructura como servicio. Que todo sea “autoservicio” hace que nos olvidemos para siempre de las tecnologías complejas y las habilidades de nicho. El Data mesh se basa, por principio, en una gestión de datos mediante una plataforma común y un conjunto de herramientas que cualquier equipo de dominio pueda aprovechar.
Inconvenientes
- Complejidad de coordinación. La descentralización de la gestión de datos puede introducir cierta complejidad en la coordinación entre los equipos de dominio, especialmente cuando se trata de compartir datos entre diferentes dominios.
- Consistencia de datos. Garantizar la consistencia y calidad de los datos entre diferentes equipos puede ser un desafío, especialmente cuando los datos se comparten y utilizan en varios dominios, lo que provoca la aparición de silos de información.
- Necesidad de estándares. Para que Data Mesh funcione eficientemente, es necesario establecer estándares y prácticas compartidas para la gestión de datos, lo que puede requerir una planificación y acuerdo cuidadosos entre los equipos. Esta rigidez contrarrestaría parcialmente la flexibilidad característica del Data Mesh.
- Coste. Implementar una arquitectura Data Mesh puede requerir inversiones en tecnologías y plataformas de datos para permitir la colaboración y el intercambio de datos entre equipos.
La democratización de los datos y el dato como producto son dos enfoques muy interesantes que aporta el Data Mesh, dándole protagonismo al dato y creando equipos y procesos especializados en cada dominio. Esto va a ayudar a agilizar mucho los procesos y escalar mejor la arquitectura de datos empresarial. Ahora bien, este enfoque se aplica en empresas de gran volumen donde tiene sentido que exista un equipo de datos en cada dominio, y hay que ser cauteloso pues resulta muy fácil que surjan silos de información, por lo que aplicar políticas de gobernabilidad, tanto de datos, como de sus productos, es clave para que el Data Mesh tenga éxito.
Data Lakehouse
Un Data Lakehouse es un enfoque que combina las capacidades de un Data Lake y un Data Warehouse, aprovechando la flexibilidad del primero y la estructura y rendimiento del segundo. Es una integración más estrecha entre ambos conceptos para mejorar el acceso y análisis de datos.
El Data Lakehouse reduce la duplicidad de datos al proporcionar una única plataforma de almacenamiento de datos multiusos para satisfacer todas las demandas de datos comerciales.
Los Data Scientists usan técnicas de análisis en Data Lakes para analizar datos no estructurados, mientras que los analistas de BI usan un Data Warehouse. Un Data Lakehouse ayuda a ambos equipos a trabajar en un repositorio único y compartido. Esto ayuda a reducir los data silos.
Un Data Lakehouse reduce los costos de almacenamiento mediante el uso de clústeres que se ejecutan en hardware económico. Puede ofrecer almacenamiento de datos en un clúster y ejecución de consultas en un clúster separado. Este desacoplamiento de procesamiento y almacenamiento puede ayudar a aprovechar al máximo los recursos.
Ventajas
- Flexibilidad en el esquema. Al igual que un Data Lake, el Data Lakehouse permite almacenar datos en su formato original y esquemas flexibles, lo que facilita la incorporación de nuevos tipos de datos sin necesidad de reestructuración.
- Ventajas del Data Lake. Real time, flexibilidad, escalabilidad, coste reducido del almacenamiento e integración de datos.
- Rendimiento optimizado. Aprovecha las características de rendimiento de un Data Warehouse, permitiendo consultas rápidas y eficientes sobre datos estructurados y semiestructurados.
- Análisis avanzado. Al combinar datos estructurados y no estructurados en un mismo repositorio, el Data Lakehouse ofrece oportunidades para análisis avanzados, como aprendizaje automático e inteligencia artificial.
- Costo-efectividad. Al utilizar una única plataforma para almacenar y analizar datos, el Data Lakehouse puede ofrecer una solución más económica en comparación con mantener sistemas separados.
Inconvenientes
- Complejidad de implementación. La integración de características de Data Lake y Data Warehouse puede requerir una planificación cuidadosa y una implementación técnica más compleja.
- Mantenimiento. El Data Lakehouse necesita una gestión adecuada para asegurar la calidad de datos y evitar problemas de duplicación o inconsistencias.
- Escalabilidad. Aunque el Data Lakehouse puede ofrecer ventajas de rendimiento, la escalabilidad puede ser un desafío cuando se enfrenta a grandes volúmenes de datos en crecimiento constante.
- Requerimientos técnicos. Implementar un Data Lakehouse puede requerir conocimientos técnicos sólidos y la selección de tecnologías adecuadas para optimizar el almacenamiento y análisis de datos.
El Data Lake resulta muy útil para poder trabajar con información desestructurada y desarrollar sistemas escalables compatibles con terabytes y hexabytes de datos, pero la falta de estructura provoca que los desarrollos de productos de datos se ralenticen mucho. Con un Data Lakehouse reducimos estos tiempos al tener unos datos ya estructurados, basados en todas las fuentes de datos ingestadas en el Data Lake y que sirve para que perfiles no tan técnicos puedan utilizar estos datos.
Comparativa
| Características | Data Warehouse | Data Lake | Data Mesh | Data Lakehouse |
|---|---|---|---|---|
| Rendimiento | Bueno, pero con datos estructurados y volúmenes controlados | Alto | Alto | Alto |
| Escalabilidad | Pobre | Escalabale al fundamentarse en tecnologías Big Data | Escalabale, mayor agilidad en el desarrollo | Escalable, aunque la capa estructurada puede ser problemática |
| Flexibilidad | Poca, trabaja con esquemas muy rígidos | Gran flexibilidad al trabajar con los datos en crudo | Gran flexibilidad tanto en los propios datos como en el desarrollo de productos de datos | Flexibilidad al contar con todos los datos, tener una capa estructurada para todos los dominios pero con dificultades cuando haya que modificar la capa estructurada |
| Datos Estructurados | Trabaja con datos principalmente transaccionales y estructurados | Punto débil del Data Lake, pues si no se controla, se puede convertir en un pantano | Mejora respecto al Data Lake, pues los dominios crean sus propias estructuras | Si, cuenta con una capa en el Data Lake de datos estructurados que agiliza los desarrollos |
| Datos Desestructurados | No es el más adecuado para trabajar con datos semi y desestructurados | Si, cuenta con todos los datos en crudo, estructurados, semi y desestructurados | Si, cuenta con todos los datos en crudo, estructurados, semi y desestructurados, aunque dependerá del nivel de abstracción que se le quiera dar a cada dominio | Si, cuenta con todos los datos en crudo, estructurados, semi y desestructurados |
| Real time | No son los más indicados para el real time | Si | Si | Si |
| Tiempo desarrollo | Medio, schema on read | Medio, sin embargo la explotación es más costosa que un DWH al tener schema on read | Requiere de recursos, sobre todo al principio, pues cada dominio realiza sus propios desarrollos y hay que coordinarlos bien | Requiere de un tiempo de desarrollo inicial extra al tener que montar la capa estructurada y metadatada del Data Lake |
| Analítica avanzada/IA | Por rendimiento y funcionalidades, no son los más adecuados para trabajar con Machine Learning | Puede trabajar en algoritmos avanzados de IA y Machine Learning | Puede trabajar en algoritmos avanzados de IA y Machine Learning | Puede trabajar en algoritmos avanzados de IA y Machine Learning |
| Históricos | Pobre | Cuenta con históricos | Cuenta con históricos | Cuenta con históricos |
| Data Governance | Al tener un schema on write y una estructura fija, no es necesario implementar muchas políticas de Data Governance | Es necesario establecer políticas de Data Governance para asegurar datos de calidad | Es clave un buen gobierno de los datos para que no se formen silos | Al tener datos estructurados en el Data Lake, no requiere de tantas políticas como en otros casos, aunque siguen siendo importantes |
| Centralización/Dominios | Todos los dominios trabajan sobre el DWH | Todos los dominios trabajan sobre el Data Lake. Como el schema es on read, fomenta la aparición de silos | Tiene todos los datos en un Data Lake, pero luego la explotación del dato se divide en equipos de dominio | Todos los dominios trabajan sobre los mismos datos |
| Facilidad de uso | Si, perfiles no técnicos | No, es necesario un perfil técnico para su explotación | Son necesarios perfiles no técnicos en cada dominio, pero con el objetivo de que sea más sencilla la explotación del dominio | Mejora con respecto al Data Lake tradicional al introducir una capa de datos estructurados, lo que permite la explotación tanto a perfil técnico como a no técnico |
| Seguridad | Si, aspecto maduro e integrado en esta tecnología | No está madura y es necesario aplicar políticas de seguridad | Se establecen políticas de seguridad con más sentido que en el Data Lake, pues los responsables de cada dominio son expertos en esos datos | No está madura y es necesario aplicar políticas de seguridad |
| Coste | Elevado el almacenamiento, medio la explotación | Almacenamiento barato y explotación medio | Almacenamiento barato, elevado coste de desarrollo | Almacenamiento barato, elevado coste de desarrollo |
| Mantenimiento | Muy cómodo de mantener, hasta que hay que cambiar el schema | Complejo de mantener | Puede haber complejidad en la gestión de los equipos | Complejidad a la hora de modificar sus datos estructurados |
Como toda elección en recursos de IT, no existe la solución perfecta, sino que tendremos que orientarnos por las necesidades de nuestro proyecto, entender bien nuestras especificaciones, y una vez lo tengamos claro, elegir la arquitectura que mejor se ajuste.
Si queremos trabajar con históricos de datos, datos estructurados, semiestructurados y desestructurados, está claro que hay que utilizar un Data Lake, ya sea en la modalidad pura de Data Lake, Data Mesh o Data Lakehouse. Un DWS no va a encajar pues se alimenta de datos transaccionales estructurados.
En caso de ser una empresa pequeña con apenas departamentos, quizá un DWS o un Data Lake puro puede ser la mejor solución, pues en el caso del Data Mesh y Dara Lakehouse, hay que realizar muchos más desarrollos y no se va a contar con los recursos ni para los desarrollos ni para la explotación. DWH será interesante en caso de contar con poco equipo técnico, mientras que el Data Lake resultará más interesante si la mayoría de las personas a explotar el dato son Data Scientist o Data Engineers, pues requiere de desarrollos complejos.
Si lo que tenemos es una gran compañía, con procesos complejos, muchos empleados que requieran del uso del dato, y varios departamentos, un Data Mesh o un Data Lakehouse sería lo ideal. Cobrará ventaja un Data Mesh respecto a un Data Lakehouse siempre y cuando se haga una buena inversión en políticas de Data Governance, destinadas a compartir, controlar y securizar recursos y productos de datos entre los diferentes dominios. Un Data Mesh tiene un enfoque muy orientado a la democratización del dato y la especialización de los profesionales no en tecnología, sino en el dominio del dato, lo cual tiene bastante sentido para que los productos de datos los realicen auténticos expertos en esos datos. Ahora bien, la aparición de silos de información es altamente probable, por lo que las políticas de Data Governance son fundamentales.
Un Data Lakehouse es la evolución natural del Data Lake. Una vez están montadas todas las ingestas sobre un Data Lake, habrá que introducir una capa de estructura y metadatado para agilizar los procesos posteriores de analítica y BI, de tal forma que no se produzcan duplicidad de procesos.
Tanto Data Mesh como Data Lakehouse son dos soluciones que normalmente resultan más interesantes que el simple Data Lake, pues aportan una capa de negocio y estructura, lo que posibilita posteriormente agilizar los desarrollos y permitir que empleados no tan técnicos, como podría ser un Data Analyst, un Business Analyst o un Manager, beneficiarse de los datos del Data Lake.
Hay muchas diferencias entre el Data Lake, Data Warehouse, Data Mesh y Data Lakehouse, por lo que analiza muy bien tu caso de negocio, estructura organizacional, presupuesto, cloud de la empresa y capacidades de los equipos para tomar la decisión correcta a la hora de escoger una arquitectura.
SIGUIENTE EPISODIO – Te recomendamos que continúes tu travesía por las Arquitecturas de Big Data con nuestro artículo de Ingesta de Datos en un Data Lake.
Bibliografía
https://www.powerdata.es/data-warehouse
Pingback: We Learn Data
Pingback: We Learn Data