Puntos clave
- El historial de atributos de una dimensión es SCD2 antes de publicar informes a una fecha.
- Las MLV (o un equivalente con nombre) son responsables de la transformación SCD sobre el change feed.
- Dos historiales pueden ir separados cuando la madurez de sus orígenes es distinta.
- Los flags de tipo de evento viajan con las filas del historial; DAX no los reinventa.
- La granularidad de gold y las relaciones a una fecha del modelo semántico se documentan como una sola especificación.
- La aceptación a una fecha incluye fixtures con cambios y correcciones conocidos.
Las dimensiones con el estado actual mienten en cuanto cambia un atributo. Los dashboards que dicen "qué es ahora" están bien para pantallas de estado actual. Las preguntas de historial ("¿qué era cuando ocurrió el hecho?") necesitan una dimensión lentamente cambiante de tipo 2, no la esperanza de que alguien guardara el extracto de ayer.
En cualquier tabla de dimensión cuyos atributos cambian con el tiempo, pongo el historial en Materialized Lake Views SCD2 antes de que nadie construya páginas a una fecha. El change feed es la fuente de verdad. La MLV es la especificación del historial convertida en producto.
Modelo con nombre: SCD2 como especificación de producto
- Change feed: cambios y correcciones fiables (no la esperanza de que alguien guardara el extracto de ayer).
- MLV SCD2: fechas de vigencia declarativas sobre ese feed, con flags de tipo de evento junto a las filas.
- Especificación a una fecha: la granularidad de gold, las claves y las relaciones semánticas comparten un mismo reloj y un mismo predicado de join por escrito.
- Informes a una fecha: las páginas de historial se publican solo cuando la MLV existe y los fixtures pasan.
- Especificación: el estado en un momento dado es una decisión de producto entre gold, las tablas de historial y el modelo, no un disfraz de dashboard sobre dimensiones de tipo 1.
Figura 1. SCD2 como especificación de producto. La verdad del change feed, el historial en la MLV, una granularidad a una fecha compartida y después informes controlados. Las dimensiones actuales responden por hoy. El historial necesita SCD2.
Contexto y restricción
Un fallo habitual: los informes a una fecha no coinciden con las pantallas de estado actual, que solo conocen la fila más reciente. La granularidad parecía correcta hasta que alguien pidió la vista del trimestre pasado. Las dimensiones actuales respondían por hoy. Los usuarios preguntaban por entonces.
Dos historiales no siempre cuentan la misma historia. Si la tabla de cambios de origen está incompleta para un conjunto de atributos, separa las SCD en lugar de forzar un único historial ancho que se inventa la certeza. Los flags de tipo de evento van junto al historial para que la clasificación no se reinvente en DAX en cada sprint.
La figura 2 es el planteamiento de Learn sobre las fechas de vigencia de tipo 2. Modela las fechas antes de pedir a los dashboards que se inventen el historial.
Figura 2. El estado en un momento dado es una cuestión de producto para SCD2. Modela las fechas de vigencia antes de pedir a los dashboards que se inventen el historial. Fuente: Microsoft Learn: tablas de dimensiones en el modelado dimensional.
La figura 3 explica por qué las MLV son un buen hogar cuando el change feed es real. El linaje muestra qué feed alimenta la especificación a una fecha.
Figura 3. Las MLV hacen que las transformaciones de historial se puedan operar. El linaje muestra qué change feed alimenta la especificación a una fecha. Fuente: Microsoft Learn: introducción a las materialized lake views.
Diseño
1. Admite que las dimensiones de estado actual no son historial
Una dimensión que se actualiza en su sitio responde al "ahora". El día que cambia un atributo de una fila de la dimensión, todos los hechos pasados que solo se unen por claves actuales heredan los atributos nuevos, salvo que hayas modelado fechas de vigencia. Fingir que una dimensión de tipo 1 es "suficiente hasta que necesitemos historial" es la forma de acabar reconstruyendo gold con la fecha de entrega encima.
2. Prefiere las MLV cuando el change feed es la verdad
Las Materialized Lake Views funcionan bien cuando puedes expresar la lógica SCD2 de forma declarativa sobre un feed de cambios o de snapshots y rematerializar con una programación que controlas tú. Mantén la lógica cerca del lakehouse, versionada y revisable. Los notebooks con merges hechos a mano están bien para prototipos; se vuelven conocimiento tribal cuando cada ingeniero tiene un caso límite distinto para la fecha de vigencia. La figura 1 muestra ese reparto de responsabilidades como cuatro tareas.
3. Divide un historial en dos cuando los orígenes son desiguales
El conjunto de atributos A puede llegar limpio mientras el conjunto B llega tarde o en otra tabla. Modela dos historiales con granularidades claras en lugar de una mega-SCD dispersa llena de rangos de vigencia nulos. Los informes que solo necesitan el historial A no deberían esperar a la calidad del historial B, y al revés. La figura 4 muestra la división.
Figura 4. Separa los historiales desiguales. Dos granularidades claras ganan a una mega-SCD dispersa que se inventa la certeza. Documentar más objetos sale más barato que uno en el que nadie confía.
4. Lleva los flags de tipo de evento y de clasificación con el historial
Si "cambiado", "reclasificado" y "corregido" son eventos de cambio distintos, guarda los flags junto a las filas de la SCD. Si no, cada modelo semántico inventa su propia lógica CASE, que acaba divergiendo. Un historial sin semántica de eventos se convierte en una línea de tiempo sobre la que se discute en las reuniones.
5. Define la especificación del join a una fecha en gold y en el modelo
Nombra las claves, el predicado a una fecha (tiempo de transacción frente a tiempo de validez, si los distingues) y cómo se enlazan los hechos. Las relaciones semánticas tienen que coincidir con esa granularidad. Una relación puente o de rol que ignora las fechas de vigencia parecerá conectada y aun así devolverá atributos incorrectos.
6. Condiciona los informes a una fecha a que exista la SCD
No publiques una página de informe que sugiera historial mientras el modelo solo tiene dimensiones actuales. Haz que la MLV (o una tabla SCD equivalente) sea una dependencia en la checklist de entrega. Enseña el estado actual sobre dimensiones actuales. Enseña el historial solo cuando SCD2 esté en marcha y probada. La figura 5 es el control.
Figura 5. Condiciona los informes a una fecha a la SCD. El paquete de fixtures en verde antes de la página de historial. Una dimensión solo con el estado actual disfrazada de informe a una fecha no pasa el release.
Fixtures que demuestran el comportamiento a una fecha
Mantén un conjunto pequeño de fixtures: una fila de dimensión que cambia una vez, otra que se reclasifica, otra con un evento de corrección y otra que nunca cambia. Para cada una, comprueba los atributos en instantes anteriores y posteriores al cambio. Si tu lógica SCD no pasa esos fixtures, no discutas sobre los colores del dashboard. Arregla primero el historial. Los paquetes de fixtures también documentan para el siguiente ingeniero el significado de producto de los tipos de evento.
Errores comunes
Tipo 1 para siempre. Las pantallas de estado actual están contentas. La revisión histórica, no.
Una SCD que recoge cada cambio de atributo. Historial ruidoso, granularidad confusa, backfills imposibles. La figura 4 da nombre al antipatrón.
DAX recreando las fechas de vigencia. Lento, incoherente e invisible para los ingenieros de datos.
Dar por hecho que el change feed está completo. Las correcciones tardías sin un tipo de evento de corrección reescriben la historia en silencio.
Joins a una fecha con el reloj equivocado. Se mezclan el tiempo de validez y el tiempo de carga del pipeline sin decirlo.
Publicar el visual antes que la especificación. Los lectores se creen la página. Después del release descubres que la dimensión solo tenía el estado actual. La figura 5 es la checklist que lo evita.
Úsalo tal cual o adáptalo
Úsalo tal cual
- El historial de atributos de una dimensión es SCD2 antes de publicar informes a una fecha.
- Las MLV (o un equivalente con nombre) son responsables de la transformación SCD sobre el change feed.
- Dos historiales pueden ir separados cuando la madurez de sus orígenes es distinta.
- Los flags de tipo de evento viajan con las filas del historial; DAX no los reinventa.
- La granularidad de gold y las relaciones a una fecha del modelo semántico se documentan como una sola especificación.
- Las pruebas de aceptación a una fecha incluyen fixtures con cambios y correcciones conocidos.
Adáptalo antes de usarlo
El almacenamiento y la rematerialización de SCD2 cuestan más que el tipo 1. Lo pagas para responder con honestidad a las preguntas de historial. Las MLV añaden restricciones de la plataforma y una semántica de refresco que tienes que aprender; a cambio, hay menos código de merge a medida. Separar las SCD significa documentar más objetos. La alternativa es un objeto confuso en el que nadie confía. La semántica a una fecha también obliga a los product owners a definir qué reloj importa. Esa conversación es incómoda y necesaria.
Referencias principales: introducción a las Materialized Lake Views, primeros pasos con las Materialized Lake Views y tablas de dimensiones en el modelado dimensional.
Construye SCD2 como una decisión de producto. Ponlo en MLV cuando el change feed sea real. Separa los historiales desiguales. Entonces, y solo entonces, construye los informes a una fecha que la gente no deja de pedir.