第 1 章 為何選擇 Flink
- 許多情況下，人們希望用低延遲或者實(shí)時(shí)的流處理來獲得數(shù)據(jù)的高時(shí)效性，前提是流處理本身是準(zhǔn)確且高效的
- 優(yōu)秀的流處理技術(shù)可以容錯(cuò)，而且能保證
exactlyonce2 -
Storm提供了低延遲的流處理，但是它為實(shí)時(shí)性付出了一些代價(jià)：很難實(shí)現(xiàn)高吞吐，并且其正確性沒能達(dá)到通常所需的水平。換句話說，它并不能保證exactlyonce；即便是它能夠保證的正確性級(jí)別，其開銷也相當(dāng)大
圖12：
Flink的一個(gè)優(yōu)勢(shì)是，它擁有諸多重要的流式計(jì)算功能。其他項(xiàng)目為了實(shí)現(xiàn)這些功能，都不得不付出代價(jià)。比如，Storm實(shí)現(xiàn)了低延遲，但是在作者撰寫本書時(shí)還做不到高吞吐，也不能在故障發(fā)生時(shí)準(zhǔn)確地處理計(jì)算狀態(tài)；SparkStreaming通過采用微批處理方法實(shí)現(xiàn)了高吞吐和容錯(cuò)性，但是犧牲了低延遲和實(shí)時(shí)處理能力，也不能使窗口與自然時(shí)間相匹配，并且表現(xiàn)力欠佳
- “
ApacheFlink是為分布式、高性能、隨時(shí)可用以及準(zhǔn)確的流處理應(yīng)用程序打造的開源流處理框架?！?code>Flink不僅能提供同時(shí)支持高吞吐和exactlyonce語(yǔ)義的實(shí)時(shí)計(jì)算，還能提供批量數(shù)據(jù)處理 -
flink一詞表示快速和靈巧。項(xiàng)目采用一只松鼠的彩色圖案作為logo，這不僅因?yàn)樗墒缶哂锌焖俸挽`巧的特點(diǎn)，還因?yàn)榘亓值乃墒笥幸环N迷人的紅棕色 - 2014年12月一躍成為
Apache軟件基金會(huì)的頂級(jí)項(xiàng)目。作為Apache軟件基金會(huì)的5個(gè)最大的大數(shù)據(jù)項(xiàng)目之一，Flink在全球范圍內(nèi)擁有200多位開發(fā)人員，以及若干公司中的諸多上線場(chǎng)景，有些甚至是世界500強(qiáng)的公司 -
Flink是如何同時(shí)實(shí)現(xiàn)批處理與流處理的呢？答案是，Flink將批處理（即處理有限的靜態(tài)數(shù)據(jù)）視作一種特殊的流處理 -
FlinkRuntime執(zhí)行引擎可以作為YARN（YetAnotherResourceNegotiator）的應(yīng)用程序在集群上運(yùn)行，也可以在Mesos集群上運(yùn)行，還可以在單機(jī)上運(yùn)行（這對(duì)于調(diào)試Flink應(yīng)用程序來說非常有用）
圖14：
Flink技術(shù)棧的核心組成部分。值得一提的是，Flink分別提供了面向流處理的接口（DataStreamAPI）和面向批處理的接口（DataSetAPI）。因此，Flink既可以完成流處理，也可以完成批處理。Flink支持的拓展庫(kù)涉及機(jī)器學(xué)習(xí)（FlinkML）、復(fù)雜事件處理（CEP），以及圖計(jì)算（Gelly），還有分別針對(duì)流處理和批處理的TableAPI
-
Flink解決了許多問題，比如保證了exactlyonce語(yǔ)義和基于事件時(shí)間的數(shù)據(jù)窗口。開發(fā)人員不再需要在應(yīng)用層解決相關(guān)問題，這大大地降低了出現(xiàn)bug的概率 - 不用再在編寫應(yīng)用程序代碼時(shí)考慮如何解決問題，所以工程師的時(shí)間得以充分利用，整個(gè)團(tuán)隊(duì)也因此受益。好處并不局限于縮短開發(fā)時(shí)間，隨著靈活性的增加，團(tuán)隊(duì)整體的開發(fā)質(zhì)量得到了提高，運(yùn)維工作也變得更容易、更高效
布衣格電信
支持真正的流處理——通過上層的
API和下層的執(zhí)行引擎都能實(shí)時(shí)進(jìn)行流處理，這滿足了我們對(duì)可編程性和低延遲的需求。此外，使用Flink，我們的系統(tǒng)得以快速上線，這是其他任何一種方案都做不到的。如此一來，我們就有了更多的人手開發(fā)新的業(yè)務(wù)邏輯
-
ETL是Extract、Transform和Load的縮寫，即抽取、轉(zhuǎn)換和加載
第 2 章 流處理架構(gòu)
- 以流為基礎(chǔ)的架構(gòu)設(shè)計(jì)讓數(shù)據(jù)記錄持續(xù)地從數(shù)據(jù)源流向應(yīng)用程序，并在各個(gè)應(yīng)用程序間持續(xù)流動(dòng)。沒有一個(gè)數(shù)據(jù)庫(kù)來集中存儲(chǔ)全局狀態(tài)數(shù)據(jù)，取而代之的是共享且永不停止的流數(shù)據(jù)，它是唯一正確的數(shù)據(jù)源，記錄了業(yè)務(wù)數(shù)據(jù)的歷史。在流處理架構(gòu)中，每個(gè)應(yīng)用程序都有自己的數(shù)據(jù)，這些數(shù)據(jù)采用本地?cái)?shù)據(jù)庫(kù)或分布式文件進(jìn)行存儲(chǔ)
消息傳輸層和流處理層
- 如何有效地實(shí)現(xiàn)流處理架構(gòu)并從
Flink中獲益呢？一個(gè)常見的做法是設(shè)置消息傳輸層和流處理層 - (1)消息傳輸層從各種數(shù)據(jù)源（生產(chǎn)者）采集連續(xù)事件產(chǎn)生的數(shù)據(jù)，并傳輸給訂閱了這些數(shù)據(jù)的應(yīng)用程序和服務(wù)（消費(fèi)者）
- (2)流處理層有3個(gè)用途：
- 持續(xù)地將數(shù)據(jù)在應(yīng)用程序和系統(tǒng)間移動(dòng)；
- 聚合并處理事件；
- 在本地維持應(yīng)用程序的狀態(tài)
圖21：
Flink項(xiàng)目的架構(gòu)有兩個(gè)主要組成部分：消息傳輸層和由Flink提供的流處理層。消息傳輸層負(fù)責(zé)傳輸連續(xù)事件產(chǎn)生的消息，能夠提供消息傳輸?shù)南到y(tǒng)包括Kafka和MapRStreams。MapRStreams是MapR融合數(shù)據(jù)平臺(tái)的一個(gè)主要組成部分，它兼容KafkaAPI
- 兼具高性能和持久性對(duì)于消息傳輸系統(tǒng)來說至關(guān)重要；
Kafka和MapRStreams都可以滿足這個(gè)需求 - 具有持久性的好處之一是消息可以重播
第 3 章 Flink 的用途
-
Flink解決了可能影響正確性的幾個(gè)問題，包括如何在故障發(fā)生之后仍能進(jìn)行有狀態(tài)的計(jì)算 -
Flink所用的技術(shù)叫作檢查點(diǎn)（checkpoint） - 在每個(gè)檢查點(diǎn)，系統(tǒng)都會(huì)記錄中間計(jì)算狀態(tài)，從而在故障發(fā)生時(shí)準(zhǔn)確地重置。這一方法使系統(tǒng)以低開銷的方式擁有了容錯(cuò)能力——當(dāng)一切正常時(shí)，檢查點(diǎn)機(jī)制對(duì)系統(tǒng)的影響非常小
-
Flink還承擔(dān)了跟蹤計(jì)算狀態(tài)的任務(wù)，從而減輕了開發(fā)人員的負(fù)擔(dān)，簡(jiǎn)化了編程工作，并提高了應(yīng)用程序的成功率。用同一種技術(shù)來實(shí)現(xiàn)流處理和批處理，大大地簡(jiǎn)化了開發(fā)和運(yùn)維工作
第 4 章 對(duì)時(shí)間的處理
- 用流處理器編程和用批處理器編程最關(guān)鍵的區(qū)別在于對(duì)時(shí)間的處理。舉一個(gè)非常簡(jiǎn)單的例子：計(jì)數(shù)。事件流數(shù)據(jù)（如微博內(nèi)容、點(diǎn)擊數(shù)據(jù)和交易數(shù)據(jù)）不斷產(chǎn)生，我們需要用
key將事件分組，并且每隔一段時(shí)間（比如一小時(shí)）就針對(duì)每一個(gè)key對(duì)應(yīng)的事件計(jì)數(shù)。這是眾所周知的“大數(shù)據(jù)”應(yīng)用，與MapReduce的詞頻統(tǒng)計(jì)例子相似 - 流處理區(qū)別于批處理最主要的兩點(diǎn)是：
- 流即是流，不必人為地將它分割為文件；
- 時(shí)間的定義被明確地寫入應(yīng)用程序代碼（如以上代碼的時(shí)間窗口），而不是與攝取、計(jì)算和調(diào)度等過程牽扯不清
- 流處理系統(tǒng)中的批處理必須符合以下兩點(diǎn)要求
- 批處理只作為提高系統(tǒng)性能的機(jī)制。批量越大，系統(tǒng)的吞吐量就越大
- 為了提高性能而使用的批處理必須完全獨(dú)立于定義窗口時(shí)所用的緩沖，或者為了保證容錯(cuò)性而提交的代碼，也不能作為
API的一部分。否則，系統(tǒng)將受到限制，并且變得脆弱且難以使用
- 在流處理中，主要有兩個(gè)時(shí)間概念
- 事件時(shí)間，即事件實(shí)際發(fā)生的時(shí)間。更準(zhǔn)確地說，每一個(gè)事件都有一個(gè)與它相關(guān)的時(shí)間戳，并且時(shí)間戳是數(shù)據(jù)記錄的一部分（比如手機(jī)或者服務(wù)器的記錄）。事件時(shí)間其實(shí)就是時(shí)間戳
- 處理時(shí)間，即事件被處理的時(shí)間。處理時(shí)間其實(shí)就是處理事件的機(jī)器所測(cè)量的時(shí)間
圖4-4：事件時(shí)間順序與處理時(shí)間順序不一致的亂序事件流
- 窗口是一種機(jī)制，它用于將許多事件按照時(shí)間或者其他特征分組，從而將每一組作為整體進(jìn)行分析（比如求和）
- 時(shí)間窗口是最簡(jiǎn)單和最有用的一種窗口。它支持滾動(dòng)和滑動(dòng)。舉一個(gè)例子，假設(shè)要對(duì)傳感器輸出的數(shù)值求和
圖45：一分鐘滾動(dòng)窗口計(jì)算最近一分鐘的數(shù)值總和
圖46：一分鐘滑動(dòng)窗口每半分鐘計(jì)算一次最近一分鐘的數(shù)值總和
- 在
Flink中，一分鐘滾動(dòng)窗口的定義如下 -
Flink支持的另一種常見窗口叫作計(jì)數(shù)窗口。采用計(jì)數(shù)窗口時(shí)，分組依據(jù)不再是時(shí)間戳，而是元素的數(shù)量。例如，圖46中的滑動(dòng)窗口也可以解釋為由4個(gè)元素組成的計(jì)數(shù)窗口，并且每?jī)蓚€(gè)元素滑動(dòng)一次。滾動(dòng)和滑動(dòng)的計(jì)數(shù)窗口分別定義如下 - 雖然計(jì)數(shù)窗口有用，但是其定義不如時(shí)間窗口嚴(yán)謹(jǐn)，因此要謹(jǐn)慎使用
- 一種解決辦法是用時(shí)間窗口來觸發(fā)超時(shí)
-
Flink支持的另一種很有用的窗口是會(huì)話窗口
- 會(huì)話指的是活動(dòng)階段，其前后都是非活動(dòng)階段，例如用戶與網(wǎng)站進(jìn)行一系列交互（活動(dòng)階段）之后，關(guān)閉瀏覽器或者不再交互（非活動(dòng)階段）。會(huì)話需要有自己的處理機(jī)制，因?yàn)樗鼈兺ǔ]有固定的持續(xù)時(shí)間（有些30秒就結(jié)束了，有些則長(zhǎng)達(dá)一小時(shí)），或者沒有固定的交互次數(shù)（有些可能是3次點(diǎn)擊后購(gòu)買，另一些可能是40次點(diǎn)擊卻沒有購(gòu)買）
- 每一個(gè)默認(rèn)窗口都有一個(gè)觸發(fā)器。例如，采用事件時(shí)間的時(shí)間窗口將在收到水印時(shí)被觸發(fā)。對(duì)于用戶來說，除了收到水印時(shí)生成完整、準(zhǔn)確的結(jié)果之外，也可以實(shí)現(xiàn)自定義的觸發(fā)器（例如每秒提供一次近似結(jié)果）
- 在
Flink內(nèi)部，所有類型的窗口都由同一種機(jī)制實(shí)現(xiàn) - 開窗機(jī)制與檢查點(diǎn)機(jī)制（第5章將詳細(xì)討論）完全分離。這意味著窗口時(shí)長(zhǎng)不依賴于檢查點(diǎn)間隔。事實(shí)上，窗口完全可以沒有“時(shí)長(zhǎng)”（比如上文中的計(jì)數(shù)窗口和會(huì)話窗口的例子）
- 高級(jí)用戶可以直接用基本的開窗機(jī)制定義更復(fù)雜的窗口形式（如某種時(shí)間窗口，它可以基于計(jì)數(shù)結(jié)果或某一條記錄的值生成中間結(jié)果）
- 時(shí)空穿梭意味著將數(shù)據(jù)流倒回至過去的某個(gè)時(shí)間，重新啟動(dòng)處理程序，直到處理至當(dāng)前時(shí)間為止。像
Kafka和MapRStreams這樣的現(xiàn)代傳輸層，支持時(shí)空穿梭，這使得它們與更早的解決方案有所區(qū)別 -
Flink通過水印來推進(jìn)事件時(shí)間。水印是嵌在流中的常規(guī)記錄，計(jì)算程序通過水印獲知某個(gè)時(shí)間點(diǎn)已到 - 在
Flink中，水印由應(yīng)用程序開發(fā)人員生成，這通常需要對(duì)相應(yīng)的領(lǐng)域有一定的了解。完美的水印永遠(yuǎn)不會(huì)錯(cuò)：時(shí)間戳小于水印標(biāo)記時(shí)間的事件不會(huì)再出現(xiàn) - 設(shè)定水印通常需要用到領(lǐng)域知識(shí)。舉例來說，如果知道事件的遲到時(shí)間不會(huì)超過5秒，就可以將水印標(biāo)記時(shí)間設(shè)為收到的最大時(shí)間戳減去5秒。另一種做法是，采用一個(gè)
Flink作業(yè)監(jiān)控事件流，學(xué)習(xí)事件的遲到規(guī)律，并以此構(gòu)建水印生成模型 - 該架構(gòu)在不斷地適應(yīng)（學(xué)習(xí)）新系統(tǒng)常態(tài)的同時(shí)，能夠快速且準(zhǔn)確地發(fā)現(xiàn)異常。這使它成為理想工具，并能夠極大地降低因大型計(jì)算設(shè)施運(yùn)行而產(chǎn)生的維護(hù)成本
圖48展示了愛立信團(tuán)隊(duì)構(gòu)建的數(shù)據(jù)管道
- 推送給
Kafka的原始數(shù)據(jù)是來自云基礎(chǔ)設(shè)施中的所有實(shí)體機(jī)和虛擬機(jī)的遙測(cè)信息和日志事件。它們經(jīng)過不同的Flink作業(yè)消費(fèi)之后，被寫回Kafka主題里，然后再?gòu)?code>Kafka主題里被推送給搜索引擎Elasticsearch和可視化系統(tǒng)Kibana。這種架構(gòu)讓每個(gè)Flink作業(yè)所執(zhí)行的任務(wù)有清晰的定義，一個(gè)作業(yè)的輸出可以成為另一個(gè)作業(yè)的輸入
第 5 章 有狀態(tài)的計(jì)算
- 流式計(jì)算分為無狀態(tài)和有狀態(tài)兩種情況。無狀態(tài)的計(jì)算觀察每個(gè)獨(dú)立事件，并根據(jù)最后一個(gè)事件輸出結(jié)果
- 有狀態(tài)的計(jì)算則會(huì)基于多個(gè)事件輸出結(jié)果
- 第4章討論的所有類型的窗口。例如，計(jì)算過去一小時(shí)的平均溫度，就是有狀態(tài)的計(jì)算
- 所有用于復(fù)雜事件處理的狀態(tài)機(jī)。例如，若在一分鐘內(nèi)收到兩個(gè)相差20度以上的溫度讀數(shù)，則發(fā)出警告，這是有狀態(tài)的計(jì)算
- 流與流之間的所有關(guān)聯(lián)操作，以及流與靜態(tài)表或動(dòng)態(tài)表之間的關(guān)聯(lián)操作，都是有狀態(tài)的計(jì)算
- 無狀態(tài)流處理分別接收每條記錄（圖中的黑條），然后根據(jù)最新輸入的記錄生成輸出記錄（白條）
- 有狀態(tài)流處理會(huì)維護(hù)狀態(tài)（根據(jù)每條輸入記錄進(jìn)行更新），并基于最新輸入的記錄和當(dāng)前的狀態(tài)值生成輸出記錄（灰條）
圖5-1：無狀態(tài)流處理與有狀態(tài)流處理的區(qū)別。輸入記錄由黑條表示。無狀態(tài)流處理每次只轉(zhuǎn)換一條輸入記錄，并且僅根據(jù)最新的輸入記錄輸出結(jié)果（白條）。有狀態(tài)流處理維護(hù)所有已處理記錄的狀態(tài)值，并根據(jù)每條新輸入的記錄更新狀態(tài)，因此輸出記錄（灰條）反映的是綜合考慮多個(gè)事件之后的結(jié)果
- 在流處理中，一致性分為3個(gè)級(jí)別
-
atmostonce：這其實(shí)是沒有正確性保障的委婉說法——故障發(fā)生之后，計(jì)數(shù)結(jié)果可能丟失 -
atleastonce：這表示計(jì)數(shù)結(jié)果可能大于正確值，但絕不會(huì)小于正確值。也就是說，計(jì)數(shù)程序在發(fā)生故障后可能多算，但是絕不會(huì)少算 -
exactlyonce：這指的是系統(tǒng)保證在發(fā)生故障后得到的計(jì)數(shù)結(jié)果與正確值一致
-
Flink的一個(gè)重大價(jià)值在于，它既保證了exactlyonce，也具有低延遲和高吞吐的處理能力
圖5-2：數(shù)環(huán)狀項(xiàng)鏈上的珠子看上去毫無意義（甚至有些徒勞無功，因?yàn)榭梢杂啦煌Ｐ赜?jì)數(shù)），但是它可以用來很好地類比處理永不結(jié)束的事件流。在某些文化中，人們?nèi)耘f將數(shù)珠子視作消磨時(shí)間的好方法
- 在項(xiàng)鏈上每隔一段就松松地系上一根有色皮筋，將珠子分隔開；當(dāng)珠子被撥動(dòng)的時(shí)候，皮筋也可以被撥動(dòng)；然后，你安排一個(gè)助手，讓他在你和朋友撥到皮筋時(shí)記錄總數(shù)。用這種方法，當(dāng)有人數(shù)錯(cuò)時(shí)，就不必從頭開始數(shù)。相反，你向其他人發(fā)出錯(cuò)誤警示，然后你們都從上一根皮筋處開始重?cái)?shù)，助手則會(huì)告訴每個(gè)人重?cái)?shù)時(shí)的起始數(shù)值，例如在粉色皮筋處的數(shù)值是多少
- 按照輸入記錄的第一個(gè)字段（一個(gè)字符串）進(jìn)行分組并維護(hù)第二個(gè)字段的計(jì)數(shù)狀態(tài)
- 該程序有兩個(gè)算子：
keyBy算子用來將記錄按照第一個(gè)元素（一個(gè)字符串）進(jìn)行分組，根據(jù)該key將數(shù)據(jù)進(jìn)行重新分區(qū)，然后將記錄再發(fā)送給下一個(gè)算子：有狀態(tài)的map算子（mapWithState）。map算子在接收到每個(gè)元素后，將輸入記錄的第二個(gè)字段的數(shù)據(jù)加到現(xiàn)有總數(shù)中，再將更新過的元素發(fā)射出去
圖5-3：程序的初始狀態(tài)。注意，
a、b、c三組的初始計(jì)數(shù)狀態(tài)都是0，即三個(gè)圓柱上的值。ckpt表示檢查點(diǎn)屏障。每條記錄在處理順序上嚴(yán)格地遵守在檢查點(diǎn)之前或之后的規(guī)定，例如["b",2]在檢查點(diǎn)之前被處理，["a",2]則在檢查點(diǎn)之后被處理
圖5-4：當(dāng)
Flink數(shù)據(jù)源（在本例中與keyBy算子內(nèi)聯(lián)）遇到檢查點(diǎn)屏障時(shí)，它會(huì)將其在輸入流中的位置保存到穩(wěn)定存儲(chǔ)中。這讓Flink可以根據(jù)該位置重啟輸入
圖5-6：檢查點(diǎn)操作完成，狀態(tài)和位置均已備份到穩(wěn)定存儲(chǔ)中。輸入流中的所有記錄都已處理完成。值得注意的是，備份的狀態(tài)值與實(shí)際的狀態(tài)值是不同的。備份反映的是檢查點(diǎn)的狀態(tài)
-
Flink檢查點(diǎn)算法的正式名稱是異步屏障快照（asynchronousbarriersnapshotting）。該算法大致基于ChandyLamport分布式快照算法 - 檢查點(diǎn)由
Flink自動(dòng)生成，用來在故障發(fā)生時(shí)重新處理記錄，從而修正狀態(tài)。Flink用戶還可以通過另一個(gè)特性有意識(shí)地管理狀態(tài)版本，這個(gè)特性叫作保存點(diǎn)（savepoint） - 保存點(diǎn)與檢查點(diǎn)的工作方式完全相同，只不過它由用戶通過
Flink命令行工具或者Web控制臺(tái)手動(dòng)觸發(fā)，而不由Flink自動(dòng)觸發(fā)。和檢查點(diǎn)一樣，保存點(diǎn)也被保存在穩(wěn)定存儲(chǔ)中 - 對(duì)保存點(diǎn)的另一種理解是，它在明確的時(shí)間點(diǎn)保存應(yīng)用程序狀態(tài)的版本
圖5-9：手動(dòng)觸發(fā)的保存點(diǎn)（以圓圈表示）在不同時(shí)間捕獲正在運(yùn)行的
Flink應(yīng)用程序的狀態(tài)
圖5-10：使用保存點(diǎn)更新
Flink應(yīng)用程序的版本。新版本可以從舊版本生成的一個(gè)保存點(diǎn)處開始執(zhí)行
- 保存點(diǎn)可用于應(yīng)對(duì)流處理作業(yè)在生產(chǎn)環(huán)境中遇到的許多挑戰(zhàn)
- 應(yīng)用程序代碼升級(jí)
-
Flink版本更新 - 維護(hù)和遷移
- 假設(shè)模擬與恢復(fù)
-
A/B測(cè)試
圖5-11：在該應(yīng)用程序架構(gòu)中，有狀態(tài)的 Flink 應(yīng)用程序消費(fèi)來自消息隊(duì)列的數(shù)據(jù)，然后將數(shù)據(jù)寫入輸出系統(tǒng)，以供查詢 。底部的詳情圖展示 了 Flink 應(yīng)用程序的內(nèi)部情況
圖5-14：Yahoo!Streaming Benchmark 結(jié)果。橫軸表示每秒的事件吞吐量，以千為單位。縱軸表示端到端的99百分位數(shù)延遲，以秒為單位。
在性能測(cè)評(píng)中，Spark Streaming 遇到了吞吐量和延遲性難兩全的問題。隨著批處理作業(yè)規(guī)模的增加，延遲升高。如果為了降低延遲而縮減規(guī)模，吞吐量就會(huì)減少。Storm 和 Flink 則可以在吞吐量增加時(shí)維持低延遲
圖5-16：使用高吞吐數(shù)據(jù)生成器的結(jié)果
- 當(dāng)Storm 和 Kafka 一起使用時(shí)，應(yīng)用程序可以保持每秒40萬事件的處理速度，并且瓶頸在于 CPU
- 當(dāng) Flink 和 Kafka 一起使用時(shí)，應(yīng)用程序可以保持每秒300萬事件的處理速度，并且瓶頸在于網(wǎng)絡(luò)
- 當(dāng)消除網(wǎng)絡(luò)瓶頸時(shí)，F(xiàn)link 應(yīng)用程序可以保持每秒1500萬事件的處理速度
- 在額外的測(cè)試中，消除隊(duì)列由 MapR Streams提供，并且采用10個(gè)高性能網(wǎng)絡(luò)節(jié)點(diǎn)；Flink 應(yīng)用程序可以保持每秒1000萬事件的處理速度
- 通過避免流處理瓶頸，同時(shí)利用 Flink 的有狀態(tài)流處理能力，可以使吞吐量達(dá)到 Storm 的30倍左右 ，同時(shí)還能保證
exactly-once和高可用性
第 6 章 批處理：一種特殊的流處理
- 如果計(jì)算結(jié)果不在執(zhí)行過程中連續(xù)生成，而僅在末尾處生成一次，那就是批處理（分批處理數(shù)據(jù)）
- 批處理是流處理的一種非常特殊的情況。在流處理是，我們?yōu)閿?shù)據(jù)定義滑動(dòng)窗口或滾動(dòng)窗口，并且在每次窗口滑動(dòng)或滾動(dòng)時(shí)生成結(jié)果 。批處理則不同，我們定義一個(gè)全局窗口，所有的記錄都屬于同一個(gè)窗口
圖64：分布式排序的處理階段
進(jìn)一步使用 Flink
- Https://flink.apache.org有『快速入門』指南，通過例子教你如何使用 Flink 攝取和分析維基百科的編輯日志。只需花幾分鐘，你就可以開始編寫你的第一個(gè)流處理程序了。
- 如果你偏愛視覺效果，可以看看 MapR 公司提供的例子：如何用 Flink 攝取紐約市出租車路線的數(shù)據(jù)流，并用 Kibana 將它可視化（https://www.mapr.com/blog/essential-guide-streaming-first-processing-apache-flink）
