據(jù)歐洲外媒Deutsche Startups報道，阿里巴巴集團以1.033億美元（9000萬歐元）的價格收購了總部位于柏林的初創(chuàng)公司Data Artisans。

Data Artisan成立于2014年，專門提供為公司企業(yè)部署大規(guī)模數(shù)據(jù)處理解決方案的服務(wù)。該公司的解決方案可以實時管理和部署這類數(shù)據(jù)，以便客戶更合理更快速地做出決策。Data Artisans由開源數(shù)據(jù)流處理技術(shù)Apache Fink的幾位開發(fā)者創(chuàng)辦。

據(jù)Data Artisans官網(wǎng)介紹，其dA平臺由Apache Flink和dA Application Manager組成，“包括與容器編排、持續(xù)集成/持續(xù)交付（CI/CD）、日志記錄、度量指標和狀態(tài)存儲整合的隨時可用的功能，為公司客戶提供了單一視圖，以便了解所有的數(shù)據(jù)流處理應(yīng)用。”其客戶包括荷蘭國際集團（ING）、Netflix、優(yōu)步、Lyft、阿里巴巴、eBay、康卡斯特、華為和King等。

從阿里技術(shù)公眾號分享的一篇《阿里巴巴為什么選擇Apache Flink？》的文章中可看出端倪，阿里巴巴計算平臺事業(yè)部資深技術(shù)專家莫問在云棲大會的演講時表示隨著人工智能時代的降臨，數(shù)據(jù)量的爆發(fā)，在典型的的業(yè)務(wù)場景下數(shù)據(jù)業(yè)務(wù)最通用的做法是：選用批處理的技術(shù)處理全量數(shù)據(jù)，采用流式計算處理實時增量數(shù)據(jù)。在絕大多數(shù)的業(yè)務(wù)場景之下，用戶的業(yè)務(wù)邏輯在批處理和流處理之中往往是相同的。但是，用戶用于批處理和流處理的兩套計算引擎是不同的。

因此，用戶通常需要寫兩套代碼。

毫無疑問，這帶來了一些額外的負擔(dān)和成本。阿里巴巴的商品數(shù)據(jù)處理就經(jīng)常需要面對增量和全量兩套不同的業(yè)務(wù)流程問題，所以阿里就在想，我們能不能有一套統(tǒng)一的大數(shù)據(jù)引擎技術(shù)，用戶只需要根據(jù)自己的業(yè)務(wù)邏輯開發(fā)一套代碼。這樣在各種不同的場景下，不管是全量數(shù)據(jù)還是增量數(shù)據(jù)，亦或者實時處理，一套方案即可全部支持，這就是阿里選擇Flink的背景和初衷。

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

從技術(shù)，生態(tài)等各方面的綜合考慮。首先，Spark的技術(shù)理念是基于批來模擬流的計算。而Flink則完全相反，它采用的是基于流計算來模擬批計算。

從技術(shù)發(fā)展方向看，用批來模擬流有一定的技術(shù)局限性，并且這個局限性可能很難突破。而Flink基于流來模擬批，在技術(shù)上有更好的擴展性。從長遠來看，阿里決定用Flink做一個統(tǒng)一的、通用的大數(shù)據(jù)引擎作為未來的選型。

Flink是一個低延遲、高吞吐、統(tǒng)一的大數(shù)據(jù)計算引擎。在阿里巴巴的生產(chǎn)環(huán)境中，F(xiàn)link的計算平臺可以實現(xiàn)毫秒級的延遲情況下，每秒鐘處理上億次的消息或者事件。同時Flink提供了一個Exactly-once的一致性語義。保證了數(shù)據(jù)的正確性。這樣就使得Flink大數(shù)據(jù)引擎可以提供金融級的數(shù)據(jù)處理能力。

Flink在阿里的現(xiàn)狀

基于Apache Flink在阿里巴巴搭建的平臺于2016年正式上線，并從阿里巴巴的搜索和推薦這兩大場景開始實現(xiàn)。目前阿里巴巴所有的業(yè)務(wù)，包括阿里巴巴所有子公司都采用了基于Flink搭建的實時計算平臺。同時Flink計算平臺運行在開源的Hadoop集群之上。采用Hadoop的YARN做為資源管理調(diào)度，以 HDFS作為數(shù)據(jù)存儲。因此，F(xiàn)link可以和開源大數(shù)據(jù)軟件Hadoop無縫對接。

