Diseño de lakehouse: ¿un lakehouse con esquemas o muchos lakehouses?

La arquitectura medallion pregunta dónde viven bronze, silver y gold. En Fabric puedes responder con muchos lakehouses o con esquemas dentro de un único lakehouse.

Esa elección se filtra a los shortcuts, los SQL endpoints, los notebooks, el CI/CD y a lo dolorosos que serán luego los cambios de nombre. No es una preferencia de carpetas. Es una decisión de topología.

Figura 1. El empaquetado sigue a la responsabilidad. Muchos lakehouses compran aislamiento a costa de conexiones. Un único lakehouse con esquemas compra menos conexiones a costa de disciplina en los nombres.

Contexto y restricción

Hay equipos que dividen los lakehouses para tenerlo todo limpio y luego se ahogan en cadenas de conexión. Otros mantienen un único lakehouse sin esquemas y ven cómo se convierte en un cajón de sastre donde bronze y gold se mezclan por costumbre. Ambos fallan por motivos distintos. La respuesta correcta depende de la responsabilidad y de los release trains, no de qué captura quedaba más ordenada en un taller.

Dominan dos topologías:

Muchos lakehouses. Un blast radius claro por dominio. Aislamiento mental más fácil. Más artefactos que desplegar, más endpoints que vincular y más errores del tipo "¿en qué lakehouse estoy?" en los notebooks. Funciona bien cuando los límites de responsabilidad o de sensibilidad son reales.

Un único lakehouse con esquemas. Medallion como esquemas (bronze_*, silver_*, gold_*, o esquemas primero por dominio con prefijos de capa). Menos conexiones. Más necesidad de disciplina en los nombres. Activar los esquemas es una propiedad que se fija al crear el lakehouse. Descubrir que necesitabas esquemas cuando el lakehouse ya existe es una sorpresa cara.

Ninguna de las dos es, en abstracto, "más nativa de Fabric". Fabric admite ambas. Tus modos de fallo deciden cuál puedes operar.

La figura 2 es la pantalla de creación donde se decide si se activan los esquemas. La figura 3 muestra los esquemas dentro de un lakehouse una vez tomada esa decisión al crearlo.

Figura 2. Creación de un lakehouse en Microsoft Fabric. La activación de los esquemas se elige aquí, no después. Fuente: Microsoft Learn: lakehouse schemas.

Figura 3. Esquemas dentro de un lakehouse. La disciplina en los nombres se convierte en el sistema operativo. Fuente: Microsoft Learn: lakehouse schemas.

Diseño

1. Identidades estables

Los nombres visibles de los workspaces pueden cambiar por motivos de marca. Los GUID de los lakehouses y de los workspaces no deberían recrearse a la ligera. Trata los id como contratos en la configuración y en los pipelines. Los nombres bonitos son etiquetas. Si tus notas de despliegue todavía dicen "usa el lakehouse llamado Gold A", estás a un cambio de nombre de un fin de semana roto.

2. Destinos parametrizados

Nada de nombres de entornos o de sistemas de origen escritos a fuego en fragmentos de notebook compartidos. Una sesión que trabaja en un dominio no debería heredar el lakehouse por defecto de otro dominio a través de una celda copiada. Pasa el id del lakehouse, el esquema y el entorno como parámetros o mediante un pequeño módulo de configuración que todos los jobs importen de la misma forma.

3. Los shortcuts y los SQL endpoints entran en el alcance

Consolidar o dividir lakehouses cambia cómo se vinculan los shortcuts y los informes. Reserva tiempo para volver a vincular cuando cambies la topología. "Solo hemos cambiado carpetas" casi nunca es cierto para los semantic models, los vínculos de Direct Lake o los consumidores del SQL endpoint. Dibuja el mapa de conexiones antes de migrar, no después del primer informe roto. La figura 4 es ese mapa.

Figura 4. Los notebooks, los shortcuts, los SQL endpoints y los modelos de Direct Lake se vinculan a la identidad del lakehouse. Los cambios de topología necesitan presupuesto para volver a vincular.

4. Superficie de CI/CD

Un único lakehouse puede significar menos elementos, pero más grandes. Muchos lakehouses pueden significar despliegues ruidosos si las herramientas vuelven a publicar artefactos sin cambios en un grafo amplio. Conoce tu herramienta de despliegue antes de optimizar por una u otra belleza. Cuenta lo que cambia de verdad en un merge típico, no lo que promete un diagrama de topología.

5. Ajusta la topología al acceso y a la responsabilidad

