一、Apache Flink 的命脈

"命脈" 即生命與血脈，常喻極為重要的事物。系列的首篇，首篇的首段不聊Apache Flink的歷史，不聊Apache Flink的架構(gòu)，不聊Apache Flink的功能特性，我們用一句話聊聊什么是 Apache Flink 的命脈?我的答案是：Apache Flink 是以"批是流的特例"的認(rèn)知進(jìn)行系統(tǒng)設(shè)計(jì)的。

二、唯快不破

我們經(jīng)常聽說 "天下武功，唯快不破"，大概意思是說 "任何一種武功的招數(shù)都是有拆招的，唯有速度快，快到對(duì)手根本來不及反應(yīng)，你就將對(duì)手KO了，對(duì)手沒有機(jī)會(huì)拆招，所以唯快不破"。 那么這與Apache Flink有什么關(guān)系呢?Apache Flink是Native Streaming(純流式)計(jì)算引擎，在實(shí)時(shí)計(jì)算場景最關(guān)心的就是"快",也就是 "低延時(shí)"。

就目前最熱的兩種流計(jì)算引擎Apache Spark和Apache Flink而言，誰最終會(huì)成為No1呢?單從 "低延時(shí)" 的角度看，Spark是Micro Batching(微批式)模式，***延遲Spark能達(dá)到0.5~2秒左右，F(xiàn)link是Native Streaming(純流式)模式，***延時(shí)能達(dá)到微秒。很顯然是相對(duì)較晚出道的 Apache Flink 后來者居上。 那么為什么Apache Flink能做到如此之 "快"呢?根本原因是Apache Flink 設(shè)計(jì)之初就認(rèn)為 "批是流的特例"，整個(gè)系統(tǒng)是Native Streaming設(shè)計(jì)，每來一條數(shù)據(jù)都能夠觸發(fā)計(jì)算。相對(duì)于需要靠時(shí)間來積攢數(shù)據(jù)Micro Batching模式來說，在架構(gòu)上就已經(jīng)占據(jù)了絕對(duì)優(yōu)勢。

那么為什么關(guān)于流計(jì)算會(huì)有兩種計(jì)算模式呢?歸其根本是因?yàn)閷?duì)流計(jì)算的認(rèn)知不同，是"流是批的特例" 和 "批是流的特例" 兩種不同認(rèn)知產(chǎn)物。

1. Micro Batching 模式

Micro-Batching 計(jì)算模式認(rèn)為 "流是批的特例"， 流計(jì)算就是將連續(xù)不斷的批進(jìn)行持續(xù)計(jì)算，如果批足夠小那么就有足夠小的延時(shí)，在一定程度上滿足了99%的實(shí)時(shí)計(jì)算場景。那么那1%為啥做不到呢?這就是架構(gòu)的魅力，在Micro-Batching模式的架構(gòu)實(shí)現(xiàn)上就有一個(gè)自然流數(shù)據(jù)流入系統(tǒng)進(jìn)行攢批的過程，這在一定程度上就增加了延時(shí)。具體如下示意圖：

很顯然Micro-Batching模式有其天生的低延時(shí)瓶頸，但任何事物的存在都有兩面性，在大數(shù)據(jù)計(jì)算的發(fā)展歷史上，最初Hadoop上的MapReduce就是優(yōu)秀的批模式計(jì)算框架，Micro-Batching在設(shè)計(jì)和實(shí)現(xiàn)上可以借鑒很多成熟實(shí)踐。

2. Native Streaming 模式

Native Streaming 計(jì)算模式認(rèn)為 ""批是流的特例"，這個(gè)認(rèn)知更貼切流的概念，比如一些監(jiān)控類的消息流，數(shù)據(jù)庫操作的binlog，實(shí)時(shí)的支付交易信息等等自然流數(shù)據(jù)都是一條，一條的流入。Native Streaming 計(jì)算模式每條數(shù)據(jù)的到來都進(jìn)行計(jì)算，這種計(jì)算模式顯得更自然，并且延時(shí)性能達(dá)到更低。具體如下示意圖：

