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 das Tabelas Delta, que armazenam seus dados em arquivos Parquet no OneLake, o único repositório para todos os dados de análise. Depois de carregado na memória, o modelo semântico permite consultas de alto desempenho. O Direct Lake elimina a necessidade lenta e dispendiosa de importar dados para o modelo.

Você pode usar o modo de armazenamento do Direct Lake para se conectar às tabelas ou exibições de um só Lakehouse do Fabric ou Warehouse do Fabric. Tanto os itens do Fabric quanto os modelos semânticos do Direct Lake exigem uma licença de capacidade do Fabric.

De certa forma, um modelo semântico do Direct Lake é semelhante a um Modelo semântico de importação. Isso ocorre porque os dados do modelo são carregados na memória pelo mecanismo VertiPaq para desempenho rápido de consulta (exceto no caso de fallback do DirectQuery, que é explicado mais adiante neste artigo).

No entanto, um modelo semântico do Direct Lake difere de um modelo semântico de importação de uma maneira importante. Isso ocorre porque 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. Para um modelo semântico do Direct Lake, uma atualização envolve uma operação de enquadramento (descrita posteriormente neste artigo), que pode levar alguns segundos para ser concluída. É uma operação de baixo custo em que o modelo semântico analisa os metadados da versão mais recente das tabelas Delta e é atualizado para referenciar os arquivos mais recentes no OneLake. Por outro lado, para um modelo semântico de importação, uma atualizaçã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).

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

O principal caso de uso para um modo de armazenamento do Direct Lake normalmente é para projetos de análise orientados por TI que usam arquiteturas centradas no lago. Nesse cenário, 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.

O modo de armazenamento Direct Lake também é adequado para minimizar a latência de dados para disponibilizar dados rapidamente para usuários corporativos. Se as tabelas Delta forem modificadas de modo intermitente (e supondo que você já tenha feito a preparação de dados no data lake), você poderá depender de atualizações automáticas para reestruturar na resposta a essas modificações. Nesse caso, as consultas enviadas ao modelo semântico retornam os dados mais recentes. Esse recurso funciona bem em parceria com o recurso de atualização automática de página dos relatórios do Power BI.

Tenha em mente que o Direct Lake depende da preparação de dados realizada no data lake. A preparação de dados pode ser feita usando várias ferramentas, como Spark jobs para Fabric Lakehouses, instruções DML T-SQL para Fabric warehouses, fluxos de dados, pipelines e outros. Essa abordagem ajuda a garantir que a lógica de preparação de dados seja executada o mais baixo possível 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, um analista de autoatendimento que não tem permissões de gravação em um lakehouse gerenciado por TI, o modo de armazenamento de Importação poderá ser a melhor opção. Isso ocorre porque ele 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.

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.

Um modelo semântico do Direct Lake também pode usar o fallback do DirectQuery, que envolve a alternância direta 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 pode ocorrer quando uma tabela Delta contém mais linhas de dados do que o suporte da capacidade do Fabric (descrito posteriormente neste artigo). 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.

O diagrama a seguir mostra como o Direct Lake funciona usando o cenário de um usuário que abre um relatório do Power BI.

O diagrama ilustra as seguintes ações, processos e recursos do usuário.

Item	Descrição
	O OneLake é um data lake que armazena dados de análise no formato Parquet. Esse formato de arquivo é otimizado para armazenar dados para modelos semânticos do Direct Lake.
	Um lakehouse ou um warehouse do Fabric existe em um workspace que está na capacidade do Fabric. O lakehouse tem um endpoint de análises SQL, que fornece uma experiência baseada em SQL para consultas. Tabelas (ou exibições) fornecem um meio de consultar as tabelas Delta no OneLake usando Transact-SQL (T-SQL).
	Um modelo semântico do Direct Lake existe em um workspace do Fabric. Ele se conecta a tabelas ou exibições no lakehouse ou no warehouse.
	Um usuário abre um relatório do Power BI.
	O relatório do Power BI envia consultas DAX (Expressões de Análise de Dados) para o modelo semântico do Direct Lake.
	Quando possível (e necessário), o modelo semântico carrega colunas na memória diretamente dos arquivos Parquet armazenados no OneLake. As consultas alcançam o desempenho na memória, que é muito rápido.
	O modelo semântico retorna os resultados da consulta.
	O relatório do Power BI renderiza os visuais.
	Em determinadas circunstâncias, como quando o modelo semântico excede os verificadores de integridade da capacidade, as consultas do modelo semântico retornam automaticamente ao modo DirectQuery. Nesse modo, as consultas são enviadas para o ponto de extremidade de análise de SQL do lakehouse ou do warehouse.
	As consultas DirectQuery enviadas ao ponto de extremidade de análise do SQL, por sua vez, consultam as tabelas Delta no OneLake. Por esse motivo, o desempenho da consulta pode ser mais lento do que as consultas na memória.

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.

