Microsoft Fabric Data Warehouse: Power BI y arquitectura de datos

By Mirko Peters · 2026-02-26 · Updated 2026-03-24

Aprende sobre almacenes de datos con Microsoft Fabric y Power BI usando Microsoft Learn. Unifica datos, explora la arquitectura de Fabric y garantiza la gobernanza.

Automatically translated with AI from the original post. Read the English original

Seguramente has vivido este momento: presentas un panel de control cuidadosamente preparado y un directivo se recuesta en la silla y dice: "¿Puedes poner todos los KPI en una sola página?". Tu primer impulso es abrir Power BI y empezar a reordenar los mosaicos. Pero, siendo sinceros, esa petición no tiene que ver con el diseño, sino con la confianza. Te están diciendo (con educación) que el sistema actual no responde de forma fiable a la pregunta "¿Qué hacemos a continuación y quién lo hace?". Yo lo aprendí por las malas tras entregar lo que creía un informe "listo para el consejo", solo para ver cómo una reunión de 20 minutos se convertía en una discusión de 90 sobre de quién era la cifra de ingresos "real". Ahí lo entendí: los paneles muestran información; los sistemas de decisión hacen cumplir las decisiones. Y tu trabajo es construir el segundo.

1. Fabric unifica el análisis y la gestión de métricas: la arquitectura de KPI combina almacenamiento, cómputo, métricas y visualización en una sola plataforma (OneLake + Lakehouse + Power BI) en lugar de sistemas de métricas separados.
2. Almacenamiento nativo de series temporales: las arquitecturas de KPI en Fabric suelen guardar los KPI como datos de series temporales optimizados dentro de tablas de lakehouse, lo que permite una retención eficiente, reducción de resolución (downsampling) y consultas rápidas por ventanas de tiempo sin necesidad de una TSDB independiente.
3. Linaje automático a nivel de KPI: Fabric captura el linaje de extremo a extremo de las definiciones de KPI, mostrando exactamente qué tablas, cuadernos o canalizaciones contribuyen a cada métrica, lo que permite la trazabilidad para aprobaciones y auditorías.
4. Semántica de KPI de bajo código y reutilización: una capa semántica permite a los equipos definir los KPI canónicos una sola vez (cálculos, umbrales, dimensiones) y reutilizarlos en informes, alertas y modelos de ML sin reescribir la lógica.
5. Alertas en tiempo real con latencia casi nula: combinando la ingesta en streaming (canalizaciones de Fabric) con cómputo incremental y vistas materializadas, la arquitectura de KPI puede activar alertas y acciones casi en tiempo real.
6. Observabilidad integrada y señales de coste: Fabric muestra no solo el rendimiento de los KPI, sino también el coste de las consultas, la duración de las actualizaciones y el impacto en el almacenamiento por KPI, lo que convierte la optimización operativa en parte de la arquitectura de KPI.
7. Recomendaciones de KPI asistidas por IA: Fabric puede sugerir definiciones de KPI, agregaciones y líneas base para la detección de anomalías analizando patrones de datos históricos y de uso, lo que acelera el diseño de KPI.
8. Compartición de KPI multiinquilino y gobernada: la arquitectura admite la compartición segura y gobernada de KPI entre equipos y clientes mediante modelos semánticos y controles de acceso, evitando copias de datos y manteniendo el aislamiento.

El significado real de "todos los KPI en una página"

Cuando un directivo te pide un panel ejecutivo de KPI con "todos los KPI en una página", tómalo como una petición de un plano de control determinista, no de un diseño más compacto. Normalmente significa que no confía en que las cifras actuales sean coherentes, que estén definidas del mismo modo en todos los equipos o que estén vinculadas a una acción clara. El problema no es la falta de visibilidad. Es la falta de confianza.

Traduce la petición: la confianza es la funcionalidad que falta

"Hazlo más sencillo" suele aparecer después de que los líderes se hayan quemado con definiciones contradictorias, retrasos en las actualizaciones o debates sobre los KPI. Eso es entropía empresarial: las métricas se multiplican, los significados se desvían y la "verdad" depende de qué informe hayas abierto. El resultado es fricción en la toma de decisiones, dicho claramente: debate, ambigüedad y reuniones interminables.

El dolor oculto: la latencia de decisión

