指标定义清楚了，这一章讲平台本身的架构——各厂的分层设计高度趋同，说明这套架构已经收敛成"标准答案"。
快手指标中台定位为"数据服务层的语义层"，将底层的关系模型抽象为指标维度的语义模型（来源：快手指标中台技术分享）。整体技术架构分四层：
| 层 | 职责 | 关键组件 |
|---|---|---|
| 物理查询层 | 解决物理数据源查询，跨引擎联邦查询 | 自研统一查询引擎 Octo |
| 语义模型层 | 管理指标维度元数据计算口径，构建语义模型 | 自动化建模（基于维度建模理论） |
| 统一服务层 | 指标维度元数据服务 + 数据查询服务 + 加速层 | 指标查询服务、加速层 |
| 统一接口层 | 对接上层应用 | 数据集、指标查询 API、查询语言 OAX |
分层背后的设计思想："以指标管理驱动数据服务"——从技术语言抽象到管理语言，对外提供统一指标管理和统一指标服务。
快手把指标中台划分为两大层次（来源：快手指标中台技术分享）：
当前快手指标中台已和 BI 平台全能力打通，还对接了 AB 实验平台、经营决策系统、各业务线垂直数据系统，保证同一指标在各系统间一致——这就是"一处定义、多处使用"的落地形态。
腾讯欧拉从数据治理视角给出的架构（来源：腾讯欧拉数据自治系统），包含三个子产品：
| 子产品 | 定位 |
|---|---|
| 资产工场 | 在湖、仓、流上构建标准化数仓模型（偏数据生产） |
| 指标中台 tMetric | 基于 Headless BI 理念在数仓之上定义指标，提供统一指标服务 |
| 数据发现 | 面向数据使用方，让数据可被发现、可理解（数据地图/知识库） |
其中资产工场和指标中台是"面向数据生产"，数据发现是"面向数据消费"，治理引擎（元数据采集、扫描、发现、修复问题）贯穿其中做事后治理。
腾讯欧拉提出 Uni-Model（统一模型） 的概念（来源：腾讯欧拉数据自治系统）。数据模型分三层：
| 模型层次 | 定义 | 对应数仓工作 |
|---|---|---|
| 概念模型 | 数据范畴、业务域、主题域等业务含义和规则 | 数仓分层分域 |
| 逻辑模型 | 数据/字段之间的关系，不区分底层引擎 | 映射/转换关系 |
| 物理模型 | 基于具体引擎的数据实现 | 建表 DDL |
腾讯欧拉的核心洞察是：传统数仓只做好了物理模型，缺的是概念模型和逻辑模型的构建与管理能力——这正是导致"可理解性低、重复冗余、同名不同义"的根源（详见 01 章）。
把快手、腾讯欧拉、美团、Aloudata 的架构并排看，可以提炼出指标平台的通用分层范式：
┌─────────────────────────────────────────┐
│ 应用层：BI / 报表 / 实验平台 / 业务系统 │
├─────────────────────────────────────────┤
│ 接口层：统一 API / 查询语言（OAX 等） │
├─────────────────────────────────────────┤
│ 服务层：指标查询服务 / 元数据服务 / 加速层 │
├─────────────────────────────────────────┤
│ 语义层（核心）：指标定义 / 维度建模 / 拓扑路由 │
├─────────────────────────────────────────┤
│ 引擎层：统一查询引擎（Octo / StarRocks / …）│
├─────────────────────────────────────────┤
│ 数据层：数仓（ODS/DWD/DWS/ADS） │
└─────────────────────────────────────────┘
语义层是全架构的心脏——它是"指标"和"物理表"之间的翻译层，往下屏蔽物理数据源，往上提供统一指标接口。理解了语义层，就理解了指标平台。
本章要点回顾
上一章：03 指标体系建模方法论 ｜ 下一章：05 核心技术实现