Lagos de datos de segunda generación: principios arquitectónicos y tecnologías

Este artículo se publicó por primera vez como portada en la revista BI-Spektrum (número 4 / 2021) con el título ÜEl informe se publicó con el título "Lagos de datos de segunda generación".

Como elemento central de una organización impulsada por los datos, muchas empresas confían en el desarrollo de una plataforma de datos basada en el concepto de lago de datos. Sin embargo, las grandes expectativas que despiertan estos lagos de datos no suelen cumplirse a corto plazo. En lugar de discutir sobre la implementación de casos de uso basados en datos, se desata una disputa sobre las diferentes arquitecturas y posibles tecnologías para la implementación arquitectónica del lago de datos. La dinámica del mercado también ha llevado a que los lagos de datos on-premise de primera generación a menudo se vean complementados o sustituidos por arquitecturas y tecnologías de segunda generación al cabo de poco tiempo. Como mejores prácticas, este documento presenta principios de diseño comunes y las tecnologías de nube pertinentes para los lagos de datos de segunda generación basados en una arquitectura de referencia.

El lago de datos como un elemento más dentro de un ecosistema analítico    

En la década de 1990, el concepto de almacén de datos estableció la idea de una plataforma de datos independiente con fines de planificación, elaboración de informes y análisis en la práctica, que integra y consolida los datos redundantes de los sistemas operativos [Gluchowski et al. 2008]. El concepto de almacén de datos se centraba en la idea de integrar los datos normalmente estructurados de los sistemas fuente en un modelo de datos predefinido y coordinado. La gran demanda de datos correctos y armonizados en toda la empresa hacía que, por lo general, en los proyectos de almacén de datos pasara bastante tiempo hasta que los datos de una nueva fuente de datos se integraban en esta visión consolidada, ya que era necesario un gran esfuerzo previo de conceptualización y coordinación. 

Tras el cambio de milenio, surgió una nueva idea para una plataforma de datos dispositiva integradora con el concepto de lago de datos en el contexto del debate sobre big data centrado en el procesamiento rápido e inmediato de datos masivos estructurados y no estructurados. La idea básica se atribuye comúnmente a James Dixon, quien acuñó por primera vez la imagen de un lago de datos en una entrada de blog de 2010 [Dixon 2010]. El lago de datos hace que todos los datos de origen -internos y externos, estructurados y no estructurados- estén disponibles como datos en bruto, incluso en su forma no procesada. Los datos deben estar disponibles en el lago de datos de la forma más rápida y no adulterada posible inmediatamente después de su generación, para poder responder a las preguntas analíticas actuales y futuras. 

 

El manejo eficiente de grandes volúmenes de datos poliestructurados, el procesamiento rápido (a menudo casi en tiempo real) de flujos de datos y el dominio de análisis complejos para nuevas aplicaciones de ciencia de datos y aprendizaje automático están en el primer plano del lago de datos en detrimento de la armonización e integración de los datos. En su lugar, la atención se centra en la estructura de los datos en favor de una integración rápida y completa en el lago de datos, no ya durante el almacenamiento, sino sólo en el contexto del análisis posterior. Así pues, el objetivo de un lago de datos es la creación de estructuras flexibles para domar la compleja integración de la multitud de fuentes de datos. 

Aunque la relación entre el lago de datos y el almacén de datos no solía estar del todo clara en el debate general de la época, en la actualidad cada vez está más asentada la comprensión de una coexistencia cooperativa de ambos conceptos, que constituyen la base de un ecosistema analítico en la empresa [Dittmar 2013]. Ambos conceptos tienen campos de aplicación iguales a lo largo de sus puntos focales. La siguiente tabla resume las características esenciales del almacén de datos y del lago de datos. Sin embargo, cabe señalar que las características establecidas se están difuminando cada vez más, especialmente en relación con conceptos arquitectónicos actuales como la casa del lago de datos.

Almacén de datos: base de datos para sistemas de registro Lago de datos: base de datos para sistemas de innovación 
- Proporciona 80% de análisis con 20% de datos - Ampliación original de la zona de estacionamiento de DWH 
- Optimizado para procesos repetibles - Almacena datos brutos para su exploración y análisis actuales y futuros. 
- Da soporte a una amplia gama de necesidades de información interna de la empresa - Optimiza los datos para soluciones analíticas de forma sencilla 
- Centrarse en evaluaciones orientadas al pasado - Centrarse en el descubrimiento de datos desconocidos y en la ciencia de datos e inteligencia artificial orientadas al futuro 
- Esquema en escritura con modelo de datos armonizado - Lectura de esquemas con gestión de datos brutos en tiempo real 
Cuadro 1: Comparación de las características esenciales de un almacén de datos y un lago de datos 

