引言

Hadoop集群的计算和数据处理能力随着集群规模的增长逐渐形成了一个弥漫天际的浩翰空间，处于其中的各种数据应用、采集作业、数据分析、数据挖掘，以及前沿的机器学习、人工智能等都如同空间中的一朵朵云彩，此消彼长。Hadoop集群根据业务提起的请求按需动态分配计算资源、数据空间，虽然业务的需求是复杂多变的，但是对于大规模的Hadoop集群来说，整体的计算能力需求则始终是平滑的。这正是云计算的特点，而为了应对这样一个动态的计算资源，仅仅通过前几弹描述的一些含有相当强烈针对性的测试作业来模拟真实状况显然是远不够完备的。

因此，我们需要对每一个新发布的Hadoop版本进行真实的业务线作业仿真模拟回归。这种仿真回归可以最大限度的验证发布版的每个功能点是否正确可靠，检查在新版本下集群的稳定性、数据的正确性和完备性，以及运行周期是否出现变化，是否引发了新的计算热点或出现数据倾斜。本身仿真模拟回归也一直是发现bug最多的一项测试活动，通过业务线仿真回归验证的新版本，就像盖了最后一道质检认证章，能给予用户、运维和开发团队更好的上线信心。

常态化回归

业务线的回归按照规模大小来分，可以分为常态化回归和定制化回归。常态化回归一般用于小版本发布前的集成测试，作为测试周期的一部分，需要快速、简洁的定位出常规问题。因此这种类型的回归规模一般都不大，选取的业务作业往往具有广泛的代表性。此类业务作业所需的数据可以自行创建，用非真实的随机数据模拟填充业务数据，但作业内容可以是直接抽取线上的真实执行过程来模拟。业务完成后，通过自动化工具将新生结果与基线结果进行全量对比。

我们在云梯的测试中，有一个早期引入的业务线回归环境，数据和作业都比较陈旧，但是在广度覆盖面上是比较充分的，基本覆盖了广告线、搜索线和BI线三大模块。业务回归由调度系统、执行gateway和结果对比三个部分组成，执行过程中收集指标信息，判断任务执行过程的正确性，以及判断对比结果是否出现偏差。早期这个业务线都是手动执行各步骤，然后人工分析监控指标数据和对比结果，过程冗长易出错，后来有了第三弹提及的DST系统后，通过自动化工具将各步骤顺次串联执行，终于实现了业务回归一键自动化。测试人员只要坐在页面前点点鼠标，等待一段时间后看一下结果就可以了。

当然，业务线的引入和各模块的部署安装以及各步骤的理顺并非一蹴而就的事情，其间复杂度是很高的，这也是在跨机房项目之前一直沿用这个比较老的业务线做常态化回归的原因。也正是因为跨机房项目的复杂性导致沿用近两年的老数据和老作业逐渐不具备广泛的代表性，借此契机我得以了解了整个业务线仿真回归的设计过程。下面将就此进行介绍。

数据快照

既然要跑真实的业务线作业，那么就少不了需要从线上集群导入脱敏后数据（后文会提及从安全角度如何做脱敏）。显然，实现海量数据的全量模拟回归是不现实的，因为这将需要建立一个和线上集群同等规模的测试集群来做这件事情，耗费成本巨大，更体现不了测试团队在这个过程中的技术价值。当然灰度发布是一个可行的方案，但这种方式要求线上集群必须停止一段时间的对外服务或者腾出部分空间和计算资源，专门用来对新版本进行验证，对于24小时不间断且基本处于满负荷状态的云梯来说，是没法提供这样的机会来做灰度发布的。

既然不能导入全量数据，也不能通过灰度发布来模拟业务线回归，那么就只能通过导入某一天的数据来实现我们的测试目标了。于是我们在启动新的业务线设计流程后，立即开始将最近的一天数据导入到测试集群。之所以取最近的一天，是因为一般说来为了提高空间的利用率，节约存储资源，数据在结果表生成之后最快3天左右就会出现大规模的合并和删除，导致旧的原始数据出现缺漏。因此这个快照不仅要取最近的一天，还要争分夺秒的从线上拖拽到测试集群，以防止时间过长后数据被合并或删除（后面会谈一下原始数据已经缺失后怎么办）。

数据快照的取得需要从audit日志中进行分析，看前一天晚上生产作业都访问了哪些数据，好在HDFS的这些信息都是导入到hive中的，可以通过sql语句快速查询整理出这个列表，刘顺提供了这个列表，我们循惯例称呼为“刘顺列表”，这和跨机房之后的刘顺列表还是有点类似的。顺带说一下，顺哥一直是各种列表的产生源，因为执着所以专业。

这个列表并非完整的，在后面我们的实际调试过程中，不断发现某些作业需求的数据有缺失，因此需要动态的补充数据。跨机房项目中，我们启动了两个集群做业务线的仿真测试，其中一个用于固定的BI线回归，提取了2013年5月19日的数据快照，执行作业也是固定不变的，因此数据的补充是一个短暂的过程，短时间调试后，这条业务线就可以正常的工作了。而另一个集群，则汇合了几乎所有应用云梯的项目组提交各自的作业在其中进行模拟回归，这个集群更合乎线上的真实状况，用户不断提交各自的真实业务作业到云梯上进行测试，因此数据也需要经常动态补充，为此，我们这边在dst上快速开发一个页面提供给用户提交各自所需的数据文件路径，我们拿到这个信息后，就会尽快进行数据补充。开始都是人工通过distcp来拖拽数据，后来也快速迭代了自动化工具，配合简单的人肉甄别（感谢慧觉的不懈努力）实现了几乎无缝的数据补缺工作。这个集群的数据量从早期不到600TB，一直补缺增长到了1.2PB，前后一个多月的大规模业务回归模拟中，通过这个集群发现并解决了很多云梯跨机房产品的问题，其价值不可估量。

除了HDFS上的数据快照，还需要获取业务线的meta数据快照，这包括2013年5月19日当天的hive元数据信息，以及作业执行脚本等等。这些meta数据，在线上也是日新月异的，好在量并不大，在业务方的配合下，我们快速搭建了一台gateway用于BI线业务回归。而另一个多项目组配合的集群则也是模拟线上的真实情况，几乎每个项目组都单独配置了一个gateway，最终配置了16台gateway。

一切源于真实

数据快照取得之后，云梯还需要打通各类权限，以模拟线上的用户和组，同时又不能让这些用户和组无意中访问到线上，干扰了正常的生产作业。因此Namenode和Jobtracker上的用户组配置被完整的拷贝到了测试集群，但是对密码都做了修改，只保留了一个账号用于补充数据所需。测试集群所有机器都修改了/etc/hosts列表，将namenode和jobtracker地址指向了测试集群的这两个角色，测试作业所在的gateway无需任何改变就将作业跑进了测试集群。这期间也出过一次不大不小的故障，部分作业因部署的gateway疏忽修改而跑到了线上，好在密码不对，所有操作都被线上集群拒绝了。这样的双重保障最终确保了测试与线上之间的安全隔离，两者互不干扰。

除了确保数据的真实性之外，我们也同样完整的复制了调度系统“天网”，在光锐团队的大力配合下，完整的业务线作业最终成功执行。天网遵从下面四个条件调度任务作业：

1.节点的运行日志为空

2.节点存在运行失败日志

3.所有依赖的父节点已运行完毕，且状态为运行成功

4.该节点没有被人为设置成不执行（有些作业因为受环境限制不得不停止调度）

因此我们可以通过清空日志来重新调度我们需要执行的业务线作业。由于测试集群性能比不上线上，因此调度作业的先后顺序会由于执行时间不同而与线上相比发生变化，有些依赖关系上的bug也在本次模拟回归中暴露了出来。

为了真实的模拟跨机房全过程，云梯测试在业务线仿真回归中，同样仿真了跨机房全过程，可以说业务线测试集群的参与人员是跨机房项目真正的先锋部队。业务方项目的测试人员是第一批真正感受跨机房的群体。从众多客户端到云梯客户端的统一，从过去直连Namenode到启用viewfs通过zookeeper选择Namenode，从单一Namenode到federation版本的Namenode一切为二，从Datanode向一个Namenode汇报到向多个Namenode汇报，从两个Namenode在同一机房到其中一个Namenode迁移到新机房，从数据的不跨到跨机房，从副机房的副本的增加到主机房副本减少，从主副机房的数据独立到crossnode启用，业务线仿真回归集群紧密跟随着跨机房复杂而又零碎的脚步前行，确保每一次修改上线都经过了周密的验证，盖上了由云梯测试以及众多业务方项目测试团队确认的权威“质检章”。

流程图

为了更直观的说明业务线仿真回归的全部设计过程，我抽象了如下图所示的流程图，取复杂的多业务线回归集群为例：

整个过程中，云梯测试团队处于一个组织者的角色，Owner了整个项目的顺次执行，同时成为了测试集群的运维和技术支持，保障了业务方项目组测试人员可以顺畅执行各自负责的部分。同时还参与到了具体业务中，帮助业务方调查问题，甚至应业务方要求搭建了一些微型云梯集群供其执行一些非常特殊的测试。

如今跨机房项目成功上线后，回忆起那段与业务方团队浴血奋战的峥嵘岁月，虽然艰苦繁忙，但是也收获良多，这种非常难得的大型业务线仿真回归实践，更是让我站在了一个比较高的层面上得以一窥云梯这个数据海洋的洋流全貌。

正确性验证

BI业务线是一个相对来说，输入输出以及执行脚本都比较单一的以hive为基础的仿真回归测试。既然是测试就必然需要做正确性验证，我们在这个过程中，沿用以前花香设计的对比脚本的思想，全新制作了全量对比工具。在BI线执行中，我们在gateway上的hive安装了一个hook，将所有新生成的表和数据同时生成一份到我们指定的位置（这个hook也用在多业务测试集群中）。在使用老版本hadoop测试完毕后，我们将自己设定的输出路径改名保存，然后重新部署新版本再次执行BI业务线回归。这样就获得了新老两次输出结果。和BI业务方讨论出需要执行全量对比的重要表列表后，全量对比自动化脚本就会生成两张与原始表schema完全相同的新表，然后将新老两次输出的路径作为location赋值给这两张新表。再利用hive sql对这两张表执行全量对比（具体sql因涉及安全不便透露分析）。

对于其他业务项目来说，一般各自团队都有验证正确性的方案，在这次跨机房业务仿真回归中可说是八仙过海各显神通。但占据极大比例的hive相关作业都是通过上述方式进行的正确性验证。

除了结果的正确性，执行过程的正确性和完备性也是需要进行验证的，这主要由审核各类执行日志来进行判断。此外，由于涉及客户端的统一化，因此兼容性测试的执行过程正确性尤其被关注。在跨机房项目的后期，稳定性测试的7*24小时连续不间断高负荷运作过程中，也不断需要对结果和执行过程的正确性做校准。本身，正确性验证由于全量对比造成的高负载也被作为稳定性测试的一部分被不断重复执行。至于性能和指标数据的正确性则由监控系统来保证，跨机房项目不仅需要集群内的监控，还需要多机房间的网络监控，以及主机房节点与副机房节点之间数据传输的监控，在有针对性的部署了多套监控体系后，我们甚至可以通过不同的监控系统来对同一个关注指标进行证伪性质的正确性判断。

一些大家关注的问题

1.数据脱敏

从线上直接引导数据至测试集群，鉴于测试集群的参与人员较多，数据安全就成为了一个比较重要的问题。虽然同样有权限方面的控制和操作方面的审计监控，但有心人在线上不可能进行的诸如数据补全、对比等执行过程中，总可以绕过防范来抓取到敏感数据。这便是数据脱敏的意义所在，根据原始数据的特点，我们通过随机字符的填充，或者MD5码等方式来加密数据，并在加密过程中加上唯一的seed，来确保数据之间的关联不会因此发生断裂。

2.缺失的数据

前文提到数据的时效性，部分作业会在结果报表产生后立即就对源头数据进行清理或合并，这导致我们拷贝来用于做业务回归的数据不完整。此外，大部分源头数据在3天或一周后都会进行删除合并操作以提高空间使用效率，而我们的数据快照始终必须是那固定的一天，当这一天的数据缺失后，我们通过拷贝最新的数据然后改写这些数据的日期来达到补全源头数据的目的，完美的解决了缺失数据的问题。

3.随机数据的全量对比

业务线作业的类型是复杂的，其中有一些机器学习算法或者和日期、计数器相关的数据会在每次回归后都出现全量对比不能通过的现象。例如包含几百万条根据生日确定年龄的表中，由于作业运行日期的不同，哪怕只是隔了一天也会出现其中的365分之一的年龄数据出现变化。因此遇到这种数据，需要采用根据字段特点来进行匹配的方式做全量对比。而对于完全受随机数影响构成的一些数据，则只能忽略进行对比。好在这种随机数据在整体中的占比非常小。

总结

终于到了系列文章的尾声，本文作为系列文章的最后一弹，不仅是因为其复杂性较高，考验了整个跨机房项目参与人员的组织能力、技术能力以及协同合作的能力，且时间跨度较长，横亘整个云梯跨机房项目开发周期，更因为业务线仿真回归汇集了大量各种各样的不同项目的自动化工具，以及人工的协调参与，可谓自动化与测试工具之集大成者。鸟览云梯跨机房项目始末，无论从宏观角度还是从微观角度来看，业务线仿真回归测试都和整个跨机房项目一样气势恢宏、动人心魄。这是无数测试团队与技术人员之间的一次共舞，是合作与竞争、组织与协调、默契与分歧的一次盛会。置身其中，感受无数技术与思想的碰撞，无数创新与灵感的火花，成为一个里程碑一段历史的见证者，我深感无比的荣幸。谨以此文献给这一段历史，期待在将来诸如登月等大型合作项目中可以再次实践。