Notebooks e Spark no Fabric: quando usar

O ponto em que o Power Query para de dar conta#

Existe um momento bem específico na vida de um projeto de dados em que a conversa muda. Enquanto o volume é pequeno, tudo cabe em um Dataflow, uma consulta em Power Query resolve, e ninguém pensa em cluster. Só que aí a fonte cresce, o job que rodava em três minutos passa a rodar em quarenta, a atualização começa a estourar timeout, e alguém pergunta se não era o caso de usar Spark. É nesse ponto que os notebooks e Spark no Fabric deixam de ser um assunto de arquiteto de dados curioso e viram uma decisão de custo e de prazo que o time precisa tomar com clareza.

Este artigo é para quem já está dentro do Microsoft Fabric, tem um Lakehouse configurado e precisa decidir, caso a caso, quando o problema pede um notebook PySpark e quando ele pede algo mais simples. Vou ser direto sobre onde o Spark brilha, onde ele é overkill, e quanto isso custa em Capacity Units, porque essa é a parte que costuma ser esquecida na empolgação.

Notebooks e Spark no Fabric rodam código distribuído sobre o Lakehouse#

Um notebook no Fabric é um ambiente de código interativo, organizado em células, que roda em cima de um cluster Apache Spark gerenciado pela própria plataforma. Você não provisiona máquina, não instala nada: abre o notebook, ele sobe uma sessão Spark e você começa a escrever. As linguagens suportadas são PySpark (o dialeto Python do Spark), Scala, Spark SQL e R, e dá para misturar mais de uma no mesmo notebook usando as chamadas mágicas de célula, como %%sql ou %%scala.

O ponto que torna o notebook útil no Fabric é a integração nativa com o Lakehouse. Quando você anexa um Lakehouse ao notebook, as tabelas Delta que vivem lá ficam acessíveis diretamente, sem string de conexão, sem credencial no código. Você lê uma tabela como um DataFrame, transforma, e escreve de volta como Delta. Toda a persistência acontece no OneLake, o armazenamento único do Fabric, em formato aberto Delta Lake, o que significa que a mesma tabela que o Spark grava pode ser consultada depois pelo endpoint SQL ou lida pelo Power BI em modo Direct Lake.

Se você ainda está avaliando a plataforma como um todo, vale ler antes o nosso panorama de o que é o Microsoft Fabric e quando vale a pena. Aqui o foco é mais estreito: o notebook e o motor Spark.

Ler e escrever tabelas Delta no Lakehouse é o feijão com arroz#

Antes de falar de grande volume, vale mostrar a operação mais banal e mais frequente: ler uma tabela Delta, fazer uma transformação e gravar o resultado. Com um Lakehouse anexado, o caminho mais limpo é usar a Spark SQL API por nome de tabela.

from pyspark.sql import functions as F

# Le a tabela bronze de pedidos que ja esta no Lakehouse
pedidos = spark.read.table("bronze_pedidos")

# Limpeza e enriquecimento
pedidos_tratados = (
    pedidos
    .filter(F.col("valor_total") > 0)
    .withColumn("data_pedido", F.to_date("data_pedido"))
    .withColumn("faixa_valor",
        F.when(F.col("valor_total") < 100, "baixo")
         .when(F.col("valor_total") < 1000, "medio")
         .otherwise("alto"))
)

# Grava como tabela Delta gerenciada na camada silver
(pedidos_tratados
    .write
    .format("delta")
    .mode("overwrite")
    .saveAsTable("silver_pedidos"))

Se você preferir trabalhar por caminho de arquivo em vez de nome de tabela, o padrão é apontar para a área Tables do Lakehouse. As duas formas convivem:

# Leitura e escrita por caminho no OneLake
df = spark.read.format("delta").load("Tables/bronze_pedidos")

(df.write
   .format("delta")
   .mode("append")
   .save("Tables/silver_pedidos"))

O mode importa e é fonte recorrente de erro em produção. Use overwrite quando o passo reconstrói a tabela inteira, append quando adiciona um novo lote sem tocar no histórico, e prefira operações de MERGE do Delta quando precisa de upsert (atualizar registro existente e inserir novo na mesma passada). O MERGE é onde o Delta ganha do Parquet puro, porque dá transação ACID em cima do lake.

from delta.tables import DeltaTable

alvo = DeltaTable.forName(spark, "silver_clientes")
novos = spark.read.table("staging_clientes")

(alvo.alias("t")
    .merge(novos.alias("n"), "t.cliente_id = n.cliente_id")
    .whenMatchedUpdateAll()
    .whenNotMatchedInsertAll()
    .execute())

O Spark ganha quando o volume e a complexidade sobem juntos#

O motor Spark existe para uma coisa: processar dados que não cabem, ou não rodam em tempo aceitável, em uma máquina só. Ele particiona o trabalho, distribui entre os nós do cluster e processa em paralelo. Isso tem um custo de overhead: subir a sessão, distribuir os dados, coordenar os executores. Para um volume pequeno, esse overhead faz o Spark ser mais lento que uma consulta T-SQL trivial. Para dezenas ou centenas de milhões de linhas, com joins pesados e agregações em janela, é exatamente o contrário.

