Lago Direto
O modo Direct Lake é um recurso de modelo semântico para analisar volumes de dados muito grandes no Power BI. O Direct Lake baseia-se no carregamento de ficheiros formatados em parquet diretamente a partir de um data lake sem ter de consultar um ponto de extremidade lakehouse ou warehouse e sem ter de importar ou duplicar dados para um modelo do Power BI. O Direct Lake é um caminho rápido para carregar os dados do lago 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 ao modo Direct Lake.
No modo DirectQuery, o mecanismo do Power BI consulta os dados na origem, o que pode ser lento, mas evita ter que copiar os dados como no modo de importação. Quaisquer alterações na fonte de dados são imediatamente refletidas 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ório DAX e MDX sem ter que traduzir e passar SQL ou outros tipos de consultas para a fonte de dados. No entanto, o mecanismo do Power BI deve primeiro copiar quaisquer novos dados para o modelo durante a atualização. Quaisquer alterações na origem só são captadas com a próxima atualização do modelo.
O modo Direct Lake elimina o requisito de importação carregando os dados diretamente do OneLake. Ao contrário do DirectQuery, não há tradução de DAX ou MDX para outras linguagens de consulta ou execução de consultas em outros sistemas de banco de dados, produzindo desempenho semelhante ao modo de importação. Como não há um processo de importação explícito, é possível pegar todas as alterações na fonte de dados à medida que ocorrem, combinando as vantagens do DirectQuery e dos modos de importação, evitando suas desvantagens. O modo Direct Lake pode ser a escolha ideal para analisar modelos muito grandes e modelos com atualizações frequentes na fonte de dados.
O Direct Lake também oferece suporte à segurança em nível de linha do Power BI e à segurança em nível de objeto para que os usuários vejam apenas os dados que têm permissão para ver.
Pré-requisitos
O Direct Lake é suportado apenas em SKUs Microsoft Premium (P) e SKUs Microsoft Fabric (F).
Importante
Para novos clientes, o Direct Lake é suportado 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 uma SKU de capacidade de malha é recomendada. Consulte o anúncio de licenciamento para obter mais informações sobre o licenciamento do Power BI Premium.
Casa do Lago
Antes de usar o Direct Lake, você deve provisionar uma lakehouse (ou um depósito) com uma ou mais tabelas Delta em um espaço de trabalho hospedado em uma capacidade compatível do Microsoft Fabric. O lakehouse é necessário porque fornece o local de armazenamento para seus arquivos formatados em parquet no OneLake.
Para saber como provisionar uma casa no lago, criar uma mesa Delta na casa do lago e criar um modelo básico para a casa do lago, consulte Criar uma casa do lago para o lago direto.
Ponto de extremidade de análise SQL e data warehouse
Como parte do provisionamento de um lakehouse, um ponto de extremidade de análise SQL para consultas SQL é criado e atualizado com quaisquer tabelas adicionadas ao lakehouse. Embora o modo Direct Lake não consulte o ponto de extremidade de análise SQL ao carregar dados diretamente do OneLake, ele é necessário quando um modelo Direct Lake deve retornar perfeitamente 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 através do Direct Lake e devem utilizar o ponto de extremidade de análise SQL. O modo Direct Lake também consulta periodicamente o ponto de extremidade de análise SQL em busca de informações relacionadas ao esquema e à segurança.
Como alternativa a um lakehouse com ponto de extremidade de análise SQL, você também pode provisionar um depósito e adicionar tabelas usando instruções SQL ou pipelines de dados. O procedimento para provisionar um armazém de dados autônomo é quase idêntico ao procedimento para uma casa de lago.
Modelo semântico padrão do Power BI
Armazéns e pontos de extremidade de análise SQL também criam um modelo semântico padrão do Power BI no modo Direct Lake. Esse modelo semântico padrão só pode ser editado dentro do armazém ou do ponto de extremidade de análise SQL e tem limitações adicionais. Consulte a documentação do modelo semântico padrão do Power BI. Esta documentação do Direct Lake destina-se a modelos semânticos não predefinidos do Power BI no modo Direct Lake.
Criar um modelo semântico do Power BI no modo Direct Lake
Os modelos semânticos do Power BI no modo Direct Lake são criados na casa do lago ou no armazém.
No Lakehouse, clique em Novo modelo semântico do Power BI para criar um modelo semântico do Power BI no modo Direct Lake.
No armazém ou no ponto de extremidade de análise SQL, selecione a faixa de opções Relatórios e selecione Novo modelo semântico do Power BI para criar um modelo semântico do Power BI no modo Direct Lake.
Em seguida, você pode adicionar relações, medidas, grupos de cálculos, formatar cadeias de caracteres, segurança em nível de linha, etc., e renomear tabelas e colunas editando o modelo semântico no navegador. Edite o modelo semântico posteriormente usando o menu de contexto do espaço de trabalho para abrir o modelo de dados.
Suporte de gravação de modelo com ponto de extremidade XMLA
Os modelos Direct Lake oferecem 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 Editor de Tabelas e o estúdio DAX. Operações de gravação de modelo através do suporte de ponto de extremidade XMLA:
Personalização, mesclagem, criação de scripts, depuração e teste de 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 a modelos Direct Lake usando APIs PowerShell e REST.
As tabelas Direct Lake criadas usando aplicativos XMLA estarão inicialmente em um estado não processado até que o aplicativo emita um comando refresh. As tabelas não processadas voltam ao modo DirectQuery. Ao criar um novo modelo semântico, certifique-se de atualizar seu modelo semântico para processar suas tabelas.
Habilitar leitura-gravação XMLA
Antes de executar operações de gravação em modelos Direct Lake por meio do ponto de extremidade XMLA, a leitura-gravação XMLA deve ser habilitada para a capacidade.
Para 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 XMLA.
No Portal de administração, selecione Configurações de capacidade.
Selecione a guia Avaliação .
Selecione a capacidade com Avaliação e seu nome de usuário no nome da capacidade.
Expanda Cargas de trabalho do Power BI e, na configuração Ponto de Extremidade XMLA, selecione Ler Gravação.
Lembre-se de que a configuração XMLA Endpoint se aplica a todos os espaços de trabalho e modelos atribuídos à capacidade.
Metadados do modelo Direct Lake
Ao se conectar a um modelo Direct Lake autônomo por meio do ponto de extremidade XMLA, os metadados se parecem com qualquer outro modelo. No entanto, os modelos Direct Lake mostram as seguintes diferenças:
A
compatibilityLevel
propriedade do objeto de banco de dados é 1604 ou superior.A
Mode
propriedade de partições Direct Lake é definida comodirectLake
.As partições Direct Lake usam expressões compartilhadas para definir fontes de dados. A expressão aponta para o ponto de extremidade de análise SQL de um lakehouse ou armazém. O Direct Lake usa o ponto de extremidade de análise SQL do Lakehouse para descobrir informações de esquema e segurança, mas carrega os dados diretamente das tabelas Delta (a menos que o Direct Lake deva voltar ao modo DirectQuery por qualquer motivo).
Aqui está um exemplo de consulta XMLA no SSMS:
Para saber mais sobre o suporte a ferramentas por meio do ponto de extremidade XMLA, consulte Conectividade do modelo semântico com o ponto de extremidade XMLA.
Fallback
Os 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 Direct Lake exceder os limites para a SKU ou usar recursos que não oferecem suporte ao modo Direct Lake, como exibições SQL em um depósito, a consulta poderá retornar ao modo DirectQuery. No modo DirectQuery, as consultas usam SQL para recuperar os resultados do depósito ou do ponto de extremidade de análise SQL de um Lakehouse, 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. A desativação do fallback é recomendada se você não precisar de fallback para o DirectQuery. Também pode ser útil ao analisar o processamento de consultas para um modelo Direct Lake para identificar se e com que frequência ocorrem fallbacks. Para saber mais sobre o modo DirectQuery, consulte Modos de modelo semântico no Power BI.
Os guarda-corpos definem limites de recursos para o modo Direct Lake, além dos quais é necessário um fallback para o modo DirectQuery para processar consultas DAX. Para obter detalhes sobre como determinar o número de arquivos de parquet e grupos de linhas para uma tabela Delta, consulte a referência de propriedades da tabela Delta.
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. Na verdade, não é um guardrail porque excedê-lo não causa um fallback para o DirectQuery; no entanto, ele pode ter um impacto no desempenho se a quantidade de dados for grande o suficiente para causar a paginação dentro e fora dos dados do modelo dos dados do OneLake.
A tabela a seguir lista os guardrails de recursos e a Memória Máxima:
SKUs de malha | Arquivos de 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 | 1500 | Ilimitado | 25 |
F128/P2 | 5.000 | 5.000 | 3,000 | Ilimitado | 50 |
F256/P3 | 5.000 | 5.000 | 6000 | 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 no disco/Onelake faz com que todas as consultas ao modelo retornem ao DirectQuery, ao contrário de outros guardrails que são avaliados por consulta.
Dependendo do seu SKU de malha, a unidade de capacidade adicional e os limites de memória máxima por consulta também se aplicam aos modelos Direct Lake. Para saber mais, consulte Capacidades e SKUs.
Comportamento de fallback
Os modelos 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 somente o modo Direct Lake. O fallback para o modo DirectQuery está desativado. 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 não conseguem carregar dados na memória, forçando um erro a ser retornado.
DirectQueryOnly - Especifica que todas as consultas usam somente o modo DirectQuery. Use essa configuração para testar o desempenho de fallback.
A propriedade DirectLakeBehavior pode ser configurada usando TOM (Tabular Object Model) ou TMSL (Tabular Model Scripting Language).
O exemplo a seguir especifica que todas as consultas usam somente o modo Direct Lake:
// Disable fallback to DirectQuery mode.
//
database.Model.DirectLakeBehavior = DirectLakeBehavior.DirectLakeOnly = 1;
database.Model.SaveChanges();
Isso também pode ser definido ao editar o modelo semântico no navegador nas propriedades do modelo semântico. Selecione Modelo semântico na guia Modelo do painel Dados .
Analisar o processamento de consultas
Para determinar se as consultas DAX de um visual de relatório à fonte de dados estão fornecendo o melhor desempenho usando o modo Direct Lake ou voltando ao modo DirectQuery, você pode usar o Analisador de desempenho no Power BI Desktop, no SQL Server Profiler ou em outras ferramentas de terceiros para analisar consultas. Para saber mais, consulte Analisar o processamento de consultas para modelos Direct Lake.
Atualizar
Por padrão, as alterações de dados no OneLake são refletidas automaticamente em um modelo Direct Lake. Você pode alterar esse comportamento desativando Manter seus dados do Direct Lake atualizados nas configurações do modelo.
Você pode querer desativar se, por exemplo, precisar permitir a conclusão de trabalhos de preparação de dados antes de expor quaisquer 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 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 fazer referência aos arquivos mais recentes no OneLake.
Observe que o Power BI pode pausar as atualizações automáticas de tabelas Direct Lake se um erro irrecuperável for encontrado durante a atualização, portanto, verifique se seu 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.
Logon único (SSO) habilitado por padrão
Por padrão, os modelos Direct Lake dependem do Microsoft Entra Single Sign-On (SSO) para acessar as fontes de dados do Fabric Lakehouse e do Warehouse e usar a identidade do usuário que está interagindo com o modelo. Você pode verificar a configuração nas configurações do modelo Direct Lake expandindo a seção Gateway e conexões de nuvem, mostrada na captura de tela a seguir. O modelo Direct Lake não requer uma conexão de dados explícita, pois o Lakehouse ou o Warehouse é diretamente acessível e o SSO elimina a necessidade de credenciais de conexão armazenadas.
Você também pode vincular explicitamente a fonte de dados Lakehouse ou Warehouse a uma conexão de nuvem compartilhável (SCC) nos casos em que deseja usar credenciais armazenadas e, assim, desabilitar o SSO para essa conexão de fonte de dados. Para vincular explicitamente a fonte de dados, selecione o SCC na caixa de listagem Mapas para: na seção Conexões de gateway e nuvem . Você também pode criar uma nova conexão selecionando Criar uma conexão e siga as etapas para fornecer um nome de conexão. Em seguida, selecione OAuth 2.0 como o método de autenticação para a nova conexão, insira as credenciais desejadas e desmarque a caixa de seleção Logon único e, em seguida, vincule a fonte de dados Lakehouse ou Warehouse à nova conexão SCC que você acabou de criar.
A configuração de conexão Default: Single Sign-On (Entra ID) simplifica a configuração do modelo Direct Lake, no entanto, se você já tiver uma conexão de nuvem pessoal (PCC) com a fonte de dados Lakehouse ou Warehouse, o modelo Direct Lake se ligará automaticamente ao PCC correspondente para que as configurações de conexão já definidas para a fonte de dados sejam imediatamente aplicadas. Você deve confirmar a configuração de conexão de seus modelos Direct Lake para garantir que os modelos acessem suas fontes de dados de malha com as configurações corretas.
Os modelos semânticos podem usar a configuração de conexão Default: Single Sign-On (Entra ID) para Fabric Lakehouses e Warehouses no modo Direct Lake, Import e DirectQuery. Todas as outras fontes de dados exigem conexões de dados definidas explicitamente.
Segurança de acesso a dados em camadas
Os modelos Direct Lake criados sobre lakehouses e warehouses aderem ao modelo de segurança em camadas que lakehouses e warehouses suportam executando verificações de permissão por meio do ponto de extremidade de análise 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 Direct Lake usam logon único (SSO), 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 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 podem acessar os dados. O ponto de extremidade de análise SQL retorna Permitido ou Negado para o modelo Direct Lake com base na combinação de segurança OneLake e permissões SQL.
Por exemplo, um administrador de depósito pode conceder a um usuário permissões SELECT 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 OneLake. O usuário foi autorizado no nível da casa do lago/armazém. Por outro lado, um administrador de armazém também pode NEGAR a um usuário acesso de leitura a uma tabela. O usuário não poderá ler a partir dessa tabela, mesmo que tenha permissões de Leitura de segurança do OneLake. A instrução DENY anula qualquer segurança OneLake concedida ou permissões SQL. Consulte a tabela a seguir para obter as permissões efetivas que um usuário pode ter dado a qualquer combinação de segurança do OneLake e permissões SQL.
Permissões de segurança do OneLake | Permissões SQL | Permissões efetivas |
---|---|---|
Permitir | Nenhuma | Permitir |
Nenhuma | Permitir | Permitir |
Permitir | Negar | Negar |
Nenhuma | Negar | Negar |
Problemas e limitações conhecidos
Por design, apenas tabelas no modelo semântico derivadas de tabelas em um Lakehouse ou Warehouse suportam o modo Direct Lake. Embora as tabelas no modelo possam ser derivadas de exibições SQL no Lakehouse ou no Warehouse, 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 visualizações de uma única Lakehouse ou Warehouse. Uma única Lakehouse pode incluir atalhos adicionados de outras Lakehouses.
As consultas que usam segurança em nível de linha em tabelas no depósito (incluindo o ponto de extremidade de análise do Lakehouse SQL) retornarão ao modo DirectQuery.
Atualmente, as tabelas Direct Lake não podem ser misturadas com outros tipos de tabela, como Import, DirectQuery ou Dual, no mesmo modelo. Os modelos compostos em modelos semânticos do Power BI podem usar modelos semânticos do Power BI no modo de armazenamento Direct Lake como origem.
As relações DateTime não são suportadas nos modelos Direct Lake. As relações de data são suportadas.
Não há suporte para colunas calculadas e tabelas calculadas. Grupos de cálculo e parâmetros de campo são suportados.
Alguns tipos de dados podem não ser suportados, como decimais de alta precisão e tipos monetários.
As tabelas 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 de suas colunas principais coincidam. As colunas de chave primária devem conter valores exclusivos. As consultas DAX falharão se valores de chave primária duplicados forem detetados.
O comprimento dos valores de coluna de cadeia de caracteres é limitado a 32.764 caracteres Unicode.
O valor de ponto flutuante 'NaN' (Not A Number) não é suportado nos modelos Direct Lake.
Os cenários do Power BI Embedded que dependem de entidades incorporadas ainda não são suportados.
A validação é limitada para modelos 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ções lista apenas as falhas de atualização relacionadas ao Direct Lake. As atualizações bem-sucedidas são omitidas no momento.
Começar agora
A melhor maneira de começar a usar uma solução Direct Lake em sua organização é criar uma Lakehouse, criar uma tabela Delta nela e, em seguida, criar um modelo semântico básico para a lakehouse em seu espaço de trabalho do Microsoft Fabric. Para saber mais, consulte Criar uma casa de lago para o Direct Lake.