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

一、背景

得物经过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平台

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

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

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

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/1191315.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

上位机软件开发中串口超时机制的设计实践

串口通信“卡死”怎么办&#xff1f;上位机超时机制的实战设计之道你有没有遇到过这样的场景&#xff1a;上位机软件点击“读取参数”&#xff0c;界面瞬间“假死”&#xff0c;鼠标动不了&#xff0c;任务管理器都救不回来&#xff1f;等了整整30秒&#xff0c;才弹出一个“设…

Eclipse 打开报 `An error has occurred. See the log null` 错误及解决方法

Eclipse 打开报 An error has occurred. See the log null 错误及解决方法 项目场景&#xff1a; 在日常 Java 开发中&#xff0c;Eclipse 是最常用的开发工具之一。我们在 Windows 系统中使用 Eclipse 时&#xff0c;有时会遇到突然无法打开 Eclipse 的情况&#xff0c;报错信…

第七篇:告别手动拼 URL!我们封装自己的“地图超市”

View Post第七篇:告别手动拼 URL!我们封装自己的“地图超市”本专栏旨在手把手带你从零开始,基于开源三维地球引擎 **Cesium** 封装一套功能完善、可复用的 **WebGIS 增强型 SDK**。内容涵盖核心封装思路、关键代码…

基于微信小程序的小区租车拼车系统【源码+文档+调试】

&#x1f525;&#x1f525;作者&#xff1a; 米罗老师 &#x1f525;&#x1f525;个人简介&#xff1a;混迹java圈十余年&#xff0c;精通Java、小程序、数据库等。 &#x1f525;&#x1f525;各类成品Java毕设 。javaweb&#xff0c;ssm&#xff0c;springboot等项目&#…

数字频率计设计超详细版:基本结构与工作流程讲解

以下是对您提供的博文《数字频率计设计超详细版&#xff1a;基本结构与工作流程讲解》的深度润色与专业重构版本。本次优化严格遵循您的全部要求&#xff1a;✅ 彻底去除AI痕迹&#xff0c;语言自然、有“人味”&#xff0c;像一位资深嵌入式工程师在技术博客中娓娓道来&#x…

35岁转行学了网络安全,能谋生吗?

35岁转行学了网络安全&#xff0c;能谋生吗&#xff1f; 35岁转型搞安全是否还有戏&#xff1f; 放眼现在安全圈 00后的黑客CEO已经出场了 18岁的少年也开始穿梭于微软、谷歌、苹果各大国际公司的安全致谢榜 年轻的黑客们早已登上国际舞台&#xff0c;开始在世界顶级黑客大…

VitePress 进阶指南:自动化侧边栏配置与 TOC 渲染深度排查

VitePress 进阶指南:自动化侧边栏配置与 TOC 渲染深度排查VitePress 进阶指南:自动化侧边栏配置与 TOC 渲染深度排查 在使用 VitePress 搭建文档系统时,随着文件数量的增加,手动维护 .vitepress/config.ts 中的 si…

ERROR. pos 145, line 2, column 21, token COMMA 报错已解决

ERROR. pos 145, line 2, column 21, token COMMA 报错已解决 在软件开发过程中&#xff0c;尤其是 Java、C 以及基于模板的配置文件中&#xff0c;偶尔会遇到编译器或 IDE 报出的类似如下错误&#xff1a; ERROR. pos 145, line 2, column 21, token COMMA虽然错误提示看起来枯…

前端指纹技术是如何实现的?(Canvas、Audio、硬件API 核心原理解密)

什么是设备指纹&#xff1f;在讲实现之前&#xff0c;先纠正一个误区&#xff1a;设备指纹&#xff08;Device Fingerprint&#xff09;不是为了知道你是张三&#xff0c;而是为了知道 这台设备是编号 9527。它的核心逻辑只有一条&#xff1a;利用浏览器暴露的硬件底层差异&…

vivado安装资源推荐:新手自学的最佳路径

Vivado 安装指南&#xff1a;从零开始搭建 FPGA 开发环境 你是不是也曾在搜索“vivado安装”时&#xff0c;被一堆杂乱的教程、失效的链接和复杂的系统要求搞得头大&#xff1f; 明明只是想学点 FPGA 基础逻辑设计&#xff0c;结果第一步—— 装软件 &#xff0c;就卡了三天…

LLM动态调参医疗设备故障预警提前30%

&#x1f4dd; 博客主页&#xff1a;Jax的CSDN主页 LLM动态调参&#xff1a;医疗设备故障预警提前30%的范式突破 目录 LLM动态调参&#xff1a;医疗设备故障预警提前30%的范式突破 1. 引言&#xff1a;医疗设备故障的隐性危机 2. 现有预警系统的瓶颈与LLM的破局点 3. LLM动态调…

uni-app使用北斗卫星实现离线定位

权限配置仍然采用 HTML5 的定位方法&#xff0c;首先需要打开定位权限&#xff1a;// manifest.json/* 模块配置 */ "modules" : {"Geolocation" : {}, // 启用定位模块}, /* 应用发布信息 */ "distribute" : {/* android打包配置 */"andr…

React 官方纪录片观后:核心原理解析与来龙去脉

你真的理解 React 的运作方式吗&#xff1f;这段时间在回顾自己过去几年的 React 项目时&#xff0c;我发现一个有点尴尬但很真实的情况&#xff1a; 我能熟练写Hooks、拆组件、做性能优化&#xff0c;但如果有人让我用几分钟解释清楚——React 内部到底是怎么运作的&#xff0…

Java中构建前端可视化维度指标列表:从代码实现到最佳实践

在后端对接前端可视化需求&#xff08;比如雷达图、多维度评分展示&#xff09;时&#xff0c;经常需要把数据库中分散的字段&#xff0c;转换成前端友好的结构化数据格式。今天记录一段典型的“维度指标列表构建代码”&#xff0c;从实现逻辑到优化思路一次性讲透。 一、需求背…

AI法律文书准确性测试方法论

一、风险背景与技术挑战 当前法律AI工具在生成起诉状、合同等文书时存在三类核心风险&#xff1a;虚构法条&#xff08;如评测中出现的错误法条引用&#xff09;、逻辑矛盾&#xff08;如将"双方约定"误用为"甲方必须"的强制性表述&#xff09;及过时条款…

跨境电商“防关联”实战指南:把风险挡在账号之外

跨境平台的风控越来越“聪明”&#xff1a;同一批设备、网络、支付、收货、资料、操作习惯之间&#xff0c;只要出现可被平台归因的“共同点”&#xff0c;就可能触发关联审查&#xff0c;轻则限流、二审&#xff0c;重则直接封号、资金冻结。防关联不是“玄学”&#xff0c;核…

别管,咱们前端人有自己的拼夕夕~

这份清单&#xff0c;是无数次面试复盘后沉淀下来的“考点最大公约数”&#xff0c;是八股文里的精华。它由十六个经典模块构成&#xff0c;像积木一样&#xff0c;能拼出绝大多数大厂面试的轮廓&#xff1a; 1.JavaScript 深度解剖室&#xff1a;这里不问“怎么用”&#xff…

大家有空就去看这份前端宝典,真的能提高level

如果你感觉刷了无数八股文、背了各种框架API&#xff0c;面试时依然被问到哑口无言——问题可能不在于你不够努力&#xff0c;而在于你努力的方向&#xff0c;恰好错过了当前面试真正的筛选逻辑。 如今的前端面试&#xff0c;已经形成了一套高度标准化的「能力探测模型」&…

2026年国内GEO优化服务商深度评测:数据监测能力对比分析

本文深度评测 2026 年国内 GEO 优化服务商 TOP5,重点分析数据监测能力与服务透明度的核心差异。AIDSO 爱搜凭借公域开放、实时监测、白盒交付三大优势领跑行业,覆盖 10 个主流 AI 平台,为企业提供从数据诊断到效果验…

从策划到执行一站式服务,苏州合肥江苏南京双节美陈设计公司甄选

当节日的灯火渐次点亮&#xff0c;城市的脉搏也随之跃动。一场深入人心的节日氛围营造&#xff0c;不仅在于瞬间的视觉惊艳&#xff0c;更在于从概念萌芽到圆满呈现的完整旅程。在长三角的活力版图上&#xff0c;从苏州的精致园林到南京的厚重人文&#xff0c;从合肥的创新节奏…