Databricks Metric Views for manufacturing analytics
Define manufacturing measures centrally in Unity Catalog, query them at the business grain you need and reuse the same metric logic across SQL, BI and governed AI experiences.
Governed source
production_run_fact
Fields
Measures
The grouping can change at query time. The measure definition stays in the Metric View.
The difference is where aggregation becomes fixed.
Standard SQL view
Need another grain? Build another query or view.
Metric View
The same measure can serve different analytical grains.
Metric Views still rely on a sound source model. They standardize metric behavior; they do not replace upstream data modeling.
Why Metric Views
A standard view fixes the query shape. A Metric View keeps the measure reusable.
A Metric View separates measures from the fields used to group and filter them. Users can analyse the same governed measure by site, line, product, shift or date without recreating the aggregation logic.
Central measure logic
The formula is maintained in Unity Catalog instead of being copied into every consumer.
Flexible grouping
Fields stay available for grouping and filtering at query time.
Shared semantic contract
Comments, display names and synonyms give the metric a documented business meaning.
Create a Metric View
Start with a governed source, then define fields and measures
The YAML contract can reference a Unity Catalog table, view, Metric View or SQL query. For manufacturing analytics, start from a data product with a clear grain and add only the fields and measures that belong to that business process.
Metric View anatomy
Source
The governed fact or data product underneath the metric.
Fields
Business attributes available for selection, grouping and filtering.
Measures
Aggregate expressions that stay independent of the final query grain.
Semantic metadata
Comments, display names and synonyms improve discoverability and interpretation.
CREATE OR REPLACE VIEW factory.gold.production_performance_metrics
WITH METRICS
LANGUAGE YAML
AS $$
version: 1.1
comment: "Production performance metrics"
source: factory.gold.production_run_fact
fields:
- name: Production Date
expr: source.production_date
- name: Site
expr: source.site_id
- name: Line
expr: source.line_id
- name: Product
expr: source.product_id
measures:
- name: Good Output
expr: SUM(source.good_output_kg)
comment: "Released good output in kg"
synonyms: ["good quantity", "accepted output"]
- name: Yield
expr: 100 * SUM(source.good_output_kg)
/ NULLIF(SUM(source.input_qty_kg), 0)
comment: "Good output as percentage of input"
$$;SELECT
`Production Date`,
`Site`,
`Line`,
MEASURE(`Good Output`) AS good_output_kg,
MEASURE(`Yield`) AS yield_pct
FROM factory.gold.production_performance_metrics
GROUP BY ALL
ORDER BY `Production Date`, `Site`, `Line`;Illustrative result set. Change the grouping fields and the Metric View evaluates the same measures at the requested grain.
Querying measures
Use MEASURE() and choose the grouping at query time
Measures are queried through the MEASURE() aggregate function. The query selects the fields that define the analysis grain, while the Metric View keeps the underlying measure expression centralized.
Select fields normally
Use fields in SELECT, WHERE and GROUP BY clauses.
Wrap measures in MEASURE()
The engine evaluates the governed aggregation for the requested grouping.
Keep filters explicit
Query filters can narrow the analysis without redefining the measure.
Metric design
Design measures around a clear manufacturing business process
A Metric View works best when its source already has a stable grain. Keep measures close to that process and document the rule that can change the outcome.
Measure
Yield
Natural grain
run × product
Rule to make explicit
input basis · rework · by-products
Measure
Available stock
Natural grain
batch × location
Rule to make explicit
blocked · quarantine · expiry status
Measure
Release rate
Natural grain
batch × release decision
Rule to make explicit
release state · rework treatment
Measure
OTIF
Natural grain
order line × shipment
Rule to make explicit
promised date · quantity tolerance
Measure
Margin
Natural grain
order line × product
Rule to make explicit
cost basis · rebates · allocation
Relationships
Use joins to enrich the metric, without losing control of cardinality
Metric Views support star and snowflake relationships. The common manufacturing pattern is a fact source enriched with dimensions such as product, line, site and customer.
Many-to-one is the default
Use dimension joins where each source row resolves to the expected dimension member.
Snowflake paths are supported
Normalized dimensions can be modeled through nested joins when the business relationship is clear.
RELY needs a real guarantee
Only declare at_most_one_match when the data contract truly guarantees it. Databricks does not validate that promise at runtime.
Keep the fact source central and bring in only the dimensions required by the query.
Product
Site
production_run_fact
run grain
Line
Date
The engine can avoid unnecessary joined tables when a query does not reference their fields.
version: 1.1
source: factory.gold.production_run_fact
joins:
- name: product
source: factory.gold.dim_product
on: source.product_id = product.product_id
rely:
at_most_one_match: true
fields:
- name: Product Family
expr: product.product_family
measures:
- name: Good Output
expr: SUM(source.good_output_kg)Build higher-level metrics from smaller governed components.
Atomic
Good Output
SUM(good_output_kg)
Atomic
Input Quantity
SUM(input_qty_kg)
Composed measure
Yield
Good Output ÷ Input Quantity
Time series
7-day rolling yield
window measure
Reusable model
Metric View as source
compose across views
Advanced measures
Compose metrics instead of repeating their logic
Metric Views can reference earlier fields and measures, and a Metric View can also use another Metric View as its source. This is useful when a business KPI is built from smaller measures that already have a governed definition.
Composed measures
Reference existing measures so the lower-level logic is not duplicated.
Window measures
Use them for moving averages, period comparisons and cumulative calculations when the feature fits your runtime and support requirements.
Treat window measures as experimental
Current Databricks documentation labels window measures Experimental. Keep that maturity level in mind for production design.
Performance
Materialize expensive query patterns without changing the metric contract
Metric View materialization can pre-compute aggregations or prepare an unaggregated joined dataset. Queries still target the Metric View, while the optimizer can rewrite them to the best valid materialization.
Aggregated materialization
Useful for recurring dashboard grains and predictable groupings.
Unaggregated materialization
Useful when joins and filters are expensive but final grouping remains ad hoc.
Check security constraints first
Current Databricks guidance excludes materialization when the Metric View or its sources use RLS, column masks or ABAC policies.
Query
SELECT fields, MEASURE(...)
Query optimizer
Choose the best valid path
Aggregated
pre-computed grain
Unaggregated
prepared joins
Source
fallback path
Consumption
Keep the metric in Databricks and adapt the access pattern to the consumer
The semantic definition can serve several interfaces. Each tool may need a different query pattern, but the measure remains governed in the Metric View.
Governed semantic contract
Production Performance
Databricks SQL
Query fields and MEASURE() directly.
Power BI
Use Native query with MEASURE() in DirectQuery for the current connector pattern.
Databricks dashboards
Build visualizations on the same governed measures.
Genie and AI
Use semantic metadata to improve metric discovery and interpretation.
Power BI connector behavior changes over time. Current Microsoft guidance uses Native query with MEASURE() in DirectQuery; the former BI Compatibility Mode option is no longer available in the Power BI connector.
Semantic governance
Treat shared measures as production code
A central measure can affect many reports and analyses at once. Ownership, regression tests and controlled change review are part of the implementation.
Define
owner · grain · scope · unit
Test
known cases · edge cases
Review
downstream impact · approval
Publish
shared access · documentation
How Food For Analytics implements it
Metric Views sit on top of governed manufacturing data products in Titan
Titan keeps source integration, manufacturing context and semantic definitions separate. Metric Views are added where a shared measure contract improves reuse across reporting, analytics and AI.
Governed source
Manufacturing data product
Stable grain, conformed units, history and business context.
Titan on Azure Databricks
Govern the measure
Define fields, measures, relationships and metadata in Unity Catalog Metric Views where they belong.
Governed consumers
Reuse the metric
Serve the same business logic to Databricks SQL, Power BI, analytics and Ask Titan.
Common mistakes
Keep the semantic layer small enough to trust
Metric Views become difficult to maintain when unstable data, incorrect relationships or consumer-specific logic are pushed into the shared metric contract.
Avoid
Defining measures before the source grain is stable
Better default
Stabilize the data product first
Avoid
Using measures to hide identity or unit problems
Better default
Fix conformance upstream
Avoid
Declaring join guarantees without validating the data
Better default
Test cardinality before using RELY
Avoid
Copying the same KPI back into Power BI
Better default
Consume the governed measure where the tool supports it
Avoid
Materializing every possible grouping
Better default
Materialize repeated and expensive query patterns
Avoid
Changing a shared measure without regression tests
Better default
Test known cases and review downstream impact
FAQ
Frequently asked questions
Practical answers about Databricks Metric Views for manufacturing analytics.
What is a Databricks Metric View?
A Metric View is a Unity Catalog object that defines reusable measures separately from the fields used to group and filter them. The same measure can therefore be evaluated at different query grains.
What runtime is required for Metric Views?
Basic Metric Views are supported on Databricks Runtime 16.4 and above. Individual capabilities can require later runtimes, so check feature availability before using joins, materialization, window measures or newer YAML features.
How do I query a Metric View measure?
Use the MEASURE() aggregate function around the governed measure and group by the fields needed for the analysis.
Can Metric Views use joins?
Yes. Metric Views support star and snowflake relationships. Many-to-one is the default cardinality, and any RELY guarantee should only be used when the underlying relationship is actually guaranteed.
Can Metric Views be materialized?
Yes. Metric View materialization can pre-compute aggregated or unaggregated paths and let the query optimizer rewrite eligible queries automatically. Current requirements include serverless compute and Databricks Runtime or compute 17.3 and above.
How should Power BI query Metric Views?
Current Microsoft guidance recommends the Azure Databricks connector Native query option with MEASURE() in DirectQuery mode. The former Metric View BI Compatibility Mode connector option has been removed.
Are window measures production ready?
Current Databricks documentation labels window measures Experimental. Evaluate feature maturity and runtime requirements before relying on them for critical production metrics.
Practical next step
Turn a shared KPI into a governed Metric View
Start with a manufacturing measure that already has a clear grain, owner and reconciliation rule. We can review the source model, Metric View design and consumption pattern with you.