Telco Churn MLOps
Governed customer-churn retention decision support, retained as a time-boxed learning and demonstration use case.
Executive summary
A governed MLOps capability demonstration
This use case is designed to demonstrate a governed Azure Databricks MLOps delivery pattern using the IBM Telco Customer Churn sample dataset.
The intended business output is a reviewable retention decision dataset: identify sample customers with elevated churn propensity and prioritise human review using an estimated monthly revenue-at-risk proxy.
Status
Parked
The IBM dataset is fictional/sample data for learning and demonstration. It is not real customer or operator data.
Baseline status: The scikit-learn logistic regression baseline was successfully trained and evaluated on held-out test data. Its performance is sufficient to begin the MLOps lifecycle, but it is not production-ready.
Business decision
Prioritise sample customers for hypothetical retention review
Delivery evidence
Bronze, Silver, Features, and MLflow verified
Next gate
Parked before Model Registry
Claim ceiling
Learning/demo only · Production readiness not proven
Azure Databricks MLOps Learning Progress
ADLS
Unity Catalog
Bronze
Silver
Features
MLflow
Model Registry
Batch Inference
Monitoring
Progress reflects completed hands-on evidence, not conceptual understanding alone.
Feature Preparation → Model Training
Lesson Learned: Spark Connect Preprocessing Overhead
During model preparation, the Spark ML preprocessing pipeline repeatedly failed at preprocessing_pipeline.fit(train_df) while fitting multiple categorical stages through Spark Connect. This was a Spark ML preprocessing issue, not an MLflow failure.
The original pipeline used 15 individual StringIndexer stages, one multi-column OneHotEncoder, and one VectorAssembler. Because fitted StringIndexers can create server-side model objects, managing many fitted stages through a Spark Connect client/server session may add more session and object-management overhead than this small dataset requires.
Preprocessing was consolidated into one multi-column StringIndexer, one multi-column OneHotEncoder, and one VectorAssembler.
This reduced the pipeline from 17 stages to 3. More precisely, fitted estimator models fell from approximately 16 to 2 because VectorAssembler is a Transformer and does not require fitting.
- Spark and Unity Catalog for governed Bronze, Silver, and feature tables
- pandas and scikit-learn for local preprocessing and training
- MLflow for experiment tracking, metrics, parameters, and model artifacts
This was appropriate for 7,043 customer records. Scikit-learn normally keeps its pipeline and fitted objects in the Python process rather than maintaining remote fitted model objects across a Spark Connect boundary, lowering operational overhead while preserving the learning objective.
Key conclusion: Spark ML issue ≠ dataset cache size
The relevant architectural difference was remote Spark Connect fitted-object and session management versus local Python-memory object management.
Limitation: This is workload-specific, not a general recommendation to replace Spark ML. Converting data with toPandas() places it in driver memory and requires reassessment for materially larger datasets.
Demonstration scope
What the learning path connects
Governed source ingestion and data-quality controls
Reproducible model-ready data and leakage controls
MLflow experiment evidence and model-governance gates
Batch scoring, monitoring, and human operational handoff
Can sample customers likely to churn be identified, prioritised with a transparent revenue-at-risk proxy, and delivered through a traceable workflow for hypothetical Retention-team review?
Scores and reason indicators support human review. They do not autonomously choose customer treatment, retrain a model, or promote a model version.