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. Depois de 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 do Fabric ou Warehouse do Fabric. Ambos os itens do Fabric e os modelos semânticos do Direct Lake exigem uma licença de capacidade do Fabric.
De certa forma, um modelo semântico do Direct Lake é semelhante a um modelo semântico de Importação. Isso ocorre porque os dados do modelo são carregados na memória pelo mecanismo VertiPaq para desempenho rápido de consulta (exceto no caso de fallback do DirectQuery, que é explicado posteriormente neste artigo).
No entanto, um modelo semântico do 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 do Direct Lake é conceitualmente diferente de uma operação de atualização para um modelo semântico de Importação. Para um modelo semântico do 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 referenciar os 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).
Observação
Atualização incremental para um modelo semântico de Importação pode ajudar a reduzir o tempo de atualização e o uso de recursos de capacidade.
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 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.
Observação
Os modelos semânticos de Importação e DirectQuery ainda são relevantes no Fabric e são a escolha certa do modelo semântico para alguns cenários. Por exemplo, o modo de armazenamento de Importação geralmente funciona bem para um analista de autoatendimento que precisa de liberdade e agilidade para agir rapidamente e sem dependência de TI para adicionar novos elementos de dados.
Além disso, a integração do OneLake grava automaticamente dados para tabelas no modo de armazenamento de Importação para tabelas Delta no OneLake sem envolver nenhum esforço de migração. Usando essa opção, você pode perceber muitos dos benefícios do Fabric que são disponibilizados para usuários do modelo semântico de Importação, como integração com lakehouses por meio de atalhos, consultas SQL, notebooks e muito mais. Recomendamos que você considere essa opção como uma forma rápida de aproveitar os benefícios do Fabric sem necessariamente ou imediatamente projetar novamente seu data warehouse e/ou sistema de análise existente.
O modo de armazenamento Direct Lake também é adequado para minimizar a latência de dados para disponibilizar dados rapidamente para usuários corporativos. Se as tabelas Delta forem modificadas intermitentemente (e supondo que você já tenha feito a preparação de dados no data lake), poderá depender de atualizações automáticas para reestruturar na resposta a essas modificações. Nesse caso, as consultas enviadas ao modelo semântico retornarão os dados mais recentes. Esse recurso funciona bem em parceria com o recurso atualização automática de página dos relatórios do Power BI.
Lembre-se 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 fluxos de dados, pipelines, warehouses do Fabric 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 talvez não tenha permissões de gravação em um lakehouse gerenciado por TI, o modo de armazenamento de Importação pode ser a melhor opção. Isso ocorre porque ele dá suporte à preparação de dados usando o Power Query, que é definido como parte do modelo semântico.
Certifique-se de considerar a atual licença de capacidade do Fabric e os verificadores de integridade de capacidade do Fabric quando você considerar o modo de armazenamento Direct Lake. Além disso, analise as considerações e limitações, que são descritas posteriormente neste artigo.
Dica
Recomendamos que você produza um protótipo, ou POC (prova de conceito), para determinar se um modelo semântico do Direct Lake é a solução adequada e para reduzir o risco.
Como funciona o Direct Lake
Normalmente, as consultas enviadas para um modelo semântico do Direct Lake são manipuladas 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 dados por colunas em vez de linhas. Os modelos semânticos carregam colunas inteiras de tabelas Delta na memória, pois elas são exigidas por consultas.
Um modelo semântico do Direct Lake também pode usar 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 de 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 suporte da capacidade do Fabric (descrito posteriormente neste artigo). Nesse caso, uma operação DirectQuery envia uma consulta para o ponto de extremidade de análise do SQL. 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 de análise no formato Parquet. Esse formato de arquivo é otimizado para armazenar dados para modelos semânticos do Direct Lake. |
|
Um lakehouse do Fabric ou um warehouse do Fabric existe em um workspace que está na capacidade do Fabric. O lakehouse tem um ponto de extremidade de análise de SQL, que fornece uma experiência baseada em SQL para consulta. Tabelas (ou exibições) fornecem um meio de consultar as tabelas Delta no OneLake usando o T-SQL (Transact-SQL). |
|
Um modelo semântico do Direct Lake existe em um workspace do Fabric. Ele se conecta a tabelas ou exibições no lakehouse ou no warehouse. |
|
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 de arquivos Parquet armazenados no OneLake. As consultas alcançam o desempenho na memória, o que é muito rápido. |
|
O modelo semântico retorna os resultados da consulta. |
|
O relatório do Power BI renderiza os visuais. |
|
Em determinadas circunstâncias, como quando o modelo semântico excede os verificadores de integridade 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 de SQL do lakehouse ou do warehouse. |
|
As consultas DirectQuery enviadas ao ponto de extremidade de análise do 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 colunas, enquadramento, atualizações automáticas e fallback do DirectQuery.
Carregamento de coluna (transcodificação)
Os modelos semânticos do 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), ele primeiro determina quais colunas são necessárias para produzir um resultado de consulta. As colunas necessárias incluem todas as colunas que são 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 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 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 ela ser removida (removida) da memória. Os motivos pelos quais as colunas podem ser removidas incluem:
- O modelo ou a tabela foi atualizada (consulte Enquadramento na próxima seção).
- Nenhuma consulta usou a coluna por algum tempo.
- Outros motivos de gerenciamento de memória, incluindo a demanda de memória na capacidade devido a outras operações simultâneas.
Sua escolha de SKU do Fabric determina a memória máxima disponível para cada modelo semântico do Direct Lake na capacidade. Para obter mais informações sobre os verificadores de integridade de recursos e os limites máximos de memória, consulte Verificadores de integridade e limitações de capacidade do Fabric posteriormente 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 disparada por uma atualização de um modelo semântico e, na maioria dos casos, leva apenas alguns segundos para ser concluída. Isso acontece porque uma operação de baixo custo em que o modelo semântico analisa os metadados da versão mais recente das tabelas Delta Lake e é atualizado para referenciar os 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 se torna a nova linha de base para todos os eventos futuros de transcodificação. 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 momento 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 do Direct Lake funcionam.
O diagrama ilustra os seguintes processos e recursos.
| Item | Descrição |
|---|---|
|
|
Um modelo semântico existe 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 futuras. As operações de enquadramento podem ocorrer automaticamente, manualmente, no agendamento 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 futuros de transcodificação. |
|
|
As modificações de dados subsequentes, representadas por novos arquivos Parquet, não ficam 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 uma operação de transcodificação ocorre. Considere que o enquadramento pode ajudá-lo a fornecer resultados de consulta consistentes em ambientes em que os dados em tabelas Delta são transitórios. Os dados podem ser transitórios por vários motivos, como quando processos de ETL (extração, transformação e carregamento) de execução longa ocorrem.
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 Noções básicas sobre o armazenamento de 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. Ela 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 ao enquadrar, o que foi explicado na seção anterior. Para obter mais informações, consulte Gerenciar modelos semânticos do Direct Lake.
Dica
Você pode configurar a atualização automática de página em seus relatórios do Power BI. É um recurso que atualiza automaticamente uma página de relatório específica, desde que o relatório se conecte a um modelo semântico do Direct Lake (ou outros tipos de modelo semântico).
Fallback do DirectQuery
Uma consulta enviada a um modelo semântico do Direct Lake pode voltar ao modo DirectQuery. Nesse caso, ele recupera dados diretamente do ponto de extremidade de análise de SQL do lakehouse ou do warehouse. Essas consultas sempre retornam os dados mais recentes porque não estão restritos ao ponto no tempo da última operação de enquadramento.
Uma consulta sempre recua quando o modelo semântico consulta uma exibição no ponto de extremidade de análise do SQL ou uma tabela no ponto de extremidade de análise do SQL que impõe a RLS (segurança em nível de linha).
Além disso, uma consulta pode recuar quando o modelo semântico exceder os verificadores de integridade da capacidade.
Importante
Se possível, você sempre deve projetar sua solução (ou dimensionar sua capacidade) para evitar o fallback do DirectQuery. Isso ocorre porque pode resultar em um desempenho de consulta mais lento.
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.
Limitações e verificadores de integridade de capacidade do Fabric
Os modelos semânticos do Direct Lake exigem uma licença de capacidade do Fabric. Além disso, há limitações e verificadores de integridade de capacidade que se aplicam à sua SKU (assinatura de capacidade do Fabric), conforme apresentado na tabela a seguir.
Importante
A primeira coluna na tabela a seguir também inclui SKUs P (assinaturas de capacidade do Power BI Premium). Lembre-se de que a Microsoft está consolidando as opções de compra e desativando o Power BI Premium por SKUs capacidade. Em vez disso, os clientes novos e existentes devem considerar a compra de SKUs (assinaturas de capacidade do Fabric).
Para obter mais informações, consulte Atualização importante em breve no licenciamento do Power BI Premium e Power BI Premium.
| SKU do Fabric | Arquivos parquet por tabela | Grupos de linhas por tabela | Linhas por tabela (milhões) | Tamanho máximo do modelo em disco/OneLake (GB) | Memória máxima (GB) 1 |
|---|---|---|---|---|---|
| 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 para modelos semânticos do Direct Lake, Memória máxima representa o limite de recursos de memória superior para a quantidade de dados que podem ser paginado. Por esse motivo, não é um verificador de integridade porque exceder não resulta em um fallback para o modo DirectQuery; no entanto, ele poderá ter um impacto no desempenho se a quantidade de dados for grande o suficiente para causar paginação excessiva 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 para o modelo semântico retornem ao modo DirectQuery. Todos os outros verificadores de integridade apresentados na tabela são avaliados por consulta. Portanto, é importante otimizar suas tabelas Delta e o modelo semântico do Direct Lake para evitar a necessidade de escalar verticalmente de forma desnecessária para um SKU do Fabric mais alto (resultando em um custo maior).
Além disso, Unidade de capacidade e Memória máxima por limites de consulta se aplicam a modelos semânticos do Direct Lake. Para saber mais, confira Capacidades e SKUs.
Considerações e limitações
Os modelos semânticos do Direct Lake apresentam algumas considerações e limitações.
Observação
As funcionalidades e os recursos de modelos semânticos do Direct Lake estão evoluindo. Verifique periodicamente para examinar a lista mais recente de 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 do SQL que impõe a RLS (segurança em nível de linha), as consultas que envolvem essa tabela de modelos sempre voltarã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 modelos sempre voltarã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 Importação, DirectQuery ou Dual (exceto casos especiais, incluindo grupos de cálculo, parâmetros de teste de hipóteses 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. Não há suporte para Grupos de cálculo, parâmetros de teste de hipóteses e parâmetros de campo que criam implicitamente tabelas calculadas e para tabelas calculadas que não fazem referência a colunas ou tabelas do Direct Lake.
- As tabelas do modo de armazenamento Direct Lake não dão suporte a tipos de coluna de tabela Delta complexos. Também não há suporte para tipos semânticos binários e GUID. 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 colunas relacionadas correspondam.
- As colunas de relações de um lado devem conter valores exclusivos. As consultas falharão se forem detectados valores duplicados em uma coluna de um lado.
- Não há suporte para inteligência de dados temporais/dados automáticos 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 do ponto flutuante NaN (não é um número).
- Não há suporte para cenários de inserção que usam o cenário de uso Para seu cliente.
- Publicar na Web do Power BI só tem suporte 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 de usuário são consideradas corretas e nenhuma consulta é realizada para validar a cardinalidade ou 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ções lista apenas falhas de atualização relacionadas ao Direct Lake. As operações de atualização (enquadramento) bem-sucedidas não estão listadas.
- Seu SKU do Fabric determina a memória máxima disponível para cada modelo semântico do Direct Lake da capacidade. Quando o limite é excedido, as consultas para o 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 a partir deste Lakehouse na mesma região. Uma solução alternativa é criar um Lakehouse no workspace da outra região e usar atalho para as tabelas antes de criar o modelo semântico. Para encontrar em qual região você está, consulte encontrar sua região base do Fabric.
- Você pode criar e exibir um modelo semântico do Direct Lake personalizado usando uma identidade de entidade de serviço, mas o modelo semântico do Direct Lake padrão não dá suporte a entidades de serviço. Verifique se a autenticação da entidade de serviço está habilitada para APIs REST do Fabric em seu locatário e conceda ao colaborador da entidade de serviço ou permissões mais altas para o workspace do modelo semântico do Direct Lake.
- O Direct Lake não dá suporte a perfis de entidade de serviço para autenticação.
Comparação com outros modos de armazenamento
A tabela a seguir compara o modo de armazenamento Direct Lake com os modos de armazenamento de Importação e DirectQuery.
| Funcionalidade | Direct Lake | Importação | DirectQuery |
|---|---|---|---|
| Licenciamento | Somente SKUs (assinatura de capacidade do Fabric) | Qualquer licença do Fabric ou do Power BI (incluindo licenças grátis do Microsoft Fabric) | Qualquer licença do Fabric ou do Power BI (incluindo licenças grátis do Microsoft Fabric) |
| Fonte de dados | Apenas tabelas (ou exibições) de lakehouse ou warehouse | Qualquer conector | Qualquer conector que dê suporte ao modo DirectQuery |
| Conectar-se a exibições de ponto de extremidade de análise de SQL | Sim – mas retornará automaticamente ao modo DirectQuery | Sim | Sim |
| Modelos compostos | Não 1 | Sim – pode combinar com tabelas do modo de armazenamento DirectQuery ou Dual | Sim – pode combinar com tabelas do modo de armazenamento de Importação ou Dual |
| SSO (logon único) | Sim | Não Aplicável | Sim |
| Tabelas calculadas | Não – exceto grupos de cálculo, parâmetros de teste de hipóteses e parâmetros de campo, que criam tabelas calculadas de forma implícita | Sim | Não – tabelas calculadas usam o modo de armazenamento de Importação mesmo quando se referem a outras tabelas no modo DirectQuery |
| Colunas calculadas | Não | Sim | Sim |
| Tabelas híbridas | Não | Sim | Sim |
| Modelar partições de tabela | Não – no entanto, o particionamento pode ser feito no nível da tabela Delta | Sim – criado automaticamente por atualização incremental ou criado manualmente usando o ponto de extremidade XMLA | Não |
| Agregações definidas pelo usuário | Não | Sim | Sim |
| Segurança em nível de objeto ou segurança no nível da coluna do ponto de extremidade da análise de SQL | Sim – mas as consultas retornarão ao modo DirectQuery e poderão produzir erros quando a permissão for negada | Sim – mas deve duplicar permissões com segurança em nível de objeto do modelo semântico | Sim – mas as consultas podem produzir erros quando a permissão é negada |
| RLS (segurança em nível de linha) do ponto de extremidade da análise de SQL | Sim – mas as consultas retornarão ao modo DirectQuery | Sim – mas deve duplicar permissões com RLS do modelo semântico | Sim |
| RLS (segurança em nível de linha) do modelo semântico | Sim – mas é altamente recomendável usar uma conexão de nuvem de identidade fixa | Sim | Sim |
| OLS (segurança em nível de objeto) do modelo semântico | Sim | Sim | Sim |
| Grandes volumes de dados sem requisito de atualização | Sim | Menos adequado – um tamanho de capacidade maior pode ser necessário para consultar e atualizar | Sim |
| Reduzir latência de dados | Sim – quando atualizações automáticas estiver habilitada, ou reenquadrar programaticamente; no entanto, a preparação de dados deve ser feita upstream primeiro | Não | Sim |
1 Não é possível combinar tabelas de modo de armazenamento 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 Direct Lake e, em seguida, estendê-lo com novas tabelas (usando o modo de armazenamento de Importação, DirectQuery ou Dual) ou cálculos. Para obter mais informações, consulte Criar um modelo composto em um modelo semântico.