El coste real es la latencia de decisión: el tiempo que se pierde entre ver una cifra y actuar sobre ella. Los paneles mejoran la telemetría (lo que puedes ver), pero no reducen la latencia a menos que también impulsen una acción. Incluso con Power BI, Fabric, OneLake, Purview o Copilot, puedes acabar con "gráficos de adorno": visualizaciones pulidas que parecen contundentes pero no cambian los resultados.

No solucionas un problema de confianza con gráficos más bonitos; lo solucionas con reglas repetibles y una propiedad responsable. — Cassie Kozyrkov

Autoevaluación rápida: ¿es telemetría o control?

Hazte una pregunta: si un KPI cambia, ¿se mueve algo más automáticamente? Si la respuesta es "programamos una reunión", no tienes un sistema de KPI, tienes una galería de informes.

• ¿Un umbral genera un disparador claro?
• ¿Hay un único responsable que rinde cuentas?
• ¿La respuesta está preacordada y tiene un plazo definido?
• ¿El resultado queda registrado para auditoría y aprendizaje?

Lo que una "página" debería contener realmente

Un plano de control de KPI es un único lugar donde las métricas se convierten en obligaciones: disparadores, responsables, plazos y un registro de las acciones. Así es como se construye un motor de decisiones determinista, y no metiendo más mosaicos en Power BI.

Nota aparte: tus habilidades de diseño no son el problema; el problema es el sistema.

Entropía empresarial: cómo los KPI se degradan en silencio con el tiempo

La entropía empresarial no es un fallo dramático. Es la lenta expansión de definiciones contradictorias y métricas duplicadas, hasta que tus paneles dejan de ser un plano de control y se convierten en un escenario de debate. La reconocerás cuando los líderes pregunten: «muestra todos los KPI en una página» o «hazlo más sencillo». Esa petición suele ser una señal: la inconsistencia de las métricas está generando desconfianza, y tu configuración actual no puede sostener una toma de decisiones basada en datos fiable.

El clásico argumento aparece enseguida: «¿Nuestros ingresos son los mismos que los suyos?» Un equipo extrae datos del CRM, otro del ERP y un tercero de una exportación «limpiada». Ahora tienes fuentes no sincronizadas que producen verdades en conflicto, y cada reunión empieza con una conciliación en lugar de con una acción.

Deriva semántica: el nombre del KPI permanece, pero el cálculo cambia

La entropía empeora cuando la etiqueta se mantiene estable pero el cálculo cambia en silencio. El «margen bruto» pasa a ser «margen bruto (excluyendo el flete)» en un informe, después se añade un nuevo filtro a una medida de Power BI y nadie actualiza la definición. Sin control de versiones del modelo semántico, no puedes responder a la pregunta más sencilla: ¿qué cambió, cuándo y por qué?

Cuando las medidas no están definidas ni gobernadas, no tienes métricas, tienes opiniones con marca de tiempo. — Martin Fowler

Las tres fuentes de caos en los KPI que sigues heredando

• Datos no sincronizados: la frecuencia de actualización, el nivel de detalle y las combinaciones difieren entre sistemas y áreas de trabajo.
• Canalizaciones ad hoc: las transformaciones «temporales» se convierten en dependencias de producción sin responsable.
• Correcciones manuales: el parche rápido que se salta la lógica, el linaje y la revisión.

Seguro que has vivido la escena: el parche de hoja de cálculo del viernes. Alguien exporta los datos, «corrige» unas cuantas filas y envía por correo un número listo para el consejo de administración. El viernes siguiente vuelve a pasar, y ya se ha convertido en un proceso. Así es como la degradación de los KPI se vuelve normal.

Por eso, el self-service sin gobierno de Power BI acaba en duplicación de KPI a escala. Las capas semánticas gobernadas reducen los KPI duplicados y mejoran la confianza en las decisiones, sobre todo cuando se cuestionan. Y cuando la sala exige pruebas, el linaje de Purview te proporciona los justificantes.

Los cinco requisitos imprescindibles para que los KPI sean «accionables»

Cuando los líderes te piden que «muestres todos los KPI en una página», en realidad piden control: menos debates, decisiones más rápidas y un motor de decisiones determinista que convierta las señales en obligaciones.

Una buena métrica es la que cambia el comportamiento; si no lo hace, es trivia. — John Doerr

1) Definición del disparador (deja de renegociar la alerta)

Cada KPI necesita un disparador preciso: umbral + duración + contexto. Si no puedes enunciarlo con claridad, seguirás discutiendo qué significa «malo».

