京东业务指标数据体系建设实践

罗弘

​ 业界首个“数据智能知识地图”已发布！1月限时免费领取！
<hr/>导读：本次分享题目为京东数据驱动业务发展 - 业务指标数据体系建设及集市治理实践。
文章会围绕下面三点展开：

• 业务集市现状
  
• 业务集市治理
  
• 未来展望
  

<hr/>分享嘉宾｜张婉绮 京东 数据挖掘工程师
编辑整理｜杨佳慧
出品社区｜DataFun
<hr/>01/业务集市现状


首先介绍一下京东业务集市的现状。众所周知互联网轨道生命周期已经进入成熟阶段处于人口红利倒退的趋势中，各个公司都以精细化运营的方式来正面应对此情景，所以数据驱动成为业务决策的中坚力量。



1. 数据驱动力

数据驱动力指的是通过数据体系系统化地获取及分析数据，为业务决策提供有效支撑，驱动业务发展。

2. 业务市集现状





在业务数据增长越来越明显的趋势下，构建业务体系、获取数据能力就目前而言是非常重要的，但业务集市的历史构建主要由各个业务线的数据分析同学负责，他们的关注点更多在于数据的快速交付，一定程度上造成了数据集市无序建设的问题。业务集市的现存的问题主要有以下四点：

• 烟囱式开发现象严重：每一个需求都对应一个模型，每一个模型都需要开发，模型的重复性较高且模型较为分散。此时就会造成冗余计算的情况，浪费了过多集群资源。烟囱式开发也是较为常见的情况。
  
• 跨层依赖严重：跨层依赖严重，读取共享数据有明显问题，存在大量重复读取消耗 IO 资源，缺乏共享复用。业务团队的数据分析同学使用的数据源通常为贴源层数据，数据量较大、字段较多，会对资源造成一些不必要的消耗。
  
• 业务数据共享度低：一个公司/部门可能存在多条业务线，但这些业务之间并不是完全独立的，存在较强的数据的耦合性，但数据共享度较低。
  
• 无统一的数据标准：各业务团队之间无统一数据标准，数据口径难以保持统一，导致数据质量参差不齐，进入恶性循环。业务同学无法感知已有数据维度与需求的关联匹配程度，从而无法深入挖掘数据价值，也无法得知数据统计的准确口径，导致数据信任度较低、数据失真的情况。
  

这样的集市现状给数据的使用带来了很多问题，总结来讲就是：不可知、不可取、不可用、不可控。

• 不可知：用户不知道集市/平台中有哪些数据可以使用，是否能够帮助自己解决核心问题。
  
• 不可取：用户难以做到数据与知识之间的快速转换，同时集群资源紧张导致取数困难。
  
• 不可用：各业务的数据分类体系缺乏统一的原则规范，使得数据定位难、可信度降低。
  
• 不可控：不关注集群状态导致的恶性循环。
  

--
02/业务集市治理





对于存在上述问题业务集市治理来说，除了使用现有常见的即时治理工具之外，更还有着更为重要且比较根源性的做法：建立业务集市标准，以及对历史无序情况进行重构。



由于业务数据分析同学与数据开发同学所在角色和思维角度的不同，业务同学关注点更多在于如何经营阶段内的数据目标、阶段性的 OKR、KPI 等数据指标如何向下拆解，但数据开发同学的焦点在于如何保证数据的可用性和集市的稳定性。对于一个良好的业务数据集市来说，自上而下通过基础数据来逐步逐层地、秩序稳定地实现业务数据支撑是极其重要的。
在期望之下衍生出了新的数据框架：

• 最底层为现有的常规数据仓库。
  
• 中间第二层为基础建设，此部分主要是建设基于业务基础的通用层模型，通过此部可以为业务线或耦合性较强的业务群组创建一套标准化通用的基础层，不仅可以配合一些维表来实现业务数据的维度扩充和数据快速定位，还可以在此基础上利用一些中间表来减少在计算过程中的资源浪费。
  
• 在基础层的建设之上，基于基础通用数据模型、结合业务需求将经营目标拆解成具体的数据指标，通过数据之间的交叉计算给出更深层次的分析，或者将部分数据建设成为数据看板进行数据可视化的展示。这些数据指标可以为业务同学的经营分析起到很好的辅助作用，涵盖从项目规划、到日常经营、再到效果复盘、最后到下一个新的决策如此循环的完整过程，与此同时也能够逐层保证产出的数据质量。
  

