Você escolheu um F-SKU. Pagou. Configurou o workspace. Deu acesso pra galera.
E aí vem o problema.
Os dashboards começam a demorar. Os jobs Spark ficam na fila. A TI recebe chamado sem saber o que está acontecendo. E você, no meio de tudo isso, sem saber de onde vem o gargalo.
Isso não é problema de Fabric. É problema de quem escolheu o SKU sem entender o que vai rodar dentro dele.
Neste artigo vou te mostrar como a capacidade funciona de verdade, o que cada workload consome, como a engenharia bem feita reduz desperdício e como monitorar para tomar decisões, não achismos.
O que você está comprando quando contrata um F-SKU
A primeira coisa que a maioria das pessoas erra é imaginar que está comprando uma VM ou um cluster. Não é isso.
Quando você contrata um F-SKU, você está comprando uma cota de Capacity Units por segundo as CUs. Para facilitar o raciocínio, essa cota é dividida em timepoints de 30 segundos. Um dia inteiro tem 2.880 timepoints.
O modelo vai de F2 até F2048. As features são as mesmas, o que muda é a quantidade de CUs disponível.
Um detalhe importante: você paga pelo SKU contratado, independente do uso. Se você contratou um F64, vai pagar por F64 mesmo que só use 20%.
O consumo acontece por operações, e existem dois tipos:
- Interativas : Power BI, SQL ad-hoc. A janela de suavização dura enquanto a operação durar.
- Background: Spark, Pipelines. A janela de suavização se estende por 24 horas.
Por que isso importa? Porque uma operação Spark pesada não vai te travar imediatamente. O consumo é distribuído ao longo do tempo. Mas se você ficar acumulando jobs pesados sem monitoramento, a conta chega.
A vantagem que muita gente não percebe
Antes do Fabric, uma arquitetura típica de dados tinha Power BI Premium em um medidor, Synapse em outro, ADLS em outro e ADF em mais um. Custo imprevisível. Capacidade ociosa em um serviço que não ajudava o outro.
E tem outro cenário que aparece bastante no mercado: a stack Frankenstein. Docker com Airflow orquestrando Spark, dados caindo em MinIO, queries no Trino, metadados no PostgreSQL, tudo open source, tudo customizável, tudo integrado na força bruta. Não estou dizendo que é ruim. Para times com maturidade técnica alta e necessidade real de controle granular, essa stack funciona.
O problema é o custo oculto: você passa mais tempo integrando do que fazendo pipeline. A engenharia de plataforma vira o trabalho principal e o dado fica em segundo plano. Quem já montou esse ambiente sabe do que estou falando.
Com o F-SKU unificado, tudo muda. CU ociosa de um workload fica disponível para outro. Spark pode usar o que o Power BI não está usando naquele momento. O custo vira previsível e centralizado.
Na prática, isso não é um detalhe técnico. É uma mudança de modelo de negócio.
Cada workload consome diferente — e você precisa saber isso
Vamos ser honestos: a maioria dos times dimensiona capacidade sem entender o perfil de consumo de cada workload. Resultado: throttling no pior momento possível.
Veja o padrão de cada um:
- Spark jobs: burst durante a execução, proporcional a vCores × tempo. Quanto mais paralelismo, mais CU.
- Power BI Direct Lake: burst no framing. As CUs são consumidas ao carregar colunas na memória. Não é contínuo, mas pode ser pesado.
- Power BI Import (refresh): burst no refresh. Processa o dataset inteiro a cada atualização.
- T-SQL Warehouse: burst durante a query, proporcional à complexidade e ao volume.
- Data Factory Pipelines: baixo consumo por atividade, mas Copy e Notebook têm custos distintos.
- Eventstream: contínuo. As CUs ficam ativas enquanto o stream roda.
- Dataflow Gen2: burst durante a execução, mas diminui após 10 minutos.
Antes de escolher qualquer SKU, você precisa mapear:
- Quais workloads rodam ao mesmo tempo?
- Quantos visualizadores tem na organização?
- Quantos reports existem ativos?
- Qual o volume de dados e quantas fontes?
Sem essas respostas, qualquer escolha de SKU é chute.
Engenharia que economiza CU
Saber o que consome é metade do caminho. A outra metade é engenharia bem feita.
No Spark, os erros mais caros são:
Tabelas Delta mal particionadas podem consumir até 10x mais CU que o necessário. O Spark lê partições inteiras quando não há filtro eficiente — e cada partição desnecessária é CU desperdiçada.
collect(), display() e print() em produção movem dados para o driver. Em notebooks de desenvolvimento isso é normal. Em produção é erro.
Spark onde cabe Python puro. Se você está processando 5 mil registros, não precisa de cluster. Você está usando o canhão para matar uma barata. O overhead de inicialização do Spark já supera o trabalho que ele vai fazer.
Tabelas Delta sem manutenção sem VACUUM e sem OPTIMIZE — acumulam small files que explodem o tempo de leitura.
Não utilizar o modo High Concurrency quando múltiplas sessões rodam ao mesmo tempo. Cada sessão separada ocupa mais CU do que o necessário.
No Direct Lake e Power BI:
OPTIMIZE + V-ORDER nas tabelas Delta reduz as CUs consumidas no framing. O Direct Lake carrega menos dados na memória quando os arquivos estão bem organizados.
Colunas desnecessárias no modelo custam CU. Cardinalidade alta em colunas que ninguém usa é desperdício puro.
Medidas DAX complexas sem fallback adequado causam throttling silencioso. A query vai para o DirectQuery sem você perceber, e a experiência do usuário degrada sem alerta claro.
Modelagem mal planejada, sem Star Schema, com relacionamentos N:N, esses são erros que parecem inofensivos no desenvolvimento e viram bomba em produção.
Coluna calculada para tudo é ETL dentro do Power BI. O lugar do ETL é no pipeline, não no modelo.
Na separação de capacidades:
Uma estratégia que funciona bem na prática é separar workloads em capacidades diferentes:
- F64 para Analytics (workspaces de produção de relatórios)
- F32 para Engineering (workspaces da camada bronze, silver e gold)
- F8 para Dev/Test
Assim, um job Spark pesado no pipeline de ingestão não derruba os dashboards que o C-level está vendo naquele momento. Isolamento real, não teórico.
Decisões de arquitetura que mudam o consumo real:
Dataflow Gen2 é a opção mais fácil de montar, arrastar, soltar, publicar. É também a que mais consome CU por unidade de trabalho entregue. A Microsoft documentou isso no modelo de billing: o motor do Dataflow tem overhead de inicialização e escala de forma menos eficiente que as alternativas.
O padrão que funciona: Copy Data para movimentação de volume, Visual Query para transformações que o time de negócio precisa acompanhar. Dataflow só quando o caso realmente não cabe em outra abordagem.
Mirroring é a feature mais subutilizada do Fabric. Quando a fonte suporta — Azure SQL, Cosmos DB, Snowflake, Azure Databricks, entre outras — o Mirrored Database replica os dados continuamente para o OneLake sem pipeline, sem orquestração, sem custo de atividade. Você elimina uma camada inteira de trabalho de engenharia. Sempre que a fonte e o caso de uso comportarem, use Mirroring antes de pensar em qualquer outra estratégia de ingestão.
Em Notebooks, o desperdício mais comum que vejo é múltiplas sessões Spark separadas para tarefas que poderiam estar dentro do mesmo fluxo. Cada sessão carrega overhead de inicialização, vCores reservados antes de qualquer linha de código executar. O padrão correto é notebookutils.notebook.runMultiple, que paraleliza execução de notebooks dentro da mesma sessão. Resultado: menos CU consumida, menos tempo de fila, mais throughput. Um notebook bem escrito consome menos que Copy Data. Copy Data consome menos que Dataflow. Isso não é preferência, é o comportamento documentado do modelo de cobrança do Fabric.
VACUUM e OPTIMIZE não são manutenção opcional. Tabelas Delta sem essas operações acumulam small files progressivamente. Você vê o sintoma nos jobs Spark ficando cada vez mais lentos sem nenhuma mudança no volume de dados, o problema está na quantidade de arquivos que o Spark precisa abrir, não na lógica. A cadência mínima para tabelas com escrita contínua é semanal. Para tabelas críticas de produção, diária. Sem isso, qualquer ganho de engenharia no código vai sendo corroído com o tempo.
Sem visibilidade, qualquer decisão é achismo
Você pode fazer tudo certo na engenharia e ainda ter problemas de capacidade. Por isso o monitoramento não é opcional.
As principais ferramentas disponíveis:
- Fabric Capacity Metrics App: mostra CU% por hora e por workload, separando interativas de background, indicando operações com throttling e os maiores consumidores por workspace.
- Fabric Unified Admin Monitoring (FUAM): visão consolidada de toda a organização, com as mesmas dimensões de análise da Metrics App, mas em escala de tenant.
- OneLake Catalog: governança de itens e visibilidade de acesso.
- FabricGov: biblioteca Python open source que automatiza governança e extração de métricas via API do Fabric. Criada por mim, disponível no GitHub.
- Power Monitor: dashboards personalizados em cima dos dados de capacidade exportados, para quem precisa de visões específicas que os apps nativos não entregam. Conheça o Power Monitor no site https://powermonitor.com.br/.
Os sinais de alerta que você precisa monitorar:
Verde: CU% abaixo de 60%, operação saudável.
Amarelo: CU% acima de 60% por períodos prolongados, atenção. Pode ser comportamento esperado em picos, mas se for contínuo é sinal de subdimensionamento.
Vermelho: CU% acima de 80% ou Background acima de 70%, throttling iminente ou em curso.
A cadência que funciona:
- Diariamente — verificar CU% do dia anterior.
- Semanalmente — identificar os maiores consumidores por workspace.
- Mensalmente — comparar consumo vs SKU contratado e decidir se é hora de escalar ou otimizar.
O que levo desta conversa
Não adianta saber criar um Dataflow, um notebook Spark ou um report Power BI se quando você executa isso vai derrubar o ambiente inteiro.
Capacidade é um tema de engenharia, não de infraestrutura. A decisão de qual SKU contratar é consequência de como você arquiteta, modela e executa os workloads.
O caminho é esse:
Entenda o modelo de contratação. Mapeie o que vai rodar. Escreva código que respeita os limites de CU. Monitore para decidir com dados.
Simples assim. Difícil de executar sem conhecimento de causa — mas totalmente possível quando você para de tratar capacidade como um problema da TI e começa a tratar como responsabilidade do time de dados.
Qualquer dúvida ou ponto que você quer aprofundar, estou no LinkedIn @luhborba e no YouTube no mesmo handle.
Se quiser me aprofundar neste tema numa mentoria, acessa lrdataconsult.com.br.
Recursos para ir além
Live FMU — Microsoft Fabric na prática Participei de uma Evento Presencial, mas também teve uma live na FMU onde aprofundei vários dos temas deste artigo, capacidade, workloads, boas práticas de engenharia. Está disponível no YouTube: Link da Live
Microsoft Fabric Starter — curso gratuito Se você está começando no Fabric ou quer nivelar a base antes de ir para os tópicos avançados, o Fabric Starter cobre arquitetura, OneLake, Lakehouse, Medallion e os fundamentos que a maioria pula. É gratuito e está na Data Driven School: datadrivenschool.com.br
Cursos em prevenda — Data Driven School Dois cursos estão abrindo vagas em breve:
Microsoft Fabric na Prática — formação intermediária, focada nas ferramentas de ingestão, transformação com e sem código e orquestração real de pipelines. datadrivenschool.com.br Microsoft Fabric — Gestão Dinâmica: Capacidade, Custos e Performance — o aprofundamento direto do que foi discutido neste artigo. Controle de CUs, otimização Spark, tuning do engine SQL, governança e billing. datadrivenschool.com.br
E se você não me seguir no instagram, tenho uma pessima noticia sua capacidade vai cair hoje, então não deixa de me seguir lá também!!!! @lrdataconsult