Ejemplo de disparador: forecast variance > -7% for ten days in EMEA enterprise.

2) Propiedad única (responsabilidad de un solo titular)

Cada disparador debe dirigirse a un único responsable, no a un comité, a un canal ni a «el negocio». La propiedad única evita la dispersión y obliga a un siguiente paso claro: actuar o registrar una excepción.

3) Acción preacordada (prohibido «programar una reunión»)

La capacidad de actuar requiere planes de respuesta, no solo visibilidad. Debes preacordar la respuesta para que el sistema pueda ejecutarla de forma coherente.

Hipotético: si se cumple forecast variance > -7% for ten days in EMEA enterprise, tus playbooks de Power Automate activan una congelación del gasto discrecional, notifican a Finanzas y abren una tarea con seguimiento para el responsable, siempre.

4) Restricción temporal (plazos según el riesgo)

Las obligaciones con plazo reducen la latencia de las decisiones, porque eliminan «ya lo veremos» como opción. Define las ventanas de respuesta según el riesgo, no según calendarios mensuales.

Ejemplo: respond within 15 minutes for a Sev 1 breach.

5) Bucle de retroalimentación (hazlo auditable)

Los paneles no tienen memoria. Necesitas un libro operativo de KPI que registre disparador → responsable → acción → marca de tiempo → resultado. Al principio resultará rígido; precisamente por eso funciona. Así es como integras la acción en el proceso y la arquitectura, y no como «buenas prácticas».

1. Disparador definido
2. Responsable asignado
3. Acción comprometida de antemano
4. Plazo aplicado de forma obligatoria
5. Resultado aprendido y registrado

Construye el "Decision Stack" (y deja de tratar el dashboard como el producto)

Cuando los líderes piden "mostrar todos los KPI en una sola página", no están pidiendo un mejor diseño. Están señalando poca confianza: el sistema no produce decisiones claras y repetibles. Un dashboard es telemetría. El control requiere una pila que convierta señales validadas en acciones con responsable, a tiempo y con evidencia.

Si no puedes explicar qué pasa después de que se dispare la alerta, no construiste un sistema, construiste un informe. — Gene Kim

Capa 1 — Datos: Microsoft Fabric OneLake como límites de convergencia

Usa Microsoft Fabric y OneLake como límites de convergencia: el lugar donde deben llegar los datos de calidad para decisiones, con contratos de actualización, fuentes certificadas y menos "extracciones en la sombra". Esto contiene la entropía al evitar varias versiones no sincronizadas de los mismos insumos de los KPI.

Capa 2 — Lógica: gobierno de Power BI para un único significado por término

Coloca cada definición crítica en un modelo semántico gobernado. Con gobierno de Power BI, controlas las versiones de las medidas (como ingresos, abandono o SLA), aplicas una gestión formal de cambios y evitas la deriva semántica. Purview añade linaje para que puedas justificar de dónde vienen los números, y Copilot puede ayudar a documentar la lógica, pero no puede reemplazar al gobierno.

Capa 3 — Estado: un registro operativo de KPI que combate la amnesia del dashboard

Los dashboards olvidan. Muestran el "ahora", no qué se disparó, quién era el responsable ni qué pasó después. Crea un registro operativo de KPI en Dataverse para guardar disparadores, responsables, marcas de tiempo, acciones, excepciones y resultados, de modo que la responsabilidad sobreviva a los ciclos de actualización.

Capa 4 — Acción: playbooks deterministas con Power Automate

Usa Power Automate para convertir eventos validados en respuestas consistentes: asignar a un único rol responsable, aplicar plazos, exigir una acción o una excepción registrada, y volver a escribir en el registro. La ejecución repetible es la forma de evitar la deriva de los KPI.

Capa 5 — Interfaz: muestra estados de decisión, no solo gráficos

Tu dashboard se convierte en un punto de acceso: "¿Qué está vencido? ¿Quién es el responsable? ¿Cuál es el siguiente paso?" Piensa en control de tráfico aéreo, no en un panel de llegadas más bonito.

Gobierno que no se siente como un impuesto: productos certificados + linaje

Si la toma de decisiones basada en datos te parece lenta, normalmente no es por falta de dashboards. Es por falta de confianza. El gobierno de Power BI real no es un proceso extra: es velocidad, menos debates, menos ciclos de retrabajo y menos reuniones de "¿qué número es el correcto?".

