Data Solution Architect com mais de 20 anos de experiência em Engenharia de Dados, hoje atuando na GFT Technologies com plataformas modernas de dados, governança, analytics e Inteligência Artificial usando Databricks, Azure, AWS e Microsoft Fabric. 9x Certificado Microsoft — incluindo Azure Databricks Data Engineer Associate e Azure Database Administrator Associate —, Databricks Certified Machine Learning Professional, Microsoft Certified Trainer (MCT) e líder do São Paulo Databricks User Group. Palestrante e coordenador de trilhas de Dados e IA no TDC (The Developers Conference), e autor dos livros Lakehouse Engineering com Databricks e Machine Learning Prático com Python. Meu objetivo é contribuir cada vez mais com a comunidade Microsoft e Databricks, compartilhando aqui artigos técnicos e opiniões sobre esse universo.
Mover tabela entre catálogos sem copiar dado: a Databricks contribuiu UNREGISTER pro padrão aberto do Iceberg
REGISTER e UNREGISTER, em Private Preview, deixam uma tabela sair de um catálogo e entrar em outro reaproveitando só a localização do metadado, sem mover arquivo nenhum, baseado na especificação REST do Apache Iceberg à qual a própria Databricks contribuiu o UNREGISTER.
Um service principal só, mil clientes diferentes, cada um vendo só a própria linha
Custom identity claim injeta um identificador assinado no token OAuth de um service principal, lido via current_oauth_custom_identity_claim() dentro de view dinâmica ou política ABAC, deixando uma aplicação multi-tenant servir usuário final sem criar conta individual no Azure Databricks pra cada um.
Atlassian normalizou 44 bilhões de eventos por dia em OCSF, e a consulta que levava 45 segundos passou pra 3
Já vimos a arquitetura geral da Data Intelligence for Cybersecurity da Databricks (Agent Bricks, Lakebase, OCSF sobre Delta Lake). Agora a Atlassian mostra como isso funciona na prática em 44 bilhões de eventos por dia: 80% de redução de custo de ingestão, consulta de 45 segundos pra 2-3 segundos, e um schema tipado em Go que rejeita log fora do padrão já na compilação.
O repartition sob demanda que era Public Preview virou GA, e dois Databricks MVPs bateram nisso no mesmo dia
On-demand state repartitioning, que já cobrimos aqui como Public Preview, chegou à disponibilidade geral: redimensionar partição de shuffle de uma query stateful ou pipeline do Lakeflow sem perder o estado do checkpoint, e agora os Databricks MVPs Hubert Dudek e Derar Alhussein confirmaram, cada um por conta própria, que o recurso está liberado pra uso geral.
A Databricks CLI 1.20 não deprecia mais o Terraform em bundle, ela remove de vez
O Databricks MVP Daniel Sahal destacou que a Databricks CLI 1.20.0 removeu de vez o engine Terraform de Databricks Asset Bundles: setar bundle.engine: terraform ou a variável de ambiente equivalente agora retorna erro, e falha de migração de state também vira erro em vez de cair de volta pro Terraform.
Feature Views chegou à disponibilidade geral, e unifica feature de batch, streaming e tempo de requisição numa peça só
Feature Views atingiu disponibilidade geral no Azure Databricks para dado de batch, streaming e tempo de requisição, mas só chega a workspaces com compliance security profile em meados de novembro de 2026, quase um mês depois do resto.
Agentes no Azure Databricks ganharam memória de longo prazo, destilada por um LLM a cada 24 horas
Agent memory pipelines, em Beta, conectam um session store a um memory store e usam um LLM para destilar fato, preferência e decisão de conversas passadas em entradas de memória que o agente recupera depois, rodando sob demanda ou a cada 24 horas.
Previsão de série temporal como modelo de fundação: a aposta do ai_forecast dentro do SQL do Databricks
As Predictive AI Functions, em Beta, trazem um ai_forecast renovado baseado em modelo de fundação para série temporal, mais quatro funções SQL novas de análise de driver, anomalia e predição, sem exigir que o usuário treine ou gerencie modelo.
Já falei que Knowledge Assistant virou legado, mas não falei no que ele virou: o DurableAgentServer
DurableAgentServer, parte do AgentKit do Agent Bricks CLI, serve agente via uma única API de invocação cobrindo execução síncrona, em stream e em segundo plano, com invocação idempotente via ID gerado pelo cliente, sessão ordenada e recuperação automática de execução interrompida por crash.
Knowledge Assistant e Supervisor Agent, que vimos num workflow real há pouco, agora são legado
Knowledge Assistant, Supervisor Agent e mais sete oferecimentos de agente viraram legado na documentação da Azure Databricks: pra agente sem código, use Genie Agents; pra agente escrito em código, use o Agent Bricks CLI com DurableAgentServer no Agent Runtime.