Las herramientas de gobierno y los roles de workspace pueden encajar mejor con un modelo o con el otro según cómo aísle los dominios tu plataforma. Si dos equipos no pueden compartir una ventana de fallo, probablemente tampoco deberían compartir un lakehouse. Los esquemas concentran el riesgo cuando los permisos son gruesos. Los lakehouses separados desplazan el riesgo hacia la dispersión. Elige el dolor para el que tienes gente.

Regla práctica para decidir

• Prefiere esquemas en un único lakehouse cuando las capas comparten dominio, equipo y release train.
• Prefiere lakehouses separados cuando los dominios, la sensibilidad o los límites de responsabilidad son reales, no estéticos.
• Prefiere workspaces separados cuando el ciclo de vida, la capacidad o el grupo de colaboradores divergen de verdad, y no finjas que el número de lakehouses lo resuelve por sí solo.
• Nunca inventes un tercer híbrido (unas capas separadas, otras juntas) sin escribir antes el mapa de conexiones. En los híbridos es donde muere el onboarding.

Haz una pregunta directa en la revisión de diseño: si este job escribe en el sitio equivocado, ¿quién se da cuenta y en cuánto tiempo? Esa respuesta debería guiar el empaquetado más que la preferencia por árboles ordenados.

La figura 5 muestra por qué la activación de los esquemas no se puede aplazar como un ticket de limpieza.

Figura 5. Los esquemas se activan al crear. Saltárselo y luego necesitarlos supone, a la vez, el coste de recrear, cambios de id y vínculos rotos.

Errores comunes

Crear un lakehouse nuevo para cada notebook. Topología por agotamiento. Seis meses después nadie sabe qué lakehouse es el canónico.

Saltarse la activación de los esquemas y luego necesitarlos. Coste de recrear y cambios de id. Los pipelines, los shortcuts y la documentación se rompen a la vez.

Escribir a fuego los nombres de los lakehouses en los jobs. Se rompe en cuanto añades un sandbox o un segundo entorno.

Cambiar el nombre de los workspaces en el portal mientras la configuración sigue dependiendo de los nombres visibles antiguos. Prefiere los id. Los nombres visibles son para las personas; los contratos son para las máquinas.

Suponer que los shortcuts "seguirán solos" a una consolidación. Comprueba los semantic models, los SQL endpoints y los valores por defecto de los notebooks. No te pedirán perdón cuando apunten al sitio antiguo.

Híbrido sin mapa. Bronze en un lakehouse, silver y gold en otro "de momento", con notebooks que adivinan. El coste del onboarding se acumula para siempre.

Úsalo tal cual o adáptalo

Úsalo tal cual

• Con esquemas o sin ellos, y el coste de recrear si te equivocas.
• Convención de nombres para esquemas frente a lakehouses (primero la capa, primero el dominio, o ambos con una regla).
• Cómo se vinculan los shortcuts y los semantic models de Direct Lake, y quién se encarga de volver a vincularlos.
• Qué está parametrizado y qué está escrito a fuego en los notebooks y los pipelines.
• Quién es responsable de cada límite de dominio y de su release train.
• No objetivos explícitos: ningún híbrido sin mapa de conexiones; ningún lakehouse por notebook.

Adáptalo antes de usarlo

Los esquemas concentran el riesgo: un job defectuoso puede escribir en el esquema equivocado del mismo lakehouse si los permisos son gruesos. Necesitas nombres más claros, valores por defecto más claros y tests que detecten pronto las escrituras entre capas.

Los lakehouses separados desplazan el riesgo hacia la dispersión y la carga operativa: más cadenas de conexión, más destinos de despliegue, más incidentes del tipo "he conectado el lakehouse equivocado". El aislamiento es real, pero la carga cognitiva también.

Las herramientas de CI/CD castigan los dos extremos de forma distinta. Un único lakehouse enorme puede hacer que los diffs sean más difíciles de revisar. Muchos lakehouses pequeños pueden hacer que los pipelines sean muy charlatanes. Mide el comportamiento real de tu herramienta de despliegue en una rama parecida a producción antes de fijar la topología en una diapositiva para toda la empresa.

Puede que el gobierno y los roles de workspace ya codifiquen los límites de dominio. Ajusta la topología a cómo concedes ya el acceso, o te pasarás la vida peleando con la plataforma a base de excepciones a medida.

Referencias principales: Lakehouse schemas, Lakehouse overview.

Medallion es un significado. Los lakehouses y los esquemas son empaquetado. Elige un empaquetado que puedan sobrevivir tanto tu CI/CD como tu gente.

Relacionado

• Materialized Lake Views: ¿pueden las MLV reemplazar las tablas silver y gold? (mover vistas del warehouse a MLV entre lakehouses con esquemas)