Observe que 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 recém-adicionados 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.

O diagrama representa os seguintes processos e características.

Item	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.

Para obter mais informações sobre o controle de versão e o enquadramento da tabela Delta, consulte Noções básicas sobre o armazenamento de 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.

Fallback do DirectQuery

Uma consulta enviada a um modelo semântico do Direct Lake pode voltar ao modo DirectQuery. Nesse caso, ele recupera dados diretamente do ponto de extremidade de análise de SQL do lakehouse ou do 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.

Uma consulta sempre recua 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 a RLS (segurança em nível de linha).

Além disso, uma consulta pode recuar quando o modelo semântico exceder os verificadores de integridade da capacidade.

Você pode controlar o fallback dos seus modelos semânticos do Direct Lake definindo a propriedade DirectLakeBehavior. Para obter mais informações, consulte Defina a propriedade de comportamento do Direct Lake.

Limitações e verificadores de integridade de capacidade do Fabric

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.

¹ 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 suas tabelas Delta e o modelo semântico do Direct Lake para evitar a necessidade de escalar verticalmente de forma desnecessária para um SKU do Fabric mais alto (resultando em um custo maior).

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.

• Quando uma tabela de modelo semântico do Direct Lake se conecta a uma tabela no endpoint de analytics do SQL que impõe RLS (segurança em nível de linha), as consultas que envolvem essa tabela de modelo sempre reverterão ao modo DirectQuery. O desempenho da consulta pode ser mais lento.
• Quando uma tabela de modelo semântico do Direct Lake se conecta a uma exibição no ponto de extremidade de análise do SQL, as consultas que envolvem essa tabela de modelos sempre voltarão ao modo DirectQuery. O desempenho da consulta pode ser mais lento.
• Não há suporte para modelagem composta. Isso 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 casos especiais, incluindo grupos de cálculo , parâmetros de hipótesese parâmetros de campo ).
• 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.
• 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.
• As relações de tabela exigem que os tipos de dados de colunas relacionadas correspondam.
• 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.
• Não há suporte para Dados automáticos/inteligência de dados temporais no Power BI Desktop. Há suporte para marcar sua própria tabela de datas como uma tabela de datas.
• O comprimento dos valores de coluna de cadeia de caracteres é limitado a 32.764 caracteres Unicode.
• O valor do ponto flutuante NaN (não um número) não tem suporte.
• 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.
• 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.
• No portal do Fabric, a guia Direct Lake no histórico de atualizações lista apenas falhas de atualização relacionadas ao Direct Lake. Operações de atualização (enquadramento) bem-sucedidas não são listadas.
• 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.
• 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.
• Você pode criar e exibir um modelo semântico personalizado do Direct Lake usando uma identidade de Entidade de Serviço, mas o modelo semântico do Direct Lake padrão não dá suporte a Entidades de Serviço. Verifique se a autenticação da entidade de serviço está habilitada para APIs REST do Fabric em seu locatário e conceda permissões de Colaborador da entidade de serviço, ou permissões mais altas, para o workspace do modelo semântico do Direct Lake.
• A inserção de relatórios requer um token de inserção V2.
• O Direct Lake não dá suporte a perfis de entidade de serviço para autenticação.
• Modelos semânticos personalizados do Direct Lake criados pela Entidade de Serviço e visualizador com a Entidade de Serviço têm suporte, mas não há suporte para modelos semânticos do Direct Lake padrão.

Comparação com outros modos de armazenamento

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

¹ 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.

² 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.

Conteúdo relacionado

• desenvolver modelos semânticos do Direct Lake
• Gerencie modelos semânticos do Direct Lake
• Entender o armazenamento de modelos semânticos do Direct Lake
• Criar uma lakehouse para o Direct Lake
• Analisar o processamento de consultas para modelos semânticos do Direct Lake