Five Things Enterprise Architects Get Wrong About Semantic Modelling — and How to Fix Them企业架构师对语义建模的五大误区——以及如何修正

I recently ran a live demo on proactive semantic modelling for over 800 data professionals across EMEA. The questions that came in during the session were some of the sharpest I’ve seen — and they pointed directly at five architectural mistakes I see teams repeat constantly.我最近在EMEA地区为800多名数据专业人士进行了一场关于主动语义建模的现场演示。会中提出的问题是我见过的最尖锐的，它们直接指向了我经常看到的五个架构错误。

This is my attempt to give those questions the long-form answer they deserved.这是我尝试给这些问题一个长篇答案的努力。

Semantic modelling has had something of a renaissance. We all surely understand that attaching semantics i.e. meaning to data greatly contributes to common understanding of that data. But, the rise of agentic AI systems has finally made the question of “what does this data actually mean?” acutely urgent in ways it wasn’t when a human was in the query loop. A human analyst can resolve ambiguity on the fly by applying their specific domain knowledge. An AI agent cannot. It will pick an interpretation, run with it, and confidently return a wrong answer or at best, an incomplete answer.语义建模正经历一次复兴。我们都清楚，为数据附加语义（即意义）极大地促进了对数据的共同理解。但随着具备代理能力的AI系统的兴起，“这些数据到底意味着什么？”这一问题变得异常紧迫，因为当人类在查询环节时并不存在这种紧迫感。人类分析师可以即时运用其特定领域知识解决歧义，而AI代理则不能。它会选择一种解释并坚持下去，最终自信地给出错误答案，或至多给出不完整的答案。

The semantic layer is how you prevent that. It’s the governed, machine-readable definition of what your data means: how metrics are calculated, how dimensions relate, what terms like “active customer” or “net revenue” mean in your specific business context. Without it, every AI system you build is working from an implicit, unverified interpretation of your data.语义层正是防止这种情况的手段。它是对数据含义的受管、机器可读的定义：度量如何计算、维度如何关联、“活跃客户”或“净收入”等术语在特定业务背景下的含义。没有语义层，所有构建的AI系统都只能基于隐式、未经验证的数据解释工作。

If we’re ever disappointed in the results of AI reasoning, it’s because we realise we’re bigger experts than AI on the topic and that we’d do a much better job. And the root cause is its lack of understanding the underlying data i.e. not having enough context.如果我们对AI推理的结果感到失望，那是因为我们意识到自己在该主题上比AI更专业，能够做得更好。而根本原因是AI缺乏对底层数据的理解，即缺乏足够的上下文。

The challenge is that building a semantic layer is not a one-time project. It’s a discipline. It’s a muscle to be built and maintained. But most organisations approach it in ways that create more fragility than they solve. Here are the five patterns I see most often — and what to do instead.挑战在于，构建语义层并非一次性项目，而是一门学科，是需要构建和维护的肌肉。但大多数组织的做法却往往导致更多脆弱性。以下是我最常见的五种模式——以及相应的改进措施。

Mistake 1: Assuming you need to start from scratch错误 1：假设必须从头开始

The question that surfaced this: “What’s the difference between pure dimensional modelling and Snowflake semantic views? Can we reverse-engineer our existing model? How do we integrate with Erwin/IBM IDA? Does SqlDBM generate dbt SQL or just the YAML?”引发此问题的提问是：“纯维度建模和Snowflake语义视图有什么区别？我们能逆向工程现有模型吗？如何与Erwin/IBM IDA集成？SqlDBM是生成dbt SQL还是仅生成YAML？”

Very obviously, every one of these questions came from teams that already have something. A dimensional model. A dbt project. A BI semantic layer. Years of business logic encoded in transformations, views, and documentation. And every question was really asking the same thing: do I have to throw this away?很明显，这些问题都来自已有一定资产的团队：维度模型、dbt项目、BI语义层、以及多年在转换、视图和文档中编码的业务逻辑。每个问题其实都在问同一个核心：我必须把这些全部丢弃吗？

