Guía

Diseñar la capa inicial de ingesta de datos en una arquitectura de medallón para capturar datos brutos de origen.

→Ingerir datos en la capa Bronze con una transformación mínima y un esquema permisivo.

Por qué: Preserva la fidelidad de los datos originales, incluidos los registros mal formados, para reprocesamiento, auditoría y linaje de datos.

Implementar entornos aislados y un proceso de promoción para los artefactos de Fabric.

→Utilizar Fabric Deployment Pipelines con etapas de espacio de trabajo distintas para Desarrollo, Pruebas y Producción.

Por qué: Proporciona un mecanismo estructurado y seguro para probar cambios y promover artefactos sin afectar las cargas de trabajo de producción.

Aplicar control de código fuente y flujos de trabajo de aprobación para los cambios en los elementos de Fabric de producción.

→Integrar el espacio de trabajo de Fabric con Azure DevOps Git. Utilizar políticas de rama para aplicar revisiones de pull request.

Por qué: Permite el control de versiones, el seguimiento de cambios y las revisiones obligatorias por pares, alineando la ingeniería de datos con las mejores prácticas de DevOps.

Automatizar los cambios de cadenas de conexión específicas del entorno durante las implementaciones de pipeline.

→Configurar reglas de despliegue en el pipeline de despliegue para parametrizar las conexiones de origen de datos para cada etapa.

Por qué: Elimina la configuración manual posterior al despliegue, reduciendo errores y asegurando que cada entorno se conecte al origen de datos correcto.

Organizar espacios de trabajo para múltiples unidades de negocio que requieren tanto aislamiento como gobernanza compartida.

→Crear espacios de trabajo separados por unidad de negocio y agruparlos bajo Fabric Domains.

Por qué: Los espacios de trabajo proporcionan aislamiento de contenido y seguridad, mientras que los Domains permiten una gobernanza y descubrimiento centralizados en espacios de trabajo relacionados.

Mejorar el descubrimiento de datos y señalar la calidad de los conjuntos de datos a los usuarios de negocio.

→Aplicar descripciones y etiquetas a las tablas de lakehouse y utilizar etiquetas de Endorsement (Promoted, Certified).

Por qué: Los niveles de Endorsement generan confianza en el usuario y los guían hacia conjuntos de datos de alta calidad y curados para informes y análisis.

Asegurar una clasificación y protección de datos consistente en todos los elementos de Fabric.

→Integrar con Microsoft Purview Information Protection y habilitar la herencia descendente para las etiquetas de sensibilidad.

Por qué: Automatiza la aplicación de etiquetas de sensibilidad desde los orígenes de datos a los artefactos descendentes, como modelos semánticos e informes, aplicando políticas de seguridad.

Determinar el factor principal para dimensionar una capacidad de Fabric.

→Analizar la ejecución de consultas concurrentes y los requisitos de cómputo de la carga de trabajo.

Por qué: La capacidad de Fabric es consumida por operaciones de cómputo (Capacity Units), no por el volumen de almacenamiento de datos. La concurrencia y la complejidad del trabajo son los factores clave.

Proporcionar acceso seguro y de grado de producción desde un acceso directo de Fabric a una cuenta externa de ADLS Gen2.

→Utilizar un Service Principal con autenticación de Azure AD, otorgándole roles RBAC de mínimo privilegio en la cuenta de almacenamiento.

Por qué: Service Principal es el método más seguro y auditable, evitando los riesgos de claves de cuenta compartidas o tokens SAS.

Crear una réplica de solo lectura y casi en tiempo real de una Base de datos Azure SQL en Fabric sin afectar el origen.

→Utilizar Fabric Mirroring para Azure SQL Database.

Por qué: Mirroring proporciona replicación continua y de baja latencia de datos en OneLake como tablas Delta, ideal para análisis en tiempo real sin desarrollo ETL.

Compartir un conjunto de datos con otro espacio de trabajo o acceder a datos externos sin crear una copia.

→Crear un Shortcut que apunte a la tabla de lakehouse de origen o a la ubicación de datos externa.

Por qué: Los Shortcuts actúan como enlaces simbólicos, proporcionando una vista unificada de los datos en OneLake mientras evitan la duplicación de datos, los costos de almacenamiento y los problemas de sincronización.

