Cómo Estructurar tu Data Lakehouse con la Arquitectura Medallion

·

·

, ,

En el mundo digital de hoy, los datos no son solo un activo; son una ola gigantesca. Las organizaciones están recopilando información a una escala y velocidad sin precedentes, a partir de cada clic, transacción y sensor. La promesa es clara: aprovechar estos datos para tomar decisiones más inteligentes, personalizar las experiencias de los clientes e innovar más rápido que nunca. Para cumplir con esta promesa, hemos ido más allá de los almacenes de datos tradicionales hacia sistemas más flexibles y potentes, como el data lake moderno y el data lakehouse.

Pero este paraíso crudo y sin filtrar rápidamente degeneró en lo que muchos llaman “pantanos de datos”: vastos y turbios repositorios donde encontrar datos confiables y de alta calidad se convirtió en un desafío monumental. ¿Cómo garantizar la calidad de los datos? ¿Cómo gestionar el rendimiento y los costos cuando todo se almacena en su forma bruta y abultada? ¿Cómo ofrecer a los usuarios de negocio datos confiables y listos para usar sin ahogarlos en complejidad?

Aquí entra en juego la Arquitectura Medallion. Más que una tecnología, es un patrón de diseño robusto: una forma de pensar sobre cómo organizar y gestionar los datos en tu lakehouse. Al estructurar los datos en capas lógicas e incrementales —Bronce, Plata y Oro— proporciona un camino claro desde la ingesta bruta hasta las perspectivas listas para el negocio. Es el plano para transformar un pantano de datos caótico en una finca de datos prístina, confiable y altamente valiosa.

En esta entrada de blog, profundizaremos en la Arquitectura Medallion. Exploraremos el contexto del stack de datos moderno, descubriremos los problemas que crea de manera inherente y luego detallaremos cómo el enfoque Medallion resuelve elegantemente estos desafíos, devolviendo orden, calidad y confianza a tus datos.

Contexto: La Arquitectura de Datos Moderna

Para entender por qué la Arquitectura Medallion es tan crucial, primero debemos apreciar el entorno para el cual fue diseñada: la arquitectura de datos moderna. Durante décadas, el estándar fue el data warehouse—un sistema rígido pero confiable, construido para datos estructurados e internos de negocio. Sin embargo, la explosión digital trajo consigo nuevos desafíos, resumidos de manera célebre en las tres V: Volumen, Velocidad y Variedad. Para afrontarlos, surgió un nuevo paradigma: el Data Lakehouse. Piénsalo como lo mejor de ambos mundos. Combina el almacenamiento flexible y de bajo costo de un data lake (capaz de manejar cualquier tipo de dato) con las potentes funciones de gestión y transacción de un data warehouse (como transacciones ACID, aplicación de esquemas y time travel). Esta es la base del stack de datos moderno. Ya hemos visto en un blog anterior los beneficios que ofrece un lakehouse.

Para hacerlo más concreto, imaginemos una empresa de comercio electrónico llamada GadgetGalaxy. Venden los últimos dispositivos electrónicos en línea y están luchando por dar sentido a sus datos.

Su arquitectura de datos moderna se ve así:

  • Fuentes de Datos:
    • Una base de datos PostgreSQL que rastrea pedidos de clientes, productos e inventario.
    • Registros del servidor web que capturan cada clic, vista de página y artículo añadido al carrito (clickstream data).
    • Una API de Google Ads que proporciona datos de rendimiento de campañas de marketing.
  • Ingesta de Datos: GadgetGalaxy utiliza una herramienta como Fivetran para extraer continuamente datos de estas fuentes y cargarlos directamente en su repositorio central.
  • Almacenamiento y Procesamiento de Datos: Usan un lakehouse de Databricks construido sobre Amazon S3. Todos los datos en bruto de sus fuentes llegan aquí en su formato original. Planean usar Spark y SQL para transformar estos datos con fines de análisis. Este enfoque “ELT” (Extract, Load, Transform) es central en el stack moderno.
  • Consumo de Datos: Su objetivo es capacitar a:
    • Analistas de datos para crear paneles en una herramienta de BI como Tableau.
    • Científicos de datos para construir modelos de machine learning que recomienden productos.
    • Líderes de negocio para obtener respuestas confiables a sus preguntas.