目前，這套基于Flink搭建的實時計算平臺不僅服務(wù)于阿里巴巴集團內(nèi)部，而且通過阿里云的云產(chǎn)品API向整個開發(fā)者生態(tài)提供基于Flink的云產(chǎn)品支持。

Flink在阿里巴巴的大規(guī)模應(yīng)用，表現(xiàn)如何？

規(guī)模：一個系統(tǒng)是否成熟，規(guī)模是重要指標，F(xiàn)link最初上線阿里巴巴只有數(shù)百臺服務(wù)器，目前規(guī)模已達上萬臺，此等規(guī)模在全球范圍內(nèi)也是屈指可數(shù)；

狀態(tài)數(shù)據(jù)：基于Flink，內(nèi)部積累起來的狀態(tài)數(shù)據(jù)已經(jīng)是PB級別規(guī)模；

Events：如今每天在Flink的計算平臺上，處理的數(shù)據(jù)已經(jīng)超過萬億條；

PS：在峰值期間可以承擔(dān)每秒超過4.72億次的訪問，最典型的應(yīng)用場景是阿里巴巴雙11大屏；

Flink的發(fā)展之路

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

Flink誕生于歐洲的一個大數(shù)據(jù)研究項目StratoSphere。該項目是柏林工業(yè)大學(xué)的一個研究性項目。早期，F(xiàn)link是做Batch計算的，但是在2014年，StratoSphere里面的核心成員孵化出Flink，同年將Flink捐贈Apache，并在后來成為Apache的頂級大數(shù)據(jù)項目，同時Flink計算的主流方向被定位為Streaming，即用流式計算來做所有大數(shù)據(jù)的計算，這就是Flink技術(shù)誕生的背景。

2014年Flink作為主攻流計算的大數(shù)據(jù)引擎開始在開源大數(shù)據(jù)行業(yè)內(nèi)嶄露頭角。區(qū)別于Storm,Spark Streaming以及其他流式計算引擎的是：它不僅是一個高吞吐、低延遲的計算引擎，同時還提供很多高級的功能。比如它提供了有狀態(tài)的計算，支持狀態(tài)管理，支持強一致性的數(shù)據(jù)語義以及支持Event Time,WaterMark對消息亂序的處理。

Flink核心概念以及基本理念

Flink最區(qū)別于其他流計算引擎的，其實就是狀態(tài)管理。

什么是狀態(tài)？例如開發(fā)一套流計算的系統(tǒng)或者任務(wù)做數(shù)據(jù)處理，可能經(jīng)常要對數(shù)據(jù)進行統(tǒng)計，如Sum,Count,Min,Max,這些值是需要存儲的。因為要不斷更新，這些值或者變量就可以理解為一種狀態(tài)。如果數(shù)據(jù)源是在讀取Kafka,RocketMQ，可能要記錄讀取到什么位置，并記錄Offset，這些Offset變量都是要計算的狀態(tài)。

Flink提供了內(nèi)置的狀態(tài)管理，可以把這些狀態(tài)存儲在Flink內(nèi)部，而不需要把它存儲在外部系統(tǒng)。這樣做的好處是第一降低了計算引擎對外部系統(tǒng)的依賴以及部署，使運維更加簡單；第二，對性能帶來了極大的提升：如果通過外部去訪問，如Redis,HBase它一定是通過網(wǎng)絡(luò)及RPC。如果通過Flink內(nèi)部去訪問，它只通過自身的進程去訪問這些變量。同時Flink會定期將這些狀態(tài)做Checkpoint持久化，把Checkpoint存儲到一個分布式的持久化系統(tǒng)中，比如HDFS。這樣的話，當(dāng)Flink的任務(wù)出現(xiàn)任何故障時，它都會從最近的一次Checkpoint將整個流的狀態(tài)進行恢復(fù)，然后繼續(xù)運行它的流處理。對用戶沒有任何數(shù)據(jù)上的影響。

Flink是如何做到在Checkpoint恢復(fù)過程中沒有任何數(shù)據(jù)的丟失和數(shù)據(jù)的冗余？來保證精準計算的？

這其中原因是Flink利用了一套非常經(jīng)典的Chandy-Lamport算法，它的核心思想是把這個流計算看成一個流式的拓撲，定期從這個拓撲的頭部Source點開始插入特殊的Barries，從上游開始不斷的向下游廣播這個Barries。每一個節(jié)點收到所有的Barries,會將State做一次Snapshot，當(dāng)每個節(jié)點都做完Snapshot之后，整個拓撲就算完整的做完了一次Checkpoint。接下來不管出現(xiàn)任何故障，都會從最近的Checkpoint進行恢復(fù)。

