背景与挑战

df40f27c41e6cf17bc950bdca458194d_format,webp.webp

❌1 、口径歧义与存算不受控：指标通常散落在BI报表工具、数据产品、ETL过程与各种中间表中，看不清，改不动；如何系统化保障存算资源使用合理？

❌2、研发资源缺口：数据BP缺少OLAP数据研发、数据服务研发、前后端研发，在不扩招的情况下如何满足各业务单元的用数诉求，降低指标加工门槛，使少量BP同学即可完成自交付？

❌3、指标开放共享难：如何让原本锁定在数据应用产品内部的指标无需重复加工即可对外开放共享，让指标流通起来？

技术先进性

纵观业界比较成熟的指标中台相关建设，针对零售场景口径变化快、用户类型多且数量大、数据产品形态丰富等特点，我们打造了核心优势项能力：

1.全量的指标明细资产管控能力【指标、维度资产】

2.系统原生的拓扑能力【指标市场】

3.业务公式统一沉淀能力【规则引擎】

4.指标异常主动预警能力【指标巡检】

5.基于逻辑宽表的智能加速和扩维能力【定义驱动生产】

结合以上我们特有的优势项能力，在业界首次实现了生产与消费联动互相促进，打造了数据收集、数据安全、指标计算、监控、分析以及决策支持的指标生态，提供一站式的中台化、服务化的指标服务平台，让用户可以高效地管理和分析各种业务指标，主要解决用户在数据处理和分析过程中遇到的以下几个问题：（1）数据孤岛：不同的部门或业务线可能使用不同的系统来记录数据，导致数据分散在不同的地方，集中分析变得困难。（2）数据标准一致性：保证整个组织内部使用统一的数据指标定义和计算逻辑。（3）实时性：业务决策往往需要实时或近实时的指标来支持，一站式指标中台化解决方案可以提供实时监控和即时分析。（4）自助式分析：业务人员和分析师可以通过友好的界面进行自助式的数据探索和分析，而不需要依赖于专业的数据团队。（5）数据治理：包括数据安全、质量管理、合规性监控等多方面确保数据的准确性和可靠性。

总体架构设计

166a273052667dc250c48c142ef1b3b8_format,webp.webp

在架构设计上我们参考了MDA和DDD的思想，希望通过口径组件实现自动生成代码并统一查询语言，支持全链路行为决策；通过DRY的原则抽象指标定义相关可积木化执行的原语，以便于基于数据应用的场景连接底层平台能力；从图中可以看到整体架构分为物化层，语义层，和查询层。在整个过程中都会伴随数据加速，通过统一接入层开放给各个产品端或可视化工具来使用，物化层用来回答前面的存不存，存多久，存哪里，怎么存的问题；语义层用来通过系统将业务语言转化为机器语言，查询层用来回答数据去哪拿、怎么拿、怎么拿最快的问题，最上面蓝色部分为各个消费指标产物的产品端，深绿色是可视化工具，浅绿色是正在孵化阶段的基于GPT的数据分析工具。

详细设计展开

查询层：统一查询语言，最佳查询策略、最优查询性能

f6da0ee00d93b99309d0c19643ea7a10_format,webp.webp

统一的DSL

在查询语言层面，需要将自然语言分析需求转换为结构化的查询语言从而达到书同文、车同轨的目的，使得指标数据所见即所得，开箱即用。我们通过如下案例来说明语言抽象的思路，例如一个常见的分析需求：

「23年12月21日'小米'品牌在各店铺'成交金额'排名top5的情况」

如果将该需求进行结构化抽取，可以做如下解释：

聚合条件：【按‘店铺’聚合】，筛选条件：【时间范围 = '2023-12-21'、品牌 = '小米'（id是8557）】，要查的指标 = 【成交金额】，排序 = 【按‘成交金额’降序】，返回维度属性 = 【店铺】，分页 = 【第一页-5条】。

通过这样的结构化思维的理解，则统一的指标查询语言可以由五要素组成：指标、聚合条件、筛选条件、排序分页、返回维度属性。基于此五要素，设计出统一查询DSL。如下结构体所示，语法规则设计类似Json语法风格。

