[{"content":"O Databricks MVP Daniel Sahal apontou pra um comando de CLI que ataca um tipo de bug clássico: código que funciona local e quebra ao rodar no Databricks só por diferença de versão de Python ou de biblioteca.\nO databricks environments setup-local resolve o compute de destino, seja cluster clássico com Databricks Runtime específico ou ambiente serverless versionado, busca a versão de Python e de databricks-connect fixadas pra aquele alvo junto com as restrições de dependência publicadas, e a partir disso provisiona ou atualiza um .venv gerenciado por uv já alinhado com esse ambiente remoto. Isso fecha o gap entre \u0026ldquo;funciona no meu notebook local\u0026rdquo; e \u0026ldquo;quebra no cluster\u0026rdquo; que sempre exigiu ajuste manual de versão toda vez que o time trocava de runtime.\nO comando também sabe lidar com projeto que já existe: ao rodar num projeto com pyproject.toml, ele faz o merge das mudanças necessárias no arquivo em vez de sobrescrever, e grava um backup em pyproject.toml.bak pra permitir revisão ou reversão manual antes de aceitar a mudança definitivamente.\nPontos técnicos:\nResolve o compute alvo pra uma chave de ambiente, buscando versão de Python, versão de databricks-connect e restrição de dependência publicadas pra essa chave Provisiona .venv via uv já casado com Databricks Runtime do cluster ou versão do ambiente serverless Em projeto existente, faz merge no pyproject.toml e grava backup em pyproject.toml.bak Se uv python install falhar, cai automaticamente pra um interpretador Python compatível já instalado na máquina Reporta código de erro distinto (E_PROVISION_CONFLICT) quando dependência do projeto conflita com a versão fixada pro ambiente alvo Flag --constraints-only foi descontinuada em favor de --no-dbconnect; novas flags --no-constraints e --no-dbconnect permitem pular escrita de pin de versão ou dependência de databricks-connect, respectivamente Minha ressalva: merge automático em pyproject.toml, mesmo com backup, é o tipo de operação que vale revisar via diff antes de commitar, principalmente em projeto com dependência já fixada manualmente por outro motivo que não seja compatibilidade com Databricks. O backup evita perda de dado, mas não evita que uma mudança automática passe despercebida num pull request maior.\nFonte: https://github.com/databricks/cli/releases\n#Databricks #CLI #AzureDatabricks\n","permalink":"https://wiliamrosa.github.io/posts/databricks-environments-setup-local-cli/","summary":"O comando resolve o compute alvo, seja cluster clássico ou serverless, descobre a versão de Python e de databricks-connect fixadas pra aquele ambiente e provisiona um .venv gerenciado por uv já casado com essas versões, atualizando o pyproject.toml com backup automático em pyproject.toml.bak.","title":"`databricks environments setup-local` sincroniza venv local com a versão exata do compute remoto"},{"content":"O Databricks MVP Ajay Kumar Pandey destacou uma peça de governança que fecha um buraco comum em monitoramento de qualidade de dado: alguém só descobre que uma tabela quebrou quando um dashboard já está errado há dias.\nOs alertas de anomaly detection, agora em Beta dentro da Data Quality Monitoring UI, eliminam a necessidade de escrever regra manual de frescor ou completude tabela por tabela. Em vez disso, o sistema aprende o padrão histórico de cada tabela monitorada e dispara notificação por e-mail assim que detecta um problema, como uma tabela parada há tempo demais ou uma queda inesperada na contagem de linha, dentro do escopo de catálogo ou schema em que a regra de alerta foi configurada.\nA configuração acontece direto no Catalog Explorer: dentro de um schema com monitoramento de qualidade já habilitado, a aba Details leva pra Data Quality Monitoring UI, onde o botão Manage alerts abre um painel pra criar, editar ou excluir regra de alerta, escolhendo catálogo, schema (ou todos os schemas do catálogo) e a lista de usuários a notificar.\nPontos técnicos:\nRegra de alerta escopada por catálogo inteiro ou schema específico Cada destinatário recebe um e-mail por tabela insalubre importante detectada dentro do escopo da regra Criar alerta em nível de schema exige privilégio MANAGE no schema; em nível de catálogo, exige MANAGE no catálogo Gerenciamento (criar, editar, excluir) feito direto no painel Manage alerts da Data Quality Monitoring UI Recurso está em Beta e já vem habilitado por padrão pra todo usuário, sem precisar ativação na página Previews Minhas considerações: automatizar a detecção de tabela insalubre é bem-vindo, mas o alerta por si só não substitui decidir o que fazer depois que ele chega. Vale já desenhar de antemão quem recebe cada regra e qual runbook aciona quando o e-mail cai, porque alerta que ninguém tem responsabilidade clara de tratar vira ruído rapidamente, principalmente em catálogo grande com muito schema monitorado ao mesmo tempo.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/data-governance/unity-catalog/data-quality-monitoring/anomaly-detection/alerts\n#Databricks #UnityCatalog #AzureDatabricks\n","permalink":"https://wiliamrosa.github.io/posts/deteccao-anomalia-alertas-unity-catalog/","summary":"Alertas de anomaly detection, em Beta na Data Quality Monitoring UI, notificam por e-mail usuário do workspace quando uma tabela monitorada fica insalubre dentro do escopo de catálogo ou schema configurado, sem exigir regra manual de qualidade escrita à mão.","title":"Unity Catalog agora manda alerta por e-mail quando anomaly detection acha tabela doente"},{"content":"O Databricks MVP Ajay Kumar Pandey chamou atenção pra uma peça nova de personalização do Genie Code que resolve um problema comum de quem tenta padronizar uso de agente de código dentro de um time.\nInstrução customizada global sempre teve o problema de ser aplicada em toda conversa, mesmo quando a maior parte dela não tem nada a ver com a tarefa em questão, o que desperdiça janela de contexto e às vezes até confunde o agente com regra irrelevante. As Skills seguem o padrão aberto Agent Skills e resolvem isso empacotando conhecimento de domínio, boa prática e até script executável num arquivo SKILL.md, carregado pelo Genie Code automaticamente só quando a descrição da skill bate com o pedido do usuário, ou manualmente via menção com @.\nExistem dois tipos: skill de workspace, criada por administrador e disponível pra todo mundo, útil pra forçar padrão organizacional como mascaramento de coluna sensível; e skill de usuário, pessoal, útil pra preferência individual de biblioteca ou estilo de código, e também como rascunho antes de promover a skill pro nível de workspace.\nPontos técnicos:\nSkill vive em .assistant/skills/, cada uma com pasta própria contendo um SKILL.md obrigatório SKILL.md tem frontmatter com name e description, seguido de instrução em Markdown com passo a passo, exemplo e caso de borda Genie Code carrega a skill automaticamente com base na descrição e no pedido do usuário, ou por menção manual com @ Skill de workspace fica em Workspace/.assistant/skills/; skill de usuário fica em /Users/{usuario}/.assistant/skills/ Suporta script e arquivo de referência adicional, referenciados por caminho relativo dentro da pasta da skill Editar uma skill exige abrir chat novo pra aplicar a mudança, chat já aberto não atualiza sozinho Minha ressalva: a promessa de \u0026ldquo;contexto só quando relevante\u0026rdquo; depende inteiramente da qualidade da descrição de cada skill, porque é justamente esse texto que o Genie Code usa pra decidir quando carregar. Skill mal descrita tende a nunca ser acionada automaticamente ou, pior, ser acionada no momento errado, então o trabalho real de adoção está em escrever descrição precisa, não em criar a skill em si.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/genie-code/skills\n#Databricks #GenieCode #AzureDatabricks\n","permalink":"https://wiliamrosa.github.io/posts/genie-code-skills-contexto-especializado/","summary":"Skills empacotam instrução, exemplo e script executável num arquivo SKILL.md dentro de .assistant/skills/, e o Genie Code carrega automaticamente a skill relevante conforme o pedido do usuário, em vez de manter tudo em instrução global que consome contexto em toda conversa.","title":"Genie Code agora aceita Skills pra carregar contexto especializado só quando precisa"},{"content":"O Databricks MVP Bartosz Konieczny mostrou como o novo trigger continuous resolve um desconforto antigo de quem roda job de streaming no Lakeflow.\nTrigger de CRON e trigger orientado a evento nunca foram desenhados pra sustentar um job que, por definição, deveria rodar sem parar. A saída de sempre era forçar um agendamento curtíssimo pra simular continuidade, o que na prática significava reinício desnecessário e gerenciamento manual de retomada depois de falha. O trigger continuous inverte isso: ao ser declarado, o job vira um serviço always-on que reinicia automaticamente assim que uma execução termina ou falha, sem esperar próximo horário de agendamento.\nA configuração acontece direto no Databricks Asset Bundle, com o bloco continuous definindo pause_status: UNPAUSED e task_retry_mode: ON_FAILURE, esse último garantindo que tarefa individual dentro de um job com múltiplas tarefas seja reiniciada sozinha com backoff exponencial em caso de falha, em vez de deixar aquele pedaço específico do pipeline parado sem ninguém perceber.\nPontos técnicos que valem registrar:\nDeclaração via Databricks Asset Bundle, bloco continuous com pause_status e task_retry_mode Cada reinício provisiona cluster novo, o que introduz latência que pode pressionar SLA e acumular dado não processado durante a janela de restart task_retry_mode: ON_FAILURE aplica retry com backoff exponencial por tarefa, essencial em job multi-tarefa Job contínuo não deve misturar trigger Available Now com Processing Time na mesma definição, porque gera conflito de dependência entre tarefas Minhas considerações: delegar a orquestração de \u0026ldquo;rodar pra sempre\u0026rdquo; pro próprio Databricks é um ganho de manutenção real frente a manter um CRON job fingindo ser contínuo. O ponto que merece atenção antes de migrar pipeline crítico é o provisionamento de cluster novo a cada reinício, porque isso significa que falha frequente numa tarefa específica pode virar um ciclo caro de reprovisionamento em vez de simplesmente retomar processamento onde parou.\nFonte: https://www.waitingforcode.com/databricks/continuous-trigger-lakeflow-jobs/read\n#Databricks #Lakeflow #AzureDatabricks\n","permalink":"https://wiliamrosa.github.io/posts/lakeflow-jobs-continuous-trigger-streaming/","summary":"O trigger continuous transforma um Lakeflow Job em serviço always-on que reinicia sozinho assim que termina ou falha, delegando pra Databricks a responsabilidade de manter o job rodando sem interrupção, em vez de forçar CRON ou trigger orientado a evento a fazer papel de scheduler contínuo.","title":"Lakeflow Jobs ganhou trigger contínuo pra job de streaming parar de depender de gambiarra de CRON"},{"content":"Extrair campo de documento com IA funciona bem até o documento passar de algumas dezenas de página ou o schema ficar grande demais para caber numa janela de contexto só.\nA Databricks lançou o Precision Mode dentro da função ai_extract, mirando justamente os três jeitos clássicos de esse tipo de pipeline quebrar: documento longo que exige reconciliar informação entre página distante, saída longa como nota fiscal com centena de item de linha, e schema complexo cujo campo exige inferência ou cálculo em vez de simples cópia de texto. Em vez de depender só de um modelo de fronteira lendo o documento inteiro de uma vez, o modo combina um modelo afinado especificamente pra extração com uma camada agentica que raciocina em etapas, decompõe o trabalho e distribui pedaço do documento entre subagentes rodando em paralelo antes de consolidar tudo numa saída só.\nA Databricks testou esse modo em seis benchmarks de documento complexo, cobrindo cerca de nove mil documentos, misturando caso interno de cliente de setor financeiro, industrial e de saúde com benchmark público como VAREX e RealDocBench, incluindo documento de até duas mil páginas e schema com mais de trezentos campo aninhado.\nPontos técnicos:\nAtiva-se passando o modo precision na chamada da função ai_extract, ou pelo toggle de Precision Mode na interface de Information Extraction dentro de Agents Resultado de 94,7% de acurácia agregada nos seis benchmarks testados, sete pontos acima do melhor baseline de modelo de fronteira usando abordagem tradicional de chunk-and-merge Endereça três falha comum: reconciliação entre página distante em documento longo, saída longa com muito item repetido, e schema com campo que exige raciocínio, não só extração literal Harness agentico dispara subagente em paralelo por trecho do documento e depois faz o merge final num único resultado estruturado Minha ressalva: ganho de sete pontos de acurácia custa alguma coisa em latência e custo computacional, já que agora tem modelo afinado mais harness agentico rodando subagente em paralelo em vez de uma chamada só. Antes de trocar todo pipeline de extração para Precision Mode, vale medir se o schema e o volume de documento do seu caso realmente estão no território onde o chunk-and-merge tradicional falha, porque para documento curto e schema simples o ganho tende a ser marginal frente ao custo extra.\nFonte: https://www.databricks.com/blog/databricks-document-intelligence-pushing-frontier-complex-document-extraction\n#Databricks #DocumentIntelligence #AzureDatabricks\n","permalink":"https://wiliamrosa.github.io/posts/ai-extract-precision-mode-documentos-complexos/","summary":"Precision Mode no ai_extract combina modelo especializado com um harness agentico que dispara subagentes em paralelo por seção do documento e depois junta os resultados, atingindo 94,7% de acurácia em benchmark contra 9 mil documentos, sete pontos acima do melhor baseline de modelo de fronteira com chunk-and-merge.","title":"AI Extract ganhou modo Precision pra documento longo e schema complexo demais pro chunk-and-merge"},{"content":"Trabalhar com Databricks remotamente sempre teve aquele atrito de sincronizar dependência e versão de runtime entre a máquina local e o cluster.\nA Databricks lançou um túnel SSH que conecta VS Code, Cursor ou o terminal direto num compute do Azure Databricks, seja serverless, AI Runtime ou cluster dedicado. Isso elimina a etapa de replicar manualmente o ambiente Python local para bater com o Databricks Runtime remoto: o editor passa a rodar e depurar notebook e arquivo de workspace com dependência e versão já sincronizadas com o cluster de verdade, não com uma cópia local que pode ter versão de biblioteca diferente.\nA ativação usa a flag --ide apontando pra vscode ou cursor; sem essa flag, a sessão abre direto no terminal, e de lá dá pra navegar até /Workspace/Users/seu-usuario pra acessar os arquivos do workspace normalmente. Do lado de agente de código, Cursor e GitHub Copilot já funcionam sem configuração extra dentro do túnel, e é possível instalar outro agente, como Claude Code, manualmente depois que a sessão SSH está ativa, o que dá a esses agentes o contexto completo do workspace.\nPontos técnicos que valem registrar:\nConexão via SSH tunnel para compute serverless, AI Runtime ou cluster dedicado, com flag --ide para vscode/cursor ou modo terminal puro Arquivo e dependência ficam sempre sincronizados com o Databricks Runtime do cluster remoto, não com o ambiente local Cursor e Copilot funcionam nativamente; outros agentes como Claude Code precisam ser instalados manualmente dentro da sessão Sessão SSH pode cair depois de uma hora de inatividade Limite de dez conexões SSH simultâneas por cluster Minhas considerações: é uma peça de developer experience bem-vinda para quem já vive trocando de editor local para notebook remoto, mas o limite de dez conexões por cluster e a queda de sessão em uma hora deixam claro que isso foi pensado para uso individual em desenvolvimento, não para virar um padrão de equipe inteira compartilhando poucos clusters. Vale testar antes de assumir que substitui Databricks Connect ou Asset Bundles no fluxo de CI/CD.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/dev-tools/ssh-tunnel\n#Databricks #DeveloperExperience #AzureDatabricks\n","permalink":"https://wiliamrosa.github.io/posts/databricks-ssh-tunnel-vscode-cursor-compute/","summary":"O túnel SSH conecta editor local ou CLI direto num cluster serverless, AI Runtime ou dedicado do Azure Databricks, com Cursor e Copilot funcionando de fábrica e Claude Code instalável na sessão. Sessão cai depois de uma hora e o limite é de dez conexões por cluster, então não é substituto de workflow de produção.","title":"Agora dá pra plugar VS Code, Cursor ou terminal direto no compute do Azure Databricks via SSH"},{"content":"A Databricks tornou GA duas extensões do OpenSharing que ampliam o alcance de quem já usa Lakehouse Federation pra unificar acesso a dado espalhado fora do Databricks.\nA primeira permite compartilhar tabela Iceberg federada de um catálogo Iceberg externo através do OpenSharing, incluindo pra quem consome usando um cliente Iceberg de fora do ecossistema Databricks, sem precisar copiar o dado pra dentro da plataforma antes de compartilhar. A segunda vai além: permite compartilhar schema inteiro ou tabela federada vinda de fonte de dado externa qualquer via Lakehouse Federation, não só Iceberg, mas aqui existe uma diferença importante de custo, porque compartilhar schema ou tabela externa dessa forma materializa o dado do lado do provedor, o que gera custo de compute e armazenamento que o compartilhamento de tabela Iceberg federada normalmente não exige.\nNa prática, isso amplia o OpenSharing de \u0026ldquo;compartilhar o que já está nativamente no Unity Catalog\u0026rdquo; pra \u0026ldquo;compartilhar o que está federado de fora\u0026rdquo;, incluindo banco relacional e outro data warehouse acessado via Lakehouse Federation, sem forçar uma ingestão completa antes.\nPontos técnicos:\nCompartilhamento de tabela Iceberg federada de catálogo Iceberg externo via OpenSharing, GA, sem cópia de dado, compatível com cliente Iceberg externo ao Databricks Compartilhamento de schema ou tabela federada de fonte externa qualquer via Lakehouse Federation, GA, mas com materialização do dado do lado do provedor Materialização de schema/tabela externa compartilhada gera custo adicional de compute e armazenamento, ao contrário do caminho de tabela Iceberg federada Ambos os recursos dependem de a fonte já estar configurada via Lakehouse Federation antes de poder ser incluída num share Minha ressalva: a diferença de custo entre os dois caminhos, um sem materialização e outro que materializa do lado do provedor, é o tipo de detalhe que pode passar despercebido até a fatura de compute chegar maior que o esperado. Antes de expor schema externo inteiro via OpenSharing pra múltiplos recipientes, vale simular o volume de dado envolvido e entender que aquele compartilhamento específico não é gratuito do jeito que compartilhar uma tabela Unity Catalog nativa costuma ser.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/release-notes/product/2026/september#sharing-foreign-iceberg-tables-with-opensharing-is-now-generally-available\n#Databricks #OpenSharing #AzureDatabricks\n","permalink":"https://wiliamrosa.github.io/posts/opensharing-tabelas-iceberg-schemas-externos/","summary":"Duas novidades GA no OpenSharing: compartilhar tabela Iceberg federada de catálogo externo via Lakehouse Federation, inclusive pra cliente Iceberg de fora do Databricks, sem copiar dado; e compartilhar schema ou tabela inteira federada de fonte externa, essa última materializando o dado do lado do provedor e gerando custo extra de compute e armazenamento.","title":"OpenSharing agora compartilha tabela Iceberg e schema inteiro vindo de fonte externa via federação"},{"content":"A Databricks lançou suporte nativo a tabela temporária no Databricks SQL, fechando uma lacuna que forçava analista e engenheiro a criar tabela permanente só pra armazenar resultado intermediário e depois lembrar de apagar depois.\nA tabela criada com CREATE TEMPORARY TABLE (ou CREATE TEMP TABLE) é uma tabela Delta física de verdade, guardada num local interno do Unity Catalog atrelado ao workspace, usando o mesmo cache e as mesmas otimizações de performance de uma tabela Delta comum. A diferença é o ciclo de vida: ela existe só enquanto a sessão que a criou estiver ativa, com um teto absoluto de sete dias mesmo que a sessão continue aberta além disso, e um serviço de limpeza remove o objeto automaticamente quando a sessão termina ou esse limite é atingido.\nIsso resolve um padrão comum em pipeline SQL exploratório e em análise ad hoc: materializar um resultado intermediário pra reaproveitar em consulta seguinte sem pagar o custo de recalcular do zero, mas sem precisar criar uma tabela permanente que alguém vai ter que lembrar de derrubar depois, ou que vai aparecer indevidamente em listagem de catálogo pra outras pessoas do time.\nPontos técnicos:\nCriação via CREATE TEMPORARY TABLE / CREATE TEMP TABLE, com variante CREATE OR REPLACE TEMPORARY TABLE pra substituir uma já existente Suporta tanto tabela vazia com schema definido quanto tabela criada a partir do resultado de uma consulta Escopo de sessão: tabela some quando a sessão termina, com limite máximo absoluto de sete dias de vida Fisicamente é uma tabela Delta, armazenada em local interno do Unity Catalog atrelado ao workspace, com mesmo cache e otimização de performance de tabela padrão Limpeza é automática via serviço dedicado, sem exigir DROP TABLE manual ao final do trabalho Minhas considerações: o ganho de não poluir o catálogo com tabela de vida curta é real, mas o teto de sete dias pode surpreender quem tem sessão de notebook ficando aberta por dia demais, ou pipeline job de longa duração que depende de reaproveitar uma tabela temporária entre execuções separadas, esse tipo de padrão vai continuar exigindo tabela permanente mesmo com a novidade.\nFonte: https://www.databricks.com/blog/introducing-temporary-tables-databricks-sql\n#Databricks #DatabricksSQL #AzureDatabricks\n","permalink":"https://wiliamrosa.github.io/posts/temporary-tables-databricks-sql/","summary":"CREATE TEMPORARY TABLE cria uma tabela Delta física que existe só durante a sessão que a criou, com limite máximo de sete dias de vida, usando a mesma infraestrutura de cache e performance de uma tabela padrão, mas sem exigir limpeza manual nem poluir o catálogo com objeto de vida curta.","title":"Databricks SQL ganhou tabela temporária de verdade, escopada por sessão e com limpeza automática"},{"content":"O Databricks MVP Maksim Pachkouski apontou uma mudança pequena na superfície mas grande no efeito prático pra quem cuida de custo de IA generativa dentro da empresa.\nAté aqui, orçamento de Genie Code só gerava alerta quando o limite era excedido, o que na prática significava que alguém precisava ver a notificação e agir manualmente pra impedir gasto continuar subindo. Com a opção Block usage habilitada, o próprio sistema impede o usuário de continuar usando o produto assim que o limite é ultrapassado, seja um limite compartilhado, por time ou por usuário individual, até o orçamento resetar no início do mês seguinte ou um administrador aumentar manualmente o limite daquela pessoa ou grupo.\nO detalhe que merece atenção é como a prioridade funciona quando existe mais de um nível de limite configurado ao mesmo tempo: se o limite compartilhado (do time ou da organização) estourar e estiver com bloqueio ativado, todo mundo dentro daquele escopo é bloqueado, mesmo quem individualmente nem chegou perto do próprio limite pessoal. Do mesmo jeito, um usuário que bate no próprio limite individual é bloqueado mesmo que o pool compartilhado ainda tenha saldo sobrando.\nPontos técnicos:\nBlock usage bloqueia uso de Genie Code assim que o limite configurado é excedido, até reset mensal ou aumento manual por um admin Limite pode ser configurado em nível compartilhado (organização/time) ou por usuário individual Limite compartilhado excedido com bloqueio ativo bloqueia todo mundo do escopo, mesmo quem não bateu o próprio limite pessoal Limite individual excedido bloqueia aquele usuário mesmo com saldo sobrando no pool compartilhado Uso gratuito mensal de cada usuário nunca é removido por configuração de orçamento Databricks recomenda manter só \u0026ldquo;Send alert\u0026rdquo; ativo e usar limite por usuário com override específico em vez de bloqueio geral, pra ter controle mais granular Minhas considerações: a própria recomendação da Databricks de preferir alerta e limite individual em vez de bloqueio geral já é um sinal de que Block usage é uma ferramenta de última linha, útil pra estourar teto de orçamento em cenário real de descontrole, mas arriscada como configuração padrão porque pode travar time inteiro por causa do consumo de uma pessoa só dentro do mesmo pool compartilhado.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/genie/budgets\n#Databricks #GenieCode #AzureDatabricks\n","permalink":"https://wiliamrosa.github.io/posts/genie-code-block-usage-orcamento/","summary":"A opção Block usage nos controles de orçamento do Genie Code impede o usuário de continuar usando o produto assim que o limite mensal, geral, por time ou por pessoa, é excedido, até o orçamento resetar no início do mês ou um admin liberar mais uso; antes só existia alerta, sem bloqueio efetivo.","title":"Genie Code agora pode bloquear uso de verdade quando o orçamento estoura, não só avisar"},{"content":"O Databricks MVP Juan Diaz chamou atenção pra uma expansão de identidade que importa justamente porque governança de agente de IA depende de saber, com precisão, quem ou o quê está pedindo acesso.\nO AIM sincroniza usuário, grupo e associação de grupo direto do provedor de identidade pra dentro do Databricks, eliminando a necessidade de manter provisionamento via SCIM em paralelo. O recurso já era GA via Entra ID especificamente no Azure Databricks; agora a mesma capacidade GA chega também pra AWS e GCP, e o Okta entra como provedor suportado em preview público. Isso importa mais do que parece numa organização multi-cloud, porque até aqui o time de identidade precisava manter estratégia diferente de sincronização dependendo de qual nuvem hospedava qual workspace.\nJunto dessa expansão vieram as políticas de ingress baseadas em contexto, que controlam acesso de agente de IA a recursos como Genie, dashboard e Databricks Apps não só pela identidade de quem está por trás do agente, mas pelo contexto da requisição em si. É uma peça que fecha lacuna real de segurança à medida que mais agente autônomo passa a interagir com dado corporativo sem uma pessoa clicando em cada etapa.\nPontos técnicos:\nAIM via Entra ID: GA em AWS e GCP, complementando GA que já existia no Azure Databricks Okta como provedor de identidade para AIM: preview público Sincronização automática de usuário, grupo e associação de grupo do provedor de identidade, dispensando SCIM Sincronização de grupo aninhado funciona com Entra ID; Okta não suporta grupo aninhado Políticas de ingress baseadas em contexto controlam acesso de agente de IA a Genie, dashboard e Databricks Apps Minha ressalva: a diferença de suporte a grupo aninhado entre Entra ID e Okta é o tipo de detalhe que só aparece depois que a migração já começou, então quem usa Okta e depende de hierarquia de grupo complexa precisa mapear isso antes de trocar o modelo de provisionamento, não depois. Vale também lembrar que Okta ainda está em preview, não GA, então mudança de comportamento até a estabilização é esperada.\nFonte: https://www.databricks.com/blog/automatic-identity-management-entra-id-now-generally-available-azure-databricks\n#Databricks #Segurança #AzureDatabricks\n","permalink":"https://wiliamrosa.github.io/posts/aim-identidade-automatica-agentes-ia/","summary":"O AIM (Automatic Identity Management) via Entra ID já era GA no Azure Databricks e agora chega GA também em AWS e GCP, com Okta entrando em preview público; junto vieram políticas de ingress baseadas em contexto pra controlar acesso de agente de IA a Genie, dashboard e Databricks Apps.","title":"Automatic Identity Management chegou pra AWS e GCP, e Okta entrou em preview"},{"content":"O Databricks MVP Derar Alhussein destacou um ajuste fino de governança que muda um comportamento que até então era fixo: o período de sete dias em que uma tabela derrubada por engano ficava recuperável.\nO Unity Catalog sempre manteve tabela gerenciada derrubada recuperável via UNDROP TABLE por sete dias, prazo fixo e igual pra todo mundo. Agora, em Public Preview, dá pra configurar esse período em nível de catálogo ou de schema usando a cláusula RETAIN DROPPED TO, aceitando de zero horas, que desativa completamente a recuperação, até trinta dias. Isso importa tanto pra quem precisa de uma janela maior de segurança operacional quanto pra quem, por política de retenção de dado regulada, precisa garantir que dado apagado realmente suma rápido e não fique recuperável por padrão.\nA configuração é declarativa e pode ser feita tanto na criação quanto depois: CREATE CATALOG meu_catalogo RETAIN DROPPED FOR 30 DAYS ou ALTER SCHEMA meu_catalogo.meu_schema RETAIN DROPPED TO 7 DAYS, por exemplo. Quando catálogo e schema têm configuração diferente, o valor definido no schema é o que vale pras tabelas daquele schema específico.\nPontos técnicos:\nConfigurável via ALTER CATALOG / ALTER SCHEMA ... RETAIN DROPPED TO, ou na criação com RETAIN DROPPED FOR Aceita de zero horas (desabilita recuperação via UNDROP) até trinta dias Configuração em nível de schema tem precedência sobre a de catálogo quando os dois estão definidos Exige privilégio MANAGE ou posse do catálogo/schema pra alterar o período Mudança só vale pra tabela derrubada depois da configuração, não retroage sobre tabela já derrubada antes Arquivo de dado da tabela é efetivamente apagado do armazenamento em nuvem em até 48 horas depois do fim do período de recuperação Minhas considerações: dar esse controle pro nível de schema é o tipo de granularidade que faz sentido numa organização com times diferentes tendo tolerância a risco diferente, um schema de sandbox pode ter zero retenção e um schema de produção crítica pode ir até os trinta dias. O ponto de atenção é justamente a irretroatividade: configurar isso hoje não protege tabela que já foi derrubada ontem sob a regra antiga de sete dias.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/tables/managed\n#Databricks #UnityCatalog #AzureDatabricks\n","permalink":"https://wiliamrosa.github.io/posts/undrop-table-periodo-retencao-configuravel/","summary":"Em Public Preview, ALTER CATALOG ou ALTER SCHEMA com a cláusula RETAIN DROPPED TO permite configurar entre zero (desabilita recuperação) e trinta dias quanto tempo uma tabela gerenciada derrubada fica recuperável via UNDROP TABLE, com a configuração de schema tendo precedência sobre a de catálogo.","title":"UNDROP TABLE ganhou período de retenção configurável em vez dos sete dias fixos"},{"content":"Time de marketing que depende de dado espalhado entre plataforma de anúncio, CRM e ferramenta de atendimento geralmente resolve isso construindo (e depois mantendo pra sempre) uma integração customizada pra cada fonte.\nA Databricks publicou um panorama de como o Lakeflow Connect ataca esse problema com conector gerenciado nativo, sem infraestrutura pra provisionar, gerenciar ou escalar por conta própria. São mais de 15 conectores organizados pela jornada do cliente: aquisição (Google Analytics, Meta Ads, TikTok Ads, LinkedIn Ads), engajamento (Salesforce Marketing Cloud, SendGrid, Marketo), relacionamento (Salesforce, HubSpot, Dynamics 365) e experiência (Zendesk, Amplitude, Pendo). O dado chega como managed table governada no Unity Catalog, já no formato certo pra virar análise sem etapa extra de limpeza estrutural.\nOs conectores de plataforma de anúncio entregam tabela de relatório pronta, com gasto, impressão, clique e conversão como Delta table atualizada de forma incremental, então não é preciso desenhar esse schema na mão nem ficar reconciliando taxonomia diferente entre TikTok Ads e Meta Ads. Pra quem quer ir além da tabela crua, o acelerador Ad-Genie refina esse dado ingerido em camada silver e gold, alimentando dashboard AI/BI e Genie agent apoiados em metric views do Unity Catalog, então a mesma definição de métrica de marketing fica disponível tanto pra dashboard quanto pra pergunta em linguagem natural.\nPontos técnicos que valem atenção:\nMais de 15 conectores nativos cobrindo aquisição, engajamento, relacionamento e experiência do cliente Dado chega como managed table governada no Unity Catalog, sem infraestrutura própria pra manter Conector de anúncio entrega tabela de relatório pronta (gasto, impressão, clique, conversão) com atualização incremental Acelerador Ad-Genie refina o dado em camada silver e gold com metric views pra dashboard e Genie agent Minhas considerações: consolidar conector de marketing dentro da mesma plataforma que já governa o resto do dado da empresa é o tipo de coisa que parece incremental no anúncio mas resolve um atrito real, o de marketing viver numa ilha de dado separada do resto da organização. O ganho maior aparece quando alguém realmente cruza dado de campanha com dado de produto ou financeiro, não só quando substitui uma integração antiga por outra gerenciada.\nFonte: https://www.databricks.com/blog/unify-your-marketing-data-lakeflow-connect\n#Databricks #LakeflowConnect #DataEngineering\n","permalink":"https://wiliamrosa.github.io/posts/lakeflow-connect-dados-marketing-unificados/","summary":"A Databricks reuniu mais de 15 conectores gerenciados do Lakeflow Connect cobrindo aquisição, engajamento, relacionamento e experiência do cliente, com tabela pronta de gasto e conversão pra plataforma de anúncio direto em Delta table.","title":"Marketing parou de precisar de conector customizado pra cada plataforma de anúncio"},{"content":"Ter Unity Catalog governando o dado e outro motor de consulta acessando esse mesmo dado direto costuma abrir uma brecha: quem garante que a política de acesso vale igual dos dois lados?\nA Databricks publicou um detalhamento de duas especificações que a comunidade Apache Iceberg adotou recentemente pra atacar esse problema de ângulos diferentes. Read restrictions padroniza como um motor de consulta confiável aplica controle de acesso delegado pelo catálogo de origem: o catálogo avalia a política pro usuário que está pedindo o dado e devolve instrução de filtragem, usando um vocabulário fechado de ações de projeção de coluna e expressão de filtro de linha, e o motor de destino aplica essas restrições na hora de acessar o dado. Catalog labels resolve outro cenário, o de catálogos federados heterogêneos: em vez de repetir checagem de permissão a cada consulta, o catálogo de origem anexa metadado de governança (rótulo chave-valor) direto na tabela ou coluna, e cada catálogo consumidor mapeia esse rótulo pro seu próprio sistema de governança nativo, aplicando a política localmente.\nO post organiza isso em três modelos, dependendo de quem está do outro lado: enforcement centralizado via serviço de filtragem seguro pra motor não confiável, read restrictions pra motor confiável com acesso direto, e catalog labels pra federação entre sistemas de governança autônomos e heterogêneos. Cada modelo troca expressividade de política, trilha de auditoria, performance e escala de um jeito diferente, então a escolha depende de quanto se confia no motor do outro lado e de quanto overhead de checagem repetida a arquitetura consegue absorver.\nPontos técnicos que valem atenção:\nRead restrictions: catálogo de origem avalia a política e devolve instrução de filtragem num vocabulário padronizado Catalog labels: metadado de governança anexado em tabela ou coluna, mapeado localmente por cada catálogo consumidor Três modelos de enforcement dependendo do nível de confiança no motor de destino Ambas as especificações vieram de adoção recente pela comunidade Apache Iceberg, não são exclusivas do Databricks Minha ressalva: padronização entre projetos open source é sempre mais lenta que a evolução de um produto fechado, então vale acompanhar de perto quantos motores e catálogos de fato implementam essas duas especificações na prática antes de desenhar arquitetura de governança federada em cima delas. Especificação adotada no papel e especificação implementada de verdade em produção nem sempre andam no mesmo ritmo.\nFonte: https://www.databricks.com/blog/unifying-governance-across-engines-and-catalogs-open-lakehouse\n#Databricks #UnityCatalog #ApacheIceberg\n","permalink":"https://wiliamrosa.github.io/posts/unificando-governanca-engines-catalogos-open-lakehouse/","summary":"A comunidade Apache Iceberg adotou read restrictions e catalog labels, duas especificações que a Databricks detalhou pra resolver o mesmo problema por ângulos diferentes: como manter política de acesso consistente quando motor de consulta e catálogo de dado não são os mesmos.","title":"Governança consistente entre motor e catálogo diferente: o Open Lakehouse propõe dois padrões novos"},{"content":"Achar que managed table é só uma external table sem o LOCATION explícito é o tipo de simplificação que engana o time inteiro na hora de planejar retenção de dado.\nO Databricks MVP Jacek Laskowski destacou um artigo de Youssef Mrini que volta ao básico do Unity Catalog pra explicar essa diferença direito. Numa external table, quem decide onde o dado físico mora é quem criou a tabela, apontando pra um caminho de storage já existente, e dropar a tabela remove só o registro de metadado, o arquivo continua lá. Numa managed table, o Unity Catalog escolhe e controla o caminho de armazenamento dentro da managed storage location do catálogo ou schema, e dropar a tabela remove também o dado físico.\nEssa diferença de propriedade sobre o ciclo de vida é o que abre espaço pra Databricks aplicar otimização automática só em managed table, como predictive optimization, compactação e vacuum sem o time precisar agendar job manual pra isso. External table continua útil quando o dado já existe em algum lugar específico, por exigência de compliance ou porque outro sistema também lê o mesmo arquivo, mas aí o time abre mão de parte dessa automação em troca de controle total sobre onde o byte fica.\nPontos técnicos que valem revisar:\nManaged table: Databricks controla local de armazenamento e ciclo de vida completo do arquivo External table: local de armazenamento é definido explicitamente via LOCATION, arquivo sobrevive ao DROP TABLE Só managed table recebe otimização automática de storage por padrão Governança de acesso via Unity Catalog vale igual pros dois tipos Escolha errada nesse ponto costuma aparecer como surpresa só na hora de migrar ou de fazer disaster recovery Minhas considerações: é um daqueles conceitos que parece óbvio quando já se trabalha com Unity Catalog há um tempo, mas que continua gerando escolha errada em projeto novo, geralmente porque alguém copia um exemplo de tutorial sem entender a implicação de longo prazo. Vale revisitar esse artigo com quem está desenhando arquitetura de dado agora, antes da decisão virar dívida técnica.\nFonte: https://community.databricks.com/t5/technical-blog/actually-understanding-unity-catalog-managed-tables/ba-p/168194\n#Databricks #UnityCatalog #DataEngineering\n","permalink":"https://wiliamrosa.github.io/posts/unity-catalog-managed-tables-entendendo/","summary":"Um artigo do Youssef Mrini, destacado pelo Databricks MVP Jacek Laskowski, revisita um ponto que ainda confunde muita gente: managed table não é só \u0026rsquo;tabela sem LOCATION\u0026rsquo;, é a Databricks assumindo o ciclo de vida inteiro do dado.","title":"O que realmente separa uma managed table de uma external table no Unity Catalog"},{"content":"Trace de agente de IA em produção acumula rápido, e deixar tudo pra sempre no mesmo backend SQL que atende consulta interativa cedo ou tarde vira gargalo de performance.\nO Databricks MVP Juan Diaz destacou o Trace Retention \u0026amp; Auto Archival, lançado no MLflow 3.13, que ataca esse problema com uma rotina automática rodando em segundo plano. Span de trace mais velho que a janela de retenção configurada sai do backend SQL, otimizado pra consulta rápida, e vai pra um object storage mais barato, como S3. O ponto importante é que essa mudança de local é transparente: quem consulta o trace pela interface ou pela API continua enxergando o histórico completo, sem precisar saber se aquele trace específico está quente no SQL ou frio no object storage.\nA configuração é feita por política, não por comando manual repetido: um YAML no servidor define se o arquivamento está ligado, pra onde vai (um bucket S3, por exemplo), qual a janela de retenção e de quanto em quanto tempo a rotina roda. A partir daí, quem administra o workspace ou é dono do experimento pode apertar essa retenção pela própria interface ou linha de comando, sem precisar mexer na configuração central do servidor, e cada trace passa a mostrar um selo indicando quando ele será arquivado.\nPontos técnicos que valem atenção:\nRotina em segundo plano move trace vencido do backend SQL pro object storage automaticamente Leitura via UI e API continua funcionando igual, independente de onde o trace está fisicamente Política resolve em cascata: servidor, depois workspace, depois experimento Configuração via YAML no servidor (trace_archival, location, retention, interval_seconds) Interface mostra selo de \u0026ldquo;Archive after\u0026rdquo; em cada trace com a data efetiva de corte Minhas considerações: é o tipo de feature que não aparece em nenhum anúncio chamativo mas resolve um problema real de quem já roda agente em produção há alguns meses e começou a sentir o backend de trace pesando. Vale configurar a política de retenção antes que o volume vire problema, não depois que a consulta de trace já está lenta.\nFonte: https://mlflow.org/releases/3.13.0/\n#Databricks #MLflow #Observabilidade\n","permalink":"https://wiliamrosa.github.io/posts/mlflow-trace-retention-auto-archival/","summary":"O Databricks MVP Juan Diaz destacou o Trace Retention \u0026amp; Auto Archival do MLflow 3.13: uma rotina em segundo plano move trace mais antigo que a janela de retenção do backend SQL pra object storage, sem perder leitura via UI nem API.","title":"Trace antigo do MLflow agora sai sozinho do banco caro e vai pra object storage barato"},{"content":"Imagine este cenário: seu time de dados construiu um lakehouse impecável. Pipelines de ingestão, camadas bronze/silver/gold, dashboards brilhando. Tudo está funcionando perfeitamente.\nAté que alguém pergunta: \u0026ldquo;e a aplicação de produção? Onde ela armazena os dados transacionais?\u0026rdquo;\nÉ aí que começa a dor de cabeça. Você precisa de um banco OLTP separado (Postgres, MySQL, DynamoDB\u0026hellip;), pipelines de CDC pra levar os dados ao lakehouse, reverse ETL pra devolver dados enriquecidos à aplicação, e um time de infraestrutura pra manter tudo funcionando. O resultado é data silo, latência de sincronização, complexidade operacional e custo cada vez maior.\nArquitetura tradicional, e seus pontos de dor É assim que a maioria das empresas opera hoje:\nOs pontos de dor dessa arquitetura são conhecidos de quem já operou algo parecido:\nMúltiplas ferramentas e fornecedores pra gerenciar. Latência significativa entre a escrita no OLTP e a disponibilidade no lakehouse. Governança fragmentada, já que o Unity Catalog não enxerga o banco externo. Custo operacional alto associado aos pipelines de sincronização. O que é o Lakebase Lakebase é um banco de dados Postgres totalmente gerenciado e integrado nativamente à Databricks Data Intelligence Platform, projetado pra preencher a lacuna entre workload transacional (OLTP) e analítico (OLAP), unificando os dois num único ecossistema.\nEm termos simples: é como ter um servidor Postgres de alto desempenho vivendo dentro do seu lakehouse, com governança unificada via Unity Catalog, sincronização bidirecional nativa e recursos modernos como autoscaling, scale-to-zero e database branching.\nA nova arquitetura com Lakebase O que muda em relação ao modelo tradicional:\nZero infraestrutura de banco de dados externo. Sincronização bidirecional nativa, sem Debezium, sem Airflow. Governança unificada por meio do Unity Catalog. Um único control plane pra OLTP e OLAP. As inovações arquiteturais do Lakebase Lakebase não é só mais um Postgres gerenciado. Ele leva conceito moderno de engenharia de dados pro mundo transacional.\nSeparação entre compute e storage. Diferente de banco de dados tradicional, onde CPU e disco estão acoplados, o Lakebase separa completamente compute de storage. Cada um escala de forma independente, e você paga só pelo que usa.\nCopy-on-write storage. O storage usa uma abordagem copy-on-write: quando você cria uma branch do banco, não há duplicação de dado, só a alteração é armazenada separadamente. Isso torna operação de branching e restore praticamente instantânea.\nAutoscaling e scale-to-zero. O compute ajusta a capacidade automaticamente conforme a demanda. Em período de inatividade, o banco executa scale-to-zero, eliminando custo, e volta a acordar em segundos quando chega uma requisição nova.\nDatabase branching: Git pros seus dados Esse é provavelmente o recurso mais inovador. Assim como desenvolvedor cria branch no Git pra trabalhar numa feature isolada, o Lakebase deixa criar branch pro banco de dados inteiro.\nCasos de uso poderosos:\nDesenvolvimento: cada desenvolvedor tem sua própria branch do banco de dados, sem interferir em produção. Teste de migração: teste alteração de schema numa branch isolada antes de aplicar em produção. Instant restore: restaure o banco pra qualquer ponto no tempo (janela configurável de 0 a 30 dias) criando uma branch a partir desse ponto. Sincronização bidirecional: o fim do reverse ETL Uma das maiores vantagens é a sincronização nativa entre lakehouse e Lakebase:\nSynced Tables (lakehouse para Lakebase). Tabela do Unity Catalog é sincronizada automaticamente com o Lakebase, permitindo que aplicação consulte dado analítico enriquecido com baixa latência. Há suporte aos modos snapshot, triggered e continuous.\nLakehouse Sync (Lakebase para lakehouse). Dado transacional do Lakebase é replicado continuamente pra Delta Tables no Unity Catalog usando change data capture. A tabela de destino segue o padrão SCD Type 2, mantendo histórico completo das alterações.\nMinha leitura: isso elimina completamente a necessidade de ferramenta externa de CDC (Debezium, Fivetran), pipeline de reverse ETL (Census, Hightouch) e job customizado de sincronização em Airflow ou Prefect. Pra quem já manteve essa esteira de ferramentas rodando, a economia de superfície operacional é o argumento que mais pesa, mais até do que a promessa de latência baixa.\nTrês casos de uso estratégicos Feature serving pra ML em tempo real. O Lakebase funciona como online store pro Feature Store da Databricks. Feature calculada no lakehouse é sincronizada via Synced Tables pro Lakebase, de onde o modelo de ML consulta com latência de milissegundos.\nEstado de AI Agents. Agente de IA precisa persistir estado entre requisição, contexto de conversa, histórico de ação, dado de workflow. O Lakebase fornece banco de dados transacional nativo pra guardar esse estado com consistência ACID.\nDado transacional pra aplicação. Databricks Apps, ou qualquer aplicação externa, pode usar o Lakebase como banco de dados principal. A integração é nativa, basta adicionar o projeto Lakebase como resource na aplicação. Além disso, a Data API oferece interface REST compatível com PostgREST pra acesso HTTP direto.\nComparação: antes e depois Aspecto Sem Lakebase Com Lakebase Banco OLTP Externo (RDS, Cloud SQL\u0026hellip;) Nativo na plataforma Sincronização CDC externo + reverse ETL Bidirecional nativa Governança Fragmentada entre sistemas Unity Catalog unificado Scaling Manual ou semiautomático Autoscaling + scale-to-zero Ambiente de teste Dump/snapshot lento Branching instantâneo Custo de inatividade Paga compute ocioso Zero (scale-to-zero) Time-to-recovery Restore de backup (minutos/horas) Instant restore (segundos) Feature serving Infra separada (Redis, DynamoDB) Online store nativo Disponibilidade O Lakebase Autoscaling está disponível nas seguintes regiões da AWS: us-east-1, us-east-2, us-west-2, ca-central-1, sa-east-1, eu-central-1, eu-west-1, eu-west-2, ap-south-1, ap-southeast-1 e ap-southeast-2.\nA presença em sa-east-1 é particularmente relevante pra nós da comunidade brasileira, garantindo baixa latência pra aplicação hospedada no Brasil.\nO que isso não resolve Vale o mesmo ceticismo saudável que aplico a qualquer feature nova: unificar OLTP e OLAP numa plataforma só resolve o problema de infraestrutura fragmentada, mas não resolve sozinho decisão de modelagem de dado, disciplina de schema entre ambiente, nem a curva de aprendizado de quem nunca operou Postgres em produção. E a cobertura de região ainda é uma lista fechada, então quem depende de uma região fora dela precisa esperar ou desenhar em volta disso.\nConclusão O Lakebase representa uma mudança de paradigma: em vez de tratar OLTP e OLAP como mundos separados que precisam de pontes complexas, ele os unifica numa única plataforma.\nPros times de dados brasileiros, isso significa menos ferramenta pra gerenciar e integrar, menos pipeline que quebra silenciosamente às três da manhã, mais tempo focado em gerar valor com dado, e governança real em todo o ciclo de vida do dado, da escrita transacional ao dashboard executivo.\nO lakehouse finalmente tem seu banco de dados transacional nativo. E ele fala Postgres.\nReferências Microsoft Learn, \u0026ldquo;Lakebase Postgres - Azure Databricks\u0026rdquo;: https://learn.microsoft.com/en-us/azure/databricks/oltp/projects/ Databricks, \u0026ldquo;Lakebase - Serverless Postgres for Agents and Apps\u0026rdquo;: https://www.databricks.com/product/lakebase #Databricks #Lakebase #Postgres #Arquitetura\n","permalink":"https://wiliamrosa.github.io/articles/lakebase-lacuna-aplicacoes-analytics/","summary":"Lakebase é um Postgres totalmente gerenciado e nativo da Databricks Data Intelligence Platform, pensado pra unificar workload transacional e analítico com governança única via Unity Catalog, sincronização bidirecional e recursos como autoscaling, scale-to-zero e database branching.","title":"A lacuna entre aplicações e analytics, e como o Lakebase a resolve"},{"content":"Desenhar um crew de agentes com papel, tarefa e ferramenta definidos costuma virar um arquivo de configuração gigante antes mesmo do primeiro teste rodar.\nO Databricks MVP Josue Bogran gravou uma demonstração do Kasal, um projeto do Databricks Labs pensado pra reduzir essa fricção inicial. Em vez de escrever manualmente a definição de cada agente, tarefa e ferramenta num framework tipo CrewAI, o Kasal expõe uma tela visual onde dá pra montar o time de agentes arrastando blocos, ligando um agente ao seu papel e às tarefas que ele deve executar, e testar essa composição antes de publicar de verdade.\nO ponto central é encurtar o ciclo entre \u0026ldquo;ideia de fluxo multiagente\u0026rdquo; e \u0026ldquo;primeiro teste rodando\u0026rdquo;, que hoje costuma passar por escrever bastante código de cola só pra descobrir que a divisão de tarefas entre os agentes não fazia sentido. Depois de validado na interface, o fluxo pode ser publicado como Model Serving endpoint ou job dentro do próprio ambiente Databricks, reaproveitando a mesma governança de Unity Catalog que já vale pro resto da plataforma.\nPontos técnicos que valem atenção:\nInterface visual pra compor agente, papel, tarefa e ferramenta sem editar YAML na mão Pensado pra padrão de multiagente tipo crew, um agente coordenando ou colaborando com outros Permite testar a composição antes de publicar Publicação final vira Model Serving endpoint ou job dentro do Databricks É projeto do Databricks Labs, então sem SLA de suporte formal como um produto GA Minha ressalva: interface visual pra multiagente ajuda muito no protótipo, mas a complexidade real de um sistema desses (o que acontece quando um agente trava, como depurar decisão errada de coordenação) não desaparece só porque a montagem inicial ficou mais fácil. Vale testar em cenário com falha de propósito antes de confiar isso em produção.\nFonte: https://youtu.be/iaZZCMDLr7s\n#Databricks #DatabricksLabs #AIAgents\n","permalink":"https://wiliamrosa.github.io/posts/kasal-databricks-labs-agentes-multiagente/","summary":"O Databricks MVP Josue Bogran mostrou o Kasal, projeto do Databricks Labs que dá uma interface visual pra desenhar, testar e publicar um grupo de agentes cooperando, sem escrever o código de orquestração na mão.","title":"Kasal: montar um time de agentes arrastando caixinha, não escrevendo orquestrador do zero"},{"content":"Migração de dialeto de SQL sempre foi trabalho manual demorado, script por script, corrigindo função proprietária uma de cada vez até tudo rodar igual no destino.\nO Databricks MVP Laurenz Wuttke explicou como funciona o agentic code converter, recurso em beta que usa o Genie Code pra automatizar boa parte dessa migração. O fluxo começa com a criação de um projeto de migração dentro do workspace, que serve como painel central acompanhando o estado de cada arquivo. A partir daí, o Genie Code aciona uma skill específica de migração e distribui subagentes que trabalham em paralelo, cada um convertendo um arquivo do dialeto de origem, como T-SQL, Snowflake, Redshift, Oracle, BigQuery ou Teradata, pra ANSI SQL compatível com Databricks.\nO diferencial em relação a um conversor de sintaxe tradicional é o loop de validação embutido: cada subagente não só traduz a query, ele valida o resultado e tenta de novo os trechos que falharam, em vez de entregar uma conversão que só parece certa até alguém rodar em produção. Isso não elimina a necessidade de revisão humana, mas tira do time boa parte do trabalho repetitivo de tradução linha a linha que consumia a maior parte do tempo numa migração desse tipo.\nPontos técnicos que valem atenção:\nRecurso em Beta, precisa ser ativado pelo admin do workspace na página de Previews Organizado como projeto de migração, que rastreia o estado de cada arquivo Suporta origem em T-SQL, Snowflake, Redshift, Oracle, BigQuery e Teradata Subagentes rodam em paralelo, cada um analisando, convertendo, validando e corrigindo seu próprio arquivo Resultado final é ANSI SQL pronto pra rodar no Databricks Minha ressalva: validação automática reduz erro óbvio de sintaxe, mas não garante que a lógica de negócio embutida numa stored procedure legada sobreviveu intacta à tradução. Query complexa com efeito colateral específico do dialeto de origem ainda merece revisão humana linha a linha antes de ir pra produção, não só o sinal verde do validador automático.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/migration/agentic-code-converter\n#Databricks #GenieCode #Migracao\n","permalink":"https://wiliamrosa.github.io/posts/agentic-code-converter-genie-code-migracao-sql/","summary":"O Databricks MVP Laurenz Wuttke detalhou o agentic code converter (Beta): o Genie Code converte script de T-SQL, Snowflake, Redshift, Oracle, BigQuery e Teradata pra ANSI SQL, com subagente validando e corrigindo cada arquivo em paralelo.","title":"Genie Code ganhou subagente pra migrar dialeto de SQL sozinho, com validação e retry"},{"content":"Segredo que já vive no Key Vault da empresa não precisa mais ser reimportado pra dentro do Unity Catalog pra virar governável.\nO Databricks MVP Hubert Dudek notou que o Azure Databricks lançou em beta o external secrets no Unity Catalog, um jeito de conectar um schema inteiro ao Azure Key Vault. Isso é diferente do UC secrets nativo (já GA desde agosto, quando segredo passou a viver como ativo de catálogo com namespace de três níveis). Ali, o valor fica armazenado dentro do próprio Unity Catalog. Aqui, o Databricks não guarda cópia nenhuma: cada leitura busca o valor direto no Key Vault, e o objeto que aparece no catálogo é só uma referência somente leitura com as permissões do Unity Catalog por cima.\nNa prática isso resolve um atrito comum em empresa que já centraliza segredo de aplicação inteira no Azure Key Vault e não quer manter dois lugares de verdade. Em vez de replicar chave de API, connection string ou certificado pro Databricks e depois se preocupar em manter os dois sincronizados, o time de segurança continua rotacionando segredo só no Key Vault, e quem usa Databricks enxerga esse mesmo segredo como um securable normal, com grant, revoke e auditoria de acesso pela trilha do Unity Catalog.\nPontos técnicos que valem atenção:\nConexão é feita no nível de schema, não segredo por segredo Objeto aparece no Unity Catalog como securable somente leitura Valor é buscado sob demanda no Azure Key Vault, sem cache persistente dentro do Databricks Governança de acesso continua sendo via privilégio do Unity Catalog, não via IAM do Key Vault Complementa, não substitui, o UC secrets nativo já em disponibilidade geral Minha ressalva: ter dois modelos de segredo coexistindo, o nativo e o externo, é o tipo de decisão que parece simples no anúncio e vira dúvida real de arquitetura seis meses depois, quando alguém precisa migrar um pra outro ou explicar pra auditoria por que metade dos segredos vive num lugar e metade em outro. Vale definir logo qual é o padrão do time antes de espalhar os dois em produção.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/security/secrets/external-secrets\n#Databricks #UnityCatalog #AzureDatabricks\n","permalink":"https://wiliamrosa.github.io/posts/unity-catalog-external-secrets-azure-key-vault-beta/","summary":"External secrets (Beta) conecta um schema do Unity Catalog direto ao Azure Key Vault: o segredo aparece como objeto governável e somente leitura, e o valor é lido sob demanda, sem duplicar cópia dentro do Databricks.","title":"Segredo externo no Unity Catalog: agora dá pra apontar direto pro Azure Key Vault"},{"content":"A maioria dos times que constrói agente de IA trata avaliação como uma etapa que acontece antes do deploy e depois nunca mais, um notebook rodado uma vez, um número de acurácia bonito num slide, e o agente vai pra produção sem nenhum mecanismo sistemático de saber se ele continua bom depois que o tráfego real, cheio de caso de borda que ninguém previu, começa a chegar. O resultado usual é um agente que degrada silenciosamente, e ninguém percebe até o cliente reclamar.\nO case da Zepto usando Azure Databricks e MLflow ilustra um jeito diferente de organizar isso, tratando avaliação como um sistema com dois loops que se retroalimentam, não como um checkpoint único. A escala ajuda a evidenciar o padrão (80%+ de automação de ticket de suporte, redução de custo relatada em 65%), mas o valor real do case está na arquitetura de avaliação em si, que qualquer time construindo agente em produção pode replicar independente do volume de tráfego.\nA composição do agente em si também merece nota: em vez de um agente monolítico tentando resolver todo tipo de ticket de suporte, a Zepto usa uma arquitetura composável, com agente especialista vertical pra cada tipo de problema (pedido errado, item faltante, prazo de validade, devolução, qualidade) e agente de supervisão horizontal cuidando de preocupação transversal como detecção de fraude e manipulação de imagem enviada pelo cliente. Isso importa pro tema de avaliação porque cada agente especialista pode ter seu próprio dataset dourado e seu próprio critério de qualidade, em vez de um critério genérico tentando cobrir toda a superfície de problema ao mesmo tempo.\nO mecanismo: dois loops, um portão de qualidade no meio A arquitetura tem duas metades com propósito diferente:\nLoop de desenvolvimento: onde nova versão de agente é construída e iterada com confiança, testada contra um dataset de avaliação antes de qualquer coisa tocar tráfego real. Loop de produção: onde o comportamento ao vivo é monitorado e falha é detectada continuamente, com trace completo de cada interação. Portão de qualidade: controla a promoção entre os dois loops, uma versão só sobe pra produção se passar em critério objetivo definido previamente. Por baixo dos dois loops, três peças técnicas do MLflow 3 sustentam o sistema:\nTracing automático, via mlflow.\u0026lt;library\u0026gt;.autolog() e o decorador @mlflow.trace, capturando prompt, resposta, documento recuperado, chamada de ferramenta e caminho de decisão como spans OpenTelemetry. Vale notar, pela documentação atual, que em compute serverless o autolog de tracing genAI não vem habilitado por padrão, precisa de chamada explícita. Dataset dourado, com exemplo anotado cobrindo caso normal, caso de borda e caso de falha, crescendo ao longo do tempo (a Zepto foi de 500 pra mais de 5.200 exemplos). Scorers, na terminologia atual do MLflow: juiz pronto (built-in judge) pra avaliação rápida, juiz customizado com critério e tipo de retorno flexível, e scorer baseado em código pra checagem determinística tipo formato ou correspondência exata. A combinação dos três forma o que a Zepto chama de \u0026ldquo;júri de IA\u0026rdquo;, com 80 a 90% de calibração contra rótulo humano. Mão na massa: um scorer customizado simples com MLflow Um exemplo de como fica um scorer básico combinando checagem determinística com um juiz de LLM, no espírito do que o MLflow 3 oferece:\nimport mlflow from mlflow.genai.scorers import scorer @scorer def resposta_cita_prazo_reembolso(inputs, outputs, trace): \u0026#34;\u0026#34;\u0026#34;Scorer baseado em código: valida se a resposta menciona prazo, exigência dura.\u0026#34;\u0026#34;\u0026#34; texto = outputs.get(\u0026#34;resposta\u0026#34;, \u0026#34;\u0026#34;) tem_prazo = any(p in texto.lower() for p in [\u0026#34;dia útil\u0026#34;, \u0026#34;dias úteis\u0026#34;, \u0026#34;prazo de\u0026#34;]) return {\u0026#34;passou\u0026#34;: tem_prazo, \u0026#34;motivo\u0026#34;: \u0026#34;menciona prazo\u0026#34; if tem_prazo else \u0026#34;sem prazo explícito\u0026#34;} @mlflow.trace def agente_suporte(pergunta: str) -\u0026gt; dict: resposta = chama_llm_com_contexto(pergunta) return {\u0026#34;resposta\u0026#34;: resposta} # Rodando avaliação contra o dataset dourado resultado = mlflow.genai.evaluate( data=dataset_dourado, predict_fn=agente_suporte, scorers=[resposta_cita_prazo_reembolso], ) Esse tipo de scorer determinístico é barato de rodar em todo trace de produção, o que viabiliza a amostragem estratificada por risco que a Zepto usa, cobrindo de 18% a 20% do tráfego total mas concentrando essa amostra em interação de maior risco, e obtendo, segundo o case, nove vezes mais detecção de caso de borda do que amostragem uniforme teria dado com o mesmo volume.\nMinha leitura: o detalhe que mais chama atenção nesse case não é o número de redução de custo, é o fato de o dataset dourado ser tratado como ativo vivo que cresce dez vezes ao longo do projeto, não como um artefato congelado criado uma vez no início. Isso é trabalho manual real, alguém tem que rotular caso de borda continuamente, e é o tipo de investimento que a maioria dos times corta primeiro quando o prazo aperta. Eu testaria a calibração do júri de IA contra rótulo humano no meu próprio domínio antes de confiar no número de 80 a 90% relatado pela Zepto, porque calibração de juiz de LLM varia bastante conforme o tipo de conteúdo avaliado, resposta de suporte de e-commerce é mais fácil de julgar automaticamente do que, por exemplo, laudo médico ou parecer jurídico.\nOtimização de prompt automatizada fecha o loop Uma peça que costuma passar batido nesse tipo de case é a otimização automatizada de prompt. O registro de prompt do MLflow (prompt registry) gera e testa variante de prompt contra os scorers já definidos, o que significa que a melhoria de prompt deixa de ser um processo manual de tentativa e erro feito por um engenheiro e passa a ser um processo mensurável, com cada variante avaliada contra o mesmo critério objetivo antes de ser promovida. Isso fecha o loop entre avaliação e desenvolvimento de um jeito que eu acho subestimado: o dataset dourado não serve só pra aprovar ou reprovar uma versão do agente, ele também serve como sinal de otimização pra gerar a próxima versão.\nO que isso não resolve Vale dizer com clareza onde essa arquitetura tem limite:\nScorer baseado em LLM continua custando token, e rodar júri de IA sobre volume alto de trace de produção sem estratégia de amostragem vira custo relevante rápido, daí a necessidade da amostragem estratificada, que por sua vez exige uma boa definição prévia do que é \u0026ldquo;interação de risco\u0026rdquo;. Portão de qualidade automatizado reduz, mas não elimina, risco de regressão silenciosa. Um critério numérico bem calibrado hoje pode ficar desatualizado conforme o comportamento do usuário muda, o dataset dourado precisa de manutenção contínua pra continuar representativo. Nada disso substitui desenho de agente bom. Arquitetura de avaliação sofisticada não conserta um agente com prompt mal escrito ou ferramenta mal desenhada, ela só torna visível, mais rápido, que o agente está errando. Fechamento O padrão de loop duplo com portão de qualidade é generalizável bem além de suporte ao cliente, qualquer agente de produção se beneficia de separar claramente \u0026ldquo;estou testando uma versão nova\u0026rdquo; de \u0026ldquo;estou monitorando o que está no ar\u0026rdquo;, com um critério objetivo decidindo a travessia entre os dois. A parte de infraestrutura (MLflow tracing, scorers, dataset dourado) é replicável hoje. A parte de disciplina, manter o dataset crescendo e recalibrando o júri de IA, é o trabalho de verdade que a maioria dos times subestima.\nReferências Post oficial: Evaluation-First AI Agents: How Zepto Scales Customer Support on Databricks and MLflow Documentação oficial: Automatic tracing para GenAI Documentação oficial (Microsoft Learn): Automatic tracing - Azure Databricks Documentação oficial: Scorers no MLflow GenAI Documentação oficial (Microsoft Learn): Scorers and LLM judges - Azure Databricks #Databricks #MLflow #AIEngineering #Avaliação\n","permalink":"https://wiliamrosa.github.io/articles/mlflow-avaliacao-loop-duplo-agentes-producao/","summary":"O case da Zepto usando MLflow mostra um padrão generalizável, dois loops separados, um de desenvolvimento e um de produção, ligados por um portão de qualidade, mais dataset dourado que cresce com o tempo e amostragem estratificada por risco em vez de amostragem uniforme. É engenharia de avaliação, não só uma métrica de acurácia isolada.","title":"Avaliação não é etapa final: o loop duplo que decide se um agente de IA vai pra produção"},{"content":"Quem já passou por um ciclo de fechamento regulatório em seguradora conhece o ritual: planilha trocada por e-mail entre atuário e controladoria, motor de cálculo (Prophet, RAFM, Igloo) rodando isolado, e alguém no fim do processo tentando reconciliar número de fontes diferentes horas antes do prazo do QRT vencer. O problema raramente é falta de modelo atuarial bom, é a cola entre os pedaços, ingestão, controle de qualidade, orquestração de modelo e trilha de aprovação, que normalmente não existe como sistema, existe como conhecimento tribal de quem já fez aquilo por anos.\nA Databricks propôs endereçar essa cola diretamente, não como um dashboard de BI a mais, mas como uma camada de controle central sobre o fluxo de reporte inteiro. Isso muda a pergunta de \u0026ldquo;que ferramenta de BI mostra o Solvency Ratio\u0026rdquo; pra \u0026ldquo;onde mora a visão única de onde o processo está, o que está atrasado, e quem aprovou o quê\u0026rdquo;.\nEsse tipo de proposta chega numa hora interessante do mercado segurador, com pressão regulatória crescente e prazo de reporte cada vez mais curto em várias jurisdições, e ao mesmo tempo com o mesmo time de atuária e controladoria sendo cobrado a fazer mais com o mesmo quadro de pessoas. Uma camada de orquestração que reduz o tempo gasto reconciliando número entre planilha tem valor mesmo antes de qualquer feature de IA generativa entrar na conversa, e é importante separar essas duas coisas na hora de avaliar a proposta.\nO mecanismo: control tower sobre um fluxo que já existia A arquitetura descrita se apoia em cinco peças que, individualmente, não são novidade, a novidade é elas conversarem em um só lugar:\nControl Tower: um painel central mostrando Solvency Ratio, prontidão para o prazo, aprovações pendentes, feed atrasado e problema em aberto, tudo num único ponto de visão em vez de espalhado por planilha. Ingestão automatizada com checagem de qualidade, validando frescor de dado, completude, dono do dado e regra de negócio customizada, com fluxo de decisão configurável pra cada tipo de falha. Orquestração de modelo atuarial, onde o Azure Databricks prepara o dado que motores como Prophet, RAFM e Igloo consomem, e depois ingere e governa a saída desses motores de volta pro lakehouse. Governança e trilha de auditoria, registrando promoção, aprovação e toda atividade relacionada ao relatório, com Unity Catalog como camada de controle de acesso. Análise assistida por IA, com LLM ajudando a redigir seção do relatório ORSA, e agente de IA revisando reconciliação de QRT e rodando análise de cenário (por exemplo, \u0026ldquo;e se a carteira de seguro cyber dobrar de tamanho\u0026rdquo;). O ponto estrutural é que o motor atuarial continua sendo o motor atuarial, o Azure Databricks não substitui Prophet ou RAFM, ele vira a camada que prepara o insumo, governa a saída e dá visibilidade do processo inteiro em cima disso.\nMão na massa: um exemplo de regra de qualidade e disposição de falha Um esboço de como ficaria uma checagem de completude e roteamento de falha, simplificado em SQL/Python dentro de um pipeline declarativo:\nfrom pyspark.sql import functions as F def valida_feed_atuarial(df, coluna_data=\u0026#34;data_referencia\u0026#34;, dono_esperado=\u0026#34;atuarial\u0026#34;): hoje = F.current_date() df_validado = ( df .withColumn(\u0026#34;atraso_dias\u0026#34;, F.datediff(hoje, F.col(coluna_data))) .withColumn( \u0026#34;status_qualidade\u0026#34;, F.when(F.col(\u0026#34;atraso_dias\u0026#34;) \u0026gt; 2, \u0026#34;atrasado\u0026#34;) .when(F.col(\u0026#34;dono_dado\u0026#34;) != dono_esperado, \u0026#34;dono_incorreto\u0026#34;) .when(F.col(\u0026#34;valor_total\u0026#34;).isNull(), \u0026#34;incompleto\u0026#34;) .otherwise(\u0026#34;ok\u0026#34;) ) ) return df_validado # Disposição: separa o que segue pro motor atuarial do que vai pra fila de correção feed_validado = valida_feed_atuarial(spark.table(\u0026#34;bronze.feed_apolices\u0026#34;)) feed_validado.filter(\u0026#34;status_qualidade = \u0026#39;ok\u0026#39;\u0026#34;).write.saveAsTable(\u0026#34;silver.feed_pronto_para_prophet\u0026#34;) feed_validado.filter(\u0026#34;status_qualidade != \u0026#39;ok\u0026#39;\u0026#34;).write.saveAsTable(\u0026#34;control_tower.fila_correcao\u0026#34;) Esse padrão de \u0026ldquo;valida, classifica, roteia\u0026rdquo; é o tipo de lógica que sustenta o painel do control tower, cada linha na fila de correção vira um item visível de pendência, não um erro escondido que só aparece no dia do prazo.\nMinha leitura: o pedaço mais interessante dessa proposta não é a parte de IA, é a trilha de auditoria nativa sobre um processo que hoje, na maioria das seguradoras que conheço, é auditado via captura de tela de planilha e e-mail de aprovação. Ter promoção, aprovação e atividade de relatório registrada de forma consistente no mesmo catálogo de dado é uma melhoria de governança que vale por si só, independente de qualquer feature de IA generativa. A parte de agente revisando reconciliação de QRT eu trataria com mais cautela, reconciliação regulatória tem zero margem pra erro silencioso, e eu exigiria trilha de decisão auditável e revisão humana obrigatória antes de qualquer número desses ir pro órgão regulador.\nO que isso não resolve Vale ser honesto sobre os limites dessa proposta:\nO motor atuarial legado continua sendo uma caixa preta externa. O Azure Databricks governa entrada e saída, mas não abre o cálculo atuarial em si, então qualquer erro de modelagem dentro do Prophet ou do RAFM continua fora do alcance dessa camada de governança. \u0026ldquo;Análise assistida por IA\u0026rdquo; pra ORSA e reconciliação de QRT é a parte mais nova e menos testada da proposta. Redigir rascunho de relatório regulatório com LLM ajuda a velocidade, mas não elimina a necessidade de revisão técnica por atuário sênior, e o post oficial não detalha nível de confiança ou processo de validação desse rascunho. Migrar um processo de fechamento regulatório inteiro pra um control tower novo é projeto de transformação, não configuração. Seguradora com processo já consolidado (mesmo que manual) enfrenta custo real de mudança de gestão antes de colher o benefício de visibilidade única. Quem já usa Genie e MLflow tem vantagem de adoção Vale reforçar um ponto prático: nada nessa arquitetura é exclusivo de seguradora ou de Solvency II especificamente. Control Tower como padrão de orquestração, checagem de qualidade configurável com disposição de falha, e trilha de auditoria via Unity Catalog são blocos genéricos que qualquer processo de fechamento regulatório complexo (tributário, contábil, prudencial) pode reaproveitar. A camada de Genie pra consulta em linguagem natural sobre o estado do processo, e MLflow pra rastrear versão e desempenho de modelo, também não são específicos do setor de seguro. Isso quer dizer que uma seguradora que já usa Azure Databricks pra outro workload tem vantagem real de adoção aqui, o esforço de configurar o control tower de Solvency II reaproveita infraestrutura de governança que ela provavelmente já pagou e já opera.\nFechamento Solvency II sempre foi mais um problema de processo do que de cálculo, e atacar a cola entre ingestão, modelo e aprovação com um control tower único é uma resposta sensata pra esse tipo de dor. A parte de IA generativa é a cereja do bolo, útil, mas não o motivo pelo qual esse tipo de arquitetura vale a pena adotar. Quem decide entrar nesse caminho deveria priorizar a parte de governança e trilha de auditoria primeiro, e tratar o agente de reconciliação como um assistente em avaliação, não como substituto de revisão humana.\nReferências Post oficial: A practical approach to end-to-end Solvency II reporting in Databricks #Databricks #FinancialServices #Governança #SolvencyII\n","permalink":"https://wiliamrosa.github.io/articles/databricks-solvency-ii-control-tower-relatorio-regulatorio/","summary":"Solvency II não é um relatório, é uma cadeia de ingestão, validação, modelagem atuarial e aprovação que hoje vive espalhada entre planilha, motor atuarial e ferramenta de BI isolada. A Databricks propõe um control tower único sobre o lakehouse, com trilha de auditoria nativa e agente de IA revisando reconciliação de QRT, mas isso não elimina a dependência do motor atuarial legado.","title":"Control tower, não relatório: orquestrando Solvency II sem sair do lakehouse"},{"content":"Todo engenheiro que já operou Postgres em produção aprendeu, de um jeito ou de outro, que ajustar shared_buffers é meio ritual, meio ciência exata. O valor clássico é algo como 25% da RAM disponível, e o resto fica por conta do cache de página do sistema operacional, que o Postgres nem enxerga diretamente. Esse acordo tácito entre banco e SO funciona bem quando os dois vivem na mesma máquina física, com o mesmo disco embaixo. O problema é que essa premissa desmorona assim que você desacopla compute de armazenamento, que é exatamente o que acontece dentro do Lakebase.\nO problema que a arquitetura desagregada cria No Postgres tradicional, uma página que não está nos shared buffers cai no cache de página do SO, que por sua vez é backed por um filesystem local. Duas camadas de cache, uma decisão de despejo (eviction) coordenada implicitamente pelo kernel. No Lakebase, a camada de compute é stateless: o dado durável vive numa camada de storage separada, com pageservers reconstruindo versões de página sob demanda e safekeepers replicando o write-ahead log via consenso Paxos. Isso significa que uma leitura que não está em memória não cai num filesystem local rápido, ela pode significar uma viagem de rede até o pageserver. Duplicar cache (shared buffers + cache de SO) deixou de fazer sentido, porque não existe mais aquele segundo nível \u0026ldquo;de graça\u0026rdquo; que o SO oferecia.\nComo a Databricks reorganizou as camadas de cache A solução documentada combina três frentes, cada uma endereçando um ponto de fricção diferente:\nLocal File Cache (LFC): uma camada de cache autoscaling que roda em paralelo aos shared buffers, usando NVMe local como storage secundário. Ela absorve o volume de leitura que não cabe nos shared buffers sem exigir round-trip até a camada de storage remota.\nShared buffers expandidos para compute fixo: em instâncias com capacidade de computação (CU) alta e estável, o LFC foi desabilitado e os shared buffers foram configurados para ocupar até 75% da DRAM disponível. Faz sentido: quando a carga é previsível e o compute não escala pra baixo com frequência, vale mais a pena centralizar tudo num único nível de cache maior do que manter duas camadas coordenando entre si.\nHuge pages (2 MB) em toda a stack virtualizada: essa é a parte que costuma passar despercebida. Numa VM, a tradução de endereço de memória passa por host, hypervisor e guest kernel. Com páginas de 4 KB (o padrão), o número de entradas na TLB (translation lookaside buffer) explode, gerando cache misses de tradução de endereço em cada camada. Usar páginas de 2 MB reduz drasticamente esse overhead.\nMinha leitura: o motivo pelo qual gosto desse tipo de post é que ele expõe o trabalho de infraestrutura que normalmente fica invisível pro usuário final. Quem provisiona um banco no Lakebase não escolhe huge page nem decide se o LFC está ligado, mas é exatamente esse tipo de decisão de engenharia embaixo do capô que determina se o SLA de latência que a Databricks promete se sustenta sob carga real.\nOs números que a Databricks publicou Os benchmarks divulgados mostram três cenários distintos, cada um batendo numa configuração diferente:\nUm caso com aproximadamente 2x de ganho em throughput e 5x de redução em leituras do storage remoto (de 8 mil pra 1,5 mil reads por segundo). Um segundo caso com 1,3x de ganho em throughput e taxa de acerto de cache (cache hit rate) próxima de 100%. Um terceiro caso com 5x de redução de uso de CPU (de 20 pra 4 núcleos) e 2x de throughput. Testes isolados de huge pages mostrando redução de cerca de 40% na tail latency (p99) e 30% em uso de CPU. Mão na massa: o que dá pra observar no seu próprio workload Você não configura huge pages nem LFC manualmente no Lakebase, isso é gerenciado pela plataforma. Mas dá pra monitorar o efeito prático disso via métricas do Postgres. Um jeito simples de acompanhar taxa de acerto de cache dos shared buffers:\nSELECT sum(heap_blks_read) AS heap_read, sum(heap_blks_hit) AS heap_hit, round( sum(heap_blks_hit)::numeric / nullif(sum(heap_blks_hit) + sum(heap_blks_read), 0), 4 ) AS cache_hit_ratio FROM pg_statio_user_tables; Se o cache_hit_ratio está consistentemente abaixo de 0.99 num workload que deveria caber em memória, vale investigar se o tamanho do compute (CU) escolhido está subdimensionado, porque no Lakebase isso se traduz diretamente em mais round-trips até a camada de storage remota, não só em mais uso de disco local como seria num Postgres convencional.\nOutra query útil é olhar o tamanho efetivo do working set versus a memória disponível, pra decidir se vale a pena subir de tier de compute antes de tentar qualquer otimização de query:\nSELECT pg_size_pretty(pg_database_size(current_database())) AS db_size; O que isso não resolve Cache maior e mais eficiente não resolve query mal escrita, índice ausente, nem falta de particionamento em tabela grande. Se o padrão de acesso é aleatório demais, ou se o working set genuinamente não cabe em nenhuma configuração razoável de CU, nenhuma camada de cache turbina isso o suficiente. Também vale lembrar que shared buffers expandidos pra 75% da DRAM só fazem sentido em compute fixo e previsível; num compute que escala pra zero ou pra baixo com frequência, esse tipo de configuração estática provavelmente reintroduziria o problema que o LFC resolve.\nNa prática: eu testaria o comportamento de failover e scale-to-zero com essas configurações de cache antes de assumir que o ganho de benchmark se replica em produção. Cache quente se perde em cold start, e o primeiro conjunto de queries depois de uma pausa de compute provavelmente não vê nenhum desses ganhos até \u0026ldquo;esquentar\u0026rdquo; de novo.\nResumindo O Lakebase precisou reinventar a lógica de cache do Postgres porque a premissa de compute e storage colados na mesma máquina não existe mais nesse modelo desagregado. A combinação de LFC autoscaling, shared buffers maiores pra compute fixo e huge pages na stack inteira entrega ganhos reais e documentados, mas é uma engenharia de infraestrutura que roda por trás da cena. Pra quem usa Lakebase no dia a dia, o valor prático está em monitorar cache hit ratio e dimensionar CU corretamente, não em tentar replicar manualmente o que a plataforma já faz.\nReferências Improving Lakebase Postgres compute cache performance (blog oficial Databricks) Lakebase Postgres architecture (documentação oficial) Lakebase architecture (Microsoft Learn) #Databricks #Lakebase #Postgres #Performance\n","permalink":"https://wiliamrosa.github.io/articles/lakebase-postgres-cache-huge-pages-shared-buffers/","summary":"O Lakebase separa compute de storage, e isso quebra a lógica de cache que o Postgres tradicional assume há décadas. A Databricks detalhou como resolveu isso combinando um cache local autoscaling, shared buffers maiores em compute fixo e huge pages na stack inteira, com ganhos de até 5x em leitura de storage.","title":"Por que o cache padrão do Postgres não funciona dentro de um banco desagregado"},{"content":"Mostrar rota de entrega ou trajeto de veículo num dashboard sempre esbarrava na mesma limitação: mapa com ponto marcado não é a mesma coisa que mapa com o caminho percorrido desenhado.\nO Databricks MVP Geir E. Alstad notou a chegada do path map como um novo tipo de visualização nos dashboards AI/BI. Diferente dos tipos de mapa existentes, que plotam ponto (latitude e longitude isolados) ou área preenchida, o path map lê uma coluna de geometria do resultado da consulta e desenha linha conectando essa sequência de coordenadas direto sobre o mapa. Isso encaixa bem em qualquer caso onde o que importa é o caminho, não a posição num instante só.\nA lógica de uso é parecida com os outros tipos de gráfico dos dashboards AI/BI: a consulta SQL já precisa devolver a geometria pronta (uma linha, por exemplo, resultado de agregação de pontos GPS ao longo do tempo ou de uma junção com dado de roteamento), e o dashboard só cuida da parte de desenhar isso sobre o mapa base, com o mesmo motor de renderização que já atende os outros tipos de visualização geográfica da plataforma.\nPontos técnicos que valem atenção:\nNovo tipo de visualização dentro dos dashboards AI/BI, ao lado dos mapas de ponto e de área já existentes Consome coluna de geometria já calculada no resultado da consulta, não faz roteamento sozinho Útil pra caso de uso como rota de entrega, trajeto de veículo ou linha de transporte Integra com o resto da stack de dashboard AI/BI, incluindo filtro e drill-down já existentes Minhas considerações: é um tipo de visualização de nicho, a maioria dos dashboards de negócio nunca vai precisar de path map, mas pra quem trabalha com logística, transporte ou qualquer coisa que envolva movimento no espaço, é a diferença entre montar essa visualização com gambiarra de biblioteca externa ou ter isso nativo na plataforma.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/dashboards/manage/visualizations/types#path-map\n#Databricks #AIBIDashboards #DataVisualization\n","permalink":"https://wiliamrosa.github.io/posts/aibi-dashboards-path-map-visualizacao/","summary":"O Databricks MVP Geir E. Alstad destacou o path map, novo tipo de visualização nos dashboards AI/BI que desenha linha no mapa a partir de uma coluna de geometria no resultado da consulta, em vez de só marcar ponto isolado.","title":"Path map chega aos dashboards AI/BI pra desenhar trajeto, não só ponto no mapa"},{"content":"Agente de IA que faz uma chamada de API e devolve resposta é fácil de tornar resiliente, se falhar, tenta de novo. O problema aparece quando o agente executa um fluxo longo, várias etapas, chamada de ferramenta externa, espera por revisão humana no meio do caminho, e o worker que estava rodando aquilo cai na etapa 7 de 12. Reiniciar do zero pode duplicar efeito colateral já aplicado (mandar e-mail duas vezes, debitar duas vezes), e reiniciar do meio exige saber exatamente que estado já foi alcançado. A maioria dos frameworks de agente de mercado simplesmente não pensa nesse cenário, porque foi desenhada pra chamada curta, não pra workflow de negócio de verdade.\nUm projeto de referência publicado pela Databricks junto com a Temporal ataca esse problema combinando duas peças com papel bem definido: Temporal cuida da execução durável do workflow, Lakebase Postgres serve o estado operacional que o resto do sistema (dashboard, API, humano revisando) precisa consultar em tempo real. Nenhuma das duas peças sozinha resolve o problema completo.\nVale situar por que nenhuma das duas resolve sozinha. Usar só Temporal sem um banco operacional dedicado funciona bem pra orquestrar a execução, mas consultar \u0026ldquo;em que ponto está o caso 4821 agora\u0026rdquo; exige ler o Event History bruto do motor de workflow, que não foi desenhado pra ser consultado como se fosse uma tabela de aplicação. Usar só um banco relacional sem Temporal resolve a parte de estado consultável, mas devolve pro desenvolvedor a responsabilidade de reimplementar retry, controle de concorrência e espera durável por evento externo na mão, exatamente o tipo de código repetitivo e sujeito a bug que motor de orquestração existe pra eliminar.\nO mecanismo: execução determinística mais estado consultável A divisão de responsabilidade é clara:\nTemporal preserva o progresso do agente através de um Event History armazenado no Temporal Cloud. Se um worker cai, o trabalho já registrado é recuperado, operação que falhou é reexecutada automaticamente, e o workflow consegue esperar de forma durável por uma revisão humana no meio do processo, sem manter processo nenhum vivo enquanto espera. Lakebase serve o estado da aplicação em tempo real: evidência coletada, recomendação gerada, decisão de revisão e métrica operacional ficam consultáveis via SQL durante toda a execução, não só no fim. Política governada via Unity Catalog: o workflow lê política de underwriting (no exemplo usado, um caso de seguro) através de tabela sincronizada continuamente do Unity Catalog, e com Change Data Feed do Lakebase habilitado, publica mudança operacional de volta pra tabela Delta history, fechando o ciclo entre operação e governança. A arquitetura completa usa Temporal Cloud pra despachar tarefa e guardar histórico de evento, Lakebase Postgres com dois schemas (um pra estado operacional, outro pra política sincronizada), e uma camada de aplicação em React e FastAPI cuidando de HTTP e interface.\nMão na massa: idempotência é o detalhe que decide se isso funciona O ponto mais importante da arquitetura, e o que menos aparece em diagrama bonito, é que Activity do Temporal pode ser reexecutada, e cada uma precisa convergir pro mesmo estado final mesmo se rodar duas vezes. Isso exige identificador determinístico e SQL de update com guarda, não um simples insert:\nimport hashlib def gera_id_deterministico(caso_id: str, etapa: str) -\u0026gt; str: \u0026#34;\u0026#34;\u0026#34;ID estável: mesma Activity reexecutada gera o mesmo identificador.\u0026#34;\u0026#34;\u0026#34; base = f\u0026#34;{caso_id}:{etapa}\u0026#34; return hashlib.sha256(base.encode()).hexdigest()[:16] async def registra_evidencia_coletada(caso_id: str, evidencia: dict): registro_id = gera_id_deterministico(caso_id, \u0026#34;coleta_evidencia\u0026#34;) # UPSERT com guarda: reexecução não duplica, só confirma o mesmo estado await conexao.execute( \u0026#34;\u0026#34;\u0026#34; INSERT INTO agent_ops.evidencias (id, caso_id, payload, status) VALUES (%s, %s, %s, \u0026#39;coletada\u0026#39;) ON CONFLICT (id) DO UPDATE SET payload = EXCLUDED.payload WHERE agent_ops.evidencias.status != \u0026#39;coletada\u0026#39; \u0026#34;\u0026#34;\u0026#34;, (registro_id, caso_id, evidencia), ) Sem esse cuidado de ID determinístico e ON CONFLICT guardado, a promessa de durabilidade do Temporal vira uma faca de dois gumes, a Activity reexecuta com sucesso, só que duplica o efeito colateral que o Postgres registra.\nMinha leitura: o que mais me chama atenção nessa arquitetura é que ela admite, sem rodeio, que durabilidade de workflow (Temporal) e estado consultável em tempo real (Lakebase) são dois problemas diferentes que a maioria dos frameworks de agente tenta resolver com a mesma peça, geralmente um banco de checkpoint genérico que não é bom em nenhum dos dois papéis. Separar isso é mais trabalho de desenho inicial, mas evita o cenário comum de workflow \u0026ldquo;recuperado com sucesso\u0026rdquo; cujo estado intermediário ninguém consegue consultar sem abrir o Event History bruto do motor de orquestração.\nO papel do Change Data Feed fechando o ciclo com governança Um detalhe da arquitetura que merece mais atenção do que costuma receber é o uso do Change Data Feed do Lakebase pra publicar mudança operacional de volta pra tabela Delta history. Isso significa que toda decisão tomada durante a execução do agente, evidência coletada, recomendação gerada, aprovação registrada, não fica presa dentro do schema operacional do Postgres, ela flui de volta pro lakehouse em formato Delta, onde o resto da organização (auditoria, relatório de compliance, análise de tendência de decisão do agente ao longo do tempo) consegue consultar sem precisar acessar o banco operacional diretamente. Isso resolve um problema comum de arquitetura orientada a agente, que é o estado operacional ficar isolado num banco transacional que só o próprio sistema do agente enxerga, invisível pro resto da governança de dado da empresa.\nO que isso não resolve Antes de adotar esse padrão, vale considerar:\nIdempotência não vem de graça da plataforma, é responsabilidade de quem escreve cada Activity. O framework garante reexecução, não garante que sua lógica de negócio lida bem com reexecução, isso é código que você escreve e testa. Duas dependências externas novas (Temporal Cloud e Lakebase) somam superfície operacional, não é uma simplificação de stack, é uma troca deliberada de simplicidade por robustez, que só vale a pena se o workflow realmente precisar de execução de longa duração com espera humana no meio. O exemplo de referência é um caso de underwriting de seguro, com schema e política específicos daquele domínio. Adaptar pra outro domínio de negócio exige redesenhar schema operacional e regra de idempotência do zero, o código do repositório de referência é ponto de partida, não solução pronta. Fechamento Agente que realmente sobrevive à falha de infraestrutura, sem duplicar efeito colateral e sem perder rastro do que já foi feito, exige separar execução durável de estado operacional consultável, e tratar idempotência como parte do contrato de cada etapa, não como detalhe de implementação. É mais arquitetura do que a maioria dos protótipos de agente tem hoje, e é exatamente o tipo de rigor que separa demo de sistema que aguenta produção.\nReferências Post oficial: Build durable agents with Temporal and Lakebase Documentação oficial: Lakebase autoscaling Documentação oficial (Microsoft Learn): Autoscaling - Azure Databricks Documentação oficial: Temporal Workflows Repositório de referência: temporal-sa/temporal-lakebase-agent #Databricks #Lakebase #Temporal #AgentesDeIA\n","permalink":"https://wiliamrosa.github.io/articles/agentes-duraveis-temporal-lakebase-postgres/","summary":"Agente de IA de longa duração falha de um jeito diferente de API request-response: o processo pode cair no meio de uma etapa que já produziu efeito parcial. Um projeto de referência combina Temporal para reexecução determinística de workflow com Lakebase Postgres para estado operacional consultável, mas a idempotência de cada passo continua sendo responsabilidade de quem escreve o código do agente.","title":"Agente que sobrevive à queda de worker: durabilidade real combinando Temporal e Lakebase"},{"content":"📅 29 de setembro de 2026 · ⏰ 12h às 13h30 (BRT) · 💻 Evento online\nO Microsoft Reactor São Paulo promove uma sessão introdutória sobre o GitHub Copilot SDK, voltada a quem quer construir aplicações com agentes sem precisar implementar o loop do agente do zero.\nDiferente de chamar direto uma API de modelo, o SDK dá acesso programático ao runtime de agentes do Copilot: gerenciamento de conversas, planejamento, orquestração de ferramentas, eventos em streaming e estado de sessão. A sessão cobre clientes, sessões, prompts e o runtime de agentes na prática, incluindo como criar conversas com múltiplas interações, expor funções da aplicação como ferramentas, conectar recursos externos via servidores MCP e controlar o comportamento do agente com hooks e permission handlers. Também explica quando faz mais sentido usar o SDK em vez do Copilot CLI interativo. Não exige experiência prévia com o GitHub Copilot SDK.\nSobre o evento Promovido pelo Microsoft Reactor, hub de eventos gratuitos da Microsoft para a comunidade de desenvolvedores.\nInscreva-se 👉 Inscrição no evento\n#MicrosoftReactor #AgentesDeIA\n","permalink":"https://wiliamrosa.github.io/events/reactor-github-copilot-sdk-agentes/","summary":"Sessão introdutória gratuita do Microsoft Reactor São Paulo sobre o GitHub Copilot SDK, pra quem quer construir aplicações com agentes sem implementar o loop do agente do zero.","title":"💻 Let's Learn GitHub Copilot SDK"},{"content":"Kernel de GPU genérico serve qualquer modelo, mas não é ótimo pra nenhum, e a Databricks resolveu isso deixando um agente escrever o kernel especializado sozinho.\nA Databricks detalhou o Proteus, um sistema que propõe kernel de GPU candidato, valida contra uma implementação de referência controlada, faz benchmark e itera até chegar numa versão especializada pro formato exato de operação em jogo. A motivação é que o formato de uma operação varia tanto pelo tamanho do modelo quanto por fator dinâmico do pedido em produção, e servir tudo isso com um kernel genérico deixa desempenho na mesa.\nO ponto que a equipe mais destacou não foi a velocidade de busca por kernels novos, foi a robustez do validador. Pra evitar que o próprio sistema aprenda a otimizar o benchmark em vez do desempenho real, o checador usa múltiplos métodos de cronometragem, limpa estado compilado residual entre execuções, roda contra conjunto de teste nunca visto e sinaliza automaticamente qualquer speedup fisicamente impossível. Do lado do prompt, uma camada de conhecimento guarda só contexto de alta confiança, do tipo situação específica pareada com ação, recuperado por filtragem hierárquica, pra não gastar token com informação genérica ou desatualizada.\nPontos técnicos que valem atenção:\nO sistema propõe kernel candidato, valida contra referência controlada, faz benchmark e itera Validador rigoroso evita otimizar o benchmark em vez do desempenho real, com timing múltiplo, limpeza de estado compilado e teste em dado nunca visto Camada de conhecimento retém só contexto de alta confiança, evitando prompt inchado com informação genérica Estudo de caso: kernel de packed decode do Gated DeltaNet no Qwen 3.5 122B (NVIDIA B200) saiu de baseline de 0,025ms pra versões específicas por formato, com ganho de 1,5x a 1,6x por formato individual Resultado agregado: speedup de 1,8x a 5,2x sobre a melhor implementação equivalente do vLLM Minha ressalva: o próprio material reconhece que o maior risco desse tipo de sistema é o gerador de kernel aprender a passar no benchmark em vez de entregar ganho real, e é por isso que boa parte do esforço foi construir o verificador, não o gerador. Vale lembrar também que o speedup de 1,8x a 5,2x foi medido num par específico, modelo Qwen 3.5 122B rodando em B200, o número não necessariamente se repete pra outra combinação de modelo e hardware.\nFonte: https://www.databricks.com/blog/achieving-extreme-efficiency-through-specialized-gpu-kernel-generation\n#Databricks #GPU #InferenciaIA\n","permalink":"https://wiliamrosa.github.io/posts/proteus-geracao-kernel-gpu-especializado/","summary":"O Proteus propõe, valida e faz benchmark de kernel de GPU especializado por formato de operação, com um estudo de caso no Gated DeltaNet do Qwen 3.5 122B atingindo de 1,8x a 5,2x de speedup sobre a melhor implementação do vLLM.","title":"A Databricks construiu um agente que escreve e valida kernel de GPU sozinho"},{"content":"Nem todo relatório precisa virar um app, mas trocar esse momento de decisão dá pra errar caro dos dois lados.\nO Databricks MVP Domonkos Pal publicou um comparativo prático entre usar uma skill de agente ou construir um Databricks App quando o objetivo é gerar relatório, e o ponto central dele não é qual tecnologia é melhor, é em que momento faz sentido migrar de uma pra outra.\nA régua que ele propõe é direta: uma skill resolve bem experimento rápido, com poucos usuários e revisão humana obrigatória a cada rodada. Já o app entra em cena quando o número de usuários cresce, o relatório passa a ser recorrente e o resultado começa a influenciar decisão crítica que exige aprovação formal antes de valer. O detalhe que sustenta essa migração sem dor é que skill e app não vivem em mundos separados, os dois herdam a mesma camada de governança do Databricks, então trocar de um pro outro é graduar dentro da mesma camada semântica versionada, não reconstruir do zero.\nPontos técnicos que valem atenção:\nSkill: setup rápido, poucos usuários, revisão humana obrigatória em cada execução App: usuários em crescimento, relatório recorrente, saída que impacta decisão crítica e precisa de sign-off Skill e app compartilham a mesma governança no Databricks: Unity Catalog, Unity AI Gateway e Omnigent Ele publicou um repositório de skill builder que deixa criar uma skill de relatório simples e depois graduar ela pra app sem reescrever a camada semântica Minhas considerações: o critério que mais me chamou atenção não foi usuário nem recorrência, foi o \u0026ldquo;sign-off formal\u0026rdquo;. No fim das contas, o que decide entre skill e app é quem assume a responsabilidade pelo resultado, não a tecnologia usada pra gerar ele. É uma régua que serve pra qualquer decisão de arquitetura de agente, não só relatório.\nFonte: https://medium.com/databrickscommunity/skills-for-speed-and-learning-apps-for-trust-and-scale-924de1ee24db\n#Databricks #DatabricksApps #Omnigent\n","permalink":"https://wiliamrosa.github.io/posts/skill-ou-app-databricks-reporting/","summary":"O Databricks MVP Domonkos Pal publicou um guia prático sobre quando um skill de agente basta pra gerar relatório e quando vale migrar pra um Databricks App, com skill e app compartilhando a mesma camada de governança.","title":"Skill ou app no Databricks: quando cada um vale a pena pra relatório"},{"content":"Tratar governança só como controle de acesso deixa a IA mais cara, porque falta significado nos dados pra qualquer modelo mais barato entender sozinho.\nA Databricks publicou um argumento de que governança de dado, quando tratada só como controle de acesso e compliance, ignora a parte que mais custa caro pra IA: dar significado, contexto e confiança aos dados que o agente vai consumir. Sem isso, a organização acaba compensando a falta de clareza semântica pagando por modelo de fronteira mais caro, em vez de resolver o problema na origem.\nA proposta une cinco pilares, governança de dado, governança de conhecimento e ML, letramento de dado, gestão de dado e ontologia, sob uma única lente no Unity Catalog. A partir daí entram os chamados build agents: agentes automatizados que leem instrução direto do metadado curado no catálogo e escrevem resultado de volta, cobrindo geração de ETL, teste, anonimização e deploy num loop contínuo. Dado ou agente sem descrição explícita no catálogo é bloqueado por padrão, não é uma exceção tratada depois. Do outro lado, dado e agente de IA passam pelos mesmos portões de ciclo de vida, medidos por um scorecard único de certificação que avalia governança, qualidade, semântica e propriedade.\nPontos técnicos que valem atenção:\nCinco pilares de governança, dado, conhecimento/ML, letramento, gestão e ontologia, unificados numa lente só via Unity Catalog Build agents leem instrução do metadado curado no catálogo e escrevem resultado de volta: ETL, teste, anonimização e deploy viram um loop contínuo Enforcement fail-closed: dado ou agente sem descrição explícita no catálogo é bloqueado por padrão Scorecard único de certificação de IA mede governança, qualidade, semântica e propriedade pros dois lados, dado e agente Cada agente tem um Data Product Owner nomeado, e definição de métrica compartilhada é aplicada em tempo de execução pelo catálogo, não só documentada Minha ressalva: a promessa de usar modelo mais barato porque o significado já mora no metadado é sedutora, mas depende de alguém manter esse metadado curado e atualizado de verdade, o que é trabalho manual constante. Sem isso, o enforcement fail-closed vira só mais atrito, e o time acaba preenchendo descrição de catálogo às pressas só pra destravar o agente, o oposto de dado com significado real.\nFonte: https://www.databricks.com/blog/governance-beyond-security-knowledge-context-ontology-lakehouse\n#Databricks #UnityCatalog #Governança\n","permalink":"https://wiliamrosa.github.io/posts/governanca-alem-seguranca-lakehouse/","summary":"A Databricks defende que tratar governança só como segurança deixa passar a parte que mais encarece IA: dar significado e contexto ao dado, unindo cinco pilares de governança numa lente só via Unity Catalog.","title":"Governança no Databricks deixou de ser só controle de acesso, virou também gerar significado"},{"content":"A métrica de negócio definida numa metric view do Unity Catalog agora pode ser compartilhada com outro metastore ou outra conta, não só consumida dentro de casa.\nO Azure Databricks liberou em beta o compartilhamento de metric views via OpenSharing, o protocolo aberto que sucedeu o Delta Sharing. Antes, metric view era um recurso preso ao Unity Catalog de quem criou ela; agora dá pra empacotar essa definição de métrica dentro de um share e distribuir pra usuário de outro metastore ou de outra conta do Azure Databricks.\nO ponto central é que o que atravessa a fronteira não é só o dado agregado, é a própria definição semântica: dimensão, medida e a lógica de cálculo por trás da métrica. Quem recebe o share lê a metric view compartilhada e consulta ela com a função MEASURE(), do mesmo jeito que consultaria uma metric view local, sem reimplementar a lógica de negócio na outra ponta.\nPontos técnicos que valem registrar:\nBeta no Azure Databricks a partir de 3 de setembro de 2026 Compartilha a definição da metric view, não só um snapshot do dado agregado Quem recebe consulta a métrica compartilhada com a mesma função MEASURE() usada em metric view local Complementa o rebranding recente do Delta Sharing para OpenSharing como protocolo de distribuição de dado entre metastores e contas Minha ressalva: compartilhar a definição de uma métrica de negócio entre organizações diferentes é mais delicado do que compartilhar uma tabela. Duas empresas raramente concordam sobre o que significa \u0026ldquo;receita líquida\u0026rdquo; ou \u0026ldquo;usuário ativo\u0026rdquo; da mesma forma, então receber a metric view de outra conta não garante que a métrica calculada vá bater com a definição interna de quem recebe. Vale tratar a metric view recebida via OpenSharing como ponto de partida pra alinhamento, não como fonte de verdade automática.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/release-notes/product/2026/september#share-metric-views-with-opensharing-beta\n#Databricks #MetricViews #OpenSharing\n","permalink":"https://wiliamrosa.github.io/posts/metric-views-opensharing-beta/","summary":"O Azure Databricks liberou em beta o compartilhamento de metric views via OpenSharing: quem recebe o share consulta a definição de métrica compartilhada com a função MEASURE(), sem reimplementar a lógica de negócio.","title":"Metric Views agora atravessam metastore diferente via OpenSharing"},{"content":"Rodar um coding agent inteiro sem gastar um único token de API soa bem no papel, mas a pergunta de sempre é quanto trabalho de configuração isso realmente exige.\nA Databricks MVP Zoë Van Noppen testou na prática configurar o Omnigent, o meta-harness open-source da Databricks para orquestrar agentes de código, com um modelo de linguagem local rodando no próprio Mac, em vez de depender de API paga. O objetivo dela não era substituir modelo via API no dia a dia, mas entender se um modelo pequeno e quantizado rodando localmente consegue assumir tarefas simples que hoje são roteadas para modelo pago sem necessidade.\nA configuração passa por instalar o llama.cpp via Homebrew e subir um servidor local com um modelo Gemma quantizado baixado direto do Hugging Face, depois instalar o harness Pi via npm junto com o plugin que conecta Pi ao llama.cpp. A parte final acontece dentro do próprio Omnigent, pelo comando Omni setup: escolher Pi como harness, configurar um gateway do tipo \u0026ldquo;URL base customizada + chave\u0026rdquo;, apontar a URL base para o servidor local do llama.cpp, preencher uma chave de API qualquer (o campo exige algo, mas não valida nada localmente) e informar o nome do modelo local ao configurar o harness Claude via Responses API. Ela também tentou o mesmo processo com Ollama em vez de llama.cpp e achou mais trabalhoso: precisou depurar configuração de janela de contexto e URL base, e o mesmo modelo rodou mais devagar no Ollama do que no llama.cpp, algo que segundo ela é um problema já conhecido da comunidade.\nPontos técnicos que valem registrar:\nInstalação via brew install llama.cpp, subindo o servidor com llama-server -hf \u0026lt;modelo-quantizado-no-Hugging-Face\u0026gt; Harness Pi instalado via npm install -g mais o plugin pi-llama-cpp No Omni setup, o gateway customizado usa a URL do servidor llama-server local, uma chave de API qualquer (não validada) e o harness Claude via Responses API apontando pro nome do modelo local Ollama exigiu depuração extra de contexto e URL base, e rodou o mesmo modelo mais devagar que o llama.cpp Minhas considerações: esse tipo de post prático, com comando exato e passo a passo real, vale mais do que dez posts de opinião sobre modelo local, porque tira a dúvida de \u0026ldquo;dá pra fazer isso hoje\u0026rdquo; da teoria. A ideia de rotear tarefa simples para modelo local e reservar o modelo pago só pro que exige mais raciocínio é um padrão de economia que ainda vejo pouco discutido no ecossistema Databricks, e acho que vamos ver mais gente adotando isso à medida que modelo quantizado pequeno continuar melhorando.\nFonte: https://www.linkedin.com/in/zo%C3%AB-van-noppen-7378b6139/#omnigent-llm-local-llama-cpp\n#Databricks #Omnigent #AgentesIA\n","permalink":"https://wiliamrosa.github.io/posts/omnigent-llm-local-llama-cpp/","summary":"Configurar o Omnigent para rodar com um modelo quantizado local via llama.cpp é mais simples do que parece, e ainda revela que o Ollama, apesar de mais popular, é mais lento e mais trabalhoso de configurar pro mesmo modelo.","title":"Rodei o Omnigent com um LLM local no Mac, e a configuração levou menos de 30 minutos"},{"content":"Todo mundo que já tentou colocar um agente de IA em produção sabe que o trabalho difícil começa depois do demo funcionar.\nA Databricks lançou o Big Book of AgentOps, um material que tenta dar estrutura a algo que este blog já cobriu em pedaços separados: rastreamento automático de chamada de ferramenta, orçamento de gasto com IA, governança de acesso a modelo externo. O ebook organiza isso em seis capítulos, cobrindo desde arquitetura de agente até padrão de implantação que vai de workspace único até topologia multi-conta pra empresa grande, passando por um ciclo de vida de projeto em sete fases.\nA base técnica não é novidade isolada, é a mesma peça que já apareceu aqui antes em contexto pontual: MLflow pra avaliação e rastreamento de execução, Unity Gateway administrando tráfego de modelo e ferramenta, Unity Catalog controlando acesso com privilégio mínimo. O que muda é a tentativa de amarrar essas peças num ciclo operacional parecido com DevOps, só que pensado pra sistema que decide sozinho, não só executa código determinístico.\nPontos técnicos que valem atenção:\nSeis capítulos cobrindo arquitetura de agente, padrão de implantação e ciclo de vida de projeto em sete fases Recomenda construir dataset de avaliação a partir de rastro real de produção, não só caso sintético de teste Reforça controle de acesso de privilégio mínimo via Unity Catalog como parte do ciclo operacional, não como item avulso de segurança Cita resultado de cliente: FactSet reportou 44% de melhora de acurácia, DXC Technology cortou 30% de custo de plataforma Trata validação de chamada de ferramenta, atribuição de custo e rastreamento de execução multi-etapa como prática operacional recorrente, não exceção Minha ressalva: material assim tende a soar mais consolidado do que a realidade de quem está no dia a dia, a maioria das empresas ainda nem tem rastreamento básico de chamada de ferramenta funcionando, quanto mais um ciclo de sete fases rodando redondo. Serve mais como mapa de onde chegar do que como retrato do que já é padrão hoje.\nFonte: https://www.databricks.com/blog/announcing-databricks-big-book-agentops\n#Databricks #AgentOps #MLflow\n","permalink":"https://wiliamrosa.github.io/posts/big-book-agentops-databricks/","summary":"O Big Book of AgentOps organiza em seis capítulos e sete fases de projeto o que já vínhamos vendo em pedaços soltos por aqui: MLflow pra avaliação e rastreamento, Unity Gateway pro tráfego de modelo e ferramenta, Unity Catalog pro controle de acesso, com resultado de cliente como FactSet e DXC Technology.","title":"AgentOps ganha um manual: a Databricks tenta dar nome à disciplina de operar agente em produção"},{"content":"Uma concessionária de energia levou anos pra parar de operar tempestade com três sistemas que não se falavam entre si.\nA Databricks publicou o terceiro capítulo de uma série sobre como a Southern Company reconstruiu sua operação de resposta a tempestade em cima do lakehouse. Depois do SPEAR, pra previsão antes do evento, e do RAMP, pra análise depois que a poeira baixa, chega o SCOUT, o aplicativo que cobre o intervalo mais crítico: enquanto a tempestade está acontecendo e a equipe de campo precisa decidir onde mandar gente agora.\nO que sustenta isso por baixo não é só um dashboard bonito. Delta Lake guarda o dado de forma resiliente, warehouses serverless do lakehouse atualizam a consulta em produção a cada minuto, e o Unity Catalog controla quem acessa o quê via service principal, sem depender de cópia solta de planilha circulando entre equipes durante o incidente.\nPontos técnicos que valem atenção:\nIngestão unificada de outage, base de cliente, GIS, clima, terreno e dado operacional numa única camada, em vez de cada sistema isolado Atualização de consulta a cada minuto durante o evento, via warehouse serverless do lakehouse Diferencial de terreno: o sistema distingue local que exige equipe de escalada (área residencial densa) de área montanhosa que limita acesso de veículo, pra otimizar despacho de equipe Genie Code e notebook colaborativo usados no desenvolvimento das pipelines de analytics 1.139 funcionários usando a ferramenta entre as unidades da Southern Company, com pico de mais de 250 usuários simultâneos numa tempestade real em junho Minhas considerações: o que chama atenção aqui não é a tecnologia em si, Delta Lake e Unity Catalog já são conhecidos, é o desenho de três aplicativos separados cobrindo três momentos do mesmo ciclo de vida do incidente, em vez de tentar forçar um sistema genérico a fazer tudo. Isso é um argumento prático a favor de modelar pipeline de dado em torno do momento de decisão do usuário final, não em torno da conveniência de manter uma arquitetura só.\nFonte: https://www.databricks.com/blog/southern-companys-scout-completing-storm-intelligence-story\n#Databricks #DeltaLake #CasoDeUso\n","permalink":"https://wiliamrosa.github.io/posts/southern-company-scout-storm-intelligence/","summary":"SCOUT é o terceiro aplicativo da Southern Company sobre Databricks pra operação de tempestade, cobrindo o momento em tempo real entre a previsão (SPEAR) e a análise pós-evento (RAMP), com dado de outage, clima, terreno e equipe numa única camada.","title":"SCOUT: como a Southern Company junta previsão, resposta e pós-tempestade num único lakehouse"},{"content":"Recebi o Matheus Domingos, Solutions Architect na Databricks (Holanda) e um dos líderes do Eindhoven Databricks User Group, pra um encontro com a comunidade do São Paulo Databricks User Group.\nO Matheus passou pelos diferentes sabores do Databricks Genie, Genie Code, Genie One, Genie Agents e Genie ZeroOps, como cada um resolve um problema diferente dentro da plataforma, e depois entramos no tema de carreira internacional em dados: a jornada dele, os desafios de construir uma trajetória fora do Brasil e o que costuma pesar nessa decisão.\nMais detalhes sobre esse encontro estão no post do evento.\nAssista 👉 Assistir no YouTube\n","permalink":"https://wiliamrosa.github.io/videos/sabores-databricks-genie-carreira-internacional/","summary":"Gravação do encontro com Matheus Domingos, Solutions Architect na Databricks (Holanda), sobre os diferentes sabores do Databricks Genie e carreira internacional em dados, feito para a comunidade São Paulo Databricks User Group.","title":"🎥 Os Sabores do Databricks Genie + Carreira Internacional"},{"content":"O Databricks MVP Juan Diaz apontou uma mudança pequena de configuração com efeito grande em quem já tem alerta demais que ninguém trata: o alerta SQL virou um tipo de tarefa dentro do Lakeflow Jobs.\nAté então, alerta SQL vivia isolado, rodava sua consulta, checava a condição e mandava notificação, sem se conectar ao resto de um pipeline. Agora ele pode entrar como uma tarefa dentro do Job: a consulta roda no SQL warehouse configurado, a condição é avaliada, e o estado da avaliação, OK, TRIGGERED ou ERROR, fica disponível como valor de saída pra tarefa seguinte referenciar. Na prática isso abre espaço pra construir uma tarefa If/Else logo depois do alerta, com condição do tipo {{tasks.Alert-FraudRateCheck.output.alert_state}} == \u0026quot;TRIGGERED\u0026quot;, decidindo automaticamente se o fluxo segue direto, dispara uma tarefa de correção ou interrompe outra etapa.\nUm detalhe importa pra quem for configurar isso: a tarefa de alerta reporta status \u0026ldquo;Succeeded\u0026rdquo; sempre que consegue avaliar a condição, independente do alerta ter disparado ou não. Quem quer reagir ao disparo precisa ler o valor de saída explicitamente, não dá pra confiar só no status da tarefa pra saber se algo deu errado.\nPontos técnicos que valem atenção:\nEstado da avaliação sai como OK, TRIGGERED ou ERROR, acessível como saída da tarefa Tarefa If/Else consegue ramificar com base nesse valor, por exemplo {{tasks.\u0026lt;nome\u0026gt;.output.alert_state}} == \u0026quot;TRIGGERED\u0026quot; Tarefa de alerta reporta \u0026ldquo;Succeeded\u0026rdquo; mesmo quando o alerta dispara, o status por si só não indica problema Tarefa de alerta SQL não aceita parâmetro, uma limitação a considerar no desenho do Job Minha ressalva: o ponto que mais merece atenção é justamente o status \u0026ldquo;Succeeded\u0026rdquo; mascarando um alerta disparado. Sem montar explicitamente a ramificação com base no valor de saída, um Job inteiro pode terminar \u0026ldquo;verde\u0026rdquo; no monitoramento mesmo com uma condição crítica acionada lá dentro, o que é o oposto do que se espera de um alerta.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/jobs/tasks/alert\n#Databricks #LakeflowJobs #Automação\n","permalink":"https://wiliamrosa.github.io/posts/lakeflow-jobs-sql-alert-task-branching/","summary":"O Databricks MVP Juan Diaz notou que o Lakeflow Jobs agora aceita alerta SQL como tipo de tarefa, expondo o estado da avaliação como saída pra tarefa seguinte decidir o próximo passo com um If/Else.","title":"Alerta SQL virou tarefa dentro do Job, e agora dá pra ramificar o fluxo a partir do resultado dele"},{"content":"O Databricks MVP Derar Alhussein chamou atenção pra um recurso que resolve um problema chato e recorrente: começar a modelar dado de um domínio de negócio do zero, sem nenhuma referência.\nOs Industry Data Models são uma biblioteca de modelo de dado pronto pra mais de 40 indústrias, publicada num repositório de referência da Databricks. Cada indústria sai em duas versões, um modelo conceitual mais enxuto (MVM) e um modelo corporativo mais completo (ECM), cobrindo entidade central, relacionamento, convenção de nome e padrão específico do domínio. A escala chama atenção: ao todo são 80 modelos somando as duas versões, mais de 23 mil tabelas, quase 900 mil atributos, mais de 150 mil chave estrangeira e mais de 11 mil metric view já definida. Cada modelo segue um conjunto de mais de 200 regras estruturais distribuídas em 14 domínio de modelagem diferente, o que dá uma base consistente entre indústrias, e foi gerado pelo agente Vibe Data Modeling em vez de desenhado manualmente indústria por indústria.\nA proposta não é usar isso engessado. A Databricks recomenda tratar como camada Silver inicial, adaptável ao vocabulário e à regra específica de cada organização, com repositório incluindo notebook, orquestrador, harness de teste e guia de integração e qualidade.\nPontos técnicos que valem atenção:\nMais de 40 indústrias, cada uma em duas versões, MVM (mais simples) e ECM (mais completo) 80 modelos ao todo, mais de 23 mil tabelas e mais de 11 mil metric view já mapeada Ruleset de mais de 200 regras em 14 domínio de modelagem garante consistência estrutural entre indústrias Gerado pelo agente Vibe Data Modeling, não desenhado manualmente modelo por modelo Pensado como ponto de partida pra camada Silver, customizável, não como modelo final fixo Minha ressalva: modelo gerado por agente em escala de 80 modelos e quase 900 mil atributos é difícil de auditar um por um antes de adotar. \u0026ldquo;Produção-grade desde o dia zero\u0026rdquo; é a promessa, mas a responsabilidade de validar se a regra de 14 domínios realmente reflete a realidade regulatória e de negócio da sua indústria específica continua sendo sua, não do agente que gerou o modelo. Vale tratar como acelerador de rascunho, não como modelo pronto pra rodar sem revisão de arquiteto de dado humano.\nFonte: https://www.databricks.com/blog/jumpstart-your-data-modeling-databricks-industry-data-models\n#Databricks #ModelagemDeDados #UnityCatalog\n","permalink":"https://wiliamrosa.github.io/posts/databricks-industry-data-models-40-industrias/","summary":"O Databricks MVP Derar Alhussein resgatou os Industry Data Models, biblioteca com modelo de dado de referência pra mais de 40 indústrias, gerada por um agente de modelagem e pensada pra virar a camada Silver do seu Lakehouse.","title":"40 indústrias, 80 modelos de dado prontos: a Databricks publicou um ponto de partida pra quem não quer desenhar schema do zero"},{"content":"Buscar por similaridade sempre foi o motivo de existir do AI Search, mas nem toda consulta contra um índice é sobre similaridade.\nO Azure Databricks ampliou o filtro do AI Search (o antigo Vector Search) pra alcançar campo aninhado dentro de coluna do tipo struct e chave dentro de coluna do tipo map, usando notação de ponto pra struct, profile.age, e notação de colchete pra map, attrs['voltage']. Ao lado disso chegou a consulta só de filtro: basta omitir query_text, query_vector e query_type e informar apenas o filtro, e o índice devolve toda linha que bate com a condição sem rodar busca vetorial nem full-text por trás. Isso vale tanto pra endpoint padrão quanto pro endpoint storage-optimized, cada um com sua própria sintaxe de filtro, dicionário de chave e valor no padrão e string estilo cláusula WHERE no storage-optimized.\nNa prática isso empurra o AI Search pra um território que antes pedia uma consulta SQL direto na tabela: filtrar por chave primária pra fazer um lookup pontual, sem gastar ciclo com embedding nem ranking, agora é um caso suportado dentro do próprio índice.\nPontos técnicos que valem atenção:\nStruct aninhado é filtrado com notação de ponto, profile.age, map com notação de colchete, attrs['voltage'] Consulta só de filtro dispensa query_text, query_vector e query_type, mantém apenas filters Os mesmos limites de num_results e paginação da busca normal valem pra consulta só de filtro Lookup por ponto (point lookup) é o caso de uso indicado quando o filtro é sobre a coluna de chave primária Endpoint padrão e storage-optimized usam sintaxe de filtro diferente entre si, dicionário versus string tipo SQL Minhas considerações: faz sentido técnico, já que o índice já guarda a coluna e o filtro, mas isso também confunde a fronteira entre \u0026ldquo;índice de busca\u0026rdquo; e \u0026ldquo;tabela consultável\u0026rdquo;, o que provavelmente é a intenção. A pergunta prática é de custo: consulta só de filtro contra um índice de AI Search compensa mesmo, ou uma consulta direto na tabela Delta que já origina o índice resolve mais barato o mesmo lookup pontual. Vale medir antes de trocar um pelo outro por conveniência de API única.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/ai-search/query-ai-search\n#Databricks #AISearch #AzureDatabricks\n","permalink":"https://wiliamrosa.github.io/posts/ai-search-structs-maps-filter-only-queries/","summary":"AI Search passou a aceitar filtro em campo de struct aninhado e chave de map, e ganhou a opção de consulta só de filtro, sem busca vetorial nem por palavra-chave, útil pra lookup direto por chave.","title":"AI Search agora filtra dentro de struct e map, e dá pra consultar sem buscar nada"},{"content":"Agendar o Genie Code pra rodar todo dia de madrugada e te entregar um relatório pronto quando você chega no trabalho já é possível.\nA Databricks tornou geralmente disponível o agendamento de tarefas do Genie Code no Azure Databricks. Antes, cada sessão do Genie Code dependia de alguém abrir o chat e digitar o prompt; agora dá pra configurar um prompt fixo pra rodar numa recorrência definida, sem intervenção manual.\nCada execução agendada dispara uma sessão completa do Genie Code, com o mesmo prompt de sempre, e produz um chat continuável com o resultado, então quem chega depois pode abrir aquela conversa e seguir interagindo com o agente a partir de onde ele parou, em vez de só ler um log estático. A configuração acontece direto no chat do Genie Code ou no menu de Schedules, sem precisar orquestrar isso via job externo.\nPontos técnicos que valem registrar:\nDisponibilidade geral a partir de 1 de setembro de 2026 Cada execução cria uma sessão completa de Genie Code, com histórico continuável, não só um log de texto Configuração pelo próprio chat do Genie Code ou pelo menu de Schedules Casos de uso descritos: resumir resultado de job noturno, investigar ticket, gerar auditoria de conformidade recorrente Minhas considerações: transformar prompt em tarefa agendada é o tipo de feature pequena que muda o hábito de uso. A diferença entre \u0026ldquo;pergunto quando lembro\u0026rdquo; e \u0026ldquo;isso roda sozinho toda noite\u0026rdquo; é grande, mas também levanta a pergunta de quem revisa o resultado quando ninguém pediu a execução daquela vez. Vale pensar no agendamento de Genie Code como mais um job de produção que precisa de dono e de alerta de falha, não como um chat que só acontece de forma automática.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/release-notes/product/2026/september#genie-code-scheduled-tasks-are-now-generally-available\n#Databricks #GenieCode #AzureDatabricks\n","permalink":"https://wiliamrosa.github.io/posts/genie-code-scheduled-tasks-ga/","summary":"O agendamento de tarefas do Genie Code chegou à disponibilidade geral no Azure Databricks: dá pra configurar um prompt fixo pra rodar numa recorrência, gerando um chat continuável a cada execução.","title":"Genie Code agora roda sozinho num horário fixo, sem ninguém abrir o chat"},{"content":"Ingestão de alta taxa de evento ganhou um formato binário colunar nativo em vez de depender só de serialização linha a linha.\nO Azure Databricks confirmou disponibilidade geral do suporte a Apache Arrow Flight dentro do Zerobus Ingest, o caminho de ingestão de baixa latência do Lakeflow Connect que já grava direto em tabela Delta sem passar por Kafka nem cluster Spark. Arrow Flight entra como um terceiro formato de envio, ao lado de JSON e protobuf, rodando na mesma conexão gRPC, mesmo endpoint e mesmo fluxo de autenticação já usados pelos outros formatos.\nA diferença prática é o formato de dado que trafega. Em vez de converter cada linha em JSON ou protobuf antes de enviar, a aplicação manda lote de dado já colunar, RecordBatch do Arrow, e o protocolo Arrow Flight DoPut carrega esse lote como mensagem IPC pela mesma conexão. Isso favorece principalmente aplicação que já trabalha nativamente com Arrow, como pipeline construído sobre Polars ou DataFusion, ou coletor que agrega dado por um intervalo curto antes de mandar em lote.\nPontos técnicos que valem atenção:\nSDK disponível em Python (pacote databricks-zerobus-ingest-sdk com extra [arrow]) e Rust (feature arrow-flight do crate) Compressão opcional na mensagem IPC, com LZ4_FRAME pra baixo custo de CPU ou ZSTD pra taxa de compressão maior Lote Arrow não está sujeito ao limite de 10 MB por mensagem gRPC que vale pra linha individual, o SDK quebra lote grande em mensagens menores automaticamente Recomendação oficial é reaproveitar o mesmo stream pra muitos lotes, já que abrir stream novo tem custo fixo relevante Não é indicado pra tráfego esparso, linha a linha, onde JSON ou protobuf continuam mais simples Minhas considerações: esse suporte fecha uma lacuna que fazia sentido existir desde o lançamento do Zerobus, quem já processa dado colunar na aplicação não deveria pagar o custo de converter tudo pra JSON só pra depois a Databricks reconverter pra Delta do outro lado. Vale considerar principalmente pra pipeline de streaming que já nasce em Arrow, o ganho em aplicação pequena e esparsa provavelmente não compensa a complexidade extra.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/ingestion/zerobus-arrow-flight\n#Databricks #LakeflowConnect #Streaming\n","permalink":"https://wiliamrosa.github.io/posts/zerobus-ingest-arrow-flight-ga/","summary":"Apache Arrow Flight chegou como formato de envio pro Zerobus Ingest do Lakeflow Connect, ao lado de JSON e protobuf, carregando RecordBatch colunar direto pela mesma conexão gRPC, com SDK em Python e Rust e opção de compressão ZSTD ou LZ4.","title":"Zerobus Ingest ganhou protocolo binário Arrow Flight como terceiro formato de envio"},{"content":"Abrir cinco notebooks do mesmo projeto e esperar cinco ambientes serverless subirem, cada um com sua própria lista de dependência, nunca fez muito sentido pra quem trabalha em múltiplos arquivos do mesmo repositório.\nO Azure Databricks lançou em Beta o Git Folder Serverless: notebook e arquivo dentro do mesmo Git folder agora podem se conectar a um único recurso de compute serverless, com o ambiente Python gerenciado por um pyproject.toml na raiz da pasta em vez da configuração por notebook do serverless padrão. Só é possível usar essa opção dentro do editor de Git folder, e o requisito é ter environment_version 5 ou superior se já existir um pyproject.toml. Dependência nova entra de duas formas: rodando %uv add \u0026lt;pacote\u0026gt; seguido de %uv sync direto na célula, ou editando o pyproject.toml manualmente e clicando em Aplicar no editor. Um detalhe que separa isso de simplesmente \u0026ldquo;um cluster só pro projeto inteiro\u0026rdquo;: variável Python de um notebook não fica visível em outro, cada arquivo ainda roda seu próprio estado, só o ambiente e o compute são compartilhados.\nPontos técnicos que valem atenção:\nApenas assets dentro do mesmo Git folder conseguem anexar ao recurso de compute compartilhado Terminal web aberto a partir de qualquer notebook ou arquivo do folder roda no mesmo compute Só quem iniciou o compute consegue rodar workload nele, outro usuário que abrir o mesmo Git folder fica bloqueado Recomendação da Databricks pra colaboração é cada pessoa clonar o repositório na própria pasta pessoal, cada clone gera compute e ambiente próprios, a troca acontece via branch, commit e push Compartilhamento de compute fica restrito a uma mesma usage policy serverless, Git folder com política diferente ganha compute separado Minha ressalva: a trava de um único usuário ativo por compute é a parte que mais chama atenção. Resolve o desperdício de subir ambiente repetido pro mesmo projeto, mas não resolve pair programming nem revisão em tempo real dentro do mesmo Git folder, que continua exigindo clone separado. Ainda em Beta, vale testar em projeto individual multi-arquivo antes de esperar isso resolver colaboração em equipe.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/compute/serverless/notebooks/git-folder-serverless\n#Databricks #AzureDatabricks #Serverless\n","permalink":"https://wiliamrosa.github.io/posts/git-folder-serverless-beta-azure-databricks/","summary":"Git Folder Serverless (Beta) deixa notebook e arquivo do mesmo Git folder compartilharem um único compute serverless e um ambiente gerenciado por pyproject.toml, em vez de cada notebook subir seu próprio ambiente.","title":"Um Git folder inteiro passou a compartilhar um único ambiente serverless"},{"content":"Mostro na prática como automatizar o deploy de jobs, pipelines e outros recursos do Databricks usando Declarative Automation Bundles (DABs), ex-Databricks Asset Bundles, direto por linha de comando.\nSe você quer entender também as mudanças recentes de engine desses bundles (o novo modo direct virando padrão no lugar do Terraform), já escrevi sobre isso neste post.\nAssista 👉 Assistir no YouTube\n","permalink":"https://wiliamrosa.github.io/videos/automacao-declarative-automation-bundles-dabs/","summary":"Demonstração prática de automação de deploy no Databricks usando Declarative Automation Bundles (DABs), da definição do bundle ao deploy de ponta a ponta.","title":"🎥 Automação com Declarative Automation Bundles (DABs)"},{"content":"Apresento o Governance RiskOps Agent, um agente construído sobre o Databricks Free Edition pra detectar riscos de governança no Unity Catalog automaticamente, em vez de depender de auditoria manual.\nEsse é o mesmo projeto que ficou entre os Top 5 Global no DAIS 2026 Community Virtual Contest, evento oficial da Databricks em San Francisco (contei mais sobre isso neste post). Aqui no vídeo mostro a solução funcionando na prática.\nAssista 👉 Assistir no YouTube\n","permalink":"https://wiliamrosa.github.io/videos/governance-riskops-agent-unity-catalog/","summary":"Demonstração do Governance RiskOps Agent, projeto premiado como Top 5 Global no DAIS 2026 Community Virtual Contest, sobre detecção inteligente de riscos de governança no Unity Catalog.","title":"🎥 Governance RiskOps Agent: Detecção Inteligente de Riscos no Unity Catalog"},{"content":"Abrindo o curso preparatório para a certificação Azure Databricks Data Engineer Associate (DP-750), este vídeo apresenta o que o curso vai cobrir e como as aulas estão organizadas.\nA ideia é seguir com aulas focadas nos temas que mais caem na prova, sempre com exemplos práticos na plataforma, complementando o que já escrevo aqui no blog sobre Databricks.\nAssista 👉 Assistir no YouTube\nAs próximas aulas do curso vão aparecer automaticamente na página do curso: Certificação Databricks DP-750.\n","permalink":"https://wiliamrosa.github.io/videos/curso-databricks-dp-750-apresentacao/","summary":"Vídeo de apresentação do curso preparatório para a certificação Azure Databricks Data Engineer Associate (DP-750). As próximas aulas do curso vão sendo publicadas aqui conforme lançadas.","title":"🎬 Curso preparatório para Certificação Databricks DP-750: Apresentação"},{"content":"Ativar change data feed tabela por tabela deixou de ser necessário: agora o Databricks calcula a mudança de linha na hora em que alguém pergunta por ela.\nO Azure Databricks anunciou a disponibilidade geral do Automatic Change Data Feed (Auto CDF), recurso que calcula mudança de linha usando row tracking no momento da consulta, sem exigir que você habilite change data feed manualmente em cada tabela Delta Lake ou Apache Iceberg v3.\nA diferença em relação ao change data feed tradicional está em quando o custo é pago. Em vez de gravar dado extra de rastreamento de mudança a cada escrita, o Auto CDF calcula isso só quando alguém efetivamente consulta a mudança, removendo a sobrecarga de escrita em tabela que raramente é lida por esse ângulo. O recurso funciona em consulta batch, em Structured Streaming e em Delta Lake Sharing, e exige Databricks Runtime 19 LTS ou superior com row tracking habilitado.\nPontos técnicos que valem atenção:\nCalcula mudança de linha, insert, update e delete, na hora da consulta, usando row tracking, em vez de gravar changelog a cada escrita Funciona em consulta batch, Structured Streaming e Delta Lake Sharing Exige Databricks Runtime 19 LTS ou superior com row tracking habilitado A Databricks reporta operação de MERGE e UPDATE cerca de 15% mais rápida em tabela consultada por mudança, já que a sobrecarga de escrita deixa de acontecer antecipadamente Minhas considerações: o ganho de desempenho aqui não vem de um MERGE ou UPDATE mais esperto, vem de mover o custo de \u0026ldquo;sempre que escreve\u0026rdquo; pra \u0026ldquo;só quando alguém de fato consulta a mudança\u0026rdquo;. Isso favorece claramente tabela que raramente é lida via CDC, mas pra tabela consultada com frequência por streaming downstream vale medir se calcular a mudança a cada consulta não acaba custando mais do que o antigo rastreamento feito na escrita.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/release-notes/product/2026/september#automatic-change-data-feed-is-now-generally-available\n#Databricks #DeltaLake #AzureDatabricks\n","permalink":"https://wiliamrosa.github.io/posts/auto-cdf-change-data-feed-automatico-ga/","summary":"Automatic Change Data Feed (Auto CDF) atingiu disponibilidade geral no Azure Databricks: calcula mudança de linha na hora da consulta usando row tracking, sem exigir habilitar change data feed manualmente em cada tabela.","title":"Change Data Feed automático chega à disponibilidade geral, sem precisar ligar nada tabela por tabela"},{"content":"Órgão regulador americano também sofre do mesmo problema clássico de dado espalhado em silo, só que com a complicação extra de exigência de segurança de governo.\nA Databricks detalhou como a FDA (Food and Drug Administration) modernizou a própria infraestrutura de dado construindo o HALO (Harmonized AI and Lifecycle Operations for Data), rodando sobre Databricks em AWS GovCloud. O objetivo declarado é permitir capacidade de IA segura e governada pra trabalho regulatório, sem repetir o problema de cada centro da agência manter seu próprio pedaço isolado de dado.\nA peça central é o Unity Catalog funcionando como camada única de governança pra descobrir e gerenciar ativo confiável entre região e formato diferente. O modelo de isolamento usado é descrito como \u0026ldquo;apartment complex\u0026rdquo;: cada centro regulatório compartilha a mesma infraestrutura de base, mas mantém espaço isolado e governado por política própria, parecido com prédio de apartamento onde a estrutura é comum mas cada unidade tem sua própria porta trancada.\nPontos técnicos que valem atenção:\nUnity Catalog como camada única de governança de dado e IA entre região e formato Modelo \u0026ldquo;apartment complex\u0026rdquo;: infraestrutura compartilhada entre centro regulatório, mas isolamento e política por unidade PrivateLink, chave de criptografia gerenciada pelo cliente e perfil de segurança de compliance provisionados via Terraform Compute serverless e model serving usados na camada de execução 30% de ganho de performance em consulta SQL reportado após a otimização Minhas considerações: o modelo \u0026ldquo;apartment complex\u0026rdquo; é basicamente multi-tenant com governança fina de sempre, o que muda aqui é o contexto, é órgão de governo tratando isolamento entre departamento regulatório com o mesmo rigor que uma empresa trataria isolamento entre cliente pagante. Vale de referência pra qualquer organização grande e descentralizada que precisa de dado compartilhado sem abrir mão de fronteira de acesso entre área.\nFonte: https://www.databricks.com/blog/how-fda-building-secure-ai-ready-data-foundation-databricks-government\n#Databricks #UnityCatalog #Governanca\n","permalink":"https://wiliamrosa.github.io/posts/fda-databricks-government-data-foundation/","summary":"A FDA construiu o HALO, plataforma sobre Databricks em AWS GovCloud, pra resolver silo de dado entre centros regulatórios distintos, usando Unity Catalog como camada de governança única e um modelo de isolamento por área que a Databricks chama de \u0026lsquo;apartment complex\u0026rsquo;.","title":"Como a FDA constrói governança de dado sobre Databricks for Government"},{"content":"O Genie deixou de responder só com base em tabela estruturada e passou a lidar com pergunta que exige investigar antes de responder.\nA Databricks expandiu o Genie Agents em três frentes. A primeira é o Agent mode, um modo de raciocínio em múltiplos passos: em vez de tentar responder de cara, o agente monta um plano de investigação, explora o dado em rodadas iterativas de consulta e devolve um relatório com achados, visualização e citação da fonte usada. Isso já está disponível via API com Server-Sent Events pra resposta em streaming, com gestão completa de conversa, histórico de follow-up e suporte a visualização junto do texto. A segunda frente é a leitura de dado não estruturado: PDF, documento, slide e imagem guardados em volume do Unity Catalog agora entram na mesma análise que já cobria tabela, até dez volumes por configuração, sempre respeitando a permissão de quem está perguntando. Um índice de busca opcional acelera a recuperação e melhora o raciocínio quando o volume de arquivo é grande.\nA terceira frente muda quem constrói o agente. O Genie Code ganhou três funções voltadas a curar outro Genie: gerar uma configuração inicial a partir de uma descrição de propósito e perguntas de exemplo, diagnosticar falha analisando conversa com erro e sugerindo ajuste de instrução, e acompanhar produção analisando tendência de pergunta e feedback do usuário pra apontar lacuna de conhecimento.\nPontos técnicos que valem atenção:\nAgent mode monta plano de investigação e itera em múltiplas consultas antes de responder, em vez de responder direto API com Server-Sent Events permite streaming de resposta e gestão programática de conversa e follow-up Até dez volumes do Unity Catalog por configuração, com permissão do usuário respeitada arquivo por arquivo Indexação de conteúdo é opcional, pensada pra coleção grande de documento Genie Code passa a gerar, diagnosticar e monitorar outro agente Genie, não só escrever código de pipeline Minhas considerações: juntar tabela estruturada e arquivo solto na mesma pergunta resolve um problema real, muita decisão de negócio depende de cruzar número com contrato, ata ou política em PDF. Mas isso também espalha a superfície de governança: antes bastava pensar em permissão de tabela, agora entra permissão de volume, indexação de conteúdo e o próprio comportamento do Agent mode ao decidir quantas iterações vale a pena rodar antes de responder. Vale acompanhar de perto quanto esse raciocínio em múltiplos passos custa em token antes de liberar geral.\nFonte: https://www.databricks.com/blog/expanding-genie-agents-deep-analysis-file-reasoning-and-more\n#Databricks #Genie #Agentes\n","permalink":"https://wiliamrosa.github.io/posts/genie-agents-deep-analysis-file-reasoning/","summary":"Agent mode traz raciocínio em múltiplos passos com relatório e visualização, Genie Agents passa a ler PDF, slide e imagem dentro de volume do Unity Catalog, e o Genie Code ganha função pra criar e diagnosticar outros agentes Genie.","title":"Genie Agents ganha modo de pesquisa em múltiplos passos e aprende a ler arquivo, não só tabela"},{"content":"Uma mudança de \u0026ldquo;opcional\u0026rdquo; pra \u0026ldquo;obrigatório\u0026rdquo; em regra de compliance costuma passar despercebida até travar um workspace em produção.\nA Microsoft confirmou nas release notes de setembro de 2026 que os controles de compliance HITRUST e IRAP chegaram à disponibilidade geral no Azure Databricks, via compliance security profile. A parte que exige atenção não é a GA em si, é a mudança de regra que vem junto: a partir de agora, workspace que processa dado sob HIPAA, HITRUST ou IRAP precisa ter o compliance security profile ativado, deixou de ser recomendação, virou pré-requisito.\nCompliance security profile é o mecanismo do Azure Databricks que aplica um conjunto de controle técnico (rede, monitoramento, hardening) necessário pra atender padrão regulatório específico. Até aqui, HITRUST e IRAP estavam em estágio anterior à disponibilidade geral, o que deixava equipe de segurança em zona cinzenta sobre se podia depender disso pra certificação formal.\nPontos técnicos que valem atenção:\nHITRUST (saúde, padrão americano) e IRAP (Infosec Registered Assessors Program, padrão australiano de governo) agora em disponibilidade geral Compliance security profile passa a ser exigência, não opção, pra workspace sob HIPAA, HITRUST ou IRAP Mudança vale a partir de 1º de setembro de 2026 Sem prazo de carência mencionado nas release notes pra quem já roda workspace sob esses padrões sem o perfil ativado Minha ressalva: toda vez que um requisito de compliance muda de opcional pra obrigatório, o risco real não é técnico, é operacional, alguém que já certificou o ambiente sob a regra antiga e não percebeu a mudança de status até uma auditoria travar. Vale checar agora se algum workspace sob HIPAA, HITRUST ou IRAP na sua conta ainda está sem o compliance security profile ligado, antes que isso vire problema de auditoria.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/release-notes/product/2026/september#hitrust-and-irap-compliance-controls-are-now-generally-available\n#AzureDatabricks #Compliance #Governanca\n","permalink":"https://wiliamrosa.github.io/posts/hitrust-irap-compliance-security-profile-ga/","summary":"Controles de compliance HITRUST e IRAP atingiram disponibilidade geral no Azure Databricks em setembro de 2026, e a partir de agora HIPAA, HITRUST e IRAP exigem o compliance security profile ativado, deixou de ser configuração opcional pra quem já usa esses padrões.","title":"HITRUST e IRAP viram GA no Azure Databricks, e o perfil de segurança de compliance passa a ser obrigatório"},{"content":"Um bug de formatação numa ferramenta de integração com Jira custava sozinho quase meio milhão de dólares por ano em token desperdiçado.\nA Databricks publicou um relato interno mostrando como usou o rastreamento automático que o Unity AI Gateway já gera pra cada chamada de ferramenta MCP, sem precisar instrumentar nada a mais, pra encontrar falha silenciosa em produção. Toda chamada de ferramenta feita por um agente passa pelo gateway, que grava nome da ferramenta, argumento, erro, token consumido, latência e sessão numa tabela unificada.\nEm vez de vasculhar log manualmente, o time usou o próprio Genie One, em linguagem natural, pra perguntar direto sobre essa tabela de rastreamento, tipo quais ferramentas falham mais e quanto isso custa. Esse cruzamento achou sete bugs em uma amostra de 24 horas.\nPontos técnicos que valem atenção:\n1.409 falhas por dia identificadas nesses sete bugs somados Maior bug isolado: ferramenta de Jira esperava string separada por vírgula, mas recebia array JSON, gerando 535 falhas por dia e média de 12 turnos de conversa até o modelo conseguir contornar sozinho Custo estimado de token desperdiçado, cerca de 499 mil dólares por ano, mais cerca de 12 mil horas de engenharia perdidas, total próximo de 1,2 milhão de dólares por ano Correção do bug principal saiu em uma hora, da análise até o deploy Princípio de design reforçado pelo caso: ferramenta MCP deveria tolerar o jeito que modelo naturalmente chama ela, com coerção de tipo e valor default, em vez de simplesmente falhar Minhas considerações: esse caso é um bom contraponto pra discussão de custo de IA que geralmente foca só em qual modelo é mais barato, aqui o desperdício real estava em ferramenta mal desenhada, não em escolha de modelo. Observabilidade nativa sem instrumentação extra parece ser o tipo de investimento que se paga sozinho quase imediatamente.\nFonte: https://www.databricks.com/blog/how-we-eliminated-1-million-year-wasted-ai-agent-spend-one-hour\n#Databricks #UnityAIGateway #Observabilidade\n","permalink":"https://wiliamrosa.github.io/posts/unity-gateway-tracing-mcp-economiza-1-milhao/","summary":"A Databricks publicou um caso interno onde o rastreamento OpenTelemetry nativo do Unity AI Gateway, cruzado com pergunta em linguagem natural no Genie One, achou sete bugs de ferramenta MCP responsáveis por quase 1,2 milhão de dólares por ano em token e hora de engenharia desperdiçados.","title":"Rastreamento automático de chamada MCP achou bug que custava quase 500 mil dólares por ano"},{"content":"Um pesquisador de segurança achou uma falha que qualquer usuário comum do Lakebase Postgres, sem privilégio nenhum, conseguia explorar.\nA Databricks publicou os detalhes de uma vulnerabilidade de memória encontrada na extensão address_standardizer do PostGIS, usada em bancos Postgres para normalizar endereço. A falha permitia que qualquer usuário com acesso normal ao banco, sem privilégio administrativo, acionasse um comportamento de estouro de limite na extensão, o tipo de brecha que em tese poderia ser usada para acessar memória fora do escopo esperado da consulta.\nO que chama atenção não é só a falha em si, mas o processo em volta dela. A Databricks detectou o comportamento de teste do pesquisador de segurança Mehmet Ince de forma proativa, colaborou com ele durante a investigação, corrigiu o problema em produção rapidamente para proteger cliente do Lakebase Postgres e de outras plataformas que usam a mesma extensão, como o Neon, e depois contribuiu a correção completa de volta para o projeto PostGIS. O pesquisador, por sua vez, doou a recompensa do bug bounty para mantenedores voluntários de projeto open source.\nPontos técnicos que valem registrar:\nFalha de bounds-check na extensão address_standardizer do PostGIS, acionável por usuário comum, sem privilégio elevado Afetava qualquer plataforma de Postgres gerenciado que carregasse essa extensão, incluindo Lakebase Postgres e Neon Databricks identificou o teste do pesquisador antes da divulgação pública e já tinha corrigido quando o relatório formal chegou Correção completa contribuída de volta ao projeto PostGIS, beneficiando qualquer usuário da extensão, não só cliente Databricks Minha ressalva: extensão de terceiro dentro de um Postgres gerenciado é superfície de ataque que a plataforma não controla sozinha. O processo de divulgação responsável funcionou bem dessa vez, mas o episódio é um lembrete de que rodar Postgres com extensão como PostGIS, mesmo dentro de um serviço gerenciado como o Lakebase, herda o risco de segurança do ecossistema de extensão que ninguém audita sozinho. Vale perguntar ao seu fornecedor de banco gerenciado, Databricks incluso, qual é o processo de auditoria de extensão de terceiro antes de habilitar qualquer uma em produção.\nFonte: https://www.databricks.com/blog/collaboration-makes-us-all-stronger\n#Databricks #Lakebase #Seguranca\n","permalink":"https://wiliamrosa.github.io/posts/databricks-vulnerabilidade-postgis-lakebase-postgres/","summary":"Um pesquisador encontrou uma falha de bounds-check na extensão address_standardizer do PostGIS, explorável por qualquer usuário comum do Lakebase Postgres e do Neon, e a Databricks corrigiu antes da divulgação pública.","title":"Uma falha no PostGIS expôs todo tenant do Lakebase Postgres, e a Databricks corrigiu antes de qualquer exploração"},{"content":"📅 09 e 10 de dezembro de 2026 · 📍 Porto Alegre, RS\nA TDC Experience chega a Porto Alegre com trilhas dedicadas a quem constrói tecnologia no dia a dia, no Multiplan Hall do BarraShoppingSul.\nA programação inclui trilhas de Gestão e Agilidade, Arquitetura de Agentes de IA, Futuro do Design Interativo, Liderança Técnica, Engenharia orientada a dados, e Segurança, Governança e Qualidade, cobrindo tanto profissionais técnicos (devs, analistas, arquitetos) quanto lideranças e empreendedores de tecnologia.\nSobre o evento TDC Experience é o formato regional do TDC (The Developer\u0026rsquo;s Conference) fora do eixo das conferências principais, com ingressos avulsos por dia ou passaporte para os dois dias.\nInscreva-se 👉 Inscrição no evento\n#TDC #TDCExperience\n","permalink":"https://wiliamrosa.github.io/events/tdc-experience-porto-alegre-2026/","summary":"TDC Experience chega a Porto Alegre com trilhas de Arquitetura de Agentes de IA, Engenharia orientada a dados e Governança, voltadas a quem constrói tecnologia no dia a dia.","title":"🎤 TDC Experience Porto Alegre"},{"content":"📅 11 e 12 de novembro de 2026 · 📍 Recife, PE\nO TDC Stage chega a Recife pelo quinto ano consecutivo, dentro da programação do Rec\u0026rsquo;n\u0026rsquo;Play, no Moinho Recife, com entrada gratuita.\nÉ uma trilha de conteúdo técnico de alto nível voltada a desenvolvedores e profissionais de tecnologia, dentro da proposta mais ampla do TDC de levar conteúdo técnico e comunidade pra fora do eixo São Paulo.\nSobre o evento O TDC Stage é a versão itinerante do TDC (The Developer\u0026rsquo;s Conference), levando trilhas de conteúdo técnico pra dentro de eventos parceiros em diferentes cidades do Brasil.\nInscreva-se 👉 Pré-inscrição no TDC Stage (inscrição geral do Rec\u0026rsquo;n\u0026rsquo;Play em recnplay.pe)\n#TDC #TDCStage\n","permalink":"https://wiliamrosa.github.io/events/tdc-stage-recife-2026/","summary":"TDC Stage chega a Recife pelo quinto ano consecutivo dentro da programação do Rec\u0026rsquo;n\u0026rsquo;Play, com entrada gratuita e trilha de conteúdo técnico de alto nível.","title":"🎤 TDC Stage Recife"},{"content":"📅 08 de setembro de 2026 · ⏰ 18h às 22h (BRT) · 📍 São Paulo, SP\nA Databricks promove o DevConnect em São Paulo, um encontro presencial gratuito para profissionais de dados e IA, no DotHub (Deloitte), com happy hour de networking no final.\nA programação tem três blocos técnicos: um sobre construção artesanal de pipelines de dados (Lakehouse em tempo real, disaster recovery, cargas SQL e transações multi-tabela), outro sobre ferramentas de desenvolvimento com IA (MCPs, Unity AI Gateway e automação de workflow), e um terceiro sobre como levar esses builds a usuários não técnicos via Apps, Genie e dashboards customizados. Entre os palestrantes confirmados estão Felipe Cruz Neiva Campos, Filipe Ferrari Galan Deo, Wagner Santos e Moises Santos, da Databricks, e Jefferson Lopes Dent, da Deloitte.\nSobre o evento Databricks DevConnect é a série de encontros presenciais da Databricks voltada a praticantes de dados e IA, com conteúdo técnico aplicado.\nInscreva-se 👉 Inscrição no evento\n#Databricks #DevConnect\n","permalink":"https://wiliamrosa.github.io/events/databricks-devconnect-sao-paulo-2026/","summary":"Encontro presencial gratuito da Databricks em São Paulo, com sessões técnicas sobre Lakehouse, ferramentas de IA como Unity AI Gateway e MCPs, e como levar esses builds a usuários não técnicos via Genie.","title":"🤝 Databricks DevConnect São Paulo"},{"content":"📅 27 de outubro de 2026 · ⏰ 19h30 (BRT) · 💻 Evento online\nSessão de encerramento da série do Microsoft Reactor São Paulo sobre desenvolvimento com agentes, focada em escalar essas práticas para ambientes colaborativos.\nO tema é como levar workflows com agentes além do uso individual: padronizar práticas entre diferentes pessoas do time, manter consistência entre contribuidores, e usar desenvolvimento orientado por especificação (spec-driven) como base pra escalar o uso de IA no dia a dia de um time inteiro.\nInscreva-se 👉 Inscrição no evento\n#MicrosoftReactor #AgentesDeIA\n","permalink":"https://wiliamrosa.github.io/events/reactor-escalando-workflows-com-agentes/","summary":"Sessão de encerramento da série do Microsoft Reactor São Paulo sobre desenvolvimento com agentes, focada em padronizar e escalar essas práticas em times inteiros.","title":"📈 Escalando Workflows com Agentes"},{"content":"📅 20 de outubro de 2026 · ⏰ 19h30 (BRT) · 💻 Evento online\nTerceira sessão da série do Microsoft Reactor São Paulo sobre desenvolvimento com agentes de código, voltada pra construção de workflows reutilizáveis no Visual Studio Code.\nA ideia é sair do prompt avulso e organizar bibliotecas de prompts e fluxos de trabalho pra cenários recorrentes, como desenvolvimento de features, refatoração e documentação, buscando mais previsibilidade e eficiência no uso do GitHub Copilot.\nInscreva-se 👉 Inscrição no evento\n#MicrosoftReactor #AgentesDeIA\n","permalink":"https://wiliamrosa.github.io/events/reactor-workflows-reutilizaveis-vscode/","summary":"Terceira sessão da série do Microsoft Reactor São Paulo sobre desenvolvimento com agentes, mostrando como organizar bibliotecas de prompts e workflows reutilizáveis no VS Code.","title":"🔁 Construindo Workflows Reutilizáveis no VS Code"},{"content":"📅 13 de outubro de 2026 · ⏰ 19h30 (BRT) · 💻 Evento online\nSegunda sessão da série sobre agentic development do Microsoft Reactor São Paulo, dessa vez aprofundando como estruturar o comportamento de agentes de código usando AGENTS.md e prompt files reutilizáveis.\nO foco é organização prática: como separar instruções por tarefa, definir responsabilidades claras entre diferentes agentes, e evoluir um setup inicial simples para um modelo modular e reutilizável no dia a dia de desenvolvimento.\nInscreva-se 👉 Inscrição no evento\n#MicrosoftReactor #AgentesDeIA\n","permalink":"https://wiliamrosa.github.io/events/reactor-estruturando-agentes-agents-md-prompt-files/","summary":"Segunda sessão da série do Microsoft Reactor São Paulo sobre desenvolvimento com agentes, aprofundando o uso de AGENTS.md e prompt files reutilizáveis pra organizar instruções por tarefa.","title":"📋 Estruturando Agentes com AGENTS.md e Prompt Files"},{"content":"📅 06 de outubro de 2026 · ⏰ 19h30 (BRT) · 💻 Evento online\nO Microsoft Reactor São Paulo abre uma série sobre desenvolvimento orientado a agentes com uma introdução aos fundamentos do agentic development no Visual Studio Code, usando GitHub Copilot.\nA sessão mostra como definir o comportamento de um agente de código através de um arquivo AGENTS.md, comparando essa abordagem estruturada com interações soltas baseadas apenas em prompts, e fecha com a implementação de um primeiro setup orientado por especificação.\nInscreva-se 👉 Inscrição no evento\n#MicrosoftReactor #AgentesDeIA\n","permalink":"https://wiliamrosa.github.io/events/reactor-introducao-agentic-dev-spec-driven-vscode/","summary":"Primeira sessão de uma série do Microsoft Reactor São Paulo sobre desenvolvimento orientado a agentes no VS Code, cobrindo os fundamentos de definir comportamento de agente via AGENTS.md.","title":"💻 Introdução ao Agentic Dev com Spec-Driven no VS Code"},{"content":"📅 01 de outubro de 2026 · ⏰ 19h (BRT) · 💻 Evento online\nO Microsoft Reactor recebe Josimar Hedler, Cyber Security Engineer, para uma sessão sobre identidade e governança de agentes autônomos de IA.\nA discussão parte de uma pergunta central: quando um agente de IA pode agir sozinho, acessando recursos e tomando decisões, quem controla essa identidade? A sessão mostra como o Microsoft Entra Agent ID aplica conceitos de gestão de identidade e acesso (IAM) a essa nova realidade, com uma parte teórica sobre riscos e conceitos, seguida de um hands-on colocando a governança de agentes em prática.\nSobre o evento Promovido pelo Microsoft Reactor, hub de eventos gratuitos da Microsoft para a comunidade de desenvolvedores.\nInscreva-se 👉 Inscrição no evento\n#MicrosoftReactor #AgentesDeIA\n","permalink":"https://wiliamrosa.github.io/events/reactor-governando-agentes-entra-agent-id/","summary":"Sessão gratuita do Microsoft Reactor sobre identidade, privilégios e governança de agentes autônomos de IA usando o Microsoft Entra Agent ID, com Josimar Hedler, Cyber Security Engineer.","title":"🤖 Governando agentes autônomos com o Microsoft Entra Agent ID"},{"content":"📅 30 de setembro de 2026 · ⏰ 19h (BRT) · 💻 Evento online\nO Microsoft Reactor promove uma sessão gratuita sobre proteção de dados na era da IA, com Júlio César Vasconcelos, Cybersecurity Architect na Jornada 365 e Microsoft MVP de Security.\nA proposta é mostrar como o Microsoft Purview ajuda a descobrir, classificar, proteger e governar dados enquanto uma organização adota IA generativa, cobrindo prevenção de perda de dados (DLP), proteção de informações sensíveis e governança de IA aplicada a cenários práticos.\nSobre o evento Promovido pelo Microsoft Reactor, hub de eventos gratuitos da Microsoft para a comunidade de desenvolvedores, com transmissão ao vivo e gravação disponível depois.\nInscreva-se 👉 Inscrição no evento\n#MicrosoftReactor #GovernançaDeIA\n","permalink":"https://wiliamrosa.github.io/events/reactor-protecao-dados-era-ia/","summary":"Sessão gratuita do Microsoft Reactor sobre como o Microsoft Purview ajuda a descobrir, classificar, proteger e governar dados sensíveis na adoção de IA, com Júlio César Vasconcelos, Cybersecurity Architect.","title":"🛡️ Proteção de dados na era da IA"},{"content":"O que a Databricks anunciou A Databricks disponibilizou o Claude Fable 5.1, descrito pela Anthropic como seu modelo mais capaz, como lançamento de dia 0 na plataforma. Ele se junta ao Claude Opus 5, Claude Sonnet 5 e mais de 30 modelos open-source e de fronteira já hospedados. Via Unity Gateway, é possível conectar o Fable 5.1 direto aos agentes de código da organização, com roteamento inteligente, controle de custo centralizado e observabilidade em um único painel.\nFonte original: post da Databricks no LinkedIn\nPor que isso importa na prática O dado que salta aos olhos aqui não é \u0026ldquo;modelo novo disponível\u0026rdquo;, isso vira rotina a cada poucas semanas. É o fato de esse tipo de lançamento já nascer conectado à mesma camada de governança que comentei quando o Unity AI Gateway chegou à disponibilidade geral: roteamento, custo e observabilidade não são construídos de novo a cada modelo, eles já existem como política, e o modelo novo só entra na fila.\nIsso muda o tipo de trabalho que times de plataforma fazem quando um modelo novo sai. Sem gateway central, adicionar um provedor novo costuma significar reabrir instrumentação de custo, reconfigurar acesso e reconstruir observabilidade específica para aquele modelo. Com o Unity Gateway já em produção, isso vira uma decisão de política, apontar o roteamento para o modelo certo, dentro do orçamento certo, com a auditoria de sempre.\nMinha opinião \u0026ldquo;Dia 0\u0026rdquo; é uma boa notícia para quem desenvolve, mas o ganho real, na minha visão, é para quem administra a plataforma: onboarding de modelo deixou de ser projeto de engenharia para virar decisão de política central, e é exatamente esse tipo de estrutura que permite adotar modelo novo rápido sem abrir mão de controle.\nA ressalva que eu levantaria: roteamento inteligente entre mais de 30 modelos é ótimo para custo e performance, mas cabe perguntar se a política de roteamento também considera classificação de dado, não só custo e latência. Um agente de código que é automaticamente redirecionado para \u0026ldquo;o modelo mais adequado\u0026rdquo; pode acabar enviando um trecho de código sensível para um modelo mais novo e ainda pouco auditado internamente, sem que isso passe por uma aprovação explícita. Vale confirmar se o Unity Gateway permite fixar política de roteamento por classificação de dado, e não apenas por custo ou latência, antes de liberar roteamento automático para cargas sensíveis.\nPara saber mais Post original: https://lnkd.in/g-i2XFCQ Unity AI Gateway chega à disponibilidade geral: governança de IA deixou de ser opcional ","permalink":"https://wiliamrosa.github.io/posts/databricks-claude-fable-5-1-unity-gateway/","summary":"A Databricks liberou o Claude Fable 5.1 da Anthropic no mesmo dia do lançamento, via Unity Gateway, ao lado de Opus 5, Sonnet 5 e mais de 30 modelos. O que chama atenção não é o modelo novo, é a infraestrutura que torna isso rotina.","title":"Claude Fable 5.1 no Databricks no dia 0: o Unity Gateway é que torna isso rotina"},{"content":"O Databricks MVP Casper Lubbers notou uma mudança silenciosa nas system tables do Databricks: informação potencialmente sensível, tanto em query.history quanto em alguns request_params onde detalhes de query ficam guardados, agora vem mascarada por padrão. Pra ver o dado sem máscara, é preciso fazer parte do grupo databricks_pii_access.\nIsso resolve um problema prático que qualquer time de plataforma que já trabalhou com system tables conhece bem: historicamente, a única forma seguindo de dar acesso amplo às system tables (fundamentais pra responder perguntas como \u0026ldquo;quanto isso está me custando\u0026rdquo; ou \u0026ldquo;quem fez X\u0026rdquo;) era manter uma view própria por cima, filtrando manualmente o que era sensível antes de liberar pro resto da organização.\nPor que essa mudança elimina trabalho real de manutenção:\nViews customizadas pra mascarar dado sensível são exatamente o tipo de camada que ninguém lembra de atualizar quando o schema da system table muda Mascaramento por padrão, com controle de acesso baseado em grupo, é o modelo que já funciona bem pro resto dos dados no Unity Catalog, aplicado agora ao próprio metadado operacional da plataforma Sem a necessidade de view intermediária, mais gente na organização pode ter acesso direto às system tables pra responder perguntas de custo e uso, sem esperar que alguém do time de plataforma libere acesso caso a caso Minha ressalva: mascaramento por padrão é uma boa mudança, mas \u0026ldquo;por padrão\u0026rdquo; também significa que times que já tinham processos de auditoria dependendo do dado não-mascarado (por exemplo, investigação de segurança que precisa ver o texto completo de uma query suspeita) agora precisam garantir explicitamente que as pessoas certas estão no grupo databricks_pii_access, é fácil essa mudança quebrar silenciosamente um processo de auditoria existente até alguém notar que o dado sumiu da view.\nFonte: https://www.linkedin.com/in/casper-lubbers/\n#Databricks #UnityCatalog #Governança\n","permalink":"https://wiliamrosa.github.io/posts/databricks-system-tables-mascaramento-pii-padrao/","summary":"Dados potencialmente sensíveis em query.history e request_params agora vêm mascarados por padrão nas system tables, liberando acesso amplo sem expor informação sensível a quem não deveria ver.","title":"Chega de manter view própria só pra esconder dado sensível das system tables"},{"content":"A Databricks publicou um guia prático sobre como operacionalizar o Genie Ontology usando os ativos governados que sua organização já tem, sem esperar por um modelo de dados corporativo perfeito antes de começar. A tese central: curadoria deliberada ao longo do tempo fortalece o contexto de negócio, tornando as respostas mais precisas, autorizadas e confiáveis, mas isso pode (e deve) começar pequeno.\nO guia recomenda escolher um domínio de alto valor, modelar a \u0026ldquo;cabeça\u0026rdquo; crítica do negócio manualmente, e deixar o Genie inferir a \u0026ldquo;cauda longa\u0026rdquo;, expandindo depois com base nas perguntas reais dos usuários, nas áreas onde a ambiguidade persiste, e nas oportunidades onde contexto mais forte melhora a decisão.\nPor que essa recomendação específica importa:\nModelagem de ontologia corporativa completa antes de qualquer valor entregue é o tipo de projeto que historicamente nunca termina Deixar o sistema inferir a cauda longa a partir de um núcleo bem modelado é uma aposta pragmática: você não precisa de cobertura perfeita pra já ter valor real Tratar isso como processo iterativo (curadoria contínua, avaliação constante) reconhece que ontologia de negócio nunca fica \u0026ldquo;pronta\u0026rdquo; de verdade Minha ressalva: \u0026ldquo;comece pequeno e expanda\u0026rdquo; é um bom conselho de produto, mas esconde o risco real de governança: cada domínio adicional de ontologia que entra depois do primeiro precisa da mesma disciplina de curadoria que o piloto recebeu, ou a qualidade das respostas do Genie começa a variar dependendo de qual parte do negócio você pergunta. Vale definir desde o início quem é dono da manutenção contínua de cada domínio, não só de quem modela o primeiro.\nFonte: https://www.databricks.com/blog/operationalizing-genie-ontology-your-data-stack\n#Databricks #GenieOntology #Governança\n","permalink":"https://wiliamrosa.github.io/posts/databricks-genie-ontology-guia-operacionalizacao/","summary":"A Databricks publicou um guia com seis formas práticas de operacionalizar o Genie Ontology, defendendo começar pequeno num domínio de alto valor em vez de esperar um modelo corporativo completo.","title":"Genie Ontology não exige um modelo de dados perfeito para começar a valer a pena"},{"content":"Redimensionar a máquina de um banco de dados em produção sem derrubar conexão ainda soa como proeza, mesmo em 2026.\nA Databricks detalhou o mecanismo de autoscaling automático de VM do Lakebase Postgres. Como o Lakebase separa armazenamento de computação, o nó de computação pode ser iniciado, parado, movido ou redimensionado de forma independente do dado gravado em disco, o que abre espaço pra trocar de tamanho de máquina sem perder o estado.\nA decisão de quando escalar olha três sinais ao mesmo tempo e usa o maior deles como gatilho, sempre respeitando limite configurado pelo usuário. O sinal mais interessante tecnicamente é a estimativa de working set, calculada com uma variante de HyperLogLog que guarda timestamp em vez de bit dentro de cada registrador, permitindo estimar o tamanho do conjunto de dados ativo numa janela de tempo, ao invés de só uma contagem acumulada.\nPontos técnicos que valem atenção:\nSinal de CPU, média de 1 minuto, mantém abaixo de 90%, checado a cada 5 segundos Sinal de memória, mantém uso abaixo de 75% da RAM alocada, verificado a cada 100 milissegundos Sinal de working set, recalculado a cada 20 segundos, com janela de estimativa de até 60 minutos Em produção, o sistema já executa mais de 32 mil eventos de escalonamento por mês Minhas considerações: a variante de HyperLogLog sensível a tempo é o tipo de detalhe de engenharia que vale guardar como referência, mesmo fora do contexto Lakebase, pra qualquer sistema que precise estimar cardinalidade recente sob carga variável. Isso complementa o que já foi coberto aqui antes sobre arquitetura do Lakebase, agora com o pedaço específico de como ele decide escalar.\nFonte: https://www.databricks.com/blog/autoscaling-lakebase-postgres\n#Databricks #Lakebase #Arquitetura\n","permalink":"https://wiliamrosa.github.io/posts/lakebase-postgres-autoscaling-hyperloglog/","summary":"A Databricks detalhou como o Lakebase Postgres faz autoscaling automático de VM sem derrubar conexão, combinando uso de CPU, uso de memória e uma estimativa de working set feita com uma variante de HyperLogLog sensível a tempo.","title":"Lakebase Postgres decide sozinho quando trocar de tamanho de máquina, usando HyperLogLog"},{"content":"Framework mais adotado dos Databricks Labs pra construir pipeline bronze e prata trocou de nome e ganhou peças novas de uma vez.\nO Databricks MVP Josue Bogran documentou o lançamento da versão 0.1.0 do SDP-META, a nova identidade do projeto que até então se chamava DLT-META, renomeado pra acompanhar a mudança de nome de Delta Live Tables pra Lakeflow Spark Declarative Pipelines dentro da plataforma.\nA proposta do framework continua a mesma: em vez de escrever um notebook de pipeline pra cada tabela, você descreve fonte, destino, regra de CDC e regra de qualidade em configuração JSON ou YAML, e um pipeline genérico lê essa configuração e monta o grafo de processamento em tempo de execução. Isso reduz bastante código repetido em ambiente com dezenas ou centenas de tabelas seguindo o mesmo padrão de ingestão.\nPontos técnicos que valem atenção:\nInstalação via pip install databricks-labs-sdp-meta, com pacote de compatibilidade pra quem ainda usa dlt-meta CLI própria, databricks labs sdp-meta, com comando de bundle-init, onboard e deploy Suporte nativo a Databricks Asset Bundles pra empacotar e implantar o pipeline App de configuração no navegador (SDP-META App) pra montar e revisar metadado sem editar arquivo direto MCP Server novo, pra scaffolding assistido por agente de código como Claude Code ou Cursor Continua suportando Autoloader, Delta, Kafka, Event Hub e ingestão via snapshot, incluindo CDC multi-fonte Minhas considerações: a Databricks troca nome de produto com uma frequência que já virou motivo de piada interna, mas nesse caso a essência do framework, pipeline guiado por metadado em vez de código repetido, continua sólida e vale a adoção pra time que sobe muitas tabelas parecidas. O MCP Server é o pedaço mais interessante pra quem já usa agente de código no dia a dia.\nFonte: https://pypi.org/project/databricks-labs-sdp-meta/\n#Databricks #Lakeflow #DatabricksLabs\n","permalink":"https://wiliamrosa.github.io/posts/sdp-meta-framework-lakeflow-declarative-pipelines/","summary":"O framework de pipeline metadata-driven dos Databricks Labs mudou de nome, de DLT-META pra SDP-META, na versão 0.1.0, e ganhou CLI própria, Asset Bundles, app de configuração e um MCP Server pra scaffolding assistido por agente.","title":"DLT-META virou SDP-META, com CLI novo e MCP Server pra montar pipeline"},{"content":"A Databricks colocou em Beta a system table pipeline_events, que reúne numa tabela só o log de evento de todo pipeline Lakeflow rodando na conta, em qualquer workspace da região.\nO ponto central é sair da situação em que investigar falha de pipeline significa abrir a interface de um workspace por vez e caçar log espalhado. Com pipeline_events, transição de ciclo de vida do pipeline, progresso de cada flow, métrica de qualidade de dado e erro operacional passam a ser linha de uma tabela padrão, com o mesmo modelo de consulta SQL que já se usa pra qualquer outra system table de auditoria ou billing. Isso muda investigação de falha de \u0026ldquo;abrir tela e procurar\u0026rdquo; pra \u0026ldquo;escrever query e filtrar\u0026rdquo;, e também abre a porta pra montar alerta automatizado em cima de padrão de falha recorrente, em vez de depender de alguém notar o problema primeiro.\nO que dá pra fazer com isso na prática:\nConsultar histórico de atividade de pipeline de forma centralizada, cruzando múltiplos workspaces da mesma região numa query só Montar alerta próprio sobre falha de pipeline, correlacionando com outras system tables de Lakeflow em vez de depender só de notificação nativa Auditar comportamento de pipeline ao longo do tempo, útil pra time de dado que responde por SLA de ingestão Minha ressalva: feature em Beta de system table costuma amadurecer bem, mas o valor real só aparece quando alguém efetivamente constrói o dashboard ou o alerta em cima dela, o dado sozinho parado numa tabela não muda nada operacionalmente. Vale tratar isso como convite pra revisar a estratégia de observabilidade de pipeline do zero, não só ligar o preview e seguir com o processo manual de sempre.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/admin/system-tables/pipeline-events\n#Databricks #Lakeflow #Observabilidade\n","permalink":"https://wiliamrosa.github.io/posts/pipeline-events-system-table-beta/","summary":"A pipeline_events system table (Beta) centraliza log de evento de todo pipeline Lakeflow da conta numa única tabela consultável, transição de estado, progresso de flow, métrica de qualidade e erro incluídos.","title":"Uma system table só pra saber o que aconteceu dentro do seu pipeline Lakeflow"},{"content":"O Databricks MVP Hubert Dudek notou um detalhe útil do modo de desenvolvimento dos bundles: trabalhando a partir da experiência web, com source-linked deployment ativado (o padrão no modo dev), editar um job ou pipeline direto na interface propaga a mudança automaticamente pros arquivos YML do bundle. Na prática, é o melhor dos dois mundos: baixo código pra quem quer ajustar rápido pela UI, e Infrastructure as Code pra quem depende de versionamento, ao mesmo tempo.\nEsse tipo de sincronização bidirecional (UI edita YAML, e não só o contrário) resolve uma fricção clássica de quem usa bundles: historicamente, editar pela UI e editar pelo arquivo eram dois mundos separados, e misturar os dois sem cuidado gerava divergência silenciosa entre o que estava rodando e o que estava versionado.\nPor que isso é útil, mas pede disciplina:\nReduz o atrito de \u0026ldquo;preciso editar um YAML só pra testar uma mudança pequena\u0026rdquo; Mantém o bundle como fonte de verdade, mesmo quando a edição começou pela interface Só funciona em modo de desenvolvimento, não é o comportamento esperado (nem desejável) em produção Minha ressalva, a mesma que o próprio Hubert Dudek levantou: revise sempre as mudanças no Git antes de assumir que elas capturam tudo, elementos que não passam pela UI, como variáveis e mutators, não necessariamente ficam refletidos automaticamente. Sincronização automática é ótima pra produtividade, mas não substitui revisão de diff antes de comitar.\nFonte: https://www.linkedin.com/posts/hubertdudek_when-working-from-the-web-experience-in-development-activity\n#Databricks #DeclarativeAutomationBundles #DevOps\n","permalink":"https://wiliamrosa.github.io/posts/databricks-dabs-source-linked-deployment-dev-mode/","summary":"Em modo de desenvolvimento com source-linked deployment, editar job ou pipeline pela UI propaga a mudança automaticamente pros arquivos YML do bundle, low-code e infra-como-código convivendo, mas exige atenção no Git.","title":"Editar job pela interface web e ver o YAML do bundle mudar sozinho, o melhor dos dois mundos, com uma ressalva"},{"content":"O Databricks MVP Hubert Dudek notou algo que passou batido no changelog oficial: o Fivetran, que estava presente na seção de Ingestão do workspace há muitos anos, sumiu, na mesma época em que novos conectores nativos do Lakeflow foram adicionados.\nEsse tipo de mudança silenciosa (sem anúncio formal, só percebida por quem usa a interface no dia a dia) diz bastante sobre a direção do produto: a Databricks vem investindo pesado em conectores nativos do Lakeflow Connect, SharePoint, Workday, conectores baseados em query sem CDC, e cada conector nativo novo é, indiretamente, um motivo a menos pra manter uma ferramenta de ingestão terceirizada em destaque na interface principal.\nPor que isso importa mesmo sem confirmação oficial:\nTimes que hoje dependem do Fivetran via essa integração devem verificar se o acesso ainda existe por outro caminho, ou se é hora de migrar pra um conector nativo do Lakeflow É um sinal (não prova definitiva) de prioridade de produto: nativo primeiro, parceiro depois Mudanças de interface sem changelog formal são exatamente o tipo de coisa que só aparece quando alguém da comunidade presta atenção, reforça o valor de acompanhar MVPs que usam a plataforma de verdade, não só ler nota de release Minha ressalva: isso é uma observação de um usuário avançado, não uma confirmação oficial da Databricks sobre descontinuar a parceria com o Fivetran. Vale tratar como um sinal de atenção, não como decisão automática de migrar tudo pra conector nativo, até vir uma confirmação (ou desmentido) oficial.\nFonte: https://www.linkedin.com/posts/hubertdudek_i-went-to-the-ingestion-section-and-see-activity\n#Databricks #LakeflowConnect #Ingestão\n","permalink":"https://wiliamrosa.github.io/posts/databricks-fivetran-removido-lakeflow-connectors/","summary":"O Databricks MVP Hubert Dudek percebeu que o Fivetran, presente há anos na seção de Ingestão, desapareceu silenciosamente, junto com a chegada de novos conectores nativos do Lakeflow.","title":"O Fivetran sumiu da seção de Ingestão do Databricks, e ninguém anunciou isso"},{"content":"O Databricks MVP Hubert Dudek teve acesso antecipado ao Genie ZeroOps, novo agente autônomo da Databricks que promete monitorar pipelines, jobs e tabelas continuamente, investigar a causa quando algo falha, e já propor a correção, e testou com três cenários de falha reais: overflow de tipo de dado, divisão por zero, e migração de servidor ao vivo.\nA maioria dos times só descobre que algo quebrou quando alguém rio abaixo reclama. Os três cenários que Hubert testou são justamente os tipos de problema que normalmente tiram alguém do sono às 3h da manhã, e é exatamente essa lógica que o ZeroOps tenta inverter.\nPor que isso é diferente de \u0026ldquo;mais um monitoramento\u0026rdquo;:\nMonitoramento tradicional avisa que algo quebrou; ZeroOps se propõe a já saber o porquê Cobre cenários de infraestrutura (migração de servidor), não só erro de código Reduz o tempo entre \u0026ldquo;algo quebrou\u0026rdquo; e \u0026ldquo;alguém entendeu o motivo\u0026rdquo;, que é normalmente o gargalo real de debug em produção Minha ressalva: \u0026ldquo;propor correção\u0026rdquo; é bem diferente de \u0026ldquo;aplicar correção\u0026rdquo;. A pergunta que eu faria antes de confiar nisso em produção é onde fica o ponto de aprovação humana, um agente que identifica a causa raiz corretamente mas erra na correção proposta pode transformar um incidente pequeno em um grande, se a proposta for aplicada sem revisão.\nFonte: https://www.sunnydata.ai/blog/genie-zeroops-hands-on-preview\n#Databricks #GenieZeroOps #Observabilidade\n","permalink":"https://wiliamrosa.github.io/posts/databricks-genie-zeroops-agente-autonomo/","summary":"Genie ZeroOps promete monitorar, investigar e propor correção pra pipelines, jobs e tabelas sozinho. O Databricks MVP Hubert Dudek testou em preview com três cenários reais de falha.","title":"Genie ZeroOps: um agente que conserta seu pipeline antes de alguém reclamar"},{"content":"A Databricks acabou de detalhar por que colocou object storage embaixo de um banco Postgres transacional, e a resposta não é sobre velocidade.\nO Lakebase separa compute de armazenamento, com a fonte de verdade vivendo em object storage. Isso muda o motivo de existir de um OLTP: deixa de ser só \u0026ldquo;banco para aplicação\u0026rdquo; e vira infraestrutura pensada para agentes que criam, clonam e derrubam bancos em segundos.\nO que isso destrava na prática:\nGovernança única via Unity Catalog, sem uma segunda camada de permissão só pro banco operacional Branch de banco como operação de rotina, não projeto de infraestrutura Agente decide provisionar/descartar ambiente sozinho, sem esperar um humano Minha ressalva: bancos transacionais não perdoam latência de I/O. A Databricks ainda não publicou latência p99 sob concorrência real, é o primeiro benchmark que eu pediria antes de colocar carga crítica em cima disso.\nFonte: https://www.databricks.com/blog/object-storage-wal-lakebase-postgres-agentic-era\n#Databricks #Lakebase #EngenhariaDeDados\n","permalink":"https://wiliamrosa.github.io/posts/linkedin-lakebase-postgres-object-storage/","summary":"A resposta não é sobre velocidade: é sobre onde fica a fonte da verdade quando quem opera o banco pode ser um agente, não um humano.","title":"Por que o Lakebase colocou object storage embaixo de um Postgres transacional"},{"content":"O que a Databricks anunciou A Databricks publicou um artigo detalhando a arquitetura por trás do Lakebase Postgres, seu banco de dados transacional serverless. A pergunta que abre o material é direta: faz sentido colocar object storage embaixo de um banco transacional? A resposta da engenharia da Databricks é que sim, e que o lugar onde você posiciona a fonte da verdade dos dados importa mais do que a velocidade bruta do object store em si.\nA tese central é que um Postgres construído dessa forma deixa de ser só \u0026ldquo;mais um OLTP\u0026rdquo; e passa a ser uma evolução pensada para cargas de trabalho agênticas: agentes que criam bancos, fazem branch de dados, escrevem e leem em padrões muito mais imprevisíveis do que uma aplicação tradicional com tráfego humano.\nFonte original: post da Databricks no LinkedIn\nPor que isso importa na prática Quem trabalha com Unity Catalog e Lakehouse no dia a dia sabe que historicamente sempre existiu uma fronteira nítida entre o mundo analítico (Delta Lake, object storage, processamento em lote/streaming) e o mundo transacional (bancos OLTP tradicionais, geralmente fora do Lakehouse, com sua própria governança). Essa fronteira gera duplicação de dados, pipelines de sincronização e, o pior, dois sistemas de governança para manter alinhados.\nSe o Lakebase realmente consegue rodar OLTP com a fonte de verdade em object storage, isso reduz drasticamente a necessidade de mover dados transacionais para fora do Lakehouse só para servir uma aplicação. Unity Catalog passa a governar de ponta a ponta, sem uma segunda camada de permissões para o banco operacional.\nMinha opinião Tecnicamente, separar compute de storage não é novidade, é o que fez o Snowflake ganhar tração no mundo analítico, e é a mesma lógica por trás do Neon Postgres (que a Databricks adquiriu e que aparentemente é a base do Lakebase, como abordo no artigo sobre a entrevista com Nikita Shamgunov). O que muda de fato aqui é o público-alvo: não é mais só analista rodando query pesada, é um agente autônomo decidindo, em tempo de execução, que precisa provisionar um banco, popular com dados e derrubar minutos depois.\nMeu ceticismo saudável fica por conta da promessa de desempenho. Bancos transacionais são implacáveis com latência de I/O, e object storage historicamente não foi desenhado para isso, daí toda a engenharia de camadas de cache e write-ahead log que normalmente entra no meio do caminho. A Databricks não detalhou publicamente números de latência p99 sob concorrência real, e é exatamente isso que eu testaria antes de colocar uma aplicação crítica de produção em cima do Lakebase.\nNa prática, para quem já vive o dia a dia de governança no Unity Catalog, vale acompanhar de perto: se a promessa se confirmar, é uma redução real de complexidade arquitetural para quem constrói aplicações orientadas a agentes sobre o Lakehouse.\nPara saber mais Post original: https://www.databricks.com/blog/object-storage-wal-lakebase-postgres-agentic-era Documentação oficial do Databricks: https://docs.databricks.com/ ","permalink":"https://wiliamrosa.github.io/posts/databricks-lakebase-postgres-arquitetura-agentes/","summary":"A Databricks anunciou os detalhes de arquitetura do Lakebase Postgres. Minha leitura sobre por que separar compute e armazenamento pode ser o passo que faltava para bancos operacionais aguentarem cargas geradas por agentes.","title":"Lakebase Postgres: por que o banco transacional da era dos agentes começa pelo object storage"},{"content":"Meu livro Machine Learning Prático com Python, Da Exploração de Dados ao Deploy de Modelos, já está disponível para aquisição.\nO livro percorre todo o ciclo prático de um projeto de Machine Learning: exploração e preparação de dados, construção e avaliação de modelos, e o caminho até o deploy em produção.\nO que você encontra no livro Conteúdo prático usando as principais ferramentas do ecossistema Python de dados:\nNumPy e Pandas para manipulação e análise de dados Matplotlib e Seaborn para visualização scikit-learn para construção e avaliação de modelos TensorFlow para deep learning Do exploratório à curva ROC e métricas de avaliação, até o deploy de modelos Onde encontrar 📗 clubedeautores.com.br/livro/machine-learning-pratico-com-python\nSe fizer sentido pra você, depois me conta o que achou 🙌\n","permalink":"https://wiliamrosa.github.io/posts/livro-machine-learning-pratico-com-python/","summary":"Meu livro Machine Learning Prático com Python já está disponível: da exploração de dados ao deploy de modelos, com NumPy, Pandas, Matplotlib, Seaborn, scikit-learn e TensorFlow.","title":"📖 Livro: Machine Learning Prático com Python"},{"content":"Meu livro Lakehouse Engineering com Databricks, Certificação, Arquitetura e Casos Reais, já está disponível para aquisição, em eBook e impresso.\nEste livro foi pensado para compartilhar, de forma prática e direta, como construímos soluções modernas com Databricks no dia a dia, alinhado aos conhecimentos exigidos como base para o exame de certificação Databricks Certified Data Engineer Associate.\nFico extremamente satisfeito em poder contribuir com engenheiros de dados, arquitetos e toda a comunidade que vem crescendo e se fortalecendo cada vez mais no Brasil.\nEsse material nasceu a partir de anos de estudo, prática e experiência em projetos reais, com o objetivo de compartilhar conhecimento aplicado e relevante para quem atua ou deseja atuar com engenharia de dados moderna.\nO que você encontra no livro Construa pipelines modernos com Spark, Delta Lake, Unity Catalog e arquiteturas reais em produção.\nOnde encontrar 📱 eBook (Amazon): amazon.com.br/dp/B0DTJCBG46 📗 Impresso (Clube de Autores): clubedeautores.com.br/livro/lakehouse-engineering-com-databricks E tem um detalhe especial 👇\nO eBook está no programa KDP Select, ou seja: quem possui o plano Amazon Kindle Unlimited poderá acessar e ler o conteúdo sem custo adicional, diretamente pela plataforma.\nSe fizer sentido pra você, depois me conta o que achou 🙌\n","permalink":"https://wiliamrosa.github.io/posts/livro-lakehouse-engineering-com-databricks/","summary":"Meu livro Lakehouse Engineering com Databricks já está disponível em eBook e impresso: pipelines modernos com Spark, Delta Lake e Unity Catalog, alinhado ao exame Databricks Certified Data Engineer Associate.","title":"📖 Livro: Lakehouse Engineering com Databricks"},{"content":"Top 5 Global Project DAIS 2026 Community Virtual Contest\nEstou muito feliz em compartilhar que meu projeto Governance RiskOps Agent for Unity Catalog foi reconhecido entre os Top 5 projetos do mundo no DAIS 2026 Community Virtual Contest, evento oficial da Databricks em San Francisco.\nO projeto O projeto nasceu da minha experiência prática ajudando organizações a transformar logs de auditoria do Unity Catalog em ações concretas de governança e segurança através de análise automatizada de riscos.\nNome: Governance RiskOps Agent for Unity Catalog O que faz: transforma logs de auditoria do Unity Catalog em insights acionáveis de governança e segurança Construído com: Databricks Free Edition Reflexão Como profissional brasileiro, é uma enorme satisfação ver um projeto desenvolvido por mim sendo reconhecido em uma competição global da comunidade Databricks e poder colocar nossa bandeira no topo.\nObrigado à equipe da Databricks, aos avaliadores, Emma Stowell, Stefan Bjelcevic, Mohan Mathews, Sean Ludera e Anshu Roy, e a todos que apoiam nossa jornada.\nSeguimos construindo. 🚀🇧🇷\n","permalink":"https://wiliamrosa.github.io/posts/top-5-global-project-dais-2026-governance-riskops-agent/","summary":"Meu projeto Governance RiskOps Agent for Unity Catalog foi reconhecido entre os Top 5 do mundo no DAIS 2026 Community Virtual Contest, evento oficial da Databricks em San Francisco.","title":"🏆 Top 5 Global Project no DAIS 2026 Community Virtual Contest"},{"content":"Muito feliz em receber o reconhecimento como Databricks User Group Organizer 2026!\nConstruir comunidade vai muito além de organizar eventos. É criar um espaço onde pessoas possam se conectar, compartilhar experiências, aprender umas com as outras e, principalmente, crescer juntas.\nReceber este badge como organizador oficial do São Paulo Databricks User Group é motivo de muito orgulho, mas também um incentivo para continuar fazendo mais: novos encontros, novas conexões, mais conteúdo e mais oportunidades para a nossa comunidade.\nMeu agradecimento à Databricks, à Elizabeth Sapiro Santor, ao meu amigo e também líder de comunidade Nilton Kazuyuki Ueda e a todos que apoiam e participam da comunidade. 💗\nE seguimos! Tem muita coisa boa ainda por vir.\n🔗 São Paulo Databricks User Group\n#Databricks #DatabricksCommunity #DataAI #DataEngineering #Lakehouse #Community #SãoPaulo\n","permalink":"https://wiliamrosa.github.io/posts/databricks-user-group-organizer-2026/","summary":"Recebi o reconhecimento oficial da Databricks como User Group Organizer 2026, pelo trabalho como líder do São Paulo Databricks User Group.","title":"🎖️ Reconhecimento como Databricks User Group Organizer 2026"},{"content":"É com grande alegria que venho compartilhar que fui aprovado no exame Databricks Data Engineer Associate (DP-750), voltado para engenharia de dados no ecossistema Azure com foco em Azure Databricks.\nUm agradecimento especial ao Sidney Cirqueira, que me incentivou a encarar esse desafio, mesmo o exame ainda estando em beta.\nAgora é seguir estudando, compartilhando conhecimento com a comunidade e aplicando esse aprendizado para desenvolver soluções de dados cada vez mais eficientes.\n#Microsoft #AzureDatabricks #Databricks #DataEngineering #Lakehouse #DeltaLake #UnityCatalog #DataPlatform #MicrosoftLearning\n","permalink":"https://wiliamrosa.github.io/posts/certificacao-dp-750-azure-databricks-data-engineer-associate/","summary":"Fui aprovado no exame Databricks Data Engineer Associate (DP-750), voltado para engenharia de dados no ecossistema Azure com foco em Azure Databricks.","title":"✅ Aprovado no exame DP-750: Azure Databricks Data Engineer Associate"},{"content":"📅 23 a 25 de setembro de 2026 · 📍 Pro Magno, São Paulo\nA programação do TDC São Paulo 2026 já está no ar, e este ano vou atuar como coordenador da trilha DataScience e Analytics, no dia 24 de setembro, ao lado de:\nErika Nagamine (AWS) Felipe Teodoro (Kaqui Tecnologia) Lia Yumi Morimoto (Nubank) Coordenar uma trilha significa ajudar a montar uma programação cheia de conteúdo de qualidade sobre dados e analytics, curando palestras e conectando a comunidade com quem está construindo essas soluções no dia a dia.\nSe você trabalha ou está estudando Dados, Analytics ou IA, é uma ótima oportunidade para conferir a programação, fazer networking e trocar experiências pessoalmente.\nSobre o TDC São Paulo Tecnologia conecta, pessoas transformam.\nProgramação e inscrições 👉 Página oficial do evento\nNos vemos no TDC São Paulo! 🚀\n","permalink":"https://wiliamrosa.github.io/events/tdc-sao-paulo-2026-datascience-analytics/","summary":"Vou atuar como coordenador da trilha DataScience e Analytics no TDC São Paulo 2026, dia 24 de setembro, ao lado de Erika Nagamine, Felipe Teodoro e Lia Yumi Morimoto.","title":"🎤 TDC São Paulo 2026 | Coordenador da trilha DataScience e Analytics"},{"content":"📅 02 de setembro de 2026 · ⏰ 18h (BRT) · 💻 Evento online\nNo dia 02 de setembro, às 18h (BRT), teremos um encontro especial no São Paulo Databricks User Group!\nDesta vez vamos receber Matheus Domingos, Solutions Architect na Databricks, na Netherlands, e também um dos líderes do Eindhoven Databricks User Group, falando sobre:\nOs sabores do Genie:\nGenie Code Genie One Genie Agents Genie ZeroOps Mas o encontro não será apenas técnico.\n🌍 Também vamos conversar sobre carreira internacional: a jornada do Matheus, os desafios de construir uma carreira fora do Brasil, trabalhar com tecnologia na Europa e sua experiência hoje como Solutions Architect na Databricks.\nSerá uma ótima oportunidade para trocar experiências, fazer perguntas e aproximar ainda mais as comunidades Databricks do Brasil 🇧🇷 e de Eindhoven 🇳🇱.\nInscreva-se 👉 Inscrição no evento\nParticipe das comunidades 🔴 São Paulo Databricks User Group 🔴 Eindhoven Databricks User Group (liderado pelo Matheus Domingos) Nos vemos no Café com Databricks! ☕\n","permalink":"https://wiliamrosa.github.io/events/cafe-com-databricks-genie-carreira-internacional/","summary":"Encontro online do São Paulo Databricks User Group com Matheus Domingos, Solutions Architect na Databricks (Netherlands) e líder do Eindhoven Databricks User Group, sobre os sabores do Genie e carreira internacional.","title":"☕ Café com Databricks | Os sabores do Genie + Carreira Internacional 🌍"},{"content":"Introdução Recentemente conquistei a certificação Microsoft Certified: Azure Databricks Data Engineer Associate, somando-se às minhas credenciais como Databricks Certified Machine Learning Professional e Microsoft Certified Trainer (MCT). Neste primeiro post quero compartilhar como foi essa jornada de estudos, os principais aprendizados e por que decidi começar a documentar publicamente meu trabalho com dados, algo que já faço como líder do São Paulo Databricks User Group e palestrante no TDC, mas que até agora não tinha um espaço próprio.\nPor que essa certificação Já atuava com Databricks no dia a dia, como Databricks Certified Machine Learning Professional, líder do São Paulo Databricks User Group e MCT, mas boa parte do meu trabalho real acontece especificamente na integração entre Databricks e Azure: Unity Catalog governando dados que vivem no Azure Data Lake Storage, autenticação via Microsoft Entra ID, segredos no Key Vault, monitoramento pelo Azure Monitor. O DP-750 é a certificação que valida exatamente essa combinação, e como meu objetivo é contribuir cada vez mais com a comunidade Microsoft, fazia sentido formalizar esse conhecimento com uma credencial oficial da própria Microsoft, e não só da Databricks.\nComo me preparei Como já vinha da prática diária com a plataforma, o estudo foi mais um processo de mapear lacunas e formalizar conceitos do que aprender do zero:\nRevisão do Study Guide oficial da Microsoft Learn para o DP-750, objetivo por objetivo. Prática hands-on no Databricks Free Edition, recriando cenários de governança no Unity Catalog, pipelines com Lakeflow Jobs e Lakeflow Declarative Pipelines, e ingestão com Auto Loader. Revisão profunda de otimização em Delta Lake: OPTIMIZE, VACUUM, Z-ORDER, leitura de Spark UI e DAGs, e Adaptive Query Execution (AQE), tópicos que pesam bastante na prova. Estudo dos pontos de integração com Azure: ADLS, Key Vault, Microsoft Entra ID e Azure Monitor. Principais tópicos do exame O exame é fortemente prático e cobre principalmente:\nUnity Catalog: governança, permissões e linhagem de dados. Delta Lake: internals, otimização de performance (OPTIMIZE, VACUUM, Z-ORDER) e MERGE/upserts. Lakeflow Jobs e Lakeflow Spark Declarative Pipelines: orquestração e pipelines declarativos de produção. Auto Loader: ingestão incremental de dados. Databricks Asset Bundles: deploy e CI/CD de projetos Databricks. Integrações Azure: Azure Data Lake Storage, Key Vault, Microsoft Entra ID e Azure Monitor. Vale destacar: os domínios de construção e deploy de pipelines de dados concentram a maior parte da prova, então mais importante que decorar conceito é ter mão na massa.\nO que mais me surpreendeu O quanto o exame é cenário-based e não teórico: em vez de perguntar \u0026ldquo;o que é o Unity Catalog\u0026rdquo;, ele coloca um problema real de governança ou de pipeline quebrando em produção e pede a melhor solução. Também me chamou atenção o peso dado a Databricks Asset Bundles, um sinal claro de que a maturidade de Databricks no Azure já é tratada como engenharia de software de verdade, com CI/CD, e não só como notebooks avulsos.\nPróximos passos A partir de agora pretendo publicar regularmente sobre Azure Databricks e Data Platform, compartilhando tanto conteúdo técnico (arquitetura, otimização, boas práticas) quanto opiniões sobre o ecossistema de dados. Se você trabalha ou está estudando a mesma área, me siga e vamos trocar experiências.\n","permalink":"https://wiliamrosa.github.io/posts/minha-jornada-azure-databricks-data-engineer/","summary":"Como me preparei para a certificação, o que mais me surpreendeu no exame e por que decidi documentar publicamente minha jornada em dados.","title":"Minha jornada até a certificação Azure Databricks Data Engineer Associate"},{"content":"Vector Search no Databricks parou de ser uma escolha única e virou uma decisão de arquitetura com três caminhos possíveis.\nO Databricks MVP Laurenz Wuttke mapeou as opções que existem hoje pra guardar e buscar embedding na plataforma. A primeira é o AI Search (antigo Vector Search): índice gerenciado sobre uma tabela Delta, sincronização automática quando o dado muda, busca híbrida combinando vetor e palavra-chave, tudo consultável direto via SQL pela função vector_search(), serverless e de baixa latência, pensado pra caso de uso de RAG ou agente em produção.\nA segunda opção é nova: o Lakebase, o Postgres operacional do Databricks, agora suporta pgvector por completo, e ganhou em beta o lakebase_vector, uma busca ANN própria compatível com pgvector mas bem mais econômica em uso de memória. Faz sentido quando o embedding já precisa morar onde a aplicação já está escrevendo, como memória de agente ou feature serving. A terceira opção é a mais simples: calcular embedding em lote via ai_query() sobre a tabela inteira, guardar como array numa tabela Delta e resolver similaridade direto com função SQL, sem índice nem endpoint, ideal pra job periódico que não precisa rodar em tempo real.\nO que muda na prática entre as três:\nAI Search entrega menor latência e sincronização automática, mas exige manter um índice gerenciado separado lakebase_vector (Beta) faz sentido quando o embedding já vive no mesmo lugar que grava dado operacional, evitando duplicar armazenamento A variante em batch via SQL dispensa índice e endpoint, mas não serve pra consulta em tempo real Minhas considerações: a pergunta certa deixou de ser \u0026ldquo;qual vector store usar\u0026rdquo; e virou \u0026ldquo;qual dessas três opções combina com o padrão de escrita e leitura que eu já tenho\u0026rdquo;. Quem está construindo agente com memória persistente ganha mais testando o lakebase_vector, ainda em beta, do que forçando tudo pelo AI Search só porque é a opção mais conhecida.\nFonte: https://www.linkedin.com/in/laurenz-wuttke/\n#Databricks #Lakebase #VectorSearch\n","permalink":"https://wiliamrosa.github.io/posts/databricks-vector-store-tres-opcoes/","summary":"AI Search, o novo lakebase_vector em beta e a variante em batch via SQL resolvem o mesmo problema, guardar e buscar embedding, de formas bem diferentes.","title":"Vector Store no Databricks virou três produtos diferentes, e escolher errado sai caro"},{"content":"Genie Code deixou de ser só uma conversa que você inicia manualmente e virou um tipo de tarefa dentro de um Job do Databricks.\nO Databricks MVP Derar Alhussein destacou a novidade assim que ela saiu: o Genie Code task inicia um novo chat a partir de um prompt em linguagem natural e produz uma resposta sozinho, lendo dado, chamando ferramenta e agindo sobre o pedido sem exigir aprovação adicional durante a execução. Depois que o job termina, ainda dá pra abrir o chat e continuar interagindo com o histórico daquela execução.\nO caso de uso central é automação de análise complexa dentro de uma rotina agendada: resumir o resultado de jobs que rodaram de madrugada e mandar um relatório por e-mail, analisar dado novo e sinalizar anomalia, investigar um ticket do Jira e propor correção, gerar auditoria de compliance semanal. Como é sempre auto-aprovado dentro de um job, o Databricks compensa isso com um classificador de IA que avalia cada ação contra o prompt original e bloqueia operação que sai do escopo pretendido.\nPontos técnicos que valem registrar:\nAuto-aprovação é sempre ligada em tarefa de job, não é uma opção, é o comportamento padrão Um classificador de IA (não uma barreira determinística) decide o que conta como ação arriscada demais pro escopo do prompt Recurso ainda em Beta, admin de workspace controla o acesso pela página de Previews Minha ressalva: já escrevi aqui antes sobre o modo de auto-aprovação do Genie Code fora de job, e a mesma ressalva vale, e pesa mais dentro de uma automação agendada: quem decide o que é \u0026ldquo;arriscado\u0026rdquo; é um classificador de IA, não uma regra fixa e auditável. Rodando dentro de um job que ninguém está acompanhando ao vivo, esse é exatamente o tipo de cenário em que um falso negativo do classificador passa despercebido até o relatório final chegar errado na caixa de entrada de alguém.\nFonte: https://docs.databricks.com/aws/en/jobs/tasks/genie-code\n#Databricks #GenieCode #Automação\n","permalink":"https://wiliamrosa.github.io/posts/databricks-genie-code-task-jobs/","summary":"O novo Genie Code task type deixa rodar um agente autônomo dentro de um job agendado, a partir de um prompt em linguagem natural e com auto-aprovação sempre ligada.","title":"Genie Code virou um tipo de tarefa dentro de Job, e roda sozinho, sem parar pra perguntar nada"},{"content":"Conectividade privada pro serverless do Azure Databricks até aqui era recurso por recurso, um Private Endpoint de cada vez.\nO Databricks MVP Daniel Sahal chamou atenção pro Private Network Gateway logo na semana em que entrou em preview privado: uma opção nova pra quando o serverless precisa alcançar API interna, banco de dado, sistema on-premises ou passar pelo próprio firewall da empresa, em vez de só alcançar um recurso específico de nuvem de forma privada.\nO mecanismo funciona delegando uma sub-rede da sua VNet pro Azure Databricks: o compute serverless passa a alcançar tudo que essa sub-rede alcança, incluindo rede conectada transitivamente via ExpressRoute ou VPN, como sistema on-premises. Ele não substitui Private Link, complementa: use Private Endpoint pra conexão privada direta com um recurso específico gerenciado na nuvem (como object storage), e use o gateway quando o objetivo for alcançar toda a rede, rotear egresso por appliance de segurança próprio, ou garantir IP de origem estável pra permitir allowlist em ambiente multi-tenant.\nDetalhes técnicos que valem nota:\nDois modos de tráfego: SPECIFIC_DESTINATIONS (roteia só os destinos listados) ou ALL_TRAFFIC (roteia todo egresso serverless pelo gateway) Regra de Private Link sempre tem prioridade: se existir Private Endpoint pra um recurso, o tráfego usa ele em vez do gateway, mesmo em modo ALL_TRAFFIC Limite durante o preview: uma NCC suporta no máximo dois gateways, e cada gateway suporta até dois resolvedores DNS e cem destinos Configuração hoje é só via API REST de conta, sem suporte de UI ou Terraform ainda Minha ressalva: ainda está em Private Preview e, segundo a própria documentação, não é cobrado agora mas vai ser cobrado no futuro, o que muda o cálculo de quem for adotar cedo. Além disso, sem suporte a Terraform ainda, quem já trata toda a infraestrutura de rede como código vai ter que abrir uma exceção manual via API pra esse pedaço específico, ao menos até o recurso amadurecer.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/security/network/serverless-network-security/private-network-gateway\n#AzureDatabricks #Serverless #Rede\n","permalink":"https://wiliamrosa.github.io/posts/azure-databricks-private-network-gateway-serverless/","summary":"Private Network Gateway conecta compute serverless a toda a VNet (e redes conectadas via ExpressRoute ou VPN) através de um único gateway gerenciado, complementando em vez de substituir os Private Endpoints.","title":"Serverless do Azure Databricks ganha um jeito de chegar na sua rede inteira, não só num recurso por vez"},{"content":"Faltava um lugar só pra enxergar governança no Databricks, e agora existe.\nO Databricks MVP Daniel Sahal apontou o Governance Hub assim que ele apareceu: até aqui, entender cobertura de dado, uso e gasto com IA, principais fontes de custo e tag faltando exigia navegar entre abas diferentes, system tables separadas e telas de administração distintas, o que fica difícil de acompanhar em ambiente grande.\nO Governance Hub é uma UI no nível de conta (não de workspace) organizada em quatro páginas: Data (acesso a objeto, uso de ativo, tags governadas, classificação e qualidade de dado), AI (uso de token, orçamento, atividade por modelo e usuário), Cost (fonte de custo, orçamento, cobertura de tag e recomendações) e Tags (atribuições recentes e lacunas de cobertura). Um admin de conta ativa a funcionalidade pela página de Previews do console de conta, e os dados levam até um dia pra carregar depois disso.\nDetalhes técnicos que valem nota:\nNão introduz permissão nova: cada pessoa vê só o que já tinha acesso via Unity Catalog Admin de workspace vê a página de Cost só dos workspaces que administra Admin de metastore vê a página de Data só dos metastores que administra Não substitui Unity Catalog nem orçamentos existentes, é uma camada de visão consolidada por cima do que já existe Minha ressalva: ainda está em Beta, e \u0026ldquo;uma tela só pra tudo\u0026rdquo; tem um risco embutido: vira o ponto de referência padrão do time mesmo antes de a cobertura de dado estar completa ou o cálculo de custo estar totalmente ajustado. Eu trataria os números do Governance Hub como direção, não como verdade absoluta, até a funcionalidade sair de Beta e a Databricks confirmar paridade completa com as fontes originais que ele está resumindo.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/admin/governance-hub/\n#Databricks #Governança #UnityCatalog\n","permalink":"https://wiliamrosa.github.io/posts/databricks-governance-hub-beta/","summary":"Governance Hub (Beta) é uma visão no nível de conta que reúne saúde de dado, gasto e uso de IA, e recomendações de custo num só lugar, sem substituir Unity Catalog ou orçamentos existentes.","title":"Governance Hub junta dado, IA e custo numa tela só, e ainda faltava exatamente isso"},{"content":"Escolher onde hospedar um agente de IA no Databricks parece detalhe de infraestrutura, mas na prática decide se o agente roda até o fim ou morre no meio de uma tarefa longa.\nO Databricks MVP Shashank Shekhar resumiu um dilema que quem constrói agente em produção acaba enfrentando cedo ou tarde: usar Databricks Apps ou Model Serving como camada de hospedagem, e por que a resposta certa muda conforme o tipo de carga de trabalho.\nModel Serving nasceu para servir modelo de ML clássico, com escalonamento a zero quando ocioso e cobrança por uso, mas isso vem com um teto de execução em torno de dez minutos por requisição. Um agente que faz raciocínio em múltiplos passos, chama ferramenta externa ou espera resposta de LLM mais lento pode facilmente estourar essa janela. Databricks Apps, por outro lado, roda como servidor persistente, sem esse limite de tempo, só que cobra por hora enquanto estiver ligado, mesmo ocioso, o que inverte a equação de custo pra quem tem tráfego baixo ou picos irregulares.\nPontos técnicos que valem registrar:\nDatabricks Apps é a opção recomendada pela Databricks para hospedar agente novo, por rodar como servidor persistente Model Serving impõe um timeout de aproximadamente dez minutos por requisição, um limite real para agente com execução longa Model Serving escala a zero e cobra só pelo uso, enquanto Databricks Apps tem custo por hora mesmo com baixo tráfego Serverless Micro Apps, ainda não disponível, promete resolver esse trade-off de custo ocioso no futuro Minhas considerações: esse tipo de decisão de arquitetura costuma ficar invisível até o agente falhar em produção por timeout, e nesse ponto já é tarde para descobrir que a escolha de hospedagem estava errada desde o início. Recomendo tratar isso como parte do desenho técnico logo na primeira reunião de arquitetura do projeto, não como ajuste de última hora: se o agente tem passo longo ou espera de ferramenta externa, Databricks Apps evita dor de cabeça, mas exige monitorar custo ocioso até que Serverless Micro Apps chegue.\nFonte: https://www.linkedin.com/in/ishashankshekhar/#databricks-apps-vs-model-serving-agentes\n#Databricks #AgentesIA #Arquitetura\n","permalink":"https://wiliamrosa.github.io/posts/databricks-apps-model-serving-agentes-ia/","summary":"Databricks Apps virou o host recomendado pra agente novo, mas Model Serving ainda vence em cenário de baixo custo e alta escala, e a diferença de timeout entre os dois muda qual opção funciona pra que tipo de agente.","title":"Databricks Apps ou Model Serving pra hospedar seu agente? A resposta depende de três coisas"},{"content":"A Databricks passou a permitir restringir o segredo OAuth de um service principal a escopos de API específicos, em vez de deixar cada segredo valer para qualquer API da conta.\nO problema que isso resolve é conhecido de quem já lidou com incidente de segredo vazado: historicamente, um segredo OAuth de service principal dava acesso a tudo que aquela identidade tinha permissão de fazer, API de SQL, de jobs, de cluster, todas juntas atrás do mesmo segredo. Agora é possível emitir um segredo já limitado a um escopo, como sql ou jobs, e qualquer token gerado a partir desse segredo carrega essa mesma limitação, não importa o que o service principal tenha de permissão em outros lugares. Na prática, isso separa \u0026ldquo;o que o service principal pode fazer\u0026rdquo; de \u0026ldquo;o que esse segredo específico pode fazer\u0026rdquo;, e são duas coisas diferentes agora.\nOnde isso muda o cálculo de risco:\nUm segredo vazado com escopo sql não vira porta de entrada pra disparar job ou mexer em cluster, mesmo que o service principal tenha essas permissões Isso incentiva o padrão de emitir um segredo por integração, com escopo mínimo necessário pra aquela integração específica, em vez de um segredo genérico reaproveitado em vários lugares Reduz o raio de explosão de um pipeline de CI/CD comprometido, que normalmente usa um único segredo pra tudo que precisa automatizar Minhas considerações: essa é o tipo de feature de segurança que só entrega valor se alguém de fato for revisar os segredos já existentes e recriá-los com escopo restrito, porque segredo antigo continua com acesso total até ser trocado. Recomendo tratar isso como gatilho pra um inventário de segredos de service principal ativos hoje, não só como opção disponível pra segredo novo daqui pra frente.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/dev-tools/auth/oauth-m2m\n#Databricks #Segurança\n","permalink":"https://wiliamrosa.github.io/posts/oauth-secrets-escopo-service-principal/","summary":"Agora dá pra restringir o segredo OAuth de um service principal a escopos de API específicos, como sql ou jobs, em vez de liberar acesso total. Um token gerado por segredo restrito não consegue ultrapassar esses escopos.","title":"Segredo OAuth vazado agora pode ter dano limitado por escopo de API"},{"content":"Genie One deixou de ser só um chat que responde pergunta e virou lugar de escrever documento em conjunto com o resto do time.\nO app nativo pra macOS dessa mesma leva de novidades já foi coberto aqui antes, então esse post foca no restante do pacote que a Databricks lançou pro Genie One. A peça mais robusta é a colaboração em documento, rascunhar, editar e revisar relatório com visualização de dado ao vivo embutida, com histórico de versão, comentário, link de compartilhamento somente leitura e exportação em PDF.\nOutras funcionalidades também chegam nessa leva. Dá pra transformar uma conversa curada em Genie Agent reutilizável, com o contexto da conversa virando a base do agente, e compartilhar esse agente com o time, desde que quem for usar tenha acesso ao workspace e ao SQL envolvido. Também é possível compartilhar um chat inteiro, com pergunta, resposta e visualização preservadas, e subir arquivo direto na conversa, CSV, Excel, PDF, imagem ou Word, mantido privado àquela conversa específica.\nPontos técnicos que valem atenção:\nColaboração em documento com versionamento e comentário, pensado pra relatório vivo em vez de export estático Criação de agente a partir de conversa, reaproveitando contexto já validado pelo usuário Compartilhamento de chat somente leitura pra qualquer usuário da conta Genie Ontology Snippets, que integra Metric Views, Domains e Pages, com extração automática de regra de negócio a partir de dashboard, SQL e agente existente, respeitando a permissão da fonte original Upload de arquivo (CSV, Excel, PDF, imagem, Word) restrito à conversa Ações de escrita via MCP, permitindo o agente escrever de volta em sistema externo, tudo governado pelo Unity AI Gateway Minha ressalva: ação de escrita via MCP governada pelo gateway é a peça mais poderosa e também a mais arriscada desse pacote, porque agente que escreve de volta em ticket, documento ou e-mail externo exige revisão de política bem mais rígida do que agente que só lê e responde. Vale revisar essa política antes de liberar write action em produção pra qualquer time.\nFonte: https://www.databricks.com/blog/beyond-answers-new-genie-one-features-turn-insights-action\n#Databricks #GenieOne #IAGenerativa\n","permalink":"https://wiliamrosa.github.io/posts/genie-one-colaboracao-documentos-mcp-write/","summary":"A Databricks lançou um pacote de novidades pro Genie One além do app nativo pra macOS já coberto aqui antes: colaboração em documento com versionamento, criação de agente a partir de conversa, compartilhamento de chat, upload de arquivo e ações de escrita via MCP governadas pelo Unity AI Gateway.","title":"Genie One virou lugar de escrever relatório em conjunto, não só de perguntar"},{"content":"Falha de região inteira é um cenário diferente de falha de zona de disponibilidade, e até agora o Lakebase não tinha resposta pra isso.\nO Databricks MVP Mani Kandasamy apontou o Lakebase Disaster Recovery como um dos lançamentos que mais valeu acompanhar depois do Data + AI Summit, junto com Genie Ontology e Lakehouse//RT. A funcionalidade replica os dados do seu projeto pra um workspace secundário numa região diferente, protegendo contra falha completa de região (incluindo apagão), não só falha de máquina isolada ou de zona de disponibilidade.\nO mecanismo replica metadado do Unity Catalog, dado de tabela gerenciada e ativos de workspace de forma contínua, mantém uma URL estável que sobrevive ao failover, e permite disparar o failover manualmente pelo console de conta. Durante o Private Preview, a disponibilidade é restrita a replicação entre regiões só na AWS, e a própria documentação é explícita: não é recomendado pra uso em produção enquanto estiver nessa fase.\nLimitações que valem registrar antes de considerar adotar:\nTabelas sincronizadas (synced tables) e pipelines de Lakebase CDF terminam no failover e não retomam automaticamente depois Dado Delta não é replicado, o disaster recovery do Lakebase não cobre Delta table Só cross-region na AWS durante o preview, sem confirmação ainda de quando chega no Azure Minha ressalva: disaster recovery que não cobre Delta table nem retoma pipeline de sincronização sozinho ainda deixa um bocado de trabalho manual pro time de operação no momento em que mais precisa de automação, que é logo depois de uma região inteira cair. Vale acompanhar como isso evolui até a disponibilidade geral, mas por enquanto eu trataria como proteção parcial, não como plano de disaster recovery completo pronto pra depender dele sozinho.\nFonte: https://docs.databricks.com/aws/en/oltp/projects/disaster-recovery\n#Databricks #Lakebase #DisasterRecovery\n","permalink":"https://wiliamrosa.github.io/posts/databricks-lakebase-disaster-recovery-preview/","summary":"Lakebase Disaster Recovery replica metadado do Unity Catalog, dado de tabela gerenciada e ativos de workspace pra uma região secundária, mas Delta table e pipelines de sincronização ficam fora da replicação por enquanto.","title":"Lakebase ganha disaster recovery entre regiões, mas ainda deixa Delta table de fora"},{"content":"Um job de ingestão que só devia inserir linha, mas também podia apagar tabela inteira: essa era a realidade de anos de MODIFY no Unity Catalog.\nA Databricks MVP Gavita Regunath destacou uma mudança pequena na superfície, mas com impacto real em quem administra permissão de escrita no Unity Catalog: o privilégio MODIFY, que por anos era tudo ou nada, ganhou privilégios filhos separados, INSERT, UPDATE e DELETE.\nAntes, conceder MODIFY para um job de ingestão significava dar a ele o poder de inserir linha, mas também de apagar coluna, truncar tabela ou reescrever schema inteiro, porque o Unity Catalog não distinguia esses casos. Com a mudança, dá pra conceder só o verbo que aquele workload realmente usa: um loader que só faz append recebe SELECT e INSERT e mais nada, e se algum dia tentar um DELETE ou um ALTER TABLE, a resposta vem como PERMISSION_DENIED em vez de suceder silenciosamente.\nPontos técnicos que valem registrar:\nMODIFY continua existindo, mas agora atua como agrupador dos três privilégios filhos INSERT, UPDATE e DELETE podem ser concedidos individualmente, sem liberar os outros dois Job de ingestão append-only passa a operar com o mínimo privilégio necessário, sem depender de disciplina manual pra não usar poder que não precisa Tentativa de operação fora do escopo concedido falha com PERMISSION_DENIED, não passa despercebida Minhas considerações: esse é o tipo de mudança que não aparece em keynote, mas resolve um problema real de princípio de menor privilégio que toda auditoria de segurança cobra e poucas plataformas realmente entregam no nível certo de granularidade. Vale revisar hoje mesmo quem no seu workspace tem MODIFY concedido só porque era a única opção disponível, e trocar por INSERT, UPDATE ou DELETE conforme o que aquele principal realmente faz.\nFonte: https://dailydatabricks.tips/tips/Unity%20Catalog/FineGrainedDMLPrivileges.html\n#Databricks #UnityCatalog #Governanca\n","permalink":"https://wiliamrosa.github.io/posts/unity-catalog-modify-privilegios-insert-update-delete/","summary":"O privilégio MODIFY do Unity Catalog, antes tudo ou nada, ganhou privilégios filhos separados: INSERT, UPDATE e DELETE podem ser concedidos individualmente, com falha explícita quando um principal tenta operação fora do escopo.","title":"MODIFY deixou de ser um privilégio só, e virou três: INSERT, UPDATE e DELETE"},{"content":"O Databricks MVP Hubert Dudek percebeu, direto na interface, que uma peça nova apareceu para gerenciar skills de agente antes mesmo da documentação oficial confirmar o recurso: Unity Catalog Skills, agora em Beta.\nA ideia central é simples de explicar e difícil de fazer bem: hoje, skill de agente de código vive espalhada, num README aqui, num arquivo de instrução ali, sem dono claro nem controle de quem pode usar o quê. O Unity Catalog Skills trata skill como um securable de três níveis, catalog.schema.skill, seguindo a especificação aberta SKILL.md. Isso significa que você registra a skill uma vez e ganha, de graça, o mesmo modelo de permissão, tag e auditoria que já protege tabela e view no Unity Catalog. Um agente de código pode baixar a skill publicada ou carregá-la em tempo real via MCP, sem precisar embutir instrução fixa no prompt.\nPontos técnicos que valem atenção:\nSkill é um objeto governável, não um arquivo solto, então dá pra restringir quem descobre, usa e atualiza cada skill A referência é a especificação SKILL.md, um formato já usado fora do ecossistema Databricks, o que facilita portar skill entre ferramentas O consumo funciona tanto por download direto quanto por MCP, cobrindo agente batch e agente interativo com o mesmo mecanismo Minhas considerações: faz sentido que skill de agente siga o mesmo caminho que modelo e prompt já seguiram dentro do MLflow, virar ativo organizacional versionado em vez de configuração pessoal espalhada. A pergunta que fica em aberto é operacional: quem no time assume a responsabilidade de manter skill atualizada quando a lógica de negócio muda, porque um catálogo de skills desatualizado é pior do que nenhum catálogo, ele passa confiança que não deveria.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/agents/uc-skills/\n#Databricks #UnityCatalog #Agentes\n","permalink":"https://wiliamrosa.github.io/posts/unity-catalog-skills-beta-agentes/","summary":"Unity Catalog Skills (Beta) trata skill de agente como securable de três níveis, catalog.schema.skill, com as mesmas permissões e tags que já protegem tabela. O Databricks MVP Hubert Dudek notou a mudança antes do anúncio oficial confirmar.","title":"Skill de agente virou um objeto do Unity Catalog, com dono, permissão e auditoria"},{"content":"Workspace criado depois de 30 de setembro de 2026 simplesmente não vai ter Hive metastore pra usar, nem que você queira.\nA Databricks MVP Dilorom Abdullah alertou pra um prazo concreto que muita equipe ainda trata como opcional: a partir de 30 de setembro de 2026, todo workspace novo do Databricks passa a nascer sem acesso a DBFS root, DBFS mounts, Hive metastore ou cluster compartilhado sem isolamento, ficando restrito ao Unity Catalog desde o primeiro dia.\nO risco real não está no workspace que ainda vai ser criado, está no que já existe hoje e depende de Hive metastore sem ninguém perceber. Cluster, notebook, job e metastore externo podem continuar amarrados no Hive metastore legado mesmo depois de uma migração pra Unity Catalog considerada concluída, porque a migração de tabela não garante que toda dependência oculta foi identificada e cortada. Dilorom recomenda tratar isso como decisão de governança, não como tarefa de limpeza: validar dependência antes de desligar acesso legado, em vez de assumir que, se a tabela já está no Unity Catalog, o resto segue automaticamente.\nPontos técnicos que valem registrar:\nA partir de 30 de setembro de 2026, workspace novo nasce Unity-Catalog-only, sem DBFS root, DBFS mounts, Hive metastore nem cluster sem isolamento Workspace existente não é afetado automaticamente, mas a direção geral da plataforma já está definida Dependência oculta em cluster, notebook, job ou metastore externo pode manter o Hive metastore vivo mesmo após a tabela já estar migrada Recomendação prática: validar toda dependência antes de desligar o acesso legado, em vez de confiar só na migração de tabela como sinal de conclusão Minha ressalva: prazo com data fixa tende a ser ignorado até faltar pouco tempo, e migração de metastore raramente é rápida quando aparece dependência escondida que ninguém documentou. Se seu workspace ainda tem qualquer coisa rodando sobre Hive metastore, vale tratar setembro de 2026 como prazo de verdade pra auditar isso agora, não como aviso genérico pra resolver depois.\nFonte: https://blog.dataengineerthings.org/the-hive-metastore-era-is-ending-close-it-on-your-terms-434231670b5c\n#Databricks #UnityCatalog #Governanca\n","permalink":"https://wiliamrosa.github.io/posts/hive-metastore-unity-catalog-only-deadline-setembro-2026/","summary":"A partir de 30 de setembro de 2026, todo workspace novo do Databricks nasce sem DBFS root, DBFS mounts, Hive metastore ou cluster sem isolamento, restrito ao Unity Catalog desde o primeiro dia.","title":"A partir de 30 de setembro, todo workspace novo do Databricks nasce sem Hive metastore"},{"content":"Até aqui, quem precisava auditar uma política de acesso no Unity Catalog tinha só duas opções ruins: ganhar MANAGE (e com isso poder de fato mudar a política) ou não ver nada.\nO MVP Aladdin Alchalabi resumiu um pacote de novidades de agosto do Azure Databricks, e uma delas mereceu destaque isolado: READ METADATA, um privilégio novo que dá visibilidade completa sobre metadado sensível de um objeto sem conceder nem poder de modificação nem acesso ao dado em si.\nO mecanismo é simples de descrever e resolve um problema real de separação de função: READ METADATA é um privilégio filho de MANAGE, mas só de leitura. Quem tem ele enxerga concessão de permissão, row filter, column mask, política ABAC, definição de view e function, e até detalhe de credencial de storage (nome e ID), mas não consegue alterar nada disso nem ler o dado protegido por essas regras. A documentação é explícita sobre pra quem isso foi pensado: auditor de segurança, time de governança de dado, e SRE que precisa depurar controle de acesso sem assumir responsabilidade de administrar ele.\nPontos técnicos que valem registrar:\nAplica-se à maioria dos objetos securáveis: tabela, view, function, volume, credencial de storage e até o metastore É privilégio filho de MANAGE, mas estritamente somente leitura A própria documentação recomenda conceder só a principal de confiança, porque o metadado exposto é sensível por natureza Minhas considerações: esse é um daqueles privilégios pequenos que resolve um atrito organizacional real, não só técnico. Antes dele, dar a alguém poder de auditar governança geralmente significava dar mais poder do que a função exigia, o que empurrava empresa a pular a auditoria por preguiça de gerenciar mais uma permissão ampla. Separar \u0026ldquo;ver a regra\u0026rdquo; de \u0026ldquo;mudar a regra\u0026rdquo; é o tipo de detalhe que só importa quando sua empresa já tem política de acesso complexa o suficiente pra alguém de fora do time técnico precisar confirmar que ela está sendo seguida.\nFonte: https://docs.databricks.com/aws/en/data-governance/unity-catalog/access-control/privileges-reference\n#Databricks #UnityCatalog #Governança\n","permalink":"https://wiliamrosa.github.io/posts/databricks-read-metadata-privilege-auditoria/","summary":"READ METADATA é uma privilégio novo do Unity Catalog: visibilidade completa sobre permissão, row filter, column mask e política ABAC de um objeto, sem poder de leitura de dado nem de alteração.","title":"Agora dá pra auditar política de acesso sem ganhar poder pra mudar ela"},{"content":"O Databricks MVP Hubert Dudek acompanhou de perto a chegada do engine \u0026ldquo;direct\u0026rdquo; nos Declarative Automation Bundles (ex-Databricks Asset Bundles): já é o padrão para bundles criados a partir do workspace desde 13 de agosto de 2026, e vira padrão geral da CLI em 26 de agosto. Segundo ele, quem já testou reporta até 40% de deploy mais rápido, sem depender do provider do Terraform por trás.\nIsso é o desfecho natural de uma mudança que já vinha sendo sinalizada: o engine direct nasceu como substituto drop-in do engine Terraform (que sempre esteve por baixo dos bundles desde o início), e agora a Databricks confirma o suporte ao Terraform como caminho de saída, não mais o padrão.\nPor que isso interessa mesmo pra quem não usa bundle todo dia:\nDeploy mais rápido sem provider externo significa menos dependência de binário/plugin do Terraform no pipeline de CI/CD Quem ainda depende de customização via Terraform provider pode continuar usando (bundle.engine: terraform), mas já recebe aviso de depreciação É o tipo de mudança de infraestrutura interna que geralmente passa despercebida até quebrar um pipeline de CI/CD que ninguém tocava há meses Minha ressalva: migração de engine de deploy é sempre mais arriscada do que parece no changelog. Bundles com customização pesada via provider Terraform (recursos que o engine direct ainda não cobre) merecem um teste completo em ambiente de staging antes da virada de padrão, não vale confiar só no \u0026ldquo;drop-in replacement\u0026rdquo; da documentação sem validar o caso específico do seu pipeline.\nFonte: https://www.sunnydata.ai/blog/databricks-dabs-direct-mode-ga\n#Databricks #DeclarativeAutomationBundles #DevOps\n","permalink":"https://wiliamrosa.github.io/posts/databricks-dabs-direct-mode-ga-terraform/","summary":"O engine \u0026lsquo;direct\u0026rsquo; virou padrão pra bundles criados no workspace desde 13 de agosto, e vira padrão geral da CLI em 26 de agosto. O suporte ao Terraform está no caminho da deprecação.","title":"Direct mode virou padrão nos Databricks Asset Bundles, o Terraform está com os dias contados aqui"},{"content":"Um agente de recuperação quase sempre erra a resposta quando o dado certo está dentro de um gráfico, não de um parágrafo de texto.\nA Databricks lançou uma técnica de enriquecimento pensada exatamente pra esse ponto cego: hoje, RAG tradicional trata gráfico como imagem, ou ignora, ou joga pra um modelo multimodal caro tentar interpretar em tempo de consulta. A proposta aqui inverte a ordem, extrai a estrutura do gráfico uma vez, no momento da indexação, e guarda como JSON.\nO mecanismo usa duas funções SQL nativas em sequência: ai_parse_document identifica e recorta gráfico dentro do PDF ou documento, e ai_prep_search converte esse recorte em JSON estruturado, com eixo, série, valor e legenda explícitos, que entra no índice de busca do Genie junto com o texto ao redor. Na hora da pergunta, o agente recupera o JSON do gráfico como se fosse mais um trecho de texto, sem precisar rodar um modelo de visão pesado toda consulta.\nPontos técnicos que valem atenção:\nTestado em dois benchmarks públicos, ViDoRe V3 (310 perguntas, 7 domínios) e Chart-RAG (114 perguntas, 3 relatórios financeiros) Taxa de acerto de 75,9% e 75,1% respectivamente, superando quatro baselines de embedding multimodal O modelo usado pra extrair é bem menor, na casa de 300M de parâmetros, e a consulta final passa menos imagem pro modelo de resposta Minhas considerações: o ganho aqui não é só de acurácia, é de custo, trocar chamada de modelo multimodal em toda consulta por uma extração feita uma vez na indexação reduz bastante o gasto recorrente. Vale lembrar que o benchmark é da própria Databricks, então taxa de acerto divulgada merece ser validada em dado próprio antes de virar decisão de arquitetura.\nFonte: https://www.databricks.com/blog/enhancing-agent-retrieval-structured-chart-extraction\n#Databricks #Genie #RAG\n","permalink":"https://wiliamrosa.github.io/posts/genie-chart-json-enrichment-ai-parse-document/","summary":"A Databricks publicou uma técnica de enriquecimento que usa ai_parse_document e ai_prep_search pra transformar gráfico dentro de documento em JSON estruturado antes de indexar, e bateu embedding multimodal maior em dois benchmarks públicos.","title":"Genie aprendeu a extrair gráfico de PDF como JSON estruturado antes de responder"},{"content":"O Databricks MVP Geir E. Alstad chamou atenção pra uma mudança que muda o alcance de uma feature que este blog já cobriu antes só dentro do Databricks: Metric Views deixou de ser exclusividade da plataforma hospedada e chegou à versão open source do Apache Spark 4.3 e do Unity Catalog 0.6.\nA mecânica é a mesma já vista no Spark 4.2 dentro do Databricks: você define métrica de negócio uma vez, num arquivo YAML com fonte de dado, join, filtro, dimensão e medida, e a partir daí tanto pessoa quanto agente consultam a mesma definição em vez de cada um recalcular a métrica do seu jeito. A consulta usa a função MEASURE() pra pedir o valor de uma medida já nomeada, por exemplo SELECT MEASURE(Order Count), MEASURE(Total Revenue) FROM orders_metric_view, em vez de reescrever a lógica de agregação a cada relatório. O que muda agora é o alcance: rodando fora do Databricks, em qualquer ambiente Spark 4.3 com Unity Catalog 0.6, a mesma definição de métrica passa a valer pra time que não usa o Databricks hospedado, não só pra quem já está dentro do ecossistema.\nPontos técnicos que valem atenção:\nRequer Apache Spark 4.3 e Unity Catalog 0.6, ambos open source Definição em YAML cobre fonte, join, filtro, dimensão e medida numa peça só Função MEASURE() calcula a medida nomeada na hora da consulta Mesma definição serve pra consulta humana e pra agente, sem recalcular a métrica em cada lugar Minhas considerações: complementando o que já vimos sobre Metric Views no Spark 4.2 dentro do Databricks, essa abertura pro open source parece menos sobre dar de graça uma feature e mais sobre tentar virar o padrão de fato pra camada semântica no ecossistema Spark, competindo direto com dbt Semantic Layer e ferramenta parecida. A pergunta que fica: quando a definição de métrica passa a rodar em qualquer motor Spark, quem garante que a mesma métrica calculada fora do Unity Catalog do Databricks continua governada com o mesmo rigor de permissão e auditoria que ela tem hospedada.\nFonte: https://unitycatalog.io/blogs/uc-metric-views/\n#Databricks #UnityCatalog #ApacheSpark\n","permalink":"https://wiliamrosa.github.io/posts/metric-views-open-source-spark-4-3-unity-catalog-0-6/","summary":"O Databricks MVP Geir E. Alstad destacou que Metric Views chegou ao Apache Spark 4.3 e ao Unity Catalog 0.6 open source, levando a semântica de negócio definida em YAML e a função MEASURE() pra fora do Databricks hospedado.","title":"Metric Views saiu do Databricks e virou parte do Apache Spark e do Unity Catalog open source"},{"content":"O que a Databricks anunciou O modelo Grok 4.6, da xAI, já está disponível no Databricks via Unity AI Gateway. Segundo o anúncio, o Grok 4.6 estabeleceu um novo patamar de desempenho no benchmark interno OfficeQA Pro v2, usado pela Databricks para avaliar tarefas complexas de raciocínio sobre documentos corporativos, quando combinado com o harness do Genie.\nA proposta de valor destacada é rodar o modelo onde os dados já vivem, governados e seguros, em vez de mover dados para fora do Lakehouse até um provedor externo, com todo o gasto sendo monitorado e controlado via Unity Gateway.\nFonte original: post da Databricks no LinkedIn\nPor que isso importa na prática Isoladamente, \u0026ldquo;mais um modelo disponível\u0026rdquo; não é uma notícia técnica profunda. O que importa é o padrão que se repete: a cada poucas semanas, mais um modelo de peso passa a estar disponível via Unity AI Gateway. A Databricks está, de forma consistente, se posicionando como camada neutra de acesso a modelo, não como dona de um modelo próprio competindo de igual para igual com OpenAI, Anthropic ou xAI, mas como o lugar que já tem seus dados governados e por isso é o caminho de menor atrito para usar qualquer modelo novo que surgir.\nMinha opinião Esse tipo de anúncio individual de modelo eu trato com relativamente pouco entusiasmo, daqui a três meses vai ter outro modelo \u0026ldquo;estado da arte\u0026rdquo; em algum benchmark, e o ciclo se repete. O que me interessa de verdade é o benchmark citado, o OfficeQA Pro v2: um benchmark proprietário da própria Databricks para avaliar raciocínio sobre documentos corporativos é, na prática, uma forma de dizer \u0026ldquo;não confie só no benchmark público do fornecedor do modelo, confie no nosso, feito para o seu tipo de dado real\u0026rdquo;.\nIsso é uma faca de dois gumes. Por um lado, benchmarks genéricos realmente têm pouca relação com o desempenho em dados corporativos confusos e mal estruturados, que é a realidade de quem trabalha com Lakehouse. Por outro lado, é um benchmark controlado pelo mesmo fornecedor que está vendendo o acesso ao modelo, vale sempre pedir a metodologia antes de usar o resultado para justificar uma decisão de arquitetura.\nNa prática, o valor real para quem eu treino e mentorizo na comunidade não é \u0026ldquo;use Grok 4.6\u0026rdquo;, é \u0026ldquo;trocar de modelo dentro do Databricks virou uma decisão de configuração, não uma decisão de arquitetura\u0026rdquo;, e isso, sim, muda como eu ensino a pensar sobre seleção de modelo.\nPara saber mais Post original: https://lnkd.in/gK55k5AT Documentação oficial do Databricks: https://docs.databricks.com/ ","permalink":"https://wiliamrosa.github.io/posts/databricks-grok-4-6-unity-ai-gateway/","summary":"Mais um modelo externo disponível via Unity AI Gateway. O anúncio em si é pequeno, mas confirma uma estratégia maior: a Databricks quer ser o lugar neutro onde você roda qualquer modelo em cima dos seus próprios dados governados.","title":"Grok 4.6 chega ao Databricks: o Unity AI Gateway como vitrine multi-modelo"},{"content":"Dar permissão de leitura pra um agente não devia significar dar a mesma permissão que o humano que ele representa tem.\nA Databricks MVP Zoë Van Noppen apontou o Context Attributes assim que saiu do papel: uma extensão das políticas ABAC do Unity Catalog que deixa condicionar máscara de coluna e row filter não só a quem é o usuário, mas ao contexto técnico da própria requisição.\nO mecanismo introduz duas condições novas de política: request.is_on_behalf_of, que retorna verdadeiro sempre que a chamada vem de um app OAuth agindo em nome de alguém (não exclusivo de agente, CLI e SDK também contam), e request.client_id, que deixa mirar uma aplicação OAuth específica pelo identificador dela. Isso resolve um problema real de quem constrói agente hospedado como Databricks App: autenticação on-behalf-of já garante que o agente herda a identidade do usuário, mas às vezes você quer que o agente veja menos dado do que a pessoa vê diretamente, por exemplo, dado sensível demais pra passar por um LLM mesmo que o usuário tenha acesso a ele.\nDetalhes técnicos que valem registrar:\nrequest.is_on_behalf_of retorna a string \u0026rsquo;true\u0026rsquo; ou \u0026lsquo;false\u0026rsquo;, verdadeiro pra qualquer requisição vinda de app OAuth request.client_id permite política direcionada a uma aplicação OAuth específica pelo ID As funções has_context_attribute e has_context_attribute_value são suportadas na cláusula WHEN de política de row filter e column mask Ainda em Beta, precisa ser ativado por admin de conta na página de Previews Minhas considerações: essa é uma peça pequena mas exatamente do tipo que separa \u0026ldquo;agente com acesso ok em teoria\u0026rdquo; de \u0026ldquo;agente com acesso auditável na prática\u0026rdquo;. Sem diferenciar contexto de requisição, a única forma de restringir o que um agente vê era criar um usuário técnico separado com permissão reduzida, o que quebra o modelo mais limpo de on-behalf-of. Vale testar cedo em qualquer solução agêntica que já lide com dado sensível, antes de precisar improvisar um workaround.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/data-governance/unity-catalog/abac/core-concepts\n#Databricks #UnityCatalog #ABAC\n","permalink":"https://wiliamrosa.github.io/posts/databricks-abac-context-attributes-beta/","summary":"Context Attributes (Beta) deixa política ABAC do Unity Catalog condicionar máscara e row filter ao contexto da requisição, se veio via OAuth on-behalf-of ou de qual client_id, não só a quem pertencem os dados.","title":"Uma política ABAC agora sabe distinguir se quem pergunta é um agente ou uma pessoa"},{"content":"Até pouco tempo, se o workspace tinha serverless habilitado, todo mundo tinha acesso, sem meio-termo.\nO Databricks MVP Soufiane Darraz apontou a chegada do Serverless Compute Access Control à disponibilidade geral: agora existem dois objetos de compute nativos, Default Interactive Compute (pra notebook e Databricks Connect) e Default Automated Compute (pra job e pipeline), e um admin de workspace controla o acesso a cada um separadamente.\nO mecanismo é direto: por padrão, todo usuário do workspace mantém o direito de uso em ambos os tipos de compute, então nada quebra pra workload existente no dia em que isso for adotado. A partir daí, o admin remove grupo ou usuário específico de um dos dois objetos pra restringir acesso, seja pela UI, seja pela Access Control API, dependendo se a preferência é gerenciar isso manualmente ou via automação.\nPontos técnicos que valem registrar:\nDois objetos de compute distintos: interativo (notebook, Databricks Connect) e automatizado (job, pipeline declarativa) Acesso é aditivo por padrão, ninguém perde permissão automaticamente na migração Restrição acontece por remoção explícita de grupo ou usuário, não por allowlist desde o início Gerenciável tanto pela interface quanto pela API de controle de acesso Minha ressalva: \u0026ldquo;por padrão todo mundo mantém acesso\u0026rdquo; é a escolha certa pra não quebrar produção no dia da adoção, mas também significa que a governança só existe de fato depois que alguém ativamente decide restringir. Se sua empresa habilitou serverless há tempos sem pensar em quem deveria ou não ter acesso, essa funcionalidade só ajuda se alguém realmente for lá auditar os grupos hoje, ela não impõe disciplina sozinha.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/compute/serverless/access-control\n#Databricks #Serverless #Governança\n","permalink":"https://wiliamrosa.github.io/posts/databricks-serverless-compute-access-control-ga/","summary":"Serverless Compute Access Control chegou à disponibilidade geral: admin de workspace agora governa acesso a compute interativo e automatizado por usuário ou grupo, via UI ou API.","title":"Quem pode usar serverless no seu workspace virou uma decisão explícita, não implícita"},{"content":"O Databricks MVP Josue Bogran gravou uma série de entrevistas explicativas com Akram Chetibi, que lidera o produto, cobrindo desde o básico do que é o OpenSharing, o novo nome do Delta Sharing, que já resolvia bem o problema de distribuir dado pra clientes sem duplicação e agora foi rebatizado pela própria Databricks como o protocolo aberto de compartilhamento pra era agêntica.\nRenomear um protocolo de compartilhamento de dados já maduro não costuma ser cosmético, geralmente sinaliza expansão de escopo. Dado o contexto de tudo que a Databricks vem lançando (Omnigent, Unity AI Gateway, agentes cada vez mais autônomos), a aposta razoável é que \u0026ldquo;para a era agêntica\u0026rdquo; significa: compartilhar não só tabela e dado estático, mas também os recursos que um agente precisa consumir através de organizações diferentes.\nPor que vale acompanhar esse rebranding de perto:\nSe o escopo realmente expandir pra cobrir compartilhamento de recursos agênticos (não só dado), isso muda o Delta Sharing de \u0026ldquo;ferramenta de distribuição de dado\u0026rdquo; pra peça central de arquitetura multi-organização de agentes Quem já usa Delta Sharing hoje precisa entender se o rebranding vem só com nome novo ou com mudança real de capacidade Entrevista em vídeo com o líder de produto é uma fonte primária melhor que nota de release pra entender a intenção estratégica por trás do nome novo Minha ressalva: renomear pra sinalizar ambição é uma jogada de marketing legítima, mas carrega o mesmo risco que Maria Vechtomova já documentou sobre a Databricks, mudança de nome frequente quebra busca e deixa conteúdo técnico antigo desatualizado por causa do rótulo, não da tecnologia. Vale esperar a documentação oficial confirmar exatamente o que mudou tecnicamente antes de reescrever qualquer material próprio sobre Delta Sharing.\nFonte: https://www.youtube.com/watch\n#Databricks #OpenSharing #Governança\n","permalink":"https://wiliamrosa.github.io/posts/databricks-delta-sharing-vira-opensharing/","summary":"O Databricks MVP Josue Bogran entrevistou o líder de produto do OpenSharing pra explicar o que muda quando o Delta Sharing se rebatiza como o protocolo aberto de compartilhamento para a era agêntica.","title":"Delta Sharing virou OpenSharing, mais um rebranding que esconde uma ambição maior"},{"content":"O Databricks MVP Soufiane Darraz, que costuma postar só anúncio oficial já confirmado, trouxe o lançamento do app de desktop do Genie One pra macOS, agora em Beta.\nO que muda é menos sobre funcionalidade nova e mais sobre onde essa funcionalidade vive. Até aqui, conversar com dado do Lakehouse em linguagem natural via Genie One significava manter uma aba de browser aberta o tempo todo, competindo com dezenas de outras abas de trabalho. O app nativo tira essa dependência: ele abre como qualquer outro aplicativo do sistema, com ícone próprio no dock, badge de notificação e atualização automática, e dentro dele o usuário de negócio segue conversando com os dados, revisitando thread antigo, trabalhando com documento anexado e usando Genie Agents, sem precisar do Chrome ou do Safari por perto.\nDetalhes técnicos do lançamento:\nÉ um app nativo de macOS, não um wrapper de browser disfarçado, o que normalmente significa menos consumo de memória e integração melhor com atalho do sistema operacional Mantém paridade com a versão web em thread, documento e Genie Agents, não é uma versão reduzida Atualização acontece automaticamente, sem o usuário precisar buscar versão nova manualmente Minhas considerações: empacotar Genie One como app de desktop é um sinal claro de pra quem a Databricks está mirando com esse produto, o usuário de negócio que não abre notebook nem SQL editor no dia a dia, e pra essa pessoa reduzir fricção de acesso importa mais do que qualquer feature nova de modelo. Falta saber se Windows e Linux entram na mesma onda, ou se o macOS ficou na frente por causa de composição de público entre quem hoje usa Genie One com mais frequência.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/genie-one/desktop\n#Databricks #Genie\n","permalink":"https://wiliamrosa.github.io/posts/genie-one-app-desktop-macos-beta/","summary":"O app de desktop do Genie One pra macOS entrou em Beta, tirando a experiência de dentro de uma aba de browser. O Databricks MVP Soufiane Darraz destacou o lançamento assim que ele saiu.","title":"Genie One ganha app nativo pra macOS, e sai do browser"},{"content":"Uma pergunta simples de cliente virou um artigo técnico sobre um detalhe que muda latência de pipeline streaming sensível.\nO Databricks MVP Mani Kandasamy destacou o trabalho do arquiteto de soluções Sreekanth Munigati, que explicou o que acontece quando um micro-batch demora mais que o intervalo de gatilho configurado num Lakeflow Spark Declarative Pipeline serverless. A resposta virou a explicação de uma otimização chamada Stream Pipelining: em queries de streaming elegíveis, múltiplos micro-batches podem ficar em voo ao mesmo tempo, em vez de sempre esperar um terminar completamente antes do próximo começar.\nNa prática, isso ataca um gargalo clássico de Spark Structured Streaming: sem pipelining, um micro-batch lento vira um funil que atrasa tudo depois dele, mesmo que o motor tivesse capacidade sobrando pra já começar a processar o próximo. Com múltiplos micro-batches em voo, o motor aproveita melhor a capacidade disponível em vez de ficar ocioso esperando uma etapa terminar.\nPontos técnicos que valem registrar:\nA otimização se aplica a queries de streaming elegíveis dentro de Lakeflow Spark Declarative Pipelines serverless Resolve especificamente o cenário em que o processamento de um micro-batch ultrapassa o intervalo de gatilho configurado É uma otimização de execução, não uma mudança de API, o comportamento muda sem exigir reescrever a lógica do pipeline Minhas considerações: esse é o tipo de detalhe que só aparece quando alguém debuga um problema real de latência em produção, não em documentação de lançamento de feature. Vale a pena acompanhar esse tipo de conteúdo técnico vindo direto de quem trabalha com cliente, porque frequentemente é onde aparece o \u0026ldquo;porquê\u0026rdquo; por trás de um comportamento que a documentação oficial só descreve por cima.\nFonte: https://community.databricks.com/t5/technical-blog/triggered-vs-continuous-mode-a-deep-dive-into-serverless/ba-p/164327\n#Databricks #Lakeflow #SparkStreaming\n","permalink":"https://wiliamrosa.github.io/posts/databricks-lakeflow-stream-pipelining-serverless/","summary":"Stream Pipelining permite múltiplos micro-batches em voo ao mesmo tempo em pipelines declarativos serverless, em vez de esperar cada um terminar antes do próximo começar.","title":"Micro-batch atrasado não precisa mais travar a fila inteira no Lakeflow serverless"},{"content":"Migrar dashboard legado sem reconstruir do zero deixou de ser promessa e virou funcionalidade.\nO Databricks MVP Soufiane Darraz destacou a novidade assim que ela chegou: agora dá pra fazer upload direto de arquivo do Tableau (.twb, .twbx) ou do Power BI (.tds, .tdsx, .pbit) no Genie Code e deixar a IA gerar um dashboard AI/BI que replica as visualizações originais, sem reescrever cada gráfico manualmente.\nO mecanismo funciona em duas camadas. Primeiro, o Genie Code interpreta a estrutura do arquivo importado (fonte de dado, campo calculado, tipo de visualização) e monta o dashboard equivalente. Segundo, e essa é a parte que importa pra quem se preocupa com governança: a lógica de negócio por trás dos gráficos vira Metric View, promovida ao Unity Catalog, onde passa a ter linhagem, controle de acesso e fica disponível pra reuso em outros dashboards, não só isolada dentro daquele relatório importado.\nDetalhes técnicos que valem registrar:\nFormatos suportados: .twb e .twbx do Tableau, .tds e .tdsx (fontes de dado do Tableau), .pbit do Power BI Arquivos de referência ficam armazenados em volumes do Unity Catalog Metric Views geradas automaticamente podem ser promovidas ao Unity Catalog pra governança, linhagem e reuso Minha ressalva: replicar visualização automaticamente é diferente de replicar a intenção de negócio por trás dela. Um campo calculado complexo do Tableau, cheio de lógica condicional acumulada ao longo de anos, é exatamente o tipo de coisa que uma tradução automática tende a simplificar demais ou errar sutilmente. Eu revisaria cada Metric View gerada linha por linha antes de promover pro Unity Catalog, principalmente se o dashboard original alimenta decisão financeira ou regulatória.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/dashboards/manage/import-bi\n#Databricks #GenieCode #AIBI\n","permalink":"https://wiliamrosa.github.io/posts/databricks-genie-code-importar-tableau-powerbi/","summary":"Genie Code agora aceita arquivo .twb, .twbx, .tds, .tdsx ou .pbit e gera automaticamente um dashboard AI/BI equivalente, com Metric Views replicando a lógica de negócio original.","title":"Migrar dashboard do Tableau ou Power BI pro Databricks virou upload de arquivo"},{"content":"O Databricks MVP Josue \u0026ldquo;Josh\u0026rdquo; Bogran testou o recurso de Policies do Unity AI Gateway, ainda em beta, combinado com o Omnigent, adicionando camadas de proteção contra uso de IA arriscado ou fora de conformidade. Durante os testes, ele encontrou casos onde as barreiras (guardrails) deveriam ter sido mais rigorosas do que realmente foram, e já repassou esse retorno para a equipe da Databricks.\nIsso confirma algo que quem acompanha governança de IA já esperava: sair do \u0026ldquo;faroeste de IA\u0026rdquo; pra um modelo com controles de acesso, políticas e custo é o caminho certo, mas uma feature em beta que promete barreira de segurança precisa ser testada sob condição adversária antes de virar dependência crítica, não só sob o caminho feliz.\nPor que esse tipo de teste importa mais do que o anúncio da feature em si:\nBeta significa exatamente isso: ainda não é confiável o suficiente pra tratar como controle definitivo Um MVP testando ativamente e reportando gap pra Databricks é o processo de maturação da feature funcionando como deveria Quem já está usando Policies em produção (mesmo em beta) precisa saber que existem brechas conhecidas, não descobrir isso sozinho depois de um incidente Minha ressalva: \u0026ldquo;beta com gap conhecido\u0026rdquo; é diferente de \u0026ldquo;beta pronto pra teste de estresse mais sério\u0026rdquo;, a diferença entre os dois só fica clara quando mais gente testa e reporta, como o Josue fez aqui. Antes de colocar Policies do Unity AI Gateway como única camada de proteção pra uso de IA sensível, eu manteria um controle complementar (revisão humana, ou um segundo gateway/proxy com regra própria) até a feature sair de beta com um histórico mais robusto de testes adversariais da comunidade.\nFonte: https://www.linkedin.com/in/josuebogran/\n#Databricks #UnityAIGateway #GovernançaDeIA\n","permalink":"https://wiliamrosa.github.io/posts/databricks-unity-ai-gateway-policies-beta-gaps/","summary":"O Databricks MVP Josue Bogran testou o recurso de Policies (ainda em beta) do Unity AI Gateway com Omnigent, e encontrou casos onde as barreiras deveriam ter sido mais rigorosas.","title":"Testei o beta de Policies no Unity AI Gateway, e a barreira ainda deixa passar coisa que não devia"},{"content":"O engenheiro de plantão que já foi acordado por um alerta de madrugada conhece a sequência: abrir o dashboard, cruzar log de três serviços diferentes, checar se houve deploy recente, revisar métrica de dependência upstream, e só depois de vinte minutos montando esse quadro começar de fato a investigar a causa. A Databricks mediu isso internamente e chegou num número desconfortável: entre 60% e 80% do tempo de investigação de incidente não vai pra achar a causa raiz, vai pra montar o contexto necessário pra começar a procurar.\nO AI SRE, agente interno que a Databricks documentou recentemente, ataca exatamente esse desperdício. A ideia central não é substituir o julgamento do engenheiro, é eliminar o trabalho mecânico de reunir contexto que vem antes desse julgamento, rodando em paralelo, em segundos, o que um humano levaria minutos pra montar manualmente.\nO mecanismo: três trilhas em paralelo, evidência antes de conclusão Quando um incidente dispara, o AI SRE não espera um engenheiro pedir informação, ele já começa três investigações simultâneas:\nChecagem de saúde da plataforma: verifica infraestrutura de nuvem, rede e dependência upstream, descartando de cara causa que não está no código do time (uma zona de disponibilidade com problema, um provedor externo fora do ar).\nAnálise em nível de serviço: examina log, métrica, trace, deploy recente e mudança de configuração do serviço específico envolvido no alerta.\nExecução de runbook: roda os fluxos que o próprio time já documentou como \u0026ldquo;o que um especialista checaria nesse tipo de falha\u0026rdquo;, convertidos em runbook agêntico.\nO princípio de design que amarra as três trilhas juntas é declarado explicitamente pela equipe: \u0026ldquo;checagem estruturada antes de raciocínio aberto\u0026rdquo;. Isso significa que o AI SRE roda primeiro checagem de plataforma determinística e passo de runbook, e só depois entrega esse resultado bruto pra camada de LLM sintetizar e explicar, nunca o contrário. A coleta de dado não fica a critério do julgamento do modelo, ela é feita antes, com processo fixo. Toda recomendação final vem amarrada à evidência que a sustenta, rastreável até a checagem específica que a gerou, não uma inferência solta do modelo sobre o que \u0026ldquo;provavelmente\u0026rdquo; aconteceu.\nMinha leitura: esse é o tipo de decisão de design que só fica óbvia depois que alguém erra do outro jeito primeiro. Um agente que já parte pra \u0026ldquo;raciocínio aberto\u0026rdquo; sobre log e métrica, sem checagem determinística prévia, tende a soar convincente mesmo quando está errado, e incidente é exatamente o cenário onde uma causa raiz errada e convincente atrasa a correção real. Fixar \u0026ldquo;dado primeiro, interpretação depois\u0026rdquo; como regra de arquitetura, não como boa prática opcional, é o que faz esse tipo de agente ser seguro o suficiente pra rodar sem supervisão constante.\nMão na massa: transformando checklist de plantão em runbook agêntico A peça mais replicável fora do ambiente interno da Databricks é o próprio mecanismo de runbook, construído sobre o sistema público de skills do Genie Code (.assistant/skills/), o mesmo usado pra ensinar lógica de negócio a agente de dado. Qualquer time no Azure Databricks pode aplicar a mesma lógica pro próprio plantão, convertendo um checklist informal em skill:\nWorkspace/.assistant/skills/incidente-fila-kafka-atrasada/ └── SKILL.md --- name: incidente-fila-kafka-atrasada description: Runbook para lag alto no consumer group de streaming. Use quando o alerta mencionar consumer lag, offset atrasado ou fila de eventos acumulando. --- Checagem, na ordem: 1. Consultar `lag_by_partition` no painel de métricas do consumer group; lag acima de 500 mil mensagens em qualquer partição é o limiar de atenção. 2. Verificar se houve deploy do consumer nas últimas 2 horas (causa mais comum: handler novo mais lento que o anterior). 3. Se não houve deploy, checar throughput do broker de origem; partição com lag isolado numa única partição indica hot partition, não problema de consumer. 4. Mitigação padrão: escalar réplica do consumer group primeiro, nunca aumentar partição em produção sem aprovação, isso reembaralha o particionamento existente. Assim que documentado dessa forma, esse conhecimento deixa de morar só na cabeça de quem já resolveu esse incidente antes e passa a ser executável automaticamente na próxima vez que o alerta disparar, exatamente o efeito de \u0026ldquo;runbook agêntico\u0026rdquo; que o AI SRE aplica internamente, só que disponível pra qualquer time hoje, sem esperar acesso a uma ferramenta interna da Databricks.\nO trabalho que ninguém vê: dar acesso sem abrir brecha A parte menos glamorosa desse projeto, e a que a própria equipe da Databricks destaca como tendo consumido mais esforço de engenharia do que o desenho do agente em si, foi reconstruir a camada de API que dá ao agente acesso à observabilidade da empresa. O motivo é direto: um agente que pode consultar log, métrica e trace livremente também pode, se mal configurado, gerar volume de consulta capaz de sobrecarregar o próprio sistema de observabilidade que sustenta o alerta crítico de produção, uma ironia cruel de um agente de confiabilidade derrubar a confiabilidade. A equipe precisou colocar limite de taxa, escopo de permissão e guarda-corpo suficiente pra deixar o agente rápido sem virar ele mesmo uma fonte de incidente.\nIsso é uma lição que vale além do caso específico do AI SRE: todo projeto de agente com acesso amplo a sistema de produção carrega esse mesmo risco de segunda ordem, e o desenho de guarda-corpo geralmente exige mais tempo de engenharia do que o próprio comportamento do agente que ele protege. Subestimar essa parte é o motivo mais comum de projeto de agente interno travar em fase de segurança depois de já funcionar bem em prova de conceito.\nO que isso não resolve O AI SRE não elimina a necessidade de runbook bem escrito, ele só executa mais rápido o que o time já sabe fazer. Se ninguém documentou o checklist de um tipo de incidente novo, não existe runbook pra rodar, e o agente cai de volta na trilha de checagem genérica de plataforma e serviço, sem o atalho de conhecimento específico do time. A arquitetura também assume acesso amplo à camada de observabilidade da própria empresa, redesenhar a API pra dar esse acesso com guarda-corpo suficiente pra não derrubar infraestrutura crítica de monitoramento foi, segundo a própria equipe, mais trabalho de engenharia do que o agente em si. E vale lembrar que é ferramenta interna: não existe hoje um produto público equivalente prontinho pra instalar, o que dá pra replicar é o padrão de arquitetura (checagem antes de raciocínio, runbook como skill versionada), não uma feature que se ativa com um clique.\nFechamento O ganho aqui não vem de um modelo mais esperto interpretando o incidente, vem de eliminar o tempo que se gasta montando contexto antes de sequer começar a interpretar. Pra qualquer time de plataforma que já mantém um Wiki de \u0026ldquo;como resolver X\u0026rdquo; que só quem já viu aquele incidente antes sabe procurar, o caminho natural é o mesmo que a Databricks descreve internamente: transformar esse conhecimento em runbook versionado e executável, e deixar a checagem determinística correr antes de qualquer camada de raciocínio livre entrar em cena.\nReferências Databricks Blog, \u0026ldquo;How Databricks Uses AI to Accelerate Incident Investigation\u0026rdquo;: https://www.databricks.com/blog/how-databricks-uses-ai-accelerate-incident-investigation Databricks Docs, \u0026ldquo;Extend Genie Code with agent skills\u0026rdquo;: https://docs.databricks.com/aws/en/genie-code/skills #Databricks #AIEngineering #Observabilidade #SRE\n","permalink":"https://wiliamrosa.github.io/articles/databricks-ai-sre-investigacao-incidentes-agente/","summary":"A Databricks documentou o AI SRE, agente interno que roda checagem de plataforma, análise de log e runbook de time em paralelo assim que um incidente dispara, entregando causa raiz com evidência rastreável antes de um engenheiro terminar de montar o contexto manualmente.","title":"Antes de abrir o Grafana: como a Databricks usa agente de IA pra investigar o próprio incidente"},{"content":"O que a Databricks anunciou A Databricks publicou uma conversa com Nikita Shamgunov, VP de Engenharia e um dos fundadores do Neon, sobre a ideia por trás do Neon Postgres que hoje sustenta o Lakebase: separar compute e armazenamento em um banco Postgres OLTP. A discussão explora como object storage pode tornar dados operacionais disponíveis para sistemas downstream, por que arquitetura de banco \u0026ldquo;developer-first\u0026rdquo; importa, e o que muda quando agentes começam a provisionar bancos, criar branches de dados e gerenciar o estado de aplicações sozinhos.\nFonte original: post da Databricks no LinkedIn\nPor que isso importa na prática \u0026ldquo;Branch de banco de dados\u0026rdquo; como conceito não é novo para quem trabalha com Neon isoladamente, é uma das features que mais chamou atenção quando o produto ganhou popularidade fora do universo Databricks. O que essa conversa deixa claro é a intenção estratégica: trazer esse modelo mental (banco como recurso que se cria, clona e descarta com a mesma leveza de um container) para dentro do Lakehouse, sob o mesmo Unity Catalog que já governa o resto dos dados.\nIsso se conecta diretamente com o post de arquitetura do Lakebase que também cobri nesta série: aquele foca no \u0026ldquo;porquê\u0026rdquo; object storage embaixo de um transacional; esse aqui explica de onde veio tecnicamente essa capacidade, a aquisição e a arquitetura do Neon.\nMinha opinião Como alguém que lida com provisionamento de ambiente de dados no dia a dia, a parte que mais me chama atenção não é a separação compute/storage em si, isso já é tese validada desde o Snowflake no mundo analítico, é a normalização do branch de banco transacional como operação rotineira. Hoje, criar um ambiente de teste isolado com uma cópia realista de produção ainda é, na maioria das empresas que conheço, um processo manual, lento e caro em armazenamento. Se um agente consegue fazer isso em segundos porque o banco é fundamentalmente copy-on-write sobre object storage, isso muda o ciclo de desenvolvimento de qualquer aplicação transacional, não só as orientadas a IA.\nO ponto que eu colocaria em xeque é a maturidade operacional dessa promessa em escala empresarial regulada. Criar e descartar bancos rapidamente é ótimo para desenvolvimento e teste; para dados que tocam informação sensível, cada branch é potencialmente uma nova superfície de auditoria e retenção que o time de governança precisa entender, e isso raramente é tão simples quanto a demonstração técnica sugere.\nDe qualquer forma, é a peça que estava faltando para eu entender por que a Databricks investiu tanto em Postgres transacional quando já dominava o mundo analítico: não é sobre competir com bancos OLTP tradicionais, é sobre dar ao agente autonomia de infraestrutura sem sair do Lakehouse.\nPara saber mais Post original: https://lnkd.in/gCfiCrNU Documentação oficial do Databricks: https://docs.databricks.com/ ","permalink":"https://wiliamrosa.github.io/posts/databricks-lakebase-neon-postgres-compute-storage/","summary":"Na conversa com Nikita Shamgunov, VP de Engenharia da Databricks, fica mais claro de onde vem a arquitetura do Lakebase, e por que \u0026lsquo;agente provisionando banco sozinho\u0026rsquo; deixou de ser ficção científica.","title":"O DNA do Neon Postgres dentro do Lakebase: o que a separação compute/storage muda para quem provisiona banco"},{"content":"O que a Databricks anunciou A Databricks apresentou o Omnigent, descrito como um \u0026ldquo;meta-harness\u0026rdquo; open-source: uma camada compartilhada que permite trocar de agente de código sem perder contexto, rotear tarefas de forma inteligente, definir políticas contextuais e controles de gasto, e inserir aprovação humana onde for necessário. O anúncio veio junto com uma conversa entre Youssef Mrini, Quentin Ambard e o cofundador e CTO da Databricks, Matei Zaharia.\nFonte original: post da Databricks no LinkedIn\nPor que isso importa na prática Quem usa mais de um agente de código no dia a dia (Copilot para uma coisa, Claude Code para outra, um agente proprietário para uma terceira) sabe o custo invisível de trocar de ferramenta: o contexto do que já foi decidido, testado e descartado fica preso na ferramenta anterior. Cada troca de agente hoje é, na prática, um recomeço de contexto.\nO Omnigent ataca esse problema por baixo, como uma camada de orquestração e não como \u0026ldquo;mais um agente competindo pela sua atenção\u0026rdquo;. Isso é coerente com o outro anúncio da Databricks sobre orçamento de gasto com coding agents (veja minha análise aqui): se você quer controlar custo e política através de várias ferramentas de agente, precisa de uma camada abaixo delas, não de mais uma ferramenta ao lado.\nMinha opinião A pergunta que o Omnigent tenta responder, \u0026ldquo;como você orquestra vários agentes sem que cada troca de ferramenta vire um recomeço\u0026rdquo;, é, na minha visão, uma das perguntas mais subestimadas do momento em engenharia de IA. A maior parte do mercado ainda está competindo em \u0026ldquo;qual agente é melhor\u0026rdquo;, enquanto o problema real de quem opera múltiplos agentes em produção é de orquestração, não de escolha de modelo.\nDito isso, sou cauteloso com \u0026ldquo;meta-harness\u0026rdquo; como categoria. Já presenciei esse padrão de \u0026ldquo;camada universal que integra tudo\u0026rdquo; prometer mais do que entrega quando o ecossistema por baixo muda rápido demais, e agentes de código são hoje o ecossistema que mais muda rápido. O real teste de fogo do Omnigent não é a demonstração em vídeo com o Matei Zaharia, é: daqui a seis meses, quando surgir um agente de código totalmente novo, o Omnigent consegue absorver ele com o mesmo nível de contexto compartilhado, ou vira mais uma integração para manter?\nSendo open-source, pelo menos existe transparência para a comunidade avaliar isso na prática, e é esse código que pretendo revisar antes de recomendar adoção em produção para quem pergunta no grupo de usuários que lidero em São Paulo.\nPara saber mais Post original: https://www.youtube.com/watch?v=sk6HBdmVmL8 Documentação oficial do Databricks: https://docs.databricks.com/ ","permalink":"https://wiliamrosa.github.io/posts/databricks-omnigent-orquestracao-agentes-codigo/","summary":"O Omnigent propõe uma camada compartilhada para orquestrar múltiplos agentes de código sem perder contexto entre eles. Acho que essa é a pergunta certa, mas a resposta ainda depende de execução.","title":"Omnigent: a Databricks aposta que orquestrar agentes importa mais do que escolher um só"},{"content":"A Databricks abriu o código do Omnigent, um \u0026ldquo;meta-harness\u0026rdquo; pra resolver um problema que quase ninguém está discutindo: trocar de agente de código sem perder o contexto do que já foi decidido.\nHoje, cada vez que você troca de ferramenta de agente, o contexto acumulado fica preso na ferramenta anterior. O Omnigent tenta virar a camada abaixo de todos os agentes, roteando tarefa, aplicando política e controle de gasto, e inserindo aprovação humana onde precisar, em vez de ser mais um agente competindo pela sua atenção.\nPor que essa pergunta importa mais do que \u0026ldquo;qual agente é melhor\u0026rdquo;:\nA maior perda de produtividade hoje não é escolher o agente certo, é recomeçar contexto toda vez que troca Controle de custo e política só funciona de verdade numa camada abaixo das ferramentas, não do lado delas Sou cético com a categoria \u0026ldquo;camada universal que integra tudo\u0026rdquo;, já vi essa promessa não sobreviver à velocidade com que o ecossistema de agentes muda. Sendo open-source, pelo menos dá pra comunidade auditar isso antes de confiar.\nFonte: https://www.youtube.com/watch?v=sk6HBdmVmL8\n#Databricks #Omnigent #AgentesDeIA\n","permalink":"https://wiliamrosa.github.io/posts/linkedin-omnigent-agentes-codigo/","summary":"A pergunta que o Omnigent tenta responder importa mais do que \u0026lsquo;qual agente é melhor\u0026rsquo;, mas \u0026lsquo;meta-harness universal\u0026rsquo; é uma categoria que merece ceticismo.","title":"Omnigent: trocar de agente de código sem recomeçar o contexto"},{"content":"RBAC (role-based access control) atingiu disponibilidade geral no Azure Databricks. A mudança de modelo é mais importante do que a sigla sugere: em vez de operar sempre com a soma de todas as permissões que um usuário acumulou ao longo do tempo, ele passa a poder assumir um papel específico, e só as permissões daquele papel valem durante a sessão.\nIsso ataca um problema clássico de governança que cresce silenciosamente: usuário antigo numa empresa grande, que trocou de time três vezes, geralmente carrega permissão de todos os times por onde passou, porque revogar acesso é sempre a etapa que ninguém prioriza.\nPor que isso muda a prática, não só a teoria:\nAuditoria fica mais simples: \u0026ldquo;que papel essa pessoa estava usando quando fez X\u0026rdquo; é uma pergunta melhor que \u0026ldquo;quais das 40 permissões acumuladas ela usou\u0026rdquo; Reduz superfície de erro: assumir o papel errado de propósito é mais difícil que só \u0026ldquo;ter permissão sobrando sem perceber\u0026rdquo; Abre caminho pra automação de acesso temporário, assumir um papel por tempo limitado, sem processo manual de revogação depois Minha ressalva: RBAC bem feito depende de papéis bem desenhados. Se a empresa só recriar a bagunça de permissões acumuladas dentro de \u0026ldquo;papéis\u0026rdquo; genéricos demais, a mudança de modelo não entrega o benefício, o problema de governança simplesmente muda de nome.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/release-notes/product/2026/august\n#AzureDatabricks #RBAC #Governança\n","permalink":"https://wiliamrosa.github.io/posts/azure-databricks-rbac-geralmente-disponivel/","summary":"Com RBAC em GA, um usuário passa a assumir um papel específico em vez de carregar todas as permissões que já acumulou, uma mudança de modelo mental, não só uma feature nova.","title":"RBAC chegou ao Azure Databricks, e muda a lógica de permissão acumulada"},{"content":"O Databricks MVP Dr. Alan L. Dennis compartilhou um argumento de arquitetura que vale a pena levar a sério antes de assinar mais um contrato de cluster Kafka: se você já roda Databricks, talvez você já tenha um barramento de mensagens funcional, só não estava olhando pra ele desse jeito.\nA ideia por trás do padrão DeltaBus é substituir Kafka como camada de eventos por tabela Delta combinada com Change Data Feed. Em vez de publicar evento num tópico e consumir via broker dedicado, uma aplicação escreve numa tabela Delta comum, e consumidores leem as mudanças incrementalmente via Change Data Feed, que já expõe insert, update e delete linha a linha com a sequência correta. O ganho não é performance bruta, é eliminar uma peça inteira de infraestrutura, o cluster Kafka, sua operação, seu patch de segurança e seu time dedicado, quando o volume e a latência exigida não justificam mensageria dedicada.\nOnde esse padrão faz sentido, e onde não faz:\nFunciona bem quando o consumidor já é um pipeline Databricks, porque elimina a ponte entre dois sistemas de armazenamento diferentes Change Data Feed já resolve ordenação e captura de delete, os dois pontos que mais dão trabalho em implementação caseira de fila sobre tabela Não substitui Kafka em cenário que exige latência de milissegundos ou milhões de mensagens por segundo, ali a arquitetura orientada a broker ainda ganha Minha ressalva: trocar Kafka por Delta Lake resolve o problema de operação de infraestrutura, mas introduz um acoplamento novo, o consumidor passa a depender do formato e do ritmo de commit do Delta Lake em vez de um protocolo de mensageria desenhado pra isso. Antes de migrar um sistema de produção inteiro pra esse padrão, vale simular o pior caso de latência de leitura do Change Data Feed sob carga, porque commit em lote não tem a mesma garantia de entrega quase instantânea que um broker dedicado oferece.\nFonte: https://www.covasant.com/blogs/you-already-have-a-message-bus-why-we-stopped-using-kafka\n#Databricks #DeltaLake #Arquitetura\n","permalink":"https://wiliamrosa.github.io/posts/deltabus-delta-lake-change-data-feed-sem-kafka/","summary":"Em vez de mais um cluster Kafka pra manter, o padrão DeltaBus usa tabela Delta e Change Data Feed como barramento de eventos. O Databricks MVP Dr. Alan L. Dennis destacou o argumento por trás dessa escolha de arquitetura.","title":"DeltaBus: o padrão que usa Delta Lake e Change Data Feed em vez de Kafka"},{"content":"O Genie Code ganhou a capacidade de receber uma foto de um esboço desenhado à mão e construir a dashboard a partir dela: ele procura nos dados financeiros e outros ativos do workspace aos quais você tem acesso, monta os datasets, cria as visualizações, e resolve problemas ao longo do caminho. No final, resume o que criou, mostra quais datasets usou, e sugere próximos passos como publicar, adicionar filtros ou fazer ajustes.\nO que esse recurso realmente ataca não é \u0026ldquo;desenhar é mais fácil que descrever em texto\u0026rdquo;, é a distância entre como um stakeholder de negócio pensa visualmente sobre uma dashboard (num guardanapo, num quadro branco, numa reunião) e o que precisa virar consulta SQL, dataset e gráfico configurado.\nPor que isso é mais interessante do que parece:\nReduz o vai-e-volta entre quem pede a dashboard e quem constrói, o esboço já é uma especificação, ainda que informal Genie Code precisa entender contexto suficiente do workspace pra mapear \u0026ldquo;essa caixinha no desenho\u0026rdquo; pra \u0026ldquo;essa métrica real nos dados\u0026rdquo; É um caso de uso onde erro de interpretação é fácil de perceber visualmente, comparar o esboço com o resultado é um ótimo mecanismo de verificação embutido Minha ressalva: rabisco à mão é ambíguo por natureza, dois analistas desenhando a mesma ideia produzem esboços diferentes, e o Genie Code precisa preencher essas lacunas com suposição. Vale tratar o resultado como um primeiro rascunho pra revisão, não como a dashboard final, a IA generativa é boa em preencher intenção implícita, mas nem sempre acerta qual métrica exata alguém tinha em mente ao desenhar uma caixinha.\nFonte: https://docs.databricks.com/aws/en/dashboards/manage/dashboard-agent\n#Databricks #GenieCode #AIBI\n","permalink":"https://wiliamrosa.github.io/posts/databricks-genie-code-sketch-to-dashboard/","summary":"Fazer upload de uma foto de um esboço desenhado à mão e pedir pro Genie Code construir a dashboard: menos um passo de tradução entre a ideia de negócio e o que acaba sendo construído.","title":"Genie Code agora transforma um rabisco em rascunho de papel numa dashboard de verdade"},{"content":"Genie Ontology sempre teve o problema inverso ao esperado: monta contexto automaticamente demais, e às vezes automaticamente demais é o problema, não a solução.\nA Databricks MVP Zoë Van Noppen destacou o Pages assim que a funcionalidade entrou em beta: uma aba nova dentro do Discover onde o time define conceito de negócio explicitamente, organizado por Domínio, em vez de deixar tudo por conta da inferência automática do Genie Ontology.\nO mecanismo funciona como um glossário vivo dentro do Unity Catalog. Cada Page define um conceito de negócio, seus sinônimos, e linka os ativos relacionados (tabela ou objeto do workspace que aquele conceito conecta) e as fontes de onde ele se originou, incluindo link externo pra ferramenta como Notion, quando a documentação já vive fora do Databricks. A parte mais interessante: já dá pra gerar Page a partir de documento existente usando Genie Code e seus conectores MCP, em vez de escrever cada definição manualmente do zero. Quando o Genie One responde uma pergunta sobre um conceito que tem Page definida, ele prioriza essa definição humana em vez do que inferiria sozinho, e cita a Page como fonte.\nPontos técnicos que valem registrar:\nPages são organizadas por Domínio e Subdomínio dentro do Discover Suportam link pra ativo do Unity Catalog ou workspace, e link externo pra fonte de documentação Já dá pra gerar Page automaticamente a partir de documento existente via Genie Code e conectores MCP Ainda não tem versionamento, e a Page em si não é um objeto do Unity Catalog Minha ressalva: gerar Page automaticamente a partir de documentação existente resolve o problema de começar do zero, mas cria um risco novo: sem versionamento, não tem como saber se aquela definição ainda reflete a realidade seis meses depois, ou se alguém mudou a regra de negócio sem atualizar a Page. Documentação desatualizada que o Genie trata como fonte de verdade prioritária é pior do que nenhuma documentação, porque erra com confiança em vez de admitir incerteza.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/uc-semantics/pages\n#Databricks #Genie #UnityCatalog\n","permalink":"https://wiliamrosa.github.io/posts/databricks-genie-ontology-pages-beta/","summary":"Pages (Beta) deixa times documentarem conceito de negócio dentro do Unity Catalog, organizado por domínio, e o Genie One passa a priorizar essa definição humana em vez de inferir tudo sozinho.","title":"Pages dá ao Genie Ontology o que faltava: uma definição de negócio que alguém realmente escreveu"},{"content":"Azure Databricks agora consegue restaurar, num notebook interativo novo, as variáveis Python e a sessão Spark de um job serverless que falhou, rodou 30 minutos ou mais, ou foi cancelado. O snapshot de estado é capturado automaticamente e fica disponível por 7 dias após o run terminar.\nQuem já debugou falha de job em produção conhece o ciclo frustrante: job falha de madrugada, você chega de manhã, e pra investigar direito precisa reprocessar o pipeline inteiro só pra chegar no mesmo estado que causou o problema, gastando tempo e compute só pra reproduzir o contexto.\nPor que isso muda o dia a dia de quem sustenta pipeline em produção:\nDebug vira \u0026ldquo;abrir o snapshot e inspecionar\u0026rdquo;, não \u0026ldquo;reprocessar e torcer pra reproduzir\u0026rdquo; Reduz o custo de investigação de falhas intermitentes, que são justamente as mais caras de reproduzir manualmente Captura automática significa que ninguém precisa lembrar de configurar isso antes da falha acontecer Minha ressalva: um snapshot de estado guardado por 7 dias é, por definição, uma cópia de dado que estava em memória no momento da falha, inclusive dado sensível que talvez nunca devesse ficar persistido nem temporariamente. Vale entender exatamente o que esse snapshot guarda antes de habilitar em workspace com dado regulado.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/release-notes/product/2026/august\n#AzureDatabricks #Serverless #DataEngineering\n","permalink":"https://wiliamrosa.github.io/posts/azure-databricks-session-restore-jobs-serverless/","summary":"Session Restore recupera variáveis Python e sessão Spark de um job serverless que falhou, direto num notebook interativo, sem precisar reprocessar tudo pra investigar.","title":"Um job falhou às 3h da manhã? Agora dá pra reabrir a sessão sem rodar tudo de novo"},{"content":"O Unity Catalog ganhou, em beta, a capacidade de escrever políticas ABAC de máscara de coluna e row filter usando atributos de identidade sincronizados do seu provedor (como o Microsoft Entra ID), departamento, país, o que estiver disponível, em vez de depender só de pertencimento a grupo.\nA diferença é sutil, mas resolve uma dor real de quem já mantém ABAC em produção: até aqui, se sua política precisava distinguir por atributo que não virou grupo explícito no Unity Catalog, a saída era criar um grupo só pra isso, e agora você tem mais um objeto de governança pra manter sincronizado manualmente.\nPor que isso reduz trabalho de verdade:\nAtributo já existe no Entra ID, a política referencia ele direto, sem duplicar como grupo Menos objetos de governança pra manter alinhados entre identidade e Unity Catalog Política de máscara fica mais próxima da linguagem que RH e segurança já usam (\u0026ldquo;é do departamento X\u0026rdquo;, não \u0026ldquo;está no grupo Y que criamos pra representar o departamento X\u0026rdquo;) Minha ressalva: depender de atributo sincronizado externamente introduz uma superfície de falha que grupo nativo do Unity Catalog não tem, se a sincronização com o Entra ID atrasar ou falhar silenciosamente, a política de máscara pode aplicar a regra errada sem nenhum alerta óbvio. Eu monitoraria a saúde dessa sincronização com o mesmo rigor que já dedico à política em si.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/release-notes/product/2026/august\n#AzureDatabricks #UnityCatalog #EntraID\n","permalink":"https://wiliamrosa.github.io/posts/azure-databricks-identity-attributes-abac-entra-id/","summary":"Identity Attributes deixa políticas ABAC do Unity Catalog usarem atributos sincronizados do seu provedor de identidade, departamento, país, sem precisar recriar isso como grupo.","title":"Suas políticas de máscara de coluna agora podem confiar direto no Entra ID"},{"content":"O que a Databricks anunciou A Databricks compartilhou como controla internamente o gasto de milhares de engenheiros que usam coding agents diariamente, hoje uma das linhas de custo de P\u0026amp;D que mais cresce. A solução foi dividir o problema em dois orçamentos com propósitos diferentes:\nUm orçamento diário, que barra gasto descontrolado (runaway spend), com aumento self-service quando o uso é claramente intencional. Um orçamento mensal, que governa gasto extraordinário, com aumentos por projeto e aprovação do gestor. Como todo coding agent passa pelo Unity AI Gateway, os mesmos controles valem para qualquer ferramenta e modelo, com o uso medido em um único lugar. O objetivo declarado não é frear a adoção de IA, é manter o gasto visível e controlado enquanto se dá espaço para os engenheiros construírem.\nFonte original: post da Databricks no LinkedIn\nPor que isso importa na prática A maioria dos times que conheço trata gasto com IA generativa com um único limite genérico (ou nenhum limite, até a fatura assustar alguém). O insight aqui é sutil, mas relevante: um único orçamento tenta resolver dois problemas com naturezas opostas ao mesmo tempo, pegar erro/abuso rápido (que precisa de um limite curto e sensível, o diário) e permitir investimento real em um projeto que legitimamente precisa de mais IA (que precisa de um processo de aprovação mais deliberado, o mensal). Um limite único acaba sendo ou frouxo demais para pegar abuso, ou rígido demais para permitir uso legítimo, a divisão em dois resolve as duas pontas ao mesmo tempo.\nMinha opinião Esse é o tipo de anúncio \u0026ldquo;pequeno\u0026rdquo; que, na minha visão, tem mais aplicação prática imediata do que a maioria dos lançamentos de produto desta lista, porque qualquer time, usando Databricks ou não, pode copiar a lógica de dois orçamentos amanhã, independente de ferramenta. Não depende de comprar Unity AI Gateway, depende de entender que \u0026ldquo;limite de gasto com IA\u0026rdquo; não é um número único, são dois problemas diferentes.\nO que eu adicionaria, com o chapéu de quem pensa em governança: a divisão diário/mensal ataca bem o quanto se gasta, mas não necessariamente o com o quê. Um agente pode ficar dentro do orçamento diário e ainda assim gastar tokens em tarefas de baixo valor, refatorar código que não precisava, ou repetir chamadas em loop por um prompt mal ajustado. Orçamento é controle financeiro; qualidade de uso é um problema de observabilidade e cultura de engenharia, que nenhum limite de gasto resolve sozinho.\nAinda assim, é um relato honesto vindo de quem realmente opera a escala descrita, e vale mais do que a maioria dos artigos genéricos de \u0026ldquo;FinOps para IA\u0026rdquo; que circulam por aí.\nPara saber mais Post original: https://www.databricks.com/blog/how-databricks-manages-its-own-coding-agent-spend-unity-ai-gateway-budgets Documentação oficial do Databricks: https://docs.databricks.com/ ","permalink":"https://wiliamrosa.github.io/posts/databricks-governanca-gastos-ia-coding-agents/","summary":"A Databricks dividiu o controle de gasto com IA em orçamento diário e mensal, cada um resolvendo um problema diferente. É um case interno pequeno, mas com uma lição de FinOps que qualquer time de engenharia pode copiar hoje.","title":"Como a própria Databricks controla o gasto de milhares de engenheiros usando coding agents"},{"content":"A própria Databricks tinha um problema que a maioria dos times de engenharia finge não ter: gasto de coding agents crescendo rápido demais pra caber num único limite.\nA solução interna que eles compartilharam foi dividir o orçamento em dois:\nOrçamento diário: pega gasto descontrolado rápido, com aumento self-service quando o uso é claramente legítimo Orçamento mensal: governa gasto extraordinário, com aprovação do gestor por projeto Como todo agente passa pelo mesmo gateway, o controle vale pra qualquer ferramenta e modelo, sem depender de qual agente cada time escolheu usar.\nO que eu adicionaria: essa divisão resolve muito bem o \u0026ldquo;quanto\u0026rdquo; se gasta, mas não o \u0026ldquo;com o quê\u0026rdquo;. Um agente pode ficar dentro do orçamento e ainda assim gastar tokens em tarefa de baixo valor. Limite de gasto é controle financeiro, qualidade de uso ainda depende de observabilidade e cultura de engenharia.\nFonte: https://www.databricks.com/blog/how-databricks-manages-its-own-coding-agent-spend-unity-ai-gateway-budgets\n#Databricks #FinOps #EngenhariaDeIA\n","permalink":"https://wiliamrosa.github.io/posts/linkedin-governanca-gasto-ia-dual-budget/","summary":"Por que dividir o controle de gasto com IA em orçamento diário e mensal resolve dois problemas que um limite único não resolve sozinho.","title":"Um orçamento só não basta para controlar gasto com IA"},{"content":"O maior gargalo pra escalar o Genie dentro de uma empresa nunca foi a experiência de fazer pergunta em linguagem natural, foi o trabalho manual de criar cada Genie Space.\nO Databricks MVP Aarni Sillanpää encarou esse problema de frente: usou o Agent Bricks Multi-Agent Supervisor com sete funções do Unity Catalog empacotadas como ferramentas, mais um agente Knowledge Assistant, pra descobrir dados automaticamente, criar Genie Spaces, aplicar descrição de política da empresa, e atualizar ou apagar spaces existentes, tudo via chamada de API REST e system tables, sem precisar escrever código de agente customizado do zero.\nA prova de conceito mostrou algo importante: o supervisor conseguiu criar um space novo a partir de descoberta dinâmica de dado no Unity Catalog e, na sequência, usar esse mesmo space recém-criado sem precisar de nenhuma reconfiguração manual. Deletar space também funcionou, mas acionou barreiras de segurança no caminho, sinal de que o sistema não deixa a ação mais destrutiva passar sem fricção.\nPontos que valem destacar:\nSete funções do Unity Catalog fazem o trabalho pesado, sem exigir agente customizado escrito do zero Criação, atualização e exclusão de Genie Space viraram operação orquestrada, não clique manual repetido A automação de exclusão esbarrou em guardrails de segurança, o que é bom sinal, não falha Minha ressalva: o próprio autor é claro que essa é uma prova de conceito, não algo pronto pra produção sem trabalho adicional de observabilidade e controle de segurança mais rígido. Orquestrar criação de Genie Space automaticamente é ótimo pra escala, mas também significa que um erro de escopo na automação cria (ou apaga) space errado em lote, não um de cada vez. Vale testar em ambiente controlado antes de apontar isso pra um catálogo de produção inteiro.\nFonte: https://www.ikidata.fi/post/automating-genie-management-with-agent-bricks-supervisor\n#Databricks #Genie #AgentBricks\n","permalink":"https://wiliamrosa.github.io/posts/databricks-genie-spaces-agent-bricks-supervisor/","summary":"Um MVP usou o Agent Bricks Multi-Agent Supervisor pra criar, atualizar e apagar Genie Spaces automaticamente, sem escrever código de agente do zero.","title":"Criar Genie Space parou de ser trabalho manual de clicar em tela"},{"content":"Escolher manualmente qual modelo usar em cada tarefa de código é trabalho que já devia ter virado automático.\nA Databricks lançou o Smart Routing dentro do Unity AI Gateway, um roteador que decide sozinho qual modelo chamar pra cada tarefa de codificação, sem o desenvolvedor precisar trocar de modelo na mão. A ideia central é que boa parte do trabalho de agente de código, corrigir erro de sintaxe, ajustar import, escrever teste simples, não precisa do modelo mais caro disponível, e mandar tudo pro modelo de ponta é desperdício.\nO roteador usa um classificador leve que olha o componente do sistema envolvido, a evidência no código, o padrão da falha e onde a correção provavelmente precisa acontecer, e a partir disso decide entre escalar pra um modelo mais forte ou descer pra um mais barato. Essa decisão acontece no nível da sessão inteira, não a cada chamada isolada, justamente pra não quebrar cache de contexto no meio de uma tarefa.\nPontos técnicos que valem atenção:\nFunciona nativamente dentro do Claude Code e do Codex, sem mudança de fluxo pro time Integra com o Omnigent pra otimizar a escolha entre múltiplos harnesses de agente Benchmark interno da Databricks reportou 35% de economia mantendo qualidade equivalente Benchmark público citado aponta até 56% de economia de custo mantendo resultado perto do Opus 5, com claim de até 65% de redução de custo por tarefa Minha ressalva: todo número de economia divulgado aqui vem de benchmark da própria Databricks, e roteamento automático erra quando a tarefa é ambígua, o risco real é escalar tarde demais numa tarefa que parecia simples e não era. Vale medir taxa de re-trabalho, não só custo por chamada, antes de confiar o roteamento sem supervisão num pipeline crítico.\nFonte: https://www.databricks.com/blog/smart-routing-unity-ai-gateway-match-frontier-quality-30-lower-cost-task\n#Databricks #UnityAIGateway #IAGenerativa\n","permalink":"https://wiliamrosa.github.io/posts/unity-ai-gateway-smart-routing/","summary":"Smart Routing no Unity AI Gateway classifica cada tarefa de codificação e escolhe automaticamente entre modelo mais barato ou mais caro, com ganho reportado de até 65% de economia mantendo qualidade próxima do Opus 5.","title":"Unity AI Gateway ganhou roteamento automático de modelo pra tarefa de código"},{"content":"Todo cluster serverless que sobe precisa de uma coisa bem chata de garantir em escala: rede configurada corretamente antes da primeira linha de código do usuário rodar. Firewall, rota, isolamento entre workspaces, tudo isso precisa estar pronto no instante em que a VM liga. Quando esse processo depende de perguntar pra vários serviços \u0026ldquo;qual é a configuração de rede desse workspace agora\u0026rdquo;, cada VM nova vira uma cadeia de chamadas síncronas. Em escala de milhares de VMs por hora isso é irritante mas tolerável. Em escala de dezenas de milhões por dia, vira o tipo de gargalo que aparece direto no painel de incidentes.\nO problema com o caminho síncrono A arquitetura anterior, segundo o que a Databricks descreveu, fazia com que cada cluster buscasse sua configuração de rede consultando múltiplos serviços upstream no momento em que precisava dela. Isso funciona bem sob baixa carga, mas cria dependência direta entre a disponibilidade desses serviços upstream e a disponibilidade do próprio provisionamento de compute. Se um desses serviços está lento ou sobrecarregado, o efeito se propaga direto pro tempo de start do cluster. Os números publicados mostram o tamanho do problema: latência p99 de cerca de 5.000 milissegundos e disponibilidade de 99,8%, que parece alto até você fazer a conta de quantas tentativas falham por dia numa base de dezenas de milhões.\nA separação entre caminho de gerenciamento e caminho de atendimento A mudança central é conceitualmente simples de explicar, mesmo sendo complexa de implementar: separar o que muda raramente (configuração de rede de um workspace) do que precisa responder em tempo real (uma VM pedindo sua configuração agora).\nO desenho publicado tem quatro peças:\nManagement path (background): serviços upstream emitem eventos sempre que algo relevante muda (workspace criado, política de rede alterada, etc). Esses eventos vão pra uma fila de mensagens. Event processing: um processador consome a fila, determina quais workspaces foram afetados pela mudança e dispara a atualização correspondente. Snapshot store: a configuração já pré-computada fica armazenada localmente, pronta pra ser lida sem nenhuma dependência externa. Serving path (crítico): quando um cluster novo precisa de configuração de rede, ele faz uma única leitura no snapshot store. Nada de chamada síncrona a serviço upstream nesse caminho. Como rede de segurança contra eventos perdidos ou processados fora de ordem, existe um reconciliador periódico que resincroniza workspaces de tempos em tempos, garantindo que divergência entre o estado real e o snapshot não vire permanente.\nPor que isso é mais que só \u0026ldquo;trocar sync por async\u0026rdquo; Minha leitura: esse tipo de refatoração de arquitetura interna raramente vira post de blog porque não tem feature nova pra anunciar, mas é exatamente esse tipo de trabalho que decide se uma plataforma aguenta escalar em ordem de grandeza sem reescrever tudo de novo daqui a dois anos. Separar caminho de leitura crítico do caminho de escrita/atualização é um padrão clássico de sistemas distribuídos (CQRS, na essência), mas aplicado aqui numa camada que a maioria dos usuários nunca vai ver ou pensar sobre: provisionamento de rede de VM.\nO ganho reportado de 86% na redução do volume de chamadas upstream é o número que mais me chama atenção, porque ele indica que o gargalo não era só latência, era também carga desnecessária empurrada repetidamente pros mesmos serviços a cada novo cluster, mesmo quando a configuração de rede do workspace não tinha mudado nada desde a última vez.\nMão na massa: o padrão aplicado ao seu próprio sistema Você não implementa essa arquitetura específica do Azure Databricks, mas o padrão é replicável em qualquer sistema seu que sofre do mesmo problema: leitura frequente de configuração que muda raramente. Um esqueleto simplificado em Python usando um cache local atualizado por evento, em vez de consulta síncrona a cada leitura:\nimport json import threading from pathlib import Path class ConfigSnapshotStore: def __init__(self, snapshot_path: str): self._path = Path(snapshot_path) self._lock = threading.RLock() self._cache = {} self._load() def _load(self): with self._lock: if self._path.exists(): self._cache = json.loads(self._path.read_text()) def get(self, workspace_id: str) -\u0026gt; dict | None: # caminho crítico: leitura local, sem chamada de rede with self._lock: return self._cache.get(workspace_id) def apply_event(self, workspace_id: str, config: dict): # caminho de gerenciamento: só roda quando um evento chega with self._lock: self._cache[workspace_id] = config self._path.write_text(json.dumps(self._cache)) A ideia central: nenhuma leitura no caminho crítico depende de rede externa, e toda escrita vem de um evento processado de forma assíncrona, desacoplada do momento em que alguém precisa ler.\nO papel do reconciliador como rede de segurança Vale dedicar um parágrafo só pro reconciliador periódico, porque é essa peça que separa \u0026ldquo;arquitetura orientada a eventos elegante\u0026rdquo; de \u0026ldquo;arquitetura orientada a eventos que quebra silenciosamente quando um evento se perde\u0026rdquo;. Fila de mensagens pode ter mensagem duplicada, mensagem entregue fora de ordem, ou, em cenário de falha real, mensagem perdida. Se o snapshot store dependesse cegamente de cada evento chegar e ser processado corretamente, uma falha isolada de infraestrutura poderia deixar um workspace com configuração de rede desatualizada por tempo indefinido, sem ninguém perceber até um cluster começar a falhar de forma misteriosa. O reconciliador resolve isso varrendo periodicamente o estado real dos serviços upstream e comparando com o snapshot local, corrigindo divergência antes que ela vire incidente visível. É o tipo de componente que raramente aparece em diagrama de arquitetura chamativo, mas que decide se o sistema é confiável o suficiente pra rodar sem intervenção manual.\nO que isso não resolve Arquitetura orientada a eventos troca um problema (latência síncrona) por outro (consistência eventual). Existe uma janela, ainda que pequena, entre uma mudança de configuração de rede acontecer e o snapshot local refletir isso. Pra a maioria dos casos de provisionamento de VM isso é aceitável, porque o reconciliador periódico cobre a divergência residual, mas é uma escolha explícita de trade-off, não um almoço grátis. Também vale lembrar que esse tipo de solução exige uma fila de mensagens confiável e um processador de eventos que não pode virar, ele mesmo, um novo ponto único de falha, o que a Databricks não detalhou em profundidade no post original. Quem for replicar esse padrão internamente precisa pensar explicitamente em como monitorar o próprio pipeline de eventos, não só o sistema final que consome o snapshot, porque um processador de eventos travado silenciosamente é exatamente o tipo de falha que some do radar até o reconciliador (se existir um) sinalizar divergência.\nResumindo A troca de chamada síncrona por pipeline orientado a eventos pra configuração de rede de VMs serverless é um lembrete de que, em escala suficiente, todo caminho crítico de leitura deveria estar desacoplado de qualquer dependência que pode estar lenta ou fora do ar no momento exato em que você precisa dela. Não é feature de produto, é fundação de infraestrutura, mas é esse tipo de fundação que sustenta o SLA que a Databricks vende pra quem roda workload em produção.\nReferências Databricks network configuration: delivery to tens of millions of serverless VMs (blog oficial Databricks) Serverless compute plane networking (documentação oficial) Serverless compute plane networking (Microsoft Learn) #Databricks #Serverless #Arquitetura #Engenharia\n","permalink":"https://wiliamrosa.github.io/articles/arquitetura-event-driven-configuracao-rede-serverless/","summary":"A Databricks trocou um caminho de configuração de rede baseado em chamadas síncronas a múltiplos serviços por um pipeline assíncrono orientado a eventos, separando o caminho de gerenciamento do caminho de atendimento crítico. O resultado publicado: latência p99 caindo de cerca de 5 segundos pra 125 milissegundos e disponibilidade subindo de 99,8% para 99,99%.","title":"Quando a chamada síncrona vira gargalo em escala de dezenas de milhões de VMs por dia"},{"content":"E se o histórico de uso do seu workspace Databricks fosse suficiente pra construir um agente que pensa como você?\nO Databricks MVP Aarni Sillanpää construiu o Databricks Digital Persona, um projeto que lê 90 dias de atividade em mais de 8 system tables (auditoria, histórico de query, execução de job, dado de billing) através de 15 etapas de análise, e usa isso pra classificar o usuário entre arquétipos de comportamento (algo como \u0026ldquo;arquiteto de pipeline\u0026rdquo;, \u0026ldquo;explorador de dado\u0026rdquo;, \u0026ldquo;guardião de plataforma\u0026rdquo;) e gerar um perfil com badges de conquista.\nA parte mais curiosa é o passo seguinte: o projeto usa esse perfil pra montar um system prompt em primeira pessoa que captura a personalidade e a especialidade técnica de quem gerou os dados, criando um \u0026ldquo;gêmeo digital\u0026rdquo; com quem dá pra conversar diretamente dentro de um app Databricks. Tecnicamente, roda como Databricks App com autenticação on-behalf-of-user, ou seja, cada consulta às system tables acontece sob a permissão de quem está usando, sem credencial compartilhada.\nO que chama atenção no projeto:\nNenhum dado sai do workspace, a análise inteira acontece em cima de system tables que já existem Autenticação OBO garante isolamento: cada usuário só vê o próprio histórico, nunca o de outra pessoa O projeto tem 90 testes cobrindo pontuação, segurança, isolamento de dado e rotas, sinal de que não é só uma prova de conceito descartável Minhas considerações: o valor real disso não é o gêmeo digital em si, é lembrar que system tables guardam muito mais sinal comportamental do que a maioria dos times usa. A maior parte das empresas trata query history e billing como dado só de auditoria ou custo, quando dá pra extrair daí padrão de uso, especialização de time e até risco de dependência de uma única pessoa em um pipeline crítico. Vale menos pelo gêmeo digital e mais pelo lembrete: você provavelmente está sentado em cima de mais dado de comportamento do que imagina.\nFonte: https://github.com/ikidata/databricks-digital-persona\n#Databricks #SystemTables #AIAgents\n","permalink":"https://wiliamrosa.github.io/posts/databricks-digital-twin-system-tables/","summary":"O projeto Databricks Digital Persona lê 90 dias de system tables (query history, jobs, billing, auditoria) e usa isso pra construir um agente que conversa como se fosse você.","title":"Um MVP transformou o próprio histórico de uso do Databricks num gêmeo digital"},{"content":"Rodar um banco Postgres inteiro dentro do sandbox de um agente de IA, sem depender de rede, é a aposta por trás da aquisição da Electric.\nA Databricks anunciou a aquisição da Electric, empresa por trás do PGlite, um Postgres compilado para WebAssembly que roda embutido dentro de aplicação ou sandbox, sem precisar de servidor externo. A Electric também mantém um motor de sincronização em tempo real que mantém esse banco embutido consistente com uma fonte central.\nA lógica por trás da compra é que agente de IA não se comporta como aplicação tradicional: ele roda em ambiente isolado e efêmero, muitas vezes vários ao mesmo tempo, e precisa de estado rápido e local sem abrir mão de auditoria depois. A arquitetura que a Databricks está montando usa PGlite como banco leve dentro de cada sandbox de agente, cuidando do contexto imediato daquela execução, enquanto o motor de sincronização da Electric espelha continuamente esse estado de volta pro Lakebase central, que vira o repositório durável e governado.\nPontos técnicos que valem registrar:\nPGlite é um Postgres compilado para WASM, e cresceu de 1 milhão para 13 milhões de downloads semanais em 12 meses Arquitetura de duas camadas: PGlite local no sandbox do agente, Lakebase central como fonte de verdade durável Sincronização contínua entre o banco embutido e o Lakebase, sem a aplicação precisar orquestrar isso manualmente Pensado para workflow multiagente, onde cada sandbox precisa de contexto rápido sem esperar round-trip de rede Minhas considerações: aquisição de infraestrutura de banco embutido é um sinal claro de para onde a Databricks está apontando o Lakebase, não só banco operacional pra aplicação, mas peça de infraestrutura pra agente que precisa de estado rápido, descartável e ainda assim auditável depois. Vale acompanhar se essa camada local vai expor as mesmas garantias de governança do Unity Catalog, ou se vira um ponto cego até sincronizar de volta pro Lakebase.\nFonte: https://www.databricks.com/blog/electric-joins-databricks-bring-wasm-postgres-ai-agent-sandboxes\n#Databricks #Lakebase #AgentesDeIA\n","permalink":"https://wiliamrosa.github.io/posts/databricks-adquire-electric-pglite-lakebase/","summary":"A Databricks adquiriu a Electric, criadora do PGlite, um Postgres compilado para WebAssembly que roda embutido dentro de sandbox de agente, sincronizado em tempo real com o Lakebase central.","title":"Databricks compra a Electric e leva Postgres em WASM pra dentro do sandbox de agente"},{"content":"O Databricks MVP Hubert Dudek destacou uma flag útil pra quem prefere trabalhar num IDE local mas em algum momento precisa editar um ativo direto no Databricks: o --watch dos bundles resolve exatamente esse cenário, sincronizando a mudança feita no workspace de volta pro seu IDE local, automaticamente.\nÉ o problema espelhado do que resolvi comentar sobre o source-linked deployment: lá, a UI edita e o YAML do bundle acompanha; aqui, é o desenvolvedor local que às vezes precisa ir até o workspace fazer um ajuste rápido, sem perder a referência de que o código \u0026ldquo;de verdade\u0026rdquo; mora no IDE. Sem uma flag como essa, esse tipo de edição pontual no workspace vira uma mudança órfã, que alguém eventualmente sobrescreve sem querer no próximo deploy.\nPor que isso resolve um atrito real de quem já usa bundles no dia a dia:\nElimina a necessidade de copiar manualmente uma mudança feita no workspace de volta pro arquivo local Reduz o risco clássico de \u0026ldquo;esqueci de levar essa correção pro Git e ela sumiu no próximo deploy\u0026rdquo; Complementa (não substitui) a disciplina de sempre revisar o diff antes de comitar Minha ressalva: sincronização automática em qualquer direção (workspace → local, ou local → workspace) sempre carrega o mesmo risco, ela facilita esquecer de revisar o que realmente mudou. --watch é uma ferramenta de produtividade, não um substituto para olhar o diff no Git antes de assumir que uma alteração feita \u0026ldquo;rapidinho\u0026rdquo; no workspace está correta.\nFonte: https://www.linkedin.com/posts/hubertdudek_dabs-if-you-like-to-work-in-a-local-ide-activity\n#Databricks #DeclarativeAutomationBundles #DevOps\n","permalink":"https://wiliamrosa.github.io/posts/databricks-dabs-watch-flag-sincroniza-ide-local/","summary":"Quem prefere trabalhar num IDE local mas às vezes precisa editar ativo direto no Databricks agora tem uma flag que sincroniza essa mudança de volta pro projeto local.","title":"A flag --watch dos bundles resolve o problema de editar no Databricks mas viver no seu IDE local"},{"content":"O Databricks MVP Hubert Dudek chamou atenção pra uma mudança de convenção que passa fácil despercebida: o Databricks Runtime 18 é o primeiro a usar um formato unificado de release notes. Em vez de cada versão menor (18.0, 18.1, 18.2\u0026hellip;) ganhar sua própria página, toda novidade, mudança de comportamento e correção entra como uma atualização datada na mesma página do Runtime 18, sem trocar o número da versão.\nIsso resolve um atrito pequeno, mas constante, de quem mantém Databricks Asset Bundles e pipelines de CI/CD apontando pra uma versão específica de runtime: a pergunta recorrente \u0026ldquo;espera, era 18.2 ou 18.3 que tinha essa feature?\u0026rdquo; simplesmente deixa de fazer sentido, o que antes seria uma versão menor nova agora é só mais uma entrada datada na mesma página.\nPor que essa mudança de convenção importa na prática:\nElimina a necessidade de decorar em qual sub-versão uma feature específica apareceu Simplifica o pin de versão em bundle/YAML: \u0026ldquo;18.x\u0026rdquo; cobre o runtime inteiro, sem se preocupar em qual \u0026ldquo;sub-release\u0026rdquo; está rodando Times que documentam internamente \u0026ldquo;qual runtime usar\u0026rdquo; ganham uma única referência viva em vez de várias páginas históricas fragmentadas Minha ressalva: unificar a documentação por trás de um único número de versão facilita a vida de quem lê, mas exige mais disciplina de quem escreve testes de regressão, se uma mudança \u0026ldquo;menor\u0026rdquo; já não gera uma versão nova identificável, o time precisa confiar mais em pipeline de teste automatizado e menos em \u0026ldquo;só travar numa versão que já testamos e sabemos que funciona\u0026rdquo;.\nFonte: https://docs.databricks.com/aws/en/release-notes/runtime/18\n#Databricks #DatabricksRuntime #DevOps\n","permalink":"https://wiliamrosa.github.io/posts/databricks-runtime-18-lts-nova-convencao/","summary":"A partir do Runtime 18, a Databricks unificou as release notes: sem mais versão menor pra decorar, features novas chegam como atualizações datadas na mesma página.","title":"Databricks Runtime 18 virou LTS e matou a pergunta '18.1 ou 18.2?'"},{"content":"O Databricks MVP Awadelrahman Ahmed descreve bem o padrão que se repete no MLflow 3.15, que trouxe o MCP Registry: modelo virou ativo compartilhado que times precisam versionar e promover, depois prompt seguiu o mesmo caminho, e agora servidor MCP está indo na mesma direção. Um MCP Registry só faz diferença real quando várias equipes já compartilham os mesmos servidores MCP, pra quem usa um ou dois sozinho, é overhead desnecessário.\nA versão também trouxe outras mudanças que, juntas, mostram pra onde o MLflow está indo: suporte a Claude Code e Codex no MLflow Assistant, com visibilidade de chamadas de ferramenta, aprovações e custo de token durante a execução; juízes multimodais capazes de avaliar imagem dentro de traces, não só texto; visualizações compartilháveis de tabela de execuções (defina coluna, filtro e ordenação uma vez, compartilhe o link); e transferência de artefato sem proxy, relevante pra quem lida com artefato grande.\nPor que essa versão é mais significativa do que um changelog qualquer:\nServidor MCP virar \u0026ldquo;ativo organizacional com registro\u0026rdquo; é reconhecimento de que múltiplos agentes dentro da mesma empresa já compartilham as mesmas ferramentas, e isso precisa de governança, não só configuração local Visibilidade de chamada de ferramenta, aprovação e custo de token durante a execução do assistant é exatamente o tipo de observabilidade que falta na maioria dos fluxos de agente hoje Juiz multimodal fecha uma lacuna real: avaliação de agente que trabalha com imagem não tinha, até aqui, um jeito nativo de ser avaliada automaticamente Minha ressalva: \u0026ldquo;registro para servidor MCP\u0026rdquo; resolve o problema de descoberta e versionamento, mas não resolve sozinho a pergunta mais difícil de governança de MCP, quem decide qual time pode usar qual servidor, com qual escopo de permissão. Um registro sem uma camada de política de acesso por cima é só um catálogo bem organizado; a parte difícil de \u0026ldquo;quem pode usar o quê\u0026rdquo; continua em aberto.\nFonte: https://www.linkedin.com/in/awadelrahman/\n#Databricks #MLflow #MCP\n","permalink":"https://wiliamrosa.github.io/posts/mlflow-3-15-mcp-registry-databricks/","summary":"O MCP Registry é o terceiro \u0026lsquo;primo\u0026rsquo; da família Registry do MLflow, depois de Model e Prompt. O Databricks MVP Awadelrahman Ahmed detalha essa e outras novidades da versão 3.15.","title":"MLflow 3.15 trata servidor MCP como ativo organizacional, não mais config local de cada um"},{"content":"O Databricks MVP Hubert Dudek detalhou uma mudança na forma como segredos são armazenados no Databricks: agora dá pra guardá-los no Unity Catalog, usando a convenção de namespace de três níveis, em vez de ficarem presos ao nível de workspace como sempre foi.\nO que chama atenção não é só \u0026ldquo;onde\u0026rdquo; o segredo mora, é a granularidade de permissão nova que vem junto. Além do já conhecido READ SECRET, existe agora REFERENCE SECRET, pensado especificamente para cenários em que o segredo precisa ser usado por outros serviços do Databricks, como Lakeflow Connections, sem que isso implique acesso programático direto ao valor do segredo. Ler o segredo dentro de um notebook continua sendo feito da forma de sempre, via dbutils.secrets.get.\nPor que essa distinção de permissão é o ponto mais importante da mudança:\nREAD SECRET e REFERENCE SECRET resolvem problemas diferentes: um dá acesso ao valor bruto, o outro só permite que um serviço use o segredo sem expô-lo Isso fecha uma lacuna real de governança: antes, dar acesso pra um conector usar uma credencial praticamente exigia dar acesso de leitura ao segredo também Segredo virar objeto do Unity Catalog significa herdar o mesmo modelo de permissão e auditoria que já existe pro resto dos dados, não é mais uma ilha de governança à parte Minha ressalva: mover segredo de workspace pra catálogo é uma migração de superfície de risco, não só uma mudança de local de armazenamento, quem administra hoje via escopo de workspace precisa mapear cuidadosamente qual segredo vira REFERENCE SECRET versus READ SECRET antes de migrar, porque errar essa distinção pode tanto quebrar uma integração legítima quanto abrir acesso mais amplo do que pretendido.\nFonte: https://www.linkedin.com/in/hubertdudek/\n#Databricks #UnityCatalog #Segurança\n","permalink":"https://wiliamrosa.github.io/posts/databricks-unity-catalog-secrets-namespace-catalogo/","summary":"Segredos agora podem viver no nível de catálogo, com um namespace de três níveis e uma permissão nova (REFERENCE SECRET) pensada especificamente para serviços como Lakeflow Connections.","title":"Segredos saem do nível de workspace e viram ativo governado no Unity Catalog"},{"content":"Tag automatizada finalmente chegou no Unity Catalog, e a parte mais interessante não é a automação em si, é como você a configura.\nO Databricks MVP Ajay Kumar Pandey destacou o Tag Automation logo na semana em que saiu do papel: um jeito de manter tag correta sem depender de alguém lembrar de atualizar manualmente toda vez que uma tabela muda de dono, fica obsoleta ou passa a carregar dado sensível.\nO mecanismo funciona assim: você define condições (tag existente, contagem de query, data de criação ou modificação, dono, existência de descrição, correspondência de nome) e o automation aplica ou remove tags governadas com base nelas, de forma recorrente. A parte que chama atenção é que, em vez de escrever a regra manualmente, dá pra descrever em linguagem natural e deixar o Genie montar o escopo, a condição e a ação, tudo revisável antes de salvar.\nAlguns limites valem nota pra quem for testar:\nCada execução processa no máximo 500 ativos, e uma automação atribui ou remove no máximo 5 tags governadas por vez O escopo é sempre um catálogo só, sem abranger múltiplos catálogos numa regra Automação é separada entre tabelas OU volumes, nunca os dois juntos Exige privilégios específicos: USE CATALOG, USE SCHEMA, APPLY TAG, MANAGE no catálogo alvo, mais ASSIGN em cada tag que a automação toca Minha ressalva: deixar o Genie escrever a regra a partir de uma descrição em linguagem natural é conveniente, mas ainda é código de governança rodando sozinho, revisar o resultado antes de salvar não é opcional, é o único ponto de controle humano que sobra nesse fluxo. Automação de tag errada tem o mesmo efeito de qualquer automação errada: silenciosa até alguém descobrir tarde demais.\nFonte: https://docs.databricks.com/aws/en/admin/governed-tags/automate-tag-assignment\n#Databricks #UnityCatalog #DataGovernance\n","permalink":"https://wiliamrosa.github.io/posts/databricks-unity-catalog-tag-automation-beta/","summary":"Tag Automation (Beta) deixa o Unity Catalog aplicar e remover tags governadas sozinho, com base em regras que você descreve em linguagem natural pro Genie construir.","title":"Tag Automation chega ao Unity Catalog, e você pode descrever a regra em português"},{"content":"Documento, imagem, áudio e vídeo agora podem virar coluna de tabela no Databricks, não só referência solta num storage.\nA Databricks lançou o tipo FILE, um tipo de coluna nativo, ainda em beta, pensado para dado não estruturado dentro de tabela Delta ou Iceberg. Em vez de guardar o binário inteiro dentro da tabela, a coluna guarda uma referência leve para o arquivo, e o conteúdo só é carregado quando uma consulta realmente precisa dele.\nO motivo de existir é mais sobre governança do que sobre armazenamento. Hoje, quem guarda caminho de arquivo como string de URL depende de permissão de pasta, que vive fora do controle de acesso da tabela, então documento e imagem acabam com um modelo de permissão paralelo ao dos dados estruturados. Com FILE, a mesma política de linha, coluna e ABAC do Unity Catalog passa a valer também para o arquivo, incluindo a exclusão em cascata: apagar a linha apaga o binário correspondente no storage, o que ajuda bastante quem lida com pedido de exclusão sob LGPD ou GDPR.\nPontos técnicos que valem registrar:\nBeta, integra com Spark, Delta Lake e Apache Iceberg Controle de acesso a nível de linha, coluna e ABAC via Unity Catalog, aplicado também ao arquivo Deletar a linha remove o binário do storage automaticamente, sem processo separado de limpeza Funciona em SQL e em UDF Python, incluindo função de IA nativa como AI_PARSE_DOCUMENT Conectores prontos para SharePoint, Google Drive e storage em nuvem, com opção de referenciar arquivo sem mover ele Minha ressalva: unificar governança de dado estruturado e não estruturado numa mesma política é o tipo de promessa que só se prova em produção. Column-level ABAC pensado pra número e string é uma coisa, aplicar a mesma lógica a vídeo de gigabytes é outra, com implicação de custo e latência que o anúncio não detalha. Vale testar o comportamento de exclusão em cascata com cuidado antes de confiar nele como mecanismo único de conformidade.\nFonte: https://www.databricks.com/blog/introducing-file-type-native-column-type-multimodal-data\n#Databricks #UnityCatalog #DadosNaoEstruturados\n","permalink":"https://wiliamrosa.github.io/posts/databricks-file-type-dados-nao-estruturados/","summary":"A Databricks lançou o tipo FILE em beta: documento, imagem, áudio e vídeo agora podem virar coluna nativa de tabela, com a mesma governança de linha, coluna e ABAC do Unity Catalog aplicada também ao arquivo.","title":"FILE vira tipo de coluna nativo, e arquivo passa a ter dono e permissão como qualquer tabela"},{"content":"O que a Databricks anunciou A Databricks lançou a Databricks Certified Context Engineer Associate, descrita como a primeira certificação do mercado focada especificamente em context engineering. Junto com o exame, a Databricks Academy adicionou cursos sobre fundamentos de agentes, agentes de recuperação (retrieval) e avaliação de agentes, além de orientação oficial sobre como usar ferramentas de IA para se preparar para provas de certificação.\nFonte original: post da Databricks no LinkedIn\nPor que isso importa na prática \u0026ldquo;Context engineering\u0026rdquo; é um termo que ganhou força só nos últimos anos, à medida que ficou claro que o gargalo de aplicações com LLM raramente é o modelo em si, é o que você entrega para ele: que documentos, que ferramentas, que memória, em que ordem, com qual formatação. É uma disciplina que mistura recuperação de informação, design de prompt e arquitetura de dados, e até agora não tinha um corpo de conhecimento formalizado nem uma forma padronizada de comprovar competência nela.\nFormalizar isso como certificação é a Databricks dizendo, essencialmente: \u0026ldquo;isso já não é mais só uma técnica de quem experimenta bastante, é uma disciplina que se ensina e se avalia.\u0026rdquo;\nMinha opinião Como Databricks Certified, acompanho de perto como a Databricks decide o que vira certificação, normalmente é sinal de que uma habilidade amadureceu o suficiente para ter um corpo de conhecimento estável. Esse lançamento em particular me interessa mais pessoalmente do que os outros desta lista, porque toca direto na minha trajetória: comecei documentando publicamente minha jornada de certificação com o DP-750, e context engineering é exatamente a próxima fronteira de habilidade que sinto crescer entre quem já domina os fundamentos de dados e ML.\nMeu único ponto de cautela: certificações de área tão nova correm o risco de ficar desatualizadas rápido, porque as melhores práticas de context engineering ainda estão mudando mês a mês, o que era \u0026ldquo;boa prática\u0026rdquo; para montar contexto para um agente há seis meses hoje já mudou com harnesses como Omnigent (que também comento nesta série) entrando em cena. Vou estudar o conteúdo programático antes de recomendar para quem pergunta no São Paulo Databricks User Group, mas o instinto inicial é que vale a pena, é a certificação da lista que mais tenho vontade de tirar eu mesmo.\nPara saber mais Post original: https://lnkd.in/gtKywV4k Documentação oficial do Databricks: https://docs.databricks.com/ ","permalink":"https://wiliamrosa.github.io/posts/databricks-certificacao-context-engineer-associate/","summary":"A nova certificação Databricks Certified Context Engineer Associate formaliza uma habilidade que, até pouco tempo atrás, nem tinha nome. Como alguém que vive de certificação Databricks, essa é a que mais me chamou atenção este ano.","title":"Nasce a certificação Context Engineer Associate: o que isso diz sobre o futuro das certificações Databricks"},{"content":"O que a Databricks anunciou A Databricks anunciou a disponibilidade geral (GA) do Unity AI Gateway, o hub central de governança para todo ativo de IA da organização, modelos, agentes externos, servidores MCP, skills e assistentes de código. Segundo o anúncio, mais de um quatrilhão de tokens já passaram pelo gateway no último ano, com observabilidade de ponta a ponta e atribuição granular de custo por modelo, provedor, time e aplicação.\nO argumento da Databricks é simples: a era de gerenciar \u0026ldquo;um punhado de modelos\u0026rdquo; acabou. Agora se governa uma frota de agentes e aplicações que acessam dados, chamam ferramentas e agem sozinhos, e isso muda completamente o que \u0026ldquo;governança de IA\u0026rdquo; precisa cobrir.\nFonte original: post da Databricks no LinkedIn\nPor que isso importa na prática Quem administra Unity Catalog sabe que governança de dados já é, por si só, um trabalho contínuo: quem acessa o quê, com qual política de mascaramento, sob qual linhagem. O Unity AI Gateway está fazendo o mesmo movimento, só que para chamadas de modelo e execução de agente, tratando cada requisição de IA como um evento governável, com custo, política e auditoria, e não como uma chamada de API isolada e opaca.\nIsso conecta diretamente com outro anúncio recente da própria Databricks, sobre orçamento diário e mensal para controlar gastos de coding agents internamente (que também comento neste outro post), ambos nascem do mesmo problema real: gasto de IA virou uma das linhas que mais cresce no orçamento de engenharia, e sem um ponto central de controle, ele se torna invisível até a fatura chegar.\nMinha opinião Esse é, na minha visão, o anúncio mais estruturalmente importante da lista que estou cobrindo nesta série, mais até do que os lançamentos de modelo. Ferramentas de IA generativa mudam de mês em mês; a necessidade de um plano de controle central para governar acesso, custo e comportamento de agentes é estrutural e vai continuar existindo independente de qual modelo estiver na moda.\nO ponto de atenção que eu levantaria para quem for adotar: centralizar tudo em um gateway cria um ponto único de dependência crítica. Vale perguntar como fica a resiliência (o que acontece se o gateway cair?) e como a Databricks trata multi-cloud e modelos hospedados fora do seu próprio ecossistema, a promessa é \u0026ldquo;todo ativo de IA\u0026rdquo;, mas a profundidade de governança tende a ser maior justamente para o que já vive dentro do Lakehouse.\nPara quem lidera comunidade e treina gente em Databricks, como eu, esse é o tipo de anúncio que muda o que ensino: já não basta explicar Unity Catalog para dados, é hora de incluir Unity AI Gateway como parte do currículo básico de governança.\nPara saber mais Post original: https://www.databricks.com/blog/unity-ai-gateway-generally-available Documentação oficial do Databricks: https://docs.databricks.com/ ","permalink":"https://wiliamrosa.github.io/posts/databricks-unity-ai-gateway-disponibilidade-geral/","summary":"Com a GA do Unity AI Gateway e mais de um quatrilhão de tokens já processados, a Databricks formaliza algo que quem trabalha com governança de dados já sentia: administrar agentes de IA é, antes de tudo, um problema de governança.","title":"Unity AI Gateway chega à disponibilidade geral: governança de IA deixou de ser opcional"},{"content":"Unity AI Gateway saiu de preview e virou GA, e o número que chama atenção não é o de clientes, é o de tokens: mais de 1 quatrilhão passaram pelo gateway no último ano.\nA ideia central: parar de tratar cada modelo/agente como uma integração isolada e trazer tudo, modelos, agentes externos, MCPs, skills, coding assistants, para um único plano de governança, com custo e observabilidade por time, projeto e aplicação.\nPor que isso importa mais do que parece:\nGerenciar \u0026ldquo;um punhado de modelos\u0026rdquo; já não é a realidade de ninguém Custo de IA virou uma das linhas que mais cresce em qualquer orçamento de engenharia Sem um ponto central, esse gasto só aparece quando a fatura assusta alguém Ponto que ainda quero ver resolvido: centralizar tudo em um gateway cria uma dependência crítica única. Vale perguntar como fica a resiliência se ele cair, e se a governança é igualmente profunda pra modelo fora do ecossistema Databricks.\nFonte: https://www.databricks.com/blog/unity-ai-gateway-generally-available\n#Databricks #UnityAIGateway #GovernançaDeIA\n","permalink":"https://wiliamrosa.github.io/posts/linkedin-unity-ai-gateway-ga/","summary":"Mais de 1 quatrilhão de tokens já passaram pelo gateway. O que isso diz sobre para onde vai a governança de IA nas empresas.","title":"Unity AI Gateway em GA: o número que importa não é de clientes, é de tokens"},{"content":"Depois que o coding agent virou ferramenta do dia a dia, a conta de IA generativa deixou de ser uma linha de orçamento marginal e virou uma das que mais cresce em qualquer time de engenharia. A reação mais comum é cortar acesso ou impor limite rígido, o que resolve o custo e cria um problema novo, engenheiro frustrado voltando a copiar e colar prompt manualmente numa aba do navegador porque a ferramenta oficial ficou capada. A Databricks descreveu um jeito diferente de atacar esse problema, focado em técnica, não em corte.\nO argumento central é que a maior parte do trabalho de coding agent não precisa do modelo mais inteligente disponível, precisa do modelo mais barato que ainda resolve a tarefa. Isso muda o problema de \u0026ldquo;quanto posso gastar\u0026rdquo; pra \u0026ldquo;como gasto menos por unidade de trabalho útil\u0026rdquo;, e é aí que entram as cinco técnicas.\nVale marcar uma diferença importante em relação a outro material que a própria Databricks já publicou sobre o mesmo assunto: existe um relato interno separado, mais focado em orçamento diário e mensal como controle financeiro puro (quanto o time pode gastar, com que processo de aprovação). Este aqui é o complemento técnico daquele, focado em quanto cada chamada custa por natureza, antes mesmo de qualquer orçamento entrar em ação. As duas peças resolvem partes diferentes do mesmo problema, e um time maduro em FinOps de IA generativa provavelmente precisa das duas ao mesmo tempo, não escolhe uma.\nO mecanismo: cinco alavancas, não uma bala de prata Seleção por fronteira de eficiência: em vez de sempre chamar o modelo de ponta, o sistema escolhe o modelo mais barato que ainda entrega qualidade aceitável pra aquela tarefa específica, reservando o modelo caro pra caso que realmente precisa de raciocínio pesado. Meta-harness com flexibilidade de modelo: uma camada de abstração (a Databricks chama a própria ferramenta interna de Omnigent) desacopla o harness de coding agent do modelo por trás, permitindo trocar de modelo sem que o engenheiro precise mudar de ferramenta ou de fluxo de trabalho. Roteamento dinâmico de requisição e tarefa: um sistema de Smart Routing decide, por requisição ou por tipo de tarefa, qual o modelo mais barato capaz de resolver aquilo, incluindo padrão de escalonamento pra modelo mais caro só quando o mais barato falha. A Databricks relata 30% de redução de custo mantendo qualidade equivalente. Visibilidade do desenvolvedor com fricção progressiva: em vez de bloqueio duro quando o orçamento acaba, o sistema usa dashboard de gasto visível pro próprio engenheiro, portão de autoliberação, e downshift de modelo (troca automática pra opção mais barata) em vez de suspensão total. Redução de overhead de token: compressão de contexto, harness mais eficiente e cache de prompt, com redução relatada de 50% no volume de token sem perda de qualidade percebida. Mão na massa: um roteador simples de custo por tarefa O princípio de roteamento dinâmico dá pra prototipar de forma simplificada assim, decidindo o modelo com base no tipo de tarefa antes de chamar a API via Unity Gateway:\nTAREFA_PARA_MODELO = { \u0026#34;autocomplete\u0026#34;: \u0026#34;modelo-pequeno-barato\u0026#34;, \u0026#34;revisao_pr\u0026#34;: \u0026#34;modelo-medio\u0026#34;, \u0026#34;refatoracao_grande\u0026#34;: \u0026#34;modelo-medio\u0026#34;, \u0026#34;debug_complexo\u0026#34;: \u0026#34;modelo-frontier\u0026#34;, } def escolhe_modelo(tipo_tarefa: str, tentativa: int = 1) -\u0026gt; str: modelo = TAREFA_PARA_MODELO.get(tipo_tarefa, \u0026#34;modelo-medio\u0026#34;) # escalonamento: se já falhou uma vez com o modelo barato, sobe de nível if tentativa \u0026gt; 1 and modelo != \u0026#34;modelo-frontier\u0026#34;: return \u0026#34;modelo-frontier\u0026#34; return modelo def chama_coding_agent(tipo_tarefa: str, prompt: str, tentativa: int = 1): modelo = escolhe_modelo(tipo_tarefa, tentativa) resposta = unity_gateway.chat(model=modelo, prompt=prompt) if resposta.baixa_confianca and tentativa == 1: return chama_coding_agent(tipo_tarefa, prompt, tentativa=2) return resposta O ponto não é o código em si, é o princípio, classificar a tarefa antes de decidir o modelo, e só escalar pro caro quando o barato realmente não dá conta, medindo tudo no mesmo lugar (aqui, o Unity Gateway).\nNa prática: a peça que eu acho mais subestimada dessa lista é o meta-harness, não o roteamento. Roteamento por custo qualquer fornecedor de LLM Gateway oferece hoje. O que trava a adoção de modelo mais barato na maioria dos times não é falta de opção de modelo, é o fato de o harness (o \u0026ldquo;como o agente edita arquivo, roda teste, aplica diff\u0026rdquo;) estar amarrado a um fornecedor específico. Sem essa camada de abstração, toda troca de modelo vira projeto de migração, e ninguém troca de modelo por causa de 20% de economia se a troca custa uma sprint de trabalho de engenharia.\nPor que a fronteira de eficiência muda de posição com o tempo Um ponto que passa despercebido na primeira leitura é que \u0026ldquo;modelo mais barato que ainda resolve a tarefa\u0026rdquo; não é uma escolha fixa, é uma fronteira que se move a cada poucos meses conforme fornecedor lança modelo novo com relação custo-desempenho diferente. Um sistema de roteamento estático, escrito uma vez e esquecido, fica desatualizado rápido, o modelo que era a melhor opção de custo em janeiro pode não ser mais a melhor opção em julho, mesmo sem nenhuma mudança de comportamento do time. Isso é parte do motivo pelo qual a arquitetura de meta-harness importa mais do que parece à primeira vista: ela é o que permite reavaliar e trocar a política de roteamento sem reescrever a ferramenta que o engenheiro usa todo dia. Um sistema de roteamento que exige migração de ferramenta toda vez que sai modelo novo tende a nunca ser atualizado na prática, porque ninguém quer pagar o custo de migração só para testar se o modelo novo é mesmo mais barato.\nO que isso não resolve Essa lista de técnica ataca o \u0026ldquo;quanto se gasta por chamada\u0026rdquo;, não resolve tudo:\nDownshift automático de modelo pode degradar qualidade de um jeito que só aparece depois, quando o código gerado por um modelo mais barato introduz um bug sutil que passa despercebido no code review. Métrica de \u0026ldquo;qualidade equivalente\u0026rdquo; comparada em benchmark interno não é garantia de qualidade equivalente no seu código específico. Meta-harness e roteamento dinâmico são investimento de engenharia de plataforma, não configuração de dez minutos. Time pequeno sem squad de platform engineering dedicado provavelmente não vai construir um Omnigent próprio, vai depender do que o fornecedor de ferramenta já oferecer pronto. Redução de token via compressão de contexto tem limite prático: comprimir demais o contexto de um repositório grande derruba a qualidade da sugestão do agente, porque ele perde referência de código relacionado que estava fora da janela comprimida. Fechamento O recado central aqui é que custo de coding agent em escala não se resolve com um botão de orçamento só, se resolve tratando \u0026ldquo;custo por tarefa\u0026rdquo; como uma variável de engenharia, com roteamento, abstração de modelo e otimização de token trabalhando juntos. Isso não substitui a governança financeira do gasto (orçamento diário e mensal continuam necessários), complementa ela atacando o outro lado da equação, quanto cada chamada custa de verdade.\nReferências Post oficial: Managing AI Coding Costs at Scale Documentação oficial: Unity Gateway Documentação oficial (Microsoft Learn): AI governance with Unity Gateway - Azure Databricks #Databricks #AIEngineering #FinOps #CodingAgents\n","permalink":"https://wiliamrosa.github.io/articles/databricks-reducao-custo-coding-agents-roteamento-modelos/","summary":"Orçamento é só uma parte da conta de coding agent em escala. A Databricks lista cinco alavancas técnicas, roteamento dinâmico por modelo mais barato, meta-harness pra trocar de modelo sem fricção, e redução de token via cache e compressão de contexto, que reduziram custo em até 50% sem baixar qualidade percebida pelo engenheiro.","title":"Cinco alavancas técnicas pra baixar o custo de coding agent sem cortar acesso do time"},{"content":"Escolher framework de orquestração de agente parece decisão de biblioteca, mas na prática decide quanto de rastreamento e recuperação de falha você ganha de graça, e quanto sobra pra você construir na mão.\nO Databricks MVP Shashank Shekhar comparou três caminhos para workflow agêntico no ecossistema Databricks, LangGraph, Claude Agent SDK e Deep Agents (da LangChain), olhando especificamente pra integração com MLflow, gerenciamento de estado de longa duração e esforço real de implementação, não só qual \u0026ldquo;parece\u0026rdquo; melhor em demo.\nNa integração com MLflow, o LangGraph sai na frente: mlflow.langchain.autolog() entrega rastreamento nativo do grafo inteiro, já formatado para os frameworks de avaliação do Databricks. Deep Agents herda esse mesmo runtime do LangGraph por baixo, então aproveita esse rastreamento, só que com nomes de etapa um pouco mais genéricos. Já o Claude Agent SDK captura bem cada chamada de modelo isoladamente, mas pra ver o loop completo e os spans de skill é preciso exportar via OpenTelemetry manualmente, não tem autologging nativo de fábrica. No quesito recuperação de estado, LangGraph e Deep Agents se encaixam bem num desenho de checkpoint assíncrono sobre Lakebase, com estado persistindo a cada passo, o que é essencial pra workflow com humano no loop. O Claude Agent SDK espelha a transcrição da sessão via banco, mas sua fronteira de durabilidade é a invocação completa, então esperar uma ferramenta responder no meio de uma execução longa exige camada própria construída por quem implementa.\nPontos técnicos que valem registrar:\nLangGraph oferece rastreamento nativo do grafo completo via mlflow.langchain.autolog(), alinhado aos frameworks de avaliação do Databricks Deep Agents herda o runtime do LangGraph e seu rastreamento, mas com granularidade de etapa mais grosseira Claude Agent SDK exige exportação via OTel para capturar loop completo e spans de skill, sem autologging nativo LangGraph e Deep Agents se apoiam em checkpoint assíncrono compatível com Lakebase, mantendo estado a cada passo Claude Agent SDK tem fronteira de durabilidade na invocação completa, exigindo camada própria para espera longa de ferramenta LangGraph é o framework mais adotado e testado em produção, mas exige montar a própria estrutura de skills; Deep Agents pede menos esforço de implementação para arquitetura multiagente complexa, sendo porém o harness mais recente dos três Minha ressalva: comparação desse tipo envelhece rápido, porque os três projetos evoluem toda semana, e o que hoje é uma lacuna do Claude Agent SDK em autologging pode fechar no próximo release. Ainda assim, o critério que ele usou, rastreamento nativo versus esforço manual, e durabilidade a nível de passo versus a nível de invocação completa, é o jeito certo de comparar framework de agente pra quem vai rodar isso em produção sobre Databricks, não a lista de features do marketing de cada um.\nFonte: https://www.linkedin.com/in/ishashankshekhar/#langgraph-claude-agent-sdk-deep-agents-databricks\n#Databricks #AgentesIA #MLflow\n","permalink":"https://wiliamrosa.github.io/posts/langgraph-claude-agent-sdk-deep-agents-databricks/","summary":"Uma comparação prática entre LangGraph, Claude Agent SDK e Deep Agents mostra que a escolha de orquestração muda o que você ganha de graça em rastreamento MLflow e o quanto sobra pra você construir sozinho quando o agente trava no meio de uma tarefa longa.","title":"LangGraph, Claude Agent SDK ou Deep Agents no Databricks: qual rastreia melhor e qual sobrevive a uma queda"},{"content":"A Databricks MVP Maria Vechtomova, autora de um livro sobre a plataforma, resumiu bem uma frustração comum: a Databricks troca o nome dos próprios produtos com frequência incomum, e ela mesma precisou atualizar o manuscrito várias vezes só por causa disso, não de mudança de funcionalidade. Alguns exemplos recentes: Databricks Vector Search virou Mosaic AI Vector Search, que virou Databricks AI Search. AI Gateway virou Unity AI Gateway. Genie Spaces virou Genie Agents. Delta Live Tables virou Lakeflow Spark Declarative Pipelines.\nIsso não é exclusivo de quem escreve livro, qualquer um que produz conteúdo técnico sobre a plataforma sente esse atrito na pele.\nA resposta da comunidade veio de dois Databricks MVPs, que criaram o rebricked.org: um projeto que rastreia essas mudanças de nome e também o estágio de maturidade de cada feature (Preview, GA, etc.), num formato que até vira quiz pra testar se você está atualizado.\nPor que isso é mais do que curiosidade:\nRenomeação de feature quebra busca: quem procura pela documentação usando o nome antigo simplesmente não acha o conteúdo atual Conteúdo técnico publicado (artigo, livro, treinamento) vira desatualizado por causa de nome, não de tecnologia Ter uma referência única e viva pra \u0026ldquo;qual é o nome atual disso\u0026rdquo; economiza o trabalho de cada criador de conteúdo tentar rastrear isso sozinho Minha ressalva: um projeto de rastreamento mantido pela comunidade é só tão confiável quanto o esforço voluntário por trás dele continuar. Isso não é crítica ao rebricked.org especificamente, é o risco estrutural de qualquer ferramenta de terceiros tentando compensar uma prática de naming que, no fundo, quem deveria resolver de forma mais estável é a própria Databricks.\nFonte: https://rebricked.org/\n#Databricks #Documentação #Comunidade\n","permalink":"https://wiliamrosa.github.io/posts/databricks-renomeacoes-rebricked-guia/","summary":"A Databricks renomeia produto com uma frequência que confunde até quem escreve livro sobre a plataforma. Um projeto da comunidade tenta resolver isso com uma espécie de dicionário vivo.","title":"Vector Search, Mosaic AI Vector Search, Databricks AI Search: o mesmo produto, três nomes em dois anos"},{"content":"A Databricks concluiu a aquisição da Panther, plataforma de SOC (Security Operations Center) com IA, unindo os workflows de detecção e investigação da Panther ao LakeWatch, o \u0026ldquo;security lakehouse\u0026rdquo; aberto da própria Databricks.\nA Panther traz mais de 100 integrações de dados prontas, detecção como código, e workflows de SOC agênticos pra automatizar investigação de alerta. Juntando isso ao LakeWatch, a proposta é clara: reter petabytes de telemetria em formato aberto, rodar agentes autônomos de triagem em tempo real, e executar detecção como código sobre dado governado, em vez de depender de um SIEM tradicional fechado e caro por volume de log.\nPor que essa aquisição merece atenção mesmo de quem não é do time de segurança:\nSIEM tradicional cobra pesado por volume de dado retido, o argumento do \u0026ldquo;security lakehouse\u0026rdquo; é justamente desacoplar retenção de custo de licença Trazer segurança pra dentro do mesmo Lakehouse que já governa o resto dos dados elimina mais uma cópia de dado vivendo isolada numa ferramenta à parte É outro sinal de que a Databricks está comprando capacidade especializada (como fez com Neon pro Lakebase) em vez de construir tudo internamente do zero Minha ressalva: integrar uma aquisição de segurança é historicamente mais lento e mais arriscado do que integrar uma aquisição de infraestrutura de dados, workflow de SOC tem processo, certificação e confiança de analista construídos ao longo de anos, e isso não se copia junto com o código-fonte. Eu esperaria a integração real (não só o anúncio) antes de migrar operação crítica de segurança pra cá.\nFonte: https://www.databricks.com/blog/databricks-completes-acquisition-panther-accelerating-security-lakehouse-era\n#Databricks #Segurança #LakeWatch\n","permalink":"https://wiliamrosa.github.io/posts/databricks-adquire-panther-security-lakehouse/","summary":"Com a aquisição da Panther concluída, a Databricks une workflows de SOC e detecção de ameaças ao LakeWatch, uma tacada clara contra o modelo tradicional de SIEM.","title":"Databricks compra a Panther e aposta todas as fichas no 'security lakehouse'"},{"content":"O Databricks MVP Ajay Kumar Pandey chamou atenção para uma mudança pequena no editor do Databricks que resolve um incômodo bem concreto de quem trabalha em mais de um projeto ao mesmo tempo: a chegada de Spaces.\nO mecanismo é direto. Antes, todo mundo que já trabalhou num workspace do Databricks por um tempo conhece a sensação de abrir uma pasta de projeto novo e ver as dez abas do projeto anterior ainda ali, competindo por espaço na tela. Spaces resolve isso deixando você focar numa pasta ou projeto específico enquanto preserva as abas abertas daquele contexto separadamente. Trocar de Space significa trocar de contexto de trabalho inteiro, não só de pasta visível na árvore de arquivos, o que é diferente de simplesmente fechar e reabrir abas manualmente toda vez que muda de tarefa.\nDetalhes que fazem diferença no dia a dia:\nCada Space guarda seu próprio conjunto de abas abertas, então voltar pra um projeto antigo restaura exatamente onde você parou Isso ajuda especialmente quem alterna entre notebook interativo, pipeline declarativo e projeto de bundle no mesmo workspace É um ajuste de ergonomia, não uma feature com API ou flag de configuração nova para aprender Minhas considerações: é o tipo de feature que não vira manchete de nenhum release notes, mas que economiza minutos reais todo dia, principalmente pra quem faz consultoria e circula entre workspace de clientes diferentes ou entre múltiplos projetos internos na mesma semana. Vale menos como anúncio técnico e mais como lembrete de que produtividade de plataforma de dados também se ganha em detalhe de UX, não só em feature de Genie ou de IA.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/notebooks/spaces\n#Databricks #Produtividade\n","permalink":"https://wiliamrosa.github.io/posts/spaces-organizar-trabalho-editor-databricks/","summary":"A nova feature Spaces deixa organizar abas abertas por pasta ou projeto no editor do Databricks, então dá pra alternar entre um pipeline e um bundle sem perder o contexto de cada um. O Databricks MVP Ajay Kumar Pandey notou a chegada.","title":"Spaces chega ao editor do Databricks pra resolver o problema da aba que some"},{"content":"Dashboard reporta uma receita, agente de IA reporta outra, e os dois estão olhando pro mesmo dado.\nO Databricks MVP P Shekhar Shukla resumiu o problema clássico que motivou a novidade: quando cada consumidor de dado recalcula a mesma métrica de negócio à sua maneira, especialmente em razão, contagem distinta ou retenção, calculadas em grão diferente, o número diverge mesmo partindo da mesma tabela. O Spark 4.2 ataca isso trazendo semântica nativa pro Spark SQL através de Metric Views.\nO mecanismo funciona via CREATE VIEW \u0026hellip; WITH METRICS, transformando dimensão (como agrupar o dado) e medida (o que precisa ser calculado) em objetos de primeira classe que o próprio motor entende e preserva a semântica de agregação pretendida, em vez de deixar cada ferramenta reinterpretar a lógica por conta própria. Uma vez definida, a Metric View carrega metadado semântico junto (nome de exibição, formato, sinônimo), então dashboard, relatório, aplicação e agente de IA consomem a mesma definição de métrica, com a mesma lógica de agregação, ao consultar o mesmo objeto.\nPontos técnicos que valem registrar:\nSintaxe nova: CREATE VIEW \u0026hellip; WITH METRICS, dimensões e medidas declaradas explicitamente Resolve especialmente métrica sensível a grão de agregação: razão, contagem distinta, retenção Carrega metadado semântico (nome de exibição, formato, sinônimo) junto da definição técnica Funciona através de SQL, ferramenta de BI e aplicação externa consumindo o mesmo objeto Minhas considerações: a promessa de \u0026ldquo;uma definição, todo mundo usa a mesma\u0026rdquo; só se sustenta se a organização realmente centralizar a criação de Metric View em vez de deixar cada time continuar definindo métrica solta em notebook ou dashboard próprio. A tecnologia resolve o problema de onde a definição pode viver; ela não resolve sozinha o problema de governança de quem tem autoridade pra decidir qual é a definição \u0026ldquo;certa\u0026rdquo; de receita quando dois times discordam.\nFonte: https://www.databricks.com/blog/introducing-apache-spark-42\n#Databricks #ApacheSpark #MetricViews\n","permalink":"https://wiliamrosa.github.io/posts/spark-4-2-metric-views-camada-semantica/","summary":"Metric Views trazem semântica nativa pro Spark SQL: dimensão e medida viram objeto de primeira classe que o motor entende, então dashboard, relatório e agente de IA calculam a mesma métrica do mesmo jeito.","title":"O Spark 4.2 finalmente entende o que é uma métrica de negócio, não só uma coluna"},{"content":"Manter só a versão mais recente de um registro parece simples até o feed de mudança trazer delete e evento fora de ordem no meio.\nO Databricks MVP P Shekhar Shukla resumiu bem o problema que o Auto CDC resolve: um change feed de cliente que mudou de endereço normalmente carrega o registro original, uma atualização com o endereço novo, um evento de exclusão, e às vezes tudo isso chega fora de ordem. Manter a tabela de destino correta nesse cenário sempre exigiu lógica de MERGE escrita à mão, que fica complicada rápido quando delete e ordenação entram na conta.\nO Spark 4.2 introduz suporte a Auto CDC dentro do Spark Declarative Pipelines especificamente pra processamento SCD Type 1, o padrão que mantém só a versão mais recente de cada registro (perfil de cliente, catálogo de produto, dado de referência operacional). Em vez de escrever cada passo do merge, você descreve a regra de mudança e o motor aplica: target (tabela a atualizar), source (evento de mudança de entrada), keys (como casar registro), sequence_by (como ordenar evento), apply_as_deletes (quais eventos contam como exclusão) e stored_as_scd_type (o tipo de processamento SCD).\nPontos técnicos que valem registrar:\nResolve especificamente SCD Type 1: manter só a versão mais recente, não histórico completo O parâmetro sequence_by garante ordenação correta mesmo com evento chegando fora de sequência apply_as_deletes deixa explícito quais eventos do feed contam como exclusão de registro Roda dentro do Spark Declarative Pipelines, herdando checkpoint e observabilidade que o SDP já oferece Minha ressalva: declarar a regra de mudança em vez de escrever o merge manualmente resolve o problema de manutenção, mas move a complexidade pra outro lugar: agora o cuidado precisa estar na definição correta de sequence_by e apply_as_deletes, porque um erro ali silenciosamente aplica a versão errada como \u0026ldquo;mais recente\u0026rdquo; sem lançar exceção óbvia. Eu testaria com um conjunto de eventos propositalmente fora de ordem antes de confiar isso em produção com dado que importa.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/ldp/cdc\n#Databricks #ApacheSpark #SDP\n","permalink":"https://wiliamrosa.github.io/posts/spark-4-2-auto-cdc-scd-type-1/","summary":"Auto CDC chega ao Spark Declarative Pipelines pra SCD Type 1: você descreve a regra de mudança (chave, ordenação, o que conta como delete), e o motor aplica, mesmo com evento fora de ordem.","title":"Auto CDC no Spark 4.2 tira o MERGE manual de cima de quem só queria manter a versão mais recente"},{"content":"O Databricks MVP Bartosz Konieczny documentou como usar o SQLFluff pra impor um estilo consistente em scripts SQL no Databricks, indo além do Ruff, que ele já havia coberto pro lado Python. A configuração passa por um arquivo pyproject, com uma tarefa Poe compartilhada que pode servir tanto como aviso de commit local quanto como barreira de CI/CD.\nO padrão de integração é o mesmo que ele já recomenda pro Ruff: não travar deploy em ambiente de sandbox com verificação de lint, reservar isso pra CI/CD em branch principal ou de release, e usar um hook de pre-commit local pra pegar o problema antes mesmo do código sair da máquina do desenvolvedor.\nPor que isso importa pra quem já lida com Declarative Automation Bundles:\nSQL costuma ficar de fora das discussões de qualidade de código, tratado como \u0026ldquo;menos código de verdade\u0026rdquo; do que Python, na prática, é código que roda em produção do mesmo jeito Ter um linter dedicado pra SQL fecha a lacuna de quem já padronizou Python mas deixou os scripts SQL sem controle nenhum A mesma tarefa Poe compartilhada entre Ruff e SQLFluff mantém a configuração de qualidade centralizada, em vez de duas ferramentas com dois fluxos diferentes Minha ressalva: com agente de código gerando cada vez mais SQL dentro de pipelines Databricks, um linter de estilo ajuda com legibilidade, mas não substitui revisão de lógica, SQL sintaticamente limpo e SQL correto são coisas diferentes, e nenhuma ferramenta de lint pega uma junção errada ou um filtro que muda silenciosamente o resultado de uma query.\nFonte: https://www.waitingforcode.com/databricks/sqlfluff-keeping-sql-queries-clean/read\n#Databricks #SQL #QualidadeDeCodigo\n","permalink":"https://wiliamrosa.github.io/posts/databricks-sqlfluff-code-style-sql-bundles/","summary":"O Databricks MVP Bartosz Konieczny mostra como usar o SQLFluff pra padronizar scripts SQL no Databricks, integrando a verificação ao ciclo de deploy dos Declarative Automation Bundles.","title":"Consistência de estilo no Databricks não é só sobre Python, SQL também precisa de linter"},{"content":"O Unity AI Gateway adicionou o \u0026ldquo;Priority pay-per-token\u0026rdquo;: latência consistente para aplicações de IA críticas em tempo real, sem precisar reservar capacidade dedicada. A ideia é dar prioridade de fila pra quem paga mais por token, em vez de forçar a escolha binária entre pay-per-token comum (mais barato, latência variável) ou provisioned throughput (latência garantida, mas com capacidade reservada e custo fixo mesmo ocioso).\nIsso preenche uma lacuna real de quem serve modelo em produção: nem toda aplicação crítica tem volume constante o suficiente pra justificar capacidade reservada, mas ainda assim não pode tolerar latência imprevisível em horário de pico.\nPor que isso importa na prática:\nEvita pagar por capacidade reservada ociosa em aplicações com tráfego irregular mas latência-sensível Dá um terceiro ponto no espectro custo/latência, não só os dois extremos de sempre Funciona dentro do mesmo Unity AI Gateway que já centraliza custo e observabilidade, não é uma configuração isolada Minha ressalva: \u0026ldquo;prioridade\u0026rdquo; só funciona de verdade quando há contenção de fato, se todo mundo pagar o prêmio de prioridade, a fila volta a ser genérica e você só pagou mais caro pelo mesmo resultado. Vale medir o ganho real de latência em horário de pico antes de assumir que o prêmio pago se traduz em benefício proporcional.\nFonte: https://docs.databricks.com/aws/en/machine-learning/foundation-model-apis/priority-mode\n#Databricks #UnityAIGateway #ModelServing\n","permalink":"https://wiliamrosa.github.io/posts/databricks-unity-ai-gateway-priority-pay-per-token/","summary":"O Unity AI Gateway ganhou um modo de prioridade que promete latência consistente pra aplicações de IA em tempo real, sem exigir capacidade reservada, um meio-termo entre pay-per-token comum e provisioned throughput.","title":"Priority pay-per-token: pagar mais caro pra garantir latência, sem reservar capacidade dedicada"},{"content":"O Databricks MVP Casper Lubbers construiu um agente de FinOps voltado especificamente pra avaliação de custo em ambientes Azure e Databricks, capaz de responder perguntas como \u0026ldquo;quanto custaria capturar toda a tabela de auditoria do Unity Catalog num workspace do Log Analytics\u0026rdquo; ou \u0026ldquo;quanto realmente custa, de forma estática, um Azure Firewall rodando\u0026rdquo; antes de qualquer coisa ser de fato provisionada.\nO que diferencia essa abordagem da calculadora de custo genérica de qualquer provedor de nuvem é o escopo: em vez de estimar preço de um recurso isolado, o agente foi pensado pra responder a pergunta que times de plataforma realmente fazem, \u0026ldquo;se eu montar esse desenho específico de arquitetura, qual o custo esperado\u0026rdquo;, cruzando múltiplos serviços de uma vez.\nPor que esse tipo de ferramenta resolve uma dor real de quem opera Databricks:\nCusto de nuvem hoje é descoberto majoritariamente de forma reativa, olhando a fatura do mês, não de forma preditiva antes do deploy Perguntas de custo que cruzam múltiplos serviços (Firewall + Databricks + Log Analytics) normalmente exigem juntar manualmente várias calculadoras diferentes Expor isso como algo que se pode \u0026ldquo;conversar\u0026rdquo; (via MCP, por exemplo) reduz a barreira de quem não é especialista em FinOps mas ainda assim precisa tomar decisão de arquitetura com custo em mente Minha ressalva: um agente que estima custo é só tão confiável quanto sua capacidade de acompanhar mudanças de preço e SKU da própria nuvem, e isso muda com frequência. Eu trataria a saída desse tipo de agente como uma estimativa de ordem de grandeza pra apoiar decisão rápida, não como substituto da calculadora oficial do provedor na hora de aprovar orçamento formal.\nFonte: https://www.linkedin.com/in/casper-lubbers/\n#Databricks #FinOps #Azure\n","permalink":"https://wiliamrosa.github.io/posts/databricks-finops-agent-azure-cost/","summary":"O Databricks MVP Casper Lubbers construiu um agente de FinOps focado em avaliação de custo Azure + Databricks, do tipo de pergunta que hoje normalmente só se responde depois do fato, olhando a fatura.","title":"Um agente que responde 'quanto vai custar isso' antes de você rodar em produção"},{"content":"O que a Databricks anunciou A Databricks expandiu o Genie Code para suportar trabalho agêntico mais complexo em dados e ML. As duas novidades centrais:\nUm command center em página inteira para gerenciar trabalho multi-thread, com status de cada thread, pontos de revisão humana e acesso rápido a instruções, skills e conectores. Inteligência nativa sobre MLflow, Model Serving e compute, transformando o mesmo agente que já se usa no dia a dia em um especialista de engenharia de ML para produção. A Databricks também adiantou que tarefas agendadas (scheduled tasks) estão a caminho, permitindo que o Genie Code rode trabalho de forma autônoma e devolva os resultados para revisão.\nFonte original: post da Databricks no LinkedIn\nPor que isso importa na prática O maior gargalo de \u0026ldquo;agentes de código para dados\u0026rdquo; nunca foi gerar o código certo isoladamente, é integrar esse código ao ciclo de vida real de ML: registrar experimento no MLflow, promover modelo, servir via Model Serving, monitorar drift. Um agente que entende esse ciclo nativamente, em vez de tratar cada etapa como uma chamada de API genérica, economiza exatamente o trabalho manual de \u0026ldquo;colar\u0026rdquo; o resultado do agente no resto da esteira de ML.\nO command center multi-thread também resolve um problema real de quem já usa agentes de código em produção: perder o fio da meada quando várias tarefas rodam em paralelo. Ter pontos de revisão explícitos no meio do fluxo é um reconhecimento de que \u0026ldquo;autonomia total sem checkpoint humano\u0026rdquo; ainda não é o que times de dados maduros quer em ambientes regulados.\nMinha opinião Vejo essa combinação, command center + integração nativa com MLflow, como o Genie Code amadurecendo de \u0026ldquo;assistente de código genérico com contexto de dados\u0026rdquo; para algo mais próximo de um membro júnior do time de MLOps. É uma evolução natural e, na minha experiência treinando gente para a certificação de Machine Learning da própria Databricks, é exatamente o tipo de trabalho repetitivo (registrar run, comparar métricas, promover para staging) que mais gera atrito para quem está começando.\nO ponto que eu observaria com cuidado é a promessa de tarefas agendadas rodando de forma autônoma. Scheduling é fácil de anunciar e difícil de operar com segurança, a pergunta que eu faria antes de habilitar isso em um workspace de produção é: que garantias existem contra um agente agendado tomar uma ação destrutiva silenciosamente às 3h da manhã, sem ninguém olhando? Os pontos de revisão do command center ajudam, mas revisão humana e execução agendada autônoma são, por definição, objetivos em tensão.\nDe qualquer forma, é um anúncio que acompanho de perto porque toca diretamente na minha rotina como Databricks Certified Machine Learning Professional: quanto mais o Genie Code absorve o trabalho operacional do MLflow, mais meu papel se desloca para decidir o quê construir, e menos para executar o como.\nPara saber mais Post original: https://www.databricks.com/blog/whats-new-genie-code-data-ai-summit-2026 Documentação oficial do Databricks: https://docs.databricks.com/ ","permalink":"https://wiliamrosa.github.io/posts/databricks-genie-code-command-center-mlflow/","summary":"A expansão do Genie Code traz um painel para gerenciar trabalho multi-thread e integração nativa com MLflow e Model Serving. Isso aproxima o agente do fluxo real de quem já trabalha com ML em produção.","title":"Genie Code ganha command center: o que muda quando o agente vira um colega de engenharia de ML"},{"content":"O Genie Code deixou de ser \u0026ldquo;assistente de código com contexto de dados\u0026rdquo; e ganhou cara de colega júnior de MLOps.\nDuas novidades mudam o jogo: um command center pra gerenciar várias tarefas em paralelo (com pontos de revisão humana no meio do caminho) e inteligência nativa sobre MLflow, Model Serving e compute, o agente já entende o ciclo de vida de ML, não só gera código solto.\nO que muda no dia a dia de quem já usa MLflow:\nMenos trabalho manual de \u0026ldquo;colar\u0026rdquo; resultado do agente na esteira de ML Threads paralelas sem perder o fio da meada Tarefas agendadas rodando o agente de forma autônoma (a caminho) Minha ressalva é justo sobre esse último ponto: execução agendada autônoma e revisão humana são, por definição, objetivos em tensão. Pontos de revisão ajudam, mas não respondem sozinhos \u0026ldquo;o que impede um agente agendado de tomar uma ação ruim às 3h da manhã sem ninguém olhando?\u0026rdquo;\nFonte: https://www.databricks.com/blog/whats-new-genie-code-data-ai-summit-2026\n#Databricks #GenieCode #MLOps\n","permalink":"https://wiliamrosa.github.io/posts/linkedin-genie-code-mlflow/","summary":"Command center multi-thread e inteligência nativa sobre MLflow mudam o que esperar de um agente de código para dados.","title":"O Genie Code virou um colega júnior de MLOps"},{"content":"O Databricks MVP Jaco van Gelder chamou atenção pro Packaged Clean Rooms, que atingiu disponibilidade geral em 31 de julho de 2026, descrevendo o Databricks como um \u0026ldquo;wrecking ball para silos de dados\u0026rdquo;. É um modo diferente do Clean Rooms tradicional (que já era GA desde fevereiro de 2025): aqui, um provedor empacota notebooks, JARs e dados prontos para uso, e o consumidor roda esse pacote contra os próprios dados dele, sem nunca enxergar o código ou os dados de origem do provedor.\nO Clean Rooms tradicional já permitia colaboração segura trazendo dado de fora do Databricks (Synapse, Snowflake, Redshift, BigQuery, desde que governados por Unity Catalog); o modo packaged estende isso pra lógica de processamento também, não só dado.\nPor que essa distinção entre os dois modos importa:\nClean Rooms tradicional resolve \u0026ldquo;duas partes analisam dado combinado sem uma ver o dado bruto da outra\u0026rdquo; Packaged Clean Rooms resolve um problema diferente: \u0026ldquo;um fornecedor distribui um produto de análise pronto sem expor propriedade intelectual (o código) nem pedir acesso aos dados de quem consome\u0026rdquo; Isso abre caminho pra um modelo de \u0026ldquo;produto de dados empacotado\u0026rdquo;, parecido com vender um relatório pronto, mas rodando dentro do ambiente governado do próprio cliente Minha ressalva: empacotar lógica pra rodar no ambiente de terceiros sempre levanta a pergunta inversa de proteção de dados, o provedor consegue auditar o que o consumidor está de fato fazendo com o pacote rodando no ambiente dele? Delta Sharing e Clean Rooms resolvem bem o problema de \u0026ldquo;não vazar dado bruto\u0026rdquo;, mas a garantia de que o pacote não está sendo mal utilizado do outro lado é uma camada de confiança contratual, não só técnica.\nFonte: https://docs.databricks.com/aws/en/release-notes/product/2026/july\n#Databricks #CleanRooms #UnityCatalog\n","permalink":"https://wiliamrosa.github.io/posts/databricks-packaged-clean-rooms-ga/","summary":"Diferente do Clean Rooms tradicional (GA desde 2025), o modo \u0026lsquo;packaged\u0026rsquo; permite que um provedor distribua notebooks, JARs e dados prontos, sem o consumidor nunca ver o código ou os dados de origem.","title":"Packaged Clean Rooms virou GA, compartilhar lógica sem compartilhar código"},{"content":"Largar um agente de código genérico pra resolver \u0026ldquo;por que a receita da região sul caiu no dashboard\u0026rdquo; costuma terminar do mesmo jeito: ele lista tabela, abre notebook, tenta adivinhar qual coluna significa o quê, erra o join, tenta de novo. Cada exploração consome chamada de ferramenta, e cada chamada de ferramenta consome token. O agente não é burro, ele só está começando do zero num workspace que ele nunca viu antes, toda vez.\nUm benchmark interno recente da Databricks, rodado contra 401 tarefas reais de descoberta de dado em ambiente corporativo, tenta isolar exatamente esse efeito: será que um agente especializado, com acesso estruturado ao catálogo de dado, vence um agente de código genérico só por conhecer melhor o terreno, mesmo usando modelo de linguagem comparável por trás? O resultado, com Genie Code do Azure Databricks levando 76,6% de acurácia contra 55,9% a 72,1% dos concorrentes testados, e custando US$ 0,55 por tarefa contra US$ 0,91 a US$ 1,16 dos outros, sugere que sim, e o motivo importa mais que o número em si.\nO mecanismo: não é o modelo, é o que o agente já sabe sem perguntar A diferença central não está em raciocínio melhor, está em informação que o agente especializado já tem de cara, então nunca precisa gastar chamada de ferramenta descobrindo. Três peças sustentam isso:\nBusca semântica sobre catálogo e workspace: em vez de listar tabela por tabela até achar a certa, o agente busca por significado, então uma pergunta sobre \u0026ldquo;receita por região\u0026rdquo; já aponta pra tabela certa mesmo que o nome dela seja fact_sales_v3.\nMemória persistente de tabela e lógica de negócio frequentes: tabela que o time já usa com frequência, e a lógica de negócio já validada em consulta anterior, não precisam ser redescobertas a cada tarefa nova. Isso inclui, na peça pública equivalente desse mecanismo (o Genie Ontology, hoje em Public Preview), a capacidade de o agente consultar definição de métrica e dica de join já documentada pelo time antes de escrever o SQL.\nEntendimento semântico de contexto corporativo: interpretar o que \u0026ldquo;cliente ativo\u0026rdquo; ou \u0026ldquo;pedido cancelado\u0026rdquo; significam dentro daquela empresa específica, não a definição genérica do dicionário.\nA consequência prática apareceu no próprio benchmark: o agente especializado precisou, em média, de 8,3 chamadas de ferramenta por tarefa, menos que qualquer agente genérico testado. Menos exploração às cegas significa menos chamada de ferramenta, e cada chamada de ferramenta a menos é custo e tempo que não vira gasto.\nMinha leitura: o dado que mais chama atenção aqui não é a acurácia mais alta, é a causa dela ser estrutural e não uma questão de \u0026ldquo;modelo mais esperto\u0026rdquo;. Isso importa porque significa que trocar o modelo de linguagem por trás de um agente genérico não fecha essa lacuna sozinho, o problema não é raciocínio, é falta de contexto estruturado sobre o ambiente. Quem quiser competir nesse eixo precisa investir em dar contexto ao agente, não só em trocar de modelo.\nMão na massa: ensinando lógica de negócio ao agente com skills A peça que qualquer time pode configurar hoje, sem esperar por feature nova, é o mecanismo de skills do Genie Code: uma pasta .assistant/skills/ (em nível de workspace ou de usuário) onde cada subpasta é uma skill com seu próprio SKILL.md. O agente carrega a skill automaticamente quando o pedido do usuário casa com a descrição dela, sem precisar de invocação manual.\nUm exemplo de skill documentando a lógica de \u0026ldquo;pedido cancelado\u0026rdquo; pra um time de e-commerce:\nWorkspace/.assistant/skills/pedidos-cancelados/ ├── SKILL.md └── exemplos-consulta.sql --- name: pedidos-cancelados description: Define o que conta como pedido cancelado neste workspace e onde consultar. Use quando a pergunta envolver cancelamento, estorno ou pedido não concluído. --- Pedido cancelado é qualquer linha em `vendas.pedidos` com `status_pedido IN (\u0026#39;CANCELADO\u0026#39;, \u0026#39;ESTORNADO\u0026#39;)` E `motivo_cancelamento IS NOT NULL`. Pedido com status `PENDENTE` há mais de 48h não conta como cancelado, conta como pendente de pagamento (ver skill separada). A tabela de fato já teve rename de `id_pedido` pra `pedido_sk` na migração de 2026-03, use `pedido_sk` em consulta nova. Sem essa skill, o agente teria que inferir a regra de cancelamento olhando dado de exemplo e arriscando interpretação errada, exatamente o tipo de exploração que consome chamada de ferramenta e ainda corre risco de sair errado. Com ela documentada, a resposta vem correta na primeira tentativa, e continua correta pra próxima pessoa do time que perguntar algo parecido, sem precisar redocumentar.\nComo o benchmark foi montado Vale entender a metodologia antes de aceitar o número de cara. As 401 tarefas vieram de uso real e interno, não de pergunta sintética criada só pra favorecer um lado, o que reduz (mas não elimina) o viés de \u0026ldquo;prova feita sob medida\u0026rdquo;. Cada agente testado, especializado ou genérico, teve acesso ao mesmo workspace e ao mesmo conjunto de tabelas, então a variável isolada foi de fato a estratégia de descoberta de dado, não uma vantagem de acesso desigual. A métrica de custo por tarefa correta (não custo por tarefa executada) é a que mais importa aqui: um agente mais barato por execução mas que erra a resposta com frequência maior ainda sai mais caro por resposta certa, e foi exatamente essa métrica composta que abriu a maior diferença entre os dois grupos.\nO que isso não resolve Esse tipo de vantagem estrutural desaparece se o catálogo em si estiver mal documentado, sem descrição de coluna, sem convenção de nome, sem skill nenhuma escrita. O agente especializado ainda depende de metadado de qualidade pra ter algo estruturado pra consultar, sem isso ele volta a se comportar como um agente genérico explorando às cegas. O benchmark também mede tarefa de descoberta e análise de dado especificamente, não generaliza pra toda tarefa de engenharia de software, um agente de código genérico ainda pode ser a escolha certa pra refatoração de aplicação ou trabalho fora do universo de dado e catálogo. E calibração de benchmark interno de fornecedor sempre merece ceticismo saudável: vale reproduzir o teste com tarefa real do seu próprio workspace antes de tratar os números como garantia, principalmente porque o ganho documentado depende diretamente de quanto o workspace testado já estava bem documentado, algo que a Databricks controla no próprio ambiente de teste e que a maioria das empresas não tem de graça.\nFechamento O argumento de fundo aqui é simples de generalizar: agente de propósito geral compete em raciocínio, agente de domínio específico compete em contexto que ele já tem de graça. Pra time que já usa Azure Databricks, o caminho de curto prazo pra capturar esse efeito não é trocar de agente, é investir em documentar lógica de negócio como skill e manter metadado de catálogo atualizado, porque é exatamente esse investimento que faz a diferença de custo e acurácia aparecer.\nReferências Databricks Blog, \u0026ldquo;Why A Frontier Data Agent Outperforms General Coding Agents in Quality and Cost\u0026rdquo;: https://www.databricks.com/blog/why-frontier-data-agent-outperforms-general-coding-agents-quality-and-cost Databricks Docs, \u0026ldquo;Genie Code features and capabilities\u0026rdquo;: https://docs.databricks.com/aws/en/genie-code/features-capabilities Microsoft Learn, \u0026ldquo;Genie Code features and capabilities - Azure Databricks\u0026rdquo;: https://learn.microsoft.com/en-us/azure/databricks/genie-code/features-capabilities Databricks Docs, \u0026ldquo;Extend Genie Code with agent skills\u0026rdquo;: https://docs.databricks.com/aws/en/genie-code/skills #Databricks #GenieCode #AIEngineering #Agentes\n","permalink":"https://wiliamrosa.github.io/articles/genie-code-agente-dados-vs-agente-codigo-generico/","summary":"Um benchmark interno da Databricks com 401 tarefas reais de descoberta de dado mostra o Genie Code batendo agentes de código genéricos em acurácia e custo, e a explicação não é o modelo por trás, é o agente não precisar explorar o workspace às cegas.","title":"Por que um agente que já conhece seu catálogo vence um agente de código genérico em tarefa de dado"},{"content":"Quem já rodou um WHERE message LIKE '%connection refused%' numa tabela de log com alguns bilhões de linhas conhece a sensação. A query sobe, o cluster consome crédito, e minutos depois volta meia dúzia de linhas relevantes escondidas em terabytes de dado irrelevante. O Delta Lake sabe pular arquivo quando o filtro é numérico, é uma igualdade exata ou o dado está ordenado por aquela coluna, mas contra substring dentro de texto livre ele historicamente não tinha resposta boa: sem abrir o arquivo, o motor não tem como saber se a palavra está lá dentro.\nO índice de busca textual chegou em Beta na Databricks Runtime 18.2 justamente pra atacar esse ponto cego. A lógica é a mesma que já sustenta min/max statistics e Z-Ordering no Delta Lake, só que estendida pra um tipo de predicado que aquelas técnicas nunca cobriram: substring e palavra dentro de texto livre. Numa tabela de log real, onde um termo raro costuma aparecer numa fração pequena dos arquivos, isso não é ajuste fino de configuração, é mudança de classe de problema, do tipo que decide se uma tela de busca em produção é usável ou não.\nO mecanismo: pular arquivo em vez de ler tudo O índice de busca textual não guarda o texto inteiro numa estrutura de busca à parte, nem substitui o motor de query por algo parecido com Elasticsearch. Ele guarda, por arquivo do Delta, se aquele arquivo pode conter o padrão buscado. Quando a query usa as novas funções search ou isearch, o otimizador consulta o índice antes de tocar em disco e descarta de cara todo arquivo onde a resposta é \u0026ldquo;certamente não\u0026rdquo;. Sobra pra leitura só o subconjunto de arquivos onde a palavra pode estar, e é aí que mora o ganho: numa tabela de log real, a fração de arquivos que efetivamente contém um termo raro costuma ser pequena, então o corte de I/O é desproporcional ao tamanho da tabela.\nEssa é a mesma lógica de file skipping que o Delta já usa com min/max statistics e Z-Ordering, só que aplicada a um tipo de predicado que aquelas técnicas não cobrem: substring e palavra dentro de texto livre. O índice não altera o resultado da query, só decide quais arquivos vale a pena abrir.\nMão na massa: criando e consultando um índice O recurso exige tabela gerenciada (Delta ou Iceberg) com row tracking ligado, Databricks Runtime 18.2 ou superior, e o Beta habilitado no workspace. Do lado de permissão, é preciso ter MODIFY na tabela base e CREATE TABLE no schema pai pra poder criar o índice, e a coluna indexada não precisa ser só texto solto: STRING, VARIANT, STRUCT e ARRAY são todos aceitos, desde que uma STRUCT tenha pelo menos um campo folha do tipo certo em algum nível de aninhamento. Criar e usar um índice é direto em SQL:\nCREATE TABLE logs ( event_time TIMESTAMP, message STRING, error_detail STRING ) TBLPROPERTIES (\u0026#39;delta.enableRowTracking\u0026#39; = \u0026#39;true\u0026#39;); CREATE SEARCH INDEX log_idx ON logs (message, error_detail) OPTIONS (tokenizer = \u0026#39;ngram\u0026#39;, ngram_size = 4); -- busca case-insensitive por substring SELECT event_time, message FROM logs WHERE isearch(message, \u0026#39;connection refused\u0026#39;); -- busca por todas as palavras, em qualquer ordem SELECT event_time, message FROM logs WHERE search(message, \u0026#39;timeout gateway upstream\u0026#39;, mode =\u0026gt; \u0026#39;word\u0026#39;); A escolha do tokenizer importa mais do que parece. ngram fatia o texto em blocos sobrepostos de N caracteres (aceita de 3 a 10, padrão 5) e é o que sustenta busca por substring parcial, tipo achar \u0026quot;refus\u0026quot; dentro de \u0026quot;connection refused\u0026quot;. split fatia por palavra inteira, com um min_token_length configurável (padrão 3) pra descartar token curto demais na hora de indexar, e é mais barato quando a necessidade real é checar se um conjunto de palavras aparece no texto, sem se importar com substring dentro delas. Dá pra manter até quatro índices por tabela, cada um numa coluna diferente, então também é possível ter um índice ngram numa coluna e split em outra. Um detalhe que também vale saber de antemão: renomear a coluna indexada ou mudar o tipo dela depois de criado o índice não é suportado, então essas duas operações de schema exigem recriar o índice do zero.\nCusto: o ganho não aparece só no relógio, aparece na fatura O ponto de comparação que mais importa aqui não é \u0026ldquo;quanto tempo demora\u0026rdquo;, é \u0026ldquo;quanto compute é preciso alugar pra terminar em tempo aceitável\u0026rdquo;. Sem índice, uma busca textual em tabela grande normalmente empurra o time a escalar o warehouse pra um tamanho maior só pra tolerar a varredura completa, o que significa pagar por DBU maior durante todo o tempo da consulta. Com o índice fazendo file skipping antes da leitura, o mesmo warehouse pequeno resolve a consulta rápido o suficiente pra não justificar o upsize. Numa tela de busca usada com frequência por várias pessoas ao mesmo tempo, a diferença entre manter um warehouse XS ligado e precisar de um M ou L pra dar conta da carga é o tipo de conta que aparece de forma bem concreta na fatura mensal, não é só experiência de usuário.\nO detalhe que passa despercebido: refresh não é automático Diferente de uma estatística de tabela, o índice de busca textual não se atualiza sozinho quando a tabela recebe escrita nova. É preciso rodar REFRESH INDEX log_idx pra incorporar linhas novas de forma incremental, ou REFRESH INDEX log_idx FULL quando também é preciso remover entradas de linhas deletadas. Ignorar isso não quebra a query, porque o Databricks garante corretude usando table scan como fallback pra dado não indexado, mas o ganho de performance vai encolhendo silenciosamente conforme a tabela recebe escrita e ninguém lembra de atualizar o índice.\nMinha leitura: esse design é sensato pra evitar surpresa de resultado errado, mas cria um tipo de dívida técnica que é fácil não perceber, porque a query continua funcionando, só fica cada vez mais lenta sem avisar. Se o índice vai proteger uma tela de busca em produção, o refresh precisa entrar no mesmo job que faz a ingestão, não ficar como tarefa manual esporádica.\nO que isso não resolve O índice de busca textual não é um substituto de motor de busca full-text de verdade. Não existe ranking por relevância, não existe stemming, não existe busca fuzzy tolerante a erro de digitação, e três recursos bem usados em ambiente corporativo ficam de fora da lista de compatibilidade: OpenSharing, shallow clone e qualquer tabela com controle de acesso baseado em atributo (ABAC), máscara de coluna ou row-level security. Se a tabela adotar qualquer um desses depois de o índice já existir, o Databricks simplesmente ignora o índice na hora da query, silenciosamente, sem erro. Vale testar explicitamente DESCRIBE INDEX depois de qualquer mudança de política de acesso na tabela pra confirmar que o índice ainda está sendo considerado.\nTambém vale lembrar que é Beta: a documentação já avisa que índice criado nessa fase não tem garantia de compatibilidade quando o recurso virar Public Preview, e que vai ser preciso recriar. Não é o tipo de coisa que eu colocaria como dependência crítica de um pipeline de produção ainda em 2026.\nVale a pena adotar? Pra tabela de log, auditoria, ou qualquer caso onde a consulta típica é \u0026ldquo;essa palavra aparece em algum lugar desse texto\u0026rdquo;, o índice de busca textual resolve um problema que só tinha soluções ruins até aqui, replicar dado pra um Elasticsearch à parte, manter uma coluna derivada com truque de particionamento, ou simplesmente aceitar que a busca ia ser lenta. Pra qualquer time que já sofre com tabela de log gigante e dashboard de troubleshooting lento, vale o teste em ambiente de não produção, com atenção especial à rotina de refresh e à lista de incompatibilidades antes de prometer o ganho de performance pra alguém.\nReferências Microsoft Learn, \u0026ldquo;Full-text search indexes on Unity Catalog managed tables\u0026rdquo;: https://learn.microsoft.com/en-us/azure/databricks/optimizations/full-text-search-indexes Databricks Docs, \u0026ldquo;Accelerate search queries with full-text search indexes on Databricks\u0026rdquo;: https://www.databricks.com/blog/accelerate-search-queries-full-text-search-indexes-databricks #Databricks #UnityCatalog #Performance #SQL\n","permalink":"https://wiliamrosa.github.io/articles/databricks-indice-busca-textual-delta-lake/","summary":"O índice de busca textual do Unity Catalog (Beta na Databricks Runtime 18.2) deixa de varrer arquivo por arquivo atrás de uma palavra e passa a pular direto pra onde ela realmente está. O ganho de performance é real, mas vem com manutenção manual e uma lista de recursos incompatíveis que vale conhecer antes de sair criando índice em tudo.","title":"Índice de texto no Delta Lake: o que muda quando o Databricks para de escanear tudo pra achar uma palavra"},{"content":"O Databricks MVP Jaco van Gelder resolveu um problema que o Databricks ainda não oferece pronto: uma forma nativa e simples de rastrear como o schema de uma tabela evoluiu ao longo do tempo. Ele construiu uma função em PySpark que usa a funcionalidade de histórico do Delta Lake pra reconstruir a linha do tempo completa de mudanças de schema de uma lista de tabelas, não só a linhagem de dado, mas a linhagem da própria estrutura.\nO caso de uso que ele destaca é auditoria, principalmente em setor financeiro: saber exatamente quando uma coluna foi adicionada, removida ou teve o tipo alterado é o tipo de pergunta que auditoria anual cobra, e que hoje normalmente exige reconstrução manual a partir de log de mudança ou memória de quem mexeu na tabela.\nPor que essa lacuna (e a solução pra ela) merece atenção:\nGovernança de dado geralmente foca em quem acessou o quê, mas raramente em como a própria estrutura dos dados mudou ao longo do tempo O histórico do Delta Lake já guarda essa informação, o trabalho de Jaco foi extrair e organizar algo que tecnicamente já existia, só não estava exposto de forma consumível Ele mesmo apontou uma inconsistência interessante: remover coluna e adicionar coluna geram estruturas de array diferentes no histórico, o que deixou a query mais complexa do que deveria Minha ressalva: uma solução comunitária pra uma lacuna de plataforma é útil, mas é exatamente esse tipo de funcionalidade que deveria eventualmente virar recurso nativo, linhagem de schema junto com linhagem de dado, dentro do próprio Unity Catalog. Até lá, quem depender dessa função precisa tratar a manutenção dela (e a compatibilidade com futuras mudanças no formato de histórico do Delta Lake) como responsabilidade própria, não como algo garantido pela plataforma.\nFonte: https://github.com/jacovg91/linkedinstuff/blob/main/code-snippets/schema-evolution2.py\n#Databricks #DeltaLake #Governança\n","permalink":"https://wiliamrosa.github.io/posts/databricks-schema-evolution-audit-trail-delta/","summary":"O Databricks MVP Jaco van Gelder construiu uma função PySpark que reconstrói o histórico completo de mudanças de schema de uma tabela, útil pra auditoria financeira, algo que o Databricks não oferece pronto.","title":"Databricks ainda não rastreia a evolução do schema de uma tabela, mas dá pra construir isso com Delta Lake"},{"content":"Detecção de anomalia em streaming quase sempre esbarra na mesma parede: o micro-batch. Structured Streaming tradicional processa em janelas de um a dois segundos, o que é rápido pra maioria dos casos de uso, mas péssimo quando o próprio ato de esperar o batch fechar já é tarde demais. Fraude, validação de payload sensível, dado corrompido entrando num pipeline crítico, esses cenários não toleram nem um segundo de atraso estrutural. O Real-Time Mode do Apache Spark existe pra atacar exatamente essa lacuna, e a Databricks publicou um experimento que usa um caso de uso concreto pra provar o ponto: analisar transações de blockchain em tempo real.\nO que muda estruturalmente no Real-Time Mode Diferente do trigger de micro-batch, o Real-Time Mode processa dados conforme eles chegam, sem esperar uma janela fechar. Isso é possível por três mudanças arquiteturais combinadas: fluxo contínuo de dados entre estágios (em vez de materializar resultado intermediário a cada batch), agendamento simultâneo de todos os estágios da query (em vez de agendar estágio por estágio), e shuffle de streaming em memória entre os estágios, eliminando o custo de escrever e ler shuffle files a cada rodada.\nNa prática, isso aproxima o Spark Structured Streaming de um modelo de processamento contínuo, algo historicamente associado a engines como Flink, mas dentro do mesmo runtime que já roda o resto do pipeline batch e streaming da sua organização.\nO experimento: transações Ethereum como teste de estresse O time da Databricks montou um pipeline que ingere blocos e transações da blockchain Ethereum e classifica cada evento como ALLOW ou QUARANTINE, baseado em duas checagens:\nValidação de invariante de protocolo: um bloco onde gas_used é maior que gas_limit é logicamente impossível dentro das regras do próprio protocolo Ethereum, então vira sinal automático de dado corrompido ou malformado. Higiene de payload: o campo extra_data do bloco é inspecionado atrás de padrões que não deveriam estar ali, como fragmento de PII, token JWT ou chave de acesso da AWS vazada acidentalmente. O cluster usado foi um Databricks Runtime 16.4 LTS, quatro workers i3.xlarge, modo single-user dedicado, com o Photon desabilitado propositalmente pra isolar o efeito do próprio Real-Time Mode.\nOs números que sustentam a promessa Taxa de entrada sustentada de aproximadamente 65.592 linhas por segundo. Taxa de processamento sustentada de aproximadamente 69.713 linhas por segundo (o motor conseguiu absorver a entrada sem acumular backlog). Mais de 23,2 milhões de mensagens processadas no total do experimento. Latência p95 abaixo de 0,5 milissegundo. Latência p99 de 1 milissegundo. Pra contextualizar: micro-batch tradicional de 1-2 segundos representa uma diferença de três ordens de grandeza na latência de detecção. Se o objetivo é interromper uma transação suspeita antes que ela se propague, essa diferença não é cosmética.\nMão na massa: um esqueleto de classificação em tempo real O padrão de \u0026ldquo;classificar e rotear\u0026rdquo; descrito no experimento pode ser reproduzido em qualquer schema de evento estruturado. Um exemplo simplificado usando transformWithState, o operador que dá acesso a lógica customizada de estado dentro do Structured Streaming:\nfrom pyspark.sql.streaming import StatefulProcessor, StatefulProcessorHandle from pyspark.sql.types import StructType, StructField, StringType, LongType class BlockValidator(StatefulProcessor): def init(self, handle: StatefulProcessorHandle): self.handle = handle def handleInputRows(self, key, rows, timer_values): for row in rows: status = \u0026#34;ALLOW\u0026#34; if row[\u0026#34;gas_used\u0026#34;] \u0026gt; row[\u0026#34;gas_limit\u0026#34;]: status = \u0026#34;QUARANTINE\u0026#34; elif self._contem_padrao_sensivel(row[\u0026#34;extra_data\u0026#34;]): status = \u0026#34;QUARANTINE\u0026#34; yield {\u0026#34;block_id\u0026#34;: row[\u0026#34;block_id\u0026#34;], \u0026#34;status\u0026#34;: status} def _contem_padrao_sensivel(self, payload: str) -\u0026gt; bool: marcadores = [\u0026#34;AKIA\u0026#34;, \u0026#34;eyJhbGciOi\u0026#34;, \u0026#34;-----BEGIN\u0026#34;] return any(m in (payload or \u0026#34;\u0026#34;) for m in marcadores) query = ( spark.readStream.table(\u0026#34;bronze.eth_blocks\u0026#34;) .groupBy(\u0026#34;block_id\u0026#34;) .transformWithState( statefulProcessor=BlockValidator(), outputStructType=StructType([ StructField(\u0026#34;block_id\u0026#34;, LongType()), StructField(\u0026#34;status\u0026#34;, StringType()), ]), ) .writeStream .trigger(availableNow=False) # trigger real-time é configurado via cluster/runtime .toTable(\u0026#34;silver.eth_blocks_classified\u0026#34;) ) Vale reforçar: ativar o Real-Time Mode em si depende de configuração no nível de runtime e cluster, não é só trocar o trigger na API, então a documentação oficial de referência deve ser consultada antes de rodar em produção.\nNa prática: eu testaria esse tipo de pipeline sob picos reais de carga, não só sob taxa constante, antes de confiar cegamente no número de p99. Blockchain real tem rajadas de transação bem mais irregulares que um teste sintético de throughput constante, e é sob rajada que qualquer sistema de baixa latência costuma mostrar o comportamento real de fila.\nPor que blockchain foi uma escolha inteligente de benchmark Vale parar um momento no motivo de usar blockchain como cenário de teste, porque não é óbvio à primeira vista. Transação de blockchain tem duas propriedades que a tornam um teste de estresse honesto pra sistema de detecção de anomalia: primeiro, o volume é público e replicável, qualquer pessoa pode auditar o dataset usado, o que reduz a chance de benchmark artificialmente favorável. Segundo, e mais importante, as regras de invariante do protocolo (como gas_used nunca poder ultrapassar gas_limit) são conhecidas e verificáveis de forma determinística, então não existe ambiguidade sobre o que conta como anomalia real versus falso positivo. Isso remove uma variável de confusão comum em benchmark de detecção de anomalia, onde a própria definição de \u0026ldquo;anomalia\u0026rdquo; já é subjetiva. Aplicado a um cenário corporativo, o equivalente seria ter regras de negócio claras e auditáveis (limite de crédito, faixa de valor esperado, formato de campo) antes de tentar aplicar esse tipo de classificação em tempo real; sem isso, o pipeline técnico até funciona, mas a qualidade da classificação despenca.\nO que isso não resolve Real-Time Mode reduz drasticamente a latência de processamento, mas não substitui a necessidade de uma boa estratégia de resposta ao dado suspeito. Classificar como QUARANTINE em um milissegundo não adianta nada se o processo humano ou automatizado que trata esse alerta ainda leva minutos ou horas pra agir. Também é importante notar as limitações documentadas do transformWithState em modo real-time: transformWithStateInPandas não é suportado nesse modo, e o gerenciamento de estado (timers, TTL) tem regras próprias que diferem do modo de micro-batch tradicional, o que exige atenção redobrada ao migrar um pipeline existente.\nResumindo O experimento com blockchain Ethereum funciona como prova de conceito de algo mais amplo: quando o próprio Spark Structured Streaming consegue operar na casa de milissegundos, cenários que antes exigiam sair do ecossistema Spark (fraude, validação crítica, alerta operacional imediato) passam a caber dentro do mesmo runtime que já processa o resto do seu pipeline de dados. Vale testar, mas com expectativa realista sobre o que ainda depende de decisão e resposta humana depois da detecção.\nReferências Ultra-fast anomaly detection using Apache Spark Real-Time Mode (blog oficial Databricks) Apache Spark Structured Streaming Real-Time Mode: concepts (documentação oficial) Real-time mode concepts (Microsoft Learn) Stateful applications with transformWithState (documentação oficial) Build a custom stateful application with transformWithState (Microsoft Learn) #Databricks #ApacheSpark #Streaming #DataEngineering\n","permalink":"https://wiliamrosa.github.io/articles/spark-real-time-mode-deteccao-anomalias-blockchain/","summary":"O Apache Spark Real-Time Mode processa evento por evento em vez de esperar o próximo micro-batch fechar, e um experimento publicado pela Databricks usando transações da blockchain Ethereum mostrou latência p99 abaixo de 1 milissegundo classificando dado como válido ou suspeito em tempo real.","title":"Detectar dado corrompido em menos de 1 milissegundo: o que muda quando o Spark para de esperar o próximo micro-batch"},{"content":"O Databricks MVP Bartosz Konieczny detalhou como aplicar o Ruff em projetos Databricks, especificamente dentro de Declarative Automation Bundles, a mesma ferramenta que a comunidade do Apache Spark adotou a partir da versão 4.2.0, tanto para lint quanto para formatação de código, com dois comandos (check e format) integrados direto no pipeline de CI/CD do próprio projeto.\nO ponto que mais chama atenção não é a ferramenta em si, Ruff já é conhecida, é a recomendação de onde colocar cada verificação no ciclo de deploy: lint não deveria bloquear deploy em ambiente de sandbox, e sim ficar reservado para CI/CD em branch principal ou de release. Um hook de pre-commit local complementa isso, pegando problema antes mesmo do código sair da máquina do desenvolvedor.\nPor que isso é mais relevante do que \u0026ldquo;só mais um linter\u0026rdquo;:\nCom agente de código gerando cada vez mais código Databricks, quem revisa precisa de regras consistentes pra conseguir avaliar o que está sendo gerado Separar lint de sandbox e lint de CI/CD reconhece que velocidade de iteração e rigor de qualidade têm momentos diferentes no ciclo de deploy Ruff cobrindo tanto lint (Pyflakes, pycodestyle, bugbear, segurança, performance) quanto formatação num único binário reduz a lista de ferramentas que um projeto precisa manter Minha ressalva: a recomendação de \u0026ldquo;não copiar configuração de lint de outro projeto sem avaliar\u0026rdquo; é fácil de concordar em teoria e fácil de ignorar na prática, a maioria dos times realmente copia a config de lint de algum repositório de referência e nunca revisita. Vale tratar esse \u0026ldquo;construa seu próprio contrato de qualidade\u0026rdquo; como trabalho de verdade, com tempo alocado, não como um checkbox que se marca uma vez e esquece.\nFonte: https://www.waitingforcode.com/databricks/ruff-declarative-automation-bundles/read\n#Databricks #ApacheSpark #DevOps\n","permalink":"https://wiliamrosa.github.io/posts/databricks-spark-ruff-linting-bundles/","summary":"A comunidade Spark passou a usar Ruff pra lint e formatação a partir da versão 4.2. O Databricks MVP Bartosz Konieczny explica como incorporar isso aos Declarative Automation Bundles sem travar deploys em sandbox.","title":"O próprio Apache Spark adotou o Ruff, e isso muda como eu penso em lint pra Databricks"},{"content":"O Databricks MVP Bartosz Konieczny detalhou um padrão batizado de Dynamic Data Overwriter, evolução do clássico \u0026ldquo;Data Overwrite\u0026rdquo; que ele já documentava no livro \u0026ldquo;Data Engineering Design Patterns\u0026rdquo;: se sua tabela é particionada ou clusterizada, você não precisa dizer explicitamente quais partições substituir, o engine consegue descobrir isso sozinho a partir dos próprios dados de entrada.\nO mecanismo central é a detecção automática de escopo: o partitionOverwriteMode=dynamic do Apache Spark, o INSERT INTO ... REPLACE USING do liquid clustering do Databricks, e a estratégia incremental insert_overwrite do dbt implementam essa ideia nativamente. Quando não existe uma chave de partição clara, um MERGE bem construído com um identificador único de linha reproduz o mesmo comportamento.\nPor que esse padrão resolve um atrito real:\nElimina reprocessamento desnecessário de dados que não mudaram, só porque a lógica de overwrite tradicional exige reescrever a tabela inteira Funciona nativamente com liquid clustering, sem precisar desenhar esquema de particionamento manual Reduz o custo de compute em pipelines que hoje já fazem overwrite completo por simplicidade, não por necessidade real Minha ressalva: o próprio Bartosz já sinaliza os problemas que essa técnica não resolve sozinha, dado atrasado (late data) que chega fora da janela esperada, visibilidade real do que mudou entre execuções, e o trade-off de performance quando o escopo detectado automaticamente é maior do que o esperado. Detecção automática de escopo é ótima até o dia em que ela decide reprocessar mais partições do que você imaginava, e a fatura de compute chega maior sem aviso.\nFonte: https://www.waitingforcode.com/data-engineering-patterns/data-engineering-design-patterns-dynamic-data-overwriter/read\n#Databricks #LiquidClustering #DeltaLake\n","permalink":"https://wiliamrosa.github.io/posts/databricks-liquid-clustering-dynamic-overwrite/","summary":"O Databricks MVP Bartosz Konieczny detalha o Dynamic Data Overwriter: usar partitionOverwriteMode dinâmico ou liquid clustering com INSERT INTO\u0026hellip;REPLACE USING pra substituir só o subconjunto de dados afetado, sem tocar no resto da tabela.","title":"Reprocessar a tabela inteira só pra atualizar duas partições? Existe um padrão pra isso"},{"content":"Unity AI Gateway promete governança unificada pra qualquer modelo, mas \u0026ldquo;unificado\u0026rdquo; não quer dizer \u0026ldquo;igual\u0026rdquo; na hora de pagar a conta.\nO Databricks MVP Gary Nakanelua montou um experimento simples pra testar o que a unificação realmente remove: apontou uma única configuração de Unity AI Gateway pra três famílias de modelo hospedadas no Databricks (Claude Haiku, Llama 3.3 e GPT OSS), todas via Foundation Model APIs, pay-per-token, sem chave externa nenhuma.\nO resultado técnico mais interessante não foi sobre funcionalidade, foi sobre custo escondido atrás da mesma barreira de segurança. A mesma configuração de guardrails bloqueou uma tentativa de prompt injection 3 de 3 vezes, antes mesmo de chegar em qualquer modelo, e o rastreamento de uso escreveu um ledger por modelo numa system table sem exigir nenhuma linha de código de log. Até aqui, unificação cumprindo a promessa. Mas o mesmo prompt, com as mesmas palavras, custou 21 tokens de entrada na Claude contra 115 tokens de entrada no GPT OSS, uma diferença de cinco vezes pro mesmo pedido.\nPontos que valem registrar do experimento:\nGuardrails aplicados uma vez cobriram os três modelos simultaneamente, sem configuração duplicada Bloqueio de prompt injection funcionou no lado de entrada, antes da chamada chegar em qualquer modelo externo Ledger de uso por token e por modelo foi gravado automaticamente numa system table Modelos pay-per-token compartilhados são endpoint de sistema compartilhado entre times, o que aponta pra necessidade de isolamento por time no futuro Minha ressalva: governança unificada de acesso não é o mesmo que custo unificado, e esse experimento deixa isso bem claro. Se sua empresa está roteando tráfego pra múltiplos modelos achando que a diferença é só de qualidade de resposta, vale medir tokenização real por modelo antes de decidir qual usar por padrão, porque uma diferença de 5x em tokens de entrada muda a conta rapidamente em escala de produção.\nFonte: https://www.linkedin.com/in/gnakan/\n#Databricks #UnityAIGateway #FinOps\n","permalink":"https://wiliamrosa.github.io/posts/databricks-unity-ai-gateway-teste-guardrails-custo-tokens/","summary":"Um MVP apontou um Unity AI Gateway pra três modelos hospedados no Databricks e mediu guardrail bloqueando prompt injection 3 de 3 vezes, mas com uma diferença de até 5x no custo de token pro mesmo prompt entre modelos.","title":"Testei três modelos atrás do mesmo Unity AI Gateway, e o custo de token variou cinco vezes pra pergunta idêntica"},{"content":"O Lakehouse//RT entrou em beta como um novo tipo de SQL warehouse serverless, desenhado especificamente pra latência sub-segundo em consultas de leitura contra tabelas do Unity Catalog, com alta concorrência, pensado pra servir dashboards de Power BI e analytics operacional pra centenas ou milhares de usuários simultâneos.\nIsso é uma categoria de warehouse diferente da que a maioria já usa. Warehouse serverless comum é ótimo pra consulta analítica esporádica; Lakehouse//RT mira o cenário de \u0026ldquo;milhares de pessoas atualizando o mesmo dashboard ao mesmo tempo, toda hora\u0026rdquo;.\nPor que vale acompanhar:\nDashboard de Power BI lento por causa de concorrência é uma reclamação clássica de quem serve BI em escala Separar warehouse \u0026ldquo;analítico esporádico\u0026rdquo; de warehouse \u0026ldquo;operacional de alta concorrência\u0026rdquo; é reconhecer que são cargas de trabalho diferentes, não a mesma coisa em tamanhos diferentes Se performar como anunciado, reduz a pressão pra exportar dado do Lakehouse pra um banco separado só pra servir dashboard rápido Minha ressalva: \u0026ldquo;sub-segundo\u0026rdquo; em beta e \u0026ldquo;sub-segundo\u0026rdquo; em produção sob pico real de usuários raramente são a mesma promessa. Antes de migrar um dashboard crítico, eu testaria concorrência real, não só o benchmark de lançamento.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/release-notes/product/2026/june\n#AzureDatabricks #LakehouseRT #PowerBI\n","permalink":"https://wiliamrosa.github.io/posts/azure-databricks-lakehouse-rt-reyden/","summary":"Um novo tipo de SQL warehouse serverless mirando latência sub-segundo em alta concorrência, o Lakehouse tentando entrar em terreno que sempre foi de banco operacional.","title":"Lakehouse//RT promete SQL em milissegundos pra milhares de usuários simultâneos"},{"content":"Toda empresa que já passou por auditoria de segurança conhece a pergunta incômoda: \u0026ldquo;esse ambiente de processamento de dado, quem garante que ele não muda de uma execução pra outra, e quem garante que o certificado interno da empresa está instalado nele?\u0026rdquo; Num cluster Databricks padrão, a resposta tende a ser vaga, porque o runtime é gerenciado pela Databricks e atualizado com o tempo. Pra times que rodam workload em ambiente regulado, banco, saúde, setor público, isso é exatamente o tipo de resposta que não passa numa auditoria.\nO Databricks Container Services muda essa conversa: em vez de aceitar o runtime padrão como caixa preta, dá pra construir a própria imagem Docker, versionar ela junto do código, escanear ela no mesmo pipeline de CI/CD que já existe pra aplicação, e usar exatamente essa imagem, travada, em produção. A ideia de \u0026ldquo;ambiente dourado\u0026rdquo; (golden image) que nunca muda sozinho deixa de ser promessa e vira configuração literal de cluster.\nO mecanismo: Databricks entrega o Spark, você entrega o resto Container Services deixa especificar uma imagem Docker na hora de criar o compute, mas antes disso um workspace admin precisa habilitar o recurso explicitamente pra conta inteira, via CLI (databricks workspace-conf set-status --json '{\u0026quot;enableDcs\u0026quot;: \u0026quot;true\u0026quot;}'), não vem ligado por padrão. A Databricks recomenda partir de uma base já testada por ela, publicada em databricksruntime/standard, databricksruntime/minimal ou databricksruntime/python no Docker Hub, com Dockerfiles públicos no GitHub em databricks/containers (imagem com sufixo -LTS recebe patch regular, as demais são só exemplo). É possível também construir a imagem do zero, mas nesse caso o Dockerfile precisa entregar JDK (na versão compatível com o Runtime alvo), bash, iproute2, coreutils, procps, sudo e acl, sobre Ubuntu (Alpine é suportado com pacote extra de coreutils/procps/sudo e setup manual de Python). Na inicialização do compute, a Databricks baixa a imagem do seu registry, cria o container, copia o código do Databricks Runtime pra dentro dele e só então roda os init scripts, sempre ignorando qualquer CMD ou ENTRYPOINT que a imagem declare. Dá pra pensar assim: o \u0026ldquo;motor\u0026rdquo; (agendamento de job, integração com Unity Catalog, runtime Spark) continua sendo responsabilidade da Databricks, e o \u0026ldquo;chassi\u0026rdquo; (biblioteca de sistema, certificado, binário nativo) passa a ser seu.\nVale registrar que esse fluxo descrito aqui é especificamente o Container Services pra compute de acesso dedicado; existe uma variante em Beta separada pra compute em modo de acesso standard, com página própria na documentação, que não é o foco deste artigo.\nMão na massa: base própria, publicada e usada num cluster Um Dockerfile mínimo que parte da base oficial, adiciona uma biblioteca Python e um certificado corporativo:\nFROM databricksruntime/standard:16.4-LTS # biblioteca extra usando o pip específico da imagem RUN /databricks/python3/bin/pip install pandas==2.2.2 # certificado interno da empresa, exigência recorrente de compliance COPY corp-ca.crt /usr/local/share/ca-certificates/corp-ca.crt RUN update-ca-certificates Depois de publicar essa imagem num registry (Docker Hub ou Azure Container Registry, com autenticação básica), o cluster é criado apontando pra ela via API ou UI:\ndatabricks clusters create \\ --cluster-name etl-compliance \\ --node-type-id Standard_DS3_v2 \\ --json \u0026#39;{ \u0026#34;num_workers\u0026#34;: 2, \u0026#34;docker_image\u0026#34;: { \u0026#34;url\u0026#34;: \u0026#34;meuregistro.azurecr.io/etl-runtime:2026-06-25\u0026#34;, \u0026#34;basic_auth\u0026#34;: { \u0026#34;username\u0026#34;: \u0026#34;{{secrets/docker/registry-user}}\u0026#34;, \u0026#34;password\u0026#34;: \u0026#34;{{secrets/docker/registry-pass}}\u0026#34; } }, \u0026#34;spark_version\u0026#34;: \u0026#34;16.4.x-scala2.12\u0026#34; }\u0026#39; Note a tag da imagem carregando a data do build: numa auditoria, \u0026ldquo;qual exatamente é o ambiente que rodou esse job em produção no dia X\u0026rdquo; vira uma resposta objetiva, não uma suposição sobre o estado do runtime gerenciado naquela data.\nOnde entra o CI/CD de verdade O ganho maior não é o Dockerfile em si, é encaixar a construção da imagem no mesmo pipeline que já faz build e teste de código de aplicação: build da imagem, scan de vulnerabilidade (Trivy, Grype, ou o scanner que a empresa já usa), push pro registry privado só se o scan passar, e só então liberação da tag nova pro cluster de produção. Isso transforma \u0026ldquo;qual biblioteca está instalada nesse cluster\u0026rdquo; de pergunta que só o time de plataforma sabe responder em artefato versionado no Git, com histórico e review, igual qualquer outro deploy.\nNa prática: o argumento de compliance é o que mais aparece nesse tipo de decisão, mas o efeito colateral que mais economiza tempo de time no dia a dia é outro, biblioteca nativa e binário que hoje viram init script frágil e demorado passam a fazer parte da imagem, e o cluster sobe mais rápido porque não precisa reinstalar nada toda vez.\nImagem própria ou init script: como escolher Nem toda customização justifica sair construindo Dockerfile. A própria documentação da Databricks separa os dois casos com um critério simples: o que precisa acontecer na construção do ambiente (biblioteca de sistema, certificado, binário nativo, JDK específico) pertence à imagem; o que precisa acontecer toda vez que o compute liga (subir um daemon de segurança, registrar o node num serviço externo, configuração que depende de variável só disponível em runtime) pertence ao init script, mesmo rodando dentro de um container customizado. Misturar as duas coisas, colocando no init script o que devia estar no Dockerfile, é o motivo mais comum de cluster que demora minutos a mais pra subir sem necessidade nenhuma: toda inicialização reinstala pacote que já podia estar cozido na imagem desde o build.\nIsso importa porque a decisão de adotar Container Services não é tudo ou nada. Dá pra manter o runtime gerenciado padrão pra maioria dos clusters e reservar a imagem própria só pros workloads que realmente carregam exigência de compliance ou dependência nativa incomum, o que limita a superfície de manutenção justamente ao ponto onde o ganho compensa o custo de manter imagem atualizada.\nO que isso não resolve Container Services não é gratuito em manutenção. A imagem passa a ser responsabilidade de quem construiu, incluindo atualização de patch de segurança do sistema operacional base, uma tarefa que o runtime gerenciado normalmente absorve sozinho. Databricks Runtime for Machine Learning não é suportado nesse modelo, então workload de ML que depende dele precisa ficar fora dessa estratégia ou replicar manualmente o que aquele runtime já entrega pronto. Acesso a Volumes do Unity Catalog exige ligar spark.databricks.unityCatalog.volumes.enabled=true na configuração Spark do compute, e Hive metastore federado exige spark.databricks.unityCatalog.hms.federation.enabled=true, nenhum dos dois vem habilitado por padrão. Autenticação via notebook não é suportada nesse modelo. Vale ainda evitar montar recurso na faixa 172.17.0.0/16, que é a rede padrão do próprio Docker e pode gerar conflito de IP difícil de diagnosticar. E a documentação é direta numa ressalva que vale levar a sério: um container que funciona local ou na máquina de build pode falhar, ter feature desabilitada, ou parar de funcionar silenciosamente quando sobe num compute Databricks real, no pior caso corrompendo dado ou expondo dado a terceiro, então \u0026ldquo;testei localmente\u0026rdquo; não é suficiente, o teste em compute real de não produção é obrigatório antes de qualquer promoção pra produção.\nVale a pena adotar? Faz sentido pra quem já tem exigência de compliance documentada (certificado corporativo obrigatório, biblioteca proibida por política interna, ambiente que precisa ser auditável e reprodutível) ou pra quem já mantém pipeline de CI/CD maduro e quer eliminar init script frágil. Não faz sentido trocar o conforto do runtime gerenciado por Docker só porque parece mais \u0026ldquo;engenheiro de plataforma\u0026rdquo;: cada imagem própria é mais um artefato pra manter atualizado e mais uma superfície de erro no lançamento do cluster.\nReferências Microsoft Learn, \u0026ldquo;Databricks Container Services for dedicated compute\u0026rdquo;: https://learn.microsoft.com/en-us/azure/databricks/compute/custom-containers Databricks base images e Dockerfiles: https://github.com/databricks/containers #Databricks #Docker #CICD #Compliance\n","permalink":"https://wiliamrosa.github.io/articles/databricks-container-services-docker-compliance/","summary":"Databricks Container Services deixa trocar o runtime gerenciado por uma imagem Docker própria, construída e escaneada no seu próprio pipeline de CI/CD. Resolve certificado corporativo, biblioteca proibida e ambiente travado, mas exige abrir mão de parte do conforto de um cluster totalmente gerenciado.","title":"Runtime engessado ou imagem Docker própria: o dilema de compliance que o Databricks Container Services resolve"},{"content":"O Databricks MVP Jacek Laskowski chamou atenção pro Delta Lake 4.3, que avança sobre as catalog-managed tables com as Unity Catalog Delta REST APIs: agora operações de tabela, carregamento, CREATE, CTAS, REPLACE, CREATE OR REPLACE, RTAS, evolução de schema via DML, e ALTER TABLE suportado, passam por APIs unificadas de catálogo, com validação de commit do lado do servidor. Antes, era comum que só a leitura se beneficiasse de um catálogo central; agora a escrita também fica sujeita à mesma validação.\nA versão também melhora o UniForm, a conversão incremental e atômica pra Iceberg: o modo experimental IcebergCompatV3 passa a suportar deletion vectors e UniForm na mesma tabela, uma combinação que antes exigia escolher entre um recurso ou outro.\nPor que isso é mais relevante do que \u0026ldquo;mais uma versão do Delta\u0026rdquo;:\nValidação de commit do lado do catálogo pra operações de escrita fecha uma lacuna que existia entre \u0026ldquo;o catálogo sabe o que existe\u0026rdquo; e \u0026ldquo;o catálogo garante que a escrita seguiu as regras\u0026rdquo; Apache Spark, DuckDB, Apache Flink e clientes Delta-Kernel conseguem compartilhar a mesma tabela através de um catálogo único, interoperabilidade que historicamente era o ponto fraco do formato Deletion vectors + UniForm juntos significa que dá pra ter performance de delete moderna sem abrir mão da compatibilidade com Iceberg Minha ressalva: interoperabilidade multi-engine sobre o mesmo catálogo é ótima na teoria, mas cada engine adicional que escreve na mesma tabela é mais uma superfície de comportamento pra testar, a promessa de \u0026ldquo;qualquer engine, mesma tabela\u0026rdquo; só se sustenta na prática se cada implementação respeitar de fato as mesmas garantias de commit. Eu testaria com cuidado antes de misturar múltiplos engines de escrita na mesma tabela em produção.\nFonte: https://delta.io/blog/2026-06-22-delta-4-3-release/\n#Databricks #DeltaLake #ApacheIceberg\n","permalink":"https://wiliamrosa.github.io/posts/delta-lake-4-3-catalog-managed-tables/","summary":"Delta 4.3 expande as catalog-managed tables para que operações de escrita, CREATE, REPLACE, ALTER TABLE, também passem por validação de commit do lado do catálogo, não só a leitura.","title":"Delta 4.3 faz até CREATE TABLE passar pelo catálogo, não só a leitura"},{"content":"Toda negociação de cruzamento de dado entre duas empresas trava no mesmo ponto: quem confia em quem primeiro. O parceiro de dado não quer expor a base de cliente crua pra terceiro, e quem detém o algoritmo de matching não quer entregar a lógica proprietária que levou anos pra afinar. O resultado histórico é reunião jurídica longa, contrato de processamento de dado, e em muitos casos a integração simplesmente não sai do papel porque nenhum dos dois lados topa piscar primeiro.\nAs Clean Rooms do Azure Databricks já resolviam parte disso desde que existem, criando um ambiente onde duas organizações compartilham metadado e rodam notebook aprovado sem se ver o dado bruto uma da outra. O que muda com o modo empacotado é mais sutil e, pra quem já bateu de frente com esse tipo de negociação, mais relevante: ele quebra a simetria de privilégio entre os dois lados de propósito, porque o problema real raramente é simétrico.\nO mecanismo: dois papéis, dois conjuntos de privilégio No modelo padrão de Clean Room (chamado de \u0026ldquo;no-trust\u0026rdquo; ou baseado em aprovação), todos os colaboradores têm privilégio igual: qualquer um pode subir notebook, mas ele só roda depois que todos os outros colaboradores aprovarem explicitamente o código, linha por linha se quiserem. Isso funciona bem quando as duas partes têm capacidade técnica parecida e querem revisar o que roda sobre o dado delas.\nO modo empacotado assume outra configuração de poder, bem mais comum na prática: um parceiro (o \u0026ldquo;provedor\u0026rdquo;) é dono de uma análise proprietária, tipo um algoritmo de matching de identidade, e quer que outra empresa (a \u0026ldquo;consumidora\u0026rdquo;) rode essa análise contra o próprio dado dela, sem nunca enxergar o código por trás. A tabela abaixo, direto da documentação oficial, resume a diferença de privilégio entre os três papéis possíveis:\nCapacidade Aprovação (padrão) Empacotado (consumidor) Empacotado (provedor) Ver notebook/JAR Código completo visível Só o nome, sem código Os próprios notebooks Adicionar notebook/JAR Sim Não Sim Ver dado do outro lado Tudo visível Só o próprio dado Só o próprio dado Ver resultado da execução Sim Sim Não Disparar execução Sim Sim Não Repare no que fica invisível em cada direção: o provedor nunca vê o dado do consumidor nem o resultado da execução (ele só sabe, pelo histórico, que uma execução aconteceu), e o consumidor nunca vê o código do provedor, só o nome do notebook, como se fosse uma biblioteca privada que ele confia sem auditar. Nenhum dos dois lados tem privilégio de administrador dentro da \u0026ldquo;clean room central\u0026rdquo;, o ambiente efêmero e isolado, hospedado pela Databricks, onde a execução de fato acontece.\nMinha leitura: o detalhe que mais gosto nesse desenho é que ele não tenta fingir simetria onde não existe. Toda vez que vi negociação de cruzamento de dado travar, era porque o modelo de confiança proposto (geralmente \u0026ldquo;os dois revisam tudo\u0026rdquo;) não batia com a realidade de que um lado tem ativo proprietário que não vai expor de jeito nenhum. Empacotar essa assimetria em vez de negá-la é o que faz esse modelo ser adotável de verdade.\nMão na massa: criando uma clean room empacotada via API A criação passa por três decisões que precisam estar corretas desde o início, porque o modo empacotado é definido na criação e não pode ser alterado depois. Via REST API, o corpo da requisição de criação já sinaliza isso no campo package_provider_collaborator_alias:\n{ \u0026#34;name\u0026#34;: \u0026#34;matching-identidade-parceiro-x\u0026#34;, \u0026#34;remote_detailed_info\u0026#34;: { \u0026#34;cloud_vendor\u0026#34;: \u0026#34;azure\u0026#34;, \u0026#34;region\u0026#34;: \u0026#34;eastus2\u0026#34;, \u0026#34;collaborators\u0026#34;: [ { \u0026#34;global_metastore_id\u0026#34;: \u0026#34;azure:eastus2:11111111-2222-3333-4444-555555555555\u0026#34;, \u0026#34;collaborator_alias\u0026#34;: \u0026#34;minha_empresa\u0026#34; } ], \u0026#34;egress_network_policy\u0026#34;: { \u0026#34;internet_access\u0026#34;: { \u0026#34;restriction_mode\u0026#34;: \u0026#34;FULL_ACCESS\u0026#34; } }, \u0026#34;package_provider_collaborator_alias\u0026#34;: \u0026#34;minha_empresa\u0026#34; }, \u0026#34;owner\u0026#34;: \u0026#34;dono.projeto@empresa.com\u0026#34;, \u0026#34;comment\u0026#34;: \u0026#34;Clean room empacotada para matching de identidade com Parceiro X\u0026#34; } O campo que faz a diferença é package_provider_collaborator_alias: apontar o alias de um colaborador ali designa esse colaborador como provedor, e todos os outros entram automaticamente como consumidores. Depois de criada, cabe ao provedor subir o notebook e os assets de dado dele (visíveis só pra ele), e cabe ao consumidor adicionar o próprio dado (via Add Input Data, visível só pra ele) e disparar a execução. O consumidor então vê o resultado; o provedor só vê, no histórico de execução, que uma run aconteceu, sem acesso ao output.\nOnde isso resolve um problema real: matching de identidade sem expor a base O case que a Databricks documentou com a Stagwell (agência que mantém um grafo de identidade próprio) ilustra bem o encaixe: a marca cliente tem a própria base de clientes com email, dispositivo e cookie, e a Stagwell tem o algoritmo proprietário de resolução de identidade construído ao longo de anos. Numa clean room empacotada, a Stagwell entra como provedora do notebook de matching, a marca entra como consumidora trazendo só a própria base, dispara a execução, e recebe de volta taxa de correspondência e cobertura, sem que a Stagwell precise expor a lógica de matching e sem que a marca precise exportar dado bruto de cliente pra fora do próprio ambiente controlado.\nO resultado final também pode ser compartilhado de volta pros dois lados através de uma tabela de saída (output table), registrada num schema compartilhado que ambos conseguem ler, útil quando o objetivo não é só o consumidor ver o resultado, mas os dois lados alinharem sobre o mesmo número de cobertura.\nO que garante a confiança nesse modelo (e onde ela ainda depende de você) Vale entender por que esse modelo não é \u0026ldquo;confiança cega\u0026rdquo;. A clean room central roda em plano de computação serverless isolado, gerenciado pela própria Databricks, numa região que quem cria a clean room escolhe. Nenhuma das partes tem acesso de administrador a esse ambiente, e toda ação (quem rodou o quê, quando, qual versão do notebook) fica registrada numa tabela de sistema de eventos e no log de auditoria da conta.\nIsso cobre o eixo \u0026ldquo;quem viu o quê\u0026rdquo;, mas existe um eixo separado que continua sendo responsabilidade de quem entra como consumidor: a política de rede de saída (egress network policy) da clean room. Se o egress estiver liberado (FULL_ACCESS, como no exemplo acima) ou permitir endpoint externo que o consumidor não valida antes, o código do provedor, que o consumidor não pode inspecionar, tecnicamente teria como enviar o dado do consumidor pra fora do ambiente controlado. A documentação oficial é direta sobre isso: antes de contribuir dado sensível numa clean room empacotada, revisar a política de egress não é opcional, é a única auditoria que o consumidor ainda tem disponível já que o código em si está fechado pra ele.\nNa prática: eu trataria a configuração de egress como o item número um de checklist antes de qualquer dado real entrar numa clean room empacotada como consumidor, não como detalhe de configuração pra revisar depois. É o único controle que sobra quando você abre mão de auditar o código.\nO que isso não resolve O modo empacotado não é a opção certa quando as duas partes querem simetria de revisão, nesse caso o modelo de aprovação padrão continua sendo o adequado. Regra de auto-aprovação fica desabilitada pra todo mundo dentro de uma clean room empacotada, inclusive pro provedor, o que significa que não dá pra automatizar liberação de notebook novo sem intervenção manual. Cada clean room tem limite de dez colaboradores e não pode ser renomeada depois de criada, então o planejamento de nome e escopo precisa acontecer antes, não durante. E, como já dito, a decisão entre modelo empacotado e modelo de aprovação é definitiva no momento da criação, não existe migração de um pro outro depois que a clean room já está em uso.\nVale a pena adotar? Faz sentido quando existe assimetria real de propriedade intelectual entre as partes, um lado com algoritmo proprietário que não pode ser exposto, o outro com dado sensível que não pode ser exportado, e ambos precisam do resultado do cruzamento entre os dois. Não faz sentido forçar esse modelo quando as duas partes têm capacidade e interesse de revisar o código uma da outra, nesse caso a fricção extra de nunca ver o notebook completo não compra segurança adicional, só reduz visibilidade sem necessidade. Quem for adotar como consumidor: trate a política de egress como parte da diligência, não como detalhe técnico de configuração.\nReferências Microsoft Learn, \u0026ldquo;What is Azure Databricks Clean Rooms?\u0026rdquo;: https://learn.microsoft.com/en-us/azure/databricks/clean-rooms/ Microsoft Learn, \u0026ldquo;Packaged clean rooms\u0026rdquo;: https://learn.microsoft.com/en-us/azure/databricks/clean-rooms/packaged-clean-rooms Databricks Docs, \u0026ldquo;Create a clean room (REST API)\u0026rdquo;: https://docs.databricks.com/api/workspace/cleanrooms/create Databricks Blog, \u0026ldquo;How Stagwell built privacy-safe ID matching on Databricks\u0026rdquo;: https://www.databricks.com/blog/how-stagwell-built-privacy-safe-id-matching-databricks #Databricks #CleanRooms #UnityCatalog #Governanca\n","permalink":"https://wiliamrosa.github.io/articles/clean-rooms-empacotados-provedor-consumidor/","summary":"O modo \u0026rsquo;empacotado\u0026rsquo; das Clean Rooms do Azure Databricks separa o papel de provedor (que traz o algoritmo e nunca expõe o código) do papel de consumidor (que traz o dado e nunca vê a lógica), permitindo cruzar identidade ou fazer matching entre empresas sem que nenhum dos dois lados abra mão do que é proprietário.","title":"Clean Rooms empacotados: como rodar o algoritmo de um parceiro sem nunca ver o código dele"},{"content":"A relação entre Azure Databricks e Microsoft Fabric deixou de ser só \u0026ldquo;ler os dados do outro\u0026rdquo; e virou uma via de mão dupla.\nDe um lado, a federação de catálogo do OneLake atingiu GA: o Unity Catalog consulta dados que vivem no OneLake sem copiar nada. Do outro, entrou em beta a capacidade de o Databricks armazenar Delta tables gerenciadas nativamente dentro do próprio OneLake.\nPor que isso importa pra quem vive entre os dois mundos (Fabric no time de BI, Databricks no time de engenharia):\nAcaba a pergunta \u0026ldquo;onde é a fonte da verdade\u0026rdquo;, os dois lados podem apontar pro mesmo storage Menos pipeline de sincronização só pra levar dado de um lado pro outro Governança via Unity Catalog passa a valer também pro que fica fisicamente no OneLake Minha ressalva: \u0026ldquo;sem cópia\u0026rdquo; não é sinônimo de \u0026ldquo;sem latência\u0026rdquo;. Vale testar o desempenho de consulta federada sob carga real antes de assumir que substitui integração nativa, histórico de federação de catálogo entre plataformas diferentes costuma ter pegadinha de performance que só aparece em produção.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/release-notes/product/2026/june\n#AzureDatabricks #OneLake #MicrosoftFabric\n","permalink":"https://wiliamrosa.github.io/posts/azure-databricks-onelake-bidirecional/","summary":"Federação de catálogo virou GA e o armazenamento nativo de Delta tables no OneLake entrou em beta, pela primeira vez a via de mão dupla entre Databricks e Fabric é oficial.","title":"Azure Databricks e OneLake agora conversam nos dois sentidos"},{"content":"A Databricks lançou o CustomerLake: uma CDP (Customer Data Platform) nativamente agêntica, com Profile Agents e Campaign Agents cuidando de segmentação e orquestração de experiência personalizada, tudo em cima do mesmo Lakehouse que já governa o resto dos dados da empresa.\nIsso é diferente de \u0026ldquo;mais uma feature de marketing\u0026rdquo;: é a Databricks entrando de vez em um mercado (CDP) que hoje é dominado por plataformas especializadas, e apostando que ter o dado unificado e governado desde a origem vale mais do que a profundidade de feature de um CDP dedicado.\nPor que isso é relevante além do time de marketing:\nElimina a exportação de perfil de cliente do Lakehouse pra uma plataforma de CDP externa Profile Agent e Campaign Agent herdam a mesma governança de Unity Catalog que já existe pros outros dados Times de dados que já mantêm o Lakehouse como fonte única ganham controle sobre uma peça que normalmente vivia isolada em outra ferramenta Minha ressalva: CDP é um mercado maduro, com ferramentas construídas especificamente pra esse caso de uso há mais de uma década. A pergunta que eu faria antes de migrar é: o CustomerLake compete em profundidade de feature de campanha, ou só resolve bem pra quem já vive 100% dentro do ecossistema Databricks e aceita trocar profundidade por unificação.\nFonte: https://www.databricks.com/blog/unifying-data-and-governance-agentic-era-whats-new-azure-databricks\n#AzureDatabricks #CustomerLake #CDP\n","permalink":"https://wiliamrosa.github.io/posts/azure-databricks-customerlake-cdp-agentica/","summary":"CustomerLake traz Profile Agents e Campaign Agents pra dentro do Lakehouse, e isso é a Databricks competindo direto com plataformas de dados de cliente estabelecidas.","title":"A Databricks entrou no território de CDP com agentes fazendo o trabalho de campanha"},{"content":"O Lakebase chegou ao Azure Databricks com um caso de uso bem concreto: branch de banco de dados para debugar agentes do GitHub Copilot em produção sem risco de compliance.\nA ideia é simples de explicar e difícil de fazer bem: você cria uma cópia leve (branch) do banco transacional, deixa o agente investigar ou reproduzir o problema nessa cópia, e descarta depois, sem nunca expor dado real de produção ao processo de debug.\nPor que isso resolve uma dor real:\nDebugar agente em produção hoje geralmente significa \u0026ldquo;olhar log e torcer\u0026rdquo; ou replicar o ambiente manualmente Branch de banco transacional, historicamente, é operação cara e lenta, aqui vira rotina Times de compliance ganham uma resposta pronta pra \u0026ldquo;como vocês testam agente sem tocar em dado sensível\u0026rdquo; Minha ressalva: branch fácil de criar é branch fácil de esquecer de apagar. Antes de adotar isso em escala, eu perguntaria como fica o ciclo de vida desses branches, quem garante que uma cópia de debug não vira um banco órfão rodando fatura sem ninguém saber.\nFonte: https://www.databricks.com/blog/unifying-data-and-governance-agentic-era-whats-new-azure-databricks\n#AzureDatabricks #Lakebase #GitHubCopilot\n","permalink":"https://wiliamrosa.github.io/posts/azure-databricks-lakebase-github-copilot-branching/","summary":"A combinação Lakebase + branching de banco resolve um problema bem específico: como debugar um agente em produção sem tocar nos dados reais.","title":"Lakebase chega ao Azure com branch de banco pra debugar agente do GitHub Copilot"},{"content":"📅 15 a 18 de junho de 2026 · 📍 San Francisco, EUA · Evento realizado\nEstar no Databricks Data + AI Summit, em San Francisco, foi uma experiência incrível. Além de acompanhar as principais tendências em IA e dados, é inspirador ver a forte presença da América Latina em um dos maiores eventos de tecnologia do mundo.\nMuitas ideias, aprendizados e conexões para levar de volta ao Brasil 🇧🇷.\nFeliz também por estar representando a nossa comunidade São Paulo Databricks User Group junto ao Nilton Kazuyuki Ueda.\n#DataAISummit\nSobre o evento O Data + AI Summit é o maior evento do mundo dedicado a dados e Inteligência Artificial, reunindo a comunidade Databricks global — incluindo uma presença cada vez mais forte da América Latina (🇧🇷 🇲🇽 🇨🇴 🇨🇱 🇦🇷 🇨🇷 🇵🇪 🇺🇾 🇵🇦 🇪🇨 🇧🇴 e muito mais).\n","permalink":"https://wiliamrosa.github.io/events/databricks-data-ai-summit-2026-san-francisco/","summary":"Representei a comunidade São Paulo Databricks User Group no Data + AI Summit 2026, em San Francisco, ao lado de Nilton Kazuyuki Ueda e de centenas de pessoas da América Latina.","title":"🌉 Databricks Data + AI Summit 2026 | San Francisco"},{"content":"Ingestão de streaming tradicional carrega uma decisão que ninguém gosta de tomar cedo demais: quantas partições sua fila vai ter. Errar pra menos significa gargalo quando o volume cresce. Errar pra mais significa overhead e complexidade desnecessária desde o primeiro dia. E o pior: mudar o número de partições depois que o sistema já está em produção normalmente exige rebalanceamento doloroso. O Zerobus Ingest ataca esse problema removendo a própria pergunta: em vez de partição fixa, a garantia de ordenação vive na conexão do stream, não num índice de partição pré-definido.\nO que é o Zerobus Ingest Zerobus é o serviço de ingestão de streaming totalmente gerenciado e serverless do Azure Databricks. Funciona como uma API push, onde produtores empurram dados diretamente para tabelas Delta governadas pelo Unity Catalog, sem provisionar broker de mensagens, sem gerenciar conector nem decidir esquema de partição antecipadamente. Segundo a documentação oficial, o fluxo de uso se resume a duas etapas: criar a tabela Delta com schema definido, e então enviar dados pra ela via gRPC, REST, OpenTelemetry (OTLP) ou, mais recentemente, um protocolo Kafka-compatível (ainda em Beta). A maior parte do serviço já está em disponibilidade geral (GA); os SDKs de C#/.NET e as APIs compatíveis com Kafka são as exceções documentadas em Beta.\nO mecanismo: particionamento dinâmico por conexão A ideia central é simples de enunciar, mas exige repensar onde a ordenação \u0026ldquo;mora\u0026rdquo;. Em vez de garantir ordem dentro de uma partição fixa (o modelo clássico de fila de mensagens), o Zerobus garante ordem dentro da conexão lógica de um produtor. Quando um cliente abre uma conexão de stream, ele recebe uma identidade lógica própria. Internamente, o serviço distribui essas conexões entre pods usando roteamento heurístico: se um pod está sobrecarregado, novas conexões são direcionadas pra outro pod com capacidade disponível. Isso destrava autoscaling de verdade, adicionar ou remover pods conforme a carga muda, sem exigir replanejamento de esquema de partição, porque a unidade de ordenação nunca dependeu do número de partições em primeiro lugar.\nDuas peças de engenharia sustentam esse modelo em alta vazão:\nZeroParser: um decodificador protobuf customizado, desenhado para fazer parsing em um único passe (single-pass) e zero alocação de memória, mesmo lidando com descritores de schema dinâmicos. O número reportado é de aproximadamente 1 GB/s por núcleo de CPU.\nWrite-ahead log com reconhecimento assíncrono: o servidor retorna o offset máximo já confirmado no stream, permitindo que o cliente limpe seus buffers locais assim que recebe esse ack, sem precisar de confirmação síncrona por mensagem individual.\nO teste de carga: dataset NASA NEOWISE Pra provar o mecanismo em escala real, a Databricks rodou um teste de 24 horas usando o dataset NEOWISE da NASA (cerca de 200 bilhões de pontos de observação acumulados em 11 anos de missão), com 2.048 streams concorrentes. Os números reportados:\nThroughput sustentado: 12 milhões de linhas por segundo. Vazão sustentada: 11,8 GB/s. Total ingerido: mais de 1 trilhão de registros. Resultado: mais de 1 petabyte de dado ingerido em menos de 24 horas. Minha leitura: o que mais me impressiona nesse tipo de benchmark não é o número absoluto, é a escolha do dataset. Dado astronômico real, com 11 anos de heterogeneidade de schema e volume, é um teste bem mais honesto do que um gerador sintético de linhas idênticas. Ainda assim, vale sempre lembrar que benchmark de fornecedor mede o melhor cenário controlado por quem construiu o sistema, então acompanhar como isso se comporta no seu workload real, com seu schema e sua distribuição de chegada de dado, continua sendo o teste que importa de verdade.\nMão na massa: enviando dados via gRPC (esqueleto conceitual) Um exemplo simplificado de como um produtor Python se conectaria ao Zerobus pra empurrar eventos, com base no modelo de autenticação e endpoint documentado:\nfrom zerobus.sdk import ZerobusClient, StreamConfig client = ZerobusClient( workspace_url=\u0026#34;https://\u0026lt;seu-workspace\u0026gt;.cloud.databricks.com\u0026#34;, client_id=\u0026#34;\u0026lt;CLIENT_ID\u0026gt;\u0026#34;, client_secret=\u0026#34;\u0026lt;CLIENT_SECRET\u0026gt;\u0026#34;, ) stream = client.open_stream( table=\u0026#34;main.telemetria.eventos_sensor\u0026#34;, config=StreamConfig(ack_mode=\u0026#34;async\u0026#34;), ) for evento in gerar_eventos_sensor(): stream.write(evento) # o ack assíncrono libera o buffer local sem round-trip por mensagem ultimo_offset_confirmado = stream.last_acked_offset() limpar_buffer_ate(ultimo_offset_confirmado) stream.close() O ponto chave nesse padrão é nunca bloquear o produtor esperando confirmação síncrona de cada linha individual, o que seria o gargalo clássico de qualquer sistema de ingestão de alta vazão.\nOnde isso se encaixa frente a Kafka e outras filas tradicionais Vale situar o Zerobus frente ao que a maioria dos times já conhece. Numa fila Kafka tradicional, você decide o número de partições no momento da criação do tópico, e essa escolha define o teto de paralelismo de consumo daquele tópico dali pra frente. Aumentar partições depois é possível, mas reordena o mapeamento de chave pra partição, o que quebra garantia de ordenação pra chaves que já existiam antes do aumento, a não ser que você planeje isso com cuidado. O Zerobus evita essa armadilha inteira porque nunca expõe o conceito de partição pro produtor: a unidade que importa é a conexão de stream, que o cliente abre e fecha livremente, sem negociar antecipadamente quantas dessas conexões vão existir ou como elas mapeiam pra infraestrutura interna. Isso desloca a complexidade de dimensionamento do lado do usuário pro lado da plataforma, o que é exatamente a proposta de um serviço serverless: você paga pra não ter que tomar essa decisão.\nO que isso não resolve Particionamento dinâmico por conexão resolve o problema de escalonamento operacional, mas não elimina a necessidade de pensar em chave de negócio pra consultas downstream. A tabela Delta resultante ainda se beneficia de boas escolhas de clustering e Z-ordering pra leitura eficiente, o particionamento dinâmico do lado da ingestão não substitui isso. Também vale notar que a documentação remete a um documento separado de \u0026ldquo;Zerobus Ingest quotas\u0026rdquo; pra limites precisos de throughput por workspace, então antes de dimensionar uma carga de produção nesse volume vale checar esses limites específicos da sua conta, não só o número do benchmark publicado.\nResumindo Deslocar a garantia de ordenação da partição fixa pra conexão de stream é o tipo de decisão arquitetural que parece pequena no papel mas resolve um problema operacional real: não ter que adivinhar, com meses de antecedência, quantas partições um sistema de ingestão vai precisar. O benchmark de 1 petabyte em 24 horas prova que o modelo escala, mas o valor prático pro dia a dia está em não precisar mais ter essa conversa de dimensionamento de partição logo na largada de um projeto novo.\nReferências Ingesting the Milky Way at petabyte scale with Zerobus Ingest (blog oficial Databricks) Zerobus Ingest overview (documentação oficial) Zerobus Ingest overview (Microsoft Learn) #Databricks #Zerobus #Streaming #DataEngineering\n","permalink":"https://wiliamrosa.github.io/articles/zerobus-ingest-particionamento-dinamico-petabyte/","summary":"A Databricks publicou um teste de carga do Zerobus Ingest usando o dataset NASA NEOWISE, sustentando 12 milhões de linhas por segundo e ingerindo mais de 1 trilhão de registros em 24 horas. O truque estrutural é deslocar a garantia de ordenação da partição fixa para a conexão de stream, permitindo autoscaling real de pods sem repensar o esquema de particionamento.","title":"1 petabyte em menos de 24 horas: o que acontece quando você tira a partição fixa do meio do caminho"},{"content":"O app do Databricks Genie chegou ao Microsoft Teams em beta: mensagem direta ou @menção num canal, e a pergunta roteia pro Genie ou pra um Genie Agent fixado, sem abrir o workspace do Databricks em nenhum momento.\nParece um detalhe de distribuição, mas é o tipo de mudança que decide se uma ferramenta de dados é usada por 50 pessoas do time de analytics ou por 5.000 pessoas da empresa inteira.\nPor que essa integração pesa mais do que \u0026ldquo;mais um canal de acesso\u0026rdquo;:\nA barreira de entrada pra perguntar algo ao Genie deixa de ser \u0026ldquo;ter conta e saber navegar no Databricks\u0026rdquo; Área de negócio já vive dentro do Teams o dia inteiro, a pergunta de dado se torna tão natural quanto perguntar pra um colega Governança do Unity Catalog continua valendo: quem pergunta só vê o que tem permissão de ver Minha ressalva: colocar uma ferramenta de linguagem natural dentro do canal onde todo mundo já está aumenta o volume de perguntas mal formuladas recebendo respostas mal calibradas. Facilitar o acesso sem investir em curadoria dos Genie Agents que respondem é trocar \u0026ldquo;ninguém usa\u0026rdquo; por \u0026ldquo;todo mundo usa errado\u0026rdquo;.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/release-notes/product/2026/june\n#AzureDatabricks #Genie #MicrosoftTeams\n","permalink":"https://wiliamrosa.github.io/posts/azure-databricks-genie-microsoft-teams/","summary":"Perguntar sobre dado do Lakehouse sem sair do Teams parece um detalhe de UX, mas muda quem realmente usa Genie no dia a dia.","title":"O Genie virou um app dentro do Microsoft Teams"},{"content":"O conector gerenciado de SharePoint no Lakeflow Connect ganhou suporte a ingestão de arquivo estruturado (CSV, JSON, XML, Excel, Parquet, Avro, ORC), metadados de arquivo, filtros e schema evolution, substituindo a abordagem anterior, que só lidava com conteúdo não-estruturado.\nIsso muda o que dá pra fazer: antes, SharePoint no pipeline era basicamente \u0026ldquo;jogar PDF pra dentro de um volume e extrair texto depois\u0026rdquo;. Agora, planilha e arquivo estruturado dentro de biblioteca de documentos do SharePoint entram na esteira de ingestão do mesmo jeito que uma tabela de banco relacional.\nPor que isso é mais relevante do que parece à primeira vista:\nMuita empresa ainda trata SharePoint como \u0026ldquo;banco de dados informal\u0026rdquo; de área de negócio Schema evolution automático evita quebrar pipeline toda vez que alguém adiciona uma coluna na planilha Metadados de arquivo (quem criou, quando modificou) viram linhagem, não só o conteúdo Minha ressalva: formalizar ingestão de SharePoint estruturado é reconhecer que dado de negócio crítico vive fora do Lakehouse, em planilha compartilhada sem controle de versão de schema. A ferramenta resolve o sintoma; o problema de governança de \u0026ldquo;quem pode criar uma coluna nova numa planilha que alimenta um pipeline\u0026rdquo; continua sendo humano.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/release-notes/product/2026/june\n#AzureDatabricks #SharePoint #LakeflowConnect\n","permalink":"https://wiliamrosa.github.io/posts/azure-databricks-sharepoint-connector-lakeflow/","summary":"Ingestão estruturada, metadados de arquivo e schema evolution chegaram ao conector de SharePoint, ele deixou de ser um caso de uso de nicho pra virar ingestão de verdade.","title":"O conector de SharePoint do Lakeflow Connect parou de ser só leitura de PDF solto"},{"content":"Delta Lake sempre resolveu concorrência de escrita de um jeito engenhoso e um tanto invisível: cada tabela mantém o próprio log de transação dentro do object storage, e todo writer que quer confirmar uma mudança precisa negociar diretamente com aquele log, arquivo por arquivo, tabela por tabela. Funciona bem pra uma tabela por vez. O problema aparece quando a operação de negócio real mexe em duas ou três tabelas ao mesmo tempo, um pedido que atualiza estoque e cria registro de auditoria, por exemplo, e não existe garantia nativa de que as duas escritas aconteçam juntas ou falhem juntas.\nO Catalog Commits muda onde mora a coordenação dessa transação: em vez de cada tabela negociar sozinha com o object storage, o Unity Catalog passa a ser a fonte da verdade sobre o estado de cada tabela gerenciada. O dado continua exatamente onde sempre esteve, em formato aberto no seu storage account, o que muda é quem arbitra a escrita. Vale uma atualização de status logo de cara: a Databricks anunciou GA do recurso central em 12 de maio de 2026, e a documentação da Microsoft (atualizada em agosto) confirma isso, mas com duas exceções importantes que ainda carregam rótulo de preview, tratadas na seção de limitações mais abaixo.\nO mecanismo: metadado sai do storage e entra no catálogo Na arquitetura tradicional, um cliente que quer ler o estado atual de uma tabela Delta precisa ir até o object storage, listar arquivo de log, e reconstruir o estado a partir dali, um processo que soma latência de rede a cada consulta de metadado. Com Catalog Commits habilitado, o Unity Catalog já sabe o estado da tabela e entrega essa informação direto pro cliente Delta na hora do acesso, sem esse round-trip. Isso acelera tanto planejamento de query quanto escrita, porque o gargalo de metadado deixa de existir.\nO ganho estrutural maior, porém, é a possibilidade de transação atômica atravessando múltiplas tabelas: como o Unity Catalog já está no meio de cada commit, ele consegue coordenar um conjunto de mudanças em tabelas diferentes como uma unidade só, tudo confirma junto ou nada confirma, mantendo a garantia ACID que o Delta Lake sempre teve, só que agora numa escala de várias tabelas e não apenas uma. Some a isso a possibilidade de engine externo escrever com segurança numa tabela gerenciada pelo Unity Catalog, porque é o próprio catálogo que arbitra conflito de concorrência, prevenindo corrupção de dado que hoje só existe informalmente por convenção de time.\nMão na massa: ligando e verificando o recurso Habilitar Catalog Commits é uma propriedade de tabela, não uma mudança de arquitetura:\n-- numa tabela nova CREATE TABLE vendas ( id_venda BIGINT, valor DECIMAL(10,2), data_venda DATE ) TBLPROPERTIES (\u0026#39;delta.feature.catalogManaged\u0026#39; = \u0026#39;supported\u0026#39;); -- numa tabela existente ALTER TABLE vendas SET TBLPROPERTIES (\u0026#39;delta.feature.catalogManaged\u0026#39; = \u0026#39;supported\u0026#39;); -- confirmando que está ativo DESCRIBE DETAIL vendas; -- procure \u0026#39;catalogManaged\u0026#39; na coluna tableFeatures Um detalhe que quem administra plataforma de dado precisa saber de antemão: ligar Catalog Commits numa tabela existente dispara uma sincronização do estado da tabela com o catálogo, e em tabela com alto volume histórico de escrita essa sincronização pode levar minutos, não é uma troca de flag instantânea. Vale planejar essa janela como faria com qualquer outra migração de metadado, de preferência fora do horário de pico de escrita.\nO requisito de versão de runtime varia conforme a operação, não é um número único pra decorar: Databricks Runtime 16.4 ou superior já lê, escreve e cria tabela gerenciada com Catalog Commits ligado; ativar ou desativar o recurso numa tabela existente exige Runtime 18.0 ou superior; streaming table e materialized view pedem Runtime 17.3 ou superior pra ler e escrever, e Runtime 18 LTS ou superior especificamente pra desativar o recurso nelas depois de ligado. Também não dá pra alternar Catalog Commits usando CREATE OR REPLACE TABLE ou REPLACE TABLE, só CREATE TABLE (na criação) ou ALTER TABLE (numa tabela já existente) funcionam pra esse propósito.\nMinha leitura: o nome do recurso sugere uma feature de conveniência, mas o efeito é uma mudança de modelo mental sobre onde mora a verdade dos seus dados. Hoje, muita gente ainda pensa em Unity Catalog como um dicionário de metadado e controle de acesso, um verniz de governança sobre um Delta Lake que continua se virando sozinho por baixo. Catalog Commits empurra o catálogo pra dentro do caminho crítico de escrita, o que é ótimo pra consistência entre tabelas, mas também faz do Unity Catalog um ponto de coordenação do qual a plataforma passa a depender de verdade, não só de fachada.\nUm cenário concreto: leitura via Delta Kernel de fora da Databricks Pense num time que já consulta a mesma tabela gerenciada a partir de mais de um motor, Databricks SQL de um lado, e Trino, DuckDB ou um pipeline Flink de outro. Sem Catalog Commits, cada engine reconstrói o estado da tabela lendo o log de transação direto do object storage, e nada garante que os vários engines estejam vendo exatamente o mesmo commit no mesmo instante. A leitura via integração com Delta Kernel já é o caminho suportado hoje: Delta Spark, Delta Flink, Starburst Trino, DuckDB e StreamNative aparecem explicitamente na lista de engines com suporte a Catalog Commits.\nEscrita a partir de engine externo é uma história diferente: continua listada como Beta na documentação, atrás de habilitação explícita na página de Previews do workspace, então \u0026ldquo;qualquer engine externo escreve com segurança hoje\u0026rdquo; ainda é otimismo antecipado. O que já é GA é a leitura consistente entre engines e a coordenação de commit para o que já escreve através da própria Databricks (Delta Sharing, Zerobus, Lakeflow Connect, Unity AI Gateway, MLflow e Lakeflow Job Triggers foram citados nominalmente pela Databricks como já integrados).\nO que isso não resolve A lista de incompatibilidades é longa o suficiente pra merecer checklist antes de ligar em produção, mesmo com o recurso central já em GA. Transação escrevendo em tabela gerenciada Iceberg via Catalog Commits continua em Private Preview, atrás de formulário de inscrição. Escrita de engine externo pelo Delta Kernel continua em Beta, atrás da página de Previews do workspace, então nem toda promessa de \u0026ldquo;engine externo escreve com segurança\u0026rdquo; já vale pra produção sem essa habilitação explícita. Tabela com Catalog Commits habilitado passa a ser compartilhada via OpenSharing usando URL pré-assinada em vez de token de nuvem, uma mudança de comportamento que pode pegar quem já tem consumidor externo configurado. Streaming table e materialized view com acesso externo já configurado precisam ter esse acesso desativado antes de habilitar Catalog Commits, é preciso escolher um dos dois. E cluster de usuário único simplesmente não consegue acessar streaming table com o recurso habilitado. Nenhum desses pontos invalida o recurso, mas todos empurram na mesma direção: teste em ambiente de não produção antes, com o inventário real de quem lê e escreve cada tabela candidata, e confirme na documentação qual pedaço específico da feature ainda carrega rótulo de preview antes de prometer algo pra outro time.\nVale a pena adotar? Pra time que já sofre com necessidade real de transação atômica entre tabelas, hoje resolvida via job sequencial e reprocessamento manual quando algo falha no meio, ou que sofre com latência de metadado em tabela consultada com muita frequência, Catalog Commits ataca um problema estrutural de verdade, não é feature cosmética, e o fato de já estar em GA desde maio remove boa parte da hesitação natural de adotar algo em Beta. Pra quem já usa OpenSharing, streaming table com consumidor externo, ou depende de cluster single-user pra algum fluxo específico, vale mapear esses casos antes de ligar o flag. E pra quem sonha com engine totalmente externo escrevendo direto na tabela gerenciada sem depender da Databricks pra nada, ainda vale esperar essa parte específica sair do Beta antes de prometer isso pra produção.\nReferências Microsoft Learn, \u0026ldquo;Catalog commits - Azure Databricks\u0026rdquo;: https://learn.microsoft.com/en-us/azure/databricks/delta/catalog-commits Databricks Blog, \u0026ldquo;The Convergence of Open Table Formats and Open Catalogs: Catalog Commits is Generally Available\u0026rdquo;: https://www.databricks.com/blog/convergence-open-table-formats-and-open-catalogs-catalog-commits-generally-available #Databricks #UnityCatalog #DeltaLake #Governança\n","permalink":"https://wiliamrosa.github.io/articles/databricks-catalog-commits-unity-catalog-transacoes/","summary":"Catalog Commits tira a coordenação de transação do Delta Lake do object storage e coloca dentro do Unity Catalog, habilitando transação atômica entre várias tabelas e leitura de metadado sem round-trip pra nuvem. O recurso central já é GA desde maio de 2026, com Delta Spark, Flink, Trino e DuckDB entre os engines suportados, mas escrita de engine externo continua em Beta e tabela Iceberg gerenciada em Private Preview.","title":"Quando o Unity Catalog vira coordenador de transação, não só o dicionário de tabelas"},{"content":"O Genie Code agora tem um modo de auto-aprovação: ações de ferramenta (rodar código, editar notebook) deixam de pedir confirmação a cada passo. Um classificador de IA revisa cada ação e bloqueia as consideradas arriscadas.\nA documentação oficial já vem com o aviso mais importante embutido: auto-aprovação é feature de produtividade, não barreira de segurança. A recomendação da própria Databricks é manter desligado ao trabalhar com dado de produção ou recurso compartilhado.\nPor que vale prestar atenção nesse detalhe:\nGanho de produtividade é real, parar de confirmar toda ação pequena economiza tempo de quem já confia no agente pra tarefas repetitivas \u0026ldquo;Classificador de IA bloqueia ação arriscada\u0026rdquo; é probabilístico, não determinístico, não existe garantia formal de que toda ação perigosa será pega A própria Databricks reconhece isso explicitamente, o que é honesto, mas não muda o risco de quem ativa sem ler a letra miúda Minha ressalva: qualquer feature que a documentação já avisa \u0026ldquo;isso não é barreira de segurança\u0026rdquo; deveria vir com um toggle de workspace, não só de usuário individual, decisão de segurança dessa magnitude não deveria ficar só na mão de quem está com pressa às 17h de sexta-feira.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/release-notes/product/2026/june\n#AzureDatabricks #GenieCode #SegurançaDeIA\n","permalink":"https://wiliamrosa.github.io/posts/azure-databricks-genie-code-auto-aprovacao/","summary":"Auto-aprovação tira o prompt de confirmação a cada ação do Genie Code, mas quem decide o que é \u0026lsquo;arriscado\u0026rsquo; é um classificador de IA, não uma barreira de segurança.","title":"Genie Code ganhou modo de auto-aprovação, com um classificador de IA decidindo por você"},{"content":"O Add-in do Azure Databricks para Excel ganhou uma capacidade que muda o público-alvo da ferramenta: escrever dados de volta numa tabela do Unity Catalog, criando ou sobrescrevendo, sem sair da planilha.\nAté aqui, integração Excel-Databricks era estritamente de leitura, bom pra quem só precisa consumir uma metric view. Write-back muda o jogo: o Excel vira também um ponto de entrada de dados governado, e não só de consulta.\nPor que isso importa na prática:\nÁrea de negócio que só sabe trabalhar em Excel ganha um caminho oficial pra alimentar o Lakehouse Elimina a etapa manual de \u0026ldquo;exportar Excel → subir CSV → rodar pipeline\u0026rdquo; Ainda passa pelo Unity Catalog, então a governança da tabela de destino continua valendo Minha ressalva: write-back direto de Excel é exatamente o tipo de porta de entrada que precisa de controle de qualidade rígido, schema errado, tipo de dado inconsistente, duplicata de linha. Antes de liberar isso pra usuário de negócio, eu garantiria validação na tabela de destino, porque Excel não vai fazer esse trabalho por você.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/release-notes/product/2026/june\n#AzureDatabricks #Excel #UnityCatalog\n","permalink":"https://wiliamrosa.github.io/posts/azure-databricks-excel-write-back/","summary":"O Add-in do Excel para Azure Databricks deixou de ser só leitura, agora escreve de volta em uma tabela do Unity Catalog, sem sair da planilha.","title":"Agora dá pra escrever no Unity Catalog direto do Excel"},{"content":"Sessionização parece um problema resolvido até você tentar fazer em tempo real e em escala de milhões de usuários simultâneos. O desafio não é detectar quando uma sessão começa, é decidir quando ela terminou. Se o jogador simplesmente para de mandar evento (fecha o app, cai a conexão, trava o celular), não existe nenhum evento explícito de \u0026ldquo;fim de sessão\u0026rdquo; pra disparar o fechamento. O jeito clássico de resolver isso em micro-batch é esperar uma janela de inatividade fechar, o que introduz atraso estrutural exatamente no momento em que você mais precisa de dado fresco: para personalizar conteúdo, recomendar próxima ação ou decidir agendamento dinâmico enquanto o jogador ainda está ativo.\nO problema específico de sessionização em tempo real Numa plataforma de gaming com alcance global, a escala descrita é considerável: 4 milhões de sessões ativas simultaneamente, com cerca de 500 mil eventos de início e fim de sessão por minuto, mais 8 milhões de registros de heartbeat por minuto vindos de clientes ainda conectados. Em micro-batch tradicional, cada janela de processamento adiciona latência ao fechamento de sessão, e a decisão de \u0026ldquo;essa sessão expirou por inatividade\u0026rdquo; só é reavaliada quando o próximo batch roda, não no instante exato em que o timeout de fato acontece.\nO mecanismo: transformWithState com timers nativos O operador transformWithState do Structured Streaming permite lógica de estado customizada por chave de agrupamento, e oferece dois métodos que trabalham em conjunto pra resolver exatamente o problema de sessão sem evento de fechamento explícito:\nhandleInputRows(): processa cada evento recebido de forma reativa, atualizando o estado da sessão (início, heartbeat, ou fim explícito quando o cliente envia esse sinal).\nhandleExpiredTimer(): dispara de forma proativa quando um timer configurado anteriormente expira, independentemente de ter chegado algum dado novo pra aquela chave. É esse método que resolve o caso da sessão abandonada sem aviso: você registra um timer no momento do último evento recebido, e se nenhum evento novo chegar antes do timer expirar, handleExpiredTimer fecha a sessão automaticamente, sem depender de uma janela de batch fechar.\nO resultado é que uma única classe de processador stateful cobre o ciclo de vida inteiro da sessão, tanto o caminho reativo (evento chegou) quanto o proativo (nada chegou, e já passou tempo suficiente pra considerar encerrado).\nOs números: Real-Time Mode contra micro-batch A comparação publicada mostra:\nLatência p99 de 432 milissegundos em Real-Time Mode. Ganho de aproximadamente 20x em relação ao mesmo pipeline rodando em modo micro-batch. Minha leitura: o número de 20x chama atenção, mas o que considero mais relevante aqui é estrutural, não só de velocidade: em micro-batch, mesmo que você reduza a janela pra um segundo, você ainda paga o custo de reavaliar tudo periodicamente. Com timer nativo, o sistema só reage exatamente quando precisa, no momento exato do timeout, não numa próxima checagem agendada. É uma mudança de \u0026ldquo;polling\u0026rdquo; pra \u0026ldquo;evento\u0026rdquo;, dentro do próprio motor de streaming, e isso importa mais pro caso de uso do que só a redução de latência média.\nMão na massa: esqueleto de sessionização com transformWithState Um exemplo simplificado do padrão de handleInputRows + handleExpiredTimer pra fechar sessão por inatividade:\nfrom pyspark.sql.streaming import StatefulProcessor, StatefulProcessorHandle from pyspark.sql.types import StructType, StructField, StringType, LongType TIMEOUT_MS = 5 * 60 * 1000 # 5 minutos de inatividade encerra a sessão class SessionizerProcessor(StatefulProcessor): def init(self, handle: StatefulProcessorHandle): self.handle = handle self.state = handle.getValueState(\u0026#34;sessao_ativa\u0026#34;, schema=\u0026#34;last_event_ts LONG, started_at LONG\u0026#34;) def handleInputRows(self, key, rows, timer_values): estado_atual = self.state.get() agora = timer_values.get_current_processing_time_in_ms() if estado_atual is None: self.state.update({\u0026#34;last_event_ts\u0026#34;: agora, \u0026#34;started_at\u0026#34;: agora}) else: self.state.update({\u0026#34;last_event_ts\u0026#34;: agora, \u0026#34;started_at\u0026#34;: estado_atual[\u0026#34;started_at\u0026#34;]}) # renova o timer de expiração a cada evento novo self.handle.registerTimer(agora + TIMEOUT_MS) def handleExpiredTimer(self, key, timer_values, expired_timer_info): estado_atual = self.state.get() if estado_atual is not None: duracao = timer_values.get_current_processing_time_in_ms() - estado_atual[\u0026#34;started_at\u0026#34;] yield {\u0026#34;player_id\u0026#34;: key, \u0026#34;session_duration_ms\u0026#34;: duracao, \u0026#34;status\u0026#34;: \u0026#34;encerrada_por_inatividade\u0026#34;} self.state.clear() O detalhe que faz esse padrão funcionar é o timer sendo re-registrado a cada evento novo: enquanto o jogador continua ativo, o timer nunca dispara. No instante em que os eventos param, o timer configurado anteriormente expira e fecha a sessão sozinho, sem esperar próximo batch.\nO que muda no consumo downstream Uma implicação prática que costuma passar batido: sessão fechada por handleExpiredTimer chega no destino (tabela Delta, fila de saída, sistema de personalização) de um jeito estruturalmente diferente de uma sessão fechada por evento explícito, mesmo que o schema de saída seja idêntico. Sessão fechada por evento reflete uma ação real do cliente (usuário saiu do app deliberadamente); sessão fechada por timer reflete uma inferência da plataforma sobre inatividade. Sistemas consumidores que tomam decisão de negócio em cima desse dado, como calcular tempo médio de sessão pra dimensionar capacidade de servidor de jogo, deveriam considerar guardar esse metadado (motivo do fechamento) como coluna própria, porque duração de sessão encerrada por timeout de 5 minutos embute uma imprecisão de até 5 minutos na duração real, enquanto duração de sessão fechada por evento explícito é exata. Ignorar essa diferença tende a distorcer métrica agregada de forma sutil, mas sistemática, sempre subindo a duração média reportada.\nO que isso não resolve Timer nativo resolve o fechamento de sessão sem evento explícito, mas não resolve reconciliação de sessão em cenário de reconexão. Se o jogador cai e reconecta rapidamente com um novo identificador de conexão, decidir se isso é a \u0026ldquo;mesma sessão continuando\u0026rdquo; ou uma \u0026ldquo;sessão nova\u0026rdquo; ainda é uma regra de negócio que precisa ser modelada explicitamente, o motor de streaming não infere isso sozinho. Também vale registrar uma limitação documentada: transformWithStateInPandas não funciona em modo real-time, então times que já usam esse operador em Pandas API precisam migrar pra API nativa Scala/Python antes de adotar Real-Time Mode.\nResumindo Sessionização em tempo real de milhões de usuários simultâneos é um problema onde a estrutura importa mais que a força bruta. Handler reativo pra evento que chega e handler proativo pra timeout que expira, os dois dentro do mesmo processador stateful, resolvem de forma nativa um problema que historicamente exigia gambiarra de janela de batch cada vez menor. O ganho de 20x reportado é real, mas o valor está em não precisar mais decidir entre latência baixa e complexidade de implementação.\nReferências Apache Spark Real-Time Mode for gaming: a better way to do real-time sessionization (blog oficial Databricks) Apache Spark Structured Streaming Real-Time Mode: concepts (documentação oficial) Real-time mode concepts (Microsoft Learn) Stateful applications with transformWithState (documentação oficial) Build a custom stateful application with transformWithState (Microsoft Learn) #Databricks #ApacheSpark #Streaming #Gaming\n","permalink":"https://wiliamrosa.github.io/articles/real-time-mode-sessionizacao-gaming-transformwithstate/","summary":"Uma plataforma de gaming usou o Apache Spark Real-Time Mode com transformWithState pra sessionizar 4 milhões de sessões simultâneas com latência p99 de 432 milissegundos, cerca de 20x mais rápido que o mesmo pipeline em micro-batch. O ganho central vem de timers nativos que produzem saída mesmo sem novo evento chegar.","title":"Sessionizar milhões de jogadores sem reprocessar nada: o que muda com timer nativo no Structured Streaming"},{"content":"O Lakebase ganhou uma capacidade de CDC (change data capture) nativa, hoje chamada Lakebase Change Data Feed, batizada inicialmente como Lakehouse Sync. O mecanismo: uma extensão chamada wal2delta roda dentro do próprio compute do Lakebase, faz logical decoding do write-ahead log do Postgres, e escreve cada insert/update/delete direto numa tabela Delta gerenciada no Unity Catalog, em lotes de aproximadamente 15 segundos.\nO que chama atenção aqui não é \u0026ldquo;mais um conector de CDC\u0026rdquo;, é que a aplicação que escreve no Lakebase não precisa saber que isso está acontecendo. Não tem trigger pra configurar, não tem outbox pattern pra implementar, não tem job de ingestão pra agendar.\nPor que isso resolve uma dor recorrente:\nCDC tradicional geralmente exige configurar replicação lógica manualmente ou manter uma ferramenta terceira só pra essa ponte Aqui, cada tabela de origem ganha automaticamente uma tabela de histórico (lb_\u0026lt;nome\u0026gt;_history) no Unity Catalog, com status de sincronização visível Dá pra inspecionar o estado da sincronização direto via SQL (SELECT * FROM wal2delta.tables), sem depender de dashboard externo Minha ressalva: CDC \u0026ldquo;invisível pra aplicação\u0026rdquo; é ótimo até o dia em que você precisa debugar por que uma linha não chegou no Delta a tempo. Ferramenta de CDC que roda por baixo dos panos tende a virar caixa-preta justamente no momento em que você mais precisa entender o que está acontecendo, eu documentaria desde já o processo de troubleshooting antes de depender disso pra decisão de negócio em tempo quase real.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/oltp/projects/lakehouse-sync\n#Databricks #Lakebase #CDC\n","permalink":"https://wiliamrosa.github.io/posts/databricks-lakebase-cdf-wal2delta-unity-catalog/","summary":"Lakebase Change Data Feed (ex-Lakehouse Sync) usa uma extensão de WAL do Postgres pra replicar toda escrita direto pra tabelas Delta no Unity Catalog, sem tocar na aplicação.","title":"Lakebase ganhou CDC de graça, e o Postgres nem percebe"},{"content":"A hipótese mais óbvia sobre quando usar um modelo de reasoning acabou não se sustentando quando testada com número real.\nO Databricks MVP Gary Nakanelua partiu de uma pergunta prática que aparece cada vez mais em time usando Databricks: quais tarefas realmente justificam rotear pra um modelo de reasoning em vez de um modelo base mais barato? A hipótese de partida era que reasoning compensaria em tarefa de classificação ambígua, porque \u0026ldquo;raciocinar melhor\u0026rdquo; pareceria ajudar justamente onde o sinal é misto. Os dados mataram essa hipótese.\nO teste rodou databricks-gpt-oss-120b com reasoning_effort alto contra databricks-meta-llama-3-3-70b-instruct em três níveis de complexidade (extração estruturada simples, aritmética multi-etapa, classificação de sinal misto), cinco itens por tarefa, nas Foundation Model APIs do Databricks. Onde reasoning realmente valeu a pena foi só na aritmética multi-etapa: o modelo base acertou 2 de 5 com respostas erradas e confiantes, contra 5 de 5 do modelo de reasoning. Já na classificação de sinal misto, o modelo base rotulou em 2 tokens e o modelo de reasoning gastou 110 tokens pro mesmo resultado, sem ganho de qualidade que justificasse o custo.\nO que vale reter do experimento:\nReasoning compensa em tarefa com lógica multi-etapa ou aritmética, onde o modelo base erra com confiança Classificação baseada em rubrica bem definida não precisa de reasoning, um modelo base instruído já resolve em poucos tokens O critério certo de roteamento não é \u0026ldquo;quão ambígua parece a tarefa\u0026rdquo;, é \u0026ldquo;quantas etapas de lógica ela exige\u0026rdquo; Minhas considerações: esse é o tipo de experimento barato (poucos minutos, poucas dezenas de chamadas) que qualquer time rodando Foundation Model APIs no Databricks deveria replicar antes de decidir uma política de roteamento por padrão. É fácil assumir que \u0026ldquo;mais raciocínio\u0026rdquo; ajuda em qualquer cenário confuso, mas o dado aqui sugere o oposto: gastar reasoning em tarefa que não exige lógica multi-etapa é desperdício de token sem ganho de acerto.\nFonte: https://www.linkedin.com/in/gnakan/\n#Databricks #FoundationModelAPIs #FinOps\n","permalink":"https://wiliamrosa.github.io/posts/databricks-quando-rotear-modelo-reasoning/","summary":"Um experimento comparando modelo base e modelo de reasoning em três níveis de complexidade nas Foundation Model APIs do Databricks mostrou que reasoning só compensa em tarefa de lógica multi-etapa, não em classificação ambígua.","title":"Rotear pergunta ambígua pra um modelo de reasoning não compensou, e os números provam"},{"content":"Os conectores baseados em query do Lakeflow Connect atingiram GA. A proposta: ingerir dado de banco relacional consultando a fonte diretamente por uma coluna cursor, sem precisar configurar CDC nem manter um gateway de ingestão.\nIsso remove uma barreira de entrada que sempre existiu pra times que não podem ou não querem habilitar CDC no banco de origem, seja por restrição do DBA, seja pelo overhead operacional de manter mais uma peça de infraestrutura rodando.\nO mecanismo, resumido:\nVocê define a tabela e escolhe uma coluna cursor (timestamp ou ID) O Databricks rastreia a marca d\u0026rsquo;água e consulta só as linhas novas/alteradas a cada execução Funciona com Oracle, Teradata, SQL Server, MySQL, MariaDB, PostgreSQL, e qualquer fonte do Lakehouse Federation via ingestão por catálogo externo Minha ressalva: ingestão baseada em query só captura o que existe na tabela no momento da consulta, ela não vê delete físico nem update que aconteceu e foi revertido entre duas execuções, do jeito que um CDC de log de transação captura. Pra caso de uso que exige histórico completo de mudança (auditoria estrita, por exemplo), essa abordagem é mais simples de operar, mas não é substituta equivalente ao CDC tradicional, é uma troca consciente de completude por simplicidade operacional.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/release-notes/product/2026/may\n#AzureDatabricks #LakeflowConnect #EngenhariaDeDados\n","permalink":"https://wiliamrosa.github.io/posts/azure-databricks-lakeflow-connect-query-based-ga/","summary":"Conectores baseados em query atingiram disponibilidade geral: ingestão incremental via cursor, sem CDC nem gateway, pra Oracle, SQL Server, MySQL, MariaDB, Teradata e PostgreSQL.","title":"Ingestão sem CDC no Lakeflow Connect saiu do papel e virou GA"},{"content":"Existe um erro de design que se repete em pipeline de dados regulatório: tratar tudo com a mesma granularidade e a mesma frequência, só porque é mais simples de manter um pipeline só. O problema é que dado de liquidação regulatória, dado de receita pra tarifa dinâmica e dado de receita padrão têm SLAs completamente diferentes entre si, e forçar os três dentro do mesmo fluxo mensal monolítico significa reprocessar volume gigantesco de dado que, na prática, muda pouco. Foi exatamente esse o diagnóstico que levou a Octopus Energy a redesenhar o pipeline de MHHS (Market-wide Half-Hourly Settlement, o regime de liquidação de energia do Reino Unido) em três fluxos separados.\nO problema: um pipeline monolítico carregando três SLAs diferentes O regime MHHS exige processar leitura de medidor a cada 30 minutos pra fins de liquidação regulatória. Antes da mudança, esse processamento era feito de forma mensal e monolítica, processando cerca de 25 bilhões de linhas por execução. Só que dentro desse volume gigantesco existiam três necessidades bem distintas: liquidação regulatória (que precisa de granularidade de meia hora, mas pode tolerar atraso de processamento), receita de tarifa smart (clientes com carro elétrico ou bomba de calor, que se beneficiam de dado mais fresco pra decisões de precificação dinâmica) e receita de tarifa padrão (que não precisa de granularidade fina, diária já é suficiente).\nA solução: arquitetura multi-grain com três fluxos independentes A resposta da Octopus Energy foi parar de tratar isso como um problema só. A nova arquitetura separa em três streams paralelos:\nSettlement (meia hora): cobre a obrigação regulatória de custo, rodando na cadência exigida pelo regime MHHS. Revenue half-hourly: cobre receita pra cliente com tarifa smart, na mesma granularidade de meia hora, porque esse segmento se beneficia de visibilidade fina. Daily revenue: cobre receita de tarifa padrão, processada diariamente, porque a granularidade fina simplesmente não agrega valor pra esse segmento. O ponto que amarra os três é uma camada de consumo unificada que reconcilia leitura de medidor contra liquidação, mesmo vindo de fluxos com granularidades diferentes. Sem essa camada, você teria três pipelines desconexos gerando visões inconsistentes entre si.\nAs peças técnicas que sustentam o ganho A arquitetura multi-grain sozinha não explica o ganho de custo, o que faz a diferença é a combinação com processamento incremental de verdade:\nChange Data Feed (CDF) do Delta Lake: em vez de reprocessar a tabela inteira a cada execução, o pipeline passa a identificar apenas os registros que de fato mudaram desde a última execução, usando os metadados de mudança de linha do Delta Lake.\ndbt em microbatch com watermark: o modelo incremental do dbt, combinado com watermark de tempo, evita reler dado histórico que já foi processado e não mudou.\nAdaptive Query Execution (AQE) do Spark: ajusta o plano de execução da query em tempo real, com base em estatística real coletada durante a própria execução, em vez de depender só de estimativa estática feita antes de rodar.\nDatabricks Serverless: elimina a latência de start de cluster no ciclo de desenvolvimento iterativo, o que segundo a Octopus Energy foi relevante pra acelerar a própria reformulação do pipeline.\nWorkflow \u0026ldquo;job of jobs\u0026rdquo;: orquestra a dependência entre os três fluxos e a camada de consumo unificada, garantindo ordem de execução correta sem acoplamento rígido entre eles.\nOs números que sustentam o case Métrica Antes Depois Linhas processadas 25 bilhões 300 milhões Custo projetado por dia de dado MHHS US$ 23,63 US$ 0,48 Frequência de atualização Semanal Diária Volume de dado suportado Baseline 48x maior A redução de custo por unidade de dado processada gira em torno de 50x, com economia mensal projetada de aproximadamente US$ 83 mil frente à trajetória anterior, o que a empresa projeta em cerca de US$ 1 milhão anualizado (sem contar economia adicional em etapas anteriores do pipeline).\nMinha leitura: o número de 98,8% de redução em linhas processadas (de 25 bilhões pra 300 milhões) é mais revelador que o número de custo em dólar, porque ele mostra que a maior parte daquele processamento anterior era, na prática, trabalho redundante. Reprocessar dado que não mudou, numa granularidade mais fina do que o necessário pra boa parte do volume, é o tipo de ineficiência que só aparece quando alguém para pra segmentar o problema por SLA real, em vez de aceitar \u0026ldquo;processa tudo igual\u0026rdquo; como default.\nMão na massa: um exemplo de leitura incremental via CDF O padrão central, ler só o que mudou usando Change Data Feed, é replicável em qualquer tabela Delta. Um exemplo de consulta incremental usando table_changes, guardando o último ponto processado:\n-- habilita CDF numa tabela existente de leitura de medidor ALTER TABLE bronze.leituras_medidor SET TBLPROPERTIES (delta.enableChangeDataFeed = true); -- lê só as mudanças desde a última versão processada, -- em vez de reprocessar a tabela inteira SELECT medidor_id, timestamp_leitura, valor_kwh, _change_type FROM table_changes(\u0026#39;bronze.leituras_medidor\u0026#39;, :ultima_versao_processada) WHERE _change_type IN (\u0026#39;insert\u0026#39;, \u0026#39;update_postimage\u0026#39;); Em modelo dbt incremental, o equivalente seria configurar o materialization como incremental com uma estratégia de merge baseada nessa mesma coluna de mudança, processando só o delta a cada execução em vez da tabela inteira.\nO que isso não resolve Arquitetura multi-grain exige disciplina de modelagem que não é trivial de manter: toda vez que uma regra de negócio muda (por exemplo, um novo tipo de tarifa que precisa de granularidade diferente das três já existentes), alguém precisa decidir conscientemente em qual fluxo ela entra, e ajustar a camada de consumo unificada pra continuar reconciliando corretamente. Além disso, separar fluxos por SLA adiciona complexidade operacional real: mais pipelines pra monitorar, mais pontos de falha possíveis, e uma dependência maior de que o \u0026ldquo;job of jobs\u0026rdquo; orquestre a ordem certa. É trade-off, não solução isenta de custo.\nResumindo O ganho de 50x na Octopus Energy não veio de uma feature isolada, veio de reconhecer que dado de liquidação regulatória, receita de tarifa smart e receita de tarifa padrão simplesmente não deveriam competir pelo mesmo pipeline mensal monolítico. Separar por granularidade real, e usar CDF, AQE e processamento incremental de verdade dentro de cada fluxo, é o tipo de decisão de arquitetura que qualquer time de engenharia de dados lidando com regulação ou multiplicidade de SLA deveria revisitar antes de simplesmente pedir mais compute pro mesmo pipeline de sempre.\nReferências Scaling MHHS: how Octopus Energy achieved 50x cost reduction in margin data engineering (blog oficial Databricks) Delta Lake Change Data Feed (documentação oficial) Use change data feed on Azure Databricks (Microsoft Learn) #Databricks #DeltaLake #DataEngineering #Custo\n","permalink":"https://wiliamrosa.github.io/articles/octopus-energy-arquitetura-multi-grain-custo-dados/","summary":"A Octopus Energy reduziu de 25 bilhões pra 300 milhões de linhas processadas trocando um pipeline mensal monolítico por três fluxos independentes de granularidade diferente, usando Change Data Feed, dbt incremental e Adaptive Query Execution. O custo por dado de liquidação MHHS caiu de cerca de 23 dólares pra menos de 50 centavos.","title":"Nem tudo precisa da mesma granularidade: como separar SLA por fluxo derrubou custo de dado em 50x"},{"content":"📅 09 de maio de 2026 · 📍 FMU - Casa Metropolitana do Direito, São Paulo · Evento híbrido (Presencial e Online) · Evento realizado\nHoje tive a oportunidade de participar da Conferência Microsoft Fabric Brasil, acompanhando palestras e trocando experiências com grandes referências da área: Hugo Venturini, Sidney Cirqueira, Luciano Borba, Samyr Moises, Juliana Maria Lopes e Alison Pezzott.\nUm agradecimento especial ao Sidney, que em breve também estará compartilhando conhecimento com a São Paulo Databricks User Group. Vai ser uma excelente oportunidade para fortalecer ainda mais a troca de experiências entre profissionais de dados, analytics e IA.\nAproveitei também para rever amigos palestrantes e divulgar meu livro Lakehouse Engineering com Databricks entre a comunidade. 📖\nSobre o evento A Conferência Microsoft Fabric Brasil foi um dia inteiro de imersão total em Microsoft Fabric, com exposições completas abrangendo todos os níveis e camadas da plataforma — organizada pela comunidade em parceria com a Microsoft, reunindo grandes referências de dados e analytics do Brasil.\n👉 Página oficial do evento\n","permalink":"https://wiliamrosa.github.io/events/conferencia-microsoft-fabric-brasil-maio-2026/","summary":"Participei da Conferência Microsoft Fabric Brasil, acompanhando palestras e trocando experiências com grandes referências da área, além de aproveitar para divulgar meu livro Lakehouse Engineering com Databricks.","title":"🟢 Conferência Microsoft Fabric Brasil"},{"content":"O Databricks MVP Hubert Dudek documentou um padrão prático pra um problema comum: quando Terraform provisiona a infraestrutura de nuvem e Declarative Automation Bundles gerenciam a camada Databricks, a integração entre os dois historicamente era uma pessoa copiando um ID de um lugar e colando no outro, às vezes avisando no Slack quando algo mudava. Isso não é integração, é um ponto único de falha esperando acontecer.\nA correção documentada é simples de descrever: o Terraform já sabe emitir saída como JSON, e os bundles já sabem ler um arquivo JSON de override no momento do deploy. Juntar essas duas capacidades que já existiam elimina o processo manual por completo, sem ferramenta nova, só conectando o que já estava disponível.\nPor que vale adotar esse padrão mesmo em ambiente pequeno:\nElimina o \u0026ldquo;alguém precisa lembrar de atualizar aquele ID manualmente\u0026rdquo; que sempre vira incidente em algum momento Não exige nenhuma ferramenta adicional, é reorganização de um fluxo que o Terraform e os bundles já suportavam separadamente Documenta a dependência entre infraestrutura e bundle como código, em vez de conhecimento tribal guardado na cabeça de uma pessoa só Minha ressalva: automatizar a passagem de ID entre Terraform e bundle resolve o sintoma de \u0026ldquo;cola manual\u0026rdquo;, mas não resolve sozinho o problema de quem decide a ordem de execução, Terraform precisa rodar e terminar antes do bundle consumir o JSON, e essa dependência sequencial no pipeline de CI/CD merece ficar tão explícita quanto a própria integração de dados.\nFonte: https://www.sunnydata.ai/blog/declarative-automation-bundles-terraform-variable-overrides\n#Databricks #Terraform #DevOps\n","permalink":"https://wiliamrosa.github.io/posts/databricks-terraform-dabs-integracao-json/","summary":"Terraform provisiona a infraestrutura, os bundles gerenciam a camada Databricks, e a integração entre os dois deixou de depender de mensagem no Slack com o ID copiado manualmente.","title":"Chega de copiar e colar ID do Key Vault entre Terraform e bundle, agora é só JSON"},{"content":"O Databricks MVP Hubert Dudek destacou um lançamento que passou meio despercebido: a Databricks lançou um tier gratuito permanente pro Lakeflow Connect, 100 DBUs por dia, por workspace, sem data de expiração, o equivalente a cerca de 100 milhões de registros por dia, de graça.\nPra times de porte médio, isso frequentemente cobre a carga de ingestão inteira. E vem com o pacote completo: conectores nativos, governança via Unity Catalog, linhagem de dado já embutida desde o primeiro registro ingerido, não é uma versão capada da ferramenta, é a ferramenta completa com um limite generoso de uso diário.\nPor que essa jogada é mais estratégica do que parece:\nIngestão cobrada por linha/registro sempre foi um modelo estranho pra quem já paga pela plataforma como um todo Um tier gratuito permanente (não um trial de 30 dias) remove a fricção de decisão pra quem está avaliando migrar de uma ferramenta de ingestão paga à parte Times que hoje pagam por linha ingerida numa ferramenta terceira ganham um motivo concreto pra recalcular a conta Minha ressalva: \u0026ldquo;grátis pra sempre\u0026rdquo; em produto de nuvem quase sempre tem uma leitura estratégica por trás, normalmente é a porta de entrada pra consumo de outras partes da plataforma (compute, armazenamento, Unity AI Gateway) que não são gratuitas. Vale entender o tier gratuito como aquisição de cliente, não como filantropia, e projetar o custo total assim que o volume ultrapassar os 100 DBUs diários.\nFonte: https://www.sunnydata.ai/blog/lakeflow-connect-free-tier-etl-cost-savings\n#Databricks #LakeflowConnect #EngenhariaDeDados\n","permalink":"https://wiliamrosa.github.io/posts/databricks-lakeflow-connect-tier-gratuito/","summary":"O novo tier gratuito permanente do Lakeflow Connect cobre cerca de 100 milhões de registros por dia, por workspace, sem prazo de validade. Isso muda o cálculo de quem hoje paga por linha ingerida.","title":"100 DBUs de ingestão grátis por dia, todo dia, pra sempre, o que a Databricks está apostando com isso"},{"content":"📅 23 e 24 de abril de 2026 · 📍 Distrito Anhembi, São Paulo · Evento realizado\nTive a honra de atuar como host e como coordenador da trilha de Engenharia de Dados no TDC Summit São Paulo, focado em Inteligência Artificial, acompanhando apresentações de palestrantes incríveis que compartilharam muito conhecimento com a comunidade.\nAgradeço pela oportunidade e confiança — foi uma experiência enriquecedora poder contribuir de perto com esse momento.\nObrigado aos palestrantes que passaram pelo palco comigo: Lucas Ximenes, Arthur Fücher, Letticia Nicoli, Breno Masi, Alan Felix, Alberto Souza e Doacir Santana Gazola de Oliveira.\nEspero vê-los novamente nos próximos eventos!\n#tdcsummit #tdc\nSobre o evento O TDC Summit IA é um evento 100% focado em Inteligência Artificial aplicada ao dia a dia de profissionais de tecnologia — construindo, entregando e decidindo no mercado.\n👉 Página oficial do evento\n","permalink":"https://wiliamrosa.github.io/events/tdc-summit-sao-paulo-2026-ia/","summary":"Atuei como host e como coordenador da trilha de Engenharia de Dados no TDC Summit São Paulo (IA), acompanhando apresentações de palestrantes incríveis que compartilharam muito conhecimento com a comunidade.","title":"🎙️ TDC Summit São Paulo — Inteligência Artificial | Host e Coordenador de Trilha"},{"content":"Times que adotaram dbt cedo resolveram um problema real, transformação SQL versionada, testável e documentada, mas herdaram outro no processo: o projeto dbt vive numa ferramenta, o agendamento vive em outra (Airflow, cron, ou o próprio dbt Cloud), e o catálogo de dado onde o resultado final pousa é um terceiro sistema. Quando uma transformação falha às quatro da manhã, o analista de plantão precisa abrir três abas diferentes só pra reconstruir o que aconteceu.\nA aposta da Databricks é remover essa fragmentação tratando dbt como tarefa de primeira classe dentro do Lakeflow Jobs, na mesma superfície onde já rodam ingestão via Auto Loader, pipeline declarativo e dashboard de BI. Isso não substitui o dbt, o modelo continua sendo escrito em SQL com Jinja como sempre foi, o que muda é onde a execução, o log de falha e a governança do resultado vivem.\nO mecanismo: dbt como tarefa, não como sistema externo Na configuração nativa, o projeto dbt precisa estar num repositório Git conectado via Azure Databricks Git folders, não pode viver em DBFS. A execução acontece em compute do Azure Databricks, enquanto o SQL gerado pelo dbt é efetivamente rodado num SQL warehouse serverless ou pro. A Databricks recomenda o pacote dbt-databricks, uma camada de adaptação otimizada pra plataforma, em vez do adaptador genérico dbt-spark, porque ele conhece particularidade de sintaxe e otimização específica do motor SQL do Azure Databricks.\nIsso significa que o comando dbt run que rodava antes num agente do Airflow ou numa VM dedicada do dbt Cloud passa a ser uma tarefa dentro do mesmo DAG que já orquestra o resto do pipeline de dado, com retry, notificação de falha e histórico de execução compartilhando a mesma interface.\nMão na massa: uma tarefa dbt dentro de um job Lakeflow Um job que primeiro ingere dado via Auto Loader e depois roda a transformação dbt, tudo no mesmo DAG, se declara assim:\nresources: jobs: pipeline_vendas: name: \u0026#34;pipeline_vendas_diario\u0026#34; tasks: - task_key: ingestao_bronze notebook_task: notebook_path: /Repos/dados/ingestao_autoloader - task_key: transformacao_dbt depends_on: - task_key: ingestao_bronze dbt_task: project_directory: /Repos/dados/projeto_dbt commands: - \u0026#34;dbt deps\u0026#34; - \u0026#34;dbt run --select staging+\u0026#34; - \u0026#34;dbt test\u0026#34; warehouse_id: \u0026#34;abc123def456\u0026#34; catalog: \u0026#34;vendas\u0026#34; schema: \u0026#34;silver\u0026#34; A tarefa transformacao_dbt só dispara depois que ingestao_bronze termina com sucesso, e uma falha no dbt test interrompe o job com o mesmo mecanismo de alerta que qualquer outra tarefa do Lakeflow usa, sem precisar de um segundo sistema de monitoramento dedicado só ao dbt.\nGovernança que persiste através de rebuild de tabela Um detalhe técnico que faz diferença prática: permissão de acesso concedida via Unity Catalog em nível de schema persiste através de reconstrução de tabela feita pelo dbt. Isso resolve um problema clássico de quem já usou dbt com --full-refresh, onde a tabela é recriada do zero e historicamente exigia reaplicar grant de acesso manualmente depois. A funcionalidade persist_docs do dbt também integra a documentação do modelo direto no comentário de tabela e coluna dentro do Unity Catalog, então a documentação do dbt e o catálogo de metadado deixam de ser duas fontes de verdade divergentes.\nLineage em nível de coluna também é capturado automaticamente a partir da transformação SQL que o dbt gera, rastreando o caminho desde a ingestão até o consumo final, sem depender de anotação manual dentro do .yml do projeto dbt.\nPerformance: Photon e Liquid Clustering entram de graça Minha leitura: esse é o ponto que, na minha experiência, mais surpreende quem migra de warehouse genérico pra Azure Databricks rodando dbt. Photon, o motor de execução vetorizado, já vem habilitado por padrão em SQL warehouse serverless, então o modelo dbt ganha aceleração sem precisar mudar uma linha de SQL. Liquid Clustering, integrado nativamente na configuração de tabela do adaptador dbt-databricks, substitui particionamento rígido tradicional por uma abordagem mais flexível que se adapta ao padrão de consulta real, e Predictive Optimization automatiza manutenção de tabela (compactação, coleta de estatística) usando IA pra decidir quando vale a pena rodar, sem exigir job de manutenção agendado manualmente. Nenhum desses três exige reescrever modelo dbt existente, é ganho de infraestrutura por baixo, o que é raro o suficiente em engenharia de dado pra merecer nota.\nPortabilidade: o argumento contra vendor lock-in Um ponto que a Databricks reforça, e que merece verificação própria de quem já foi pego de surpresa por dependência de fornecedor antes, é a portabilidade do resultado. Como o lakehouse usa formato de tabela aberto (Delta Lake, com suporte também a Apache Iceberg) e o SQL do warehouse segue padrão ANSI, o modelo dbt compilado continua legível por qualquer engine de consulta externo que saiba ler esses formatos, não fica preso a um dialeto SQL proprietário nem a um formato de arquivo fechado. Isso não elimina o custo de trocar de plataforma se um dia fizer sentido, migração de dado sempre tem custo operacional, mas reduz o risco de ficar refém de uma sintaxe SQL específica que não existe fora do ecossistema Azure Databricks.\nO que isso não resolve Quem já usa dbt Platform (antigo dbt Cloud) com feature avançada de CI/CD própria da plataforma dbt precisa saber que a integração nativa de \u0026ldquo;dbt Platform task\u0026rdquo; dentro do Lakeflow Jobs ainda está em Beta, então depender dela pra produção crítica hoje é aceitar instabilidade de feature em amadurecimento. A exigência de repositório Git via Azure Databricks Git folders também significa que projeto dbt organizado de forma não convencional, ou com processo de deploy que dependia de DBFS, precisa de trabalho de migração antes de adotar a tarefa nativa. E nenhuma dessas integrações resolve o problema de modelagem dbt mal desenhado desde o início, teste insuficiente e dependência circular mal gerenciada continuam sendo responsabilidade de quem escreve o projeto, não da plataforma que executa.\nFechamento A promessa central aqui não é dbt ficar mais poderoso como linguagem de transformação, é o entorno operacional dele parar de ser um sistema à parte com governança, monitoramento e performance próprios. Pra time que já sofre com reconciliar permissão entre dbt e catálogo depois de todo full-refresh, ou que mantém um Airflow só pra agendar dbt run, vale medir o esforço real de migrar o projeto pro Git folder nativo antes de assumir que é apenas trocar o executor.\nReferências Databricks Blog, \u0026ldquo;Open Platform, Unified Pipelines: Why dbt on Databricks is Accelerating\u0026rdquo;: https://www.databricks.com/blog/open-platform-unified-pipelines-why-dbt-databricks-accelerating Databricks Docs, \u0026ldquo;Use dbt transformations in a Databricks job\u0026rdquo;: https://docs.databricks.com/aws/en/jobs/how-to/use-dbt-in-workflows Microsoft Learn, \u0026ldquo;Use dbt transformations in Lakeflow Jobs - Azure Databricks\u0026rdquo;: https://learn.microsoft.com/en-us/azure/databricks/jobs/how-to/use-dbt-in-workflows dbt Labs Docs, \u0026ldquo;Databricks configurations\u0026rdquo;: https://docs.getdbt.com/reference/resource-configs/databricks-configs #Databricks #dbt #Lakeflow #UnityCatalog\n","permalink":"https://wiliamrosa.github.io/articles/dbt-databricks-lakehouse-aberto-orquestracao/","summary":"Tratar dbt como tipo de tarefa nativo do Lakeflow Jobs, em vez de um orquestrador externo apontando pra um warehouse, unifica visibilidade de falha, governança via Unity Catalog e performance de Photon numa única stack, mas ainda exige repositório Git e SQL warehouse serverless ou pro como pré-requisito.","title":"dbt dentro do Lakeflow: o que muda quando o orquestrador para de ser um sistema à parte"},{"content":"Todo time de dado enterprise tem uma pasta de rede, um SharePoint ou um Google Drive cheio de contrato, nota fiscal, laudo técnico e formulário escaneado que nunca vira linha de tabela. A resposta clássica é um projeto de OCR paralelo, com fila de mensagem, um modelo de extração customizado e um time inteiro dedicado a manter aquilo rodando fora do resto da plataforma de dados. Isso é caro, frágil, e cria mais um silo justamente no lugar onde você já tinha decidido não ter silo.\nA Databricks empacotou o problema de outro jeito, tratando documento não estruturado como só mais uma fonte que entra pelo Lakeflow e passa por camadas bronze, silver e gold, igual dado tabular sempre passou. A diferença é que agora a camada bronze aceita PDF, imagem escaneada e DOCX como entrada nativa, com funções de IA fazendo o trabalho que antes exigia um serviço de OCR terceirizado. Vale destacar de cara: as três funções centrais desse pipeline, ai_parse_document, ai_extract e ai_classify, já estão GA na documentação atual, o que muda o cálculo de risco de quem hesitava em colocar isso em produção.\nNa minha experiência conversando com time de dado de empresa grande, o obstáculo real nunca foi convencer alguém de que \u0026ldquo;processar documento com IA\u0026rdquo; é útil, isso todo mundo já sabe. O obstáculo é convencer o time de segurança e o jurídico de que o documento sensível não vai sair do perímetro de governança da empresa pra passar por um serviço terceiro de OCR na nuvem de outro fornecedor. Resolver isso dentro do mesmo Unity Catalog que já governa o resto do dado da empresa é, na prática, o argumento que destrava aprovação, mais do que qualquer benchmark de acurácia de extração.\nO mecanismo: quatro funções, uma tabela Delta no fim A arquitetura recomendada tem cinco etapas, todas dentro do Lakehouse, sem componente externo:\nIngestão via Lakeflow Connect, trazendo arquivo de SharePoint, Google Drive ou volume direto pro Unity Catalog Volumes, com OAuth e controle de acesso nativos. Parsing com ai_parse_document (GA), que converte o arquivo bruto numa representação estruturada em VARIANT, capturando texto, tabela, descrição de imagem e a estrutura do documento, inclusive letra de médico ruim e imagem escaneada torta. Extração e classificação com ai_extract e ai_classify (ambas GA), que tiram campo específico do documento parseado, tipo data de vencimento de contrato ou valor total de nota fiscal, e roteiam o documento por tipo ou nível de risco. Preparação pra busca com ai_prep_search (ainda Beta), que faz o chunking semântico do documento, com contexto de título, cabeçalho e referência de página, no formato que o AI Search espera. Orquestração com Lakeflow Jobs, cuidando de controle de fluxo avançado, compute serverless e observabilidade nativa do pipeline inteiro. O ponto central é que cada uma dessas etapas é uma função SQL ou Python chamável dentro de um notebook ou pipeline declarativo, não um serviço separado que você precisa provisionar, versionar e monitorar à parte.\nMão na massa: um pipeline mínimo de bronze a gold Um exemplo simplificado de como isso fica em SQL, processando contrato em PDF que chega via volume:\n-- Bronze: parse do documento bruto CREATE OR REPLACE TABLE bronze.contratos_parsed AS SELECT path, ai_parse_document(content) AS documento_estruturado FROM READ_FILES(\u0026#39;/Volumes/juridico/contratos/raw/\u0026#39;, format =\u0026gt; \u0026#39;binaryFile\u0026#39;); -- Silver: extração de campos e classificação de risco CREATE OR REPLACE TABLE silver.contratos_extraidos AS SELECT path, ai_extract( documento_estruturado, array(\u0026#39;data_vencimento\u0026#39;, \u0026#39;valor_total\u0026#39;, \u0026#39;parte_contratada\u0026#39;) ) AS campos, ai_classify( documento_estruturado, array(\u0026#39;baixo_risco\u0026#39;, \u0026#39;medio_risco\u0026#39;, \u0026#39;alto_risco\u0026#39;) ) AS nivel_risco FROM bronze.contratos_parsed; -- Gold: pronto pra dashboard e alerta de vencimento CREATE OR REPLACE TABLE gold.contratos_monitorados AS SELECT path, campos.data_vencimento, campos.valor_total, nivel_risco FROM silver.contratos_extraidos WHERE nivel_risco IN (\u0026#39;medio_risco\u0026#39;, \u0026#39;alto_risco\u0026#39;); Esse pipeline inteiro pode rodar como Lakeflow Job agendado, com o resultado alimentando um dashboard AI/BI de contrato perto do vencimento sem que ninguém tenha escrito uma linha de código de OCR.\nUm detalhe que faz diferença na prática: o resultado de ai_parse_document fica em VARIANT, um tipo semi-estruturado que aceita schema variável entre linha e linha, o que é exatamente o que você quer quando o lote de documento mistura contrato de duas página com laudo técnico de quarenta. Isso significa que consultar o campo extraído exige notação de acesso a VARIANT (documento_estruturado:paginas, por exemplo) em vez de coluna fixa, e vale testar isso num notebook antes de montar o pipeline inteiro, porque schema inconsistente entre documento é a causa mais comum de query que quebra silenciosamente nessa etapa.\nOnde essa arquitetura ganha do modelo antigo de OCR isolado Vale comparar diretamente com o modelo anterior pra deixar claro o que muda. Antes, um pipeline de IDP típico envolvia um serviço de OCR externo, uma fila de mensagem pra desacoplar processamento pesado, um banco de metadado separado pra guardar resultado de extração, e um processo próprio de sincronização pra levar aquele resultado de volta pro lakehouse. Cada uma dessas peças tinha dono, versão e ciclo de deploy próprio. No modelo baseado em Lakeflow e funções de IA, as quatro peças viram uma sequência de tabela Delta, com linhagem automática, controle de acesso herdado do Unity Catalog e observabilidade compartilhada com qualquer outro pipeline de dado da empresa. O ganho não é só técnico, é organizacional: o time que já sabe operar pipeline de dado no Azure Databricks não precisa aprender uma stack nova pra processar documento.\nMinha leitura: o salto de Public Preview pra GA em ai_extract e ai_classify é o tipo de detalhe que muda a conversa com jurídico e compliance. Preview costuma vir com SLA mais fraco e sem garantia de estabilidade de schema de saída, o que trava qualquer aprovação de produção em setor regulado. GA muda esse cálculo, mas antes de eu apostar um processo crítico nisso eu testaria a extração num lote de documento real do cliente, com letra ruim e formato inconsistente de verdade, porque a demonstração da Databricks sempre usa documento limpo, e o mundo real não é assim.\nO que isso não resolve O pipeline resolve bem o problema de \u0026ldquo;documento entra, campo estruturado sai\u0026rdquo;, mas não resolve tudo. Três limites reais:\nai_prep_search ainda é Beta, e é justamente a etapa que decide a qualidade do chunk que vai pro RAG. Se você depende de retrieval preciso pra um agente de atendimento, testar essa etapa com dado real antes de produção é obrigatório, não opcional. Extração de campo com LLM erra em documento ambíguo ou com informação conflitante entre página, e a função não te dá, por padrão, um score de confiança fácil de auditar linha a linha. Você ainda precisa de uma camada de validação humana pra caso de alto risco. Custo por token de VARIANT gerado por ai_parse_document em documento grande (contrato de 40 página, por exemplo) soma rápido se você reprocessa o lote inteiro toda vez que muda um prompt de extração. Vale desenhar o pipeline pra reprocessar só o que mudou, não a base inteira. Fechamento O que a Databricks está vendendo aqui não é uma feature isolada, é a ideia de que documento não estruturado não precisa de uma stack de dados paralela. Pra quem já vive dentro do Unity Catalog e do Lakeflow, isso reduz superfície de manutenção de verdade. Ainda assim, GA na função central não significa que o resultado da extração é confiável sem revisão, então trate isso como aceleração de um pipeline que você ainda precisa validar, não como caixa preta que substitui julgamento humano em documento crítico.\nReferências Post oficial: Building with Databricks Document Intelligence and Lakeflow Documentação oficial: Intelligent Document Processing Documentação oficial (Microsoft Learn): Intelligent document processing - Azure Databricks #Databricks #DocumentIntelligence #Lakeflow #DataEngineering\n","permalink":"https://wiliamrosa.github.io/articles/databricks-document-intelligence-pipeline-documentos-nao-estruturados/","summary":"ai_parse_document, ai_extract e ai_classify já são GA no Azure Databricks, e o pipeline de processamento inteligente de documento (IDP) inteiro roda dentro do Lakeflow, sem infraestrutura separada de OCR ou fila de mensagem. A peça que ainda é Beta, ai_prep_search, é justamente a que decide se o documento processado vira retrieval bom ou lixo semântico.","title":"De PDF solto a coluna de tabela: o pipeline que domestica documento não estruturado no lakehouse"},{"content":"O AI Runtime entrou em preview público trazendo suporte a GPU pro compute serverless do Databricks, mas, por enquanto, só pra tarefas single-node. A API de treinamento distribuído multi-GPU segue em beta, um degrau atrás.\nIsso é significativo porque GPU serverless remove uma fricção histórica de quem faz deep learning no Databricks: gerenciar cluster com GPU manualmente, escolher tipo de instância, lidar com fila de provisionamento. Serverless promete abstrair tudo isso, você só pede compute com GPU e o Databricks resolve o resto.\nPor que vale ficar de olho nesse rollout gradual:\nSingle-node já cobre boa parte de fine-tuning e inferência que hoje é feita \u0026ldquo;artesanalmente\u0026rdquo; em cluster dedicado Separar GPU serverless single-node (preview) de multi-GPU distribuído (beta) é sinal de que a Databricks está sendo conservadora exatamente na parte mais difícil de acertar Menos gerenciamento de infraestrutura de GPU significa menos motivo pra time de ML manter conhecimento profundo de configuração de cluster Minha ressalva: preview público de GPU serverless costuma vir com fila de disponibilidade e variação de custo que só aparecem quando o volume de uso sobe. Antes de migrar workload de treinamento crítico pra cá, eu testaria com carga real e acompanharia custo por algumas semanas, não só o cenário de demonstração.\nFonte: https://learn.microsoft.com/en-us/azure/databricks/release-notes/product/2026/march\n#AzureDatabricks #AIRuntime #MachineLearning\n","permalink":"https://wiliamrosa.github.io/posts/azure-databricks-ai-runtime-gpu-serverless/","summary":"AI Runtime traz suporte a GPU pro serverless em preview público, pra tarefas single-node, a promessa é treinar sem gerenciar cluster, mas ainda com pé atrás no treinamento distribuído.","title":"GPU chegou ao compute serverless do Databricks com o AI Runtime"},{"content":"Quem já montou uma stack de engenharia de dados do zero conhece o padrão: uma ferramenta de ingestão pra puxar dado de CRM e ERP, um orquestrador separado pra costurar as dependências entre jobs, notebooks ou scripts fazendo a transformação propriamente dita, e um quarto sistema só pra monitorar se tudo isso rodou certo ontem à noite. Cada peça vem de um fornecedor diferente, com autenticação própria, log próprio e SLA próprio. Quando algo quebra às três da manhã, o primeiro trabalho não é corrigir o problema, é descobrir em qual das quatro ferramentas ele está.\nO Lakeflow ataca essa fragmentação de um jeito direto: junta ingestão, transformação e orquestração numa única superfície dentro do Azure Databricks, com Unity Catalog fazendo a governança de ponta a ponta. Não é reempacotamento de marketing de três produtos que já existiam separadamente, é a promessa de que dependência entre ingestão e transformação, lineage de coluna e controle de acesso deixam de ser reconciliados manualmente entre sistemas e passam a existir nativamente no mesmo grafo.\nAs três peças que formam o Lakeflow Lakeflow Connect cobre a ingestão, com conectores ponto e clique pra aplicação SaaS (Salesforce, Workday, ServiceNow), banco de dados (SQL Server) e mensageria, além do Zerobus Ingest, uma API serverless de escrita direta pra quem tem evento chegando de aplicação própria sem precisar montar um message bus no meio do caminho.\nSpark Declarative Pipelines é a camada de transformação: em vez de escrever a orquestração de streaming table e materialized view manualmente, você declara a tabela de destino e a lógica de negócio, e o motor infere o grafo de dependência sozinho, monta o DAG, e cuida de detalhe operacional como backfill e versionamento. O nome interno mudou ao longo do tempo (quem acompanha a plataforma há mais tempo vai reconhecer isso como evolução direta do que era Delta Live Tables), mas o mecanismo de fundo, declarar o resultado desejado em vez do passo a passo procedural, continua sendo a ideia central.\nLakeflow Jobs orquestra tudo isso como um DAG unificado: workload SQL, código Python, pipeline declarativo, dashboard e sistema externo convivem na mesma definição de job, com gatilho orientado a dado (tabela atualizada, arquivo chegou num volume), tarefa de controle de fluxo, e execução de backfill sem código.\nMão na massa: um pipeline simples de ponta a ponta Pra dar concretude, um exemplo de como as três peças se encaixam num pipeline básico de ingestão e transformação declarada:\nimport dlt from pyspark.sql.functions import col # Streaming table: ingestão incremental via Auto Loader @dlt.table( comment=\u0026#34;Ingestão bruta de pedidos via Auto Loader\u0026#34; ) def pedidos_bronze(): return ( spark.readStream.format(\u0026#34;cloudFiles\u0026#34;) .option(\u0026#34;cloudFiles.format\u0026#34;, \u0026#34;json\u0026#34;) .load(\u0026#34;/Volumes/vendas/bronze/pedidos_raw\u0026#34;) ) # Materialized view: validação e enriquecimento @dlt.table( comment=\u0026#34;Pedidos validados, com filtro de qualidade\u0026#34; ) @dlt.expect_or_drop(\u0026#34;valor_positivo\u0026#34;, \u0026#34;valor_total \u0026gt; 0\u0026#34;) def pedidos_silver(): return ( dlt.read_stream(\u0026#34;pedidos_bronze\u0026#34;) .withColumn(\u0026#34;valor_total\u0026#34;, col(\u0026#34;valor_total\u0026#34;).cast(\u0026#34;decimal(10,2)\u0026#34;)) .filter(col(\u0026#34;cliente_id\u0026#34;).isNotNull()) ) Esse trecho não roda sozinho, ele vira uma tarefa dentro de um Lakeflow Job que também pode disparar um dashboard de AI/BI assim que a tabela pedidos_silver for atualizada, usando gatilho orientado a dado em vez de agendamento por horário fixo. É essa amarração entre ingestão, transformação e o próximo passo do fluxo, tudo no mesmo lugar, que elimina boa parte do trabalho de cola que hoje vive em Airflow ou Azure Data Factory separado.\nGovernança sem reconciliação manual O ponto que costuma passar despercebido em quem só olha a superfície de produto é o que acontece por baixo com o Unity Catalog. Como ingestão, transformação e orquestração compartilham o mesmo catálogo, a linhagem de dado é capturada de ponta a ponta automaticamente, desde a tabela de origem no SQL Server até o dashboard final, sem depender de anotação manual ou de um sistema de linhagem terceiro tentando inferir relação a partir de log.\nMinha leitura: essa unificação de governança é, na minha visão, o argumento mais forte do Lakeflow, mais forte até que a conveniência de ter um conector pronto pra Workday. Eu já vi mais de um projeto de engenharia de dados falhar auditoria não porque o pipeline estava errado, mas porque ninguém conseguia provar com confiança de onde um número específico tinha vindo, com quantas transformações no meio. Ter isso garantido estruturalmente, e não como processo manual de documentação que sempre fica desatualizado, muda o tipo de conversa que se tem com o time de compliance.\nSystem Tables entram como a peça de observabilidade: em vez de montar um dashboard próprio de monitoramento consultando API de cada ferramenta separada, dá pra construir alerta e relatório de saúde direto em cima de tabela SQL nativa, com retenção e schema padronizados pela própria Databricks.\nCusto: onde a promessa exige verificação própria A Databricks divulga número de redução de custo bem expressivo, incluindo caso de até 83% de redução em custo de ETL e melhoria de performance de até 90 vezes reportada por cliente específico. Vale tratar esse tipo de número com o ceticismo padrão que qualquer benchmark de fornecedor merece: geralmente reflete uma migração específica, de uma stack mal otimizada, pra uma configuração nova bem ajustada. Na prática, eu testaria a economia real comparando o mesmo workload representativo do seu ambiente rodando old vs. new, com cluster policy e modo de compute (Performance vs. Standard no compute serverless) equivalentes, antes de usar o número de marketing numa justificativa de orçamento pra liderança.\nO mecanismo que sustenta a economia é real e faz sentido tecnicamente: compute serverless com otimização automática elimina cold start entre tarefa sequencial do mesmo job, e resource control granular por tarefa evita superalocar cluster pra etapa leve do pipeline. Isso é diferente de garantir que qualquer migração vai bater 83% de redução.\nO que isso não resolve Consolidar ingestão, transformação e orquestração numa plataforma não elimina a necessidade de modelagem de dado bem pensada, nem substitui decisão de arquitetura sobre particionamento e clustering de tabela grande. Também não resolve, por si só, o problema de time que já tem investimento pesado em Airflow com plugin customizado difícil de portar, a migração de orquestração legada continua sendo trabalho manual de reescrita, mesmo com a tarefa dbt e integrações de terceiro facilitando parte do caminho. E o conector ponto e clique do Lakeflow Connect cobre um conjunto específico de fonte, sistema legado ou API proprietária sem conector nativo ainda dependem de ingestão customizada via Auto Loader ou API própria.\nFechamento Lakeflow não inventa um paradigma novo de engenharia de dados, ele remove a fricção de coordenar três ferramentas diferentes pra fazer o que sempre foi conceitualmente uma coisa só: trazer dado de fora pra dentro, transformá-lo com confiança, e entregar no formato certo pro próximo consumidor. Pra quem está no Azure Databricks e já sente a dor de manter Data Factory, um orquestrador de terceiro e um catálogo de linhagem separado, vale o piloto num pipeline real antes de prometer o número de redução de custo da Databricks pra ninguém.\nReferências Databricks Blog, \u0026ldquo;Modernize your Data Engineering Platform with Lakeflow on Azure Databricks\u0026rdquo;: https://www.databricks.com/blog/modernize-your-data-engineering-platform-lakeflow-azure-databricks Databricks Docs, \u0026ldquo;Get started: Build an ETL pipeline\u0026rdquo;: https://docs.databricks.com/aws/en/getting-started/data-pipeline-get-started Microsoft Learn, \u0026ldquo;Tutorial: Build an ETL pipeline with Lakeflow pipelines - Azure Databricks\u0026rdquo;: https://learn.microsoft.com/en-us/azure/databricks/getting-started/data-pipeline-get-started Microsoft Learn, \u0026ldquo;System tables\u0026rdquo;: https://learn.microsoft.com/en-us/azure/databricks/admin/system-tables/ #Databricks #Lakeflow #EngenhariaDeDados #AzureDatabricks\n","permalink":"https://wiliamrosa.github.io/articles/lakeflow-azure-modernizacao-engenharia-dados/","summary":"Lakeflow consolida Connect, Spark Declarative Pipelines e Jobs numa única superfície de engenharia de dados dentro do Azure Databricks, substituindo a combinação típica de ferramenta de ingestão, orquestrador externo e scripts de transformação por um único plano de controle governado pelo Unity Catalog.","title":"Lakeflow no Azure Databricks: quando ingestão, transformação e orquestração param de ser três produtos separados"},{"content":"Time de segurança que já operou um SIEM tradicional conhece bem esse dilema: cada gigabyte adicional de log ingerido custa dinheiro, então a decisão de \u0026ldquo;o que vale a pena logar\u0026rdquo; acaba sendo tomada pelo orçamento, não pela necessidade real de visibilidade. O resultado previsível é ponto cego, exatamente na fonte de dado que parecia cara demais pra manter dentro da retenção padrão. Isso é um problema de arquitetura, não de disciplina do time de segurança.\nA proposta da Databricks com Data Intelligence for Cybersecurity é tratar telemetria de segurança como qualquer outro dado de lakehouse: armazenado em formato aberto (Delta Lake), padronizado por um schema comum (Open Cybersecurity Schema Framework, OCSF), e consultado com o mesmo motor que já processa o resto do dado corporativo. Isso desacopla o custo de retenção do custo de licença por volume que caracteriza SIEM legado, e permite reter mais telemetria por mais tempo sem multiplicar o orçamento de segurança.\nO mecanismo: três camadas sobre uma fundação comum A arquitetura se organiza em três peças que compartilham a mesma base de dado. Na entrada, telemetria de nuvem, endpoint, SaaS e sistema legado é normalizada pra OCSF, um padrão aberto que evita que cada fonte tenha um formato proprietário próprio, o que historicamente era um dos maiores custos ocultos de integração em SOC. No meio, o Unity Catalog aplica controle de acesso granular e trilha de auditoria sobre essa base, o \u0026ldquo;Security Lakehouse\u0026rdquo; citado na arquitetura oficial. Na saída, Agent Bricks entra como camada de automação, executando triagem de alerta, enriquecimento contextual e orquestração de resposta entre canal, o tipo de trabalho repetitivo que hoje consome a maior parte do tempo de analista júnior de SOC.\nLakebase complementa essa base como banco operacional de baixa latência dentro do mesmo ecossistema, útil pra caso que precisa de leitura e escrita rápida de estado (por exemplo, o status atual de um caso sendo investigado) sem depender de um banco transacional externo desconectado do resto do dado de segurança.\nMão na massa: consultando telemetria normalizada com OCSF Uma vez que a telemetria está normalizada em OCSF sobre Delta Lake, consultas que antes exigiam sintaxe proprietária do SIEM viram SQL padrão sobre tabela governada:\n-- eventos de autenticação suspeitos nas últimas 24h, -- já normalizados no schema OCSF (categoria authentication) SELECT time, actor.user.name AS usuario, src_endpoint.ip AS ip_origem, status, count(*) AS tentativas FROM security.ocsf.authentication WHERE time \u0026gt;= current_timestamp() - INTERVAL 24 HOURS AND status = \u0026#39;Failure\u0026#39; GROUP BY time, usuario, ip_origem, status HAVING count(*) \u0026gt; 5 ORDER BY tentativas DESC; O ganho aqui não é a sintaxe SQL em si, times de segurança maduros já usam SQL há anos dentro de SIEM moderno. O ganho é que essa mesma tabela security.ocsf.authentication está sob a mesma governança de Unity Catalog que qualquer outra tabela do lakehouse corporativo, com lineage, controle de acesso em nível de linha e auditoria, sem precisar exportar dado pra outro sistema e perder essa governança no caminho.\nGenie e autoatendimento pra quem não escreve SQL AI/BI Genie permite que analista de segurança faça pergunta em linguagem natural sobre a base de telemetria sem escrever consulta, o que remove um gargalo real: hoje boa parte da investigação depende de engenheiro de dado disponível pra escrever a query certa. Não é substituição de analista experiente, é redução do tempo entre \u0026ldquo;tenho uma hipótese\u0026rdquo; e \u0026ldquo;tenho o dado pra confirmar ou descartar essa hipótese\u0026rdquo;.\nMinha leitura: os números de redução de custo e tempo de resposta divulgados no anúncio (até 90% de redução em tempo médio de detecção, até 80% de redução em custo de SIEM) vêm de caso de cliente específico, e citar Arctic Wolf processando 8 trilhões de evento por semana é impressionante, mas não diz nada sobre o esforço de migração que uma empresa média vai enfrentar pra sair de um SIEM estabelecido há anos. Migrar SOC de plataforma é projeto de meses, não de fim de semana, mesmo com conector pronto. Eu trataria esse tipo de anúncio como validação de que a arquitetura funciona em escala, não como estimativa de esforço pra qualquer empresa que decida migrar amanhã.\nRetenção como decisão técnica, não como decisão de orçamento O argumento de fundo que sustenta essa arquitetura vale destacar de forma isolada: quando o custo de armazenar telemetria de segurança por mais tempo é o mesmo custo de armazenar qualquer outro dado no Delta Lake, com camada de storage barata e separada de compute, a decisão de quanto reter deixa de ser dominada por orçamento de licença de SIEM e passa a ser uma decisão técnica de política de retenção. Isso muda o tipo de investigação possível: um incidente descoberto seis meses depois do comprometimento inicial, cenário comum em ataque de longa duração, ainda tem telemetria disponível pra reconstrução forense, em vez de esbarrar numa janela de retenção de 30 ou 90 dias definida por custo de licenciamento, não por necessidade de segurança.\nO que isso não resolve Normalizar telemetria em OCSF exige mapeamento de fonte que não segue o padrão nativamente, e esse trabalho de mapeamento não desaparece só porque a plataforma de destino é melhor, alguém ainda precisa garantir que o conector ou pipeline de ingestão está traduzindo o evento da ferramenta de endpoint específica pra dentro do schema OCSF corretamente. Detecção baseada em regra e correlação que hoje já roda madura dentro de um SIEM tradicional também não é recriada automaticamente: migrar a lógica de detecção existente, ajustada ao longo de anos pra reduzir falso positivo, é trabalho manual de reescrita e reteste, não portabilidade automática. E depender de um ecossistema de parceiro (mais de 25 citados no anúncio, incluindo ferramenta de SIEM, descoberta de dado e segurança de agente de IA) significa que parte da experiência final depende da maturidade da integração de cada parceiro específico, não só da Databricks.\nFechamento Tratar dado de segurança como dado de lakehouse, governado pelo mesmo Unity Catalog e armazenado no mesmo formato aberto que o resto da plataforma, ataca um problema estrutural real de SOC moderno: o custo de retenção que hoje limita visibilidade. Vale a pena avaliar com cuidado a extensão do esforço de migração de regra de detecção existente antes de tratar isso como troca simples de fornecedor.\nReferências Databricks Blog, \u0026ldquo;Announcing Data Intelligence for Cybersecurity\u0026rdquo;: https://www.databricks.com/blog/transforming-cybersecurity-data-intelligence Databricks, \u0026ldquo;Lakebase\u0026rdquo;: https://www.databricks.com/product/lakebase Databricks, \u0026ldquo;Databricks AI Security Framework (DASF)\u0026rdquo;: https://www.databricks.com/resources/whitepaper/databricks-ai-security-framework-dasf #Databricks #Ciberseguranca #UnityCatalog #Lakebase\n","permalink":"https://wiliamrosa.github.io/articles/databricks-lakehouse-nativo-ciberseguranca/","summary":"Data Intelligence for Cybersecurity une Agent Bricks, Lakebase e o padrão aberto OCSF sobre Delta Lake pra tratar telemetria de segurança como dado de lakehouse governado, em vez de um silo isolado dentro de um SIEM proprietário caro por volume ingerido.","title":"Por que juntar SIEM e lakehouse na mesma tabela muda o cálculo de custo e velocidade em SecOps"},{"content":"Benchmark de geração de código pra linguagem geral (Python, JavaScript) é abundante, tem HumanEval, MBPP, uma dúzia de variante. Biblioteca de nicho, como as centenas de função específicas do Spark SQL, não tem esse luxo. Se você quer saber se um modelo de código realmente entende array_intersect ou transform do jeito que o Spark SQL implementa, muito provavelmente não existe benchmark público bom pra isso, e escrever um caso de teste manual pra cada função de uma API grande é trabalho que ninguém tem paciência de fazer na mão.\nA resposta da Databricks pra esse problema específico foi construir um pipeline que gera o próprio benchmark automaticamente, partindo da documentação da função, sem precisar de humano escrevendo caso de teste um por um. O resultado prático foram 286 casos de teste de Spark SQL gerados dessa forma, junto com uma descoberta que interessa a qualquer time avaliando ou fine-tunando modelo de código: o jeito como você escreve a instrução muda o resultado do modelo de forma mensurável, mesmo mantendo a tarefa idêntica.\nO motivo pelo qual esse tipo de trabalho ainda importa hoje, mesmo o texto original sendo de 2024, é que o problema de fundo, avaliar modelo de código numa API de nicho sem depender de benchmark genérico de linguagem geral, ficou mais comum, não menos. Toda empresa que constrói biblioteca interna própria (função customizada de transformação de dado, wrapper de API interna, DSL proprietária) enfrenta exatamente esse mesmo problema quando quer avaliar se um coding agent lida bem com o código específico daquela empresa, e o HumanEval genérico não ajuda em nada nesse caso.\nO mecanismo: quatro estágios, do exemplo da documentação ao caso de teste validado O pipeline segue uma lógica de validação cruzada em cadeia:\nFiltragem da função semente: cada função candidata é validada rodando o exemplo de código documentado contra o resultado de referência esperado, garantindo saída determinística e compatibilidade com o ambiente de execução. Função com comportamento não determinístico é descartada aqui. Geração de instrução de código: um modelo de ponta gera um comentário de código conciso (a instrução) a partir do nome da função, sua definição e exemplo, deliberadamente evitando mencionar o nome da função na instrução, pra forçar o modelo avaliado a inferir qual função usar, não só copiar o nome citado. Validação da instrução gerada: a instrução é testada pedindo pro mesmo modelo de ponta gerar uma solução a partir dela, que é executada e comparada contra o resultado da função semente original. Instrução que não produz solução equivalente é descartada. Avaliação do modelo de código: os modelos candidatos são avaliados em modo fill-in-the-middle (completar o meio de um trecho de código), com métrica pass@1, contra o conjunto final de 286 casos de teste de Spark SQL. O resultado reportado mostra Deepseek-coder-6.7b em 0,528 de pass@1 contra 0,748 do GPT-4o, e a maior parte dos erros vem de identificação incorreta da função certa ou de query aninhada complicada demais pra resolver um problema simples.\nMão na massa: reproduzindo o princípio de geração de instrução O pipeline completo depende de acesso a modelo de ponta em escala, mas o princípio central, gerar instrução sem citar o nome da função e validar com execução real, dá pra prototipar em pequena escala assim:\nimport re def extrai_nome_funcao(assinatura: str) -\u0026gt; str: return re.match(r\u0026#34;(\\w+)\\(\u0026#34;, assinatura).group(1) def gera_instrucao_sem_nome(nome_funcao: str, definicao: str, exemplo_sql: str) -\u0026gt; str: \u0026#34;\u0026#34;\u0026#34;Gera instrução evitando citar o nome da função (simplificado).\u0026#34;\u0026#34;\u0026#34; prompt = f\u0026#34;\u0026#34;\u0026#34; Baseado na definição abaixo, escreva um comentário curto descrevendo o QUE a query faz, sem mencionar o nome literal \u0026#39;{nome_funcao}\u0026#39;: Definição: {definicao} Exemplo: {exemplo_sql} \u0026#34;\u0026#34;\u0026#34; return chama_modelo_ponta(prompt) def valida_instrucao(instrucao: str, sql_esperado_resultado): \u0026#34;\u0026#34;\u0026#34;Pede pro modelo resolver a partir só da instrução, e compara execução.\u0026#34;\u0026#34;\u0026#34; solucao_gerada = chama_modelo_ponta(f\u0026#34;-- {instrucao}\\nSELECT \u0026#34;) resultado_gerado = executa_spark_sql(solucao_gerada) return resultado_gerado == sql_esperado_resultado # Exemplo com array_intersect nome = extrai_nome_funcao(\u0026#34;array_intersect(array1, array2)\u0026#34;) instrucao = gera_instrucao_sem_nome( nome, \u0026#34;Retorna um array com os elementos comuns entre dois arrays, sem duplicata.\u0026#34;, \u0026#34;SELECT array_intersect(array(1,2,3), array(2,3,4))\u0026#34; ) valido = valida_instrucao(instrucao, sql_esperado_resultado=[2, 3]) Esse esqueleto captura o essencial do estágio 2 e 3 do pipeline original, gerar instrução que testa compreensão semântica em vez de memorização de nome de função, e validar com execução real em vez de confiar cegamente na saída do modelo gerador.\nMinha leitura: o achado mais reaproveitável desse trabalho, pra quem usa Azure Databricks no dia a dia, nem é o benchmark de 286 casos em si, é a descoberta de que incluir o comentário # Databricks notebook source no prompt melhorou o desempenho do modelo de forma mensurável. Isso é um lembrete simples e prático: contexto de ambiente (saber que aquilo é um notebook do Azure Databricks, não um script solto) muda o comportamento de modelo de código de um jeito que vale a pena testar antes de assumir que seu prompt está bem otimizado. Eu testaria essa mesma ideia, adicionar marcador de contexto de ambiente no prompt, em qualquer pipeline de geração de código assistido por IA que eu estivesse validando hoje, é barato de testar e o ganho relatado não é desprezível.\nAdaptando o pipeline pra biblioteca interna própria Pra quem quer aplicar essa metodologia na própria empresa, o requisito de entrada é mais simples do que parece: você precisa de uma função com exemplo de uso documentado e resultado esperado determinístico, o resto do pipeline (gerar instrução sem citar o nome, validar com execução, avaliar com fill-in-the-middle) é reutilizável quase sem modificação. A parte que mais exige cuidado ao adaptar é o estágio 1, filtragem da função semente, porque biblioteca interna geralmente tem função com efeito colateral (grava em banco, chama serviço externo) que não é seguro executar repetidamente durante a geração e validação do benchmark. Vale isolar essas funções com efeito colateral do conjunto elegível antes de rodar o pipeline, ou mockar o efeito colateral de forma determinística.\nO que isso não resolve Esse tipo de benchmark automatizado tem limite claro:\nA qualidade do benchmark gerado depende inteiramente da qualidade do modelo gerador da instrução. Se o modelo de ponta usado pra gerar e validar instrução tem viés ou lacuna de conhecimento sobre uma função específica, esse viés se propaga pro benchmark inteiro sem ninguém perceber. 286 casos de teste é uma cobertura parcial da superfície de função do Spark SQL, que tem centenas de função built-in. O pipeline é uma metodologia reutilizável, não um benchmark definitivo e completo. Pass@1 mede se a primeira tentativa do modelo acerta, não mede robustez em produção frente a schema real, dado sujo ou combinação de função em query mais complexa do que os casos de teste sintéticos cobrem. Fechamento Passados quase dois anos desde a publicação original, a metodologia continua atual porque o problema que ela resolve, falta de benchmark bom pra biblioteca de nicho, não desapareceu, só ficou mais relevante conforme mais gente usa LLM pra gerar código Spark SQL no dia a dia. O valor prático real está no padrão de \u0026ldquo;gera, valida com execução, depois avalia\u0026rdquo;, que qualquer time pode adaptar pra própria biblioteca interna sem depender de um benchmark público que provavelmente não existe pro seu caso de uso.\nReferências Post oficial: Generating Coding Tests for LLMs: A Focus on Spark SQL Documentação de referência: Spark SQL built-in functions #Databricks #SparkSQL #DataEngineering #LLM\n","permalink":"https://wiliamrosa.github.io/articles/geracao-testes-codigo-llm-spark-sql/","summary":"Avaliar modelo de código em biblioteca de nicho como Spark SQL esbarra num problema básico: falta benchmark bom. Um pipeline de quatro estágios da Databricks gera caso de teste automaticamente a partir da própria função, com validação cruzada entre dois modelos, e revela que instrução simples como comentário de notebook do Azure Databricks muda o resultado do modelo de forma mensurável.","title":"Como ensinar um LLM a passar no teste de Spark SQL sem decorar a prova"},{"content":"Uma pergunta que volta com frequência em decisão de arquitetura de dado é \u0026ldquo;esse pipeline precisa ser streaming ou batch pode resolver?\u0026rdquo;, como se fossem dois mundos tecnológicos separados, com trade-off permanente entre um e outro. Essa pergunta parte de uma premissa que já não é verdadeira há alguns anos: no Azure Databricks, batch e streaming rodam no mesmo motor, com o mesmo código, e a decisão real não é qual tecnologia usar, é qual latência o negócio de fato precisa.\nTrocar a pergunta \u0026ldquo;batch ou streaming\u0026rdquo; por \u0026ldquo;qual é o tempo certo pra esse dado chegar\u0026rdquo; muda a conversa inteira. Tem caso que genuinamente precisa de milissegundos, detecção de fraude em transação de cartão, por exemplo. Mas tem uma quantidade grande de pipeline hoje rodando em janela batch de hora em hora só porque foi assim que alguém desenhou há três anos, quando streaming parecia coisa de time de infraestrutura sênior com Kafka cluster próprio pra manter. Isso não é mais verdade.\nO mecanismo: um motor, dois modos de disparo Spark Structured Streaming processa dado incrementalmente usando o mesmo modelo de execução do Spark batch, a diferença central está em como e quando o motor decide processar um novo lote de dado. O motor mantém checkpoint de progresso em armazenamento persistente, o que garante tolerância a falha e semântica de processamento exatamente uma vez: se o job cair no meio de um micro-lote, ele retoma exatamente de onde parou, sem duplicar nem perder registro.\nO intervalo de disparo é onde mora a flexibilidade real. Trigger.AvailableNow processa todo dado disponível no momento em um ou mais micro-lotes e depois encerra o job sozinho, funcionando como um batch incremental disfarçado de streaming, útil pra quem quer rodar o pipeline a cada quinze minutos via agendamento em vez de manter processo contínuo ligado. No outro extremo, o modo de processamento contínuo entrega latência de ponta a ponta na casa de milissegundos pra caso que realmente demanda isso. No meio, o intervalo de disparo tradicional (a cada alguns segundos, minutos, o que fizer sentido) cobre a maioria dos casos de negócio reais.\nMão na massa: o mesmo pipeline, dois perfis de latência O ponto que costuma surpreender quem nunca testou isso é o quão pequena é a diferença de código entre rodar o mesmo pipeline como batch incremental ou como streaming contínuo:\n# Perfil 1: batch incremental a cada execução agendada (df.writeStream .format(\u0026#34;delta\u0026#34;) .option(\u0026#34;checkpointLocation\u0026#34;, \u0026#34;/chk/pedidos\u0026#34;) .trigger(availableNow=True) .table(\u0026#34;vendas.silver.pedidos\u0026#34;)) # Perfil 2: streaming quase contínuo, latência de segundos (df.writeStream .format(\u0026#34;delta\u0026#34;) .option(\u0026#34;checkpointLocation\u0026#34;, \u0026#34;/chk/pedidos\u0026#34;) .trigger(processingTime=\u0026#34;10 seconds\u0026#34;) .table(\u0026#34;vendas.silver.pedidos\u0026#34;)) A leitura de origem (df), a lógica de transformação e o destino Delta continuam idênticos, só o trigger muda. Isso significa que a decisão de latência deixa de ser uma escolha arquitetural irreversível tomada no dia um do projeto e vira um parâmetro que dá pra ajustar conforme a necessidade do negócio evolui, sem reescrever pipeline.\nGovernança que atravessa dado histórico e dado em movimento Um argumento que costuma ficar em segundo plano na discussão sobre streaming é a governança. Como tudo aterrissa em tabela Delta gerenciada pelo Unity Catalog, dado processado em streaming carrega o mesmo controle de acesso, a mesma linhagem e a mesma política de mascaramento de coluna que dado processado em batch. Isso evita o cenário comum em arquitetura mais antiga, onde o pipeline de tempo real vive numa stack de governança paralela (Kafka Connect, um cluster próprio, permissão gerenciada à parte) e acaba com regra de acesso divergente da que vale pro resto do lakehouse.\nMinha leitura: o argumento de custo de streaming também merece uma correção de percepção. Existe uma crença antiga de que streaming custa mais que batch porque \u0026ldquo;fica ligado o tempo todo\u0026rdquo;. Isso era verdade quando streaming significava cluster dedicado rodando 24 horas independente de ter dado chegando ou não. Com trigger incremental e compute serverless escalando pra zero entre execuções, o padrão de consumo se aproxima muito mais do batch tradicional do que a intuição sugere. Eu ainda testaria o custo real com carga de produção antes de assumir isso como verdade universal, mas a lacuna que existia é bem menor hoje do que era há alguns anos.\nUm cenário concreto: de hora em hora pra quase tempo real sem reescrever nada Imagine um pipeline de detecção de estoque baixo que hoje roda a cada hora, porque foi assim que alguém configurou o Airflow há dois anos, quando ninguém tinha certeza se o cluster aguentaria rodar com mais frequência. Com o pipeline já escrito em Structured Streaming lendo via Auto Loader, a mudança pra latência de poucos minutos é trocar trigger(availableNow=True) agendado de hora em hora por trigger(processingTime=\u0026quot;5 minutes\u0026quot;) rodando continuamente, sem tocar em uma linha da lógica de transformação. O time de operação de loja passa a enxergar ruptura de estoque quase em tempo real, e o custo adicional, com compute serverless escalando conforme o volume real de evento chegando, costuma ser bem menor do que a intuição de \u0026ldquo;streaming é caro\u0026rdquo; sugere. Esse tipo de ganho incremental, sem projeto de reescrita, é onde a decisão de arquitetura realmente compensa o esforço de revisão.\nO que isso não resolve Streaming incremental não é mágica pra todo tipo de carga. Transformação que exige olhar o dataset inteiro de uma vez, tipo reprocessamento completo de histórico pra corrigir uma regra de negócio retroativamente, ainda é trabalho de batch full, não incremental. Join com estado (stateful join) entre dois streams de alto volume também traz complexidade real de gerenciamento de watermark e tamanho de estado que não desaparece só porque a API é declarativa, exige entendimento de janela de tempo e tolerância a atraso de chegada de dado (late data) pra não estourar memória do executor. E streaming contínuo de baixíssima latência tem trade-off genuíno de custo e complexidade operacional frente ao modo de trigger incremental, não é a opção padrão certa pra maioria dos pipelines.\nFechamento A pergunta certa deixou de ser \u0026ldquo;esse pipeline é batch ou streaming\u0026rdquo; e passou a ser \u0026ldquo;quanto atraso entre o evento acontecer e o dado estar disponível pra consulta é aceitável pro caso de uso\u0026rdquo;. Com o mesmo motor, o mesmo Delta Lake como destino e o mesmo Unity Catalog cuidando de governança, ajustar essa resposta não exige trocar de arquitetura, só de parâmetro de trigger. Vale revisar pipeline batch antigo que roda de hora em hora só por hábito, boa parte já poderia ganhar latência menor sem custo adicional relevante.\nReferências Databricks Blog, \u0026ldquo;Rethinking Data Streaming: Why It\u0026rsquo;s Viable for More Use Cases than You Might Expect\u0026rdquo;: https://www.databricks.com/blog/rethinking-data-streaming-why-its-viable-more-use-cases-you-might-expect Databricks Docs, \u0026ldquo;Structured Streaming\u0026rdquo;: https://docs.databricks.com/en/structured-streaming/index.html Microsoft Learn, \u0026ldquo;Structured Streaming concepts - Azure Databricks\u0026rdquo;: https://learn.microsoft.com/en-us/azure/databricks/structured-streaming/concepts #Databricks #StructuredStreaming #EngenhariaDeDados #DeltaLake\n","permalink":"https://wiliamrosa.github.io/articles/streaming-right-time-processing-databricks/","summary":"A divisão rígida entre pipeline batch e pipeline streaming é mais uma escolha de ferramenta antiga do que uma necessidade real: Spark Structured Streaming trata os dois casos como pontos no mesmo espectro de latência, com o mesmo motor, o mesmo código e as mesmas garantias de tolerância a falha.","title":"Streaming não é sobre velocidade máxima, é sobre acertar o relógio certo pra cada dado"},{"content":"Todo administrador de plataforma de dado já viveu essa cena: a fatura da nuvem chega mais alta que o esperado, e a investigação começa reativamente, vasculhando log de cluster de três semanas atrás tentando entender quem deixou o quê ligado. Esse modelo de gestão de custo, reativo e baseado em auditoria posterior, não escala com o tamanho do time nem com a quantidade de workspace. A alternativa que funciona de verdade é estrutural: restringir a configuração possível antes que ela vire gasto, não depois.\nO Databricks Unit (DBU) é a unidade de consumo da plataforma, calculada a partir de número de nó no cluster e poder computacional do tipo de instância escolhido, variando por tipo de workload (Jobs, All-Purpose, pipeline declarativo, SQL, serverless) e por tier de assinatura. Entender esse mecanismo é pré-requisito, mas a alavanca prática que realmente move a agulha é a cluster policy.\nO mecanismo: cluster policy como cerca, não como sugestão Cluster policy é um conjunto de regra administrativa que restringe o que um usuário pode configurar ao subir um cluster, seja via valor fixo, faixa de valor, padrão regex ou valor default. Diferente de uma diretriz documentada que depende de disciplina individual pra ser seguida, a policy é aplicada no momento da criação do cluster, o usuário simplesmente não consegue configurar fora do que foi permitido.\nEsse espectro entre \u0026ldquo;mais restritivo\u0026rdquo; e \u0026ldquo;menos restritivo\u0026rdquo; é a tensão central de qualquer decisão de FinOps em plataforma de dado: política restritiva demais garante previsibilidade de gasto, mas gera fricção que empurra usuário avançado a pedir exceção toda semana; política solta demais dá autoatendimento, mas custo vira imprevisível. O ponto de equilíbrio, segundo a própria documentação da Databricks, costuma ser uma abordagem balanceada, com custo previsível e autoatendimento controlado dentro de limite conhecido.\nMão na massa: uma policy de exemplo Uma policy típica pra ambiente de desenvolvimento, limitando tamanho de cluster e forçando prática de economia, se parece com isto:\n{ \u0026#34;spark_version\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;regex\u0026#34;, \u0026#34;pattern\u0026#34;: \u0026#34;1[5-9]\\\\..*\u0026#34;, \u0026#34;defaultValue\u0026#34;: \u0026#34;16.4.x-scala2.12\u0026#34; }, \u0026#34;node_type_id\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;allowlist\u0026#34;, \u0026#34;values\u0026#34;: [\u0026#34;Standard_D4ds_v5\u0026#34;, \u0026#34;Standard_D8ds_v5\u0026#34;] }, \u0026#34;autotermination_minutes\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;range\u0026#34;, \u0026#34;minValue\u0026#34;: 10, \u0026#34;maxValue\u0026#34;: 60, \u0026#34;defaultValue\u0026#34;: 30 }, \u0026#34;num_workers\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;range\u0026#34;, \u0026#34;maxValue\u0026#34;: 4 }, \u0026#34;custom_tags.cost_center\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;fixed\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;dados-analytics\u0026#34; }, \u0026#34;aws_attributes.availability\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;fixed\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;SPOT_WITH_FALLBACK\u0026#34; } } Repare que a tag cost_center é obrigatória e fixa, não uma sugestão que o usuário preenche se lembrar. Essa tag propaga pro billing da nuvem, o que transforma atribuição de custo por time de uma reconciliação manual trabalhosa numa consulta direta em tabela de uso.\nOnde o dinheiro realmente vaza Três mecanismos concentram a maior parte do desperdício evitável. Auto-termination encerra cluster ocioso depois de um período configurável de inatividade, e é surpreendente quantos workspace ainda operam sem esse limite ligado por padrão, pagando por cluster esquecido ligado num fim de semana inteiro. Autoscaling ajusta o número de nó conforme a carga de trabalho real, bom pra cluster compartilhado e job batch de complexidade variável, mas inadequado pra workload sensível a latência onde o tempo de scale-up vira gargalo. E instância spot, com desconto de até 90% frente ao preço sob demanda, resolve bem carga tolerante a falha como ambiente de desenvolvimento e staging, mas exige que o pipeline saiba lidar com preempção no meio da execução.\nNa prática: o erro mais comum que já vi em auditoria de custo não é uma dessas três coisas configurada errada isoladamente, é a ausência completa de cluster policy obrigatória pra usuário não técnico. Analista de negócio que só quer rodar uma consulta SQL não deveria ter a opção de subir um cluster All-Purpose de 20 nós, a interface deveria nem oferecer essa possibilidade. Migrar mesmo que seja 10% do workload de cluster interativo pra cluster de job com policy restrita já costuma gerar economia de cinco dígitos, segundo relato da própria Databricks, e isso bate com o que se observa na prática: a maior fonte de gasto evitável não é o job mal otimizado, é o cluster interativo esquecido ligado.\nCompute serverless muda o cálculo de novo SQL warehouse serverless elimina a cobrança dupla que existia no modelo clássico, onde se pagava DBU e instância de nuvem separadamente. Com serverless, a própria Databricks gerencia o pool de compute por trás, cobrando de forma unificada, com autoscaling praticamente instantâneo e sem tempo de start frio pra warehouse pequeno. Isso reduz drasticamente o incentivo perverso de deixar warehouse superdimensionado ligado \u0026ldquo;por garantia\u0026rdquo;.\nMonitoramento: da fatura reativa ao dashboard de consumo Depois que a policy estrutural está no lugar, a segunda camada é visibilidade contínua. A página de uso do Account Console permite visualizar consumo por DBU ou por valor em dólar, filtrado por workspace ou por SKU, tanto de forma agregada quanto detalhada por tabela. No Azure, a integração com Azure Cost Management entrega granularidade por tag através de todo o conjunto de serviço da assinatura, não só Azure Databricks, o que ajuda a comparar gasto de plataforma de dado com o resto do orçamento de nuvem numa visão só. Pra quem quer ir além do dashboard pronto, a exportação diária de log de uso em CSV permite montar pipeline próprio, carregando esse histórico numa tabela Delta e construindo alerta customizado em cima, por exemplo, um aviso quando o gasto semanal de um cost center específico ultrapassa a média das últimas quatro semanas em mais de 20%.\nO que isso não resolve Cluster policy bem desenhada não substitui monitoramento contínuo. Ela previne o pior caso (cluster gigante esquecido ligado), mas não identifica automaticamente query mal escrita rodando repetidamente num warehouse corretamente dimensionado, nem job redundante que dois times diferentes criaram sem saber da existência um do outro. Pra isso ainda é necessário consumir tabela de uso via API de billable usage ou System Tables, com pipeline próprio de análise, e isso é trabalho de engenharia recorrente, não configuração de política que se faz uma vez e esquece. Vale também lembrar que política de ciclo de vida de storage precisa estar coordenada com o ciclo de vacuum do Delta Lake, aplicar TTL de storage sem essa coordenação pode corromper tabela por remover arquivo de dado ainda referenciado pelo log de transação.\nFechamento Gestão de custo eficaz em Azure Databricks se parece mais com desenho de sistema de permissão do que com trabalho de auditoria financeira. Cluster policy, tag obrigatória e compute serverless bem configurado removem grande parte da superfície onde gasto acidental acontece, antes que ele vire linha na fatura do mês seguinte. O trabalho de monitorar consumo continua sendo necessário depois disso, mas parte de uma base bem menor de coisa que pode dar errado.\nReferências Databricks Blog, \u0026ldquo;Best Practices for Cost Management on Databricks\u0026rdquo;: https://www.databricks.com/blog/best-practices-cost-management-databricks Microsoft Learn, \u0026ldquo;Classic compute configuration best practices - Azure Databricks\u0026rdquo;: https://learn.microsoft.com/en-us/azure/databricks/compute/cluster-config-best-practices #Databricks #FinOps #ClusterPolicies #Governança\n","permalink":"https://wiliamrosa.github.io/articles/gestao-custo-databricks-politicas-cluster/","summary":"Controlar gasto no Databricks funciona melhor como restrição estrutural definida em cluster policy, autoscaling e auto-termination, do que como auditoria reativa de fatura no fim do mês. O trade-off central é entre restringir demais e travar produtividade, ou liberar demais e perder controle de custo.","title":"Gestão de custo no Databricks é decisão de política de cluster, não corte de orçamento no fim do mês"},{"content":" Olá! Sou Wiliam Rosa, especialista em Arquitetura e Engenharia de Dados, com atuação em plataformas modernas de dados, governança, analytics e Inteligência Artificial utilizando Databricks, Azure, AWS e Microsoft Fabric.\nCertificações e credenciais Databricks Certified Machine Learning Professional Microsoft Certified Trainer (MCT) Microsoft Certified: Azure Databricks Data Engineer Associate Microsoft Certified: Azure AI Engineer Associate Microsoft Certified: Azure Data Engineer Associate Microsoft Certified: Fabric Analytics Engineer Associate Microsoft Certified: Azure Data Fundamentals Microsoft Certified: Azure Fundamentals Designing Microsoft Azure Infrastructure Solutions (AZ-305) Comunidade Líder do São Paulo Databricks User Group, comunidade oficial da Databricks no Brasil. Palestrante e coordenador de trilhas de Dados e IA no TDC (The Developers Conference). Livros Lakehouse Engineering com Databricks — Amazon (eBook) · Clube de Autores (impresso) Machine Learning Prático com Python — Clube de Autores Sobre este blog Aqui escrevo sobre:\nDatabricks e Lakehouse: Delta Lake, Unity Catalog, Delta Live Tables, otimização de performance e custos, Machine Learning e MLOps. Plataformas de dados multicloud: Azure Data Platform, AWS e Microsoft Fabric. Governança e Analytics: arquitetura de dados, qualidade, segurança e boas práticas. Opinião e carreira: aprendizados de certificações, comunidade e o dia a dia de quem trabalha com dados e IA. Contato LinkedIn: linkedin.com/in/wiliam-rosa GitHub: github.com/WiliamRosa E-mail: wrosa85@gmail.com ","permalink":"https://wiliamrosa.github.io/about/","summary":"\u003cimg src=\"foto-wiliam.png\" alt=\"Foto de Wiliam Rosa\" class=\"about-avatar\"\u003e\n\n\u003cp\u003eOlá! Sou Wiliam Rosa, especialista em \u003cstrong\u003eArquitetura e Engenharia de Dados\u003c/strong\u003e, com atuação em plataformas modernas de dados, governança, analytics e Inteligência Artificial utilizando \u003cstrong\u003eDatabricks\u003c/strong\u003e, \u003cstrong\u003eAzure\u003c/strong\u003e, \u003cstrong\u003eAWS\u003c/strong\u003e e \u003cstrong\u003eMicrosoft Fabric\u003c/strong\u003e.\u003c/p\u003e\n\u003ch2 id=\"certificações-e-credenciais\"\u003eCertificações e credenciais\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eDatabricks Certified Machine Learning Professional\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMicrosoft Certified Trainer (MCT)\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMicrosoft Certified: Azure Databricks Data Engineer Associate\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMicrosoft Certified: Azure AI Engineer Associate\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMicrosoft Certified: Azure Data Engineer Associate\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMicrosoft Certified: Fabric Analytics Engineer Associate\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMicrosoft Certified: Azure Data Fundamentals\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMicrosoft Certified: Azure Fundamentals\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDesigning Microsoft Azure Infrastructure Solutions (AZ-305)\u003c/strong\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"comunidade\"\u003eComunidade\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eLíder do \u003cstrong\u003eSão Paulo Databricks User Group\u003c/strong\u003e, comunidade oficial da Databricks no Brasil.\u003c/li\u003e\n\u003cli\u003ePalestrante e coordenador de trilhas de Dados e IA no \u003cstrong\u003eTDC (The Developers Conference)\u003c/strong\u003e.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"livros\"\u003eLivros\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eLakehouse Engineering com Databricks\u003c/strong\u003e — \u003ca href=\"https://www.amazon.com.br/dp/B0DTJCBG46\"\u003eAmazon (eBook)\u003c/a\u003e · \u003ca href=\"https://clubedeautores.com.br/livro/lakehouse-engineering-com-databricks\"\u003eClube de Autores (impresso)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMachine Learning Prático com Python\u003c/strong\u003e — \u003ca href=\"https://clubedeautores.com.br/livro/machine-learning-pratico-com-python\"\u003eClube de Autores\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"sobre-este-blog\"\u003eSobre este blog\u003c/h2\u003e\n\u003cp\u003eAqui escrevo sobre:\u003c/p\u003e","title":"Sobre"}]