??想了解更多關(guān)于開源的內(nèi)容，請訪問：??

??51CTO 開源基礎(chǔ)軟件社區(qū)??

??https://ost.51cto.com??

【本期看點(diǎn)】

• Hadoop和Spark框架的性能優(yōu)化系統(tǒng)。
• 云計算重復(fù)數(shù)據(jù)刪除技術(shù)降低冗余度。
• 壓縮框架Ares如何統(tǒng)一不同算法。
• 在線數(shù)據(jù)壓縮“搖擺門趨勢”。
• 揭秘新型移動云存儲SDM。

【技術(shù)DNA】

【智慧場景】

背景介紹

大數(shù)據(jù)概念

大數(shù)據(jù)(Big Data)，又稱為巨量資料，指的是所涉及的資料量規(guī)模巨大到無法透過主流軟件工具，在合理的時間內(nèi)達(dá)到擷取、管理、處理、并整理成為幫助企業(yè)經(jīng)營決策更積極目的的資訊。

但大數(shù)據(jù)是個抽象的概念，業(yè)界對大數(shù)據(jù)還沒有一個統(tǒng)一的定義，而且用上面的定義似乎難以理解，所以就有了以下用 “4V” 來定義大數(shù)據(jù)的方法。

大數(shù)據(jù)特征

說到大數(shù)據(jù)的特征，就不得不提到“4V”。那什么是“4V”呢?

“4V” 即四個用來描述大數(shù)據(jù)特征的英文單詞：Volume(體積)、Velocity(速度)、Variety(多樣) 和 Value(價值)。用“4V”的方式給大數(shù)據(jù)下個中文定義，那就是滿足數(shù)據(jù)體量巨大、數(shù)據(jù)速度快速、數(shù)據(jù)種類繁多和數(shù)據(jù)價值密度低的數(shù)據(jù)即大數(shù)據(jù)。

每天大家都在使用微信、QQ與好友開黑聊天，用支付寶、淘寶完成線上下支付。時過境遷，目前互聯(lián)網(wǎng)產(chǎn)生的數(shù)據(jù)已經(jīng)遠(yuǎn)遠(yuǎn)地超過很多年前的“3G時代”。比如下圖，生動形象地描述了2021年各大互聯(lián)網(wǎng)公司每分鐘所產(chǎn)生的數(shù)據(jù)。

像是 Tiktok 每分鐘就產(chǎn)生了5000次下載，197.6 百萬條電子郵件被發(fā)出，500 個小時的視頻被上傳。雖然不是國內(nèi)的數(shù)據(jù)，但也能反映出國內(nèi)的一些情況，更能讓我們體會到大數(shù)據(jù)時代下的數(shù)據(jù)量之大，數(shù)據(jù)種類之繁雜。側(cè)面也能反映出處理這些數(shù)據(jù)的困難。

問題解決

那么大數(shù)據(jù)是怎樣一步步發(fā)展到今天的呢?在回答這個問題之前，我們先來介紹一下兩個由著名的 Apache 基金會開源出來的非常重要的項目 Apache Spark 和 Apache Hadoop。

Apache Hadoop 介紹

Apache Hadoop 是一個開源的，可靠的，可擴(kuò)展的分布式計算框架，是下面這位大佬 Doug Cutting 發(fā)明的。這個項目的名稱以及Logo來源也很有趣，就是大佬手中拿著的玩具的名字，對比一下 Apache Hadoop 的 Logo，是不是感覺有異曲同工之處?

Apache Hadoop 能做些什么呢?搭建大型的數(shù)據(jù)倉庫以及PB級別的數(shù)據(jù)的存儲、處理、分析、統(tǒng)計等業(yè)務(wù)，這些 Hadoop 都不在話下。而且，在搜索引擎時代，數(shù)據(jù)倉庫時代、數(shù)據(jù)挖掘時代以及如今的機(jī)器學(xué)習(xí)時代，Hadoop 都分別擔(dān)當(dāng)著重要的作用。

Apache Spark 介紹