{
    "indicators": [
      "ge_deal_standard_deal_ord_amt"
    ],
    "attributes": [
      "shop"
    ],
    "criteria": {
      "criterions": [
        {
          "propertyName": "main_brand",
          "values": "8557",
          "type": "string",
          "op": "="
        },
        {
          "propertyName": "dt",
          "value": "2023-12-21",
          "type": "string",
          "op": "="
        },
        ...
      ],
      "orders": [
        {
          "ascending": false,
          "propertyName": "ge_deal_standard_deal_ord_amt"
        }
      ],
      "maxResults": 5,
      "firstResult": 0,
      "group": [
        "shop"
      ]
    }
}

智能寻址拆分

在实际应用情况中，在简单的五要素基础上，真实业务场景还存在一些同环比、复合指标计算类似的分析及提数场景，则一次取数任务并不是提交一次引擎查询就可以满足需求。所以按照实际场景，查询引擎在处理一次取数任务时，会生成一个执行计划DAG，主要包含两层拆分原则：

（1）语义拆分：按照查询引擎提供的DSL语义进行第一层拆分，结合统一的包含“指标、维度、数据服务”的基础元数据中心，进行寻址物料的归堆分组，根据决策策略表进行拆分，包含取寻址最大必要集、在线转离线的策略以及可手动调配的权重等，一个Job（对应用户一次取数任务）会拆分为多个Task，每个Task表示一批逻辑的指标/维度查询。

（2）引擎拆分：按照指标维度所存在的数据服务（表引擎）进行第二层拆分，一个Task会拆分多个Query，每个Query表示一次面向引擎的查询，包括上图里当期查询、同期查询等并针对Task按照实际查询场景进行主从/并行的Query决策。

查询逻辑加速

包含根据执行计划发起的主从/并行和点查/批查的查询，通过这个逻辑加速可以减少2/3（整体的统计，一批指标越多越明显）的冗余数据查询，从而提升整体TP99表现，同时在查询层通过动态获取集群CPU负载等情况可以用来进行自动切流、潮汐滚动等加速优化，比如在双流情况下，当其中一条流集群CPU负载超过预设的阈值时，启动自动切一部分流量到另一个流从而来前置降低集群负载避免影响查询速度。又如在近线的查询场景中（分页逻辑异步发起多次请求，用户预期分钟级响应内），通过获取集群CPU、负载的使用情况来动态调节请求的流速，从而通过最大化利用集群资源来实现查询提速。当然在查询加速上少不了缓存的介入，通过JIMDB+本地缓存的方式进行多级缓存的加速。

语义层：数据知识系统化，使资产放心好用、治理有依据

0b34197d1e7909c75fc07bffaf15f8f0_format,webp.webp

数据知识系统化：

在数据知识可视化上要做的事儿是如何将业务语言转化为机器语言，并根据设定的标准及规则进行执行，对此分别从指标维度体系化标准定义模型、指标维度的数据安全保障模型、指标消费应用管理模型三个层面进行了系统化设计，为自动化生产、消费及全链路血缘可视化做数据治理打好基础。

•指标、维度体系化标准定义模型：

通过定义4w1h构造原子指标并结合标准维度定义的裁剪口径进行唯一的、标准的衍生指标定义。

复合指标指建立在衍生指标之上，通过一定运算规则形成的计算指标集合（二次逻辑计算），如ARPU值、渗透率等；包括比率型、比例型、变化量型、变化率型、统计行（均值、分位数），复合指标采用了“积木化+服务化”双重解决方案，在既满足业务灵活场景下，又做到了复合指标的资产沉淀。

又如以复合维度的模型为例在维度模型上结合较频繁变动的维度（维度的定义会周期性变动）调整项如何统一，对需求进行了抽象，设计复合维度模型，进一步扩充"指标-维度-修饰"的概念体系，既保证了维度口径定义的透明,又保证了逻辑一致且可被系统执行;一次定义,多处使用，结合上面提到的统一查询的服务化能力做到了真正的开放（日均调用量4000w）、共享（可复用，不用单独开发）。

