¿Qué es un Data Lake y por qué es importante?

Un Data Lake es un repositorio de almacenamiento que contiene grandes cantidades de datos en bruto en su formato nativo. Como resultado, los usuarios de la empresa pueden acceder rápidamente a ella siempre que lo necesiten y los científicos de datos pueden aplicar analítica para obtener información. A diferencia de su primo mayor -el data warehouse-, un Data Lake es ideal para almacenar big data no estructurado, como tweets, imágenes, voz y datos en streaming. Pero puede utilizarse para almacenar todo tipo de datos: cualquier fuente, cualquier tamaño, cualquier velocidad, cualquier estructura.

Algunos de los formatos de información almacenada en los Data Lakes son:

• Datos estructurados, como las filas y columnas de las tablas de las bases de datos relacionales.
• Datos semi estructurados, como archivos de texto plano delimitados y archivos con esquemas.
• Datos no estructurados entre los que se incluyen los contenidos de las redes sociales y los datos del Internet de las cosas (IoT), así como documentos, imágenes, voz y vídeo.

Historia de los Data Lakes: Dónde empezó todo

Las primeras versiones de lo que ahora llamamos lagos de datos fueron pioneras en los abrevaderos del elefante amarillo: Hadoop. Cuando se lanzó por la primera vez, Hadoop era una colección de software de código abierto que se utilizaba para el almacenamiento distribuido, el procesamiento y el análisis de big data. Resulta especialmente útil para las nuevas fuentes de datos semiestructurados y no estructurados, que cada vez son más frecuentes. Los lagos de datos también se utilizaron para ampliar los datos estructurados cuyos volúmenes aumentaban rápidamente.

Desgraciadamente, la primera comunicaciones en torno a Hadoop decían que se podía incluir arbitrariamente cualquier cantidad de datos a un data lake y luego dejar que los usuarios se las arreglaran. Múltiples fracasos demostraron que ese enfoque era erróneo. Algunos de los primeros usuarios vieron cómo sus Data lakes se convertían rápidamente en vertederos mal gestionados y sin control, parecidos más a pantanos o ciénagas de datos. Esto dio lugar a:

• La redundancia, que sesga los resultados analíticos.
• Datos no auditables, de los que nadie se fía.
• El escaso rendimiento de las consultas, que acabó con los primeros objetivos del Data lake: la exploración y el descubrimiento de alto rendimiento.

Estos primeros lagos de datos, desorganizados e indocumentados, eran casi imposibles de navegar.El etiquetado de los metadatos evolucionó hasta convertirse en una de las prácticas de gestión de los lagos de datos más esenciales, ya que facilitaba la localización de los datos en el lago. La gobernanza del lago de datos mejoró su auditabilidad y fiabilidad, verificando su utilidad para más aplicaciones empresariales.

Las tecnologías y metodologías utilizadas para implementar un Data lake han mejorado con el tiempo. Ahora incluyen no sólo Hadoop, sino también otras tecnologías tradicionales y de big data.  

Más allá de la información inicial

A medida que el bombo de los primeros Data lakes se desvaneció, un Data lake dejó de ser confundido con una plataforma de datos. En su lugar, se reconoció como un contenedor para múltiples colecciones de datos variados que coexisten en un lugar conveniente.

Hoy en día, los Data lakes se incluyen formalmente en las estrategias de datos y analítica de las empresas. Las organizaciones reconocen que el término Data lake se refiere sólo a una parte del ecosistema empresarial, que incluye:

• Sistemas fuente.
• Pipeline de ingestión.
• Tecnologías de integración y tratamiento de datos.
• Bases de datos.
• Metadatos.
• Motores analíticos.
• Capas de acceso a los datos.

Para ser una plataforma de Business Intelligence completa que genere un alto valor de negocio, un Data lake requiere integración, limpieza, gestión de metadatos y gobernanza. Las organizaciones líderes están adoptando este enfoque holístico de la gestión del Data lake. Como resultado, pueden utilizar la analítica para correlacionar diversos datos de diversas fuentes en diversas estructuras. Esto significa que la empresa puede recurrir a una información más completa para tomar decisiones.

