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 espaço de trabalho do Microsoft Fabric. Ele é otimizado para grandes volumes de dados que podem ser rapidamente carregados na memória a partir de tabelas Delta, que armazenam os seus dados em arquivos Parquet no OneLake— o único armazenamento para todos os dados analíticos. 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 Direct Lake de armazenamento para se conectar às tabelas ou vistas de um único Fabric lakehouse ou Fabric warehouse. Ambos os itens Fabric e modelos semânticos Direct Lake exigem uma licença de capacidade Fabric .
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 rápido desempenho de consulta (exceto no caso de fallback do DirectQuery , que é explicado mais adiante neste artigo).
No entanto, um modelo semântico Direct Lake difere de um modelo semântico Import 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 Import. Para um modelo semântico Direct Lake, uma atualização envolve uma operação de enquadramento (descrita mais à frente neste artigo), que pode levar alguns segundos para ser concluída. É uma operação de baixo custo onde 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. Em contraste, para um modelo semântico de importação, uma atualização produz uma cópia dos dados, o que pode levar tempo considerável e consumir recursos significativos de fonte de dados e capacidade (memória e CPU).
Observação
A atualização incremental para um modelo semântico Import 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 usam arquiteturas centradas no lago. 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 rápido desempenho da consulta são importantes para este caso de uso.
Observação
Os modelos semânticos Import e DirectQuery ainda são relevantes no Fabric e são a escolha certa de 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 depender da TI para adicionar novos elementos de dados.
Além disso, de 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 a integração com lakehouses por meio de atalhos, consultas SQL, blocos de anotações e muito mais. Recomendamos que você considere essa opção como uma maneira rápida de colher os benefícios do Fabric sem necessariamente ou imediatamente reprojetar 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 rapidamente os dados para usuários corporativos. Se suas tabelas Delta forem modificadas intermitentemente (e supondo que você já tenha feito a preparação de dados no data lake), você poderá depender de atualizações automáticas para reformular em resposta a essas modificações. Nesse caso, as consultas enviadas para o modelo semântico retornam os dados mais recentes. Esse recurso 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 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 T-SQL DML para armazéns do Fabric, fluxos de dados, pipelines e outras. 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, se um analista de autoatendimento não tiver permissões de gravação em um lakehouse gerenciado pela TI, o modo de armazenamento de importação pode ser uma escolha melhor. Isso porque ele oferece suporte à preparação de dados usando o Power Query, que é definido como parte do modelo semântico.
Certifique-se de levar em consideração sua de licença de capacidade de malha atual e as grades de proteção de capacidade de malha 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.
Dica
Recomendamos que você produza um protótipo — ou prova de conceito (POC) — para determinar se um modelo semântico Direct Lake é a solução certa e para mitigar riscos.
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 é 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.
Um modelo semântico Direct Lake também pode usar de fallback do DirectQuery , que envolve alternar perfeitamente para 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 pode ocorrer quando uma tabela Delta contém mais linhas de dados do que o suportado pela sua capacidade de malha (descrito mais adiante neste artigo). 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.
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 descreve as seguintes ações, processos e recursos do usuário.
| Número | 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 Direct Lake. |
|
Existe um lakehouse Fabric ou um armazém Fabric num espaço de trabalho com capacidade Fabric. O lakehouse tem um endpoint SQL de análise, 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 Transact-SQL (T-SQL). |
|
Existe um modelo semântico Direct Lake num espaço de trabalho Fabric. Ele se conecta a mesas ou vistas na casa do lago 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 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 um desempenho em memória, que é extremamente rápido. |
|
O modelo semântico retorna os resultados da consulta. |
|
O relatório do Power BI renderiza os elementos visuais. |
|
Em determinadas circunstâncias, como quando o modelo semântico excede as guarda-corpos da capacidade, as consultas de modelo semântico retornam automaticamente ao modo DirectQuery. Nesse modo, as consultas são enviadas para o endpoint de análise SQL do lakehouse ou warehouse. |
|
As consultas DirectQuery enviadas para o ponto de extremidade de análise SQL consultam, por sua vez, as tabelas Delta no OneLake. Por esse motivo, o desempenho da consulta pode ser mais lento do que o das consultas em memória. |
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 residente na memória. Consultas futuras que envolvem apenas colunas residentes não precisam carregar mais colunas em memória.
Uma coluna permanece residente até que haja motivo para ser removida (desalojada) 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 diretrizes de proteção de recursos e limites máximos de memória, consulte Limites e restrições de capacidade de infraestrutura 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 a moldagem ocorre, os segmentos de coluna e os dicionários da tabela residente podem ser removidos da memória se os dados subjacentes tiverem sido alterados e o momento da atualização se tornar a nova referência base para todos os eventos de transcodificação futuros. 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 mais recente. Esse momento não é necessariamente o estado mais recente das tabelas Delta.
Observe que 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 de. 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 arquivos Parquet adicionados após a última operação de enquadramento. |
|
|
As colunas residentes no modelo semântico 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. |
|
|
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.
Para obter mais informações sobre controle de versão e enquadramento de tabelas Delta, consulte Compreender o armazenamento para modelos semânticos 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.
Dica
Você pode configurar de 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 Direct Lake (ou outros tipos de modelo semântico).
Fallback do DirectQuery
Uma consulta enviada para um modelo semântico Direct Lake pode retornar ao modo DirectQuery . Neste caso, ele recupera dados diretamente do ponto de extremidade de análise SQL do data lakehouse ou armazém de dados. Tais consultas retornam sempre os dados mais recentes porque não estão limitadas ao momento da última ação de enquadramento.
Uma consulta sempre retorna 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 segurança em nível de linha (RLS).
Além disso, uma consulta pode retroceder quando o modelo semântico exceder os limites da capacidade.
Importante
Se possível, você deve sempre projetar sua solução — ou dimensionar sua capacidade — para evitar fallback do DirectQuery. Isso porque isso pode resultar em um desempenho de consulta mais lento.
Você pode controlar o fallback dos seus modelos semânticos Direct Lake configurando a propriedade DirectLakeBehavior. Para obter mais informações, consulte Definir a propriedade de comportamento Direct Lake.
Grades de proteção e limitações da capacidade da malha
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.
Importante
A primeira coluna da tabela a seguir também inclui assinaturas de capacidade do Power BI Premium (SKUs P). Lembre-se de que a Microsoft está consolidando opções de compra e descontinuando as SKUs do Power BI Premium por capacidade. Em vez disso, os clientes novos e existentes devem considerar a compra de assinaturas de capacidade de Fabric (SKUs F).
Para obter mais informações, consulte Atualização importante para o licenciamento do Power BI Premium e Power BI Premium.
| Tecido SKU | Arquivos de parquet por tabela | Grupos de linhas por tabela | Linhas por tabela (milhões) | Tamanho máximo do modelo no 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 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 um limite de segurança porque ultrapassá-lo não resulta em um retrocesso para o modo DirectQuery; no entanto, isto pode ter um impacto no desempenho se a quantidade de dados for suficientemente grande para causar paginação excessiva na 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. Todos os outros guarda-corpos apresentados na tabela são avaliados a cada consulta. Portanto, é importante que se otimizem as suas tabelas Delta e modelo semântico Direct Lake para evitar fazer uma escalada desnecessária para um SKU do Fabric mais alto (resultando em maior custo).
Além disso, de unidade de capacidade e limites de memória máxima por consulta se aplicam 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.
Observação
As capacidades e características dos modelos semânticos Direct Lake estão evoluindo. Certifique-se de consultar periodicamente a lista mais recente de considerações e limitações.
- Quando uma tabela de modelo semântico Direct Lake se conecta a uma tabela no ponto de extremidade de análise SQL que impõe segurança em nível de linha (RLS), 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 Direct Lake se conecta a uma vista no endpoint de análise SQL, as consultas que envolvem essa tabela de modelo sempre reverterã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éticose 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. Os grupos de cálculo, os parâmetros hipotéticose os parâmetros de campo, que criam tabelas calculadas de forma implícita, bem como as tabelas calculadas que não fazem referência a colunas ou tabelas Direct Lake, são suportados.
- As tabelas do modo de armazenamento 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 das colunas relacionadas correspondam.
- As colunas unilaterais de relações devem conter valores exclusivos. As consultas falham se valores duplicados são detetados em uma coluna de um lado.
- A inteligência automática de dados/tempo no Power BI Desktop não tem suporte. Há suporte para marcar sua própria tabela de data como uma tabela de data.
- O comprimento dos valores de coluna de cadeia de caracteres é limitado a 32.764 caracteres Unicode.
- O valor de ponto flutuante NaN (não um número) não é suportado.
- Publicar na Web a partir do Power BI usando uma entidade de serviço só é suportado ao usar uma identidade fixa para o modelo semântico Direct Lake.
- Na experiência de modelação web, a validação é limitada para modelos semânticos Direct Lake. As seleções de usuário são consideradas corretas e nenhuma consulta é emitida para validar cardinalidade ou seleções de filtro cruzado para relacionamentos 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 as falhas de atualização relacionadas ao Direct Lake. As operações de atualização (enquadramento) bem-sucedidas não são listadas.
- O SKU de malha determina a memória máxima disponível por modelo semântico 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 Direct Lake em um espaço de trabalho que esteja em uma região diferente do espaço de trabalho da fonte de dados. Por exemplo, se a Lakehouse estiver no Centro-Oeste dos EUA, você só poderá criar modelos semânticos a partir dessa Lakehouse na mesma região. Uma solução alternativa é criar um Lakehouse no espaço de trabalho da outra região e criar ligações para as tabelas antes de criar o modelo semântico. Para descobrir em que região está, consulte para encontrar a sua região de origem do Fabric.
- Você pode criar e exibir um modelo semântico personalizado do Direct Lake usando uma identidade da Entidade de Serviço, mas o modelo semântico Direct Lake padrão não oferece suporte a Entidades de Serviço. Verifique se a autenticação do principal de serviço está habilitada para as APIs REST do Fabric no seu locatário e conceda ao principal de serviço permissões de Contribuinte ou superiores para o espaço de trabalho do seu modelo semântico Direct Lake.
- A incorporação de relatórios requer um token de incorporação V2.
- O Direct Lake não oferece suporte a perfis de entidade de serviço para autenticação.
- Há suporte para modelos semânticos personalizados do Direct Lake criados pela Entidade de Serviço e pelo visualizador com a Entidade de Serviço, mas os modelos semânticos Direct Lake padrão não são suportados.
Comparação com outros modos de armazenamento
A tabela a seguir compara o modo de armazenamento Direct Lake com os modos de armazenamento Import e DirectQuery.
| Capacidade | Lago Direto | Importação | DirectQuery |
|---|---|---|---|
| Licenciamento | Somente assinatura de capacidade de malha (SKUs) | Qualquer licença do Fabric ou do Power BI (incluindo licenças do Microsoft Fabric Free) | Qualquer licença do Fabric ou do Power BI (incluindo licenças do Microsoft Fabric Free) |
| Fonte de dados | Apenas mesas de lago ou armazém (ou vistas) | Qualquer conector | Qualquer conector que suporte o modo DirectQuery |
| Conectar-se às visualizações do ponto final de análise SQL | Sim, mas voltará automaticamente ao modo DirectQuery | Sim | Sim |
| Modelos compósitos | N.º 1 | Sim – pode combinar com tabelas de modo de armazenamento DirectQuery ou Dual | Sim, pode ser combinado com tabelas no modo de armazenamento Import ou Dual. |
| Logon único (SSO) | Sim | Não aplicável | Sim |
| Tabelas calculadas | Não – exceto os grupos de cálculo , os parâmetros hipotéticos e os parâmetros de campo , os quais criam implicitamente tabelas calculadas. | Sim | Não – as tabelas calculadas usam o modo de armazenamento Importar mesmo quando se referem a outras tabelas no modo DirectQuery |
| Colunas calculadas | Não | Sim | Sim |
| Tabelas híbridas | Não | Sim | Sim |
| Partições de tabela modelo | Não – no entanto, o particionamento pode ser realizado ao 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 a nível de objeto no endpoint de análises SQL ou segurança a nível de coluna | Sim, mas as consultas voltarão ao modo DirectQuery e poderão produzir erros quando a permissão for negada | Sim – mas deve duplicar permissões com segurança no nível de objeto do modelo semântico | Sim, mas as consultas podem produzir erros quando a permissão é negada |
| Segurança de nível de linha (RLS) do ponto de extremidade de análises SQL | Sim, mas as consultas voltarão ao modo DirectQuery | Sim – mas deve duplicar permissões com o modelo semântico RLS | Sim |
| Segurança em nível de linha (RLS) do modelo semântico | Sim, mas é altamente recomendável usar uma identidade fixa conexão de nuvem | Sim | Sim |
| Modelo semântico de segurança em nível de objeto (OLS) | Sim | Sim | Sim |
| Grandes volumes de dados sem necessidade de atualização | Sim | Menos adequado – pode ser necessário um tamanho de capacidade maior para consultar e atualizar | Sim |
| Reduza a latência dos dados | Sim – quando atualizações automáticas estão ativadas, ou reenquadramento programático; no entanto, a preparação de dados deve ser realizada a montante primeiro. | Não | Sim |
| Power BI incorporado | Sim 2 | Sim | Sim |
1 Não é possível combinar tabelas de modo de armazenamento Direct Lake com tabelas de 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.
2 Requer um token de incorporação V2. Se estiver a utilizar uma entidade de serviço, tem de utilizar uma ligação à nuvem com uma identidade fixa .