Share this article

Honeydew and Snowflake Semantic Views

David Krakov

Co-founder and CEO

Last week, Snowflake announced the availability of Semantic Views.

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

Lets start with,

What is a Snowflake Semantic View?

A Semantic View is a schema-level object that:

Stores a single Cortex semantic model
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.

CREATE SEMANTIC VIEW tpch_rev_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:

-- 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:

Create a single place for business logic on top of data in Snowflake
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.

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.

A Semantic view wrapped in Honeydew is immediately available to those tools for live queries, as well as its associated metadata.

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:

To support more complex metrics (varying level of details, order of filtering, dynamic grouping, multi-fact relationships, time intelligence, etc.)
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)
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, with significant (100x) speed-ups. **

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, a testing playground – and most importantly, explainable queries.

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.

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).