Compartilhar via

Desenvolver modelos semânticos Direct Lake

  • Artigo

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

Criar o modelo

Use o portal Fabric para criar um modelo semântico do Direct Lake em um espaço de trabalho. É um processo simples que envolve selecionar quais tabelas de um único lakehouse ou warehouse adicionar ao modelo semântico.

Você pode então usar a experiência de modelagem web para desenvolver ainda mais o modelo semântico. Essa experiência permite que você crie relacionamentos entre tabelas, crie medidas e grupos de cálculos, marque tabelas de datas e defina 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 do Microsoft Entra ou grupos de segurança) 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 comunitárias de código aberto. Para obter mais informações, veja Suporte à gravação de modelo com o ponto de extremidade XMLA mais adiante neste artigo.

Dica

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

Tabelas de modelos

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. Isso ocorre porque as consultas a uma tabela de modelo com base em uma 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 filtragem, agrupamento, classificação e resumo, além de colunas que suportem relacionamentos de modelo. Embora 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.

Aviso

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

Para saber como selecionar quais tabelas incluir no seu modelo semântico do Direct Lake, veja 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, veja Entender o armazenamento para modelos semânticos do Direct Lake.

Aplicar regras de acesso a dados

Quando você tem requisitos para entregar subconjuntos de dados de modelo para diferentes usuários, você pode impor regras de acesso a dados. Você aplica regras configurando a segurança em nível de objeto (OLS) e/ou a 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, à definição de permissões para consumidores de conteúdo, criadores e usuários que gerenciarão o modelo semântico (e itens do Fabric relacionados). Para obter mais informações sobre como definir permissões, veja Gerenciar modelos semânticos do Direct Lake.

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

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 às tabelas ou colunas do modelo. Você precisa usar ferramentas comunitárias de código aberto, como o Tabular Editor, para configurar o OLS.

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

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

Para um ponto de extremidade de análise SQL, você pode configurar RLS para controlar o acesso às 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 RLS para controlar o acesso às linhas nas tabelas do 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 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 qualquer coluna restrita pelo CLS do ponto de extremidade de análise SQL (ou a tabela for negada), um resultado de erro será retornado (o visual do relatório não será renderizado).
    1. Se a conexão com a nuvem usar SSO (padrão), o CLS será determinado pelo nível de acesso do consumidor do relatório.
    2. Se a conexão com a nuvem usar uma identidade fixa, o 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 SQL que imponha RLS ou uma exibição for usada, a consulta retornará ao modo DirectQuery.
    1. Se a conexão com a nuvem usar SSO (padrão), o RLS será determinado pelo nível de acesso do consumidor do relatório.
    2. Se a conexão com a nuvem usar uma identidade fixa, o RLS será determinado pelo nível de acesso da identidade fixa.
  4. Se a consulta exceder os limites de capacidade, ela retornará ao modo DirectQuery.
  5. Caso contrário, a consulta será atendida a partir do cache na memória. Os dados da coluna são carregados na memória conforme e quando necessário.

Permissões de itens de origem

A conta usada para acessar os dados é uma das seguintes.

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

A conta deve 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 do espaço de trabalho ou atribuídas explicitamente para o item, conforme descrito nesse 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 colunas na memória) e as regras de acesso a dados podem ser aplicadas.

Opções de regras 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, faça isso no modelo semântico sempre que possível. Isso ocorre porque o RLS imposto pelo modelo semântico é obtido pela filtragem do 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 com a nuvem use uma identidade fixa em vez de SSO. O SSO implicaria que os usuários finais podem acessar o ponto de extremidade de análise SQL diretamente e, portanto, podem ignorar as regras de segurança no modelo semântico.

Importante

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

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 Gravação no modelo semântico. Por outro lado, as regras de acesso a dados se aplicam a usuários atribuídos à função Visualizador espaço de trabalho. No entanto, os usuários atribuídos à função de espaço de trabalho Administrador, Membro ou Colaborador têm implicitamente permissão de Gravação no modelo semântico e, portanto, as regras de acesso a dados não são aplicadas. Para obter mais informações, veja 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 de extremidade de análise SQL quando o modelo semântico conexão de nuvem usa logon único (SSO). 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 consultarem o ponto de extremidade de análise SQL diretamente para outras cargas de trabalho (por exemplo, para criar um relatório paginado do Power BI ou exportar dados).

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

Regras em ambas as camadas

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

Comparação de opções de regras 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 para Comentário
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 com a nuvem para usar uma identidade fixa. Alto desempenho de consulta pode ser obtido 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 warehouse ou do modelo semântico e com regras consistentes de acesso a dados. Certifique-se de que o SSO esteja habilitado para a conexão com a nuvem. O desempenho da consulta pode ser lento.
Lakehouse ou warehouse e modelo semântico Essa opção envolve uma sobrecarga de gerenciamento extra. Configure a conexão com a 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 precisarem ser restritos a subconjuntos de dados, sempre que viável, aplique RLS somente na camada do modelo semântico. Dessa forma, os usuários se beneficiarão de consultas de alto desempenho na memória. Nesse caso, é altamente recomendável que a conexão com a nuvem use uma identidade fixa em vez de SSO.
  • Se possível, evite impor OLS e CLS em qualquer camada, pois isso resulta em erros nos visuais do relatório. Erros podem causar confusão ou preocupação aos usuários. Para colunas sumarizáveis, considere criar 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 do Direct Lake oferecem suporte a operações de gravação com o ponto de extremidade XMLA usando ferramentas como SSMS (19.1 ou posterior) e ferramentas comunitárias de código aberto.

Dica

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

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 e gravação de XMLA.

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

  • Personalizando, mesclando, scripts, depurando e testando 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, veja 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 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 do objeto alterado para incluir 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.

Os modelos suportados para alterar um modelo semântico usando XMLA são os seguintes:

  • Renomear tabela/coluna ( ChangeProperty = nome)
  • Remover tabela (adicionar tabela à anotação PBI_RemovedChildren na expressão de consulta)

Importante

As tabelas do Direct Lake criadas usando aplicativos XMLA ficarão inicialmente em um estado não processado até que o aplicativo envie um comando de atualização. Consultas que envolvem tabelas não processadas sempre retornarão ao modo DirectQuery. Portanto, ao criar um novo modelo semântico, certifique-se de atualizar o modelo para processar suas tabelas.

Para obter mais informações, veja Conectividade do modelo semântico com o ponto de extremidade 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 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. 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 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 sem suporte

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

  • Tabelas calculadas referenciando tabelas ou colunas no modo de armazenamento Direct Lake
  • Colunas calculadas que fazem referência a tabelas ou colunas no modo de armazenamento Direct Lake
  • Tabelas híbridas
  • Agregações definidas pelo usuário
  • Modelos compostos, nos quais você não pode 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 dinâmica com um modelo semântico do Direct Lake e, em seguida, estendê-lo com novas medidas e, a partir daí, clicar na opção para fazer alterações nesse modelo para adicionar novas tabelas (usando o modo Importar, DirectQuery ou Armazenamento duplo). Essa ação cria uma conexão DirectQuery com o modelo semântico no modo Direct Lake, de modo que as tabelas são exibidas como modo de armazenamento DirectQuery, mas esse modo de armazenamento não indica fallback 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 endpoint de análise SQL que aplicam mascaramento de dados dinâmico.

Conteúdo relacionado