•指标、维度数据安全保障模型：

对人在数据应用产品上能看到什么样的数据范围需要有安全保障，避免数据泄露风险。对此通过把看数视角【维度+维度值】定义到数据角色里，可做到数据角色被多个人或者岗位所复用。在数据角色基础上抽取岗位的模型把人与角色关联起来，保证一个人可有多个身份切换不同视角进行灵活看数。在岗位下通过设计功能角色把资源（菜单）的权限进行管控，在资源下进行具体指标和维度组的关联，从而达到在基础的行列之外，提供了各种“视图”级别的权控，而每一个“视图”是展示的最小单元。而资源内的指标维度叉乘关系是数据权限全集的真子集从而达到快速分配权限的目的。

•指标消费应用管理模型：

当一个指标被申请消费时，需要知道被用在来什么平台、什么端，应用场景是什么样的，从而来评估是否允许接入、是否需要重保、资源如何分配等。对此构建消费应用管理模型，从指标到资源、场景、应用端、应用平台的关系把消费血缘需要体现出的具体消费情况都能涵盖。

资产放心好用：

在数据知识系统化的前提下，需要大量对外开放，基于三道防线保障了日常和大促的资产放心好用，为系统稳定运行保驾护航：

•第一道防线：前置避免故障发生：

通过资源隔离来进行各平台、端甚至看板级别的隔离保障，保障的是一些非重保看板查询变慢或者阻塞不影响其他核心业务；压测相关是在平台层面上基于历史调用采集分析对现实场景的高度还原，进行全链路节点高保真压测，并且针对压测期间通过动态别名切换技术，来实现业务无损压测及数据产品无感知压测；在混沌工程演练上将核心的数据链路注入问题点，自动识别潜在风险，防患于未然。

•第二道防线：巡检与监控，主动发现

241c6dd9c7bc817dc41729a254e63a5c_format,webp.webp

在态势检测及预警上，结合调用情况对预计算、预热命中率等趋势预警，防止有些预计算未命中或者预热未覆盖到的情况；在数据SRE的体系建设上，对调用情况通过全链路的uuid进行串联，并进行可视化展示，提升数据可观测性，打破多系统监控数据孤岛，提升监控效率；巡检能力是通过日常的访问日志分析及梳理，以及各核心业务场景的输入，如上图所示，基于统一查询服务的巡检配置场景及对应告警规则，结合巡检自动化任务，可在任意时间按任意频次动态执行任务，防止数据空窗、跌0、异常波动等情况。先于用户无感的在系统层面发现问题；从发现、跟进、分析、解决、经验沉淀做到全流程自动化。在实战中巡检的问题主要分以下几类：

（1）对于实时数据异常的巡检，第一时间发现后马上进行数据流切换，用户完全无感知；

（2）BP的战报、日报通过巡检无需人工确认，自动将结果发送给对应业务，可以及时介入；

（3）大促期间有很多指标数据有“异常”大波动（以23年618期间为例，巡检发现16个线上异常情况），产品研发收到巡检结果后第一时间进行业务分析，从经营状态角度确保数据在预期之内。

•第三道防线：应急预案

对于一些已发生的问题，一定要有应急预案才能真正做到临危不乱，服务化对于限流、熔断实现了精准靶向，可做到针对某一个页面的某个主题指标进行细粒度限流或者熔断处理，也可做到整体的看板或者集群粒度的处理，保证容灾的灵活性。同时对降级策略有更友好的设计，在降级后默认返回兜底0的基础上，通过缓存机制，可返回最后一次请求成功的结果，增加了系统灵活性及减少业务的损失。在应急预案上由于压力过大导致服务或容器出现异常时，会应急启动热备容器，让子弹飞一会儿，争取更多的修复及问题定位时间。

存算成本集约化治理：

指标体系开放，在生产、消费间进行系统化流转，基于指标体系及指标消费应用管理模型首次解决消费链路可追踪，结合指标的生产血缘，形成清晰的全链路血缘。

打通全链路血缘的必要性主要基于以下三大视角：

