Move from dbt, Snowflake or Databricks
Import a MetricFlow, Snowflake semantic view, Databricks metric view, Cube or Apache Ossie file as a Proposal, read the Loss Report, and export your model back out as Ossie.
Updated
You can bring a model you already wrote. Hashi converts the file and opens a Proposal. Nothing reaches your draft until an editor approves it.
What you can import
| Tool | File | Spec read |
|---|---|---|
| dbt MetricFlow | YAML with semantic_models and metrics |
dbt 1.9 to 1.11 (measures on the semantic model) |
| Snowflake | Semantic view YAML (tables, facts, dimensions, metrics) |
Cortex Analyst semantic model |
| Databricks | Metric view YAML | version 0.1 and 1.1 |
| Cube | YAML with cubes (and views, which are dropped) |
sql_table cubes |
| Apache Ossie | Ossie YAML | 0.1.1 and 0.2.0.dev0 (a draft spec) |
Import in Studio
- Open Studio and choose Import.
- Pick the format and the file. If you have several connections, name the one the tables live on.
- Read the Loss Report. Then open Proposals, review the diff, and approve.
- Compile, check your tests, and publish.
Approving writes the files into your draft. It does not publish.
You can also call the API: POST /v1/tenants/{tenant}/model/import with {"format": "metricflow", "content": "...", "connection": "warehouse"}. The formats are ossie, metricflow, snowflake, databricks and cube.
How terms map
Hashi keeps a Measure (a raw aggregate such as sum(amount)) apart from a Metric (a named expression over measures). Other tools often call a single aggregate a metric. The importer splits it for you.
| Hashi | MetricFlow | Snowflake | Databricks | Ossie |
|---|---|---|---|---|
| Entity | semantic model | table | source and joins | dataset |
| Dimension | dimension | dimension, time dimension | dimension | field with dimension |
| Measure + Metric | measure + metric | metric | measure | metric |
| Join | foreign entity | relationship | join | relationship |
AVG(x) becomes sum(x) and count(x) with a ratio metric, because Hashi has no avg aggregation.
The Loss Report
Every import returns a list of what did not carry over.
| Severity | Meaning |
|---|---|
| Skipped | Hashi cannot keep the meaning, and importing it would change a number. It is left out. |
| Approximate | Kept, but it may behave a little differently. |
| Note | Wording or metadata was dropped. Numbers are unaffected. |
Common skipped items:
- A metric with a
filter(MetricFlow), a cumulative or conversion metric, or a semi-additive measure. - A SQL function around an aggregate, such as
ROUND(SUM(x), 2). - A Databricks window measure, or an aggregate over a joined table.
- A join or relationship on several columns.
- A dataset or cube defined by a query.
- A Cube
rolling_windowmeasure.
Fix these in the Proposal or in the source and import again. An import that skips a metric never guesses its value.
Export to Ossie
Choose Export in Studio, or call GET /v1/tenants/{tenant}/model/export?format=ossie. You get the published version as an Ossie 0.2.0.dev0 file and a Loss Report.
Ossie has no place for these, so they are not exported: policy roles (column grants and row filters), rollups, saved queries, model tests, hierarchies, segments, views, and metrics that use offset() or multi-stage leaves. Whoever loads the file must set up access control again.
Importing your own export gives back the same SQL for the part Ossie can hold.