Capítulo 1. Introducción a la Arquitectura de Casas del Lago

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com

Todos los profesionales de los datos, independientemente de su perfil laboral, realizan dos actividades comunes y fundamentales: ¡hacer preguntas y encontrar respuestas! Cualquier persona de datos, ya sea ingeniero de datos, arquitecto de datos, analista de datos, científico de datos, o incluso un líder de datos como un director de información (CIO) o director de datos (CDO), debe ser curioso y hacer preguntas.

Encontrar respuestas a preguntas complejas es difícil. Pero la tarea más difícil es formular las preguntas adecuadas. El "arte de lo posible" sólo puede explorarse (1) haciendo las preguntas adecuadas y (2) descubriendo respuestas aprovechando los datos. Por sencillo que esto pueda parecer, una organización necesita toda una plataforma de datos que permita a los usuarios realizar estas tareas. Esta plataforma debe soportar la ingestión y el almacenamiento de datos, proporcionar herramientas para que los usuarios formulen y descubran nuevas preguntas, realicen análisis avanzados, predigan y pronostiquen resultados, y generen perspectivas. La plataforma de datos es la infraestructura que permite a los usuarios aprovechar los datos para obtener beneficios empresariales.

Para implantar estas plataformas de datos, necesitas una arquitectura de datos sólida, que te ayude a definir los componentes básicos de la plataforma de datos y a establecer los principios de diseño para ponerla en práctica. Tradicionalmente, las organizaciones han utilizado arquitecturas de almacén de datos o de lago de datos para implantar sus plataformas de datos. Ambos enfoques arquitectónicos han sido ampliamente adoptados en todos los sectores. Estas arquitecturas también han evolucionado para aprovechar las tecnologías y patrones modernos que mejoran continuamente. La arquitectura Lakehouse es uno de esos patrones arquitectónicos modernos que se ha desarrollado en los últimos años, y se ha convertido en una opción popular para los arquitectos de datos que diseñan plataformas de datos.

En este capítulo, te presentaré los conceptos fundamentales relacionados con la arquitectura de datos, las plataformas de datos y sus componentes básicos, y cómo la arquitectura de datos ayuda a construir una plataforma de datos. A continuación, te explicaré por qué son necesarios nuevos patrones arquitectónicos, como la arquitectura lakehouse. Aprenderás los fundamentos de la arquitectura lakehouse, sus características y las ventajas de implantar una plataforma de datos utilizando la arquitectura lakehouse. Concluiré el capítulo con conclusiones importantes, que resumirán todo lo que hemos tratado y te ayudarán a recordar los puntos clave mientras lees los capítulos siguientes de este libro.

Empecemos por los fundamentos de la arquitectura de datos.

Comprender la arquitectura de datos

La plataforma de datos es el resultado final de implantar una arquitectura de datos utilizando la pila tecnológica elegida. La arquitectura de datos es el anteproyecto que define el sistema que pretendes construir. Te ayuda a visualizar el estado final de tu sistema objetivo y cómo piensas conseguirlo. La arquitectura de datos define los componentes básicos, las interdependencias entre estos componentes, los principios fundamentales de diseño y los procesos necesarios para implantar tu plataforma de datos.

¿Qué es la arquitectura de datos?

Para comprender la arquitectura de datos, considera esta analogía del mundo real de una obra de construcción comercial, como un centro comercial o una gran urbanización.

Construir un local comercial requiere una arquitectura sólida, un diseño innovador, un arquitecto experimentado y un ejército de trabajadores de la construcción. La arquitectura desempeña el papel más crucial en el desarrollo: garantiza que la construcción sobreviva a todas las condiciones meteorológicas, ayuda a las personas a acceder y navegar fácilmente por las distintas plantas y permite una rápida evacuación de las personas en caso de emergencia. Estas arquitecturas se basan en ciertos principios rectores que definen el diseño y la disposición básicos de los bloques de construcción. Tanto si construyes una vivienda como un complejo comercial o un pabellón deportivo, los pilares fundamentales y los principios básicos de diseño de la arquitectura siguen siendo los mismos. Sin embargo, los patrones de diseño -interiores, estética y otras características para los usuarios- difieren.

De forma similar a la construcción de un inmueble comercial, la arquitectura de datos desempeña el papel más crucial a la hora de desarrollar plataformas de datos sólidas que den soporte a varios usuarios y a diversos casos de uso de datos y análisis. Para construir una plataforma resistente, escalable y accesible a todos los usuarios, la arquitectura de datos debe basarse en principios rectores fundamentales. Independientemente del sector o dominio, los fundamentos de la arquitectura de datos siguen siendo los mismos.

La arquitectura de datos, al igual que la arquitectura de diseño de una obra, desempeña un papel importante a la hora de determinar cómo se adaptan los usuarios a la plataforma. Esta sección abordará la importancia de la arquitectura de datos en el proceso general de implantación de una plataforma de datos.

¿Cómo ayuda la Arquitectura de Datos a construir una Plataforma de Datos?

La arquitectura de la plataforma de datos es probablemente la fase más crítica de un proyecto de datos y a menudo influye en resultados clave como la adopción de la plataforma por parte del usuario, la escalabilidad, el cumplimiento y la seguridad. La arquitectura de datos te ayuda a definir las siguientes actividades fundamentales que debes realizar para empezar a construir tu plataforma.

Definir los componentes básicos

Los componentes centrales de tu plataforma de datos ayudan a a realizar actividades cotidianas como la ingestión, almacenamiento, transformación y consumo de datos, y otros servicios comunes relacionados con la gestión, las operaciones, la gobernanza y la seguridad. La arquitectura de datos te ayuda a definir estos componentes básicos de tu plataforma de datos. Estos componentes básicos se tratan en detalle en la siguiente sección.

Definir las interdependencias de los componentes y el flujo de datos

Tras definir los componentes básicos de tu plataforma, tienes que determinar cómo interactuarán. La arquitectura de datos define estas dependencias y te ayuda a visualizar cómo fluirían los datos entre productores y consumidores. La arquitectura también te ayuda a determinar y abordar cualquier limitación específica o reto de integración al que puedas enfrentarte al mover los datos entre estos componentes.

Definir los principios rectores

Como parte del proceso de diseño de la arquitectura de datos, también definirás los principios rectores para implantar tu plataforma de datos. Estos principios ayudan a construir un entendimiento compartido entre los distintos equipos de datos que utilizan la plataforma. Garantizan que todos sigan el mismo enfoque de diseño, normas comunes y marcos reutilizables. Definir principios rectores compartidos te permite implantar una solución de plataforma de datos optimizada, eficiente y fiable. Los principios rectores pueden aplicarse a varios componentes y se definen en función de las capacidades y limitaciones de la arquitectura de datos. Por ejemplo, si tu plataforma dispone de varias herramientas de inteligencia empresarial (BI), un principio rector debe especificar qué herramienta de BI utilizar en función del patrón de consumo de datos o del caso de uso.

Definir la pila tecnológica

El anteproyecto de arquitectura también informa sobre la pila tecnológica de los componentes básicos de la plataforma. Al crear la arquitectura de la plataforma, puede resultar difícil ultimar todas las tecnologías subyacentes: se necesitaría un estudio detallado de las limitaciones y ventajas, junto con una prueba de concepto (PdC), para ultimarlas. La arquitectura de datos ayuda a definir las consideraciones clave para hacer estas elecciones tecnológicas y los factores de éxito deseados al llevar a cabo cualquier actividad de PoC y finalizar la pila tecnológica.

Alineación con la visión global y la estrategia de datos