¿Por qué son importantes los Data Lakes? 

Dado que un Data lake puede incorporar rápidamente todo tipo de datos nuevos, al tiempo que proporciona acceso, exploración y visualización en autoservicio, las empresas pueden ver y responder más rápido sobre la nueva información. Además, tienen acceso a datos que no podían obtener en el pasado.

Estos nuevos tipos y fuentes de datos están disponibles para el descubrimiento de datos, pruebas de concepto, visualización y analítica avanzada. Por ejemplo, un Data lake es la fuente de datos más común para el machine learning, técnica que suele aplicarse a los archivos de registro, los datos de clics de sitios web, el contenido de las redes sociales, los sensores de transmisión y los datos procedentes de otros dispositivos conectados a Internet.

Muchas empresas llevan tiempo deseando poder realizar estas exploraciones orientadas al descubrimiento, analítica avanzada e informes. Un Data lake proporciona rápidamente la escala y la diversidad de datos necesarias para ello. También puede ser un punto de consolidación tanto para big data como para los datos tradicionales, permitiendo correlaciones analíticas entre todos los datos.

Aunque normalmente se utiliza para almacenar datos en bruto, un Data lake también puede almacenar algunos de los datos intermedios o totalmente transformados, reestructurados o agregados producidos por un data warehouse y sus procesos posteriores. Esto suele hacerse para reducir el tiempo que los científicos de datos deben dedicar a las tareas comunes de preparación de datos.

El mismo enfoque se utiliza a veces para ocultar o anonimizar la información personal identificable (PII) u otros datos sensibles que no son necesarios para el análisis. Esto ayuda a las empresas a cumplir con las políticas de seguridad y privacidad de los datos. Los controles de acceso son otro método que las empresas pueden utilizar para mantener la seguridad.

Lago de datos vs. almacén de datos

¿Qué se debe tener en cuenta al comparar un data lake y un data warehouse? Una de las principales consideraciones está relacionada con el diseño, o esquema, del almacén de datos.

Las bases de datos relacionales y otros almacenes de datos estructurados utilizan un diseño basado en esquemas. Esto significa que cualquier dato que se añada a ellos debe ajustarse o transformarse en la estructura predefinida por su esquema. El esquema está alineado con los requisitos empresariales asociados para usos específicos. El ejemplo sencillo de este tipo de diseño es un data warehouse.

Un Data lake, en cambio, utiliza un diseño basado en datos. Esto permite una rápida asimilación de nuevos datos antes de que se definan las estructuras de datos y los requisitos empresariales para su uso. A veces, los Data lakes y los data warehouse se diferencian por los términos, esquema de escritura (data warehouse) frente a esquema de lectura (data lake).

• El esquema de escritura (data warehouse) limita o ralentiza la inserción de nuevos datos. Está diseñado con un propósito específico sobre uso de los datos, así como metadatos específicos asociados. Sin embargo, la mayoría de los datos pueden servir para múltiples propósitos.
• Esquema de lectura (data lake) conserva los datos en bruto, lo que permite reutilizarlos fácilmente. También permite asignar múltiples etiquetas de metadatos para los mismos datos.

Al no estar restringido a una única estructura, un Data lake puede dar cabida a datos multi estructurados para una misma área temática. Por ejemplo, los data lakes pueden mezclar las transacciones de ventas estructuradas con los sentimientos de los clientes no estructurados. Y como se centra en el almacenamiento, un data lake requiere menos potencia de procesamiento que un data warehouse. Los data lakes también son mucho más fáciles, rápidos y menos costosos de escalar en el tiempo.

Una de las desventajas de un data lake es que sus datos no están estandarizados, no están duplicados, no tienen control de calidad ni están transformados. En respuesta, algunas personas han adoptado una tendencia a utilizar los data lakes de forma diferente. Pueden proporcionar una zona nueva y mejorada para el aterrizaje y la puesta en escena de los datos antes de que se preparen, integren y transformen para cargarlos en el data awrehouse.

Estos ejemplos ilustran por qué un data lake no sustituye a un data warehouse, sino que lo complementa. Además de utilizarse como zonas de descanso, los data lakes también pueden servir de archivo. En este caso, los datos obsoletos se archivan pero se mantienen fácilmente accesibles para la auditoría y el análisis histórico.

