Data Lake, otra de esas palabras que últimamente están de moda. Y lo peor de todo es que mucha gente asocia esta palabra a un concepto equivocado:

¡Un Data Lake no es un DataWarehouse!

Un Data Lake puede ser un complemento perfecto para un DataWarehouse, pero no debería ser un sustituto de este, principalmente porque cada uno de ellos está optimizado para propósitos distintos, y sus usuarios finales, por norma, también van a ser perfiles distintos. De hecho, ambos pueden ser términos totalmente opuestos: mientras que un DataWarehouse está muy bien estructurado y con información limpia y procesada, un Data Lake puede ser “un caos” tanto a nivel estructural como de contenido.

Llegados a este punto, nos preguntamos entonces qué papel juega el Data Lake en esto del BI, y en donde lo podemos posicionar dentro de la arquitectura de este.

Un posible ejemplo de arquitectura que haga uso de un Data Lake podría ser el siguiente:

Como se puede observar en la imagen, un Data Lake lo podemos situar a dos niveles dentro de la arquitectura. Por un lado, puede ser, al igual que un área de Staging, la antesala de un DataWarehouse, pero por otro puede contener también información que proviene del DataWarehouse.

Una vez que tenemos claro el qué y el dónde, lo que nos debemos preguntar realmente es ¿lo necesito?, ¿me puede aportar algo que no aporten mi DataWarehouse o mi área de Staging?

A la hora de abordar la implementación de una arquitectura “Modern Data Warehouse” debemos tener en cuenta las siguientes consideraciones:

  1. Tener suficiente conocimiento y nivel de madurez:

Debemos tener la capacidad de autoanálisis para saber si realmente necesitamos un datalake, si dispones de multitud de fuentes de datos desestructurados que pueden ser valiosos a la hora de analizar datos, o si la capacidad de almacenamiento (o procesado) de tu actual Data Warehouse se está viendo comprometida o supone grandes costes, es muy probable que sea beneficioso implementar un Data Lake. Este sería un buen principio o puerta de entrada a la hora de decidirse a usar un Data Lake aunque hay muchos más casos de uso en los que es beneficioso.

 

  1. Mantenimiento de varios componentes y tecnologías diferentes:

Este tipo de ecosistemas suele estar compuesto por una variedad amplia de diferentes tecnologías, por lo que implantar una solución de este tipo conllevará un gasto en contratación de servicios en la nube (procesamiento y almacenamiento).

 

  1. Disponer de perfiles técnicos capacitados:

Es necesario disponer de personal capacitado, o formar al personal en estas nuevas tecnologías, es muy fácil cometer errores a la hora de diseñar la estrategia de flujo de información o de diseño de la arquitectura. Necesitaremos el apoyo de ingenieros de datos, arquitectos y probablemente científicos de datos.

 

  1. Saber lidiar con el mantenimiento de diferentes tecnologías e interfaces ETL/ELT

Definir bien como se mueve la información es clave y en este aspecto los procesos ETL y ELT son primordiales, debemos tener la información necesaria en el lugar necesario (y evidentemente en el momento “necesario”), ¿debo mover datos estructurados al datalake?, ¿puedo usar el Data Lake como área de staging para mi DW? Debemos responder preguntas como esta y muchas otras cuya implementación supondrá un esfuerzo en trabajo y servicios.

 

  1. Gobierno del dato, especialmente en el Data Lake y herramientas como los notebooks:

La definición de políticas de gobierno del dato suele ser muy beneficioso para tener claro el origen y la calidad de los datos. qué es cada cosa, de donde sale y quien tiene acceso.

En ocasiones definir políticas de restricción de acceso a datos en un Data Lake no es algo trivial y debemos tenerlo en cuenta.

 

Algunas de las cuestiones que trataremos en la charla de este SolidQ Summit 2020 serán las siguientes:

En qué Casos debo migrar datos estructurados a un DL antes de ser volcados a un DW, algunos de los escenarios en los que puede ser beneficioso este movimiento son:

  • Querer descargar el procesado de los datos al Data Lake (normalmente basado en tecnología Hadoop), para que el procesamiento y el espacio en el EDW se reduzca, y se evite chocar con la gente que hace consultas en el EDW.
  • Si nos es beneficioso usar alguna de las tecnologías/herramientas de Hadoop para refinar datos, ya que hacen esta tarea más rápido y mejor que su EDW. Por ejemplo, para reprocesar grandes volúmenes de datos de stock se podrían crear tareas en paralelo en el Data Lake en función de agrupaciones de tiendas u otro atributo y de este modo se podrían reajustar los datos de forma más eficiente en menos tiempo.
  • El Data Lake puede ingerir grandes archivos rápidamente y proporcionar redundancia de datos. ¿Lo necesita?… adelante!
  • Los trabajos del ELT en el DW están tardando demasiado debido al aumento de los volúmenes de datos y el aumento de la tasa de ingestión, por lo que descargar algunos de ellos al datalake puede ser beneficioso. Es posible que necesite una arquitectura Lambda.

  • El Data Lake es un buen lugar para los datos que «podría» usar en el futuro. Puedes almacenarlos en el Data Lake y hacer que los usuarios usen SQL a través de PolyBase para mirar los datos y determinar si tienen valor.  Tenga en cuenta que PolyBase permite a los usuarios finales consultar los datos en un Data Lake utilizando SQL normal, por lo que no es necesario que aprendan ninguna tecnología relacionada con el Hadoop.  PolyBase incluso permite al usuario final usar cualquier herramienta de reporte que use SQL, para unir datos en una base de datos relacional con datos en un cluster Hadoop.
  • Tener una copia de seguridad de los datos en bruto en caso de que necesite cargarlos de nuevo debido a un error de ETL (y no tener que volver a la fuente). Puedes mantener un largo historial de datos sin procesar en el Data Lake.
  • Si tiene usuarios avanzados/científicos de datos pueden hacer uso de los datos estructurados en el Data Lake (generalmente combinándolos con datos no relacionales).
  • Como una forma más rápida de cargar datos en el Azure SQL Data Warehouse a través de PolyBase desde el Data Lake (que suele ser mucho más rápido que usar SSIS para copiar desde la fuente al Azure SQL Data Warehouse “Synapse”).

Tenga en cuenta también que hay que valorar estos beneficios en contra posición con el trabajo extra que requiere el exportar los datos de una fuente relacional a un formato como CSV, luego copiarlos al Data Lake (donde pueden limpiarse con herramientas como databricks y luego moverse al DW).

También hay que tener en cuenta que los datos relacionales que se mueven al lago de datos perderán los metadatos como tipos de datos, restricciones, claves externas…

Otra opción, si es necesario tener los datos relacionales en el datalake, es la de hacer cargas incrementales en el DataWarehouse y una vez allí, mover estos datos ya actualizados al Data Lake mediante algún proceso ETL o mediante databricks con spark (en el caso de que dispongamos de Azure Synapse como EDW)

Esperamos que este artículo os haya sido de utilidad.

Alfonso Carreira y Chema Pérez.

DPA’s at SolidQ

X Edición Executive Máster en BI & Advanced Analytics con Tecnologías Microsoft. Conviértete en un año en un experto en BI con un seguimiento personalizado de los mentores y MVPs de SolidQ y con el nuevo temariodel máster en BI & Advanced Analytics , introduciendo Modern Data Warehouse, analítica y visualización avanzada. ¡Empezamos en octubre! Inscríbete ahora y aprovecha el descuento que hay disponible hasta finales de julio o completar inscripciones. Toda la información aquí.