No history yet

Diseño de Arquitectura Medallion

Del Data Lake al Lakehouse Transaccional en AWS

La arquitectura de data lake tradicional sobre Amazon S3, aunque escalable y rentable, a menudo sufre de una falta de fiabilidad. Sin transacciones ACID, la gestión de actualizaciones concurrentes, eliminaciones y la corrección de errores se convierte en una pesadilla de ingeniería. Esto conduce a los temidos “data swamps”, donde la calidad y la confianza en los datos se erosionan. La evolución natural es el Lakehouse, que impone la estructura y fiabilidad de un data warehouse directamente sobre la flexibilidad del almacenamiento de objetos de S3.

Este cambio es posible gracias a los formatos de tabla abiertos como Apache Iceberg o Delta Lake. Estos formatos actúan como una capa de metadatos transaccionales sobre los archivos Parquet o ORC en S3. Gestionan el versionado de datos, la evolución del esquema y, lo más importante, habilitan transacciones atómicas. El resultado es un único repositorio de datos que soporta tanto cargas de trabajo de BI como de machine learning, eliminando la necesidad de duplicar datos en sistemas separados.

Estructura Medallion en S3

La arquitectura Medallion organiza los datos en tres capas lógicas, cada una representando un nivel progresivo de calidad y refinamiento. Este patrón no se trata solo de carpetas, sino de un contrato de calidad de datos en cada etapa. Su implementación en AWS se mapea directamente a una estructura de prefijos en un bucket de S3.

Una estructura de prefijos bien diseñada es fundamental para el control de acceso, la optimización de costos y el rendimiento de las consultas.

Capa Bronze (Cruda):

  • Propósito: Persistencia de los datos de origen en su estado original. Es una fuente de verdad histórica e inmutable.
  • Estructura en S3: s3://<bucket>/bronze/<dominio>/<tabla>/ingestion_date=YYYY-MM-DD/. El particionamiento por fecha de ingesta es crucial para reprocesar datos de manera eficiente.
  • Formato: Generalmente el formato de origen (JSON, CSV) o un formato binario como Avro. No se aplican esquemas en la lectura; la estructura es la que provee el origen.

Capa Silver (Validada):

  • Propósito: Proporcionar una visión limpia, validada y unificada de los datos. Aquí es donde los datos se vuelven confiables para el análisis.
  • Transformaciones: Limpieza de tipos de datos, manejo de nulos, deduplicación, y join con datos de referencia (ej. enriquecer un ID de usuario con datos de un CRM).
  • Estructura en S3: s3://<bucket>/silver/<dominio>/<tabla>/. El particionamiento se basa en las claves de consulta más frecuentes (ej. country=US o event_date=YYYY-MM-DD). Se utiliza un formato columnar como para optimizar las lecturas analíticas.

Capa Gold (Agregada):

  • Propósito: Servir datos agregados y optimizados para casos de uso de negocio específicos, como dashboards de BI o features para modelos de ML.
  • Transformaciones: Agregaciones a nivel de negocio (ventas mensuales por producto), KPIs, y modelado en esquemas de estrella o copo de nieve para un rendimiento de consulta óptimo.
  • Estructura en S3: s3://<bucket>/gold/<agregado_de_negocio>/. La granularidad es mucho menor y está totalmente orientada al consumidor final.

Modelado y Estrategias de Diseño

El diseño de un Lakehouse Medallion exitoso va más allá de la estructura de carpetas. Requiere un modelado de datos intencionado en cada capa. En la capa Silver, a menudo se busca una forma normalizada (similar a 3NF) para eliminar redundancias y crear una fuente de verdad coherente. Esto facilita el análisis exploratorio y la reutilización de datos en múltiples tablas Gold.

La capa Gold, por otro lado, es inherentemente denormalizada. Aquí se construyen tablas de hechos y dimensiones pre-unidas, optimizadas para las herramientas de BI. Las agregaciones se precalculan para que los dashboards se carguen instantáneamente, en lugar de ejecutar consultas complejas sobre los datos de la capa Silver en tiempo real.

Una estrategia clave es la segregación de dominios de datos. Cada dominio de negocio (ej. marketing, finanzas, logística) puede gestionar su propio pipeline Medallion dentro del mismo Lakehouse. Esto se alinea con los principios de [{}] y fomenta la autonomía y la propiedad de los datos.

Para garantizar la alta concurrencia y la evolución del esquema, es imperativo utilizar formatos de tabla abiertos. Por ejemplo, al usar Apache Iceberg, las operaciones de escritura (como una actualización en la capa Silver) crean un nuevo snapshot de metadatos que apunta a los archivos de datos nuevos y existentes. Las lecturas concurrentes pueden seguir usando el snapshot anterior hasta que estén listas para ver los datos actualizados, garantizando consistencia y aislamiento sin bloqueos.

-- Ejemplo: Actualización atómica en la capa Silver usando SQL con Iceberg
-- Esta operación MERGE se ejecuta como una única transacción ACID en S3.

MERGE INTO lakehouse.silver.customers c
USING (SELECT * FROM lakehouse.bronze.updates_today) u
ON c.customer_id = u.customer_id
WHEN MATCHED THEN
  UPDATE SET c.address = u.new_address, c.last_updated = current_timestamp()
WHEN NOT MATCHED THEN
  INSERT (customer_id, address, created_at, last_updated)
  VALUES (u.customer_id, u.new_address, current_timestamp(), current_timestamp());

Este enfoque desacopla completamente el cómputo del almacenamiento. Motores como Spark, Trino o Amazon Athena pueden operar sobre el mismo conjunto de datos en S3, cada uno optimizado para su tarea específica. La arquitectura Medallion, impulsada por formatos de tabla transaccionales, transforma un simple data lake en un activo de datos robusto, fiable y preparado para el futuro.