Partilhar via


Gerenciar modelos semânticos do Direct Lake

Este artigo descreve tópicos de design relevantes para gerenciar modelos semânticos do Direct Lake.

Tarefas pós-publicação

Depois de publicar pela primeira vez um modelo semântico do Direct Lake pronto para relatórios, você deve concluir imediatamente algumas tarefas pós-publicação. Essas tarefas também podem ser ajustadas a qualquer momento durante o ciclo de vida do modelo semântico.

Opcionalmente, você também pode configurar a descoberta de dados para permitir que os criadores de relatórios leiam metadados, ajudando-os a descobrir dados no hub de dados do OneLake e solicitar acesso a eles. Você também pode endossar (certificado ou promovido) o modelo semântico para comunicar que ele representa dados de qualidade adequados para uso.

Configurar a ligação à nuvem

Um modelo semântico Direct Lake usa uma conexão de nuvem para se conectar ao ponto de extremidade de análise SQL. Ele permite o acesso aos dados de origem, que são os arquivos Parquet no OneLake (modo de armazenamento Direct Lake, que envolve o carregamento de dados de coluna na memória) ou o ponto de extremidade de análise SQL (quando as consultas retornam ao modo DirectQuery).

Conexão de nuvem padrão

Quando você cria um modelo semântico Direct Lake, a conexão de nuvem padrão é usada. Ele aproveita o logon único (SSO), o que significa que a identidade que consulta o modelo semântico (geralmente um usuário de relatório) é usada para consultar os dados do ponto de extremidade da análise SQL.

Conexão de nuvem compartilhável

Opcionalmente, você pode criar uma conexão de nuvem compartilhável (SCC) para que as conexões com a fonte de dados possam ser feitas com uma identidade fixa. Ele pode ajudar os clientes corporativos a proteger seus armazenamentos de dados organizacionais. O departamento de TI pode gerenciar credenciais, criar SCCs e compartilhá-las com os criadores pretendidos para gerenciamento centralizado de acesso.

Para configurar uma identidade fixa, consulte Especificar uma identidade fixa para um modelo semântico Direct Lake.

Autenticação

A identidade fixa pode autenticar usando OAuth 2.0 ou entidade de serviço.

Nota

Apenas a autenticação do Microsoft Entra é suportada. Portanto, a autenticação básica não é suportada para modelos semânticos Direct Lake.

OAuth 2.0

Quando você usa o OAuth 2.0, você pode autenticar com uma conta de usuário do Microsoft Entra. A conta de usuário deve ter permissão para consultar as tabelas e exibições de ponto de extremidade da análise SQL e os metadados do esquema.

Usar uma conta de usuário específica não é uma prática recomendada. Isso porque as consultas de modelo semântico falharão se a senha for alterada ou a conta de usuário for excluída (como quando um funcionário sair da organização).

Service principal (Principal de serviço)

A autenticação com uma entidade de serviço é a prática recomendada porque não depende de uma conta de usuário específica. A entidade de segurança deve ter permissão para consultar as tabelas e exibições de ponto de extremidade da análise SQL e os metadados do esquema.

Para a continuidade, as credenciais da entidade de serviço podem ser gerenciadas por rotação secreta/de certificado.

Nota

As configurações de locatário de malha devem permitir entidades de serviço e a entidade de serviço deve pertencer a um grupo de segurança declarado.

Início de sessão único

Quando você cria uma conexão de nuvem compartilhável, a caixa de seleção Logon único é desmarcada por padrão. Essa é a configuração correta ao usar uma identidade fixa.

Você pode habilitar o SSO quando quiser que a identidade que consulta o modelo semântico também consulte o ponto de extremidade da análise SQL. Nessa configuração, o modelo semântico Direct Lake usará a identidade fixa para atualizar o modelo e a identidade do usuário para consultar dados.

Ao usar uma identidade fixa, é prática comum desabilitar o SSO para que a identidade fixa seja usada para atualizações e consultas, mas não há nenhum requisito técnico para isso.

