Hadoop 對象存儲 Ozone
- 2019 年 10 月 31 日
- 筆記
作者：Yan Liu
審閱：Xiaoyu Yao
0
Hadoop HDFS的現狀
Apache Hadoop 項目至今已經有十多年的歷史了，作為大數據的基石，自從投放之社區之後就引來了不少的眼球，進而也孕育出了眾多的Apache項目，例如HBase，Hive , Spark 等等這些優秀的數據存儲和處理等項目，從而構造成了一個龐大的生態圈。參考了世界級標準的，也就是 Hadoop的HDFS，一直在跟IEEE的POSIX文件系統API標準靠攏，因此我覺得，HDFS是長久的，因為它的API足夠的標準化。API足夠的標準化也就意味著照著實現的東西考慮的是很全面的。但是這並不代表HDFS本身的設計不存在問題或缺陷。
Current HDFS High Level Design
通常我們見到的一個HDFS集群，普通用戶的上限是2億個Block，有些能力特彆強的用戶群體，能做到4億到6億個Block。如果按照這個理想狀態每個Block的元數據佔位都對應有128MB的數據塊，那麼理論情況下的存儲上限是75 PB。這個存儲上限其實已經非常高了，對比今日甚至未來幾年的需求，除了雲服務提供商，幾乎不會有其它的企業想去存儲75PB的可用數據。
雖然這個上限非常的高，但並不代表它的設計架構就可以一直這樣保持下去，作為一個理想的文件系統，不應該對上層的應用有挑剔。可是至今為止，我們見到HDFS對上層的應用挑剔性還是比較大的。例如微服務的應用，目前就沒辦法運行在HDFS之上。同時，實時類的應用，例如Apache Kafka ，也沒有辦法運行在HDFS之上。究其原因，還是數據的寫入速度不夠快，同時存在唯一的目錄元數據，文件越多越可能導致RPC過高等等問題。
1
社區的一些改進
大體上講，HDFS目前的問題有以下幾個方面：
1
超大規模的擴展能力問題；
2
運維的複雜性問題；
3
應對雲和實時的問題；
4
小文件問題。
舉個例子，即便是大型互聯網公司，比如eBay, 也有每兩周一次的HDFS健康檢查日，如此可見HDFS的運維是需要不斷的Review和修復的。不過，為了解決這些問題，社區是有一些方案的，例如，NameNode Federation和Route Based Federation等。但是這些方案都沒有辦法很好的解決HDFS目前面臨的所有問題。
HDFS NameNode Federation High Level Design
HDFS Route Based Federation High Level Design
正如上面的圖裡所顯示的，NNF是將Namespace做了拆分，DataNode不需要拆分，而RBF是將數個HDFS集群通過Router抽象合併。這兩個實現方案都有各自的優點和缺點，但是都不能完整的解決HDFS目前的各種痛點。
2
由 HDFS 轉變為 HDDS
為了把HDFS做的更加的通用和標準化，Hadoop社區由Anu Engineer帶隊，著手設計Apache Hadoop的對象存儲方案，也就是今天人們熟知的Hadoop Ozone。為了實現Ozone，還需要實現一個自通訊數據一致性方案，於是這個大團隊又著手研發了Apache Ratis。關於Apache Ratis是什麼以及什麼原理，我們可以後續討論（主要是PAXOS理論實在太晦澀了，即便是簡版的RAFT理論也很難講出來），當前這篇文章還是主要以Ozone為主。
HDDS High Level Design
Ozone Manager：用來負責管理和分配文件名；
Storage Container Manager：用來分配Block的位置和物理伺服器；
Container: 這個是我曾經和研發Team吐槽過的一個點，大部分用戶看到Container都會聯想到K8S的應用容器。而這個Container，如果用JAVA的名詞概念來解釋的話，實際上就是把一堆Bean(極小的Block)放到Jar（Container）里，然後再放一個RocksDB來告訴打開罐子的人，這個罐子里每一個Bean的具體位置。另外,特別小的文件（<1MB）甚至直接可以放在RocksDB里。
這樣的設計吸收了HDFS本身的優秀的一面，同時也解決了HDFS面臨的諸多問題：
1
多層目錄結構的設計方案使得Ozone可以提升到百億級別的文件Key；
2
OM和SCM是可以橫向擴展的，並不會出現RPC集中在單點的問題；
3
使用Offheap來減少GC，通過FSCK服務來自動化的維護集群；
4
通過Apache Ratis來保障數據的強一致性等等。
同時，這樣的設計還更好的支援了K8S應用的部署，通過Quadra服務還可以創建和Mount與K8S應用對應的Storage Volume。關於K8S支援的技術細節，在Ozone系列的下一篇文章中會講到。
3
結束語
大頭作為一個社區粉絲，還是要敬仰並感謝這些社區貢獻人員不斷的為Hadoop注入新鮮的活力，以下是Ozone項目的不完全社區主要貢獻人員列表。
Anu Engineer (Ozone Project Lead)
Cloudera Principal Software Engineer
Apache Hadoop Committer/PMC Member
Apache Ratis Committer/PMC Member
Xiaoyu Yao
Cloudera Principal Software Engineer
Apache Hadoop Committer/PMC Member
Marton Elek
Cloudera Principal Software Engineer
Apache Hadoop Committer
Apache Ratis. Committer/PMC Member
Nicholas Sze
Cloudera Principal Software Engineer
Apache Hadoop Committer/PMC Member
Apache Ratis. Committer/PMC Member
Chen Liang
LinkedIn Senior Software Engineer
Apache Hadoop Committer
等等等等
Ozone項目主頁：
https://hadoop.apache.org/ozone/
Ozone設計方案：
https://issues.apache.org/jira/secure/attachment/12724042/Ozone-architecture-v1.pdf
Ozone Jira：
https://jira.apache.org/jira/projects/HDDS/
嘗鮮Ozone：
https://www.katacoda.com/elek/scenarios/ozone101
Ozone Docker Volume(Quadra / cBlock):
https://issues.apache.org/jira/secure/attachment/12837867/cblock-proposal.pdf
