Compartilhar via

Visão geral do Direct Lake

O Direct Lake é uma opção de modo de armazenamento para tabelas em um modelo semântico do Power BI armazenado em um workspace do Microsoft Fabric. Ele é otimizado para grandes volumes de dados que podem ser carregados rapidamente na memória de tabelas Delta armazenadas no OneLake , o único repositório para todos os dados de análise. Depois de carregado na memória, o modelo semântico permite uma análise interativa de alto desempenho.

Diagrama mostra um modelo semântico do Direct Lake e como ele se conecta às tabelas Delta no OneLake, conforme descrito nos parágrafos anteriores.

O Direct Lake é ideal para modelos semânticos que se conectam a grandes lakehouses, armazéns e outras fontes do Fabric com tabelas Delta, especialmente quando a replicação de todo o volume de dados em um modelo de Importação é desafiadora ou impossível. As consultas do Direct Lake são, como o modo de importação, processadas pelo mecanismo de consulta VertiPaq, enquanto o DirectQuery federa consultas à fonte de dados subjacente. Isso significa que as consultas do Direct Lake, como o modo de importação, normalmente superam o DirectQuery.

No entanto, um Direct Lake difere de um modo de importação de uma maneira importante: uma operação de atualização para um modelo semântico do Direct Lake é conceitualmente diferente de uma operação de atualização para um modelo semântico de importação. O modo de importação replica os dados e cria uma cópia inteira armazenada em cache dos dados para o modelo semântico, enquanto uma atualização do Direct Lake copia apenas metadados (conhecidos como enquadramento, descritos posteriormente neste artigo), o que pode levar alguns segundos para ser concluído. A atualização do Direct Lake é uma operação de baixo custo que analisa os metadados da versão mais recente das tabelas Delta e é atualizada para referenciar os arquivos mais recentes no OneLake. Por outro lado, uma atualização de importação produz uma cópia dos dados, o que pode levar um tempo considerável e consumir recursos significativos de fonte de dados e capacidade (memória e CPU). O Direct Lake move a preparação de dados para o OneLake e, ao fazer isso, usa toda a amplitude das tecnologias do Fabric para preparação de dados, incluindo trabalhos do Spark, instruções DML T-SQL, fluxos de dados, pipelines e muito mais.

O modo de armazenamento Direct Lake oferece os seguintes principais benefícios:

  • Semelhante ao modo de importação, as consultas do Direct Lake são processadas pelo mecanismo VertiPaq e, portanto, fornecem desempenho de consulta comparável ao modo de importação sem a sobrecarga de gerenciamento dos ciclos de atualização de dados para carregar todo o volume de dados.
  • Usa os investimentos existentes do Fabric integrando-se perfeitamente com grandes lakehouses, armazéns e outras fontes do Fabric com tabelas Delta. Por exemplo, Direct Lake é uma opção ideal para a camada de análise de ouro na arquitetura medalhão lakehouse.
  • Maximiza o ROI (Retorno sobre o Investimento) porque os volumes de dados analisados podem exceder os limites máximos de memória da capacidade, pois apenas os dados necessários para responder a uma consulta são carregados na memória.
  • Minimiza as latências de dados sincronizando rapidamente e automaticamente um modelo semântico com suas fontes, disponibilizando novos dados para usuários empresariais sem agendamentos de atualização.

Quando você deve usar o modo de armazenamento do Direct Lake?

O principal caso de uso para o modo de armazenamento do Direct Lake normalmente é para projetos de análise orientados por TI que usam arquiteturas centradas no lago. Nesses cenários, você tem ou espera acumular grandes volumes de dados no OneLake. O carregamento rápido desses dados na memória, as operações de atualização frequentes e rápidas, o uso eficiente dos recursos de capacidade e o desempenho rápido da consulta são importantes para esse caso de uso.

Nota

Os modelos semânticos de Importação e DirectQuery ainda são relevantes no Fabric e são a escolha certa do modelo semântico para alguns cenários. Por exemplo, o modo de importação de armazenamento geralmente funciona bem para um analista de autoatendimento que precisa de liberdade e agilidade para agir rapidamente e sem dependência de TI para adicionar novos elementos de dados.

