Gerenciar modelos semânticos do Direct Lake

  • Artigo

Este artigo descreve tópicos de design relevantes para o gerenciamento de 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 conexão de nuvem

Um modelo semântico do Direct Lake usa uma conexão de nuvem para se conectar ao ponto de extremidade de análise do 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 do Direct Lake, a conexão de nuvem padrão é usada. Ele aproveita o SSO (logon único), 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 de 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 de acesso centralizado.

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

Autenticação

A identidade fixa pode ser autenticada usando o OAuth 2.0 ou a entidade de serviço.

Observação

Somente a autenticação do Microsoft Entra tem suporte. Portanto, não há suporte para a autenticação básica para modelos semânticos do Direct Lake.

OAuth 2.0

Ao usar o OAuth 2.0, você pode se 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 do ponto de extremidade de análise SQL e os metadados do esquema.

Usar uma conta de usuário específica não é uma prática recomendada. Isso ocorre 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 sai da organização).

Entidade 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 do ponto de extremidade de análise SQL e os metadados do esquema.

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

Observação

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

Logon Ú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 de análise SQL. Nessa configuração, o modelo semântico do 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 fazer isso.

Aqui estão as práticas recomendadas relacionadas a conexões de 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 padrão de conexão de nuvem podem ser usadas. Nesse caso, a identidade do usuário que consulta o modelo será usada caso as consultas voltem para o modo DirectQuery.
  • Crie uma conexão de nuvem compartilhada quando quiser usar uma identidade fixa para consultar dados de origem. Isso pode ocorrer porque os usuários que consultam o modelo semântico não têm permissão para ler o lakehouse ou warehouse. Essa abordagem é especialmente relevante quando o modelo semântico impõe a RLS.
  • Se você usar uma identidade fixa, use a opção Entidade de serviço porque ela é mais segura e confiável. Isso ocorre 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 usuários diferentes precisarem ser restritos a acessar apenas subconjuntos de dados, se viável, imponha a RLS somente na camada do 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 usuários. 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 de direito de acesso

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

Definir permissões de item de malha

Os modelos semânticos do 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 está tentando 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 do Direct Lake. Em resumo, os consumidores de relatórios precisam de permissão de leitura e os criadores de relatórios precisam da permissão de compilação . As permissões de 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 warehouse, talvez seja necessário conceder outras permissões (descritas na tabela nesta seção).

Observação

Notavelmente, os usuários nunca precisam de permissão para ler dados no OneLake. Isso ocorre 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 de consulta (ou identidade fixa) pode acessar.

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

Cenário Permissões necessárias Comentários
Os usuários podem visualizar relatórios • Conceda 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 o lakehouse ou armazém.		 Os relatórios não precisam pertencer ao mesmo workspace que o modelo semântico. Para obter mais informações, consulte Estratégia para consumidores somente leitura.
Os usuários podem criar relatórios • Conceda 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 o lakehouse 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 de análise do SQL ou do lakehouse • Não conceda nenhuma permissão para a casa do lago ou armazém. Adequado apenas quando a conexão com a nuvem usa uma identidade fixa.
Os usuários podem consultar o modelo semântico e o ponto de extremidade de análise do SQL, mas não podem consultar o lakehouse • Conceda permissões de leitura e ReadData para o lakehouse ou warehouse. Importante: As consultas enviadas ao ponto de extremidade de análise do 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, confira Detalhes do 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 do Fabric ou executando o comando de atualização TMSL (Tabular Model Scripting Language) 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 um agendamento de atualização no portal do Fabric.
  • Automaticamente, quando são detectadas alterações nas tabelas Delta subjacentes, para obter mais informações, consulte Atualizações automáticas (descritas a seguir).
  • Programaticamente, disparando uma atualização usando a API REST do Power BI ou TOM. Você pode disparar uma atualização programática como uma etapa final de um processo de ETL (extração, transformação e carregamento).

Atualizações automáticas

Há uma configuração semântica no nível do modelo chamada Manter os dados do Direct Lake atualizados que faz atualizações automáticas das tabelas do Direct Lake. Isso é habilitado por padrão. Ele garante que as alterações de dados no OneLake sejam refletidas automaticamente no modelo semântico do Direct Lake. A configuração está disponível no portal do 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 são detectadas modificações de dados nas tabelas Delta subjacentes. A operação de enquadramento é sempre específica apenas para as tabelas em que as modificações de dados são detectadas.

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, talvez você queira desabilitar as atualizações automáticas. Por exemplo, talvez seja necessário permitir a conclusão de trabalhos de preparação de dados ou o processo de ETL antes de expor novos dados aos consumidores do modelo semântico. Quando desabilitado, você pode disparar uma atualização usando um método programático (descrito anteriormente).

Observação

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.

Aquecer o cache

Uma operação de atualização do modelo semântico do 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 do Direct Lake podem sofrer algum atraso à medida que as colunas são carregadas na memória. Os atrasos só podem ser perceptíveis quando você tem volumes extremamente grandes de dados.

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

Importante

O aquecimento do 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 pressionar 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 do Direct Lake definindo sua DirectLakeBehavior propriedade. Ele pode ser definido como:

  • Automático: (Padrão) As consultas voltam para o 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. O fallback para o modo DirectQuery está desabilitado. Se os dados não puderem ser carregados na memória, um erro será retornado.
  • DirectQueryOnly: todas as consultas usam apenas 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 o TOM (Modelo de Objeto de Tabela) ou a TMSL (Linguagem de Script de Modelo de Tabela).

Dica

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

Monitorar modelos semânticos do Direct Lake

Você pode monitorar um modelo semântico do 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 software livre, como o DAX Studio.

Performance Analyzer

Você pode usar o Analisador de Desempenho no Power BI Desktop para registrar o tempo de processamento necessário para atualizar os elementos do 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 do 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 do 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 do Direct Lake. É um serviço no 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.

Conteúdo relacionado