文章轉發自51CTO【ELT.ZIP】OpenHarmony啃論文俱樂部——《云計算數據壓縮方案》

1.技術DNA

2. 智慧場景

3.前言概覽

近年來，相機、衛星、地震監測等傳感設備產生了大量的流數據。云計算技術使這些流數據的存儲、訪問和管理變得更加容易，也降低了成本。其中，云存儲系統成為在各種云服務器上存儲數據塊的一種有前途的技術，其主要機制之一是數據復制。數據復制的目標是解決云存儲的可用性、可靠性、安全性、帶寬和數據訪問的響應時間，從而使數據密集型項目能夠實現更優越的性能。然而，既然復制，就免不了會產生過多的重復副本造成資源浪費。因此，便產生了一種通過移除重復副本來減小云存儲系統中數據占用的大小，實現數據壓縮、避免資源浪費的重復數據刪除技術。

以一種典型的傳統分類方式來看，可以將此重復數據刪除技術分為delta-based和hash-based兩類。本著相同的目標，前者基于相似性的消除，后者基于加密函數而發揮作用。

而在另一種分類方式中，可以將此重復數據刪除技術分為基于服務器和基于客戶端兩類。前者中，消除冗余數據的操作是在服務器接收到數據后完成的，而后者則在發送數據之前就先在客戶端檢查數據的重復性。

后文將對以上內容一一解析，不過開始之前，我們還是先了解一些云計算的周邊內容。

4.云計算

4.1 云計算產生背景

云存儲數字數據量的不斷增加 ，需要更多的存儲空間，高效的技術 ，處理這些數據。

那么何為云計算？是如上圖一般把網線接到云彩上進行計算嗎？當然不是，這是一種形象的比喻，云計算提供了一種新的互聯網技術方式，利用互聯網和中央遠程服務器管理資源和應用程序。許多最終用戶以最低的成本使用這一創新，并且無需安裝就可以訪問應用程序。

4.2 公有云和私有云

云計算可以是公共云或是私有云。公共云平臺(例如AWS和Microsoft Azure)將資源集中在分布在全球各地的數據中心，用戶可以通過公共互聯網訪問它們。這些資源通過計量服務提供給客戶，云計算供應商負責不同程度的后端維護。

私有云被托管在企業數據中心或托管數據中心設施中。雖然其功能不如大規模的公共云。但它們確實有一定的彈性，企業的開發人員和管理人員仍然可以使用自助服務門戶訪問資源。從理論上來說，私有云提供了更好的控制和安全性，但這需要企業的IT團隊的努力。

云計算部署模型包括私有云、公共云、兩者的混合，以及多個云平臺的組合。也可以將公共云和私有云鏈接以創建混合云，或者可以將兩個或多個公共云連接以創建多云架構。

4.3 云計算主要優點

• 可容錯

• 處理速度快

• 存儲容量大

• 帶寬寬

• 允許使用 Internet 訪問遠程信息和文件

• 大規模數據分析和數據挖掘

• 物聯網等物物互聯的場景運用

4.4云計算存在問題

云服務中最重要、最典型的是信息存儲服務。數據的安全性、個人數據的隱私性保護、數據訪問的權限管理、數據的容災備份、數據拜訪的實時性會受網絡穩定性影響。以及如何降低冗余數據、減少存儲成本。

4.5常見的云存儲供應商

亞馬遜、微軟、谷歌和阿里巴巴四大云服務廠商，占據了全球七成以上市場份額。緊隨四大市場領導者后面的有IBM、Salesforce、騰訊、Oracle和一大批市場份額較小的公司。而亞馬遜在全球公有云服務市場中的領導地位主要是由于其市場份額第一緣故。

4.6云計算與大數據

云計算和大數據是近六七年來大熱的兩個概念，很多時候，二者都是被綁定在一起談論的。

大數據就是通過搜集海量的數據對其進行分析和處理，發現隱藏在這些數據背后的潛在聯系，洞察內在過程，進而使這些數據轉化或推導出具有更多價值的信息，最終為用戶的決策提供幫助。放到日常工作生活中的典型表現就是“喜歡看什么，就會推什么”：當我們刷一些娛樂類或者新聞類的app時，看到感興趣的內容就免不了會駐足多停留一段時間，可能還會直接去搜相關的話題，這時大數據就已經完成了標記、為你的ID打上了相應的標簽。基于內容相關性的頻次或后臺的定位信息等，標簽也會不盡相同。盡管覺得自己凈如白紙，但在平臺的全閉環下，大數據總是能精確地捕捉并震撼到我們。