Além disso, a integração do OneLake grava automaticamente dados para tabelas no modo de armazenamento de importação em tabelas Delta no OneLake sem envolver nenhum esforço de migração, o que permite perceber muitos dos benefícios do Fabric que são disponibilizados para importar usuários de modelo semântico, como integração com lakehouses por meio de atalhos, consultas SQL, notebooks e muito mais. Recomendamos essa opção como uma maneira rápida de colher os benefícios do Fabric sem necessariamente ou imediatamente reformar seu armazém de dados existente e/ou sistema de análise.

O Direct Lake depende da preparação de dados que está sendo feita no data lake. A preparação de dados pode ser feita usando várias ferramentas, como trabalhos do Spark para lakehouses do Fabric, instruções DML T-SQL para warehouses do Fabric, fluxos de dados, pipelines e outros, o que ajuda a garantir que a lógica de preparação de dados seja executada upstream na arquitetura para maximizar a reutilização. No entanto, se o autor do modelo semântico não tiver a capacidade de modificar o item de origem, por exemplo, se um analista de autoatendimento não tiver permissões de gravação em um lakehouse gerenciado por TI, aumentar o modelo com tabelas de modo de armazenamento de importação poderá ser uma boa opção, já que o modo de importação dá suporte à preparação de dados usando o Power Query, que é definido como parte do modelo semântico.

Considere sua licença de capacidade do Fabric atual e os verificadores de integridade da capacidade do Fabric ao considerar o modo de armazenamento do Direct Lake. Além disso, considere as considerações e limitações , que são descritas posteriormente neste artigo.

Dica

Recomendamos que você produza um protótipo — ou poc (prova de conceito)— para determinar se um modelo semântico do Direct Lake é a solução certa e reduzir o risco.

Conceitos-chave e terminologia

Este guia presume familiaridade com os seguintes conceitos:

  • Os usuários interagem com visuais em relatórios do Power BI, que geram consultas DAX para o modelo semântico.
  • Modo de armazenamento: o modelo semântico processa as consultas DAX de forma diferente, dependendo do modo de armazenamento empregado. Por exemplo:
    • Os modos de Importação e Armazenamento Direct Lake usam o motor VertiPaq para processar consultas DAX e retornar resultados para o relatório e o usuário do Power BI.
    • O DirectQuery, por outro lado, converte consultas DAX para a sintaxe de consulta da fonte de dados (normalmente uma forma de SQL) e as federa para o banco de dados subjacente. Os processadores de consulta de banco de dados de origem geralmente não são voltados para consultas agregadas, estilo BI e, portanto, resultam em desempenho mais lento e interatividade reduzida do usuário em comparação com os modos Importar e Direct Lake.

O modo de armazenamento é uma propriedade de uma tabela no modelo semântico. Quando um modelo semântico inclui tabelas com modos de armazenamento diferentes, ele é conhecido como um modelo composto. Para obter mais informações sobre modos de armazenamento, consulte modos de modelo semântico no serviço do Power BI.

  • O modo Direct Lake pode usar dois métodos de acesso diferentes:

    • O Direct Lake no OneLake não depende de pontos de extremidade SQL e pode usar dados de qualquer fonte de dados do Fabric com tabelas Delta. Direct Lake no OneLake não volta para o modo DirectQuery.

    Nota

    Direct Lake no OneLake está atualmente em versão prévia pública.

    • O Direct Lake nos pontos de extremidade SQL usa o ponto de extremidade SQL de um lakehouse ou warehouse do Fabric para verificações de permissão e descoberta de tabela Delta. O Direct Lake em pontos de extremidade SQL pode voltar ao modo DirectQuery quando não pode carregar os dados diretamente de uma tabela Delta, como quando a fonte de dados é uma exibição SQL ou quando o Warehouse usa a RLS (segurança em nível de linha) baseada em SQL. O Direct Lake em pontos de extremidade SQL geralmente está disponível e tem suporte total na produção.

Comparação de modos de armazenamento

A tabela a seguir compara o modo de armazenamento Direct Lake com os modos de armazenamento Import e DirectQuery.

