DirectQuery en Power BI

DirectQuery en Power BI le permite mantener los datos en el origen y consultarlos en el momento del informe en lugar de importarlos. En este artículo se explica cuándo usar DirectQuery, sus limitaciones y alternativas, como tablas híbridas, Direct Lake y conexiones dinámicas para que pueda elegir el modo correcto.

En este artículo se describe:

• Modos de conectividad de datos de Power BI y dónde encaja DirectQuery
• Cuándo usar DirectQuery frente a importación, tablas híbridas, Direct Lake o una conexión dinámica
• Limitaciones, implicaciones y consideraciones de rendimiento
• Recomendaciones para el modelado y el diseño de informes
• Diagnóstico y mejora del rendimiento

Guía de decisión rápida

En la tabla siguiente se resume el modo de conectividad de Power BI que se debe tener en cuenta en función de sus requisitos. Úselo como referencia rápida para ayudar a elegir entre importar, DirectQuery, tablas híbridas, Direct Lake o conexiones dinámicas:

Modos de conectividad de datos de Power BI

Power BI se conecta a muchos orígenes de datos:

• Servicios en línea como Salesforce y Dynamics 365
• Bases de datos como SQL Server, PostgreSQL, MySQL, Oracle, Snowflake y Amazon Redshift
• Archivos (Excel, CSV, JSON, Parquet)
• Motores de macrodatos y análisis como Spark y Databricks
• Otros orígenes, como sitios web y Microsoft Exchange

Importe datos de estos orígenes. Algunos también admiten DirectQuery. Para obtener una lista mantenida, consulte Orígenes de datos de Power BI. Las fuentes habilitadas para DirectQuery suelen ofrecer un rendimiento interactivo en consultas agregadas.

Utiliza importación de forma predeterminada. Usa el motor en memoria de alto rendimiento de Power BI y proporciona el conjunto de características más rico. Vaya más allá de la importación solo cuando las restricciones específicas (latencia, tamaño, gobernanza, seguridad o arquitectura) lo requieran.

Mejoras modernas: tablas híbridas, Direct Lake, agregaciones automáticas, modelos compuestos y actualización incremental, reduce la frecuencia con la que se necesita DirectQuery puro.

En las secciones siguientes se tratan los modos de importación, DirectQuery y conexión dinámica. El resto del artículo se centra en DirectQuery, al tiempo que reconoce enfoques alternativos.

Importación de conexiones

Al importar datos:

• Las selecciones de Obtener datos definen consultas para conjuntos de tablas; puede modificarlas (filtrar, agregar, unir) antes de cargarlas.
• Todos los datos definidos por esas consultas se cargan en la caché en memoria del modelo semántico.
• La creación de consultas visuales solo consulta los datos almacenados en caché, de manera rápida y totalmente interactiva.
• Los objetos visuales no reflejan los cambios de origen hasta que se refresca (reimportación).
• La publicación carga un modelo semántico que contiene los datos importados. Puede programar la actualización (la frecuencia depende de la licencia) y podría necesitar una puerta de enlace de datos local.
• La creación o apertura de informes en el servicio usa los datos importados.
• Los iconos del panel anclados se actualizan cuando se actualiza el modelo semántico.

Conexiones de DirectQuery

Cuando se usa DirectQuery:

• Obtener datos establece una conexión a un origen admitido. En el caso de los orígenes relacionales, todavía puede seleccionar tablas o vistas; para orígenes multidimensionales (por ejemplo, SAP BW), seleccione el modelo de origen.
• No se importan datos en tiempo de carga. Cada objeto visual desencadena una o varias consultas en el origen subyacente.
• La latencia de actualización visual depende completamente del rendimiento de origen subyacente (y de la sobrecarga de red o puerta de enlace si procede).
• Los cambios en los datos de origen solo aparecen después de las acciones que requieren una nueva consulta (navegación, segmentación o cambios de filtro, actualización manual).
• La publicación crea una definición de modelo semántico (esquema y metadatos) sin datos importados.
• Los informes del servicio consultan el origen. Es posible que se requiera una puerta de enlace para los orígenes locales.
• Los iconos de panel basados en los modelos directQuery se actualizan según una programación para almacenar en caché los resultados del icono para abrir rápidamente el panel.
• Los iconos del panel muestran los resultados de su última actualización programada a menos que se actualice manualmente.

Conexiones dinámicas

Una conexión dinámica conecta Power BI directamente a un modelo semántico existente (por ejemplo, Analysis Services u otro modelo semántico de Power BI publicado). Es similar a DirectQuery (sin datos importados), pero la semántica (como el cumplimiento de roles) se controla mediante el modelo ascendente. Cuando se conecta en directo:

• Aparece la lista de campos del modelo externo completo, sin definición de consulta de Power Query.
• Las conexiones en vivo siempre pasan la identidad del usuario a Analysis Services o al modelo semántico de Power BI para el filtrado de seguridad.
• Algunas actividades de modelado (como agregar tablas calculadas) no están disponibles porque el modelo es externo.

Dónde encaja DirectQuery entre las opciones más recientes

DirectQuery era la solución principal para datos muy grandes o de cambio rápido que no podía importar de forma eficaz. Hoy:

• Las tablas híbridas permiten mezclar particiones en memoria y DirectQuery en una tabla (reciente frente a histórica).
• Direct Lake (Fabric) permite el acceso casi en tiempo real a las tablas de Lakehouse sin sobrecarga de actualización tradicional.
• Las agregaciones automáticas y las tablas de agregaciones manuales aceleran las consultas frecuentes.
• La actualización incremental con tiempo real permite que DirectQuery acceda a la fuente en la ventana de tiempo más reciente, mientras que los datos más antiguos permanecen importados.

Evalúe estas opciones antes de adoptar un modelo de DirectQuery completo.

Casos de uso de DirectQuery

DirectQuery es más beneficioso cuando:

• Los datos cambian con demasiada frecuencia para la importación (incluso con la actualización incremental y la frecuencia máxima de actualización programada) y necesita visibilidad de baja latencia.
• Las restricciones de gobernanza o de volumen de datos hacen que la ingesta completa no sea práctica.
• La seguridad aplicada por el origen (reglas de fila específicas) debe seguir siendo autoritativa a través del pase directo.
• La soberanía de datos o las reglas normativas restringen las copias completas persistentes.
• El origen está centrado en multidimensionalidad o medidas (como SAP BW) y las medidas definidas por el servidor deben resolverse por cada visual.

Los datos cambian con frecuencia y necesita informes casi en tiempo real

Los modelos importados (Pro) pueden programar hasta 8 actualizaciones al día (además de desencadenadores de API o a petición). Premium y PPU admiten hasta 48 actualizaciones programadas al día, además de la actualización incremental y DirectQuery en tiempo real para la partición más reciente (híbrida). Si aún no se puede cumplir la latencia necesaria (o la importación completa es inviable), use DirectQuery, tablas híbridas o Direct Lake. Los paneles de DirectQuery pueden actualizar iconos con tanta frecuencia como cada 15 minutos.

Los datos son grandes

La importación completa podría exceder la capacidad de la memoria o el tiempo de actualización de las ventanas. DirectQuery consulta los datos en su lugar. Si el origen es demasiado lento para el rendimiento interactivo, tenga en cuenta lo siguiente:

• Importar solo subconjuntos agregados o filtrados.
• Uso de la actualización incremental y las agregaciones.
• Uso de tablas híbridas o Direct Lake para segmentos recientes y de alto valor.

Consulte Modelos semánticos grandes en Power BI Premium para administrar datos en memoria considerables.

Seguridad aplicada por el origen

La importación se basa en las credenciales de Power BI más la seguridad de nivel de fila opcional (RLS) definida en el modelo semántico. DirectQuery puede (cuando se admite) pasar la identidad de usuario (SSO) para que el origen aplique sus propias reglas de seguridad. Consulte Introducción al inicio de sesión único (SSO) para puertas de enlace de datos locales en Power BI.

Restricciones de soberanía de datos

Cuando las regulaciones requieren que los datos permanezcan dentro de un límite controlado, DirectQuery limita la existencia de copias persistentes. Las cachés visuales y de iconos todavía pueden contener datos agregados limitados.

Origen con medidas definidas por el servidor

Algunos sistemas (como SAP BW) contienen lógica semántica (medidas y jerarquías) que se resuelven en el momento de la consulta. DirectQuery habilita la resolución por objeto visual. Consulte DirectQuery y SAP BW y DirectQuery y SAP HANA.

Consideraciones específicas del origen (incluidas PostgreSQL y MySQL)

El comportamiento y el rendimiento difieren según el motor:

• PostgreSQL: Los identificadores entre comillas distinguen entre mayúsculas y minúsculas. Asegúrese de que haya índices B-tree adecuados para las columnas de combinación y filtro. Evite las funciones que interrumpen el plegado de consultas de manera prematura. Compruebe si hay conversiones implícitas en uniones numéricas y textuales.
• MySQL: Usar ordenaciones coherentes y modos SQL. Cree índices compuestos para patrones comunes de filtro y combinación. Las columnas grandes TEXT pueden reducir el plegado o forzar el postprocesamiento.
• Snowflake, BigQuery y Databricks: El escalado elástico mejora la simultaneidad, pero la latencia de inicio en frío puede afectar a la primera consulta. Envíe pings de preparación o programe una actividad periódica.
• Azure Synapse, SQL y Fabric Warehouse: Los índices de almacén columnar y el almacenamiento en caché del conjunto de resultados proporcionan una gran aceleración. Emparejarlos con agregaciones automáticas.
• Azure Data Explorer: La eliminación de proyección es importante. Seleccione solo las columnas necesarias y aplique los filtros lo antes posible.
• SAP BW y SAP HANA: La resolución y la semántica de jerarquía determinan los patrones de consulta. Evite las transformaciones de supercapa que bloquean el plegado.

Confirme el plegamiento de consultas (seleccione Ver consulta nativa en el Editor de Power Query) para que las transformaciones se apliquen.

Limitaciones de DirectQuery

El uso de DirectQuery tiene implicaciones en la coherencia, el rendimiento, la seguridad, las transformaciones, el modelado y los informes.

Implicaciones generales

Las siguientes implicaciones generales se aplican al usar DirectQuery en Power BI:

• Actualice para ver los datos más recientes. Las memorias caché (objeto visual, icono, resultado) significan que un objeto visual puede mostrar los resultados anteriores hasta que se actualice. Seleccione Actualizar para forzar una nueva consulta de todos los objetos visuales de una página.
• Los objetos visuales no siempre son coherentes con el tiempo. Los distintos objetos visuales (o consultas internas de un objeto visual) se pueden ejecutar en momentos ligeramente diferentes. Actualice la página o diseñe instantáneas agregadas si se requiere una precisión estricta a un momento dado.
• Los cambios de esquema requieren una actualización de Power BI Desktop. El servicio no detecta automáticamente las columnas quitadas ni cambiadas de nombre. Abra el modelo en Power BI Desktop y actualice para conciliar los metadatos del modelo.
• Límite de resultados intermedios de un millón de filas. Se produce un error en cualquier consulta (o operación intermedia) que devuelva más de 1000 000 filas. Las capacidades Premium pueden aumentar este límite; consulte Número máximo de conjuntos de filas intermedios.
• El cambio del modo de almacenamiento está restringido. No se puede cambiar globalmente un modelo de solo importación a DirectQuery. Consulte la sección siguiente.

Cambio de los modos de almacenamiento (Importar ↔ DirectQuery)

No se puede cambiar el modelo de importación completo a DirectQuery. En lugar de:

• Agregue una nueva conexión de DirectQuery al mismo origen y asigne objetos visuales a nuevas tablas.
• Cree un modelo compuesto: mantenga las dimensiones de importación, agregue tablas de hechos de DirectQuery (o viceversa) y, opcionalmente, establezca algunas tablas en 'Dual'.
• Use tablas híbridas (particiones de DirectQuery recientes e importación histórica) para la optimización activa y fría.
• Recompile con transformaciones que admiten plegamiento si los pasos anteriores impiden DirectQuery.

Implicaciones de rendimiento y carga

El rendimiento interactivo depende de la latencia de origen y la simultaneidad. Objetivo de tiempos comunes de actualización visual en menos de 5 segundos; más de 30 segundos degrada la facilidad de uso. Cada acción de usuario desencadena consultas. Los recuentos elevados de usuarios, elementos visuales y actualizaciones de iconos pueden crear una carga significativa: planificar la capacidad en consecuencia.

Implicaciones de seguridad

A menos que se configure el inicio de sesión único, DirectQuery usa credenciales almacenadas configuradas para todos los visores. Defina RLS en el modelo semántico según sea necesario. Varios orígenes de modelos compuestos pueden mover datos entre orígenes; evaluar el movimiento de datos confidenciales: consulte Implicaciones de seguridad.

Limitaciones de transformación de datos

El plegado de Power Query es necesario para un rendimiento escalable. Las transformaciones deben condensarse en una sola consulta nativa. Los pasos complejos (operaciones no plegables, ciertas funciones personalizadas, lógica procedural de múltiples pasos) pueden provocar errores que requieren simplificación o cambio a import. Los orígenes OLAP, como SAP BW, no permiten transformaciones en la consulta porque se expone todo el modelo externo. Las llamadas a procedimientos almacenados y las expresiones de tabla comunes (CTE) no se admiten de una manera que permita el plegado en DirectQuery.

Limitaciones del modelado

La mayoría del enriquecimiento funciona, pero algunas funcionalidades se reducen:

• Ninguna jerarquía de fechas automática (cree una tabla de fechas explícita).
• Precisión de tiempo limitada a segundos (quite milisegundos en el origen).
• Columnas calculadas limitadas a expresiones de nivel de fila que se pueden plegar; funciones no admitidas omitidas de la función de autocompletar.
• No hay funciones PATH de relación padre-hijo.
• No se admite la agrupación en clústeres.

Limitaciones de informes

La mayoría de los objetos visuales funcionan si la fuente es receptiva. Observe estas limitaciones y consideraciones de rendimiento:

• No se admiten columnas de texto largas de más de 32 764 caracteres.
• Los filtros de medida, los filtros topN, los filtros avanzados que contienen o comienzan con texto, las segmentaciones de selección múltiple y los totales o subtotales (especialmente con Median) pueden agregar consultas adicionales o degradar el rendimiento.
• Considere la posibilidad de simplificar el diseño o deshabilitar determinadas interacciones.

Ejemplo (filtro de medida):

Recomendaciones de DirectQuery

En esta sección se proporcionan recomendaciones prácticas para diseñar, optimizar y solucionar problemas de modelos directQuery en Power BI. Siga estas instrucciones para mejorar el rendimiento, la confiabilidad y la experiencia del usuario al trabajar con conexiones directQuery.

Rendimiento del origen de datos subyacente

Valide las consultas interactivas de línea base. Si son lentos, inspeccione las consultas mediante el Analizador de rendimiento y optimice el esquema de origen (índices, estadísticas y almacén de columnas, si procede). Favorece las claves de entero para las combinaciones.

Diseño de modelos

• Mantenga los pasos de Power Query sencillos y plegables. Previsualiza "Ver consulta nativa" con frecuencia.
• Comience con medidas simples y, a continuación, iteración.
• Evite combinaciones en columnas de expresión calculadas: materialice en el origen si es necesario.
• Evitar combinaciones en uniqueidentifier donde las conversiones interrumpen el uso del índice; materialice tipos de clave alternativos.
• Ocultar claves suplentes o del sistema; cree columnas con alias visibles si es necesario.
• Revise las tablas o columnas calculadas que pueden generar expresiones no plegables.
• Limite los filtros bidireccionales solo a los casos necesarios. Pruebe el impacto en el rendimiento.
• Considere la posibilidad de asumir la integridad referencial para habilitar el INNER JOIN uso.
• Evite los filtros de fecha relativa en Power Query. Implemente lógica relativa en el modelo o la capa de informe en su lugar.

Ejemplo de filtrado:

La consulta nativa resultante usa una fecha literal fija:

Diseño del informe

Al diseñar informes que usan DirectQuery, tenga en cuenta los siguientes procedimientos recomendados para optimizar la facilidad de uso y el rendimiento:

• Utilice las opciones de reducción de consultas (utilice el botón Aplicar para segmentaciones y filtros y deshabilite el resaltado cruzado donde la latencia afecta negativamente la experiencia de usuario).

  

• Aplique filtros de clave al principio para reducir los recuentos de filas intermedios y evitar alcanzar los límites.

• Limite los objetos visuales por página para minimizar las consultas en paralelo y serializadas.

• Deshabilite las interacciones innecesarias (filtrado cruzado o resaltado) si desencadenan consultas de origen costosas.

  

Número máximo de conexiones

Ajuste la simultaneidad de DirectQuery por archivo (valor predeterminado 10) en Opciones de archivo > y opciones de > configuración > DirectQuery para el archivo actual.

Los valores más altos pueden mejorar el rendimiento de muchos visuales, pero también pueden aumentar la carga sobre la fuente. El comportamiento publicado también depende de los límites de servicio o capacidad.

Características de mitigación de rendimiento

Use estas características para mejorar el rendimiento de DirectQuery:

• Agregaciones automáticas y tablas de agregaciones manuales: Almacenar en caché los datos resumidos para reducir las consultas de origen.
• Tablas híbridas: Mantenga los datos recientes a través de DirectQuery, histórico a través de Import.
• Diseño de medidas compatibles con agregaciones: Asegúrese de que DAX se evalúa en la capa de agregación siempre que sea posible.
• Parámetros M dinámicos: Inserte las selecciones del usuario en los predicados de origen desde el principio.
• Almacenamiento en caché de consultas y resultados (configuración de capacidad): Reutilización de conjuntos de resultados recientes para objetos visuales repetidos.
• Modo de almacenamiento dual para tablas de dimensiones compartidas: Reduzca los exámenes de dimensiones remotas repetidos.

DirectQuery en el servicio Power BI

