Compartilhar via

Desenvolver modelos semânticos do Direct Lake

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

Criar o modelo

Você pode criar um modelo semântico do Direct Lake no Power BI Desktop ou em muitos itens do Fabric no navegador. Por exemplo, em um Lakehouse aberto, você pode escolher Novo modelo semântico para criar um novo modelo semântico no modo de armazenamento Direct Lake.

Você pode usar o Power BI Desktop ou a modelagem da Web no navegador para editar o modelo semântico para adicionar relações, renomear campos, adicionar medidas e outras tarefas de modelagem semântica.

Como alternativa, como em qualquer modelo semântico do Power BI, você pode continuar o desenvolvimento do modelo usando uma ferramenta compatível com XMLA, como o SSMS (SQL Server Management Studio) (versão 19.1 ou posterior) ou ferramentas de comunidade de software livre. Para obter mais informações, veja Suporte à gravação de modelo com o ponto de extremidade XMLA mais adiante neste artigo. Os notebooks do Fabric também podem criar e editar modelos semânticos programaticamente com links semânticos e laboratórios de links semânticos.

Tip

Você pode aprender a criar uma lakehouse, uma tabela Delta e um modelo semântico básico do Direct Lake concluindo este tutorial.

Model tables

As tabelas de modelo são baseadas em uma tabela ou em uma exibição do ponto de extremidade de análise SQL. No entanto, evite usar visualizações sempre que possível. Consultas a uma tabela de modelo com base em uma vista recaem no modo DirectQuery, o que pode resultar em um desempenho de consulta mais lento.

Warning

Visões só podem ser usadas no Direct Lake no SQL e não podem ser usadas no Direct Lake no OneLake.

As tabelas devem incluir colunas para filtragem, agrupamento, classificação e resumo, além de colunas que dão suporte a relações de modelo. Colunas desnecessárias não afetam o desempenho de consulta de modelo semântico porque não são carregadas na memória, mas resultam em um tamanho de armazenamento maior no OneLake e exigem mais recursos de computação para carregar e manter.

Warning

Não há suporte para o uso de colunas que aplicam DDM (máscara de dados dinâmica) em modelos semânticos do Direct Lake.

As tabelas de importação podem ser adicionadas a modelos semânticos com o Direct Lake em tabelas OneLake. Tabelas calculadas podem ser adicionadas desde que não façam referência a uma tabela do Direct Lake. Grupos de cálculo podem ser adicionados.

Para saber como selecionar quais tabelas incluir no modelo semântico do Direct Lake, consulte Editar tabelas para modelos semânticos do Direct Lake.

Para obter mais informações sobre colunas a serem incluídas em suas tabelas de modelo semântico, consulte Noções básicas sobre o desempenho da consulta do Direct Lake.

Impor regras de acesso a dados

Quando você tem requisitos para fornecer subconjuntos de dados de modelo para diferentes usuários, você pode impor regras de acesso a dados. Você aplica regras configurando a OLS (segurança no nível do objeto) e/ou a RLS (segurança em nível de linha) no endpoint de análise SQL ou no modelo semântico.

Note

O tópico da imposição de regras de acesso a dados é diferente, mas relacionado, à configuração de permissões para consumidores de conteúdo, criadores e usuários que gerenciam o modelo semântico (e itens relacionados do Fabric). Para obter mais informações sobre como definir permissões, consulte Gerenciar modelos semânticos do Direct Lake.

Segurança no nível do objeto (OLS)

OLS envolve restringir o acesso para descobrir e consultar objetos ou colunas. Por exemplo, você pode usar o OLS para limitar os usuários que podem acessar a coluna Salary da tabela Employee.

Para um ponto de extremidade de análise SQL, você pode configurar o OLS para controlar o acesso aos objetos do ponto de extremidade, como tabelas ou visualizações, e a segurança em nível de coluna (CLS) para controlar o acesso às colunas da tabela do ponto de extremidade.

Para um modelo semântico, você pode configurar o OLS para controlar o acesso a tabelas ou colunas de modelo. Você precisa usar ferramentas de software livre e de comunidade, como o Editor tabular, para configurar o OLS.

Segurança no nível da linha (RLS)

O RLS envolve restringir o acesso a subconjuntos de dados em tabelas. Por exemplo, você pode usar rls para garantir que os vendedores só possam acessar dados de vendas para clientes em sua região de vendas.

Para um endpoint de análise SQL, você pode configurar o RLS para controlar o acesso às linhas em uma tabela de endpoint.

Important

Quando uma consulta usa qualquer tabela que tenha RLS no ponto de extremidade de análise do SQL, ela volta para o modo DirectQuery. O desempenho da consulta pode ser mais lento.

Para um modelo semântico, você pode configurar o RLS para controlar o acesso a linhas em tabelas de modelo. O RLS pode ser configurado na experiência de modelagem da Web ou usando uma ferramenta de terceiros.

Como as consultas são avaliadas

