万字干货 - 京东零售数据资产能力升级与实践

开篇

京东自营和商家自运营模式，以及伴随的多种运营视角、多种组合计算、多种销售属性等数据维度，相较于行业同等量级，数据处理的难度与复杂度都显著增加。如何从海量的数据模型与数据指标中提升检索数据的效率，降低数据存算的成本，提供更可信的数据内容和多种应用模式快速支撑业务的数据决策与分析，是数据团队去年聚焦解决的核心课题。

通过 23 年的打磨与应用，我们在数据指标开发与共享效率大幅提升，分析看板搭建时间从天级别缩短到小时级别，日均指标消费频次从 23 年初的百万级增长到年末的数千万。

本文会基于我们的实践，通过如下几个章节和大家进行分享交流，希望能为技术同学们带来一些启发或帮助。这也是“2023 京东零售技术年度盘点的深度文章系列”的第二篇，欢迎持续关注。

1、 数据资产篇--资产认证与治理

2、 数据能力篇--指标中台实践

3、 数据展现篇--数据可视化工具

4、 数据智能篇-- 基于大模型的智能化应用

1、数据资产篇--资产认证与治理

背景与挑战

零售数据模型有几万张，其中有大量的临时表、无效表等，零售数据资产用户(尤其是分析师角色)一直存在找模型、理解模型、使用模型困难的情况，面对业务用数、分析需求，在找模型探数据的环节经常消耗较多的时间精力，用户普遍希望可以节约找、用模型的时间，提升交付数据结果、分析结果的效率，而且有些错误的或重复的资产在公司部门内流通，重复资产一方面浪费成本，另一方面无法保证数据的一致性。

为解决用户诉求，同时从产研角度希望优化数据资产的质量和标准化程度，从生产到消费均进行一定程度的优化改造，提升端到端的资产建立标准化程度，进而提升用户使用体验。

数据统一语言

目标：如下图所示，拉齐资产建设者和资产消费者之间的沟通语言，提升找表效率、增强表的可解释性。

通过数据维度建模的三个阶段(概念模型、逻辑模型、物理模型)，形成描述模型的标准定义。

总结为一句话：

业务域 **& 主题 **下，描述了 **X1 业务过程 ， X2 业务过程 **的 **X 主体 **表，每 **更新频率 **更新 更新周期 数据的 存储方式 表，表主键是 数据粒度

比如： adm_d04_trade_std_ord_det_snapshot 通用域 & 交易 下，描述了 取消,完成,成交,订单出库,下单 的 大盘订单 表，每天更新近 1 日的增量快照 表，表主键是 ord_type+sale_ord_det_id

维度建模方法论

3 个阶段：概念模型 > 逻辑模型 > 物理模型 (1:N:M )

概念模型

在一个分析领域内，描述实体以及实体之间的关系，等同于业务图谱。一个主题下一个概念模型。

实体之间的关系包括引用关系和继承关系，引用关系：一个实体是另外一个实体的属性。继承关系：实体比另外一个实体更细化具体，比如事件和浏览。

where [业务域]+ why[主题]+who[主体集合] + what [业务过程集合]

举例：交易的业务流程图：

将业务流程中的实体（包括业务活动和业务对象）之间的关系构建出来，变成交易主题下的概念模型：

逻辑模型

逻辑模型：是将概念模型转化为具体的数据模型的过程。一个概念模型下会拆分成多个逻辑模型。拆分原则：根据主体或者业务过程进行拆分。

where [业务域] + why[主题] +who[主体] + what [业务过程]

这里的业务过程可以是单个，也可以是多个。一般根据业务将业务相似度高，同粒度的业务过程放在一起。

举例：

where [主站] + why[交易] +who[订单] + what [下单、支付、出库、完成] where [主站] + why[交易] +who[订单] + what [下单、支付] where [主站] + why[交易] +who[移动订单] + what [下单]

物理模型

用技术手段将逻辑模型通过不同的加工方式和周期频率等物化形成多个不同的物理模型。一个逻辑模型对应一个或者多个物理模型。更新周期：每次更新多久的数据。更新频率：多久更新一次。加工粒度：描述模型每一行的业务含义，也就是主键。

where [业务域] + why[主题] +who[主体] + what [业务过程]

• when [更新周期+更新频率]

• how much [加工粒度]

• how [更新方式]

举例：

[主站] + [交易] +[订单] + [下单、支付、出库、完成] + [未归档/日]+[订单号] + 增量