4.7云計算的技術

云計算本質上是分布式計算的一種，通過對任務的分發，實現多端并行計算，最終再進行計算結果的合并。它提供了計算資源的虛擬化池，存儲、應用、內存、處理能力和服務都是在用戶需要時可以用來請求這些資源的實例。其中，云服務通常分為平臺即服務（PaaS）、軟件即服務（SaaS）和基礎設施即服務（IaaS）三種模式，三者的主要區別就是提供服務的方式不同，需要用戶根據實際需要進行選擇匹配。此外，基于云計算的思路，還衍生出了霧計算、邊緣計算、移動邊緣計算（MEC）和移動云計算（MCC）。

5.云存儲

云存儲是一種有用的移動邊緣計算(M E C)設備，其特點是存儲空間有限。這些數據或日志數據可以在需要時被存儲和訪問到云存儲服務中。為了提高M E C設備上的云存儲服務體驗，可以將多個云存儲服務合并成一個統一的云存儲在云存儲中，在處理大量數據時，無法避免重復。盡管云存儲空間巨大，這種復制極大地浪費了網絡資源，消耗了大量電能，并使數據管理變得復雜。重復數據刪除可以節省大量空間和成本，備份應用可以減少高達 90-95%的存儲需求，標準文件系統可以減少高達 68%的存儲需求。數據重復刪除和數據壓縮是在云中優化存儲的可用技術中使用的最突出的技術。

5.1 重復數據刪除技術

隨機復制作為一種流行的復制方案，已廣泛用于云存儲系統，如Hadoop分布式文件系統（HDFS）、RAMCloud、Google文件系統（GFS）和微軟Azure等，使用隨機復制從不同機房隨機選擇的三臺服務器中復制數據，從而防止單個集群中的數據丟失。然而，三方隨機復制不能很好地應對機器故障，若三個節點的隨機組合同時出現錯誤，就會造成數據丟失。

為了解決以上問題，便提出了Copyset復制和分層復制兩種方案。但又出現了新的問題：它們都沒有試圖降低由于復制而造成的存儲成本和帶寬成本。盡管后續又提出了更多相關的復制方案，但仍然存在著同樣的問題。

于是，有學者設計了一種叫做流行感知的多故障彈性和經濟有效的復制方案（PMCR）的方案。它比之前的復制方案都有優勢，且同時具有以下特點：

• 可以處理相關或不相關的機器故障

• 壓縮那些很少使用的冷門數據的副本

• 降低了存儲和帶寬成本

• 不會顯著影響數據持久性、數據可用性和數據請求的延遲

5.1.1 SC、DC壓縮

由于PMCR方案的操作是一整套流程，我們在此只關注其中壓縮數據降低冗余度的部分。

SC全稱Similarity Compression，是依據數據相似性壓縮的一種方法；DC全稱Delta Compression，意即增量壓縮。PMCR使用SC壓縮讀密集型數據，使用DC壓縮寫密集型數據。SC刪除文件或文件中相似的塊，文件請求用戶在接收到壓縮文件后，可再恢復已刪除的數據塊；DC存儲文件的副本和與此文件相似的其他文件的不同部分，以上將會被傳輸給文件請求用戶。而當文件更新時，只需將更新后的部分同步到副本節點即可。

5.1.1.1相似性壓縮（SC）

進行SC時，相似的塊被分組在一起，一定數量相似的小塊形成一個大塊。然后，刪除重復的塊或接近重復的塊到一個塊。在PMCR中，當壓縮讀密集型數據時，對于每一組相似的塊，只需存儲第一個塊即可，剩下的冗余塊可刪除；對于不同數據對象之間的冗余塊，也可消除，方式大體分為文件內壓縮和文件間壓縮：

5.1.1.2增量壓縮（DC）