Por último, y lo más importante, la arquitectura de datos te ayuda a implantar una plataforma de datos que esté alineada con tu visión global y la estrategia de datos de tu organización para alcanzar sus objetivos empresariales. Por ejemplo, la gobernanza de los datos forma parte integral de la estrategia de datos de cualquier organización. La arquitectura de datos define los componentes que garantizan que la gobernanza de datos esté en el núcleo de cada proceso. Se trata de componentes como repositorios de metadatos, catálogos de datos, controles de acceso y principios de compartición de datos.

Nota

La gobernanza de datos es un término general que comprende diversas normas, reglas y políticas que garantizan que todos los procesos de datos siguen las mismas directrices formales. Estas directrices ayudan a garantizar el cumplimiento de las normativas geográficas o sectoriales, así como a asegurar que los datos son fiables, de alta calidad y aportan valor. Las organizaciones deben seguir políticas de gobierno de datos en todos los procesos de gestión de datos para mantener la confianza de los consumidores en los datos y seguir cumpliendo la normativa. La gobernanza de datos ayuda a las organizaciones a mantener un mejor control sobre sus datos, a descubrirlos fácilmente y a compartirlos de forma segura con los consumidores.

Ahora que entiendes mejor la arquitectura de datos y su importancia en la implantación de plataformas de datos, vamos a hablar de los componentes básicos de una plataforma de datos.

Componentes básicos de una Plataforma de Datos

En esta sección, veremos los componentes básicos de una plataforma de datos y cómo sus características contribuyen a un ecosistema de datos sólido. La Figura 1-1 muestra los componentes básicos para implementar una plataforma de datos basada en un anteproyecto de arquitectura de datos.

Figura 1-1. Componentes básicos de una plataforma de datos

Exploremos estos componentes básicos y sus procesos asociados.

Sistemas de fuentes

Los sistemas fuente proporcionan datos a la plataforma de datos que pueden utilizarse para casos de uso de análisis, inteligencia empresarial (BI) y aprendizaje automático (ML). Estas fuentes incluyen sistemas heredados, sistemas backend de procesamiento de transacciones en línea (OLTP), dispositivos IoT, flujos de clics y redes sociales. Las fuentes pueden clasificarse en función de múltiples factores.

Sistemas fuente internos y externos

Las fuentes internas son las aplicaciones internas de una organización que producen datos. Entre ellas se incluyen los sistemas internos de gestión de relaciones con los clientes (CRM), las bases de datos transaccionales y los registros generados por máquinas. Las fuentes internas pueden pertenecer a equipos internos de dominios específicos, responsables de generar los datos.

Las plataformas de datos suelen necesitar datos de sistemas externos a para mejorar sus datos internos y obtener información competitiva. Ejemplos de datos que proceden de sistemas externos son los tipos de cambio, la información meteorológica y los datos de estudios de mercado.

Sistemas por lotes, casi en tiempo real y de streaming

Hasta hace un par de décadas, la mayoría de los sistemas fuente de sólo podían enviar datos por lotes, lo que significa que generalmente enviaban los datos al final del día como un proceso diario por lotes. Con la creciente demanda de más información y análisis casi en tiempo real, los sistemas fuente empezaron a enviar datos casi en tiempo real. Estos sistemas pueden ahora compartir datos como múltiples micro lotes más pequeños a un intervalo fijo que puede ser de tan sólo unos minutos. Fuentes como los dispositivos IoT, las fuentes de medios sociales y los flujos de clics envían datos como un flujo continuo que debe ser ingerido y procesado en tiempo real para obtener el máximo valor.

Datos estructurados, semiestructurados y no estructurados

Tradicionalmente, los sistemas fuente sólo producían datos estructurados en tablas o archivos estructurados fijos. Con los avances en los formatos de intercambio de datos, aumentó la producción de datos semiestructurados en forma de archivos XML y JSON. Y cuando las organizaciones empezaron a implantar soluciones de big data, empezaron a generar grandes volúmenes de datos no estructurados en forma de imágenes, vídeos y registros de máquinas. Tu plataforma de datos debe admitir todo tipo de sistemas de origen, que envíen distintos tipos de datos en diversos intervalos de tiempo.

Ingesta de datos

La ingestión de datos es el proceso de extraer datos de los sistemas fuente y cargarlos en tu plataforma de datos. Como se ha visto en la sección anterior, en función de la capacidad del sistema fuente para producir y enviar datos, debe implementarse el marco de ingestión para construir un sistema por lotes, casi en tiempo real o en flujo.

Ingesta por lotes

Los datos que se envían una vez al día (ya sea como proceso de final de día o de inicio de día) pueden ingestarse como proceso por lotes en la plataforma de datos. Éste es el patrón de ingesta más habitual en las arquitecturas tradicionales de almacenes de datos para generar informes diarios de sistemas de información de gestión (MIS) o informes normativos.

Casi en tiempo real

Para los datos más sensibles al tiempo, la ingesta puede hacerse como microlotes o en tiempo casi real. Los intervalos de ingestión de microlotes pueden ser de unas horas a unos minutos, mientras que los datos casi en tiempo real pueden ingestarse en un intervalo de unos minutos a segundos. Las herramientas de ingesta de datos deben cumplir los acuerdos de nivel de servicio (SLA) requeridos según las exigencias de la empresa.

Streaming

Los casos de uso de análisis de flujo son extremadamente sensibles al tiempo y necesitan una arquitectura que admita la ingestión de datos en tiempo real, es decir, en unos pocos milisegundos desde el momento en que se generan los datos. Dado que estos datos son críticos en el tiempo, pueden perder valor rápidamente si no se ingieren y procesan inmediatamente. Los componentes de ingestión de tu plataforma de datos deben ser capaces de soportar requisitos de baja latencia para que los datos estén disponibles tan pronto como los sistemas fuente los generen.

Consejo

Una buena práctica para diseñar el proceso de ingesta es diseñar marcos reutilizables y configurables que puedan ingerir datos de múltiples fuentes o entidades. Esto ayuda a incorporar rápidamente nuevas entidades a la plataforma de datos. Al diseñar la arquitectura de datos, puedes considerar la creación de soluciones reutilizables en estos componentes básicos para reducir los esfuerzos de implementación.

Almacenamiento de datos

Una vez que se ingieren los datos, deben almacenarse para que duren, se descubran fácilmente y se analicen posteriormente. Los componentes de almacenamiento de datos permiten almacenar eficazmente diversos tipos de datos. Estos componentes conservan datos que pueden recuperarse cuando sea necesario y deben proporcionar una alta disponibilidad y durabilidad.

Según los casos de uso, puedes clasificar el almacenamiento de datos en dos grandes categorías: almacenamiento general y almacenamiento específico.

Almacenamiento general

Todo tipo de datos en almacenamiento de objetos como Hadoop Distributed File System (HDFS), Amazon Simple Storage Service (S3), Azure Data Lake Storage (ADLS) o Google Cloud Storage (GCS). Estos almacenes de objetos admiten la persistencia de datos estructurados, semiestructurados o no estructurados. Proporcionan alta disponibilidad y durabilidad, y además son rentables, lo que los convierte en una de las mejores opciones para almacenar datos durante más tiempo.

Nota

ADLS Gen 2 es un servicio de almacenamiento de objetos en la nube proporcionado por Azure que se basa en Azure Blob Storage. Proporciona alta disponibilidad, funciones de recuperación ante desastres, diferentes niveles de almacenamiento para ahorrar costes y otras capacidades de big data. Se utiliza ampliamente para implementar lagos de datos dentro del ecosistema Azure. Anteriormente, Azure también ofrecía ADLS Gen 1 (basado en HDFS), que ya ha sido retirado. A lo largo de este libro, cuando nos referimos a ADLS, nos referimos al servicio ADLS Gen 2.

Almacenamiento específico

