Por que minhas tabelas Delta/Iceberg ficam mais lentas toda semana mesmo sem a query ter mudado?

Uma tabela alimentada a cada cinco minutos por um job de streaming acumula milhares de arquivos pequenos por mês - e toda query contra ela paga overhead por arquivo, não importa quão pouco cada um tenha.

De onde realmente vêm os arquivos pequenos

Writers de streaming e micro-batch confirmam um arquivo novo (muitas vezes vários, um por partição tocada) a cada trigger. Com um trigger de 5 minutos, são centenas de arquivos por dia por partição - cada um pequeno, cada um adicionando seu próprio custo de abertura e leitura de metadados a cada scan futuro, não importa quão pouco realmente contenha.

O que o OPTIMIZE/compactação conserta e o que não conserta

A compactação reescreve muitos arquivos pequenos em menos e maiores, que é o que realmente conserta o tempo de scan. O que ela não faz: recuperar espaço em disco - os arquivos antigos e novos precisam coexistir, já que snapshots anteriores da tabela (usados para time-travel) ainda referenciam os originais - e não conserta um esquema de particionamento que já estava errado desde o início.

O VACUUM é um passo separado e mais arriscado

O VACUUM é o que realmente apaga arquivos não mais referenciados pelo snapshot atual da tabela, depois de uma janela de retenção - esse é o passo que recupera o custo de armazenamento. Uma janela de retenção curta demais pode apagar arquivos que um leitor concorrente ou uma query de time-travel em andamento ainda precisa, por isso é um comando separado e deliberado, não algo que a compactação roda automaticamente.