Arquitectura del Lago de Datos: Cómo crear un Data Lake bien diseñado

Los lagos de datos son depósitos de almacenamiento para grandes volúmenes de datos. Sin duda, una de las mayores características de esta solución es el hecho de poder almacenar en ella todos los datos en formato nativo. Por ejemplo, puede interesarle la ingestión de

  • Datos operativos (ventas, finanzas, inventario)
  • Datos generados automáticamente (dispositivos IoT, registros)
  • Datos generados por humanos (publicaciones en redes sociales, correos electrónicos, contenido web) ya sea que provengan del interior o del exterior de la organización.

Capas

Podemos pensar en los lagos de datos como repositorios únicos. Sin embargo, tenemos la flexibilidad de dividirlos en capas separadas. Por nuestra experiencia, podemos distinguir entre 3 y 5 capas que pueden aplicarse a la mayoría de los casos.

Estas capas son:

  • Crudo (Raw)
  • Estandarizado (Standarized)
  • Limpiado (Cleansed)
  • Aplicación (Application)
  • Sandbox
Hosting Elástico

Sin embargo, las opciones estandarizadas y Sandbox se consideran opcionales en la mayoría de las implantaciones. Profundicemos en los detalles para ayudarte a entender su propósito.

  • Capa de datos Raw – también llamada capa de ingestión/área de aterrizaje, porque es literalmente el sumidero de nuestro Data Lake. El objetivo principal es ingerir los datos en crudo de la forma más rápida y eficiente posible. Para ello, los datos deben permanecer en su formato nativo. No permitimos ninguna transformación en esta fase. Con Raw, podemos volver a un punto en el tiempo, ya que el archivo se mantiene. No se permite la anulación, lo que significa manejar duplicados y diferentes versiones de los mismos datos. A pesar de permitir lo anterior, Raw sigue necesitando ser organizado en carpetas. Por nuestra experiencia, aconsejamos a los clientes que empiecen con una división genérica: área temática/fuente de datos/objeto/año/mes/día de ingesta/datos en bruto. Es importante mencionar que los usuarios finales no deberían tener acceso a esta capa. Los datos aquí no están listos para ser utilizados, requieren mucho conocimiento en términos de consumo apropiado y relevante; también por temas de seguridad, puede contener datos personales al no estás enmascarados o ofuscados. Raw es bastante similar a la conocida puesta en escena de Data Warehouse o almacén de datos.
  • Capa de datos estandarizada – puede ser considerada como opcional en la mayoría de las implementaciones. Si prevemos que nuestro Data Lake crecerá rápidamente, esta es la dirección correcta. El objetivo principal de esta capa es mejorar el rendimiento en la transferencia de datos de Raw a Curated. Se incluyen tanto las transformaciones diarias como las cargas bajo demanda. Mientras que en Raw los datos se almacenan en su formato nativo, en Standardized elegimos el formato que mejor se adapte a la limpieza. La estructura es la misma que en la capa anterior, pero se puede particionar a grano más fino si es necesario.
  • Capa de datos depurada/limpiada – también llamada Capa Curada/Capa Formada. Los datos se transforman en conjuntos de datos consumibles y pueden almacenarse en archivos o tablas. El propósito de los datos, así como su estructura en esta etapa ya se conoce. Es de esperar que la limpieza y las transformaciones se realicen antes de esta capa. También es habitual la desnormalización y consolidación de diferentes objetos. Debido a todo lo anterior, esta es la parte más compleja de toda la solución de Data Lake. En cuanto a la organización de los datos, la estructura es bastante simple y sencilla. Por ejemplo: Propósito/Tipo/Archivos. Normalmente, los usuarios finales sólo tienen acceso a esta capa.
  • Capa de datos de la aplicación – también llamada capa de confianza/capa de seguridad/capa de producción, obtenida dela capa limpiada y reforzada con cualquier lógica de negocio necesaria. Puede tratarse de claves sustitutas compartidas entre la aplicación, seguridad a nivel de fila o cualquier otra cosa que sea específica para la aplicación que consume esta capa. Si alguna de sus aplicaciones utiliza modelos de aprendizaje automático que se calculan en su lago de datos, también los obtendrá de aquí. La estructura de los datos seguirá siendo la misma, como en la capa depurada.
  • Capa de datos Sandbox – también llamada capa de autoservicio. Es otra capa que podría considerarse opcional, está pensada para el trabajo de analistas avanzados y científicos de datos. Aquí pueden llevar a cabo sus experimentos cuando buscan patrones o correlaciones. Siempre que tenga una idea para enriquecer sus datos con cualquier fuente de Internet, Sandbox es el lugar adecuado para ello.

Mientras los datos fluyen a través del Lago, se puede pensar en él como un paso más del procesamiento lógico de datos.

Imagen cedida de https://lingarogroup.com/

Componentes importantes

