Desenvolver modelos semânticos Direct Lake

  • Artigo

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

Criar o modelo

Use o portal Fabric para criar um modelo semântico Direct Lake em um espaço de trabalho. É um processo simples que envolve a seleção de quais tabelas de uma única casa de lago ou armazém adicionar ao modelo semântico.

Em seguida, podes usar a experiência web de modelagem para desenvolver ainda mais o modelo semântico. Essa experiência permite criar relações entre tabelas, criar medidas e grupos de cálculo, marcar tabelas de data e definir propriedades para o modelo e seus objetos (como formatos de coluna). Você também pode configurar o modelo de segurança em nível de linha (RLS) definindo funções e regras e adicionando membros (contas de usuário ou grupos de segurança do Microsoft Entra) a essas funções.

Como alternativa, você pode continuar o desenvolvimento do seu modelo usando uma ferramenta compatível com XMLA, como o SQL Server Management Studio (SSMS) (versão 19.1 ou posterior) ou ferramentas de comunidade de código aberto. Para obter mais informações, consulte Suporte de gravação de modelo com o ponto de extremidade XMLA mais adiante neste artigo.

Dica

Você pode aprender a criar uma casa de lago, uma tabela Delta e um modelo semântico básico de Lago Direto completando este tutorial.

Tabelas modelo

As tabelas de modelo baseiam-se numa tabela ou numa vista do endpoint SQL de análise. No entanto, evite usar visualizações se possível. Isso ocorre porque as consultas a uma tabela de modelo com base em um modo de exibição sempre retornarão ao modo DirectQuery, o que pode resultar em um desempenho de consulta mais lento.

As tabelas devem incluir colunas para filtrar, agrupar, classificar e resumir, além de colunas que oferecem suporte a relações de modelo. Embora as colunas desnecessárias não afetem o desempenho da consulta do modelo semântico (porque não serão carregadas na memória), elas resultam em um tamanho de armazenamento maior no OneLake e exigem mais recursos de computação para carregar e manter.

Advertência

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

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 modelos semânticos, consulte Compreender o armazenamento para modelos semânticos Direct Lake.

Aplicar regras de acesso a dados

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

Observação

O tópico de aplicação de regras de acesso a dados é diferente, mas relacionado ao estabelecimento de permissões para consumidores, criadores e utilizadores de conteúdo que gerenciarão o modelo semântico (e itens de malha relacionados). Para obter mais informações sobre como definir permissões, consulte Gerenciar modelos semânticos Direct Lake.

Segurança em nível de objeto (OLS)

O OLS envolve a restrição de 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 a partir da tabela Employee.

Para um ponto de extremidade de análise SQL, você pode configurar o OLS para controlar o acesso aos objetos de ponto de extremidade, como tabelas ou exibições, e a segurança em nível de coluna (CLS) para controlar o acesso às colunas da tabela de 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 comunidade de código aberto, como o Editor de Tabelas, para configurar o OLS.

Segurança a nível de linha (RLS)

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

Para um ponto de extremidade de análise SQL, você pode configurar a RLS para controlar o acesso a linhas em uma tabela de ponto de extremidade.

Importante

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

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

Como as consultas são avaliadas

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

As etapas a seguir aproximam 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 (o visual do relatório não será renderizado).
  2. Se a consulta contiver alguma coluna restrita pelo ponto de extremidade de análise SQL CLS (ou se a tabela for negada), será retornado um erro (a representação visual do relatório falhará ao ser renderizada).
    1. Se a conexão de nuvem usar SSO (padrão), o CLS será determinado pelo nível de acesso do consumidor do relatório.
    2. Se a conexão de nuvem usa uma identidade fixa, o CLS é determinado pelo nível de acesso da identidade fixa.
  3. Se a consulta contiver qualquer tabela no ponto de extremidade de análise SQL que imponha RLS ou se um modo de exibição for usado, a consulta retornará ao modo DirectQuery.
    1. Se a conexão na nuvem usar SSO (padrão), a RLS será determinada pelo nível de acesso do consumidor do relatório.
    2. Se a conexão de nuvem usa uma identidade fixa, a RLS é determinada pelo nível de acesso da identidade fixa.
  4. Se a consulta exceder as restrições da capacidade, ele voltará ao modo DirectQuery.
  5. Caso contrário, a consulta será atendida a partir do cache em memória. Os dados da coluna são carregados na memória à medida que são necessários.

Permissões de item de origem

A conta usada para acessar dados é uma das seguintes.

  • Se a conexão de nuvem usa SSO (padrão), é o consumidor do relatório.
  • Se a conexão de nuvem usa uma identidade fixa, é a identidade fixa.

A conta deve ter pelo menos permissões de leitura e de ler dados no item de origem (lakehouse ou warehouse). As permissões de item podem ser herdadas de funções de espaço de trabalho ou atribuídas explicitamente para o item, conforme descrito em este 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:

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

Regras no modelo semântico

Se tiver de impor regras de acesso a dados, deve fazê-lo no modelo semântico sempre que possível. Isso porque a RLS imposta pelo modelo semântico é obtida filtrando o cache de dados na memória para obter consultas de alto desempenho.