Capacidade Direct Lake no OneLake Direct Lake em pontos de extremidade SQL Importação DirectQuery
Licenciamento Somente assinatura de capacidade do Fabric (SKUs) Somente assinatura de capacidade do Fabric (SKUs) Qualquer licença do Fabric ou do Power BI (incluindo licenças do Microsoft Fabric Free) Qualquer licença do Fabric ou do Power BI (incluindo licenças do Microsoft Fabric Free)
Fonte de dados Tabelas de qualquer fonte de dados do Fabric apoiadas por tabelas Delta Somente tabelas (ou exibições) de lakehouse ou warehouse Qualquer conector Qualquer conector que dê suporte ao modo DirectQuery
Conectar-se a exibições do ponto de extremidade de análise de SQL Não Sim – mas retornará automaticamente ao modo DirectQuery Sim Sim
Modelos compostos Não 1 Não 1 Sim – pode combinar com tabelas do modo de armazenamento DirectQuery ou Dual Sim – pode combinar com tabelas de modo de importação ou de armazenamento duplo
SSO (logon único) Sim Sim Não aplicável Sim
Tabelas calculadas Sim – mas os cálculos não podem se referir a colunas de tabelas no modo Direct Lake. Não – exceto grupos de cálculo, parâmetros de hipótesese parâmetros de campo, que criam implicitamente tabelas calculadas Sim Não – tabelas calculadas usam o modo de armazenamento de importação mesmo quando se referem a outras tabelas no modo DirectQuery
Colunas calculadas Sim – mas os cálculos não podem se referir a colunas de tabelas no modo Direct Lake. Não Sim Sim
Tabelas híbridas Não Não Sim Sim
Modelar partições de tabela Não – no entanto, o particionamento pode ser feito no nível da tabela Delta Não – no entanto, o particionamento pode ser feito no nível da tabela Delta Sim – criado automaticamente pela atualização incremental ou criado manualmente usando o ponto de extremidade XMLA Não
Agregações definidas pelo usuário Não Não Sim – Há suporte para importar tabelas de agregação em tabelas DirectQuery Sim
Segurança em nível de objeto ou segurança em nível de coluna do ponto de extremidade de análise SQL Não Sim – mas pode produzir erros quando a permissão é negada Sim – mas deve duplicar permissões com a segurança em nível de objeto do modelo semântico Sim – mas as consultas podem produzir erros quando a permissão é negada
RLS (segurança em nível de linha) do ponto de extremidade da análise SQL Não Sim – mas as consultas retornarão ao modo DirectQuery Sim – mas deve duplicar permissões com o modelo semântico RLS Sim
RLS (segurança em nível de linha) do modelo semântico Sim – mas é altamente recomendável usar uma conexão de nuvem com identidade fixa. Sim – mas é altamente recomendável usar uma conexão de nuvem com identidade fixa. Sim Sim
OLS (segurança no nível do objeto) do modelo semântico Sim Sim Sim Sim
Volumes de dados grandes sem requisito de atualização Sim Sim Não Sim
Reduzir a latência de dados Sim – quando as atualizações automáticas estão habilitadas ou o reframamento programático Sim – quando as atualizações automáticas estão habilitadas ou o reframamento programático Não Sim
Power BI Embedded Sim 2 Sim 2 Sim Sim

1 Ao usar o Direct Lake em pontos de extremidade SQL, não é possível combinar tabelas de modo de armazenamento Direct Lake com tabelas do modo de armazenamento DirectQuery ou Dual no mesmo modelo semântico. No entanto, você pode usar o Power BI Desktop para criar um modelo composto em um modelo semântico do Direct Lake e, em seguida, estendê-lo com novas tabelas (usando o modo de importação, DirectQuery ou armazenamento duplo) ou cálculos. Para obter mais informações, consulte Criar um modelo composto em um modelo semântico.

2 requer um token de inserção V2. Se você estiver usando uma entidade de serviço, deverá usar uma conexão de nuvem com identidade fixa.

Como funciona o Direct Lake

Normalmente, as consultas enviadas para um modelo semântico do Direct Lake são processadas em um cache na memória das colunas originadas de tabelas Delta. O armazenamento de base de uma tabela Delta consiste em um ou mais arquivos Parquet no OneLake. Os arquivos Parquet organizam dados por colunas em vez de linhas. Os modelos semânticos carregam colunas inteiras de tabelas Delta na memória, pois elas são exigidas por consultas.

