Gerenciar modelos semânticos do Direct Lake

  • Artigo

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ê deverá 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 ele. Você também pode endossar (certificar ou promover) 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 endpoint 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 do Direct Lake, a conexão de nuvem padrão é usada. Ela aproveita o SSO (logon único). Isso 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 do SQL.

Conexão de nuvem compartilhável

Opcionalmente, você pode criar uma SCC (conexão de nuvem fragmentável) 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 o 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 OAuth 2.0 ou a entidade de serviço.

Nota

Somente a autenticação do Microsoft Entra tem suporte. Portanto, não há suporte para a autenticação Basic 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 do SQL e os metadados de 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 caso a senha seja alterada ou a conta de usuário seja excluída (como quando um funcionário sair da organização).

Entidade de serviço

A autenticação com uma entidade de serviço é a prática recomendada porque ela 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 de esquema.

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

Nota

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 Single Sign-On é 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 do 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 às conexões de nuvem:

  • Quando todos os usuários podem acessar os dados (e ter permissão para fazer isso), não é necessário 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 ocorrer porque os usuários que consultam o modelo semântico não recebem permissão para ler o lakehouse ou o warehouse. Essa abordagem é especialmente relevante quando o modelo semântico impõe 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 alterem a senha ou saiam da organização.
  • Se usuários diferentes precisarem ser restritos a acessar apenas subconjuntos de dados, se viável, imponha 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 em visuais de relatório. Erros podem criar confusão ou preocupação para os usuários. Para colunas sumarizáveis, considere criar medidas que retornem BLANK em determinadas condições em vez de CLS (se possível).

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

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

Definir permissões de item do Fabric

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 endpoint de análise do 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 do Direct Lake. Em suma, os consumidores de relatório precisam da permissão de Leitura e os criadores de relatório 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 do workspace. Para gerenciar as configurações de modelo semântico (para atualização e outras configurações), você deve ser o proprietário do modelo semântico .

Dependendo da conexão com a nuvem configurada e se os usuários precisam consultar o endpoint de análise SQL do lakehouse ou warehouse, talvez seja necessário conceder outras permissões (descritas na tabela nesta seção).

Nota

Notavelmente, os usuários nunca exigem 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 endpoint de análise do SQL, a fim de executar verificações de permissão e determinar quais dados o usuário que realiza a 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 exibir 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 de nuvem usar SSO, conceda pelo menos permissão de Leitura para o lakehouse ou warehouse.		 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 Build para o modelo semântico.
• Se a conexão de nuvem usar SSO, conceda pelo menos a permissão de Leitura para o lakehouse ou warehouse.		 Para obter mais informações, consulte Estratégia para criadores de conteúdo.
Os usuários podem consultar o modelo semântico, mas são impedidos de consultar o endpoint lakehouse ou o endpoint de análise SQL. • Não conceda nenhuma permissão para o lakehouse ou o warehouse. Adequado somente quando a conexão de 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 ReadData para o lakehouse ou warehouse. Importante: as consultas enviadas ao endpoint 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 semântica do modelo. Para obter mais informações, consulte Propriedade do modelo semântico.

Importante

Você sempre deve 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 do Direct Lake resulta em uma operação de enquadramento. Uma operação de atualização pode ser disparada:

  • Manualmente, fazendo uma atualização sob demanda no portal do Fabric ou executando o comando Atualizar do TMSL (Linguagem de Scripts de Modelo Tabular) de um script no SSMS (SQL Server Management Studio) 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 forem detectadas alterações nas tabelas Delta subjacentes—para mais informações, confira Atualizações Automáticas (descritas a seguir).
  • Programaticamente, disparando uma atualização usando a API REST do Power BI ou o 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 de nível de modelo chamada Manter seus dados do Direct Lake atualizados que faz atualizações automáticas de tabelas do Direct Lake. Ele está 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 de 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 detectadas. 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 pequeno ou médio. É 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 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).

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, verifique se o modelo semântico pode 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 de 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, pois 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 uma consulta programaticamente para o modelo semântico. Uma maneira conveniente de enviar uma consulta é utilizar 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 atrasos são inaceitáveis. Tome cuidado para não carregar desnecessariamente na memória dados que possam pressionar outras cargas de trabalho de capacidade, fazendo com que elas sejam limitadas ou não sejam priorizadas.

Definir a propriedade de comportamento do Direct Lake

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

  • Automático: (Padrão) as consultas retornam ao modo DirectQuery se os dados necessários não podem 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, em que, 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 Modelo de Objeto Tabular (TOM) ou a Linguagem de Script de Modelo Tabular (TMSL) .

Dica

Considere desabilitar o fallback do DirectQuery quando você quiser processar consultas somente no modo de armazenamento do 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 do Direct Lake para identificar se ocorre fallback e com que frequência isso acontece.

Monitorar modelos semânticos do Direct Lake

Você pode monitorar um modelo semântico do Direct Lake para avaliar o desempenho das consultas DAX em visualizações de relatórios, ou para identificar quando ele retorna ao modo DirectQuery.

Você pode usar o Analisador de Desempenho, o SQL Server Profiler, o Azure Log Analytics ou uma ferramenta de comunidade de software livre, como o DAX Studio.

Analisador de Desempenho

Você pode usar do Analisador de Desempenho no Power BI Desktop para registrar o tempo de processamento necessário para atualizar os 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 do SQL Server Profiler para recuperar detalhes sobre o desempenho da consulta rastreando eventos de consulta. É 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 rápido de consulta, a menos que uma alternância para o modo DirectQuery seja necessária. 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 (Análise de Logs do Azure)

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

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

Conteúdo relacionado