Atualização incremental e dados em tempo real para modelos semânticos

A atualização incremental e os dados em tempo real para modelos semânticos no Power BI fornecem maneiras eficientes de lidar com dados dinâmicos e melhorar o desempenho da atualização do modelo. Ao automatizar a criação e o gerenciamento de partições, a atualização incremental reduz a quantidade de dados que precisam ser atualizados e permite a inclusão de dados em tempo real. Este artigo explica como configurar e usar recursos de atualização incremental no Power BI para capturar dados em movimento rápido e aprimorar o desempenho.

A atualização incremental estende as operações de atualização agendadas fornecendo criação e gerenciamento automatizados de partições para tabelas de modelos semânticos que carregam frequentemente dados novos e atualizados. Para a maioria dos modelos, uma ou mais tabelas contêm dados de transação que mudam com frequência e podem crescer exponencialmente, como uma tabela de fatos em um esquema de banco de dados relacional ou em estrela. Uma política de atualização incremental para particionar a tabela, atualizar apenas as partições de importação mais recentes e, opcionalmente, usar outra partição DirectQuery para dados em tempo real pode reduzir significativamente a quantidade de dados que precisam ser atualizados. Ao mesmo tempo, essa política garante que as alterações mais recentes na fonte de dados sejam incluídas nos resultados da consulta.

Com atualização incremental e dados em tempo real:

• São necessários menos ciclos de atualização para dados em rápida mudança. O modo DirectQuery obtém as atualizações de dados mais recentes à medida que as consultas são processadas, sem exigir uma alta cadência de atualização.
• As atualizações são mais rápidas. Apenas os dados mais recentes que foram alterados precisam ser atualizados.
• As atualizações são mais confiáveis. Conexões de longa duração com fontes de dados voláteis não são necessárias. As consultas aos dados de origem são executadas mais rapidamente, reduzindo o potencial de interferência de problemas de rede.
• O consumo de recursos é reduzido. Menos dados a serem atualizados reduz o consumo geral de memória e outros recursos no Power BI e nos sistemas de fonte de dados.
• Modelos semânticos grandes estão habilitados. Modelos semânticos com potencialmente bilhões de linhas podem crescer sem a necessidade de atualizar totalmente o modelo inteiro a cada operação de atualização.
• A configuração é fácil. As políticas de atualização incremental são definidas no Power BI Desktop com apenas algumas tarefas. Quando o Power BI Desktop publica o relatório, o serviço aplica automaticamente essas políticas a cada atualização.

Quando você publica um modelo do Power BI Desktop no serviço, cada tabela no novo modelo tem uma única partição. Essa única partição contém todas as linhas dessa tabela. Se a tabela for grande, digamos, com dezenas de milhões de linhas ou mais, uma atualização para essa tabela pode levar muito tempo e consumir uma quantidade excessiva de recursos.

Com a atualização incremental, o serviço particiona e separa dinamicamente os dados que precisam ser atualizados com frequência dos dados que podem ser atualizados com menos frequência. Os dados da tabela são filtrados utilizando os parâmetros de data/hora do Power Query com os nomes RangeStart reservados que diferenciam maiúsculas de minúsculas e RangeEnd. Quando você configura a atualização incremental no Power BI Desktop, esses parâmetros são usados para filtrar apenas um pequeno período de dados carregados no modelo. Quando o Power BI Desktop publica o relatório no serviço do Power BI, com a primeira operação de atualização, o serviço cria partições históricas e de atualização incremental e, opcionalmente, uma partição DirectQuery em tempo real com base nas configurações de diretiva de atualização incremental. Em seguida, o serviço substitui os valores de parâmetro para filtrar e consultar dados para cada partição com base em valores de data/hora para cada linha.

A cada atualização subsequente, os filtros de consulta retornam apenas as linhas dentro do período de atualização definido dinamicamente pelos parâmetros. As linhas com uma data/hora dentro do período de atualização são atualizadas. As linhas com uma data/hora que não estão mais dentro do período de atualização passam a fazer parte do período histórico, que não é atualizado. Se uma partição DirectQuery em tempo real for incluída na política de atualização incremental, seu filtro também será atualizado para que ele retome todas as alterações que ocorrerem após o período de atualização. Tanto a atualização quanto os períodos históricos são rolados. À medida que novas partições de atualização incremental são criadas, as partições de atualização não mais no período de atualização se tornam partições históricas. Com o tempo, as partições históricas tornam-se menos granulares à medida que são fundidas. Quando uma partição histórica não está mais no período histórico definido pela política, ela é totalmente removida do modelo. Esse comportamento é conhecido como um padrão de janela rolante.