O Direct Lake no OneLake não está associado ao ponto de extremidade do SQL, oferecendo uma integração mais rigorosa com recursos do OneLake, como segurança do OneLake e planos de consulta DAX mais eficientes porque, por exemplo, não é necessário verificar a segurança baseada em SQL. O fallback do DirectQuery não é suportado pelo Direct Lake no OneLake.

Com o Direct Lake em pontos de extremidade SQL, uma consulta DAX pode usar o fallback do DirectQuery, que envolve alternar perfeitamente para o modo DirectQuery. O fallback do DirectQuery recupera dados diretamente do ponto de extremidade de análise de SQL do lakehouse ou do warehouse. Por exemplo, o fallback ocorre quando a segurança baseada em SQL é detectada no ponto de extremidade SQL. Nesse caso, uma operação de DirectQuery envia uma consulta para o endpoint de análise do SQL. Operações de fallback podem resultar em um desempenho de consulta mais lento.

As seções a seguir descrevem os conceitos e recursos do Direct Lake, incluindo carregamento de colunas, enquadramento, atualizações automáticas e fallback do DirectQuery.

Carregamento de coluna (transcodificação)

Os modelos semânticos do Direct Lake só carregam dados do OneLake como e quando as colunas são consultadas pela primeira vez. O processo de carregamento de dados sob demanda do OneLake é conhecido como transcodificação.

Quando o modelo semântico recebe uma consulta DAX (ou Expressões Multidimensionais – MDX), ele primeiro determina quais colunas são necessárias para produzir um resultado de consulta. Qualquer coluna usada diretamente pela consulta é necessária e também colunas exigidas por relações e medidas. Normalmente, o número de colunas necessárias para produzir um resultado de consulta é significativamente menor do que o número de colunas definidas no modelo semântico.

Depois de entender quais colunas são necessárias, o modelo semântico determina quais colunas já estão na memória. Se as colunas necessárias para a consulta não estiverem na memória, o modelo semântico carregará todos os dados dessas colunas do OneLake. O carregamento de dados de coluna normalmente é uma operação rápida, no entanto, pode depender de fatores como a cardinalidade dos dados armazenados nas colunas.

As colunas carregadas na memória são residentes na memória. Consultas futuras que envolvem apenas colunas residentes não precisam carregar mais colunas na memória.

Uma coluna permanece residente até que haja motivo para ela ser removida da memória. Os motivos pelos quais as colunas podem ser removidas incluem:

  • O modelo ou tabela foi atualizada após uma atualização da tabela Delta na origem (consulte Enquadramento na próxima seção).
  • Nenhuma consulta usou a coluna por algum tempo.
  • Outros motivos de gerenciamento de memória, incluindo a pressão de memória na capacidade devido a outras operações simultâneas.

Sua escolha de SKU do Fabric determina a memória disponível máxima para cada modelo semântico do Direct Lake na capacidade. Para obter mais informações sobre os verificadores de integridade de recursos e os limites máximos de memória, consulte Verificadores de integridade e limitações de capacidade do Fabric posteriormente neste artigo.

Enquadramento

O enquadramento fornece aos proprietários do modelo controle de ponto temporal sobre quais dados são carregados no modelo semântico. O enquadramento é uma operação do Direct Lake disparada por uma atualização de um modelo semântico e, na maioria dos casos, leva apenas alguns segundos para ser concluída. Isso ocorre porque é uma operação de baixo custo em que o modelo semântico analisa os metadados da versão mais recente das tabelas Delta Lake e se atualiza para referenciar os arquivos Parquet mais recentes no OneLake.

Quando ocorre o enquadramento, os dicionários e os segmentos de colunas de tabelas residentes podem ser removidos da memória se os dados subjacentes são alterados e o ponto no tempo da atualização se torna a nova linha de base para todos os eventos futuros de transcodificação. A partir desse ponto, as consultas do Direct Lake consideram apenas os dados nas tabelas Delta a partir do momento da operação de enquadramento mais recente. Por esse motivo, as tabelas Direct Lake são consultadas para retornar dados com base no estado da tabela Delta no ponto da operação de enquadramento mais recente. Esse momento não representa necessariamente o estado mais recente das tabelas Delta.

