Saltar a contenido

Data Lakes

El concepto de Data Lakehouse fue introducido por el equipo de Databricks y popularizado posteriormente por Bill Inmon en su libro Building the Data Lakehouse. Hoy en d铆a la idea ha sido ampliamente adoptada por los principales actores en la gesti贸n de datos ya que la arquitectura combina la escalabilidad y la rentabilidad con la infraestructura anal铆tica tradicionalmente asociada a los Data Warehouse. Este enfoque h铆brido permite leer, procesar y comprender los datos de forma m谩s eficiente, al tiempo que se aprovechan las soluciones de almacenamiento de bajo coste

Principios del Data Lakehouse

  • Aprovechar la infraestructura preexistente: siempre que sea posible, utilizar infraestructura existente y en opciones de almacenamiento de bajo coste como Amazon S3, Azure Blob Storage o Google Cloud Storage. Los datos deben almacenarse en formatos abiertos, como CSV, Parquet y ORC, para garantizar la compatibilidad y la flexibilidad
  • Garantizar la coherencia de los datos con transacciones ACID: utilizar tecnolog铆as para mantener la coherencia de los datos mediante transacciones ACID (atomicidad, coherencia, aislamiento y durabilidad) que a menudo se gestionan mediante SQL
  • Admitir la aplicaci贸n y la evoluci贸n de esquemas: el Data Lakehouse debe admitir la aplicaci贸n y la evoluci贸n de esquemas, el uso de arquitecturas de esquemas de almacenes de datos como los esquemas en estrella y en copo de nieve
  • Implementar mecanismos de gobernanza y auditor铆a: a帽adir funciones de gobernanza y auditor铆a incluido un control de acceso basado en roles muy detallado. Garantizar que la manipulaci贸n de datos se pueda realizar a trav茅s de diversas API (Scala, Java, Python, SQL) para cumplir con normativas como el RGPD y la CCPA
  • Desacoplar el almacenamiento de la computaci贸n: la arquitectura debe permitir que los recursos de almacenamiento y computaci贸n se escalen de forma independiente dando cabida a m谩s usuarios simult谩neos y conjuntos de datos m谩s grandes sin degradaci贸n del rendimiento
  • Proporcionar acceso directo a los datos: ofrecer acceso directo a datos sin procesar, seleccionados y agregados para herramientas de inteligencia empresarial (BI). Esto reduce la obsolescencia de los datos, mejora su frescura, reduce la latencia y minimiza los costes de mantener copias separadas de los datos
  • Admite API no SQL para el procesamiento de datos: incluye API declarativas eficientes y no SQL como las API de tipo DataFrame para permitir a los cient铆ficos de datos acceder directamente y procesar grandes vol煤menes de datos, en particular para experimentos de aprendizaje autom谩tico que utilizan bibliotecas R y Python
  • Adopci贸n de formatos de datos abiertos y API: compatibilidad con formatos de datos abiertos y API que permiten el acceso directo a los datos sin depender de motores propietarios, lo que evita la dependencia de un proveedor y garantiza la flexibilidad a largo plazo
  • Habilitaci贸n de la transmisi贸n de datos y el an谩lisis en l铆nea: elimina la necesidad de sistemas separados para gestionar aplicaciones de datos en tiempo real

El concepto de Data Lakehouse parece m谩s un esfuerzo pragm谩tico por codificar el status quo existente que una arquitectura respaldada por un an谩lisis coherente del problema. Dado que no se trata de un concepto innovador, la barrera para su adopci贸n es baja y casi todos los proveedores afirman implementarlo. Aunque este concepto ha ganado un gran impulso, tiene ciertas limitaciones que pueden obstaculizar su eficacia:

  • Enfoque centrado en la tecnolog铆a: el enfoque del Data Lakehouse se centra principalmente en soluciones tecnol贸gicas, pasando por alto a menudo la importancia de las personas y los procesos en la gesti贸n de datos. Las plataformas de datos eficaces requieren un enfoque hol铆stico que integre la tecnolog铆a con las pr谩cticas y la cultura de la organizaci贸n
  • Atenci贸n limitada a los silos de datos y la alineaci贸n empresarial: aunque el Data Lakehouse hace hincapi茅 en la capacidad de descubrimiento de datos, tiende a descuidar los retos que plantean la eliminaci贸n de los silos de datos y la alineaci贸n de los activos de datos con los objetivos empresariales. Tambi茅n presta una atenci贸n insuficiente al ciclo de vida de los datos, los SLA (acuerdos de nivel de servicio) y los SLO (objetivos de nivel de servicio)
  • Gobernanza centralizada frente a agilidad: la gobernanza centralizada y la aplicaci贸n de esquemas inherentes al Data Lakehouse pueden obstaculizar la agilidad de la organizaci贸n. La r谩pida adaptaci贸n es fundamental a medida que las empresas evolucionan, y las estructuras de gobernanza r铆gidas pueden convertirse en un cuello de botella
  • Abordaje inadecuado de los desaf铆os de la integraci贸n de datos: aunque el Data Lakehouse proporciona las capacidades t茅cnicas para la transformaci贸n de datos a gran escala, no aborda completamente los desaf铆os cr铆ticos de la integraci贸n de datos, como la gesti贸n de la complejidad de los datos, los metadatos y las reglas de mapeo de contexto. Estos son componentes esenciales para crear una plataforma de datos verdaderamente integrada y procesable