Mar 26, 2026/5 min read
If You're Serious About Data Analysis, You Need a Semantic Model
Take a real question: "What was NRR last two quarters, and what are the top churn drivers by ARR?"以一个实际问题为例：“过去两个季度的 NRR 是多少，按 ARR 计算的流失驱动因素有哪些？”
Most teams give their text-to-SQL system DDL, column comments, and a handful of sample queries. That system sees something like this:大多数团队会为他们的 Text-to-SQL 系统提供 DDL、列注释和少量示例查询。该系统看到的内容大致如下：
-- Tables available:
-- subscriptions (id, account_id, start_date, end_date, mrr, plan_type)
-- churn_events (id, account_id, churn_date, reason_code, arr_impact)
-- accounts (id, name, segment, region, csm_id)
--
-- Sample query: SELECT account_id, SUM(mrr) FROM subscriptions GROUP BY 1The system has to guess what "NRR" means — maybe (starting_mrr + expansion - contraction - churn) / starting_mrr, but over what cohort window, and which subscriptions rows count as expansion versus new business? The join between churn_events and subscriptions could easily double-count ARR, and nothing in the schema says how to avoid it. So the system guesses, and different tools guess differently.系统必须猜测“NRR”的含义——可能是 (期初 MRR + 扩张 - 收缩 - 流失) / 期初 MRR，但具体是针对哪个同期群窗口？哪些订阅行应计入扩张而非新业务？churn_events 和 subscriptions 之间的连接很容易导致 ARR 重复计算，而架构中没有任何说明如何避免这种情况。因此，系统只能进行猜测，而不同的工具猜测的结果也各不相同。
Add a semantic view, and the system sees this instead:如果加入语义视图，系统看到的就是这样：
CREATE OR REPLACE SEMANTIC VIEW revenue_metrics
TABLES (
accounts AS accounts PRIMARY KEY (id) WITH SYNONYMS ('customer'),
subscriptions AS subscriptions PRIMARY KEY (id),
churn_events AS churn_events PRIMARY KEY (id)
)
RELATIONSHIPS (
subscriptions(account_id) REFERENCES accounts,
churn_events(account_id) REFERENCES accounts
)
DIMENSIONS (
accounts.region AS accounts.region,
accounts.segment AS accounts.segment,
churn_events.reason_code AS churn_events.reason_code
)
METRICS (
net_revenue_retention AS <sql_expr> COMMENT = 'NRR over a rolling quarterly cohort',
annual_recurring_revenue AS SUM(churn_events.arr_impact) COMMENT = 'ARR impact from churn events'
)
COMMENT = 'Governed revenue and retention metrics';NRR has a definition, the relationships between tables are in the schema, and every metric specifies how it aggregates. Because semantic views live as schema objects, they become the shared contract across BI, APIs and AI workflows so that every consumer gets the same answer.NRR 有了明确的定义，表之间的关系已在架构中体现，每个指标都指定了其聚合方式。由于语义视图作为架构对象存在，它们成为了 BI、API 和 AI 工作流之间的共享契约，确保每个使用者都能得到相同的答案。
If you're running analytics at scale, using semantic models isn't optional anymore.如果你正在大规模运行分析业务，使用语义模型已不再是可选项。
The "DDL + sample queries" baseline breaks under real conditions“DDL + 示例查询”的基准方案在实际条件下会失效
Most teams start with the same bootstrap package: DDL with column comments, a few sample queries and informal conventions passed through docs or tribal knowledge. It works for demos. But it falls apart in production for four reasons:大多数团队都从同样的引导包开始：带有列注释的 DDL、少量示例查询以及通过文档或隐性知识传递的非正式约定。这在演示时没问题，但在生产环境中会因为以下四个原因而崩溃：
- Metric drift: Sample queries go stale. One team's definition of "active user" quietly diverges from another's, and nobody notices until the board deck has two conflicting numbers.指标漂移：示例查询会过时。一个团队对“活跃用户”的定义会悄然偏离另一个团队的定义，直到董事会演示文稿中出现两个相互冲突的数字时，才会被人察觉。
- Join ambiguity: When multiple plausible join paths exist between tables, small differences change the grain and the totals. A text-to-SQL system picking the wrong path silently returns a confidently wrong number.连接歧义：当表之间存在多个看似合理的连接路径时，细微的差异就会改变数据的粒度和总量。如果 Text-to-SQL 系统选择了错误的路径，它会默默地返回一个看起来很自信但却是错误的数字。
- Concept mismatch: Business questions refer to concepts such as "NRR" or "customer health score" that don't map to any single physical column. Without an explicit definition, every consumer reinvents the logic.概念不匹配：业务问题涉及“NRR”或“客户健康评分”等概念，这些概念无法映射到任何单一的物理列。如果没有明确的定义，每个使用者都会重新发明一套逻辑。
- Tool duplication: Each BI tool and each AI agent independently learns meaning from the same raw schema and reproduces it inconsistently. You end up maintaining the same business logic in Tableau, in Power BI, in your internal Python scripts and in your LLM prompts.工具重复：每个 BI 工具和每个 AI 代理都会独立地从相同的原始架构中学习含义，并以不一致的方式进行复现。最终，你不得不在 Tableau、Power BI、内部 Python 脚本和 LLM 提示词中维护同一套业务逻辑。
Semantic views address all four of these issues by moving meaning from informal convention into an executable, governed schema object. Metrics become first-class definitions. Relationships are declared explicitly. The warehouse becomes the single source of business semantics.语义视图通过将含义从非正式约定转变为可执行的、受治理的架构对象，解决了这四个问题。指标成为了“一等公民”定义。关系被明确声明。数据仓库成为了业务语义的单一事实来源。
"This sounds like a lot of up-front work"“这听起来需要大量的前期工作”
It used to be. Building a semantic model from scratch meant weeks of interviews, spreadsheets and manual YAML authoring before you saw any value.过去确实如此。从零开始构建语义模型意味着在看到任何价值之前，需要进行数周的访谈、整理电子表格和手动编写 YAML。
Semantic View Autopilot makes this practical. It generates semantic views from the logic your organization already has (query patterns, BI dashboards, trusted SQL).语义视图自动驾驶（Semantic View Autopilot）让这一切变得切实可行。它能根据你组织中已有的逻辑（查询模式、BI 仪表板、可信 SQL）生成语义视图。
The practical workflow looks like this:实用的工作流程如下：
- Pick one domain like revenue or product usage and a small set of Tier 1 metrics.选择一个领域（如收入或产品使用情况）以及一小套一级（Tier 1）指标。
- Feed Autopilot real context: trusted SQL queries, BI dashboards and historical query patterns. Autopilot uses query history, table metadata (including primary keys and cardinality) and the context you provide to validate relationships and extract business logic. When you supply SQL examples, Snowflake adds them as verified queries and infers relationships from them.为自动驾驶提供真实的上下文：可信的 SQL 查询、BI 仪表板和历史查询模式。自动驾驶利用查询历史、表元数据（包括主键和基数）以及你提供的上下文来验证关系并提取业务逻辑。当你提供 SQL 示例时，Snowflake 会将其添加为经过验证的查询，并从中推断出关系。
- Review and certify the generated semantic view. Autopilot proposes candidates when multiple definitions exist and you choose which one is canonical.审查并认证生成的语义视图。当存在多个定义时，自动驾驶会提出候选方案，由你来选择哪一个是规范定义。
- Use verified queries as a regression harness. As business rules evolve, Autopilot monitors usage and proposes updates, so the model stays aligned with how the organization actually operates.将经过验证的查询用作回归测试工具。随着业务规则的演变，自动驾驶会监控使用情况并提出更新建议，从而使模型始终与组织的实际运作方式保持一致。
The cost of creating a semantic model is no longer a reason to skip it.创建语义模型的成本不再是跳过它的理由。
Semantic views are where BI and AI converge语义视图是 BI 与 AI 融合的交汇点
BI tools have always maintained their own semantic layers: Tableau has its data model, Looker has LookML, and Power BI has DAX measures. Every tool reinvents the same definitions independently. When the warehouse itself holds the semantic layer, that duplication collapses. You define "NRR" once in a semantic view, and every downstream tool reads it.BI 工具一直都在维护各自的语义层：Tableau 有自己的数据模型，Looker 有 LookML，Power BI 有 DAX 度量。每个工具都在独立地重复发明相同的定义。当数据仓库本身承载了语义层时，这种重复就会消失。你在语义视图中定义一次“NRR”，所有下游工具都能读取它。
Open Semantic Interchange (OSI) is a standard designed to unlock semantic definitions that are portable across BI vendors and AI systems: define a metric once, and have it render correctly everywhere for tools (such as Tableau, Power BI and Sigma) that adopt the standard.开放语义交换（OSI）是一项旨在解锁语义定义的标准，使其能够在不同的 BI 供应商和 AI 系统之间移植：定义一次指标，即可在采用该标准的工具（如 Tableau、Power BI 和 Sigma）中正确呈现。
On the AI side, semantic views act as operational tools for agents. When you configure a Cortex Agent, you can attach semantic views as tools via Snowflake Cortex Analyst. The agent routes a natural-language question to the relevant semantic view, which provides the metric definitions and relationship graph needed to generate correct SQL.在 AI 方面，语义视图充当了代理的操作工具。当你配置 Cortex 代理时，可以通过 Snowflake Cortex Analyst 将语义视图作为工具附加。代理会将自然语言问题路由到相关的语义视图，该视图提供生成正确 SQL 所需的指标定义和关系图。
Semantic models are the shared interface that lets BI dashboards and AI agents operate on the same definitions. As agentic analytics becomes a primary way people interact with data, having that shared interface in place is how you keep answers reliable.语义模型是让 BI 仪表板和 AI 代理能够基于相同定义运行的共享接口。随着代理式分析成为人们与数据交互的主要方式，拥有这样一个共享接口是确保答案可靠的关键。
If you want self-serve analytics that stays governed as AI usage scales, treat your semantic model as a first-class asset. The cost of not having a semantic model should worry you.如果你希望在 AI 使用规模扩大的同时，保持自助式分析的受控状态，就请将语义模型视为一种核心资产。没有语义模型所带来的成本，才应该让你感到担忧。