No cabe duda de que en la práctica se han desarrollado diferentes formas de lagos de datos. Dependiendo de la proporción de datos disponibles en el lago de datos de todo el hogar de datos y del número y origen organizativo de los usuarios, se puede distinguir entre charcos de datos, estanques de datos, lagos de datos en sentido estricto o un océano de datos [Gorelik 2019]. 

Un charco de datos como primera forma de adaptación del concepto de lago de datos se caracteriza por su limitado conjunto de datos, que sólo cubre el caso de uso actual, y su uso local por expertos (en TI), que requiere un alto grado de actividades manuales para su utilización. Una construcción de lago de datos es una multitud de charcos de datos aislados que se encuentran unos junto a otros.  

Un lago de datos en sentido estricto difiere de un estanque de datos en dos factores esenciales: en primer lugar, permite el uso en régimen de autoservicio por parte de los usuarios sin la intervención de TI. En segundo lugar, un lago de datos en sentido estricto contiene datos que no se utilizan actualmente pero que podrían resultar interesantes en el futuro. El océano de datos se considera la respuesta definitiva a las decisiones basadas en datos, basadas en todos los datos (de negocio) de una empresa y con un acceso sencillo y comprensible para todos los empleados. Sin embargo, la creación de valor resultante sólo puede aumentar marginalmente en comparación con un lago de datos bien posicionado en sentido estricto.  

Una forma especial es el famoso pantano de datos. Se trata de una acumulación de datos diferentes que no están organizados ni procesados en absoluto o no muy bien. Además, la falta de metadatos impide su uso por una base de usuarios más amplia.  

Fig. 1: Nivel de madurez de uso del concepto de lago de datos y creación de valor resultante (línea discontinua), ilustración propia basada en [Gorelik 2019]. 

Principios de diseño de un lago de dátiles  

Las mejores prácticas en el diseño de lagos de datos no han hecho más que emerger. Gracias a los principios de diseño, es posible definir las características esenciales de un lago de datos a partir de las características individuales. Dentro del proceso de tratamiento de datos, estos principios de diseño pueden dividirse en los tres pasos de conexión de fuentes de datos, almacenamiento de datos y acceso a los datos. Además, hay principios de diseño que describen las propiedades características de la plataforma del lago de datos subyacente.  

La siguiente figura ofrece una visión general de los principios de diseño de un lago de datos, que, por supuesto, varían en función del contexto del proyecto. 

Principios esenciales del diseño de un lago de datos 

Las fuentes de datos deben conectarse al lago de datos de tal forma que sea posible realizar pruebas rápidas (y ágiles) y la posterior implementación productiva de los casos de uso actuales y potencialmente nuevos. Los datos de origen deben conectarse lo más ampliamente posible a lo largo de las fuentes primarias con la mayor granularidad de datos disponible.  

En el ámbito del almacenamiento de datos, mantener el formato original de los datos en bruto es un factor decisivo para permitir cualquier reinterpretación de los mismos. El uso de un concepto de zona se ha establecido como una unidad organizativa sensata dentro de una arquitectura de lago de datos. Especialmente tras la modificación de la normativa sobre protección de datos, se ha convertido en práctica habitual en muchos lagos de datos evitar el uso de datos personales mediante su completa anonimización. A diferencia del almacén de datos, la implementación de un modelo de datos equilibrado en lugar de unificado es una característica definitoria de un lago de datos. En el lago de datos se permiten definiciones divergentes que pueden justificarse por diferentes casos de uso, de modo que no es necesario un costoso y largo proceso de reconciliación para armonizar los datos. 

El acceso liberal a un lago de datos permite idealmente a muchos usuarios acceder a los datos. Sólo en casos excepcionales justificados debe controlarse el acceso de forma detallada. Algunos ejemplos son los datos personales, confidenciales o relacionados con el código de la empresa. El acceso también debe ser técnicamente posible sin restricciones. 

