本文作者：王峰（花名：莫問）
導讀：伴随着海量增長的資料，數字化時代的未來感撲面而至。不論是結繩記事的小資料時代，還是我們正在經曆的大資料時代，計算的邊界正在被無限拓寬，而資料的價值再也難以被計算。時下，談及大資料，不得不提到熱門的下一代大資料計算引擎Apache Flink（以下簡稱Flink）。本文将結合Flink的前世今生，從業務角度出發，向大家娓娓道來：為什麼阿裡選擇了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計算和特征計算，訓練的計算等進行內建，讓開發者能夠同時享受到多種生态給大家帶來的好處。
2018年12月20日-21日，首屆Flink Forward China峰會将在北京國家會議中心舉辦。點選
Flink Forward China 2018 報名即可報名。