Aunque los almacenamientos de objetos son buenos para un almacenamiento rentable y a largo plazo, puede que necesites un sistema de almacenamiento diseñado específicamente que pueda presentar características como acceso rápido, recuperación más rápida, búsquedas basadas en claves, almacenamiento en columnas y alta concurrencia.

Existen diferentes tecnologías y patrones arquitectónicos para implantar estos sistemas de almacenamiento creados a propósito:

Almacenes de datos

Proporciona soporte para las cargas de trabajo del Procesamiento Analítico Online (OLAP)

Sistemas de gestión de bases de datos relacionales (RDBMS)

Soporte en línea Sistemas de Procesamiento de Transacciones (OLTP) para backends de aplicaciones

Bases de datos en memoria

Proporciona una recuperación de datos más rápida

Bases de datos gráficas

Almacena conexiones y relaciones

Los componentes de almacenamiento de datos son los más utilizados dentro de una plataforma de datos. Desde almacenar datos a largo plazo hasta servirlos rápidamente, todas las actividades importantes pasan por estos componentes con la ayuda de un motor de cálculo.

Tratamiento y transformaciones de datos

Los datos brutos recogidos de los sistemas de origen deben validarse, limpiarse, integrarse y transformarse según los requisitos de la empresa. Como parte del procesamiento de datos, se llevan a cabo los siguientes pasos para transformar los datos brutos en un producto final más consumible.

Validación y depuración de datos

Cuando los datos se ingieren desde los sistemas fuente, están en bruto y necesitan validaciones y limpieza antes de que puedan ponerse a disposición de los usuarios finales. Ambos pasos son importantes para garantizar que la exactitud de los datos no se vea comprometida durante su traslado a las zonas de almacenamiento superiores del ecosistema Lakehouse. La jerarquía de las zonas de almacenamiento de datos -en bruto, depurados, curados y semánticos- se tratará en detalle en el Capítulo 7.

Los datos de entrada se validan como primer paso posterior a la ingestión. Estas validaciones se aplican a los datos estructurados y, en cierta medida, a los datos semiestructurados que se utilizan para los informes y la generación de información. Durante este paso, los datos fluyen a través de varias lentes de validación, incluidas las siguientes validaciones técnicas y empresariales:

Validaciones técnicas

Principalmente relacionado con los tipos de datos, formatos de datos y otras comprobaciones que son de naturaleza técnica y pueden aplicarse en cualquier dominio o industria.

Validaciones empresariales

Específicos del dominio o de la función y relacionados con valores concretos en los atributos, y su exactitud o integridad

Validaciones de esquemas

Qué deben seguir los datos de entrada, según el esquema acordado en definido en las especificaciones o contratos de datos

Nota

El contrato de datos es un término relativamente nuevo que describe el acuerdo entre el productor de datos y sus consumidores. Define varios parámetros asociados a los datos producidos, como su propietario, frecuencia, tipo de datos y formato. Los contratos de datos garantizan un entendimiento común entre productores y consumidores de datos.

Transformación de datos

El proceso de transformar datos brutos en información útil se conoce como transformación de datos. Puede consistir en una serie de transformaciones que primero integran los datos recibidos de múltiples sistemas fuente y luego los transforman en una forma consumible que las aplicaciones posteriores, los usuarios empresariales y otros consumidores de datos puedan utilizar según sus requisitos.

Hay múltiples transformaciones de datos que puedes aplicar en función de tu caso de uso y tus requisitos. Las transformaciones de datos más comunes son:

Integración de datos

Como los datos se ingieren desde múltiples sistemas fuente, debes combinarlos para obtener una visión integrada. Un ejemplo es la integración de datos de perfiles de clientes procedentes de sistemas fuente externos, sistemas internos o aplicaciones de marketing. Los distintos sistemas fuente pueden suministrar datos en formatos diferentes, por lo que hay que llevarlos a un formato común y estándar para que puedan ser consumidos por las aplicaciones posteriores de. Por ejemplo, considera el atributo "fecha de nacimiento", que puede tener formatos diferentes (como MM/DD/AAAA o DD-MM-AAAA) en distintos sistemas fuente. Es importante transformar todos los registros de los sistemas fuente a un formato estándar (como DD/MM/AAAA) antes de almacenarlos en tu plataforma central de datos. Como parte del proceso de transformación, esta integración se realiza antes de almacenar los datos en las zonas de almacenamiento superiores.

Mejora de los datos

Para que los datos tengan más sentido, hay que mejorarlos o aumentarlos con datos externos. Ejemplos de mejora de datos son:

  • Aumentar tus datos internos con tipos de cambio externos de aplicaciones de terceros para calcular las ventas diarias globales

  • Aumentar tus datos internos con datos externos de agencias de calificación crediticia para calcular las puntuaciones crediticias de tus clientes

Agregación de datos

Los datos deben resumirse en función de las necesidades de la empresa para que la consulta y la recuperación sean más rápidas. Un ejemplo sería agregar datos en función de la fecha, el producto y la ubicación para obtener vistas resumidas de las ventas.

Conservación y servicio de datos

En el último paso del procesamiento de datos, éstos se curan y se sirven según los procesos y requisitos empresariales. Los datos se cargan en la zona de almacenamiento curada, basándose en un modelo de datos estándar del sector que utiliza enfoques de modelado como el modelado de dimensiones. Esta disposición de los datos mediante modelos de datos específicos del sector facilita una generación de información y unos informes más rápidos y sencillos. Los datos curados pueden utilizarse después para crear productos de datos que los consumidores pueden utilizar directamente para satisfacer sus necesidades empresariales.

Nota

Producto de datos es un nuevo término utilizado para definir un producto final consumible específicamente curado para sus consumidores. Los productos de datos suelen ser creados por equipos de dominio responsables de los datos. Estos productos pueden compartirse con otros equipos de dominio y aplicaciones posteriores. Un producto de datos puede ser una tabla, una vista, un informe, un cuadro de mando o incluso un modelo de aprendizaje automático (ML) que los usuarios finales pueden descubrir y consumir fácilmente.

Consumo y entrega de datos

Los componentes de consumo de datos de tu plataforma permiten a los usuarios acceder a los datos, analizarlos, consultarlos y consumirlos. Pueden ser tus herramientas de informes BI o incluso modelos ML que se utilizan para hacer predicciones y pronósticos. Las distintas cargas de trabajo que soportan estos componentes incluyen:

Cargas de trabajo BI

Las herramientas de BI ayudan a crear informes y cuadros de mando para casos de uso como MIS, informes normativos y análisis de ventas o tendencias diarias. BI ha sido uno de los primeros casos de uso soportados por tecnologías tradicionales como RDBMS y arquitecturas construidas con el enfoque de almacén de datos.

Análisis ad hoc/interactivo

Los usuarios empresariales, los analistas de datos y los líderes de datos a menudo necesitan realizar análisis para dar soporte a requisitos ad hoc o para encontrar respuestas a preguntas improvisadas que surgen durante las reuniones. Los componentes que permiten estos análisis interactivos ad hoc proporcionan una sencilla interfaz SQL.

Aplicaciones descendentes y API

Las aplicaciones posteriores necesitan una forma universal de interactuar con tu plataforma de datos. Las API proporcionan flexibilidad y pueden ser utilizadas por los sistemas posteriores para obtener los datos fácilmente.

Cargas de trabajo de IA y ML

La IA y el ML pueden ayudar en múltiples casos de uso, como predicciones, pronósticos y recomendaciones. Si en tu organización existen estos tipos de casos de uso, tu plataforma de datos debe ser capaz de proporcionar herramientas para el ciclo de vida del ML, incluyendo el entrenamiento, la implementación y la inferencia de los modelos.