Apache Spark是加州大學(xué)伯克利分校AMP實(shí)驗室(Algorithms, Machines, and People Lab)開發(fā)的通用內(nèi)存并行計算框架。具有運(yùn)行速度快、易用性好、通用性強(qiáng)以及隨處運(yùn)行的特點(diǎn)。

Apache Spark 支持使用內(nèi)存中處理來提升大數(shù)據(jù)分析應(yīng)用程序的性能。 大數(shù)據(jù)解決方案旨在處理對傳統(tǒng)數(shù)據(jù)庫來說太大或太復(fù)雜的數(shù)據(jù)，而使用Spark處理內(nèi)存中的大量數(shù)據(jù)，會比基于磁盤的替代方法要快得多。

兩者的聯(lián)系

Apache Hadoop 提供分布式數(shù)據(jù)存儲功能HDFS，還提供了用于數(shù)據(jù)處理的 MapReduce。雖然 MapReduce 是可以不依靠 Apache Spark 進(jìn)行數(shù)據(jù)的處理，Apache Spark 也可以不依靠 HDFS 來完成數(shù)據(jù)存儲功能，但如果兩者結(jié)合在一起，讓 Apache Hadoop 來提供分布式集群和分布式 文件系統(tǒng)，Apache Spark 可以依附 HDFS 來代替 MapReduce 去彌補(bǔ) MapReduce 計算能力不足的問題。

或許，有了上面的兩個框架，處理如今的大數(shù)據(jù)時代所產(chǎn)生的問題已經(jīng)很完美了，但是看一看下圖對全球數(shù)據(jù)量以及其增速的預(yù)測，就能感覺到終有一天，現(xiàn)有的技術(shù)不能再滿足我們，我們的技術(shù)仍然需要精進(jìn)。

如何精進(jìn)

從Hadoop源頭

此時，或許我們應(yīng)該了解一下 Apache Hadoop 的來源。Apache Hadoop 最早起源于Nutch。Nutch 的設(shè)計目標(biāo)是構(gòu)建一個大型的全網(wǎng)搜索引擎，包括網(wǎng)頁抓取、索引、查詢等功能，但隨著抓取網(wǎng)頁數(shù)量的增加，遇到了嚴(yán)重的可擴(kuò)展性問題——如何解決數(shù)十億網(wǎng)頁的存儲和索引問題。

2003~2014 年 Google 發(fā)表的三篇論文為這個問題帶來了解決的方案。三篇論文中分別提到了三個至關(guān)重要的技術(shù)點(diǎn) GFS，MapReduce 以及 BigTable。最終分別演變成了 Hadoop 生態(tài)中的 HDFS，Hadoop MapReduce 以及 HBase。

• GFS：Google File System，Google的分布式文件系統(tǒng)。
• MapReduce：Google的分布式計算模型，用于解決PageRank問題。
• BigTable：列式存儲Hbse的理論基礎(chǔ)。

而其中的 Hadoop MapReduce 就是 Apache Hadoop 中重要的組成部分之一，它是數(shù)據(jù)中心的一個重要的數(shù)據(jù)處理引擎，它可以幫助用戶避免維護(hù)物理基礎(chǔ)設(shè)施的成本。許多研究都集中在 MapReduce 的任務(wù)上，來提高數(shù)據(jù)中心的性能并將能源的消耗大幅降低。這期閱讀的論文也是研究了與 MapReduce 相關(guān)的數(shù)據(jù)壓縮。

從數(shù)據(jù)壓縮入手

數(shù)據(jù)壓縮算法的權(quán)衡取決于各種因素，比如壓縮程度、數(shù)據(jù)質(zhì)量、壓縮算法類型或者數(shù)據(jù)類型。最終的數(shù)據(jù)大小或是 I/O 減少的程度取決于壓縮比，而壓縮比取決于數(shù)據(jù)和壓縮算法。這意味著更低的比率將會減少內(nèi)存以及I/O的使用。

從Hadoop特性

下面是 Hadoop 中可用的壓縮格式的摘要:

由于數(shù)據(jù)需要被安全的存儲，所以作者選擇的上表中所有選擇的壓縮編碼器以及解碼器都是無損的。

gzip 和 deflate 編解碼器都使用 deflate 算法來替代 lz77 和 Huffman 編碼的組合。兩者的區(qū)別在于 Huffman 編碼階段

可拆分壓縮 bzip2 編解碼器使用 Burrows-Wheeler(塊排序)文本壓縮和 Huffman 編碼算法。Bzip2 可以獨(dú)立壓縮數(shù)據(jù)塊，也可以并行壓縮數(shù)據(jù)塊。

Snappy 是一個快速的數(shù)據(jù)壓縮和解壓縮庫，使用了 lz77 的思想。Snappy 塊是不可分割的，但是 Snappy 塊中的文件是可分割的。

lzo (Lempel- Ziv-Oberhumer)壓縮算法是 lz77 壓縮算法的變體。該算法分為查找匹配，寫入未匹配的文字?jǐn)?shù)據(jù)，確定匹配的長度，以及寫入匹配令牌部分。

壓縮的數(shù)據(jù)文件由 lz4 序列組成，該序列包含一個標(biāo)記、文字長度、偏移量和匹配長度。

Zstandart 是 Facebook 開發(fā)的一種基于 lz77 的算法，支持字典、大規(guī)模搜索框和使用有限狀態(tài)熵和霍夫曼編碼的熵編碼步驟。

Hadoop 支持的壓縮格式太多，因此需要一種可以動態(tài)選擇壓縮方式的算法，根據(jù)數(shù)據(jù)類型對壓縮格式進(jìn)行選擇。

相關(guān)工作

• 關(guān)于 I/O 性能。作者分析了幾篇論文，找到提升 I/O 性能并能提高能源效率的方法。
• 首先作者閱讀量三篇論文，該論文中的作者將 4 個計算機(jī)節(jié)點(diǎn)集群，來研究部分?jǐn)?shù)據(jù)壓縮對 MapReduce 小工作量的情況下對性能的提高以及對能源的利用情況。
• 其次該論文中的作者從已有的幾種方法和壓縮算法來確定壓縮方法，以減少數(shù)據(jù)加載時間和提高并發(fā)性。
• 最后，該論文中的作者研究了兩種可動態(tài)選擇的算法，通過周期性的壓縮算法特征分析和實(shí)時系統(tǒng)資源狀態(tài)的監(jiān)控來實(shí)現(xiàn)最佳的 I/O 性能。
• 關(guān)于能源效率。作者選取了幾篇論文，分析了不同的能源模型來預(yù)測 MapReduce 作業(yè)時的能源消耗。
• 通過調(diào)整數(shù)據(jù)復(fù)制系數(shù)和數(shù)據(jù)塊大小參數(shù)，最小化了作業(yè)的執(zhí)行時間和能耗。
• 其次，作者通過另一篇論文的一個預(yù)測 MapReduce 工作負(fù)載能耗的線性回歸模型，發(fā)現(xiàn)了了通過精確的資源分配和只能的動態(tài)電壓和頻率縮放調(diào)度，可以顯著節(jié)省能源。
• 還有，作者了解了修改 Hadoop 以實(shí)現(xiàn)可操作集群規(guī)模縮減方面的早期工作。
• 最后，作者閱讀了一篇調(diào)整HPC集群并行度，網(wǎng)絡(luò)帶寬以及電源管理功能的策略，來達(dá)到高效執(zhí)行 MapReduce 的目的。
• 作者最終通過修改Hadoop/Spark 框架中關(guān)于能源效率的各種配置參數(shù)，以達(dá)到提升 Hadoop MapReduce 作業(yè)的性能的目的。論文旨在提出一個選擇最佳壓縮工具并調(diào)整壓縮因子以達(dá)到最佳性能的系統(tǒng)。

測試方法

方法框架