The architectural reality: Your existing assets are not the problem. Fragmentation is the problem. Most enterprises have semantics in four places simultaneously — the warehouse layer (dimensional models, views), the transformation layer (dbt metric definitions, staging models), the BI layer (Power BI datasets, Tableau data sources), and tribal knowledge in spreadsheets and wikis. None of these talk to each other. When an AI agent asks a question, it hits one of these layers and ignores the others, producing an answer that is locally consistent but globally wrong.架构现实：现有资产不是问题，碎片化才是问题。大多数企业的语义分布在四个地方——仓库层（维度模型、视图）、转换层（dbt度量定义、暂存模型）、BI层（Power BI 数据集、Tableau 数据源）以及电子表格和维基中的部落知识。这些层之间互不通信。当AI代理提问时，它只会查询其中一层，忽略其他层，得到的答案在局部一致却在全局错误。

What good looks like: Rather than replacing, consolidate. Treat your existing dimensional model as the structural foundation — it already encodes entity relationships and grain definitions that are hard to rebuild. Treat your dbt models as the transformation and metric logic layer. Then build your semantic model on top of these, referencing them rather than redefining them. Use reverse-engineering capabilities where they exist to pull existing definitions into your semantic tooling, review them, and formalise them. LLM models are surprisingly good at reverse-engineering.良好做法：与其替换，不如整合。把现有的维度模型视为结构基础——它已经编码了实体关系和粒度定义，难以重建。把dbt模型视为转换和度量逻辑层。然后在此之上构建语义模型，引用而非重新定义。利用已有的逆向工程功能将现有定义导入语义工具，审查并正式化。LLM在逆向工程方面出奇地好。

The target architecture is a single semantic layer that acts as the canonical reference for all consumers — BI tools, AI agents, APIs — with your warehouse and transformation layers as implementation details beneath it, not competing semantic surfaces.目标架构是单一语义层，作为所有消费者——BI工具、AI代理、API——的规范参考；仓库层和转换层作为其下的实现细节，而不是竞争的语义表面。

The anti-pattern to avoid: Building a parallel semantic model from scratch because it feels cleaner. It will be cleaner — for about three months. Then it will diverge from the warehouse, the BI tool will still be using its own definitions, and you’ll have three semantic surfaces instead of one.需避免的反模式：从头构建平行的语义模型，因为它看起来更干净。它确实会在大约三个月内保持干净，但随后会与仓库产生分歧，BI工具仍使用自己的定义，最终出现三个语义表面而非一个。

Mistake 2: Treating semantic modelling as an engineering problem错误 2：把语义建模当作工程问题

The question that surfaced this: “Business experts hold the knowledge — is there a suitable interface for them to author and manage the semantic model, or does it always have to go through a data engineer?” And: “Are Business Glossary terms supported? Can enterprise-wide definitions be embedded?”引发此问题的提问是：“业务专家拥有知识——是否有合适的界面让他们自行编写和管理语义模型，还是必须始终通过数据工程师？”以及：“业务词汇表的术语是否受支持？能否嵌入企业范围的定义？”

These questions reveal a fundamental misconception that is extremely common: that the semantic model is the data team’s responsibility to build and maintain. It isn’t. Or rather — it can’t be, at scale.这些问题揭示了一个极其常见的根本误解：语义模型是数据团队的职责。事实并非如此，或者说在大规模时不可能。

The architectural reality: The data team has the technical capability to build a semantic model. But they don’t have the domain authority (domain knowledge) to define what “churn,” “active account,” or “net revenue” means for the business. For your business, to be precise. That authority lives with the people who make decisions based on those numbers — finance, commercial, product, operations. When the data team makes these definitions alone, they make implicit choices that the business either doesn’t know about or actively disagrees with. Those disagreements surface later, usually at the worst possible moment (on a Monday morning when the board is looking at the financial reports).架构现实：数据团队具备技术能力来构建语义模型，但缺乏定义“流失率”“活跃账户”“净收入”等业务含义的领域权威。真正的权威在于依据这些数字做决策的人员——财务、商业、产品、运营。当数据团队单独定义这些概念时，会做出业务不知情甚至反对的隐含选择。这些分歧往往在最糟糕的时刻显现（比如周一早上董事会审阅财报时）。