Todos estos componentes -herramientas de elaboración de informes de IC y modelos de ML- permiten el consumo y la entrega de datos a los consumidores y desempeñan un papel importante en el aumento de la adopción de la plataforma por parte de los usuarios. Estos componentes también proporcionan una interfaz para que los usuarios interactúen con los datos que residen en la plataforma, por lo que la experiencia del usuario debe tenerse en cuenta al diseñar la plataforma.

Servicios comunes

Hay servicios comunes de que proporcionan la funcionalidad en toda una plataforma de datos y desempeñan un papel importante a la hora de hacer que los datos sean fácilmente descubribles, estén disponibles y sean accesibles de forma segura para sus consumidores. Estos servicios comunes se resumen a continuación.

Gestión de metadatos

Consisten en herramientas y tecnologías que te ayudan a ingerir, gestionar y mantener metadatos dentro de tu ecosistema. Los metadatos facilitan a los usuarios el descubrimiento y acceso a los datos. Puedes crear catálogos de datos para organizar los metadatos con detalles de varias tablas, atributos, tipos de datos, longitudes, claves y otra información. Los catálogos de datos ayudan a los usuarios a descubrir y aprovechar los datos con mayor rapidez y eficacia.

Gobernanza y seguridad de los datos

Implantar políticas sólidas de gobernanza de datos y de seguridad de datos es esencial para:

  • Garantizar una buena calidad de los datos para que los consumidores confíen en ellos

  • Cumplir todos los requisitos reglamentarios pertinentes

  • Visualiza el linaje de los datos para seguir el flujo de datos entre sistemas

  • Implantar los niveles adecuados de controles de acceso para todos los usuarios de la plataforma

  • Compartir datos con consumidores de datos internos y externos

  • Gestiona los datos sensibles abstrayéndolos de los usuarios sin permiso

  • Proteger los datos cuando se almacenan o se mueven dentro o fuera de la plataforma de datos

Estos temas se tratarán en detalle en el Capítulo 6.

Operaciones con datos

Estos servicios ayudan a gestionar diversas operaciones en varias etapas del ciclo de vida de los datos. Las operaciones de datos permiten las siguientes actividades:

  • Orquestar canalizaciones de datos y definir calendarios para ejecutar procesos

  • Automatización de pruebas, integración e implementación de canalizaciones de datos

  • Gestionar y observar la salud de todo el ecosistema de datos

Las plataformas de datos modernas emplean funciones de observabilidad de datos para el monitoreo de la salud de los datos en general.

Nota

La observabilidad de los datos es un nuevo término utilizado para comprender la salud de los datos dentro del ecosistema. Es un proceso para identificar los problemas relacionados con la calidad, precisión, frescura e integridad de los datos de forma proactiva para evitar cualquier tiempo de inactividad de los datos. Las plataformas de datos modernas deben proporcionar funciones para la observabilidad de los datos, sobre todo teniendo en cuenta los grandes volúmenes y la rápida ingestión y procesamiento de datos, en los que cualquier tiempo de inactividad puede afectar gravemente al sistema.

Todos estos componentes básicos forman la plataforma de datos y permiten a sus usuarios realizar diversas actividades. Las arquitecturas de datos proporcionan el plano y los principios rectores para construir estas plataformas de datos. Con estos conocimientos básicos sobre las arquitecturas de datos y las plataformas de datos y su importancia, vamos a hablar ahora de un nuevo patrón arquitectónico -la casa lago- que es el tema principal de este libro.

¿Por qué necesitamos una nueva arquitectura de datos?

Los almacenes de datos y los lagos de datos han seguido siendo las arquitecturas más populares para implantar plataformas de datos. Sin embargo, en los últimos años, algunas organizaciones se han esforzado por implantar plataformas de datos aprovechando distintos enfoques arquitectónicos.

Sus motivaciones para buscar nuevos enfoques en lugar de implantar las conocidas arquitecturas de datos tradicionales, son principalmente dos:

  • Las arquitecturas tradicionales tienen varias limitaciones cuando se implementan como sistemas autónomos. Hablaré de estas arquitecturas tradicionales y de sus restricciones en el Capítulo 2.

  • Se han producido múltiples avances tecnológicos en los últimos años. Las innovaciones en el espacio de la nube y la madurez de las tecnologías de código abierto han sido los principales impulsores de estos avances.

Las organizaciones han intentado constantemente superar las limitaciones de las arquitecturas tradicionales y aprovechar las nuevas tecnologías para construir plataformas escalables, seguras y fiables. Las organizaciones, los proveedores de servicios independientes (ISV) y los integradores de sistemas (SI) han probado enfoques diferentes e innovadores para implantar plataformas de datos más modernas. Algunos de estos enfoques son:

  • Una arquitectura de dos niveles que combina un lago de datos y un almacén de datos para dar soporte a casos de uso de BI, análisis de datos y ML

  • Aprovechando las tecnologías de procesamiento transaccional/analítico híbrido (HTAP), que utilizan una única capa de almacenamiento , para unificar cargas de trabajo transaccionales (OLTP) y analíticas (OLAP)

  • Construir almacenes de datos modernos en la nube que puedan procesar datos no estructurados junto con datos estructurados y semiestructurados

  • Implementar formatos de almacenamiento propios de en el almacenamiento de objetos en la nube que puedan proporcionar un rendimiento similar al de un almacén

  • Construir motores de computación para realizar BI directamente en lagos de datos

Todos estos esfuerzos indican la necesidad de un nuevo patrón arquitectónico que pueda:

  • Apoyar la implementación de una plataforma sencilla y unificada que pueda manejar todos los formatos de datos y un conjunto diverso de casos de uso para ayudar a los usuarios a consumir fácilmente los datos.

  • Proporcionan el soporte ACID, el excelente rendimiento BI y los mecanismos de control de acceso de un almacén de datos

  • Proporcionar la escalabilidad, rentabilidad y flexibilidad de un lago de datos

Así es como en los últimos años ha surgido un nuevo modelo: la arquitectura de las casas del lago. Hablaremos más de ello en la próxima sección.

Arquitectura de casas lacustres: Un nuevo modelo

Las nuevas herramientas, productos y tecnologías de código abierto han cambiado la forma en que las organizaciones implementan los ecosistemas de datos. Estas nuevas tecnologías han ayudado a simplificar las complejas arquitecturas de datos, dando lugar a plataformas de datos que son más fiables, abiertas y flexibles para soportar una variedad de cargas de trabajo de datos y análisis.

La casa lago de datos (denominada casa lago o arquitectura casa lago a lo largo de este libro) es un nuevo patrón arquitectónico que aprovecha la nueva tecnología para construir plataformas de datos sencillas y abiertas. Como se muestra en la Figura 1-2, una casa lago es, en esencia, un lago de datos con una capa transaccional adicional y una capa informática de alto rendimiento. La capa transaccional adicional le confiere propiedades ACID similares a las de un almacén de datos y otras características.

Nota

La capa transaccional adicional se denomina a veces "capa de metadatos", ya que proporciona metadatos relacionados con la transacción. Para mantener la coherencia, nos referiremos a ella como capa transaccional a lo largo del libro.

Figura 1-2. Capas de la arquitectura de Lakehouse

Pronto hablaremos de estas capas con más detalle. Pero antes, dediquemos más tiempo a comprender el concepto de lago de datos y cómo combina las características del almacén de datos y del lago de datos.

La Casa del Lago: Lo mejor de dos mundos

Las plataformas de datos construidas mediante la arquitectura lakehouse presentan características de un almacén de datos y de un lago de datos, de ahí el nombre de lakehouse. La Figura 1-3 muestra las características clave de la arquitectura lakehouse, que es una combinación de las mejores características de un lago de datos y un almacén. Las características de un lago de datos y un almacén de datos se tratarán con más detalle en el Capítulo 2, donde explicaré estas arquitecturas tradicionales, sus características y sus ventajas.

