溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
作者介紹：
徐祥曦，七牛云工程師，獨立開發了多套高性能糾刪碼/再生碼編碼引擎。
柳青，華中科技大學博士，研究方向為基于糾刪碼的分布式存儲系統。
前言：
隨著數據的存儲呈現出集中化（以分布式存儲系統為基礎的云存儲系統）和移動化（互聯網移動終端）的趨勢，數據可靠性愈發引起大家的重視。集群所承載的數據量大大上升，但存儲介質本身的可靠性進步卻很小，這要求我們必須以更加經濟有效的方式來保障數據安全。
副本與糾刪碼都是通過增加冗余數據的方式來保證數據在發生部分丟失時，原始數據不發生丟失。但相較于副本，糾刪碼能以低得多的存儲空間代價獲得相似的可靠性。比如 3 副本下，存儲開銷為 3，因為同樣的數據被存儲了三份，而在 10+3（將原始數據分為 10 份，計算 3 份冗余）的糾刪碼策略下，存儲開銷為為 1.3。采用糾刪碼能夠極大地減少存儲系統的存儲開銷，減少硬件、運維和管理成本，正是這樣巨大的收益驅使各大公司紛紛將糾刪碼應用于自己的存儲系統，比如 Google、Facebook、Azure、EMC 等等國際巨頭，在國內以淘寶、華為、七牛云等為代表的公司也在自己的存儲系統上應用了糾刪碼。
最典型的糾刪碼算法是里德-所羅門碼（Reed-Solomon 碼，簡稱 RS 碼）。RS 碼最早應用于通信領域，經過數十年的發展，其在存儲系統中得到廣泛應用，比如光盤中使用 RS 碼進行容錯，防止光盤上的劃痕導致數據不可讀；生活中經常使用的二維碼就利用了RS 碼來提高識別的成功率。近年 RS 碼在分布式存儲系統中的應用被逐漸推廣，一方面是分布式存儲系統存儲的存儲容量和規模增大的需求；另一方面是由于糾刪碼編碼速度在近年得到迅猛提升。隨著對高性能糾刪碼引擎在實際系統中應用需要，也催生了對糾刪碼在具體系統中實現的各種優化手段。并為相關的決策者帶來了困擾——究竟什么樣的編碼引擎才是高效的呢？
我們將以這個問題展開對糾刪碼技術的剖析，幫助企業更全面，深入的了解糾刪碼在存儲系統中的應用并更好地做出技術選型。本系列文章將從糾刪碼的基本原理開始，隨后引出如何判斷編碼引擎優劣這個問題，接下來將深度分析代碼實現，幫助開發者順利完成定制開發。
本系列共計上下兩篇篇文章：
（上篇）如何選擇糾刪碼編碼引擎
（下篇）實現高性能糾刪碼引擎
本文作為系列首篇，我們將一起探討糾刪碼的編碼原理與如何選擇編碼引擎這兩個問題。
在展開分析之前，我們先來看一看 RS 碼是如何工作的。
下圖展示了 3+2（3 份數據，2 份冗余）下對 2 字節長度的數據進行編碼與數據修復過程：
為了計算冗余數據，首先我們需要選舉出一個合適的編碼矩陣。編碼矩陣的上部為一個單位矩陣，這樣保證了在編碼后原始數據依然可以直接讀取。通過計算編碼矩陣和原始數據的乘積，可以到最終的結果。
下面介紹解碼過程，當 1，2 兩塊數據丟失，即：
當數據塊發生丟失，在編碼矩陣中去掉相應行，等式仍然保持成立。這為我們接下來恢復原始數據提供了依據。
原始數據的修復過程如下：
為了恢復數據，首先我們求剩余編碼數據的逆矩陣，等式兩邊乘上這個逆矩陣仍然保持相等。與此同時，互逆矩陣的乘積為單位矩陣，因此可以被消掉。那么所求得的逆矩陣與剩余塊的數據的乘積就是原始數據了。
數據編碼以字節為單位，如果將被編碼數據看做一個「數組」，「數組」中每個元素是一個字節，數據按照字節順序被編碼。編碼過程是計算編碼矩陣中元素和「數組」的乘積過程。為保證乘積的運算結果仍舊在一個字節大小以內（即 0-255），必須應用到有限域[1]。有限域上的算術運算不同于通常實數的運算規則。我們通常事先準備好乘法表，并在算術運算時對每一次乘法進行查表得到計算結果。早期的編碼引擎之所以性能不佳，是因為逐字節查表的性能是非常低的。倘若能一次性對多字節進行查表以及相應的吞吐和運算，引擎的工作效率必將大幅度提升。
許多 CPU 廠商提供了包含更多位數的寄存器（大于 64 位），這類寄存器和相應支持的運算使得用戶程序可以同時對大于機器位數的數據進行運算，支持這類寄存器和運算的指令稱之為SIMD（Single Instruction Multiple Data）指令集，比如 Intel 支持的 SSE 指令集最大支持 128 bits 的數據運算，AVX2 指令集最大支持 512 bits 的數據運算。它們為我們對一個「數組」數據分別執行相同的操作，提高了數據運算的并行性。目前，市面上所有高性能的糾刪碼引擎均采用了該項技術以提高編解碼性能。
我們將從以下幾個關鍵指標來對編碼引擎進行分析：
1、 高編/解碼速度；
2、參數可配置；
3、編碼速度穩定性；
4、代碼簡潔、穩定；
5 、降低修復開銷等。
上文提到，依賴于SIMD 技術 RS 碼編碼性能有了大幅度的提高。其中，我們可以利用多種指令集擴展以供加速，引擎應該能自動根據 CPU 的特性而選擇最優的指令集擴展進行加速。
速度是最基本的要求。不過在這里我很難給出一個絕對的數字來衡量速度，因為其受參數，運行平臺的影響極大。在下文中提到的三款引擎均有出色的性能表現，可以以它們為基準來衡量引擎的編碼速度。除此之外，我們還可以將逐字節查表（下稱基本方法）的編碼速度與利用 SIMD 技術加速的編碼速度做對比，兩者之間應該有非常直觀的差距。以我的個人電腦為例（i5-4278U 2.6GHz),在 10+4 的策略下（每個數據塊大小為 128KB），基本方法的速度為（原始數據總量/編碼耗時）318.1 MB/s，而通過 AVX2 指令集加速后達到了 5558.6 MB/s[2],在 SSSE3 指令集的加速下也有 2978.87 MB/s 。
另外，解碼速度應該大于或等于編碼速度（視丟失的數據塊數量而定），下圖截自在我本機上運行的修復原始數據塊的性能測試結果：
一款合理的糾刪碼引擎必須能做到編碼策略在理論范圍內可隨意切換，這指的是如果要將編碼策略進行變化時，僅需從接口傳入不同參數而不需要改動引擎本身。這大大降低了后續的開發和維護所需要的精力。一個可配置參數的編碼引擎可以根據數據的冷熱程度和數據重要程度選擇不同的編碼系數，比如可靠性要求高的數據可以選擇更多冗余。
速度的穩定性指的是對于不同尺寸的數據塊會有相近的性能表現。由于系統緩存的影響，當被編碼數據的大小和緩存大小相當時，編碼應該具有最快的速度。當編碼數據的大小大于緩存大小時，內存帶寬成為編碼速度的瓶頸，文件大小和編碼時間呈現近似線性關系。這樣，數據編碼時間是可預期的，用戶的服務質量也是可保障的。在實際中，我們對于大文件進行定長分塊，依次編碼，分塊大小和緩存大小保持一定關系：以 10+4 編碼方法為例，對比數據塊尺寸分別為取 L3 Cache Size 的 1/12 以及 12 倍。如 L3 Cache Size 的大小為 12MB，則每一塊的數據尺寸分別取 1MB，144MB。倘若大數據塊下編碼速度遠遠低于小數據塊，則說明該引擎 CPU cache 的優化工作做得不充分。對于上述參數來說，大數據塊的速度應該不低于小數據塊的 70% 。同樣以我的個人電腦為例（L3 Cache 大小為 3MB）：
為了利用 SIMD 加速我們不得不引入匯編代碼或者封裝后的 CPU 指令，因此代碼形式并不常見。為了增強可讀性可將部分邏輯抽離到高級語言，然而會損失部分性能，這其中的利弊需要根據團隊的研發實力進行權衡。
接下來的可維護性也非常重要。首先是接口穩定，不會隨著新技術的引入而導致代碼大規模重構；另外代碼必須經過有合理的測試模塊以便在后續的更新中校驗新算法。
比如早先的 SIMD 加速是基于 SSE 指令集擴展來做的，隨后 Intel 又推出 AVX 指令集進一步提高了性能，引擎應該能即時跟上硬件進步的步伐。在比方說，再生碼（可以理解為能減少修復開銷的糾刪碼）是將來發展的趨勢，但我們不能因為算法的升級而隨意改變引擎的接口。
糾刪碼的一大劣勢便是修復代價數倍于副本方案。k+m 策略的 RS 碼在修復任何一個數據塊時，都需要k 份的其他數據從磁盤上讀取和在網絡上傳輸。比如 10+4 的方案下，丟失一個數據塊將必須讀取 10 個塊來修復，這個修復過程占用大量磁盤 I/O 和網絡流量，并使得系統暴露在一種降級的不穩定狀態。因此，實際系統中應該盡量避免使用過大的 k 值。
再生碼[2] 便是為了緩解數據修復開銷而被提出的，它能夠極大減少節點失效時所需要的吞吐的數據量。然而其復雜度大，一方面降低了編碼速度，另外一方面犧牲了傳統 RS 碼的一些優秀性質，在工程實現上的難度也大于傳統糾刪碼。
目前被應用最廣泛并采用了 SIMD 加速的引擎有如下幾款：
Intel 出品的 ISA-L[4]
J.S.Plank 教授領導的 Jerasure[4]
klauspost 的個人項目（in Golang)[6]
這三款引擎的執行效率都非常高，在實現上略有出入，以下是具體分析：
糾刪碼作為 ISA-L 庫所提供的功能之一，其性能應該是目前業界最佳。需要注意的是 Intel 采用的性能測試方法與學術界常用的方式略有出路，其將數據塊與冗余塊的尺寸之和除以耗時作為速度，而一般的方法是不包含冗余塊的。另外，ISA-L 未對 vandermonde 矩陣做特殊處理，而是直接拼接單位矩陣作為其編碼矩陣，因此在某些參數下會出現編碼矩陣線性相關的問題。好在 ISA-L 提供了cauchy 矩陣作為第二方案。
ISA-L 之所以速度快，一方面是由于 Intel 諳熟匯編優化之道，其次是因為它將整體矩陣運算搬遷到匯編中進行。但這導致了匯編代碼的急劇膨脹，令人望而生畏。
另外 ISA-L 支持的指令集擴展豐富，下至 SSE，上到 AVX512，平臺適應性最強。
不同于 ISA-L 直接使用匯編代碼，Jerasure2.0 使用 C 語言封裝后的指令，這樣代碼更加的友好。另外 Jerasure2.0 不僅僅支持 GF(2^8) 有限域的計算，其還可以進行 GF(2^4) - GF(2^128) 之間的有限域。并且除了 RS 碼，還提供了 Cauchy Reed-Solomon code （CRS 碼）等其他編碼方法的支持。它在工業應用之外，其學術價值也非常高。目前其是使用最為廣泛的編碼庫之一。目前 Jerasure2.0 并不支持 AVX 加速，盡管如此，不過在僅使用 SSE 的情況下，Jerasure2.0 依然提供了非常高的性能表現。不過主要作者之一 James S. Plank 教授轉了研究方向，另外一位作者 Greenan 博士早已加入工業界。因此后續的維護將是個比較大的問題。
klauspost 利用 Golang 的匯編支持，友好地使用了 SIMD 技術，此款引擎的 SIMD 加速部分是目前我看到的實現中最為簡潔的，矩陣運算的部分邏輯被移到了外層高級語言中，加上 Golang 自帶的匯編支持，使得匯編代碼閱讀起來更佳的友好。不過 Go 并沒有集成所有指令，部分指令不得不利用 YASM 等匯編編譯器將指令編譯成字節序列寫入匯編文件中。一方面導致了指令的完全不可讀，另外一方面這部分代碼的語法風格是 Intel 而非 Golang 匯編的 AT&T 風格，平添了迷惑。這款引擎比較明顯的缺陷有兩點：1.對于較大的數據塊，編碼速度會有巨大的下滑；2.修復速度明顯慢于編碼速度。
可能是由于對開源庫后續維護問題的擔憂，也有可能是現有方案并不能滿足企業對某些特定需求和偏好，很多公司選擇了自研引擎。那么如何寫出高效的代碼呢？在上面的簡單介紹中，受限于篇幅我跳過了很多細節。比如 SIMD 技術是如何為糾刪碼服務的，以及如何利用 CPU Cache 做優化等諸多重要問題。我們會在后續的文章中逐步展開其實現，歡迎大家繼續關注。
附錄：
許以超 馬松雅. 代數編碼與密碼[M]. 北京:高等教育出版社, 2015.
徐祥曦 Reed-Solomon
Alexandros G Dimakis, P Godfrey, Yunnan Wu, Martin J Wainwright, and Kannan Ramchan-dran. Network coding for distributed storage systems. Information Theory, IEEE Transactions on, 56(9):4539–4551, 2010.
Intel ISA-L
Jerasure
klauspost Reed-Solomon
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