What good looks like: Design your semantic governance model around two distinct roles. The semantic architect (data team) is responsible for the technical structure: how dimensions and metrics are implemented, how the model connects to the warehouse, how it is tested and deployed. The semantic steward (business domain owner) is responsible for the definition: what the metric means, what its boundaries are, what edge cases are excluded, and who has authority to change it.良好做法：围绕两个明确角色设计语义治理模型。语义架构师（数据团队）负责技术结构：维度和度量的实现方式、模型与仓库的连接、测试与部署。语义管家（业务领域负责人）负责定义：度量的意义、边界、排除的边缘情况以及变更权限。

This separation requires tooling that exposes the definitional layer to non-engineers — ideally through an interface that lets a business analyst review, annotate, or propose changes to a metric definition without touching the underlying YAML or SQL. It also requires a review and approval workflow: a proposed change to a core business definition should go through the same kind of review process as a change to a financial report.这种分工需要工具向非工程师暴露定义层——理想情况下提供一个界面，让业务分析师能够审阅、注释或提议度量定义的变更，而无需触及底层YAML或SQL。同时需要审查与批准工作流：对核心业务定义的变更应经过与财务报告变更相同的审查流程。

Embedding your Business Glossary into the semantic model — rather than maintaining it as a separate documentation artifact — is the right architectural choice. It creates a single point of truth that both humans and AI systems reference, rather than a documentation layer that gradually falls behind the implementation.将业务词汇表嵌入语义模型，而不是作为独立的文档工件维护，是正确的架构选择。它创建了一个人类和AI系统共同引用的单一真相点，而不是一个逐渐落后于实现的文档层。

If you already have a Business Glossary, LLMs are also good here for reverse engineering it into elements of a semantic model.如果已有业务词汇表，LLM同样擅长将其逆向工程为语义模型的元素。

The anti-pattern to avoid: Documenting semantic definitions in Confluence or a wiki that lives next to, but separate from, the technical model. This always diverges. Documentation is written once and not maintained. The semantic model, if governed properly, is maintained because it breaks things when it’s wrong.需避免的反模式：在Confluence或维基中记录语义定义，却与技术模型分离。这样总会产生分歧。文档写一次后不再维护，而语义模型若治理得当会因错误而被迫维护。

Mistake 3: Building a monolithic central model错误 3：构建单体中心模型

The question that surfaced this: “How can decentralised teams extend a central semantic model without giving them broad access? We want a central foundation that teams can enhance with additional dimensions.”引发此问题的提问是：“去中心化的团队如何在不授予广泛访问权限的情况下扩展中心语义模型？我们想要一个中心基础，团队可以在其上添加维度。”

This is the most common architectural mistake at scale, and it comes from a reasonable instinct: you want consistency, so you build centrally. But a monolithic central semantic model becomes a bottleneck. Domain teams can’t extend it without going through the central team. The central team becomes a queue. Changes slow down. Domain teams start building their own parallel models in the BI tool or in ad-hoc SQL views, and you’re back to four competing semantic surfaces.这是规模化时最常见的架构错误，源于合理的直觉：追求一致性，于是集中构建。但单体中心语义模型会成为瓶颈。领域团队若想扩展必须经过中心团队，导致中心团队排队，变更缓慢。领域团队于是自行在BI工具或临时SQL视图中构建平行模型，回到四个竞争的语义表面。

The architectural reality: We don’t need to look far. Organisations have already adopted a decentralised data governance and we can now extend that to data semantics. The solution is a hub-and-spoke semantic architecture, modelled on how mature data mesh organisations structure ownership. The central (hub) model defines core entities and metrics that must be consistent across the organisation — customer, account, revenue, date. These definitions are owned by the platform team, versioned carefully, and changed through a governed process. Domain teams (spokes) extend this core model with their own dimensions, metrics, and relationships — but cannot modify the core definitions.架构现实：我们不必远观。组织已经采用去中心化的数据治理，现在可以将其扩展到数据语义。解决方案是枢纽‑辐射（hub‑and‑spoke）语义架构，借鉴成熟数据网格组织的所有权结构。中心（枢纽）模型定义全组织必须保持一致的核心实体和度量——客户、账户、收入、日期。这些定义由平台团队拥有，经过严格版本管理，并通过受管流程变更。领域团队（辐射）在此核心模型上扩展自己的维度、度量和关系——但不能修改核心定义。