Define los "productos de datos certificados" como calidad para decisiones

Empieza por hacer que los productos de datos certificados signifiquen algo concreto en tu organización. "Calidad para decisiones" no es una sensación; es un contrato. Un producto certificado debe cumplir reglas claras:

• Con propietario: un único responsable con una ruta de soporte.
• Documentado: el significado de negocio, los filtros y las exclusiones están por escrito.
• Probado: comprobaciones básicas (actualidad, completitud, conciliaciones clave).
• Estable: los cambios siguen una gestión formal de cambios, no ediciones silenciosas.

Contratos de actualización: "lo bastante actual para actuar"

Los directivos no necesitan "tiempo real". Necesitan "lo bastante actual para actuar". Ponlo por escrito: ¿cuándo deben actualizarse los datos y qué pasa si no se actualizan? Esto evita que los disparadores de KPI se activen con datos obsoletos y reduce el tiempo perdido validando números a posteriori.

Linaje y auditabilidad: responde rápido a "¿de dónde sale este número?"

Usa Microsoft Purview para el linaje y la auditabilidad, de modo que puedas rastrear un KPI desde Power BI hasta el modelo semántico, y de ahí a las tablas de origen y a los pipelines. La investigación y la experiencia de campo coinciden: el linaje y la certificación aumentan la confianza y reducen el tiempo dedicado a validar números.

Sin linaje no hay responsabilidad; solo hay confianza hasta la primera auditoría. — Satya Nadella

Versionado del modelo semántico: el self-service está permitido, la semántica no es negociable

Deja que las personas creen informes, exploren con Copilot y segmenten los datos con libertad, pero bloquea el significado. Las definiciones semánticas gobernadas evitan KPI duplicados e informes inconsistentes. Usa control de versiones del modelo semántico para que "Ingresos" y "SLA" tengan una única definición aprobada, con un registro de cambios visible. La forma más rápida de perder la confianza es cambiar una definición sin avisar a nadie. La capa semántica garantiza que el autoservicio esté gobernado, no que sea caótico.

Operacionalizar los KPI: de las alertas a las obligaciones (en términos de Microsoft)

Si tu KPI solo genera una alerta, sigues sin tener control; tienes ruido. Lo que necesitas es un plano de control de KPI en el que cada KPI esté asignado a una obligación determinista: desencadenante → responsable → acción → SLA → evidencia. Así sustituyes la interpretación por un compromiso previo, y por eso los flujos de trabajo deterministas reducen la carga de reuniones: el sistema decide qué ocurre a continuación, siempre.

Asigna cada KPI a un playbook de Power Automate

Crea playbooks de Power Automate que se inicien solo a partir de eventos analíticos validados (no de correos ad hoc ni de "alguien se dio cuenta"). Cada playbook debe dirigirse a un único responsable que esté obligado a actuar o a registrar formalmente las excepciones. Las aprobaciones y las escalaciones deben seguir protocolos estructurados y con plazos definidos para proteger el flujo determinista.

• Desencadenante: umbral + duración + contexto
• Responsable: una única persona con nombre
• Acción: siguiente paso acordado de antemano (no "programar una reunión")
• SLA: ventana de respuesta alineada con el riesgo
• Evidencia: registro con marca de tiempo de lo que ocurrió

Usa Dataverse como tu registro operativo de KPI

Los paneles olvidan. Tu registro operativo de KPI no debería. Usa Microsoft Dataverse como sistema de registro para los desencadenantes, las asignaciones, las acciones, las excepciones y los resultados. Un registro de acciones duradero te permite medir la eficacia de las intervenciones a lo largo del tiempo: qué funcionó, qué no y qué desencadenantes necesitan ajustes.

Diseña notificaciones que no saturen

Envía menos notificaciones, pero mejores: un responsable, un plazo y un siguiente paso claro. Si el responsable no puede actuar, debe registrar una excepción con un motivo y un nuevo compromiso; nada de ignorar en silencio.

Mini escenario: incumplimiento de Sev 1

La automatización no sustituye el criterio; lo protege de que la ambigüedad lo retrase. — Mary Poppendieck

Lo que tu "KPI en una página" debería mostrar realmente

Cuando los directivos piden un panel ejecutivo de KPI "en una sola página", rara vez piden menos gráficos. Lo que buscan es certidumbre: qué necesita atención, quién tiene la responsabilidad y si se está gestionando. Una vista de una página solo aporta valor si funciona como un plano de control de KPI: un panel de mando, no un collage.