O motivo para desenvolver modelos semânticos do Direct Lake é obter consultas de alto desempenho em grandes volumes de dados no OneLake. Portanto, você deve se esforçar para criar uma solução que maximize as chances de consulta na memória.

As etapas a seguir se aproximam de como as consultas são avaliadas (e se elas falham). Os benefícios do modo de armazenamento direct lake só são possíveis quando a quinta etapa é alcançada.

  1. Se a consulta contiver qualquer tabela ou coluna restrita pelo modelo semântico OLS, um resultado de erro será retornado (os visuais do relatório não serão renderizados).
  2. Se a consulta contiver qualquer coluna restrita pelo CLS do endpoint de análise do SQL (ou se a tabela for negada), um resultado de erro será retornado (os visuais do relatório falharão ao serem renderizados).
    1. Se a conexão de nuvem usar SSO (padrão), CLS será determinado pelo nível de acesso do consumidor de relatório.
    2. Se a conexão de nuvem usar uma identidade fixa, CLS será determinado pelo nível de acesso da identidade fixa.
  3. Se a consulta contiver qualquer tabela no ponto de extremidade de análise do SQL que imponha RLS ou se uma visão for usada, a consulta retornará ao modo DirectQuery.
    1. Se a conexão de nuvem usar SSO (padrão), o RLS será determinado pelo nível de acesso do consumidor de relatório.
    2. Se a conexão de nuvem usar uma identidade fixa, o RLS será determinado pelo nível de acesso da identidade fixa.
  4. Se a consulta exceder os guardrails da capacidade, ela retornará ao modo DirectQuery.
  5. Caso contrário, a consulta será atendida do cache na memória. Os dados da coluna são carregados na memória como e quando são necessários.

Permissões de itens de origem

A conta usada para acessar dados é uma das seguintes.

  • Se a conexão de nuvem usar SSO (padrão), será o consumidor do relatório.
  • Se a conexão de nuvem usar uma identidade fixa, ela será a identidade fixa.

A conta precisa ter pelo menos permissões Leitura e ReadData no item de origem (lakehouse ou warehouse). As permissões de item podem ser herdadas de funções de workspace ou atribuídas explicitamente para o item, conforme descrito neste artigo.

Supondo que esse requisito seja atendido, o Fabric concede o acesso necessário ao modelo semântico para ler as tabelas Delta e os arquivos Parquet associados (para carregar dados de coluna na memória) e as regras de acesso a dados podem ser aplicadas.

Opções de regra de acesso a dados

Você pode configurar regras de acesso a dados em:

  • Somente o modelo semântico.
  • Somente o ponto de extremidade de análise SQL.
  • Tanto no modelo semântico quanto no ponto de extremidade de análise SQL.

Regras no modelo semântico

Se você precisar impor regras de acesso a dados, deverá fazê-lo no modelo semântico sempre que viável. Isso ocorre porque o RLS imposto pelo modelo semântico é obtido filtrando o cache de dados na memória para obter consultas de alto desempenho.

Também é uma abordagem adequada quando os consumidores de relatórios não têm permissão para consultar o lakehouse ou o armazém.

Em ambos os casos, é altamente recomendável que a conexão de nuvem use uma identidade fixa em vez de SSO. O SSO implicaria que os usuários finais podem acessar diretamente o endpoint de análise SQL e, assim, podem ignorar as regras de segurança no modelo semântico.

Important

Permissões de item de modelo semântico podem ser definidas explicitamente por meio de aplicativos do Power BI ou adquiridas implicitamente por meio de funções de workspace.

Notavelmente, as regras de acesso a dados do modelo semântico não são aplicadas para usuários que têm permissão de escrita no modelo semântico. Por outro lado, as regras de acesso a dados se aplicam aos usuários atribuídos à função de workspace Viewer. No entanto, os usuários atribuídos ao papel no ambiente de trabalho Administrador, Membro ou Colaborador têm implicitamente permissão de escrita no modelo semântico e, portanto, as regras de acesso a dados não são impostas. Para obter mais informações, consulte Funções em espaços de trabalho.

Regras no ponto de extremidade de análise SQL

É apropriado impor regras de acesso a dados no ponto final de análise SQL quando a conexão de nuvem do modelo semântico usa SSO (logon único). Isso ocorre porque a identidade do usuário é delegada para consultar o endpoint de análise SQL, garantindo que as consultas retornem apenas os dados que o usuário tem permissão para acessar. Também é apropriado impor regras de acesso a dados neste nível quando os usuários consultam o endpoint de análise SQL diretamente para outras tarefas (por exemplo, para criar um relatório paginado do Power BI ou exportar dados).

Contudo, de forma notável, uma consulta de modelo semântico volta ao modo DirectQuery quando inclui qualquer tabela que imponha Segurança em Nível de Linha (RLS) no endpoint de análise SQL. Portanto, o modelo semântico pode optar por não armazenar dados em cache na memória para alcançar consultas de alto desempenho.

