Databricks · Roadmap 2026

Roadmap de Estudos
Databricks — do Básico ao Avançado

Trilha de estudo estruturada em quatro níveis, do essencial da plataforma até a arquitetura de alta performance e a camada de IA. Inspirada no artigo The 2026 Mastering Databricks Roadmap (DataExpert.io), com cada tópico ligado à documentação oficial da Databricks.

4 níveis · 23 tópicos
Nível: iniciante → avançado
Referências oficiais em cada item
01

Fundamentos da Plataforma

Infraestrutura, governança e as primeiras consultas

Workspaces e Notebooks
Ambiente de desenvolvimento com Git

O Workspace é o ambiente central onde vivem notebooks, pipelines, dashboards e pastas de código. Notebooks são o "rascunho" para explorar dados, montar pipelines e desenvolver agentes de IA, combinando Python, SQL, Scala e R na mesma tela. O versionamento se dá via Git Folders (Repos), conectando o workspace a GitHub, GitLab ou Azure DevOps.

Comece pelo tutorial de "primeira consulta" para entender células, resultados e visualizações antes de tudo.

WorkspaceNotebooksGit Folders
Doc oficial · Query and visualize from a notebook
Compute: Clusters e Serverless
A infraestrutura que processa o trabalho

Todo processamento roda sobre compute. Um cluster é um conjunto de máquinas com Spark; o Serverless Compute elimina o gerenciamento da infraestrutura e hoje atende a grande maioria dos jobs — inicia em segundos e escala automaticamente. Entenda os tipos (all-purpose vs. jobs compute), o dimensionamento (autoscaling) e como isso impacta custo.

💡Regra prática: use Serverless por padrão; recorra a clusters clássicos apenas quando precisar de bibliotecas/instâncias específicas ou controle fino de rede.
ClustersServerlessAutoscaling
Doc oficial · Databricks components
Unity Catalog e a hierarquia do Metastore
Governança, acesso e rastreio de custo

O Unity Catalog é a camada de governança unificada: controle de acesso, linhagem, auditoria e rastreamento de custo em um só lugar. É essencial dominar a hierarquia de três níveis — Metastore → Catalog → Schema → Table — porque todo objeto é referenciado pelo nome totalmente qualificado catalog.schema.tabela.

sql
-- Hierarquia: Metastore > Catalog > Schema > Table
USE CATALOG main;
USE SCHEMA vendas;

-- Nome totalmente qualificado (three-level namespace)
SELECT * FROM main.vendas.pedidos LIMIT 10;

-- Conceder acesso a um grupo
GRANT SELECT ON TABLE main.vendas.pedidos TO `analistas`;
GovernançaMetastoreLinhagemGrants
Doc oficial · What is Unity Catalog?
Delta Tables — fundamentos
O formato de tabela do Lakehouse

O Delta Lake é o formato padrão de armazenamento: traz transações ACID, esquema versionado, time-travel, changelog e clustering líquido sobre arquivos Parquet. Aprenda a criar, gravar e ler tabelas Delta — é a base de tudo que vem depois.

sql
CREATE TABLE main.vendas.pedidos (
  id BIGINT,
  cliente STRING,
  valor DECIMAL(10,2),
  data DATE
) USING DELTA;

-- Inserir e ler
INSERT INTO main.vendas.pedidos VALUES (1, 'ACME', 250.00, '2026-08-18');
SELECT * FROM main.vendas.pedidos;
Delta LakeACIDParquet
Doc oficial · Create and manage Delta Lake tables
SQL e PySpark
As duas linguagens para ler e gravar Delta

Você vai alternar o tempo todo entre SQL (para consultas e transformações declarativas) e PySpark (para lógica programática, ETL e ML). Dominar o DataFrame API do PySpark — select, filter, groupBy, join, withColumn — é indispensável.

python
from pyspark.sql.functions import col

df = spark.read.table("main.vendas.pedidos")

resultado = (df
  .filter(col("valor") > 100)
  .select("cliente", "valor"))