很明顯Native Streaming模式占據(jù)了流計(jì)算領(lǐng)域 "低延時(shí)" 的核心競爭力，當(dāng)然Native Streaming模式的實(shí)現(xiàn)框架是一個(gè)歷史先河，***個(gè)實(shí)現(xiàn)Native Streaming模式的流計(jì)算框架是***個(gè)吃螃蟹的人，需要面臨更多的挑戰(zhàn)，后續(xù)章節(jié)我們會(huì)慢慢介紹。當(dāng)然Native Streaming模式的框架實(shí)現(xiàn)上面很容易實(shí)現(xiàn)Micro-Batching和Batching模式的計(jì)算，Apache Flink就是Native Streaming計(jì)算模式的流批統(tǒng)一的計(jì)算引擎。

三、豐富的部署模式

Apache Flink 按不同的需求支持Local，Cluster，Cloud三種部署模式，同時(shí)Apache Flink在部署上能夠與其他成熟的生態(tài)產(chǎn)品進(jìn)行***集成，如 Cluster模式下可以利用YARN(Yet Another Resource Negotiator)/Mesos集成進(jìn)行資源管理，在Cloud部署模式下可以與GCE(Google Compute Engine), EC2(Elastic Compute Cloud)進(jìn)行集成。

1. Local 模式

該模式下Apache Flink 整體運(yùn)行在Single JVM中，在開發(fā)學(xué)習(xí)中使用，同時(shí)也可以安裝到很多端類設(shè)備上。

2. Cluster模式

該模式是典型的投產(chǎn)的集群模式，Apache Flink 既可以Standalone的方式進(jìn)行部署，也可以與其他資源管理系統(tǒng)進(jìn)行集成部署，比如與YARN進(jìn)行集成。

這種部署模式是典型的Master/Slave模式，我們以Standalone Cluster模式為例示意如下：

其中JM(JobManager)是Master，TM(TaskManager)是Slave，這種Master/Slave模式有一個(gè)典型的問題就是SPOF(single point of failure), SPOF如何解決呢?Apache Flink 又提供了HA(High Availability)方案，也就是提供多個(gè)Master，在任何時(shí)候總有一個(gè)JM服役，N(N>=1)個(gè)JM候選,進(jìn)而解決SPOF問題，示意如下：

在實(shí)際的生產(chǎn)環(huán)境我們都會(huì)配置HA方案，目前Alibaba內(nèi)部使用的也是基于YARN Cluster的HA方案。

3. Cloud 模式

該模式主要是與成熟的云產(chǎn)品進(jìn)行集成，Apache Flink官網(wǎng)介紹了Google的GCE 參考，Amazon的EC2 參考，在Alibaba我們也可以將Apache Flink部署到Alibaba的ECS(Elastic Compute Service)。

四、完善的容錯(cuò)機(jī)制

1. 什么是容錯(cuò)

容錯(cuò)(Fault Tolerance) 是指容忍故障，在故障發(fā)生時(shí)能夠自動(dòng)檢測出來并使系統(tǒng)能夠自動(dòng)回復(fù)正常運(yùn)行。當(dāng)出現(xiàn)某些指定的網(wǎng)絡(luò)故障、硬件故障、軟件錯(cuò)誤時(shí)，系統(tǒng)仍能執(zhí)行規(guī)定的一組程序，或者說程序不會(huì)因系統(tǒng)中的故障而中止，并且執(zhí)行結(jié)果也不會(huì)因系統(tǒng)故障而引起計(jì)算差錯(cuò)。

2. 容錯(cuò)的處理模式