Combinar datos de streaming de alta velocidad con datos históricos por lotes para un análisis unificado.

→Utilizar Eventstream para la ingesta en tiempo real y un Lakehouse con tablas Delta Lake para almacenamiento unificado.

Por qué: Eventstream maneja la ruta de streaming, mientras que las propiedades ACID de Delta Lake le permiten servir como objetivo tanto para anexos de streaming como para actualizaciones por lotes.

Habilitar tanto el análisis basado en T-SQL como la ciencia de datos basada en Python sobre los mismos datos de lakehouse.

→Aprovechar el punto final de análisis SQL generado automáticamente para el Lakehouse.

Por qué: Fabric proporciona acceso de doble motor a las mismas tablas Delta: un punto final SQL para consultas T-SQL y el motor Spark para notebooks, sin duplicación de datos.

Ingerir datos de una fuente de datos local (por ejemplo, Oracle, SQL Server) en Fabric.

→Instalar y configurar una puerta de enlace de datos local.

Por qué: La puerta de enlace actúa como un puente seguro, retransmitiendo datos entre la red local y el servicio en la nube de Fabric sin exponer la fuente a Internet.

Procesar automáticamente nuevos archivos tan pronto como lleguen a Azure Blob Storage.

→Utilizar un disparador de Evento de Almacenamiento para el pipeline de datos, configurado para activarse en eventos de creación de blobs.

Por qué: Los disparadores basados en eventos proporcionan menor latencia y son más eficientes que el sondeo programado, que puede perder datos o ejecutarse innecesariamente.

Extraer todos los registros de una API REST que devuelve datos en páginas.

→En una actividad de Copy, configurar las reglas de paginación integradas del conector REST. Alternativamente, usar un bucle Until o ForEach con variables para gestionar los tokens de página.

Por qué: Automatiza el proceso de iterar a través de todas las páginas de la API hasta que se recuperan todos los datos, manejando enlaces o desplazamientos dinámicos a la siguiente página.

Implementar la lógica de Dimensión de Cambio Lento Tipo 2 o procesar flujos de Change Data Capture (CDC).

→Utilizar la operación MERGE de Delta Lake con las cláusulas `WHEN MATCHED` y `WHEN NOT MATCHED`.

Por qué: MERGE proporciona capacidades atómicas de upsert (actualización/inserción/eliminación), que es la operación fundamental para mantener registros históricos en patrones SCD2.

Transformar una columna de DataFrame que contiene arrays anidados de objetos en filas separadas.

→Aplicar la función `explode()` a la columna de array en un notebook de PySpark.

Por qué: `explode()` es la función estándar de Spark para desanidar arrays, creando una nueva fila para cada elemento en el array.

Manejar datos de llegada tardía en una agregación de streaming con estado (por ejemplo, recuentos en ventanas).

→Configurar una watermark en la columna de tiempo de evento en la consulta de Spark Structured Streaming.

Por qué: El watermarking define un umbral de tiempo para cuánto tiempo el motor esperará los datos tardíos, evitando que el estado crezca indefinidamente mientras asegura la corrección.

Realizar una carga de datos incremental desde un sistema de origen que tiene una columna de marca de tiempo pero no CDC.

→Implementar un patrón de high-watermark. Almacenar la marca de tiempo máxima de la última ejecución y usarla para filtrar el origen en la siguiente ejecución.

Por qué: Este es un patrón eficiente y común para extraer solo registros nuevos o actualizados sin la sobrecarga de escaneos completos de tabla o el requisito de CDC formal.

Una actividad de pipeline falla intermitentemente debido a problemas transitorios de red o carga del sistema de origen.

→Configurar la política de reintento de la actividad con un recuento especificado y un intervalo de retroceso exponencial.

Por qué: Construye resiliencia en el pipeline reintentando automáticamente las operaciones fallidas, a menudo resolviendo problemas transitorios sin intervención manual.

Ingerir y consultar telemetría o datos de registro de alto volumen y baja latencia para análisis exploratorio en tiempo real.

→Ingerir datos en un Eventhouse y consultarlos utilizando Kusto Query Language (KQL).

Por qué: Eventhouse (construido sobre Azure Data Explorer) y KQL están diseñados específicamente para análisis de series temporales y registros de alto rendimiento.

