Arquitectura Medallón en Databricks: De Datos Brutos a Conjuntos de Datos Listos para IA

Los datos brutos que llegan de los sistemas operacionales son inherentemente poco fiables para el consumo analítico o de IA. Contienen duplicados, inconsistencias de esquema, valores nulos sin significado empresarial y artefactos históricos de migraciones de sistemas upstream. Consumir estos datos directamente crea pipelines frágiles que fallan ante la evolución del esquema, producen resultados analíticos incorrectos y hacen que el entrenamiento de modelos de IA sea poco fiable.

La intuición central de la arquitectura medallón es la separación de responsabilidades por nivel de calidad de datos. En lugar de transformar los datos brutos en forma analítica en un solo paso —un patrón que crea pipelines frágiles y difíciles de depurar—, el enfoque medallón introduce capas de calidad intermedias que aíslan la lógica de transformación, hacen el linaje explícito y permiten a los consumidores downstream confiar en las garantías de calidad de la capa que leen.

Los patrones de capas de datos son anteriores al lakehouse —el área de preparación, el almacén de datos operacional y las capas del almacén de datos de Kimball expresan todos una intuición similar sobre separar la captura bruta de la presentación analítica. Lo que la arquitectura medallón añade es un diseño nativo para el almacenamiento de objetos en la nube a escala, donde las garantías de transacciones ACID de Delta Lake permiten lecturas y escrituras concurrentes fiables entre capas sin la sobrecarga de bloqueo que haría este patrón poco práctico en un sistema de archivos tradicional o en un lago de datos de primera generación.

La capa Bronce es la zona de aterrizaje para los datos brutos de todos los sistemas fuente. Su característica definitoria es la transformación mínima: los datos llegan y se almacenan lo más cerca posible de su forma en la fuente, con la adición de metadatos de ingestión (marca de tiempo de llegada, identificador del sistema fuente, ID de lote). La capa Bronce es de solo adición de forma predeterminada —los registros existentes nunca se modifican, lo que preserva un historial completo de cada evento de la fuente.

La principal preocupación técnica en Bronce es la ingestión fiable y escalable. Azure Data Factory, Databricks Auto Loader y Apache Kafka son mecanismos de ingestión comunes. Auto Loader es particularmente adecuado para el patrón Bronce porque maneja la evolución del esquema automáticamente, procesando incrementalmente los nuevos archivos a medida que llegan a ADLS sin requerir gestión manual del esquema.

La estrategia de particionamiento en Bronce debe estar impulsada por la cadencia de ingestión más que por los patrones de consulta. Para flujos de eventos, el particionamiento por fecha y hora de llegada es estándar; para cargas por lotes, el particionamiento por sistema fuente y fecha de carga hace que la repetición y la depuración sean simples. Escribir Bronce en formato Delta en lugar de Parquet bruto se recomienda generalmente incluso en esta capa más temprana: el registro de transacciones de Delta permite un seguimiento fiable de la evolución del esquema y admite viajes en el tiempo para la investigación de incidentes sin requerir herramientas adicionales ni copias de datos.

La capa Plata es donde los datos brutos se vuelven fiables. Las transformaciones en esta capa se centran en la deduplicación, el manejo de nulos, la conversión de tipos y la aplicación de reglas de validación a nivel empresarial. Una tabla Plata es la primera representación de una entidad en la que un consumidor de datos puede razonablemente confiar: tiene un esquema estable, garantías de calidad documentadas y no está sujeta a la variabilidad upstream de los sistemas fuente.

La capa Plata es también donde típicamente ocurren las uniones entre fuentes. Si una entidad de cliente existe tanto en un CRM como en un sistema ERP, la capa Plata es el lugar apropiado para resolver la entidad y producir un registro de cliente canónico. Esto requiere una lógica cuidadosa de resolución de identidades y, idealmente, un contrato de datos que especifique las reglas de fusión y su justificación empresarial.

