Trilha de certificações
Databricks Certified Machine Learning Associate
Avalia tarefas básicas de machine learning na Databricks: AutoML, Feature Store no Unity Catalog, MLflow (tracking, registro, aliases), exploração e preparação de dados, treino, tuning, avaliação e deploy (batch, streaming e tempo real).
Formato da prova
- Questões
- 48 questões
- Duração
- 90 min
- Taxa
- US$ 200
- Idiomas
- Inglês, Japonês, Português (BR), Coreano
- Validade
- 2 anos
- Versão do guia oficial
- 01 de mar. de 2025
Nenhum obrigatório. Recomenda-se o curso Machine Learning with Databricks, seis meses de prática e conhecimento de Python, scikit-learn e Spark ML.
O que cai e quanto pesa
- Databricks Machine Learning38%
- Processamento de dados19%
- Desenvolvimento de modelos31%
- Deploy de modelos12%
Número aproximado de questões por seção, considerando as 48 questões pontuadas.
Seção 1 · 38% · ≈ 18 questões
Databricks Machine Learning
Objetivos oficiais
- Identificar boas práticas de uma estratégia de MLOps.
- Identificar as vantagens de usar os runtimes de ML.
- Identificar como o AutoML ajuda na seleção de modelos e features e as vantagens que ele traz.
- Identificar os benefícios de feature tables no Unity Catalog (nível de conta) em vez do workspace.
- Criar uma feature table no Unity Catalog, gravar dados nela, treinar e pontuar modelos com essas features.
- Descrever as diferenças entre feature tables online e offline.
- Identificar o melhor run com a MLflow Client API e registrar manualmente métricas, artefatos e modelos em um run.
- Identificar as informações disponíveis na UI do MLflow.
- Registrar um modelo no Unity Catalog com a MLflow Client API e conhecer os benefícios sobre o registry do workspace.
- Identificar quando promover código é melhor que promover modelos, e vice-versa.
- Definir ou remover uma tag de modelo e promover um challenger a champion usando aliases.
MLOps em uma frase
Código versionado (Git), dados e features governados (UC), experimentos rastreados (MLflow), modelos registrados com aliases, deploy automatizado e monitoramento — em ambientes separados (dev/staging/prod).
Runtime de ML
Já vem com scikit-learn, XGBoost, PyTorch, TensorFlow, MLflow, Hyperopt/Optuna e drivers de GPU — sem instalar nada e com versões compatíveis entre si.
AutoML
Você aponta a tabela e o alvo; ele faz exploração, treina vários algoritmos, faz tuning e gera notebooks editáveis com o código de cada tentativa, tudo registrado no MLflow. Ótimo como baseline rápido e transparente.
Feature Store no Unity Catalog
from databricks.feature_engineering import FeatureEngineeringClient, FeatureLookup
fe = FeatureEngineeringClient()
fe.create_table(name="main.ml.cliente_features", primary_keys=["cliente_id"],
df=features_df, description="Features de clientes")
fe.write_table(name="main.ml.cliente_features", df=novas_features, mode="merge")
training_set = fe.create_training_set(
df=rotulos_df, # cliente_id + label
feature_lookups=[FeatureLookup(table_name="main.ml.cliente_features", lookup_key="cliente_id")],
label="churn")
fe.log_model(model=modelo, artifact_path="model", flavor=mlflow.sklearn,
training_set=training_set, registered_model_name="main.ml.churn")
preds = fe.score_batch(model_uri="models:/main.ml.churn@champion", df=clientes_df)
No UC, qualquer tabela Delta com primary key é uma feature table: governança, linhagem e compartilhamento entre workspaces. score_batch busca as features sozinho.
Offline = tabela Delta para treino/batch; online = cópia de baixa latência para serving em tempo real.
MLflow tracking
with mlflow.start_run():
mlflow.log_param("max_depth", 6)
mlflow.log_metric("rmse", 12.3)
mlflow.log_artifact("matriz_confusao.png")
mlflow.sklearn.log_model(modelo, "model", input_example=X[:5])
runs = mlflow.search_runs(experiment_ids=[exp_id], order_by=["metrics.rmse ASC"], max_results=1)
A UI mostra parâmetros, métricas (com gráficos de comparação), artefatos, código/notebook de origem e duração.
Registry no UC e aliases
mlflow.set_registry_uri("databricks-uc")
mv = mlflow.register_model(f"runs:/{run_id}/model", "main.ml.churn")
client = mlflow.MlflowClient()
client.set_registered_model_alias("main.ml.churn", "champion", mv.version)
client.set_model_version_tag("main.ml.churn", mv.version, "validado", "sim")
client.delete_model_version_tag("main.ml.churn", mv.version, "validado")
Aliases (@champion, @challenger) substituem os antigos stages. O UC dá permissões, linhagem e uso entre workspaces.
Promover código x modelo
- Deploy code (recomendado): o mesmo código de treino roda em cada ambiente com os dados daquele ambiente.
- Deploy model: treina uma vez e promove o artefato — útil quando treinar é caro demais para repetir.
Pegadinhas comuns
- FeatureStoreClient é a API antiga (workspace); no UC use FeatureEngineeringClient.
- Stages (Staging/Production) são do registry antigo; no UC use aliases.
Documentação:AutoMLFeature Store no UCModelos no UC
Seção 2 · 19% · ≈ 9 questões
Processamento de dados
Objetivos oficiais
- Calcular estatísticas de resumo de um DataFrame Spark com .summary() ou dbutils.data.summarize.
- Remover outliers por desvio-padrão ou IQR.
- Criar visualizações para features categóricas ou contínuas e comparar pares de features com o método adequado.
- Comparar imputação por média, mediana ou moda e aplicá-las.
- Usar one-hot encoding e identificar quando ele é ou não apropriado.
- Identificar quando aplicar transformação logarítmica.
Estatísticas
df.summary().show() # count, mean, stddev, min, quartis, max
dbutils.data.summarize(df) # perfil visual com histogramas
Outliers
q1, q3 = df.approxQuantile("valor", [0.25, 0.75], 0.01)
iqr = q3 - q1
sem_outliers = df.filter((F.col("valor") >= q1 - 1.5 * iqr) & (F.col("valor") <= q3 + 1.5 * iqr))
Por desvio-padrão: manter |x - média| <= 3σ (funciona melhor com distribuição ~normal).
Comparar features
| Par | Método |
|---|---|
| Contínua × contínua | Correlação (Pearson/Spearman), dispersão |
| Categórica × categórica | Tabela de contingência, qui-quadrado |
| Categórica × contínua | Box plot, comparação de médias |
Imputação
- Média: contínua sem outliers fortes.
- Mediana: contínua assimétrica ou com outliers.
- Moda: categórica. Olhe a distribuição antes de escolher.
from pyspark.ml.feature import Imputer
Imputer(strategy="median", inputCols=["renda"], outputCols=["renda_imp"]).fit(df).transform(df)
One-hot encoding
Bom para modelos lineares e redes com categóricas nominais de baixa cardinalidade. Ruim para alta cardinalidade (explode o número de colunas) e desnecessário em árvores, que lidam bem com índices (StringIndexer).
Log
Para variáveis positivas e muito assimétricas (renda, preço, contagens), log1p(x) aproxima de uma distribuição normal e reduz a influência de valores extremos.
Documentação:Preparação de dados para ML
Seção 3 · 31% · ≈ 15 questões
Desenvolvimento de modelos
Objetivos oficiais
- Usar fundamentos de ML para escolher o algoritmo adequado a um cenário.
- Identificar formas de mitigar desbalanceamento de classes.
- Comparar estimators e transformers e desenvolver um pipeline de treino.
- Usar o fmin do Hyperopt para tunar hiperparâmetros; fazer busca aleatória, em grade ou bayesiana; paralelizar o tuning de modelos de nó único.
- Descrever prós e contras de validação cruzada em relação a split treino/validação e aplicá-la.
- Calcular quantos modelos são treinados em grid search com validação cruzada.
- Usar métricas de classificação (F1, Log Loss, ROC/AUC) e de regressão (RMSE, MAE, R²) e escolher a mais adequada ao objetivo.
- Identificar a necessidade de exponenciar variáveis transformadas por log antes de avaliar ou interpretar.
- Avaliar o impacto da complexidade e do trade-off viés-variância no desempenho.
Escolha do algoritmo
Prever número → regressão (linear, árvores, gradient boosting). Prever classe → classificação (logística, árvores, boosting). Sem rótulo → clustering (k-means). Interpretabilidade importa → modelos lineares/árvores rasas.
Desbalanceamento
Pesos de classe / cost-sensitive learning, oversampling (SMOTE), undersampling, ajuste do limiar, e métricas adequadas (F1, PR-AUC) em vez de acurácia.
Transformer x Estimator (Spark ML)
- Transformer:
transform(df)→ df (ex.:VectorAssembler, modelo já treinado). - Estimator:
fit(df)→ Transformer (ex.:StringIndexer,LogisticRegression). - Pipeline encadeia etapas;
pipeline.fit()devolve umPipelineModel.
Hyperopt
from hyperopt import fmin, tpe, hp, STATUS_OK, Trials
def objetivo(params):
modelo = RandomForestClassifier(**params).fit(X_tr, y_tr)
return {"loss": -f1_score(y_val, modelo.predict(X_val)), "status": STATUS_OK}
espaco = {"max_depth": hp.choice("max_depth", [4, 8, 12]),
"n_estimators": hp.quniform("n_estimators", 50, 300, 50)}
melhor = fmin(objetivo, espaco, algo=tpe.suggest, max_evals=40, trials=Trials())
tpe.suggest = bayesiana; rand.suggest = aleatória. Para paralelizar modelos de nó único, a Databricks usava SparkTrials; hoje recomenda Optuna ou Ray para tuning distribuído.
Validação cruzada
k-fold usa melhor os dados e dá estimativa mais estável, mas custa k vezes mais. Nº de modelos = combinações da grade × k (+1 se re-treina o melhor no conjunto todo). Ex.: 3 × 2 × 3 = 18 combinações × 5 folds = 90.
Métricas
| Métrica | Use quando |
|---|---|
| RMSE | Erros grandes devem pesar mais |
| MAE | Robustez a outliers, interpretação em unidades |
| R² | Proporção da variância explicada |
| F1 | Classes desbalanceadas, equilibrar precisão e recall |
| ROC-AUC | Capacidade de ranquear, independente do limiar |
| Log loss | Importa a qualidade da probabilidade |
Se o alvo foi treinado em log(y), exponencie a predição (exp/expm1) antes de calcular RMSE na escala original.
Viés x variância
Modelo simples demais → underfitting (alto viés). Complexo demais → overfitting (alta variância: ótimo no treino, ruim na validação).
Pegadinhas comuns
- Grid de 3×2×3 com 5-fold = 90 modelos, não 18.
- Acurácia engana em dados desbalanceados.
Documentação:Hyperparameter tuningMLflow evaluate
Seção 4 · 12% · ≈ 6 questões
Deploy de modelos
Objetivos oficiais
- Identificar diferenças e vantagens de serving em batch, tempo real e streaming.
- Implantar um modelo customizado em um endpoint de model serving.
- Usar pandas para inferência em batch.
- Identificar como funciona a inferência em streaming com pipelines declarativos (antigo Delta Live Tables).
- Implantar e consultar um modelo para inferência em tempo real.
- Dividir o tráfego entre modelos em um endpoint de tempo real.
| Modo | Latência | Exemplo |
|---|---|---|
| Batch | Minutos/horas | Score diário de churn de toda a base |
| Streaming | Segundos | Detecção de anomalia em eventos |
| Tempo real | Milissegundos | Recomendação no checkout via API |
Batch
modelo = mlflow.pyfunc.spark_udf(spark, "models:/main.ml.churn@champion")
spark.table("main.ml.clientes").withColumn("pred", modelo(*colunas)).write.saveAsTable("main.ml.preds")
# ou com pandas: mlflow.pyfunc.load_model(uri).predict(pdf)
Streaming com pipeline declarativo
A mesma spark_udf aplicada a uma streaming table num pipeline — o pipeline escala o compute com o volume (autoscaling).
Tempo real
Crie um Model Serving endpoint apontando para a versão/alias do UC; consulte via REST:
curl -X POST https://<workspace>/serving-endpoints/churn/invocations \
-H "Authorization: Bearer $TOKEN" -d '{"dataframe_records": [{"idade": 40, "plano": "pro"}]}'
Divisão de tráfego: dois served entities no mesmo endpoint, ex.: 90% champion / 10% challenger (A/B ou canário).
Documentação:Model ServingInferência em batch
Treinamentos recomendados pela Databricks
- Instrutor: Machine Learning with Databricks
- Academy: Data Preparation for Machine Learning
- Academy: Machine Learning Model Development
- Academy: Machine Learning Model Deployment
- Academy: Machine Learning Ops