O exemplo abaixo mostra o tipo de transformação em que o Spark se paga: uma função de janela calculando o acumulado de gasto por cliente ao longo do tempo, algo que fica caro em outras ferramentas quando a tabela é grande.

from pyspark.sql import functions as F
from pyspark.sql.window import Window

vendas = spark.read.table("silver_vendas")

janela = (Window
    .partitionBy("cliente_id")
    .orderBy("data_venda")
    .rowsBetween(Window.unboundedPreceding, Window.currentRow))

vendas_acumulado = (vendas
    .withColumn("gasto_acumulado", F.sum("valor").over(janela))
    .withColumn("ticket_medio_movel",
        F.avg("valor").over(janela)))

(vendas_acumulado
    .write.format("delta").mode("overwrite")
    .saveAsTable("gold_comportamento_cliente"))

A regra prática que uso com cliente é simples: se a transformação envolve grande volume, lógica que não se expressa bem em SQL, machine learning, ou leitura de arquivos semiestruturados como JSON e Parquet aninhado, o notebook Spark é a ferramenta certa. Se é limpeza tabular simples de fonte modesta, provavelmente não é.

Spark, Dataflow Gen2 ou T-SQL: escolha pelo problema, não pela moda#

O Fabric te dá três motores de transformação que se sobrepõem de propósito. A pior decisão é escolher por afinidade pessoal. A boa decisão olha para volume, complexidade e quem vai manter aquilo depois. A tabela abaixo resume como eu comparo os três.

Critério	Notebook Spark (PySpark)	Dataflow Gen2	T-SQL no Warehouse
Volume ideal	Grande a muito grande	Pequeno a médio	Médio a grande
Complexidade da lógica	Alta, inclusive ML	Baixa a média	Média, tudo que é SQL
Interface	Código	Visual (Power Query)	Código SQL
Perfil de quem mantém	Engenheiro de dados	Analista, self-service	Quem já domina SQL
Escrita em Delta	Nativa e flexível	Sim, destino no Lakehouse	Via tabelas do Warehouse
Custo por unidade de trabalho	Maior por sessão	Menor em cargas leves	Eficiente para SQL puro

Traduzindo em recomendação: o Dataflow Gen2 é excelente para o analista que quer ingestão e limpeza sem escrever código, e é imbatível em produtividade quando o volume é modesto. O T-SQL no Warehouse resolve muito bem transformação declarativa quando os dados já estão estruturados e a equipe pensa em SQL. O notebook Spark é para quando o volume ou a complexidade extrapolam os outros dois. Não é raro os três coexistirem no mesmo projeto: Dataflow ingerindo, Spark tratando o pesado, T-SQL servindo camadas para consumo.

Quando o destino final é dashboard, essa escolha de motor conversa diretamente com a camada de modelagem e visualização. Se o seu foco é o consumo em relatório, o guia completo de Power BI para empresas ajuda a fechar a ponta.

O custo mora nas Capacity Units, e ele é real#

Aqui é onde muita gente se machuca. No Fabric, você não paga por job, paga por uma capacidade provisionada, medida em Capacity Units (CUs). Toda execução de notebook Spark consome CUs enquanto a sessão está ativa, proporcional ao tamanho do cluster e ao tempo de uso. Um cluster maior processa mais rápido, mas queima CUs mais rápido também. E aqui está a pegadinha: a sessão continua consumindo mesmo quando você parou de rodar células e ficou pensando, até ela expirar por inatividade.

Alguns hábitos derrubam a conta de forma consistente:

Prática	Efeito no consumo de CUs
Encerrar a sessão ao terminar em vez de deixar ociosa	Corta consumo morto de sessão parada
Ajustar o tamanho do pool ao volume real	Evita cluster grande para dado pequeno
Rodar em Spark só o que precisa de Spark	Empurra carga leve para Dataflow ou SQL
Usar OPTIMIZE e particionamento nas tabelas	Reduz leitura de arquivo e tempo de job
Evitar collect() e toPandas() em dados grandes	Impede trazer tudo para o driver e estourar

Duas configurações práticas ajudam a conter custo. A primeira é não trazer dados para o nó driver sem necessidade: collect() e toPandas() puxam o DataFrame inteiro para a memória de uma máquina só, o que mata o propósito do Spark e, em volume grande, derruba a sessão. Prefira agregar no cluster e escrever o resultado. A segunda é manter as tabelas Delta enxutas com manutenção periódica.

# Compacta arquivos pequenos e reorganiza por coluna de filtro frequente
spark.sql("OPTIMIZE gold_comportamento_cliente ZORDER BY (cliente_id)")

# Remove arquivos antigos que so ocupam espaco e encarecem leitura
spark.sql("VACUUM gold_comportamento_cliente RETAIN 168 HOURS")

