Oceanus:基於Apache Flink的一站式實時計算平臺

一、背景介紹

TEG實時計算團隊作為騰訊內部最大的實時資料服務部門，為業務部門提供高效、穩定和易用的實時資料服務。其每秒接入的資料峰值達到了2.1億條，每天接入的資料量達到了17萬億條，每天的資料增長量達到了3PB，每天需要進行的實時計算量達到了20萬億次。

 近年來大資料技術的發展，特別是HDFS和HBase這些大資料儲存系統以及Hadoop和Spark這些大資料計算系統，已經使人們能較好地處理資料規模的問題。但是人們對於資料內在價值的追求是無止境的。一方面，人們開發了越來越多複雜的資料探勘演算法來發現資料更深層次的關係資訊；而另一方面，由於資料價值往往隨著時間的流逝而消失，人們對資料分析時效性的要求也越來越高。越來越多的業務開始使用實時計算來及時獲取資料反饋。

之前實時計算團隊基於Apache Storm構建了早期的實時計算平臺。但在長期的維護過程中，Apache Storm一些設計和實現上的缺陷逐漸暴露出來。Apache Flink出現之後，其在計算介面、計算效能和可靠性上的優異表現，使我們決定使用Apache Flink作為新一代實時計算平臺的計算引擎。

相比於Storm和其他一些流計算框架，Flink有著更先進的計算框架，具有以下幾點優勢：

1）首先，Flink提供了更友好的程式設計介面。Storm提供的API偏底層且過於簡單，使用者需要大量的開發工作來完成業務需求。另外，使用者在開發Storm程式時的學習成本也較高，需要熟悉框架原理和在分散式環境下的執行細節。Flink除了提供Table API和SQL這些高階的宣告式程式語言之外，還對window這些流計算中常見的運算元進行了封裝，幫助使用者處理流計算中資料亂序到達等問題，極大的降低了流計算應用的開發成本並減少了不必要的重複開發。

2）Flink提供了有效的狀態管理支援。大部分的計算程式都是有狀態的，即計算結果不僅僅決定於輸入，還依賴於計算程式當前的狀態。但Storm對程式狀態的支援十分有限。一般情況下，使用者常常需要將狀態資料儲存在MySQL和HBase這樣的外部儲存中，自己負責這些狀態資料的訪問。這些對外部儲存的訪問常常成為Storm程式的效能瓶頸。大多數情況下，使用者只能設計複雜的本地cache來提升效能。Spark Streaming直到最近才提供了有限的狀態管理支援，但受限於其實現機制需要一定的遠端訪問和資料遷移工作，因此狀態資料的訪問效率並不高。Flink則對計算程式的狀態儲存提供了有效支援。使用者可以透過提供的介面方便地儲存和訪問程式狀態。由於這些狀態資料存放在本地，因此使用者可以得到較高的訪問效能。在發生故障時，Flink的狀態管理會配合容錯機制進行狀態資料的重建，保證使用者程式的正確性。而當使用者需要修改程式併發度時，Flink也可以自動地將狀態資料分發到新的計算節點上。

3）Flink提供了豐富的容錯語義。由於Storm缺少對程式狀態的有效支援，其對容錯的支援也較弱，很難保證在發生故障的情況下，每條輸入資料恰好被處理一次。而Flink則依靠分散式系統中經典的Chandy-Lamport演算法，能夠對使用者程式的輸入和狀態生成滿足一致性的程式快照。在發生異常的情況下透過快照回滾，Flink可以保證EXACTLY-ONCE的容錯語義。而利用非同步checkpoint和增量checkpoint技術，Flink能夠在以較低的成本對使用者程式進行快照。在開啟快照時，使用者程式的效能幾乎不受影響。