Figura 1-3. Características de la casa del lago

Pero, ¿cómo consiguen los almacenes de lagos las mejores características de los almacenes y los lagos de datos en un único nivel de almacenamiento? ¿Qué tecnologías permiten estas características?

¿Cómo se obtienen las características de un lago de datos?

Al igual que un lago de datos, un lakehouse utiliza el almacenamiento de objetos en la nube, como Amazon S3, ADLS o GCS, y almacena los datos en formatos de archivo abiertos como Apache Parquet, Apache Avro o Apache ORC. Este almacenamiento en la nube permite que los lakehouses tengan todas las mejores características de los lagos de datos, como alta disponibilidad, alta durabilidad, eficiencia de costes, escalabilidad, soporte para todos los tipos de datos (estructurados, semiestructurados, no estructurados), y soporte para casos de uso de IA y ML.

¿Cómo se consiguen las características de un almacén de datos?

En comparación con un lago de datos, un lakehouse tiene un componente adicional: la capa transaccional, que es una capa adicional sobre los formatos de archivo. Esta capa adicional separa un almacén de lago de un lago de datos. Permite a los almacenes de lago obtener capacidades de almacén de datos como el cumplimiento de ACID, la compatibilidad con actualizaciones y eliminaciones, un mejor rendimiento de BI y un control de acceso de grano fino. La tecnología utilizada para implementar esta capa transaccional se conoce como "formatos de tabla abiertos", que trataremos en detalle en la siguiente sección.

La arquitectura Lakehouse ha despertado interés en la comunidad de datos, y varias organizaciones han empezado a adoptarla para construir plataformas que den soporte a múltiples casos de uso, como el procesamiento ETL, BI, ML, ciencia de datos y análisis de streaming. Aparte de los principales proveedores de servicios en la nube, varios proveedores de productos comerciales proporcionan ofertas SaaS o PaaS para apoyar la implementación de la arquitectura lakehouse basada en plataformas de datos. Entre ellos están los productos de Databricks, Snowflake, Dremio y Onehouse.

Profundicemos en la arquitectura Lakehouse y en las tecnologías subyacentes que utiliza.

Comprender la arquitectura de las casas del lago

La Figura 1-4 muestra una vista sencilla de la arquitectura lakehouse, compuesta por las capas de almacenamiento y computación junto con las opciones tecnológicas subyacentes. Se trata de una vista granular de la Figura 1-2, vista anteriormente en este capítulo.

Figura 1-4. Vista más granular de la arquitectura de las casas lacustres

Como ya hemos dicho, la arquitectura Lakehouse consta de una capa de almacenamiento y una capa de cálculo. Las plataformas de datos construidas con arquitectura Lakehouse permiten que las cargas de trabajo de datos y análisis consuman datos de la capa de almacenamiento mientras utilizan el motor de cálculo.

Capa de almacenamiento

Entendamos primero las opciones tecnológicas de la capa de almacenamiento. Esta capa consta de tres componentes: almacenamiento en la nube, formato de archivo abierto y formato de tabla abierta.

Almacenamiento en la nube

El almacenamiento en la nube es un servicio que ofrece la alta disponibilidad, durabilidad y escalabilidad necesarias para implantar plataformas de lago de datos y lakehouse. Los principales proveedores de servicios en la nube ofrecen los siguientes servicios para implantar plataformas lakehouse:

  • Amazon S3 en Amazon Web Services (AWS)

  • ADLS en Microsoft Azure

  • GCS en Plataforma Google Cloud (GCP)

Nota

Las organizaciones también pueden implementar un lago utilizando almacenamiento HDFS local. No es necesario utilizar únicamente almacenamiento de objetos en la nube para implantar una casa del lago. Sin embargo, teniendo en cuenta características como el bajo coste, la separación de cálculo y almacenamiento, y la fácil escalabilidad, es aconsejable utilizar el almacenamiento de objetos en la nube como infraestructura subyacente para implantar una casa del lago.

Este libro sólo tratará de las plataformas modernas que las organizaciones implantan utilizando tecnologías en la nube. Aprenderemos más sobre las plataformas modernas en el Capítulo 2.

Abrir formatos de archivo

Las plataformas de datos pueden almacenar datos en diferentes formatos de archivo en el almacenamiento en la nube. Formatos de archivo como CSV, JSON y XML son los más populares. Para las plataformas de análisis, los tres formatos de archivo más utilizados son Parquet, ORC y Avro.

Todos ellos son formatos de archivo abiertos, es decir, forman parte de un ecosistema de código abierto. No son propietarios; cualquiera puede utilizarlos fácilmente para almacenar datos. Cualquier motor de procesamiento compatible puede interactuar con estos formatos de archivo abiertos. Muchas otras características hacen que estos tres formatos sean adecuados para cargas de trabajo analíticas. Hablaremos de estos formatos de archivo con más detalle en el Capítulo 3.

Abrir formatos de tabla

Como ya hemos dicho, los formatos de tabla abiertos de aportan a un lago de datos las capacidades transaccionales de para convertirlos en un lakehouse. Estos formatos de tabla abiertos son el corazón del lago de datos. Hay tres formatos de este tipo que están ganando popularidad entre la comunidad de datos: Apache Iceberg, Apache Hudi y Delta Lake de la Fundación Linux.

Echemos un vistazo rápido a estos tres formatos de mesa abierta:

Apache Iceberg

Apache Iceberg es un formato de tabla abierto que puede utilizarse con almacenes de objetos en la nube y formatos de archivo abiertos como Parquet, Avro y ORC para implementar la arquitectura lakehouse. Admite funciones como el viaje en el tiempo, la evolución de esquemas y la compatibilidad con SQL, lo que agiliza y facilita la implementación de lakehouse.

Apache Hudi

Apache Hudi ayuda a implementar un lago de datos transaccional y puede utilizarse para aportar al lago de datos capacidades similares a las de un almacén de datos. Proporciona garantías transaccionales ACID, procesamiento incremental, capacidades de desplazamiento en el tiempo, evolución de esquemas y funciones de aplicación.

Lago Delta de la Fundación Linux

Iniciado por Databricks como un proyecto interno, Delta Lake de la Fundación Linux es conocido comúnmente como un marco de almacenamiento de código abierto para construir una arquitectura de lago de datos. Delta Lake proporciona la capa de metadatos y capacidades ACID a los lagos de datos. También proporciona funciones como el viaje en el tiempo, la aplicación y evolución de esquemas y el registro de pistas de auditoría.

Nota

Actualmente existen dos distribuciones diferentes de Delta Lake. La versión comercial viene con la plataforma Databricks. La versión de código abierto está disponible en el sitio web de la Fundación Linux, y puedes utilizarla con otros entornos que no sean Databricks. Aunque Databricks ha hecho que todas sus funciones de Delta Lake sean de código abierto, es posible que la última versión de código abierto no esté disponible inmediatamente con los servicios gestionados de Apache Spark como Amazon EMR o Azure Synapse Analytics. Tendrás que esperar a que estos servicios gestionados en la nube ofrezcan las últimas versiones de Spark y Delta Lake para aprovechar todas las últimas funciones de Delta Lake.

Todos estos formatos de tabla abierta se tratarán con más detalle en el capítulo 3.

Capa de cálculo

Una de las principales ventajas de la arquitectura lakehouse es su naturaleza abierta y su capacidad para ser consultada o accedida directamente por cualquier motor de procesamiento compatible. No necesita un motor específico y propietario para ejecutar cargas de trabajo de BI o análisis interactivos. Estos motores de cálculo pueden ser de código abierto o motores de consulta comerciales diseñados explícitamente para las arquitecturas lakehouse.

Motores de código abierto