O erro clássico de custo não é rodar Spark. É rodar Spark para tudo, inclusive para transformação de 50 mil linhas que um Dataflow faria mais barato, e deixar sessão aberta a tarde inteira. Governança de capacidade é tão parte do trabalho quanto o código. Esse é um dos pontos que mais aparece nos nossos projetos de engenharia de dados: não basta o pipeline funcionar, ele precisa caber no orçamento de capacidade que a empresa contratou.

Um padrão de organização que funciona na prática#

Notebook vira bagunça rápido se você tratar cada um como script solto. O que funciona é organizar por camada da arquitetura medalhão: um notebook de bronze para silver, outro de silver para gold, cada um com responsabilidade única, e orquestração por Pipeline do Data Factory dentro do próprio Fabric. Isso deixa cada notebook testável e barato de rodar isolado, e concentra o Spark nas etapas pesadas.

Parametrizar ajuda a reaproveitar. O Fabric permite marcar uma célula como célula de parâmetros, e o Pipeline injeta valores em tempo de execução, o que torna o mesmo notebook capaz de processar um dia específico ou um recorte de fonte sem duplicar código.

# Celula de parametros (marcada como Parameters cell no Fabric)
data_processamento = "2026-04-01"
tabela_origem = "bronze_pedidos"

df = (spark.read.table(tabela_origem)
      .filter(F.col("data_pedido") == data_processamento))

Para cargas que envolvem previsão, clustering ou qualquer analítica que passe do SQL, o notebook também é a porta de entrada natural do machine learning dentro do Fabric, assunto que tratamos nos projetos de analytics avançado. O mesmo cluster que trata o dado treina o modelo, e o resultado volta para uma tabela Delta que o Power BI lê.

Perguntas frequentes#

Preciso saber Scala para usar Spark no Fabric? Não. PySpark cobre a esmagadora maioria dos casos e é a linguagem mais usada em notebooks do Fabric. Scala tem vantagem de performance em cenários muito específicos e de baixo nível, mas para pipeline de dados e transformação de volume, PySpark resolve com folga e tem comunidade e documentação muito maiores.

Dá para usar SQL dentro de um notebook Spark? Sim. Você usa a mágica %%sql em uma célula e escreve Spark SQL direto sobre as tabelas do Lakehouse, ou chama spark.sql("...") dentro do Python. Muitos times misturam: PySpark para a lógica de transformação e Spark SQL para consultas de leitura e validação. É prático e não obriga a escolher uma linguagem só.

Qual a diferença entre gravar em Delta pelo notebook e criar tabela no Warehouse? O notebook grava tabelas Delta no Lakehouse, com controle fino de particionamento, MERGE e manutenção via código. O Warehouse expõe uma experiência T-SQL com tabelas gerenciadas e transações no padrão SQL. Ambos acabam em Delta no OneLake, mas o notebook dá mais flexibilidade de transformação, enquanto o Warehouse é mais natural para quem vive em SQL e para servir consumo.

Notebook Spark serve para dado que atualiza a cada poucos minutos? Serve, mas avalie o custo. Subir sessão Spark tem overhead, então micro-lotes muito frequentes podem manter capacidade ocupada o tempo todo. Para streaming e near real-time, o Fabric tem recursos específicos como Eventstream, e vale desenhar a solução em vez de só agendar o notebook a cada cinco minutos, que costuma sair caro em CUs.

Como sei se estou gastando Capacity Units demais com notebooks? O Fabric traz o Capacity Metrics App, que mostra o consumo por item e por operação. É lá que você identifica sessão ociosa, cluster superdimensionado e jobs que consomem desproporcionalmente. Acompanhar essa métrica é parte da operação, não um luxo, porque capacidade estourada afeta todas as cargas da mesma capacidade, inclusive os relatórios.

Vale sempre usar Spark porque é o mais poderoso? Não, e essa é a armadilha mais comum. O mais poderoso raramente é o mais barato ou o mais simples de manter. Para limpeza tabular de volume modesto, Dataflow Gen2 entrega mais rápido e com menos código. Para transformação declarativa sobre dado já estruturado, T-SQL é eficiente. Guarde o Spark para quando o volume ou a complexidade realmente pedirem, e você economiza capacidade e dor de manutenção.

Fechando#

Notebook Spark no Fabric é uma ferramenta excelente para a coisa certa: grande volume, transformação complexa, machine learning e leitura de dados semiestruturados, tudo escrevendo Delta no Lakehouse de forma nativa. Ele não é o martelo universal. A decisão madura é combinar Spark, Dataflow Gen2 e T-SQL pelo problema de cada etapa, e manter o olho no consumo de Capacity Units desde o primeiro dia, porque é ali que a conta chega. Se a sua equipe está montando ou revisando a arquitetura de dados no Fabric e quer acertar essa divisão de motores sem estourar capacidade, fale com a gente.