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 espaço de trabalho do Microsoft Fabric. Ele é otimizado para grandes volumes de dados que podem ser rapidamente carregados na memória a partir de tabelas Delta, que armazenam seus dados em arquivos Parquet no OneLake — o armazenamento único para todos os dados analíticos. Uma vez 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 Direct Lake para se conectar às tabelas ou exibições de uma única casa de malha ou armazém de malha. Ambos os itens de malha e modelos semânticos Direct Lake exigem uma licença de capacidade de malha.

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

No entanto, um modelo semântico Direct Lake difere de um modelo semântico Import de uma maneira importante. Isso ocorre porque uma operação de atualização para um modelo semântico Direct Lake é conceitualmente diferente de uma operação de atualização para um modelo semântico Import. Para um modelo semântico Direct Lake, uma atualização envolve uma operação de enquadramento (descrita mais adiante neste artigo), que pode levar alguns segundos para ser concluída. É uma operação de baixo custo onde o modelo semântico analisa os metadados da versão mais recente das tabelas Delta e é atualizado para fazer referência aos arquivos mais recentes no OneLake. Em contraste, para um modelo semântico de importação, uma atualização produz uma cópia dos dados, o que pode levar 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 Direct Lake?

O principal caso de uso para um modo de armazenamento Direct Lake é normalmente para projetos de análise orientados por TI que aproveitam 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 rápido desempenho da consulta são importantes para este caso de uso.

O modo de armazenamento Direct Lake também é adequado para minimizar a latência de dados para disponibilizar rapidamente os dados para usuários corporativos. Se suas tabelas Delta forem modificadas intermitentemente (e supondo que você já tenha feito a preparação de dados no data lake), você poderá depender de atualizações automáticas para reformular em resposta a essas modificações. Nesse caso, as consultas enviadas para o modelo semântico retornarão 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.

Lembre-se de que 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 lagos de malha, instruções T-SQL DML para armazéns de malha, 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, no caso de um analista de autoatendimento que pode não ter permissões de gravação em um lakehouse gerenciado pela TI, o modo de armazenamento de importação pode ser uma escolha melhor. Isso porque ele oferece suporte à preparação de dados usando o Power Query, que é definido como parte do modelo semântico.

Certifique-se de considerar sua licença de capacidade de malha atual e os guarda-corpos de capacidade de malha ao considerar o modo de armazenamento Direct Lake. Além disso, considere as considerações e limitações, que são descritas mais adiante neste artigo.

Como funciona o Direct Lake

Normalmente, as consultas enviadas para um modelo semântico Direct Lake são tratadas a partir de um cache na memória das colunas originadas de tabelas Delta. O armazenamento subjacente para uma tabela Delta é um ou mais arquivos Parquet no OneLake. Os arquivos Parquet organizam os dados por colunas em vez de linhas. Os modelos semânticos carregam colunas inteiras de tabelas Delta na memória conforme são exigidas pelas consultas.

Um modelo semântico Direct Lake também pode usar 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 SQL da casa do lago ou do depósito. Por exemplo, o fallback pode ocorrer quando uma tabela Delta contém mais linhas de dados do que o suportado pela sua capacidade de malha (descrito mais adiante neste artigo). Nesse caso, uma operação DirectQuery envia uma consulta para o ponto de extremidade da análise SQL. As 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 descreve as seguintes ações, processos e recursos do usuário.

Item	Description
	O OneLake é um data lake que armazena dados analíticos no formato Parquet. Esse formato de arquivo é otimizado para armazenar dados para modelos semânticos Direct Lake.
	Existe um armazém Fabric lakehouse ou Fabric em um espaço de trabalho com capacidade Fabric. O lakehouse tem um ponto de extremidade de análise SQL, que fornece uma experiência baseada em SQL para consulta. As tabelas (ou exibições) fornecem um meio de consultar as tabelas Delta no OneLake usando Transact-SQL (T-SQL).
	Existe um modelo semântico Direct Lake em um espaço de trabalho de malha. Ele se conecta a mesas ou vistas na casa do lago ou armazém.
	Um usuário abre um relatório do Power BI.
	O relatório do Power BI envia consultas DAX (Data Analysis Expressions) para o modelo semântico 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 um 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 elementos visuais.
	Em determinadas circunstâncias, como quando o modelo semântico excede os guardrails da capacidade, as consultas de modelo semântico retornam automaticamente ao modo DirectQuery. Nesse modo, as consultas são enviadas para o ponto de extremidade de análise SQL do lakehouse ou warehouse.
	As consultas DirectQuery enviadas para o ponto de extremidade de análise 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 conceitos e recursos do Direct Lake, incluindo carregamento de coluna, enquadramento, atualizações automáticas e fallback do DirectQuery.

