How to Build a Metric View in Databricks: A Step-by-Step Guide for Analysts

If you're working in Databricks and you're tired of repeating the same joins and recalculations across dashboards or queries, metric views are a game-changer.

As an analyst, I often found myself duplicating logic, rechecking definitions, or digging through tables just to answer simple questions. Then I discovered metric views, and everything got a lot smoother.

Metric views let you define your data logic once and reuse it across dashboards, Genie Rooms, and notebooks. They simplify maintenance, improve consistency, and save time across every project.

Here’s a simple step-by-step guide to building your first metric view, even if you’re not a data engineer.

Step 1: Understand What You’re Building

A metric view is like a curated layer that sits between your raw data and your dashboards or reporting tools. It contains:

• Source table – the main fact table you want to analyse
• Joins – to bring in relevant dimensions (like customers, products, dates)
• Dimensions – fields you want to slice by (e.g. product name, region, delivery date)
• Measures – metrics you calculate (e.g. OTIF %, total policies, average delay)

Instead of repeating this setup in every dashboard, you define it once and reuse it across multiple tools.

Measures in metric views can range from simple aggregated values (SUM, COUNT, AVG) to more advanced types like rolling windows, month-to-date (MTD), year-to-date (YTD), and growth calculations. You can also create calculated dimensions for grouping, filtering, and labelling, such as flags for weekends or mapping status codes to readable names. Joins are always left outer joins, ensuring you retain all records from your base table.

Step 2: Create the YAML File

Databricks metric views are defined using YAML. You can write this directly in your workspace using a .yaml file or in notepad and upload it yourself.

Here's the basic structure:

version: 0.1

source: your_catalog.your_schema.your_fact_table

joins:

- name: dimension_name

   source: your_catalog.your_schema.dimension_table

   on: source.key = dimension_name.key

dimensions:

- name: dimension_name

   expr: column_name_or_expression

measures:

- name: metric_name

   expr: SQL_expression

   description: What this metric measures

   format: percent/integer/decimal

You can also define more complex measures:

• Window measures for rolling time periods, such as trailing 30-day averages or day-over-day comparisons.
• Inline filtered measures for precise period-based logic like MTD, PMTD, and YoY growth.
• Embedded SQL measures when you need advanced joins or logic inside the measure itself (note: these ignore external filters).
• Metric view level filters to restrict all data in the view to a specific subset (e.g., only corporate customers).

Example:

version: 0.1

source: analytics.cpg.fact_delivery_lines

joins:

- name: customers

   source: analytics.cpg.dimension_customers

   on: source.customer_id = customers.customer_id

dimensions:

- name: customer_name

   expr: customers.customer_name

- name: delivery_month

   expr: DATE_TRUNC('month', source.delivery_date)

measures:

- name: otif_percentage

   expr: SUM(CASE WHEN delivery_status = 'OnTime' THEN 1 ELSE 0 END) / COUNT(*)

   description: On-Time In-Full delivery percentage

   format: percent

Once your YAML is written, it's time to bring it into Databricks and test it.

Step 3: Load in & Test Your Metric View

Once you’ve written your YAML:

1. In your workspace, navigate to the area you want the view to live
2. Paste in the YMAL content
3. Enter a name for your metric view
4. Click create in the top right corner

Use the metric view explorer in Databricks to preview it

Check:

• Are the joins returning the expected values?
• Are dimension names readable and business-friendly?
• Are the measures calculating correctly?

For time-based measures like YTD, make sure the date logic matches your business rules. Trailing windows use the latest date in the dataset rather than today’s system date.

You can run quick test queries or connect it to a lightweight dashboard to confirm everything works as expected.

Once it's looking good, it's time to set up a Genie Room.

Step 4: Publish and Use It

Once it’s tested, you can start using the metric view across Databricks:

• SQL Dashboards for interactive visualisations
• Genie Rooms for natural language exploration
• Notebooks for deeper analysis with consistent definitions

