PL-300: como implementar partições e optimizar refresh de modelos Power BI

Nesta lição vou ensinar-te a competência: implementar partições de tabelas e estratégias de refresh para modelos Power BI. Esta habilidade é importante no exame PL-300 porque influencia desempenho, consumo de recursos e requisitos de actualização na prática profissional.

O que precisas de saber

Particionar uma tabela significa dividi-la logicamente em segmentos (partições) que podem ser carregados ou actualizados independentemente. No contexto do Power BI existem dois cenários principais:

• Modelos importados (in-memory / VertiPaq): as partições são normalmente geridas automaticamente pelo serviço Power BI, mas quando se usa o endpoint XMLA ou ferramentas externas (Tabular Editor, Analysis Services) podes criar partições para controlar o processamento incremental.
• DirectQuery e modelos compostos (Composite models): não há partições no motor import para DirectQuery, mas podes usar estratégias de particionamento na fonte (por exemplo, views particionadas) para controlar os volumes retornados.

Vantagens das partições e do refresh incremental:

• Reduz o tempo de refresh, processando apenas os dados novos ou alterados.
• Minimiza janelas de manutenção e reduz o impacto sobre os utilizadores.
• Melhora a utilização de recursos e pode reduzir custos em grandes conjuntos de dados.

Como funciona

O mecanismo base para actualizações eficientes no Power BI é o refresh incremental. Aqui está o fluxo conceptual:

1. Identificar uma coluna de partição (ex.: OrderDate, ModifiedDate, PartitionKey) que permita filtrar por intervalo temporal ou por chaves de partição.
2. Definir políticas: quantos períodos (dias/meses) reprocessar totalmente e quais somente anexar (incremental).
3. Na primeira carga faz-se full refresh da tabela; depois aplicam-se apenas os critérios incrementais para novos/alterados.

No Power BI Desktop (modelo import), configuras o refresh incremental nas definições de tabela em Power Query e publicas no serviço. No serviço precisas de um Gateway quando a fonte é on-premises.

Na prática

Exemplo prático: tabela Sales com coluna OrderDate. Processo resumido (Power Query + Power BI Service):

1. Em Power Query filtra OrderDate para uma janela, ex.: RangeStart e RangeEnd (parâmetros DateTime).
2. Criar dois parâmetros: RangeStart, RangeEnd (usados apenas para query folding).
3. Aplicar filtros usando: OrderDate >= RangeStart and OrderDate < RangeEnd.
4. Em Transform > Table > Incremental Refresh (no Power BI Desktop):
   - Enable incremental refresh for this table
   - Set store rows for (ex.: 5 years)
   - Set refresh rows for (ex.: 1 month)
5. Publicar para Power BI Service. O serviço usa essas definições para executar refresh incremental durante o agendamento.

Notas importantes:

• Query folding é crítico: o filtro entre RangeStart/RangeEnd tem de ser traduzido para a fonte (SQL, Synapse, etc.). Sem folding, o serviço fará full refresh.
• Para fontes que não suportam folding, considera usar uma tabela intermédia ou um processo ETL na fonte (ex.: Azure Data Factory) que já parta os dados.

Erros comuns

1) Confiar em filtros locais: usar parâmetros dinâmicos sem query folding resulta em processamento completo e anula o benefício do incremental. Verifica sempre se a query dobra na fonte (View Native Query / Diagnostics).

2) Escolher a coluna errada para particionar: usar uma coluna não fiável (ex.: data de carga que muda) pode levar a omissões ou duplicações. Preferir colunas de negócio estáveis (timestamp de modificação ou data do evento).

3) Esquecer o comportamento de retenção: se guardares apenas X períodos e depois precisares de dados mais antigos, terás de reprocessar historicamente (full reload) ou restaurar backups.

Como praticar

Pratica com um dataset real: cria uma tabela de factos com vários anos e uma coluna ModifiedDate. Segue os passos acima e valida:

• Testa o folding com ferramentas como Power Query Diagnostics ou a opção "View Native Query".
• Faz alterações em linhas antigas e verifica se as políticas de refresh incremental as capturam (por exemplo, usando Refresh History no serviço).
• Experimenta combinar o Incremental Refresh com partições definidas via XMLA se quiseres controlar partições manualmente (requer capacidades Premium ou PPU para ligar via XMLA).

Para prática específica do exame, usa o Practice Assessment OFICIAL da Microsoft (gratuito) e a Study Guide da Microsoft para PL-300 — ambos gratuitos e actualizados. Não uses bancos de perguntas não oficiais nem dumps.

Em resumo

• Partições e refresh incremental reduzem o tempo de actualização ao processar apenas os dados novos/alterados.
• Query folding e a escolha da coluna de partição são determinantes para o sucesso.
• Testa e valida no Power BI Service: vê o histórico de refresh e usa diagnósticos para garantir o folding.
• Para controlo avançado (XMLA) e partições manuais é necessária capacidade Premium/PPU.