阿里巴巴爲何選擇Apache Flink？

本文主要整理自阿里巴巴計算平臺事業部資深技術專家莫問在雲棲大會的演講。

合抱之木，生於毫末

隨着人工智能時代的降臨，數據量的爆發，在典型的大數據的業務場景下數據業務最通用的作法是：選用批處理的技術處理全量數據，採用流式計算處理實時增量數據。在絕大多數的業務場景之下，用戶的業務邏輯在批處理和流處理之中每每是相同的。可是，用戶用於批處理和流處理的兩套計算引擎是不一樣的。

所以，用戶一般須要寫兩套代碼。毫無疑問，這帶來了一些額外的負擔和成本。阿里巴巴的商品數據處理就常常須要面對增量和全量兩套不一樣的業務流程問題，因此阿里就在想，咱們能不能有一套統一的大數據引擎技術，用戶只須要根據本身的業務邏輯開發一套代碼。這樣在各類不一樣的場景下，不論是全量數據仍是增量數據，亦或者實時處理，一套方案便可所有支持，這就是阿里選擇Flink的背景和初衷。

目前開源大數據計算引擎有不少選擇，流計算如Storm,Samza,Flink,Kafka Stream等，批處理如Spark,Hive,Pig,Flink等。而同時支持流處理和批處理的計算引擎，只有兩種選擇：一個是Apache Spark，一個是Apache Flink。

從技術，生態等各方面的綜合考慮。首先，Spark的技術理念是基於批來模擬流的計算。而Flink則徹底相反，它採用的是基於流計算來模擬批計算。

從技術發展方向看，用批來模擬流有必定的技術侷限性，而且這個侷限性可能很難突破。而Flink基於流來模擬批，在技術上有更好的擴展性。從長遠來看，阿里決定用Flink作一個統一的、通用的大數據引擎做爲將來的選型。

Flink是一個低延遲、高吞吐、統一的大數據計算引擎。在阿里巴巴的生產環境中，Flink的計算平臺能夠實現毫秒級的延遲狀況下，每秒鐘處理上億次的消息或者事件。同時Flink提供了一個Exactly-once的一致性語義。保證了數據的正確性。這樣就使得Flink大數據引擎能夠提供金融級的數據處理能力。

Flink在阿里的現狀

基於Apache Flink在阿里巴巴搭建的平臺於2016年正式上線，並從阿里巴巴的搜索和推薦這兩大場景開始實現。目前阿里巴巴全部的業務，包括阿里巴巴全部子公司都採用了基於Flink搭建的實時計算平臺。同時Flink計算平臺運行在開源的Hadoop集羣之上。採用Hadoop的YARN作爲資源管理調度，以 HDFS做爲數據存儲。所以，Flink能夠和開源大數據軟件Hadoop無縫對接。

目前，這套基於Flink搭建的實時計算平臺不只服務於阿里巴巴集團內部，並且經過阿里雲的雲產品API向整個開發者生態提供基於Flink的雲產品支持。

Flink在阿里巴巴的大規模應用，表現如何？

規模：一個系統是否成熟，規模是重要指標，Flink最初上線阿里巴巴只有數百臺服務器，目前規模已達上萬臺，此等規模在全球範圍內也是屈指可數；

狀態數據：基於Flink，內部積累起來的狀態數據已是PB級別規模；

Events：現在天天在Flink的計算平臺上，處理的數據已經超過萬億條；

PS：在峯值期間能夠承擔每秒超過4.72億次的訪問，最典型的應用場景是阿里巴巴雙11大屏；

Flink的發展之路

接下來從開源技術的角度，來談一談Apache Flink是如何誕生的，它是如何成長的？以及在成長的這個關鍵的時間點阿里是如何進入的？並對它作出了那些貢獻和支持？

Flink誕生於歐洲的一個大數據研究項目StratoSphere。該項目是柏林工業大學的一個研究性項目。早期，Flink是作Batch計算的，可是在2014年，StratoSphere裏面的核心成員孵化出Flink，同年將Flink捐贈Apache，並在後來成爲Apache的頂級大數據項目，同時Flink計算的主流方向被定位爲Streaming，即用流式計算來作全部大數據的計算，這就是Flink技術誕生的背景。

2014年Flink做爲主攻流計算的大數據引擎開始在開源大數據行業內嶄露頭角。區別於Storm,Spark Streaming以及其餘流式計算引擎的是：它不只是一個高吞吐、低延遲的計算引擎，同時還提供不少高級的功能。好比它提供了有狀態的計算，支持狀態管理，支持強一致性的數據語義以及支持Event Time,WaterMark對消息亂序的處理。

