最近的實時流處理已經獲得了發展勢頭，啟用它的主要工具是Apache Spark和Apache Fink。透過資料處理、資料流、資料管理和使用這些工具的案例研究來學習。

對更快的資料處理的需求不斷增加，實時流資料處理似乎是答案。雖然Apache Spice仍在很多組織中用於大資料處理，但Apache FLink已經成為一種替代方案。事實上，許多人認為它有可能取代Apache SCAP，因為它能夠實時處理流資料。當然，關於弗林克能否取代火花的陪審團仍在進行中，因為弗林克尚未被廣泛接受。但是實時處理和低資料延遲是其定義特徵的兩個方面。同時，這需要考慮Apache SCAP可能不會因為它的批處理能力將仍然相關而不受歡迎。

流資料處理例項

對於基於批處理的所有優點，實時流資料處理似乎有一個強有力的例子。流資料處理使得資料倉庫的建立和載入成為可能。具有低資料延遲的流處理器提供了對資料的更快的洞察力。所以，你有更多的時間去了解正在發生的事情。除了更快的處理，還有一個顯著的好處：你有更多的時間來設計一個適當的事件響應。例如，在異常檢測的情況下，較低的延遲和更快的檢測使您能夠識別最佳的響應，這是防止在諸如安全網站或工業裝置損壞的欺騙性攻擊的情況下防止損壞的關鍵。所以，你可以防止實質性的損失。

什麼是Apache Fink？

APACHE FLink是一種大規模的資料處理工具，它以大資料量的低資料延遲和高容錯性快速處理大資料。它的定義特徵是它能夠實時處理流資料。

Apache Fink開始作為一個學術開源專案，在那時，它被稱為平流層。後來，它成為Apache軟體基金會孵化器的一部分。為了避免與另一個專案的名稱衝突，將名稱更改為弗林克。弗林克的名字是恰當的，因為它意味著敏捷。即使是選擇的標誌，松鼠也是合適的，因為松鼠代表敏捷、靈活和速度的優點。

因為它被新增到Apache軟體基金會，它作為一個大的資料處理工具迅速崛起，在八個月內，它開始吸引更多的觀眾的注意力。人們對Flink的興趣越來越多，反映在2015年一些與會者的人數上。許多人參加了弗林克在2015年5月在倫敦召開的地層會議和2015年6月在聖若澤的Hadoop峰會上的會議。超過60人參加了海灣地區Apache Fink會議在2015年8月在聖若澤的MAPR總部舉辦。

下面的影象給出了FLink的lambda架構。

spark與flink之間的比較

雖然spark和flink之間有一些相似之處，例如API和元件，但在資料處理方面，它們的相似性並不重要。下面給出的是flink和spark的比較。

資料處理

flink在批處理模式下處理資料，而Fink實時處理流資料。火花處理資料塊，稱為RDDS，而FLink可以實時處理行資料之後的行。因此，雖然最小的資料延遲總是在spark上存在，但spark卻不是這樣。

迭代

spark支援批處理中的資料迭代，但弗林克可以透過使用流式架構來對其資料進行迭代迭代。下面的影象顯示了迭代處理是如何發生的。

記憶體管理

FLink可以自動適應不同的資料集，但spark需要手動最佳化和調整其作業到單個數據集。spark也進行手動分割槽和快取。因此，期待一些延遲處理。

資料流

FLink在需要時能夠在資料處理上提供中間結果。spark遵循過程程式設計系統，FLink遵循分散式資料流方法。因此，每當需要中間結果時，廣播變數被用來將預先計算的結果分發給所有的工作者節點。

資料視覺化

弗林克提供了一個提交和執行所有作業的Web介面。星火和弗林克都與Apache齊柏林飛船整合，並提供資料攝取、資料分析、發現、協作和視覺化。Apache Zeppin還提供了一個多語言後端，允許您提交和執行FLink程式。

加工時間

下面的段落提供了flink和spark在不同工作中所花費的時間的比較。

為了進行公平的比較，flink和spark都以機器規格和節點配置的形式提供了相同的資源。

如上面的影象所示，以紅色突出顯示的區域指示FLink和spark處理器的節點配置。

FLink由於流水線執行而處理得更快。為了處理資料，火花花了2171秒，而FLink花費了1490秒。

當具有不同資料大小的TeraSort被執行時，結果如下：

對於10GB的資料，flink花了157秒的時間與Skp887秒相比。

對於160GB的資料，flink花了3127秒與火花的427秒相比。

基於批處理或流資料-哪個過程更好？

流批處理

資料或輸入以特定的順序以記錄的形式到達。資料或輸入根據記錄的數量或時間分為批。

儘可能快地要求輸出，但不能比驗證序列所需的時間更早。輸入是根據要求給出的，但保留一定數量的批。

輸出在寫入後不需要修改，記錄新的狀態和輸出的所有行的細節。

也可以做批處理的資料無法做批次處理的資料

個別情況下，flink和批處理都是有用的。以每天滾動月度銷售計算為例。在這個活動中，需要的是計算每天的銷售總額，然後累積起來。在這樣的用例中，可能不需要流式資料處理。資料的批次處理可以根據日期來處理單個批次的銷售數字，然後新增它們。在這種情況下，即使存在一些資料延遲，當以後的潛在資料被新增到以後的批次中時，它總是可以稍後進行。

也有類似的用例需要流式處理。以計算每個訪問者在網站上的滾動月度時間為例。在網站的情況下，訪問次數可以更新，每小時，每分鐘，甚至每天。但這種情況下的問題是定義會話。定義會話的開始和結束可能是困難的。此外，很難計算或識別不活動的時期。因此，在這種情況下，沒有合理的界限來定義會話甚至是不活動的週期。在這樣的情況下，需要實時地進行流資料處理。

總結

雖然spark在批次資料處理方面有很多優勢，但它仍有許多用例可以迎合，看來弗林克正在迅速獲得商業牽引力。事實上，FLink也可以進行批次處理，這對其有利。當然，這需要考慮到FLink的批處理能力可能與spark不一樣。所以，火花仍然有一段時間。

flink和spark都是apache 軟體基金會（ASF）旗下頂級專案，都是通用資料處理平臺。它們可以應用在很多的大資料應用和處理環境。兩者均可在不依賴於其他環境的情況下運行於standalone模式，或是執行在基於hadoop（YARN,HDFS)之上，由於它們均是運行於記憶體，所以他們表現的都比hadoop要好很多。

二者的不同：

Flink在進行集合的迭代轉換時可以是迴圈或是迭代計算處理。flink的流式處理的是真正的流處理。流式資料一但進入就實時進行處理，這就允許流資料靈活地在操作視窗。

Spark 在另一方面是基於彈性分散式資料集（RDD），這（主要的）給於spark基於記憶體內資料結構的函數語言程式設計。它可以透過固定的記憶體給於大批次的計算。

Apache 兩個開源專案比較：Flink vs Spark

https://www.toutiao.com/i6726687424803504653/