Puntos clave
- Un inventario completo de vistas y un grafo de dependencias son la condición para cualquier conversión masiva a MLV.
- Las reglas de resolución de esquemas y shortcuts se documentan antes de las oleadas de silver y gold.
- Un POC vertical debe superar la paridad y el tiempo de ejecución antes de los lotes de la cola larga.
- Un notebook (o un grupo pequeño) por MLV; la lógica compartida solo en librerías.
- Éxito = comprobaciones de paridad + presupuesto de tiempo de ejecución, no que el objeto exista en el portal.
- Promueve por oleadas de capa, con criterios de parada y un responsable con nombre por lote.
Pasar un puñado de vistas de warehouse a Materialized Lake Views es una reescritura. Pasar un conjunto grande es un programa. Los equipos que tratan la cola larga como un notebook de fin de semana suelen descubrir el orden de dependencias por las malas: gold se rompe, silver se atasca y los shortcuts de bronze nunca se registraron como la verdadera fuente de verdad.
Plantea el trabajo como un recorrido de bronze a silver y a gold, con puertas. Cuenta las vistas. Ordénalas por dependencias. Demuestra un POC representativo. Después convierte con un notebook por vista para que el blast radius siga siendo local. El éxito es paridad más tiempo de ejecución, no "el portal muestra una MLV".
Modelo con nombre: de bronze a silver y a gold, con puertas
- Inventario y orden: cada vista de warehouse, sus referencias y sus consumidores en un grafo antes de que nadie reescriba SQL.
- Oleada de bronze: las definiciones de shortcuts y la resolución de esquemas se estabilizan primero, para que los nombres se resuelvan igual para cada MLV posterior.
- Oleada de silver: las transformaciones se convierten en MLV en notebooks aislables; la paridad y el tiempo de ejecución se siguen por lote.
- Oleada de gold: los consumidores y las medidas conocidas se mueven al final, cuando las claves son estables.
- Puertas: un POC vertical y criterios de parada explícitos se sitúan entre oleadas. El número de objetos en el portal no es una puerta.
- Terminado: paridad acordada frente a una línea base fijada, más un tiempo de ejecución dentro de la ventana de refresco que de verdad vas a usar.
Figura 1. Modelo con nombre: de bronze a silver y a gold, con puertas. Primero inventario y orden. Las oleadas se ganan la promoción. Verde en el portal no es aceptación.
Contexto y restricción
Un grafo de vistas de warehouse suele parecer plano en una diapositiva y está muy anidado en la realidad. Un mega-notebook que convierte "casi todo" deja al equipo cargando con una deriva silenciosa de granularidad. El portal estaba en verde. Las medidas de negocio, no.
Los lakehouses con esquemas y los layouts de shortcuts de bronze cambian cómo se resuelven los nombres. Las vistas que daban por hecho un catálogo de warehouse necesitan una respuesta explícita sobre las rutas. Un POC representativo debe superar la paridad y el tiempo de ejecución antes de empezar con la cola larga. Un notebook por vista mantiene los fallos aislables. "Las vistas existen" es un informe de estado. "Las vistas cuadran y terminan dentro del presupuesto" es un release.
La figura 2 es el planteamiento medallion de Learn. Las capas son un significado compartido. Aun así, el empaquetado necesita puertas cuando conviertes muchas vistas.
Figura 2. La migración a MLV es un programa que recorre bronze, silver y gold. Las puertas van entre capas, no en el deseo de cambiarlo todo en un fin de semana. Fuente: Microsoft Learn: medallion lakehouse architecture.
Diseño
1. Primero contar y ordenar por dependencias
Inventaría cada vista de warehouse, sus referencias y sus consumidores (informes, vistas posteriores, notebooks). Dibuja las aristas antes de reescribir SQL. Una conversión masiva sin grafo es la forma de convertir las hojas antes que los troncos y pasarte una semana persiguiendo objetos que faltan. Los números ganan al optimismo: cuenta las vistas, di la cifra y planifica los lotes.
2. Rediseña la resolución para lakehouses con esquemas
Los shortcuts y los esquemas no son cosméticos. Las rutas de bronze pueden pasar de objetos planos de warehouse a tablas de lakehouse cualificadas con esquema. Actualiza a la vez el modelo mental y el SQL. Documenta cómo leen las MLV el bronze respaldado por shortcuts frente al silver gestionado. La migración es en parte una migración de espacios de nombres que se hace pasar por una migración de sintaxis.
3. Pon como puerta un POC representativo
Elige un corte vertical que toque shortcuts de bronze, una transformación de silver no trivial y un consumidor de gold con medidas conocidas. Demuestra los recuentos de filas, la paridad de claves, los agregados de las columnas críticas y el tiempo real bajo una concurrencia realista. Solo entonces abre las compuertas. Un POC que solo convierte tres vistas aisladas de bronze no te enseña casi nada sobre tu grafo real.
Figura 3. POC vertical antes de la cola larga. Los cortes del camino feliz solo con bronze son teatro de POC.
4. Mejor un notebook por vista que un mega-notebook
Un notebook por MLV (o un grupo pequeño muy acoplado) limita el blast radius, aclara la responsabilidad y hace legibles los diffs de CI. Los mega-notebooks ocultan qué objeto falló e invitan a "volver a ejecutarlo todo" como única recuperación. Los helpers compartidos van en librerías; las definiciones de objetos van en unidades aislables.
Figura 4. Un notebook por vista gana a un mega-notebook. Registra para cada MLV la ruta del notebook, el lote, la paridad, el tiempo de ejecución y el responsable.
5. Define el éxito como paridad más tiempo de ejecución
Que aparezca en el portal no es terminar. Terminar significa que las comprobaciones de paridad acordadas pasan frente a la línea base del warehouse (o una instantánea congelada) y que el tiempo de ejecución cabe en la ventana de refresco que de verdad vas a usar. Sigue ambas métricas por lote. Una MLV rápida y equivocada es una fábrica de regresiones.
6. Promueve por oleadas de capa con criterios de parada explícitos
Primero las definiciones de shortcuts de bronze, cuando los shortcuts tienen que estabilizarse. Después silver para las transformaciones. Gold al final, cuando los consumidores dependen de claves estables. Cada oleada tiene criterios de salida y un plan de vuelta atrás. Saltarse oleadas para "ahorrar tiempo" suele costar el doble en modo incidente.
Qué debería seguir el responsable de la migración
Mantén un registro vivo: nombre de la vista, capa, dependencias, ruta del notebook, id de POC o de lote, estado de paridad, tiempo de ejecución frente al presupuesto y responsable. Revísalo en la misma reunión en la que se prioriza el trabajo de funcionalidades. La deuda de migración se vuelve invisible en cuanto solo se sigue por chat. Si un lote se retrasa, mueve la fecha en el registro; no amplíes en silencio la lista de excepciones de paridad.
Ejecución en paralelo sin engañarte
Si mantienes vivas las vistas de warehouse junto a las MLV, fija la comparación al mismo día de negocio y al mismo conjunto de claves. Una ejecución en paralelo que compara el warehouse del martes con el lakehouse del miércoles fabrica fallos falsos y confianza falsa. Registra qué instantánea de línea base usó el job de paridad. Cuando los stakeholders pregunten por qué un lote va con retraso, enséñales el registro y el nivel que falla, no una vaga sensación de que "Spark va lento".
Errores comunes
Reescribir primero, inventariar nunca. SQL ingenioso, dependientes desconocidos, informes que se rompen por sorpresa.
Un notebook para gobernarlos a todos. Un solo fallo bloquea muchos objetos que no tienen nada que ver.
Teatro de POC. Solo vistas del camino feliz; ningún consumidor de gold; ningún presupuesto de tiempo de ejecución.
Suponer que los nombres del warehouse se trasladan uno a uno. Los esquemas y los shortcuts cambian la resolución; después llegan lecturas silenciosas de la tabla equivocada.
Cantar victoria por el número de objetos. Un lote de MLV con varios fallos de paridad no es una migración.
Convertir gold antes de que existan los shortcuts de bronze. Materializas ficción y luego culpas a Spark.
Úsalo tal cual o adáptalo
Úsalo tal cual
- Un inventario completo de vistas y un grafo de dependencias son la condición para cualquier conversión masiva a MLV.
- Las reglas de resolución de esquemas y shortcuts se documentan antes de las oleadas de silver y gold.
- Un POC vertical debe superar la paridad y el tiempo de ejecución antes de los lotes de la cola larga.
- Un notebook (o un grupo pequeño) por MLV; la lógica compartida solo en librerías.
- Éxito = comprobaciones de paridad + presupuesto de tiempo de ejecución, no que el objeto exista en el portal.
- Promoción por capas con criterios de parada y un responsable con nombre por lote.
Adáptalo antes de usarlo
La carga de un programa parece lenta al lado de "conviértelo y ya". Es más rápida que un cambio a medias que congela los informes. Un notebook por vista añade archivos; a cambio quita misterio. Las puertas de POC estrictas molestan a los stakeholders que quieren una fecha más que una prueba. Dales las dos cosas: una fecha que dependa de las métricas de las puertas. Rediseñar los esquemas puede obligar a pagar temporalmente una ejecución en paralelo. Presupuéstala. Una ejecución en paralelo sin jobs de paridad es teatro.
Referencias principales: Materialized Lake Views y lakehouse schemas en Microsoft Learn. Combínalas con tu inventario de shortcuts y un arnés de paridad por escrito.
Cuenta el grafo. Demuestra un corte. Convierte en unidades aislables. Dalo por terminado cuando la paridad y el tiempo de ejecución coincidan, no cuando el portal parezca muy ocupado.
Relacionado
- MLV + SCD2: ¿es SCD2 en bronze el patrón correcto antes de las MLV de silver? (tablas de historial como MLV antes de los informes a una fecha)
- Calidad de datos en MLV: ¿por qué no hay comprobaciones nativas de unicidad por columna? (comprobaciones por columna en cada cambio)
- Vistas de Warehouse: ¿conviene materializar las vistas pesadas para Direct Lake? (qué vistas pesadas merece la pena materializar primero)
- NEE fallback: ¿por qué varían los resultados con y sin Native Execution Engine? (a dónde se va realmente el tiempo de ejecución de una MLV)