# Honeydew and Snowflake Semantic Views

URL: https://honeydew.ai/blog/honeydew-and-snowflake-semantic-views/

Last week, Snowflake announced the availability of [Semantic Views](https://docs.snowflake.com/en/user-guide/views-semantic/overview).

Let’s talk about how Semantic Views and Honeydew integrate: commonalities, differences, and how to _data mesh_ Honeydew with your Semantic Views.

![Snowflake Semantic Views and Honeydew integration](/assets/blog/honeydew-and-snowflake-semantic-views/snowflake-semantic-views-and-honeydew.png)

Lets start with,

## What is a Snowflake Semantic View?

A Semantic View is a schema-level object that:

1. Stores a single _Cortex semantic model_
2. And makes it available for AI or BI tools to consume with a special query interface.

For example, the semantic model below represents retail sales data:

- There are three connected tables (`line_items` , `orders` and `customers`) representing customers and their orders.
- There are metrics on top of them (such as `order_average_value`) to allow counting customers, orders and their properties.

```sql
CREATE SEMANTIC VIEW tpch_analysis

  TABLES (
    orders AS SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.ORDERS
      PRIMARY KEY (o_orderkey)
      WITH SYNONYMS ('sales orders')
      COMMENT = 'All orders table for the sales domain',
    customers AS SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.CUSTOMER
      PRIMARY KEY (c_custkey)
      COMMENT = 'Main table for customer data',
    line_items AS SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.LINEITEM
      PRIMARY KEY (l_orderkey, l_linenumber)
      COMMENT = 'Line items in orders'
  )

  RELATIONSHIPS (
    orders (o_custkey) REFERENCES customers,
    line_items (l_orderkey) REFERENCES orders
  )

  FACTS (
    line_items.line_item_id AS CONCAT(l_orderkey, '-', l_linenumber),
    orders.count_line_items AS COUNT(line_items.line_item_id),
    line_items.discounted_price AS l_extendedprice * (1 - l_discount)
      COMMENT = 'Extended price after discount'
  )

  DIMENSIONS (
    customers.customer_name AS customers.c_name
    customers.customer_market_segment AS customers.c_mkt_segment
    orders.order_date AS o_orderdate
      COMMENT = 'Date when the order was placed',
    orders.order_year AS YEAR(o_orderdate)
      COMMENT = 'Year when the order was placed'
  )

  METRICS (
    customers.customer_count AS COUNT(c_custkey)
      COMMENT = 'Count of number of customers',
    orders.order_average_value AS AVG(orders.o_totalprice)
      COMMENT = 'Average order value across all orders',
    orders.average_line_items_per_order AS AVG(orders.count_line_items)
      COMMENT = 'Average number of line items per order'
  )
;
```

In addition to storing the **metadata** (a _semantic model_), the Semantic View provides a way to consume that logic with a special [query language](https://docs.snowflake.com/en/user-guide/views-semantic/querying):

```sql
-- Get the average order value by market segment
SELECT * FROM SEMANTIC_VIEW(
    tpch_analysis
    DIMENSIONS customer.customer_market_segment
    METRICS orders.order_average_value
  );
```

When executing the query above, Snowflake will first join the customer and orders table, and then aggregate the `order_average_value` metric, grouped by `customer_market_segment` .

## Semantic View(s) and Honeydew

Honeydew is a Semantic Layer for AI+BI.

From a high level perspective, both Honeydew Semantic Layer and a Snowflake Semantic View appear to serve a similar task:

1. Create a single place for business logic on top of data in Snowflake
2. That consistently serves all AI and BI workloads

The core difference is **scope**: while a Semantic View is a singular schema-level object for a specific purpose, Honeydew is organization-wide layer for multiple data models and semantic views, serving diverse workloads and many semantic views.

But first, what happens if you wrap **one semantic view** in Honeydew?

## Step 1: One Semantic View in Honeydew

What a Semantic View is added as a source to Honeydew, Honeydew will extend the shared semantic layer with the Cortex Semantic Model stored in that view, and provide **all Honeydew functionality** on top of that view.

![Adding a Snowflake Semantic View as a source in Honeydew](/assets/blog/honeydew-and-snowflake-semantic-views/adding-semantic-view-as-source.png)

For example, if a Semantic View has defined a relationship between customers and orders, Honeydew will know those tables connect; if a Semantic View defines a summation metric, Honeydew will know that as well.

This has a number of use cases:

### Standard BI interface for a Semantic View

Honeydew supports a standard SQL interface and a metadata integration for many common BI tools such as Microsoft Power BI, Tableau, Looker, Domo, Quicksight and others.

![Honeydew BI tool integrations: Power BI, Tableau, Looker, Domo, Quicksight](/assets/blog/honeydew-and-snowflake-semantic-views/honeydew-bi-tool-integrations.png)

A Semantic View wrapped in Honeydew is immediately available to any BI tool for dynamic live queries. Honeydew also provides the BI tool with all the business-facing metadata (such as descriptions, folders or formatting) of the metrics and dimensions.

With dynamic live queries using standard SQL, there are no limits on what a user can do. They can ask on any level of detail of any metric with any filtering:

![image](/assets/blog/honeydew-and-snowflake-semantic-views/image.png)

Whether the BI user is aggregating across all data or is looking at the details of a specific transaction, Honeydew _will create on the fly_ a tailored and specific Snowflake query that answers the user question.

### Semantic Enrichment

Semantic Views are a relatively simple model with limited query functionality.

By using them as a source in Honeydew, that functionality can be extended:

1. To support more complex metrics (varying level of details, order of filtering, dynamic grouping, multi-fact relationships, time intelligence, etc.)
2. To support more flexibility with queries using the existing metrics defined in the view (for example allowing to mix levels of granularity in a query)
3. To support richer metadata (AI or BI-specific, such as a formatting)

**Note**: To support more enrichment, Honeydew query generation on a Semantic View model may seamlessly use Honeydew’s own semantic compiler as-required.

### Performance Optimization

Honeydew includes a set of performance features that include optimized query generation and caching. A common use case is _Aggregate Awareness_: using aggregated data in lieu of the original granular data when it matches a user query.

For example, if a user queries for total order value by customer segment, a simple query would join the a large `orders` table with `customers` and aggregate. If there are 100M orders, the query would process 100M rows.

However, with Aggregate Awareness, Honeydew can detect that there is a table with total order value already pre-computed by _customer id_. Honeydew compiler will then join to it `customers` to get the customer segment, and sum up the total order value. If there are 100,000 customers for those orders - then only 100,000 rows would need to be processed for the same response, 1000x faster.

### Explainability

The Honeydew Semantic Layer is built for collaboration and testing. As such, a number of Honeydew features can be helpful to understand a Semantic View: logic lineage, a relationship diagram, and a testing playground.

Queries generated by Honeydew are also explainable, transparently showing the particular joins or order of computation invoked. As the complexity of semantics grows, explainability becomes a key feature for maintaining correctness.

## Step 2: Many Semantic Views in Honeydew

As a singular object, Semantic Views can help to set the ownership boundaries for a single data product.

Honeydew connects data products together as sources with relationships, ownership, governance, versioning and testing, making Snowflake into a connected data mesh.

![Honeydew connects data products as a connected data mesh in Snowflake](/assets/blog/honeydew-and-snowflake-semantic-views/connected-data-mesh-in-snowflake.png)

### Semantic View as a Data Contract

Data owners can use Semantic Views to create a data contract for their delivery. Honeydew enforces those contracts, as data sources connect across teams and domains.

### Collaborative Workflow for Semantics

As the number of users that use shared semantic logic scales up, so are the **collaboration requirements**.

Consider a single DDL statement (like a Semantic View) as a single “_thing_”.

In a collaborative environment like a semantic layer there are many “_things_” to agree on. Some are data sources (a table, a view or a semantic view acting as a data contract). Some are metric calculations, entity definitions, or business metadata. “Things have inter-dependencies, are shared across different domains, and have ownerships and metadata.

Things managed in Honeydew (called semantic objects) have a lifecycle and an associated workflow:

### Semantic Object

A semantic object in Honeydew can be a data source, an entity, a relationship, a metric, a domain, or an aggregated dataset. Every object has an owner, and is backed by a Git file (using your Git provider - GitHub, GitLab, BitBucket or Azure DevOps).

As a managed object, it is part of a change management workflow:

- **Ownership**: objects can have owner
- **Versioning**: objects always have a version (backed by Git)
- **Reviews and Approvals:** when an object changes, it can go through an approval and review process before being added to the shared semantic layer

It is also a part of a shared world, with:

- **Logic Lineage**: objects can be based on other objects. For example, a profit margin metric might be based on a profit metric and a cost metric (each managed by different teams). Note that in a semantic layer lineage is for _logic_, not for _data_, which makes traditional data lineage tools inapplicable.
- **Logic Reuse**: objects can (and should!) be reused, following the DRY (”Do not repeat yourself”) principle. For example, a customer entity or a revenue metric may participate in multiple other objects, such as aggregated datasets or domains with the same definition.
- **Impact Radius**: When an object changes or breaks, it’s important to know what is logically affected to avoid downstream failures, and create a foundation that minimizes the blast radius of a change.
- **Business Interpretation**: an ability to control (with versioning and collaboration) how an object appears to different business users, AI agents or BI tools. For example, a sales team and a marketing team might have different preferred names for the same metric.

### Development Workflow

As people collaborate on shared objects, Honeydew enables a development process with:

- **Development environments**: an ability to build and test changes in isolated environments for local development, testing and production.
- **Development** **workflow automation**: an ability to add automated testing or AI evaluations for changes that go into the shared semantic layer.
- **Granular Object Security**: different objects (like metrics) might have different access control, based on user roles. While security and governance in Snowflake apply to data, Security within a semantic layer applies to the semantic objects - the metadata.

As both data sources and targets diversify, Honeydew provides metadata synchronization for the shared semantic objects from source (i.e. a dbt model or a semantic view) to target (i.e., a Tableau workbook).

## Available Now!

Honeydew support for Semantic Views as a semantic source is currently in private preview.

Interested to get access today? Reach out to [hello@honeydew.ai](mailto:hello@honeydew.ai) or [set up a demo](/get-started/).

## Links

- [Documentation](https://honeydew.ai/docs)
- [Get started](https://honeydew.ai/get-started/)
- [Pricing](https://honeydew.ai/pricing/)
- [Blog](https://honeydew.ai/blog/)
- [Home](https://honeydew.ai/)