說到Flink不得不先說一下大數(shù)據(jù)。
這幾年大數(shù)據(jù)的飛速發(fā)展，出現(xiàn)了很多熱門的開源社區(qū)，其中著名的有 Hadoop、Storm，以及后來的 Spark，他們都有著各自專注的應(yīng)用場景。Spark 掀開了內(nèi)存計(jì)算的先河，也以內(nèi)存為賭注，贏得了內(nèi)存計(jì)算的飛速發(fā)展。Spark 的火熱或多或少的掩蓋了其他分布式計(jì)算的系統(tǒng)身影。就像 Flink，也就在這個時候默默的發(fā)展著。
在國外一些社區(qū)，有很多人將大數(shù)據(jù)的計(jì)算引擎分成了 4 代，當(dāng)然，也有很多人不會認(rèn)同。我們先姑且這么認(rèn)為和討論。
首先第一代的計(jì)算引擎，無疑就是 Hadoop 承載的 MapReduce。這里大家應(yīng)該都不會對 MapReduce 陌生，它將計(jì)算分為兩個階段，分別為 Map 和 Reduce。對于上層應(yīng)用來說，就不得不想方設(shè)法去拆分算法，甚至于不得不在上層應(yīng)用實(shí)現(xiàn)多個 Job 的串聯(lián)，以完成一個完整的算法，例如迭代計(jì)算。
由于這樣的弊端，催生了支持 DAG 框架的產(chǎn)生。
因此，支持 DAG 的框架被劃分為第二代計(jì)算引擎。如 Tez 以及更上層的 Oozie。這里我們不去細(xì)究各種 DAG 實(shí)現(xiàn)之間的區(qū)別，不過對于當(dāng)時的 Tez 和 Oozie 來說，大多還是批處理的任務(wù)。
接下來就是以 Spark 為代表的第三代的計(jì)算引擎。第三代計(jì)算引擎的特點(diǎn)主要是 Job 內(nèi)部的 DAG 支持（不跨越 Job），以及實(shí)時計(jì)算。
隨著第三代計(jì)算引擎的出現(xiàn)，促進(jìn)了上層應(yīng)用快速發(fā)展，例如各種迭代計(jì)算的性能以及對流計(jì)算和 SQL 等的支持。Flink 的誕生就被歸在了第四代。這應(yīng)該主要表現(xiàn)在 Flink 對流計(jì)算的支持，以及更一步的實(shí)時性上面。當(dāng)然 Flink 也可以支持 Batch 的任務(wù)，以及 DAG 的運(yùn)算。
或許會有人不同意以上的分類，我覺得其實(shí)這并不重要的，重要的是體會各個框架的差異，以及更適合的場景。并進(jìn)行理解，沒有哪一個框架可以完美的支持所有的場景，也就不可能有任何一個框架能完全取代另一個，就像 Spark 沒有完全取代 Hadoop，當(dāng)然 Flink 也不可能取代 Spark。
如今最火的就是Spark和Flink。Spark和Flink的主要差別就在于計(jì)算模型不同。Spark采用了微批處理模型，而Flink采用了基于操作符的連續(xù)流模型。因此，對Apache Spark和Apache Flink的選擇實(shí)際上變成了計(jì)算模型的選擇，而這種選擇需要在延遲、吞吐量和可靠性等多個方面進(jìn)行權(quán)衡。
Spark
對于以下場景：
復(fù)雜的批量處理（Batch Data Processing），偏重點(diǎn)在于處理海量數(shù)據(jù)的能力，至于處理速度可忍受，通常的時間可能是在數(shù)十分鐘到數(shù)小時。
基于歷史數(shù)據(jù)的交互式查詢（Interactive Query），通常的時間在數(shù)十秒到數(shù)十分鐘之間。
基于實(shí)時數(shù)據(jù)流的數(shù)據(jù)處理（Streaming Data Processing），通常在數(shù)百毫秒到數(shù)秒之間。
目前都有比較成熟的處理框架，第一種情況可以用Hadoop的MapReduce來進(jìn)行批量海量數(shù)據(jù)處理，第二種情況可以Impala進(jìn)行交互式查詢，對于第三中情況可以用Storm分布式處理框架處理實(shí)時流式數(shù)據(jù)。以上三者都是比較獨(dú)立，各自一套維護(hù)成本比較高，而Spark的出現(xiàn)能夠一站式平臺滿意以上需求。
Spark適用和不適用的場景：
- Spark是基于內(nèi)存的迭代計(jì)算框架，適用于需要多次操作特定數(shù)據(jù)集的應(yīng)用場合。需要反復(fù)操作的次數(shù)越多，所需讀取的數(shù)據(jù)量越大，受益越大，數(shù)據(jù)量小但是計(jì)算密集度較大的場合，受益就相對較小。
- 內(nèi)存hold不住的場景，在內(nèi)存不足的情況下，Spark會下放到磁盤，會降低應(yīng)有的性能
- 數(shù)據(jù)量不是特別大，但是要求近實(shí)時統(tǒng)計(jì)分析需求，如果有高實(shí)時性要求的流式計(jì)算業(yè)務(wù)，就不太適合了，例如實(shí)時性要求毫秒級
- 由于RDD設(shè)計(jì)上的只讀特點(diǎn)，所以Spark對于待分析數(shù)據(jù)頻繁變動的情景很難做（并不是不可以），比如題主例子里的搜索，假設(shè)你的數(shù)據(jù)集在頻繁變化（不停增刪改），而且又需要結(jié)果具有很強(qiáng)的一致性（不一致時間窗口很?。敲淳筒缓线m了。還有像web服務(wù)的存儲或者是增量的web爬蟲和索引，就是對于那種增量修改的應(yīng)用模型不適合。
- 流線長或文件流量非常大的數(shù)據(jù)集不適合。你會發(fā)現(xiàn)你的內(nèi)存不夠用，集群壓力大時一旦一個task失敗會導(dǎo)致他前面一條線所有的前置任務(wù)全部重跑，然后惡性循環(huán)會導(dǎo)致更多的task失敗，整個sparkapp效率極低。就不如MapReduce啦！
Flink
Flink就是為流式計(jì)算而生的，就連Batch最終也是轉(zhuǎn)化成了streaming，也就是說Flink的一切都是stream。
Flink有一下優(yōu)點(diǎn)：
- Flink的流處理引擎只需要很少配置就能實(shí)現(xiàn)高吞吐率和低延遲。
- Flink 的 checkpointing 機(jī)制保證了即時在故障發(fā)生下也能保障狀態(tài)的 exactly once 語義。
- Flink 支持在時間窗口，統(tǒng)計(jì)窗口，session 窗口，以及數(shù)據(jù)驅(qū)動的窗口，窗口可以通過靈活的觸發(fā)條件來定制，以支持復(fù)雜的流計(jì)算模式。
- Flink streaming 在運(yùn)行時有著天然的流控，自帶反壓功能——慢的數(shù)據(jù) sink 節(jié)點(diǎn)會反壓（backpressure）快的數(shù)據(jù)源（sources）。
- Flink 的容錯機(jī)制是基于 Chandy-Lamport distributed snapshots 來實(shí)現(xiàn)的。這種機(jī)制是非常輕量級的，允許系統(tǒng)擁有高吞吐率的同時還能提供強(qiáng)一致性的保障。
- Flink 在 JVM 中實(shí)現(xiàn)了自己的內(nèi)存管理。應(yīng)用可以超出主內(nèi)存的大小限制，并且承受更少的垃圾收集的開銷。
- Flink 具有迭代計(jì)算的專門支持（比如在機(jī)器學(xué)習(xí)和圖計(jì)算中）。增量迭代可以利用依賴計(jì)算來更快地收斂。
- Flink 批處理程序會自動地優(yōu)化一些場景，比如避免一些昂貴的操作（如 shuffles 和 sorts），還有緩存一些中間數(shù)據(jù)。
- DataStream API 支持了數(shù)據(jù)流上的函數(shù)式轉(zhuǎn)換，可以使用自定義的狀態(tài)和靈活的窗口。
- Flink 棧中提供了很多高級 API 和滿足不同場景的類庫：機(jī)器學(xué)習(xí)、圖分析、關(guān)系式數(shù)據(jù)處理。當(dāng)前類庫還在 beta 狀態(tài)，并且在大力發(fā)展。
- Flink 與開源大數(shù)據(jù)處理生態(tài)系統(tǒng)中的許多項(xiàng)目都有集成。Flink 可以運(yùn)行在 YARN 上，與 HDFS 協(xié)同工作，從 Kafka 中讀取流數(shù)據(jù)，可以執(zhí)行 Hadoop 程序代碼，可以連接多種數(shù)據(jù)存儲系統(tǒng)。
