鏈接：https://zhuanlan.zhihu.com/p/20585530
來源：知乎
著作權(quán)歸作者所有替梨。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)撬腾，非商業(yè)轉(zhuǎn)載請(qǐng)注明出處螟蝙。
本文由本人發(fā)表于《程序員》雜志恢恼，原文鏈接在此：深入理解Apache Flink核心技術(shù)民傻，如欲轉(zhuǎn)載，請(qǐng)獲取CSDN授權(quán)场斑。
Flink項(xiàng)目是大數(shù)據(jù)處理領(lǐng)域最近冉冉升起的一顆新星漓踢，其不同于其他大數(shù)據(jù)項(xiàng)目的諸多特性吸引了越來越多的人關(guān)注Flink項(xiàng)目。本文將深入分析Flink一些關(guān)鍵的技術(shù)與特性漏隐，希望能夠幫助讀者對(duì)Flink有更加深入的了解喧半，對(duì)其他大數(shù)據(jù)系統(tǒng)的開發(fā)者也能有所裨益。
注：本文假設(shè)讀者對(duì)MapReduce青责，Spark及Storm等大數(shù)據(jù)處理系統(tǒng)有基本了解挺据，同時(shí)熟悉流處理與批處理的基本概念。
Flink簡介
Flink的核心是一個(gè)流式的數(shù)據(jù)流執(zhí)行引擎脖隶，其針對(duì)數(shù)據(jù)流的分布式計(jì)算提供了數(shù)據(jù)分布扁耐，數(shù)據(jù)通信以及容錯(cuò)機(jī)制等功能〔澹基于流執(zhí)行引擎婉称，F(xiàn)link提供了諸多更高抽象層的API以方便用戶編寫分布式任務(wù)：
1. DataSet API, 對(duì)靜態(tài)數(shù)據(jù)進(jìn)行批處理操作，將靜態(tài)數(shù)據(jù)抽象成分布式的數(shù)據(jù)集，用戶可以方便的采用Flink提供的各種操作符對(duì)分布式數(shù)據(jù)集進(jìn)行各種操作王暗，支持Java悔据，Scala和Python。
2. DataStream API俗壹，對(duì)數(shù)據(jù)流進(jìn)行流處理操作科汗，將流式的數(shù)據(jù)抽象成分布式的數(shù)據(jù)流，用戶可以方便的采用Flink提供的各種操作符對(duì)分布式數(shù)據(jù)流進(jìn)行各種操作绷雏，支持Java和Scala肛捍。
3. Table API，對(duì)結(jié)構(gòu)化數(shù)據(jù)進(jìn)行查詢操作之众，將結(jié)構(gòu)化數(shù)據(jù)抽象成關(guān)系表拙毫，并通過Flink提供的類SQL的DSL對(duì)關(guān)系表進(jìn)行各種查詢操作，支持Java和Scala棺禾。
此外缀蹄，F(xiàn)link還針對(duì)特定的應(yīng)用領(lǐng)域提供了領(lǐng)域庫，例如：
1. Flink ML膘婶，F(xiàn)link的機(jī)器學(xué)習(xí)庫缺前，提供了機(jī)器學(xué)習(xí)Pipelines API以及很多的機(jī)器學(xué)習(xí)算法實(shí)現(xiàn)。
2. Gelly悬襟，F(xiàn)link的圖計(jì)算庫衅码，提供了圖計(jì)算的相關(guān)API以及很多的圖計(jì)算算法實(shí)現(xiàn)。
Flink的技術(shù)棧如下圖所示：
圖1 Flink技術(shù)棧
此外脊岳，F(xiàn)link也可以方便地和其他的Hadoop生態(tài)圈的項(xiàng)目集成逝段，例如，F(xiàn)link可以讀取存儲(chǔ)在HDFS或HBase中的靜態(tài)數(shù)據(jù)割捅，以Kafka作為流式的數(shù)據(jù)源奶躯，直接重用MapReduce/Storm代碼，或是通過YARN申請(qǐng)集群資源等等亿驾。
統(tǒng)一的批處理與流處理系統(tǒng)
在大數(shù)據(jù)處理領(lǐng)域嘹黔，批處理任務(wù)與流處理任務(wù)一般被認(rèn)為是兩種不同的任務(wù)，一個(gè)大數(shù)據(jù)項(xiàng)目一般會(huì)被設(shè)計(jì)為只能處理其中一種任務(wù)莫瞬，例如Apache Storm儡蔓，Apache Smaza只支持流處理任務(wù)，而Aapche MapReduce疼邀， Apache Tez喂江，Apache Spark只支持批處理任務(wù)。Spark Streaming是Apache Spark之上支持流處理任務(wù)的子系統(tǒng)檩小，看似一個(gè)特例开呐，實(shí)則不然。Spark Streaming采用了一種micro-batch的架構(gòu)，即將輸入的數(shù)據(jù)流切分成細(xì)粒度的batch數(shù)據(jù)筐付，對(duì)于每一個(gè)batch數(shù)據(jù)卵惦，以此為輸入提交一個(gè)批處理Spark任務(wù)，所以Spark Streaming本質(zhì)上還是基于Spark批處理系統(tǒng)對(duì)流式數(shù)據(jù)進(jìn)行處理瓦戚，和Apache Storm沮尿，Apache Smaza等完全流式的數(shù)據(jù)處理方式完全不同。Flink能夠同時(shí)處理批處理任務(wù)與流處理任務(wù)较解，其靈活的執(zhí)行引擎支持完全原生的批量的數(shù)據(jù)處理和流式的數(shù)據(jù)處理畜疾。
在執(zhí)行引擎這一層，流處理系統(tǒng)與批處理系統(tǒng)最大的不同在于節(jié)點(diǎn)間數(shù)據(jù)傳輸?shù)姆绞接∠巍?duì)于一個(gè)流處理系統(tǒng)啡捶，其節(jié)點(diǎn)間數(shù)據(jù)傳輸?shù)臉?biāo)準(zhǔn)模型是：當(dāng)一條數(shù)據(jù)被處理完成后，序列化到緩存中奸焙，然后立刻通過網(wǎng)絡(luò)傳輸?shù)较乱粋€(gè)節(jié)點(diǎn)瞎暑，由下一個(gè)節(jié)點(diǎn)繼續(xù)處理。而對(duì)于一個(gè)批處理系統(tǒng)与帆，其節(jié)點(diǎn)間數(shù)據(jù)傳輸?shù)臉?biāo)準(zhǔn)模型是：當(dāng)一條數(shù)據(jù)被處理完成后了赌，序列化到緩存中，并不會(huì)立刻通過網(wǎng)絡(luò)傳輸?shù)较乱粋€(gè)節(jié)點(diǎn)玄糟，當(dāng)緩存寫滿勿她，就持久化到本地硬盤上，當(dāng)所有數(shù)據(jù)都被處理完成后阵翎，才開始將處理后的數(shù)據(jù)通過網(wǎng)絡(luò)傳輸?shù)较乱粋€(gè)節(jié)點(diǎn)逢并。這兩種數(shù)據(jù)傳輸模式是兩個(gè)極端，對(duì)應(yīng)的是流處理系統(tǒng)對(duì)低延遲的要求和批處理系統(tǒng)對(duì)高吞吐量的要求贮喧。Flink的執(zhí)行引擎采用了一種十分靈活的方式筒狠，同時(shí)支持了這兩種數(shù)據(jù)傳輸模型。Flink以固定的緩存塊為單位進(jìn)行網(wǎng)絡(luò)數(shù)據(jù)傳輸箱沦，用戶可以通過緩存塊超時(shí)值指定緩存塊的傳輸時(shí)機(jī)。如果緩存塊的超時(shí)值為0雇庙，則Flink的數(shù)據(jù)傳輸方式類似上面提到的流處理系統(tǒng)的標(biāo)準(zhǔn)模型谓形，此時(shí)系統(tǒng)可以獲得最低的處理延遲。如果緩存塊的超時(shí)值為無限大疆前，則Flink的數(shù)據(jù)傳輸方式類似上面提到的批處理系統(tǒng)的標(biāo)準(zhǔn)模型寒跳，此時(shí)系統(tǒng)可以獲得最高的處理吞吐量。同時(shí)緩存塊的超時(shí)值也可以設(shè)置為0到無限大之間的任意值竹椒。緩存塊的超時(shí)閾值越小童太，則Flink流處理執(zhí)行引擎的數(shù)據(jù)處理延遲越低，但吞吐量也會(huì)越低，緩存塊的超時(shí)閾值越大時(shí)书释，則反之翘贮。通過調(diào)整緩存塊的超時(shí)閾值，用戶可根據(jù)自己的需要靈活的權(quán)衡Flink的延遲和吞吐量爆惧。
圖2 Flink執(zhí)行引擎數(shù)據(jù)傳輸模式
在統(tǒng)一的流式執(zhí)行引擎的基礎(chǔ)上狸页，F(xiàn)link同時(shí)支持了流處理系統(tǒng)與批處理系統(tǒng)，并且保證了其流處理系統(tǒng)與批處理系統(tǒng)的性能（延遲扯再，吞吐量等）芍耘，相對(duì)于其他原生的流處理與批處理系統(tǒng)，并沒有因?yàn)榻y(tǒng)一的執(zhí)行引擎而受到影響熄阻。用戶可以在Flink上同時(shí)執(zhí)行批處理任務(wù)與流處理任務(wù)斋竞，這大大減輕了用戶安裝，部署秃殉，監(jiān)控窃页，維護(hù)等成本。
Flink流處理的容錯(cuò)機(jī)制
對(duì)于一個(gè)分布式系統(tǒng)來說复濒，單個(gè)進(jìn)程或是節(jié)點(diǎn)崩潰導(dǎo)致整個(gè)Job失敗是經(jīng)常發(fā)生的事情脖卖，在異常發(fā)生的時(shí)候不會(huì)丟失用戶數(shù)據(jù)，并能夠自動(dòng)恢復(fù)是分布式系統(tǒng)的需要支持的特性之一巧颈。本節(jié)主要介紹Flink流處理系統(tǒng)對(duì)于任務(wù)級(jí)別的容錯(cuò)機(jī)制畦木。
批處理系統(tǒng)比較容易實(shí)現(xiàn)容錯(cuò)機(jī)制，由于文件可以重復(fù)訪問砸泛，當(dāng)某個(gè)任務(wù)失敗后十籍，重啟該任務(wù)即可。但是在流處理系統(tǒng)中唇礁，由于數(shù)據(jù)源是無限的數(shù)據(jù)流勾栗，一個(gè)流處理任務(wù)甚至可能會(huì)執(zhí)行幾個(gè)月，將所有數(shù)據(jù)緩存或是持久化盏筐，留待以后重復(fù)訪問基本上是不可行的围俘。Flink基于分布式快照與可部分重發(fā)的數(shù)據(jù)源實(shí)現(xiàn)了容錯(cuò)，用戶可自定義對(duì)整個(gè)Job進(jìn)行快照的時(shí)間間隔琢融，當(dāng)出現(xiàn)任務(wù)失敗時(shí)界牡，F(xiàn)link將整個(gè)Job恢復(fù)到最近一次快照的狀態(tài)，并從數(shù)據(jù)源重發(fā)快照之后的數(shù)據(jù)漾抬。
Flink的分布式快照的實(shí)現(xiàn)借鑒了Chandy和Lamport在1985年發(fā)表的一篇關(guān)于分布式快照的論文宿亡，其實(shí)現(xiàn)的主要思想如下：
按照用戶自定義的分布式快照間隔時(shí)間，F(xiàn)link會(huì)在定時(shí)在所有數(shù)據(jù)源中插入一種特殊的快照標(biāo)記消息纳令，這些快照標(biāo)記消息和其他消息一樣在DAG中流動(dòng)挽荠，但是不會(huì)被用戶定義的業(yè)務(wù)邏輯所處理克胳，每一個(gè)快照標(biāo)記消息都將其所在的數(shù)據(jù)流分成兩部分：本次快照數(shù)據(jù)和下次快照數(shù)據(jù)。
圖3 Flink包含快照標(biāo)記消息的消息流
快照標(biāo)記消息沿著DAG流經(jīng)各個(gè)操作符圈匆，當(dāng)操作符處理到快照標(biāo)記消息時(shí)漠另，會(huì)對(duì)自己的狀態(tài)進(jìn)行快照，并存儲(chǔ)起來臭脓。當(dāng)一個(gè)操作符有多個(gè)輸入的時(shí)候酗钞，F(xiàn)link會(huì)將先抵達(dá)的快照標(biāo)記消息及其之后的消息緩存起來，當(dāng)所有的輸入中對(duì)應(yīng)該次快照的快照標(biāo)記消息全部抵達(dá)后来累，操作符對(duì)自己的狀態(tài)快照并存儲(chǔ)砚作，之后處理所有快照標(biāo)記消息之后的已緩存消息。操作符對(duì)自己的狀態(tài)快照并存儲(chǔ)可以是異步與增量的操作嘹锁，并不需要阻塞消息的處理葫录。分布式快照的流程如下圖所示：
圖4 Flink分布式快照流程圖
當(dāng)所有的Data Sink(終點(diǎn)操作符)都收到快照標(biāo)記信息并對(duì)自己的狀態(tài)快照和存儲(chǔ)后，整個(gè)分布式快照就完成了领猾，同時(shí)通知數(shù)據(jù)源釋放該快照標(biāo)記消息之前的所有消息米同。若之后發(fā)生節(jié)點(diǎn)崩潰等異常情況時(shí)，只需要恢復(fù)之前存儲(chǔ)的分布式快照狀態(tài)摔竿，并從數(shù)據(jù)源重發(fā)該快照以后的消息就可以了面粮。
Exactly-Once是流處理系統(tǒng)需要支持的一個(gè)非常重要的特性，它保證每一條消息被流處理系統(tǒng)處理一次继低，且僅被處理一次熬苍，許多流處理任務(wù)的業(yè)務(wù)邏輯都依賴于Exactly-Once特性。相對(duì)于At-Least-Once或是At-Most-Once, Exactly-Once特性對(duì)流處理系統(tǒng)的要求更嚴(yán)格袁翁，實(shí)現(xiàn)也更困難柴底。Flink基于分布式快照實(shí)現(xiàn)了Exactly-Once特性。
相對(duì)于其他流處理系統(tǒng)的容錯(cuò)方案粱胜，F(xiàn)link基于分布式快照的方案在功能和性能方面都具有很多優(yōu)點(diǎn)柄驻，包括：
1. 低延遲。由于操作符狀態(tài)的存儲(chǔ)可以是異步的焙压，所以進(jìn)行快照的過程基本上不會(huì)阻塞消息的處理鸿脓，對(duì)消息的延遲不會(huì)產(chǎn)生負(fù)面的影響。
2. 高吞吐量冗恨。當(dāng)操作符狀態(tài)較少時(shí)答憔，對(duì)吞吐量基本沒有影響。當(dāng)操作符狀態(tài)較多時(shí)掀抹，相對(duì)于其他的容錯(cuò)機(jī)制，分布式快照的時(shí)間間隔是用戶自定義的心俗，所以用戶可以權(quán)衡錯(cuò)誤恢復(fù)時(shí)間和吞吐量的要求傲武，調(diào)整分布式快照的時(shí)間間隔蓉驹。
3. 與業(yè)務(wù)邏輯的隔離。Flink的分布式快照機(jī)制與用戶的業(yè)務(wù)邏輯是完全隔離的揪利，用戶的業(yè)務(wù)邏輯不會(huì)依賴或是對(duì)分布式快照產(chǎn)生任何影響态兴。
4. 錯(cuò)誤恢復(fù)代價(jià)。分布式快照的時(shí)間間隔越短疟位，錯(cuò)誤恢復(fù)的時(shí)間越少埋嵌，與吞吐量負(fù)相關(guān)瞬场。
Flink流處理的時(shí)間窗口
對(duì)于流處理系統(tǒng)來說，流入的消息是無限的，所以對(duì)于聚合或是連接等操作辅辩，流處理系統(tǒng)需要對(duì)流入的消息進(jìn)行分段，然后基于每一段數(shù)據(jù)進(jìn)行聚合或是連接等操作左电。消息的分段即稱為窗口柿扣，流處理系統(tǒng)支持的窗口有很多類型，最常見的就是時(shí)間窗口祥绞，基于時(shí)間間隔對(duì)消息進(jìn)行分段處理非洲。本節(jié)主要介紹Flink流處理系統(tǒng)支持的各種時(shí)間窗口。
對(duì)于目前大部分流處理系統(tǒng)來說蜕径，時(shí)間窗口一般是根據(jù)Task所在節(jié)點(diǎn)的本地時(shí)鐘來進(jìn)行切分两踏，這種方式實(shí)現(xiàn)起來比較容易，不會(huì)阻塞消息處理兜喻。但是可能無法滿足某些應(yīng)用的要求梦染，例如：
1. 消息本身帶有時(shí)間戳，用戶希望按照消息本身的時(shí)間特性進(jìn)行分段處理虹统。
2. 由于不同節(jié)點(diǎn)的時(shí)鐘可能不同弓坞，以及消息在流經(jīng)各個(gè)節(jié)點(diǎn)時(shí)延遲不同，在某個(gè)節(jié)點(diǎn)屬于同一個(gè)時(shí)間窗口處理的消息车荔，流到下一個(gè)節(jié)點(diǎn)時(shí)可能被切分到不同的時(shí)間窗口中渡冻，從而產(chǎn)生不符合預(yù)期的結(jié)果。
Flink支持三種類型的時(shí)間窗口忧便，分別適用于用戶對(duì)于時(shí)間窗口不同類型的要求：
1. Operator Time族吻。根據(jù)Task所在節(jié)點(diǎn)的本地時(shí)鐘來進(jìn)行切分的時(shí)間窗口。
2. Event Time珠增。消息自帶時(shí)間戳超歌，根據(jù)消息的時(shí)間戳進(jìn)行處理，確保時(shí)間戳在同一個(gè)時(shí)間窗口的所有消息一定會(huì)被正確處理蒂教。由于消息可能是亂序流入Task的巍举，所以Task需要緩存當(dāng)前時(shí)間窗口消息處理的狀態(tài)，直到確認(rèn)屬于該時(shí)間窗口的所有消息都被處理后凝垛，才可以釋放其狀態(tài)懊悯。如果亂序的消息延遲很高的話蜓谋，會(huì)影響分布式系統(tǒng)的吞吐量和延遲。
3. Ingress Time炭分。有時(shí)消息本身并不帶有時(shí)間戳信息桃焕，但用戶依然希望按照消息而不是節(jié)點(diǎn)時(shí)鐘劃分時(shí)間窗口(例如，避免上面提到的第二個(gè)問題)捧毛。此時(shí)可以在消息源流入Flink流處理系統(tǒng)時(shí)观堂，自動(dòng)生成增量的時(shí)間戳賦予消息，之后處理的流程與Event Time相同呀忧。Ingress Time可以看成是Event Time的一個(gè)特例师痕，由于其在消息源處時(shí)間戳一定是有序的，所以在流處理系統(tǒng)中荐虐，相對(duì)于Event Time七兜，其亂序的消息延遲不會(huì)很高，因此對(duì)Flink分布式系統(tǒng)的吞吐量和延遲的影響也會(huì)更小福扬。
Event Time時(shí)間窗口的實(shí)現(xiàn)
Flink借鑒了Google的MillWheel項(xiàng)目腕铸，通過WaterMark來支持基于Event Time時(shí)間窗口。
當(dāng)操作符通過基于Event Time的時(shí)間窗口來處理數(shù)據(jù)時(shí)铛碑，它必須在確定所有屬于該時(shí)間窗口的消息全部流入此操作符后狠裹，才能開始處理數(shù)據(jù)。但是由于消息可能是亂序的汽烦，所以操作符無法直接確認(rèn)何時(shí)所有屬于該時(shí)間窗口的消息全部流入此操作符涛菠。WaterMark包含一個(gè)時(shí)間戳，F(xiàn)link使用WaterMark標(biāo)記所有小于該時(shí)間戳的消息都已流入撇吞，F(xiàn)link的數(shù)據(jù)源在確認(rèn)所有小于某個(gè)時(shí)間戳的消息都已輸出到Flink流處理系統(tǒng)后俗冻，會(huì)生成一個(gè)包含該時(shí)間戳的WaterMark，插入到消息流中輸出到Flink流處理系統(tǒng)中牍颈，F(xiàn)link操作符按照時(shí)間窗口緩存所有流入的消息迄薄，當(dāng)操作符處理到WaterMark時(shí)，它對(duì)所有小于該WaterMark時(shí)間戳的時(shí)間窗口的數(shù)據(jù)進(jìn)行處理并發(fā)送到下一個(gè)操作符節(jié)點(diǎn)煮岁，然后也將WaterMark發(fā)送到下一個(gè)操作符節(jié)點(diǎn)讥蔽。
為了保證能夠處理所有屬于某個(gè)時(shí)間窗口的消息，操作符必須等到大于這個(gè)時(shí)間窗口的WaterMark之后画机，才能開始對(duì)該時(shí)間窗口的消息進(jìn)行處理冶伞，相對(duì)于基于Operator Time的時(shí)間窗口，F(xiàn)link需要占用更多的內(nèi)存步氏，且會(huì)直接影響消息處理的延遲時(shí)間响禽。對(duì)此，一個(gè)可能的優(yōu)化措施是，對(duì)于聚合類的操作符金抡，可能可以提前對(duì)部分消息進(jìn)行聚合操作瀑焦，當(dāng)有屬于該時(shí)間窗口的新消息流入時(shí)腌且，基于之前的部分聚合結(jié)果繼續(xù)計(jì)算梗肝，這樣的話，只需緩存中間計(jì)算結(jié)果即可铺董，無需緩存該時(shí)間窗口的所有消息巫击。
對(duì)于基于Event Time時(shí)間窗口的操作符來說，流入WaterMark的時(shí)間戳與當(dāng)前節(jié)點(diǎn)的時(shí)鐘一致是最簡單理想的狀況了精续，但是在實(shí)際環(huán)境中是不可能的坝锰，由于消息的亂序以及前面節(jié)點(diǎn)處理效率的不同，總是會(huì)有某些消息流入時(shí)間大于其本身的時(shí)間戳重付，真實(shí)WaterMark時(shí)間戳與理想情況下WaterMark時(shí)間戳的差別稱為Time Skew顷级，如下圖所示：
圖5 WaterMark的Time Skew圖
Time Skew決定了該WaterMark與上一個(gè)WaterMark之間的時(shí)間窗口所有數(shù)據(jù)需要緩存的時(shí)間，Time Skew時(shí)間越長确垫，該時(shí)間窗口數(shù)據(jù)的延遲越長弓颈，占用內(nèi)存的時(shí)間也越長，同時(shí)會(huì)對(duì)流處理系統(tǒng)的吞吐量產(chǎn)生負(fù)面影響删掀。
基于時(shí)間戳的排序
在流處理系統(tǒng)中翔冀，由于流入的消息是無限的，所以對(duì)消息進(jìn)行排序基本上被認(rèn)為是不可行的披泪。但是在Flink流處理系統(tǒng)中纤子，基于WaterMark，F(xiàn)link實(shí)現(xiàn)了基于時(shí)間戳的全局排序款票。
Flink基于時(shí)間戳進(jìn)行排序的實(shí)現(xiàn)思路如下：排序操作符緩存所有流入的消息控硼，當(dāng)其接收到WaterMark時(shí)，對(duì)時(shí)間戳小于該WaterMark的消息進(jìn)行排序艾少，并發(fā)送到下一個(gè)節(jié)點(diǎn)卡乾，在此排序操作符中釋放所有時(shí)間戳小于該WaterMark的消息，繼續(xù)緩存流入的消息姆钉，等待下一個(gè)WaterMark觸發(fā)下一次排序说订。由于WaterMark保證了其之后不會(huì)出現(xiàn)時(shí)間戳比它小的消息，所以可以保證排序的正確性潮瓶。需要注意的是陶冷，如果排序操作符有多個(gè)節(jié)點(diǎn)，只能保證每個(gè)節(jié)點(diǎn)的流出消息是有序的毯辅，節(jié)點(diǎn)之間的消息不能保證有序埂伦，要實(shí)現(xiàn)全局有序，則只能有一個(gè)排序操作符節(jié)點(diǎn)思恐。
通過支持基于Event Time的消息處理沾谜，F(xiàn)link擴(kuò)展了其流處理系統(tǒng)的應(yīng)用范圍膊毁，使得更多的流處理任務(wù)可以通過Flink來執(zhí)行。
定制的內(nèi)存管理
略基跑，請(qǐng)參考上篇文章：脫離JVM婚温？ Hadoop生態(tài)圈的掙扎與演化 - 大數(shù)據(jù)技術(shù)與實(shí)踐 - 知乎專欄
總結(jié)
本文主要介紹了Flink項(xiàng)目的一些關(guān)鍵特性，F(xiàn)link是一個(gè)擁有諸多特色的項(xiàng)目媳否，包括其統(tǒng)一的批處理和流處理執(zhí)行引擎栅螟，通用大數(shù)據(jù)計(jì)算框架與傳統(tǒng)數(shù)據(jù)庫系統(tǒng)的技術(shù)結(jié)合，以及流處理系統(tǒng)的諸多技術(shù)創(chuàng)新等篱竭，因?yàn)槠邢蘖ν迹現(xiàn)link還有一些其他很有意思的特性沒有詳細(xì)介紹，比如DataSet API級(jí)別的執(zhí)行計(jì)劃優(yōu)化器掺逼，原生的迭代操作符等吃媒，感興趣的讀者可以通過Flink的官網(wǎng)了解更多Flink的詳細(xì)內(nèi)容。希望通過本文的介紹能夠讓讀者對(duì)Flink項(xiàng)目能有更多的了解吕喘，也讓更多的人使用甚至參與到Flink項(xiàng)目中去赘那。
引用
1. project tungsten：Project Tungsten: Bringing Spark Closer to Bare Metal
2. The "Memory Wall":Modern Microprocessors
3. flink memory management:Flink: Juggling with Bits and Bytes
4. java GC：Tuning Java Garbage Collection for Spark Applications
5. Project Valhalla:OpenJDK: Valhalla
6. java object size:dweiss/java-sizeof · GitHub
7.Big Data Performance Engineering
8. Flink distributed snapshot: High-throughput, low-latency, and exactly-once stream processing with Apache Flink
9. Flink Event Time: Time and Order in