Los data lakes en sus inicios: Una inmersión más profunda

Los primeros data lakes utilizaban el sistema de archivos distribuidos Hadoop (HDFS), de código abierto, como marco para almacenar datos en muchos dispositivos de almacenamiento diferentes como si se tratara de un único archivo. HDFS funcionaba junto con MapReduce como marco de procesamiento de datos y gestión de recursos que dividía las grandes tareas de cálculo (como las agregaciones analíticas) en tareas más pequeñas. Estas tareas más pequeñas se ejecutan en paralelo en clústeres informáticos de hardware básico.

En su segunda versión, Hadoop introdujo una mejora que desvinculó el marco de gestión de recursos de MapReduce y lo sustituyó por Yet Another Resource Negotiator (YARN). Esto se convirtió esencialmente en el sistema operativo de Hadoop. Lo más importante es que YARN admite alternativas a MapReduce como marco de procesamiento. Esto amplió enormemente las aplicaciones (y las funciones de gestión de datos y de gobernanza) que podían ejecutarse de forma nativa en Hadoop.

Cómo funcionan los data lakes en la actualidad

La carga rápida y la capacidad de almacenar datos en bruto en su formato nativo han sido siempre las principales ventajas de losdata lakes. Pero, ¿qué significa exactamente eso? ¿Y cómo funciona?

• Datos brutos significa que los datos no han sido procesados ni preparados para un uso concreto. Sin embargo, algunas fuentes de datos han aplicado previamente algún tipo de tratamiento o preparación a sus datos. Así, un data lake almacena datos en bruto, en el sentido de que no procesa ni prepara los datos antes de almacenarlos. Una excepción notable es la relativa al formato.
• Formato nativo significa que los datos permanecen en el formato del sistema o aplicación de origen que los creó. Sin embargo, esta no es siempre la mejor opción para el almacenamiento del data lake. De hecho, rara vez la carga rápida significa simplemente copiar los datos tal cual en un directorio del sistema de archivos utilizado por el data lake.

Por ejemplo, una hoja de cálculo de Microsoft Excel está, por defecto, en su formato nativo XLS. Pero la mayoría de los data lakes prefieren almacenarlos como un archivo de texto plano delimitado en formato de valores separados por comas (CSV). Los datos transaccionales de las bases de datos relacionales también suelen convertirse en archivos CSV para su almacenamiento.

Esquema integrado y datos granulares

Otra alternativa habitual es utilizar un formato de archivo con información de esquema incrustada, como la notación de objetos de JavaScript (JSON). Por ejemplo, los datos de los clics, el contenido de las redes sociales y los datos de los sensores del IoT suelen convertirse en archivos JSON para el almacenamiento del data lake. Los archivos JSON son también un buen ejemplo de cómo la carga de un data lake suele implicar la conversión de los datos de su formato nativo a un formato más granular.

Los datos granulares, especialmente con información de esquema incrustada, como los pares clave-valor (KVP), permiten operaciones de lectura y escritura más rápidas. Esto significa que:

• No desperdicia almacenamiento en marcadores de posición para claves o valores opcionales, predeterminados o faltantes.
• Puede agregarse y desagregarse para satisfacer las necesidades de diferentes situaciones.
• Es más fácil recuperar sólo los datos aplicables a un uso específico.
  
  

También están disponibles otros formatos de almacenamiento de data lakes más optimizados. Algunos de estos formatos de almacenamiento permiten una mejor escalabilidad y un procesamiento paralelo, a la vez que incorporan información sobre el esquema. Los datos se pueden convertir en:

• Almacenes de columnas (por ejemplo, Redshift, Vertica, Snowflake).
• Formatos comprimidos orientados a columnas (por ejemplo, Parquet para Spark u ORC para Hive).
• Formatos convencionales orientados a filas (por ejemplo, PostgreSQL, MySQL u otras bases de datos relacionales).
• Formatos comprimidos orientados a filas (por ejemplo, Avro para Kafka).
• Almacenes en memoria (por ejemplo, SingleStore, Redis, VoltDB).
• Almacenes NoSQL (por ejemplo, MongoDB, Elasticsearch, Cassandra).

