前言
衆所周知，在當下存儲系統中爲了存儲效率的提升，Erasure Coding(糾刪碼)技術在扮演着一個越來越重要的角色。比如說目前Hadoop HDFS中，它就已經能夠支持EC功能了。在EC模式下，HDFS 可以不必存儲多打3份這樣的冗餘副本數來爲了容災保護。存儲效率的提高意味着存儲海量數據所需要的存儲節點資源的減少。不過本文並不是聊HDFS的EC實現的，而是談談時下另外一個存儲系統Ozone的EC設計，也是簡單聊聊在Ozone的對象存儲模式下，EC要如何實現以及它能夠帶來的好處。
EC技術以及EC下的存儲效率的提升
關於EC技術本身，全稱Erasure Coding，中文稱之爲糾刪碼技術。EC的具體算法實現細節網上資料講述的也已經很多了，本文不做過分細緻的闡述。
簡單的來說，就是將原始數據塊進行劃分成多個data block，然後根據EC算法的計算，產生出新的校驗塊(parity block)，如下所示：
當上述數據塊或者校驗塊發生丟失或者損壞的情況時，系統可以根據EC算法進行重新生成來恢復，以此達到數據保護的效果。
還有一個問題，這裏的數據存儲效率的提升體現在哪裏呢？
繼續以上述例子爲例，在上面3個數據塊，2個校驗塊模式下，那麼此時數據存儲效率爲3/(3+2)=60%，而在傳統3副本模式下，存儲效率只爲1/3=33%，它的另外2份存儲是完全冗餘的，注意我們這裏談的是絕對有效的存儲。
OK，我們可以看到在EC模式下，系統的存儲效率能夠得到不小的提升，當採用不同EC算法模式時，這個存儲效率還可能更高。
凡是硬幣都有正方面，另外一方面，EC的劣勢在於做它做數據恢復時，需要耗費更多的網絡和CPU資源，所以我們一般將那些訪問低頻次的冷數據進行EC的處理。
Ozone下的EC方案設計
在上小節部分我們對EC有個簡單的瞭解後，我們再來看看針對Ozone系統的特點，Ozone社區是如何做這塊的設計的。Ozone社區在JIRA HDDS-3816：Erasure Coding in Apache Hadoop Ozone中對此方案進行了設計。
在此方案中它主要提出了2套可選的方案：
- 以Container爲基本存儲單元，針對Container Level的EC實現。
- 以Block(Container內的Block)爲基本存儲單元，針對Block Level的EC實現。
這2種EC的實現方案在實現複雜度以及各自方案的優劣勢都有所不同。下面我們來分別來了解這裏面的實現細節部分的內容。
Container Level的EC實現
首先Container Level的EC實現，以Container爲基本單位，Ozone將會把一個整的Container作爲一個大的data block，而Container裏面實際存儲的Block在是這個data block的一個小的部分。然後不同的Container就組成了多data block，最後就是校驗Container塊的產生了。
此過程圖如下所示：
上面Container裏面1，2，3，4，5數字代表的裏面的Block塊。每個相同偏移量位置的Block數據進行對應檢驗塊數據的生成，如下圖所示：
我們從另外一個層面來看，多餘的Container副本就可以校驗Container剔除取代了，
在Container Level的EC實現中，對現有Ozone內部的改動其實是稍微比較小的。因爲Container內部的Block數據結構，位置其實都沒有發生改變。OM那邊也不需要更新Key對應的Block位置信息。換句話鎖，Container Level的EC對於原有的對象數據的讀寫訪問沒有什麼影響。
但是這裏的影響主要在於Container的異步校驗Container的生成，當前設計是隻考慮給closed狀態的Container做EC處理，因此我們不會有數據新寫入Container，而校驗Container還是老的這樣的問題。
另外一點的影響方面是closed狀態的Container數據的刪除，在Container EC模式中，每個Container的作用是被放大了，每個Container不僅自身存儲有Block數據外，它還同時擔負着幫助其它Container進行數據錯誤恢復的作用，即使這個Container它可能已經被刪除了。簡單來說，在Ozone中被刪除的closed狀態的Container或Container中的任何Block數據被刪除了，都不能被馬上立即地被物理刪除掉，除非等到它所依賴的Container已經重新組織別的新的Container進行校驗Container的生成。
最後是我們以Container級別的粒度做數據的恢復，它的cost開銷可能會比較大。目前Ozone默認一個Container最大的size是5GB。在HDFS中，它的block設置往往就128MB，256MB這種級別，在Ozone中我們提升到了GB級別，它所需要的開銷必然會有所增加的。
Block Level的EC實現
聊完Container Level的EC方案後，我們再來說說Block的EC方案。這裏的Block指的是Container內的那些Block。如果我們按照Container Block做EC的實現，其本質已經十分類似於HDFS的EC實現了。它同樣是將一個Block進行條帶式的分散寫入到多個Container，多個node裏去。
這裏類似HDFS Block EC結構，下圖爲HDFS Block的EC條帶式存儲：
這樣的方式會打破現有Block數據的寫入實現邏輯，而且OM服務那邊Key對應的Block位置信息也是需要更新的。Block Level的EC實現所需要的代碼變動相較Container Level來說是更多一點的。
不過在Block Level下，筆者認爲它的讀寫性能理應會得到提升的，因爲數據橫向存儲在多節點中，我們可以採用並行讀寫，然後合併結果的方式來提升數據讀寫的效率。
另外在Block Level下，我們可以針對更細粒度Key級別做EC的設置了。當然了，它也會損失數據的locality特徵，因爲此時數據是分散存儲在多節點之下的。
但論整體完整度和潛在影響來說，筆者個人觀點是認爲Block Level的EC方案要比Container Level更好一些。包括它也沒有上面提到的Container刪除的問題。
以上就是本文今天所要闡述的關於Ozone EC的內容了，還是很期待這個功能在Ozone中得到完整的實現的。
引用
[1].https://issues.apache.org/jira/browse/HDDS-3816 . Erasure Coding in Apache Hadoop Ozone