Como particionar uma tabela Delta no Lakehouse do Fabric

Particionar uma tabela Delta no Lakehouse é uma técnica simples que pode acelerar muito as consultas quando trabalhas com grandes volumes de dados. A ideia é guardar as linhas em pastas separadas por uma coluna — por exemplo, o ano — para que o motor leia apenas a parte de que precisa, em vez de percorrer a tabela inteira. É uma boa forma de melhorar o desempenho sem mudares a maneira como escreves SQL. Funciona especialmente bem em tabelas de factos grandes, com milhões de linhas e um histórico de vários anos.

Pré-requisitos

• Um workspace do Microsoft Fabric com capacidade atribuída.
• Um Lakehouse já criado no teu workspace.
• Um notebook Fabric ligado a esse Lakehouse, com Spark disponível.
• Uma tabela ou ficheiro com uma coluna adequada para partição (data, ano, região…).
• Conhecimentos básicos de PySpark e de SQL.

Passo 1: Escolher uma boa coluna de partição

Antes de escrever qualquer código, pensa bem na coluna. Uma boa coluna de partição tem poucos valores distintos (baixa cardinalidade) e aparece com frequência nos filtros das tuas consultas. Datas agregadas — como o ano ou o mês — são as escolhas clássicas. Evita particionar por colunas com milhares de valores únicos, como um ID de cliente, porque isso cria milhares de pastas minúsculas e, em vez de ajudar, deixa tudo mais lento.

Regra prática: tenta que cada partição fique com um volume razoável de dados (idealmente centenas de megabytes). Se cada pasta tiver muito poucos ficheiros pequenos, estás a particionar de mais — escolhe uma coluna com menos valores.

Passo 2: Preparar a coluna de partição

Se ainda não tens uma coluna simples para partição, podes criá-la a partir de uma data. No teu notebook, extrai o ano da coluna de data com a função year:

from pyspark.sql.functions import year, col

# Lê os dados de origem (uma tabela já existente no Lakehouse)
df = spark.read.table("vendas")

# Cria a coluna "ano" a partir da data da venda
df = df.withColumn("ano", year(col("data_venda")))

Agora o df tem uma coluna ano com valores como 2024 ou 2025, perfeita para servir de partição.

Passo 3: Gravar a tabela particionada

Grava os dados como uma tabela Delta e indica a coluna de partição com partitionBy. O formato Delta é o predefinido no Lakehouse, por isso a tabela fica logo pronta a ser consultada por SQL.

df.write.format("delta") \
    .partitionBy("ano") \
    .mode("overwrite") \
    .saveAsTable("vendas_particionada")

Ao gravar, o Fabric cria uma pasta por cada valor da coluna — por exemplo ano=2024 e ano=2025 — e coloca em cada uma apenas as linhas correspondentes. Usámos mode("overwrite") para (re)criar a tabela do zero; se só quisesses acrescentar dados novos, usarias mode("append").

Passo 4: Consultar tirando partido da partição

Quando filtras pela coluna de partição, o motor lê apenas as pastas necessárias. A isto chama-se partition pruning (poda de partições) e é o que torna a consulta mais rápida.

SELECT ano, SUM(total) AS total_ano
FROM vendas_particionada
WHERE ano = 2025
GROUP BY ano;

Como filtraste por ano = 2025, o motor ignora todas as outras pastas e lê só essa partição. Quanto mais anos tiveres na tabela, maior é a poupança.

Verificar o resultado

Para confirmar que a tabela ficou mesmo particionada, corre o comando DESCRIBE DETAIL e observa o campo partitionColumns:

DESCRIBE DETAIL vendas_particionada;

No resultado, partitionColumns deve mostrar ["ano"]. Podes ainda abrir o Lakehouse no explorador do Fabric e expandir a tabela: vais ver as pastas ano=2024, ano=2025, e assim por diante. Se estas pastas aparecerem e a consulta filtrada devolver os números certos, a partição está a funcionar como devia.

Conclusão

Em poucos passos criaste uma tabela Delta particionada no Lakehouse e viste como o partition pruning acelera as consultas sem complicar o teu SQL. Um bom próximo passo é medir a diferença: corre a mesma consulta numa tabela sem partição e noutra particionada e compara os tempos. Depois, combina a partição com o comando OPTIMIZE para manteres os ficheiros bem arrumados. E fica a pergunta para pensares: qual das tuas tabelas maiores beneficiaria já de uma boa coluna de partição?