Cuándo utilizar diferentes opciones de almacenamiento de datos

La mayoría de los data lakes utilizan diversas opciones de almacenamiento, en función de las fuentes de datos y cada caso empresarial. Esto es especialmente cierto para los casos empresariales relacionados con el acceso y la analítica. Por ejemplo:

• El almacenamiento orientado a columnas funciona mejor cuando lo más importante es la recuperación rápida y la agregación acelerada.
• El almacenamiento orientado a filas funciona mejor cuando hay mucha variabilidad de esquemas, como suele ocurrir con las aplicaciones de streaming. También es ideal cuando el data lake se utiliza como área de preparación para un data warehouse.
• El almacenamiento en memoria funciona mejor para los casos de uso analítico en tiempo real.
• El almacenamiento NoSQL funciona mejor para escenarios de analítica que requieren una rápida generación de métricas en grandes conjuntos de datos.

Los data lakes y la importancia de la arquitectura

La conclusión es que un data lake no es sólo un depósito masivo, sino que requiere una arquitectura de datos bien diseñada. Es posible utilizar una amplia gama de herramientas para implementar la carga rápida de datos en bruto en el data lake. Entre estas herramientas se encuentran las de integración de datos y las de extracción-transformación-carga (ETL) . Probablemente su empresa ya disponga de ellas. Algunas de las nuevas tecnologías de big data (incluidos algunos de los ejemplos anteriores) también ofrecen esta funcionalidad.

Independientemente de cómo decida implementar la carga y el almacenamiento, los data lakes pueden implicar la implementación de tecnologías de back-end con las que esté menos familiarizado, especialmente los sistemas de gestión de bases de datos no relacionales (non-RDBMS). Por suerte, muchas de estas tecnologías incluyen interfaces fáciles de usar. Por ejemplo, algunos ofrecen funciones de consulta similares a las de SQL que muchos usuarios esperan y ya saben utilizar.

Data lake y nube

Un data lake puede utilizarse como un depósito centralizado a través del cual fluyen todos los datos de la empresa. De este modo, se convierte en una zona de paso de fácil acceso en la que se pueden obtener todos los datos de la empresa. Esto incluye los datos consumidos por las aplicaciones in situ, así como las aplicaciones basadas en la nube que pueden acomodar el tamaño, la velocidad y la complejidad del big data. Todo ello nos lleva a la pregunta de data lake frente a la nube: ¿Dónde debe ubicarse data lake?

Data lake en la nube

Para algunas empresas, la nube puede ser la mejor opción para el almacenamiento del data lake. Esto se debe a que ofrece ventajas complementarias -escalabilidad elástica, prestación de servicios más rápida y eficiencia informática- junto con un modelo de contabilidad basado en la suscripción.

Data lake in situ

Las empresas pueden optar por instalar su data lake dentro de sus propios muros por razones similares a los argumentos esgrimidos para gestionar una nube privada in situ. Este enfoque proporciona la máxima seguridad y control al tiempo que protege la propiedad intelectual y las aplicaciones críticas para la empresa. También puede salvaguardar los datos sensibles en cumplimiento de la normativa gubernamental.

Pero las desventajas de gestionar una nube privada in situ también se aplican a un lago de datos.Ambas cosas pueden conducir a un mayor mantenimiento interno de la arquitectura del lago de datos, la infraestructura de hardware y el software y los servicios relacionados. 

Lago de datos híbrido

A veces, las empresas optan por un lago de datos híbrido, que divide su lago de datos entre las instalaciones y la nube. En estas arquitecturas, el lago de datos en la nube no suele almacenar datos que sean críticos para el negocio. Y si contiene información personal identificable (PII) u otros datos sensibles, se oscurece o se anonimiza. Esto ayuda a la empresa a cumplir con las políticas de seguridad y privacidad de los datos. Para minimizar los costes de almacenamiento en la nube, los datos almacenados en ella pueden purgarse periódicamente o una vez finalizados los proyectos piloto.