En apariencia, esta arquitectura es un gran éxito. GadgetGalaxy ahora puede almacenar todos sus datos en un solo lugar, sin importar la fuente. Pero esta nueva libertad y flexibilidad trae consigo un costo oculto. Los datos en bruto y sin procesar en su lakehouse son caóticos, inconsistentes y no están listos para un usuario de negocio. Este es el “pantano de datos” que mencionamos, y es donde comienzan los problemas de GadgetGalaxy.

La Realidad Indisciplinada: Problemas en la Arquitectura de Datos Moderna

La arquitectura de datos moderna, con su enfoque de lakehouse y ELT, le da a GadgetGalaxy la increíble capacidad de almacenar cualquier cosa. Pero esta libertad es un arma de doble filo. Sin un marco disciplinado para gestionar esos datos, su lakehouse prístino rápidamente degenera en el temido “pantano de datos”. La zona de datos en bruto se convierte en un vertedero caótico, creando una serie de problemas para todos los que necesitan usarla.

Veamos estos problemas a través de los ojos del equipo de GadgetGalaxy.

  1. Mala Calidad de Datos e Inconsistencia Los datos en bruto son inherentemente desordenados. Provienen de diferentes sistemas, con distintas reglas, formatos y niveles de calidad. Sin un proceso central para limpiarlos y estandarizarlos, reina el caos.

En GadgetGalaxy: Los registros del servidor web guardan un user_id como cadena (ejemplo: “a1b2-c3d4-e5f6”), mientras que la base de datos PostgreSQL almacena customer_id como entero (ejemplo: 12345). Los registros web usan una marca de tiempo en UTC, pero los datos de pedidos usan order_date en la zona horaria local de la empresa (PST). Un analista que intente vincular el recorrido de un usuario en el sitio web con su compra real primero debe resolver cómo unir estas claves conflictivas y reconciliar las zonas horarias. Esto es tedioso y propenso a errores.

  1. Rendimiento Deficiente y Costos Elevados Consultar datos en bruto y no estructurados es increíblemente ineficiente. Cada vez que un analista o científico de datos ejecuta una consulta, el sistema debe escanear archivos masivos completos (como terabytes de registros JSON) para encontrar la información relevante.

En GadgetGalaxy: Una analista de marketing quiere saber qué campañas publicitarias generan más ingresos. Su consulta necesita unir los enormes archivos JSON de Google Ads con los igualmente masivos registros del servidor web y la tabla de pedidos de PostgreSQL. Debido a que los datos están en su forma bruta, esta única consulta tarda horas en ejecutarse y consume una gran cantidad de costoso poder de cómputo en su entorno de Databricks. Ejecutar este tipo de análisis diariamente simplemente no es viable.

  1. Alta Complejidad y Baja Accesibilidad Las personas que más necesitan información—líderes de negocio, responsables de marketing, gestores de producto—no son ingenieros de datos. No se les puede exigir que escriban complejos trabajos en Spark o consultas SQL de varias páginas que analicen JSON, manejen estructuras anidadas y unan fuentes dispares.

En GadgetGalaxy: La Directora de Marketing quiere un panel sencillo que muestre “Nuevos Clientes Diarios por Canal de Adquisición”. Para obtener este número, un ingeniero de datos tendría que escribir una transformación altamente compleja. La líder de marketing depende completamente del equipo de ingeniería, creando un cuello de botella y retrasando su capacidad de tomar decisiones rápidas basadas en datos. Los datos están técnicamente “disponibles”, pero no son accesibles.

  1. Falta de Gobernanza y Confianza Cuando todos trabajan directamente con los datos en bruto, no existen reglas. ¿Quién es responsable de la calidad de los datos de marketing? ¿Cuál es la definición oficial de “usuario activo”? Cuando el sistema fuente cambia, ¿quién es responsable de actualizar los informes posteriores?