在一個(gè)分布式系統(tǒng)中由于單個(gè)進(jìn)程或者節(jié)點(diǎn)宕機(jī)都有可能導(dǎo)致整個(gè)Job失敗，那么容錯(cuò)機(jī)制除了要保證在遇到非預(yù)期情況系統(tǒng)能夠"運(yùn)行"外，還要求能"正確運(yùn)行",也就是數(shù)據(jù)能按預(yù)期的處理方式進(jìn)行處理，保證計(jì)算結(jié)果的正確性。計(jì)算結(jié)果的正確性取決于系統(tǒng)對(duì)每一條計(jì)算數(shù)據(jù)處理機(jī)制，一般有如下三種處理機(jī)制：

• At Most Once：最多消費(fèi)一次，這種處理機(jī)制會(huì)存在數(shù)據(jù)丟失的可能。
• At Least Once：最少消費(fèi)一次，這種處理機(jī)制數(shù)據(jù)不會(huì)丟失，但是有可能重復(fù)消費(fèi)。
• Exactly Once：精確一次，無論何種情況下，數(shù)據(jù)都只會(huì)消費(fèi)一次，這種機(jī)制是對(duì)數(shù)據(jù)準(zhǔn)確性的***要求，在金融支付，銀行賬務(wù)等領(lǐng)域必須采用這種模式。

3. Apache Flink的容錯(cuò)機(jī)制

Apache Flink的Job會(huì)涉及到3個(gè)部分，外部數(shù)據(jù)源(External Input), Flink內(nèi)部數(shù)據(jù)處理(Flink Data Flow)和外部輸出(External Output)。如下示意圖:

目前Apache Flink 支持兩種數(shù)據(jù)容錯(cuò)機(jī)制：

• At Least Once
• Exactly Once

其中 Exactly Once 是最嚴(yán)格的容錯(cuò)機(jī)制，該模式要求每條數(shù)據(jù)必須處理且僅處理一次。那么對(duì)于這種嚴(yán)格容錯(cuò)機(jī)制，一個(gè)完整的Flink Job容錯(cuò)要做到 End-to-End 的 容錯(cuò)必須結(jié)合三個(gè)部分進(jìn)行聯(lián)合處理，根據(jù)上圖我們考慮三個(gè)場景：

• 場景一：Flink的Source Operator 在讀取到Kafla中pos=2000的數(shù)據(jù)時(shí)候，由于某種原因宕機(jī)了，這個(gè)時(shí)候Flink框架會(huì)分配一個(gè)新的節(jié)點(diǎn)繼續(xù)讀取Kafla數(shù)據(jù)，那么新的處理節(jié)點(diǎn)怎樣處理才能保證數(shù)據(jù)處理且只被處理一次呢?

 

• 場景二：Flink Data Flow內(nèi)部某個(gè)節(jié)點(diǎn)，如果上圖的agg()節(jié)點(diǎn)發(fā)生問題，在恢復(fù)之后怎樣處理才能保持map()流出的數(shù)據(jù)處理且只被處理一次?

• 場景三：Flink的Sink Operator 在寫入Kafka過程中自身節(jié)點(diǎn)出現(xiàn)問題，在恢復(fù)之后如何處理，計(jì)算結(jié)果才能保證寫入且只被寫入一次?

4. 系統(tǒng)內(nèi)部容錯(cuò)

Apache Flink利用Checkpointing機(jī)制來處理容錯(cuò)，Checkpointing的理論基礎(chǔ) Stephan 在 Lightweight Asynchronous Snapshots for Distributed Dataflows 進(jìn)行了細(xì)節(jié)描述，該機(jī)制源于有K. MANI CHANDY和LESLIE LAMPORT 發(fā)表的 Determining-Global-States-of-a-Distributed-System Paper。Apache Flink 基于Checkpointing機(jī)制對(duì)Flink Data Flow實(shí)現(xiàn)了At Least Once 和 Exactly Once 兩種容錯(cuò)處理模式。

Apache Flink Checkpointing的內(nèi)部實(shí)現(xiàn)會(huì)利用 Barriers，StateBackend等后續(xù)章節(jié)會(huì)詳細(xì)介紹的技術(shù)來將數(shù)據(jù)的處理進(jìn)行Marker。Apache Flink會(huì)利用Barrier將整個(gè)流進(jìn)行標(biāo)記切分，如下示意圖：