resultado.write.mode("overwrite").saveAsTable("main.vendas.pedidos_top")
PySparkSQLDataFrame API
Doc oficial · PySpark basics
Lakebase — Postgres no Lakehouse
Banco transacional com CDC automático

O Lakebase é o banco OLTP (equivalente a Postgres) integrado à plataforma, com change data capture automático para o Lakehouse. Serve para aplicações operacionais e para expor dados de baixa latência lado a lado com o analítico, sem pipelines de sincronização manuais.

LakebaseOLTPPostgresCDC
Doc oficial · Lakebase Change Data Feed
02

Movimentação de Dados e Orquestração

Construção de pipelines de produção

MERGE INTO — pipelines idempotentes
Reprocessar com segurança (upsert)

O MERGE INTO combina insert, update e delete em uma única operação atômica. É a chave para pipelines idempotentes: reexecutar o mesmo lote não duplica dados nem corrompe o estado, o que torna reprocessamentos seguros.

sql
MERGE INTO main.vendas.pedidos AS alvo
USING atualizacoes AS origem
  ON alvo.id = origem.id
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *;
UpsertIdempotênciaACID
Doc oficial · MERGE INTO
Time Travel
Consultar e reverter versões da tabela

Cada gravação em uma tabela Delta cria uma nova versão. Com Time Travel você consulta o estado passado por versão ou timestamp, audita mudanças e reverte erros — indispensável para depuração e reprodutibilidade.

sql
-- Ver o histórico de versões
DESCRIBE HISTORY main.vendas.pedidos;

-- Consultar por versão ou por data
SELECT * FROM main.vendas.pedidos VERSION AS OF 12;
SELECT * FROM main.vendas.pedidos TIMESTAMP AS OF '2026-08-01';

-- Reverter para uma versão anterior
RESTORE TABLE main.vendas.pedidos TO VERSION AS OF 12;
VersionamentoAuditoriaRestore
Doc oficial · Work with table history
Change Data Feed (CDF)
Capturar mudanças linha a linha

O Change Data Feed expõe as linhas inseridas, atualizadas e removidas entre versões. Isso permite modelos de dados mestres em tempo real e propagação incremental para camadas seguintes, indo além de snapshots completos.

sql
-- Habilitar o CDF na tabela
ALTER TABLE main.vendas.pedidos
  SET TBLPROPERTIES (delta.enableChangeDataFeed = true);

-- Ler as mudanças a partir da versão 10
SELECT * FROM table_changes('main.vendas.pedidos', 10);
CDFIncrementalStreaming
Doc oficial · Use change data feed
OPTIMIZE e VACUUM
Manutenção e conformidade de privacidade

OPTIMIZE compacta arquivos pequenos em arquivos maiores e ordena os dados, acelerando leituras. VACUUM remove arquivos antigos não referenciados, liberando armazenamento e apoiando a conformidade (ex.: exclusão definitiva de dados após o período de retenção).

sql
-- Compactar e ordenar
OPTIMIZE main.vendas.pedidos;

-- Remover arquivos além de 7 dias (168h) de retenção
VACUUM main.vendas.pedidos RETAIN 168 HOURS;
⚠️Reduzir a retenção do VACUUM abaixo do padrão remove a capacidade de time-travel para versões mais antigas. Ajuste com consciência.
OPTIMIZEVACUUMRetenção
Doc oficial · Remove unused files with VACUUM
Lakeflow Declarative Pipelines
Transformação declarativa (ex-DLT)

Os Lakeflow Declarative Pipelines (a evolução do Delta Live Tables) deixam você declarar o que a tabela deve conter; o framework cuida da orquestração, dependências, retries, qualidade de dados (expectations) e processamento incremental. É a forma recomendada de construir ETL de produção.

python
import dlt
from pyspark.sql.functions import col

@dlt.table(comment="Bronze — dados brutos")
def bronze_pedidos():
    return (spark.readStream.format("cloudFiles")
        .option("cloudFiles.format", "json")
        .load("/Volumes/main/vendas/raw"))