[主站] + [交易] +[订单] + [下单、支付、出库、完成] +[未归档/日]+[销售订单明细编号] + 增量

[主站] + [交易] +[订单] + [下单、支付、出库、完成] +[近 1 日/日]+[销售订单明细编号] + 增量

[主站] + [交易] +[订单] + [下单、支付、出库、完成] +[近 180 日/日]+[销售订单明细编号] + 增量

[主站] + [交易] +[订单] + [下单、支付] +[近 1 日/日]+[销售订单明细编号] + 增量

[主站] + [交易] +[移动订单] + [下单] +[近 1 日/日]+[订单号] + 增量

资产认证

基于数据标准，推进资产认证，通过资产完备性、唯一性治理，存量资产关停并转，提升认证资产的需求覆盖率，降本增效。目前，覆盖零售范围内的交易、用户、流量、营销、财务等核心主题数据资产建设。

资产可感知

从全局到局部，端到端的全面了解数据资产，提升资产可感知的能力，包含：

1）推进数据资产图谱的自动化构建能力，从资产全景上快速了解到业务流程及业务数据化的资产模型（数据孪生）；

2）丰富模型详情页，归一所有信息源，并增加对模型行高、数据范围、常见问题等信息，提升用户理解模型的效率；

3）标准字段库，通过对字段标准口径、业务描述、特殊场景、常见问题等信息的补充和完善，提升用户理解模型、用模型的效率。

未来计划

•以用户反馈问题出发，完善和优化数据标准 5W2H，使其确保数据资产清晰易理解的目标达成；

•依据样板间的效果反馈，完善样板间的功能和内容，并推广到其他主题资产；

•加强数据资产运营，扩展渠道，提升用户找数用数体验。

2、数据能力篇--指标中台实践

背景与挑战

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

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

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

技术先进性

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

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

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

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

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

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

结合以上我们特有的优势项能力，在业界首次实现了生产与消费联动互相促进，打造了数据收集、数据安全、指标计算、监控、分析以及决策支持的指标生态，提供一站式的中台化、服务化的指标服务平台，让用户可以高效地管理和分析各种业务指标，主要解决用户在数据处理和分析过程中遇到的以下几个问题：

（1）数据孤岛： 不同的部门或业务线可能使用不同的系统来记录数据，导致数据分散在不同的地方，集中分析变得困难。

（2）数据标准一致性： 保证整个组织内部使用统一的数据指标定义和计算逻辑。

（3）实时性： 业务决策往往需要实时或近实时的指标来支持，一站式指标中台化解决方案可以提供实时监控和即时分析。

（4）自助式分析： 业务人员和分析师可以通过友好的界面进行自助式的数据探索和分析，而不需要依赖于专业的数据团队。

（5） 数据治理： 包括数据安全、质量管理、合规性监控等多方面确保数据的准确性和可靠性。

总体架构设计

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

详细设计展开

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

统一的 DSL

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

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

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

聚合条件：【按‘店铺’聚合】，筛选条件：【时间范围 = '2023-12-21'、品牌 = 'XX'（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+本地缓存的方式进行多级缓存的加速。

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

数据知识系统化：

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

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

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

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

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

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

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

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

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

资产放心好用：

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

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

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

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

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

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

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

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

•第三道防线：应急预案

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

存算成本集约化治理：

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

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

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

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

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

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

中间结果物化

大数据量预计算有着耗资源、易失败的特点，数据同步会因为网络抖动或集群异常造成同步失败，整个链路失败率高、重试成本高。用户在定义驱动生产只配置基于数仓做预计算，结果数据同步到目标数据源，中间过程并没有做配置。为提高任务稳定性，系统内置 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 个外部子集团产研。日均 4000w+次数据调用，支持零售 8000+个指标，并支持了 22 个数据产品。做到了无 OLAP 数据和服务端研发资源使用指标服务平台交付需求，数据整体交付效率由 3 天缩短到 0.8 天，提升需求交付效率 70%。

3、数据展现篇--数据可视化工具

背景与挑战

从行业来看，未来所有成功的企业都将是数字化转型中表现卓越的组织。在数据展现能力上，持续探索数据可视化理论、丰富数据分析方法和可视化表达，推动数据可视化自动化、场景化、智能化快速落地，助力京东各业务单元敏捷作战，激发个体创造力，不断适应市场和业务需求的变化。