Regras em ambas as camadas

As regras de acesso a dados podem ser impostas em ambas as camadas. No entanto, essa abordagem envolve complexidade extra e sobrecarga de gerenciamento. Nesse caso, é recomendável que a conexão de nuvem use uma identidade fixa em vez de SSO.

Comparação de opções de regra de acesso a dados

A tabela a seguir compara as opções de configuração de acesso a dados.

Aplicar regras de acesso a dados Comment
Somente modelo semântico Use essa opção quando os usuários não tiverem permissões de item para consultar o lakehouse ou o warehouse. Configure a conexão de nuvem para usar uma identidade fixa. Um alto desempenho de consultas pode ser alcançado através do cache na memória.
Somente ponto de extremidade de análise SQL Use essa opção quando os usuários precisarem acessar dados do warehouse ou do modelo semântico e com regras consistentes de acesso a dados. Verifique se o SSO está habilitado para a conexão de nuvem. O desempenho da consulta pode ser lento.
Lakehouse ou warehouse e modelo semântico Essa opção envolve sobrecarga extra de gerenciamento. Configure a conexão de nuvem para usar uma identidade fixa.

Aqui estão as práticas recomendadas relacionadas à imposição de regras de acesso a dados:

  • Se usuários diferentes precisarem ser restritos a subconjuntos de dados, sempre que viável, imponha RLS somente na camada de modelo semântico. Dessa forma, os usuários se beneficiam de consultas na memória de alto desempenho. Nesse caso, é altamente recomendável que a conexão de nuvem use uma identidade fixa em vez de SSO.
  • Se possível, evite impor OLS e CLS em ambas as camadas porque isso resulta em erros nas visualizações de relatórios. Erros podem causar 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).

Suporte para gravação de modelo usando o endpoint XMLA

Os modelos semânticos do Direct Lake dão suporte a operações de gravação com o ponto de extremidade XMLA usando ferramentas como SSMS (19.1 ou posterior) e ferramentas de comunidade de software livre.

Tip

Para obter mais informações sobre o uso de ferramentas de terceiros para desenvolver, gerenciar ou otimizar modelos semânticos, consulte o cenário de uso de gerenciamento de modelo de dados avançado .

Antes de poder executar operações de gravação, a opção de leitura e gravação XMLA deve ser habilitada para a capacidade. Para obter mais informações, veja Habilitar leitura-escrita XMLA.

Operações de gravação de modelo com suporte ao ponto de extremidade XMLA:

  • Personalizando, mesclando, escrevendo script, depurando e testando os metadados de modelo do Direct Lake.
  • Controle de origem e versão, integração contínua e implantação contínua (CI/CD) com o Azure DevOps e o GitHub. Para obter mais informações, consulte Gerenciamento do ciclo de vida de conteúdo.
  • Tarefas de automação, como atualização semântica de modelo, e a aplicação de alterações em modelos semânticos do Direct Lake usando o PowerShell e as APIs REST.

Ao alterar um modelo semântico usando XMLA, você deve atualizar a coleção ChangedProperties e PBI_RemovedChildren para que o objeto alterado inclua quaisquer propriedades modificadas ou removidas. Se você não executar essa atualização, as ferramentas de modelagem do Power BI poderão substituir as alterações na próxima vez que o esquema for sincronizado com o Lakehouse.

Saiba mais sobre marcas de linhagem de objeto de modelo semântico no artigo de marcas de linhagem para modelos semânticos do Power BI .

Important

As tabelas direct lake criadas usando aplicativos XMLA estarão inicialmente em um estado não processado até que o aplicativo envie um comando de atualização. As consultas que envolvem tabelas não processadas sempre retornarão ao modo DirectQuery. Portanto, ao criar um novo modelo semântico, atualize o modelo para processar suas tabelas.

Para obter mais informações, consulte conectividade do modelo semântico com o ponto de acesso XMLA.

Metadados de modelo do Direct Lake

Quando você se conecta a um modelo semântico do Direct Lake com o ponto de extremidade XMLA, os metadados se parecem com os de qualquer outro modelo. No entanto, os modelos do Direct Lake mostram as seguintes diferenças:

  • A propriedade compatibilityLevel do objeto de banco de dados é 1604 (ou superior).
  • A propriedade de modo das partições do Direct Lake é definida como directLake.
  • As partições do Direct Lake usam expressões compartilhadas para definir fontes de dados. A expressão aponta para o ponto de extremidade de análise SQL do lakehouse ou warehouse. Direct Lake usa o endpoint de análise SQL para descobrir informações de esquema e segurança, mas carrega os dados diretamente do OneLake (a menos que volte para o modo DirectQuery por qualquer motivo).

Post-publication tasks

Depois de publicar um modelo semântico do Direct Lake, você deve concluir algumas tarefas de instalação. Para obter mais informações, consulte Gerenciar modelos semânticos do Direct Lake.

Related content

  • Last updated on