O modelo semântico analisa o log Delta de cada tabela Delta durante o enquadramento para descartar apenas os segmentos de coluna afetados e recarregar dados adicionados recentemente durante a transcodificação. Uma otimização importante é que os dicionários geralmente não serão descartados quando o enquadramento incremental entrar em vigor e novos valores forem adicionados aos dicionários existentes. Essa abordagem de enquadramento incremental ajuda a reduzir a carga de recarregamento e beneficia o desempenho da consulta. No caso ideal, quando uma tabela Delta não recebeu atualizações, nenhuma recarga é necessária para colunas já residentes na memória e as consultas mostram muito menos impacto no desempenho após o enquadramento porque o enquadramento incremental essencialmente permite que o modelo semântico atualize partes substanciais dos dados existentes na memória em vigor.

O diagrama a seguir mostra como as operações de enquadramento do Direct Lake funcionam.

Diagrama mostra como as operações de enquadramento do Direct Lake funcionam.

O diagrama representa os seguintes processos e características.

Elemento Descrição
Existe um modelo semântico em um workspace do Fabric.
As operações de enquadramento ocorrem periodicamente e definem a linha de base para todos os eventos de transcodificação futuros. As operações de enquadramento podem ocorrer automaticamente, manualmente, em um horário programado ou programaticamente.
O OneLake armazena metadados e arquivos Parquet, que são representados como tabelas Delta.
A última operação de enquadramento inclui arquivos Parquet relacionados às tabelas Delta e, especificamente, os arquivos Parquet que foram adicionados antes da última operação de enquadramento.
Uma operação de enquadramento posterior inclui arquivos Parquet adicionados após a última operação de enquadramento.
As colunas residentes no modelo semântico do Direct Lake podem ser removidas da memória e o ponto no tempo da atualização se torna a nova linha de base para todos os eventos futuros de transcodificação.
As modificações de dados subsequentes, representadas por novos arquivos Parquet, não ficam visíveis até que a próxima operação de enquadramento ocorra.

Nem sempre é desejável ter dados que representem o estado mais recente de qualquer tabela Delta quando uma operação de transcodificação ocorre. Considere que o enquadramento pode ajudá-lo a fornecer resultados de consulta consistentes em ambientes em que os dados em tabelas Delta são transitórios. Os dados podem ser transitórios por vários motivos, como quando processos de ETL (extração, transformação e carga) de execução longa ocorrem.

A atualização de um modelo semântico do Direct Lake pode ser feita manualmente, automaticamente ou programaticamente. Para obter mais informações, consulte Atualizar modelos semânticos do Direct Lake.

Atualizações automáticas

Há uma configuração semântica no nível do modelo para atualizar automaticamente as 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. Você deve desabilitar as atualizações automáticas quando quiser controlar as alterações de dados ao enquadrar, o que foi explicado na seção anterior. Para obter mais informações, consulte Gerenciar modelos semânticos do Direct Lake.

Dica

Você pode configurar a atualização de página automática em seus relatórios do Power BI. É um recurso que atualiza automaticamente uma página de relatório específica, desde que o relatório se conecte a um modelo semântico do Direct Lake (ou outros tipos de modelo semântico).

Fallback do DirectQuery

Ao usar o Direct Lake em pontos de extremidade SQL, uma consulta enviada para um modelo semântico do Direct Lake pode voltar ao modo DirectQuery, caso em que a tabela não opera mais no modo Direct Lake. Ele recupera dados diretamente do ponto de extremidade de análise de SQL do lakehouse ou warehouse. Essas consultas sempre retornam os dados mais recentes porque não estão restritos ao ponto no tempo da última operação de enquadramento.

Quando ocorre o fallback do DirectQuery, uma consulta não usa mais o modo Direct Lake. Uma consulta não pode aproveitar o modo Direct Lake quando o modelo semântico consulta uma exibição no ponto de extremidade de análise do SQL ou uma tabela no ponto de extremidade de análise do SQL que impõe RLS (segurança em nível de linha). Além disso, uma consulta não pode aproveitar o modo Direct Lake quando uma tabela Delta ultrapassa os limites de capacidade.