技术先进性

通过持续建设系统能力，赋能看板、报告、大屏、分析、提数等多个业务场景，同时从 4 大方向纵向拉通系统质量保障建设，提升系统稳定性，最终实现在复杂多变的业务场景下，通过功能插拔、动态配置，构建一站式的解决方案，主要具备以下优势能力：

1.分析可视化组件： 引用业界先进的图形语法理论结合 SVG、D3 等技术沉淀，自研 9 类可视化分析能力，如杜邦分析、异动分析、交叉分析等。相较于行业方案，更加贴合京东零售业务分析思路。

2.低代码编排： 设计并实现了编排技术方案，包括状态管理机制、可视化编排系统、数据集编排系统、代码生成与注入系统，可将万行代码的看板完全配置化实现。

3.PC、移动端双端支持： 基于移动端组件库和低代码平台高效支持移动分析诉求，支持多端、多网络、多设备，交互体验媲美原生 App。

4.报告、洞察等场景化能力： 基于底层通用系统能力和能力基座打造。报告场景下业内首次支持复杂数据 PPT 报告的自动化输出，大幅提升分析师效率。洞察场景下基于标准化协议实现洞察配置化，并支持快速横向扩展分析能力，高效支持不同业务场景下的问题自动发现与诊断归因。

以上数据可视化技术方案目前在零售内得到充分应用，有效支撑日常迭代和大促期间复杂多变的业务场景，能够实现降低研发成本，提升研发效率，完善用户体验。

整体架构介绍

在数据驱动业务运营的策略下，以高效灵活、场景化、智能化为目标，整合数据资产和工具，以可视化组件和低代码平台为核心，打造黄金眼、商智等标杆的数据应用，实现对不同业务场景的快速赋能。我们通过持续建设系统能力，赋能看板、报告、大屏、分析、提数等多个业务场景，同时从 4 大方向纵向拉通系统质量保障建设，提升系统稳定性，最终实现在复杂多变的业务场景下，通过功能插拔、动态配置，构建一站式的解决方案。

整体来看，数据分析可视化的能力建设，主要可以分为 PC 端能力建设和移动端能力建设两个方向，接下来将从 PC 端的分析可视化组件建设、低代码编排、数据推送，以及移动端能力建设和多端一体建设几个方向，详细介绍数据分析可视化的核心技术方案以及在业务中的应用。

详细设计展开

分析可视化组件

图形语法理论

分析可视化组件底层均采用了业界先进的图形语法理论。图形语法是一种将抽象基本元素组合成图表的规则。图形语法深层次地反应出统计图形的层次结构。在图形语法学中，一般统计图表的规格主要包含 6 个要素：

•DATA：一组从数据集创建变量的数据操作

•TRANS：变量转换（如排序）

•SCALE：度量（如对数）

•COORD：一个坐标系统（如极坐标）

•ELEMENT：图形及其艺术审美属性（如颜色）

•GUIDE：一个或多个辅助物（如轴线、图例）

和传统枚举图表相比，使用图形语法生成每一个图形的过程就是组合不同的基础图形语法。故而它的灵活和强大之处就在于，只需要改动其中某一步骤，就能得到完全不同的、全新的图表。

基于灵活的图形语法理论基础，沉淀了大量可视化分析能力，接下来将具体介绍几种特色能力。

杜邦分析

杜邦分析法（DuPont Analysis） 是一种综合利用多个财务指标比率关系来拆解企业财务状况的分析方法。其基本思想是将企业净资产收益率逐级分解为多项财务比率乘积，这样有助于深入分析、比较企业的经营业绩。由于这种分析方法最早由美国杜邦公司使用，故名杜邦分析法。 使用杜邦分析法可以清晰描述指标体系内指标的层次和指标间的关系。如下图所示，杜邦分析法通过树形结构自顶向下的展示了指标间的构成和层级关系，同时通过指标之间的运算符号清晰展现出指标之间的计算关系，例如“净资产收益率=总资产净利率 * 权益乘数”、“总资产净利率=销售净利率 * 总资产周转率”、“销售净利率=净利润 / 销售收入”、“总资产周转率=销售收入 / 资产总额”。采用这一方法，可使财务比率分析的层次更清晰、条理更突出，为报表分析者全面仔细地了解企业的经营和盈利状况提供方便。

•布局策略：设计 12 种布局方案，分为两大类：垂直方向（自顶向下、自底向上）、水平方向（自左向右、自右向左），通过 d3-hierarchy 对层次结构数据进行布局计算，实现 node 布局。

