摘要

如今，隨著感測技術、無線通訊、強大的移動裝置和其他實時資訊的不斷髮展。強大的移動裝置和其他實時資源的發展，處理高速和實時資料流的方法迅速地發展，如何處理高速和實時的資料流帶來了新的挑戰。

大資料系統所面臨的這些挑戰是：以儘可能精細的粒度檢測、預測和儘可能精細地預測資訊。問題是，該系統依賴於批處理，而批處理可以對過去發生的事情給予極大的洞察；但是，它們沒有能力處理目前正在發生的事情。當然，在事件發生時對其進行實時處理是至關重要的。許多應用，如欺詐檢測、資料分析和生產檢查等許多應用都需要快速地響應和處理時間，因為大資料系統是基於MapReduce框架的，只能處理有限的資料。處理有限的資料集，不適合處理資料流，並且不適合滿足實時的限制。

因此，需要一個實時資料流處理系統，因為它是快速的，並在最短的時間內以低延遲處理資料。

本文給出了不同系統之間的明確比較，這些系統 本文對現有的實時資料流處理的不同系統進行了明確的比較，以及一個模型，該模型是基於之前進行得比較。

關鍵詞。實時處理，MapReduce，Spark，Storm。

Lambda架構，kappa架構。

介紹

如今，我們生活的世界從不同的來源產生了大量的資訊和資料，即搜尋引擎、社交網路、計算機日誌、電子郵件客戶端、感測器網路......等等，所有這些資料被稱為海量資料或大資料。例如，一分鐘在Twitter上產生347,222條新推文，約701,389次Facebook登入，YouTube上超過278萬次影片瀏覽，WhatsApp上2080萬條資訊......等等[1]。所有這些資料都是以流的形式連續產生的。

近年來，感測器技術、無線通訊以及強大的移動裝置的發展，都屬於物聯網的應用範疇，如何處理高速和實時的資料流帶來了新的挑戰。今天，大資料系統的新挑戰是以最精細的粒度檢測、預測和預報資訊。問題是，系統依靠批處理[2]，可以對過去發生的事情有很好的洞察力；但是，它們沒有能力處理此刻發生的事情，當然，把事件發生時的情況處理成實時預覽是至關重要的。大資料是基於MapReduce框架的，該框架只能處理有限的資料集，不適合處理資料流，也不適合滿足實時的約束[3] 。因此，需要一個實時的資料流處理系統，因為它速度快，能在最短的時間內處理資料，而且延遲低。

圖1 Map Reduce

Mapreduce從根本上說適合對大量資料進行並行處理，但它不是處理最新版本資料的最佳工具。這個框架是基於磁碟的方法，每個迭代的輸出都要寫到磁碟上，使得它的速度很慢。圖1表示MapReduce作業。

MapReduce從磁碟中讀取資料，並在磁碟中再次寫入四次，這意味著整個流程變得非常緩慢，從而降低了效能。

本文的其餘部分組織如下：在第二部分，我們定義了大資料、生態系統和流處理的基礎知識。在第三節中，我們介紹了資料處理工具的調查。在第四節中，我們著重於對不同的資料流處理系統進行比較研究。在第五部分，我們介紹了兩個實時處理架構的概況。最後但並非最不重要的是，在第六節中，我們提出了一個基於前面的比較的模型。

大資料的理論基礎

本節專門介紹了大資料中使用的一些主要概念，包括大資料的介紹、其架構和 大資料中使用的一些主要概念，包括大資料的介紹、其架構。使用的技術和大資料流的概念。

大資料是一個新概念，它的出現是由於大資料是一個新的概念，它的出現是由於大量複雜的資料變得難以 使用傳統的資料庫方法和工具難以處理。

根據Gartner[4]，"大資料是高容量、高速度和高種類的資訊資產，需要成本效益高、創新形式的資訊處理，以提高洞察力和決策力。加強洞察力和決策"。2010年，[5] Chen等 等人將大資料定義為 "不能由普通計算機在短時間內捕獲、管理和處理的資料集。在可接受的範圍內由普通計算機管理和處理的資料集。可接受的範圍。" [6]NIST說，"大資料是指資料量、獲取速度或資料表示方法限制了使用傳統相對論的能力。表達方式限制了使用傳統的關係型方法進行有效分析的能力，或方法進行有效分析的能力，或可透過重要的橫向放大來有效處理的資料。橫向變焦的重要技術進行有效處理的資料"。技術進行有效處理的資料"。大資料的特徵被總結歸納為五個V。數量、速度、多樣性、真實性和價值。