如圖，B塊和B’塊都是相似的塊，它們之間的差異用橙色標記出，此時，便可用DC存儲橙色區域。當塊B或塊B’被更新時，只需將更新的部分而非整個塊發送到復制服務器即可，然后，副本服務器再更新相應的部分。要將數據發送給用戶，只需傳輸存儲的不同部分和B塊的完整部分。

5.1.2DSHA算法

現有系統使用（任何類型的）加密散列算法(如 MD5 或 Secure 散列算法)，生成散列值，重復數據刪除這些算法產生固定長度的 128 位或 160 位分別作為輸出以識別復制的存在。同時用一個額外的內存空間存儲哈希值。

本文提出了一種高效的分布式存儲哈希算法(Distributed Storage Hash Algorithm, DSHA)，以減少用于識別和丟棄冗余數據的哈希值所占用的內存空間。

結論：實驗分析表明，該策略降低了哈希值的內存利用率，提高了數據讀寫性能。

5.2SDM技術

SDM是一種針對移動設備的智能重復數據刪除系統，提高了云存儲作為移動設備上的存儲解決方案的可行性。SDM旨在利用多核技術 在現代移動處理器上的架構。為了減少重復數據刪除過程的時間，針對每種文件類型的最佳重復數據刪除方法，而不依賴于針對每種文件類型的任何配置。由于其設計，學習系統不存在散列不兼容性。

5.2.1移動設備和云存儲服務的固有限制

• 移動設備的性能限制 移動設備的處理功率和電源受到限制。

• 有限的存儲容量 由于其外形因素，也很難在移動設備中安裝高容量的存儲空間。云存儲供應商提供的免費存儲容量 往往很小，升級需支付額外費用。

• 網絡帶寬 網絡帶寬對于訪問云存儲至關重要。遺憾的是，網絡帶寬通常被限制在免費存儲上，云存儲服務的帶寬是在活動用戶的數量之間劃分的，會導致更長的訪問時間，在大多數在某些情況下，這將導致云存儲服務的性能低于客戶的網絡性能。

• 價格昂貴的無線網絡收費

• 有限網絡覆蓋范圍 網絡覆蓋對移動用戶來說可能是一個問題。當用戶超出網絡覆蓋范圍時，所有的網絡活動都將是已停止，這意味著沒有云存儲服務。

5.2.2系統架構

我們建議使用智能重復數據刪除技術進行移動云存儲(SDM)。SDM在文件級和塊級使用多級重復數據刪除方法，這些方法由學習系統集成（學習系統選擇最佳的重復數據消除 方法來實現最佳的數據減少和能量消耗。此外，我們還使用哈希表和一個bloom過濾器來進行本地搜索并添加并行化來提高應用程序的性能。整個系統如圖所示。整個過程是可逆的，因為重復數據刪除是一個無損壓縮的操作。

文件級重復數據刪除 在文件級別上，重復數據刪除可以通過比較整個文件來進行操作。由于它只將一個哈希值與另一個文件哈希值進行比較，因此該進程比其他方法更快。但是，當文件的一部分發生更改時，整個哈希值也會發生更改。這就降低了文件級重復數據刪除的性能。

塊級重復數據刪除 當在塊級別執行重復數據刪除時，處理的文件被分割為多個塊。每個塊的處理與文件級重復數據刪除中的文件相同。塊的大小可以是固定大小的或可變大小的。

塊級變化不會影響其他塊的哈希值，但是，在一個塊部分字節變化上就會改變多個塊的哈希值?？勺兇笮〉膲K或內容定義的分塊通過使用固定的分塊偏移量來分割一個文件來解決這個問題。固定的分塊偏移量可以通過使用Rabin滾動散列找到。Rabin滾動散列使用多項式和一個滑動窗口來進行散列。為了找到分塊偏移量，我們滑動和散列窗口，直到哈希匹配一個預定義的值。

5.2.3應用場景

客戶端API 該方案提供了客戶端與存儲服務器之間良好的接口。通過選擇合適的存儲節點， 可以降低 CPU 負載。

System.out.println();
jLabel3.setText(digits+outputString1);
Class.forname("com.mysql.jdbc.Driver");
con = DriverManager.getConnection("jdbc//localhost:3306/javamysql", "root", "root");
String HashValue = digits + outputString1;
String status = null;
int result, tab = 0;

5.2.4性能測試數據

安卓的一個原型實現上的實現：

