Puntos clave
- Una tabla de hechos grande es un hecho de gold con una granularidad escrita.
- El matching de claves y el enriquecimiento se comparten con las tablas de hechos hermanas.
- Direct Lake (o una excepción documentada) para las tablas de hechos de gran volumen.
- Títulos, carpetas y descripciones son obligatorios al publicar.
- El comportamiento de la watermark y de las vistas limpias de bronze se documenta junto al hecho.
- Tests de joins entre hechos con claves de fixture, incluidos los casos sin correspondencia.
Una tabla de origen que lleva el nombre del pipeline que la rellena invita a tratarla como un log desechable. Entonces los informes reinventan en DAX la granularidad, el matching y los títulos. El volumen empuja hacia el modo Import hasta que el refresco se convierte en la caída semanal.
Ponle el nombre del concepto de negocio. Enriquécela con la misma lógica de matching que usa la tabla de hechos hermana. Déjala en gold para Direct Lake. Los títulos, las carpetas de consultas y las descripciones forman parte de la entrega semántica. Los atajos de watermark y las vistas limpias forman parte de la historia de bronze a gold, no son notas a pie de página.
Modelo con nombre: tablas de hechos grandes en gold
- Nombrar: llama al objeto de gold como lo llaman los analistas, no como la tabla de origen del pipeline.
- Enriquecer: resuelve las claves contra la tabla de dimensión con el mismo módulo de matching que usa la tabla de hechos hermana.
- Almacenar: Direct Lake es lo predeterminado para las tablas de hechos de gran volumen cuando el diseño de Delta acompaña; Import solo como excepción acotada.
- Entregar: los títulos, las carpetas de consultas, las descripciones, la documentación de la watermark y los tests de joins con fixtures se publican con el hecho.
- Contrato: volumen sin granularidad ni enriquecimiento compartido es solo un desastre más rápido. Elegir el modo no perdona la deriva semántica.
Figura 1. Tablas de hechos grandes en gold. Ponle el nombre del concepto de negocio, enriquécela como la tabla de hechos hermana, prefiere Direct Lake para el volumen y entrega los títulos con la tabla.
Contexto y restricción
Un fallo habitual: volúmenes de filas que "en el laboratorio iban bien" chocan con las ventanas de refresco de Import y con claves que no cuadran con las de una tabla de hechos hermana. El lake tenía los datos. El semantic model tenía un log con aspiraciones.
Direct Lake es la postura predeterminada para las tablas de hechos grandes cuando el diseño de Delta acompaña. Import es una trampa con esta granularidad. El enriquecimiento tiene que alinearse con el matching de la tabla de hechos hermana para que los informes hagan joins limpios en lugar de contradecirse de una página a otra. Las watermarks y las vistas limpias de bronze alimentan gold; no sustituyen un contrato del hecho.
La figura 2 es la página de Learn que hace visible la historia del destino: los datos de gran volumen llegan como destinos modelados, no como un montón de logs que solo Import puede disfrazar de informe.
Figura 2. Los datos de gran volumen son un hecho. Llévalos a un destino modelado, no a un montón de logs que solo el modo Import puede disfrazar de informe. Fuente: Microsoft Learn: Eventstreams overview.
Diseño
1. Ponle el nombre del concepto de negocio, no el de la tabla del pipeline
Llama al objeto de gold como lo llaman los analistas. Los nombres de pipeline (source_table_v3_compact) van en la documentación de linaje, no en la lista de campos semántica. El lenguaje influye en si la gente modela un hecho o un volcado.
2. Comparte la lógica de matching con la tabla de hechos hermana
Si la tabla de hechos A resuelve claves contra una tabla de dimensión con un módulo, la tabla de hechos B usa el mismo módulo. Un matching distinto produce recuentos que no coinciden entre páginas. La lógica compartida es una regla de plataforma, no una cortesía. La figura 3 muestra ese reparto de responsabilidades.
Figura 3. Comparte el matching entre tablas de hechos. Un solo módulo mantiene alineadas las claves compartidas. Un matching propio en B es la razón de que A diga 100 y B diga 93.
3. Prefiere Direct Lake para el volumen
Un histórico amplio y tasas de ingesta altas castigan el refresco de Import y la capacidad. Da forma a Delta para Direct Lake: tipos razonables, claves estables y evita poner delante vistas del SQL endpoint cuando vuelven a introducir latencia. Documenta cuándo es intencionado un híbrido de dimensión en Import más hecho en Direct Lake. La figura 4 muestra la postura predeterminada frente a la excepción.
Figura 4. Direct Lake es lo predeterminado para la tabla de hechos grande principal. Import es una excepción documentada con límites de filas y una fecha de revisión, no una costumbre.
Direct Lake sigue teniendo un techo de memoria por consulta. Con mil millones de filas, una consulta top 100 a nivel de fila lo alcanzó en todas las ejecuciones (consulta Motores de Fabric con 1B filas: elige por forma de consulta).
4. Títulos, carpetas y descripciones se publican con el hecho
Las columnas del payload en bruto son crípticas. Los títulos pensados para personas y las carpetas de consultas son lo que hace usable el hecho. Incluye descripciones de unidades y enumeraciones. Es la misma disciplina de entrega semántica que en las tablas de gold más estrechas, solo que más urgente con este volumen.
5. Las watermarks y las limpiezas de bronze forman parte de la historia
Los shortcuts, los avances de la watermark y las vistas limpias ligeras explican la frescura y los datos que llegan tarde. Documéntalos junto al contrato del hecho de gold para que la guardia sepa si un hueco es retraso de ingesta o un filtro semántico. No dejes el comportamiento de la watermark como conocimiento tribal en un notebook.
6. Prueba los joins con claves conocidas entre hechos
La aceptación incluye: una clave con filas en la tabla de hechos A y filas en la tabla de hechos B cuadra con las claves compartidas. Revisa por muestreo las claves sin correspondencia de B igual que revisas las de A. El volumen no es excusa para saltarse los tests de granularidad; muestrea a propósito.
El modo Import como excepción documentada
A veces un subconjunto pequeño pertenece de verdad a Import, para un modelo especializado. Escribe esa excepción con límites de filas y una fecha de revisión. Las excepciones sin límites se convierten en el nuevo estándar. Direct Lake sigue siendo la postura para la tabla de hechos grande principal que alimenta los informes generales. Esta claridad evita que un futuro ingeniero lo "simplifique" todo otra vez a Import durante una refactorización que no tiene nada que ver.
Volumen sin contrato es solo un desastre más rápido
Direct Lake no salvará un hecho con una granularidad poco clara o un matching de claves divergente. Solo te ayudará a servir los joins equivocados con más concurrencia. Primero acierta con el nombre, el enriquecimiento compartido y la entrega semántica. Después elige Direct Lake para que el refresco y la capacidad de consulta encajen con la cardinalidad en la que ya decidiste confiar.
Mide pronto: crecimiento de filas por día, duración del refresco en el modo elegido y corrección de los joins con un paquete de fixtures. Los números ganan a las opiniones cuando alguien propone volver a Import "solo para este sprint".
La planificación de capacidad para Direct Lake también necesita responsables; elegir el modo sin monitorizar es puro optimismo.
Errores comunes
Mentalidad de log. Ninguna declaración de granularidad; cada informe se inventa una.
Import por costumbre. Las ventanas de refresco se convierten en la restricción del producto.
Matching propio. La tabla de hechos A dice 100 claves; la tabla de hechos B dice 93.
Nombres técnicos en el modelo. La adopción muere; las bifurcaciones de DAX se multiplican.
Watermarks sin documentar. Los debates sobre frescura no acaban nunca.
Saltarse la revisión de claves sin correspondencia. Las filas huérfanas desaparecen en silencio.
Úsalo tal cual o adáptalo
Úsalo tal cual
- Una tabla de hechos grande es un hecho de gold con una granularidad escrita.
- El matching de claves y el enriquecimiento se comparten con las tablas de hechos hermanas.
- Direct Lake (o una excepción documentada) para las tablas de hechos de gran volumen.
- Títulos, carpetas y descripciones son obligatorios al publicar.
- El comportamiento de la watermark y de las vistas limpias de bronze se documenta junto al hecho.
- Tests de joins entre hechos con claves de fixture, incluidos los casos sin correspondencia.
Adáptalo antes de usarlo
Direct Lake necesita higiene en Delta y entender el framing. Import resulta familiar y falla a escala. Los módulos de enriquecimiento compartidos exigen disciplina de paquetes entre notebooks. Poner títulos en tablas de hechos anchas lleva tiempo; saltárselo cuesta horas a cada consumidor. Mantener al día la documentación de la watermark de bronze es una carga operativa que evita falsas escaladas de incidentes.
Referencias principales: Direct Lake overview, la guía de la arquitectura medallion en lakehouse y la documentación de modelado de Power BI para hechos grandes. Combina la elección del modo de almacenamiento con el contrato de enriquecimiento para que el volumen no excuse la deriva semántica.
Ponles nombre, enriquécelas como a sus hermanas, llévalas a Direct Lake y entrega los títulos con la tabla. Así el volumen se convierte en una cuestión de capacidad que puedes planificar, no en un incendio semanal por sorpresa en el refresco.
Relacionado
- Ingesta con Spark: ¿cómo cargas tablas grandes sin un OOM del driver? (cargar una tabla de origen grande sin que el driver se quede sin memoria)
- Pivotar una vez en gold: ¿cómo sustituyes los pivotes anchos de Import para Direct Lake? (un único hecho de gold ya pivotado en lugar de pivotes anchos en Import)
- Hechos grandes: ¿por qué un refresco en verde sigue derivando? (el contrato incremental que necesita un hecho grande)