自谷歌提出云计算概念之后，大数据领域的发展就逐渐加速日新月异，云计算具体到实例，可以归纳为调度、均衡、容错、监控、运维等一整套操作海量数据的方案。有别于传统小规模或孤立体系产品，云计算生态圈存在错综复杂的系统级别关联，并行其中的不同架构和模块流转于超大规模的分布式软硬体资源中，很难划分出明显的界限。对于这样的产品体系，传统领域的测试方案要么逐渐失效，要么作用域缩减到仅能覆盖体系末端。为了保证大数据平台的可靠性、稳定性和高性能，亟需构建一套与之相匹配的测试体系来衡量产品是否合格。
存在的问题
业界在大数据测试领域的探索始终没有停止过，以hadoop生态圈为例，与之相关的各类测试工具自成一体，例如Hadoop本身通过mock出MiniCluster（包括MR和HDFS）用来为开发代码做功能验证，DFSIO/Slive等用来做压力和性能测试；HBase则通过一系列模拟随机/顺序读写相关的工具来做性能测试。而我们自己的ODPS则通过HiveUT来完成功能覆盖和有限的性能验证。仔细梳理这些工具不难发现存在一些问题，列举如下：
1. 这些独立的测试工具和体系很难被其他产品复用，比如说验证hadoop功能的MiniCluster上是不能搭建HBase的，也不能跑Hive。MR输出的默认Counters很难在HBase的测试调优中发挥作用。
2. 各种工具之间对比性较差，例如DFSIO和Slive的输出结果几乎没有什么关联性；还有的时候同一个工具测不同版本，判断耗时、资源占用状况几乎相同，实际上某些第三方指标出现了变化，工具却不能很好的反映出来。
3. 各种工具自身的运行效率无评判标准，被测目标无第三方监控依据。缺乏系统的绘制性能趋势图的能力。
4. 传承性不够，跨产品使用的可能性较小，例如HBase的测试中，很少对HDFS的性能做一个预判，原因是相关的人员缺乏对HDFS体系的了解，对其工具可起到的测试作用缺乏理解。
5. 工具易用性较差，几乎所有类似独立体系工具由于想在广度上覆盖尽量多的应用场景，因此使用了大量的参数用于配合用户不同的测试目的。
6. 此类工具往往依赖产品自身架构来进行相关测试，缺乏完全独立于产品本身的第三方验证方式，如果产品相关联部分发生了变动，要么造成基于老版本的工具失效，要么可能会影响到测试结果的准确性。
诸如以上所述的问题，几乎存在于大数据测试领域的每一个角落，对于阿里数据平台的相关产品来说，随着时间的推移规模的扩大和业务的日渐繁忙，测试上的这些缺陷越来越无法容忍，构建一套与之匹配的分布式测试框架体系就成为了必经之路。为了构造这样一个测试体系，分布式测试框架与集群管理（DST）于2012年初应声而出，从雏形开始一步步构造成为如今拥有数十个页面、数万次构建、数千测试场景和报告，既可以应对复杂业务场景，也可以满足小版本单一功能快速集测需求的自动化测试框架体系。
历史溯源
解决上述存在的问题，构造与之匹配的测试体系，就要从分布式测试框架与集群管理（DST）的历史说起，因为DST的发展过程恰恰正是解决上述问题的轨迹。以下是里程碑级别事件的时间线：
2012年1月，DST开始立项，第一行代码提交版本控制
2012年3月，场景管理（用于构造测试用例）和实验室管理（用于调度执行测试）制作完成
2012年4月，指标配置器和指标计算模板配置功能完成
2012年5月，第一次执行从场景到调度，如今可供查阅这份古老的测试报告：隐藏
2012年5月，ganglia监控数据导入HBase成功，可供查阅第一份有监控数据的测试报告：隐藏
2012年7月，生成集测报告功能上线，最古老的一份集测报告：隐藏
2012年7月底，三线（BI线、广告线、搜索线）回归纳入DST调度体系，首次实现业务线自动化回归
2012年8月，实现基线对比功能，多个版本测试结果可自动进行趋势对比
2012年11月，数据魔方业务线回归纳入DST调度体系（由于对比工具的复杂性导致纳入体系的难度很大）
2013年1月，DST接入Kelude体系使用kelude接口进行用户认证管理和通知等功能
2013年2月，实现测试报告评审体系，通过工具引导流程，迫使测试报告必须通过开发、运维、测试的三方会审
2013年上半年，随着云梯1跨机房项目启动，DST最高接受超过7000台机器的平均每台150多个监控指标的同时导入
2013年3月，配置管理上线，海量测试资源首次实现图形化调度管理
2013年12月，优化监控指标查询系统，将分级查询耗时优化到秒级查询耗时
2014年2月，集群管理上线，用户可以自由分配测试资源组装自己的测试集群，其中云梯1产品更实现了一键自动化部署
综上所述，最终构造成功的体系与架构可以从下面几张图来看：
图：DST的构成
图：DST的体系架构
图：工具引导过程
问题的解决
回到我们刚才提到的6个问题上，DST通过场景管理促使用例复用和使用便利程度得以提升，通过监控体系的创新和改进，促使海量监控数据得到有效的管理和查询。此外，由第三方监控构成的性能评价系统能够排除产品本身的干扰，可以更客观的反应性能结果。
DST在大数据分布式测试上有三个优点：
1. 分布式调度器。调度器采用总分的形式，由console调度多个agent执行测试代码，这样可以模拟出大并发产生的压力。好处是测试代码独立于被测目标，可以防止受被测目标的干扰，且测试代码的分发和结果的收集合并过程都由框架自动化实现，免去用户自行做分布式测试时候对测试结果收集整理的烦恼。
2. 海量监控数据收集展示。DST将数据存储到HBase中，利用HBase的高效率和高容量保证了超过7000台机器的海量监控数据可以实时容纳到DST系统中。数据经过压缩整理，进一步提高了展示速度。业界在2013年2月左右出现一个开源产品OpenTSDB，有点类似这套系统。不同的是，OpenTSDB并没有利用在大数据监控领域使用广泛的成熟产品ganglia来收集监控数据，虽然在数据存储和性能效率方面更好一些，但是并不适用云梯1产品线的测试。
3. 集群管理实现动态测试资源调整。云计算最大的特点是集群和计算资源的动态伸缩，对于测试来说，为了获得不同规模下的性能数据，需要不断调整测试资源的大小，而每一次调整过程通过人工去实现都非常繁琐。DST通过集群管理实现了自动化调整测试资源，图形界面使得配置更加直观，测试资源的利用率状况也可以一目了然。此外，用户独占互斥锁的存在也避免了同一个资源被其他测试目标污染，有效保证测试的可靠性。
DST在设计成功后，于2013年初引入其他非大数据产品中，依托高度自由的框架体系，帮助用户在不同的产品中构建复杂的测试场景。
图：2014年4月新建实验室与调度次数分布
分布式测试体系架构成功后，DST进入了产品推广阶段，我们认为DST更适用于以下测试场景：
1. 被测目标是一个后端服务。无论是独立单机还是多机集群，通过简单的一键部署监控工具后，被测目标就将被纳入DST监控体系。同时，可以通过简单地配置将JMX端口监听起来，用于收集JVM的各项指标信息。
2. 性能、压力和稳定性测试。这些场景往往测试耗时较长，人工值守存在很大的困难，对结果数据的分析也比较困难。接入DST系统后，除了实现无人值守，自动报警通知用户之外。当监控数据的量也比较大的时候，通过指标模板的自动化计算更方便阅读和查找问题。稳定性测试更是可以揉入多个实验室，通过不同工作机的调度实现非常复杂且真实的用户实际使用场景。
3. 需要高效利用测试资源的产品。集群管理使得用户间沟通成本大大降低，测试资源的利用状况一目了然，每日报表更可以看到哪些产品的测试更为繁忙。
4. 多机联合制造负载。被测目标需要足够大的压力才能得出准确的测试结果，而且测试场景构造复杂，通过LR之类工具实现，要么难度太大，要么根本不能实现。DST通过分布式调度器，将测试代码自动分发，并实现结果的收集整理。而最关键的是，整套runner完全可以由用户自行编码订制，自由度与方便性并存。
5. 有指标监控需求的产品。监控体系纳入后，结果更加准确，有利于对被测目标的精致观察。
6. 存在大数据工具的复用和传承需求。由于DST中已经积累了数千个测试场景，因此用户在接入相关产品时便可以利用已有的测试场景来验证被测目标。例如，当Hive接入测试时，可以通过Hadoop的基准测试判断环境是否已经完备，发现bug时也更方便定位是Hive还是Hadoop上的问题。
前景展望
DST架构体系的建成并非一蹴而就，期间经历了复杂的论证、摸索、重构和优化。其中仅监控收集一块，由于完全是创新的产品，在多次摸索中推翻了数种方案，对其进行的优化更是持续数月。在DST推进的过程中，业务测试的需求成为其改进优化的第一源动力。例如早期云梯1由于监控数据存储在mysql中，导致100台机器的监控数据仅需两三周就可以撑爆mysql服务器，而每次测试报告的生成往往耗时达数小时。这一切在DST系统中，由于采用海量存储的缘故，得以缩短到秒级展现。此外，由于调度的自动化，收集体系的自动化，测试环境运维的自动化，促使云梯1回归集测从长达月余，缩短到最快4天以内。
对于DST来说，目前将会跟随项目脚步，逐步实现对云梯2相关的性能、压力和稳定性测试的需求。未来的工作集中于三个方向，一个是纳入神农监控体系，实现调度执行与神农监控数据的对应关系；第二个是指标的收集整理，云梯2相关指标数量巨大，理清这些将会方便用户的测试目的性；第三个是构造各种测试场景，用于对云梯2进行多角度的验证。
分布式测试体系的构建依然任重而道远，以数据为己任，为数据的流转，计算的调度保驾护航是这套体系的价值所在。能跟随这个世界级规模的海量数据平台前行，见证这一切，既是人生之幸，也是责任之所在。