（1）用户视角：让用户从指标展示入口（标准化产品、数据工具）到口径与资产血缘清晰可见，知道数据从哪来、怎么来、怎么用。

（2）治理视角：通过数据标准消费端反向治理，可清晰的知道某些模型或者表在消费侧的使用情况如何，访问少或功能相似的看板做整合，关停并转，实现了从消费价值来反推资产ROI。

（3）监控视角：当大促期间发现某一数据任务延迟或者某一实时流积压时，可通过血缘关系快速确定应用上的影响范围，从而能快速介入进行分析并判断是否公告用户。

物化层：基于数据消费行为(HBO)、系统内置规则(RBO)自动加速

e01dad0ba9593f0beff6063bd2ba9d0f_format,webp.webp

中间结果物化

大数据量预计算有着耗资源、易失败的特点，数据同步会因为网络抖动或集群异常造成同步失败，整个链路失败率高、重试成本高。用户在定义驱动生产只配置基于数仓做预计算，结果数据同步到目标数据源，中间过程并没有做配置。为提高任务稳定性，系统内置RBO判断为预计算任务会自动优化生产路径：首先生成预计算SQL，之后通过SQL做读时建模，在数仓中自动创建模型并将预计算结果数据写入到模型中，模型会继承逻辑表5W2H并写到元数据中，避免模型重复创建。最后基于模型生成数据同步任务。这样任务失败只需要重跑预计算或同步任务即可，无需全链路重跑，降低任务重试成本。更为关键的是，系统会给中间结果(包含系统创建模型)配置生命周期，让数据合理生产与消亡，如果不被下游依赖则会全部清理直至下次使用再创建，避免人工开发场景只生产不治理的情况。

双流场景，定义驱动生产内配置双流策略则会默认生成一个计算任务，中间结果物化到临时表并基于中间表数据生成两个同步主备集群的任务。

数据索引增强

多维分析场景中，经常使用Groupings Sets将多个维度组合进行计算，通常每个维度组合都对应唯一编码(命名为LVL code)供消费侧查询使用。之前人工开发大多数据研发和服务研发共同维护维度组合与LVL code映射表，在脚本和服务中通过硬编码方式实现双方联动，维护成本极高。定义驱动生产判断预计算目标源是ClickHouse则自动使用Groupings Sets生成轻聚合数据，生产侧通过调用生成LVL code函数获取维度组合对应的LVL code值，并自动将二者写入到"数据索引"表中，消费侧查询时同样通过"数据索引"表获取编码值生成SQL，生产、消费自动联动。

自动加速与引擎优选

除用户手动创建加速方式外，系统还支持基于代价与用户消费行为智能物化。用户申请指标填写QPS、TP99两个信息，用户可在加速策略模块选择高阶功能"智能物化"，并可配置存储上限、构建频率、构建结束时间等信息。系统分析访问日志，会对指标+维度粒度TP99大于目标值进行自动生成加速策略，默认将数仓数据进行预计算并同步到HBase中，系统判断逻辑表配置了介质加速如HIVE2ClickHouse，则会通过引擎优选功能判断基于数仓和ClickHouse哪个计算更快、更省资源，一般会优化为ClickHouse2HBase。

智能物化是整个系统的核心，解决业务敏捷与无序增长的困境，用户定义完虚拟数据模型的业务逻辑后，引擎不会直接将其物化，而是按消费端对模型字段的产出时间和查询速度的要求，分析全局数据的查询情况，选择性按全局最优的策略进行物化编排（通过物化视图实现），并持续HBO优化。

业务贡献和价值

覆盖数据中台内所有场景和数据团队，零售内4个C-1，及4个外部子集团产研（如CHO、京东健康、京东工业、京东自由品牌）。日均4000w+次数据调用，支持零售8000+个指标，并支持了22个数据产品，覆盖产研300+人。做到了无OLAP数据和服务端研发资源使用指标服务平台交付需求，数据整体交付效率由3天缩短到0.8天，提升需求交付效率70%。

京东零售数据资产能力升级与实践：https://blog.51cto.com/u_15714439/10050196