大数据测试实践之全量改增量（上）

大家好，我是rainbowzhou。

今晚，我在知识星球：测试人员生存指南的线上会议里，与星球伙伴们进行了大数据测试主题的分享，此篇为《大数据测试实践之全量改增量》上半部分的文字版～

项目背景

现有存量项目使用了阿里云的Datawork服务，多个服务商在上面进行ETL的开发和协作。现在面临的问题包括各个服务商在进行ETL时存在命名设计不规范的问题，以及想对数据的存储方式进行部分优化，由全量存储改为增量存储。

全量改增量方案设计

现状分析

1. 客户想要改造的表范围是多少，受影响的表有多少？
   • 初始计划涉及A系统3张表，B系统8张表，后经过与客户沟通确认全量改增量涉及A系统1张表，替换依赖1张表（解决同径不同名问题），剔除1张表，B系统8张表维持不变，最终期望是10张表进行改造升级，受影响的表为9张全量表、上游依赖这些表的数据表有7张，总计16张表，可通过数据血缘图分析得出。
2. 是否能确定业务主键与增量标识字段，存量数据与增量数据的计算方式与存储周期是否有要求？
   • 方案1：直接与客户讨论，或者等待客户问询具体业务人员反馈后得到具体业务主键与增量标识字段；存量和增量计算方式改造前后对数据的最终结果无影响，存储周期按业务特点进行设置。
   • 方案2：根据数据字典和Code Review对应的SQL代码，凭经验判定业务主键与增量标识字段，提供对应改造设计文档，包含存储方式改变的意义、多种存储方案的提供、相应Demo方案演示与讲解、准出标准与预期管理，和客户讨论一致后开始执行。（笔者采用的方案2）
3. 现有数据是否存在异常？改造前后的预期是什么？
   • 对现有数据库和表进行数据探查，包含对应空间下的库、表等详细信息，着重关注数据量、数据大小、调度周期、调度依赖。
   • 解决部分命名不规范问题，改造前后对已有任务的数据结果影响可忽略不计。

存储方式改变的意义

• 增量存储可以降低存储成本、提高查询性能，但可能存在数据不一致的问题；
• 全量存储可以确保数据一致性、简化数据处理逻辑，但需要占用更多的存储空间和计算资源。
• 根据具体场景和需求选择合适的存储策略。

扩展：Dataworks收费类型和其他可能产生的费用

• 数据库费用：数据同步时，读写上下游数据库中的数据可能会产生数据库费用。
• 计算和存储费用：运行计算引擎任务时可能会产生计算和存储费用。例如，运行一个MaxCompute的SQL任务，新建表并写入表数据可能会产生MaxCompute的计算和存储费用。
• 网络服务费用：连通DataWorks和其他相关产品的网络环境时可能会产生网络服务费用。例如，使用高速通道、共享带宽、EIP等产品连通网络时会产生相应产品的服务费用。

存储方案

• 方案1：单次存储已有某一天的全量数据作为基础数据，存储周期改为永久，调度周期不设置；新增增量表，存储增量数据，存储周期改为永久，则每天的全量数据为基础数据+全部的增量数据。
• 方案2：某天的全量数据，存储周期不变仍为30天（超30天后自动清理），调度周期设置为每月一次；新增增量表，存储增量数据，存储周期同为30天，调度周期为每天，当月的每天进行合并处理得到全量数据，为防止数据不一致问题，月末进行全量覆盖。

合并方式

• 通过确认的业务主键进行合并，连接方式可使用LEFT/FULL OUTER JOIN，则新增的数据可以合并到全量表中，若发现存量数据有改动则以增量数据的状态为准；
• 演示讲解时客户明确说明xx_customer表不会存在删除数据的情况。

全量改增量计划实施

任务目标

• 经与客户会议讨论，最终得出本次任务的Target：

计划实施细节

每张表的具体任务如下：

• 在开发环境创建相应的增量表、增量任务（创建增量表时需注意源表与目标表对应的字段的映射关系）；
• 再创建对应的merge任务编写相应的SQL代码；
• 最后再修改任务的调度周期。

上篇先介绍项目背景、方案设计、计划实施的内容，下篇将介绍全量改增量数据验证、全量改增量思考的内容，未完待续～

以上，有任何想法都欢迎大家后台私信我，一起探讨交流。