Modo DirectQuery en modelos tabulares

Se aplica a: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

En este artículo se describe el modo DirectQuery para los modelos tabulares de Analysis Services en los niveles de compatibilidad 1200 y superiores. El modo DirectQuery se puede habilitar para los modelos que está diseñando en Visual Studio o para los modelos tabulares que ya se han implementado, puede cambiar al modo DirectQuery mediante SQL Server Management Studio (SSMS). Antes de elegir el modo DirectQuery, es importante comprender tanto las ventajas como las limitaciones.

Ventajas

De forma predeterminada, los modelos tabulares utilizan una caché en memoria para almacenar los datos y realizar consultas en ellos. Cuando los datos de consultas de modelos tabulares residen en memoria, incluso las consultas complejas se pueden ejecutar con mucha rapidez. Sin embargo, hay algunas limitaciones en el uso de datos almacenados en caché; por ejemplo, los conjuntos de datos muy grandes pueden superar la memoria disponible y el procesamiento (actualización) de los datos del modelo en memoria puede requerir cantidades excesivas de recursos disponibles si se necesita con frecuencia.

DirectQuery supera estas limitaciones a la vez que también aprovecha las características de RDBMS, que mejoran la eficacia de la ejecución de las consultas. Con DirectQuery:

• Los datos están actualizados. Dado que los datos siempre se consultan en el origen de datos, las aplicaciones de informes de cliente siempre obtienen los datos más recientes.

• No hay ninguna sobrecarga de administración adicional de tener que mantener una copia independiente de los datos (en la memoria caché en memoria). No se requiere procesamiento (actualización) de los datos del modelo. Los cambios en el origen de datos subyacente se pueden reflejar inmediatamente en las consultas realizadas en el modelo de datos.

• Los conjuntos de datos pueden ser mayores que la capacidad de memoria de un recurso de servidor de Analysis Services.

• DirectQuery puede aprovechar la aceleración de consultas del lado proveedor, como la proporcionada por índices de columna optimizados para memoria.

• La base de datos de origen de back-end puede aplicar la seguridad mediante características de seguridad de nivel de fila de la base de datos (como alternativa, puede usar reglas de seguridad de nivel de fila definidas en el modelo mediante DAX).

• Si el modelo contiene fórmulas complejas que requieren varias consultas, Analysis Services puede realizar la optimización para asegurarse de que el plan de consulta para la consulta ejecutada en la base de datos back-end sea tan eficaz como sea posible.

Limitaciones

Los modelos tabulares en el modo DirectQuery tienen algunas limitaciones. Antes de cambiar de modo, es importante determinar si las ventajas de la ejecución de consultas en el servidor back-end podrían producir una reducción de funciones. Si cambia el modo de un modelo existente en Visual Studio, el diseñador de modelos tabulares le notificará las características del modelo que no son compatibles con el modo DirectQuery. Tenga presentes las siguientes limitaciones:

Característica	Restricción
Orígenes de datos	Los modelos de DirectQuery solo pueden usar datos de una base de datos relacional única de los siguientes tipos: Azure SQL Database, Azure Synapse Analytics, SQL Server, Oracle y Teradata.
Procedimientos almacenados de SQL	En el caso de los modelos directQuery, los procedimientos almacenados no se pueden especificar en una instrucción SQL para definir tablas.
Tablas calculadas	Las tablas calculadas no se admiten en los modelos DirectQuery, pero las columnas calculadas, sí. Si se trata de convertir un modelo tabular que contenga una columna calculada, se producirá un error que le indicará que el modelo no puede contener los datos pegados.
Límites de la consulta	El límite de filas predeterminado es un millón de filas. Este límite puede aumentar especificando MaxIntermediateRowSize. Para más información, consulte Propiedades de DAX.
Fórmulas DAX	Al consultar un modelo tabular en modo DirectQuery, Analysis Services convierte fórmulas DAX y definiciones de medida en instrucciones SQL. Las fórmulas DAX que contengan elementos que no se pueden convertir a sintaxis SQL devolverán errores de validación en el modelo. Esta restricción se limita principalmente a determinadas funciones de tabla DAX. En lo que respecta a las medidas, las fórmulas DAX se convierten en operaciones basadas en conjuntos en el almacén de datos relacionales. Es decir, se admiten todas las medidas creadas de forma implícita. Cuando se produzca un error de validación, tendrá que volver a escribir la fórmula (cambiarla por una función distinta) o usar columnas derivadas en el origen de datos como solución alternativa. Si un modelo tabular incluye fórmulas que contienen funciones incompatibles, se notificará al cambiar al modo DirectQuery en el diseñador. Nota: Algunas fórmulas del modelo pueden validarse al cambiar el modelo al modo DirectQuery, pero devuelven resultados diferentes cuando se ejecutan en la memoria caché frente al almacén de datos relacional. Esto se debe a que los cálculos en la memoria caché usan la semántica del motor de análisis en memoria, que contiene características destinadas a emular el comportamiento de Excel, mientras que las consultas en los datos almacenados en el origen de datos relacional usan la semántica de SQL.
Coherencia de fórmula	En algunos casos, la misma fórmula puede devolver resultados distintos en un modelo almacenado en caché, en comparación con un modelo DirectQuery que solo use el almacén de datos relacional. Estas diferencias son consecuencia de las diferencias semánticas entre el motor de análisis en memoria y el origen de datos.
Limitaciones de MDX	No hay ningún nombre de objeto relativo. Todos los nombres de objetos deben ser completos. Las instrucciones MDX sin ámbito de sesión (conjuntos con nombre, miembros calculados, celdas calculadas, totales visuales, miembros predeterminados, etc.), pero puede usar construcciones de ámbito de consulta, como la cláusula 'WITH'. No hay tuplas con miembros de diferentes niveles en las cláusulas de subselección de MDX. No hay jerarquías definidas por el usuario. No hay ninguna consulta SQL nativa (normalmente, Analysis Services admite un subconjunto de T-SQL, pero no para los modelos de DirectQuery).

Conectarse a un origen de datos

Al diseñar un modelo directQuery en Visual Studio, conectarse a un origen de datos y seleccionar las tablas y los campos que se van a incluir en el modelo es mucho igual que con los modelos en memoria.

Si ya ha activado DirectQuery pero aún no se ha conectado a un origen de datos, puede usar el Asistente para obtener datos (o el Asistente para importación de datos para orígenes de datos del proveedor heredado) para conectarse a un origen de datos, seleccionar tablas y campos, etc. La diferencia será que, al finalizar, en realidad no se importarán datos en la caché en memoria.

Si ya ha usado Obtener datos para importar datos, pero aún no ha activado el modo DirectQuery, cuando lo haga, se borrará la memoria caché en memoria.

Adición de datos de ejemplo a un proyecto de modelo de DirectQuery

De forma predeterminada, cuando se usa el diseñador de modelos tabulares en Visual Studio (SSDT) para diseñar un proyecto de modelo tabular de DirectQuery, la base de datos del área de trabajo del modelo no contiene ningún dato. Hay una partición predeterminada para cada tabla y esta partición dirige todas las consultas al origen de datos. Dado que DirectQuery se introdujo por primera vez, el diseñador de modelos tabulares incluye una característica Set as Sample (Establecer como ejemplo ) en el Administrador de particiones. Esta característica permite agregar una partición de copia a tablas que se pueden usar para importar una pequeña cantidad de datos de ejemplo en la base de datos del área de trabajo. Esta característica está pensada para ayudar a validar las decisiones de modelado sin afectar al origen de datos.

Importante

Actualmente, no se admite la característica Establecer como ejemplo en el diseñador de modelos tabulares . Ignore Table <TableName> no contiene una partición de ejemplo; para usar datos en SSDT, agregue una advertencia de partición de ejemplo.

Implementación de modelos de DirectQuery

Los modelos de DirectQuery se implementan igual que los modelos de importación. Sin embargo, a diferencia de los modelos de importación, si un modelo de DirectQuery contiene elementos calculados como columnas calculadas o grupos de cálculo, después de implementarse, debe realizar un proceso Recalc en todas las tablas. Para más información, consulte Procesar base de datos, tabla o partición.

Consulte también

Habilitación del modo DirectQuery en Visual Studio
Habilitar el modo DirectQuery en SSMS
Definición de particiones en modelos de DirectQueryPrueba de un modelo en modo DirectQuery
Orígenes de datos admitidos en Azure Analysis Services
Orígenes de datos admitidos en SQL Server Analysis Services modelos tabulares 1400 y superiores.