Table of Contents
- Understanding Metric Views
- Building Metric Views
- Enhancing with AI
- Optimizing Performance and Conclusion
Introduction
Metric Views in Databricks have evolved from YAML-based definitions to a more intuitive, UI-driven experience, enhanced by AI capabilities through Genie Code and performance optimization via materialization.
Earlier, defining metrics required working directly with YAML, which, while powerful, introduced complexity in terms of syntax, debugging, and reliance on SQL.
With the introduction of the UI editor, along with Genie Code and materialization, Metric Views are evolving into a more accessible and comprehensive semantic layer within Databricks.
The following illustration provides a high-level overview of how Metric Views have evolved from YAML-based definitions to a visual UI, AI-assisted development with Genie Code, and performance optimization through Materialization.
To learn more about Metric Views, including supported capabilities, permissions, and architecture, refer to the official Databricks Metric Views documentation.
What are Metric Views?
Metric Views provide a centralized way to define business metrics and dimensions so they can be reused across queries.
• Measures define calculations (such as revenue, profit, or KPIs)
• Dimensions define how data is grouped and analyzed
This approach ensures consistency, reusability, and a single source of truth for analytical logic.
UI + YAML: Two Layers, One Definition
One of the most powerful aspects of Metric Views is the seamless synchronization between the UI and YAML.
This synchronization works in both directions:
1. UI → YAML Synchronization
Any change made in the UI, such as updating a measure, modifying a join, or adding a dimension, is instantly reflected in the YAML definition.
In this example, an average revenue measure is created in the UI, and the corresponding aggregation logic is automatically reflected in the YAML definition.
2. YAML → UI Synchronization
Similarly, when a year-based dimension is defined in YAML, it is immediately available in the UI for analysis and grouping.
This bidirectional synchronization keeps both UI and YAML in sync, allowing users to switch seamlessly between visual and code-based development.
To explore creating and managing Metric Views using both the visual UI and YAML editor, see the official Create a Metric View documentation.
When to Use the UI and YAML
Although the UI and YAML remain fully synchronized and represent the same Metric View definition, each approach is better suited to different development scenarios.
Both the UI and YAML remain fully synchronized, allowing users to start with either approach and switch seamlessly between them based on their workflow or development needs. Rather than replacing YAML, the UI complements it by providing a visual development experience while preserving the flexibility of code-based definitions.
The UI simplifies one of the most critical parts of metric modeling, defining joins between tables. Instead of writing join conditions manually, relationships can be configured visually, making the process more intuitive and reducing dependency on SQL.
Defining Joins Using UI
Metric Views allow users to define joins directly from the UI by selecting the required tables and join conditions.
In this example, a join is created between the fact table and a dimension table using a common key. This significantly reduces dependency on writing SQL joins manually, making the modeling process faster and more accessible for BI developers.
Visual Representation of Relationships
Once joins are configured, the UI provides a visual representation of relationships between tables, helping users better understand the data model.
UI to YAML Reflection
One of the key advantages of this approach is that the join logic defined in the UI is automatically translated into YAML.
This approach not only simplifies modeling but also ensures transparency, as every visual configuration is backed by an equivalent YAML definition.
Measures can be defined using the builder interface by selecting fields and applying aggregation functions. The UI also allows switching between builder and custom expression modes for flexibility without starting directly with SQL.
The builder interface is ideal for standard aggregations, while the custom expression mode provides flexibility for defining complex calculations when needed.
Preview Behavior (Important Observation)
While the UI provides preview capabilities, it is important to understand how they behave in practice.
Accessing Preview
The preview option is available directly within the UI, allowing users to quickly inspect metric outputs.
Measure Level Preview (Right Panel)
The measure-level preview provides a reliable way to validate individual measures.
• Supports grouping by dimensions
• Displays aggregated results correctly
• Useful for verifying calculation logic
Genie Code: Enhancing Metric Views with AI
Genie Code enables an AI-assisted approach to enhancing metric views using natural language. Instead of manually writing complex logic, users can describe their requirement, and Genie Code generates the corresponding metric definitions.
Generating Advanced Metrics Using Natural Language
In this example, Genie Code is used to generate a year-over-year revenue growth measure based on existing fields.
Generated Metric Definition
Based on the prompt, Genie Code automatically generates the required YAML logic, including:
• Derived date fields
• Window-based calculations
• Growth percentage logic
The generated logic can be further refined using the UI editor or YAML as needed.
Resulting Output
Once applied, the metric view includes newly generated measures , such as:
• Current year revenue
• Previous year revenue
• Year-over-year growth percentage
Important Note
• In this example, the dataset contains data for a single year, so the year-over-year growth values appear as null.
• This is expected behavior, as YoY calculations require data from multiple years for comparison.
• When applied to datasets spanning multiple years, the same logic will produce meaningful growth insights .
• While Genie Code accelerates development, the generated logic should always be reviewed to ensure correctness and performance efficiency.
To explore additional Genie Code capabilities for Metric Views, including generating measures and complete metric definitions using natural language, refer to the official Use Genie Code (inside Create a Metric View) documentation.
Materialization — Optimizing Performance
When querying a metric view without materialization, Databricks computes results directly from the underlying source tables, including all joins and aggregations.
While this approach ensures up-to-date results, it can become resource-intensive for large datasets or frequently executed queries.
Materialization addresses this by precomputing and storing metric view results for reuse. Instead of recalculating metrics each time, Databricks can leverage precomputed data to significantly reduce query execution time and improve performance for commonly used analytical workloads.
This optimization is handled automatically, allowing users to benefit from improved performance without modifying their queries.
Creating a Materialization
Materializations can be created directly from the UI, where users can view and manage existing definitions.
Defining Aggregation Logic
Materialization allows defining how data should be precomputed by selecting:
• Type (Aggregated / Unaggregated)
• Dimensions for grouping
• Measures for aggregation
Scheduling Materialization
Materializations can be scheduled to refresh at regular intervals, ensuring that precomputed data remains up to date.
YAML Representation
All materialization configurations defined in the UI are automatically reflected in the YAML definition.
Materialization enables Databricks to optimize query execution by leveraging precomputed data when available.
With materialization in place, Databricks can intelligently decide whether to use precomputed results or compute directly from source tables based on the query context, ensuring both performance and correctness.
For additional information about configuring materializations, refresh schedules, and query optimization, refer to the official Materialization for Metric Views documentation.
Conclusion
Metric Views in Databricks are evolving beyond a YAML-driven feature into a comprehensive semantic layer experience.
With the introduction of the UI editor, defining metrics has become more intuitive. The seamless synchronization with YAML ensures flexibility for advanced users, while Genie Code accelerates development by enabling AI-assisted enhancements. Materialization further strengthens this foundation by optimizing performance through precomputed results.
Together, these capabilities shift Metric Views from being just a modeling construct to a unified system for defining, managing, and optimizing business metrics within Databricks.
Tasks that once required extensive manual effort and technical expertise are now becoming more efficient, accessible, and intelligently driven.
2 Comments