•节点关系：node 节点关系绘制（父子、兄弟）、node 节点辅助信息绘制（提示、预警等），实现关系 ICON 位置计算、辅助信息位置计算。

•交互：设计了收缩展开、缩放能力，支持大数量图表的交互，通过 viewBox 实现。

•异动分析

在实际的业务场景中，为实现对全链路监测部分的可视化展示，沉淀了可复用的可视化组件：网格指标卡。该组件适用于异常监控分析、全链路转化分析等分析场景，主要包括以下几部分：

•指标卡：集成指标卡全部功能，并通过对异常指标的特殊标识来达到预警能力

•流转线：反映指标间的转化关系

•标题：业务流程的标识

主要的实现流程如下：

在具体的技术实现上，针对点、线、卡片的位置计算和绘制，采用了类似杜邦分析的技术思路，前端动态计算节点、链接关系位置，并使用 svg 等前端技术进行渲染。除此之外由于图表结构和逻辑比较复杂，如何设计该图表的配置化方案，成为了另一个技术难点。为此，针对标题部分我们抽离行、列标题组，复用流程标签组件的配置逻辑；针对卡片本身，复用了原先指标卡的配置逻辑；针对指标卡的位置和连接关系，用户能够通过行列坐标的设置和关系绑定来进行细粒度配置，同时为了节省用户的配置成本，组件会在初始化的时候进行默认编排。

最终在商家异常全链路监测需求中使用网格指标卡组件，针对 3 个环节、7 个模块、19 类的核心指标与异常类型商家数量，让用户能够从商家经营整体环节通过预警功能进行风险监控和异常定位。

交叉分析

为解决复杂的数据分析场景，创建了一种基于 React 技术自研的交叉分析表格组件，将常见的表格操作与交叉数据分析的思路结合起来：在传统可下钻表格的基础上，创新地抽取分析动作层，能够类比数据分析中的切片、切块和下钻思路，进行数据分析，使用时允许用户在多个合法维度中选择，形成一条自定义下钻路径，成功地实现多种维度下，在表格中进行可下钻的交叉数据分析，满足了多元复杂的数据分析需求。

具体的实现原理是将表格的上卷下钻逻辑与交叉数据分析逻辑结合起来，这里面的重点处理在于对从调用参数中过滤条件、维度字段和指标字段的进行动态处理，从而实现交叉分析的数据获取查询。首先，对维度字段和指标字段分别进行遍历，能够获取到过滤条件、维度字段和指标字段这三种参数，对于同一个表格来说，数据查询的返回字段是一致的，于是在每一次遍历中，都可以在查询字段结果中增加一项，用于构建最终数据查询的结果集；接下来，从第一步触发下钻的的动作中，获取到父层级的维度信息和具体的值，设置为过滤条件，通过这一步，可以查询出当前父级条件下的数据；接下来，同理如果该维度是子级维度，那么就把该维度条作为聚合维度进行操作；最后，将上述封装好的操作条件，传递给后端进行查询，并将获取到的数据，根据父级指标的维度值，拼接到该项的子节点字段中，这样便语义化的可以了“在父级维度某个维值的过滤条件下，按子级维度聚合的”数据，再整体将最新的数据拼接到的表格数据中，至此便实现了交叉数据分析的分析动作。

自动化分析

在沉淀分析可视化组件的同时，也在自动化、智能化的数据分析方面进行探索和建设。其核心思路是，通过贡献度和基尼系数等算法，计算出最需要关注的品牌、品类等，并基于增强分析技术，如洞察文案生成技术和图表标注技术等，自动生成数据报告。

同时，基于自动分析结果，还可以进一步通过多因素分析等可视化分析组件进行更深入的探查。基于表格组件，通过组件联动能力，组合多个表格形成联动下钻分析。

低代码编排

数据产品页面具有复杂的业务逻辑。一方面页面布局复杂，一个页面可能包含数十种组件，涵盖布局、筛选、可视化等多种组件；另一方面组件间存在大量联动逻辑，如筛选组件间联动、筛选组件和可视化组件联动、可视化组件间的联动以及和外部系统的联动等；此外，业务场景灵活多变，例如在作战单元模式下，Boss、采、销、控等角色数据分析思路均不一致：这些都对编排能力提出了极大的挑战。为解决这个问题，持续调研学习行业先进的低代码技术理论，同时结合数据产品的特性，设计并实现了一整套编排技术方案。

