Study guide
1.13 Information Available in the MLflow UI
Databricks Certified Machine Learning Associate Study Guide Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Databricks Machine Learning (38% of the Exam)
1.1 MLOps Best Practices on Databricks 1.2 Advantages of Databricks ML Runtimes and Compute Selection 1.3 Promoting Code vs. Promoting Models 1.4 How AutoML Facilitates Model and Feature Selection 1.5 AutoML Advantages in the Model Development Process 1.6 Feature Tables in Unity Catalog vs. the Workspace Feature Store 1.7 Creating a Feature Table and Writing Data to It 1.8 Training a Model with Features from a Feature Table 1.9 Scoring a Model with Features from a Feature Table 1.10 Online vs. Offline Feature Tables 1.11 Manually Logging Metrics, Artifacts, and Models in an MLflow Run 1.12 Identifying the Best Run with the MLflow Client API 1.13 Information Available in the MLflow UI 1.14 Registering a Model in the Unity Catalog Registry 1.15 Model Tags, Aliases, and Champion/Challenger Promotion
2 Chapter 2: Data Processing and ML Workflows (19% of the Exam)
2.1 Computing Summary Statistics on a Spark DataFrame 2.2 Creating Visualizations for Categorical and Continuous Features 2.3 Comparing Two Categorical or Two Continuous Features 2.4 Removing Outliers with Standard Deviation and IQR 2.5 When Log-Scale Transformation Is Appropriate 2.6 Comparing and Applying Mean, Median, and Mode Imputation 2.7 One-Hot Encoding and When It Is or Is Not Appropriate
3 Chapter 3: Model Development (31% of the Exam)
3.1 Selecting the Appropriate Algorithm for a Scenario 3.2 Methods to Mitigate Data Imbalance in Training Data 3.3 Comparing Estimators and Transformers 3.4 Developing a Training Pipeline 3.5 Tuning Hyperparameters with Hyperopt's fmin 3.6 Grid, Random, and Bayesian Search Strategies 3.7 Parallelizing Single-Node Models for Hyperparameter Tuning 3.8 Cross-Validation vs. a Train-Validation Split 3.9 Counting the Models Trained by Grid Search and Cross-Validation 3.10 Using Common Classification Metrics 3.11 Using Common Regression Metrics 3.12 Choosing the Most Appropriate Metric for the Objective 3.13 Exponentiating Log-Transformed Predictions Before Evaluation 3.14 Model Complexity and the Bias-Variance Tradeoff
4 Chapter 4: Model Deployment (12% of the Exam)
4.1 Differences and Advantages of Batch, Streaming, and Real-Time Serving 4.2 Performing Batch Inference with pandas and Spark UDFs 4.3 Streaming Inference with Delta Live Tables 4.4 Deploying a Custom Model to a Model Endpoint 4.5 Deploying, Querying, and Splitting Traffic Across Real-Time Endpoints
1.13 Information Available in the MLflow UI
Key Takeaways Explain This Topic AI
The experiment page lists every run with its status, duration, source notebook or job, user, and any logged parameter or metric as a sortable, filterable column.
A run's detail page separates Parameters, Metrics, Tags, Artifacts, and the logged Model, and stepped metrics render as interactive line charts.
The Chart view plots metrics across runs — parallel-coordinates, scatter, and bar — which is how a sweep's parameter/metric relationship is read at a glance.
Selecting several runs and choosing Compare produces a side-by-side table of differing parameters and metrics plus overlaid metric curves.
The artifact viewer renders the MLmodel file, the model signature, the environment specification, and any logged images, tables, or files.
Last updated: August 2026
1.13 Information Available in the MLflow UI
Machine learning is an inherently empirical discipline. Developing high-performing models requires testing dozens of algorithmic architectures, feature combinations, and hyperparameter permutations. MLflow Tracking is the central component of the open-source MLflow platform integrated into Databricks, providing a unified logging engine for parameters, metrics, code versions, environments, and model artifacts. +---------------------------------------------------------------------------------------------------+
- | MLFLOW TRACKING ARCHITECTURE |
- +---------------------------------------------------------------------------------------------------+
- | EXPERIMENT: Top-level organizational unit (e.g., `/Shared/Experiments/churn_prediction`) |
- | |
- | +---------------------------------------------------------------------------------------------+ |
- | | RUN: Individual execution instance (Run ID: `a1b2c3d4e5f6...`) | |
- | | | |
- | | [ Parameters ] --> `learning_rate`: 0.01, `n_estimators`: 200, `max_depth`: 6 | |
- | | [ Metrics ] --> `train_loss`: 0.14, `val_f1`: 0.89, `epoch_time`: 12.4s (by step) | |
- | | [ Tags ] --> `git_commit`: `8f3a1b`, `environment`: `dev`, `author`: `alex` | |
- | | [ Artifacts ] --> `model/` (MLmodel, weights), `plots/confusion_matrix.png`, `data/` | |
- | +---------------------------------------------------------------------------------------------+ |
- +---------------------------------------------------------------------------------------------------+
- Experiment Types: Workspace vs. Notebook Experiments
On Databricks, experiments exist in two distinct operational forms:
Notebook Experiments :
Lifecycle : Automatically created when an MLflow logging command (e.g., mlflow.start_run() ) is executed within a Databricks notebook that does not explicitly set an active experiment.
Binding : Firmly bound to the specific notebook. Accessible via the Experiment Sidebar in the Databricks notebook UI.
Best Use Case : Ad-hoc, personal exploratory data science and rapid model prototyping.
Workspace Experiments :
Lifecycle : Explicitly created as standalone workspace objects via the Databricks UI ( New Experiment ) or programmatically via mlflow.create_experiment("/Shared/Experiments/fraud_v1") .
Binding : Not tied to any single notebook. Multiple team members, automated Databricks Workflows, and CI/CD pipelines can log runs into the same shared workspace experiment.
Best Use Case : Collaborative team projects, centralized production retraining jobs, and formal benchmarking.
- The Experiment Page
- Opening an experiment shows the run table — one row per run — with a fixed set of
built-in columns and a dynamic set drawn from what the runs logged:
- Column group Contents
- Run identity Run name, run ID, status ( RUNNING , FINISHED , FAILED , KILLED ), start time, duration
Provenance User who created it, source notebook or job (clickable on Databricks), Git commit when the run came from a Git Folder
- Parameters One column per logged parameter key
- Metrics One column per logged metric key, showing the latest value
- Tags Custom key/value annotations
- The table supports sorting by any column, a search box using the same filter grammar
- as search_runs ( metrics.val_f1 > 0.9 ), column show/hide, and grouping. Nested runs
- appear collapsed under their parent, which is how a Hyperopt sweep of 200 trials stays
readable.
The Run Detail Page
Clicking a run opens a page divided into fixed sections:
Overview — run ID, status, timing, source, user, and the Git commit or notebook
revision.
Parameters — the full parameter set, as logged.
Metrics — the final value of each metric. Clicking a metric that was logged with step opens an interactive line chart of the whole series.
Tags — including MLflow's own tags ( mlflow.source.name , mlflow.user , mlflow.parentRunId ) plus anything you set.
Artifacts — a file browser over everything logged to the run.
Models — the logged model, its flavour, and a link to any registered version
created from it.
What the artifact viewer renders
The MLmodel file, listing available flavours and the loader module.
The model signature — declared input and output schema.
Environment files ( requirements.txt , conda.yaml , python_env.yaml ) showing the
exact pinned dependencies.
Images (confusion matrices, SHAP plots) inline, plus tables, text, and JSON.
Chart View and Run Comparison
Two views turn a pile of runs into a decision:
- Chart view plots metrics across runs in the experiment. Parallel-coordinates
- plots are the standard way to read a hyperparameter sweep: each vertical axis is a
- parameter or metric, and each line is a run, so the parameter ranges that produce
good scores become visually obvious.
- Compare (select several runs, then Compare) produces a side-by-side table that
- highlights differing parameters, a combined metric table, and overlaid metric
curves for stepped metrics.
Databricks-Specific Additions
- Feature What it shows
- Experiment sidebar in a notebook The notebook experiment's runs without leaving the notebook
- Source links Direct link back to the notebook revision or job run that produced the run
- Registered-model link Jump from a run to the Unity Catalog model version created from it
Lineage (Catalog Explorer) Which tables and feature tables fed the run, and which endpoints serve the resulting model
System metrics CPU, GPU, and memory utilisation captured during the run, when system-metrics logging is enabled
- Exam framing : questions here are usually "which of these can you see in the
- MLflow UI". Parameters, metrics (including per-step curves), tags, artifacts, model
signature, environment, run source, and run status are all visible. Things that are not in the MLflow UI: cluster billing details, Unity Catalog grants, and raw
training data rows.