Los mejores paneles no responden "¿qué pasó?", sino "¿qué se está haciendo al respecto?". — Avinash Kaushik

Sustituye "todas las métricas" por "todas las decisiones en curso"

Tu página debería listar las obligaciones activas, no un catálogo de KPI. Si una métrica no puede desencadenar una acción, no debe estar en la página ejecutiva. Una opinión algo provocadora: si no puede mostrar responsabilidad, no es una página ejecutiva.

Muestra estados de decisión, no solo números

Los directivos valoran la claridad de la acción más que el detalle exhaustivo. Convierte la página en una cola en vivo de estados de decisión:

• Activado (umbral superado)
• Reconocido (alguien ha aceptado la responsabilidad)
• En curso (el trabajo está en marcha)
• Vencido (plazo incumplido)
• Resuelto (cerrado con resultado)

Asocia un nombre a cada obligación

Cada elemento activo necesita un único responsable: una persona, no un equipo. Aquí es donde terminan las peticiones de "algo más sencillo": en cuanto tu página muestra quién está actuando, los directivos dejan de discutir el diseño y empiezan a gestionar la ejecución.

Muestra el reloj: tiempo desde el desencadenante y tiempo hasta el plazo

Añade dos campos de tiempo: antigüedad (cuánto tiempo ha pasado desde que se activó) y tiempo restante (hasta el plazo de respuesta). Las interfaces que muestran las obligaciones reducen la ambigüedad y alinean la ejecución rápidamente.

Adjunta enlaces a la evidencia para que la confianza sea automática

Cada fila debe enlazar con sus pruebas: definición y versión de la métrica, linaje de datos y registro de acciones. Power BI puede ser la interfaz, pero Dataverse y Power Automate deben encargarse de recordar y hacer cumplir las reglas por debajo, convirtiendo la página en un motor de decisiones determinista, y no solo en telemetría.

Carta comodín: un «Sprint de determinismo» de 30 días que puedes ejecutar sin dramas

Si los directivos siguen pidiendo «todos los KPI en una sola página», el problema no es de diseño, sino de confianza. Un Sprint de determinismo de 30 días es un piloto pequeño y acotado que construye un plano de control de KPI rápidamente, sin una reescritura empresarial. Empieza donde la fricción es mayor: poner en marcha unos pocos KPI con mucha fricción restaura la confianza más rápido que intentar abarcarlo todo.

Empieza donde más duele; las mejores victorias en gobernanza son las que terminan una discusión. — Kimball Cho

Semana 1: elige 3 KPI que causen discusiones con frecuencia

Elige tres KPI que provoquen debates, retrabajo o momentos de «¿de quién es el número correcto?». Busca los puntos donde la confianza ya es escasa: ingresos, SLA, abandono de clientes, desviación de la previsión. Así el sprint se mantiene realista y medible.

Semana 2: fija las reglas (disparador/responsable/acción/plazo) con aprobación explícita

Escribe reglas deterministas y obtén una aprobación por escrito. Evita verbos vagos como «revisar» o «monitorizar». Añade criterios de aceptación que eviten la deriva:

• Definición del disparador con umbral, duración y contexto.
• Responsabilidad cerrada: una única persona responsable con nombre y apellidos.
• Acción predefinida: qué ocurre cada vez, sin excepciones.
• Límite de tiempo: fecha límite acorde con el riesgo.
• Contratos de actualización y productos certificados como condiciones no negociables (por ejemplo, los datos deben proceder de Microsoft Fabric OneLake y estar certificados antes de poder activar disparadores).

Semana 3: implementa el registro y el flujo de trabajo (Dataverse + Power Automate)

Construye la capa de «memoria»: una tabla sencilla en Dataverse que registre los eventos de disparo, el responsable, las marcas de tiempo, las acciones y las excepciones. Usa Power Automate para enrutar tareas, hacer cumplir los plazos y registrar los resultados. Aquí es donde la gobernanza de Power BI pasa de ser teórica a ser operativa.

Semana 4: rediseña Power BI para mostrar obligaciones, no decoración

Actualiza una página de Power BI para mostrar el estado: qué se disparó, quién es el responsable, qué está vencido y qué se ha hecho, junto a la línea de tendencia.

Una retrospectiva y dos entregables

