实时数仓投放主备链路 Diff 测试工具落地实践
一、背景
目前实时数仓提供的投放实时指标优先级别越来越重要，特别下游为规则引擎提供的数仓数据，直接对投放运营的广告投放产生直接影响，数据延迟或者异常均可能产生直接或者间接的资产损失；从投放管理平台的链路全景图投放全景图来看，目前投放是一个闭环的运行流程，实时数仓处于数据链路中的关键节点，实时数据直接支持规则引擎的自动化操作，以及投放管理平台的手动控盘；实时节点事故，将可能导致整个投放链路无法正常运行；为使投放链路达到 99.9%的稳定性，需要对链路任务做相关的稳定性提升，优先级提升。
研发测试综合评估方案对投放实时链路增加一条备链路，投放需求迭代，通过备链路进行迭代修改，完成修改后进行主备链路 Diff，确保 Diff 通过率 99.9%，即可上线。
二、实现方案
数据准备：主备链路产出的数据分别实时写入到 ODPS 中。
数据采集：测试工具服务同时采集主备链路数据切片，保留 2 份同一个时间周期的数据。
数据降噪 &Diff：工具采集数据后将进行第一步的降噪处理；主备数据开始对比 &第二步降噪处理。
数据 Diff 结果：加工数据对比的结果，判断出每个字段的差异量，再最终判断出整体数据的差异量，给出结果。
三、搭建主备链路
实时链路解释：源头数据写入 Kafka，Flink 消费 Kafka 数据作为数据源（Source），结合属性字段做算子加工处理（Transformatin），处理结果写入 Kafka（Sink），做下一步处理。经过一个个 Flink 任务节点加工分流到应用数据库中。
四、数据准备-数据切片
时间窗口切片
根据测试时间点，进行切片，取当天 0 点～执行时间段数据进行固定，确保数据不再更新。
业务场景切片
不同业务场景迭代进行切片，下发数据流提供多种下游场景数据，针对发生迭代的业务场景数据进行切片固定。如：fields_a='b'
五、主备链路数据 Diff-去噪
数据漂移问题
问题现象：数据流在不断更新，同一条业务数据的数据流更新的最新的一条，主链路可能进入当天分区中，备链路可能进入到第二天分区中。
去噪方案：数据流取末尾 1 条数据。
数据更新频率问题
问题现象：同一条业务数据在更新过程中，主链路可能发生了 10 次更新，后面五次数据不发生改动，备链路只发生了 5 次更新。
去噪方案：同一个业务数据取数据流的 N 条数据。
数据更新时效问题
问题现象：同一条业务数据更新过程中，主链路更新三个数据为 11.68、12.9、13.05；备链路更新三个数据为 11.68、12.9、13.1；可以看出后面 1 次更新的数据并不一样。
去噪方案：同一个业务数据的数据流融合成一个 list，主备相互判断末尾数据是否存在于对方截取的数据流 list 中。
属性字段值不统一问题
问题现象：存在空字符和 null、0 和 0.0 的情况，Diff 结果为不通过，实际业务含义是 OK 的。
去噪方案：统一转换后进行 Diff。
主备链路 message 字段解析属性字段不一致问题
问题现象：message 字段存储数据 JSON 格式。同一条业务数据，主备链路解析的 JSON 对应的属性字段并不是完全一致的，两者之间存在差异。
去噪方案：通过代码解析出全量的属性字段，确保可以完全 Diff。
message 范本：
转换 JSON：
以上五点问题可以通过 SQL 进行去噪，整体去噪 SQL 范本如下：
字段去噪问题
问题现象：涉及字段逻辑修改的情况下，Diff 结果是不通过的，影响 Diff 结果。
去噪方案：需要对逻辑修改的字段抛弃，不再判断发生逻辑修改的字段，通过 Java 灵活控制。
六、Diff 结果分析
根据主备 Diff 合成的 SQL 可以产出对比的结果表，对执行结果分析既可以判断本次执行是否通过。
分析逻辑 1：判断每一个对比字段通过占比
提供研发分析哪一个解析的字段通过率低.
分析逻辑 2：判断所有字段通过占比总记录数
此指标即可判断本次 Diff 是否通过，如果占比 99.9%，表示通过。
分析 SQL 样本：
七、工具服务化
后端服务化处理逻辑
主备对比 SQL 合成
将 Diff 的 SQL 植入到代码中，通过代码控制数据切片、去噪等场景，完成测试 SQL 合成。
Diff 结果报告解析
平台可视化
创建任务
执行列表
结果报告-平台展示
如下图：一次执行失败的结果，通过率为 99.8471，未达到 99.99%。
结果报告-飞书通知
如下样例：
执行需求名称：主备 Diff-521 执行者：*** 执行类型：主备 Diff 执行编号：20230628204636 执行备链路表名：table_main 执行主链路表名：table_branch 执行备链路表分区：20230628 执行结果明细表：table_diff 执行结果明细汇总： fields_am_ratio:99.9958 fields_z_ratio:99.9826 fields_af_ratio:99.9856 fields_ba_ratio:99.9964 fields_al_ratio:99.9915 fields_ad_ratio:99.9873 fields_r_ratio:99.9826 fields_aa_ratio:99.9906 fields_ai_ratio:99.9856 fields_v_ratio:99.9917 fields_ak_ratio:99.9909 fields_m_ratio:99.9969 fields_ak_ratio:99.9945 fields_bb_ratio:99.9964 fields_bc_ratio:99.9957 fields_bd_ratio:99.9954 fields_ae_ratio:99.9856 fields_be_ratio:99.9952 fields_bf_ratio:99.9955 fields_t_ratio:99.9917fields_ag_ratio:99.9856 fields_p_ratio:99.9909 fields_bg_ratio:99.9948 fields_a_ratio:99.9969 fields_d_ratio:99.9969 fields_x_ratio:99.9826 fields_an_ratio:99.9917fields_ap_ratio:99.9909 fields_ar_ratio:99.9915 fields_y_ratio:99.9917 fields_bh_ratio:99.9955 fields_aj_ratio:99.9916 fields_bi_ratio:99.987 fields_ac_ratio:99.9908 fields_s_ratio:99.9826 fields_ab_ratio:99.9906 fields_i_ratio:99.9969 fields_bj_ratio:99.9951 fields_ah_ratio:99.9959fields_k_ratio:99.9969fields_e_ratio:99.9969 fields_bk_ratio:99.9962 fields_bl_ratio:99.8748 fields_al_ratio:99.9958 fields_j_ratio:99.9969fields_bm_ratio:99.9951 fields_n_ratio:99.9969 fields_ao_ratio:99.9909 fields_w_ratio:99.9906 fields_bn_ratio:99.9965 fields_bo_ratio:99.9912 fields_bcrate_ratio:99.987 fields_y_ratio:99.9958 主备 diff 执行结果汇总数据： total_ratio:99.8471total_cnt:714259 执行结果失败明细：fields_bl_ratio:99.8748total_ratio:99.8471% 执行结果状态：失败
八、主备 diff 工具接入发布流程
投放备链路最终经过主备 Diff 工具测试通过的情况下，完成上线，目前相当于一条备用生产线。
后续版本迭代，需求上线前通过 Diff 工具验证通过，即可符合上线要求。
九、总结
实时计算不同于离线数仓，数据的稳定性和准确性很难把控，复杂的链路通过简单的测试无法保障整体数据的质量，双链路 Diff 的形式可以在迭代中更好保障实时数据的质量。
对于主备 Diff 的实现中：最大的痛点往往是数据的噪点非常的大，需要通过技术手段进行降噪，确保数据对比结果的准确性和可靠性。
*文/诗雨
本文属得物技术原创，更多精彩文章请看：得物技术官网
未经得物技术许可严禁转载，否则依法追究法律责任！
版权声明: 本文为 InfoQ 作者【得物技术】的原创文章。
原文链接:【http://xie.infoq.cn/article/d512345fd68736348fd3fb17e】。文章转载请联系作者。
得物APP技术部 2019-11-13 加入
关注微信公众号「得物技术」
评论