👨🏻‍💻 作者：云器Lakehouse 产品负责人郭天琪

同一个“有效订单数”，在 BI 报表里排除了取消订单，在运营看板里又多排除了测试订单。接入 AI Agent 后，团队还要解释：它该用哪份定义，能看哪些字段，哪些数据不能返回给用户。

规则原本就分散在不同工具里，AI 的加入让维护工作又多了一份。修改一个指标，需要逐个检查报表和应用；员工调岗，要到多个系统调整权限。某个入口没有同步，可能带来一次对账失败，也可能留下不该保留的数据访问权限。

如何通过集中定义与统一访问入口，减少这种分散治理。 对使用云器的团队而言，可以把业务口径集中在 Semantic View，把访问控制与审计放在 Lakehouse 平台及应用接入流程中落实。目标是让不同入口复用已有规则，而不是每接入一个工具，就重新配置一遍。

报表工具里的计算字段、应用代码里的过滤条件、Agent 提示词里的口径说明，可能都在描述同一个指标。但它们是几份独立的实现。只要其中一份发生变化，其他实现就需要跟着更新。

业务规则与安全规则还经常混在一起。例如“排除测试订单”决定指标怎样计算，“只能看所属区域”决定用户可以访问什么。两者都可能表现为查询中的过滤条件，维护责任和验证方式却不同。把它们留在各个工具里，数据团队很难判断某个条件是业务口径，还是不能被移除的安全限制。

结果是，治理经常从一张数字不一致的报表，或一次权限异常开始。要减少这类问题，先要明确规则由谁维护、在哪里执行，再让消费端引用它们。云器的语义视图设计方法也要求先确认指标口径、分析维度和业务边界，再进入技术建模。

云器语义视图（Semantic View）是 Lakehouse 中的逻辑模型。团队可以在模型中声明业务实体与表之间的关系，定义分析维度、指标公式，并用注释说明包含条件、排除条件和统计时间口径。BI、分析应用和 Agent 实际查询同一模型后，就能复用这些定义。

例如，团队确认“有效订单数”需要同时排除取消订单和测试订单，就应将规则写入对应指标，而不是分别交给每个工具的开发者实现。如果不同部门确实需要两种口径，应分别命名、说明用途，避免一个名称对应多种算法。

集中定义之后，模型也更容易被检查。SHOW SEMANTIC METRICS 可以查看指标及其元数据，DESC EXTENDED 可以检查公式和关系。Agent 使用指标之前，有了可读取的定义，不必只根据字段名称推断它代表什么。

这种集中化有一个前提：下游真正引用了模型。独立复制的公式、导出的文件和旧快照，不会因为模型更新就自动改变。迁移时需要识别这些旁路，否则只是新增了一个治理入口，原有的分散实现仍然存在。

定义的变更过程也应可追溯。建议把模型脚本纳入版本管理，记录谁修改了什么、为什么修改，以及哪些查询需要验证。版本记录和回退流程由团队的工程实践建立，不能仅凭一个视图对象就认为变更治理已经完成。

集中口径之后，还要回答“谁可以查询”。云器支持对 Semantic View 授予和撤销 SELECT 权限，并通过 SHOW GRANTS 查看授权情况。数据团队可以按业务用途组织视图，再向相应角色开放查询权限。

Lakehouse 支持基于角色的访问控制：先给角色分配权限，再将角色授予用户。这样，权限可以围绕职责维护，减少逐个用户配置的工作。检查实际访问范围时，还要考虑用户直接获得的权限以及其他角色权限，因为这些授权会共同影响最终可访问的数据。

对象权限与数据范围需要分开设计。“可以查询销售分析视图”，不等于“只能查询华东销售数据”。原文提到的区域经理隔离场景，需要行级策略或经过验证的数据范围控制来实现。云器Lakehouse 的 Row Filter 可以按身份或角色过滤行，但当前官方文档将其标为受邀预览功能，使用前应与技术支持确认。

敏感字段则可以结合平台的动态脱敏处理：在读取时，按用户或角色决定显示原值还是脱敏值。它是绑定在数据列上的平台安全能力，不是创建 Semantic View 后自动生成的保护规则。实际接入时，应分别验证语义查询、BI 和 Agent 路径上的身份及返回结果。

身份传递是统一执行规则的条件。如果多个用户共用一个高权限连接账号，数据库识别的是连接账号，而非界面上的业务用户，无法据此自动区分每个人的数据范围。员工调岗或离职时，也应核查角色、直接授权和应用连接方式，而不只是修改一处工具设置。

面向 AI 的数据访问，可以从明确的分析任务开始收敛。订单趋势分析需要哪些指标和维度，是否必须返回客户明细，哪些字段与任务无关，都应在接入前确认。Semantic View 可以用业务模型组织这些分析对象，Agent 再通过已有指标和维度查询数据。

这比让 Agent 从大量原始表中自行挑选对象更容易检查：团队知道开放了哪些分析定义，也能核查它使用了哪个口径。不过，不在模型中提供敏感维度，并不能替代底层权限控制。Agent 使用的身份及其他工具路径仍要遵循最小必要授权，避免绕过模型访问明细。

审计需要与访问入口配套。云器Lakehouse 的作业历史和账户中心审计，可用于检查 SQL 执行、数据访问及权限变更记录。结合应用侧的请求记录，团队才能进一步追查某次 Agent 回答使用了什么查询、由哪个连接身份执行。

