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