La propia plataforma del lago de datos debe ser estable, escalable y rentable. Los medios adecuados para ello son la implementación como "infraestructura como código" y el uso de estándares abiertos. Contrariamente al principio original de la arquitectura Apache Hadoop, debe aspirarse a una separación de los recursos de almacenamiento y de cálculo. Los lagos de datos deben disponer de todas las capacidades de ingesta y gestión de datos necesarias para su integración y procesamiento. Estos últimos también deben poder utilizarse mediante procesos centrales de programación y supervisión. Para evitar un pantano de datos, es de importancia elemental capturar los metadatos profesionales y operativos de la forma más automática posible con una herramienta adecuada y hacerlos utilizables para todos los usuarios. Cuando se utiliza en una empresa (grande), también es importante integrarlo en la TI general. Esto incluye, entre otras cosas, la integración en el sistema central de gestión de identidades, las opciones de facturación por uso, la auditabilidad del uso (de acuerdo con los requisitos aplicables) y la provisión de un proceso de integración continua/despliegue continuo (CI/CD). 

Arquitectura de referencia por zonas de un lago de datos  

La arquitectura de datos del lago de datos suele estar orientada hacia las denominadas zonas, por lo que a menudo se denomina lago de datos basado en zonas [Madsen 2015]. Una zona determina el grado de procesamiento de los datos contenidos en ella. Una estructura de zonas típica diferencia cuatro zonas, como se muestra en la siguiente figura. 

Fig. 2: Vista general de las zonas típicas de un lago de datos y las principales etapas de procesamiento

Por regla general, la primera zona, la zona bruta, contiene los datos entrantes en su forma bruta, sin procesar. Los datos de la zona bruta se conservan incluso después de un tratamiento posterior y, por lo general, no se borran.

En la zona anotada posterior, los datos de las fuentes se preparan de forma que sea posible el acceso de los usuarios. Con este fin, se llevan a cabo transformaciones técnicas del formato para facilitar el acceso y se añade información técnica sobre la calidad de los datos. Además, se añade información sobre el control uniforme de la autorización de acceso a los datos mediante referencia a Dimensiones de Control de Acceso (ACD) definidas uniformemente. A más tardar aquí, los datos personales se anonimizan para su uso.

En la zona de procesamiento posterior, los datos se preparan para facilitar su uso por parte del usuario. Para ello, se llevan a cabo transformaciones técnicas para combinar datos de distintas fuentes, realizar enriquecimientos y cálculos y añadir información técnica sobre la calidad de los datos.

Por último, la Zona de Servicio no es lógicamente una zona propia, sino que se utiliza exclusivamente para la optimización técnica del acceso a los datos que ya están disponibles en las zonas situadas por debajo de ella. En esta zona se utilizan diferentes formas de organización del almacenamiento, como la basada en filas o en columnas, para admitir lo más rápidamente posible los tipos de acceso conocidos.

Generaciones de lagos de datos  

Los grandes lagos de datos de la primera generación se construían principalmente en el propio centro de datos de la empresa con nodos de grandes dimensiones. El objetivo de muchas empresas era construir una plataforma de datos para todos los fines de uso. Este enfoque planteó numerosos retos, ya que requisitos como "consultas analíticas profundas en conjuntos de datos muy grandes" y "API para sitio web de cara al cliente con un comportamiento de tiempo de respuesta esperado en el rango de los segundos" se contradicen en parte en sus patrones de arquitectura.

Además, el paradigma básico original de la Apache Hadoop stacks en forma de acoplamiento dedicado de almacenamiento y computación en los nodos de un clúster. Los Data Lakes de la primera generación se basan principalmente en distribuciones comerciales de la pila Apache Hadoop. Se esperaba que esto redujera los conocimientos necesarios para un uso productivo. En retrospectiva, sin embargo, hay que señalar que a pesar del uso de distribuciones comerciales, se requería un mayor nivel de conocimientos técnicos para un soporte productivo en comparación con otras aplicaciones comerciales comunes. Además, el mercado de proveedores de distribuciones comerciales se ha consolidado en los últimos años. En consecuencia, las condiciones comerciales para los usuarios se han deteriorado en general.

Impulsada por el cambio en la situación del mercado de los proveedores de distribución comercial y por la estrategia general de mayor uso de la nube, la base de los lagos de datos de segunda generación está cambiando: la separación entre almacenamiento y computación se está sustituyendo en la Computación en nube De este modo, los almacenes de objetos (económicos) están sustituyendo en gran medida al sistema de archivos distribuidos Hadoop (HDFS). En esta segunda generación, se utiliza una mezcla de servicios nativos de la nube y componentes de Apache Hadoop Stack. Así, se descarta el enfoque monolítico y se utilizan clústeres múltiples y dedicados para tareas individuales. Los proveedores de distribución comercial también están desplazando su oferta del software instalable in situ a ofertas de servicios en la infraestructura de los grandes proveedores de nube.

Clases de tecnología para crear un lago de datos 

Los lagos de datos de segunda generación pueden dividirse en dos clases con patrones de desarrollo típicos, divididos por las zonas que se muestran en la Figura 2.