Flink核心概念以及基本理念

Flink最區別於其餘流計算引擎的，其實就是狀態管理。

什麼是狀態？例如開發一套流計算的系統或者任務作數據處理，可能常常要對數據進行統計，如Sum,Count,Min,Max,這些值是須要存儲的。由於要不斷更新，這些值或者變量就能夠理解爲一種狀態。若是數據源是在讀取Kafka,RocketMQ，可能要記錄讀取到什麼位置，並記錄Offset，這些Offset變量都是要計算的狀態。

Flink提供了內置的狀態管理，能夠把這些狀態存儲在Flink內部，而不須要把它存儲在外部系統。這樣作的好處是第一下降了計算引擎對外部系統的依賴以及部署，使運維更加簡單；第二，對性能帶來了極大的提高：若是經過外部去訪問，如Redis,HBase它必定是經過網絡及RPC。若是經過Flink內部去訪問，它只經過自身的進程去訪問這些變量。同時Flink會按期將這些狀態作Checkpoint持久化，把Checkpoint存儲到一個分佈式的持久化系統中，好比HDFS。這樣的話，當Flink的任務出現任何故障時，它都會從最近的一次Checkpoint將整個流的狀態進行恢復，而後繼續運行它的流處理。對用戶沒有任何數據上的影響。

Flink是如何作到在Checkpoint恢復過程當中沒有任何數據的丟失和數據的冗餘？來保證精準計算的？

這其中緣由是Flink利用了一套很是經典的Chandy-Lamport算法，它的核心思想是把這個流計算當作一個流式的拓撲，按期從這個拓撲的頭部Source點開始插入特殊的Barries，從上游開始不斷的向下遊廣播這個Barries。每個節點收到全部的Barries,會將State作一次Snapshot，當每一個節點都作完Snapshot以後，整個拓撲就算完整的作完了一次Checkpoint。接下來無論出現任何故障，都會從最近的Checkpoint進行恢復。

Flink利用這套經典的算法，保證了強一致性的語義。這也是Flink與其餘無狀態流計算引擎的核心區別。

下面介紹Flink是如何解決亂序問題的。好比星球大戰的播放順序，若是按照上映的時間觀看，可能會發現故事在跳躍。

在流計算中，與這個例子是很是相似的。全部消息到來的時間，和它真正發生在源頭，在線系統Log當中的時間是不一致的。在流處理當中，但願是按消息真正發生在源頭的順序進行處理，不但願是真正到達程序裏的時間來處理。Flink提供了Event Time和WaterMark的一些先進技術來解決亂序的問題。使得用戶能夠有序的處理這個消息。這是Flink一個很重要的特色。

接下來要介紹的是Flink啓動時的核心理念和核心概念，這是Flink發展的第一個階段；第二個階段時間是2015年和2017年，這個階段也是Flink發展以及阿里巴巴介入的時間。故事源於2015年年中，咱們在搜索事業部的一次調研。當時阿里有本身的批處理技術和流計算技術，有自研的，也有開源的。可是，爲了思考下一代大數據引擎的方向以及將來趨勢，咱們作了不少新技術的調研。

結合大量調研結果，咱們最後得出的結論是：解決通用大數據計算需求，批流融合的計算引擎，纔是大數據技術的發展方向，而且最終咱們選擇了Flink。

但2015年的Flink還不夠成熟，不論是規模仍是穩定性還沒有經歷實踐。最後咱們決定在阿里內部創建一個Flink分支，對Flink作大量的修改和完善，讓其適應阿里巴巴這種超大規模的業務場景。在這個過程中，咱們團隊不只對Flink在性能和穩定性上作出了不少改進和優化，同時在覈心架構和功能上也進行了大量創新和改進，並將其貢獻給社區，例如：Flink新的分佈式架構，增量Checkpoint機制,基於Credit-based的網絡流控機制和Streaming SQL等。

阿里巴巴對Flink社區的貢獻

咱們舉兩個設計案例，第一個是阿里巴巴重構了Flink的分佈式架構，將Flink的Job調度和資源管理作了一個清晰的分層和解耦。這樣作的首要好處是Flink能夠原生的跑在各類不一樣的開源資源管理器上。通過這套分佈式架構的改進，Flink能夠原生地跑在Hadoop Yarn和Kubernetes這兩個最多見的資源管理系統之上。同時將Flink的任務調度從集中式調度改成了分佈式調度，這樣Flink就能夠支持更大規模的集羣，以及獲得更好的資源隔離。

