Databricks Unity Catalog Integration
The causal, owned, and verified layer above your Unity Catalog metric definitions.
You govern your metrics in Unity Catalog. KPI Tree reads them as a source. Point KPI Tree at a Unity Catalog metric view and each measure becomes a tracked metric, with Databricks computing the value through its native MEASURE() functions so the numbers always match your lakehouse. Your semantic layer tells an agent how each metric is calculated. KPI Tree adds the layer above: how metrics drive each other with confidence levels, who owns each one as a RACI primitive, and whether the last action actually moved the number.
Read your governed metric definitions, do not rebuild them
Unity Catalog metric-view sync runs against your Databricks SQL Warehouse and turns each governed measure into a tracked metric in three steps.
Connect your SQL Warehouse
Provide your workspace host URL and the HTTP path to your SQL Warehouse, then authenticate with a personal access token or a service principal. KPI Tree validates the connection in real time before saving it. Unity Catalog metric-view sync is enabled per workspace, so this is set up with our team rather than self-served from every account.
Discover your metric views
KPI Tree lists the Unity Catalog metric views the connection can reach and reads each one with DESCRIBE TABLE EXTENDED ... AS JSON to parse its measures, dimensions, and aggregation. This needs a current Databricks SQL Warehouse, and KPI Tree returns a clear error if the warehouse cannot serve the JSON description.
Sync measures and build the layer above
Pick a metric view and each measure becomes a tracked metric, calculated by Databricks through its native MEASURE() SQL so the values match the source exactly. Optionally expand a measure into per-dimension-value breakdowns. From there, map how metrics drive each other, assign RACI ownership, and route anomalies to the person accountable for the number.
Reads Unity Catalog metric views natively
KPI Tree consumes your governed definitions rather than reimplementing them. Databricks stays the calculation engine for every synced measure, your Unity Catalog governance stays enforced, and all downstream analytics run in KPI Tree's own engine so your warehouse bill stays flat as you add metrics.
Native MEASURE() calculation
Each measure in a Unity Catalog metric view becomes a tracked metric. KPI Tree builds native MEASURE() SQL and Databricks performs the calculation, so the number in KPI Tree is the number in your lakehouse. There is no second definition to reconcile and no drift between the two.
One query per metric, off-warehouse analytics
Each metric carries a single query that aggregates to a daily series on a configurable schedule. Comparison periods, week and quarter rollups, correlations, regressions, and outlier detection all run in KPI Tree's own compute engine, so no additional queries hit your SQL Warehouse as your team explores. Cross-day rollup method, sum for flows or last for stocks, is inferred from the measure definition.
Unity Catalog governance stays enforced
KPI Tree connects through your SQL Warehouse as a read-only consumer. Unity Catalog permissions, column masks, row filters, and ACLs apply to every query it runs. Your governance model stays exactly as your team configured it, and there is no parallel permission system to maintain.
Sync your Unity Catalog metric views. Databricks does the maths.
Your Unity Catalog metric views describe your data in governed business terms, with measures expressed as MEASURE() aggregations over your lakehouse tables. KPI Tree reads them as an upstream source: it discovers the metric views the connection can reach, parses each one with DESCRIBE TABLE EXTENDED ... AS JSON, and turns every measure into a tracked metric that Databricks calculates. Definitions never drift from the warehouse because KPI Tree never re-implements the calculation. A dimension-metric option expands a measure into per-value breakdowns, for example Revenue by Region, capped per parent so a high-cardinality dimension does not create hundreds of metrics. Whichever measures you sync, each one gets the same ownership, causal context, and statistical monitoring as any other metric.
- Auto-discovers the Unity Catalog metric views the connection can reach
- Each measure becomes a metric that Databricks calculates via native MEASURE() SQL
- Aggregation, sum, average, count, first, or last, read from the measure definition
- Dimension-metric option expands a measure into per-value breakdowns, capped per parent
Map cause and effect above the definitions.
Unity Catalog governs what each metric means and how it is calculated. KPI Tree maps how they connect. Build a metric tree that shows how each operational input drives the metrics above it, up to revenue. Every driver edge is scored by proprietary ML models and statistical tests, using Pearson correlation, lagged cross-correlation, partial correlation, and Granger causality with Benjamini-Hochberg correction, so you see the relationships that survive significance testing rather than every coincidence. When a number moves, root-cause detection traces the anomaly down the tree. Assign RACI ownership to each metric so every driver has a named person accountable for it, tied to their team and manager.
- Driver edges scored by proprietary ML models and statistical tests with confidence levels
- RACI ownership assigns accountability to real people, tied to team and manager
- Root-cause detection traces anomalies down the tree automatically
- Metric definitions stay governed in Unity Catalog, unchanged
One query per metric. Nothing extra hits your warehouse.
KPI Tree runs one query per metric to aggregate your Databricks data down to a daily series, returned as Apache Arrow and cached with a configurable TTL. Comparison periods, rollups, correlations, regressions, outlier detection, and causal analysis all run in KPI Tree's compute engine, and per-metric results are cached again in the browser, so filtering, comparing, and drilling never re-hit the warehouse. Your SQL Warehouse auto-suspends between sync cycles, so you pay only for the seconds of compute each sync uses, and your bill stays flat as the number of metrics grows.
- No additional warehouse queries for comparisons, rollups, or drill-downs
- Warehouse suspends between syncs, so idle time costs nothing
- Business-model budgets and forecasts run through the same pipeline as actuals
- Configurable sync schedule per metric
Ownership, routed action, and proof it worked.
A semantic layer tells an agent the right SQL for a metric and nothing more. KPI Tree adds the layer above it. Every metric carries full RACI ownership tied to a real person, their team, and their manager. When a metric breaches its baseline, KPI Tree pushes the anomaly to the Accountable owner across Slack, email, WhatsApp, or SMS, with org-chart escalation if it is not picked up. Actions are tracked against the metric they were meant to move, and impact is verified against the statistical baseline rather than self-reported, so you can see whether the last action actually shifted the number.
- Full RACI ownership tied to a real person, their team, and their manager
- Anomalies pushed to the Accountable owner across Slack, email, WhatsApp, or SMS
- Org-chart escalation when an anomaly is not picked up
- Impact verified against the statistical baseline, not self-reported
The layer above your semantic layer
Unity Catalog is the substrate KPI Tree reads from, not something it competes with. It governs what a metric means, how it is calculated, and who can query it. KPI Tree adds the four primitives above the definition: which metric drives which, who owns each one, what action is in flight, and whether it worked.
Every source resolves onto one causal tree.
A causal layer, not just governed definitions
Unity Catalog metric views tell an agent how each metric is calculated. KPI Tree adds how metrics drive each other, as a graph where every edge carries a confidence level from nightly statistical tests, not graph-walking or a hand-written narrative. Same governed definitions, a question the semantic layer does not answer.
Ownership and routed action
A metric view has no concept of who is accountable for the number or how they hear about it. KPI Tree gives every metric full RACI ownership and pushes each anomaly to the Accountable owner in the channel they actually read, with escalation up the org chart when it is not picked up.
Proof the action moved the number
Actions are tracked against the metric they were meant to move, and impact is verified against the statistical baseline rather than self-reported. Your lakehouse can tell you the number changed. KPI Tree closes the loop and shows whether the last action is what changed it.
Related integrations. More sources that work with KPI Tree.
Common questions
What is a Unity Catalog metric view and how does KPI Tree use it?
Does KPI Tree recalculate my metrics?
What are the requirements?
How do I connect?
Is this generally available?
Can I break a measure down by dimension?
Does Unity Catalog governance stay enforced?
How does this affect Databricks costs?
How does this compare to connecting Databricks with SQL, or using dbt?
Related guides. Frameworks and metrics in depth.
Deep dives into the frameworks and metrics that work with Databricks Unity Catalog.
Semantic layer vs business context layer
A semantic layer settles what a metric is. It cannot settle how metrics drive each other, who owns them, or what happens when one moves.
How to build a metric tree
A step-by-step metric tree and KPI tree template from North Star to daily levers
Metric decomposition
Break any business metric into the components that drive it
Read your Unity Catalog metrics into KPI Tree.
Governed definitions stay in Databricks and Databricks does the maths. KPI Tree adds the causal drivers, the RACI owner, the routed alert, and the proof the number moved.