• 僅限文件級重復數據刪除的系統(FDS)

• 僅限塊級重復數據刪除的系統(BDS)

• 針對移動設備或SDM的智能重復數據刪除

• 預配置的重復數據刪除系統(PCDS)

文件類型	分配重復數據刪除方法
mp3	文件級
jpg	文件級
pdf	塊級
obb	塊級
未知的	塊級

RADS的工作原理是使用重復數據消除比率來確定每種文件類型應該使用哪種重復數據消除方法。如果沒有達到該文件類型 的目標重復數據刪除比率，則系統將選擇另一種重復數據刪除方法。對于每種文件類型，重復數據刪除比率通過將重復數據刪除文件大小除以文件大小來計算。

• 旋轉重復數據刪除系統(RADS)

文件類型	已分配的重復數據刪除方法	目標重復數據消除率（%）
mp3	5文件級	5
jpg	文件級	5
pdf	塊級	5
obb	塊級	25
未知的	塊級	10

5.2.5測試結果

演示不同的重復數據刪除系統在處理未知文件類型時的性能：

總的來說，SDM比其他系統表現得更好，特別是在未知的文件類型上，因為我們的系統不需要對不同的文件類型進行任 何特定的配置。對于大多數情況下文件和塊級之間的重復數據刪除吞吐量，以及接近塊級重復數據刪除精度的重復數據刪 除精度，與其他系統相比，我們的系統可以使云存儲作為移動設備的存儲解決方案更加可行。

6.Ares數據壓縮框架

6.1介紹

現代應用中的數據爆炸現象給存儲系統帶來了巨大的壓力，因此開發者使用數據壓縮技術來解決這個問題。但是，在考慮輸入數據類型和格式時，每個壓縮庫都表現出不同的優勢和劣勢。所以有相關學者提出了Ares，一個智能、自適應和靈活的模塊化壓縮框架，可以根據工作負載的類型為給定的輸入數據動態選擇壓縮庫，并為用戶提供適當的基礎設施來微調所選的庫。Ares是一個模塊化框架，它統一了多個壓縮庫，同時允許用戶添加更多壓縮庫。同時，Ares也是一個統一的壓縮引擎，它抽象了每個工作負載使用不同壓縮庫的復雜性。

在科學和云計算領域的實際運用中，Ares的執行速度相比其他解決方案快了 2-6 倍，而且附加數據分析的成本較低。與完全沒有壓縮的基線相比，速度快了 10 倍。

6.2面臨的問題

我們知道，無損壓縮算法分為兩類：通用算法和專用算法。像Bzip、Zlib、7z這些就是屬于通用壓縮庫，事實上，它們的性能的確很好，但不足是不會利用數據表示之間的細微差別。所以又有了一些更專門的算法，比如Snappy、SPDP、LZO等，這一類算法通過最小化數據占用空間來提高應用程序的整體性能，因而有著廣泛的前景。

盡管有以上這些特定領域的壓縮庫的良好發展，但是仍然面臨幾個比較現實的問題：

• 數據依賴：由于每個庫對某種數據類型的專一化，致使對于其他情況來說，它通常不夠一般化。即使選擇了庫，大多數應用程序由于使用很多不同類型的數據，因此僅使用一個庫也不會產生最佳性能。

• 庫的選擇：不同的庫有著不同的優點和缺點，通常為一個用例選擇合適的庫是困難的。即使在同一個應用程序中，其不同部分也會有著不同的壓縮需求。比如檔案的存儲需要高的壓縮比，而進程間的數據共享需要高的壓/解壓縮速度。

• API和可用性：每個壓縮庫都有自己的一組參數和API，通常很難過渡到或采用新的庫，沒有哪種壓縮算法可為所有類型的數據、文件格式或應用程序需求提供最佳性能。我們希望可以有一個智能的框架，能夠無縫統一多個庫，并根據特定場景動態選擇“最佳”壓縮算法。

6.3基準測試

既然要統一不同算法，那首先就要確切地掌握它們的實際表現。因此，學者對廣泛選擇的壓縮庫通過全面的基準測試進行了性能評估：

從數據類型、數據格式和工作負載優先級三個維度進行了測試，篇幅有限，細節分析部分這里不再具體展開。簡單總結為：通過觀察各個庫之間的性能變化，可以發現每個工作負載都可以從智能的動態壓縮框架中受益。