What good looks like: Design your semantic layer with an explicit tiering model:良好做法：使用明确的分层模型设计语义层：

• Tier 1 — Core: Universal entities and metrics. Owned by the platform team. Changes require cross-functional review. Examples: Customer, Account, Revenue, Date, Employee.第1层——核心：通用实体和度量。由平台团队拥有。变更需跨职能审查。示例：客户、账户、收入、日期、员工。
• Tier 2 — Domain: Domain-specific extensions of core entities. Owned by domain teams. Changes require domain review. Examples: Marketing Campaign (extends Account), Product SKU (extends Revenue).第2层——领域：领域特定的核心实体扩展。由相应领域团队拥有。变更需领域审查。示例：营销活动（扩展自账户）、产品SKU（扩展自收入）。
• Tier 3 — Exploratory: Draft or experimental definitions. Owned by individual teams. Not used in production AI systems until promoted to Tier 2.第3层——探索：草稿或实验性定义。由单个团队拥有。未在生产AI系统中使用，直至提升至第2层。

Access control follows this tiering: domain teams have write access to Tier 2 and 3 within their domain, read access to Tier 1, and no write access to other domains’ Tier 2. This is implementable with role-based access in any modern semantic modelling tool.访问控制遵循此分层：领域团队对其所属领域的第2层和第3层拥有写权限，对第1层拥有只读权限，且对其他领域的第2层没有写权限。这可以在任何现代语义建模工具中通过基于角色的访问实现。

The critical design principle: extensions must reference core entities, not redefine them. A domain team can add attributes to the Customer entity; they cannot change what “Customer” means.关键设计原则：扩展必须引用核心实体，而非重新定义。领域团队可以为Customer实体添加属性，但不能改变“Customer”的定义。

The anti-pattern to avoid: Granting broad write access to the central model in the name of velocity. One team’s “helpful shortcut” metric definition will conflict with another team’s definition within six months, and you’ll spend weeks reconciling them.需避免的反模式：以提升速度为名授予中心模型广泛写权限。一个团队的“快捷”度量定义将在六个月内与另一个团队冲突，你将花数周时间调和它们。

Mistake 4: Not deciding where context lives错误 4：未决定上下文存放位置

The question that surfaced this: “What’s your view on providing context via Skills containing knowledge versus expanding the data model to include additional definitions and context?”引发此问题的提问是：“您如何看待通过包含知识的Skills提供上下文，还是通过扩展数据模型加入额外定义和上下文？”

This question is underrated. Most teams don’t make this architectural choice consciously — they default to whichever mechanism their AI tooling makes easiest, and they pay for it later. As AI systems mature and you have multiple agents, multiple use cases, and multiple teams building on top of your data, the question of where context lives becomes one of the most consequential architectural decisions you’ll make.这个问题常被低估。大多数团队并未有意识地做出此架构选择——他们默认使用AI工具最方便的机制，随后为此付出代价。随着AI系统成熟、出现多个代理、多个用例以及多个团队在数据之上构建时，上下文存放位置成为最具影响力的架构决策之一。

The architectural reality: There are three places context can live in an AI system: in the semantic model (structured, versioned, governed), in retrieval artifacts like skills and knowledge bases (flexible, searchable, less structured), and in system prompts (immediate, fragile, unversioned). Most teams use all three without a clear policy for which is appropriate when.架构现实：上下文在AI系统中可以存在三处：语义模型（结构化、版本化、受管），检索产物如Skills和知识库（灵活、可搜索、结构较弱），以及系统提示（即时、脆弱、未版本化）。大多数团队同时使用这三种方式，却没有明确的政策来决定何时使用哪一种。

What good looks like: Apply this decision framework:良好做法：采用以下决策框架：

The test for whether something belongs in the semantic model is: should this definition be the same regardless of which AI agent, which BI tool, or which API endpoint is asking the question? If yes, it belongs in the semantic model. If it’s context that only makes sense for a specific interaction or agent, it belongs elsewhere.判断某定义是否应放入语义模型的测试是：无论是哪位AI代理、哪款BI工具或哪个API端点提问，这一定义是否应保持一致？如果是，则放入语义模型；如果是仅对特定交互或代理有意义的上下文，则放在其他位置。

