Direct Lake

O modo Direct Lake é uma funcionalidade de modelo semântico para analisar volumes de dados muito grandes no Power BI. O Direct Lake baseia-se no carregamento de arquivos formatados por parquet diretamente de um data lake sem precisar consultar um ponto de extremidade do lakehouse ou depósito e sem precisar importar ou duplicar dados em um modelo do Power BI. O Direct Lake é um caminho rápido para carregar os dados do lake diretamente no mecanismo do Power BI, pronto para análise. O diagrama a seguir mostra como os modos clássicos de importação e DirectQuery se comparam com o modo Direct Lake.

No modo DirectQuery, o mecanismo do Power BI consulta os dados na origem, que podem ser lentos, mas evita a necessidade de copiar os dados com o modo de importação. Todas as alterações na fonte de dados são refletidas imediatamente nos resultados da consulta.

Por outro lado, com o modo de importação, o desempenho pode ser melhor porque os dados são armazenados em cache e otimizados para consultas de relatórios DAX e MDX sem a necessidade de traduzir e passar o SQL ou outros tipos de consultas para a fonte de dados. No entanto, o mecanismo do Power BI deve primeiro copiar novos dados para o modelo durante a atualização. Todas as alterações na origem só são captadas com a próxima atualização de modelo.

O modo Direct Lake elimina o requisito de importação carregando os dados diretamente do OneLake. Ao contrário do DirectQuery, não existe tradução de DAX ou MDX para outras linguagens de consulta ou execução de consultas em outros sistemas de banco de dados, o que gera um desempenho de modo semelhante ao do modo de importação. Como não há um processo de importação explícito, é possível pegar as alterações na fonte de dados à medida que elas ocorrem, combinando as vantagens dos modos de importação e DirectQuery, evitando desvantagens. O modo Direct Lake pode ser a opção ideal para analisar modelos e modelos muito grandes com atualizações frequentes na fonte de dados.

O Direct Lake também dá suporte à segurança em nível de linha e à segurança no nível do objeto para que os usuários vejam apenas os dados que têm permissão para ver.

Pré-requisitos

O Direct Lake tem suporte apenas em SKUs Microsoft Premium (P) e Microsoft Fabric (F).

Importante

Para novos clientes, o Direct Lake tem suporte apenas em SKUs do Microsoft Fabric (F). Os clientes existentes podem continuar a usar o Direct Lake com SKUs Premium (P), mas a transição para um SKU de capacidade de malha é recomendada. Consulte o anúncio de licenciamento para obter mais informações sobre o licenciamento do Power BI Premium.

Lakehouse

Antes de usar o Direct Lake, você deve provisionar um lakehouse (ou um depósito) com uma ou mais tabelas Delta em um workspace hospedado em uma capacidade do Microsoft Fabric com suporte. O lakehouse é necessário porque fornece o local de armazenamento para seus arquivos formatados em parquet no OneLake. O lakehouse também fornece um ponto de acesso para iniciar uma ferramenta de modelagem Web, permitindo a criação de um modelo do Direct Lake.

Para saber como provisionar um lakehouse, criar uma tabela Delta no lakehouse e criar um modelo básico para o lakehouse, consulte Criar um lakehouse para Direct Lake.

Ponto de extremidade SQL

Como parte do provisionamento de um Lakehouse, um ponto de extremidade SQL para consulta SQL e um modelo padrão para relatórios são criados e atualizados com todas as tabelas adicionadas ao Lakehouse. Embora o modo Direct Lake não consulte o ponto de extremidade do SQL ao carregar dados diretamente do OneLake, é necessário quando um modelo do Direct Lake deve retornar diretamente ao modo DirectQuery, como quando a fonte de dados usa recursos específicos, como segurança avançada ou exibições que não podem ser lidas por meio do Direct Lake. O modo Direct Lake também realiza consultas ao ponto de extremidade SQL para obter informações de esquema e segurança.

Data Warehouse