在这样的框架下，越高层级的数据越精细化，数据统计的口径更加定制化。越底层的数据模型复用度越高，越标准。如此的层级会使数据集市更健康。

• 业务基础模型规范
  

用建设业务数仓的思路来建设标准化的通用模型，主要存储数据为公司内部标准通用的明细数据。重构建设的主要措施是封装标准口径、行列裁剪、维度扩展、跨主题拼接等。此部分的口径是广义的，不针对于具体某一个业务需求，而是更专注于一整条业务线或一个大的业务模块上的普适性。重构建设时，可以按照不同业务线/业务模块组织数据，进行明细数据的整合，解藕数据源，简化数仓模型使用复杂度，减少读取。

• 业务通用模型实践
  

用户宽表的建设：其实是将一些订单主题的数据和用户主题的数据进行融合，在订单数据的基础上，将不同业务对于用户的一些不同身份的定义全部拼接至同一张表中，并扩展一些标准的、通用的数据维度信息，支持不同业务的数据调取。这样的处理方式可以保证数据口径的统一。

• 数据指标体系
  

数据指标体系，即数据应用层，此层级的主要目的是支持业务进行某些经营专题的分析。这里的数据指标会按照业务的具体需求进行设计并包装，一般会根据特定的数据统计口径进行不同交叉维度的计算，用于其他系统的底层数据支持、数据看板可视化展示，或直接提供给业务同学进行深层次的数据分析。总体来说此部分数据的口径更加精准化，更贴切于用户经营目标的分析和监控。

• 指标纬度值统一
  

数据指标总体来讲可以分为三类：基础指标、衍生指标和复合指标。
基础指标可以理解为较为常见的、直接计算的数据指标，例如成交人数、成交金额等。
衍生指标可以理解为在基础指标的基础上结合一些定义将指标之间进行组合或者通过运算得到的一些数据指标，比如复访率、转化率等。
复合指标通常指数据的对比情况，比如同比、环比等。
在计算衍生指标时，分子分母可能已经存在在不同的模型中，此时如果能快速定位到需要的分子分母数据，就可以避免计算衍生指标时对分子分母的重复计算。针对此情况，开发出了一个特有工具，此工具可以根据不同的维度组合生成全局唯一的场景指标编码，不论在什么时间、什么引擎下，同样的维度所生成的指标维度 ID 值都是一样的。这样在计算衍生指标时，通过维度 ID 一致+维度枚举值一致，即可获取相对应的分子分母，快速计算衍生指标。

• ClickHouse 字典刷岗
  

由于 SKU 的归属是与人员身份进行相应绑定的，若人员身份产生变动时会影响到某类 SKU 的采销部署，所以需要进行刷岗操作，其本质是更新 SKU 和维度信息之间的对应关系。
刷岗的整体难度较高，主要体现在三部分：第一是数据量级大，可能涉及到百亿数据量级的两张甚至多张大宽表进行关联刷新；第二是维度组合较多，导致计算量极大；第三是业务侧要求的刷新范围不断扩大，甚至个别主题希望全量进行刷新，时效要求较高。



提出了 ClickHouse 字段刷岗的解决方案，在 ClickHouse 中将维表加载到字典，将明细表基于字典直接进行相应岗位的数据查询，这样查询逻辑更简单，查询效率更快。
基于此解决方案，也有一些相应的优化措施：
① 字典存储按照 SKU 分片存储，可以极大的减少占用内存空间的数量；
② 缩减字段，将维表中无关刷岗的字段过滤掉，此部分可以减少50%的字典存储空间；
③ 类型优化，比如部门 ID 等 ID 类的字段，在存储时可以将数据类型由 string 转化为 int 类型，使用时再转为 string 类型，在保证正确使用的情况下字典空间占用可减少 60%；
④ 考虑到字典的主键唯一性，将 sku 一对多的情况用 Array 类型进行存储。



为保证刷岗准确性，增加校验机制，引入版本表，将刷岗的结果先写入版本表中，将版本表和原有数据进行对比验证，得到验证结果是正确的才会写入正式的明细表中。



