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 os 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 os recursos de atualização incremental no Power BI para capturar dados de rápida movimentação e melhorar o desempenho.

A atualização incremental estende as operações de atualização agendadas fornecendo a criação e o gerenciamento automáticos de partições para tabelas de modelos semânticos que frequentemente carregam dados novos e atualizados. Para a maioria dos modelos, uma ou mais tabelas contêm dados de transação que podem ser alterados 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, atualizando apenas as partições de importação mais recentes e, opcionalmente, usando 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 a atualização incremental e os dados em tempo real:

• São necessários menos ciclos de atualização para dados que mudam rapidamente. 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. Somente os dados alterados mais recentemente precisam ser atualizados.
• As atualizações são mais confiáveis. As conexões de longa execução para 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 problemas de rede para interferir.
• O consumo de recursos é reduzido. Um número menor de dados para atualização reduz o consumo geral da memória e de outros recursos no Power BI e no sistema da fonte de dados.
• Modelos semânticos grandes estão habilitados. Os modelos semânticos com bilhões de linhas podem crescer sem a necessidade de atualizar totalmente todo o modelo semântico com cada operação de atualização.
• A instalação é fácil. As políticas de atualização incremental são definidas no Power BI Desktop com apenas algumas tarefas. Quando Power BI Desktop publica o relatório, o serviço aplica automaticamente essas políticas a cada atualização.

Quando você publica um modelo de Power BI Desktop para o serviço, cada tabela no novo modelo tem uma única partição. Essa partição única 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 dessa tabela poderá 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 a partir de dados que podem ser atualizados com menos frequência. Os dados da tabela são filtrados usando parâmetros de data/hora do Power Query com os nomes reservados que diferenciam maiúsculas de minúsculas RangeStart 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 Power BI, com a primeira operação de atualização, o serviço cria atualizações incrementais e partições históricas e, opcionalmente, uma partição do DirectQuery em tempo real com base nas configurações de política de atualização incremental. O serviço então substitui os valores dos parâmetros para filtrar e consultar os dados de cada partição com base nos valores de data/hora de cada linha.

Com cada atualização subsequente, os filtros da consulta retornam somente as linhas dentro do período de atualização definido dinamicamente pelos parâmetros. Essas linhas com uma data/hora dentro do período de atualização são atualizadas. As linhas com uma data/hora não estão mais no período de atualização se tornam parte do período histórico, o qual não é atualizado. Se uma partição em tempo real do DirectQuery estiver incluída na política de atualização incremental, seu filtro também será atualizado para que ele pegue as alterações que ocorreram após o período de atualização. Os períodos de atualização e históricos são rolados para frente. À medida que novas partições de atualização incremental são criadas, as partições de atualização que não estão mais no período de atualização se tornam partições históricas. Ao longo do tempo, as partições históricas se tornam menos granulares à medida que são mescladas. 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 padrão de janela rolante.

A beleza da atualização incremental consiste no fato de que o serviço cuida de tudo com base nas políticas de atualização incremental definidas por você. Na verdade, o processo e as partições criadas a partir dele não estã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 da atualização do modelo. No entanto, a partição do DirectQuery em tempo real tem suporte apenas para modelos em capacidades Premium. Power BI Premium também permite cenários mais avançados de partição e atualização por meio do ponto do Ponto de extremidade de XMLA (XML for Analysis).

Requisitos

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

Planos com suporte

Há suporte para a atualização incremental para modelos de Power BI Premium, Premium por usuário, Power BI Pro e Power BI Embedded.

A obtenção dos dados mais recentes em tempo real com o DirectQuery só tem suporte para modelos do Power BI Premium, Premium por usuário e Power BI Embedded.

Fontes de dados com suporte

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

Filtragem de data: a fonte de dados deve oferecer suporte a algum mecanismo para filtrar dados por data. Quanto a 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 do tipo de dados data/hora, filtram os dados da tabela com base na coluna de data. Para colunas de data de chaves alternativas de inteiros na forma de yyyymmdd, você pode criar uma função que converte o valor de data/hora nos parâmetros RangeStart e RangeEnd para corresponder à chave alternativa de inteiro da coluna de dados. Para saber mais, consulte Configurar a atualização incremental e os dados em tempo real – Converter o DateTime em inteiro.