A beleza da atualização incremental é que o serviço lida com tudo isso para você com base nas políticas de atualização incremental que você define. Na verdade, o processo e as partições criadas a partir dele não são visíveis no serviço. Na maioria dos casos, uma política de atualização incremental bem definida é tudo o que é necessário para melhorar significativamente o desempenho de atualização do modelo. No entanto, a partição DirectQuery em tempo real só é suportada para modelos em capacidades Premium. O Power BI Premium também permite cenários de partição e atualização mais avançados por meio do ponto de extremidade XML for Analysis (XMLA).

Requisitos

As próximas seções descrevem os planos e fontes de dados suportados.

Planos suportados

A atualização incremental é suportada para os modelos Power BI Premium, Premium por utilizador, Power BI Pro e Power BI Embedded.

A obtenção dos dados mais recentes em tempo real com o DirectQuery só é suportada para os modelos Power BI Premium, Premium por utilizador e Power BI Embedded.

Supported data sources (Origens de dados suportadas)

A atualização incremental e os dados em tempo real funcionam melhor para fontes de dados relacionais estruturadas, como o Banco de Dados SQL e o Azure Synapse, mas também podem funcionar para outras fontes de dados. Em qualquer caso, sua fonte de dados deve suportar o seguinte:

Filtragem de data - A fonte de dados deve suportar algum mecanismo para filtrar dados por data. Para uma fonte relacional, normalmente é uma coluna de data do tipo de dados data/hora ou inteiro na tabela de destino. Os parâmetros RangeStart e RangeEnd, que devem ser o tipo de dados de data/hora, filtram os dados da tabela com base na coluna de data. Para colunas de data de chaves substitutas inteiras na forma de , você pode criar uma função que converta o valor de yyyymmdddata/hora nos parâmetros RangeStart e RangeEnd para corresponder às chaves substitutas inteiras da coluna de data. Para saber mais, consulte Configurar atualização incremental e dados em tempo real - Converter DateTime em inteiro.

Para outras fontes de dados, os parâmetros RangeStart e RangeEnd devem ser passados para a fonte de dados de alguma forma que permita a filtragem. Para fontes de dados baseadas em arquivos em que arquivos e pastas são organizados por data, os parâmetros RangeStart e RangeEnd podem ser usados para filtrar os arquivos e pastas para selecionar quais arquivos carregar. Para fontes de dados baseadas na Web, os parâmetros RangeStart e RangeEnd podem ser integrados à solicitação HTTP. Por exemplo, a consulta a seguir pode ser usada para atualização incremental dos rastreamentos de uma instância do AppInsights:

let 
    strRangeStart = DateTime.ToText(RangeStart,[Format="yyyy-MM-dd'T'HH:mm:ss'Z'", Culture="en-US"]),
    strRangeEnd = DateTime.ToText(RangeEnd,[Format="yyyy-MM-dd'T'HH:mm:ss'Z'", Culture="en-US"]),
    Source = Json.Document(Web.Contents("https://api.applicationinsights.io/v1/apps/<app-guid>/query", 
    [Query=[#"query"="traces 
    | where timestamp >= datetime(" & strRangeStart &") 
    | where timestamp < datetime("& strRangeEnd &")
    ",#"x-ms-app"="AAPBI",#"prefer"="ai.response-thinning=true"],Timeout=#duration(0,0,4,0)])),
    TypeMap = #table(
    { "AnalyticsTypes", "Type" }, 
    { 
    { "string",   Text.Type },
    { "int",      Int32.Type },
    { "long",     Int64.Type },
    { "real",     Double.Type },
    { "timespan", Duration.Type },
    { "datetime", DateTimeZone.Type },
    { "bool",     Logical.Type },
    { "guid",     Text.Type },
    { "dynamic",  Text.Type }
    }),
    DataTable = Source[tables]{0},
    Columns = Table.FromRecords(DataTable[columns]),
    ColumnsWithType = Table.Join(Columns, {"type"}, TypeMap , {"AnalyticsTypes"}),
    Rows = Table.FromRows(DataTable[rows], Columns[name]), 
    Table = Table.TransformColumnTypes(Rows, Table.ToList(ColumnsWithType, (c) => { c{0}, c{3}}))
in
Table

Quando a atualização incremental é configurada, uma expressão do Power Query que inclui um filtro de data/hora com base nos parâmetros RangeStart e RangeEnd é executada na fonte de dados. Se o filtro for especificado em uma etapa de consulta após a consulta de origem inicial, é importante que a dobragem da consulta combine a etapa de consulta inicial com as etapas que fazem referência aos parâmetros RangeStart e RangeEnd. Por exemplo, na expressão de consulta a seguir, Table.SelectRows será dobrado porque ele segue imediatamente a etapa e o SQL Server oferece suporte à Sql.Database dobragem:

let
  Source = Sql.Database("dwdev02","AdventureWorksDW2017"),
  Data  = Source{[Schema="dbo",Item="FactInternetSales"]}[Data],
  #"Filtered Rows" = Table.SelectRows(Data, each [OrderDateKey] >= Int32.From(DateTime.ToText(RangeStart,[Format="yyyyMMdd"]))),
  #"Filtered Rows1" = Table.SelectRows(#"Filtered Rows", each [OrderDateKey] < Int32.From(DateTime.ToText(RangeEnd,[Format="yyyyMMdd"])))
  
in
  #"Filtered Rows1"

Não há nenhum requisito para a consulta final para suportar dobragem. Por exemplo, na expressão a seguir, usamos um NativeQuery não dobrável, mas integramos os parâmetros RangeStart e RangeEnd diretamente no SQL:

let
  Query = "select * from dbo.FactInternetSales where OrderDateKey >= '"& Text.From(Int32.From( DateTime.ToText(RangeStart,"yyyyMMdd") )) &"' and OrderDateKey < '"& Text.From(Int32.From( DateTime.ToText(RangeEnd,"yyyyMMdd") )) &"' ",
  Source = Sql.Database("dwdev02","AdventureWorksDW2017"),
  Data = Value.NativeQuery(Source, Query, null, [EnableFolding=false])
in
  Data

No entanto, se a política de atualização incremental incluir a obtenção de dados em tempo real com o DirectQuery, as transformações não dobráveis não poderão ser usadas. Se for uma política de modo de importação pura sem dados em tempo real, o mecanismo de mashup de consulta pode compensar e aplicar o filtro localmente, o que requer a recuperação de todas as linhas da tabela da fonte de dados. Isso pode fazer com que a atualização incremental seja lenta e o processo pode ficar sem recursos no serviço do Power BI ou em um gateway de dados local - derrotando efetivamente a finalidade da atualização incremental.

Como o suporte para dobragem de consulta é diferente para diferentes tipos de fontes de dados, a verificação deve ser executada para garantir que a lógica do filtro seja incluída nas consultas que estão sendo executadas na fonte de dados. Na maioria dos casos, o Power BI Desktop tenta executar essa verificação para você ao definir a política de atualização incremental. Para fontes de dados baseadas em SQL, como Banco de Dados SQL, Azure Synapse, Oracle e Teradata, essa verificação é confiável. No entanto, outras fontes de dados podem não conseguir verificar sem rastrear as consultas. Se o Power BI Desktop não conseguir confirmar as consultas, um aviso será exibido na caixa de diálogo Configuração da política de atualização incremental.

Se vir este aviso e pretender verificar se a dobragem de consulta necessária está a ocorrer, utilize a funcionalidade Diagnóstico do Power Query ou rastreie consultas utilizando uma ferramenta suportada pela origem de dados, como o SQL Profiler. Se a dobragem da consulta não estiver ocorrendo, verifique se a lógica do filtro está incluída na consulta que está sendo passada para a fonte de dados. Caso contrário, é provável que a consulta inclua uma transformação que impeça a dobragem.

Antes de configurar a sua solução de atualização incremental, leia e compreenda cuidadosamente as orientações de dobragem de consultas no Power BI Desktop e na dobragem de consultas do Power Query. Estes artigos podem ajudá-lo a determinar se a fonte de dados e as consultas oferecem suporte à dobragem de consultas.

Fonte de dados única

Quando você configura a atualização incremental e os dados em tempo real usando o Power BI Desktop ou configura uma solução avançada usando TMSL (Tabular Model Scripting Language) ou TOM (Tabular Object Model) por meio do ponto de extremidade XMLA, todas as partições, sejam elas de importação ou DirectQuery, devem consultar dados de uma única fonte.

Outros tipos de fontes de dados

Usando mais funções de consulta personalizadas e lógica de consulta, a atualização incremental pode ser usada com outros tipos de fontes de dados se os filtros se basearem RangeStart e RangeEnd puderem ser passados em uma única consulta, como com fontes de dados como arquivos de pasta de trabalho do Excel armazenados em uma pasta, arquivos no SharePoint e feeds RSS. Tenha em mente que esses são cenários avançados que exigem mais personalização e testes além do descrito aqui. Certifique-se de verificar a seção Comunidade mais adiante neste artigo para obter sugestões sobre como você pode encontrar mais informações sobre como usar a atualização incremental para cenários exclusivos.

Prazos

Independentemente da atualização incremental, os modelos do Power BI Pro têm um limite de tempo de atualização de duas horas e não suportam a obtenção de dados em tempo real com o DirectQuery. Para modelos com capacidade Premium, o prazo é de cinco horas. As operações de atualização consomem muito processo e memória. Uma operação de atualização completa pode usar até o dobro da quantidade de memória exigida apenas pelo modelo, porque o serviço mantém um instantâneo do modelo na memória até que a operação de atualização seja concluída. As operações de atualização também podem ser intensivas em processos, consumindo uma quantidade significativa de recursos de CPU disponíveis. As operações de atualização também devem depender de conexões voláteis com fontes de dados e da capacidade desses sistemas de fonte de dados de retornar rapidamente a saída da consulta. O limite de tempo é uma salvaguarda para limitar o consumo excessivo dos recursos disponíveis.

Como a atualização incremental otimiza as operações de atualização no nível da partição no modelo, o consumo de recursos pode ser significativamente reduzido. Ao mesmo tempo, mesmo com a atualização incremental, a menos que passem pelo ponto de extremidade XMLA, as operações de atualização são limitadas por esses mesmos limites de duas horas e cinco horas. Uma política de atualização incremental eficaz não só reduz a quantidade de dados processados com uma operação de atualização, mas também reduz a quantidade de dados históricos desnecessários armazenados em seu modelo.

As consultas também podem ser limitadas por um limite de tempo padrão para a fonte de dados. A maioria das fontes de dados relacionais permite substituir limites de tempo na expressão Power Query M. Por exemplo, a expressão a seguir usa a função de acesso a dados do SQL Server para definir CommandTimeout como duas horas. Cada período definido pelos intervalos de política envia uma consulta observando a configuração de tempo limite do comando:

let
    Source = Sql.Database("myserver.database.windows.net", "AdventureWorks", [CommandTimeout=#duration(0, 2, 0, 0)]),
    dbo_Fact = Source{[Schema="dbo",Item="FactInternetSales"]}[Data],
    #"Filtered Rows" = Table.SelectRows(dbo_Fact, each [OrderDate] >= RangeStart and [OrderDate] < RangeEnd)
in
    #"Filtered Rows"

Para modelos muito grandes em capacidades Premium que provavelmente contêm bilhões de linhas, a operação de atualização inicial pode ser inicializada. O bootstrapping permite que o serviço crie objetos de tabela e partição para o modelo, mas não carrega e processa dados em nenhuma das partições. Usando o SQL Server Management Studio, você pode definir partições para serem processadas individualmente, sequencialmente ou em paralelo, para reduzir a quantidade de dados retornados em uma única consulta e também ignorar o limite de tempo de cinco horas. Para saber mais, consulte Atualização incremental avançada - Evitar tempos limite na atualização completa inicial.

Data e hora atuais

Por padrão, a data e a hora atuais são determinadas com base no Tempo Universal Coordenado (UTC) no momento da atualização. Para atualizações sob demanda e agendadas, você pode configurar um fuso horário diferente em 'Atualizar' que será levado em conta ao determinar a data e a hora atuais. Por exemplo, uma atualização que ocorre às 20:00, hora do Pacífico (EUA e Canadá) com um fuso horário configurado, determina a data e hora atuais com base na hora do Pacífico, não UTC, que retornaria no dia seguinte.

As operações de atualização não invocadas por meio do serviço do Power BI, como o comando XMLA TMSL refresh ou a API de atualização aprimorada, não consideram o fuso horário de atualização agendada configurado e o padrão para UTC.

Configurar atualização incremental e dados em tempo real

Esta seção descreve conceitos importantes de configuração de atualização incremental e dados em tempo real. Quando estiver pronto para obter instruções passo a passo mais detalhadas, consulte Configurar atualização incremental e dados em tempo real.

A configuração da atualização incremental é feita no Power BI Desktop. Para a maioria dos modelos, apenas algumas tarefas são necessárias. No entanto, tenha em consideração os seguintes pontos:

• Depois de publicar no serviço do Power BI, não pode publicar o mesmo modelo novamente a partir do Power BI Desktop. A republicação remove todas as partições e dados existentes já no modelo. Se você estiver publicando em uma capacidade Premium, as alterações subsequentes no esquema de metadados podem ser feitas com ferramentas como o ALM Toolkit de código aberto ou usando TMSL. Para saber mais, consulte Atualização incremental avançada - Implantação somente de metadados.
• Depois de publicar no serviço do Power BI, você não pode baixar o modelo de volta como um .pbix para o Power BI Desktop. Como os modelos no serviço podem crescer tanto, é impraticável baixá-los e abri-los em um computador desktop típico.
• Ao obter dados em tempo real com o DirectQuery, você não pode publicar o modelo em um espaço de trabalho não Premium. A atualização incremental com dados em tempo real só é suportada com o Power BI Premium.

Criar parâmetros

Para configurar a atualização incremental no Power BI Desktop, primeiro crie dois parâmetros de data/hora do Power Query com os nomes RangeStart reservados que diferenciam maiúsculas de minúsculas e RangeEnd. Esses parâmetros, definidos na caixa de diálogo Gerenciar Parâmetros no Editor do Power Query, são inicialmente usados para filtrar os dados carregados na tabela de modelo do Power BI Desktop para incluir apenas as linhas com data/hora dentro desse período. RangeStart representa a data/hora mais antiga ou mais antiga e RangeEnd representa a data/hora mais recente ou mais recente. Depois que o modelo é publicado no serviço RangeStart e RangeEnd são substituídos automaticamente pelo serviço para consultar dados definidos pelo período de atualização especificado nas configurações de diretiva de atualização incremental.

Por exemplo, a tabela de fonte de dados FactInternetSales tem uma média de 10.000 novas linhas por dia. Para limitar o número de linhas inicialmente carregadas no modelo no Power BI Desktop, especifique um período de dois dias entre RangeStart e RangeEnd.

Filtrar dados

Com os RangeStart parâmetros e RangeEnd definidos, você aplica filtros de data personalizados na coluna de data da tabela. Os filtros aplicados selecionam um subconjunto de dados que é carregado no modelo quando você seleciona Aplicar.

Com nosso exemplo FactInternetSales, depois de criar filtros com base nos parâmetros e aplicar etapas, dois dias de dados (cerca de 20.000 linhas) são carregados no modelo.

Definir policy

Depois que os filtros tiverem sido aplicados e um subconjunto de dados tiver sido carregado no modelo, você definirá uma política de atualização incremental para a tabela. Depois que o modelo é publicado no serviço, a política é usada pelo serviço para criar e gerenciar partições de tabela e executar operações de atualização. Para definir a política, use a caixa de diálogo Atualização incremental e dados em tempo real para especificar as configurações necessárias e opcionais.

Tabela

A caixa de listagem Selecionar tabela assume como padrão a tabela selecionada no modo Dados. Habilite a atualização incremental para a tabela com o controle deslizante. Se a expressão do Power Query para a tabela não incluir um filtro baseado nos RangeStart parâmetros e RangeEnd , a alternância não estará disponível.

Configurações necessárias

A configuração Arquivar dados começando antes da data de atualização determina o período histórico no qual as linhas com data/hora nesse período são incluídas no modelo, mais linhas para o período histórico incompleto atual, além de linhas no período de atualização até a data e hora atuais.

Por exemplo, se você especificar cinco anos, a tabela armazenará os últimos cinco anos inteiros de dados históricos em partições de ano. A tabela também incluirá linhas para o ano atual em partições de trimestre, mês ou dia, até e incluindo o período de atualização.

Para modelos com capacidades Premium, as partições históricas retroativas podem ser seletivamente atualizadas com uma granularidade determinada por essa configuração. Para saber mais, consulte Atualização incremental avançada - Partições.

A configuração Atualizar dados incrementalmente começando antes da data de atualização determina o período de atualização incremental no qual todas as linhas com data/hora nesse período são incluídas nas partições de atualização e atualizadas com cada operação de atualização.

Por exemplo, se você especificar um período de atualização de três dias, com cada operação de atualização, o serviço substituirá os RangeStart parâmetros e RangeEnd para criar uma consulta para linhas com data/hora dentro de um período de três dias, com o início e o término dependentes da data e hora atuais. As linhas com uma data/hora nos últimos três dias até a hora da operação de atualização atual são atualizadas. Com esse tipo de política, você pode esperar que nossa tabela de modelo FactInternetSales no serviço, que tem uma média de 10.000 novas linhas por dia, atualize cerca de 30.000 linhas a cada operação de atualização.

Especifique um período que inclua apenas o número mínimo de linhas necessárias para garantir relatórios precisos. Quando você define políticas para mais de uma tabela, os mesmos RangeStart parâmetros devem RangeEnd ser usados mesmo que diferentes períodos de armazenamento e atualização sejam definidos para cada tabela.

Configurações opcionais

A configuração Obter os dados mais recentes em tempo real com DirectQuery (somente Premium) permite buscar as alterações mais recentes da tabela selecionada na fonte de dados além do período de atualização incremental usando o DirectQuery. Todas as linhas com data/hora posterior ao período de atualização incremental são incluídas em uma partição DirectQuery e buscadas na fonte de dados com cada consulta de modelo.

Por exemplo, se essa configuração estiver habilitada, a cada operação de atualização, o serviço ainda substituirá os RangeStart parâmetros e RangeEnd para criar uma consulta para linhas com data/hora após o período de atualização, com o início dependente da data e hora atuais. As linhas com uma data/hora após a hora da operação de atualização atual também estão incluídas. Com esse tipo de política, a tabela de modelo FactInternetSales no serviço inclui as atualizações de dados mais recentes.

A configuração Somente dias completos de atualização garante que todas as linhas do dia inteiro sejam incluídas na operação de atualização. Essa configuração é opcional, a menos que você habilite a configuração Obter os dados mais recentes em tempo real com DirectQuery (somente Premium). Por exemplo, digamos que sua atualização está programada para ser executada às 4h00 todas as manhãs. Se novas linhas de dados aparecerem na tabela da fonte de dados durante essas quatro horas entre meia-noite e 4h00, você não deseja contabilizá-las. Algumas métricas de negócios, como barris por dia na indústria de petróleo e gás, não fazem sentido com dias parciais. Outro exemplo é a atualização de dados de um sistema financeiro em que os dados do mês anterior são aprovados no décimo segundo dia de calendário do mês. Você pode definir o período de atualização para um mês e agendar a execução da atualização no décimo segundo dia do mês. Com essa opção selecionada, ele atualizaria, por exemplo, os dados de janeiro em 12 de fevereiro.

Lembre-se de que, a menos que a atualização agendada esteja configurada para um fuso horário que não seja UTC, as operações de atualização no serviço são executadas sob a hora UTC, o que pode determinar a data efetiva e os períodos completos.

A configuração Detetar alterações de dados permite uma atualização ainda mais seletiva. Você pode selecionar uma coluna de data/hora usada para identificar e atualizar apenas os dias em que os dados foram alterados. Essa configuração pressupõe que essa coluna exista na fonte de dados, que normalmente é para fins de auditoria. Esta coluna não deve ser a mesma usada para particionar os dados com os RangeStart parâmetros e RangeEnd . O valor máximo desta coluna é avaliado para cada um dos períodos no intervalo incremental. Se ele não tiver mudado desde a última atualização, não há necessidade de atualizar o período, o que poderia reduzir ainda mais os dias atualizados incrementalmente de três para um.

O design atual requer que a coluna para detetar alterações de dados seja mantida e armazenada em cache na memória. As seguintes técnicas podem ser usadas para reduzir a cardinalidade e o consumo de memória:

• Persista apenas o valor máximo da coluna no momento da atualização, talvez usando uma função do Power Query.
• Reduza a precisão para um nível aceitável, tendo em conta os seus requisitos de frequência de atualização.
• Defina uma consulta personalizada para detetar alterações de dados usando o ponto de extremidade XMLA e evite persistir completamente o valor da coluna.

Em alguns casos, a ativação da opção Detetar alterações de dados pode ser aprimorada. Por exemplo, convém evitar a persistência de uma coluna de última atualização no cache na memória ou habilitar cenários em que uma tabela de configuração/instrução é preparada por processos ETL (extract-transform-load) para sinalizar apenas as partições que precisam ser atualizadas. Em casos como estes, para capacidades Premium, use TMSL e/ou TOM para substituir o comportamento de deteção de alterações de dados. Para saber mais, consulte Atualização incremental avançada - consultas personalizadas para detetar alterações de dados.

Publicar

Depois de configurar a política de atualização incremental, você publica o modelo no serviço. Quando a publicação estiver concluída, você poderá executar a operação de atualização inicial no modelo.

Para modelos publicados em espaços de trabalho atribuídos a capacidades Premium, se você acha que o modelo crescerá além de 1 GB, poderá melhorar o desempenho da operação de atualização e garantir que o modelo não exceda os limites máximos de tamanho habilitando a configuração de formato de armazenamento de modelo semântico grande antes de executar a primeira operação de atualização no serviço. Para saber mais, consulte Modelos grandes no Power BI Premium.

Atualizar

Depois de publicar no serviço, você executa uma operação de atualização inicial no modelo. Essa atualização deve ser uma atualização individual (manual) para que você possa monitorar o progresso. A operação de atualização inicial pode levar um bom tempo para ser concluída. Partições devem ser criadas, dados históricos carregados, objetos como relações e hierarquias construídos ou reconstruídos e objetos calculados recalculados.

As operações de atualização subsequentes, individuais ou agendadas, são muito mais rápidas porque apenas as partições de atualização incremental são atualizadas. Outras operações de processamento ainda devem ocorrer, como mesclagem de partições e recálculo, mas geralmente leva muito menos tempo do que a atualização inicial.

Atualização automática de relatórios

Para relatórios que usam um modelo com uma política de atualização incremental para obter os dados mais recentes em tempo real com o DirectQuery, é uma boa ideia habilitar a atualização automática de página em um intervalo fixo ou com base na deteção de alterações para que os relatórios incluam os dados mais recentes sem demora. Para saber mais, consulte Atualização automática de página no Power BI.

Atualização incremental avançada

Se o seu modelo estiver em uma capacidade Premium com um ponto de extremidade XMLA habilitado, a atualização incremental poderá ser estendida ainda mais para cenários avançados. Por exemplo, você pode usar o SQL Server Management Studio para exibir e gerenciar partições, inicializar a operação de atualização inicial ou atualizar partições históricas retroativas. Para saber mais, consulte Atualização incremental avançada com o ponto de extremidade XMLA.

Comunidade

O Power BI tem uma comunidade vibrante onde MVPs, profissionais de BI e colegas compartilham conhecimentos em grupos de discussão, vídeos, blogs e muito mais. Ao aprender sobre a atualização incremental, consulte estes recursos:

• Comunidade do Power BI
• Pesquisar "Atualização incremental do Power BI" no Bing
• Pesquisar "Atualização incremental de ficheiros" no Bing
• Pesquisar "Manter dados existentes usando atualização incremental" no Bing

Conteúdos relacionados

• Configurar atualização incremental para modelos semânticos
• Atualização incremental avançada com o ponto de extremidade XMLA
• Solucionar problemas de atualização incremental
• Atualização incremental para fluxos de dados