Any updates made to the metric view will automatically flow through all these tools, reducing rework and improving trust in your data.

Step 5: Create a GenieRoom Using Your Metric View

To create a GenieRoom:

1. Go to the Genie section in the workspace
2. Click + New in the top right
3. Select your newly created metric view
4. Configure theRoom settings:
   • Add a clear description of the data and its use case
   • Include trusted sample questions and General instructions for the how you want Genie to behave
   • Choose who can access or edit theRoom

This connects your curated data model to a natural language interface that business users can explore confidently.

Step 6: Add Descriptions, Synonyms, and Sample Questions

To make the GenieRoom even more useful, add enhancements directly into your metric view YAML:

• Descriptions explain each field in plain language
• Synonyms allow users to refer to fields using different terms (for example, "client" instead of "customer")
• Optional value dictionaries help map business terms to system values

Example:

name: delivery_date

description: Date the delivery was scheduled or occurred

synonyms: 'delivery date', 'shipment date', 'scheduled date'

In your GenieRoom settings, also add and refine:

• A helpful description of the dataset
• A list of sample questions users can try
• Any specific instructions for how to interact with the data

These make theRoom much more accessible for non-technical users.

Step 7: Test Your GenieRoom

Once your GenieRoom is set up and connected to your metric view, it’s important to test it properly to make sure it works as expected for end users. This is your chance to check that everything from synonyms to sample questions is performing correctly.

Here’s how to test it effectively:

Now test it from a user's point of view. Ask questions like:

• "What is the OTIF percentage by delivery month"
• "Show average delay by product"
• "Which customers had the most late deliveries"

Check the following:

• Are the correct fields being selected?
• Do the synonyms work?
• Are the results accurate and clearly presented?

If something doesn’t work as expected, go back to your YAML or GenieRoom settings and refine it. Ask a someone else to try it out who isn’t familiar with the underlying data. If they can find what they need without asking you for help, your setup is running correctly.

Step 8: Publish and Use It

Once it’s tested, you can start using the metric view across Databricks:

• SQL Dashboards for interactive visualisations
• Genie Rooms for natural language exploration
• Notebooks for deeper analysis with consistent definitions

Any updates made to the metric view will automatically flow through all of these tools, reducing rework and improving trust in your data.

Step 9: Build a Dashboard Using Your Metric View

Now that your metric view is ready, you can use it to build a dashboard in Databricks without writing complex SQL or redoing your calculations.

Here's how:

1. Go to the SQL Editor in Databricks
2. Write a simple query using your metric view
   For example:

SELECT
delivery_month,
customer_name,
otif_percentage
FROM
catalog.schema.metric_view_name

1. Run the query and verify the results
2. Click Run to preview the results
3. Click + Add to dashboard above the query results
4. Choose New dashboard or select one you've already made
5. Pick a visualisation type, like a bar chart or table
6. Give it a name and click Save

You can repeat this process to build out more charts, using different queries from the same metric view. You can also add filters (like month or customer) to let users explore the data. If you ever need to update a calculation, you can make the change once in the metric view and see it reflected across all connected visualisations automatically.

Because metric views centralise logic, changes to a calculation update every connected dashboard instantly and no duplicated SQL fixes needed.

Tips

• Use clear, descriptive field names such as “average_lead_time_days”
• Keep focused to one use case or business area at a time
• Write for other people who will read, explore, and build on your work
• Leverage joins to pull in only the attributes you need, avoiding unnecessary table bloat.
• Reuse logic across projects where data structures are similar, especially in industries like CPG or insurance

You don't need to be a data engineer to build a metric view. You just need to understand your data and the questions your stakeholders are asking.

With Databricks metric views, you can define trusted logic once and reuse it across dashboards, Genie Rooms, and notebooks. It’s one of the most effective ways I’ve found to deliver consistent, scalable analytics. It has made my work faster, more accurate, and much easier to maintain.

If you haven't tried them yet, now is the time.

Ready to see how metric views can work in your environment? Talk to our experts and discover how to put them into practice.