Em 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. Em fontes de dados baseadas em arquivo, 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. Quanto às 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 o desdobramento da consulta combine a etapa de consulta inicial com as etapas que referenciam os parâmetros RangeStart e RangeEnd. Por exemplo, na seguinte expressão de consulta, Table.SelectRows será dobrada porque ela segue imediatamente a etapa Sql.Database, e o SQL Server dá suporte à 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á requisitos da consulta final para dar suporte à 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, transformações sem dobragem 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 poderá 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 possa ficar sem recursos no serviço do Power BI ou em um gateway de Dados Local, prejudicando a finalidade da atualização incremental.

Como o suporte para a dobragem de consultas é diferente para tipos distintos de fontes de dados, a verificação deve ser executada para garantir que a lógica de 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 com base em SQL, como o SQL Database, o Azure Synapse, o Oracle e o Teradata, essa verificação é confiável. Outras fontes de dados talvez não consigam realizar a verificação sem o rastreamento de consultas. Se o Power BI Desktop não puder confirmar as consultas, um aviso será exibido na caixa de diálogo de configuração da política de atualização incremental.

Se você vir esse aviso e quiser verificar se a dobragem de consultas necessária está ocorrendo, use o recurso de Diagnóstico do Power Query ou consultas de rastreamento usando uma ferramenta com suporte da fonte de dados, como o SQL Profiler. Se a dobragem de consultas 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 sua solução de atualização incremental, leia e entenda detalhadamente Diretrizes de dobragem de consultas no Power BI Desktop e Dobragem de consultas do Power Query. Esses artigos podem ajudar você a determinar se a fonte de dados e as consultas dão suporte à dobragem de consultas.

Fonte de dados única

Ao configurar dados incrementais de atualização e em tempo real usando o Power BI Desktop ou configurar uma solução avançada usando a TMSL (Linguagem de Scripts do Modelo de Tabela) ou o TOM (Modelo de Objeto Tabular) por meio do ponto de extremidade XMLA, todas as partições de importação ou DirectQuery devem consultar dados de uma única fonte.

Outros tipos de fontes de dados

Ao usar funções e lógica de consulta mais personalizadas, a atualização incremental pode ser usada com outros tipos de fontes de dados se os filtros forem baseados em RangeStart e RangeEnd puder ser passado em uma única consulta, como com fontes de dados como arquivos de pasta de trabalho do Excel armazenados em uma pasta, arquivos em SharePoint e feeds RSS. Lembre-se que esses são cenários avançados que exigm personalização e testes adicionais além do que é descrito aqui. Verifique a seção Comunidade mais adiante neste artigo para obter sugestões de como saber mais sobre como usar a atualização incremental para cenários exclusivos.

Limites de tempo

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 dão suporte à obtenção de dados em tempo real com o DirectQuery. Para modelos em uma capacidade Premium, o limite de tempo é de cinco horas. As operações de atualização são intensivas no processo e na memória. Uma operação de atualização completa pode chegar a usar até o dobro da quantidade de memória exigida pelo modelo apenas 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 de processamento, consumindo uma quantidade significativa de recursos de CPU disponíveis. As operações de atualização também devem contar com conexões voláteis com fontes de dados e com a capacidade desses sistemas de fonte de dados de retornar rapidamente o resultado da consulta. O limite de tempo é uma proteção para limitar o consumo excessivo de seus recursos disponíveis.

Como a atualização incremental otimiza as operações de atualização no nível de partição no modelo, o consumo de recursos pode ser reduzido significativamente. Ao mesmo tempo, mesmo com atualização incremental, a menos que passem pelo ponto de extremidade XMLA, as operações de atualização são vinculadas aos mesmos limites de duas e cinco horas. Uma política de atualização incremental efetiva não apenas 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 no seu modelo.