首先是自研了基于 MVC 模型的 JMT 状态管理框架，在 redux 的基础上，升级了状态的更新和变化响应机制，支持复杂异步状态管理，以一种通用状态模型支撑了数据产品逻辑的配置化。

其次是基于 JMT 组件库自研了可视化编排系统，一方面，通过多种灵活的布局组件，支持复杂页面布局的编排。另一方面，提供了灵活的组件配置面板，除常规样式的编排外，还充分发挥底层数据可视化能力，支持如杜邦分析等指标关系的编排。此外，通过对底层 React 框架的灵活使用，创新组件嵌套机制，支持可视化组件互相嵌入形成联动分析，如在杜邦分析中既展示 GMV 的拆解，也展示 GMV 的达成进度等。

第三是构建数据产品特有的数据集编排系统，支持对数据资产、EasyData 等多种数据源，通过编排维度、指标、过滤构建数据分析模型，并基于图形语法技术将可视化组件和数据服务的 olap 能力做充分打通，实现数据驱动可视化。

第四是自研了一套代码生成和注入系统。可视化编排和逻辑编排使用一套标准 Schema 进行驱动，在页面发布时，会基于 Schema，结合 React 和 JMT 状态管理，自动生成代码。此外，对于页面中的尚未被组件功能覆盖的个性化逻辑，可以通过代码注入，配合 JMT 函数库快速解决。在百亿补贴等紧急需求中，代码注入功能解决了大量个性化逻辑，在时间紧任务重的情况下，保质保量交付需求。

数据推送

邮件作为现有工作模式下一种不可或缺的通信方式，在邮件里查看看板数据（定时汇总为小时/日/周/月等不同时间粒度），成为诸多用户的强烈诉求。

各业务服务调用统一的后端服务创建定时推送任务，任务通过前置配置项检查后，被添加到消费队列中依次处理，处理的产物包括图片、Email HTML、附件等，最终按照用户配置的触发方式推送出去。

下图梳理出任务处理的关键流程：素材处理服务（Node）主要承担推送任务消费及提供获取素材的 HTTP 服务两大功能。在任务消费过程中，素材处理服务会模拟用户权限打开浏览器去做页面 Canvas 图像转换、看板截图、PDF 生成等操作。如果触达方式为邮件，则会将所有素材填充生成为 Email Html 文本文件，通过回调返回给后端，推送给用户呈现的内容是数据看板。

在素材生产过程中，服务通过捕获屏幕快照来实现这一目的。但是某些情况下，比如设备性能较差或者页面进行缩放而 Canvas 图像尺寸没有随之调整时，快照图片会变得模糊。为了解决这个问题，我们直接获取 Canvas 对象。通过 Chrome DevTools 协议，可以将 JS 代码发送到浏览器并在上下文中执行，执行结果会被序列化为 JSON 格式返回给 Node.js 环境，从而达到 Node 服务与 chromium 上下文通信的目的。

在处理阶段，由于 Canvas 对象是 Web API 的一部分，只能在浏览器环境中使用。而常用的 Node 下操作 Canvas 的工具包几乎都依赖底层的图形库，例如 Cairo 或 Skia 等。这对于开发环境（MacOS）和部署环境（CentOS）不一致的研发来说，调试难度较大。为了解决这个问题，通过 Node.js 环境提供的 Buffer 对象承接 Canvas 对象的 Data URL，配合 JPEG 图像编解码器处理。这样就无需考虑底层图形库的兼容性和安装问题，实现素材图片的顺利生成。

依托于数据推送和低代码能力组合的建设，在 618 大促期间，已将其应用到业务小时报、作战单元日报中，快速实现了基于看板的批量报告功能，帮助 3C、大商超等数据 BP 快速实现面向作战单元的日报和小时报推送，为多场景报告做到了很好的支撑。

移动端能力

通过复用 PC 端的低代码编排能力，利用 jmtm 基础组件库和 jmtm-charts 图表库，能够快速搭建起移动端的数智化分析功能。

针对移动端看数场景，使用自研的主题配置工具：将组件字号、颜色、圆角、尺寸等样式变量化，从而可以根据具体需求进行灵活配置。其中色板变量的引入保证了组件库的底色充足，而公共变量的使用则提高了配置效率。另外我们还引入组件变量，实现个性化的定制需求。支持在线预览和一键发布等功能：用户可以通过在线预览功能，在配置过程中即时查看效果；一键发布功能则可以快速将配置好的主题应用到移动端低代码平台中。

