Databricks: Nomes Antigos, Nomes Atuais e o que Realmente Muda

Um tutorial manda criar um Repo, outro fala em Git folder. Um curso usa DLT, enquanto a documentação apresenta Lakeflow pipelines. Aprender a reconhecer os nomes ajuda a conectar materiais antigos à interface atual. Mas há uma pergunta importante: mudou apenas o nome ou também a forma de trabalhar?

O infográfico enviado reúne sete correspondências. Seu próprio rodapé informa que as nomenclaturas não foram verificadas. Neste artigo, usamos a imagem como referência visual e conferimos as explicações na documentação oficial Databricks para AWS, consultada em 11/10/2026. A imagem foi preservada; as ressalvas e atualizações estão no texto.

Atenção: a frase “mesma funcionalidade” não deve ser aplicada indiscriminadamente. A passagem do Workspace Model Registry para Models in Unity Catalog envolve migração e diferenças de governança e ciclo de vida.

1. Delta Live Tables: encontre os pipelines do Lakeflow

O infográfico associa Delta Live Tables (DLT) a Lakeflow Declarative Pipelines. Na página oficial consultada sobre o destino do DLT, o nome utilizado é Lakeflow pipelines. Essa diferença de terminologia é importante ao pesquisar materiais atuais.

A Databricks informa que quem já usava DLT não precisa migrar para continuar utilizando seus pipelines: o código existente continua funcionando. A documentação recomenda novos nomes e apresenta mudanças que permitem aproveitar recursos adicionais.

A documentação de pipelines também diferencia o framework aberto Apache Spark Declarative Pipelines dos pipelines gerenciados Lakeflow, que o estendem e são interoperáveis com ele. O framework permite definir pipelines em lote e streaming com SQL e Python. Não trate todos esses nomes como produtos idênticos.

2. Databricks Jobs → Lakeflow Jobs

Para o recurso chamado Databricks Jobs no infográfico, a documentação atual utiliza Lakeflow Jobs. Ele automatiza workflows: coordena tarefas, organiza sua execução e permite agendar processos recorrentes.

Exemplo didático: organizar um fluxo diário com ingestão, transformação e validação. O job representa o workflow; as tarefas representam as etapas. Pensar nessas responsabilidades é mais útil do que decorar apenas a nova marca.

3. Databricks Asset Bundles → Declarative Automation Bundles

A mudança de nome é confirmada pela FAQ oficial. A Databricks explica que Declarative Automation Bundles descreve melhor o uso e as capacidades da ferramenta, enquanto a palavra “assets” podia gerar confusão.

Bundles reúnem código e definições de recursos para aplicar práticas como controle de versão, revisão, testes e integração e entrega contínuas, conhecidas como CI/CD, a projetos de dados e IA. Podem incluir configurações de jobs e pipelines.

Na prática do aprendizado: ao encontrar “Asset Bundles” em um tutorial, procure a documentação de Declarative Automation Bundles e confira os comandos e configurações usados. Não presuma que qualquer exemplo antigo está pronto para produção.

4. Repos → Git folders

A documentação confirma que Repos agora se chamam Git folders. A funcionalidade central continua sendo sincronizar pastas do workspace com repositórios Git remotos para controle de versão.

Isso é mais específico do que apenas “hospedar código”. A documentação também informa que caminhos existentes em /Repos continuam funcionando, com ressalvas para casos raros. Portanto, não renomeie caminhos de notebooks ou jobs automaticamente só porque o rótulo da interface mudou.

5. Genie Spaces → Genie Agents

O nome Genie Agents está confirmado: a documentação declara que anteriormente esses recursos eram chamados Genie Spaces.

Um Genie Agent é uma interface de conversa em linguagem natural focada em um domínio de dados. Os usuários podem fazer perguntas e receber consultas SQL, tabelas de resultados e visualizações. Analistas preparam o agente com conjuntos de dados, exemplos e instruções de negócio.

Essa descrição é mais precisa do que apresentar o recurso como uma plataforma genérica para “criar aplicações de IA conversacional”. O foco descrito na documentação é conversar sobre os dados de um domínio.

6. SQL Endpoints → SQL Warehouses

A documentação confirma que SQL warehouses e SQL endpoints se referem a recursos de computação otimizados para SQL que sustentam o Databricks SQL. O histórico oficial também registra a mudança de nome.

O termo “warehouse”, neste contexto, não significa apenas um lugar para armazenar tabelas: estamos falando do recurso de computação usado para executar cargas SQL. Ao estudar um tutorial antigo, relacione o nome ao papel do recurso antes de procurar a opção na interface.

7. Workspace Model Registry → Models in Unity Catalog: não é só um novo nome

Este é o principal cuidado técnico do infográfico. A documentação apresenta a passagem para Models in Unity Catalog como uma migração de modelos e workflows, não como simples troca de rótulo.

Models in Unity Catalog oferece controle de acesso centralizado, auditoria, linhagem e compartilhamento de modelos entre workspaces. Na migração, as permissões mudam e os stages do registro antigo são substituídos por aliases e tags.

Não basta trocar o nome no documento: é necessário revisar permissões, modelos, metadados e workloads que os utilizam. A documentação orienta atualizar jobs, notebooks e endpoints após migrar os modelos.

Exemplo prático: lendo um tutorial antigo sem se perder

Imagine um cenário fictício de estudo: um tutorial ensina a sincronizar notebooks em Repos, criar um pipeline DLT, executá-lo em Jobs e preparar a implantação com Asset Bundles. Seu roteiro de revisão pode ser:

1. Relacionar Repos com Git folders e verificar como a pasta está organizada.
2. Consultar a documentação de Lakeflow pipelines para entender o exemplo DLT.
3. Identificar as tarefas e dependências do workflow em Lakeflow Jobs.
4. Revisar as definições de implantação com Declarative Automation Bundles.
5. Se houver modelos de machine learning, tratar Unity Catalog como uma avaliação de migração, não como substituição automática de palavras.

Esse roteiro não foi executado em um workspace Databricks. É uma proposta didática: testar compatibilidade e implantação exige verificar o ambiente real, as permissões e os recursos disponíveis.

O que levar para sua documentação

• Registre o nome antigo e o nome consultado: ajuda quem chega por um curso anterior.
• Descreva a responsabilidade: pipeline transforma dados; workflow coordena etapas; bundle organiza definições para implantação.
• Separe renomeação de migração: “mesmo nome no código” não garante “mesma configuração no ambiente”.
• Anote a data e a fonte: nomes e interfaces podem continuar evoluindo.

A mensagem central é simples: use o infográfico como mapa de estudo, mas consulte a documentação antes de modificar um projeto. Entender o papel de cada recurso vale mais do que substituir palavras sem avaliar as consequências.