Também é uma abordagem adequada quando os consumidores de relatório não recebem permissão para consultar a casa do lago ou o armazém.

Em ambos os casos, é altamente recomendável que a conexão com a nuvem use uma identidade fixa em vez de SSO. O SSO implicaria que os utilizadores finais podem aceder diretamente ao ponto final de análise SQL e, consequentemente, podem ignorar as regras de segurança no modelo semântico.

Importante

As permissões de item de modelo semântico podem ser definidas explicitamente por meio de aplicativos Power BIou adquiridas implicitamente por meio de funções de espaço de trabalho.

Notavelmente, as regras de acesso a dados do modelo semântico não são impostas para usuários que permissão Gravar no modelo semântico. Por outro lado, as regras de acesso a dados aplicam-se aos utilizadores que são atribuídos à função Viewer do espaço de trabalho. No entanto, os usuários atribuídos ao de Administrador do, Membro ou função de espaço de trabalho de Colaborador têm implicitamente permissão Gravar 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 endpoint de análises SQL

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

No entanto, uma consulta de modelo semântico retornará ao modo DirectQuery quando incluir qualquer tabela que aplique RLS no endpoint de análise SQL. Consequentemente, o modelo semântico pode nunca armazenar dados em cache na memória para realizar consultas com alto desempenho.

Regras em ambas as camadas

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

Comparação das opções de regras de acesso a dados

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

Aplicar as regras de acesso aos dados Comentar
Apenas modelo semântico Use esta opção quando os utilizadores não tiverem permissões de item para consultar o Lakehouse ou o armazém. Configure a conexão de nuvem para usar uma identidade fixa. O alto desempenho de consulta pode ser alcançado a partir 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 depósito 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 armazém e modelo semântico Esta opção envolve despesas gerais de gestão adicionais. Configure a conexão de nuvem para usar uma identidade fixa.

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

  • Se diferentes usuários tiverem que ser restritos a subconjuntos de dados, sempre que viável, aplique 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. Nesse caso, é altamente recomendável que a conexão na nuvem use uma identidade fixa em vez de SSO.
  • Se possível, evite impor OLS e CLS em nenhuma camada, pois isso resulta em erros nos gráficos do relatório. Os erros podem gerar 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).

Suporte de gravação de modelo com o ponto de extremidade XMLA

Os modelos semânticos Direct Lake suportam operações de escrita através do ponto de extremidade XMLA, utilizando ferramentas como o SSMS (versão 19.1 ou posterior) e ferramentas de comunidade de código aberto.

Dica

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

Antes de poder executar operações de gravação, a opção XMLA de leitura/escrita deve estar ativada para a capacidade. Para obter mais informações, consulte Ativar a leitura-escrita de XMLA.

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

  • Personalização, mesclagem, criação de scripts, depuração e teste de 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 do conteúdo.
  • Tarefas de automação como atualização de modelo semântico e aplicação de alterações a modelos semânticos Direct Lake usando o PowerShell e as APIs REST.

Ao alterar um modelo semântico usando XMLA, você deve atualizar o ChangedProperties e PBI_RemovedChildren coleção 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 quaisquer alterações na próxima vez que o esquema for sincronizado com o Lakehouse.

Saiba mais sobre etiquetas de linhagem de objetos de modelos semânticos no artigo etiquetas de linhagem para modelos semânticos do Power BI.

Importante

As tabelas Direct Lake criadas usando aplicativos XMLA estarão inicialmente em um estado não processado até que o aplicativo envie um comando refresh. 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 endpoint XMLA.

Metadados do modelo Direct Lake

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

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

Tarefas pós-publicação

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

Recursos não suportados

Os seguintes recursos de modelo não são suportados pelos modelos semânticos do Direct Lake:

  • Tabelas calculadas fazendo referência a tabelas ou colunas no modo de armazenamento Direct Lake
  • Colunas calculadas fazendo referência a tabelas ou colunas no modo de armazenamento Direct Lake
  • Tabelas híbridas
  • Agregações definidas pelo usuário
  • Modelos compostos, em que não é possível combinar tabelas de modo de armazenamento Direct Lake com tabelas de modo de armazenamento DirectQuery ou Dual no mesmo modelo. No entanto, você pode usar o Power BI Desktop para criar uma conexão em tempo real com um modelo semântico Direct Lake e, em seguida, estendê-lo com novas medidas e, a partir daí, clicar na opção para fazer alterações nesse modelo adicionar novas tabelas (usando o modo de armazenamento Import, DirectQuery ou Dual). Essa ação cria uma conexão DirectQuery com o modelo semântico no modo Direct Lake, de forma que as tabelas sejam exibidas como armazenamento DirectQuery. No entanto, este modo de armazenamento não indica uma alternativa para DirectQuery. Somente a conexão entre esse novo modelo e o modelo Direct Lake é o DirectQuery e as consultas ainda utilizam o Direct Lake para obter dados do OneLake. Para obter mais informações, consulte Criar um modelo composto em um modelo semântico.
  • Colunas baseadas em colunas de ponto de extremidade de análise SQL que aplicam mascaramento dinâmico de dados.

Conteúdo relacionado