Modo DirectQuery em modelos tabulares
Aplica-se a:
SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium
Este artigo descreve o modo DirectQuery para modelos tabulares do Analysis Services nos níveis de compatibilidade 1200 e superiores. O modo DirectQuery pode ser habilitado para modelos que você está projetando no Visual Studio ou para modelos tabulares que já foram implantados, você pode alterar para o modo DirectQuery usando SQL Server Management Studio (SSMS). Antes de escolher o modo DirectQuery, é importante entender os benefícios e as limitações.
Benefícios
Por padrão, modelos de tabela usam um cache na memória para armazenar e consultar dados. Quando os modelos de tabela usam dados de consulta que residem na memória, até mesmo consultas complexas podem ser muito rápidas. No entanto, há algumas limitações ao uso de dados armazenados em cache, por exemplo, conjuntos de dados muito grandes podem exceder a memória disponível e o processamento (atualização) dos dados do modelo na memória pode exigir quantidades excessivas de recursos disponíveis, se necessário com frequência.
O DirectQuery supera essas limitações, ao mesmo tempo que aproveita os recursos RDBMS, tornando a execução da consulta mais eficiente. Com o DirectQuery:
Os dados estão atualizados. Como os dados são sempre consultados na fonte de dados, os aplicativos de relatório de cliente estão sempre obtendo os dados mais recentes.
Não há sobrecarga de gerenciamento extra de ter que manter uma cópia separada dos dados (no cache na memória). Nenhum processamento (atualização) de dados de modelo é necessário. As alterações nos dados de origem subjacentes podem ser refletidas imediatamente em consultas no modelo de dados.
Os conjuntos de dados podem ser maiores do que a capacidade de memória de um recurso de servidor do Analysis Services.
O DirectQuery pode aproveitar a aceleração de consulta do lado do provedor, como a fornecida por índices de coluna com otimização de memória.
A segurança pode ser imposta pelo banco de dados de origem de back-end usando recursos de segurança em nível de linha do banco de dados (como alternativa, você pode usar regras de segurança em nível de linha definidas no modelo usando DAX).
Se o modelo contiver fórmulas complexas que possam exigir várias consultas, o Analysis Services poderá executar a otimização para garantir que o plano de consulta da consulta executado no banco de dados back-end seja o mais eficiente possível.
Limitações
Modelos tabulares no modo DirectQuery têm algumas limitações. Antes de mudar os modos, é importante determinar se as vantagens da execução da consulta no servidor back-end superam qualquer redução na funcionalidade. Se você alterar o modo de um modelo existente no Visual Studio, o designer de modelo tabular notificará você sobre todos os recursos em seu modelo incompatíveis com o modo DirectQuery. Tenha em mente as seguintes limitações:
| Recurso | Restrição |
|---|---|
| Fontes de dados | Os modelos directQuery só podem usar dados de um único banco de dados relacional dos seguintes tipos: banco de dados SQL do Azure, análise de Azure Synapse, SQL Server, Oracle e Teradata. |
| Procedimentos armazenados do SQL | Para modelos DirectQuery, os procedimentos armazenados não podem ser especificados em uma instrução SQL para definir tabelas. |
| Tabelas calculadas | As tabelas calculadas não têm suporte para modelos DirectQuery, mas as colunas calculadas têm. Se você tentar converter um modelo de tabela que contém uma tabela calculada, ocorrerá um erro informando que o modelo não pode conter dados colados. |
| Limites de consulta | O limite de linha padrão é de um milhão de linhas. Esse limite pode ser aumentado especificando MaxIntermediateRowSize. Para saber mais, confira Propriedades da DAX. |
| Fórmulas DAX | Ao consultar um modelo tabular no modo DirectQuery, o Analysis Services converte fórmulas DAX e definições de medida em instruções SQL. As fórmulas DAX que contêm elementos que não podem ser convertidos em sintaxe SQL retornarão erros de validação no modelo. Essa restrição é limitada principalmente a determinadas funções de tabela DAX. Para medidas, as fórmulas DAX são convertidas em operações baseadas em conjunto no repositório de dados relacional. Isso significa que todas as medidas criadas implicitamente têm suporte. Quando ocorrer um erro de validação, você precisará gravar a fórmula novamente, substituindo uma função diferente, ou encontrar uma solução alternativa para isso usando colunas derivadas na fonte de dados. Se um modelo tabular incluir fórmulas que contenham funções incompatíveis, ele será relatado quando você alternar para o modo DirectQuery no designer. Observação: algumas fórmulas no modelo podem ser validadas quando você alterna o modelo para o modo DirectQuery, mas retornam resultados diferentes quando executados no cache versus no armazenamento de dados relacionais. Isso ocorre porque os cálculos em relação ao cache usam a semântica do mecanismo de análise na memória, que contém recursos destinados a emular o comportamento do Excel, enquanto as consultas em relação aos dados armazenados na fonte de dados relacionais usam a semântica do SQL. |
| Consistência de fórmula | Em alguns casos, a mesma fórmula pode retornar resultados diferentes em um modelo em cache comparado a um modelo do DirectQuery que usa apenas o armazenamento de dados relacionais. Essas diferenças são uma consequência das diferenças semânticas entre o mecanismo de análise na memória e a fonte de dados. |
| Limitações de MDX | Nenhum nome de objeto relativo. Todos os nomes de objeto devem estar totalmente qualificados. Nenhuma instrução MDX no escopo da sessão (conjuntos nomeados, membros calculados, células calculadas, totais visuais, membros padrão e assim por diante), mas você pode usar construções no escopo da consulta, como a cláusula 'WITH'. Não há tuplas com membros de níveis diferentes em cláusulas de subseleção MDX. Não há hierarquias definidas pelo usuário. Não há nenhuma consulta SQL nativa (normalmente, o Analysis Services dá suporte a um subconjunto T-SQL, mas não para modelos DirectQuery). |
Conectando a uma fonte de dados
Ao projetar um modelo DirectQuery no Visual Studio, conectar-se a uma fonte de dados e selecionar as tabelas e campos a serem incluídos no modelo é muito igual ao dos modelos na memória.
Se você já ativou o DirectQuery, mas ainda não se conectou a uma fonte de dados, pode usar Obter Dados (ou Assistente de Importação de Dados para fontes de dados do provedor herdado) para se conectar a uma fonte de dados, selecionar tabelas e campos e assim por diante. Haverá uma diferença quando você terminar: nenhum dado é realmente importado para o cache na memória.
Se você já usou Obter Dados para importar dados, mas ainda não ativou o modo DirectQuery, quando isso ocorrer, o cache na memória será limpo.
Adicionando dados de exemplo a um projeto de modelo do DirectQuery
Por padrão, ao usar o designer de modelo tabular no Visual Studio (SSDT) para criar um projeto de modelo tabular directQuery, o banco de dados do workspace do modelo não contém nenhum dado. Há uma partição padrão para cada tabela e essa partição direciona todas as consultas para a fonte de dados. Desde que o DirectQuery foi introduzido pela primeira vez, o designer de modelo tabular inclui um recurso Definir como Exemplo no Gerenciador de Partições. Esse recurso permite adicionar uma partição de cópia a tabelas que podem ser usadas para importar uma pequena quantidade de dados de exemplo para o banco de dados do workspace. Esse recurso serve para ajudar a validar decisões de modelagem sem afetar a fonte de dados.
Importante
Atualmente, não há suporte para o recurso Definir como Exemplono designer de modelo tabular . Ignorar Table <TableName> não contém uma partição de exemplo; para usar dados no SSDT, adicione um exemplo de avisos de partição.
Implantando modelos do DirectQuery
Os modelos directQuery são implantados da mesma forma que os modelos de importação. No entanto, ao contrário dos modelos de importação, se um modelo directQuery contiver itens calculados, como colunas calculadas ou grupos de cálculo, depois de ser implantado, você deverá executar um Recalc de Processo em todas as tabelas. Para saber mais, confira Processar banco de dados, tabela ou partição.
Confira também
Habilitar o modo DirectQuery no Visual Studio
Habilitar o modo DirectQuery no SSMS
Definir partições em modelos DirectQueryTestar um modelo no modo DirectQuery
Fontes de dados com suporte no Azure Analysis Services
Fontes de dados com suporte em SQL Server Analysis Services modelos tabulares 1400 e superiores.