這樣Apache Flink的每個(gè)Operator都會(huì)記錄當(dāng)前成功處理的Checkpoint，如果發(fā)生錯(cuò)誤，就會(huì)從上一個(gè)成功的Checkpoint開始繼續(xù)處理后續(xù)數(shù)據(jù)。比如 Soruce Operator會(huì)將讀取外部數(shù)據(jù)源的Position實(shí)時(shí)的記錄到Checkpoint中，失敗時(shí)候會(huì)從Checkpoint中讀取成功的position繼續(xù)精準(zhǔn)的消費(fèi)數(shù)據(jù)。每個(gè)算子會(huì)在Checkpoint中記錄自己恢復(fù)時(shí)候必須的數(shù)據(jù)，比如流的原始數(shù)據(jù)和中間計(jì)算結(jié)果等信息，在恢復(fù)的時(shí)候從Checkpoint中讀取并持續(xù)處理流數(shù)據(jù)。

5. 外部Source容錯(cuò)

Apache Flink 要做到 End-to-End 的 Exactly Once 需要外部Source的支持，比如上面我們說過 Apache Flink的Checkpointing機(jī)制會(huì)在Source節(jié)點(diǎn)記錄讀取的Position，那就需要外部數(shù)據(jù)提供讀取的Position和支持根據(jù)Position進(jìn)行數(shù)據(jù)讀取。

6. 外部Sink容錯(cuò)

Apache Flink 要做到 End-to-End 的 Exactly Once 相對(duì)比較困難，如上場景三所述，當(dāng)Sink Operator節(jié)點(diǎn)宕機(jī)，重新恢復(fù)時(shí)候根據(jù)Apache Flink 內(nèi)部系統(tǒng)容錯(cuò) exactly once的保證,系統(tǒng)會(huì)回滾到上次成功的Checkpoin繼續(xù)寫入，但是上次成功Checkpoint之后當(dāng)前Checkpoint未完成之前已經(jīng)把一部分新數(shù)據(jù)寫入到kafka了. Apache Flink自上次成功的Checkpoint繼續(xù)寫入kafka，就造成了kafka再次接收到一份同樣的來自Sink Operator的數(shù)據(jù),進(jìn)而破壞了End-to-End 的 Exactly Once 語義(重復(fù)寫入就變成了At Least Once了)，如果要解決這一問題，Apache Flink 利用Two phase commit(兩階段提交)的方式來進(jìn)行處理。本質(zhì)上是Sink Operator 需要感知整體Checkpoint的完成，并在整體Checkpoint完成時(shí)候?qū)⒂?jì)算結(jié)果寫入Kafka。

五、流批統(tǒng)一的計(jì)算引擎

批與流是兩種不同的數(shù)據(jù)處理模式，如Apache Storm只支持流模式的數(shù)據(jù)處理，Apache Spark只支持批(Micro Batching)模式的數(shù)據(jù)處理。那么Apache Flink 是如何做到既支持流處理模式也支持批處理模式呢?

1. 統(tǒng)一的數(shù)據(jù)傳輸層

開篇我們就介紹Apache Flink 的 "命脈"是以"批是流的特例"為導(dǎo)向來進(jìn)行引擎的設(shè)計(jì)的，系統(tǒng)設(shè)計(jì)成為 "Native Streaming"的模式進(jìn)行數(shù)據(jù)處理。那么Apache FLink將批模式執(zhí)行的任務(wù)看做是流式處理任務(wù)的特殊情況，只是在數(shù)據(jù)上批是有界的(有限數(shù)量的元素)。

Apache Flink 在網(wǎng)絡(luò)傳輸層面有兩種數(shù)據(jù)傳輸模式：