El primer tipo es una migración del enfoque de la pila Hadoop a la nube. En este caso, la zona RAW ya no se mapea en HDFS, sino principalmente como almacenamiento de objetos del proveedor de nube utilizado, es decir, ADLSv2 en MS Azure o S3 en AWS. El almacenamiento de las otras zonas también se mapea como almacenamiento de objetos, pero a menudo se complementa con organizaciones de almacenamiento de rendimiento optimizado en la zona de servicio, por ejemplo, Apache Impala en la oferta Cloudera CDP. La gestión de datos también se toma de la pila clásica de lago de datos y se lleva a cabo en particular con Apache Spark. Representantes típicos de este género son AWS EMR, MS Azure HDInsights, Cloudera CDP o Databricks ECS.

El segundo tipo comparte el mapeo de la zona RAW en el almacenamiento de objetos en la nube, pero sigue un enfoque diferente en el mapeo de las demás zonas: los datos se cargan lo antes posible en una base de datos relacional basada en la nube en la encarnación MPP (procesamiento paralelo masivo) y luego se procesan en paralelo dentro de ésta. Aquí se aplica el patrón ELT (Extract-Load-Tranform), que distribuye el procesamiento paralelo de tareas entre los nodos disponibles. Representantes típicos son, por ejemplo, AWS Redshift, Snowflake y Teradata Vantage.

Ambos tipos utilizan principalmente servicios nativos de la nube para la ingesta, como MS Azure Data Factory o AWS Glue, si los datos son accesibles para ellos, o el extendido Apache NiFi, que también permite la integración de varias fuentes de datos locales.

En cuanto al uso, se distinguen dos tipos: por un lado, los cuadros de mando y los informes clásicos y, por otro, los entornos de análisis avanzados. Para la elaboración de cuadros de mando e informes, se accede a los datos en representación relacional (ya sea a través de, por ejemplo, Apache HIVE, Apache Impala en el tipo uno o la base de datos relacional MPP en el tipo dos) esencialmente a través de JDBC clásico (Java Database Connectivity). Representantes típicos son AWS Quick Sight, MS PowerBI, Tableau, Qlik. Además, los entornos de análisis avanzados proporcionan la base para trabajar mediante código (por ejemplo, Python, Apache Spark, R). Las interfaces de usuario son los denominados cuadernos, que están equipados con recursos informáticos asignados y pueden acceder a los datos. Algunos ejemplos son el proyecto de código abierto Jupyter y las ofertas comerciales en la nube Amazon Sage Maker, MS Azure ML, Cloudera ML y Databricks ECS.

Además, se han producido grandes avances en los servicios integrados de fácil uso. Estos incluyen todo el espectro necesario para construir y utilizar una plataforma de lago de datos. Ejemplos actuales son AWS Lake Formation, Azure Synapse, Databricks ECS. Además, hay numerosos proveedores nicho que están tratando de aplicar este enfoque.

Conclusión 

Los lagos de datos se han consolidado como instrumento central de la digitalización en los últimos años. Los principios para la creación de lagos de datos han evolucionado: Siguen aplicándose principios esenciales como "si es posible, conectar completamente una fuente con sus datos de forma inmediata, incluso si solo se necesita un subconjunto para el caso de uso que se va a implementar en ese momento". Otros han experimentado una evolución: hoy en día, Apache Hadoop HDFS ya no es predominantemente el estándar para el almacenamiento de datos en bruto, existe una estricta separación entre almacenamiento y computación - y por lo tanto ya no hay nuevos grandes monolitos. Sólo para volúmenes de datos y consultas muy grandes resulta más económica una solución en el propio centro de datos basada en la pila clásica de Hadoop. 

Gracias a la diversificación de las soluciones ofrecidas, los obstáculos anteriores, como la extrema complejidad y la falta de competencias necesarias para crear un lago de datos en la empresa, han disminuido considerablemente. 

Autor:inside

Dr. CARSTEN DITTMAR

El Dr. Carsten Dittmar es Socio y Director del Área Oeste de Alexander Thamm GmbH. También dirige la Práctica de Estrategia de Alexander Thamm GmbH. Durante más de 20 años, ha trabajado intensamente en los campos de la analítica empresarial, la ciencia de datos y la inteligencia artificial, centrándose en la consultoría estratégica y organizativa para iniciativas basadas en datos. El Dr. Carsten Dittmar es miembro europeo de TDWI, autor de varias publicaciones especializadas y ponente en numerosos eventos especializados.

0 comentarios