一、导语

得物社区推荐的实践中，我们发现用户兴趣容易收敛到少数几个主兴趣上，难以做到有效的兴趣拓展，通过将大模型与推荐结合的方式，在得物社区的用户兴趣拓展方向上切实取得了突破，拿到了显著的业务收益并推全上线。因此我们将相关工作中采用的核心算法与模型策略总结整理，投稿了AAAI-PerFM，入选了长论文《Enhancing Serendipity Recommendation System by Constructing Dynamic User Knowledge Graphs with Large Language Models》。AAAI Conference on Artificial Intelligence）由人工智能促进会（AAAI）主办，是人工智能领域历史最悠久的国际学术会议之一。以下内容为正文的详细介绍。

二、背景介绍

得物社区作为得物的首tab，满足得物用户分享生活、发现好物的内容生产消费需求。跟其他内容平台一样，得物的社区推荐系统也存在“推荐 → 用户反馈 → 再推荐”的反馈闭环问题，系统会越来越倾向于推送相似内容，导致推荐结果收敛、同质化，进而形成信息茧房，降低用户的新鲜感与满意度。

同时随着大语言模型（LLM）的发展，世界知识提取的效率逐渐得到提升，为打破信息茧房，提高用户内容消费的新鲜感带来了新的机遇。我们提出用大语言模型（LLM）来动态构建用户知识图谱（User Knowledge Graph），并在知识图谱上进行更可控的推理来挖掘用户“潜在兴趣”，再把这些潜在兴趣以工程可落地的方式接入工业推荐链路，在得物社区业务场景取得了显著的消费指标收益。

得物App的社区页示例：

三、问题与挑战

1.为了打破信息茧房并提升用户体验，新颖性推荐应该给用户推荐意料之外的物品，并且吸引用户点击，即同时具备意外性和相关性。但受限于意外发现数据的稀缺性，近些年的研究往往只能采用较小的模型，或者在有偏差的推荐数据的基础上进行数据扩充，这可能反而会强化反馈循环，增大打破信息茧房和识别新颖性物品的难度。

2.虽然大语言模型拥有丰富的世界知识，并展现出卓越的理解和推理能力。但在将大模型推理落地到推荐系统的实践中，依然发现大模型难以通过单跳推理正确生成复杂问题的答案。

3.工业推荐系统对实时性有要求，通常响应时间在100ms内。基于大模型的新颖性推荐有较高的延迟，计算成本高昂。

4.当推理生成出用户潜在兴趣后，在推荐系统中如何高效地召回相关候选item，既要保证item与用户潜在兴趣的相关性，又要兼具高消费效率的特性（比如拥有更好的点击率，保护用户消费体验），是能否在工业场景取得收益的关键。

四、优化方案

整体框架如上图所示：

1.采用大语言模型替代传统小模型，从用户行为中提取潜在兴趣，从而缓解显式兴趣发现数据稀缺的问题。

2.通过两跳推理与多智能体多轮辩论机制，提升大模型在兴趣推理中的准确性与稳定性，保障输出质量。

3.采用近线召回架构进行工程部署，缓解大模型推理时延较高的挑战，实现推荐系统的实时响应。

4.引入对比学习，将大模型提取的兴趣与推荐系统内现有用户兴趣表征进行对齐，确保召回内容既符合用户潜在偏好，又具备高相关性与高消费转化效率的特点。

基于LLM大模型兴趣提取过程：

两跳推理

用户的静态画像（年龄、性别）以及用户的历史行为（过去30天的搜索词）作为初始输入节点，大模型作为用户动态图谱构建工具：

将大模型作为知识图谱构建器，动态构建节点和关系 G=(V,E)，其中 V 是实体集合，E 是关系集合。给定两个实体 v1 和 v3，目标是通过两跳推理判断它们之间是否存在潜在兴趣关系。

• 第一步： 从 用户静态画像和搜索词v1 出发，找到满足上位关系的节点v2。

• 即找到所有满足 (v1,v2)∈E 的 v2。
• v2是v1的核心述求和动机。

• 第二步： 从 v2 出发，找到所有满足用户核心诉求的同位或者下位的节点 v3。

• 即找到所有满足 (v2,v3)∈E 的 v3。
• 为了避免不相关的输出并减少幻觉v3限制在商品、商品类目、话题范围。

多智能体多回合辩论

通过提示工程根据用户静态画像和用户行为构建用户动态画像及完成两跳推理，会出现推理路径错误及潜在兴趣不相关问题。在本文中，我们采用了一种互补方法来改进推理过程和输出响应，其中多个语言模型实例在多个回合中提出和辩论其各自的响应和推理过程，以得出共同的最终答案。 我们发现，这种方法显著增强了任务的两跳推理能力。同时这种方法还提高了生成内容的事实有效性，减少了当代模型容易出现的谬误答案和幻觉。

具体来说，我们首先提示每个代理独立解决给定的问题或任务。 在每个代理生成回复后，我们向每个代理提供一个共识提示，如图 所示，其中每个代理被指示根据其他代理的回复更新其回复。 然后可以使用每个代理的更新回复反复给出此生成的共识提示。

SFT

为了降低部署成本，我们先使用参数量较大的推理模型deepseek-r1构建户动态图谱（思考过程）和生成潜在兴趣作，然后蒸馏到参数量更小的模型qwq-32b。将思考过程和潜在兴趣转换为文本化的SFT数据集D，其中每个条目是一个元组(x,y)。 这里，y 指的是输出，代表思考过程和潜在兴趣，而x 代表输入提示，输入和输出如图接下来，遵循如下公式，对qwq-32b进行监督微调得到interestGPT，以提高其生成期望回答的概率。

大模型兴趣在推荐系统中的应用

为了兼顾i2i召回和u2i召回的优点，我们设计了一种兼具i2i召回能力的u2i召回模型。具体而言，双塔召回模型是多任务目标，在传统双塔u2i的BCE-Loss基础上，在user塔中引入了基于兴趣对齐的对比学习损失，通过最大化相同兴趣下用户嵌入与物品嵌入之间的相似性，同时最小化不同兴趣下用户嵌入与物品嵌入之间的相似性，从而在预估阶段能够基于用户新兴趣生成与之高相关度的user-embedding。这样得到的embedding用于向量检索召回，召回得到的item集合不仅与新兴趣保持了高度的相关性，同时保持了u2i召回的消费效率高的优点。

模型输入

用户塔的输入特征包括:用户静态画像如：年龄、性别等，用户历史交互物品序列特征如类目、品牌、标签等，这些特征通过id-emddding的方式表征为fᵘ；用户兴趣，用户兴趣通过文本编码器获得

embedding

。在训练阶段，用户兴趣正样本是用户点击过的物品，用户兴趣负样本是batch内采样的其他物品，在推理阶段，用户兴趣是通过两跳推理生成的潜在新兴趣。文本编码器可以选择 CLIP、BERT、USE、BGE 等模型, 在我们的实验中，我们选择了 CLIP 作为编码器。值得注意的是，大模型推理出来的新兴趣只在推理的时候使用，而不参与到训练过程中。

双塔模型

物品塔的输入包含：物品的静态特征，如：类目体系、品牌、标签等，这些特征用id-embdedding进行表征

用户塔：将用户特征fᵘ

和历史兴趣

拼接，通过两层全连接层得到

物料塔：将物品特征fᵘ

和历史兴趣

拼接，通过两层全连接层得到

训练阶段

通过双塔模型来训练用户点击样本同时，我们希望对于同一用户，不同的z输入user塔后得到的兴趣表征具有较大的区分度：

兴趣下的用户兴趣表征

要与同为

兴趣

的物品表征更加相关，他们之间的关联度要大于其他

兴趣下的用户兴趣表征

与

兴趣的物品表征。这样就能尽可能做到，输入用户的潜在兴趣给到user towel的时候，就能获取到用户新颖性兴趣的表征而不至于与已有的兴趣混淆。

因此，我们引入了对比学习

综合以上考虑，我们采用多目标联合训练的方法，采用multi-task loss，由对比学习损失和二分类交叉熵损失构成：

其中，

是模型的参数集合，

 和

 是超参数。

另外交叉熵损失用于建模用户对历史物品的点击偏好，其公式为：

其中，

 是对物品 

 的点击概率的预测值。

预估阶段

在预估阶段，首先将用户的某个潜在新兴趣

(1<=k<=n，n为用户u潜在新兴趣总数)连同用户特征一起输入user塔，获得用户新兴趣表征向量

。利用

进行ann检索得到物品集合，作为潜在兴趣

的召回结果。将用户所有的潜在新兴趣的召回结果归并在一起，与其他召回通道内容一同给到后续的推荐链路中。

五、实验效果

我们在得物App（Dewu)上进行实验，得物App是一个拥有数千万用户的潮流电子商务平台。我们随机选取了得物社区10%的流量来进行A/B实验，目标是基于用户历史搜索词和静态画像，生成用户潜在兴趣，并为其推荐意外物品。我们选择得物原有的社区推荐召回系统作为基线，使用CLIP模型作为兴趣文本encoder，在此基础上为新颖性推荐新增了一个召回渠道。

我们使用8个指标来衡量在线性能：人均时长（AVDU），UVCTR，人均阅读量（ACR），UV互动渗透（ER），人均一级类目点击数（ACC-1），人均三级类目点击数（ACC-3），一级类目新颖性曝光占比（ENR）和一级类目新颖性点击占比（CNR）。其中人均一级类目点击数，人均三级类目点击数是用于评估多样性的指标。我们将一级类目新颖性定义为：当某物品的一级类目不在用户最近200次点击记录的一级类目集合内时，该物品的曝光或点击即具有一级类目新颖性。通过计算一级类目新颖性曝光占所有曝光的比例，以及一级类目新颖性点击占所有点击的比例，评估推荐系统的新颖性表现。

我们用deepseek-r1生成的3万条数据做标注样本，对qwq-32b模型经过sft后得到模型interestGPT，使用离线评估标准对interestGPT在1万条测试集上评估，抽样1000个用户评估结果如下： 0分占比：1%，1分占比：3%，2分占比：96%。

为了评估我们方法的在线效果，我们随机选取了大盘10%的流量进行A/B测试。我们在基线的基础上，为新颖性推荐新增了一个召回渠道。在新颖性召回渠道中，我们基于用户最近30天的用户搜索行为进行潜在兴趣拓展，每个用户最多选择16个潜在兴趣，每个兴趣召回40个对应的item。然后将这一路召回与其他渠道融合得到最终的召回结果。

最终的线上实验效果如下：

和baseline相比，我们的方法显著提升了推荐结果的多样性和新颖性。我们的方法在AVDU上相对提升0.15%。 UVCTR、ACR和ER分别提升了0.07%，0.15%，0.3%。在多样性方面，ACC-1 和ACC-3分别取得了0.21% 和0.23%的提升。对于新颖性，ENR和CNR分别取得了4.62%和4.85%的显著提升。

新颖性召回渠道对于推荐内容多样性和新颖性的改善是持续的。对照组的曝光新颖率为14.24%，实验组中新颖性召回通道的召回新颖率为26.53%，其他通道的召回新颖率为16.17%。这说明，当新颖性召回引入了新的信号，用户进行了新的交互，产生了和新兴趣有关的训练数据之后，其他召回通道也能够迅速捕捉到用户的新兴趣信号，从而打破反馈循环现象，冲破推荐茧房。

六、结论

这项工作通过提出利用大模型构建用户动态知识图谱并通过两跳推理来解决推荐系统中的信息茧房问题。 它包括两个阶段：两跳推理，通过大语言模型将用户静态画像和历史行为动态构建用户知识图谱，在构建的图谱上进行两跳推理；近线自适应，用于高效的工业部署。 同时设计了一种兼具i2i召回能力的u2i模型，召回得到的item集合不仅与新兴趣保持了高度的相关性，同时保持了u2i召回的item消费效率高的优点。

并部署了训练推理解耦的召回模型，利用大模型产出的新兴趣，生成对应的多兴趣user-embedding，将用户潜在兴趣召回结果集成到推荐系统中。无论是离线还是在线实验都取得了显著收益，完全可以在大规模工业系统上部署并拿到收益。

七、总结与展望

目前，我们主要基于得物App中的用户搜索行为构建兴趣挖掘模型。由于搜索行为本身具有较高的稀疏性，未来将引入点击、浏览、收藏等更丰富的交互行为，以探究在多行为数据融合下大语言模型对用户潜在兴趣的刻画能力，并验证兴趣建模是否存在与数据规模相关的扩展规律。在系统应用层面，除了在召回环节引入用户新兴兴趣外，还可进一步将兴趣表征融合至粗排、精排及重排等排序阶段，从而提升新兴趣场景下的物品评分准确性。此外，也可结合推荐场景中的实时用户反馈数据，对模型输出的多元兴趣进行动态校准，避免兴趣过度发散，确保其与用户真实需求的相关性。在大模型生成式架构基础上，我们同步探索并构建了生成式召回模型，目前已取得初步成果，并在得物推荐场景中全面上线应用。未来，我们将持续加大该方向的研发投入。

每一次技术迭代，其最终目标始终是服务于用户体验的提升。正如得物始终秉持的初心——我们希望通过智能推荐技术的持续进化，助力每一位用户更精准、更愉悦地「得到美好事物」。

往期回顾

1.Galaxy比数平台功能介绍及实现原理｜得物技术

2.得物App智能巡检技术的探索与实践 

3.深度实践：得物算法域全景可观测性从 0 到 1 的演进之路

4.前端平台大仓应用稳定性治理之路｜得物技术

5.RocketMQ高性能揭秘：承载万亿级流量的架构奥秘｜得物技术

文 /流煜曦

关注得物技术，每周更新技术干货

要是觉得文章对你有帮助的话，欢迎评论转发点赞～

未经得物技术许可严禁转载，否则依法追究法律责任。

一、背景

得物经过10年发展，计算任务已超10万+，数据已经超200+PB，为了降低成本，计算引擎和存储资源需要从云平台迁移到得物自建平台，计算引擎从云平台Spark迁移到自建Apache Spark集群、存储从ODPS迁移到OSS。

在迁移时，最关键的一点是需要保证迁移前后数据的一致性，同时为了更加高效地完成迁移工作（目前计算任务已超10万+，手动比数已是不可能），因此比数平台便应运而生。

二、数据比对关键挑战与目标

关键挑战一：如何更快地完成全文数据比对

现状痛点：

在前期迁移过程中，迁移同学需要手动join两张表来识别不一致数据，然后逐条、逐字段进行人工比对验证。这种方式在任务量较少时尚可应付，但当任务规模达到成千上万级别时，就无法实现并发快速分析。

核心问题：

• 效率瓶颈：每天需要完成数千任务的比对，累计待迁移任务达10万+，涉及表数十万张。
• 扩展性不足：传统人工比对方式无法满足大规模并发处理需求。

关键挑战二：如何精准定位异常数据

现状痛点：

迁移同学在识别出不一致数据后，需要通过肉眼观察来定位具体问题，经常导致视觉疲劳和分析效率低下。

核心问题：

• 分析困难：在比对不通过的情况下，比对人员需要人工分析失败原因。
• 复杂度高：面对数据量庞大、加工逻辑复杂的场景，特别是在处理大JSON数据时，肉眼根本无法有效分辨差异。
• 耗时严重：单次比对不通过场景的平均分析时间高达1.67小时/任务。

比数核心目标

基于以上挑战，数据比对系统需要实现以下核心目标：

• 高并发处理能力：支持每天数千任务的快速比对，能够处理10万+待迁移任务和数十万张表的规模。
• 自动化比对机制：实现全自动化的数据比对流程，减少人工干预，提升比对效率。
• 智能差异定位：提供精准的差异定位能力，能够快速识别并高亮显示不一致的字段和数据。
• 可视化分析界面：构建友好的可视化分析平台，支持大JSON数据的结构化展示和差异高亮。
• 性能优化：将用户单次比对分析时间从小时级大幅缩短至分钟级别。
• 可扩展架构：设计可水平扩展的系统架构，能够随着业务增长灵活扩容。

三、解决方案实现原理

快速完成全文数据比对方法

比数方法调研

待比对两表数据大小：300GB，计算资源：1000c

经过调研分析比数平台采用第二种和第三种相结合的方式进行比数。

先Union再分组数据一致性校验原理

假如我们有如下a和b两表张需要进行数据比对

表a：

表b：

表行数比较：

select count(1) from a ;

select count(1) from b ;

针对上面的查询结果，如果数量不一致则退出比对，待修复后重新比数；数量一致则继续字段值比较。

字段值比较：

第一步：union a 和 b

select 1 as _t1_count, 0 as _t2_count, `id`, `name`, `age`, `score`
from a
union all
select 0 as _t1_count, 1 as _t2_count, `id`, `name`, `age`, `score`
from b

第二步：sum(_t1_count)，sum(_t2_count) 后分组

select sum(_t1_count) as sum_t1_count, sum(_t2_count) as sum_t2_count, `id`, `name`, `age`, `score`
from (
select 1 as _t1_count, 0 as _t2_count, `id`, `name`, `age`, `score`
from a
union all
select 0 as _t1_count, 1 as _t2_count, `id`, `name`, `age`, `score`
from b
) as union_table
group by `id`, `name`, `age`, `score`

第三步：把不一致数据写入新的表中(即上面表中sum_t1_count和sum_t2_count不相等的数据)

drop table if exists a_b_diff_20240908;
create table a_b_diff_20240908 as select * from (
select sum(_t1_count) as sum_t1_count, sum(_t2_count) as sum_t2_count, `id`, `name`, `age`, `score`
from (
select 1 as _t1_count, 0 as _t2_count, `id`, `name`, `age`, `score`
from a
union all
select 0 as _t1_count, 1 as _t2_count, `id`, `name`, `age`, `score`
from b
) as union_table
group by `id`, `name`, `age`, `score`
having sum(_t1_count) <> sum(_t2_count)
) as tmp

如果a_b_diff_20240908没有数据则两张表没有差异，比数通过，如有差异如下：

第四步：读取不一致记录表，根据主键（比如id）找出不一致字段并写到结果表中。

第五步：针对不一致字段的数据进行根因分析，如 json 、数组顺序问题、浮点数精度问题等，给出不一致具体原因。

哈希值聚合实现高效一致性校验

针对上面union后sum 再 group by 方式 在数据量大的时候还是非常耗资源和时间的，考虑到比数任务毕竟有70%都是一致的，所以我们可以先采用哈希值聚合比较两表的的值是否一致，使用这种高效的方法先把两表数据一致的任务过滤掉，剩下的再采用上面方法继续比较，因为还要找出是哪个字段哪里不一致。原理如下：

SELECT count (*),SUM(xxhash64(cloum1)^xxhash64(cloum2)^...) FROM tableA 
EXCEPT 
SELECT count(*),SUM(xxhash64(cloum1)^xxhash64(cloum2)^...) FROM tableB

如果有记录为空说明数据一致，不为空说明数据不一致需要采用上面提到union 分组的方法去找出具体字段哪里不一样。

通过哈希值聚合，单个任务比数时间从500s降低到160s，节省大约70%的时间。

找到两张表不一致数据后需要对两张的数据进行分析确定不一致的点在哪里？这里就需要知道表的主键，根据主键逐个比对两张表的其他字段，因此系统会先进行主键的自动探查，以及无主键的兜底处理。

精准定位异常数据实现方法

自动探查主键：实现原理如下

刚开始我们采用的前5个字段找主键的方式，如下：

针对表a的前5个字段 循环比对
select count(distinct id) from a 与 select count(1) from a 比较 ，如相等主键为id ，不相等继续往下执行
select count(distinct id,name) from a 与 select count(1) from a比较，如相等主键为id,name ，不相等继续往下执行
select count(distinct id,name,age) from a 与 select count(1) from a比较，如相等主键为id,name,age ，不相等继续往下执行，直到循环结束

采用上面的方法不一致任务中大约有49.6%任务自动探查主键失败：因此需重点提升主键识别能力。

针对以上主键探查成功率低的问题，后续进行了一些迭代，优化后的主键探查流程如下：

一、先采用sum(hash)高效计算方式进行探查：

1.先算出两张表每个字段的sum(hash)值  。

select sum(hash(id)),sum(hash(name)),sum(hash(age)),sum(hash(score)) from a 
union all 
select sum(hash(id)),sum(hash(name)),sum(hash(age)),sum(hash(score)) from b;

2.找出值相等的所有字段，本案例中为 id, name。

3.对id，name 可能是主键进一步确认，先进行行数校验，如 select count(distinct id,name) from a 的值等于select count(1) from a 则进一步校验，否则进入到第二种探查主键方式。

4.唯一性验证，如果值为0则表示探查主键成功，否则进入到第二种探查主键方式。

slect count(*) from ((select id,name from a ) expect (select id,name from b))

二、传统distinct方式探查：

针对表a的前N（所有字段数/2或者前N、后N等）个字段 循环比对：

1.select count(distinct id) from a与select count(1) from a比较 ，如相等主键为id ，不相等继续往下执行。

2.select count(distinct id,name) from a 与 select count(1) from a比较，如相等主键为id,name ，不相等继续往下执行。

3.select count(distinct id,name,age) from a 与 select count(1) from a比较，如相等主键为id,name,age ，不相等继续往下执行，直到循环结束。

三、全字段排序模拟:

如果上面两种方式还是没有找到主键则把不一致记录表进行全字段排序然后对第一条和第二条记录挨个字段进行分析，找出不一致内容，示例如下：

slect * from a_b_diff_20240908 order by id,name,age,score asc limit 10;

通过以上结果表可以得出两表的age字段不一致 ，score不一致（但按key排序后一致）。

如果以上自动化分析还是找不到不一致字段内容，可以人工确认表的主键后到平台手动指定主键字段，然后点击后续分析即可按指定主键去找字段不一致内容。

通过多次迭代优化找主键策略，找主键成功率从最初的50.4%提升到75%，加上全字段order by排序后最前两条数据进行分析，相当于可以把找主键的成功率提升到90%以上。

根因分析：实现原理如下

当数据不一致时，平台会根据主键找出两个表哪些字段数据不一致并进行分析，具体如下：

• 精准定位： 明确指出哪条记录、哪个字段存在差异，并展示具体的源数据和目标数据值。
• 智能根因分析： 内置了多种差异模式识别规则，能够自动分析并提示不一致的可能原因，例如：
• 精度问题：如浮点数计算1.0000000001与1.0的差异。
• JSON序列化差异：如{"a":1, "b":2}与{"b":2, "a":1}，在语义一致的情况下，因键值对顺序不同而被标记为差异。同时系统会提示排序后一致。
• 空值处理差异：如NULL值与空字符串""的差异判定。
• 日期时区转换问题：时间戳在不同时区下表示不同。

• 比对结果统计： 提供总数据量、一致数据量、不一致数据量及不一致率百分比，为项目决策提供清晰的量化依据。
• 比数人员根据平台分析的差异原因，决定是否手动标记通过或进行任务修复。
• 效果展示：

四、比数平台功能介绍

数据比对基本流程

任务生成：三种比对模式

• 两表比对： 最直接的比对方式。用户只需指定源表与目标表，平台即可启动全量数据比对。它适用于临时比对的场景。
• 任务节点比对： 一个任务可能输出多个表，逐一配置这些表的比对任务繁琐且易遗漏，任务节点比对模式完美解决了这一问题。用户只需提供任务节点ID，平台便会自动解析该节点对应的SQL代码，提取出所有输出表，并自动生成比对任务，极大地提升任务迁移比对效率。
• SQL查询比对： 业务在进行SDK迁移只关心某些查询在迁移后数据是否一样，因此需要对用户提交的所有查询SQL进行比对，平台会分别在ODPS和Spark引擎上执行该查询，将结果集导出到两张临时表，再生成比对任务。

前置校验：提前发现问题

在启动耗时的全量比对之前，需要对任务进行前置校验，确保比对是在表结构一致、集群环境正常的情况下进行，否则一旦启动比数会占用大量计算资源，最后结果还是比数不通过，会影响比数平台整体的运行效率。因此比数平台一般会针对如下问题进行前置拦截。

• 元数据一致性校验： 比对双方的字段名、字段类型、字段顺序、字段个数是否一致。
• 函数缺失校验： 针对Spark引擎，校验SQL中使用的函数是否存在、是否能被正确识别，避免因函数不支持而导致的比对失败。
• 语法问题校验： 分析SQL语句的语法结构，确保其在目标引擎中能够被顺利解析，避免使用了某些特定写法会导致数据出现不一致情况，提前发现语法层面问题，并对任务进行改写。

更多校验点如下：

通过增加以上前置校验拦截，比数任务数从每天3000+下降到1500+， 减少50% 的无效比数，其中UDF缺失最多，有效拦截任务1238，缺少函数87个（帮比数同学快速定位，一次性解决函数缺失问题，避免多次找引擎同学陆陆续续添加，节省双方时间成本）。

破解比数瓶颈：资源分配与任务调度优化

由于比数平台刚上线的时候只有计算迁移团队在使用，后面随着更多的团队开始使用，性能遇到了如下瓶颈：

1.资源不足问题： 不同业务（计算迁移、存储迁移、SDK迁移）的任务相互影响，基本比数任务与根因分析任务相互抢占资源。

2.任务编排不合理： 没有优先级导致大任务阻塞整体比数进程。

3.引擎参数设置不合理： 并行度不够、数据分块大小等高级参数。

针对以上问题比数平台进行了如下优化：

• 按不同业务拆分成多个队列来运行，保证各个业务之间的比数任务可以同时进行，不会相互影响。
• 根因分析使用单独的队列，与数据比对任务的队列分开，避免相互抢占资源发生“死锁”。
• 相同业务内部按批次分时段、分优先级运行，保障重要任务优先进行比对。
• 针对Spark引擎默认调优了公共参数、并支持用户自主设置其他高级参数。

通过以上优化达到到了如下效果：

• 比数任务从每天22点完成提前至18点前，同时支持比数同学自主控制高优任务优先执行，方便比数同学及时处理不一致任务。
• 通过优化资源队列使用方式，使系统找不到主键辅助用户自主找主键接口响应时间从58.5秒降到 26.2秒。

五、比数平台收益分享

平台持续安全运行500+天，每日可完成2000+任务比对，有效比数128万+次，0误判。

• 助力计算迁移团队节省45+人日/月，完成数据分析、离线数仓空间任务的比对、交割。
• 助力存储迁移团队完成20%+存储数据的迁移。
• 助力引擎团队完成800+批次任务的回归验证，确保每一次引擎发布的安全及高效。
• 助力SDK迁移团队完成80%+应用的迁移。

六、未来演进方向

接下来，平台计划在以下方面持续改进：

智能分析引擎： 针对Json复杂嵌套类型的字段接入大模型进行数据根因分析，找出不一致内容。

比对策略优化： 针对大表自动切分进行比对，降低比数过程出现因数据量大导致异常，进一步提升比对效率。

通用方案沉淀： 将典型的比对场景和解决方案能用化，应用到更多场景及团队中去。

七、结语

比数平台是得物在迁移过程中，为了应对海量任务、大数据量、字段内容复杂多样、异常数据难定位等挑战，确保业务迁移后数据准确而专门提供的解决方案，未来它不单纯是一个服务计算迁移、存储迁移、SDK迁移、Spark版本升级等需要的数据比对工具，而是演进为数据平台中不可或缺的基础设施。

往期回顾

1.得物App智能巡检技术的探索与实践

2.深度实践：得物算法域全景可观测性从 0 到 1 的演进之路 

3.前端平台大仓应用稳定性治理之路｜得物技术

4.RocketMQ高性能揭秘：承载万亿级流量的架构奥秘｜得物技术

5.PAG在得物社区S级活动的落地

文 /Galaxy平台

关注得物技术，每周更新技术干货

要是觉得文章对你有帮助的话，欢迎评论转发点赞～

未经得物技术许可严禁转载，否则依法追究法律责任。