另外一個是實現了增量的Checkpoint機制，由於Flink提供了有狀態的計算和按期的Checkpoint機制，若是內部的數據愈來愈多，不停地作Checkpoint,Checkpoint會愈來愈大，最後可能致使作不出來。提供了增量的Checkpoint後，Flink會自動地發現哪些數據是增量變化，哪些數據是被修改了。同時只將這些修改的數據進行持久化。這樣Checkpoint不會隨着時間的運行而愈來愈難作，整個系統的性能會很是地平穩，這也是咱們貢獻給社區的一個很重大的特性。

通過2015年到2017年對Flink Streaming的能力完善，Flink社區也逐漸成熟起來。Flink也成爲在Streaming領域最主流的計算引擎。由於Flink最先期想作一個流批統一的大數據引擎，2018年已經啓動這項工做，爲了實現這個目標，阿里巴巴提出了新的統一API架構，統一SQL解決方案，同時流計算的各類功能獲得完善後，咱們認爲批計算也須要各類各樣的完善。不管在任務調度層，仍是在數據Shuffle層，在容錯性，易用性上，都須要完善不少工做。

篇幅緣由，下面主要和你們分享兩點：

 ●  統一 API Stack
 ●  統一 SQL方案

先來看下目前Flink API Stack的一個現狀，調研過Flink或者使用過Flink的開發者應該知道。Flink有2套基礎的API，一套是DataStream，一套是DataSet。DataStream API是針對流式處理的用戶提供，DataSet API是針對批處理用戶提供，可是這兩套API的執行路徑是徹底不同的，甚至須要生成不一樣的Task去執行。因此這跟獲得統一的API是有衝突的，並且這個也是不完善的，不是最終的解法。在Runtime之上首先是要有一個批流統一融合的基礎API層，咱們但願能夠統一API層。

所以，咱們在新架構中將採用一個DAG（有限無環圖）API，做爲一個批流統一的API層。對於這個有限無環圖，批計算和流計算不須要涇渭分明的表達出來。只須要讓開發者在不一樣的節點，不一樣的邊上定義不一樣的屬性，來規劃數據是流屬性仍是批屬性。整個拓撲是能夠融合批流統一的語義表達，整個計算無需區分是流計算仍是批計算，只須要表達本身的需求。有了這套API後，Flink的API Stack將獲得統一。

除了統一的基礎API層和統一的API Stack外，一樣在上層統一SQL的解決方案。流和批的SQL，能夠認爲流計算有數據源，批計算也有數據源，咱們能夠將這兩種源都模擬成數據表。能夠認爲流數據的數據源是一張不斷更新的數據表，對於批處理的數據源能夠認爲是一張相對靜止的表，沒有更新的數據表。整個數據處理能夠當作SQL的一個Query，最終產生的結果也能夠模擬成一個結果表。

對於流計算而言，它的結果表是一張不斷更新的結果表。對於批處理而言，它的結果表是至關於一次更新完成的結果表。從整個SOL語義上表達，流和批是能夠統一的。此外，不論是流式SQL，仍是批處理SQL，均可以用同一個Query來表達複用。這樣以來流批均可以用同一個Query優化或者解析。甚至不少流和批的算子都是能夠複用的。

Flink的將來方向

首先，阿里巴巴仍是要立足於Flink的本質，去作一個全能的統一大數據計算引擎。將它在生態和場景上進行落地。目前Flink已是一個主流的流計算引擎，不少互聯網公司已經達成了共識：Flink是大數據的將來，是最好的流計算引擎。下一步很重要的工做是讓Flink在批計算上有所突破。在更多的場景下落地，成爲一種主流的批計算引擎。而後進一步在流和批之間進行無縫的切換，流和批的界限愈來愈模糊。用Flink,在一個計算中，既能夠有流計算，又能夠有批計算。

第二個方向就是Flink的生態上有更多語言的支持，不只僅是Java，Scala語言，甚至是機器學習下用的Python，Go語言。將來咱們但願能用更多豐富的語言來開發Flink計算的任務，來描述計算邏輯，並和更多的生態進行對接。

最後不得不說AI，由於如今不少大數據計算的需求和數據量都是在支持很火爆的AI場景，因此在Flink流批生態完善的基礎上，將繼續往上走，完善上層Flink的Machine Learning算法庫，同時Flink往上層也會向成熟的機器學習，深度學習去集成。好比能夠作Tensorflow On Flink, 讓大數據的ETL數據處理和機器學習的Feature計算和特徵計算，訓練的計算等進行集成，讓開發者可以同時享受到多種生態給你們帶來的好處。

本文做者：莫問

閱讀原文
)

本文來自雲棲社區合做夥伴「阿里技術」，如需轉載請聯繫原做者。