• PIPELINED模式 - 即一條數(shù)據(jù)被處理完成以后，立刻傳輸?shù)较乱粋€(gè)節(jié)點(diǎn)進(jìn)行處理。
• BATCH 模式 - 即一條數(shù)據(jù)被處理完成后，并不會(huì)立刻傳輸?shù)较乱粋€(gè)節(jié)點(diǎn)進(jìn)行處理，而是寫入到緩存區(qū)，如果緩存寫滿就持久化到本地硬盤上，***當(dāng)所有數(shù)據(jù)都被處理完成后，才將數(shù)據(jù)傳輸?shù)较乱粋€(gè)節(jié)點(diǎn)進(jìn)行處理。

對(duì)于批任務(wù)而言同樣可以利用PIPELINED模式，比如我要做count統(tǒng)計(jì)，利用PIPELINED模式能拿到更好的執(zhí)行性能。只有在特殊情況，比如SortMergeJoin，這時(shí)候我們需要全局?jǐn)?shù)據(jù)排序，才需要BATCH模式。大部分情況流與批可用統(tǒng)一的傳輸策略，只有特殊情況，才將批看做是流的一個(gè)特例繼續(xù)特殊處理。

2. 統(tǒng)一任務(wù)調(diào)度層

Apache Flink 在任務(wù)調(diào)度上流與批共享統(tǒng)一的資源和任務(wù)調(diào)度機(jī)制(后續(xù)章節(jié)會(huì)詳細(xì)介紹)。

3. 統(tǒng)一的用戶API層

Apache Flink 在DataStremAPI和DataSetAPI基礎(chǔ)上，為用戶提供了流批統(tǒng)一的上層TableAPI和SQL，在語法和語義上流批進(jìn)行高度統(tǒng)一。(其中DataStremAPI和DataSetAPI對(duì)流和批進(jìn)行了分別抽象，這一點(diǎn)并不優(yōu)雅，在Alibaba內(nèi)部對(duì)其進(jìn)行了統(tǒng)一抽象)。

4. 求同存異

Apache Flink 是流批統(tǒng)一的計(jì)算引擎，并不意味著流與批的任務(wù)都走統(tǒng)一的code path，在對(duì)底層的具體算子的實(shí)現(xiàn)也是有各自的處理的，在具體功能上面會(huì)根據(jù)不同的特性區(qū)別處理。比如 批沒有Checkpoint機(jī)制，流上不能做SortMergeJoin。

六、Apache Flink 架構(gòu)

1. 組件棧

我們上面內(nèi)容已經(jīng)介紹了很多Apache Flink的各種組件，下面我們整體概覽一下全貌，如下：

TableAPI和SQL都建立在DataSetAPI和DataStreamAPI的基礎(chǔ)之上，那么TableAPI和SQL是如何轉(zhuǎn)換為DataStream和DataSet的呢?

2. TableAPI&SQL到DataStrem&DataSet的架構(gòu)

TableAPI&SQL最終會(huì)經(jīng)過Calcite優(yōu)化之后轉(zhuǎn)換為DataStream和DataSet，具體轉(zhuǎn)換示意如下：

對(duì)于流任務(wù)最終會(huì)轉(zhuǎn)換成DataStream，對(duì)于批任務(wù)最終會(huì)轉(zhuǎn)換成DataSet。

3. ANSI-SQL的支持

Apache Flink 之所以利用ANSI-SQL作為用戶統(tǒng)一的開發(fā)語言，是因?yàn)镾QL有著非常明顯的優(yōu)點(diǎn)，如下：

• Declarative - 用戶只需要表達(dá)我想要什么，不用關(guān)心如何計(jì)算。
• Optimized - 查詢優(yōu)化器可以為用戶的 SQL 生成***的執(zhí)行計(jì)劃，獲取***的查詢性能。
• Understandable - SQL語言被不同領(lǐng)域的人所熟知，用SQL 作為跨團(tuán)隊(duì)的開發(fā)語言可以很大地提高效率。
• Stable - SQL 是一個(gè)擁有幾十年歷史的語言，是一個(gè)非常穩(wěn)定的語言，很少有變動(dòng)。
• Unify - Apache Flink在引擎上對(duì)流與批進(jìn)行統(tǒng)一，同時(shí)又利用ANSI-SQL在語法和語義層面進(jìn)行統(tǒng)一。

