In Short: ML Where the Data Already Lives
Fabric's data science workload puts a working machine learning platform inside the same environment as your lakehouse and your BI: Spark notebooks for preparation and training, MLflow experiment tracking and a model registry as workspace items, AutoML for standard problems, and batch scoring that writes predictions straight back to Delta tables where Power BI reads them.
The strategic point is location. Most business ML fails not on algorithms but on plumbing - moving data out to a separate ML platform, moving predictions back, keeping both in sync. Fabric's bet is that eliminating the move beats specialised tooling for the majority of workloads, and for batch-scored business ML that bet mostly holds.
The Working Parts
Notebooks and Spark. Fabric notebooks run on managed Spark with the lakehouse mounted: features are engineered against Delta tables directly, in Python, with the usual libraries. For teams already writing PySpark or pandas, there is nothing new to learn except how little infrastructure there is to manage.
Experiments and the model registry. Training runs log to MLflow automatically - parameters, metrics, artefacts - and models register as versioned workspace items. This is the unglamorous discipline that separates reproducible ML from a folder of notebooks named final_v3, and Fabric makes it the default rather than an aspiration.
AutoML. For tabular classification, regression and forecasting, AutoML sweeps algorithms and hyperparameters and hands back a leaderboard. Its honest role is the fast baseline: many business problems are won or lost on whether a credible model exists at all, and a day-one baseline reframes the conversation from whether to how much better.
Scoring to OneLake. The predict step writes model output to Delta tables. From there it is ordinary data: pipelines transform it, semantic models expose it, Power BI visualises it, and Activator can act on it. Business users consume ML as columns in reports, which is precisely how adoption succeeds.
What It Does Not Try to Be
Honesty about the boundary saves architectural regret.
- Real-time inference at scale - Fabric's strength is batch; low-latency endpoints serving applications remain Azure Machine Learning or Foundry territory
- Heavy GPU training - large deep learning jobs belong on dedicated infrastructure
- Full MLOps ceremony - approval gates, staged deployment environments and drift monitoring are thinner than in dedicated platforms, though CI/CD via Fabric's git integration covers the essentials
- Generative AI development - building agents and LLM applications is Foundry's job; Fabric's generative story is Copilot and AI functions, not model hosting
The pattern that works: train and score where the data is, serve where the traffic is, and resist recreating a second ML platform's worth of tooling inside the first.
Where to Start
The best first Fabric ML projects share a shape: tabular data already in the lakehouse, a batch cadence the business accepts, and a prediction that lands naturally in an existing report. Churn scores on the customer table. Demand forecasts beside actuals. Payment-risk flags on invoices.
Run the sequence deliberately: AutoML baseline, honest evaluation against the current way of deciding, a scored table in OneLake, one report page that uses it, then iterate on the model only if the decision improves. Capacity is the operational watch-item - training and scoring share capacity units with everything else - and model ownership is the organisational one. A prediction column with no owner is a liability wearing a KPI's clothes.
Sources and Further Reading
Frequently asked
Spark-backed notebooks for feature engineering and training, MLflow-based experiment tracking and a model registry built into the workspace, AutoML for standard tabular problems, and batch scoring that writes predictions back to Delta tables in OneLake, where Power BI and downstream pipelines pick them up.
For many organisations, no: batch training and scoring over lakehouse data covers most business ML. Azure ML remains the better home for real-time inference endpoints at scale, heavy GPU training, and mature MLOps with managed deployment infrastructure. Plenty of estates run both, trained where the data is and served where the traffic is.
The standard pattern is batch scoring to a Delta table: the model writes predictions - churn scores, forecasts, classifications - into OneLake, and semantic models expose them like any other column. Business users consume ML through ordinary reports without knowing a model is involved.
Yes. Notebooks, training runs and scoring jobs draw capacity units from the same capacity as refreshes and queries unless you separate workloads across capacities. Schedule training thoughtfully and watch the Capacity Metrics app, exactly as you would for heavy pipelines.
For standard tabular problems - classification, regression, forecasting on reasonable volumes - AutoML produces credible baselines fast, and sometimes that baseline is all the business case needs. Custom feature engineering and hand-tuned models still win where the problem is subtle or the margin matters.