Ya que hemos cubierto las partes más vitales de los Data Lakes, sus capas; ahora podemos pasar a los otros componentes lógicos que crean nuestra solución. Veamos el siguiente diagrama:

  • Seguridad – aunque no vayas a exponer los Data Lakes a un público amplio, sigue siendo muy importante que pienses bien este aspecto, especialmente durante la fase inicial y la arquitectura. No es como las bases de datos relacionales, con una artillería de mecanismos de seguridad. Tenga cuidado y nunca subestime este aspecto.
  • Gobernanza – las operaciones de supervisión y registro (o linaje) serán cruciales en algún momento para medir el rendimiento y ajustar el Data Lake.
  • Metadatos – datos sobre los datos, así que principalmente todos los esquemas, los intervalos de recarga, las descripciones adicionales del propósito de los datos, con descripciones sobre cómo se pretende utilizarlos.
  • Administración – dependiendo de la escala que pueda necesitar, ya sea un equipo separado (rol) o delegar esta responsabilidad a los propietarios (usuarios), posiblemente a través de algunas soluciones de metadatos.
  • Datos maestros – una parte esencial de los datos listos para su uso. Necesita encontrar una manera de almacenar sus MD en el Lago de Datos, o referenciarlos mientras se ejecutan los procesos de ELT.
  • Archivo – en caso de que tenga una solución DWH relacional adicional. Es posible que se enfrente a algunos problemas relacionados con el rendimiento y el almacenamiento en esta área. Los Data Lakes se utilizan a menudo para mantener algunos datos de archivo que provienen originalmente del DWH.
  • Offload – y de nuevo, en caso de que tenga otras soluciones DWH relacionales, puede que quiera usar esta área para descargar algunos procesos ETL que consumen tiempo/recursos a su Data Lake, lo que puede ser mucho más barato y rápido.
  • Orquestación + procesos de ETL – como los datos están siendo empujados desde la capa cruda, a través de la capa limpiada a la caja de arena y la capa de aplicación, usted necesita una herramienta para orquestar el flujo. Lo más probable es que tenga que aplicar transformaciones. O bien elige una herramienta de orquestación capaz de hacerlo, o bien necesita algunos recursos adicionales para ejecutarlas.
Imagen cedida de https://lingarogroup.com/

Otros aspectos importantes

Puede que pienses en los lagos de datos como el Santo Grial del almacenamiento autoorganizado. He oído muchas veces “ingerimos y ya está”. De hecho, la realidad es otra y con este enfoque acabaremos con algo llamado Data Swamp (pantano). Literalmente, es una implementación de almacenamiento de Data Lake, pero que carece de una clara división de capas o de otros componentes comentados en el artículo. Con el tiempo se vuelve tan desordenado, que obtener los datos que buscamos es casi imposible. No debemos restar importancia a la seguridad, la gobernanza, la administración, los metadatos y la gestión de datos maestros. Un enfoque bien planificado del diseño de estas áreas es esencial para cualquier implementación de Data Lake. Animo a todos a pensar en la estructura deseada con la que les gustaría trabajar. Por otro lado, ser demasiado estricto en estas áreas provocará el Desierto de Datos (lo contrario al Pantano de Datos). El Lago de Datos en sí mismo debería ser más una forma de capacitar a la gente, en lugar de regular en exceso.

La mayoría de los problemas anteriores pueden resolverse planificando la estructura deseada dentro de las capas de su Lago de Datos y poniendo a cargo a propietarios de confianza. Por nuestra experiencia, vemos que la organización de los Data Lakes puede estar influenciada por

  • La partición del tiempo
  • Patrones de carga de datos (Tiempo real, Streaming, Incremental, Carga completa, Una sola vez)
  • Áreas temáticas/fuentes
  • Límites de seguridad
  • Aplicación/propósito/usos descendentes
  • Propietario/responsabilidad
  • Políticas de retención (temporal, permanente, por tiempo determinado)
  • Impacto empresarial (crítico, alto, medio, bajo)
  • Clasificación confidencial (información pública, uso interno solamente, información confidencial de proveedores/socios, información personal identificable, sensible – financiera)

Resumen

Para resumir, vamos a repasar los objetivos principales, lo que debe conseguir la implementación de cualquier Data Lake. Con los conocimientos anteriores, su explicación va a ser sencilla:

  • Las 3 v’s (Velocidad, Variedad, Volumen) – Podemos operar con una variedad de datos, de gran volumen, con una velocidad increíble. El hecho importante es que la velocidad se refiere aquí no sólo al tiempo de procesamiento, sino también al tiempo de valor, ya que es más fácil construir prototipos y explorar los datos.
  • Reducir el esfuerzo de ingesta de datos (Raw Layer) – retrasar el trabajo de planificación del esquema y la creación de modelos hasta que se conozca el valor de los datos.
  • Facilitar escenarios de análisis avanzados – nuevos casos de uso con nuevos tipos de datos. Empezar los MVP con datos que están listos para ser utilizados. Esto ahorra tiempo y dinero.
  • Almacenar grandes volúmenes de datos de forma rentable – No es necesario pensar si los datos se van a utilizar, se pueden almacenar por si acaso. Los datos gobernados y gestionados adecuadamente pueden recogerse hasta el día en que nos demos cuenta de que pueden ser útiles.