引言
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分之一的年齡數據出現變化。因此遇到這種數據，需要采用根據字段特點來進行匹配的方式做全量對比。而對于完全受隨機數影響構成的一些數據，則只能忽略進行對比。好在這種隨機數據在整體中的占比非常小。
總結
終于到了系列文章的尾聲，本文作為系列文章的最后一彈，不僅是因為其復雜性較高，考驗了整個跨機房項目參與人員的組織能力、技術能力以及協同合作的能力，且時間跨度較長，橫亙整個云梯跨機房項目開發周期，更因為業務線仿真回歸匯集了大量各種各樣的不同項目的自動化工具，以及人工的協調參與，可謂自動化與測試工具之集大成者。鳥覽云梯跨機房項目始末，無論從宏觀角度還是從微觀角度來看，業務線仿真回歸測試都和整個跨機房項目一樣氣勢恢宏、動人心魄。這是無數測試團隊與技術人員之間的一次共舞，是合作與競爭、組織與協調、默契與分歧的一次盛會。置身其中，感受無數技術與思想的碰撞，無數創新與靈感的火花，成為一個里程碑一段歷史的見證者，我深感無比的榮幸。謹以此文獻給這一段歷史，期待在將來諸如登月等大型合作項目中可以再次實踐。
3