怎么實現(xiàn)大數(shù)據(jù)處理引擎Spark與Flink比拼-創(chuàng)新互聯(lián)

今天就跟大家聊聊有關怎么實現(xiàn)大數(shù)據(jù)處理引擎Spark與Flink比拼，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

十多年的龍港網(wǎng)站建設經(jīng)驗，針對設計、前端、開發(fā)、售后、文案、推廣等六對一服務，響應快，48小時及時工作處理。成都全網(wǎng)營銷推廣的優(yōu)勢是能夠根據(jù)用戶設備顯示端的尺寸不同，自動調(diào)整龍港建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設計，從而大程度地提升瀏覽體驗。成都創(chuàng)新互聯(lián)公司從事“龍港網(wǎng)站設計”,“龍港網(wǎng)站推廣”以來，每個客戶項目都認真落實執(zhí)行。

下一代大數(shù)據(jù)計算引擎

　　自從數(shù)據(jù)處理需求超過了傳統(tǒng)數(shù)據(jù)庫能有效處理的數(shù)據(jù)量之后，Hadoop 等各種基于 MapReduce 的海量數(shù)據(jù)處理系統(tǒng)應運而生。從 2004 年 Google 發(fā)表 MapReduce 論文開始，經(jīng)過近 10 年的發(fā)展，基于 Hadoop 開源生態(tài)或者其它相應系統(tǒng)的海量數(shù)據(jù)處理已經(jīng)成為業(yè)界的基本需求。

　　但是，很多機構(gòu)在開發(fā)自己的數(shù)據(jù)處理系統(tǒng)時都會發(fā)現(xiàn)需要面臨一系列的問題。從數(shù)據(jù)中獲取價值需要的投入遠遠超過預期。常見的問題包括：

　　非常陡峭的學習曲線。剛接觸這個領域的人經(jīng)常會被需要學習的技術的數(shù)量砸暈。不像經(jīng)過幾十年發(fā)展的數(shù)據(jù)庫一個系統(tǒng)可以解決大部分數(shù)據(jù)處理需求，Hadoop 等大數(shù)據(jù)生態(tài)里的一個系統(tǒng)往往在一些數(shù)據(jù)處理場景上比較擅長，另一些場景湊合能用，還有一些場景完全無法滿足需求。結(jié)果就是需要好幾個系統(tǒng)來處理不同的場景。

　　

　　上圖是一個典型的 lambda 架構(gòu)，只是包含了批處理和流處理兩種場景，就已經(jīng)牽涉到至少四五種技術了，還不算每種技術的可替代選擇。再加上實時查詢、交互式分析、機器學習等場景，每個場景都有幾種技術可以選擇，每個技術涵蓋的領域還有不同方式的重疊。結(jié)果就是一個業(yè)務經(jīng)常需要使用四五種以上的技術才能支持好一個完整的數(shù)據(jù)處理流程。加上調(diào)研選型，需要了解的數(shù)目還要多得多。

　　下圖是大數(shù)據(jù)領域的全景。暈了沒?

　　