The anti-pattern to avoid: Putting business metric definitions in system prompts because it’s faster. You end up with 12 agents, each with a slightly different definition of “active customer” in their system prompt, and no centralised way to update them when the business definition changes. You will not catch this until an agent gives a materially wrong answer to a consequential question.需避免的反模式：在系统提示中放置业务度量定义，因为这样更快。结果是你会拥有12个代理，每个都有略有不同的“活跃客户”定义，且没有统一的方式在业务定义变更时更新它们。直到某个代理因错误答案导致重大后果时，你才会发现问题。

Mistake 5: Treating the semantic model as a deliverable错误 5：把语义模型当作交付物

The question that surfaced this: “If I build a semantic model on top of a table and then the table changes — will it automatically update, or will it drift?”引发此问题的提问是：“如果我在某张表上构建语义模型，然后表结构变化——模型会自动更新，还是会漂移？”

This is the question that separates teams that have actually operated a semantic model in production from teams that have only built one. The honest answer is: in most implementations, it will drift. Schema changes in the warehouse will silently break semantic model assumptions. New columns won’t automatically surface as available dimensions. Renamed fields will cause query failures in AI agents at runtime, not at build time. Business definitions will evolve without the model being updated.这是区分真正运营语义模型的团队与仅构建一次模型的团队的关键问题。诚实的答案是：在大多数实现中，它会漂移。仓库的模式变更会悄然破坏语义模型的假设。新列不会自动出现在可用维度中。字段重命名会导致AI代理在运行时查询失败，而不是在构建时。业务定义会演进而模型未同步更新。

Drift is the silent killer of semantic accuracy. And it’s almost always a process failure, not a technical one.漂移是语义准确性的无声杀手，几乎总是流程失效，而非技术故障。

The architectural reality: A semantic model in production requires the same operational discipline as any other production system. That means:架构现实：生产中的语义模型需要与其他生产系统同等的运营纪律。这意味着：

1. Schema change detection. Your CI/CD pipeline should include a step that validates the semantic model against the current warehouse schema after any schema migration. Breaking changes (renamed columns, dropped tables, type changes) should fail the pipeline and require explicit semantic model updates before deployment.模式变更检测。你的CI/CD流水线应在任何模式迁移后加入一步，验证语义模型与当前仓库模式的一致性。破坏性变更（列重命名、表删除、类型变更）应使流水线失败，并要求在部署前显式更新语义模型。
2. Semantic model testing. Every metric and dimension in your semantic model should have a test: does this metric return a non-null result for the last 30 days? Does this dimension have fewer than N% null values? Does this join return the expected grain? These tests should run on a schedule, not just at deploy time, because data changes between deployments.语义模型测试。每个度量和维度都应有测试：该度量在最近30天是否返回非空结果？该维度的空值比例是否低于N%？该连接是否返回预期粒度？这些测试应定期运行，而非仅在部署时，因为数据在部署之间会变化。
3. Definition versioning. Treat semantic model definitions like code. Use version control. Maintain a changelog. When a business definition changes, the old version should be preserved and the change should be traceable — so you can answer the question “why did this metric behave differently before and after March 1st?”定义版本化。把语义模型定义当作代码对待。使用版本控制，维护变更日志。当业务定义变更时，保留旧版本并可追溯变更——这样才能回答“为什么该度量在3月1日前后表现不同？”的问题。
4. Ownership assignment. Every entity, metric, and dimension in the semantic model should have a named owner — a human being who is responsible for its accuracy and notified when tests fail or schema changes affect it. Without named ownership, maintenance tasks fall into a collective responsibility that nobody actually takes.所有权分配。语义模型中的每个实体、度量和维度都应有明确的负责人——负责其准确性并在测试失败或模式变更影响时收到通知。没有明确所有者，维护任务会沦为无人承担的集体责任。
5. Deprecation process. Semantic models accumulate technical debt. Metrics that are no longer used, dimensions that have been superseded, definitions that reflect a business reality from two years ago — these need to be identified, communicated to consumers, and formally deprecated. An AI agent querying a deprecated metric is a liability.废弃流程。语义模型会累积技术债务。不再使用的度量、已被取代的维度、两年前的业务定义——这些都需要被识别、通知使用者并正式废弃。AI代理查询已废弃的度量将成为风险。

