1. 程式人生 > >這一年多來,阿裏Blink測試體系如何從0走向成熟?

這一年多來,阿裏Blink測試體系如何從0走向成熟?

物理 性問題 郵件 流程 轉載 兼容 手動 數量 執行計劃

引言

Apache Flink是面向數據流處理和批處理的分布式開源計算框架,2016年阿裏巴巴引入Flink框架,改造為Blink。2017年,阿裏整合了所有流計算產品,決定以Blink引擎為基礎,打造一款全球領先的實時計算引擎。當年雙11,Blink支持了二十多個事業部/群,同時運行了上千個實時計算job,每秒處理的日誌數峰值達到驚人的4.7億。因此Blink的可靠性和穩定性保障變得極其重要,搜索事業部的質量團隊為此專門成立了Blink測試小組,通過一年多的努力,建立了從代碼質量到持續集成再到預發測試的全面的測試體系,幫助Blink的質量取得大幅提高。

Blink測試平臺介紹

Blink測試團隊為Blink質量量身打造Blink測試平臺,內容如下圖所示:

技術分享圖片

Blink測試平臺包含了三個測試階段: 代碼質量校驗階段,主要進行靜態代碼掃描、單元測試和基於minicluster的測試;集成測試階段,主要是進行功能測試、性能測試和帶有破壞性的穩定性測試;而預發測試階段,主要是利用用戶的job進行仿真測試,並在版本發布之前做最後的版本兼容性測試。

平臺選取部分測試集合納入到precommit的驗證中,可盡早發現代碼中問題,而大規模的功能、性能、穩定性測試,通常作為dailybuild的集合。另外,Blink測試平臺建立了較為完善的質量度量體系,除去對代碼覆蓋率的統計及變化的分析,還可一鍵生成測試報告,並對不同版本的質量進行橫向對比。

代碼質量校驗階段

代碼質量校驗階段是整個Blink質量保障的基礎。主要包含單元測試,利用aone提供的"集團代碼規約掃描"工具對代碼進行規範掃描,單機運行的基於minicluster的集成測試,只有這三個階段都測試通過後才允許Blink代碼提交到項目git。

技術分享圖片

功能測試

Blink功能測試框架使用defender,該框架是由pytest[1]改造而來,很好地支持了BlinkSql測試的特性,並支持第三方插件的引入。在測試集群中可以端到端的對某一場景進行精準測試。具體流程如下圖所示,支持IDE和Jenkins兩種觸發模式,yarn_job、yarn_session和local三種case運行調度模式。執行結束後通過web頁面或郵件的形式對結果進行展示,並對運行結果進行持久化。具有如下優勢:

1、case的統一調度與精細化管理:現在Blink在defender上有12個場景4000多個case,可以每天定時進行dailyrun,如果某一類別的case出現問題可單獨執行,並可在頁面上顯示詳情。

2、case的三種運行模式滿足了不同場景的測試需求:其中yarn_session模式對一個模塊中存在sqlCase的場景較為適用,可大大減少與Yarn交互的時間。

3、case靈活配置:不僅可以支持系統配置,對每個case集所需資源(slot,memory等)或集群其他配置的不同進行單獨配置。

4、一個case可同時支持批和流兩種運行類型。

5、client類型靈活擴展:可對現有數據存儲和服務進行集成和擴展。現已支持多類型data store讀寫服務,yarn_session的啟動,Blink job交互等。

技術分享圖片

性能測試

Blink作為實時大數據處理引擎,其對單位時間內的數據處理能力和數據處理的實時性提出了非常嚴苛的要求。因此,性能測試是整個Blink測試中非常重要的一環,是衡量Blink新版本能否發布的核心標準之一。

Blink的性能測試主要包含Operator性能測試、SQL性能測試和runtime性能測試:

Operator指構成SQL語義的一個原子操作,例如Sum,Aggregate等,是一個不能再分割的算子。Operator的性能測試主要用於監控單個算子在整個開發過程中的性能變化,以保證局部處理的優化和提高。目前,Operator的測試分成兩個部分:單個算子的性能測試和算子組合的性能測試。Operator測試以Daily Run的方式反饋性能的變化。

SQL性能測試主要用於監控版本開發過程中單個SQL的性能變化。TPCH和TPCDS是業界SQL標準性能測試集,分別有22和103個測試用例。測試平臺將其引入到Blink性能測試中,以更全面地衡量Blink的性能變化。

Runtime性能測試主要為了保障runtime層面性能不回退,主要包含端到端性能測試和模塊性能測試。端到端性能測試首先根據梳理出測試場景,關註各場景job在指定數據量下的job運行時間,模塊性能測試主要包含網絡層性能測試,調度層性能測試,failover性能測試等,更關註在特定場景下job的處理時間。

性能測試未來規劃是將E2E性能測試、模塊級別性能測試和參數調整整體聯動起來,使其能夠更好協助開發定位性能問題root cause和查看參數調優效果。

技術分享圖片

穩定性測試

對於支持高並發、多節點,集群物理環境復雜的分布式系統來說,類似磁盤打滿、網絡延遲等物理節點的異常很難避免。Blink作為一個高可用的分布式系統,必然要做到在異常情況下也能保證系統的穩定運行及數據的正常產出。“避免失敗的最好方法就是不斷地失敗”,因此,在Blink任務運行期間將可能發生的異常模擬出來,就能夠驗證Blink的穩定性。

我們把異常場景分為兩類:一類是"黑猴子",該類場景與運行環境相關,包括機器重啟、網絡異常、磁盤異常、cpu異常等,這部分異常主要用shell命令來模擬;另一類異常是"白猴子",此類場景與Blink job相關,包括rpc消息超時,task異常,heart beat消息超時等,主要通過byteman[2]軟件註入的方式來實現。在穩定性測試中,monkey作為調度會隨機選取上述異常場景進行組合,以模擬線上可能出現的所有異常場景。