體積代表資料的大小或數量，從TB到YTB。太位元組到千兆位元組。這是一個巨大的演變，我們正在談論 自2005年以來，資料被限制在0.1ZB，而它們在未來可能達到40ZB甚至更多。2020年可能達到40ZB甚至更多[7]。速度意味著資料必須被快速處理和分析。

採集的速度。多樣性表示資料是種類，這使得我們可以利用不同的結構化、半結構化和非結構化的資料型別。

真實性是指對決策所依據的資料的信心。決策的基礎。最後但並非最不重要的是，價值，這意味著系統不僅要設計成能夠有效地處理大量的資料，而且還能夠從所有收集的資料中過濾出最重要的資料。

根據之前的定義，我們可以說，大資料是一個抽象的概念。，它使我們有可能提取出來以下問題：如何儲存、分析、處理和從不同的資料集中快速提取正確的資訊。產生並以資料流的形式出現。

流處理是一種能夠在資料產生的同時實時收集、整合、分析和視覺化的技術[8]。流處理解決方案被設計用來實時處理大資料，具有高度可擴充套件、高度可用和高度容錯的架構。這使其能夠分析運動中的資料[9]。

實時處理的目標是提供解決方案，能夠以非常快速和互動的方式處理來自實時和歷史資源的連續無限的資料流。

流資料處理工具

用於處理資料的古老方法，包括Hadoop正是MapReduce作業，都不足以進行實時處理。實時資料流處理可以讓你及時瞭解目前正在發生的事情，無論速度或資料量如何，都不需要儲存系統。為了很好地理解手頭的系統，我們將簡要介紹其他平臺，即Hadoop、Spark以及Storm。

Apache Hadoop

Apache Hadoop[10]是一個開源的軟體，用於處理跨機器叢集的大資料，並分批操作這些資料集。Hadoop的核心分為兩個主要部分，即處理資料的MapReduce和儲存資料的HDFS。它以其可靠性、可擴充套件性和處理模式而聞名。

MapReduce是由Jeffrey Dean和Sanjay Ghemawat於2004年在谷歌首次提出的[11]，它是一個程式設計模型和相關的實現，用於在大型機器商品叢集上處理和生成大型資料集。它具有高度的可擴充套件性，它可以在一個叢集上處理儲存在HDFS中的PB級資料，而且它具有高度的容錯性，可以讓你在商品伺服器叢集上執行程式。

這個框架基於兩個伺服器，一個是叢集上唯一的主Job Tracker，它接收MapReduce任務，在叢集上執行並組織其執行。它還負責在從機上排程任務的組成部分，以及監控它們並重新執行失敗的任務。另一個伺服器是任務跟蹤器，每個叢集有幾個，它自己執行作業的MapReduce。每個任務跟蹤器都是叢集的一個計算單位。

使用者指定一個map函式來處理一個鍵/值對，生成一組中間鍵/值對，並指定一個reduce函式來合併與同一中間鍵相關的所有中間值。如圖2所示，首先將

使用者程式中的MapReduce庫將輸入檔案分成M塊，每塊通常為16-64MB，主程式挑選空閒的工作者，給每個工作者分配一個map任務或一個reduce任務。被分配到地圖任務的工作者讀取相應的輸入分片的內容。由map函式產生的中間鍵/值對被緩衝在記憶體中。

定期地，緩衝的對被寫入本地磁碟。當一個reduce工作者讀取了其分割槽的所有中間資料後，它透過中間鍵對其進行排序，以便將所有相同鍵的出現歸為一組。之所以需要排序，是因為通常許多不同的鍵會對映到同一個還原任務。如果中間資料量太大，無法在記憶體中容納，則會使用外部排序。縮減工作者在排序的中間資料上進行迭代，對於遇到的每個獨特的中間鍵，它將鍵和相應的中間值集傳遞給使用者的縮減函式[11] 。

MapReduce有一些侷限性[12]。

• 為批處理而開發
• 基於磁碟的方法
• 資料流極其僵化
• 每次都要訪問磁碟
• 迭代演算法和互動式資料探勘的效率低下

Spark

Apache Spark[13]是一個開源的大資料處理框架，建立在Hadoop MapReduce的基礎上，用於執行復雜的分析，併為速度和易用性而設計。

這最初是由加州大學伯克利分校在2009年開發的，並在2010年作為一個Apache專案通過了開放原始碼。