What good looks like: If your semantic model is in production, you should be able to answer these questions on any given day: What changed in the last 30 days? Are all tests passing? Which metrics haven’t been queried in the last 90 days? Who owns each definition? What’s the current version?良好做法：如果你的语义模型在生产中，你应能在任意一天回答以下问题：过去30天有什么变更？所有测试是否通过？哪些度量在过去90天未被查询？每个定义的负责人是谁？当前版本是什么？

If you can’t answer these, you’re not operating a semantic model — you’re hoping one is still accurate.如果你无法回答这些问题，就说明你并未真正运营语义模型——只是在寄希望它仍然准确。

The anti-pattern to avoid: Treating semantic model maintenance as a project that runs alongside a data engineering initiative, then winds down when the initiative closes. The semantic model doesn’t end. It runs forever, or it becomes a liability.需避免的反模式：把语义模型维护当作伴随数据工程项目的临时项目，项目结束后即停止维护。语义模型不会结束，它要么永续运行，要么成为负债。

Where to start从何开始

If you’re an enterprise architect looking at this list and feeling the weight of it, start here:如果你是一名企业架构师，看到这份清单感到压力山大，请从这里开始：

1. Inventory first. Before you build anything new, catalogue what you have: dimensional models, dbt metric definitions, BI semantic layers, any documented business glossary. The goal is to know where definitions currently live and which ones conflict.先进行清点。在构建新东西之前，先列出已有资产：维度模型、dbt度量定义、BI语义层、任何已记录的业务词汇表。目标是了解当前定义存放位置以及哪些定义存在冲突。
2. Define the core. Pick five to ten metrics and entities that must be consistent everywhere — the ones that, if wrong, cause real business harm. Define them once, with named owners, in a governed layer. Don’t try to model everything on day one.定义核心。挑选5到10个必须在所有地方保持一致的度量和实体——这些如果出错会导致真实业务损害的关键项。一次性只定义一次，指定负责人，放在受管层中。不要在第一天就尝试建模全部内容。
3. Choose your tooling for federability, not just power. The question isn’t which tool can build the most sophisticated semantic model. It’s which tool can be extended safely by distributed teams without centralised bottlenecks.为可联邦化选择工具，而不仅仅是看功能强大。问题不在于哪个工具能构建最复杂的语义模型，而在于哪个工具能够安全地被分布式团队扩展，而不产生中心瓶颈。
4. Build the operational wrapper from the start. Schema change detection, automated testing, and ownership assignment are not things you add later. They’re things you’ll never add if you don’t add them now.从一开始就构建运营包装。模式变更检测、自动化测试和所有权分配不是后期才加的功能——如果现在不加，后面永远也加不进去。
5. Connect to AI as a forcing function. The pressure of AI reliability is the best organisational lever for finally getting semantic governance taken seriously. Use it.把AI接入作为强制因素。AI可靠性的压力是让组织最终认真对待语义治理的最佳杠杆。善加利用。

The organisations that will build reliable AI aren’t the ones with the most sophisticated models. They’re the ones that treat semantics as infrastructure — built carefully, governed consistently, and operated like production systems.能够构建可靠AI的组织并非拥有最复杂模型的组织，而是把语义视为基础设施——精心构建、统一治理、像生产系统一样运营的组织。

The rest will spend their time debugging why the agent gave the wrong answer.其余组织将把时间花在调试为何代理给出了错误答案上。

Want to see these principles applied in a live Snowflake environment? The on-demand recording covers the practical implementation — including how SqlDBM and Snowflake Semantic Views work together to address exactly these challenges.想在真实的Snowflake环境中看到这些原则的实际应用吗？点播录像涵盖了实际实现——包括SqlDBM和Snowflake语义视图如何协同解决这些挑战。

Watch on demand → https://www.snowflake.com/en/webinars/demo/proactive-semantic-modelling-make-your-data-products-aiready-2026-05-20/点播观看 → https://www.snowflake.com/en/webinars/demo/proactive-semantic-modelling-make-your-data-products-aiready-2026-05-20/