Carregamento da coluna (transcodificação)

Os modelos semânticos 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 MDX, expressões multidimensionais — MDX), ele primeiro determina quais colunas são necessárias para produzir um resultado de consulta. As colunas necessárias incluem quaisquer colunas que são usadas diretamente pela consulta e também colunas exigidas por relações e medidas. Normalmente, o número de colunas necessárias para produzir um resultado de consulta é muito menor do que o número de colunas definidas no modelo semântico.

Uma vez que se entenda 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 muito rápida, no entanto, pode depender de fatores como a cardinalidade dos dados armazenados nas colunas.

As colunas carregadas na memória são entã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 ser removida (despejada) da memória. Os motivos pelos quais as colunas podem ser removidas incluem:

• O modelo ou tabela foi atualizado (consulte Enquadramento na próxima seção).
• Nenhuma consulta usa a coluna há algum tempo.
• Outras razões de gerenciamento de memória, incluindo pressão de memória na capacidade devido a outras operações simultâneas.

Sua escolha de SKU de malha determina a memória máxima disponível para cada modelo semântico Direct Lake na capacidade. Para obter mais informações sobre guarda-corpos de recursos e limites máximos de memória, consulte Guardrails e limitações de capacidade de malha mais adiante neste artigo.

Enquadramento

O enquadramento fornece aos proprietários de modelos controle point-in-time sobre quais dados são carregados no modelo semântico. O enquadramento é uma operação Direct Lake que é acionada por uma atualização de um modelo semântico e, na maioria dos casos, leva apenas alguns segundos para ser concluída. Isso porque é uma operação de baixo custo onde o modelo semântico analisa os metadados da versão mais recente das tabelas Delta Lake e é atualizado para fazer referência aos arquivos Parquet mais recentes no OneLake.

Quando o enquadramento ocorre, as colunas residentes podem ser removidas da memória e o ponto no tempo da atualização torna-se a nova linha de base para todos os eventos de transcodificação futuros. A partir deste ponto, as consultas Direct Lake só consideram 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 tempo não é necessariamente o estado mais recente das tabelas Delta.

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

O diagrama descreve os seguintes processos e recursos.

Item	Description
	Existe um modelo semântico em um espaço de trabalho de malha.
	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 acontecer automaticamente, manualmente, dentro do cronograma 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 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 de transcodificação futuros.
	Modificações de dados subsequentes, representadas por novos arquivos Parquet, não são 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 ocorre uma operação de transcodificação. Considere que o enquadramento pode ajudá-lo a fornecer resultados de consulta consistentes em ambientes onde os dados nas tabelas Delta são transitórios. Os dados podem ser transitórios por vários motivos, como quando ocorrem processos de extração, transformação e carga (ETL) de longa duração.

A atualização de um modelo semântico 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 controle de versão e enquadramento de tabelas delta, consulte Compreender o armazenamento para modelos semânticos 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. Está ativada por predefinição. Ele garante que as alterações de dados no OneLake sejam refletidas automaticamente no modelo semântico Direct Lake. Você deve desativar as atualizações automáticas quando quiser controlar as alterações de dados por enquadramento, 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 para um modelo semântico Direct Lake pode voltar ao modo DirectQuery. Nesse caso, ele recupera dados diretamente do ponto de extremidade de análise SQL da casa do lago ou armazém. Essas consultas sempre retornam os dados mais recentes porque não estão restritas ao ponto no tempo da última operação de enquadramento.

Uma consulta sempre retorna quando o modelo semântico consulta uma exibição no ponto de extremidade da análise SQL ou uma tabela no ponto de extremidade da análise SQL que impõe a segurança em nível de linha (RLS).

Além disso, uma consulta pode cair quando o modelo semântico excede os guardrails da capacidade.

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

Grades de proteção e limitações da capacidade da malha

Os modelos semânticos Direct Lake exigem uma licença de capacidade de malha. Além disso, há guarda-corpos de capacidade e limitações que se aplicam à sua assinatura de capacidade de malha (SKU), conforme apresentado na tabela a seguir.

