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, que armazenam seus dados em arquivos Parquet no OneLake, o único repositório para todos os dados de análise. 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 um único lakehouse ou armazém do Fabric Fabric. Esses dois itens de malha e os modelos semânticos do 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 desempenho de consulta rápido (exceto no caso de fallback do DirectQuery, que é explicado posteriormente neste artigo).

No entanto, um modelo semântico 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 Direct Lake é conceitualmente diferente de uma operação de atualização para um modelo semântico de importação. Para um modelo semântico 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 fazer referência aos 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 Direct Lake?

O principal caso de uso de um modo de armazenamento Direct Lake normalmente é para projetos de análise orientados por TI que aproveitam arquiteturas centradas em lake. 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 rapidamente os dados para usuários corporativos. Se as tabelas Delta forem modificadas de forma 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 reenquadrar em resposta a essas modificações. Nesse caso, as consultas enviadas ao modelo semântico retornarão os dados mais recentes. Essa funcionalidade 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 lakehouses do Fabric, instruções DML T-SQL para warehouses do Fabric, 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 poderá ser uma opção melhor. Isso ocorre porque ele dá suporte à preparação de dados usando Power Query, que é definido como parte do modelo semântico.

Certifique-se de levar em consideração sua licença de capacidade de malha atual e as proteções de capacidade de malha 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 a um modelo semântico do Direct Lake são tratadas de um cache na memória das colunas originadas de tabelas Delta. O armazenamento subjacente de 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 exigido pelas consultas.

Um modelo semântico do Direct Lake também pode usar o fallback do DirectQuery, que envolve alternar diretamente para o modo DirectQuery. O fallback do DirectQuery recupera dados diretamente do ponto de extremidade de análise 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 suportado pela capacidade do Fabric (descrito posteriormente neste artigo). Nesse caso, uma operação DirectQuery envia uma consulta para o ponto de extremidade de 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 ilustra as seguintes ações, processos e recursos do usuário.

Item	Descrição
	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 do Direct Lake.
	Um lakehouse ou warehouse do Fabric existe em um workspace que está na capacidade do 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 o Transact-SQL (T-SQL).
	Existe um modelo semântico do Direct Lake em um workspace do Fabric. Ele se conecta a mesas ou vistas no lakehouse 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 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 desempenho na memória, que é muito rápido.
	O modelo semântico retorna resultados de consulta.
	O relatório do Power BI renderiza os visuais.
	Em determinadas circunstâncias, como quando o modelo semântico excede as proteções da capacidade, as consultas de modelo semântico retornam automaticamente para o 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 os conceitos e recursos do Direct Lake, incluindo carregamento de coluna, enquadramento, atualizações automáticas e fallback do DirectQuery.

Carregamento de coluna (transcodificação)

Os modelos semânticos do Direct Lake carregam dados do OneLake apenas 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), ele primeiro determina quais colunas são necessárias para produzir um resultado de consulta. As colunas necessárias incluem todas as colunas usadas diretamente pela consulta e também as 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.

Depois de entender quais colunas são necessárias, o modelo semântico determina quais colunas já estão na memória. Se alguma coluna necessária para a consulta não estiver 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 que ela seja removida (removida) da memória. Os motivos pelos quais as colunas podem ser removidas incluem:

• O modelo ou a tabela foi atualizado (consulte Enquadramento na próxima seção).
• Nenhuma consulta usou a coluna por algum tempo.
• Outros motivos 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 do Direct Lake na capacidade. Para obter mais informações sobre proteções de recursos e limites máximos de memória, consulte Proteções e limitações de capacidade de malha mais adiante neste artigo.

Enquadramento

O enquadramento fornece aos proprietários do modelo controle pontual sobre quais dados são carregados no modelo semântico. O enquadramento é uma operação do Direct Lake que é 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 do Delta Lake e é atualizado para fazer referência aos arquivos Parquet mais recentes no OneLake.

Quando ocorre o enquadramento, as colunas residentes 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. 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 do 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 funcionam as operações de enquadramento do Direct Lake.

O diagrama descreve os seguintes processos e recursos.

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 acontecer automaticamente, manualmente, de acordo com o 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 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 de transcodificação futuros.
	As 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 em que 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 carregamento (ETL) de longa duração.

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 Entender o armazenamento para 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. Isso é 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 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 a um modelo semântico do Direct Lake pode voltar para o modo DirectQuery. Nesse caso, ele recupera dados diretamente do ponto de extremidade de análise SQL do lakehouse ou warehouse. Essas consultas sempre retornam os dados mais recentes porque não sã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 de análise SQL ou uma tabela no ponto de extremidade de análise SQL que impõe a RLS (segurança em nível de linha).

Além disso, uma consulta pode fazer fallback quando o modelo semântico excede as proteções da capacidade.

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

Proteções e limitações de capacidade de malha

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

1 Para modelos semânticos do Direct Lake, a Memória Máxima representa o limite superior de recursos de memória para a quantidade de dados que podem ser paginados. Por esse motivo, não é uma proteção porque excedê-la 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 voltem para o modo DirectQuery. Todas as outras proteções apresentadas na tabela são avaliadas por consulta. Portanto, é importante que você otimize suas tabelas Delta e o modelo semântico do Direct Lake para evitar a necessidade de escalar verticalmente desnecessariamente para um SKU de malha mais alto (resultando em aumento de custo).

Além disso, os limites de unidade de capacidade e memória máxima por consulta se aplicam aos modelos semânticos do Direct Lake. Para obter mais informações, consulte 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 ponto de extremidade de análise SQL que impõe a RLS (segurança em nível de linha), 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 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 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 que fazem referência a colunas ou tabelas no modo de armazenamento do 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 do Direct Lake.
• As tabelas do modo de armazenamento do Direct Lake não oferecem suporte a tipos complexos de coluna de tabela Delta. Os 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 das colunas relacionadas correspondam.
• As colunas de um lado das relações devem conter valores exclusivos. As consultas falharão se valores duplicados forem detectados em uma coluna de um lado.
• Não há suporte para inteligência automática de dados/tempo no Power BI Desktop . Há suporte para marcar sua própria tabela de datas como uma tabela de datas.
• O comprimento dos valores da coluna de cadeia de caracteres é limitado a 32.764 caracteres Unicode.
• Não há suporte para o valor de ponto flutuante NaN (não um número).
• Não há suporte para cenários de inserção que usam o cenário Para o uso do cliente .
• Só há suporte para a publicação na Web do Power BI 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 do usuário são consideradas corretas e nenhuma consulta é emitida para validar a cardinalidade ou as 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ção 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.
• Seu SKU de malha determina a memória máxima disponível por modelo semântico do 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 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 desse Lakehouse na mesma região. Uma solução alternativa é criar um Lakehouse no espaço de trabalho da outra região e um atalho para as tabelas antes de criar o modelo semântico. Para descobrir em qual região você está, consulte localizar sua região de origem do Fabric.

Comparação com outros modos de armazenamento

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

1 Você não pode combinar tabelas do modo de armazenamento do 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 armazenamento Importar, DirectQuery ou Dual) ou cálculos. Para obter mais informações, consulte Criar um modelo composto em um modelo semântico.

Conteúdo relacionado

• Desenvolver modelos semânticos do Direct Lake
• Gerenciar modelos semânticos do Direct Lake
• Entender o armazenamento para modelos semânticos do Direct Lake
• Criar um Lakehouse para Direct Lake
• Analisar o processamento de consulta para modelos semânticos do Direct Lake