Crear un pipeline único y reutilizable para cargar docenas de tablas que comparten la misma lógica de transformación.

→Utilizar un enfoque basado en metadatos. Almacenar la información de origen/destino en una tabla de control y usar una actividad ForEach para iterar y pasar parámetros a un pipeline hijo genérico.

Por qué: Este patrón es altamente escalable y mantenible, evitando la duplicación y la sobrecarga de gestión de crear pipelines separados para cada tabla.

Optimizar el rendimiento de un Dataflow Gen2 que obtiene datos de una base de datos relacional como SQL Server.

→Diseñar transformaciones que puedan ser plegadas. Verificar el estado de query folding en el editor de Power Query.

Por qué: El query folding empuja la lógica de transformación al motor de la base de datos de origen, lo que es significativamente más eficiente que extraer todos los datos al motor Spark para la transformación.

Consultar una tabla tal como existía en un punto específico en el pasado para una auditoría o para recuperarse de una actualización accidental.

→Utilizar la función de viaje en el tiempo de Delta Lake con `VERSION AS OF` o `TIMESTAMP AS OF` en la consulta.

Por qué: Delta Lake versiona de forma nativa cada transacción, lo que permite consultas a un punto en el tiempo sin necesidad de instantáneas o copias de seguridad manuales.

Aplicar seguridad a nivel de fila (RLS) donde los usuarios solo deben ver los datos correspondientes a su región o departamento.

→Implementar reglas RLS usando expresiones DAX dentro del modelo semántico.

Por qué: El modelo semántico es la capa centralizada y recomendada para aplicar reglas de negocio como RLS. La lógica se aplica dinámicamente basándose en la identidad del usuario.

Evitar que un grupo de usuarios vea columnas sensibles (por ejemplo, salario, PII) en una tabla.

→Implementar Column-Level Security (CLS) en el modelo semántico o en el almacén de datos.

Por qué: CLS proporciona un control granular para restringir el acceso a columnas específicas para roles de usuario designados, protegiendo datos sensibles dentro de una tabla compartida.

Construir un informe de Power BI sobre un conjunto de datos de lakehouse muy grande con requisitos de alto rendimiento.

→Crear un modelo semántico usando el modo DirectLake.

Por qué: DirectLake ofrece el rendimiento del modo Import al cargar datos en memoria, pero sin duplicar los datos, leyendo directamente de los archivos Delta en OneLake.

Mejorar el rendimiento de las consultas y reducir el consumo de capacidad para informes con resúmenes de alto nivel.

→Crear y configurar tablas de agregación dentro del modelo semántico.

Por qué: Las consultas que acceden a datos preagregados son significativamente más rápidas y consumen menos recursos que las que escanean la tabla de detalles completa, optimizando la experiencia del usuario y el costo.

Reducir el tiempo de actualización y el uso de recursos para un modelo semántico grande donde solo cambian los datos recientes.

→Configurar una política de actualización incremental en las tablas de hechos grandes del modelo semántico.

Por qué: Esto particiona los datos y solo actualiza las particiones más recientes, evitando recargas completas costosas de datos históricos que no cambian.

El rendimiento de las consultas en una tabla Delta se ha degradado debido a un gran número de archivos pequeños de la ingesta de streaming.

→Ejecutar el comando `OPTIMIZE` en la tabla Delta.

Por qué: `OPTIMIZE` compacta archivos pequeños en menos archivos y más grandes. Esto mejora significativamente el rendimiento de lectura, ya que el motor de consulta tiene que abrir menos archivos.

Mejorar el rendimiento de las consultas en una tabla Delta grande que se filtra frecuentemente por una columna no particionada y de alta cardinalidad.

→Ejecutar `OPTIMIZE` con una cláusula `ZORDER BY` en las columnas filtradas frecuentemente.

Por qué: Z-Ordering co-localiza datos relacionados dentro de los archivos, permitiendo que el motor de consulta use el salto de datos para leer menos datos, acelerando drásticamente las consultas filtradas.

Optimizar el rendimiento de lectura para informes de Power BI que consultan tablas Delta en un lakehouse de Fabric.

→Asegurar que la optimización V-Order esté habilitada en las tablas Delta.

