01 · 需求背景与痛点：为什么需要指标平台

1.1 传统 BI 的演进路线

BI（商业智能）平台经历了三代演进（来源：美团技术团队）：

阶段	模式	特点	问题
第一代	以报表为核心的 ETL 驱动	数据研发开发报表，业务看报表	需求排期慢，业务依赖研发
第二代	以数据集为核心的敏捷驱动	业务用无代码 ETL 或 SQL 自建数据集、自助分析	灵活了，但乱了
第三代	以指标为核心的指标平台	唯一指标层连接数据和应用	解决"乱"，兼顾治理与效率

第二代"敏捷 BI"让数据消费者（运营、数据产品、分析师）能自己拖拽分析，不用等研发排期——但灵活性是有代价的，代价就是后面要讲的三大痛点。

1.2 数据集驱动模式的三大痛点

美团在建设初期观察到，业界自助敏捷 BI 的共性难题（来源：美团技术团队）：

1. 数据质量低：业务创建了百万级数据集，大量数据集导致口径不一致、数据混乱。
2. 查询效率低：非研发人员建的 SQL 数据集性能难以保障，数据抽取到各种分析引擎又导致查询资源浪费。
3. 可复用性差：指标、维度无法跨数据集分享，更难在不同工具、不同系统间复用。

一句话概括：数据集是"私有"的，指标是"公共"的——把公共的指标做成了私有的数据集，必然导致重复建设、口径打架。

1.3 大厂的具体痛点（多来源交叉验证）

快手：表多、指标冗余、同名不同义

快手指标中台落地前（来源：快手指标中台技术分享）：

• 数仓建了 10W+ 张数据表，每个业务线又各自建大量应用层表直接对接应用；
• AB 测试平台沉淀了 10W+ 指标，各平台之间无法确认同名指标口径是否一致；
• 导致三个"不统一"：

问题	表现
指标建设不统一	指标在各应用系统重复管理，大量冗余建设
指标口径不统一	同名不同义（同名指标各系统数据不一致）、同义不同名（同一含义指标跨系统名称不同）
管理流程不统一	不同系统指标管理流程不同，管理成本高

腾讯欧拉：治理难、维护难、使用难

腾讯欧拉总结数据治理的三个老大难（来源：腾讯欧拉数据自治系统）：

• 治理难：数据治理成果像"沙子堆的碉堡"，缺乏骨架，经不起风吹草动；
• 维护难：依赖关系错综复杂，同层依赖、跨层依赖、甚至下层依赖上层；
• 使用难：同一个"曝光次数"指标在不同地方取值不同，不知道该信哪个出口。

火山引擎（幸福里）：线下文档维护、词义混乱

幸福里（字节旗下房产平台）指标管理经历两个阶段（来源：火山引擎 DataLeap 分享）：

• 阶段一（粗放）：业务快速迭代，指标无统一规范，粗放管理，缺拆解标准和分类标准 → 一词多义、重复开发、指标冗余；
• 阶段二（精细）：业务趋稳，精细化运营，需要体系化建设、统一指标口径。

典型痛点：指标字典靠线下文档人工维护，格式不统一、更新不及时、无人统一负责；不同业务模块各维护各的指标库。

1.4 本质：数据确定性差

腾讯欧拉把这个问题抽象得很到位（来源：腾讯欧拉数据自治系统）：

数据治理的本质是打造一个对抗熵增的系统。信息熵等价于确定性——看到一份数据，如果不知道它算什么指标、有什么价值、上下游应用、占用成本，确定性就低、熵就大。

所以要从数据的可理解性、规范性、易用性、可靠性、安全性、成本几个方面提升确定性。

而美团指出的根源更直接：传统模式缺乏概念模型和逻辑模型的构建与管理能力（只有物理模型），导致"同名不同义、同义不同名、重复冗余严重、数据空间感极差，就像在图书馆找一本没有目录和描述的图书"。

1.5 核心矛盾：灵活性与治理的对立

把上面的痛点收敛成一句话，就是指标平台要解决的根本矛盾：

业务要灵活自助分析（快），企业要口径统一可治理（不乱），二者在传统 BI 模式下天然对立。

• 走"灵活"路线（数据集驱动）→ 百万数据集、口径混乱；
• 走"治理"路线（强管控、研发排期）→ 业务响应慢，回到第一代老路。

指标平台的答案就是：用统一的指标语义层，让"定义"和"使用"解耦——定义一次（治理可控），多处使用（灵活复用）。这就是下一章要讲的指标平台核心思想。

---

本章要点回顾

• 传统 BI 三代演进：报表 ETL → 数据集敏捷 → 指标平台。
• 数据集驱动三大痛点：质量低、效率低、复用差。
• 大厂共性：表多指标冗余、同名不同义/同义不同名、线下文档维护。
• 本质：数据确定性差（熵增）；根本矛盾：灵活 vs 治理。

下一章：02 指标平台概念与演进