2026 年 2 月 3 日，Snowflake 正式发布了 Semantic View Autopilot（SVA）。它用 AI 从企业的查询历史中自动生成语义视图，把语义建模的时间从“数周”压缩到“数分钟”。消息一出，不少同行和客户问我们：你们怎么看？你们跟它有什么区别？中国厂商做的语义层，跟全球知名云数据平台做的语义层相比处于什么水平？
这些问题值得认真思考和回答。
我们决定写一篇完全透明的对比。不回避短板，不掩饰优势，把两条路线的技术选择、代价收益和适用场景全部摊开。
一、先回答一个前提问题：SVA 和 Aloudata CAN 是竞品吗？
严格来说，不是。
Snowflake 是云原生数据仓库。SVA 是 Snowflake 生态中的语义层功能——它只服务于 Snowflake 上的数据，为 Snowflake 的 AI 能力（Cortex Analyst、Cortex Agents）提供语义上下文。
Aloudata CAN 是独立的语义层平台（NoETL 指标平台）。它不绑定任何特定数仓，而是适配多种主流 MPP/OLAP 引擎（如 Doris、StarRocks、Hologres、Databricks 等）作为查询执行层；同时通过这些引擎的跨源连接能力，对接企业已有的各种数据湖仓。
但它们在语义层这个能力域上是可以直接对比的。而且这个对比很有意义——因为它们代表了语义层建设的两条不同的技术路线。
二、为什么全世界都在抢建语义层？
“不同系统对同一个指标给出不同数字”这个问题每个数据从业者都遇到过。但过去它只是一个“报表对不上”的麻烦，最多让 CEO 在经营会上多问两句。
现在，这个老问题正在变成一个基础设施级的系统性风险。变量是 AI Agent。
当数据消费者是人的时候，人可以“问一嘴”“确认一下”。但当 AI Agent 开始代替人做数据决策——自动归因、自动预警、自动调拨库存——它不会开会和打电话确认。口径模糊性会被 Agent 当成事实继续扩散，你很难用提示词把它补救回来。AI Agent 的规模化落地，把“语义一致性”从“有了更好”的优化项变成了“没有不行”的前提条件。
这就是为什么 Snowflake、Databricks、dbt Labs 等厂商在过去 12 个月里不约而同地把语义层提升到了战略优先级。2026 年 1 月，他们甚至联合推动了 OSI（Open Semantics Initiative）标准。这波语义层升级，背后的共识并不复杂：AI 要规模化可信落地，必须有结构化、可治理、可审计的业务语义上下文。
语义层不是一个新概念，但它正在经历一次价值重估：从 BI 分析的附属功能，下沉为整个数据基础设施的核心枢纽。
那么，语义层该如何建呢？
三、原子化建模 vs 自动化提取——两种构建路径
“发现论”：语义已经存在，只需要被提取
SVA 的核心逻辑是归纳法。它的假设是：企业的查询历史、BI 仪表盘、Tableau 文件中，已经包含了业务语义的隐式定义。SVA 的工作是用 AI 把这些隐式语义“显式化”。
具体来说，SVA 分析查询历史中重复出现的计算模式。当大量查询一致使用某组 WHERE 条件来定义“活跃用户”时，SVA 就把这个模式提炼为候选的语义定义，交给团队审核后发布。
这个过程的特征是扁平提取：
“原子化构建论”：无论语义从哪来，都要拆到最小粒度，组合使用
Aloudata CAN 的核心逻辑是演绎法。虽然目前的产品实现要求人工定义语义，但我们同样认为语义的来源可以是多元的——业务专家的显式定义、元数据解析发现、AI 辅助识别，都是有效的输入。
真正的分歧在于：语义被发现之后，应该以什么样的结构存在？
Aloudata CAN 的回答是：无论语义的来源是什么，它都必须被拆解为最小粒度的原子要素（原子指标、维度、关联关系），通过系统进行动态组合来满足分析需求。这是一种在语义的可信度和查询的灵活性之间寻找全局最优的方案。
具体来说，Aloudata CAN 在物理表之上构建三类语义对象：原子指标（最小粒度的业务度量）、维度（切片分析的属性字段）、关联关系（表之间的 Join 路径）。所有的上层分析——指标组合、筛选条件、衍生计算——都建立在这些经过验证的原子对象之上，由系统自动生成查询。
这不是“AI 定义 vs 人工定义”的差异，而是“固定模式 vs 原子化组合”的架构分歧。SVA 关注的是如何更快地获得语义定义；Aloudata CAN 关注的是语义定义获得之后，如何让它在企业级的复杂场景中可信、可组合、可治理。
深层差异分析
差异一：语义的“可组合性”
需要先澄清一点：SVA 的 Metric 并非完全不能组合。Snowflake 文档明确表明，语义视图中的 Metric 可以和兼容的 Dimension 自由组合查询（前提是维度所在的逻辑表与指标所在的逻辑表存在关联关系）。SVA 还支持 Derived Metrics——跨逻辑表组合多个 Metric 的派生指标。
但两者“可组合性”的层次不同。
SVA 的组合发生在“Metric × Dimension”层面——你可以选不同的维度来切分同一个预定义好的 Metric，也可以在查询时通过 SQL WHERE 子句做筛选。但 Metric 本身的定义是固定的聚合表达式。如果你需要切换统计周期（从“自然月”改为“近 30 天滚动窗口”）、或追加衍生计算（同比、环比、排名、占比），你需要预先将这些定义为独立的 Derived Metric 或手动编写 SQL。至于业务限定（比如只看“线上渠道”“已支付订单”），虽然可以通过 WHERE 子句实现筛选，但这只是 SQL 层面的过滤操作，不是语义层面的可治理对象——系统不会“理解”这个筛选的业务含义，也不会对它进行追溯和审计。
Aloudata CAN 的组合发生在更细的粒度——“原子指标 × 任意有关联的维度 × 任意业务限定 × 任意统计周期 × 任意衍生计算”。一个原子指标（比如“交易金额”）可以在查询时动态叠加这些要素，系统自动生成正确的 SQL——不需要预定义每种组合，也不需要人工编写 SQL。
用一个具体的例子来说明这个差异的实际影响：
“近 30 天日均交易用户数的月环比增长率”——这个指标涉及去重计数、时间窗口限定（近 30 天）、多级聚合（先日级去重再取日均）、衍生计算（月环比）。在 Aloudata CAN 中，这是四个语义要素在查询时的动态组合，无需写 SQL；系统知道如何用 Bitmap 处理精确去重上卷、如何对齐环比的时间窗口。在 SVA 中，你需要将这个完整的计算逻辑预先定义为一个独立的 Metric（通过 SQL 表达式），或者在查询历史中恰好存在这种模式让 Autopilot 提取。
这个差异在长尾复杂指标场景下会被急剧放大。SVA 的 Metric 技术上可以使用复杂 SQL 表达式（包括窗口函数），“能不能表达”不是问题——但每种业务限定、统计周期、衍生计算的组合都需要独立定义为一个 Metric。当企业的指标种类多、组合多变时，Metric 数量会快速膨胀，维护成本上升。Aloudata CAN 的原子化模型则天然避免了这个问题：组合在查询时动态发生，不需要预定义。
差异二：语义的“可信度传递”
原子化组合还带来了一个重要的附加性质：可信度是从底向上传递的。我们把它叫做“语义层的复利效应”——验证了 10 个原子指标的正确性，基于它们动态组合出的数百个派生查询自动继承可信度，因为组合过程是确定性的数学操作（叠加业务限定、切换时间窗口、计算同环比），不会引入新的语义模糊性。
从架构层面分析，SVA 的可信度更接近“逐个验证”模式：每个 Metric 是独立定义的聚合表达式，它们之间没有“原子→派生”的层级继承关系。SVA 的 Derived Metrics 可以引用其他 Metrics，但这更像跨表组合而非语义层级的可信度传递。如果有 100 个 Metric，每个都需要独立审核其正确性。（注：Snowflake 官方文档未讨论“可信度传递”这一概念，此为基于两种架构差异的分析性判断。）
未来会殊途同归吗？
我们的判断是：会在某些层面趋同，但在根本架构上不会完全合流。
趋同的方面：
第一，AI 辅助建模会成为标配。Aloudata CAN 未来也会引入 AI 来辅助原子指标的发现和建议。但是大概率我们会把 AI 发现作为“建议输入”，仍然需要人工确认后纳入原子指标体系。
第二，治理能力会互相补齐。SVA 未来大概率会增加更丰富的指标分级、审批流、变更影响分析等治理能力，因为企业级客户一定会提出这些需求。
第三，AI Agent 驱动的消费层会趋同。无论底层是 Aloudata CAN 的指标体系还是 SVA 的语义视图，上层的 AI Agent（Cortex Analyst 或 Aloudata Agent）都需要一个结构化的语义上下文来生成准确的查询。消费端的体验会越来越相似。
大概率不会趋同的方面：
第一，查询时动态组合四要素的能力是架构级别的优势。SVA 已经具备 Metric × Dimension 的组合查询能力和 Derived Metrics 的跨表组合能力，但要获得“原子指标 × 任意维度 × 任意业务限定 × 任意统计周期 × 任意衍生计算”的组合爆炸能力，需要从架构层面就把语义拆解为最小的可组合单元。这不是加一个功能就能解决的，而是整个语义模型的数据结构决定的。
第二，多平台 vs 单平台的路线分歧。Snowflake 大概率不会让 SVA 支持非 Snowflake 的数据源，因为这与其商业模式矛盾。而 Aloudata CAN 通过适配多种主流引擎并利用其跨源连接能力，天然适应中国市场异构数据环境（多引擎并存是常态）。
四、执行性能——定义好了，算得出来吗？
语义层不仅要解决“怎么定义”的问题，还要解决“算得动吗”的问题。
SVA 的查询直接由 Snowflake 引擎执行。Snowflake 自带的弹性计算和自动优化在这里发挥作用，零额外基础设施，Snowflake 用户无感使用。对于 Snowflake 生态内的中等规模场景，这是最简洁的方案。
Aloudata CAN 走了一条更重的路——自建三级智能物化加速引擎。用户声明加速对象和时效性要求，系统自动编排物化链路并持续运维，查询时自动路由到最优物化结果。三级机制覆盖明细加速（预打宽）、汇总加速（预汇总 + Bitmap 精确去重上卷）和结果加速（短路命中）。
这套机制的核心价值是解耦“定义”和“性能”——你定义指标时不需要考虑性能问题。我们已有多家大型客户在百亿级数据规模上实现了 P90 < 1s 的查询响应，日均支撑百万级 API 调用。
但需要诚实地说：这套物化机制相比 Snowflake 的一体化方案会增加运维复杂度。虽然系统自动编排，用户仍需声明加速策略、监控使用情况并决策调整。但它在最佳实践（对接数仓 DWD 层构建语义层，代持 DWS/ADS 的开发与运维）中，可以大幅降低全局的人工工作量。
五、AI 适配——Agent 该用什么语言跟数据对话？
1986 年，SQL 成为 ANSI 标准，让人类可以用结构化语言跟数据库对话。四十年后，一个新问题出现了：AI Agent 该用什么语言跟数据对话？
在 Snowflake 中，自然语言数据问答通常由 Cortex Analyst 实现：用户用自然语言提问后，Cortex Analyst 结合指定的语义视图（Semantic View）或语义模型所提供的元数据（描述、同义词、维度/事实/指标定义、关系、常用筛选器、已验证查询与指令等）生成 SQL。对于基于语义视图的查询，Cortex Analyst 在路由模式下优先生成 SELECT … FROM SEMANTIC_VIEW(...) 形式的语义化 SQL；当语义视图无法覆盖问题时，会回退到基于物理表的标准 SQL。语义视图提供了上下文帮助 LLM 生成更准确的 SQL，但最终的 SQL 仍然是 LLM 的“创作”过程。
Aloudata CAN 则是 NL → MQL → SQL。LLM 的工作被限定为“意图理解”：从用户提问中识别出指标、维度和过滤条件，输出结构化的 MQL 查询。然后由语义引擎（确定性程序，非 LLM）将 MQL 翻译为优化 SQL。这把“写代码”的开放题变成了“选指标”的选择题。搜索空间从“所有可能的 SQL”收敛到“已定义的指标和维度的组合”。核心收益是可审计性——出了问题可以精确定位是意图理解出错还是语义定义有问题。
代价是灵活性的损失：如果提问超出已定义的原子指标范围，三层架构无法回答，而两层架构的 LLM 至少可以“尝试”。
六、全域语义统一 vs 共识提取——两种治理哲学
技术路线的差异，最终会体现在治理模式上。Snowflake SVA 和 Aloudata CAN 两种方案的差异，本质上是归纳法 vs 演绎法。
Snowflake SVA（归纳法 / 共识提取）：
SVA 的逻辑是“先有数据使用，再归纳语义”。它通过聚类算法分析历史查询模式，当大量查询一致使用某个 WHERE 条件来定义“活跃用户”时，就把这个模式提炼为推荐的语义定义。团队审核后即可发布。据我们对 SVA 聚类算法的分析，当存在多种定义时，它倾向于将最常见的模式作为候选提案（注：Snowflake 官方文档未详细说明冲突裁决机制，此为基于产品逻辑的推断）。
SVA 的优势很明显：
第一，启动成本极低。不需要预先的组织共识和人工建模，直接从已有的查询历史中“发现”语义。对于 Snowflake 用户来说，几乎是零边际成本的“语义层赠品”。
第二，自然演进，反映真实的业务行为。随着查询模式变化，SVA 能自动检测并建议更新。SVA 反映的是组织真实的数据使用行为，而非理想化的治理设计。在快速变化的业务环境中，“实际在用”的口径可能更有实践价值。
第三，“先用起来，在使用中迭代”可能更符合技术采纳的规律。SVA 让企业可以快速获得一个“足够好”的语义层，在实际使用中发现问题、逐步完善，而不是在治理项目中投入半年却迟迟无法交付使用。
但 SVA 也并不是完美的：
第一，共识不等于正确。200 条查询都用同一个 WHERE 条件，可能只是大家复制粘贴了同一个有误的查询。但反过来，业务专家定义的口径也可能是错误的、过时的、或出于政治原因的妥协。归纳法和演绎法各有盲区——关键是谁的纠错机制更高效。
第二，处理合理口径差异的能力较弱。如果销售部门和财务部门对“收入”有不同但都合理的口径，据我们对 SVA 生成逻辑的分析，它倾向于将最常见的模式作为候选提案。从目前的公开文档来看，SVA 尚未提供显式的机制来表达“这两个口径都对，但适用于不同场景”。不过，这应该只是现有版本的局限，并非架构上的不可能——SVA 未来完全有可能增加对多口径并存的支持。
第三，变更管理的严谨性不足。语义视图修改后，SVA 的公开文档中未见像 Aloudata CAN 那样的“修改一个原子指标，自动分析所有下游影响”的专项变更影响分析能力（Snowflake Semantic View 有 key/关系/表达式校验能力，但这属于创建时的验证，而非变更后的影响追溯）。在合规要求高的行业，这是一个需要关注的问题。
Aloudata CAN（演绎法 / 规范先行）：
Aloudata CAN 的逻辑是“先有规范，再有数据消费”。通过人工定义原子指标作为全域唯一的语义锚点，所有派生指标、部门级口径都必须显式地挂载在原子指标之上。不同部门如果对“活跃用户”有不同理解，Aloudata CAN 不是选一个“最常用的”，而是强制要求你定义成不同的指标（比如“日活跃用户_登录口径”和“日活跃用户_交易口径”），并通过分级管控和业务属性明确哪个是企业级口径、哪个是部门级口径。
这种方式的优势在于：
第一，语义精确性有刚性保证。当两个部门对“活跃用户”有不同理解时，Aloudata CAN 强制它们成为两个不同的指标对象，这是系统级别的强制约束。在金融、医疗、政府等对数据口径有监管要求的行业，这种刚性保证是不可替代的。
第二，治理是嵌入式而非后置的。Aloudata CAN 的“定义即治理”意味着指标在被创建的那一刻就已经被纳入治理体系——分类、分级、负责人、审批流、影响分析全部内嵌。而 SVA 的治理是“先生成，再审核”，审核的质量完全取决于审核者的主观判断。
第三，变更管理有完整的血缘链条。修改一个原子指标的定义，系统能自动识别所有下游派生指标的影响。SVA 的公开文档中目前未见这种级别的专项变更影响分析能力。
但我们也要诚实面对劣势。
第一，冷启动成本高。需要业务专家和数据团队协作，逐一定义原子指标、维度、关联关系。虽然我们在落地中推行的“存量挂载 + 增量原生”策略（成熟宽表先挂载，新需求直连明细层），可以缩短这个过程，但启动成本仍然高于 SVA。
第二，对组织能力有硬性要求。全域语义统一需要组织机制。技术能解决“如何统一”，但“要不要统一”“谁来定义标准”“谁有最终裁决权”都是组织问题。很多企业选择不做全域统一，不是因为不想，而是因为组织上做不到。
第三，存在“过度治理”的风险。并非所有企业、所有场景都需要“全域语义统一”这个级别的治理。对于很多企业来说，“足够好”的语义定义是更经济的选择。Aloudata CAN 的产品设计把客户推向了一个很高的治理标准，但这个标准是否匹配客户的实际需求，是一个需要诚实评估的问题。
长期判断
现阶段看，两种方案会各有适用场景：
共识提取的方案（SVA 路线）适合口径差异痛点不突出、单一平台环境、探索性分析场景、语义治理刚起步的组织。SVA 是一个很好的“冷启动工具”。
规范先行的方案（Aloudata CAN 路线）适合口径差异痛点突出、对全域口径有显式治理需求的企业，强监管行业，多部门/多业务线组织，指标口径需要法律/合规审计的场景。这些场景不会因为 AI 技术的进步而消失——事实上，AI Agent 越普及，对底层语义精确性的要求反而越高，因为 Agent 没有人类的“常识判断”来补偿口径模糊性。
但从长期的趋势看，未来成熟的语义层产品很可能同时具备两种能力——用 AI 自动发现和建议语义定义（像 SVA），但最终纳入一套有分级、有审批、有血缘的治理体系（像 Aloudata CAN）。
七、一张表看全貌
八、不同场景下的务实选择
我们不认为存在“绝对更好”的语义层方案——只有更适合特定场景的方案。
如果你的数据已经集中在 Snowflake 上，不需要跨平台的语义统一；团队还没有建立指标治理体系，希望快速拥有一个“足够好”的语义层先用起来；业务复杂度中等，不需要大量长尾复杂指标——SVA 是一个极低成本的起步选择。“有”比“完美”重要得多，SVA 让大量原本不会做语义建模的企业开始拥有语义层，这本身就是对整个行业的贡献。
如果你的数据分散在多个引擎和系统中，需要跨平台的统一语义层；所在行业有监管合规要求，指标口径需要可审计、可追溯；需要处理大量复杂的业务指标，且希望新增分析维度时不用重新定义；正在部署 AI Agent，需要一个可信度有刚性保证的语义底座——那么原子化建模的长期价值会显著超过它的冷启动成本。
也存在一种互补的可能：先用 SVA 的方式快速生成第一版语义定义作为冷启动，再将其中需要企业级治理的核心指标迁移到原子指标体系中。这不是两个产品的官方集成路径，但在逻辑上成立。
写在最后
我们做这个对比，不仅仅是为了展示在语义层这个能力域上，中国厂商也有着深刻的技术思考和成熟的产品呈现。我们更希望这篇文章能帮助整个市场建立一个认知：语义层不是可有可无的附属功能，它正在成为数据基础设施的核心枢纽。无论你选择 SVA 还是 Aloudata CAN，或者其他任何方案，当 AI Agent 越来越多地代替人类做数据决策时，“数据是什么意思”这个问题的答案，不能再是几个不同的数字。
在 AI Agent 时代，语义层不是一个品类选择题，而是一个基础设施必答题。两条路线对比只是开始——真正的故事是：全世界的数据团队正在意识到，他们需要重新定义数据的含义。
而这个定义的精确程度，将决定 AI 能走多远。
引用索引
- Snowflake SVA 产品 GA 发布（2026-02-03）— 来源：Snowflake 官方博客
- SVA 技术文档：语义视图自动生成流程 — 来源：Snowflake Documentation
- Semantic View 架构与查询语法 — 来源：Snowflake Documentation
- HyperFRAME Research 对 SVA 自动标注准确性的分析 — 来源：HyperFRAME Research
- 三大语义层方案对比（Snowflake/Databricks/dbt）— 来源：typedef.ai
- NL2SQL 准确率参考（60%-80%）— 来源：业界公开 Benchmark（Spider、BIRD 等）
- SQL 成为 ANSI 标准（1986）— 来源：ISO/IEC 9075