@dlt.table(comment="Silver — dados limpos")
@dlt.expect_or_drop("valor_valido", "valor > 0")
def silver_pedidos():
    return dlt.read_stream("bronze_pedidos").select("id", "cliente", "valor")
LakeflowDeclarativeExpectationsAuto Loader
Doc oficial · Spark Declarative Pipelines
Jobs — orquestração e agendamento
Lakeflow Jobs (Workflows)

Os Lakeflow Jobs (antes "Workflows") orquestram tarefas em grafo de dependências (DAG): notebooks, pipelines, queries SQL e scripts. Configure gatilhos por agenda ou por chegada de arquivos, retries, notificações e passagem de parâmetros entre tarefas.

JobsDAGSchedulingTriggers
Doc oficial · Lakeflow Jobs
Arquitetura Medallion
Camadas Bronze → Silver → Gold

O padrão Medallion organiza o Lakehouse em camadas de qualidade crescente: Bronze (ingestão bruta, fiel à origem), Silver (limpo, deduplicado, conformado) e Gold (agregações e modelos prontos para consumo por BI e ML). É a estratégia de layering que amarra todo o Nível 2.

🥉🥈🥇Bronze preserva o histórico; Silver aplica regras de negócio e qualidade; Gold entrega tabelas de consumo por domínio.
BronzeSilverGoldLakehouse
Doc oficial · Medallion lakehouse architecture
03

Arquitetura Avançada e Performance

Sistemas de alto desempenho e baixo custo

Liquid Clustering
Organização dinâmica e automática dos dados

O Liquid Clustering substitui o particionamento estático e o Z-Order: você define chaves de clustering e o Delta reorganiza os dados automaticamente conforme evoluem, sem reescrever a tabela inteira. Melhora o data skipping e evita o problema de partições muito pequenas ou grandes.

sql
CREATE TABLE main.vendas.pedidos (
  id BIGINT, cliente STRING, data DATE
) CLUSTER BY (data, cliente);

-- Ou em tabela existente, com clustering automático
ALTER TABLE main.vendas.pedidos CLUSTER BY AUTO;
OPTIMIZE main.vendas.pedidos;
Liquid ClusteringCLUSTER BYData Skipping
Doc oficial · Use liquid clustering for tables
Partition Pruning, Predicate Pushdown e Data Skipping
Ler o mínimo de dados possível

Três mecanismos que reduzem o volume lido: Partition Pruning descarta pastas/partições que não satisfazem o filtro; Predicate Pushdown empurra o filtro para o mais próximo possível da fonte; e Data Skipping usa estatísticas (min/max por arquivo) para pular arquivos irrelevantes. Escrever filtros que aproveitem esses recursos é o que separa uma query rápida de uma cara.

🎯Filtrar por colunas de clustering/partição e evitar funções sobre a coluna filtrada (ex.: WHERE data = '2026-08-18' em vez de WHERE year(data)=2026) mantém o skipping ativo.
Partition PruningPredicate PushdownData Skipping
Doc oficial · When to partition tables
Narrow vs. Wide, Shuffles e partições
Como o Spark distribui o trabalho

Transformações narrow (como SELECT, WHERE) processam cada partição isoladamente e são baratas. Transformações wide (GROUP BY, JOIN, ORDER BY) exigem shuffle — redistribuição de dados pela rede entre executores — que costuma ser o principal gargalo. Dimensionar partições para ~100–200 MB cada evita tanto o excesso de tarefas minúsculas quanto o estouro de memória.

⚠️Shuffle é caro: minimize joins/agrupamentos desnecessários, filtre antes de agregar e cuide do número de partições de saída.
NarrowWideShuffle100–200 MB
Doc oficial · Best practices for performance efficiency
Broadcast Joins e tipos físicos de join
Escolher a estratégia de junção certa

