Há um momento na vida de quase todos os relatórios de Power BI bem-sucedidos em que o sucesso se vira contra eles. O relatório é útil, as pessoas usam-no, os dados acumulam-se — e um dia a atualização, que antes era rápida, começa a demorar uma eternidade. Recarregar anos de histórico todas as noites torna-se um peso insustentável: horas de processamento, uma carga enorme sobre a base de dados de origem, e o risco constante de a atualização falhar por ser grande demais. A boa notícia é que o Power BI tem uma resposta desenhada exatamente para este problema, e chama-se incremental refresh, ou atualização incremental.
A ideia é tão simples que parece óbvia depois de a ouvir: se os dados antigos já não mudam, porque é que os recarregamos todas as noites? As vendas de há três anos são o que são — não vão mudar. E, no entanto, a configuração por omissão do Power BI recarrega tudo, sempre, do princípio. A atualização incremental corrige este desperdício, atualizando apenas a fatia recente que ainda muda e deixando o histórico estável intocado. É uma daquelas funcionalidades que separam quem faz relatórios de quem constrói soluções que aguentam o crescimento.
O problema da atualização total
Quando um relatório importa dados, o comportamento normal é substituir tudo a cada atualização. Com poucos dados, isto é instantâneo e ninguém repara. Mas à medida que o histórico cresce — de meses para anos, de milhares para milhões de linhas — o tempo de atualização cresce com ele, de forma linear e implacável. O que começou por demorar dois minutos passa a demorar duas horas, e essa janela começa a colidir com o início do dia de trabalho ou a esgotar os limites de tempo do serviço.
Há ainda um custo escondido do lado da origem. Cada atualização total volta a pedir à base de dados operacional que devolva todo o histórico — precisamente a base de dados que está a ser usada para gerir o negócio. Fazer isto todas as noites sobre volumes grandes sobrecarrega o sistema de origem no pior momento e transforma o relatório de BI num vizinho indesejável para os sistemas que o alimentam. A atualização total não é só lenta; é pesada para toda a gente.
A ideia central: separar o que muda do que já não muda
A atualização incremental divide os dados em duas zonas. Há uma zona histórica, mais antiga, que já está estável e não precisa de ser tocada — as vendas do ano passado, por exemplo. E há uma zona recente, dos últimos dias ou semanas, onde os dados ainda podem chegar ou ser corrigidos. A cada atualização, o Power BI recarrega apenas a zona recente e deixa a histórica exatamente como estava. Como a zona recente é uma fração minúscula do total, a atualização passa de horas a minutos.
Por baixo, o Power BI implementa isto particionando a tabela por períodos de tempo. Cada partição — cada mês, por exemplo — é carregada uma vez e depois congelada; só as partições mais recentes são reprocessadas. O utilizador final não vê nada disto: continua a ver o relatório completo, com todo o histórico. A diferença está toda nos bastidores, na quantidade de trabalho que a atualização evita fazer sem necessidade.
O que é preciso para a configurar
- Uma coluna de data fiável: a atualização incremental precisa de saber a que período pertence cada linha, por isso exige uma coluna de data em que se possa confiar.
- Filtros dinâmicos de intervalo: definem-se dois parâmetros que marcam quanto histórico guardar e que janela recente reprocessar a cada atualização.
- Uma fonte que aceite filtrar à entrada: para o ganho ser real, a origem tem de conseguir devolver só o período pedido, em vez de tudo — senão poupa-se pouco.
O ganho vai além da velocidade
O benefício óbvio é o tempo de atualização, que cai drasticamente. Mas há ganhos que se somam a esse. A carga sobre a base de dados de origem desce na mesma proporção, aliviando os sistemas operacionais. As atualizações tornam-se mais fiáveis, porque um trabalho pequeno tem muito menos probabilidade de falhar por atingir limites de tempo ou de memória do que um trabalho gigante. E o modelo pode, na prática, guardar muito mais histórico do que seria viável com atualização total, porque o custo de o manter deixa de crescer sem controlo.
Um caso concreto
Uma empresa tinha um relatório central de vendas com cerca de três anos de histórico, e a atualização diária corria durante a madrugada. No início, quando o histórico era de poucos meses, tudo corria em minutos. Mas ao longo de dois anos os dados acumularam-se para dezenas de milhões de linhas, e a atualização esticou-se para mais de duas horas — a ponto de, em alguns dias, ainda estar a correr quando a equipa comercial já queria abrir o relatório de manhã, encontrando dados incompletos. A base de dados de origem, por sua vez, sofria com o peso de devolver todo o histórico todas as noites. A solução não exigiu mais hardware nem uma nova ferramenta: configuraram atualização incremental, guardando três anos de histórico mas reprocessando apenas os últimos dez dias a cada atualização, que era a janela em que os dados ainda podiam mudar. O tempo de atualização caiu de mais de duas horas para poucos minutos, a carga sobre a origem quase desapareceu, e os dados passaram a estar sempre prontos bem antes do início do dia. Um problema que ameaçava tornar o relatório inutilizável resolveu-se com uma configuração bem pensada.
Quando não é preciso
Como quase tudo, a atualização incremental é uma resposta a um problema específico, não um dogma. Se o teu modelo tem poucas linhas e atualiza em segundos, configurá-la é adicionar complexidade sem retorno — a atualização total simples é mais fácil de manter e o ganho seria impercetível. Ela entra em cena quando o histórico é grande, a atualização começa a doer, e a origem sofre com recargas totais. Aplicá-la sem essa necessidade é resolver um problema que ainda não se tem.
Na prática
Se a atualização do teu relatório mais importante está a esticar-se noite após noite, ou se receias adicionar mais histórico por medo de a tornar impossível, a atualização incremental é provavelmente a resposta que ainda não configuraste. Começa por identificar as tabelas de factos grandes com uma boa coluna de data — são as candidatas naturais. Poucos ajustes transformam uma atualização insustentável numa rápida e fiável. O teu relatório está a recarregar anos de dados que já não mudam, todas as noites, sem necessidade?
