Cache de DataFrames chega à computação serverless no Databricks

A computação serverless do Databricks agora suporta cache de DataFrames via df.cache() e df.persist(). Ao chamar o cache, o Databricks executa a consulta imediatamente e materializa o resultado como um snapshot na sessão, evitando recomputações em acessos posteriores.

Para que serve

Imagine que você precisa fazer um join pesado entre tabelas de pedidos e clientes para gerar múltiplos relatórios no mesmo notebook, ou executar um foreachBatch no streaming que escreve para múltiplos destinos. Sem o cache, o Databricks recalcularia todo o join a cada ação. Com essa novidade, você pode:

• Reutilizar o resultado de agregações, joins ou filtros pesados várias vezes na mesma sessão.
• Calcular um micro-batch de streaming apenas uma vez e salvá-lo em diferentes tabelas de destino.
• Treinar e ajustar modelos de machine learning usando uma mesma base de features já processada.
• Garantir um snapshot estável e consistente durante análises em etapas, mesmo que os dados de origem sofram alterações.

Como usar

Para usar o cache, invoque .cache() diretamente no DataFrame. Derivações subsequentes (filter, groupBy, select) leem diretamente o snapshot.

from pyspark.sql import functions as F

# DataFrame resultante de um join pesado
pedidos_detalhados = (
    spark.table("meu_catalogo.vendas.pedidos")
    .filter(F.col("order_date") == "2026-10-15")
    .join(spark.table("meu_catalogo.vendas.clientes"), "customer_id")
)

# Materializa o resultado e salva o snapshot na sessão
pedidos_detalhados.cache()

# Ambas as operações leem do snapshot em vez de refazer o join
receita_total = pedidos_detalhados.agg(F.sum("amount")).first()[0]

receita_por_regiao = pedidos_detalhados.groupBy("order_date", "region").agg(F.sum("amount").alias("revenue"))
receita_por_regiao.write.mode("append").saveAsTable("meu_catalogo.relatorios.receita_regiao")

# Libera o armazenamento assim que terminar
pedidos_detalhados.unpersist()

O que acontece nesse código:

1. O join entre pedidos e clientes é definido e materializado imediatamente na chamada .cache().
2. O cálculo de receita total e o agrupamento por região leem diretamente o snapshot salvo, sem refazer o join com as tabelas de origem.
3. O método .unpersist() descarta o snapshot para liberar armazenamento cloud; após isso, pedidos_detalhados e variáveis derivadas dele deixam de ser utilizáveis.

Limitações e requisitos

• Estágio: Public Preview, ativado por padrão na maioria dos workspaces (administradores podem desativar na página Previews). Não disponível em workspaces com perfil de segurança de compliance ativado.
• Ambiente: Notebooks e jobs serverless exigem environment version 5 ou superior.
• Clientes: Exige Databricks Connect for Python 18.1.8+ ou Databricks Connect for Scala 18.1.5+ (versões antigas retornam erro CACHE_REQUIRES_NEWER_CLIENT_ON_SERVERLESS_GC).
• Derivação explícita: O cache só é reaproveitado por DataFrames explicitamente derivados da variável em cache. Recriar o mesmo código em outro DataFrame reprocessa as tabelas de origem.
• Duração e isolamento: Os dados duram até o fim da sessão ou por até 7 dias, isolados estritamente na sessão de quem executou. Storage level aceita qualquer valor em persist(), mas opera sempre internamente como DISK_ONLY.
• Comportamento pós-unpersist: Chamar unpersist() invalida o DataFrame cacheado e derivados diretos (retornando CACHE_DATAFRAME_ACCESS_AFTER_UNCACHE).