Aqui estão as práticas recomendadas relacionadas a conexões na nuvem:

  • Quando todos os usuários podem acessar os dados (e têm permissão para fazê-lo), não há necessidade de criar uma conexão de nuvem compartilhada. Em vez disso, as configurações de conexão de nuvem padrão podem ser usadas. Nesse caso, a identidade do usuário que consulta o modelo será usada caso as consultas retornem ao modo DirectQuery.
  • Crie uma conexão de nuvem compartilhada quando quiser usar uma identidade fixa para consultar dados de origem. Isso pode ser porque os usuários que consultam o modelo semântico não recebem permissão para ler a casa do lago ou o armazém. Esta abordagem é especialmente relevante quando o modelo semântico impõe a SPI.
  • Se você usar uma identidade fixa, use a opção Entidade de serviço porque ela é mais segura e confiável. Isso porque ele não depende de uma única conta de usuário ou de suas permissões, e não exigirá manutenção (e interrupção) caso eles alterem sua senha ou saiam da organização.
  • Se diferentes usuários precisarem ser restritos para acessar apenas subconjuntos de dados, se viável, imponha a RLS somente na camada de modelo semântico. Dessa forma, os usuários se beneficiarão de consultas na memória de alto desempenho.
  • Se possível, evite OLS e CLS porque isso resulta em erros nos visuais do relatório. Os erros podem criar confusão ou preocupação para os utilizadores. Para colunas resumidas, considere a criação de medidas que retornem BLANK em determinadas condições em vez de CLS (se possível).

Gerenciar associação à função de segurança

Se o modelo semântico do Direct Lake impuser segurança em nível de linha (RLS), talvez seja necessário gerenciar os membros atribuídos às funções de segurança. Para obter mais informações, consulte Gerenciar a segurança em seu modelo.

Definir permissões de item de malha

Os modelos semânticos Direct Lake aderem a um modelo de segurança em camadas. Eles executam verificações de permissão por meio do ponto de extremidade de análise SQL para determinar se a identidade que tenta acessar os dados tem as permissões de acesso a dados necessárias.

Você deve conceder permissões aos usuários para que eles possam usar ou gerenciar o modelo semântico Direct Lake. Em resumo, os consumidores de relatórios precisam da permissão de Leitura e os criadores de relatórios precisam da permissão de Compilação . As permissões do modelo semântico podem ser atribuídas diretamente ou adquiridas implicitamente por meio de funções de espaço de trabalho. Para gerenciar as configurações do modelo semântico (para atualização e outras configurações), você deve ser o proprietário do modelo semântico.

Dependendo da configuração da conexão de nuvem e se os usuários precisam consultar o ponto de extremidade de análise SQL do lakehouse ou do depósito, talvez seja necessário conceder outras permissões (descritas na tabela desta seção).

Nota

Notavelmente, os usuários nunca precisam de permissão para ler dados no OneLake. Isso porque o Fabric concede as permissões necessárias ao modelo semântico para ler as tabelas Delta e os arquivos Parquet associados (para carregar dados de coluna na memória). O modelo semântico também tem as permissões necessárias para ler periodicamente o ponto de extremidade de análise SQL para executar verificações de permissão para determinar quais dados o usuário que consulta (ou identidade fixa) pode acessar.

Considere os seguintes cenários e requisitos de permissão.