需要区分数据库审计与完整的用户行为审计。若应用共用服务账号，数据库记录不能直接说明是哪位业务用户发起了请求；导出后的文件流转、聊天记录和下游缓存，也需要在相应系统中管理。

涉及监管或内部合规要求时，敏感信息识别、保留与删除策略仍要在数据存储和应用流程中落实。语义层能提供可检查的分析入口，但不能单独承担全部数据生命周期管理，也不意味着企业已经满足了所有合规要求。

治理做得过于分散，业务用户往往不知道哪个指标可信；限制过于粗放，又会让每次分析都回到数据团队排队。语义层提供了一种更容易使用的入口：用户选择业务指标，底层沿用团队确认的公式和关系。

例如，“有效订单数”的名称和注释可以直接说明排除了哪些订单、按什么时间统计。业务用户不必先读懂所有物理表，Agent 也可以先读取这些定义，再解释查询结果。模型信息可以通过发现命令查看；在具体报表或对话界面中怎样呈现，还需要接入端配合。

查询便利与安全控制并不冲突。业务方在已授权范围内使用熟悉的概念，数据与安全团队维护口径和访问规则。规则集中后，新建报表可以引用已有指标，不必把计算逻辑和权限判断一起复制过去。

当然，同一个指标在不同授权范围下出现不同结果，可能是正常现象。区域经理只能看到本区域数据，总部查看全部区域时，合计自然不同。展示结果时说明统计范围，才能避免把权限差异误认为口径错误。

原文将治理规则纳入开发、评审和测试流程。使用云器时，也可以围绕 Semantic View 定义脚本、平台授权配置及数据安全策略建立相应流程，而不是等模型上线后再补权限。

建模前，数据负责人和业务方先确认指标用途、口径与分析范围，安全负责人确认数据开放边界。开发时，将经过确认的内容写入模型及相应安全配置。SHOW CREATE SEMANTIC VIEW 可用于检查现有定义，结构修改可通CREATE OR REPLACE 完成；需要追溯的脚本和审批记录则由团队统一维护。

评审不能只看 SQL 是否能执行。一个指标新增维度后，是否扩大了可分析范围？一项过滤条件被删除后，是正常口径调整，还是移除了安全约束？这些问题需要业务和安全视角一起判断。

测试也要覆盖“不能做什么”。除了核对指标结果，还应使用不同身份检查未授权访问是否被拒绝，验证适用的脱敏和行过滤结果，并测试 用户权限变化后的实际表现。已导出的文件或缓存结果，不会随着权限回收而自动消失，需要另行处置。

发布后，结合授权检查与平台审计定期复核。集中模型定义、按角色维护权限，再用测试和审计确认规则生效，才能减少工具增加时的重复配置。这是一套需要持续维护的流程，Semantic View 和平台安全能力分别承担其中的不同部分。

对数据总监来说，集中治理的价值首先体现在维护方式上。新增一个分析入口时，团队可以先检查是否已有可复用的指标、角色和安全策略，再处理接入差异；口径变化时，也有明确的定义来源和受影响范围可查。

对架构与工程负责人，模型定义减少了重复实现业务逻辑的需要。对安全负责人，统一的数据访问入口与平台审计更便于检查规则是否一致执行。新的 BI 工具或 Agent 仍需验证身份和访问路径，但不必把所有业务规则从头整理一遍。

评估云器语义视图，可以先选择一个已有口径分歧、又涉及权限控制的分析主题。整理现有报表和查询，区分业务规则与安全规则，建立模型，再用两个消费入口和不同权限身份验证。重点检查：数字是否沿用同一口径，访问范围是否符合预期，规则变更是否能被追踪。

如果你的团队正准备接入数据分析 Agent，可以带上这组报表、指标定义和权限需求，与云器团队一起评估。先把一个主题中的重复配置和访问遗漏处理清楚，再逐步扩展到其他分析场景。

Q1:语义层如何帮助非技术用户使用数据？

它将物理表、字段和关联逻辑组织为业务指标与维度。用户可以通过接入的 BI 或 Agent 使用这些概念，模型定义提供计算依据和口径说明，实际查询仍需遵守访问权限。

Q2:语义层与数据层有什么区别？

数据层负责存储和处理数据，并执行相应的数据安全策略；语义层定义分析时使用的业务含义、指标和关系。云器语义视图 是建立在 Lakehouse 上的逻辑模型，不能替代底层数据质量、安全及生命周期管理。

Q3:集中语义与治理规则，能带来哪些收益？

实际引用同一模型的应用可以复用业务定义，减少口径漂移和重复维护。配合角色授权、适用的数据安全策略以及测试和审计流程，团队也更容易核查访问边界。收益取决于接入范围，旁路访问和工具中的独立副本仍需管理。

[1] 云器官方文档：语义视图设计方法

https://www.yunqi.tech/documents/semantic-view-design

[2] 云器官方文档：管理语义视图

https://www.yunqi.tech/documents/semantic-view-manage

[3] 云器官方文档：访问控制概览

https://www.yunqi.tech/documents/access-control-general

[4] 云器官方文档：行级安全（受邀预览）

https://www.yunqi.tech/documents/row-filter

[5] 云器官方文档：列级安全与动态脱敏

https://www.yunqi.tech/documents/dynamic-mask

[6] 云器官方文档：安全合规审计指南

https://www.yunqi.tech/documents/security_compliance_audit_guide

[7] 云器官方文档：语义视图与 AI 功能集成

https://www.yunqi.tech/documents/semantic-view-ai