Las expectativas de Delta Live Tables (DLT) son el mecanismo de aplicación de calidad más natural para Plata en un entorno Databricks. Las expectativas se declaran como anotaciones de restricciones en la definición del pipeline, y DLT maneja la pregunta operativa de qué hacer con los registros que fallan: ponerlos en cuarentena en una tabla de letras muertas, descartarlos silenciosamente o hacer que el pipeline falle por completo. La elección correcta depende de la criticidad de los datos —para los pipelines de informes regulatorios, fallar ruidosamente es lo correcto; para las agregaciones de analítica, poner en cuarentena los fallos y alertar sobre el volumen es a menudo preferible a detener el flujo.

La capa Oro contiene conjuntos de datos listos para el negocio: métricas agregadas, tablas de hechos desnormalizadas, almacenes de características y conjuntos de datos curados construidos para patrones específicos de consumo analítico o de IA. Las tablas Oro suelen estar diseñadas para responder preguntas específicas en lugar de representar entidades brutas, lo que significa que son más específicas en alcance pero más rápidas de consultar y más fáciles de entender para los consumidores no técnicos.

Un principio de diseño clave para Oro es el diseño orientado al consumidor. El esquema y la granularidad de una tabla Oro deben estar impulsados por cómo el equipo consumidor —un analista de datos, un ingeniero de aprendizaje automático, una herramienta de inteligencia empresarial— necesita leer los datos. Construir tablas Oro de forma aislada de sus consumidores lleva a conjuntos de datos que son técnicamente correctos pero prácticamente inutilizados.

Las tablas Oro deben llevar contratos operativos explícitos: garantías de actualización (actualizado diariamente a las 07:00 UTC, por ejemplo), propietarios documentados con responsabilidades de guardia, y un proceso de obsolescencia que dé a los consumidores downstream un aviso anticipado antes de que una tabla se elimine o reestructure. Sin esta disciplina, los conjuntos de datos Oro acumulan deuda técnica tan silenciosamente como cualquier otro artefacto —pero las consecuencias son más graves: paneles incorrectos y datos de entrenamiento de modelos engañosos, en lugar de compilaciones rotas que se detectan inmediatamente.

El modo de fallo más común para las implementaciones medallón es la proliferación de capas: los equipos crean capas Plata-Prima, Oro-Refinado y Platino como soluciones alternativas a problemas de calidad upstream en lugar de corregir la causa raíz. Esto resulta en un panorama de datos que es tan confuso como el estado previo al medallón, con la complejidad añadida de una convención de nomenclatura que implica garantías de calidad que ya no proporciona.

Un segundo riesgo significativo es la ambigüedad de propiedad. El patrón medallón requiere una propiedad clara de cada capa y cada tabla dentro de ella. Sin esto, las tablas Bronce acumulan datos obsoletos sin propietario que los deprece, las tablas Plata desarrollan deriva de esquema que nadie detecta hasta que un pipeline downstream falla, y los conjuntos de datos Oro se modifican ad-hoc sin versionado.

A nivel de pipeline, dos patrones de fallo son particularmente comunes. Las fusiones no idempotentes: si una transformación Plata se vuelve a ejecutar después de un fallo parcial, las condiciones de MERGE INTO especificadas incorrectamente pueden producir registros duplicados o inconsistentes. La semántica de fusión de Delta Lake es idempotente cuando el predicado de coincidencia es correcto, pero esto requiere un diseño deliberado. La acumulación de archivos pequeños: la ingestión en streaming de alta frecuencia crea muchos archivos pequeños que degradan significativamente el rendimiento de las consultas con el tiempo. OPTIMIZE con AUTO OPTIMIZE habilitado, o ejecuciones de compactación Z-ORDER programadas, deben incorporarse en el manual operativo desde el despliegue inicial en lugar de aplicarse de forma reactiva cuando los tiempos de consulta aumentan.