跳到主要内容

分层与可移植定义 — 守住单一事实来源

这一章讲三件事: 无约束的分层会养出的两种病(同名不同值、循环依赖); 书的七层结构与依赖规则——尤其「指标只准依赖指标基座」这一条; 以及为什么下游定义必须写成可移植的声明式(JSON/SQL),最后经一组元数据 API 开放给 RAG 应用。 承上:03 章把实体层建好了,这一章管「实体层以上怎么长才不会歪」。

1. 顶层全景:实体层以上,怎么长​

            指标(Metrics)── 报表上的一个数
              │ 只准依赖 ↓
            指标基座(Metric Bases)── 业务逻辑只写一遍的地方
              │ 只准依赖 ↓
   语义核心(实体层,03 章)  +  维度(Dimensions)

  场景/段(Segments)、事件汇(Event Sinks)、参考表(References)挂在旁边

  图说:箭头只能朝下,永远不许朝上、也不许跨层——这就是「依赖规则」。

2. 两种病:同名不同值,与循环依赖​

这一节先看病,不看病就没法理解后面每条规矩为什么那么严。

病一:同名不同值。 数据管道是高度派生的结构:从外部源的小粒度数据出发, 经过一层层中间加工,最后变成按时间排好的汇总结果。分层本身必要, 但无约束的分层带来一个风险——逻辑重复。团队跑得快的时候,同一个指标的 不同切法,很可能落在互不相干的管道里,带着几乎相同的业务逻辑各自演化; 同一指标在不同资产里算出不同的值,可能性大增1。02 章三个「用户」的教训, 在指标层面再次上演。

病二:循环依赖。 无界分层的另一个产物:A 依赖 B,B 依赖 C,C 又回头依赖 A。 书指出,循环依赖一旦出现,连「这个指标是怎么算出来的」都解释不清—— 这件事对人成立,对 AI 同样成立2。03 章说过,实习生的第二道坎是资产目录; 循环依赖等于把目录里的一部分设成了「迷宫」。

3. 七层与依赖规则:给增长立规矩​

这一节是本章的处方。书把自家平台的层全部摊开,每层给一个「为什么存在」。

层它放什么为什么存在
语义核心03 章的实体粒度资产:回答「谁/是什么」随时间的变化;扩展属性按慢变化方式挂接权威来源;把所有权解耦,避免巨石资产,同时保住可连接性
维度静态的固定取值与映射(国家、行业、产品线),受版本治理,受控地增防止「按什么切」的表各家重复造;集中化让值变更时避免昂贵的全面重算
指标基座严格从语义核心+维度派生的聚合数据集;可复用的业务逻辑只在这里编码一次指标和分群的规范底座;把「定义逻辑」封装一次,报表间复用,阻止末端各自加工
指标报表上出现的度量:聚合或比率,不许依赖其他指标强制「语义核心→指标基座→指标」的干净血缘,定义跨报表可比、可解释
场景/段符合业务条件的实体编号清单,挂在具体指标上把增长运营要用的「人群定义」复用起来
事件汇来自记录系统的规范化事件流与事实快照数据契约的落点;保真保源,实体状态逻辑留在语义核心
参考表预测、生命周期价值、目标这类业务规则小表把原本散落的孤儿表收进轻治理,不许渗进语义核心和维度

(「维度」这个词行话里指「按什么切」的固定清单:一张国家表、一张行业表。 指标想按国家分组,就得来维度表里对号。)

书给的依赖规则只有两条,但都很硬3:语义核心资产可以互相依赖; 指标只准依赖指标基座。这两条护栏保住的是同一件东西——血缘对人和 AI 都可解释。 有了这个结构,AI 能顺着层走完整条管道:找指标去哪层、指标和分群怎么定义、 怎么用语义核心派生新资产。

4. 主走查:一个「每天活跃用户数」指标的 JSON 配方​

这一节拿书里的真实例子,把「声明式定义」从头走到尾。

书放了自家统一数据模型(UDM)风格的一份指标基座定义:按国家和分群,统计每个租户 每天有多少独立用户活跃。这个数的行话叫日活,即 Daily Active Users4。