Puedes utilizar motores de código abierto para acceder a los datos de una casa del lago. No son específicos de un proveedor y no necesitas adquirir una licencia para utilizarlos. Ejemplos de motores de cálculo de código abierto son Spark, Presto, Trino y Hive.

Motores comerciales

Se trata de motores de consulta construidos específicamente para obtener un mejor rendimiento en la ejecución de cargas de trabajo en lagos. Los motores comerciales suelen construirse desde cero, teniendo en cuenta los formatos de datos abiertos subyacentes y la eficacia con la que pueden obtener el mejor rendimiento. Algunos ejemplos de proveedores de motores de cálculo comerciales son Databricks, Dremio, Snowflake y Starburst.

Tanto la capa de almacenamiento como la de cálculo trabajan juntas para potenciar las arquitecturas lakehouse con las mejores características de los lagos de datos y los almacenes de datos. Como resultado, la arquitectura lakehouse aborda las limitaciones de las arquitecturas de datos tradicionales y admite diferentes cargas de trabajo, desde BI a IA, y diferentes aplicaciones posteriores para aprovechar los datos de una plataforma de datos.

Una plataforma de datos basada en la arquitectura Lakehouse presenta características clave que ayudan a resolver las limitaciones de las arquitecturas tradicionales. La siguiente sección detalla estas características.

Características de la arquitectura de la casa del lago

Las siguientes características diferencian la arquitectura Lakehouse de otras arquitecturas de datos tradicionales.

Un único nivel de almacenamiento sin almacén específico

Como se ha visto en secciones anteriores, un lakehouse, en su esencia, es un lago de datos construido utilizando almacenamiento de objetos en la nube con una capa transaccional adicional. No hay almacenamiento separado como un almacén de datos dedicado para soportar cargas de trabajo de BI. Todos los consumidores leen, acceden o consultan los datos directamente desde el lago de datos. El mismo almacenamiento de objetos en la nube admite todos los casos de uso, incluidas las cargas de trabajo BI y AI/ML.

Rendimiento similar al de un almacén en el lago de datos

El almacenamiento en la nube no es adecuado para las cargas de trabajo de BI y carece del rendimiento que ofrece el almacenamiento propio de los almacenes de datos en la nube. Las plataformas de datos construidas con arquitectura Lakehouse proporcionan un rendimiento excelente para los casos de uso de BI al ofrecer palancas de optimización en las capas de almacenamiento y computación. Puedes obtener un rendimiento excelente utilizando la combinación adecuada de formatos de datos abiertos (archivos y tablas) y motores informáticos construidos explícitamente para la arquitectura lakehouse.

Arquitectura desacoplada con escalado separado de almacenamiento y computación

La arquitectura Lakehouse se basa en un enfoque desacoplado, con motores de almacenamiento y cálculo separados. Las generaciones anteriores de plataformas de datos utilizaban arquitecturas con capas de almacenamiento y procesamiento integradas. Algunos ejemplos son las bases de datos, los almacenes locales tradicionales y los ecosistemas Hadoop. El escalado del almacenamiento o de la potencia de cálculo no era posible con esas arquitecturas integradas.

La arquitectura desacoplada de Lakehouse ayuda a escalar las capacidades de almacenamiento y computación individualmente. Puedes añadir fácilmente más almacenamiento sin aumentar la capacidad informática y viceversa. La Figura 1-5 muestra plataformas que implementan la arquitectura Lakehouse con almacenamiento y cálculo desacoplados.

Figura 1-5. Almacenamiento y cálculo desacoplados en la arquitectura Lakehouse

Arquitectura abierta

La arquitectura Lakehouse utiliza un enfoque "abierto" para implementar plataformas de datos. Esto significa que tienes libertad para emplear formatos de datos de código abierto y motores de cálculo de código abierto para tus plataformas de datos. A diferencia de los almacenes propietarios, en los que tienes que utilizar el motor de procesamiento nativo incluido en el software del almacén, lakehouses te permite utilizar cualquier motor de procesamiento distribuido que sea compatible con los formatos de almacenamiento subyacentes. Esta arquitectura abierta permite a los consumidores de datos acceder a los datos directamente desde el almacenamiento en la nube, sin necesidad de software específico del proveedor.

Soporte para diferentes tipos de datos

Tradicionalmente, las arquitecturas de almacenes locales sólo admitían datos estructurados. No podían almacenar, gestionar ni mantener datos semiestructurados y no estructurados. Ahora, algunos almacenes en nube modernos admiten datos semiestructurados, como archivos JSON y XML.

Las plataformas de datos construidas con el enfoque Lakehouse admiten todos los formatos de datos -imágenes estructuradas, semiestructuradas y no estructuradas; datos de audio y vídeo- en un único nivel de almacenamiento.

Soporte para diversas cargas de trabajo

Como lakehouse puede manejar todos los formatos de datos, puede soportar todo tipo de cargas de trabajo, incluyendo BI, AI/ML, ETL y streaming. No necesitas implementar niveles de almacenamiento separados o un almacenamiento específico para soportar estas cargas de trabajo. La arquitectura Lakehouse puede dar soporte a todas ellas dentro de un único nivel de almacenamiento.

A continuación, vamos a discutir las ventajas clave de la arquitectura lakehouse y cómo puede ayudar a construir una plataforma de datos sencilla, unificada y abierta.

Beneficios de la Arquitectura de Casas del Lago

Una plataforma de datos implementada utilizando el enfoque lakehouse proporciona muchas ventajas significativas, especialmente en un mundo que exige construir plataformas de datos que no sólo sean escalables y flexibles, sino también seguras y fiables.

A continuación se enumeran las ventajas que obtendrías implantando una plataforma de datos basada en la arquitectura Lakehouse.

Arquitectura simplificada

En la arquitectura de lago de datos, todos los datos residen en un único nivel de almacenamiento. La arquitectura de datos se simplifica porque no hay un almacén separado y se reduce la canalización ETL adicional necesaria para mover los datos de los lagos de datos a los almacenes de datos. La arquitectura lakehouse también evita retrasos, fallos o problemas de calidad de datos asociados a la integración de lagos y almacenes.

Esta arquitectura con un único nivel de almacenamiento tiene varias ventajas:

  • No se requieren esfuerzos adicionales para sincronizar los datos entre el lago de datos y el almacén. Sincronizar datos entre dos tipos de almacenamiento distintos siempre es un reto.

  • No tienes que preocuparte por cambiar los tipos de datos entre los lagos de datos y los almacenes. El esquema de ambos no suele coincidir, ya que los tipos de datos pueden ser diferentes.

  • La gobernanza de los datos resulta mucho más fácil en el lago de datos, ya que sólo tienes que implantar controles de acceso en un lugar. En un sistema de almacenamiento de dos niveles, tienes que mantener mecanismos de control de acceso separados para acceder a los datos del lago de datos y del almacén, y asegurarte de que estén siempre sincronizados.

  • Las cargas de trabajo ML pueden leer datos del lago, accediendo directamente a los archivos de almacenamiento subyacentes Parquet, Avro u ORC. Esto elimina la necesidad de copiar cualquier dato agregado del almacén al lago, si así lo requieren las cargas de trabajo ML.

Soporte para datos no estructurados y casos de uso de ML

Un gran volumen de datos producidos en el mundo actual es no estructurado. Un lakehouse admite datos no estructurados junto con datos estructurados y semiestructurados. Esto abre un sinfín de posibilidades para implementar casos de uso de IA y ML con el fin de aprovechar volúmenes masivos de datos no estructurados para predicciones, pronósticos, recomendaciones y nuevos conocimientos a partir de los datos.

Sin bloqueo de proveedores

