引言

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開發者工程效率。

原文釋出時間為：2018-11-22

本文作者：溶月

本文來自雲棲社群合作伙伴“阿里技術”，瞭解相關資訊可以關注“阿里技術”。