Todos los orígenes de datos de DirectQuery se admiten a través de Power BI Desktop. Solo se inicia un subconjunto limitado directamente desde la interfaz de usuario del servicio. Comience en Power BI Desktop para obtener un control de modelado y transformación más completo. Para obtener la lista actual de orígenes disponibles directamente en el servicio, consulte Orígenes de datos de Power BI.

El rendimiento del servicio depende de:

• Número de usuarios simultáneos
• Complejidad visual y recuento por página
• Presencia de seguridad de nivel de fila (puede reducir la reutilización de la memoria caché)
• Programaciones de actualización de iconos

Comportamiento de los informes en el servicio Power BI

Al abrir una página de informe se ejecutan consultas para cada objeto visual (a veces varias por objeto visual). Las interacciones (como cambios en los segmentadores, resaltado cruzado o filtros) vuelven a ejecutar las consultas. El servicio almacena en caché algunos resultados. Las consultas exactas repetidas pueden devolverse al instante, a menos que los límites de seguridad difieran.

Matices de funcionalidad:

• Conclusiones rápidas: No se admite para los modelos semánticos de DirectQuery.
• Explorar en Excel /Analizar en Excel: Compatible, pero puede sentirse más lento. Considere el modo de importación o las agregaciones para el uso intensivo de Excel.
• Jerarquías en Excel: Algunas jerarquías de modelos semánticos de DirectQuery no aparecen iguales en Excel.

Actualización del panel

Los iconos de DirectQuery se actualizan según una programación. El valor predeterminado es cada hora y puede establecerlo de cada 15 minutos hasta semanalmente. La seguridad a nivel de fila permite que cada usuario ejecute consultas de los componentes de interfaz de manera independiente. Un conteo elevado de mosaicos multiplicado por el conteo de usuarios y la frecuencia de renovación puede crear una carga pesada: planificar la capacidad y considerar agregaciones.

Tiempos de espera de las consultas

El servicio aplica un tiempo de espera de 4 minutos por consulta. Los objetos visuales que superan el límite generan un error de tiempo de espera. Asegúrese de que los orígenes subyacentes proporcionan un rendimiento interactivo antes de elegir DirectQuery.

Diagnóstico de rendimiento

Diagnostique el rendimiento en primer lugar en Power BI Desktop.

Use el analizador de rendimiento para aislar objetos visuales lentos. Céntrese en un objeto visual problemático a la vez.

Uso de SQL Server Profiler para ver consultas

Power BI Desktop escribe seguimientos de sesión, incluido DirectQuery SQL para algunos orígenes, en el archivo FlightRecorderCurrent.trc de la carpeta AnalysisServicesWorkspaces del usuario.

Para localizar la traza:

1. En Power BI Desktop, seleccione Opciones de archivo > y opciones de > configuración > Diagnósticos.

2. Seleccione Abrir carpeta de volcado de memoria/seguimientos.

   

3. Vaya un nivel a AnalysisServicesWorkspaces, abra la carpeta del área de trabajo activa y, a continuación, Datos y busque FlightRecorderCurrent.trc.

4. En SQL Server Profiler, abra el archivo: Archivo > Abrir > Archivo de seguimiento.

Profiler muestra eventos agrupados:

Columnas de eventos:

• TextData: DAX (para inicio y finalización de la consulta) o SQL nativo (para DirectQuery Begin/End).
• La duración (ms) y EndTime ayudan a identificar las fases lentas.
• ActivityID agrupa eventos relacionados.

Guía de captura:

• Mantenga las sesiones cortas (≈10 segundos de acciones dirigidas).
• Vuelva a abrir el archivo de seguimiento para ver los eventos recién vaciados.
• Evite varias instancias de Escritorio simultáneas para reducir la confusión.

Descripción del formato de las consultas

Power BI suele usar una subselección (tabla derivada) para cada tabla lógica a la que se hace referencia definida por los pasos de Power Query.

Lógica de consulta de ejemplo:

SalesAmount (SUMX(Web_Sales, [ws_sales_price]*[ws_quantity]))
by Item[i_category]
for Date_dim[d_year] = 2000

Visual resultante:

SQL generado con subselecciones:

Los patrones de consulta de subselección normalmente no afectan al rendimiento en los motores admitidos, ya que los optimizadores eliminan las columnas sin usar. Priorizar la plegabilidad.

Contenido relacionado

• Usar DirectQuery en Power BI Desktop
• DirectQuery y SAP HANA
• DirectQuery y SAP BW
• Uso de DirectQuery para modelos semánticos de Power BI y Analysis Services
• Agregaciones en Power BI
• Analizador de rendimiento
• Modelos compuestos
• Introducción a la seguridad de nivel de fila
• Inicio de sesión único (SSO)