As consultas também podem ser limitadas por um limite de tempo padrão da fonte de dados. A maioria das fontes de dados relacionais permite a substituição dos limites de tempo na expressão Power Query M. Por exemplo, a expressão a seguir usa a Função de acesso aos dados do SQL Server para definir o 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. A inicialização permite ao serviço criar objetos de tabela e de partição para o modelo, mas não carregar e processar dados em qualquer uma das partições. Usando o SQL Server Management Studio, você pode definir partições para processamento individual, sequencial ou em paralelo a fim de reduzir a quantidade de dados retornados em uma única consulta, além de ignorar o limite de tempo de cinco horas. Para saber mais, confira Atualização incremental avançada –Impedir 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 UTC (Tempo Universal Coordenado) no momento da atualização. Quanto às 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 20h, horário do Pacífico (EUA e Canadá) com um fuso horário configurado, determina a data e hora atuais com base no horário do Pacífico, não no UTC (horário universal coordenado), que retornaria o dia seguinte.

As operações de atualização não invocadas pelo serviço do Power BI, como o Comando de atualização TMSL do XMLA ou API de atualização aprimorada, não considere o fuso horário de atualização agendado configurado e o padrão para UTC.

Configurar a atualização incremental e os dados em tempo real

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

A configuração da atualização incremental é feita no Power BI Desktop. A maioria dos modelos requer apenas algumas tarefas. No entanto, tenha os seguintes pontos em mente:

• Depois de publicar no serviço Power BI, não é possível publicar o mesmo modelo novamente no Power BI Desktop. A republicação remove todas as partições e dados existentes no modelo. Se você estiver publicando em uma capacidade Premium, as alterações de esquema de metadados subsequentes poderão ser feitas com ferramentas como o ALM Toolkit de código aberto ou usando TMSL. Para saber mais, confira 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 aumentar muito, baixá-los e abri-los em um computador desktop típico é impraticável.
• Ao obter dados em tempo real com o DirectQuery, não é possível publicar o modelo em um workspace não Premium. A atualização incremental com dados em tempo real só tem suporte com 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 reservados e com distinção entre maiúsculas e minúsculas RangeStart e RangeEnd. Esses parâmetros, definidos na caixa de diálogo Gerenciar Parâmetros no Editor do Power Query, são usados inicialmente para filtrar os dados carregados na tabela de modelo do Power BI Desktop para incluir somente as linhas com uma data/hora dentro desse período. RangeStart representa a data/hora mais antiga e RangeEnd representa a data/hora mais recente. Depois que o modelo é publicado no serviço, RangeStart e RangeEnd são substituídos automaticamente pelo serviço para consultar os dados definidos pelo período de atualização especificado nas configurações de política de atualização incremental.

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

Filtrar dados

Com os parâmetros RangeStart e RangeEnd definidos, você aplica filtros de data personalizados na coluna de data de sua tabela. Os filtros que você aplica selecionam um subconjunto de dados que são carregados no modelo quando você seleciona Aplicar.

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

Definir a política

Depois que os filtros forem aplicados e um subconjunto de dados for 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, você usará a caixa de diálogo Dados de atualização incremental e em tempo real para especificar as configurações obrigatórias e opcionais.

Tabela

A caixa de listagem Selecionar tabela usa como padrão a tabela selecionada na exibição de 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 com base nos parâmetros RangeStart e RangeEnd, a alternância não estará disponível.

Configurações necessárias

A configuração Arquivar dados com início antes da data de atualização determina o período histórico no qual as linhas com uma data/hora nesse período são incluídas no modelo, além de linhas para o período histórico incompleto atual, além das 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 de dados históricos inteiros em partições do ano. A tabela também incluirá linhas para o ano atual em partições de trimestre, mês ou dia, inclusive/até o período de atualização.

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

A configuração Atualizar de forma incremental os dados com início antes da data de atualização determina o período de atualização incremental no qual todas as linhas com uma 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, a cada operação de atualização, o serviço substituirá os parâmetros RangeStart e RangeEnd para criar uma consulta de linhas com data/hora em um período de três dias, com início e término dependentes do data e hora atual. 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, espera-se como resultado nossa tabela de modelo FactInternetSales no serviço, que calcula a média de 10 mil novas linhas por dia, atualizará aproximadamente 30 mil linhas com cada operação de atualização.