• Mide los minutos de reunión ahorrados y las excepciones registradas (no supongas el ROI).
• Entrega un registro de cambios de definiciones para que nadie se lleve sorpresas el próximo trimestre.

Conclusión: de «el dashboard como decoración» a «las métricas como obligaciones»

Cuando los líderes te pidan «mostrar todos los KPI en una sola página» o «simplificarlo», trátalo como una petición de confianza, no de diseño. Te están diciendo que la configuración actual no impulsa la acción de forma fiable. En otras palabras, quieren un plano de control de KPI: un único lugar donde los números conduzcan a decisiones claras y coherentes, y no a más debate. Ese es el cambio del teatro de dashboards a la toma de decisiones basada en datos que resiste la presión.

La solución no es otro gráfico. Son las reglas del juego que convierten las métricas en compromisos. Tus cinco condiciones no negociables son sencillas: un disparador preciso, un único responsable, una acción predefinida, un límite de tiempo acorde con el riesgo y un ciclo de retroalimentación duradero. Los sistemas de KPI deterministas mejoran la alineación operativa porque las acciones son explícitas y auditables, y reducir la ambigüedad en las métricas disminuye la carga de reuniones y acelera la ejecución. Esa es la promesa práctica de un motor de decisiones determinista.

Para que esas reglas sean reales, construyes la Decision Stack. Tu capa de datos converge en fuentes de confianza para que los equipos dejen de discutir qué conjunto de datos es el «correcto». Tu capa de lógica fija las definiciones para que «ingresos» signifique lo mismo en todas partes. Tu capa de estado recuerda qué se disparó, quién era el responsable, qué ocurrió y qué cambió, para que no dependas de la memoria ni de las presentaciones. Tu capa de acción hace cumplir los playbooks con marcas de tiempo y escalado. Y tu interfaz se convierte en una ventana al estado de las decisiones y a las obligaciones vencidas, no solo en gráficos.

La ejecución es un sistema, no un discurso. Construye el sistema y el discurso se encarga solo. — James Clear

Lo que haces a continuación: elige hoy un KPI y escribe su trigger, owner, action y time en lenguaje sencillo. Después haz que el sistema registre cada resultado. Cuando conviertes los KPI de medidas decorativas en obligaciones operativas, reduces las reuniones, eliminas ambigüedades y alineas la ejecución con la intención. Y cuando el sistema es determinista, las reuniones se vuelven más tranquilas, y eso es un cumplido.

unifica los datos con la arquitectura medallion en un área de trabajo de Fabric

¿Qué es la arquitectura KPI de Microsoft Fabric y cómo se relaciona con la arquitectura medallion?

La arquitectura KPI de Microsoft Fabric describe un patrón de arquitectura de datos dentro de Microsoft Fabric que se centra en el seguimiento de indicadores clave de rendimiento (KPI) mediante la unificación de datos en un área de trabajo de Fabric. Con el enfoque de arquitectura medallion, los datos sin procesar se ingieren en un data lake, se transforman a través de las capas bronze, silver y gold, y se publican como datos fiables de Fabric para informes de BI y cargas de trabajo de la plataforma analítica. Esta estructura respalda las buenas prácticas de ingeniería de datos, la calidad de los datos y un cálculo coherente de los KPI en todo el entorno de Fabric.

¿Cómo funciona la ingesta de datos en Microsoft Fabric para los informes de KPI?

La ingesta de datos en Microsoft Fabric consiste en trasladar los datos desde los orígenes de datos a Azure Data Lake Storage o al almacenamiento de datos de Fabric, utilizando herramientas como Data Factory, flujos de datos y canalizaciones en tiempo real. Fabric se integra con las plataformas de datos existentes y admite el movimiento de datos por lotes y en tiempo real dentro de Fabric, para que los KPI se actualicen desde los datos sin procesar hasta los artefactos transformados de Fabric. Este enfoque unificado ayuda a mantener la gobernanza de datos y permite análisis casi en tiempo real para paneles de KPI precisos.

¿Cuáles son los componentes clave de una arquitectura de Fabric para el seguimiento de KPI?

Los componentes clave incluyen la arquitectura lakehouse (data lake + almacén de datos de Fabric), las canalizaciones de ingeniería de datos, el cálculo de Fabric SQL y Spark, el área de trabajo de Fabric para la gobernanza y la integración con Microsoft 365 y Power BI para la visualización. En conjunto, estos componentes proporcionan almacenamiento de datos, transformación de datos, gobernanza de datos e informes de BI, y permiten una plataforma analítica unificada que consolida las cargas de trabajo de datos tradicionales y modernas en Fabric.