Importante

Se possível, você sempre deve projetar sua solução ou dimensionar sua capacidade para evitar o fallback do DirectQuery. Isso porque isso pode resultar em um desempenho de consulta mais lento.

Você pode controlar o fallback dos seus modelos semânticos do Direct Lake definindo a propriedade DirectLakeBehavior. Esta configuração se aplica somente ao Direct Lake em endpoints SQL. O Direct Lake no OneLake não dá suporte ao fallback do DirectQuery. Para obter mais informações, consulte Defina a propriedade de comportamento do Direct Lake.

Permissões de segurança e acesso de dados

Por padrão, o Direct Lake usa o SSO (logon único), o que significa que a identidade que consulta o modelo semântico (geralmente um usuário de relatório) deve ser autorizada a acessar os dados. Como alternativa, você pode associar um modelo do Direct Lake a uma SCC (conexão de nuvem fragmentável) para fornecer uma identidade fixa e desabilitar o SSO. Nesse caso, somente a identidade fixa requer acesso de leitura aos dados na origem.

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 para determinar se a identidade que tenta acessar os dados tem as permissões de acesso a dados necessárias no item de dados de origem e no modelo semântico. As permissões podem ser atribuídas diretamente ou adquiridas implicitamente usando funções de workspace no Microsoft Fabric.

É importante saber que o Direct Lake no OneLake e o Direct Lake nos terminais SQL executam verificações de permissão de forma diferente.

  • O Direct Lake no OneLake requer permissões de Leitura e ReadAll no lakehouse/warehouse para acessar as tabelas Delta.
  • O Direct Lake nos pontos de extremidade SQL requer permissões de Leitura e ReadData no lakehouse/warehouse para acessar dados do ponto de extremidade de análise do SQL.

Nota

O Direct Lake no OneLake requer que os usuários tenham permissão para ler tabelas Delta no OneLake, mas não necessariamente no endpoint SQL. Isso impõe um design de segurança centralizado no qual o OneLake é a única fonte de controle de acesso.

O Direct Lake nos pontos de extremidade SQL, por outro lado, requer que os usuários tenham acesso de leitura ao ponto de extremidade do SQL e não necessariamente às tabelas Delta 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.

Permissões de modelo semântico

Além das permissões de item do Fabric, você também 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órios precisam de permissão Read e os criadores de relatórios precisam de permissão Build adicional. As permissões de modelo semântico podem ser atribuídas diretamente ou adquiridas implicitamente usando funções de 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 .

Requisitos de permissão

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 a permissão de leitura para o modelo semântico.

Se o modelo semântico usar o Direct Lake em pontos de extremidade SQL e a conexão de nuvem usar SSO, conceda pelo menos permissões de Leitura e ReadData para o lakehouse ou warehouse.

Se o modelo semântico usar o Direct Lake no OneLake e a conexão de nuvem usar SSO, conceda pelo menos permissão Read e ReadAll para as tabelas Delta no OneLake.		 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 Compilar para o modelo semântico.

Se o modelo semântico usar o Direct Lake em pontos de extremidade SQL e a conexão de nuvem usar SSO, conceda pelo menos permissões de Leitura e ReadData para o lakehouse ou warehouse.

Se o modelo semântico usar o Direct Lake no OneLake e a conexão de nuvem usar SSO, conceda pelo menos permissão Read e ReadAll para as tabelas Delta no OneLake.		 Para obter mais informações, consulte Estratégia para criadores de conteúdo.
Os usuários podem exibir relatórios, mas são impedidos de consultar o lakehouse, o endpoint de análise SQL ou as tabelas Delta no OneLake. Conceda permissão de leitura para os relatórios e a permissão de leitura para o modelo semântico.

Não conceda aos usuários nenhuma permissão para as tabelas lakehouse, warehouse ou Delta.		 Adequado somente quando o modelo do Direct Lake usa uma identidade fixa por meio de uma conexão de nuvem com o SSO desabilitado.
Gerenciar o modelo semântico, incluindo configurações de atualização Requer a 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.

Requisitos de capacidade têxtil