Flink利用這套經(jīng)典的算法，保證了強一致性的語義。這也是Flink與其他無狀態(tài)流計算引擎的核心區(qū)別。

下面介紹Flink是如何解決亂序問題的。比如星球大戰(zhàn)的播放順序，如果按照上映的時間觀看，可能會發(fā)現(xiàn)故事在跳躍。

在流計算中，與這個例子是非常類似的。所有消息到來的時間，和它真正發(fā)生在源頭，在線系統(tǒng)Log當(dāng)中的時間是不一致的。在流處理當(dāng)中，希望是按消息真正發(fā)生在源頭的順序進行處理，不希望是真正到達程序里的時間來處理。Flink提供了Event Time和WaterMark的一些先進技術(shù)來解決亂序的問題。使得用戶可以有序的處理這個消息。這是Flink一個很重要的特點。

接下來要介紹的是Flink啟動時的核心理念和核心概念，這是Flink發(fā)展的第一個階段；第二個階段時間是2015年和2017年，這個階段也是Flink發(fā)展以及阿里巴巴介入的時間。故事源于2015年年中，我們在搜索事業(yè)部的一次調(diào)研。當(dāng)時阿里有自己的批處理技術(shù)和流計算技術(shù)，有自研的，也有開源的。但是，為了思考下一代大數(shù)據(jù)引擎的方向以及未來趨勢，我們做了很多新技術(shù)的調(diào)研。

結(jié)合大量調(diào)研結(jié)果，我們最后得出的結(jié)論是：解決通用大數(shù)據(jù)計算需求，批流融合的計算引擎，才是大數(shù)據(jù)技術(shù)的發(fā)展方向，并且最終我們選擇了Flink。

但2015年的Flink還不夠成熟，不管是規(guī)模還是穩(wěn)定性尚未經(jīng)歷實踐。最后我們決定在阿里內(nèi)部建立一個Flink分支，對Flink做大量的修改和完善，讓其適應(yīng)阿里巴巴這種超大規(guī)模的業(yè)務(wù)場景。在這個過程當(dāng)中，我們團隊不僅對Flink在性能和穩(wěn)定性上做出了很多改進和優(yōu)化，同時在核心架構(gòu)和功能上也進行了大量創(chuàng)新和改進，并將其貢獻給社區(qū)，例如：Flink新的分布式架構(gòu)，增量Checkpoint機制,基于Credit-based的網(wǎng)絡(luò)流控機制和Streaming SQL等。

Flink的未來方向

首先，阿里巴巴還是要立足于Flink的本質(zhì)，去做一個全能的統(tǒng)一大數(shù)據(jù)計算引擎。將它在生態(tài)和場景上進行落地。目前Flink已經(jīng)是一個主流的流計算引擎，很多互聯(lián)網(wǎng)公司已經(jīng)達成了共識：Flink是大數(shù)據(jù)的未來，是最好的流計算引擎。下一步很重要的工作是讓Flink在批計算上有所突破。在更多的場景下落地，成為一種主流的批計算引擎。然后進一步在流和批之間進行無縫的切換，流和批的界限越來越模糊。用Flink,在一個計算中，既可以有流計算，又可以有批計算。

第二個方向就是Flink的生態(tài)上有更多語言的支持，不僅僅是Java，Scala語言，甚至是機器學(xué)習(xí)下用的Python，Go語言。未來我們希望能用更多豐富的語言來開發(fā)Flink計算的任務(wù)，來描述計算邏輯，并和更多的生態(tài)進行對接。

最后不得不說AI，因為現(xiàn)在很多大數(shù)據(jù)計算的需求和數(shù)據(jù)量都是在支持很火爆的AI場景，所以在Flink流批生態(tài)完善的基礎(chǔ)上，將繼續(xù)往上走，完善上層Flink的Machine Learning算法庫，同時Flink往上層也會向成熟的機器學(xué)習(xí)，深度學(xué)習(xí)去集成。比如可以做Tensorflow On Flink, 讓大數(shù)據(jù)的ETL數(shù)據(jù)處理和機器學(xué)習(xí)的Feature計算和特征計算，訓(xùn)練的計算等進行集成，讓開發(fā)者能夠同時享受到多種生態(tài)給大家?guī)淼暮锰帯?/p>