研究人員通過研究節(jié)省 CPU 和節(jié)省 I/O 之間的權(quán)衡，以此評估使用基于壓縮工具的 Hadoop 和 Spark 框架下的大數(shù)據(jù)應(yīng)用程序運(yùn)行效率，并進(jìn)一步調(diào)整壓縮因子。同時，性能優(yōu)化方法允許用戶探索和優(yōu)化大數(shù)據(jù)應(yīng)用。下圖為測試方法框架：

分布式I/O基準(zhǔn)測試工具

決策服務(wù)通過 REST API 將應(yīng)用類型和復(fù)雜度發(fā)送給服務(wù)交易模塊，以選擇最優(yōu)配置。在模擬模塊中研究和實(shí)現(xiàn)了幾個 MapReduce 類型的基準(zhǔn)、工具和應(yīng)用程序。作為分布式 I/O 基準(zhǔn)測試工具，TestDFSIO 基準(zhǔn)測試用于對 HDFS 進(jìn)行壓力測試并確定集群 I/O 速度。 TestDFSIO 對于識別網(wǎng)絡(luò)瓶頸和強(qiáng)調(diào)集群節(jié)點(diǎn)上的硬件、操作系統(tǒng)和 Spark/Hadoop 配置也是必不可少的。 TestDFSIO 10 使用單獨(dú)的 Map 任務(wù)(或 Spark 作業(yè))執(zhí)行并行讀取和寫入批量數(shù)據(jù)。在 Reduce 任務(wù)中收集統(tǒng)計信息以獲取 HDFS 吞吐量和平均 I/O 的摘要。

下表為TestDFSIO 選項摘要：

其他測試應(yīng)用程序介紹

大量的 MapReduce 應(yīng)用程序可以用于測試 HDFS 和 MapReduce 兩層。

Terasort 包用于檢查 HDFS 和 MapReduce 層，包括用于生成數(shù)據(jù)的 TeraGen、用于排序數(shù)據(jù)的 Terasort 和用于驗證數(shù)據(jù)排序的 TeraValidate。 TeraGen 旨在生成大量數(shù)據(jù)，這是 TeraSort 的輸入。生成數(shù)據(jù)的大小和輸出是輸入?yún)?shù)。 Terasort 對 TeraGen 生成的數(shù)據(jù)進(jìn)行排序。 TeraValidate 檢查排序后的 TeraSort 輸出。輸入和輸出路徑是 TeraSort 和 TeraValidate 基準(zhǔn)參數(shù)。

WordCount 工作負(fù)載讀取文本文件并計算找到單詞的頻率。 LogAnalyzer 工作負(fù)載讀取日志文件作為輸入，檢測與輸入的正則表達(dá)式匹配的行，并輸出一個報告，通知關(guān)鍵字是否存在以及是否存在多少次。

測試用算法

聚類數(shù)據(jù)分析技術(shù)根據(jù)相似性度量將整個數(shù)據(jù)分組。 k-Means 聚類是數(shù)據(jù)科學(xué)中最簡單、強(qiáng)大和流行的無監(jiān)督機(jī)器學(xué)習(xí)算法之一 。已使用并行 k-Means MapReduce 應(yīng)用程序，允許管理大型數(shù)據(jù)集以查找對象之間的距離。

評估內(nèi)容與指標(biāo)

輸入數(shù)據(jù)使用背景部分中描述的壓縮算法進(jìn)行壓縮。在 Hadoop 和 Spark 環(huán)境指標(biāo)中評估三種類型的輸入數(shù)據(jù)、七種壓縮算法和五種工作負(fù)載(TestDFSIO、TeraSort、WordCount、LogAnalyzer、k-Means)，以研究不同工作負(fù)載的環(huán)境和壓縮算法。

如下表格給出了具體評估指標(biāo)：

實(shí)驗驗證

環(huán)境配置

使用由一個主節(jié)點(diǎn)和 16 個從節(jié)點(diǎn)組成的 Hadoop/Spark 集群進(jìn)行實(shí)驗，具有如下不同的配置：1+4、1+8 和 1+16。