Os modelos semânticos do Direct Lake exigem uma licença de capacidade do Fabric. Além disso, há limitações e verificadores de integridade de capacidade que se aplicam ao SKU (assinatura de capacidade do Fabric), conforme apresentado na tabela a seguir.

Importante

A primeira coluna na tabela a seguir também inclui SKUs P (assinaturas de capacidade do Power BI Premium). A Microsoft está consolidando opções de compra e desativando os SKUs do Power BI Premium por capacidade. Clientes novos e existentes devem considerar a compra de SKUs F (assinaturas de capacidade do Fabric).

Para obter mais informações, consulte Atualização importante em breve no licenciamento do Power BI Premium e Power BI Premium.

SKU do Fabric Arquivos Parquet por tabela Grupos de linhas por tabela Linhas por tabela (milhões) Tamanho máximo do modelo em disco/OneLake (GB) Memória máxima (GB) 1
F2 1,000 1,000 300 10 3
F4 1,000 1,000 300 10 3
F8 1,000 1,000 300 10 3
F16 1,000 1,000 300 20 5
F32 1,000 1,000 300 40 10
F64/FT1/P1 5.000 5.000 1,500 Ilimitado vinte e cinco
F128/P2 5.000 5.000 3.000 Ilimitado 50
F256/P3 5.000 5.000 6.000 Ilimitado 100
F512/P4 10.000 10.000 12,000 Ilimitado 200
F1024/P5 10.000 10.000 24,000 Ilimitado 400
F2048 10.000 10.000 24,000 Ilimitado 400

1 Para modelos semânticos do Direct Lake, Memória máxima representa o limite de recursos de memória superior para a quantidade de dados que podem ser paginados. Por esse motivo, esse não é um verificador de integridade porque ultrapassá-lo não resulta em um fallback para o modo DirectQuery. No entanto, ele poderá ter um impacto no desempenho se a quantidade de dados for grande o suficiente para causar paginação excessiva dos dados do modelo dos dados do OneLake.

Se ultrapassado, o Tamanho máximo do modelo em disco/OneLake faz com que todas as consultas para o modelo semântico retornem ao modo DirectQuery. Todos os outros verificadores de integridade apresentados na tabela são avaliados por consulta. Portanto, é importante otimizar as tabelas Delta e o modelo semântico do Direct Lake para evitar escalar para um SKU de Fabric mais alto sem necessidade.

Além disso, Unidade de capacidade e Memória máxima por limites de consulta se aplicam a modelos semânticos do Direct Lake. Para saber mais, confira Capacidades e SKUs.

Considerações e limitações

Os modelos semânticos do Direct Lake apresentam algumas considerações e limitações.

Nota

As funcionalidades e os recursos dos modelos semânticos do Direct Lake estão evoluindo rapidamente. Verifique periodicamente para examinar a lista mais recente de considerações e limitações.

Consideração/limitação Direct Lake no OneLake Direct Lake em SQL (endpoint de análise)
Quando o endpoint de análise SQL aplica segurança em nível de linha, as consultas DAX são processadas de forma diferente, dependendo do tipo de modo Direct Lake utilizado.

Quando o Direct Lake no OneLake for empregado, as consultas serão bem-sucedidas e o RLS baseado em SQL não será aplicado. O Direct Lake no OneLake requer que o usuário tenha acesso aos arquivos no OneLake, que não observa o RLS baseado em SQL.		 As consultas serão bem-sucedidas. Sim, a menos que o fallback esteja desabilitado, nesse caso, as consultas falharão.
Se uma tabela no modelo semântico for baseada em uma exibição SQL (não materializada), as consultas DAX serão processadas de forma diferente dependendo do tipo de modo Direct Lake empregado.

Neste caso, o Direct Lake nos pontos de extremidade SQL fará fallback para o DirectQuery.