6.4Ares的體系架構

Ares架構的核心是即插即用，框架是一個中間件庫，它封裝了多個壓縮庫，從用戶側抽象出它們的復雜性。應用程序可以使用Ares作為工具（CLI）或作為一個庫（API）。在這兩種情況下，Ares內部的數據流是相同的。首先，Ares分析輸入數據，以識別所涉及的數據類型和格式。其輸入可以是一個文件、一個目錄或一個以前壓縮過的文件（file.ares）。然后，將分析結果傳遞給主引擎，由主引擎決定哪個壓縮庫最適合給定的情況。根據決策，Ares利用一個庫池，其中包括預編譯的壓縮庫（目前的原型中已存在11個），再執行壓/解壓縮操作。最后，Ares用其元數據修飾壓縮數據，并輸出.ares文件到磁盤。

6.5要點評估

6.5.1開銷和資源利用率

如上圖，我們可以觀察到，每個被測試的庫都展現了不同的開銷。例如，lz4、quicklz和snappy在CT、I/O和DT上都實現了類似的時間，但系統利用率不同（如snappy是CPU密集型、內存占用低）。相比之下，bsc提供了最高8.6x的CR，但也是最慢的庫，它的CPU和內存占用率高達90%以上。bzip2的內存占用較低，但在CR為6.2x時仍保持較高的CPU占用率。另一方面，Ares通過分析輸入數據來平衡CT、DT和CR，而這個額外的開銷只占總時間的10%。Ares用了74秒進行數據類型和格式的檢測，即便有這些額外的開銷，Ares執行所有操作的速度仍然比所有庫的速度快，并取得了最佳的總體時間。

具體來說，Ares比bsc快6.5倍，比bzip2快4.6倍，比lz4、quicklz快5-40%，而且在達到58%的CPU和64%的內存占用率情況下仍然非?？臁?/span>

6.5.2壓/解壓智能度

從結果可以看出，使用CR為1.75倍的lz4可以更快地壓縮二進制數據。對于較復雜的壓縮，bsc實現了大于5倍的CR，但CT和DT明顯減慢。

6.5.3壓/解壓適應度

6.5.4壓/解壓靈活度

Ares的優勢在于它能夠根據輸入的數據類型和格式進行壓縮。此外，Ares提供了在給定工作負載的情況下對某些壓縮特性進行優先級排序的基礎設施。Ares的目標是通過C/C++和Java綁定支持科學和云工作負載。此外，Ares抽象了它的引擎中包含的每個壓縮庫的細節，這使得它更易于使用，并且在需要時可以靈活地擴展到更多的壓縮庫。下面用了四個不同的科學應用（VPIC和HACC）和云工作負載（單詞計數和整數排序）測試了Ares的性能，研究了三種類型的工作負載：

6.6總結

與傳統的壓縮庫相比，Ares可以提高性能。具體來說，在科學和云計算領域的實際應用中，Ares的執行速度比同類解決方案快了2-6倍，并為用戶提供了一個靈活的基礎設施，可根據手頭的任務確定壓縮特點。

<本文完>

參考文獻

[1] Shakarami A, Ghobaei-Arani M, Shahidinejad A, et al. Data replication schemes in cloud computing: a survey[J]. Cluster Computing, 2021, 24(3): 2545-2579.

https://www.researchgate.net/publication/350921010_Data_replication_schemes_in_cloud_computing_a_survey

[2] Widodo R N S, Lim H, Atiquzzaman M. SDM: Smart deduplication for mobile cloud storage[J]. Future Generation Computer Systems, 2017, 70: 64-73.

https://www.researchgate.net/publication/304906996_SDM_Smart_deduplication_for_mobile_cloud_storage

[3] Rani, I.S., Venkateswarlu, B.: A systematic review of different data compression technique of cloud big sensing data. In: International conference on computer networks and inventive communication technologies (pp. 222–228). Springer, Cham (2019)

https://link.springer.com/content/pdf/bfm:978-3-030-37051-0/1.pdf

[4] Hema, S., Kangaiammal, A. (2019) Distributed storage hash algorithm (DSHA) for file-based deduplication in cloud computing. In: International conference on computer networks and inventive communication technologies (pp. 572–581). Springer, Cham (2019)