集群中的每個節(jié)點(diǎn)運(yùn)行 Openstack 中間件，每個節(jié)點(diǎn)使用一個虛擬機(jī)，使用 Ubuntu 服務(wù)器 18.04 操作系統(tǒng)、3 GB 內(nèi)存和 120 GB SATA 共享硬盤。

使用 Hadoop 版本 3.2.1、Spark 版本 2.4.5、Java JDK 版本 1.8 和 HDFS 塊大小 128 MB。復(fù)制因子設(shè)置為2(默認(rèn)值為3)，方便數(shù)據(jù)節(jié)點(diǎn)的下線。每個 Apache Hadoop 和 Spark 環(huán)境的實(shí)驗總數(shù)為 240。

壓縮文件與原始文件的壓縮率分析

所有實(shí)驗均執(zhí)行 4 GB、8 GB 和 16 GB 數(shù)據(jù)工作負(fù)載。數(shù)據(jù)壓縮減少了存儲使用量。壓縮和原始文件壓縮率的分析如下圖所示。

從上圖我們可以得出具有最佳壓縮率的算法為，Gzip、Zstandard 和 Bzip2 算法，其平均值為 13-17%。 gzip 和 bzip2 的壓縮比差異約為 4%。根據(jù)基準(zhǔn)，Gzip 的執(zhí)行時間大約比 Bzip2 壓縮快 7 倍。 Lzo、Lz4 和 Snappy 算法的壓縮率低 26-27%，執(zhí)行時間比 Gzip 壓縮快約 7 倍，關(guān)于執(zhí)行時間的介紹在下一部分。

LogAnalyzer 實(shí)驗

該實(shí)驗的顯示結(jié)果為，使用 lz4 壓縮格式的 Spark，以及 8 GB 和 16 GB 數(shù)據(jù)集，對于未壓縮的輸入數(shù)據(jù)，以 15-25%和 18-28%的內(nèi)存占用為代價，改進(jìn)了 47%; 對可拆分的壓縮數(shù)據(jù)占用 20-70%的 CPU 和 18-20%的內(nèi)存;不可分割壓縮數(shù)據(jù)的 CPU 占用率為 8-10%，內(nèi)存占用率為 14-28%

無論輸入數(shù)據(jù)大小如何，使用 lz4 壓縮格式，LogAnalyzer 在 Hadoop 上的執(zhí)行時間優(yōu)化了 4.4%。 對于 Hadoop, 8節(jié)點(diǎn)和4節(jié)點(diǎn)配置的標(biāo)準(zhǔn)差為 2%，對于Spark, 8 節(jié)點(diǎn)配置的標(biāo)準(zhǔn)差為 9%，4 節(jié)點(diǎn)配置的標(biāo)準(zhǔn)差為 27%。Hadoop 集群中所有節(jié)點(diǎn)的平均 CPU 占用 率為 6-6.5%，內(nèi)存占用率為 12-16.5%。在 Spark 上，對于未壓縮的輸入數(shù)據(jù)， 平均 CPU 占用為 15-25%和 18-28%;對于可拆分的壓縮數(shù)據(jù)，平均 CPU 占用為 20-70%和 18-20%;對于不可拆分的壓縮數(shù)據(jù)，平均 CPU 占用為 8-10%和 14- 28%。在 Hadoop 上，平均資源使用幾乎是相同的。

LogAnalyzer 實(shí)驗在 16 個節(jié)點(diǎn) Hadoop 和 Spark 配置上對4GB、8GB和16GB 數(shù)據(jù)量執(zhí)行時間對比如下：

WordCount 實(shí)驗

