Visão geral do Direct Lake

O Direct Lake é uma opção de modo de armazenamento de tabela de modelo semântico do Power BI disponível no Microsoft Fabric. Ele é otimizado para que grandes volumes de dados sejam rapidamente carregados na memória a partir de tabelas delta disponíveis no OneLake, o armazenamento único para todos os dados analíticos. Uma vez carregado na memória, o modelo semântico permite a análise interativa de alto desempenho.

O Direct Lake é ideal para modelos semânticos que se conectam a grandes lagos, armazéns e outras fontes de dados do Fabric com tabelas delta. O Direct Lake é especialmente útil quando replicar todo o volume de dados em uma tabela de importação é desafiador ou impossível. As consultas Direct Lake e import são processadas pelo mecanismo de consulta VertiPaq, enquanto o DirectQuery federa consultas à fonte de dados subjacente. As consultas Direct Lake e import normalmente superam as consultas DirectQuery ao carregar e interagir com elementos visuais em relatórios.

No entanto, um Direct Lake difere de um modo Import de uma maneira importante: 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. O modo de importação replica os dados e cria uma cópia em cache inteira dos dados para o modelo semântico, enquanto uma atualização do Direct Lake copia apenas metadados (conhecidos como enquadramento, descritos mais adiante 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 fazer referência aos arquivos mais recentes no OneLake. Em contraste, uma atualização de importação produz uma cópia dos dados, o que pode levar um tempo considerável e consumir recursos significativos da fonte de dados e da capacidade (memória e CPU). O Direct Lake move a preparação de dados para o OneLake e, ao fazer isso, usa toda a gama de tecnologias Fabric para preparação de dados, incluindo trabalhos Spark, instruções T-SQL DML, fluxos de dados, pipelines e muito mais.

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

• Semelhante ao modo de importação, as consultas Direct Lake são processadas pelo mecanismo VertiPaq e, portanto, oferecem desempenho de consulta comparável ao modo de importação sem a sobrecarga de gerenciamento de ciclos de atualização de dados para carregar todo o volume de dados.
• Usa os investimentos existentes em malha integrando-se perfeitamente com grandes lagos, armazéns e outras fontes de malha com tabelas Delta. Por exemplo, o Direct Lake é uma escolha ideal para a camada de análise Gold na arquitetura de medallion lakehouse.
• Maximiza o retorno sobre o investimento (ROI) porque os volumes de dados analisados podem exceder os limites máximos de memória da capacidade, uma vez que apenas os dados necessários para responder a uma consulta são carregados na memória.
• Minimiza as latências de dados sincronizando rápida e automaticamente um modelo semântico com suas fontes, disponibilizando novos dados para usuários corporativos sem agendas de atualização.

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

O principal caso de uso do modo de armazenamento 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 rápido desempenho da consulta são importantes para este caso de uso.

Direct Lake depende da preparação de dados feita no data lake. A preparação de dados pode ser feita usando várias ferramentas, como jobs do Spark para lakehouses do Fabric, instruções T-SQL DML para data 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 nas fases iniciais da 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 pela TI, aumentar o modelo com tabelas de modo de armazenamento de importação pode ser uma boa escolha, já que o modo de importação suporta a preparação de dados usando o Power Query, que é definido como parte do modelo semântico.

Certifique-se de considerar a sua licença de capacidade do Fabric atual e as limites de capacidade do Fabric ao considerar o modo de armazenamento Direct Lake. Além disso, tenha em conta as considerações e limitações, que são descritas mais adiante neste artigo.

Conceitos-chave e terminologia

Este artigo pressupõe familiaridade com os seguintes conceitos:

• Os usuários carregam e interagem com elementos visuais em relatórios do Power BI gerando 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 de tabela usado. Por exemplo:
  • Os modos de armazenamento Import e Direct Lake usam o mecanismo VertiPaq para processar consultas DAX e retornar resultados para o relatório e o usuário do Power BI.
  • O DirectQuery traduz consultas DAX para a sintaxe de consulta da fonte de dados, como uma consulta SQL, e as executa no banco de dados de origem subjacente. Esses bancos de dados de origem normalmente não são otimizados para cargas de consulta pesadas provenientes de relatórios e consultas agregadas necessárias para os elementos visuais e podem resultar em um desempenho mais lento quando comparado aos 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 diferentes modos de armazenamento, ele é chamado de 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 de armazenamento de tabela Direct Lake tem duas opções:

• Direct Lake em OneLake pode utilizar os dados provenientes de uma ou mais fontes de dados Fabric com tabelas delta. O Direct Lake no OneLake não recorre ao modo DirectQuery através do endpoint de análise SQL da fonte de dados. Os modelos semânticos com Direct Lake em tabelas OneLake também podem ter tabelas de importação adicionadas de outras fontes de dados.

• Direct Lake on SQL pode usar os dados de uma única fonte de dados Fabric com tabelas delta. O ponto de extremidade de análise SQL é utilizado para a descoberta de tabelas delta, visualização SQL e verificação de permissões. Os endpoints Direct Lake on SQL recorrem ao modo de armazenamento de tabela DirectQuery quando não conseguem carregar os dados diretamente de uma tabela delta, como quando a fonte de dados é uma vista SQL ou quando o Warehouse utiliza controle de acesso granular baseado em SQL. A propriedade do modelo semântico, Direct Lake behavior, controla o comportamento de recuo.

Comparação dos modos de armazenamento

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

¹ Ao utilizar Direct Lake nos endpoints SQL, não é possível combinar tabelas em modo de armazenamento Direct Lake com tabelas em 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.

² Requer um token de incorporação V2. Se estiver a utilizar um principal de serviço, deve utilizar uma ligação à nuvem com uma identidade fixa .

Como funciona o Direct Lake

Normalmente, as consultas enviadas para um modelo semântico Direct Lake são tratadas a partir de uma cache na memória das colunas originadas de tabelas Delta. O armazenamento subjacente para uma tabela Delta é constituído por 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.

O Direct Lake no OneLake não está associado ao endpoint SQL, oferecendo uma integração mais estreita com as funcionalidades do OneLake, como a segurança do OneLake e planos de consulta DAX mais eficientes, pois, 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 endpoints SQL, uma consulta DAX pode recorrer ao fallback do DirectQuery, o que envolve uma transição perfeita para o modo DirectQuery. O fallback do DirectQuery recupera dados diretamente do endpoint de análise SQL do lakehouse ou do armazém. Por exemplo, o fallback ocorre quando a segurança baseada em SQL é detetada no ponto de extremidade SQL. Nesse caso, uma operação DirectQuery envia uma consulta para o endpoint de análise SQL. As operações de fallback podem resultar em um desempenho de consulta mais lento.

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 de 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. 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ário 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 então residentes na memória. Consultas futuras que envolvam apenas colunas residentes não precisam carregar mais colunas na memória.

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

• O modelo ou tabela foram atualizados após uma atualização da tabela Delta na origem (consulte Enquadramento na próxima seção).
• Nenhuma consulta usou a coluna durante 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.

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

Enquadramento

Enquadramento fornece aos proprietários de modelos controlo pontual sobre quais dados são carregados no modelo semântico. O enquadramento é uma operação Direct Lake 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 ocorre o enquadramento, os segmentos de coluna e os dicionários da tabela residente podem ser removidos da memória caso os dados subjacentes tenham sido alterados e o momento da atualização se torne a nova referência para todos os eventos futuros de transcodificação. A partir deste ponto, as consultas Direct Lake consideram apenas os dados nas tabelas Delta, tal como estavam no 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 bem-sucedida mais recente. Esse momento não é 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 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 são adicionados aos dicionários existentes. Essa abordagem de enquadramento incremental ajuda a reduzir a carga de recarga e beneficia o desempenho da consulta. No caso ideal, quando uma tabela Delta não recebe 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.

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

O diagrama representa os seguintes processos e características.

Número	Descrição
	Existe um modelo semântico num espaço de trabalho Fabric.
	As operações de enquadramento ocorrem periodicamente e definem a base de referência para todos os futuros eventos de transcodificação. 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 operação de enquadramento última.
	Uma operação de enquadramento posterior inclui os arquivos Parquet que foram 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 momento da atualização torna-se o novo ponto de referência 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.

Atualizações automáticas

Há uma configuração semântica no nível do modelo para atualizar automaticamente as tabelas do Direct Lake. Está ativado 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.

Recurso de emergência do DirectQuery

Ao usar o Direct Lake em pontos de extremidade SQL, uma consulta enviada para um modelo semântico Direct Lake pode retornar 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 SQL da casa do lago ou armazém. Tais consultas retornam sempre os dados mais recentes porque não estão limitadas ao momento da última ação de enquadramento.

Quando o fallback do DirectQuery ocorre, 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 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 não pode utilizar o modo Direct Lake quando uma tabela Delta excede os limites da capacidade.

Você pode controlar o fallback dos seus modelos semânticos Direct Lake configurando a propriedade DirectLakeBehavior. Esta definição aplica-se apenas ao Direct Lake nos endpoints SQL. O Direct Lake no OneLake não suporta fallback do DirectQuery. Para obter mais informações, consulte Definir a propriedade de comportamento Direct Lake.

Segurança de dados e permissões de acesso

Por padrão, o Direct Lake usa logon único (SSO), 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 vincular um modelo Direct Lake a uma conexão de nuvem compartilhável (SCC) para fornecer uma identidade fixa e desabilitar o SSO. Neste caso, apenas a identidade fixa requer acesso de leitura aos dados na fonte.

Permissões de item de tecido

O Direct Lake impõe um modelo de segurança em camadas. A autorização efetiva para qualquer consulta depende das permissões de item de malha (acesso ao espaço de trabalho e ao modelo semântico) e das permissões no nível de origem, e de como o modelo é configurado para autenticação — SSO ou um SCC de identidade fixa.

Orientações operacionais:

• O modo de autenticação determina se as consultas são executadas usando identidades de usuário individuais (SSO) ou uma única identidade de serviço (SCC de identidade fixa).
  • Use o SSO para cenários interativos em que a autorização por usuário é necessária.
  • Utilize o SCC de identidade fixa para cenários de consumidor integrados ou de acesso somente leitura, em que o acesso ao nível de origem está limitado a uma única conta de serviço.
• Aplique princípios de privilégios mínimos nos níveis de origem e espaço de trabalho.
• Teste e valide o comportamento para ambos os modos de autenticação — especialmente para RLS baseada em SQL e quaisquer casos que possam acionar fallback do DirectQuery — antes da implantação de produção.

Para obter mais informações, consulte Integrar a segurança do Direct Lake.

Permissões de modelo semântico

Além das permissões de item do Fabric, deve-se também conceder permissões aos utilizadores para que possam usar ou gerir o modelo semântico Direct Lake. Em resumo, os consumidores de relatórios precisam de permissão de Leitura e os criadores de relatórios precisam de permissão de Compilação adicional. As permissões do modelo semântico podem ser atribuídas diretamente ou adquiridas implicitamente usando funções de espaço de trabalho. Para gerenciar as configurações do modelo semântico (para atualização e outras configurações), você deve ser o proprietário do modelo semântico .

Requisitos de permissão

Para cenários e requisitos de permissão, consulte Usuários do Direct Lake.

Para obter mais informações, consulte Permissões de modelo semântico.

Requisitos de capacidade do tecido

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

¹ 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 em um determinado momento. Por esta razão, não se trata de uma barreira de proteção, porque ultrapassá-la não resulta em um retorno ao modo DirectQuery; no entanto, isto pode ter um impacto no desempenho se a quantidade de dados for suficientemente grande para provocar paginação excessiva durante a carga e descarga dos dados do modelo da OneLake.

Caso seja excedido, o tamanho do modelo Max no disco/OneLake faz com que todas as consultas ao modelo semântico sejam redirecionadas para o modo DirectQuery. Todas as outras barreiras de segurança apresentadas na tabela são avaliadas 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.

Além disso, unidade de capacidade e limites de memória máxima por consulta aplicam-se a 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.

O modo de armazenamento de tabelas Direct Lake on OneLake está disponível em pré-visualização pública. Habilitar a configuração de locatário O usuário pode criar modelos semânticos do Direct Lake no OneLake (visualização) no portal de administração para criar modelos semânticos com o Direct Lake em tabelas do OneLake.

• Analisar no Excel as tabelas dinâmicas (e outros clientes MDX) têm as mesmas limitações que o DirectQuery com tabelas Direct Lake no modelo semântico. Não há suporte para instruções MDX com escopo de sessão, como conjuntos nomeados, membros calculados, membros padrão, etc. Instruções MDX com escopo de consulta, como a cláusula 'WITH', são suportadas. Não há suporte para hierarquias definidas pelo usuário da tabela Direct Lake. As hierarquias definidas pelo usuário da tabela de importação são suportadas mesmo com tabelas Direct Lake no modelo semântico.

• O Power BI Desktop pode editar ao vivo um modelo semântico com tabelas Direct Lake e importar tabelas. 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 também podem ser incluídos.

• A modelagem da Web do Power BI pode abrir qualquer modelo semântico, incluindo tabelas Direct Lake com outras tabelas de modo de armazenamento.

• A exibição de consulta DAX quando a edição ao vivo ou a conexão ao vivo e a gravação de consultas DAX na Web são suportadas para modelos semânticos Direct Lake on SQL, Direct Lake on OneLake e true composite (Direct Lake on OneLake + importação de qualquer fonte de dados).

• O modo de exibição TMDL é suportado durante a edição ao vivo no Power BI Desktop.

• A criação de relatórios com uma conexão em tempo real é suportada para todos os modelos semânticos, quando o autor do relatório tem pelo menos acesso de compilação.

• A expressão de ligação Direct Lake em SQL no modelo semântico deve referir-se ao ponto final de análise SQL pelo GUID, não por nome amigável, para usar Editar tabelas e atualizar operações no Power BI Desktop e na modelação Web do Power BI. A expressão de conexão pode ser atualizada na visualização TMDL ou em ferramentas externas baseadas em XMLA. O GUID está disponível na URL ao visualizar o ponto final de análise SQL no navegador.

Conteúdo relacionado

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