走一遍(行里的具体取值为演示编的,下文用简称 DAU(Daily Active Users)指代它):

  第 0 步 配方声明:
    assetType = MetricBase | entity = Tenant
    输入 = 核心 TenantProfile.v2 + 扩展 TenantUsageExt.v4
           + 维度 CountryDim.v3 / SegmentDim.v5
    约束 = 不许新增实体属性 | 输出形状 = 日期+租户+国家+分群+度量

  第 1 步 读:从扩展表 TenantUsageExt.v4 取当日明细
          行:2026-07-01,租户 8f3c,用户 u1…u5,国家键 27,分群键 3   (5 行)

  第 2 步 连接(内连接,即两表编号对上号才保留这一行):
          TenantUsageExt.countryKey = 27 → CountryDim.v3 → "德国"
          行不变,每行多了一列:国家 = 德国

  第 3 步 再连接:segmentKey = 3 → SegmentDim.v5 → "中端市场"

  第 4 步 过滤:只留 2026 年的日期范围

  第 5 步 聚合:按 日期+租户+国家+分群 分组,
          dau = count_distinct(userId)   ← 「去重后的用户数」
          5 行里有 u4 出现了两次 → dau = 4,不是 5

  结果:一行输出 {2026-07-01, 8f3c, 德国, 中端市场, dau=4}

  出处顺挂:dau 这一列来自 TenantUsageExt.v4 的 userId 列——
  书把这叫列级出处,连「这个数是从哪一列算的」都可追溯。