Como ya hemos comentado, los almacenes de lago utilizan formatos abiertos para implementar plataformas de datos. Los formatos abiertos permiten a los consumidores consultar y procesar datos utilizando cualquier motor de procesamiento compatible que se integre bien con los formatos de almacenamiento subyacentes. Las casas del lago no utilizan ningún formato de almacenamiento propietario que necesite un motor de procesamiento de un proveedor específico. Esto permite que las aplicaciones posteriores tengan acceso directo a los datos para su consumo.

Por ejemplo, si implementas una plataforma de datos de dos niveles con un lago de datos y un almacén dedicado, primero deberás cargar los datos en el almacén para poder realizar cualquier carga de trabajo de BI. Para consultar o acceder a estos datos, tendrás que utilizar el motor informático propietario del mismo proveedor del almacén. Deberás utilizar las capacidades de procesamiento proporcionadas por el proveedor y pagar por ello. Esto conduce a la dependencia del proveedor y la migración a otros motores requiere esfuerzos considerables.

Advertencia

No todos los formatos de tabla abiertos son compatibles con todos los motores de consulta comerciales o de código abierto. Se trata de un espacio en crecimiento, y múltiples proveedores de software independientes (ISV) están trabajando en la creación de conectores para interactuar con diversos formatos de datos. Al decidir tu pila tecnológica, debes tener en cuenta la compatibilidad del motor con los formatos de tabla abierta subyacentes.

Compartir datos

Al utilizar formatos de datos abiertos, compartir datos con los consumidores posteriores resulta mucho más manejable. No tienes que incorporar a los consumidores a tus plataformas ni compartir extractos de archivos con ellos. Pueden acceder directamente a los datos desde el almacén en la nube en función de los permisos de acceso para compartir datos.

Un ejemplo de compartición de datos es el protocolo de Compartición Delta, un estándar abierto para la compartición segura de datos introducido por Delta Lake. La Figura 1-6 muestra una versión simplificada del protocolo Compartir Delta. Ten en cuenta que las implementaciones reales tendrían componentes adicionales para gestionar los permisos y optimizar el rendimiento para servir sólo los datos necesarios.

Figura 1-6. Reparto del Delta en el Lago Delta

La principal ventaja de compartir datos abiertos es la libertad que tienen los consumidores de datos de utilizar cualquier motor de procesamiento de código abierto o productos comerciales para consultar y analizar los datos. No están obligados a utilizar el mismo producto que el productor de datos para acceder a los datos compartidos. Por otra parte, el productor de datos sólo necesita compartir los datos y no tiene que preocuparse de qué motores de procesamiento utilizarían los consumidores para acceder a los datos. Esta característica abre múltiples posibilidades para compartir datos de forma segura e implementar un mercado para compartir e intercambiar datos de forma colaborativa.

Se trata de un espacio en crecimiento y, en el futuro, varios proveedores y comunidades podrían introducir nuevos conectores para acceder directamente a los datos almacenados en una casa del lago.

Escalable y rentable

Los Lakehouses utilizan el almacenamiento en la nube, que es escalable y mucho más barato que los almacenes de datos tradicionales. El coste de almacenamiento de los almacenes en la nube es el que fijan los proveedores de almacenamiento en la nube. También puedes aprovechar las políticas de gestión del ciclo de vida y los niveles fríos, o de archivo, que ofrecen los proveedores de la nube para optimizar los costes de almacenamiento a largo plazo.

No hay datos pantanosos

Muchas organizaciones tienen grandes volúmenes de datos en sus lagos de datos. Sin embargo, la mayoría de las veces, no aprovechan estos datos con eficacia debido a la falta de visibilidad de los datos.

Descubrir estos grandes volúmenes de datos es difícil sin una adecuada gestión de metadatos, gobernanza, seguimiento del linaje y controles de acceso. Sin estas cosas, los lagos de datos se convierten en pantanos de datos y aprovechar estos datos se convierte en un reto. Los lagos de datos ayudan a que los consumidores de la plataforma puedan descubrir fácilmente los datos, ofreciendo funciones como la gestión unificada de metadatos (en todos los datos y activos de IA), el seguimiento del linaje, etc.

Nota

Los pantanos de datos son lagos de datos con grandes volúmenes de datos sin una organización o estructura adecuadas. Los datos almacenados en tales lagos de datos no están bien gobernados y no tienen metadatos bien organizados en forma de catálogos, lo que dificulta enormemente el descubrimiento de datos y reduce la visibilidad general de los datos para los consumidores. En resumen, los pantanos de datos son lagos de datos con datos que no se aprovechan para las necesidades empresariales debido a la ausencia de metadatos sólidos y procesos de gobernanza.

Aplicación y evolución del esquema

Las tecnologías utilizadas en la arquitectura Lakehouse soportan la aplicación de validaciones de esquema para evitar desajustes de esquema mientras se almacenan los datos. Estas tecnologías también admiten la evolución del esquema, utilizando distintos enfoques para ayudar a aceptar los cambios del esquema de origen. Estas características permiten un sistema flexible con mejor calidad e integridad de los datos. Analicemos brevemente las ventajas de estas dos características.

Aplicación del esquema

La aplicación del esquema garantiza que los datos almacenados en el lago siguen el esquema definido por los metadatos de esa tabla. El proceso ETL rechaza cualquier atributo adicional o tipos de datos que no coincidan. Estas validaciones ayudan a almacenar datos correctos, mejorando así la calidad general de los datos. Por ejemplo, si llega un valor de cadena a un atributo definido como entero en el esquema, se rechazará.

Evolución del esquema

Mientras que la aplicación del esquema mejora la calidad de los datos mediante la aplicación de validaciones estrictas, la evolución del esquema permite relajar estas validaciones ofreciendo más flexibilidad al almacenar los datos en un lago. Cualquier atributo adicional no definido en los metadatos de la tabla puede almacenarse utilizando la evolución de esquemas. Dependiendo del formato de la tabla abierta, existen varios enfoques para almacenar el atributo adicional. Esta función ayuda a conservar nuevos atributos o desajustes en los tipos de datos sin rechazarlos. La principal ventaja de este enfoque es que nunca pierdes ningún dato y puedes acomodar los cambios sobre la marcha.

Mientras que la imposición de esquemas ayuda a mejorar la calidad de los datos al aplicar reglas estrictas sobre atributos específicos, la evolución de esquemas proporciona flexibilidad para adaptarse a los cambios de metadatos en los sistemas de origen. Puedes utilizar ambas mientras implementas tu lakehouse para mantener la calidad de los datos, así como para acomodar cualquier cambio en los metadatos de origen.

Plataforma unificada para ETL/ELT, BI, AI/ML y cargas de trabajo en tiempo real

Como hemos mencionado, la arquitectura lakehouse te permite implantar una plataforma de datos unificada para soportar diversas cargas de trabajo. Analicemos con más detalle estas cargas de trabajo y las ventajas de utilizar una casa lago para implementarlas.

Cargas de trabajo ETL/ELT

Para implementar cargas de trabajo ETL, puedes utilizar motores de procesamiento populares, como Spark, para realizar transformaciones antes de almacenar los datos en las zonas superiores de la jerarquía de almacenamiento de Lakehouse. También puedes implementar una carga de trabajo ELT para realizar transformaciones mediante consultas SQL utilizando cualquier motor informático. Los profesionales de los datos que están más familiarizados con SQL prefieren realizar operaciones ELT basadas en SQL para transformar los datos.

Cargas de trabajo BI

Con un rendimiento equiparable al de los almacenes de datos, puedes implementar tus cargas de trabajo de BI utilizando un lakehouse. Dado que una casa lago proporciona una capa transaccional al lago de datos, operaciones como actualizaciones y eliminaciones son posibles y más rápidas que cuando se realizan en lagos de datos.

Cargas de trabajo AI/ML

Puesto que una casa del lago admite datos no estructurados junto con datos estructurados y semiestructurados, puedes realizar casos de uso de IA/ML accediendo directamente a los datos de la casa del lago.

