Puntos clave
- Bronze son shortcuts más vistas de limpieza ligeras para el Delta ya publicado en OneLake. La carga física solo se usa para fuentes externas o fuera de OneLake.
- Un inventario versionado de shortcuts es el contrato de bronze en Git.
- Ningún objeto de bronze limpio o transformado sin una fuente registrada que lo respalde.
- La lógica pesada va en silver o en el origen, nunca como una reescritura silenciosa en bronze.
- La CI valida los shortcuts y los esquemas de las vistas críticas en cada promoción.
- Junto a cada entrada de shortcut figura quién es el responsable del Delta de destino.
Los diagramas medallion siguen tentando a los equipos a cargar una copia física en bronze de todo lo que viene del origen. Cuando el dominio de origen ya publica Delta curado en OneLake, esa copia no es prudencia. Es un segundo warehouse con un nombre más amable.
Bronze puede ser un contrato de shortcuts y vistas de limpieza ligeras. La responsabilidad sigue en el publicador. La frescura sigue al origen. Tu lista de CI/CD pasa a ser el conjunto de shortcuts, no un catálogo en la sombra de tablas clonadas.
Modelo con nombre: bronze como contrato de shortcuts
- Delta del publicador: silver o gold curado que ya está en OneLake. El publicador es responsable del grano y de las claves.
- Inventario de shortcuts: rutas, destinos y grano esperado versionados en Git. La CI los valida en cada promoción.
- Vistas de limpieza ligeras: renombrar, convertir tipos y proyectar columnas para el silver posterior. Siempre respaldadas por un shortcut registrado o por datos en bruto.
- Contrato: si OneLake ya contiene el Delta curado, bronze hace referencia a él. La lógica pesada se queda en silver o se mueve al origen.
Figura 1. Bronze como contrato de shortcuts. Haz referencia al Delta curado. No inventes un segundo warehouse de clones.
Contexto y restricción
Un fallo habitual: bronze parece muy activo y aun así miente sobre la responsabilidad. Los pipelines copian cada noche silver y gold de dominios vecinos. La guardia es responsable de la copia. Nadie es responsable de la deriva cuando el publicador cambia una clave.
La carga física sigue importando para archivos en bruto, volcados de CDC y sistemas fuera de OneLake. No importa para "ya confiamos en esta tabla Delta de al lado". Los shortcuts más vistas de limpieza ligeras ganan a copiar y luego limpiar en coste, frescura y claridad sobre quién arregla un grano roto. Las vistas de limpieza huérfanas, sin shortcut detrás, son ficción. Bórralas o dales respaldo.
La figura 2 es la superficie de Learn para conectar un shortcut a otra ubicación. La plataforma ya tiene los bytes. Mejor un puntero que un clon nocturno.
Figura 2. Bronze puede ser una superficie de punteros. Usa shortcuts de OneLake antes que copiar bytes que la plataforma ya tiene. Fuente: Microsoft Learn: shortcuts de OneLake.
Diseño
1. Separa los datos en bruto externos de los datos curados internos
En una sola palabra conviven dos historias de bronze. Los datos en bruto externos necesitan carga y registro: archivos, extracciones, volcados de API. Los datos curados internos son el Delta publicado por otro dominio. Trátalos de forma distinta en la documentación y en los pipelines. La segunda historia son shortcuts, no escrituras de Spark que repiten el silver de otro.
La figura 3 es la bifurcación que evita que los equipos traten cada tabla del origen como una extracción que hay que volver a cargar.
Figura 3. Dos historias de bronze. Carga física para fuentes externas y fuera de OneLake. Shortcuts para el Delta curado de al lado en el que ya confías.
2. El conjunto de shortcuts es el contrato de bronze
Lista en el repo cada ruta de shortcut, el workspace o lakehouse de destino y el grano esperado, igual que listas los contratos de API. La promoción y la revisión deberían preguntar si cambió el conjunto de shortcuts, no si un job de copia terminó en verde. Cuando un publicador renombra una tabla, el contrato se rompe en un único sitio que puedes encontrar.
3. Vistas de limpieza ligeras, no una segunda capa de transformación
Las vistas de limpieza sobre shortcuts se encargan de renombrar, ajustar tipos y elegir columnas para el silver posterior. No deberían convertirse en un medallion paralelo. Si la vista necesita lógica de negocio pesada, estás colando silver en bronze. Lleva esa conversación al origen o hazte responsable de una transformación silver real con un motivo.
4. Elimina las vistas de limpieza huérfanas
Una vista "limpia" o "transformada" sin shortcut (ni datos en bruto registrados) es una tabla que alguien inventó porque tenía un notebook abierto. Conéctala a una fuente real o bórrala. Las huérfanas confunden las claves de join, la documentación y a las personas nuevas, que dan por hecho que cada objeto de bronze tiene respaldo.
La figura 4 es el control de la revisión: lo ligero se queda, lo disfrazado se muda, lo huérfano desaparece.
Figura 4. Las vistas de limpieza ligeras se quedan en bronze cuando tienen respaldo. Las disfrazadas se mudan a un silver con nombre. Las huérfanas se conectan o se borran.
5. Mantén aburridas las claves de join
En cuanto bronze deja de inventar tablas físicas paralelas, las claves siguen siendo las del publicador. Tu silver hace join sobre claves de negocio documentadas en lugar de sobre "la clave subrogada de nuestra copia, que se desvió el martes pasado". Los nombres siguen siendo sencillos cuando no mantienes tablas de alias para la misma entidad.
6. Documenta la CI/CD en torno al mapa de shortcuts
Las notas de despliegue deberían incluir los pasos para recrear o validar los shortcuts. Un lakehouse que se promociona sin shortcuts es una promesa vacía. Une el mapa con la responsabilidad: qué equipo es dueño del Delta de destino y qué equipo de las vistas de los consumidores.
Qué significa "ligera" en una revisión
Una vista de limpieza que renombra columnas, convierte tipos ya decididos en el origen y proyecta las columnas que necesita silver es ligera. Una vista que recalcula un estado de negocio, inventa claves subrogadas o filtra a un subconjunto preferido sin documentar por qué es silver disfrazado. Los revisores deberían rechazar las vistas disfrazadas o exigir que se muden a una transformación silver con nombre y con pruebas. Un bronze solo de shortcuts fracasa si cada equipo cuela lógica en la capa de limpieza porque "estaba ahí mismo".
Errores comunes
Copiar por comodidad. "Puede que lo necesitemos sin conexión" se convierte en un mantenimiento doble permanente. Pagas almacenamiento y conciliación para siempre.
Vistas de limpieza que reescriben el grano. Lo ligero se vuelve pesado. De repente bronze es responsable de reglas de negocio que el publicador nunca firmó.
Republicar en silencio el gold del origen como bronze local. Los consumidores creen que tu workspace es el sistema de registro. Los tickets de soporte rebotan sin fin.
Proliferación de shortcuts sin lista. Veinte shortcuts, ningún archivo de contrato y una ruta rota en producción. El mismo fallo que con las API sin documentar.
Suponer que frescura es lo mismo que éxito del pipeline. Tu job de copia puede terminar bien con los datos de ayer mientras el publicador ya corrigió los de hoy. Los shortcuts heredan la verdad; las copias inventan retraso.
Úsalo tal cual o adáptalo
Úsalo tal cual
- Bronze son shortcuts más vistas de limpieza ligeras para el Delta ya publicado en OneLake. La carga física solo se usa para fuentes externas o fuera de OneLake.
- Un inventario versionado de shortcuts es el contrato de bronze en Git.
- Ningún objeto de bronze limpio o transformado sin una fuente registrada que lo respalde.
- La lógica pesada va en silver o en el origen, nunca como una reescritura silenciosa en bronze.
- La CI valida los shortcuts y los esquemas de las vistas críticas en cada promoción.
- Junto a cada entrada de shortcut figura quién es el responsable del Delta de destino.
Adáptalo antes de usarlo
Los shortcuts te atan a la disponibilidad y a los permisos del publicador. Esa es la idea. Si necesitas una instantánea aislada para una extracción regulada, dilo y carga una copia deliberada con reglas de retención. No finjas que todas las tablas necesitan esa postura.
Los shortcuts entre workspaces necesitan higiene de identidad y de uso compartido. Los equipos que no pueden compartir Delta tampoco deberían simular una integración con clones nocturnos. Arregla el modelo de uso compartido o acepta una tabla de interfaz formal de la que sea responsable el publicador.
Las vistas ligeras también necesitan pruebas cuando cambian los tipos en el origen. Cambias el retraso de la copia por la vigilancia del contrato. Pon comprobaciones de esquema en los destinos de shortcut que te importan.
Referencias principales: shortcuts de OneLake, introducción a Lakehouse y esquemas de Lakehouse.
Si tu carpeta de bronze es un museo de clones, redúcela a un contrato de shortcuts y vistas ligeras. El coste, la frescura y la responsabilidad se vuelven honestos de un solo golpe.
Relacionado
- PII en Fabric: ¿qué harías al ingerir datos sensibles? (la otra frontera: qué puede salir del lakehouse)