Como uma opção a um Lakehouse com ponto de extremidade SQL, você pode provisionar um depósito e incluir tabelas por meio de instruções SQL ou pipelines de dados. O processo de provisionamento de um Data Warehouse autônomo é praticamente o mesmo de um Lakehouse.

Suporte a gravação de modelo com ponto de extremidade XMLA

Os modelos do Direct Lake dão suporte a operações de gravação por meio do ponto de extremidade XMLA, usando ferramentas como o SQL Server Management Studio (19.1 e superior) e as versões mais recentes de ferramentas de BI externas, como o Tabular Editor e o DAX Studio. Operações de gravação de modelo por meio do suporte ao ponto de extremidade XMLA:

• Personalizando, mesclando, scripts, depurando e testando metadados de modelo do Direct Lake.

• Controle de origem e versão, integração contínua e implantação contínua (CI/CD) com o Azure DevOps e o GitHub.

• Tarefas de automação, como atualizar e aplicar alterações em modelos do Direct Lake usando o PowerShell e AS APIs REST.

Observe que as tabelas Direct Lake criadas usando aplicativos XMLLA estarão inicialmente em um estado não processado até que o aplicativo emita um comando de atualização. As tabelas não processadas fazem fallback para o modo DirectQuery. Ao criar um modelo semântico, atualize seu modelo semântico para processar suas tabelas.

Habilitar o XMLA de leitura/gravação

Antes de executar operações de gravação em modelos do Direct Lake por meio do ponto de extremidade XMLA, a leitura/gravação XMLA deve ser habilitada para a capacidade.

Para as capacidades de avaliação do Fabric, o usuário de avaliação tem os privilégios de administrador necessários para habilitar a leitura/gravação de XMLA.

1. No portal do administrador, selecione Configurações de capacidade.

2. Clique na guia Avaliação.

3. Selecione a capacidade com Avaliação e seu nome de usuário no nome da capacidade.

4. Expanda as cargas de trabalho do Power BI e, na configuração do Ponto de extremidade XMLA, selecione Leitura e Gravação.

   

Tenha em mente que a configuração do ponto de extremidade XMLA se aplica a todos os workspaces e modelos atribuídos à capacidade.

Metadados de modelo do Direct Lake

Ao se conectar a um modelo autônomo do Direct Lake por meio do ponto de extremidade XMLA, os metadados se parecem com qualquer outro modelo. No entanto, os modelos do Direct Lake mostram as seguintes diferenças:

• A propriedade compatibilityLevel do objeto de banco de dados é 1604 ou superior.

• A propriedade Mode das partições do Direct Lake é definida como directLake.

• As partições do Direct Lake usam expressões compartilhadas para definir fontes de dados. Essa expressão se refere ao ponto de extremidade SQL de um Lakehouse ou depósito. O Direct Lake usa o ponto de extremidade SQL para descobrir informações de esquema e segurança, mas carrega os dados diretamente das tabelas Delta (a menos que o Direct Lake precise fazer fallback para o modo DirectQuery por algum motivo).

Aqui está um exemplo de consulta XMLA no SSMS:

Para saber mais sobre o suporte à ferramenta por meio do ponto de extremidade XMLA, consulte conectividade de modelo semântico com o ponto de extremidade XMLA.

Fallback

Modelos semânticos do Power BI no modo Direct Lake leem tabelas Delta diretamente do OneLake. No entanto, se uma consulta DAX em um modelo do Direct Lake exceder os limites da SKU ou usar recursos que não dão suporte ao modo Direct Lake, como exibições SQL em um depósito, a consulta poderá voltar ao modo DirectQuery. No modo DirectQuery, as consultas usam o SQL para recuperar os resultados do ponto de extremidade SQL do Lakehouse ou do depósito, o que pode afetar o desempenho da consulta. Você pode desabilitar o fallback para o modo DirectQuery se quiser processar consultas DAX somente no modo Direct Lake puro. É recomendável desabilitar o fallback se você não precisar de fallback para o DirectQuery. Também pode ser útil ao analisar o processamento de consultas para um modelo do Direct Lake para identificar se e com que frequência ocorrem fallbacks. Para saber mais sobre o modo DirectQuery, consulte os modos de modelo semântico no Power BI.