https://dl.acm.org/doi/abs/10.1016/j.jksuci.2021.04.005

[5] Liu J, Shen H, Narman H S. Popularity-aware multi-failure resilient and cost-effective replication for high data durability in cloud storage[J]. IEEE Transactions on Parallel and Distributed Systems, 2018, 30(10): 2355-2369.

https://ieeexplore.ieee.org/document/8478382/

[6] Devarajan H, Kougkas A, Sun X H. An intelligent, adaptive, and flexible data compression framework[C]//2019 19th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (CCGRID). IEEE, 2019: 82-91.

https://ieeexplore.ieee.org/document/8752926

[7]Top 10 benefits of cloud computing - Information Age

https://www.information-age.com/top-10-benefits-cloud-computing-7248/

ELT.ZIP是誰？

ELT<=>Elite(精英)，.ZIP為壓縮格式，ELT.ZIP即壓縮精英。

成員：

上海工程技術大學大二在校生閆旭

合肥師范學院大二在校生楚一凡

清華大學大二在校生趙宏博

成都信息工程大學大一在校生高云帆

黑龍江大學大一在校生高鴻萱

山東大學大三在校生張智騰

ELT.ZIP是來自6個地方的同學，在OpenHarmony成長計劃啃論文俱樂部里，與來自華為、軟通動力、潤和軟件、拓維信息、深開鴻等公司的高手一起，學習、研究、切磋操作系統技術...

寫在最后

OpenHarmony 成長計劃—“啃論文俱樂部”（以下簡稱“啃論文俱樂部”）是在 2022年 1 月 11 日的一次日?；顒又姓Q生的。截至 3 月 31 日，啃論文俱樂部已有 87 名師生和企業導師參與，目前共有十二個技術方向并行探索，每個方向都有專業的技術老師帶領同學們通過啃綜述論文制定技術地圖，按“降龍十八掌”的學習方法編排技術開發內容，并通過專業推廣培養高校開發者成為軟件技術學術級人才。

啃論文俱樂部的宗旨是希望同學們在開源活動中得到軟件技術能力提升、得到技術寫作能力提升、得到講解技術能力提升。大學一年級新生〇門檻參與，已有俱樂部來自多所高校的大一同學寫出高居榜首的技術文章。

如今，搜索“啃論文”，人們不禁想到、而且看到的都是我們——OpenHarmony 成長計劃—“啃論文俱樂部”的產出。

OpenHarmony開源與開發者成長計劃—“啃論文俱樂部”學習資料合集

1）入門資料：啃論文可以有怎樣的體驗

https://docs.qq.com/slide/DY0RXWElBTVlHaXhi?u=4e311e072cbf4f93968e09c44294987d

2）操作辦法：怎么從啃論文到開源提交以及深度技術文章輸出https://docs.qq.com/slide/DY05kbGtsYVFmcUhU

3）企業/學校/老師/學生為什么要參與 & 啃論文俱樂部的運營辦法https://docs.qq.com/slide/DY2JkS2ZEb2FWckhq

4）往期啃論文俱樂部同學分享會精彩回顧：

同學分享會No1.成長計劃啃論文分享會紀要（2022/02/18）https://docs.qq.com/doc/DY2RZZmVNU2hTQlFY

同學分享會No.2 成長計劃啃論文分享會紀要（2022/03/11）https://docs.qq.com/doc/DUkJ5c2NRd2FRZkhF

同學們分享會No.3 成長計劃啃論文分享會紀要（2022/03/25）

https://docs.qq.com/doc/DUm5pUEF3ck1VcG92?u=4e311e072cbf4f93968e09c44294987d

現在，你是不是也熱血沸騰，摩拳擦掌地準備加入這個俱樂部呢？當然歡迎啦！啃論文俱樂部向任何對開源技術感興趣的大學生開發者敞開大門。

掃碼添加 OpenHarmony 高校小助手，加入“啃論文俱樂部”微信群

后續，我們會在服務中心公眾號陸續分享一些 OpenHarmony 開源與開發者成長計劃—“啃論文俱樂部”學習心得體會和總結資料。記得呼朋引伴來看哦。