OpenHarmony啃論文俱樂部—大數據框架性能優化系統
【本期看點】
- Hadoop和Spark框架的性能優化系統。
- 云計算重復數據刪除技術降低冗余度。
- 壓縮框架Ares如何統一不同算法。
- 在線數據壓縮“搖擺門趨勢”。
- 揭秘新型移動云存儲SDM。
【技術DNA】
【智慧場景】
背景介紹
大數據概念
大數據(Big Data)，又稱為巨量資料，指的是所涉及的資料量規模巨大到無法透過主流軟件工具，在合理的時間內達到擷取、管理、處理、并整理成為幫助企業經營決策更積極目的的資訊。
但大數據是個抽象的概念，業界對大數據還沒有一個統一的定義，而且用上面的定義似乎難以理解，所以就有了以下用 “4V” 來定義大數據的方法。
大數據特征
說到大數據的特征，就不得不提到“4V”。那什么是“4V”呢?
“4V” 即四個用來描述大數據特征的英文單詞：Volume(體積)、Velocity(速度)、Variety(多樣) 和 Value(價值)。用“4V”的方式給大數據下個中文定義，那就是滿足數據體量巨大、數據速度快速、數據種類繁多和數據價值密度低的數據即大數據。
每天大家都在使用微信、QQ與好友開黑聊天，用支付寶、淘寶完成線上下支付。時過境遷，目前互聯網產生的數據已經遠遠地超過很多年前的“3G時代”。比如下圖，生動形象地描述了2021年各大互聯網公司每分鐘所產生的數據。
像是 Tiktok 每分鐘就產生了5000次下載，197.6 百萬條電子郵件被發出，500 個小時的視頻被上傳。雖然不是國內的數據，但也能反映出國內的一些情況，更能讓我們體會到大數據時代下的數據量之大，數據種類之繁雜。側面也能反映出處理這些數據的困難。
問題解決
那么大數據是怎樣一步步發展到今天的呢?在回答這個問題之前，我們先來介紹一下兩個由著名的 Apache 基金會開源出來的非常重要的項目 Apache Spark 和 Apache Hadoop。
Apache Hadoop 介紹
Apache Hadoop 是一個開源的，可靠的，可擴展的分布式計算框架，是下面這位大佬 Doug Cutting 發明的。這個項目的名稱以及Logo來源也很有趣，就是大佬手中拿著的玩具的名字，對比一下 Apache Hadoop 的 Logo，是不是感覺有異曲同工之處?
Apache Hadoop 能做些什么呢?搭建大型的數據倉庫以及PB級別的數據的存儲、處理、分析、統計等業務，這些 Hadoop 都不在話下。而且，在搜索引擎時代，數據倉庫時代、數據挖掘時代以及如今的機器學習時代，Hadoop 都分別擔當著重要的作用。
Apache Spark 介紹
Apache Spark是加州大學伯克利分校AMP實驗室(Algorithms, Machines, and People Lab)開發的通用內存并行計算框架。具有運行速度快、易用性好、通用性強以及隨處運行的特點。
Apache Spark 支持使用內存中處理來提升大數據分析應用程序的性能。 大數據解決方案旨在處理對傳統數據庫來說太大或太復雜的數據，而使用Spark處理內存中的大量數據，會比基于磁盤的替代方法要快得多。
兩者的聯系
Apache Hadoop 提供分布式數據存儲功能HDFS，還提供了用于數據處理的 MapReduce。雖然 MapReduce 是可以不依靠 Apache Spark 進行數據的處理，Apache Spark 也可以不依靠 HDFS 來完成數據存儲功能，但如果兩者結合在一起，讓 Apache Hadoop 來提供分布式集群和分布式 文件系統，Apache Spark 可以依附 HDFS 來代替 MapReduce 去彌補 MapReduce 計算能力不足的問題。
或許，有了上面的兩個框架，處理如今的大數據時代所產生的問題已經很完美了，但是看一看下圖對全球數據量以及其增速的預測，就能感覺到終有一天，現有的技術不能再滿足我們，我們的技術仍然需要精進。
如何精進
從Hadoop源頭
此時，或許我們應該了解一下 Apache Hadoop 的來源。Apache Hadoop 最早起源于Nutch。Nutch 的設計目標是構建一個大型的全網搜索引擎，包括網頁抓取、索引、查詢等功能，但隨著抓取網頁數量的增加，遇到了嚴重的可擴展性問題——如何解決數十億網頁的存儲和索引問題。
2003~2014 年 Google 發表的三篇論文為這個問題帶來了解決的方案。三篇論文中分別提到了三個至關重要的技術點 GFS，MapReduce 以及 BigTable。最終分別演變成了 Hadoop 生態中的 HDFS，Hadoop MapReduce 以及 HBase。
- GFS：Google File System，Google的分布式文件系統。
- MapReduce：Google的分布式計算模型，用于解決PageRank問題。
- BigTable：列式存儲Hbse的理論基礎。
而其中的 Hadoop MapReduce 就是 Apache Hadoop 中重要的組成部分之一，它是數據中心的一個重要的數據處理引擎，它可以幫助用戶避免維護物理基礎設施的成本。許多研究都集中在 MapReduce 的任務上，來提高數據中心的性能并將能源的消耗大幅降低。這期閱讀的論文也是研究了與 MapReduce 相關的數據壓縮。
從數據壓縮入手
數據壓縮算法的權衡取決于各種因素，比如壓縮程度、數據質量、壓縮算法類型或者數據類型。最終的數據大小或是 I/O 減少的程度取決于壓縮比，而壓縮比取決于數據和壓縮算法。這意味著更低的比率將會減少內存以及I/O的使用。
從Hadoop特性
下面是 Hadoop 中可用的壓縮格式的摘要:
由于數據需要被安全的存儲，所以作者選擇的上表中所有選擇的壓縮編碼器以及解碼器都是無損的。
gzip 和 deflate 編解碼器都使用 deflate 算法來替代 lz77 和 Huffman 編碼的組合。兩者的區別在于 Huffman 編碼階段
可拆分壓縮 bzip2 編解碼器使用 Burrows-Wheeler(塊排序)文本壓縮和 Huffman 編碼算法。Bzip2 可以獨立壓縮數據塊，也可以并行壓縮數據塊。
Snappy 是一個快速的數據壓縮和解壓縮庫，使用了 lz77 的思想。Snappy 塊是不可分割的，但是 Snappy 塊中的文件是可分割的。
lzo (Lempel- Ziv-Oberhumer)壓縮算法是 lz77 壓縮算法的變體。該算法分為查找匹配，寫入未匹配的文字數據，確定匹配的長度，以及寫入匹配令牌部分。
壓縮的數據文件由 lz4 序列組成，該序列包含一個標記、文字長度、偏移量和匹配長度。
Zstandart 是 Facebook 開發的一種基于 lz77 的算法，支持字典、大規模搜索框和使用有限狀態熵和霍夫曼編碼的熵編碼步驟。
Hadoop 支持的壓縮格式太多，因此需要一種可以動態選擇壓縮方式的算法，根據數據類型對壓縮格式進行選擇。
相關工作
- 關于 I/O 性能。作者分析了幾篇論文，找到提升 I/O 性能并能提高能源效率的方法。
- 首先作者閱讀量三篇論文，該論文中的作者將 4 個計算機節點集群，來研究部分數據壓縮對 MapReduce 小工作量的情況下對性能的提高以及對能源的利用情況。
- 其次該論文中的作者從已有的幾種方法和壓縮算法來確定壓縮方法，以減少數據加載時間和提高并發性。
- 最后，該論文中的作者研究了兩種可動態選擇的算法，通過周期性的壓縮算法特征分析和實時系統資源狀態的監控來實現最佳的 I/O 性能。
- 關于能源效率。作者選取了幾篇論文，分析了不同的能源模型來預測 MapReduce 作業時的能源消耗。
- 通過調整數據復制系數和數據塊大小參數，最小化了作業的執行時間和能耗。
- 其次，作者通過另一篇論文的一個預測 MapReduce 工作負載能耗的線性回歸模型，發現了了通過精確的資源分配和只能的動態電壓和頻率縮放調度，可以顯著節省能源。
- 還有，作者了解了修改 Hadoop 以實現可操作集群規?？s減方面的早期工作。
- 最后，作者閱讀了一篇調整HPC集群并行度，網絡帶寬以及電源管理功能的策略，來達到高效執行 MapReduce 的目的。
- 作者最終通過修改Hadoop/Spark 框架中關于能源效率的各種配置參數，以達到提升 Hadoop MapReduce 作業的性能的目的。論文旨在提出一個選擇最佳壓縮工具并調整壓縮因子以達到最佳性能的系統。
測試方法
方法框架
研究人員通過研究節省 CPU 和節省 I/O 之間的權衡，以此評估使用基于壓縮工具的 Hadoop 和 Spark 框架下的大數據應用程序運行效率，并進一步調整壓縮因子。同時，性能優化方法允許用戶探索和優化大數據應用。下圖為測試方法框架：
分布式I/O基準測試工具
決策服務通過 REST API 將應用類型和復雜度發送給服務交易模塊，以選擇最優配置。在模擬模塊中研究和實現了幾個 MapReduce 類型的基準、工具和應用程序。作為分布式 I/O 基準測試工具，TestDFSIO 基準測試用于對 HDFS 進行壓力測試并確定集群 I/O 速度。 TestDFSIO 對于識別網絡瓶頸和強調集群節點上的硬件、操作系統和 Spark/Hadoop 配置也是必不可少的。 TestDFSIO 10 使用單獨的 Map 任務(或 Spark 作業)執行并行讀取和寫入批量數據。在 Reduce 任務中收集統計信息以獲取 HDFS 吞吐量和平均 I/O 的摘要。
下表為TestDFSIO 選項摘要：
其他測試應用程序介紹
大量的 MapReduce 應用程序可以用于測試 HDFS 和 MapReduce 兩層。
Terasort 包用于檢查 HDFS 和 MapReduce 層，包括用于生成數據的 TeraGen、用于排序數據的 Terasort 和用于驗證數據排序的 TeraValidate。 TeraGen 旨在生成大量數據，這是 TeraSort 的輸入。生成數據的大小和輸出是輸入參數。 Terasort 對 TeraGen 生成的數據進行排序。 TeraValidate 檢查排序后的 TeraSort 輸出。輸入和輸出路徑是 TeraSort 和 TeraValidate 基準參數。
WordCount 工作負載讀取文本文件并計算找到單詞的頻率。 LogAnalyzer 工作負載讀取日志文件作為輸入，檢測與輸入的正則表達式匹配的行，并輸出一個報告，通知關鍵字是否存在以及是否存在多少次。
測試用算法
聚類數據分析技術根據相似性度量將整個數據分組。 k-Means 聚類是數據科學中最簡單、強大和流行的無監督機器學習算法之一 。已使用并行 k-Means MapReduce 應用程序，允許管理大型數據集以查找對象之間的距離。
評估內容與指標
輸入數據使用背景部分中描述的壓縮算法進行壓縮。在 Hadoop 和 Spark 環境指標中評估三種類型的輸入數據、七種壓縮算法和五種工作負載(TestDFSIO、TeraSort、WordCount、LogAnalyzer、k-Means)，以研究不同工作負載的環境和壓縮算法。
如下表格給出了具體評估指標：
實驗驗證
環境配置
使用由一個主節點和 16 個從節點組成的 Hadoop/Spark 集群進行實驗，具有如下不同的配置：1+4、1+8 和 1+16。
集群中的每個節點運行 Openstack 中間件，每個節點使用一個虛擬機，使用 Ubuntu 服務器 18.04 操作系統、3 GB 內存和 120 GB SATA 共享硬盤。
使用 Hadoop 版本 3.2.1、Spark 版本 2.4.5、Java JDK 版本 1.8 和 HDFS 塊大小 128 MB。復制因子設置為2(默認值為3)，方便數據節點的下線。每個 Apache Hadoop 和 Spark 環境的實驗總數為 240。
壓縮文件與原始文件的壓縮率分析
所有實驗均執行 4 GB、8 GB 和 16 GB 數據工作負載。數據壓縮減少了存儲使用量。壓縮和原始文件壓縮率的分析如下圖所示。
從上圖我們可以得出具有最佳壓縮率的算法為，Gzip、Zstandard 和 Bzip2 算法，其平均值為 13-17%。 gzip 和 bzip2 的壓縮比差異約為 4%。根據基準，Gzip 的執行時間大約比 Bzip2 壓縮快 7 倍。 Lzo、Lz4 和 Snappy 算法的壓縮率低 26-27%，執行時間比 Gzip 壓縮快約 7 倍，關于執行時間的介紹在下一部分。
LogAnalyzer 實驗
該實驗的顯示結果為，使用 lz4 壓縮格式的 Spark，以及 8 GB 和 16 GB 數據集，對于未壓縮的輸入數據，以 15-25%和 18-28%的內存占用為代價，改進了 47%; 對可拆分的壓縮數據占用 20-70%的 CPU 和 18-20%的內存;不可分割壓縮數據的 CPU 占用率為 8-10%，內存占用率為 14-28%
無論輸入數據大小如何，使用 lz4 壓縮格式，LogAnalyzer 在 Hadoop 上的執行時間優化了 4.4%。 對于 Hadoop, 8節點和4節點配置的標準差為 2%，對于Spark, 8 節點配置的標準差為 9%，4 節點配置的標準差為 27%。Hadoop 集群中所有節點的平均 CPU 占用 率為 6-6.5%，內存占用率為 12-16.5%。在 Spark 上，對于未壓縮的輸入數據， 平均 CPU 占用為 15-25%和 18-28%;對于可拆分的壓縮數據，平均 CPU 占用為 20-70%和 18-20%;對于不可拆分的壓縮數據，平均 CPU 占用為 8-10%和 14- 28%。在 Hadoop 上，平均資源使用幾乎是相同的。
LogAnalyzer 實驗在 16 個節點 Hadoop 和 Spark 配置上對4GB、8GB和16GB 數據量執行時間對比如下：
WordCount 實驗
研究 WordCount 大規模仿真應用程序時，情況會有所不同。實驗表明，在使用 16 GB 輸入數據的情況下，壓縮編解碼器略微提高了 Hadoop 框架的執行時間。 Lz4 和 Lzo 編解碼器在這兩種情況下都表現出最佳性能。在 Hadoop 中，Lz4 的性能比 Lzo 稍高，而在 Spark 上則相反(Lzo 的執行時間較短)。8節點和 16節點配置的Hadoop執行時間幾乎相同，但在 4 節點上，平均執行時間增加了 1.4%。在 Spark 8 節點集群上，平均執行時間增加了 17%，在四節點集群上增加了 51%。在 Hadoop 集群上，平均CPU使用率為 5.3-6.7%，內存使用率為 12-17.3%。在輸入數據未壓縮的 Spark 集群上，CPU 使用率為 20-47%，內存為 30-42%。對于使用不可拆分編解碼器壓縮的輸入數據，平均 CPU 使用率為 6-7%，內存為 2030%，對于使用可拆分編解碼器壓縮的數據，CPU 為 20-50%，內存為 30-70%。作為 Hadoop 環境中 WordCount 作業的 LogAnalyzer，平均資源使用率幾乎相同。 Wordcount 作業的最佳性能顯示為Lzo 編解碼器，比未壓縮數據快 8%，但平均多使用 12% 的 CPU 和 23% 的內存。
16 個節點 Hadoop 和 Spark 配置上 4 GB、8 GB 和 16 GB 數據的 WordCount 實驗性能對比如下：
TestDFSIO實驗
實驗表明，除了適用于 Hadoop 集群的 Bzip2 慢速壓縮算法外，可拆分編解碼器還提高了LogAnalyzer 和 WordCount 應用程序的執行時間。
Gzip 和 Snappy 不可拆分編解碼器減少了存儲大小但增加了執行時間。
可拆分壓縮編解碼器對 Spark 環境有重大影響。壓縮編解碼器未用于 TeraGen 和 TestDFSIO 基準測試，因為算法人工生成數據的。
下圖顯示了 TestDFSIO 基準測試在具有 16 個節點配置的 Hadoop 和 Spark 環境中的執行時間：
TeraSort實驗
在 8 個節點的配置下，帶有寫選項的集群基準測試工作時間大致相同。 Hadoop的偏差為 2%，Spark 為 1%。讀取選項的執行時間在 Hadoop 上增加了 82%，在Spark上增加了 31%。在四節點配置上，寫入在 Hadoop 上慢 4%，在Spark上慢 18%，14 用于讀取選項在兩種環境下都慢三倍。圖 6 顯示了 TeraGen、TeraSort、TeraValidate 基準測試在具有 16 個節點配置的 Hadoop 和 Spark 環境中的執行時間。 TeraGen 和 TeraValidate 在 Hadoop 上工作得更快，在 Spark 上工作得更快。與Hadoop 相比，Spark 的基準測試模擬時間平均縮短了 12%。在八節點 Hadoop 和Spark集群上，TeraGen 和 TeraSort 的結果幾乎相同，只有 2% 的差異，但對于 TeraValidate，在Hadoop上的基準執行時間增加了 20%，在 Spark 上增加了 50%。在四個節點上，與 16 個節點配置相比，Hadoop 集群 TeraGen 平均快 13%，Terasort 3%，Teravalidate 慢 43%。在四個節點上，Spark 集群 TeraGen 快 7%，TeraSort 慢 4%，Teravalidate 慢 72%。在這兩種環境中，平均 CPU 使用率為 5-7%，在 Hadoop 上內存為 12-14%，在 Spark 上為 15-16%。
16 個節點 Hadoop/Spark 上4GB、8GB 和16GB數據的TeraSort基準執行時間如下圖：
k-means實驗
在 k-Means 聚類應用程序中，1GB、2GB、4GB輸入數據大小用于實驗。根據下圖，Gzip、Snappy 和 Zstandart 編解碼器表現出與輸入未壓縮時幾乎具有相同的性能。
16 個節點Hadoop/Spark上1GB、2GB和4GB數據的K-means基準執行時間如該圖：
Spark 集群案例中的場景完全不同，因為除了Bzip2之外的可拆分編解碼器顯示出比未壓縮數據更好的性能。通過具有大約 93% 的壓縮比，使用 Lz4 編解碼器可以達到最佳性能。而不是Hadoop(偏差為 1%)，在 Spark 的四節點和八節點配置上，執行時間平均增加了 30% 和 93%。在Hadoop上，最佳性能顯示 Zstandard 編解碼器比未壓縮數據快 6.4%。在Hadoop k-Means集群上，與 LogAnalyzer 和WordCount相比，平均資源使用率幾乎相同。平均 CPU 使用率為 6-7%，而內存使用率為 16-18%。 Spark上性能最差的是Gzip、Zstandard和Snappy 編解碼器，它們平均使用6-8% 的 CPU 和 30-48% 的內存。如果k-Means輸入數據未壓縮，則平均CPU使用率為 37-50%，而內存為 30-44%。在其他編解碼器的情況下，平均CPU使用率為 11-56%，而內存為 26-44%。Spark 集群上的最佳性能顯示 lz4，平均比未壓縮的輸入數據快 8.8%，但平均多使用 3% 的 CPU 和 1% 的內存。
內存和處理器使用情況的統計
內存和處理器使用情況的統計分析如下表所示，以呈現數據的特征并研究分散性。在兩種框架下 TestDFSIO 和 TeraSort 結果SD較小，結果可靠性高，但 LogAnalyzer、WordCount 和 k-Means 的數據和統計平均值之間存在較為明顯的差異。
對五種工作負載的內存和處理器使用情況的均值和SD(標準差)分析如該表：
總結與最優解
本文的目的是為了能夠找到最佳權衡以在 Apache Hadoop 和 Spark 框架中達到最佳性能的系統。上述文章在 Hadoop 和 Spark 環境中評估了適用于不同應用程序(包括 TestDFSIO、TeraSort、WordCount、LogAnalyzer 和 K-means)的4GB、8GB和16GB 數據工作負載。建議的系統使用評估結果來選擇最佳配置環境。
我們由壓縮數據處理分析結果可得：
無論輸入數據大小如何，Lz4 編解碼器都能達到 Hadoop 的最佳性能。
Spark 使用 Lz4 僅能在 4Gb 的輸入數據下獲得最佳性能，使用 Zstandard 編解碼器僅能在 8Gb 和 16Gb 的情況下可以獲得最佳性能。
