Porque 90% dos ambientes Fabric que analiso consomem mais capacidade do que deveriam.
Ao longo de diversos ambientes Microsoft Fabric analisados, identifiquei um padrão recorrente: empresas pagando por capacidades maiores do que precisam:
– F128 quando bastaria F64;
– F4 quando F2 resolveria;
e por aí vai.
O que causa esse desperdício?
Dataflows Gen2 rodando refresh desnecessários (as vezes de tabelas que nem tem alteração mais), sem query folding e sem particionamento, até mesmo por causa da existencia dele, será que não teria uma abordagem mais otimizada?
Power Query fazendo transformações pesadas no semantic model quando deveria estar em outras camadas, para mim esse é um dos piores erros.
PySpark quando ele não é necessário, esse daqui é muito comum, ou mal utilizado, sem usar cache, entre outras funções do spark para evitar consumo.
Vou nem falar de questões de falta de aplicação de conceitos, SCD, Carga Incremental, entre outras.
Por que isso acontece?
Fabric é uma plataforma recente, com múltiplos workloads e uma proposta diferente do que estávamos acostumados. Tem muita gente explorando recursos sem entender o impacto no consumo.
Além disso, a pressão por entrega faz com que otimização fique sempre para depois um depois que raramente chega.
A boa notícia:
É totalmente possível reverter isso. Com análise técnica adequada, revisão de código e ajustes estruturados, já vi ambientes reduzirem consumo pela metade mantendo a mesma performance, diminuindo o custo $$.
Se sua empresa usa Fabric e a fatura está maior do que deveria, vale uma conversa. Estamos ajudando empresas a economizar e usar melhor suas capacidades.
Fala comigo, com Alison Pezzott ou com nossa equipe comercial da Power Tuning, estamos aqui para lhe ajudar.
Artigo desenvolvido por: Luciano Borba (Engenheiro de Dados).