Não há suporte para criar uma tabela Direct Lake no OneLake com base em uma exibição SQL não materializada. Em vez disso, use uma exibição materializada do lakehouse porque as tabelas Delta são criadas. Como alternativa, use um modo de armazenamento diferente, como "Import" ou DirectLake para tabelas com base em exibições SQL não materializadas.		 Não aplicável Sim, a menos que o fallback esteja desabilitado, nesse caso, as consultas falharão.
Não há suporte para a modelagem composta no momento, o que significa que as tabelas de modelo semântico do Direct Lake não podem ser misturadas com tabelas em outros modos de armazenamento, como Importação, DirectQuery ou Dual (exceto para casos especiais, incluindo grupos de cálculo, parâmetros de hipóteses e parâmetros de campo). Sem suporte Sem suporte
Não há suporte para colunas calculadas e tabelas calculadas que fazem referência a colunas ou tabelas no modo de armazenamento do Direct Lake. Há suporte para grupos de cálculo, parâmetros de teste de hipóteses e parâmetros de campo, que criam implicitamente tabelas calculadas, e para tabelas calculadas que não fazem referência a colunas ou tabelas do Direct Lake. Sem suporte Sem suporte
As tabelas do modo de armazenamento Direct Lake não dão suporte a tipos de coluna de tabela Delta complexos. Tipos semânticos binários e GUID também não têm suporte. Você deve converter esses tipos de dados em cadeias de caracteres ou outros tipos de dados com suporte. Sem suporte Sem suporte
As relações de tabela exigem que os tipos de dados de colunas relacionadas correspondam. Sim Sim
As colunas de relações de um lado devem conter valores exclusivos. As consultas falharão se valores duplicados forem detectados em uma coluna de um lado. Sim Sim
Inteligência de data/hora automática no Power BI Desktop para criar relações usando apenas a parte de data de uma coluna datetime. Observação: há suporte para marcar sua própria tabela de datas como uma tabela de datas e criar relações usando colunas de data. Suportado Sem suporte
O comprimento dos valores de coluna de cadeia de caracteres é limitado a 32.764 caracteres Unicode. Sim Sim
Não há suporte para valores de ponto flutuante não numéricos, como NaN (não um número). Sim Sim
Há suporte para Publicar na Web do Power BI usando uma entidade de serviço apenas ao usar uma identidade fixa para o modelo semântico do Direct Lake. Sim Sim
Na experiência de modelagem da Web , a validação é limitada para modelos semânticos do Direct Lake. As seleções de usuário são consideradas corretas e nenhuma consulta é emitida para validar a cardinalidade ou seleções de filtro cruzado para relações ou para a coluna de data selecionada em uma tabela de data marcada. Sim Sim
No portal do Fabric, a guia Direct Lake no histórico de atualizações lista falhas de atualização relacionadas ao Direct Lake. As operações de atualização (enquadramento) bem-sucedidas normalmente não são listadas, a menos que o status da atualização seja alterado, como nenhuma falha de execução ou atualização anterior para atualizar o êxito ou atualizar o êxito com o aviso. Sim Sim
Seu SKU do Fabric determina a memória máxima disponível para cada modelo semântico do Direct Lake da capacidade. Quando o limite é excedido, as consultas para o modelo semântico podem ser mais lentas devido à paginação excessiva dentro e fora dos dados do modelo. Sim Sim
Não há suporte para a criação de um modelo semântico do Direct Lake em um workspace que esteja em uma região diferente do workspace da fonte de dados. Por exemplo, se o Lakehouse estiver no Centro-Oeste dos EUA, você só poderá criar modelos semânticos a partir deste Lakehouse na mesma região. Uma solução alternativa é criar um Lakehouse no workspace da outra região e usar um atalho para as tabelas antes de criar o modelo semântico. Para encontrar em qual região você está, consulte encontrar sua região base do Fabric. Sim Sim
A inserção de relatórios requer um token de inserção V2. Sim Sem suporte
Perfis de entidade de serviço para autenticação. Sem suporte Sem suporte
Os modelos semânticos do Direct Lake no Power BI podem ser criados e consultados por entidades de serviço e associação de função do Visualizador com entidades de serviço, mas os modelos semânticos do Direct Lake padrão no lakehouse/warehouse não dão suporte a esse cenário. Sim Sim
Atalhos em um lakehouse podem ser usados como fontes de dados para tabelas de modelo semântico. Não há suporte durante a visualização pública Suportado
Crie modelos do Direct Lake em áreas de trabalho pessoais (Workspace Pessoal). Sem suporte Sem suporte
Regras do pipeline de implantação para reconfigurar a fonte de dados. Sem suporte Suportado

Conteúdo relacionado