Flink,Spark,Storm,Hadoop大數(shù)據(jù)框架比較
點(diǎn)擊上方“IT那活兒”，關(guān)注后了解更多精彩內(nèi)容?。?！
大數(shù)據(jù)分析作為一種用于分析大量按需數(shù)據(jù)的工具，越來(lái)越受到人們的歡迎。四個(gè)最常見(jiàn)的大數(shù)據(jù)處理框架包括Apache Hadoop，Apache Spark，Apache Storm和Apache Flink。雖然這四個(gè)都支持大數(shù)據(jù)處理，但是這些框架的用法和支持該用法的基礎(chǔ)體系結(jié)構(gòu)不同。許多研究已經(jīng)投入了時(shí)間和精力來(lái)通過(guò)評(píng)估已定義的關(guān)鍵績(jī)效指標(biāo)（KPI）來(lái)比較這些大數(shù)據(jù)框架。本文通過(guò)確定一組通用的關(guān)鍵性能指標(biāo)來(lái)總結(jié)這些早期工作，這些關(guān)鍵性能指標(biāo)包括處理時(shí)間，CPU消耗，延遲，吞吐量，執(zhí)行時(shí)間，可持續(xù)的輸入速率，任務(wù)性能，可伸縮性和容錯(cuò)能力，并比較這四個(gè)大數(shù)據(jù)通過(guò)文獻(xiàn)綜述了解這些KPI的框架。與Apache Hadoop和Apache Storm框架相比，在非實(shí)時(shí)數(shù)據(jù)中Spark為多個(gè)KPI（包括處理時(shí)間，CPU消耗，延遲，執(zhí)行時(shí)間，任務(wù)性能和可伸縮性）的贏家。在流處理中Flink與Apache Spark和Apache Storm框架相比，F(xiàn)link在處理時(shí)間，CPU消耗，延遲，吞吐量，執(zhí)行時(shí)間，任務(wù)性能，可伸縮性和容錯(cuò)能力方面最適合流處理。本文分為以下幾部分：下一部分將解釋大數(shù)據(jù)的主要特征，稱為大數(shù)據(jù)的維度。接下來(lái)是對(duì)一些大數(shù)據(jù)框架的討論。Hadoop，Spark，Storm和Flink。它們的類別將作為框架和所得結(jié)果之間的比較研究而呈現(xiàn)。之后，我們給出一些結(jié)論。
當(dāng)我們?cè)谏弦浑A段定義了大數(shù)據(jù)的含義時(shí)，現(xiàn)在說(shuō)明其特征非常重要。它由通用的大數(shù)據(jù)需求（volume（容量）, variety (多樣性) , and velocity (速度)）組成，這些需求統(tǒng)稱為3維。最近，大數(shù)據(jù)的特性從3維演變?yōu)?維度，增加了value (價(jià)值), veracity (準(zhǔn)確性), 和variability (可變性) 的特征。圖1 中顯示了6維的大數(shù)據(jù)。
圖1
譯者注：Volume（指數(shù)據(jù)量大）、Velocity（指數(shù)據(jù)量增加速度快）、Variety（指數(shù)據(jù)種類多樣）、Value（指數(shù)據(jù)價(jià)值密度）、Veracity（指數(shù)據(jù)真實(shí)性）、 variability（指數(shù)據(jù)源穩(wěn)定性）。A. Volume（容量）
Volume 是指數(shù)據(jù)的數(shù)量或大小。大數(shù)據(jù)的大小約為T(mén)B，PB（PB），Zettabyte（ZB）和Exabyte（EB）。Facebook，YouTube，Google和NASA等組織擁有大量數(shù)據(jù)，這給存儲(chǔ)，檢索，分析和處理這些數(shù)據(jù)帶來(lái)了新的挑戰(zhàn)。大數(shù)據(jù)而非傳統(tǒng)存儲(chǔ)的使用改變了我們傳輸數(shù)據(jù)和使用數(shù)據(jù)的方式。B. Variety (多樣性)
多樣性是指正在生成的不同類型的數(shù)據(jù)。可以使用不同的維度來(lái)衡量類型（例如結(jié)構(gòu)，使我們能夠區(qū)別結(jié)構(gòu)化，半結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)，或批處理與流處理的處理量）C. Variability (可變性)
可變性是指不穩(wěn)定，難以處理且難以管理的數(shù)據(jù)。解釋可變數(shù)據(jù)對(duì)研究人員來(lái)說(shuō)是一個(gè)重大問(wèn)題。譯者注：指數(shù)據(jù)源不穩(wěn)定D. Velocity (速度)
是指大數(shù)據(jù)以多快的速度生成，以便進(jìn)行操縱，交換，存儲(chǔ)和分析。由于涉及的高成本，速度對(duì)數(shù)據(jù)科學(xué)家提出了新的研究挑戰(zhàn)。當(dāng)用戶需要檢索或處理數(shù)據(jù)并且處理速度不夠快時(shí)，數(shù)據(jù)就被遺忘了。E. Veracity (準(zhǔn)確性)
準(zhǔn)確性是指正在處理的數(shù)據(jù)的質(zhì)量。數(shù)據(jù)源的準(zhǔn)確性還取決于分析數(shù)據(jù)準(zhǔn)確性。F. Value (價(jià)值)
價(jià)值是指數(shù)據(jù)帶來(lái)的目的或業(yè)務(wù)成果，以促進(jìn)決策過(guò)程。
本文比較的四個(gè)框架在它們支持的功能和底層體系結(jié)構(gòu)方面彼此不同，同時(shí)將支持大數(shù)據(jù)處理的主要目的保留在其核心。本節(jié)概述了這四個(gè)大數(shù)據(jù)處理框架的體系結(jié)構(gòu)。
A. Hadoop
在2008年，Doug Cutting和Mike Cafarella將Apache Hadoop定義為一個(gè)開(kāi)源框架，該框架通過(guò)一組稱為群集或節(jié)點(diǎn)的主機(jī)（硬件層）收集和處理分布式數(shù)據(jù)。它提供的是分發(fā)服務(wù)機(jī)器，而不是一項(xiàng)服務(wù)。因此，它們可以通過(guò)使用群集或節(jié)點(diǎn)并行工作。 圖2 說(shuō)明了Hadoop框架的三個(gè)主要層。第一個(gè)是用于收集數(shù)據(jù)的數(shù)據(jù)存儲(chǔ)層，其中包含Hadoop分布式文件系統(tǒng)（HDFS）。第二層是YARN基礎(chǔ)結(jié)構(gòu)，它提供用于作業(yè)調(diào)度的算術(shù)資源，例如CPU和內(nèi)存。第三個(gè)是MapReduce，它用于與其他進(jìn)程一起處理數(shù)據(jù)（軟件層）。圖2
Fig. 2. Hadoop Architecture Adapted 許多公司，企業(yè)和組織使用Apache Hadoop的主要原因有兩個(gè)。首先，進(jìn)行學(xué)術(shù)或科學(xué)研究。其次，進(jìn)行分析以滿足客戶的需求并幫助組織做出正確的決定。例如，當(dāng)組織需要知道客戶需要哪種產(chǎn)品時(shí)。然后，它可以產(chǎn)生大量所需的產(chǎn)品，這是Apache Hadoop的幾種應(yīng)用程序之一。B. Spark
Apache Spark是在加州大學(xué)伯克利分校建立的開(kāi)源框架。它在2013年成為Apache項(xiàng)目，通過(guò)大規(guī)模數(shù)據(jù)處理提供更快的服務(wù)。Spark框架對(duì)Hadoop而言就像MapReduce對(duì)數(shù)據(jù)處理和HDFS一樣。此外，Spark具有數(shù)據(jù)共享功能，稱為彈性分布式數(shù)據(jù)集（RDD）和有向無(wú)環(huán)圖（DAG）。圖3表示Spark架構(gòu)，它非常容易且快速地選擇大量數(shù)據(jù)處理。Spark主要由五層組成。第一層包括數(shù)據(jù)存儲(chǔ)系統(tǒng)，例如HDFS和HBASE。第二層是資源管理；例如YARN和Mesos。第三個(gè)是Spark核心引擎。第四個(gè)是一個(gè)庫(kù)，由SQL，流處理，用于機(jī)器學(xué)習(xí)的MLlib，Spark R和用于圖形處理的GraphX組成。最后一層是應(yīng)用程序接口，例如Java或Scala。通常，Spark提供了一種大型數(shù)據(jù)處理框架，供銀行，電信公司，游戲公司，政府以及Apple，Yahoo和Facebook等公司使用。圖3
Fig. 3. Spark Architecture Adapted C. Storm
Storm引擎是一個(gè)開(kāi)放源代碼框架，旨在實(shí)時(shí)處理流數(shù)據(jù)。它是用Clojure語(yǔ)言編寫(xiě)的。圖4顯示Storm可以在任何程序語(yǔ)言和任何應(yīng)用程序開(kāi)發(fā)平臺(tái)上使用。因此，它保證了數(shù)據(jù)不會(huì)丟失。圖5說(shuō)明了兩種類型的節(jié)點(diǎn)：第一種是主節(jié)點(diǎn)，第二種是工作節(jié)點(diǎn)。主節(jié)點(diǎn)用于監(jiān)視故障，承擔(dān)分布式節(jié)點(diǎn)的責(zé)任并為每臺(tái)計(jì)算機(jī)指定每個(gè)任務(wù)。所有這些任務(wù)統(tǒng)稱為Nimbus，類似于Hadoop的Job-Tracker。工作節(jié)點(diǎn)稱為主管。當(dāng)Nimbus為它分配特定的進(jìn)程時(shí)，它將起作用。因此，拓?fù)涞拿總€(gè)子過(guò)程都可與許多分布式計(jì)算機(jī)一起使用。Zookeeper扮演Nimbus與主管之間的協(xié)調(diào)員。更重要的是，如果任何集群出現(xiàn)故障，它將把任務(wù)重新分配給另一個(gè)任務(wù)。因此，從節(jié)點(diǎn)控制自己任務(wù)的執(zhí)行。圖4
Fig. 4. Storm Architecture圖5
D. Flink
Apache Flink 是由三所德國(guó)大學(xué)于2010年創(chuàng)建的開(kāi)源框架，已被有效地用于實(shí)時(shí)和批處理模式下的數(shù)據(jù)處理。它使用內(nèi)存中處理技術(shù)，并提供了許多用于查詢的API，例如流處理API（數(shù)據(jù)流），批處理API（數(shù)據(jù)集）和表API。它還具有機(jī)器學(xué)習(xí)（ML）和圖形處理（Gelly）庫(kù)。圖6展示了Flink的體系結(jié)構(gòu)。在基礎(chǔ)層中，存儲(chǔ)層可以從多個(gè)目標(biāo)（例如HDFS，本地文件等）讀取和寫(xiě)入數(shù)據(jù)。然后，部署和資源管理層包含用于管理計(jì)劃任務(wù)，監(jiān)視作業(yè)和管理資源的群集管理器。該層還包含執(zhí)行程序的環(huán)境，即集群或云環(huán)境。同時(shí)，它還支持單個(gè)Java虛擬機(jī)的本地部署。此外，它還具有用于實(shí)時(shí)處理的分布式流數(shù)據(jù)流引擎的內(nèi)核層。此外，應(yīng)用程序還具有用于兩個(gè)過(guò)程的接口層：批處理和流傳輸。上層是一個(gè)使用Java或Scala編程語(yǔ)言編寫(xiě)程序的庫(kù)。然后在Flink優(yōu)化器的幫助下將其提交給編譯器進(jìn)行轉(zhuǎn)換，以提高其性能。圖6
Fig. 6. Flink Architecture Adapted
我們研究中的每個(gè)大數(shù)據(jù)框架都支持一組功能，這些功能也可以用作關(guān)鍵績(jī)效指標(biāo)。在本節(jié)中，我們將介紹通過(guò)文獻(xiàn)綜述確定的一組通用功能，并比較這些功能中的四個(gè)框架。
A. Scalability(可伸縮性)
可伸縮性是系統(tǒng)響應(yīng)不斷增加的負(fù)載量的能力。它有兩種類型：（縱向）擴(kuò)展和（橫向）擴(kuò)展。向上擴(kuò)展用于升級(jí)硬件配置，而向外擴(kuò)展用于添加額外的硬件。我們研究中的所有四個(gè)框架都是水平可擴(kuò)展的。這意味著我們可以根據(jù)需要在集群中添加許多節(jié)點(diǎn)。B. Message Delivery Guarantees(消息傳遞保證)
失敗時(shí)將使用消息傳遞保證。根據(jù)上面提到的四個(gè)框架，它可以分為兩種類型：exactly once(恰好一次)和atleast-once(至少一次)。exactly once(恰好一次)傳遞意味著該消息將不會(huì)重復(fù)，也不會(huì)丟失，并且將精確地傳遞給收件人一次。另一方面，atleast-once(至少一次)傳遞意味著有很多傳遞消息的嘗試，并且這些嘗試中的至少一個(gè)成功。此外，該消息可以重復(fù)而不會(huì)丟失。C. Computation Mode(計(jì)算模式)
計(jì)算模式可以是內(nèi)存中計(jì)算，也可以是更傳統(tǒng)的模式，在該模式下，計(jì)算結(jié)果將寫(xiě)回到磁盤(pán)上。內(nèi)存中計(jì)算速度更快，但存在潛在的缺點(diǎn)，即在關(guān)閉計(jì)算機(jī)的情況下丟失內(nèi)容。D. Auto-Scaling(自動(dòng)擴(kuò)展)
自動(dòng)擴(kuò)展是指根據(jù)情況自動(dòng)擴(kuò)展或縮減云服務(wù)。E. Iterative Computation(迭代計(jì)算)
迭代計(jì)算是指迭代方法的實(shí)現(xiàn)，該迭代方法在沒(méi)有實(shí)際解的情況下或在實(shí)際解的成本過(guò)高的情況下估計(jì)近似解。表I對(duì)大數(shù)據(jù)框架某些特征進(jìn)行了匯總：表I：
本節(jié)介紹現(xiàn)有文獻(xiàn)，比較上述四個(gè)大數(shù)據(jù)處理框架。通過(guò)文獻(xiàn)，我們確定了九種不同的關(guān)鍵性能指標(biāo)，即處理時(shí)間，CPU消耗，延遲，吞吐量，執(zhí)行時(shí)間，可持續(xù)的輸入速率，任務(wù)性能，可伸縮性和容錯(cuò)能力。
A. Processing Time (處理時(shí)間)
許多現(xiàn)有研究已通過(guò)處理時(shí)間評(píng)估了大數(shù)據(jù)框架的性能。進(jìn)行了一項(xiàng)采用該措施作為關(guān)鍵績(jī)效指標(biāo)的工作。這項(xiàng)研究使用了個(gè)性化的監(jiān)視工具來(lái)監(jiān)視資源使用情況，并使用Python腳本來(lái)檢測(cè)計(jì)算機(jī)的狀態(tài)。在批處理模式實(shí)驗(yàn)中，研究人員包含了100億條推文的數(shù)據(jù)集，而在流模式實(shí)驗(yàn)中，他們收集了10億條推文。在批處理模式下，他們?cè)u(píng)估了數(shù)據(jù)大小和使用的群集對(duì)處理時(shí)間的影響。關(guān)于數(shù)據(jù)大小，研究發(fā)現(xiàn)Spark的速度比Hadoop和Flink的速度快，而Flink的速度最慢。他們還注意到，僅當(dāng)數(shù)據(jù)集較?。ㄐ∮? GB）時(shí)，F(xiàn)link才比Hadoop更快。實(shí)際上，與避免輸入/輸出操作的Spark相比，Hadoop通過(guò)訪問(wèn)HDFS來(lái)傳輸數(shù)據(jù)。因此，在這種情況下，處理時(shí)間受到輸入/輸出操作量的影響，因此，當(dāng)處理大量數(shù)據(jù)時(shí)，處理時(shí)間增加。另一方面，關(guān)于所用集群的大小，該研究表明，Hadoop和Flink比Spark需要更長(zhǎng)的時(shí)間，因?yàn)镾park中作業(yè)的執(zhí)行受處理器數(shù)量和對(duì)Linux的讀寫(xiě)操作量的影響RAM，而不是磁盤(pán)使用，例如Hadoop。在流模式實(shí)驗(yàn)中，研究人員通過(guò)評(píng)估窗口時(shí)間對(duì)已處理事件數(shù)的影響來(lái)研究處理速率。他們證明，在每條消息發(fā)送100 KB的推文的情況下，F(xiàn)link和Storm具有最好的處理速度，優(yōu)于Spark。這是因?yàn)檫@些框架為窗口時(shí)間使用了不同的值。Flink和Storm使用毫秒，而Spark使用秒。另一方面，在每條消息發(fā)送五個(gè)500KB的tweet時(shí)，F(xiàn)link的工作效率比Storm和Spark高。此外，在進(jìn)行的一項(xiàng)研究中，作者根據(jù)亞馬遜網(wǎng)站上的電子商務(wù)數(shù)據(jù)評(píng)估了Flink和Spark的性能。他們使用的數(shù)據(jù)集為JSON格式。每條記錄具有固定數(shù)量的字段，一條記錄的平均大小為3000字節(jié)。他們發(fā)現(xiàn)使用Flink處理數(shù)據(jù)的平均時(shí)間為240.3秒，而Spark則為60.4秒。因此，Spark的性能比Flink更好，約為179.5％。B. CPU Consumption(CPU消耗)
許多人已經(jīng)使用CPU消耗來(lái)評(píng)估大數(shù)據(jù)框架的性能。在進(jìn)行的一項(xiàng)研究中，發(fā)現(xiàn)在批處理模式下，F(xiàn)link使用的資源少于Hadoop和Spark。這是因?yàn)榕cSpark和Hadoop相比，F(xiàn)link會(huì)部分利用磁盤(pán)和內(nèi)存資源。此外，基于流模式，研究發(fā)現(xiàn)Flink在CPU消耗方面低于Spark和Storm，因?yàn)榕cStorm相比，F(xiàn)link主要用于處理大型消息。Spark每秒收集一次事件，然后執(zhí)行任務(wù)。因此，將處理多個(gè)消息，結(jié)果導(dǎo)致CPU使用率高。研究中，使用Yahoo流基準(zhǔn)測(cè)試（YSB）和三個(gè)數(shù)據(jù)流框架-Spark，Storm和Flink-進(jìn)行實(shí)驗(yàn)。實(shí)驗(yàn)發(fā)現(xiàn)，與其他框架相比，Storm具有最高的CPU資源使用率。此外，進(jìn)行的一項(xiàng)研究發(fā)現(xiàn)，Apache Spark達(dá)到大約100％的CPU利用率，而Apache Flink使用更少的CPU資源執(zhí)行相同的負(fù)載。C. Latency(延遲)
延遲是評(píng)估大數(shù)據(jù)框架性能的另一重要性能指標(biāo)。例如，使用來(lái)自監(jiān)視攝像機(jī)的數(shù)據(jù)集，其中包括1595個(gè)不同人的3425個(gè)視頻，使用RAM3S框架比較了Spark，Storm和Flink的性能。研究人員在本地環(huán)境以及Google Cloud平臺(tái)上實(shí)施了他們的實(shí)驗(yàn)。當(dāng)本地集群和云的節(jié)點(diǎn)數(shù)量變化時(shí)，Apache Storm達(dá)到了最低的延遲，并且與Flink延遲非常相似。但是，由于其微批處理設(shè)計(jì)，Spark獲得了最高的延遲。此外，進(jìn)行的一項(xiàng)研究發(fā)現(xiàn)，只有在可以接受高延遲的情況下，Spark才能勝過(guò)Flink。另外，使用RAM3S框架比較Storm，Spark和Flink中大量多媒體流的實(shí)時(shí)分析。他們使用了YouTube面孔數(shù)據(jù)集（YTFD），其中包括來(lái)自1595個(gè)不同人群的3425個(gè)視頻和不同的視頻分辨率，其中480360最常見(jiàn)，總共621、126幀，平均連接的人臉最少每個(gè)視頻181.3幀。他們證明，Storm和Flink的效果比Spark稍好。另一項(xiàng)研究基于兩組數(shù)據(jù)集（即3000個(gè)良性和500個(gè)異常）比較了Spark和Storm。第一個(gè)數(shù)據(jù)集來(lái)自VMware中的Spark集群（D1），第二個(gè)數(shù)據(jù)集來(lái)自Yahoo Cloud Serving Benchmark（YCSB），可預(yù)測(cè)異常（D2）。作者完成了在不同VM和單個(gè)VM中測(cè)試數(shù)據(jù)的工作。他們發(fā)現(xiàn)，在所有情況下，Spark的平均延遲都小于Storm。D. Throughput(吞吐量)
吞吐量是已用于評(píng)估大數(shù)據(jù)框架性能的另一種度量。例如，發(fā)現(xiàn)Spark的吞吐量要比Storm和Flink低，然而，研究人員證明，當(dāng)Spark的批處理間隔較長(zhǎng)時(shí)，吞吐量會(huì)更高。此外，在使用云環(huán)境的情況下，Storm和Flink的效果略好于Spark，而沒(méi)有考慮構(gòu)建D-stream所需的時(shí)間。E. Execution Time (執(zhí)行時(shí)間)
使用執(zhí)行時(shí)間來(lái)評(píng)估和比較Hadoop，Spark和Flink框架的性能。他們使用大數(shù)據(jù)評(píng)估工具（BDEv）在DAS-4上進(jìn)行了實(shí)驗(yàn)，以自動(dòng)化框架的配置。實(shí)驗(yàn)指出，將Spark和Flink替換為Hadoop，當(dāng)使用49個(gè)節(jié)點(diǎn)時(shí)，平均執(zhí)行時(shí)間分別減少77％和70％。工作中，研究人員使用開(kāi)源數(shù)據(jù)集評(píng)估了SparkCount和Hadoop在WordCount和Logistic回歸程序方面的性能，該數(shù)據(jù)集包括各種公司的破產(chǎn)預(yù)測(cè)。他們的結(jié)果表明，Spark中WordCount程序的執(zhí)行時(shí)間少于Hadoop。此外，在Spark中執(zhí)行邏輯回歸程序的時(shí)間少于Hadoop。例如，如果迭代次數(shù)為100，則Spark中的執(zhí)行時(shí)間為3.452秒；對(duì)于Hadoop，為9.383秒。因此，Spark在WordCount和Logistic回歸方面均勝過(guò)Hadoop。原因之一是，在Spark的內(nèi)存存儲(chǔ)中使用緩存使過(guò)程更快。此外基于WordCount程序使用Spark和MapReduce框架對(duì)性能進(jìn)行了測(cè)量，該框架運(yùn)行在安裝在Ubuntu機(jī)器上的單節(jié)點(diǎn)Hadoop（HDFS）上。他們使用了大文本文件形式的數(shù)據(jù)集，其中包含客戶對(duì)多種產(chǎn)品的評(píng)論和反饋，并將該文件分配為不同的大小。與MapReduce編程框架相比，Spark的執(zhí)行速度大約是三到四倍。比較使用Karamel（Web應(yīng)用程序）的Spark和Flink框架，以便評(píng)估系統(tǒng)級(jí)別和應(yīng)用程序級(jí)別的性能。使用了TeraSort應(yīng)用程序生成并使用HDFS存儲(chǔ)的數(shù)據(jù)，以及各種輸入級(jí)別（200GB，400GB和600GB）。研究人員發(fā)現(xiàn)Flink減少了執(zhí)行時(shí)間，比Terasort應(yīng)用程序的Spark快1.5倍。F. Sustainable Input Rate(可持續(xù)的輸入速率)
使用可持續(xù)輸入率作為比較大數(shù)據(jù)框架的績(jī)效指標(biāo)。當(dāng)本地集群和云的計(jì)算節(jié)點(diǎn)數(shù)量發(fā)生變化時(shí)，將使用此度量。Storm在兩種情況下（本地和云）都優(yōu)于Flink和Spark。此結(jié)果是由于Storm使用的最簡(jiǎn)單的一次語(yǔ)義(atleast-once 至少一次），而在Flink中，是exactly once(恰好一次)。另外，Storm的拓?fù)涫怯沙绦騿T定義的，而在Flink中，它是由優(yōu)化器定義的。這導(dǎo)致Flink的效率降低。另一方面，Spark并非主要設(shè)計(jì)為流引擎。因此，這也是輸入速率較低的原因之一。G. Task Performance (任務(wù)性能)
研究比較大數(shù)據(jù)框架在許多給定任務(wù)上的性能，這些任務(wù)包括WordCount，k-means，PageRank，Grep，TeraSort和connected components。研究發(fā)現(xiàn)，與Flink和Hadoop相比，Spark在WordCount和k-means方面表現(xiàn)最佳，而Flink對(duì)于PageRank則取得了更好的結(jié)果。另一方面，F(xiàn)link和Spark在Grep，TeraSort和connected components上均取得了相同的結(jié)果，并且在這些方面均勝過(guò)Hadoop。導(dǎo)致WordCount結(jié)果的一種解釋是，求每個(gè)單詞出現(xiàn)的次數(shù)和，Spark使用reduceByKey（）函數(shù)與flink中優(yōu)化程度較低的groupBy（）。sum（）函數(shù)的Flink相比，所以WordCount性能測(cè)試中Spark超越Flink。在Grep中，Spark和Flink的性能要優(yōu)于Hadoop，因?yàn)镠adoop使用一個(gè)MapReduce搜索模式，然后使用另一個(gè)對(duì)結(jié)果進(jìn)行排序。這導(dǎo)致大量的內(nèi)存復(fù)制和寫(xiě)入HDFS。在PageRank中，F(xiàn)link獲得了最佳性能，因?yàn)樗褂玫脑隽康鷥H處理尚未達(dá)到最終值的元素。H. Scalability(可伸縮性)
在衡量可擴(kuò)展性方面，將運(yùn)營(yíng)商的執(zhí)行計(jì)劃（端到端執(zhí)行時(shí)間）與資源使用和參數(shù)配置聯(lián)系在一起，以衡量Spark和Flink的性能。結(jié)果表明，Spark比Flink快大約1.7倍，特別是在大型圖數(shù)據(jù)處理中。相比之下，在具有大型數(shù)據(jù)集和固定節(jié)點(diǎn)的情況下，F(xiàn)link更好，其性能比Spark高出10％。I. Fault Tolerance(容錯(cuò))
關(guān)于容錯(cuò)度量， 進(jìn)行的研究指出，F(xiàn)link具有比Storm和Spark框架更高的容錯(cuò)能力。總體而言，這里回顧的所有研究都表明，與Hadoop和Flink相比，Spark在processing time(處理時(shí)間)方面是最快的。同樣在延遲方面，Spark也是最低的。此外，與Hadoop和Flink相比，Spark在Throughput(吞吐量)和execution time(執(zhí)行時(shí)間)方面是最好的。同樣在WordCount和k-means方面，它比Flink和Hadoop更好。此外，在Grep，TeraSort和Connected Components方面，它比Hadoop也更好。此外，就可伸縮性而言，與Flink相比，Spark在大型圖計(jì)算的情況下更好。與Storm和Spark相比，F(xiàn)link在processing time(處理時(shí)間)方面效率更高。另外，在使用云環(huán)境的情況下，它在Throughput(吞吐量)方面更有效，而無(wú)需考慮構(gòu)建d-stream的時(shí)間。除此之外，僅在使用Karamel和TeraSort應(yīng)用程序的情況下，與Spark相比，execution time(執(zhí)行時(shí)間)更短。此外，就PageRank而言，與Spark和Hadoop相比，它是最好的。此外，就Grep，TeraSort和Connected Components而言，它比Hadoop更好。就可伸縮性而言，只有在數(shù)據(jù)集很大且節(jié)點(diǎn)數(shù)量固定的情況下，與Spark相比才是最好的。同樣，在容錯(cuò)方面，它比Storm和Spark好。Storm在CPU利用率方面與Spark，F(xiàn)link和Hadoop框架相比性能最佳。此外，與Spark和Flink相比，它具有最低的延遲。另外，僅在使用云環(huán)境的情況下，它才具有最佳吞吐量，而無(wú)需考慮構(gòu)建d-stream所需的時(shí)間。而且，與Flink和Spark相比，它具有更好的可持續(xù)輸入速率。表II四個(gè)大數(shù)據(jù)框架比較的文獻(xiàn)綜述。表II：
這項(xiàng)研究的結(jié)果表明，與其他框架相比，F(xiàn)link表現(xiàn)最佳，因?yàn)樗诎隧?xiàng)指標(biāo)中均達(dá)到了最佳性能。Spark在六個(gè)方面優(yōu)于其他框架，Storm在四個(gè)方面優(yōu)于其他框架。因此，公司，研究人員以及對(duì)該領(lǐng)域感興趣的個(gè)人的用戶可以根據(jù)他們希望使用的關(guān)鍵績(jī)效指標(biāo)來(lái)選擇合適的框架，以便分析數(shù)據(jù)并獲得有效的結(jié)果。最后，他們將獲得高性能的計(jì)算（HPC）。
將來(lái)，通過(guò)在四個(gè)框架的性能中考慮這些度量，可以以任何對(duì)獲得HPC影響不大的度量來(lái)增強(qiáng)每個(gè)框架的機(jī)會(huì)。因此，我們希望看到其中一些框架有所增強(qiáng)，同時(shí)還包括能夠提供高性能的其他框架。
更多精彩干貨分享
點(diǎn)擊下方名片關(guān)注
IT那活兒
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://m.hztianpu.com/yun/129749.html