Cenário Permissões obrigatórias Comentários
Os usuários podem exibir relatórios • Conceder permissão de Leitura para os relatórios e permissão de Leitura para o modelo semântico.
• Se a conexão com a nuvem usar SSO, conceda pelo menos permissão de leitura para a casa do lago ou armazém.
Os relatórios não precisam pertencer ao mesmo espaço de trabalho que o modelo semântico. Para obter mais informações, consulte Estratégia para consumidores somente leitura.
Os usuários podem criar relatórios • Conceder permissão de construção para o modelo semântico.
• Se a conexão com a nuvem usar SSO, conceda pelo menos permissão de leitura para a casa do lago ou armazém.
Para obter mais informações, consulte Estratégia para criadores de conteúdo.
Os usuários podem consultar o modelo semântico, mas não podem consultar o ponto de extremidade lakehouse ou de análise SQL • Não conceda nenhuma permissão para a casa do lago ou armazém. Adequado apenas quando a conexão na nuvem usa uma identidade fixa.
Os usuários podem consultar o modelo semântico e o ponto de extremidade de análise SQL, mas não podem consultar o lakehouse • Conceda permissões de leitura e leitura de dados para a casa do lago ou armazém. Importante: as consultas enviadas para o ponto de extremidade de análise SQL ignorarão as permissões de acesso a dados impostas pelo modelo semântico.
Gerenciar o modelo semântico, incluindo configurações de atualização • Requer propriedade do modelo semântico. Para obter mais informações, consulte Propriedade do modelo semântico.

Importante

Você deve sempre testar completamente as permissões antes de liberar seu modelo semântico e relatórios em produção.

Para obter mais informações, consulte Permissões de modelo semântico.

Atualizar modelos semânticos do Direct Lake

Uma atualização de um modelo semântico Direct Lake resulta em uma operação de enquadramento . Uma operação de atualização pode ser acionada:

  • Manualmente, fazendo uma atualização sob demanda no portal de malha ou executando o comando Atualizar TMSL (Tabular Model Scripting Language) a partir de um script no SQL Server Management Studio (SSMS) ou usando uma ferramenta de terceiros que se conecta por meio do ponto de extremidade XMLA.
  • Automaticamente, configurando uma agenda de atualização no portal do Fabric.
  • Automaticamente, quando forem detetadas alterações nas tabelas Delta subjacentes — para obter mais informações, consulte Atualizações automáticas (descritas a seguir).
  • Programaticamente, acionando uma atualização usando a API REST do Power BI ou TOM. Você pode acionar uma atualização programática como uma etapa final de um processo de extração, transformação e carregamento (ETL).

Atualizações automáticas

Há uma configuração semântica no nível do modelo chamada Manter seus dados do Direct Lake atualizados que faz atualizações automáticas das tabelas do Direct Lake. Está ativada por predefinição. Ele garante que as alterações de dados no OneLake sejam refletidas automaticamente no modelo semântico Direct Lake. A configuração está disponível no portal Fabric, na seção Atualizar das configurações do modelo semântico.

Quando a configuração está habilitada, o modelo semântico executa uma operação de enquadramento sempre que modificações de dados em tabelas Delta subjacentes são detetadas. A operação de enquadramento é sempre específica apenas para as tabelas onde as modificações de dados são detetadas.

Recomendamos que você deixe a configuração ativada, especialmente quando tiver um modelo semântico de pequeno ou médio porte. É especialmente útil quando você tem requisitos de relatórios de baixa latência e as tabelas Delta são modificadas regularmente.

Em algumas situações, convém desativar as atualizações automáticas. Por exemplo, talvez seja necessário permitir a conclusão de trabalhos de preparação de dados ou do processo ETL antes de expor novos dados aos consumidores do modelo semântico. Quando desativado, você pode disparar uma atualização usando um método programático (descrito anteriormente).

Nota

O Power BI suspende as atualizações automáticas quando um erro não recuperável é encontrado durante a atualização. Um erro não recuperável pode ocorrer, por exemplo, quando uma atualização falha após várias tentativas. Portanto, certifique-se de que seu modelo semântico possa ser atualizado com êxito. O Power BI retoma automaticamente as atualizações automáticas quando uma atualização sob demanda subsequente é concluída sem erros.

Aqueça o cache

Uma operação de atualização do modelo semântico Direct Lake pode remover todas as colunas residentes da memória. Isso significa que as primeiras consultas após uma atualização de um modelo semântico Direct Lake podem sofrer algum atraso à medida que as colunas são carregadas na memória. Os atrasos só podem ser percetíveis quando você tem volumes de dados extremamente grandes.