Spark的效能快如閃電，並加快了處理時間，因為它在叢集的記憶體中執行。它也被設計為像apache Hadoop一樣在批次上執行，但批次視窗的大小非常小。apache spark的核心是RDD（Resilient Distributed Dataset），它是分佈在許多伺服器上的元素的容錯集合，我們可以對其進行並行操作。[14] RDD的元素不需要存在於物理儲存中；相反，一個RDD的控制代碼包含足夠的資訊，可以從可靠儲存中的資料開始計算RDD。這意味著，如果節點發生故障，RDDs總是可以被重建。除了Spark的主要API之外，該生態系統還包含了額外的庫，可以在大資料分析和機器學習領域開展工作。這些庫包括用於處理連續資料流的spark streaming，用於處理結構化資料的Spark SQL，MLlib是一個機器學習庫，以及用於圖形計算的GraphX，如圖3所示。

圖3 spark

Spark流[13]是對核心Spark API的擴充套件，能夠對實時資料流進行可擴充套件、高吞吐量和容錯的流處理。資料可以從Kafka、Flume、Kinesis或TCP套接字等許多來源攝取，並可以使用map、reduce、join和window等高階函式表達的複雜演算法進行處理。

在圖4中，我們可以看到，spark流是基於微批處理的模式，它接收實時輸入的資料流，並將資料分成若干批，然後由Spark引擎在非常固定的時間內處理這些資料，以分批生成最後的結果流。所有的輸入資料流都以同樣的方式處理。在每個批次持續時間上，同一個迴圈計時器為所有的流分配批次。

與Hadoop MapReduce相比，Spark有幾個優勢。首先，Spark提供了一個全面而統一的框架來滿足大資料處理的需要。然後，Spark允許Hadoop叢集上的應用程式在記憶體中的執行速度提高到100倍，在磁碟上的執行速度提高到10倍。此外，還可以互動式地使用它，從一個shell命令視窗查詢資料。儘管與Hadoop MapReduce相比，spark有很多優點，但它仍然面臨著一些限制；其中包括不能保證實時的流處理。這是由於spark在其操作中實現了微批的概念，並不在資料到達時進行處理，因為這些資料在被處理前會被積累一段時間。Spark和Storm的主要區別將在接下來的章節中討論。

圖4 Spark Streaming

Storm

Storm，[16]是由Nathan Marz在2010年12月實現的實時分析技術，是一個免費和開源的分散式實時計算，並使可靠地處理無邊界的資料流變得容易。Storm對實時處理的作用就像Hadoop對批處理的作用一樣；它很簡單，可以用任何程式語言來使用。

一個Storm叢集有三組節點，第一組是一個名為 "Nimbus "的守護程序，類似於Hadoop作業跟蹤器。它在主節點上執行，以便上傳計算執行，在叢集中分配程式碼，安排任務和檢測錯誤。第二個節點被稱為 "監督者"，它負責根據Nimbus的訊號啟動和停止工作程序。最後是 "Zookeeper "節點，它是一個分散式協調服務，協調Storm叢集，如圖5所示。Storm叢集從表面上看與Hadoop叢集相似。而在Hadoop上你執行 "MapReduce作業"，在Storm上你執行 "拓撲結構"。"作業 "和 "拓撲 "本身是非常不同的 -- 一個關鍵的區別是，一個MapReduce作業最終會結束，而一個拓撲會永遠處理訊息（或直到你殺死它）。

圖5 Storm 部署

一個拓撲結構由spouts和bolts組成，它們之間的連結顯示了流是如何傳遞的。這種拓撲結構就像一個數據處理的有向無環圖（DAG），代表了整個流處理過程。一個拓撲結構的表示方法如下圖所示 6.

spouts是一個流的來源，它從外部輸入源讀取圖元，並將它們作為流排放給bolts。bolts是storm拓撲結構的一個數據處理單元，它消耗任何數量的輸入流，進行一些特定的處理，並將新的流排放給其他bolts。Storm的核心抽象是 "流"。一個流是一個無界限的圖元序列。元組是一個命名的值列表，元組中的一個欄位可以是任何型別的物件。Storm提供了將一個流以分散式的、可靠的方式轉換成一個新的流的基元。

圖6 Storm

實時處理系統的比較

在這一節中，我們比較了用於實時流處理的不同工具，根據這一比較，我們將選擇最合適的工具。

上面的比較表明，storm是實時流處理的最佳工具，Hadoop做批處理，而spark能夠做微批處理。Storm使用spouts和bolts來做一次處理，以避免批處理和微批處理帶來的固有的延遲開銷。

實時處理架構

在本文中，我們簡要介紹了一些實時處理架構，即Lambda和Kappa。

Lambda架構

Lambda架構是由Nathan Marz提出的。這種架構混合了處理模型批處理和實時處理的好處，在低延遲中提供更好的結果。

圖7 lamba架構