这份配方的每个动词——读、连接、过滤、聚合——都是声明式的:说「要什么」, 不说「怎么一步步做」。书解释了为什么这很重要:声明式语言(如 SQL 或一份简单的 JSON 规范)语义完备,能完整说清一段代码干什么;过程式语言(如 Java、C#) 做不到——它你得逐行读完才能猜5。这正是对比两个指标为什么不同、 或拆解一个指标看能复用什么这两类高频用例的前提;书也不回避:就算 AI 能解释, 人仍然要能自己核验解释,而声明式让核验成本降到最低6。

「可移植」是另一半要求:同一份定义跨工具、跨存储使用,不发生语义漂移7—— 换一个查询引擎重放这份 JSON,算出的还是那个 4。

5. 把元数据开放出去:七个端点​

这一节讲最后一环:层和定义都建好了,RAG 应用怎么问。

书把本章全部元数据经一组 API(API,程序之间约定的调用入口)开放, 给了七个端点的形状8:

端点回答的问题
/taxonomy平台有哪几类资产?哪类对哪类的依赖是允许的?
/semanticEntity/{id}这个实体怎么定义?属性分什么类?(示例返回:user.core,SCD Type 2)
/dimensions/{id}这个维度的合法取值有哪些?(示例:geo.country 2025.10 版,US/DE)
/metric-bases/{id}这个指标基座用什么源?每列从哪来?(返回列级出处)
/metric-bases/{id}/definition它的可移植声明式定义全文
/assets/{id}/governance审批状态?敏感级?地域限制?(示例:approved/Confidential/限欧盟数据边界)
/assets/{id}/lineage上游下游各是谁?退役它影响谁?

书说这组端点「谈不上穷尽」,但已能支撑四类事:发现、定义查询、治理与合规、 影响分析8。

补充(不在书里,依据我们的 protocol 书架): 书这里画的还是自建 API; 今天把「上下文」递给模型的事实标准是 MCP(模型上下文协议)——它把应用控制的 上下文数据(正好是上面这些元数据)与模型控制的动作分成不同的原语(三类基础构件)暴露。 两者不冲突:MCP 是「递给模型的插座」,书里的端点是「插座后面的接线」。

依据: shelf=ai-protocol-reference/mcp-spec#03-server-primitives.md 事实=MCP 服务器(提供上下文的一端)暴露三种原语,其中 Resources 定义为「应用控制的上下文数据」。

6. 作者的判断与证据、边界​

有制度撑的: 七层是微软在用平台结构;UDM 风格的 JSON 定义与七个端点是 书里放出的真实工件形状48;「GenAI 前两份报表不一致必须解释」的制度 (03 章引过)就是这套分层的存在理由。

作为主张提出的: 「声明式优于过程式」给出的是论证,不是测量 (没有「过程式指标定义的解释耗时是声明式的 N 倍」这类数据); 「指标间禁止依赖」是书选择的强约束,行业里也有允许指标间四则运算的实践, 书没有讨论折中。

边界: 七层是大型商业平台的切法,小平台可能三层就够; 「参考表收进轻治理」依赖有一个愿意接盘的目录体系;端点只给了形状, 鉴权、限流、版本化策略一概未提。

7. 可带走的​

全章走查合起来一行: 5 行明细读入 → 两次内连接挂上「德国」「中端市场」→ 按日去重聚合得 dau=4 → 这一行数连同列级出处一起,可经 /metric-bases/{id} 和 /definition 端点被 RAG 应用查证。

  1. 团队一跑快,同名指标就会长出两套逻辑——逻辑重复是组织病,不是技术失误;
  2. 循环依赖的代价是「连怎么算的都解释不清」,对人和 AI 一视同仁;
  3. 七层的关键不是「七」,是依赖规则:指标只准依赖指标基座,不许指标依赖指标;
  4. 维度集中治理,为的是值变更时不用全面重算;
  5. 下游定义一律用声明式(SQL/JSON):说「要什么」,让语义完备、跨工具可重放;
  6. 可移植 = 换工具不漂移,同一份定义算出同一个数;
  7. 指标定义要带列级出处——「这个数从哪一列算的」也要能回答;
  8. 元数据经端点开放,四类用途:发现、定义查询、治理合规、影响分析;
  9. 自建端点之外,递给模型的插座今天可以选 MCP。

8. 原文地图​

主题原书章原文位置
逻辑重复的风险数据地基:RAG 的语义骨干text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:341(搜「duplication of logic」)
循环依赖数据地基:RAG 的语义骨干text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:343(搜「circular dependencies」)
分层总述数据地基:RAG 的语义骨干text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:345(搜「formal layers」)
语义核心层数据地基:RAG 的语义骨干text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:347(搜「Semantic Core」)
维度层三理由数据地基:RAG 的语义骨干text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:355(搜「Dimensions」) · text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:361(搜「expensive restatements」)
指标基座数据地基:RAG 的语义骨干text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:365(搜「Metric bases」)
指标不许依赖指标数据地基:RAG 的语义骨干text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:371(搜「not allowed to depend」) · text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:373(搜「clean lineage」)
场景/段、事件汇、参考表数据地基:RAG 的语义骨干text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:375(搜「Segments」) · text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:391(搜「References」)
依赖规则数据地基:RAG 的语义骨干text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:397(搜「allowed dependencies」)
对比与拆解指标两类用例数据地基:RAG 的语义骨干text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:401(搜「compare two different metrics」)
人要能核验 AI 的解释数据地基:RAG 的语义骨干text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:403(搜「time consuming」)
声明式的优势数据地基:RAG 的语义骨干text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:405(搜「Declarative」)
可移植防漂移数据地基:RAG 的语义骨干text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:407(搜「portability」)
UDM JSON 配方与逐步解读数据地基:RAG 的语义骨干text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:412(搜「udmEnvelope」) · text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:456(搜「declarative recipe」) · text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:474(搜「count distinct」)
列级出处数据地基:RAG 的语义骨干text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:476(搜「Provenance」)
七个元数据端点数据地基:RAG 的语义骨干text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:488(搜「/taxonomy」) · text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:533(搜「columnarProvenance」) · text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:564(搜「lineage」)
四类用途数据地基:RAG 的语义骨干text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:575(搜「nowhere exhaustive」)

Footnotes​

  1. 出处:「数据地基:RAG 的语义骨干」第 341 段(text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:341,搜「duplication of logic」)。 ↩

  2. 出处:「数据地基:RAG 的语义骨干」第 343 段(text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:343,搜「circular dependencies」)。 ↩

  3. 出处:「数据地基:RAG 的语义骨干」第 397 段(text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:397,搜「allowed dependencies」)。 ↩

  4. 出处:「数据地基:RAG 的语义骨干」第 409-478 段(text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:409,搜「Unified Data Model」)与(text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:456,搜「declarative recipe」)。 ↩ ↩2

  5. 出处:「数据地基:RAG 的语义骨干」第 405 段(text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:405,搜「Declarative」)。 ↩

  6. 出处:「数据地基:RAG 的语义骨干」第 403 段(text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:403,搜「time consuming」)。 ↩

  7. 出处:「数据地基:RAG 的语义骨干」第 407 段(text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:407,搜「portability」)。 ↩

  8. 出处:「数据地基:RAG 的语义骨干」第 485-575 段(text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:486,搜「suitable APIs」)与(text/05-ch02-chapter-2-data-foundations-a-semantic-backbone-f.txt:575,搜「nowhere exhaustive」)。 ↩ ↩2 ↩3