O Spark escolhe um tipo físico de join: broadcast hash join (envia a tabela pequena, <~10 GB, para todos os nós, evitando shuffle), shuffle sort-merge join (para tabelas grandes) e nested loop (último recurso). Forçar o broadcast de uma dimensão pequena costuma ser a otimização de maior impacto.

python
from pyspark.sql.functions import broadcast

# Faz broadcast da tabela pequena, evitando shuffle na grande
resultado = fatos.join(broadcast(dim_cliente), "cliente_id")
Broadcast JoinSort-MergeNested Loop
Doc oficial · Optimization recommendations
Adaptive Query Execution (AQE)
Otimização em tempo de execução

A AQE reotimiza o plano durante a execução com base em estatísticas reais: coalesce de partições de shuffle, conversão dinâmica para broadcast join e tratamento automático de skew (dados desbalanceados). Está ativa por padrão no Databricks — entender o que ela faz ajuda a interpretar planos e a não brigar com ela.

sql
SET spark.sql.adaptive.enabled = true;
SET spark.sql.adaptive.skewJoin.enabled = true;
SET spark.sql.adaptive.coalescePartitions.enabled = true;
AQESkewCoalesce
Doc oficial · Adaptive query execution
Query Profiling e EXPLAIN
Ler o plano de execução

Saber diagnosticar é o ápice do nível avançado. Use EXPLAIN FORMATTED para ler o plano físico (que join foi escolhido? há shuffle? o skipping foi aplicado?) e o Query Profile na UI do Databricks SQL para ver tempo por estágio, linhas lidas e gargalos reais.

sql
EXPLAIN FORMATTED
SELECT cliente, SUM(valor)
FROM main.vendas.pedidos
WHERE data >= '2026-01-01'
GROUP BY cliente;
EXPLAINQuery ProfilePlano físico
Doc oficial · Optimization recommendations
Arquiteturas de referência do Lakehouse
Consolidar as decisões de design

Feche o nível avançado estudando as arquiteturas de referência oficiais e os pilares do Well-Architected Lakehouse (confiabilidade, segurança, eficiência de performance, otimização de custo e excelência operacional). Elas mostram como todas as peças anteriores se encaixam em um sistema de produção coeso.

Reference ArchitectureWell-ArchitectedCusto
Doc oficial · Databricks reference architectures
04

IA e Analytics

Os diferenciais a explorar: AI Engineering e Genie

MLflow
Rastreio, registro e deploy de modelos

O MLflow gerencia o ciclo de vida de ML e de agentes de IA: rastreio de experimentos, versionamento de modelos no Unity Catalog, avaliação e deploy em endpoints de serving. É a espinha dorsal da engenharia de IA na plataforma.

python
import mlflow
mlflow.set_registry_uri("databricks-uc")

with mlflow.start_run():
    mlflow.log_param("max_depth", 5)
    mlflow.log_metric("rmse", 0.42)
    mlflow.sklearn.log_model(
        modelo, "modelo",
        registered_model_name="main.ml.previsao_vendas")
MLflowModel RegistryServing
Doc oficial · MLflow on Databricks
Agentes de IA e AgentBricks
Construir e servir agentes sobre seus dados

Com o Mosaic AI Agent Framework (AgentBricks) você constrói agentes que consultam dados governados pelo Unity Catalog, usam ferramentas e RAG, e são avaliados e implantados com o MLflow. Comece pelo quickstart de agentes e depois avance para agentes com recuperação sobre dados estruturados.

AI AgentsAgentBricksRAGTools
Doc oficial · Get started with agents
Genie — análise em linguagem natural
Perguntas em texto sobre dados governados

O AI/BI Genie permite que usuários de negócio façam perguntas em linguagem natural e recebam respostas geradas como SQL sobre dados do Unity Catalog, com análise e agendamento automáticos. É a ponte entre o Lakehouse governado e o consumo self-service — o fecho natural da trilha.

GenieAI/BINL para SQLSelf-service
Doc oficial · AI/BI Genie