Cargas de trabajo en tiempo real

Una arquitectura lakehouse unificada admite diversas cargas de trabajo , incluido el procesamiento en tiempo real. En los últimos años, debido al aumento de los datos en tiempo real generados por dispositivos IoT, wearables y clickstreams, las organizaciones han intentado implementar plataformas que puedan soportar cargas de trabajo en tiempo real. Las arquitecturas de datos anteriores, como la arquitectura Lambda, soportaban cargas de trabajo en tiempo real utilizando diferentes flujos de procesamiento. Las Lakehouses soportan cargas de trabajo en tiempo real utilizando una arquitectura unificada que admite la ejecución de trabajos por lotes o en tiempo real utilizando la misma base de código.

Nota

La arquitectura Lambda es un enfoque tradicional para procesar grandes volúmenes de datos ingestados con frecuencias variadas. La arquitectura Lambda tiene dos capas diferentes para procesar datos por lotes y datos en streaming. Los componentes de datos por lotes y de streaming para estas capas también están separados, en función de factores como la latencia y los SLA asociados. Esto da lugar a una arquitectura de datos compleja, con esfuerzos adicionales para mantener diferentes bases de código para las distintas capas.

Viaje en el tiempo

La capa transaccional de un lago le permite mantener en varias versiones de los datos. Esto le ayuda a realizar viajes en el tiempo para consultar y recuperar datos antiguos que se hayan actualizado o eliminado. Veamos un ejemplo para comprender la función de viaje en el tiempo. La Tabla 1-1 muestra una tabla de productos con tres columnas.

Tabla 1-1. Una tabla lacustre con registros de muestra
producto_id nombre_producto categoría_producto
22 teclado accesorio informático
12 ratón accesorio informático
71 auriculares accesorio informático
11 maletín móvil accesorio móvil

Considera un caso en el que la tercera fila, con product_id 71, se actualiza para cambiar la categoría de "accesorio de ordenador" a "accesorio de móvil". La Tabla 1-2 muestra la tabla actualizada.

Tabla 1-2. Tabla de una casa del lago con registros actualizados
producto_id nombre_producto categoría_producto
22 teclado accesorio informático
12 ratón accesorio informático
71 auriculares accesorio móvil
11 maletín móvil accesorio móvil

Ahora, si consultas la tabla de productos, podrás ver los datos actualizados, pero el valor antiguo de product_category del registro actualizado no será visible.

Si utilizas los formatos de tablas abiertas de, como Iceberg, Hudi o Delta Lake, también podrás ver los registros anteriores con sólo consultar la tabla utilizando un número de versión anterior o una marca de tiempo más antigua, como se muestra a continuación.

Recuperar datos antiguos en función de la versión

Puedes recuperar el estado más antiguo de los registros utilizando el número de versión:

select * from product as of version <older version number>

Recuperar datos antiguos en función de la fecha y hora

Puedes recuperar el estado más antiguo de los registros utilizando la marca de tiempo anterior:

select * from product as of <older timestamp>
Nota

Los comandos SQL exactos variarán en función del formato de tabla abierta y de los motores de cálculo utilizados para implementar la casa del lago.

Esta operación de viaje en el tiempo no es posible en los almacenes de datos o lagos de datos tradicionales. Algunas bases de datos NoSQL (como HBase) y los almacenes modernos en la nube almacenan todas las versiones de los datos, pero los almacenes tradicionales carecían de esta característica.

Estas ventajas permiten a todas las personas que manejan datos acceder a ellos, gestionarlos, controlarlos, analizarlos y aprovecharlos con rapidez y eficacia, en comparación con las arquitecturas de datos anteriores.

Teniendo en cuenta las ventajas, la arquitectura lakehouse puede convertirse pronto en la opción por defecto para implantar plataformas de datos y podría ver una adopción generalizada similar a la de los almacenes de datos y los lagos de datos. Las tecnologías avanzadas, las comunidades en crecimiento y los múltiples ISV que trabajan en productos basados en lakehouse indican una creciente demanda y popularidad de la arquitectura lakehouse.

Puntos clave

Si es la primera vez que aprendes sobre arquitectura de casas lacustres, entiendo que es mucha información para digerir a la primera. Resumiré los puntos clave que he tratado en este capítulo para ayudarte a recordar los conceptos más importantes mientras lees los siguientes capítulos de este libro.

Comprender la arquitectura de datos

  • La arquitectura de datos es la base de cualquier plataforma de datos. Define los componentes básicos y sus interdependencias. Proporciona el anteproyecto para construir la plataforma de datos y ayuda a establecer los principios rectores para diseñar el sistema.

  • Los componentes básicos de la plataforma de datos son los sistemas fuente, la ingestión de datos, el almacenamiento de datos, el procesamiento y las transformaciones de datos, el consumo y la entrega de datos, y los servicios comunes como la gestión de metadatos, la gobernanza y la seguridad de los datos, y las operaciones de datos.

  • Diseñar la arquitectura de datos es uno de los pasos más críticos en la creación de la infraestructura de datos. Debes esforzarte al máximo para diseñar una plataforma escalable, flexible, fiable y, sobre todo, sencilla. Esto permitirá una adopción más rápida por parte del usuario.

Características de la arquitectura de la casa del lago

  • La arquitectura Lakehouse es un nuevo patrón arquitectónico que ha surgido en los últimos años. Aporta las mejores características de los almacenes de datos y los lagos de datos.

  • La arquitectura Lakehouse almacena los datos en un almacén en la nube con una capa transaccional adicional, lo que permite capacidades similares a las de un almacén.

  • Obtendrás la escalabilidad, flexibilidad y rentabilidad de un lago de datos, así como el rendimiento, el cumplimiento de la normativa ACID y la mejor gobernanza de los almacenes de datos.

  • La arquitectura Lakehouse tiene un único nivel de almacenamiento y no dispone de almacenamiento de almacén independiente. Emplea una arquitectura desacoplada en la que las capas de cálculo y almacenamiento están separadas y escalan independientemente.

  • Admite el almacenamiento y la gestión de todos los tipos de datos, incluidos los estructurados, semiestructurados y no estructurados. También admite diversas cargas de trabajo como ETL, streaming, BI y AI/ML.

Ventajas de la arquitectura en el lago

  • La arquitectura Lakehouse te ayuda a implantar una plataforma de datos sencilla y unificada para implementar un conjunto diverso de casos de uso de datos y análisis.

  • Los almacenes en la nube utilizan tecnologías abiertas para el almacenamiento; no tienes que preocuparte por problemas de dependencia de un proveedor. Puedes utilizar cualquier motor informático compatible para consultar los datos accediendo directamente a los datos almacenados en el almacenamiento de objetos en la nube.

  • Compartir datos con los consumidores de datos, independientemente de la tecnología o el producto que utilicen, resulta más fácil sin necesidad de replicar los datos o enviar extractos de archivos.

  • Lakehouses puede ayudarte a gestionar y controlar tus datos de forma más eficaz con funciones como la aplicación de esquemas, la evolución de esquemas, el viaje en el tiempo y mucho más.

A medida que avances en la lectura de este libro, te sumergirás en temas más avanzados para comprender cómo diseñar e implantar arquitecturas lakehouse prácticas y ver sus ventajas frente a las arquitecturas tradicionales, como los almacenes de datos y los lagos de datos, o los sistemas combinados de dos niveles. Pero para los lectores nuevos en el mundo de los datos, primero tenemos que entender mejor estas arquitecturas tradicionales, sus ventajas y sus limitaciones para apreciar las ventajas de la arquitectura lakehouse. Hablaré de ello en el próximo capítulo.

Get Arquitectura práctica de casas en el lago now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial