自谷歌提出雲計算概念之後，大數據領域的發展就逐漸加速日新月異，雲計算具體到實例，可以歸納爲調度、均衡、容錯、監控、運維等一整套操作海量數據的方案。有別於傳統小規模或孤立體系產品，雲計算生態圈存在錯綜複雜的系統級別關聯，並行其中的不同架構和模塊流轉於超大規模的分佈式軟硬體資源中，很難劃分出明顯的界限。對於這樣的產品體系，傳統領域的測試方案要麼逐漸失效，要麼作用域縮減到僅能覆蓋體系末端。爲了保證大數據平臺的可靠性、穩定性和高性能，亟需構建一套與之相匹配的測試體系來衡量產品是否合格。
存在的問題
業界在大數據測試領域的探索始終沒有停止過，以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進行多角度的驗證。
分佈式測試體系的構建依然任重而道遠，以數據爲己任，爲數據的流轉，計算的調度保駕護航是這套體系的價值所在。能跟隨這個世界級規模的海量數據平臺前行，見證這一切，既是人生之幸，也是責任之所在。