研究 WordCount 大規(guī)模仿真應(yīng)用程序時，情況會有所不同。實(shí)驗表明，在使用 16 GB 輸入數(shù)據(jù)的情況下，壓縮編解碼器略微提高了 Hadoop 框架的執(zhí)行時間。 Lz4 和 Lzo 編解碼器在這兩種情況下都表現(xiàn)出最佳性能。在 Hadoop 中，Lz4 的性能比 Lzo 稍高，而在 Spark 上則相反(Lzo 的執(zhí)行時間較短)。8節(jié)點(diǎn)和 16節(jié)點(diǎn)配置的Hadoop執(zhí)行時間幾乎相同，但在 4 節(jié)點(diǎn)上，平均執(zhí)行時間增加了 1.4%。在 Spark 8 節(jié)點(diǎn)集群上，平均執(zhí)行時間增加了 17%，在四節(jié)點(diǎn)集群上增加了 51%。在 Hadoop 集群上，平均CPU使用率為 5.3-6.7%，內(nèi)存使用率為 12-17.3%。在輸入數(shù)據(jù)未壓縮的 Spark 集群上，CPU 使用率為 20-47%，內(nèi)存為 30-42%。對于使用不可拆分編解碼器壓縮的輸入數(shù)據(jù)，平均 CPU 使用率為 6-7%，內(nèi)存為 2030%，對于使用可拆分編解碼器壓縮的數(shù)據(jù)，CPU 為 20-50%，內(nèi)存為 30-70%。作為 Hadoop 環(huán)境中 WordCount 作業(yè)的 LogAnalyzer，平均資源使用率幾乎相同。 Wordcount 作業(yè)的最佳性能顯示為Lzo 編解碼器，比未壓縮數(shù)據(jù)快 8%，但平均多使用 12% 的 CPU 和 23% 的內(nèi)存。

16 個節(jié)點(diǎn) Hadoop 和 Spark 配置上 4 GB、8 GB 和 16 GB 數(shù)據(jù)的 WordCount 實(shí)驗性能對比如下：

TestDFSIO實(shí)驗

實(shí)驗表明，除了適用于 Hadoop 集群的 Bzip2 慢速壓縮算法外，可拆分編解碼器還提高了LogAnalyzer 和 WordCount 應(yīng)用程序的執(zhí)行時間。

Gzip 和 Snappy 不可拆分編解碼器減少了存儲大小但增加了執(zhí)行時間。

可拆分壓縮編解碼器對 Spark 環(huán)境有重大影響。壓縮編解碼器未用于 TeraGen 和 TestDFSIO 基準(zhǔn)測試，因為算法人工生成數(shù)據(jù)的。

下圖顯示了 TestDFSIO 基準(zhǔn)測試在具有 16 個節(jié)點(diǎn)配置的 Hadoop 和 Spark 環(huán)境中的執(zhí)行時間：

TeraSort實(shí)驗

在 8 個節(jié)點(diǎn)的配置下，帶有寫選項的集群基準(zhǔn)測試工作時間大致相同。 Hadoop的偏差為 2%，Spark 為 1%。讀取選項的執(zhí)行時間在 Hadoop 上增加了 82%，在Spark上增加了 31%。在四節(jié)點(diǎn)配置上，寫入在 Hadoop 上慢 4%，在Spark上慢 18%，14 用于讀取選項在兩種環(huán)境下都慢三倍。圖 6 顯示了 TeraGen、TeraSort、TeraValidate 基準(zhǔn)測試在具有 16 個節(jié)點(diǎn)配置的 Hadoop 和 Spark 環(huán)境中的執(zhí)行時間。 TeraGen 和 TeraValidate 在 Hadoop 上工作得更快，在 Spark 上工作得更快。與Hadoop 相比，Spark 的基準(zhǔn)測試模擬時間平均縮短了 12%。在八節(jié)點(diǎn) Hadoop 和Spark集群上，TeraGen 和 TeraSort 的結(jié)果幾乎相同，只有 2% 的差異，但對于 TeraValidate，在Hadoop上的基準(zhǔn)執(zhí)行時間增加了 20%，在 Spark 上增加了 50%。在四個節(jié)點(diǎn)上，與 16 個節(jié)點(diǎn)配置相比，Hadoop 集群 TeraGen 平均快 13%，Terasort 3%，Teravalidate 慢 43%。在四個節(jié)點(diǎn)上，Spark 集群 TeraGen 快 7%，TeraSort 慢 4%，Teravalidate 慢 72%。在這兩種環(huán)境中，平均 CPU 使用率為 5-7%，在 Hadoop 上內(nèi)存為 12-14%，在 Spark 上為 15-16%。