Os Guardrails definem limites de recursos para o modo Direct Lake além do qual um fallback para o modo DirectQuery é necessário para processar consultas DAX. Para obter detalhes sobre como determinar o número de arquivos parquet e grupos de linhas para uma tabela Delta, consulte a referência das propriedades da tabela Delta.

Para modelos semânticos do Direct Lake, a Memória Máxima representa o limite de recursos de memória superior para a quantidade de dados que podem ser paginado. Na verdade, não é um guardrail porque exceder não causa um fallback para DirectQuery; no entanto, ele poderá ter um impacto no desempenho se a quantidade de dados for grande o suficiente para causar paginação dos dados do modelo dos dados do OneLake.

A tabela a seguir lista os guardrails de recursos e o Max Memory:

SKUs do Fabric	Arquivos parquet por tabela	Grupos de linhas por tabela	Linhas por tabela (milhões)	Tamanho máximo do modelo no disco/OneLake1 (GB)	Memória máxima (GB)
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	25
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 – Se excedido, o tamanho máximo do modelo em disco/Onelake fará com que todas as consultas ao modelo façam fallback para o DirectQuery, diferentemente de outras grades de proteção avaliadas por consulta.

Dependendo do SKU do Fabric, a unidade de capacidade adicional e os limites máximos de memória por consulta também se aplicam aos modelos do Direct Lake. Para saber mais, confira Capacidades e SKUs.

Comportamento de fallback

Os modelos do Direct Lake incluem a propriedade DirectLakeBehavior, que tem três opções:

Automático – (Padrão) Especifica que as consultas retornam ao modo DirectQuery se os dados não puderem ser carregados com eficiência na memória.

DirectLakeOnly – Especifica que todas as consultas usam apenas o modo Direct Lake. O fallback para o modo DirectQuery está desabilitado. Se os dados não puderem ser carregados na memória, um erro será retornado. Use essa configuração para determinar se as consultas DAX falham ao carregar dados na memória, forçando um erro a ser retornado.

DirectQueryOnly – Especifica que todas as consultas usam apenas o modo DirectQuery. Use essa configuração para testar o desempenho de fallback.

A propriedade DirectLakeBehavior pode ser configurada usando o Modelo de Objeto Tabular (TOM) ou a Linguagem de Script de Modelo Tabular (TMSL).

O exemplo a seguir especifica que todas as consultas usam apenas o modo Direct Lake:

// Disable fallback to DirectQuery mode.
//
database.Model.DirectLakeBehavior = DirectLakeBehavior.DirectLakeOnly = 1;
database.Model.SaveChanges();

Analisar o processamento de consulta

Para determinar se as consultas DAX de um visual de relatório em fonte de dados estão fornecendo o melhor desempenho usando o modo Direct Lake ou retornando ao modo DirectQuery, use o Analisador de desempenho no Power BI Desktop, o SQL Server Profiler ou outras ferramentas de terceiros para analisar consultas. Para saber mais, confira Analisar o processamento de consultas para modelos do Direct Lake.

Atualizar

Por padrão, as alterações de dados no OneLake são refletidas automaticamente em um modelo do Direct Lake. Você pode alterar esse comportamento desabilitando manter seus dados do Direct Lake atualizados nas configurações do modelo.

Talvez você queira desabilitar se, por exemplo, precisar permitir a conclusão de trabalhos de preparação de dados antes de expor novos dados aos consumidores do modelo. Quando desabilitado, você pode invocar a atualização manualmente ou usando as APIs de atualização. Invocar uma atualização para um modelo do Direct Lake é uma operação de baixo custo em que o modelo analisa os metadados da versão mais recente da tabela Delta Lake e é atualizado para referenciar os arquivos mais recentes no OneLake.

Observe que o Power BI pode pausar as atualizações automáticas de tabelas do Direct Lake se um erro não recuperável for encontrado durante a atualização, portanto, verifique se o modelo semântico pode ser atualizado com êxito. O Power BI retoma automaticamente as atualizações automáticas quando uma atualização subsequente invocada pelo usuário é concluída sem erros.

