Semantic Layer for Shared Metrics

This is really a workflow problem, not just a storage problem. The warehouse holds raw events and tables, but teams still have to decide what counts as revenue, who counts as an active user, which refunds are excluded, and what time window applies. If those rules live separately in dashboards, notebooks, and spreadsheets, each surface quietly creates its own version of the business.

• Multiple definitions appear because each tool generates or runs its own SQL. A finance analyst may build a monthly revenue spreadsheet, a product analyst may query user events in Looker, and another team may write ad hoc SQL in Snowflake. Small choices, like filters, joins, or date grain, produce different answers.
  1 sacra 2 sacra
• The warehouse alone does not fully solve this because precomputing a metric into a table locks in one grain. A table built by day cannot automatically answer by city, product line, cohort, or week without either new tables or new SQL, which recreates the inconsistency problem.
  1 sacra 4 snowflake
• That is why the semantic layer matters. It stores the business meaning of a metric separately from any one dashboard or app, so the same definition can be reused across BI tools, notebooks, chat interfaces, and planning software. Newer warehouse features like Snowflake semantic views move in this direction, but the core job is still defining and governing shared business logic.
  2 sacra 3 sacra 4 snowflake

The direction of travel is toward metrics becoming a shared service for every data consuming application. As AI, BI, and operational tools all query the same underlying data, the companies that win will be the ones that define a metric once, approve it centrally, and let every interface call that same definition instead of rebuilding it from scratch.