1 Para modelos semânticos Direct Lake, Max Memory representa o limite superior de recursos de memória para a quantidade de dados que podem ser paginados. Por esse motivo, não é um guardrail porque excedê-lo não resulta em um fallback para o modo DirectQuery; no entanto, ele pode ter um impacto no desempenho se a quantidade de dados for grande o suficiente para causar paginação excessiva dentro e fora dos dados do modelo dos dados do OneLake.

Se excedido, o tamanho máximo do modelo no disco/OneLake fará com que todas as consultas ao modelo semântico retornem ao modo DirectQuery. Todos os outros guarda-corpos apresentados na tabela são avaliados por consulta. Portanto, é importante que você otimize suas tabelas Delta e o modelo semântico Direct Lake para evitar ter que escalar desnecessariamente para um SKU de malha mais alto (resultando em maior custo).

Além disso, a unidade de capacidade e os limites de memória máxima por consulta aplicam-se aos modelos semânticos Direct Lake. Para obter mais informações, consulte Capacidades e SKUs.

Considerações e limitações

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

• Quando uma tabela de modelo semântico Direct Lake se conecta a uma tabela no ponto de extremidade de análise SQL que impõe segurança em nível de linha (RLS), as consultas que envolvem essa tabela de modelo sempre retornarão ao modo DirectQuery. O desempenho da consulta pode ser mais lento.
• Quando uma tabela de modelo semântico Direct Lake se conecta a um modo de exibição no ponto de extremidade de análise SQL, as consultas que envolvem essa tabela de modelo sempre retornarã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 Import, DirectQuery ou Dual (exceto em casos especiais, incluindo grupos de cálculo, parâmetros hipotéticos e 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 Direct Lake. Há suporte para grupos de cálculo, parâmetros hipotéticos e parâmetros de campo, que criam implicitamente tabelas calculadas, e tabelas calculadas que não fazem referência a colunas ou tabelas Direct Lake.
• As tabelas do modo de armazenamento Direct Lake não suportam tipos complexos de colunas de tabela Delta. Tipos semânticos binários e GUID também não são suportados. Você deve converter esses tipos de dados em cadeias de caracteres ou outros tipos de dados suportados.
• As relações de tabela exigem que os tipos de dados das colunas relacionadas correspondam.
• As colunas unilaterais de relações devem conter valores exclusivos. As consultas falharão se valores duplicados forem detetados em uma coluna unilateral.
• Não há suporte para inteligência automática de dados/tempo no Power BI Desktop . A marcação da sua própria tabela de data como uma tabela de data é suportada.
• O comprimento dos valores de coluna de cadeia de caracteres é limitado a 32.764 caracteres Unicode.
• O valor de ponto flutuante NaN (não um número) não é suportado.
• Não há suporte para cenários de incorporação que usam o cenário Para uso do cliente .
• A publicação na Web a partir do Power BI só é suportada quando se utiliza uma identidade fixa para o modelo semântico Direct Lake.
• Na experiência de modelagem da Web, a validação é limitada para modelos semânticos Direct Lake. As seleções de usuário são consideradas corretas e nenhuma consulta é emitida para validar cardinalidade ou seleções de filtro cruzado para relacionamentos 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 as falhas de atualização relacionadas ao Direct Lake. As operações de atualização (enquadramento) bem-sucedidas não são listadas.
• O SKU de malha determina a memória máxima disponível por modelo semântico Direct Lake para a capacidade. Quando o limite é excedido, as consultas ao 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 Direct Lake em um espaço de trabalho que esteja em uma região diferente do espaço de trabalho da fonte de dados. Por exemplo, se a Lakehouse estiver no Centro-Oeste dos EUA, você só poderá criar modelos semânticos a partir dessa Lakehouse na mesma região. Uma solução alternativa é criar um Lakehouse no espaço de trabalho da outra região e atalho para as tabelas antes de criar o modelo semântico. Para descobrir em que região você está, consulte Localizar sua região inicial do Fabric.

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.

1 Não é possível combinar tabelas de modo de armazenamento Direct Lake com tabelas de 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 Direct Lake e, em seguida, estendê-lo com novas tabelas (usando o modo de armazenamento Import, DirectQuery ou Dual) ou cálculos. Para obter mais informações, consulte Criar um modelo composto em um modelo semântico.

Conteúdos relacionados

• Desenvolver modelos semânticos Direct Lake
• Gerenciar modelos semânticos do Direct Lake
• Compreender o armazenamento para modelos semânticos Direct Lake
• Crie uma casa no lago para o Direct Lake
• Analisar o processamento de consultas para modelos semânticos do Direct Lake