Especifique um período que inclua apenas o número mínimo de linhas necessárias para garantir um relatório preciso. Ao definir políticas para mais de uma tabela, os mesmos parâmetros RangeStart e RangeEnd devem 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 o 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 uma data/hora posterior ao período de atualização incremental são incluídas em uma partição do DirectQuery e buscadas da fonte de dados com cada consulta do modelo.

Por exemplo, se essa configuração estiver habilitada, a cada operação de atualização, o serviço ainda substituirá os parâmetros RangeStart e RangeEnd para criar uma consulta de linhas com uma 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 são incluídas. Com esse tipo de política, a tabela do modelo FactInternetSales no serviço inclui as atualizações de dados mais recentes.

A configuração Atualizar apenas dias completos 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 o DirectQuery (somente Premium). Por exemplo, digamos que sua atualização esteja agendada para ser executada às 04h00, todas as manhãs. Se novas linhas de dados aparecerem na tabela de fonte de dados durante essas quatro horas, entre a meia-noite e às 04h00, você não quer considerá-las. Algumas métricas de negócios, como barris por dia no setor de petróleo e gás, não fazem sentido com dias parciais. Outro exemplo é a atualização de dados de um sistema financeiro no qual os dados do mês anterior são aprovados no décimo segundo dia do mês. Você pode definir o período de atualização para um mês e agendar a atualização para ser executada no décimo segundo dia do mês. Com essa opção selecionada, os dados de janeiro seriam atualizados em 12 de fevereiro.

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

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

O projeto atual requer que a coluna que detecta alterações nos dados seja persistente e fique armazenada em cache na memória. As técnicas a seguir 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.
• Reduzir a precisão a um nível aceitável considerando seus requisitos de frequência de atualização.
• Definir uma consulta personalizada para detectar alterações de dados usando o ponto de extremidade XMLA e evitar persistir o valor da coluna inteiramente.

Em alguns casos, a habilitação da opção Detectar alterações de dados pode ser aprimorada. Por exemplo, você pode querer evitar a persistência de uma coluna da última atualização no cache na memória ou ativar cenários em que uma tabela de configuração/instrução seja preparada por processos ETL (extract-transform-load) para sinalizar apenas as partições que precisam ser atualizadas. Em casos como esses, em capacidades Premium, use TMSL e/ou TOM para substituir o comportamento de detecção de alterações de dados. Para saber mais, confira Atualização incremental avançada –Consultas personalizadas para detectar alterações de dados.

Publicação

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

Quanto aos modelos publicados nos espaços de trabalho atribuídos às capacidades Premium, se você achar 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 ultrapasse os limites de tamanho ativando 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, confira Modelos grandes no Power BI Premium.

Atualizar

Após publicar no serviço, você executa uma operação de atualização inicial no modelo. Essa atualização deve ser individual (manual) para que você possa monitorar o progresso. A operação de atualização inicial pode demorar algum tempo para ser concluída. Partições devem ser criadas, dados históricos carregados, objetos como relacionamentos 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 mesclar partições e recálculo, mas geralmente leva muito menos tempo do que a atualização inicial.

Atualização automática do relatório

Em 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, é recomendável habilitar a atualização automática de página em um intervalo fixo ou com base na detecção de alterações para que os relatórios incluam os dados mais recentes sem atraso. Para saber mais, confira Atualização automática de página no Power BI.

Atualização incremental avançada

Se o modelo estiver em uma capacidade Premium com o ponto de extremidade XMLA habilitado, a atualização incremental poderá ser estendida 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 as partições históricas retroativas. Para saber mais, confira Atualização incremental avançada com o ponto de extremidade XMLA.

Comunidade

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

• Comunidade do Power BI
• Pesquise "Atualizações incrementais do Power BI" no Bing
• Pesquise "Atualizações incrementais para arquivos" no Bing
• Pesquise "Manter dados existentes usando a atualização incremental" no Bing

Conteúdo relacionado

• 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