4. ***擴(kuò)展的優(yōu)化機(jī)制

Apache Flink 利用Apache Calcite對(duì)SQL進(jìn)行解析和優(yōu)化，Apache Calcite采用Calcite是開源的一套查詢引擎，實(shí)現(xiàn)了兩套Planner：

• HepPlanner - 是RBO(Rule Base Optimize)模式，基于規(guī)則的優(yōu)化。
• VolcanoPlanner - 是CBO(Cost Base Optimize)模式，基于成本的優(yōu)化。

Flink SQL會(huì)利用Calcite解析優(yōu)化之后，最終轉(zhuǎn)換為底層的DataStrem和Dataset。上圖中 Batch rules和Stream rules可以根據(jù)優(yōu)化需要***添加優(yōu)化規(guī)則。

七、豐富的類庫和算子

Apache Flink 優(yōu)秀的架構(gòu)就像一座摩天大廈的地基一樣為Apache Flink 持久的生命力打下了良好的基礎(chǔ)，為打造Apache Flink豐富的功能生態(tài)留下***的空間。

1. 類庫

• CEP - 復(fù)雜事件處理類庫，核心是一個(gè)狀態(tài)機(jī)，廣泛應(yīng)用于事件驅(qū)動(dòng)的監(jiān)控預(yù)警類業(yè)務(wù)場景。
• ML - 機(jī)器學(xué)習(xí)類庫，機(jī)器學(xué)習(xí)主要是識(shí)別數(shù)據(jù)中的關(guān)系、趨勢和模式，一般應(yīng)用在預(yù)測類業(yè)務(wù)場景。
• GELLY - 圖計(jì)算類庫，圖計(jì)算更多的是考慮邊和點(diǎn)的概念，一般被用來解決網(wǎng)狀關(guān)系的業(yè)務(wù)場景。

2. 算子

Apache Flink 提供了豐富的功能算子，對(duì)于數(shù)據(jù)流的處理來講，可以分為單流處理(一個(gè)數(shù)據(jù)源)和多流處理(多個(gè)數(shù)據(jù)源)。

3. 多流操作

• UNION - 將多個(gè)字段類型一致數(shù)據(jù)流合并為一個(gè)數(shù)據(jù)流，如下示意：

• JOIN - 將多個(gè)數(shù)據(jù)流(數(shù)據(jù)類型可以不一致)聯(lián)接為一個(gè)數(shù)據(jù)流，如下示意：

如上通過UION和JOIN我們可以將多流最終變成單流，Apache Flink 在單流上提供了更多的操作算子。

4. 單流操作

將多流變成單流之后，我們按數(shù)據(jù)輸入輸出的不同歸類如下：

如上表格對(duì)單流上面操作做簡單歸類，除此之外還可以做 過濾，排序，窗口等操作，我們后續(xù)章節(jié)會(huì)逐一介紹。

4. 存在的問題

Apache Flink 目前的架構(gòu)還存在很大的優(yōu)化空間，比如前面提到的DataStreamAPI和DataSetAPI其實(shí)是流與批在API層面不統(tǒng)一的體現(xiàn)，同時(shí)看具體實(shí)現(xiàn)會(huì)發(fā)現(xiàn)DataStreamAPI會(huì)生成Transformation tree然后生成StreamGraph，***生成JobGraph，底層對(duì)應(yīng)StreamTask，但DataSetAPI會(huì)形成Operator tree，flink-optimize模塊會(huì)對(duì)Batch Plan進(jìn)行優(yōu)化，形成Optimized Plan 后形成JobGraph,***形成BatchTask。具體示意如下：