En GadgetGalaxy: Un científico de datos construye un modelo de recomendación de productos usando los datos en bruto del clickstream. Un mes después, el equipo web añade un nuevo campo a los archivos de registro, cambiando ligeramente la estructura. El modelo del científico comienza a producir malas recomendaciones y falla silenciosamente. No hay un propietario claro de los datos, ni pruebas automatizadas, ni una forma sencilla de rastrear el problema hasta su origen. La confianza en los datos—y en los modelos construidos sobre ellos—se desploma.

Estos problemas crean un ciclo de frustración. Los datos son abundantes, pero poco confiables, caros de usar e inaccesibles para quienes más los necesitan. GadgetGalaxy es rico en datos pero pobre en información. Necesitan una manera de poner orden en este caos, un enfoque sistemático para refinar progresivamente sus datos en bruto hasta convertirlos en activos confiables y listos para el negocio. Esto es precisamente donde entra la Arquitectura Medallion.

La Arquitectura Medallion: Un Camino Estructurado del Caos a la Claridad

La Arquitectura Medallion no es una herramienta ni un producto específico; es un patrón de diseño para organizar lógicamente los datos en un lakehouse. Proporciona un marco para refinar progresivamente los datos a medida que fluyen por tu sistema, garantizando que se vuelvan más limpios, confiables y eficientes en cada etapa.

Lo logra estructurando los datos en tres capas distintas y jerárquicas: Bronce, Plata y Oro. Piénsalo como una medalla olímpica: cada nivel representa un estándar más alto de calidad y valor. Veamos cómo GadgetGalaxy implementa esta arquitectura para resolver sus problemas.

La Capa Bronce: La Zona de Aterrizaje Cruda e Inmutable

El viaje comienza en la capa Bronce, la base de la arquitectura. Aquí es donde todos los datos llegan en su formato original y sin procesar, en el momento en que se extraen de los sistemas fuente. Su propósito principal es crear un archivo completo, inmutable y con capacidad de time travel de todos los datos fuente, sirviendo como la “fuente única de verdad” para la información en bruto.

En GadgetGalaxy, esto significa que su tabla bronze.web_logs contiene los archivos JSON comprimidos en gzip provenientes de sus servidores web, exactamente como fueron generados. Su tabla bronze.postgres_orders guarda instantáneas en CSV de la base de datos de pedidos. Estos datos nunca se modifican ni actualizan; simplemente se añaden nuevos registros. Al mantener esta capa cruda e intacta, GadgetGalaxy resuelve inmediatamente un problema crítico de gobernanza. Si algún informe posterior falla, siempre pueden rastrear y “viajar en el tiempo” al estado exacto de los datos en bruto cuando fueron ingeridos por primera vez, garantizando una auditoría completa.

La Capa Plata: La Fuente Única de Verdad Refinada

Aquí es donde ocurre el trabajo de transformación más crítico. Los datos de la capa Bronce se extraen, limpian, validan, se eliminan duplicados y se conforman en un formato bien estructurado y optimizado para consultas. La capa Plata representa la verdadera fuente única de verdad de la organización para análisis confiables.

La transformación es meticulosa. Los tipos de datos se estandarizan—por ejemplo, todos los IDs de usuario y cliente se convierten a un formato de cadena consistente. Las marcas de tiempo de diferentes fuentes, como los registros web y la base de datos de pedidos, se unifican en una sola zona horaria (UTC). Los distintos conjuntos de datos se combinan para crear vistas completas y unificadas. En GadgetGalaxy, esto da lugar a tablas como silver.customers, que une y elimina duplicados de la información de clientes tanto de Postgres como de los registros web en un único registro limpio. Otra tabla, silver.sessions, toma los registros JSON en bruto y los estructura en una tabla adecuada, facilitando el análisis del comportamiento de los usuarios. Para garantizar el rendimiento, estos datos se almacenan en formatos columnares eficientes como Parquet y se particionan por fecha.

Este enfoque aborda directamente los principales dolores de cabeza de GadgetGalaxy. Resuelve la calidad de datos y la inconsistencia al centralizar toda la lógica de limpieza. Mejora drásticamente el rendimiento y reduce costos, ya que consultas que tardaban horas en los datos Bronce ahora tardan minutos o segundos en los datos optimizados de Plata. Finalmente, reduce la complejidad, permitiendo que los analistas trabajen con tablas limpias y bien definidas en lugar de tener que analizar JSON en bruto.