圖7顯示了lambda的基本架構[18]。它被分為三層。

• 批次層--管理歷史資料和重新計算結果。
• 速度層--接收到達的資料並對批處理層的結果進行增量更新。
• 服務層--實現對批處理層和速度層傳送的結果的各種查詢。

所有的新資料都被髮送到批處理層和速度層。批次層負責儲存主資料集，並利用MapReduce演算法連續計算這些資料的檢視。批處理層的結果被稱為 "批處理檢視"。

服務層對批處理層產生的預計算的檢視進行索引。它是一個可擴充套件的資料庫，當新的批處理檢視可用時，它就會交換進來。由於批處理層的延遲，服務層提供的結果總是過期幾個小時。服務層可以使用NoSQL技術實現，如HBase、Apache Druid...等。

速度層彌補了更新到服務層的高延遲。這一層的作用是實時計算批處理層最後一批沒有考慮到的資料。它產生的實時檢視總是最新的，並將其儲存在一個快速儲存中。速度層可以透過資料流技術實現，如Apache Storm或Spark Streaming。

然而，lambda架構有一些限制；首先是業務邏輯，它在實時層和批處理層實現了兩次。開發人員需要在這兩層寫相同的程式碼。第二個問題是需要掌握更多的框架。最後，當需求不那麼複雜時，還有更簡單的解決方案。

Kappa架構

Kappa架構[19]由Jay kreps於2014年在Linkedin描述，是一種軟體架構模式。Kappa是lambda架構的簡化，這意味著它就像一個去掉了批處理系統的lambda架構系統。[19] Kappa架構系統中的典型資料儲存是一個僅可追加的不可更改的日誌。從日誌中，資料被流經計算系統，並被送入輔助儲存中進行服務。

事實上，甚至比lambda架構更重要的是，Kappa架構不允許永久儲存資料。它更專注於它們的處理。雖然限制更多，但Kappa架構在選擇實現的元件方面留下了一些自由。

與lambda架構相比，它為批處理層和速度層利用兩種不同的程式碼路徑，Kappa只為這兩層使用單一的程式碼路徑，這降低了系統的複雜性[20]。Kappa架構的好處是允許使用者在一個單一的處理框架之上開發、測試、除錯和操作他們的系統。下圖表示Kappa架構。

下圖代表了之前討論過的兩種架構的簡短比較，即Lambda和Kappa，遵循特定的標準。

建議架構

根據前面幾段介紹的架構和平臺，我們介紹了每個架構的不同優點和缺點，根據它的資訊，我們設計了一個新的架構，它是開源的，並考慮到了幾個標準，其中包括從高速實時處理大量資料。它還允許無限數量的使用者創造許多新的和創新的功能，並進行若干改進。

這種架構必須以低延遲攝取-過濾-分析和處理傳入的資料流，因此係統必須做出相當快的反應，這取決於所使用的處理架構（Spark、Storm等）或資料的大小和所執行的計算的複雜性。另一方面，必須考慮如何選擇最有效的工具；它應該易於使用，而不是給使用者（無論是分析師還是開發人員）帶來基礎設施問題。

完美的是，我們希望有一個架構，允許相當容易地過渡到規模，並直觀地改變資源分配。此外，新配置的資源必須無縫地加入叢集，並能處理負載或流量的變化，而不中斷全域性的流式資料處理。

最後，一個實時架構必須提供一個實時的流媒體資料視覺化。它必須允許動態建立儀表盤、自定義圖形和UI擴充套件。

圖8 建議架構

圖8代表了大資料的傳統架構和擬議架構。傳統架構包含三個層次，即儲存、處理和分析，而我們提出的架構表示如下。資料來自不同的裝置和器材，如感測器、網路、網路基礎設施、網路、電子郵件、社交媒體等等。這些資料是來自不同來源的高速資料流，由整合層使用一系列的工具和功能（例如Apache Kafka）來獲取。攝取後，資料將透過（ELT）提取-轉換載入操作（如PIG）進行過濾。換句話說，資料將被清理，其質量將被分析...等等。這個過濾層是為實時處理層準備的資料，後者的目的是實時處理資料，並具有非常低的延遲。如圖9所示，這一層將使用兩種技術，即Storm（一種實時處理工具）和機器學習。在這一層使用機器學習可以對資料進行歸檔。它的目標是在類似的輸入上使用請求/響應方法將以前的趨勢視覺化。ML從新來的資料中不斷學習，這有利於處理。另一方面，Storm也被用在這一層，以便實時處理資料。它使用拓撲結構的概念，這是一個由Spout和Bolt組成的網路。如前所述，資料流來自Spout，它在Storm拓撲結構中廣播來自外部的資料。

