导读 本次分享题目为京东 One-Service 数据服务体系建设，主要介绍京东在建设数据服务体系过程中的三个阶段，其中将详细介绍主题化数据服务和 One-Service 数据服务体系建设思路。
主要内容包括以下几大部分：1. 数据服务发展历程
2. 主题化数据服务
3. One-Service 数据服务体系
4. 未来规划编辑整理｜杨哲
内容校对｜李瑶
在第一阶段，京东业务线爆发式扩张，各个业务线有自己的专属的业务诉求和数据要求，本阶段数据服务面对是爆发式增长的业务数据分析需求，此阶段目标是快速解决实际业务痛点，完成数据服务能力建设，存在即可。
第二阶段业务会从爆发的各个子业务线汇总成主题式的集中业务线，俗称集中力量干大事，数据服务变成了面向集中主题式的业务，解决数据边界同时可以归类类似业务线面对的问题和难点，集中解决相关问题，更有利于数据管理和业务规划。
第三阶段是 One-Service 服务一体化，在主题化数据服务的基础上，我们考虑是否存在数据服务一体化的可能性，实现一个数据服务可以完成所有主题服务的查询。
接下来，将详细介绍第二和第三阶段实现的具体细节。
1. 主题化服务逻辑
纵向来看，主题化数据服务分为前、中、后三个模块。前台面向不同端的用户群体，供不同的渠道调用，比如 PC、APP、邮件等，提供不同的页面格式和展示类型。中台负责请求分析与路由转发，通过识别调用请求中的指标属于哪个主题，将请求路由到对应的主题中。后台就是主题化的数据服务，按照业务线分为不同的主题域，划分的规则根据公司的业务制定相关规范，比如交易主题、流量主题、用户主题等。2. 主题化服务实践——融合服务
上图展示了融合服务架构，融合服务的本质是利用标准化的模版按照不同主题转换为不同的服务，最终达到“大一统”的目标，并且利用核心链路来屏蔽掉不同服务之间的性能差异，降低系统性风险，其核心就是模型适配器，由基础模型适配器组成，支持基于基础模型的各种扩展。
协议层，首先进行调用请求进行语义解析和校验，最后在查询得到结果后，对返回结果按照统一约定进行封装。权限层，权限控制包含应用接入权限、应用和各主题服务数据访问权限、应用 QPS 是否超阈值。业务层，跟业务相关的场景，比如指标的定义：包括指标和主题的关系，指标的命名，指标的支持方式（聚合类型，指的是这个指标的聚合方式是 sum 还是 count）、指标查询是否存在关联子查询等等由业务方约定的模型。适配层，时间适配是根据请求参数指定的时间类型进行对应时间维度转换，如请求参数指定的时间类型为 BY-DAY，约定了时间为天粒度，即对应时间维度模型均为 XXXX-YY-DD；模型适配，标准模型和用户自定义模型的解析和加载。查询层，SQL 语义并发执行，特殊扩展能力拟合秒（离线的情况下，当我查询第1秒和 59 秒，这两个数据是确定的可以正常返回，当需要查询第35秒的数据，会通过算法拟合的方式模拟出第 35 秒的数据）。
连接层，创建连接池、限流控制、超时、熔断等功能；详细介绍一下多热集群，服务本身对高可用的要求，支持在两个集群执行查询；
动态配置，依赖zookeeper对全局配置信息进行动态存储和分发。3. 主题化服务实践——融合服务的特点
① 代码模板化
通过定义基础模板实现基础查询，通过自定义模板来生成个性化查询；类比面向对象的概念，通过定义父类，固化一些通用的参数，子类继承父类并重写一些方法实现个性化能力。
将数据源、表、缓存时间动态配置，然后将指标和指标支持的维度以枚举的形式固化到代码中。 ③指标融合化
通过拆分服务内容，支持跨集群、跨业务线的多个指标合并查询。
④ 缓存粒度化
支持时间维度的年、月、日、小时、秒独立缓存，有利于累计指标的频繁计算。
4. 主题化服务实践——是否能真正服务于业务
融合服务承载了京东过亿的数据流量，屡次承担了大促业务需求的重任，但是不断优化和提升，是程序员追求的极致，于是我们在思考一些问题，探索有没有更加优秀的实践。第一，标准化包含两个内容，指标口径的标准化和服务协议的标准化。如何制定一个标准化的指标，原本指标定义应该由业务来制定，但是目前压力由研发同学承担。刚才提到的融合服务架构中，后端的复杂度是最高的，因为不同的业务线使用不同的服务协议，需要做大量的协议适配和分发。
第二，资产化，基于大量的业务线和数据，我们系统中积累了大量没有治理和梳理的资产，由于这些资产分散在各个业务系统中，无法进行有效的复用，导致资产化存在无法落地的瓶颈。
第三，模板化，在融合数据服务设计中，基于大量的模板化查询支持公共的数据服务查询，但是对于复杂业务场景并不能有效的支持。第四，稳定性， 服务协议的不统一造成了参数和链路的复杂度，那么数据服务的稳定性最终将依赖于最终各自服务的稳定性，无法实现整体服务平台的稳定性。第五，研发周期，当业务人员需要新增一个看板时，涉及到不同的指标，需要协调多个数据团队，那么这个研发周期是无法保证的。1. 数据模型标准
数据仓库管理数据资产，首先针对数据资产，我们需要一个标准化的规范来规范资产，为此我们提出来一个符合当前预期的标准——5W2H。业务域是从零售角度对业务进行的划分，代表所属业务范围的数据集合。主题域是一个抽象概念，将零售信息系统中的数据整合、归类，并进行分析利用的抽象。业务过程是在指定的主题域中所执行的业务活动以及对业务活动流程的描述，是一个不可拆分的行为事件 ，比如：下单，浏览。主体是模型中的最主要的一个唯一实体，也是不可缺少的一个实体，一个模型中只有一个主体，比如订单表主体是订单。更新周期是指每次更新多久范围的数据；比如 180 天订单明细宽表每天更新 180 天的订单，更新周期为近 180d。加工粒度是模型的主键，也可以是联合主键，代表每一行数据的业务含义，比如订单明细宽表的主键是 sale_ord_det_id ,如果模型没有主键，请描述每一行数据的业务含义。描述模型的存储方式，包括增量快照、全量快照、增量、全量、拉链。（如订单粒度、SKU 粒度）、更新频率以及更新方式（增\全量、补充更新等）。
比如零售业务域下的交易主题，业务过程是成交，主体是订单，根据商品粒度，并且每日增量更新数据，最后产生了零售交易成交订单明细表。这就是一个数据模型的设计过程。
指标标准我们内部统称 4W1H，与模型类似，分为业务域、主题、业务过程、业务主体、度量。度量既包含数据呈现的方式，也包含数据的口径。
3. 资产化管理平台
根据之前的设计，指标可以被标准的定义出来，那么如何管理众多指标，这里我们提出建设资产化管理平台——指标市场。
分为五个功能模块，指标注册、指标管理、指标接入、指标巡检、指标路由。指标巡检通过配置化模拟调用，定时监测指标服务是否存在异常，优先于用户感知系统异常。指标路由，分析指标的实现，将最佳实现呈现给调用方。
实际的数据分析中，很多问题往往是参数的异常造成的。比如涉及到部门的统计分析，不同系统中对于部门的定义存在差异，比如 A 系统命名为 Department，B 系统命名为 D，这就会造成系统冗余，从而影响统计结果。所以我们构建了一个标准化的维度，为所有数据指标提供一个标准化的维度视角。以 Key、Value 的形式存储数据。
当资产标准标准定义完成后，真正的困难点是如果实现指标的统一化查询，如果承担不同服务之间的差异化调用，此时我们提出了一个设想——定义驱动生产。定义驱动生产远景就是通过定义（配置）实现不同指标的数据查询，所以我们约定各种各样的配置，指标定义配置、指标和维度关系配置、指标实现配置等等各种和指标相关的口径配置，以配置化的形式完成了指标 SQL 的拼装，最终实现了指标的查询。在基础的能力之上，还建设了动态能力——动态修饰和动态函数，部分指标在查询实现过程，其实近存在 to B 和 to C 的差异时，也就是仅仅是口径参数不一样，那么可以通过动态修饰的方式实现；动态函数是指时间类的函数，如同环比，通过动态的标识，一次性查询各个时间周期的数据。
基于两个资产标准，定义驱动构建查询能力，维度中心和指标市场约定标准化调用，通过清晰的调用链路，明确的调用边界，充足的应急预案，合理的熔断降级，构建起了 One-Service 一体化服务的全貌。标准化的内容，形成了标准化的资产，建立起了京东数据资产的完全链路。7. 低代码配置化前端
到目前我们实现了所有后端处理过程的配置化，那么前端是否可以实现配置化和标准化，我们通过低代码思路来实现标准化的页面展现。一个数据分析页面通常包含，概览、明细、维度等要素，通过标准化的前端组件实现数据分析页面的配置化。8. 服务查询链路
服务的整体查询以前端接入层为入口，包含低代码标准化调用和非低代码调用。指标市场根据配置，决定路由服务，从而约定了服务的实现是由定义驱动配置化实现，还是其他原始服务实现。
服务保障层主要职责是保护系统，定时巡检，根据巡检情况对服务进行有效处理，涉及指标限流、集群切换、集群熔断、服务降级。集群切换不意味着服务降级，因为部分服务支持双流甚至于三流配置，可任意切换并不会对服务有任何影响。
9. 对比
在具体业务场景中，我们的需求实现过程发生了重大改变。首先需求分析阶段由原来的人工沟通，改变为在指标服务平台中自行定义；其次，原来需要不同团队分析的指标，转化为先在指标市场中进行复用，如果没有可以复用的指标再进行增量开发；再次，原来的开发过程，转变为配置化的定义指标；最终，由数据服务平台统一转化协议，向下游提供数据服务。10. 主题化服务 VS One-Service
通过对指标全生命周期流程的重建，从指标管理、指标开发、指标调用、开发周期和扩展能力五个方面实现了全面提升。实现了统一的指标市场管理，标准化的指标定义，统一的调用协议，同时极大地缩短了开发周期。04
未来规划
1. 减少水下能力
大量配置化的功能对于水下能力提出了很高的要求，特别是数据的运维需要大量的专业人员，部分水下能力没有及时上线。在上线初期，系统的操作流程与业务的操作习惯存在一定的差异，比如多余的参数选择等。
通过增加流程控制点，引导、规范用户的操作流程，来进一步强化流程链路。
3. 报警分层
能力平台目前有很多报警信息，但是大多报警信息来自于用户的配置问题，而真正需要关注的集群故障报警被淹没在庞大的无用报警中。那么需要对报警信息进行不同影响级别的划分，使报警信息能清晰、准确的传达。
4. 保护动态化
当前的熔断和限流措施，均由人工执行，未来我们希望能够由系统自动的实现一些动态的保护措施，根据上游集群的负载情况和可用性情况，基于预定义规则，实现自动化的熔断或限流操作。5. 服务器轻量化
经过很多轮的迭代，平台内部的各个服务之间的代码可能存在大量冗余。通过排查、合并公共服务，减少代码冗余，来提升平台的性能表现。以上就是本次分享的内容，谢谢大家。
分享嘉宾
INTRODUCTION
周慧通
京东集团
数据应用工程师
网易互娱技术中心计费实时平台与 SDK 技术负责人，Apache Flink Contributor，Flink CDC Contributor。负责计费实时数据平台与 SDK 的设计和开发，参与了实时风控、用户画像、异构关联分析挖掘等业务的核心工作。