4）Flink擁有出色的執行效能。Flink基於事件觸發的執行模式對資料流進行處理，相比於Spark Streaming採取mini batch的執行模式，能夠大量減少程式執行時的排程開銷。此外，Flink對網路層進行了大量最佳化，透過細粒度封鎖和高效記憶體訪問提高資料傳輸效能，並透過反壓機制和流量控制有效降低流量擁塞導致的效能下降。加上Flink能夠避免狀態資料的遠端訪問，Flink在實踐中表現出比其他流計算系統更出色的執行效能，具有更低的處理延遲和更高的吞吐能力。

二、平臺介紹

儘管Flink作為計算引擎有著較為出色的表現，但在業務遷移過程中，我們仍然遇到了一些問題。一個流計算任務從開發到上線要經歷包括開發、測試、部署和運維在內的多個階段。使用者首先在開發階段使用IDE開發程式，並進行編譯和打包。之後使用者將打包好的程式部署到測試環境中，生產測試資料進行測試。測試透過之後，使用者需要將其部署到現網環境中，並設定需要的運維指標進行監控。在這些階段中，使用者需要在不同環境和不同工具打交道，整體的開發和運維效率較低。

 為了提高使用者流計算任務持續整合和持續釋出的效率，實時計算團隊圍繞Flink打造了Oceanus，一個集開發、測試、部署和運維於一體的一站式視覺化實時計算平臺。Oceanus整合了應用管理、計算引擎和資源管理等功能，同時透過日誌、監控、運維等周邊服務打通了應用的整個生命週期。

 目前，Oceanus已經覆蓋了所有業務BG，為多個業務提供實時計算服務。實時計算團隊還將騰訊內部負責資料接入、處理和管理工作的TDBank作業都從JStorm遷移到了Oceanus平臺上。另外，原先基於SQL on Storm的EasyCount平臺上的大部分業務也都已遷移到Oceanus。

2.1 多樣化的應用構建方式

Oceanus提供了多種形式的應用構建方式來滿足不同使用者的需求。一般使用者可以使用畫布方便的構建他們的實時計算應用。Oceanus在web頁面上提供了常見的流計算運算元，使用者可以將運算元拖拽到畫布上，並將這些運算元連線起來之後就構建好了一個流計算應用。這種構建方式十分簡單，不需要使用者瞭解底層實現的細節，也不需要掌握SQL等語言的語法，使得使用者能夠專注於業務邏輯和資料流向。

 對於具有一定資料分析背景的使用者，Oceanus提供了Flink SQL介面。Flink SQL儘量遵循SQL標準來描述流資料的計算語義，因此對以前經常使用資料倉儲進行離線資料分析的使用者能夠很快的遷移到Flink SQL上，並用Flink SQL對實時資料流進行分析。為了進一步降低使用者的開發成本，Oceanus還在平臺上提供了很多常見的SQL函式。為了打造便捷流暢的使用體驗，Oceanus還為Flink SQL的開發提供了一系列的輔助功能：

1）語法高亮和自動補齊

2）表名和欄位名的快捷輸入、模糊匹配

3）常見函式的模糊匹配

4）一鍵檢查程式碼有效性

5）一鍵程式碼格式化

......

考慮到不管是畫布還是SQL，它們的表達能力都比較有限，在開發一些具有複雜邏輯的應用時較為困難，並且也不能進行一些底層細節的最佳化，Oceanus允許使用者繼續使用Flink提供的DataStream介面開發實時計算程式。在這種方式下，使用者只需要將他們的實時計算程式打包好上傳到Oceanus即可。

2.2 外部資料管理

為了方便使用者管理Flink作業讀取和寫入，Oceanus提供了對外部資料管理的功能。在開發應用之前，使用者可以透過Oceanus宣告應用所需要使用的資料來源名稱，儲存型別（如Hippo，Tube，MySQL或HBase等），以及每個資料欄位的名稱和型別。外部資料管理使使用者可以在Oceanus上既可以完成外部資料的建立和訪問，並在開發程式時提供必要的欄位和格式資訊，提高了使用者開發實時計算應用的效率。此外，外部資料管理也允許使用者更好地維護外部資料的血緣關係和生產邏輯，在資料發生異常時能夠根據生產鏈路追溯並定位問題。