這種情況其實(shí) DataStreamAPI到Runtime 和 DataSetAPI到Runtime的實(shí)現(xiàn)上并沒有得到***程度的統(tǒng)一和復(fù)用。在這一點(diǎn)上面Aalibab 對(duì)Apache Flink 的增強(qiáng)在架構(gòu)和實(shí)現(xiàn)上都進(jìn)行了進(jìn)一步優(yōu)化。

八、Alibaba對(duì)Apache Flink的增強(qiáng)架構(gòu)

1. 組件棧

Alibaba 對(duì)Apache Flink進(jìn)行了大量的架構(gòu)優(yōu)化，如下架構(gòu)是一直努力的方向，大部分功能還在持續(xù)開發(fā)中，具體如下：

如上架構(gòu)我們發(fā)現(xiàn)較大的變化是：

• Query Processing - 我們增加了Query Processing層，在這一層進(jìn)行統(tǒng)一的流和批的查詢優(yōu)化和底層算子的轉(zhuǎn)換。
• DAG API - 我們在Runtime層面統(tǒng)一抽象API接口，在API層對(duì)流與批進(jìn)行統(tǒng)一。

2. TableAPI&SQL到Runtime的架構(gòu)

Apache Flink執(zhí)行層是流批統(tǒng)一的設(shè)計(jì)，在API和算子設(shè)計(jì)上面我們盡量達(dá)到流批的共享，在TableAPI和SQL層無論是流任務(wù)還是批任務(wù)最終都轉(zhuǎn)換為統(tǒng)一的底層實(shí)現(xiàn)。示意圖如下：

這個(gè)層面最核心的變化是批最終也會(huì)生成StreamGraph，執(zhí)行層運(yùn)行Stream Task。

九、特別說明

后續(xù)章節(jié)會(huì)以Alibaba對(duì)Apache Flink的增強(qiáng)為主介紹功能算子，篇章中分享的功能可能開源暫時(shí)沒有，但這些的內(nèi)容后續(xù)Alibaba會(huì)共享給社區(qū)，需要大家耐心等待。

十、小結(jié)

本篇概要的介紹了"批是流的特例"這一設(shè)計(jì)觀點(diǎn)是Apache Flink的"命脈"，它決定了Apache Flink的運(yùn)行模式是純流式的，這在實(shí)時(shí)計(jì)算場景的"低延遲"需求上，相對(duì)于Micro Batching模式占據(jù)了架構(gòu)的絕對(duì)優(yōu)勢，同時(shí)概要的向大家介紹了Apache Flink的部署模式，容錯(cuò)處理，引擎的統(tǒng)一性和Apache Flink的架構(gòu)，***和大家分享了Alibaba對(duì)Apache Flink的增強(qiáng)架構(gòu)，以及對(duì)開源Apache Flink所作出的優(yōu)化。

本篇沒有對(duì)具體技術(shù)進(jìn)行詳細(xì)展開，大家只要對(duì)Apache Flink有初步感知，頭腦中知道Alibaba對(duì)Apache Flink進(jìn)行了架構(gòu)優(yōu)化，增加了眾多功能就可以了，至于Apache Flink的具體技術(shù)細(xì)節(jié)和實(shí)現(xiàn)原理，以及Alibaba對(duì)Apache Flink做了哪些架構(gòu)優(yōu)化和增加了哪些功能后續(xù)章節(jié)會(huì)展開介紹!

# 關(guān)于點(diǎn)贊和評(píng)論

本系列文章難免有很多缺陷和不足，真誠希望讀者對(duì)有收獲的篇章給予點(diǎn)贊鼓勵(lì)，對(duì)有不足的篇章給予反饋和建議，先行感謝大家!

作者孫金城，花名 金竹，目前就職于阿里巴巴，自2015年以來一直投入于基于Apache Flink的阿里巴巴計(jì)算平臺(tái)Blink的設(shè)計(jì)研發(fā)工作。

【本文為51CTO專欄作者“金竹”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】

戳這里，看該作者更多好文