针对移动端的性能优化，通过优化动效的执行时机，将动画交互与耗时的 DOM 渲染分离开来，提高动效的流畅度，减少页面加载时的卡顿感，确保用户能够得到良好的交互体验。

针对移动端多页面交互场景，创造性的采用类似原生多开 webview 的翻页卡片机制并对多个页面进行缓存处理，使整个应用体验更加接近原生化。基于多人协作及应用的可扩展性考虑，我们借鉴业内成熟的微应用方案，并结合自身需求场景，支持微应用嵌套微应用的方案，为较复杂应用的场景提供了可能。

多端一体建设

为了提高研发效率并满足用户在不同端的看数需求，我们在 PC 端逻辑编排的基础上引入了 hybrid 概念，使编排引擎可以发布到移动端的多个产品线。在页面打包及部署过程中，使用 webpack 插件 jmtbuild-hybird-plugin，发布为能适配到多端的 js-sdk 资源。最后通过前端微服务平台在对应的容器中加载并展示页面。

通过低代码平台生成的标准页面需要在不同的业务端进行展示，在权限方面，针对嵌入到客户端的场景进行了 token 校验，对于浏览器 H5，采用 cookie 解析的方式进行登录校验和数据安全保护。标准页面默认在公司内网进行访问，使用 colorAdapter 适配器函数可以使接口一键转化，接入网关。网关统一接入了神盾、反扒、防刷等功能，保障外网访问的数据和网络安全。

业务贡献和价值

在研发提效方面：在大促期间 Boss 作战单元的模式下，在战报的应用场景上，通过低代码加数据推送能力的快速整合，在两周内，支持多个部门的报告推送；此外，在百亿补贴重点项目中，面对紧急多变的业务场景，协同业务团队通过低代码线上配置化+二次开发的方式，2 周内交付 5 个看板、2 个大屏，80%的需求在 24 小时内交付。

在创新业务支持方面：业务对体系化看数需求强烈，期望使用移动端查看业绩达成情况。通过移动端低代码能力，仅用 1 个产品经理、4 个数据研发短时间内从 0 到 1 打造出一个基于低代码的黄金眼移动端应用，快速解决业务移动端看数的诉求。

此外，随着零售架构扁平调整，Boss 单元需要更高效的数字化决策工具，自动化分析能力也得到了充分的应用：基于丰富的可视化组件和低代码编排能力，结合后端的智能化算法，快速打造零售自动化分析看板，应用于每日的经营过程控制中，将诊断提前至每天的工作中，以提高发现问题和解决问题时效。

展望未来，我们会持续打磨现有能力，并不断结合新的业务场景和行业调研，沉淀新的数据可视化分析能力。首先在智能化方向上，会基于图形语法的可视化理论，并整合 AI 等能力，建设增强分析能力，打造增强图表和自动化报表，实现自动洞察数据关联、异常及趋势等，将数据分析从描述性分析跃升到预测性分析和决策性分析；同时在质量体系建设方面，会从监控预警、代码质量等方向持续建设，在不断提升交付效率的同时持续提升交付质量：最终期望能够通过数据分析技术能力的综合运用，降低研发成本，提升研发效率，完善用户体验，高效推进人人都是分析师的战略落地。

4、数据智能篇-- 基于大模型的智能化应用

背景与挑战

目前，数据分析服务主要通过数据产品、BI 工具和配备数据分析师等方式来支持，在数据响应效率、分析能力应用的广度、深度和频率等方面各有不足，但业务时常需要通过数据驱动决策，就出现了数据获取难、数据分析难等用户痛点。大模型在数据消费领域的应用，为用户痛点的解决带来了新的思路。

基于 LLM 的解决方案

对于京东复杂的业务和数据体系，大模型在数据服务领域的应用很有价值，同时也面临着挑战。当前的架构设计充分考虑了已具备的底层数据服务能力，结合 LLM 实体识别、上下文推理、决策辅助能力将用户查询与复杂数据集的相关指标匹配，实现快速准确的数据查询。通过 NER 识别将用户的筛选条件、查询指标、聚合方式抽取出来，利用 Norm(归一化)把实体转换成标准数据服务的调用参数，并且构建索引将归一化依赖的数据资产进行存储，来实现自然语言查询准确数据的全链路，与此同时，建立完善的评估体系、利用本地模型优化等机制，不断提升应答准确率，为用户带来更优质的使用体验。