關於Bolt，我們可以實現一些功能，如函式、過濾器、連線、聚合...等。因此，Map功能可以在Bolt中實現，以便對資料流的文字進行標記。從Bolt'Map'得到的資料流流入下面的Bolt，該Bolt實現了'Reduce'功能，以便將單詞聚合成數字。

結論

在本文中，我們試圖介紹有關不同概念的技術現狀，從而對資料流處理工具進行徹底的比較。這種比較背後的主要目的是表明，大資料架構是基於批處理的，不能實時處理資料。透過這次徹底的比較，風暴被選為資料處理的工具，因為它是一個開放原始碼，能夠以非常低的延遲進行實時處理。

我們還進行了另一個實時處理架構的比較，以便提出一個新的架構，其中使用風暴和機器學習，以促進實時處理。

我們的下一個目標是在即將進行的研究中實施和測試這個擬議的架構。

引用

[1] K. LEBOEUF, “2016 Update_ What Happens in One Internet Minute_ - Excelacom, Inc.” [Online]. Available: http://www.excelacom.com/resources/blog/2016-updatewhat-happens-in-one-internet-minute.

[2] “MapReduce.” [Online]. Available

[3] D. S. Terzi, U. Demirezen, and S. Sagiroglu, “Evaluations of big data processing,” vol. 3, no. 1, 2016.

[4] Gartner Inc., “What Is Big Data? - Gartner IT Glossary - Big Data,” Gartner IT Glossary. p. 1, 2013.

[5] M. Chen, S. Mao, and Y. Liu, “Big data: A survey,” Mob. Networks Appl., vol. 19, no. 2, pp. 171–209, 2014.

[6] G. Li, Big data related technologies, challenges and future prospects, vol. 15, no. 3. 2015.

[7] G. Herber, “Innovation Session Unlocking the Massive Potential of Sensor Data and the Internet of Things,” 2014.

[8] M. M. Maske and P. Prasad, “A real time processing and streaming of wireless network data using Storm,” 2015 Int. Conf. Comput. Power, Energy, Inf. Commun., pp. 0244–0249, 2015.

[9] K. Wähner, “Real-Time Stream Processing as Game Changer in a Big Data World with Hadoop and Data Warehouse,” InfoQ. pp. 1–9, 2014.

[10] W. Is et al., “Welcome to ApacheTM HadoopTM!,” Innovation, no. November 2008. pp. 2009–2012, 2012.

[11] J. Dean and S. Ghemawat, “MapReduce: Simplified Data Processing on Large Clusters,” Proc. 6th Symp. Oper. Syst. Des. Implement., pp. 137–149, 2004.

[12] G. C. Deka, “Handbook of Research on Cloud Infrastructures for Big Data Analytics,” Handbook of Research on Cloud Infrastructures for Big Data Analytics. pp. 370–391, 2014.

[13] Apache Spark, “Apache SparkTM - Lightning-Fast Cluster Computing,” Spark.Apache.Org. 2015.

[14] M. Zaharia, M. Chowdhury, M. J. Franklin, S. Shenker, and I. Stoica, “Spark : Cluster Computing with Working Sets,” HotCloud’10 Proc. 2nd USENIX Conf. Hot Top. cloud Comput., p. 10, 2010.

[15] A. Ghaffar, S. & Tariq, R. Soomro, A. G. Shoro, and & Tariq, “Big Data Analysis: Ap Spark Perspective,” Glob. J. Comput. Sci. Technol. Glob. Journals Inc. Glob. J. Comput. Sci. Technol., vol. 15, no. 1, pp. 7–14, 2015.

[16] N. Marz, “Tutorial.” [Online]. Available: http://storm.apache.org/releases/1.1.0/Tutorial.html.

[17] “Lambda Architecture,” 2014. [Online]. Available: http://lambda-architecture.net/.

[18] N. Marz, Big Data - Principles and best practices of scalable realtime data systems. 2012.

[19] “Kappa Architecture - Where Every Thing Is A Stream.” .

[20] J. Kreps, “Questioning the Lambda Architecture,” O’Reilly. pp. 1–10, 2014.

[21] J. Forgeat, “Data processing architectures – Lambda and Kappa,” Ericsson Research Blog. 2015.

論文地址： https://www.researchgate.net/profile/Mohamed-Amine-Talhaoui/publication/326985824_Real-time_Data_Stream_Processing_-_Challenges_and_Perspectives/links/5c216e53a6fdccfc70670358/Real-time-Data-Stream-Processing-Challenges-and-Perspectives.pdf