Skip to content
Lucas Lessa

Certification trails

Associate

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).

The guides and the questions are in Portuguese for now; the interface is in English.

Exam format

Questions
48 questions
Duration
90 min
Fee
US$ 200
Languages
Inglês, Japonês, Português (BR), Coreano
Validity
2 years
Official guide version
Mar 01, 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.

What is covered and how much it weighs

Approximate number of questions per section, out of the 48 scored questions.

Section 1 · 38% · ≈ 18 questions

Databricks Machine Learning

Official objectives

  • 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.

Common pitfalls

  • FeatureStoreClient é a API antiga (workspace); no UC use FeatureEngineeringClient.
  • Stages (Staging/Production) são do registry antigo; no UC use aliases.

Documentation:AutoMLFeature Store no UCModelos no UC

Section 2 · 19% · ≈ 9 questions

Processamento de dados

Official objectives

  • 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

ParMétodo
Contínua × contínuaCorrelação (Pearson/Spearman), dispersão
Categórica × categóricaTabela de contingência, qui-quadrado
Categórica × contínuaBox 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.

Documentation:Preparação de dados para ML

Section 3 · 31% · ≈ 15 questions

Desenvolvimento de modelos

Official objectives

  • 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 um PipelineModel.

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étricaUse quando
RMSEErros grandes devem pesar mais
MAERobustez a outliers, interpretação em unidades
R²Proporção da variância explicada
F1Classes desbalanceadas, equilibrar precisão e recall
ROC-AUCCapacidade de ranquear, independente do limiar
Log lossImporta 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).

Common pitfalls

  • Grid de 3×2×3 com 5-fold = 90 modelos, não 18.
  • Acurácia engana em dados desbalanceados.

Documentation:Hyperparameter tuningMLflow evaluate

Section 4 · 12% · ≈ 6 questions

Deploy de modelos

Official objectives

  • 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.
ModoLatênciaExemplo
BatchMinutos/horasScore diário de churn de toda a base
StreamingSegundosDetecção de anomalia em eventos
Tempo realMilissegundosRecomendaçã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).

Documentation:Model ServingInferência em batch

Training recommended by 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
Machine Learning Associate exam guide · Lucas Lessa