Skip to main content

mlops-quickstart-overview

Reference for the Databricks MLOps Quickstart repo structure, parameterization contract, and Challenger/Champion conventions. Use whenever the user asks about repo layout, naming patterns, three-level Unity Catalog references, notebook widgets, MLflow experiment naming, or serving endpoint naming, or before adapting any notebook, job, or bundle in this repo.

Ir a la instalación

Datos de origen

Repositorio
databricks-solutions/mlops-quickstart
Última actividad en el origen
22 de julio de 2026 a las 14:33
Idioma detectado de SKILL.md
inglés
Estrellas
11
Forks
9

Opciones de instalación

De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.

Revisa los archivos de origen

Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.

Mostrando SKILL.md

SKILL.md
Instrucciones de origen · Vista previa de solo lectura
name
mlops-quickstart-overview
description
Reference for the Databricks MLOps Quickstart repo structure, parameterization contract, and Challenger/Champion conventions. Use whenever the user asks about repo layout, naming patterns, three-level Unity Catalog references, notebook widgets, MLflow experiment naming, or serving endpoint naming, or before adapting any notebook, job, or bundle in this repo.
# Databricks MLOps Quickstart — Overview This repository is an end-to-end MLOps template on Databricks. It uses the Iris classification dataset as a placeholder — it is meant to be adapted to any dataset and ML problem type (regression, clustering, classification, forecasting, etc.). When the user wants to adapt a specific area, load the matching skill: | Area | Skill | |------|-------| | Custom data source / ingestion | `adapt-data-ingestion` | | Custom algorithm or problem type | `adapt-model-training` | | MLflow 3 evaluate → approve → deploy pipeline | `adapt-model-deployment` | | Batch or realtime inference | `adapt-inference` | | `databricks.yml`, `resources/*.yml`, CI/CD | `adapt-bundle-and-cicd` | | Python library versions / pip dependencies | `manage-dependencies` | ## Repository Structure ``` notebooks/ 1_data_preprocessing/ → Data ingestion & feature engineering 2_model_training_and_deployment/ model_training.ipynb → Train & register model in Unity Catalog model_deployment/ → MLflow 3 deployment pipeline (evaluate → approve → deploy) 3_inference/ batch_inference.ipynb → Batch scoring with the Champion model realtime_inference.ipynb → Serving endpoint example resources/ → Databricks Asset Bundle job definitions (one YAML per job) databricks.yml → Bundle config with dev/prod targets and shared variables azure_pipelines.yml → CD pipeline for Azure DevOps .github/workflows/ → GitHub Actions CD pipeline (alternative) ``` ## Parameterization Contract All notebooks accept parameters via `dbutils.widgets`. Three core parameters are wired through every notebook and job: | Parameter | Purpose | Default | |-----------|---------|---------| | `catalog_name` | Unity Catalog catalog for all tables and models | Set per target in `databricks.yml` | | `schema_name` | Schema within the catalog | `iris` | | `model_version` | Model version (deployment notebooks only) | `1` | Rules to keep this contract intact: - **Three-level Unity Catalog references** always use `{catalog_name}.{schema_name}.<object>` — never hardcode a catalog or schema inside notebook code. - Job YAMLs in `resources/` declare these as job-level `parameters` sourced from `${var.*}` bundle variables, then pass them to notebooks via `base_parameters`. - If a notebook needs a new parameter, add it in **three places**: the widget in the notebook, the job `parameters` block, and the task `base_parameters`. ## Key Conventions - **Challenger/Champion pattern**: newly trained models are registered with the `@challenger` alias. After passing evaluation and approval, the deployment notebook promotes them to `@champion`. Inference notebooks always load the `@champion` alias. - **MLflow experiment naming**: experiments are scoped per user and catalog — `/{user}/{model}_{catalog}` — to avoid collisions during development. - **Serving endpoint naming**: derived as `{catalog_name}-{schema_name}-{model}-endpoint` (dots replaced with dashes) to ensure valid endpoint names. - **Idempotent notebooks**: ingestion and inference notebooks check for table existence before deciding whether to create vs. append/overwrite. Preserve this behavior when adapting. - **Default compute**: jobs without an explicit `job_clusters` block run on serverless. Dedicated job compute can be enabled by uncommenting the `job_clusters` section in the job YAML. - **Pinned dependencies**: every library version is pinned in `requirements.txt` at the repo root. Each notebook installs from it with a single `%pip install -r ../../requirements.txt` (or `../../../` for deployment notebooks). Never pin a version inline. See `manage-dependencies`. ## Adaptation Workflow When a user clones this repo to build their own ML solution, work through the adaptation areas in this order — and load the matching skill for each step: 1. **Data** → `adapt-data-ingestion` 2. **Model training** → `adapt-model-training` 3. **Deployment pipeline** → `adapt-model-deployment` 4. **Inference** → `adapt-inference` 5. **Bundle config + CI/CD** → `adapt-bundle-and-cicd` Each adapt-* skill is self-contained for its area but assumes the conventions in this overview hold.
Ver en GitHub