字典表的应用同样可以用于数据看板的服务查询中，与刷岗原理是一致的，通过加载 sku 对应的字典数据来获取维度信息。



对于一整套的业务集市建设标准，以一个活动主题的数据举例说明治理效果。



重构前，数据指标依赖复杂，大多指标直接依赖于贴源层级的数据，比如用户日志模型。这些模型的数据量极大，对于需求无用的字段很多，因此数据重复读取率极高，造成了数据资源的浪费。
重构时，针对读仓成本居高不下问题及用户使用行为分析，对读取频率 top 的大模型（比如用户日志）进行列裁剪，仅存储近两年热数据。
针对队列资源紧张，调度不合理的问题，通过对各业务模块常用的埋点信息进行统一收集，通过埋点过滤构建 app 层加速模型，通过减少数据量，降低任务执行资源消耗。
对于一些与其他业务耦合性较强的应用层数据，封装标准口径沉淀至数仓，反哺业务其他指标/其他业务。
在计算数据指标时，不再直接依赖贴源层数据，而是依赖通用层模型，减少读仓成本。使用产出唯一维度 ID 的工具来减少重复计算。维表存储数据特性，提供维度信息，通过表关联拼接快速对数据进行特定维度的定位/区分。合理设计中间表，降低加工过程计算难度，提高运行效率。可设置为临时表，仅帮助加速本次计算，不存储历史数据。也可设置长期中间层，包含历史数据。
采取此方式进行重构后，可以降低 43% 的读仓成本；应用层模型数量减少51%，存储降低 34%；末端的的看板产品出数时间缩短 3 小时。
--
03/展望未来





敏捷、智能、可用、驱动力。
在数仓建设、数据体系建设、资产分级以及对数据智能化自动化的探索（智能标准的建设）等方面，京东数据团队会对其进行持续的探索，以期望打造一个敏捷、智能的业务数据集市，并能够以数据驱动业务发展。
--
04/问答环节


Q1：根据岗位回溯数据代价大是否存在代替方案？
A1：代价是相对的，相对于数据集市建设的意义来说代价是允许存在的。可以弱化回溯的概念，对于数据量可接受范围内且适用于业务场景的查询，可以在保留基础数据信息的前提下，将某些数据信息不进行落表物化数据的操作，通过查询进行数据的展示，例如用户在查询 SKU 数据时，用 SKU 去查关联字典数据并进行相应的数据展示。
Q2：在数仓之上再建数仓的形式增加了数据跑数的周期，是否可以对原始数仓进行治理？
A2：原始数仓治理和新建业务层级数仓是两个概念，不是冲突的，本次分享基于业务数仓的治理，新建业务层级数仓时有必要的。在现状中，业务侧的数据大多直接来自贴源层，若以极小数据量级的查询调取数据量较大的贴源层数据，也是得不偿失的。且基于京东这样的大平台来说，存在着许多条业务线，那优先考虑、兼顾的一定是全局的数据情况，而不是某一条具体的业务线。
Q3：指标是按照主题域的方式来划分管理的吗？多链路漏斗指标追踪是如何实现的？
A3：可以理解为按照主题域的方式来划分管理的，但实现过程中并不是以此单一条件进行实现的。数据溯源的最底层级是贴源层数据，是按照主题域划分的。但主题域的数据在使用时也不是单独使用的，也存在着主题域之间的交叉计算等。将数据指标进行主题划分后对上游数据源可以更好的追踪管理，对数据之间关系的管理也会相对简单，所以在计算时会先按照不同的主题进行划分，后在结果表中对不同主题的数据进行拼接。
今天的分享就到这里，谢谢大家。
<hr/>分享嘉宾



张婉绮｜京东 数据挖掘工程师
负责京东零售数据平台产品的离线数据开发及业务指标数据体系建设工作，专注于数据模型建设、数据治理、数据SLA保障等领域的应用和探索，用数据驱动业务有质量的发展。
<hr/>DataFun新媒体矩阵



<hr/>关于DataFun

专注于大数据、人工智能技术应用的分享与交流。发起于2017年，在北京、上海、深圳、杭州等城市举办超过100+线下和100+线上沙龙、论坛及峰会，已邀请超过2000位专家和学者参与分享。其公众号 DataFunTalk 累计生产原创文章800+，百万+阅读，15万+精准粉丝。