考慮到Blink支持任務failover的特性和穩定性測試的自動運行,我們把穩定性測試設定為一輪輪的叠代循環,每一輪叠代都包含釋放出monkey,提交任務,等待job恢復,校驗四個階段,校驗主要包含checkpoint,container及slot資源等是否符合預期,校驗失敗就報警,校驗成功後通過後進入下一輪叠代,以驗證任務在長時間運行下的任務穩定性。

穩定性測試架構分為四層:組件層主要包含測試Blink job,monkeys和dumper;action層包含job啟動,狀態校驗,輸出校驗等;執行層包含service,monkey操作等,monkey操作時會根據ssh到具體機器,執行monkey操作;最上層是WebUI。詳情如下圖所示:

技術分享圖片

預發測試

Blink預發測試階段主要通過克隆線上的真實任務和數據來進行復雜業務邏輯和大數據量的測試。因此,Blink 預發測試是對代碼質量校驗和集成測試的補充以及整個測試流程的完善,是Blink版本發布的最後一道關卡。

Blink預發測試主要分為兩個部分:仿真測試和兼容性測試。

仿真測試

仿真測試對Blink的功能、性能和穩定性等基礎測試指標進行進一步地衡量,並將開發中的版本與當前的線上版本進行橫向比較。因此,仿真測試能夠盡早發現各種功能、性能退化和穩定性問題,從而提高上線版本的質量。

仿真測試主要分為環境克隆,環境適配和測試運行三個階段:

環境克隆

環境克隆是實現整個仿真測試的基礎,包括線上任務的挑選、克隆和測試數據的采樣。

技術分享圖片

Blink的線上任務分散在多個不同的工程中,數量較多。雖然,每一個線上任務都有其內在的業務邏輯,但是,不同的任務可以根據其主要的處理邏輯進行歸類,例如,以Agg操作為主的任務集合,以Sum操作為主的任務集合等,因此,Blink仿真測試需要對線上任務進行甄別,挑選出其中最具有代表性的任務。

仿真測試的測試數據集是當前線上任務輸入數據的采樣,僅在數據規模上有差異,並且,可以根據測試需求的不同進行動態地調節,從而實現對測試目標的精確衡量。

環境適配

環境適配是仿真測試過程中的初始化階段,主要進行測試用例的修改,使其能夠正常運行。該過程主要包括兩個步驟:更改測試數據輸入源和測試結果輸出地址和更新任務的資源配置。

測試運行

測試運行是仿真測試流程中的實際執行模塊,包括測試用例的運行和結果反饋兩個部分。

Blink仿真測試包括功能測試、性能測試和穩定性測試等模塊,不同的測試模塊具有不同的衡量標準和反饋方式。這些測試模塊的測試結果與代碼質量校驗和集成測試的結果一起構成Blink測試的結果集。

技術分享圖片

性能測試和功能測試以仿真任務和采樣數據作為輸入,對比和分析任務在不同執行引擎上的執行過程和產出。其中,性能測試重點考察執行過程中不同執行引擎對資源的利用率、吞吐量等性能指標。功能測試則將執行的最終結果進行對比。需要特別指出的是,在功能測試中,線上版本的運行結果被假定為真,即當線上版本的執行結果與開發版本的執行結果不同時,認為開發版本的執行存在錯誤,需要修復開發中引入的錯誤。

穩定性測試重點關註仿真測試任務在線上克隆環境、大數據量和長時間運行條件下的穩定性。其以Blink開發版本作為唯一的執行引擎,通過收集執行過程中的資源利用情況、吞吐量、failover等指標來進行度量。

兼容性測試

Blink兼容性測試主要用於發現Blink新、舊版本之間的兼容性問題,從而為線上任務升級Blink執行引擎的版本提供依據。目前,兼容性測試主要分為靜態檢查和動態運行兩個階段,其中,靜態檢查是整個兼容性測試的基礎。

靜態檢查

靜態檢查主要用於分析線上任務在不同執行引擎下生成執行計劃的不同,包括兩個方面的內容:

新的執行引擎生成執行計劃的正確性及生成執行計劃的時間長短。

新、舊版本的執行引擎生成的執行計劃是否兼容。

技術分享圖片

在靜態檢查中,若新的執行引擎不能正確地生成執行計劃,或者生成執行計劃的時間超出預期,都可以認為靜態檢查失敗,Blink新版本中存在異常或者缺陷,需要查找原因。當新版本能夠正確地生成執行計劃時,若新、舊版本的執行引擎生成的執行計劃不兼容,那麽,需要將對比結果反饋給開發人員以判斷該執行計劃的更改是否符合預期;若執行計劃兼容或者執行計劃的更改符合預期,則可以直接進行運行時測試。

動態運行測試

Blink動態運行測試利用仿真測試中的功能測試模塊來進行任務的運行,是升級Blink新版本之前的最後一輪測試。若任務能夠正常啟動且測試結果符合預期,則認為該任務可以自動升級,反之,則需要人工介入進行手動升級。

展望

通過一年多的努力,Blink整體質量已經有很大幅度的提高,Blink的測試方法和工具也越來越成熟,Blink回饋社區之際,我們會逐步將測試工具一起輸出,回饋更多的社區開發測試者,與此同時,隨著Blink用戶群的壯大,Blink業務開發者對於業務任務的質量保證需要日漸高漲,Blink測試團隊未來會提供更多質量保證和開發效率工具,進一步提升Blink開發者工程效率。


原文鏈接
本文為雲棲社區原創內容,未經允許不得轉載。

這一年多來,阿裏Blink測試體系如何從0走向成熟?