2.2 實時視覺化的計算結果

對於執行中的應用，Oceanus提供了實時檢視計算結果的功能。目前Oceanus提供了兩種不同的實時視覺化方式。首先，使用者可以透過Oceanus提供的結果抽樣功能獲取到當前計算結果的實時取樣，利用對比結果來對實時計算應用的正確性進行驗證。此外，Oceanus還打通了專業報表平臺 – 小馬報表(http://xiaoma.qq.com)。使用者可以將計算結果接入到小馬報表中來搭建業務的Dashboard，將業務資料進行實時視覺化。

 2.3 自助除錯，快速驗證業務邏輯

在完成實時計算應用的開發中，Oceanus為使用者程式提供了一系列的工具進行應用邏輯的驗證。使用者既可以使用Oceanus提供的一鍵生成功能產生測試資料，也可以自己向Oceanus上傳自己的的測試資料，透過對比預期結果和實際結果來驗證應用邏輯的正確性。在後續工作中，Oceanus還將提供從現網資料抽樣生成測試資料的功能。這樣，使用者就可以更好透過更真實的測試資料來發現應用邏輯的問題。

 2.4 快速方便的資源管理和作業部署

使用者在完成作業的開發和測試之後，可以透過Oceanus快速的在叢集上進行部署。Oceanus依託騰訊內部的資源排程系統Gaia來進行資源管理和作業部署。Oceanus在作業管理頁面上提供了作業資源的配置頁面，使用者可以透過這個配置頁面來對作業所需要的CPU和記憶體資源進行配置，並指定作業需要部署的叢集。當使用者完成配置之後，Oceanus會向Gaia申請對應的資源並將作業提交到Gaia上執行。基於Flink提供的checkpoint功能，Oceanus允許使用者對作業併發度進行實時修改，實現動態的擴容和縮容。

2.5 豐富的運維監控指標

Oceanus對Flink作業執行時的多個執行指標進行採集，包括Task Manager的記憶體，I/O和GC等。這些採集的指標被寫入了訊息佇列Tube中，並利用時序資料庫OpenTSDB進行聚合。透過這些豐富的執行指標，使用者能夠很好的瞭解應用執行的情況，並在出現異常時能協助使用者及時的定位問題。運維人員則可以透過這些採集到的指標，設定報警策略並實現精細化的運營。

 三、功能改進

為了能夠提供更好的實時計算服務，實時計算團隊對Flink核心也進行了大量的改進，提高其可用性和可靠性。

為了方便使用者開發畫布和SQL程式，實時計算團隊實現了超過30個的Table API和SQL函式。使用者可以利用這些內建函式極大地提高實時計算應用的開發效率。此外，實時計算團隊也對資料流和外部維表的join進行了大量最佳化。另外還提供了AsyncIO運算元的超時處理。實時計算團隊還實現了增強視窗來對延遲到達的資料進行更好的處理，避免這些延遲資料的丟失對計算結果正確性的影響。

 實時計算團隊也對Flink的穩定性做了大量的工作。例如透過改進Job Master的容錯機制，實時計算團隊可以實現Master在發生故障時不影響作業的正常執行。

在對Flink持續進行改進的同時，實時計算團隊也和Flink社群建立了密切合作，將這些改進回饋給Flink，為Flink的發展做出了大量貢獻。目前實時計算團隊已經擁有了1名committer以及3名活躍contributor。在剛剛釋出的Flink 1.7版本中，實時計算團隊成員貢獻了超過30個pull request。

 在後面的工作中，Oceanus將繼續在實時計算的可用性和穩定性上努力，為使用者提供更好的實時計算服務。我們將繼續完善我們的運維監控指標，使我們的監控系統更加智慧化，方便使用者對執行作業的監控和對異常情況的定位。同時，我們還將最佳化現有的彈性伸縮機制，使使用者能根據業務負載實現快速的擴容和縮容。最後，我們會改進Flink現有的狀態管理系統，減少Flink由於負載傾斜導致的效能下降。