本文将分享京东零售在指标中台建设方面的实践经验。京东指标中台依据现代数据栈、Headless BI、数据虚拟化和数据编织等方法论，并结合自身了多运营模式，多运营视角，多数据维度等业务特点，构建了从指标定义到指标生产再到指标消费的全链路解决方案。指标中台技术不仅仅是一个技术实现，更是一种组织和管理数据的战略思维。指标中台技术是企业在数字化转型过程中的一种重要策略，它通过构建共享平台来整合企业的核心能力，从而提升业务效率和市场响应速度。随着技术的发展和市场的变化，中台技术将继续演进，为企业带来更多的创新和价值。
一、背景介绍
首先来介绍一下京东指标中台建设的背景。
1. 背景介绍-问题定义
在建设指标中台之前，公司内部已经存在指标系统、指标平台或者类似的产品的，但都可以归为"指标登记/注册系统"，这类系统会通常提供指标查找，注册等功能，希望可以达到指标的统一维护，一处注册，多处使用的效果，但因为本身的定位和架构设计等问题，逐渐都以失败告终。这类系统通常会有以下几类问题：
（1）查找难
指标难找的根源是定义的不够清晰和准确。“指标登记系统”在找指标的时候，往往只能通过一些关键字，例如“交易额”、“交易量”，来进行搜索，会得到很多“相近”的结果，很难定位到最终想要的结果。存在很多“同名不同义”或“同义不同名”的指标。
其次，即使可以找到，是否敢用？登记性质的指标系统，指标定义和指标生产的割裂的，指标的质量很难保证，指标的维护和治理都依赖"自上而下"的运动式的治理。用户很难知道指标的确切口径，以及是否是最新的，于是很可能不得不创建一个相似的指标为自己所用，因此慢慢的，这类系统最后都逐渐被淘汰了。
（2）定义难
我们认为指标的定义过程，是一个将业务中的自然语言进行结构化的过程，进行拆解的过程。之前的指标系统，往往没有很明确的定义规范，有的虽然也是基于原子指标+衍生指标来定义，但定义的过程往往还是通过“非结构化”的自然语言来进行，这样很难准确的表意；基于上述问题，可能还会成立诸如"资产小组"的组织，来协助指标定义，这样做确实能比较有效的提升指标的质量，但这完全就依赖于个人经验，"知识"并没有沉淀在系统中，势必会带来诸如"人力短缺"以及"指标质量不稳定"等问题。
（3）开发难
早期的指标系统往往都不具备指标开发的功能，指标开发流程仍然是传统的数据加工+数据服务开发+指标展示层开发，指标的开发和定义是完全割裂的。指标的质量完全取决于个人能力，开发过程中有多少中间表，有没有不必要的浪费，完全不可控；而且口径可能散落在这个过程中的各个环境，比如一个过滤条件，既可以在数据开发时的 spark 里做，也可能上提到指标服务 Java 中做，甚至在数据展示中进行，这样对口径的还原难度很大。我们就有发生过，两个数据产品对口径对一个月都对不齐的案例。对于口径有变更，或者新功能开发，难度都很大。
（4）使用难
由于没有统一的查询语言，每个指标的调用方式都取决于开发团队，因此一个指标想复用到另一个系统上就涉及重复开发，比如为大屏开发的指标，BI 报表想复用，是无法直接复用的，需要进行改造。
2. 背景介绍-解决思路
面对上述问题，我们把业务目标定义为以下五点：
- 首先要有一个清晰的指标目录，这个指标目录里要能很便捷很准确地找到需要的指标，好用且敢用。
- 第二，指标定义一定要清晰，既可以保证区分度，又要保证精确度，避免指标二义性的问题。
- 第三，要有比较强大的指标生产能力，通过指标的定义来驱动指标生产，系统可以解决的问题一定要系统来解决，尽量减少人工参与。在性能上，可以满足业务需要，能从全局考虑数据加速的问题。
- 第四，指标消费有统一的查询语句，与最终的展示层无关，即 headless BI 的概念。
- 最后是指标治理，保证指标口径永远都是最新的，从开始加工到最后展示这条链路中，如果发现有低频使用，那么从数据到服务到指标应用都要有相应的指标退出机制，从而释放整条数据链路上的资源。
3. 定义用户
指标中台是服务哪些用户的：
- 业务师，分析师
主要诉求是能够清晰地获取指标，不太关注指标的实现过程。对应能力就是清晰的指标目录。 - 数据产品，资产产品
负责定义指标。对应能力为指标定义。 - 数据、服务开发
负责指标生产，准确地实现指标口径。对应能力为指标开发。 - 数据消费
准确的消费数据，实现业务诉求。对应能力为指标消费。
二、指标中台建设
1. 整体架构
虚线以内的都是指标中台的范围，从左往右看，首先是用户交互的部分，用户可以在"指标市场"中检索想要的指标，还可以进行指标定义，指标的定义依赖指标语义层的建设。语义层包括 4W1H，指标，维度，修饰等概念和规范，下面会详细介绍。中间是一整套数据链路，从数据生产到数据查询，都可以通过系统化进行配置，大大减少了人力投入。最右侧是元数据，包括配置信息，语义信息等，为数据的生产，查询，治理提供依据。下面将会展开详细介绍。
2. 语义层建设
关于语义层应该建设在哪里，业界大致有三种方案，分别是在模型层，展示层，或者独立一层。随着近年来的发展和迭代，大家发现将语义层耦合在模型层或者展示层都是有明显弊端的。如果语义层建设在模型层，那势必跟业务耦合得太紧。数仓产出的结果应该是一个个“积木”，可以根据业务需要进行组合，而不应该与上层业务耦合，否则随着业务的成长，数仓的数据将会爆炸。另外一个更重要的原因，如果语义层放在数仓，生产血缘可以很容易的进行构建，通过调度系统就知道数据整个的加工链路，但是消费血缘将是缺失的，不知道指标数据该如何使用。反过来，如果与展示层耦合得比较紧，那么只能回答消费血缘，而不知道指标数据是如何加工的。
所以最合适的一种方式是语义层要有一个独立的建设，对下要屏蔽业务，对上要屏蔽数据模型的概念。但这样做的缺点就是对语义的制定规范会比较难，但考虑到其收益，现在也是业界普遍认可的一种方式。
上面提到过，我们认为定义指标的过程，就是将业务的"自然语言"结构化拆解的过程。而拆解规则设计得越好，指标定义的就越准确，既能保证区分度，也能保证精确度。这里的核心概念就是 4W1H，即 4 个 W 开头的单词，和一个 H 开头的单词，分别回答作用范围，领域，动作，作用在谁身上，以及如何量化的问题，回答好了这几个问题，一个原子指标就定义好了。
基于原子指标，结合业务限定和函数就可以得到衍生指标，这是用户最常用的指标类型。业务限定简单点说就是数据的过滤条件，SQL 中的 where 语句。业务限定有两个子类型，一类叫做修饰，它由维度操作符和维值组成，比如部门 id = 1 或者成交 flag = 0 的。另一个是“裁剪口径”，“裁剪口径”是一些列修饰的集合。我们发现，大部分用户在定义指标时，都是参考某些核心指标来定义的，比如保证和零售大盘成交金额的业务限定保持一致，而核心指标上有很多修饰，如果一个一个添加，操作起来是很麻烦的；而且一旦这个核心指标的口径有变化，用户定义的这新指标是很难感知到的，因此，我们在修饰的基础上封装了”裁剪口径“，这样在指标定义时不仅可以通过选择和核心指标一致的“裁剪口径”，就能很轻易的就能和其保持口径对齐，如果口径有更改，还可以第一时间知道。
通过上图的示例可以看到是如何通过 4W1H 来定义一个原子指标的。再加上裁剪口径，就可以得到衍生指标。另外，我们通过函数来定义时间周期和指标的二次聚合，比如近 7 天，近半年，年至今等时间函数，和均值，累计值，最值等二次聚合。
在衍生指标的基础上进行四则运算得出的新指标，适合定义各种比率比值，可以得到复合指标。
以上介绍了指标定义和体系建成的过程，而实际使用过程中还是会遇到很多问题。这里介绍其中一些关键问题。
首先，在推广 4W1H 这一核心理念时，有些用户不太理解，觉得又是在造轮子。我们经过了很详细地推演，证明这套策略可以覆盖绝大部分指标定义过程，并在小范围进行实验性落地后，才开始大范围推进推广。经过一年，用户也慢慢发现这套体系真的能够帮助其提效，能做到多方共赢，最终逐渐走向正轨。
4W1H 的内容怎么选也是很重要的，现在业务域主题有 40 个，业务过程和主题上百个，对缺乏经验的用户来说，很难从中做出选择。比如成交购买用户数，其中主体是用户，度量是数量。在最初还没有口径继承能力时，业务方要建一个时尚业务域的成交购买用户数，主体选择了“购买_用户”，度量是“人数”，也不能说他定义的就是不对的，但基于此，在系统中就很难匹配出这两个指标是存在关系的。这里存在一定的灵活性和不确定性，如果以这种方式建立下去，就会出现相似指标太多的情况。因此我们采用了主动治理和被动治理的方式来解决该问题。主动治理是由系统推荐一些最佳实践，比如被使用最多的，有其他核心产品的信用背书的等等，主动帮助用户进行选择，减少出错的可能。被动处理是在后台分析合理性，并进行总结经验，推动用户进行治理。经过以上的优化，用户定义指标的准确率得到了显著提高。
第三个问题和第二个类似，是一个更加细化的问题。4w1h 的有些概念，是可以搭配使用的，比如广告主题下的流量-页面，以及点击-坑位，这种搭配是需要业务常识的，如果不知道，就可能选择点击-页面这个组合，看起来也没错，但并不专业，容易出现二义性。我们在工作中，也在逐步收集用户的数据进行分析，并和有经验的同事来共同制定相关标准。
最后，由于注册流程比较冗长，很多审批需要人工完成。我们也结合了上面主动治理和被动治理的方式，在指标定义过程中，如果满足一些条件，就会简化审批流程。
3. 指标生产
下面介绍指标生产。传统的指标生产，服务研发和数据研发基于约定进行开发，当一个需求出现后，服务研发主导和数据研发主导的解决思路是不一样的。如果是数据研发主导，比如某个需求要做三个看板，可能就开发三个对应的模型，如果性能不好，可以再做预计算，预关联。如果是服务研发，会分析需求中这三张表是否有一些共用的信息，是不是可以只用一张表。两方都是从自己的角度出发来进行设计。实际采用哪种方式，哪种方式是相对更优的，就完全取决于研发的个人能力以及整个团队的能力，并没有一个绝对的评判标准。所以我们希望通过系统来替代人工的开发，来屏蔽掉这种不确定性。
下面介绍配置化生产的工作过程。比如配置一个类似于成交金额的订单金额，首先要设置好物理表，把这个指标所需要的维度和修饰都定义好，系统可以自动翻译出来一个 SQL 查询语句，对应的指标，维度和修饰都可以体现在 SQL 上面。
如果维度是来自于维表，可以进行关联维表的配置。
再复杂一些的情况，明细数据的粒度很细，按某些维度看是有重复数据，比一个订单有多条记录，那么就要按订单 ID 或者 sku_id 先做去重，之后再做聚合。这里可以进行二次聚合的配置。
上述是指标口径的配置。对于在线查询的要求，性能上还达不到，需要将数据加速到 OLAP 存储引擎中，因此这里需要配置加速策略。我们当前支持介质加速、轻聚合、预计算，以及智能加速。支持 ClickHouse、HBase、Redis 等多种数据源。配置完调度任务后，系统会自动翻译成执行语句并生成加工任务，把事实表和维表按配置好的加速类型推到相应的计算引擎里面。
指标生产，其模型需要符合维度建模规范。创建模型时，我们希望指标的口径全部通过维度来区分，通过修饰来实现，而不是直接把维度打到每个字段里。如果这样做，一是无法进行灵活的分析，后续也没有任何优化的可能性。
下面我们从整体上看看系统提供的数据加速能力。业界著名的 F1Query SQL 优化引擎，在查询优化上非常优秀，但该优化只停留在查询范畴上，可能会出现性能断崖，因为物理上的极限是无法突破的，而且不可能保证稳定的快。而我们会分别从查询和生产两方面进行加速，查询需要什么样的加速数据，生产就进行该数据的生产，两者相互配合，理论上是可以做到所有的查询都是 O（1） 的时间复杂度。而且和传统的预计算相比，我们的数据加速摆脱了盲目性，会根据需要进行按需加速，低频退化，在成本上也尽量做到极致。
下面介绍查询加速策略。
首先是合并查询，其核心思想是尽量减少查询次数，比如两个同源查询，可以通过把这些过滤条件放到指标中，通过 case when 来解决。对于非同源查询，可以通过 union all 的方式来合并。
另一种加速方式是谓词上拉。在 ClickHouse 中使用 arrayJoin，可能会出现性能急剧下降的情况。如果放到 prewhere 里做，就可以减少很多扫描的数据，查询的性能可以得到大幅提升。
属性拼接也是一种很有效果的优化。我们发现有很多维度，是没有对其进行分析的诉求的，只是为了和其他维度一起展示使用，比如 sku 颜色，sku 尺寸等，通常只是展示 sku 信息时才会用到，很少有对其进行分析的场景。在查询时，如果按 sku 的粒度进行分析，需要在 groupby 中加上 sku 颜色，sku 尺寸等需要的维度，这对查询性能是巨大的挑战。另外，如果整条数据链路都带上这部分数据，势必会造成极大的浪费。基于此，在确定没有对这类维度进行分析的前提下，整个数据链路都不生产这部分数据，只根据需要在数据服务侧进行结果的拼接，这样不仅可以提升查询效率，还可以很大程度上节约计算资源和存储资源。
最后介绍自定义桶深的能力。我们在一些场景，如排行榜，业务方是可以通过牺牲一些精度来提升性能的。对于 Clikehouse 来说，是可以通过在本地节点对数据进行前置过滤，来减少网络带宽和协调节点汇总压力，从而显著提升查询性能。
生产加速方面，要做到全链路系统化，这样中间结果才是可知可控的，哪些中间结果是可以共用的，或者哪些不会再用可以删掉。如果是人工来做，则完全没有依据。只有系统化，才能从全局进行把控。目前我们在数仓资产层只有数千个规模模型，处于相对稳定的状态。而到了应用层，就迅速扩展到了十数万个，并且仍会以非常快的速度激增。我们所希望的是像右边的梯形，通过系统化减少中间结果，让应用层的数据尽可能地复用。
预计算是通过空间换取时间，要预计算哪些数据往往根据用户的业务需要，如果不够精确，会浪费大量的存储空间。为了解决这个问题，我们开发了基于 HBO 的加速策略，用户只需要输入 QPS 和 TP99 等业务目标，系统会根据用户的历史查询情况，自动将高频的维度组合，时间分区等进行预计算加速，让性能优化更加具有针对性，既满足用户的业务目标，又能最大化的节省存储资源。
4. 指标治理
最后要分享的是指标治理。目前我们的数据治理工作覆盖了从数据目录到最后的数据展示的端到端全链路。在数据目录中，对指标进行调用量监控，长期没有调用的指标要进行指标下线，对全部指标进行质量评分；在指标定义方面，对 4W1H 里的元素有进行推荐，对同质化的指标进行监控；生产方面，对中间结果进行物化并监控其生命周期，对低频的数据进行数据退出；数据服务方面，包括动态扩容，QPS 使用率监控，当前真正调用的 QPS 大约只占申请 QPS 的 1/3，这里有很大的优化空间；最后是数据展示方面，有很多看板，比如今年赞助春晚的一些定制大屏，以后就再也不使用了，这种低频的要去推进它下线。
综上，我们整体的治理目标是，口径清晰、数据新鲜、系统高效、成本经济。
三、应用实战案例
1. 从指标定义到指标展示的低成本，高时效交付
上面介绍了指标中台的很多能力，实际工作中我们是如何使用的呢？这里主要涉及上面提到的 3 类角色，分别是产品，数据开发，前端开发。对于一般复杂度的看板，每个角色只需要一名人员投入，而且全程 codeless，对技术要求的门槛比较低。产品通过指标市场查找现有指标并定义新指标，包括对应的修饰和裁剪口径等。这部分工作 1-2 天可以完成，并把定义好的指标同时交付给数据开发和前端，并行进行数据开发和展示层开发。数据开发通过配置化指标生产，并通过加速策略满足性能要求，这部分工作 1-3 天可以完成。前端开发通过前端低代码平台，也是配置化完成看板的搭建，也只需要 1-2 天即可完成。后续还有联调和压测等工作，顺利的话 5-7 天可以交付一个高质量看板。这彻底改变数据交付模式，根据我们的统计，在战报、大屏、黄金眼等核心数据决策场景研发成本降低 40%+，大促备战人力下降 20%，数据需求交付效率提升 70%+。
2. 指标多端复用，口径清晰统一
经统计，在已注册的有效指标中，有过复用（被使用超过 1 次）的指标占比超过 50%，其中被使用最多的一些核心主题指标复用率超过 80%。以零售通用域的“成交金额”指标为例，该指标被应用在 20+ 的数据看板、系统上，保障了多端看到的数据一致性。在此基础上开发的复合指标和子指标，与前端低代码平台进行高效联动，可以完成日内的看板需求交付。
四、总结与展望
1. 成果总结
指标中台建立两年多来，已经成为零售指标数据的统一出口，并逐步扩展到其他 BGBU。支持零售多个核心数据产品，包括黄金眼，商智，大屏，AB 实验等。日均调用量超过 4000W+ 次，注册指标超过 10000。目前整体的需求覆盖度为 55% 以上。新需求覆盖度则可以达到 80% 以上。节省人力超过 50%。
2. 未来规划
未来的工作主要有三个思路，即让用户用数用得更广泛、更集约、更放心。
- 更广泛用数
继续进行能力建设，尤其是高阶长尾的能力，继续提升需求覆盖度。
- 更集约用数
继续提升系统化，智能化能力，基于主动元数据的数据治理覆盖度更高，减少人力和存储资源。
- 更放心用数
继续提升数据和系统的稳定性，提升指标语义层质量，结合大模型降低指标查找和注册的难度。