基于业务知识和数据知识的 Prompt 工程

Prompt 工程建设

•目标确认：针对用户对数据的诉求，整理用户问题确定输入数据，基于不同任务目标确认不同输出格式，如实体识别输出标准格式的{实体类别：实体名称}，指令生成输出标准格式的{分析能力：分析指令}等。

•工程建设：确认目标后，从环境预设、指令描述、输出规范等角度生成规范 Prompt，不断微调输入结合业务知识的个性化案例。并通过中英互译、预设负样本、增设输出校验和边际检验、动态 Prompt 生成等方案优化，兼顾时效性的同时，提高输出结果的稳定性和准确性。

准确率提升

模块归一化模块会把实体转成数据服务支持的参数值，难点在于区分出相同名称或者相似名称， 为用户匹配出最符合用户需求的结果，包括指标、筛选条件、聚合维度等实体的转化，具体思路可以拆解成以下步骤：

•精确匹配：入参类型、指标名称或 id、用户权限多维度叠加判断得到精准结果；

•相似性匹配，在精准匹配没有结果之后，使用大模型对实体进行 embedding 操作，从库里查询出相似度最高的结果；

•建立索引：对实体建立别名层，满足用户个人习惯，如部门的简称、指标的别名，来提升识别准确率；

•用户行为数据辅助：通过用户在数据产品、数据工具等系统的行为数据，生成用户对指标、筛选条件、聚合维度的偏好数据，辅助提升准确率。

评测体系

数据服务场景对准确率要求较高，同时数据指标相似度、数据口径复杂等实际情况对大模型的准确率有较高挑战，如何保障回答的准确性是产品设计之初就重点考虑的问题。目前通过周期性大样本量评测集生成、检验，以及线上监控的组合方式来保障。

•样本设置：采用人工样本和大模型生成样本结合的方式，快速、多频次对不同句式、不同场景的问答（1000+）做评测，来保障样本的多样性和丰富度。

•准确率测评：通过批量调用接口返回大模型结果，离线代码支持批量结果自动化比对，从而高效输出任务的准确率、时效性等指标，同时同一批样本会多次调用来评估任务的稳定性。

•构建产品功能：用户可以在答案上点赞或点踩来反馈满意度，产品侧持续针对用户反馈问题进行阶段性优化。

本地大模型 SFT

基于 LLM 对 prompt 工程输入 token 数量的限制及数据隐私安全的考量，我们也选用本地大模型进行 Fine-tuning。它涉及在一个预训练模型的基础上进行额外训练，以使其更好地适应特定的任务场景，实现准确率提升和影响时长降低，具有很好的效果。

指标查询场景

在指标查询场景中，用户的提问方式具有高度多样性，同时，影响查询结果的关键因素也呈现出复杂的组合形态。为了提升查询效率和准确性，建立京东专属的业务域知识库来支持样本的批量生成

•按场景构建多样化问题库，如单/多指标查询、分维度查询、维度 id 和 name 查询、排序查询等

•按查询因素构建变量知识库，建立时间、指标、维度、筛选条件知识库，方便后续新增场景的快速扩充

模型训练前后准确率对比提升明显

数据分析场景

本地大模型可支持数据交互，解决数据在传输过程中可能遭遇的安全风险和隐私泄露问题。通过问题引导，降低用户的使用成本，使用户能够智能化分析。通过用户数据查询的当前表现，由大模型提供"分析线索"引导用户进一步分析下探，线索包括：

•描述性分析，如销量达成情况、趋势分析、摘要总结

•探索性分析，如维度拆解、相关性指标推荐、异常值识别等

业务价值评估

•数据查询提效：通过自然语言对话，完成快速数据指标查询，单次查询时效降至 7.8 秒，大大降低用户数据获取的时间，并且很好的支持了用户个性化需求的满足

•数据分析赋能：依托丰富指标维度数据，通过思维链实现自动化数据分析，并依据用户的习惯喜好等选择更贴合的数据路径，非“分析师”角色用户轻松实现多场景的快速智能分析

•数据消费拓展：通过产品赋能，为每一个用户配置一个专属的 AI 数据分析师，可以扩大数据消费用户的规模，并且大幅提升数据消费的能力，支持业务应用数据驱动决策