¿Puede Microsoft Fabric admitir KPI y análisis en tiempo real?

Sí. Microsoft Fabric permite el análisis en tiempo real gracias a la compatibilidad con la ingesta de streaming, las canalizaciones basadas en eventos y el procesamiento casi en tiempo real dentro de la plataforma Fabric. Fabric ofrece capacidades de integración y transformación de datos en streaming, de modo que los datos de Fabric y el análisis en tiempo real pueden alimentar paneles y sistemas de alertas, y los KPI reflejan las condiciones actuales del negocio.

¿Cómo se diseñan los procesos de transformación y calidad de datos para una arquitectura de KPI?

Diseña la transformación de datos con la arquitectura medallion: carga los datos sin procesar en la capa bronze, realiza la limpieza y la estandarización en silver, y crea conjuntos de datos curados y listos para KPI en gold. Dentro de Fabric, utiliza las herramientas y canalizaciones de ingeniería de datos para aplicar reglas de calidad de datos, linaje y control de versiones. Las funciones de gobernanza y catalogación de datos de Fabric ayudan a garantizar que los KPI se basen en transformaciones fiables y documentadas.

¿Qué papel desempeña la gobernanza de datos en una arquitectura de KPI de Microsoft Fabric?

La gobernanza de datos es fundamental: garantiza definiciones coherentes de los KPI, controles de acceso en todo el área de trabajo de Fabric y cumplimiento normativo para los datos almacenados en Azure Data Lake Storage. Las funciones de gobernanza de Fabric ayudan a gestionar los metadatos, el linaje de datos y las directivas, de modo que las partes interesadas confíen en los datos de Fabric que hay detrás de los informes de BI y de la plataforma analítica unificada.

¿Cómo afectan la capacidad y los precios de Fabric a las implementaciones de KPI?

La capacidad y los precios de Fabric determinan cómo aprovisionas el cálculo y el almacenamiento para la ingeniería de datos, las cargas de trabajo de la plataforma analítica y las consultas al almacén de datos de Fabric. Planificar la capacidad, incluido el cálculo independiente para la transformación y para los informes de BI, ayuda a controlar los costes y a garantizar los SLA de actualización de los KPI. Evaluar los precios de Fabric para el almacenamiento, el cálculo y el movimiento de datos es esencial al escalar arquitecturas de KPI y gestionar grandes volúmenes de datos.

¿Cómo integras las plataformas de datos existentes y los orígenes de datos de Azure en Microsoft Fabric?

Fabric se integra con las fuentes de datos existentes y con los servicios de datos de Azure (como Azure Data Factory, Azure Data Lake Storage y Azure SQL) para ingerir y consolidar datos en la arquitectura de lakehouse. Con conectores y canalizaciones de integración de datos, puedes unificar datos de almacenes de datos heredados, sistemas locales y servicios en la nube, de modo que los KPI se calculen a partir de una única fuente de datos de Fabric y sean accesibles en toda la plataforma de análisis unificada.

¿Cuáles son las ventajas de usar la arquitectura medallion en Microsoft Fabric para los KPI?

Entre las ventajas están la mejora de la calidad de los datos gracias a transformaciones por fases, un linaje de datos más claro para las definiciones de KPI, flujos de trabajo de ingeniería de datos más sencillos y una mejor escalabilidad para los volúmenes de datos actuales. La arquitectura medallion dentro de Fabric permite calcular los KPI de forma coherente, obtener información más rápido y mantener con más facilidad los informes de BI en todo el entorno de Fabric.

¿Cómo se ponen en funcionamiento y se supervisan las canalizaciones de KPI dentro del entorno de Fabric?

Para poner en funcionamiento las canalizaciones de KPI, usa la orquestación de canalizaciones de Fabric, las herramientas de supervisión, las alertas y el registro de los trabajos de movimiento y transformación de datos. Implementa observabilidad de datos, SLA para los ciclos de actualización y paneles que muestren el estado de las canalizaciones y las métricas de calidad de los datos. Fabric ofrece puntos de integración para automatizar los reintentos, escalar el cómputo y garantizar que el almacén de datos y la arquitectura de lakehouse de Fabric sirvan de forma fiable a los consumidores de KPI.