La Capa Oro: La Vista Agregada y Lista para el Negocio

La capa Oro es el acabado final, donde los datos se transforman en conjuntos altamente agregados y específicos para el negocio. Estas tablas están diseñadas para responder directamente a las preguntas de líderes de negocio, analistas y científicos de datos. Aquí los datos se presentan en terminología empresarial, no en jerga técnica.

Para GadgetGalaxy, esto significa crear tablas como gold.marketing_daily_performance, que está pre-agregada para mostrar gasto diario, clics e ingresos atribuidos por campaña de marketing. Otra tabla, gold.product_recommendations, es un conjunto de datos curado específicamente para entrenar su motor de recomendaciones de machine learning. Estos son los conjuntos de datos “oficiales” en los que el negocio puede confiar plenamente.

Al crear esta capa final, GadgetGalaxy resuelve completamente los problemas de accesibilidad y confianza. La Directora de Marketing ya no necesita escribir consultas complejas ni esperar a un ingeniero. Puede conectar su panel de Tableau directamente a la tabla gold.marketing_daily_performance y obtener respuestas al instante. Esto empodera a los usuarios de negocio, elimina el cuello de botella de ingeniería y proporciona un punto final claro y gobernado para el consumo de datos.

Al estructurar su patrimonio de datos en estas tres capas, GadgetGalaxy ha transformado su pantano de datos en una fábrica de datos bien organizada y altamente valiosa. Cada capa tiene un propósito claro, lo que hace que todo el sistema sea más manejable, confiable y rentable.

Conclusiones: Del Pantano de Datos al Activo Estratégico

Nuestro recorrido con GadgetGalaxy ilustra una historia común en el mundo de los datos. La arquitectura de datos moderna, con sus principios de lakehouse y ELT, desbloqueó un potencial sin precedentes para almacenar enormes cantidades de información. Pero sin un marco para gestionarla, ese potencial a menudo se convirtió en un caótico y costoso “pantano de datos”, dejando a las organizaciones ricas en datos pero pobres en información.

La Arquitectura Medallion surgió como el plano esencial para domar este caos. Al imponer una estructura simple pero poderosa de tres niveles—Bronce, Plata y Oro—proporciona un proceso claro y repetible para convertir datos en bruto y poco confiables en perspectivas refinadas y listas para el negocio. Resuelve sistemáticamente los desafíos centrales de calidad, rendimiento y accesibilidad. La capa Bronce asegura los datos en bruto, la capa Plata establece una fuente única de verdad confiable y la capa Oro entrega inteligencia accionable directamente a las personas que la necesitan.

Pero los beneficios de la Arquitectura Medallion van mucho más allá de simplemente organizar tablas. Fomenta una cultura de confianza y responsabilidad sobre los datos. Cuando los usuarios de negocio pueden confiar en las tablas de oro, se vuelven más autosuficientes y orientados a los datos. Cuando los ingenieros de datos tienen un marco claro, pueden construir canalizaciones más sólidas y mantenibles. Y cuando toda la organización comparte una comprensión común de cómo los datos fluyen y se transforman, se crea una base sólida para las aplicaciones más avanzadas, desde recomendaciones impulsadas por IA hasta analítica predictiva en tiempo real.

En última instancia, la Arquitectura Medallion es más que un patrón técnico de diseño; es un enfoque estratégico para la gestión de datos. Es la clave para transformar tu data lakehouse de un simple repositorio de almacenamiento en un motor dinámico, escalable e invaluable para el crecimiento empresarial. Es el camino para garantizar que tus datos no sean solo una ola gigantesca que debes sobrevivir, sino una corriente que puedes aprovechar para alcanzar el éxito.


One response to “Cómo Estructurar tu Data Lakehouse con la Arquitectura Medallion”
  1. […] mencionamos en anteriores publicaciones, el data lakehouse y la Arquitectura Medallion son nuestros planos fundamentales. Entendemos el valor de este enfoque por capas: los datos en […]

Leave a Reply to De caja negra a plano maestro: cómo dbt domestica la arquitectura moderna de datos – Catedra T-Systems X URV Cancel reply

Your email address will not be published. Required fields are marked *