16 個節(jié)點(diǎn) Hadoop/Spark 上4GB、8GB 和16GB數(shù)據(jù)的TeraSort基準(zhǔn)執(zhí)行時間如下圖：

k-means實(shí)驗

在 k-Means 聚類應(yīng)用程序中，1GB、2GB、4GB輸入數(shù)據(jù)大小用于實(shí)驗。根據(jù)下圖，Gzip、Snappy 和 Zstandart 編解碼器表現(xiàn)出與輸入未壓縮時幾乎具有相同的性能。

16 個節(jié)點(diǎn)Hadoop/Spark上1GB、2GB和4GB數(shù)據(jù)的K-means基準(zhǔn)執(zhí)行時間如該圖：

Spark 集群案例中的場景完全不同，因為除了Bzip2之外的可拆分編解碼器顯示出比未壓縮數(shù)據(jù)更好的性能。通過具有大約 93% 的壓縮比，使用 Lz4 編解碼器可以達(dá)到最佳性能。而不是Hadoop(偏差為 1%)，在 Spark 的四節(jié)點(diǎn)和八節(jié)點(diǎn)配置上，執(zhí)行時間平均增加了 30% 和 93%。在Hadoop上，最佳性能顯示 Zstandard 編解碼器比未壓縮數(shù)據(jù)快 6.4%。在Hadoop k-Means集群上，與 LogAnalyzer 和WordCount相比，平均資源使用率幾乎相同。平均 CPU 使用率為 6-7%，而內(nèi)存使用率為 16-18%。 Spark上性能最差的是Gzip、Zstandard和Snappy 編解碼器，它們平均使用6-8% 的 CPU 和 30-48% 的內(nèi)存。如果k-Means輸入數(shù)據(jù)未壓縮，則平均CPU使用率為 37-50%，而內(nèi)存為 30-44%。在其他編解碼器的情況下，平均CPU使用率為 11-56%，而內(nèi)存為 26-44%。Spark 集群上的最佳性能顯示 lz4，平均比未壓縮的輸入數(shù)據(jù)快 8.8%，但平均多使用 3% 的 CPU 和 1% 的內(nèi)存。

內(nèi)存和處理器使用情況的統(tǒng)計

內(nèi)存和處理器使用情況的統(tǒng)計分析如下表所示，以呈現(xiàn)數(shù)據(jù)的特征并研究分散性。在兩種框架下 TestDFSIO 和 TeraSort 結(jié)果SD較小，結(jié)果可靠性高，但 LogAnalyzer、WordCount 和 k-Means 的數(shù)據(jù)和統(tǒng)計平均值之間存在較為明顯的差異。

對五種工作負(fù)載的內(nèi)存和處理器使用情況的均值和SD(標(biāo)準(zhǔn)差)分析如該表：

總結(jié)與最優(yōu)解

本文的目的是為了能夠找到最佳權(quán)衡以在 Apache Hadoop 和 Spark 框架中達(dá)到最佳性能的系統(tǒng)。上述文章在 Hadoop 和 Spark 環(huán)境中評估了適用于不同應(yīng)用程序(包括 TestDFSIO、TeraSort、WordCount、LogAnalyzer 和 K-means)的4GB、8GB和16GB 數(shù)據(jù)工作負(fù)載。建議的系統(tǒng)使用評估結(jié)果來選擇最佳配置環(huán)境。

我們由壓縮數(shù)據(jù)處理分析結(jié)果可得：

無論輸入數(shù)據(jù)大小如何，Lz4 編解碼器都能達(dá)到 Hadoop 的最佳性能。

Spark 使用 Lz4 僅能在 4Gb 的輸入數(shù)據(jù)下獲得最佳性能，使用 Zstandard 編解碼器僅能在 8Gb 和 16Gb 的情況下可以獲得最佳性能。

??想了解更多關(guān)于開源的內(nèi)容，請訪問：??

??51CTO 開源基礎(chǔ)軟件社區(qū)??

??https://ost.51cto.com??。