Para evitar esses atrasos, considere aquecer o cache enviando programaticamente uma consulta para o modelo semântico. Uma maneira conveniente de enviar uma consulta é usar o link semântico. Esta operação deve ser feita imediatamente após a conclusão da operação de atualização.

Importante

Aquecer o cache só pode fazer sentido quando os atrasos são inaceitáveis. Tome cuidado para não carregar dados desnecessariamente na memória que possam colocar pressão sobre outras cargas de trabalho de capacidade, fazendo com que elas sejam limitadas ou despriorizadas.

Definir a propriedade de comportamento Direct Lake

Você pode controlar o fallback de seus modelos semânticos Direct Lake definindo sua DirectLakeBehavior propriedade. Pode ser definido como:

  • Automático: (Padrão) As consultas voltam ao modo DirectQuery se os dados necessários não puderem ser carregados com eficiência na memória.
  • DirectLakeOnly: Todas as consultas usam apenas o modo de armazenamento Direct Lake. Voltar ao modo DirectQuery está desativado. Se os dados não puderem ser carregados na memória, um erro será retornado.
  • DirectQueryOnly: Todas as consultas usam somente o modo DirectQuery. Use essa configuração para testar o desempenho de fallback, onde, por exemplo, você pode observar o desempenho da consulta em relatórios conectados.

Você pode definir a propriedade na experiência de modelagem da Web ou usando TOM (Tabular Object Model) ou TMSL (Tabular Model Scripting Language).

Gorjeta

Considere desativar o fallback do DirectQuery quando quiser processar consultas somente no modo de armazenamento Direct Lake. Recomendamos que você desabilite o fallback quando não quiser voltar ao DirectQuery. Também pode ser útil quando você deseja analisar o processamento de consultas para um modelo semântico Direct Lake para identificar se e com que frequência ocorre fallback.

Monitorar modelos semânticos Direct Lake

Você pode monitorar um modelo semântico Direct Lake para determinar o desempenho de consultas DAX visuais de relatório ou para determinar quando ele retorna ao modo DirectQuery.

Você pode usar o Performance Analyzer, o SQL Server Profiler, o Azure Log Analytics ou uma ferramenta de comunidade de código aberto, como o DAX Studio.

Analisador de Desempenho

Você pode usar o Analisador de Desempenho no Power BI Desktop para registrar o tempo de processamento necessário para atualizar elementos de relatório iniciados como resultado de qualquer interação do usuário que resulte na execução de uma consulta. Se os resultados do monitoramento mostrarem uma métrica de consulta direta, isso significa que as consultas DAX foram processadas no modo DirectQuery. Na ausência dessa métrica, as consultas DAX foram processadas no modo Direct Lake.

Para obter mais informações, consulte Analisar usando o Performance Analyzer.

SQL Server Profiler

Você pode usar o SQL Server Profiler para recuperar detalhes sobre o desempenho da consulta rastreando eventos de consulta. Ele é instalado com o SQL Server Management Studio (SSMS). Antes de começar, verifique se você tem a versão mais recente do SSMS instalada.

Para obter mais informações, consulte Analisar usando o SQL Server Profiler.

Importante

Em geral, o modo de armazenamento Direct Lake fornece desempenho de consulta rápido, a menos que seja necessário um fallback para o modo DirectQuery. Como o fallback para o modo DirectQuery pode afetar o desempenho da consulta, é importante analisar o processamento de consultas para um modelo semântico Direct Lake para identificar se, com que frequência e por que os fallbacks ocorrem.

Azure Log Analytics

Você pode usar o Azure Log Analytics para coletar, analisar e agir em dados de telemetria associados a um modelo semântico Direct Lake. É um serviço dentro do Azure Monitor, que o Power BI usa para salvar logs de atividades.

Para obter mais informações, consulte Usando o Azure Log Analytics no Power BI.