　　2018 大數(shù)據(jù)和 AI 全景(來源：http://mattturck.com/bigdata2018/)

　　開發(fā)和運行效率低下。因為牽涉到多種系統(tǒng)，每種系統(tǒng)有自己的開發(fā)語言和工具，開發(fā)效率可想而知。而因為采用了多套系統(tǒng)，數(shù)據(jù)需要在各個系統(tǒng)之間傳輸，也造成了額外的開發(fā)和運行代價，數(shù)據(jù)的一致也難以保證。在很多機構(gòu)，實際上一半以上的開發(fā)精力花在了數(shù)據(jù)在各個系統(tǒng)之間的傳輸上。

　　復雜的運維。多個系統(tǒng)，每個需要自己的運維，帶來更高的運維代價的同時也提高了系統(tǒng)出問題的可能。

　　數(shù)據(jù)質(zhì)量難以保證。數(shù)據(jù)出了問題難以跟蹤解決。

　　最后，還有人的問題。在很多機構(gòu)，由于系統(tǒng)的復雜性，各個子系統(tǒng)的支持和使用落實在不同部門負責。

　　了解了這些問題以后，對 Spark 從 2014 年左右開始迅速流行就比較容易理解了。Spark 在當時除了在某些場景比 Hadoop MapReduce 帶來幾十到上百倍的性能提升外，還提出了用一個統(tǒng)一的引擎支持批處理、流處理、交互式查詢、機器學習等常見的數(shù)據(jù)處理場景?？催^在一個 Notebook 里完成上述所有場景的 Spark 演示，對比之前的數(shù)據(jù)流程開發(fā)，對很多開發(fā)者來說不難做出選擇。經(jīng)過幾年的發(fā)展，Spark 已經(jīng)被視為可以完全取代 Hadoop 中的 MapReduce 引擎。

　　正在 Spark 如日中天高速發(fā)展的時候，2016 年左右 Flink 開始進入大眾的視野并逐漸廣為人知。為什么呢?原來在人們開始使用 Spark 之后，發(fā)現(xiàn) Spark 雖然支持各種常見場景，但并不是每一種都同樣好用。數(shù)據(jù)流的實時處理就是其中相對較弱的一環(huán)。Flink 憑借更優(yōu)的流處理引擎，同時也支持各種處理場景，成為 Spark 的有力挑戰(zhàn)者。

　　Spark 和 Flink 是怎么做到這些的，它們之間又有那些異同，下面我們來具體看一下。

　　Spark 和 Flink 的引擎技術

　　這一部分主要著眼于 Spark 和 Flink 引擎的架構(gòu)方面，更看重架構(gòu)帶來的潛力和限制?，F(xiàn)階段的實現(xiàn)成熟度和局限會在后續(xù)生態(tài)部分探討。

　　數(shù)據(jù)模型和處理模型

　　要理解 Spark 和 Flink 的引擎特點，首先從數(shù)據(jù)模型開始。

　　Spark 的數(shù)據(jù)模型是彈性分布式數(shù)據(jù)集 RDD(Resilient Distributed Datasets)。 比起 MapReduce 的文件模型，RDD 是一個更抽象的模型，RDD 靠血緣(lineage) 等方式來保證可恢復性。很多時候 RDD 可以實現(xiàn)為分布式共享內(nèi)存或者完全虛擬化(即有的中間結(jié)果 RDD 當下游處理完全在本地時可以直接優(yōu)化省略掉)。這樣可以省掉很多不必要的 I/O，是早期 Spark 性能優(yōu)勢的主要原因。

　　Spark 用 RDD 上的變換(算子)來描述數(shù)據(jù)處理。每個算子(如 map，filter，join)生成一個新的 RDD。所有的算子組成一個有向無環(huán)圖(DAG)。Spark 比較簡單地把邊分為寬依賴和窄依賴。上下游數(shù)據(jù)不需要 shuffle 的即為窄依賴，可以把上下游的算子放在一個階段(stage) 里在本地連續(xù)處理，這時上游的結(jié)果 RDD 可以 省略。下圖展示了相關的基本概念。更詳細的介紹在網(wǎng)上比較容易找到，這里就不花太多篇幅了。

　　

　　Spark DAG(來源：http://datastrophic.io/core-concepts-architecture-and-internals-of-apache-spark/)

　　Flink 的基本數(shù)據(jù)模型是數(shù)據(jù)流，及事件(Event)的序列。數(shù)據(jù)流作為數(shù)據(jù)的基本模型可能沒有表或者數(shù)據(jù)塊直觀熟悉，但是可以證明是完全等效的。流可以是無邊界的無限流，即一般意義上的流處理。也可以是有邊界的有限流，這樣就是批處理。

　　Flink 用數(shù)據(jù)流上的變換(算子)來描述數(shù)據(jù)處理。每個算子生成一個新的數(shù)據(jù)流。在算子，DAG，和上下游算子鏈接(chaining) 這些方面，和 Spark 大致等價。Flink 的節(jié)點(vertex)大致相當于 Spark 的階段(stage)，劃分也會和上圖的 Spark DAG 基本一樣。

　　

　　Flink 任務圖(來源：https://ci.apache.org/projects/flink/flink-docs-release-1.5/concepts/runtime.html)

　　在 DAG 的執(zhí)行上，Spark 和 Flink 有一個比較顯著的區(qū)別。在 Flink 的流執(zhí)行模式中，一個事件在一個節(jié)點處理完后的輸出就可以發(fā)到下一個節(jié)點立即處理。這樣執(zhí)行引擎并不會引入額外的延遲。與之相應的，所有節(jié)點是需要同時運行的。而 Spark 的 micro batch 和一般的 batch 執(zhí)行一樣，處理完上游的 stage 得到輸出之后才開始下游的 stage。

　　在 Flink 的流執(zhí)行模式中，為了提高效率也可以把多個事件放在一起傳輸或者計算。但這完全是執(zhí)行時的優(yōu)化，可以在每個算子獨立決定，也不用像 RDD 等批處理模型中一樣和數(shù)據(jù)集邊界綁定，可以做更加靈活的優(yōu)化同時可以兼顧低延遲需求。

　　Flink 使用異步的 checkpoint 機制來達到任務狀態(tài)的可恢復性，以保證處理的一致性，所以在處理的主流程上可以做到數(shù)據(jù)源和輸出之間數(shù)據(jù)完全不用落盤，達到更高的性能和更低的延遲。

　　數(shù)據(jù)處理場景

　　除了批處理之外，Spark 還支持實時數(shù)據(jù)流處理、交互式查詢和機器學習、圖計算等。

　　

　　(來源： https://databricks.com/spark/about)

　　實時數(shù)據(jù)流處理和批處理主要區(qū)別就是對低延時的要求。Spark 因為 RDD 是基于內(nèi)存的，可以比較容易切成較小的塊來處理。如果能對這些小塊處理得足夠快，就能達到低延時的效果。

　　交互式查詢場景，如果數(shù)據(jù)能全在內(nèi)存，處理得足夠快的話，就可以支持交互式查詢。

　　機器學習和圖計算其實是和前幾種場景不同的 RDD 算子類型。Spark 提供了庫來支持常用的操作，用戶或者第三方庫也可以自己擴展。值得一提的是，Spark 的 RDD 模型和機器學習模型訓練的迭代計算非常契合，從一開始就在有的場景帶來了非常顯著的性能提升。

　　從這些可以看出來，比起 Hadoop MapReduce， Spark 本質(zhì)上就是基于內(nèi)存的更快的批處理。然后用足夠快的批處理來實現(xiàn)各種場景。

　　

　　(來源：https://www.slideshare.net/ParisCarbone/state-management-in-apache-flink-consistent-stateful-distributed-stream-processing)

　　前面說過，在 Flink 中，如果輸入數(shù)據(jù)流是有邊界的，就自然達到了批處理的效果。這樣流和批的區(qū)別完全是邏輯上的，和處理實現(xiàn)獨立，用戶需要實現(xiàn)的邏輯也完全一樣，應該是更干凈的一種抽象。后續(xù)會在深入對比流計算方面的時候做更深入的討論。

　　Flink 也提供了庫來支持機器學習、圖計算等場景。從這方面來說和 Spark 沒有太大區(qū)別。

　　一個有意思的事情是用 Flink 的底層 API 可以支持只用 Flink 集群實現(xiàn)一些數(shù)據(jù)驅(qū)動的分布式服務。有一些公司用 Flink 集群實現(xiàn)了社交網(wǎng)絡，網(wǎng)絡爬蟲等服務。這個也體現(xiàn)了 Flink 作為計算引擎的通用性，并得益于 Flink 內(nèi)置的靈活的狀態(tài)支持。

　　總的來說，Spark 和 Flink 都瞄準了在一個執(zhí)行引擎上同時支持大多數(shù)數(shù)據(jù)處理場景，也應該都能做到這一點。主要區(qū)別就在于因為架構(gòu)本身的局限在一些場景會受到限制。比較突出的地方就是 Spark Streaming 的 micro batch 執(zhí)行模式。Spark 社區(qū)應該也意識到了這一點，最近在持續(xù)執(zhí)行模式(continuous processing)方面開始發(fā)力。 具體情況會在后面介紹。

　　有狀態(tài)處理 (Stateful Processing)

　　Flink 還有一個非常獨特的地方是在引擎中引入了托管狀態(tài)(managed state)。要理解托管狀態(tài)，首先要從有狀態(tài)處理說起。如果處理一個事件(或一條數(shù)據(jù))的結(jié)果只跟事件本身的內(nèi)容有關，稱為無狀態(tài)處理;反之結(jié)果還和之前處理過的事件有關，稱為有狀態(tài)處理。稍微復雜一點的數(shù)據(jù)處理，比如說基本的聚合，都是有狀態(tài)處理。Flink 很早就認為沒有好的狀態(tài)支持是做不好留處理的，因此引入了 managed state 并提供了 API 接口。

　　

　　Flink 中的狀態(tài)支持(來源：https://www.slideshare.net/ParisCarbone/state-management-in-apache-flink-consistent-stateful-distributed-stream-processing)

　　一般在流處理的時候會比較關注有狀態(tài)處理，但是仔細看的話批處理也是會受到影響的。比如常見的窗口聚合，如果批處理的數(shù)據(jù)時間段比窗口大，是可以不考慮狀態(tài)的，用戶邏輯經(jīng)常會忽略這個問題。但是當批處理時間段變得比窗口小的時候，一個批的結(jié)果實際上依賴于以前處理過的批。這時，因為批處理引擎一般沒有這個需求不會有很好的內(nèi)置支持，維護狀態(tài)就成為了用戶需要解決的事情。比如窗口聚合的情況用戶就要加一個中間結(jié)果表記住還沒有完成的窗口的結(jié)果。這樣當用戶把批處理時間段變短的時候就會發(fā)現(xiàn)邏輯變復雜了。這是早期 Spark Streaming 用戶 經(jīng)常碰到的問題，直到 Structured Streaming 出來才得到緩解。

　　而像 Flink 這樣以流處理為基本模型的引擎，因為一開始就避不開這個問題，所以引入了 managed state 來提供了一個通用的解決方案。比起用戶實現(xiàn)的特定解決方案，不但用戶開發(fā)更簡單，而且能提供更好的性能。最重要的是能更好地保證處理結(jié)果的一致性。

　　簡單來說，就是有一些內(nèi)秉的數(shù)據(jù)處理邏輯，在批處理中容易被忽略或簡化處理掉也能得到可用的結(jié)果，而在流處理中問題被暴露出來解決掉了。所以流計算引擎用有限流來處理批在邏輯上比較嚴謹，能自然達到正確性。主要做一些不同的實現(xiàn)來優(yōu)化性能就可以了。而用更小的批來模擬流需要處理一些以前沒有的問題。當計算引擎還沒有通用解決方案的時候就需要用戶自己解決了。類似的問題還有維表的變化(比如用戶信息的更新)，批處理數(shù)據(jù)的邊界和遲到數(shù)據(jù)等等。

　　編程模型

　　

　　Spark 1.6 時的 API 狀態(tài)

　　Spark 的初衷之一就是用統(tǒng)一的編程模型來解決用戶的各種需求，在這方面一直很下功夫。最初基于 RDD 的 API 就可以做各種類型的數(shù)據(jù)處理。后來為了簡化用戶開發(fā)，逐漸推出了更高層的 DataFrame(在 RDD 中加了列變成結(jié)構(gòu)化數(shù)據(jù))和 Datasets(在 DataFrame 的列上加了類型)，并在 Spark 2.0 中做了整合(DataFrame = DataSet[Row])。Spark SQL 的支持也比較早就引入了。在加上各個處理類型 API 的不斷改進，比如 Structured Streaming 以及和機器學習深度學習的交互，到了今天 Spark 的 API 可以說是非常好用的，也是 Spark 最強的方面之一。

　　

　　Spark 2.0 API (來源：https://databricks.com/blog/2016/07/14/a-tale-of-three-apache-spark-apis-rdds-dataframes-and-datasets.html)

　　Flink 的 API 也有類似的目標和發(fā)展路線。Flink 和 Spark 的核心 API 可以說是可以基本對應的。今天 Spark API 總體上更完備一下，比如說最近一兩年大力投入的和機器學習深度學習的整合方面。Flink 在流處理相關的方面還是領先一些，比如對 watermark、window、trigger 的各種支持。

　　

　　Flink API(來源：https://ci.apache.org/projects/flink/flink-docs-release-1.5/concepts/programming-model.html)

　　小結(jié)

　　Spark 和 Flink 都是通用的能夠支持超大規(guī)模數(shù)據(jù)處理，支持各種處理類型的計算引擎。兩個系統(tǒng)都有很多值得探討的方面在這里沒有觸及，比如 SQL 的優(yōu)化，和機器學習的集成等等。這里主要是試圖從最基本的架構(gòu)和設計方面來比較一下兩個系統(tǒng)。因為上層的功能在一定程度上是可以互相借鑒的，有足夠的投入應該都能做好。而基本的設計改變起來會傷筋動骨，更困難一些。

　　Spark 和 Flink 的不同執(zhí)行模型帶來的較大的區(qū)別應該還是在對流計算的支持上。最開始的 Spark Streaming 對流計算想得過于簡單，對復雜一點的計算用起來會有不少問題。從 Spark 2.0 開始引入的 Structured Streaming 重新整理了流計算的語義，支持按事件時間處理和端到端的一致性。雖然在功能上還有不少限制，比之前已經(jīng)有了長足的進步。不過 micro batch 執(zhí)行方式帶來的問題還是存在，特別在規(guī)模上去以后性能問題會比較突出。最近 Spark 受一些應用場景的推動，也開始開發(fā)持續(xù)執(zhí)行模式。2.3 里的實驗性發(fā)布還只支持簡單的 map 類操作。

　　從最近 Spark+AI Summit 大會上的介紹來看，會發(fā)展成一個和 Flink 的流處理模式比較相似的執(zhí)行引擎。不過從上圖來看，主要的功能都還在開發(fā)中或者待開發(fā)。對將來能做到什么程度，和 Spark 原來的 batch 執(zhí)行引擎怎么結(jié)合，我們拭目以待。

看完上述內(nèi)容，你們對怎么實現(xiàn)大數(shù)據(jù)處理引擎Spark與Flink比拼有進一步的了解嗎？如果還想了解更多知識或者相關內(nèi)容，請關注創(chuàng)新互聯(lián)-成都網(wǎng)站建設公司行業(yè)資訊頻道，感謝大家的支持。

當前標題：怎么實現(xiàn)大數(shù)據(jù)處理引擎Spark與Flink比拼-創(chuàng)新互聯(lián)
網(wǎng)頁地址：http://www.muchs.cn/article12/dsjjgc.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站建設、響應式網(wǎng)站、手機網(wǎng)站建設、動態(tài)網(wǎng)站、網(wǎng)站內(nèi)鏈、網(wǎng)站收錄

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)