Por qué: V-Order es una optimización en tiempo de escritura específica de Fabric que mejora el rendimiento de lectura para el motor de Power BI al mejorar la compresión y el orden de los datos.

Recuperar espacio de almacenamiento de una tabla Delta que ha acumulado un historial significativo de actualizaciones y eliminaciones.

→Ejecutar el comando `VACUUM` en la tabla.

Por qué: `VACUUM` elimina físicamente los archivos de datos que ya no son referenciados por la tabla y que son más antiguos que el período de retención, reduciendo los costos de almacenamiento.

Optimizar una operación Spark join entre una tabla de hechos muy grande y una tabla de dimensiones pequeña.

→Utilizar una broadcast join proporcionando una pista (`broadcast()`) para enviar la tabla pequeña a todos los ejecutores.

Por qué: La difusión evita una operación costosa y de uso intensivo de la red de la tabla grande, que es un cuello de botella importante en el rendimiento de joins a gran escala.

Una operación Spark join es lenta o falla porque un valor de clave tiene una cantidad desproporcionadamente grande de datos (data skew).

→Implementar una técnica de "salting": añadir una clave aleatoria a los valores sesgados para distribuirlos en más particiones, luego unirlos y agregarlos.

Por qué: El salting divide manualmente la partición sesgada, permitiendo que la carga de trabajo se equilibre entre todos los ejecutores y previniendo errores OOM o tareas de larga duración.

Un trabajo de notebook de Spark se está ejecutando más lento de lo esperado y la causa no está clara.

→Utilizar la Spark UI, accesible desde el centro de monitoreo, para analizar el Directed Acyclic Graph (DAG), las duraciones de las etapas y los detalles de las tareas.

Por qué: La Spark UI proporciona una vista física detallada de la ejecución de la consulta, permitiendo identificar cuellos de botella como el data skew, los derrames a disco o las reorganizaciones ineficientes.

Un trabajo de Spark falla con un OutOfMemoryError en el nodo driver, incluso con una memoria de ejecutor grande.

→Revisar el código en busca de acciones como `.collect()` o `.toPandas()` que extraen grandes cantidades de datos distribuidos a la memoria del nodo driver.

Por qué: El driver tiene su propio límite de memoria. Recopilar un DataFrame grande en el driver es un antipatrón común que causa errores OOM; utilizar operaciones distribuidas en su lugar.

Identificar qué espacios de trabajo, informes o pipelines están consumiendo la mayor cantidad de recursos de cómputo en una capacidad de Fabric.

→Instalar y analizar la aplicación Fabric Capacity Metrics.

Por qué: Esta aplicación proporciona un desglose detallado del consumo de Capacity Unit (CU) a lo largo del tiempo por espacio de trabajo, tipo de elemento y operación específica, lo que permite la optimización y el análisis de costos dirigidos.

Implementar auditoría y monitoreo centralizados y a largo plazo de todas las actividades dentro de un espacio de trabajo de Fabric.

→En la configuración de administración de Fabric, configurar los ajustes de diagnóstico para que el espacio de trabajo transmita registros a un espacio de trabajo de Azure Log Analytics.

Por qué: Proporciona un almacén robusto, consultable y a largo plazo para todos los registros de auditoría y operativos, lo que permite monitoreo avanzado, alertas e informes de cumplimiento.

Reducir el costo operativo de una capacidad de Fabric que tiene períodos predecibles de inactividad (por ejemplo, noches, fines de semana).

→Implementar automatización (por ejemplo, a través de APIs y Azure Automation) para pausar la capacidad durante las horas no laborables y reanudarla antes de las horas de negocio.

Por qué: El cómputo de capacidad es un impulsor de costo principal. Pausar la capacidad detiene la facturación de CU, proporcionando ahorros de costos significativos durante los períodos de inactividad.

Un pipeline de datos crítico debe ser monitoreado, y el equipo de operaciones debe ser notificado inmediatamente en caso de fallo.

→Configurar alertas en el Fabric Monitoring Hub o usar Data Activator para monitorear el estado del pipeline y activar notificaciones.

Por qué: La alerta proactiva asegura que los fallos sean detectados y abordados rápidamente, minimizando el tiempo de inactividad de los datos y el impacto en los usuarios de negocio.