Segurança de acesso a dados em camadas

Os modelos do Direct Lake criados em cima de Lakehouses e depósitos aderem ao modelo de segurança em camadas que o Lakehouses e depósitos dão suporte executando verificações de permissão por meio do ponto de extremidade T-SQL para determinar se a identidade que tenta acessar os dados tem as permissões de acesso a dados necessárias. Por padrão, os modelos do Direct Lake usam SSO (Logon Único), portanto, as permissões efetivas do usuário interativo determinam se o usuário tem permissão ou acesso negado aos dados. Se o modelo do Direct Lake estiver configurado para usar uma identidade fixa, a permissão efetiva da identidade fixa determinará se os usuários que interagem com o modelo semântico poderão acessar os dados. O ponto de extremidade T-SQL retorna Permitido ou Negado ao modelo do Direct Lake com base na combinação de permissões SQL e segurança do OneLake.

Por exemplo, um administrador do depósitos pode conceder permissões SELECT a um usuário em uma tabela para que o usuário possa ler a partir dessa tabela mesmo que o usuário não tenha permissões de segurança do OneLake. O usuário foi autorizado no nível do lakehouse/depósito. Por outro lado, um administrador do depósitos também pode NEGAR um acesso de leitura de usuário a uma tabela. Em seguida, o usuário não poderá ler a partir dessa tabela, mesmo se o usuário tiver permissões de leitura de segurança do OneLake. A instrução DENY anula qualquer segurança ou permissões SQL concedidas do OneLake. Consulte a tabela a seguir para obter as permissões efetivas que um usuário pode ter dado a qualquer combinação de permissões de segurança e SQL do OneLake.

Permissões de segurança do OneLake	Permissões de SQL	Permissões efetivas
Allow	Nenhum	Allow
Nenhum	Allow	Allow
Allow	Negar	Negar
Nenhum	Negar	Negar

Limitações e problemas conhecidos

• Por design, somente tabelas no modelo semântico derivado de tabelas em um Lakehouse ou Depósito oferecem suporte ao modo Direct Lake. Embora as tabelas no modelo possam ser derivadas de visualizações SQL no lakehouse ou no depósito, as consultas que usam essas tabelas retornarão ao modo DirectQuery.

• As tabelas de modelo semântico Direct Lake só podem ser derivadas de tabelas e exibições de um único Lakehouse ou Depósito.

• Atualmente, as tabelas Direct Lake não podem ser misturadas com outros tipos de tabela, como Importação, DirectQuery ou Dual, no mesmo modelo. Ainda não há suporte para modelos compostos.

• Não há suporte para relações datetime em modelos do Direct Lake.

• Ainda não há suporte para colunas calculadas e tabelas calculadas.

• Alguns tipos de dados podem não ter suporte, como decimais de alta precisão e tipos de dinheiro.

• As tabelas do Direct Lake não oferecem suporte a tipos complexos de colunas 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 de suas colunas de chave coincidam. As colunas de chave primária devem conter valores exclusivos. As consultas DAX falharão se forem detectados valores de chave primária duplicados.

• 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) nos modelos Direct Lake.

• Cenários inseridos que dependem de entidades inseridas ainda não têm suporte.

• A validação é limitada para modelos do Direct Lake. As seleções de usuário são consideradas corretas e nenhuma consulta validará a cardinalidade e as seleções de filtro cruzado para relacionamentos ou para a coluna de data selecionada em uma tabela de data.

• A guia Direct Lake no histórico de atualização lista apenas as falhas de atualização relacionadas ao Direct Lake. As atualizações bem-sucedidas estão omitidas no momento.

Introdução

A melhor maneira de começar a usar uma solução do Direct Lake em sua organização é criar um Lakehouse, criar uma tabela Delta nela e, em seguida, criar um modelo semântico básico para o Lakehouse em seu espaço de trabalho do Microsoft Fabric. Para saber mais, confira Criar um Lakehouse para Direct Lake.

Conteúdo relacionado

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