前面幾篇文章把Hadoop常用的模塊都學習了，剩下一個新模塊Ozone，截止到今天最新版本是0.5.0Beta，還沒出正式版。好在官方網站有文檔，還是中文版的，但是中文版資料沒有翻譯完整，我試着把它都翻譯一下。參考 《Apache Hadoop Ozone》。
什么是Ozone
Ozone 是 Hadoop 的分布式對象存儲系統，具有易擴展和冗余存儲的特點。
Ozone 不僅能存儲數十億個不同大小的對象，還支持在容器化環境（比如 Kubernetes）中運行。
Apache Spark、Hive 和 YARN 等應用無需任何修改即可使用 Ozone。Ozone 提供了 Java API、S3 接口和命令行接口，極大地方便了 Ozone 在不同應用場景下的的使用。
Ozone 的管理由卷、桶和鍵組成：
- 卷的概念和用戶賬號類似，只有管理員可以創建和刪除卷。
- 桶的概念和目錄類似，用戶可以在自己的卷下創建任意數量的桶，每個桶可以包含任意數量的鍵，但是不可以包含其它的桶。
- 鍵的概念和文件類似，用戶通過鍵來讀寫數據。
Ozone架構
Ozone 是一個分布式、多副本的對象存儲系統，並針對大數據場景進行了專門的優化。Ozone 主要圍繞可擴展性進行設計，目標是十億數量級以上的對象存儲。
Ozone 通過對命名空間與塊空間的管理進行分離，大大增加了其可擴展性，其中命名空間由 Ozone Manager （OM）管理，塊空間由 Storage Container Manager（SCM）管理。
Ozone 的管理由卷、桶和鍵組成。卷類似於個人主目錄，只有管理員可以創建。
卷用來存儲桶，用戶可以在一個卷中創建任意數量的桶，桶中包含鍵，在 Ozone 中通過鍵來存儲數據。
Ozone 的命名空間由存儲卷組成，同時存儲卷也用作存儲賬戶管理。
下面的框圖展示了 Ozone 的核心組件：
Ozone Manager 管理命名空間，Storage Container Manager 管理底層的數據，而 Recon 是 Ozone 的管理接口。
Ozone Manager
Ozone Manager（OM）管理 Ozone 的命名空間。
當向 Ozone 寫入數據時，你需要向 OM 請求一個塊，OM 會返回一個塊並記錄下相關信息。當你想要讀取那個文件時，你也需要先通過 OM 獲取那個塊的地址。
OM 允許用戶在卷和桶下管理鍵，卷和桶都是命名空間的一部分，也由 OM 管理。
每個卷都是 OM 下的一個獨立命名空間的根，這一點和 HDFS 不同，HDFS 提供的是單個根目錄的文件系統。
與 HDFS 中單根的樹狀結構相比，Ozone 的命名空間是卷的集合，或者可以看作是個森林，因此可以非常容易地部署多個 OM 來進行擴展。
Ozone Manager 元數據
OM 維護了卷、桶和鍵的列表。它為每個用戶維護卷的列表，為每個卷維護桶的列表，為每個桶維護鍵的列表。
OM 使用 Apache Ratis（Raft 協議的一種實現）來復制 OM 的狀態，這為 Ozone 提供了高可用性保證。
Ozone Manager 和 Storage Container Manager
為了方便理解 OM 和 SCM 之間的關系，我們來看看寫入鍵和讀取鍵的過程。
寫入鍵
-
為了向 Ozone 中的某個卷下的某個桶的某個鍵寫入數據，用戶需要先向 OM 發起寫請求，OM 會判斷該用戶是否有權限寫入該鍵，如果權限許可，OM 分配一個塊用於 Ozone 客戶端數據寫入。
-
OM 通過 SCM 請求分配一個塊（SCM 是數據節點的管理者），SCM 選擇三個數據節點，分配新塊並向 OM 返回塊標識。
-
OM 在自己的元數據中記錄下塊的信息，然后將塊和塊 token（帶有向該塊寫數據的授權）返回給用戶。
-
用戶使用塊 token 證明自己有權限向該塊寫入數據，並向對應的數據節點寫入數據。
-
數據寫入完成后，用戶會更新該塊在 OM 中的信息。
讀取鍵
-
鍵讀取相對比較簡單，用戶首先向 OM 請求該鍵的塊列表。
-
OM 返回塊列表以及對應的塊 token。
-
用戶連接數據節點，出示塊 token，然后讀取鍵數據。
Storage Container Manager
SCM提供了支持Ozone集群的多個關鍵函數。它提供了集群管理、認證授權、塊管理、多副本管理多種功能。
集群管理
SCM負責創建Ozone集群。當通過初始化命令啟動SCM的時候，SCM會創建認證授權需要的集群ID和根證書。SCM管理數據節點在集群中的完整生命周期。
認證授權（CA）
SCM的認證中心負責給集群中的每一個服務分發身份證書，底層的證書服務能夠更容易地實現網絡層的雙向認證和基於認證的塊令牌服務。
塊管理
SCM向數據節點分配塊，客戶端可以直接讀寫這些塊。
多副本管理
SCM掌握着塊副本的實時信息。如果發生塊丟失，SCM會向數據節點發指令，讓它們復制一個塊副本來保證高可用。
Datanodes
Ozone跟HDFS的命名都如此相似。
Ozone所有的數據都存放在數據節點上。客戶端以塊的形式寫入數據，數據節點把這些塊聚合起來放入存儲容器中。一個存儲容器包含了數據流和客戶端寫入塊的元數據信息。
存儲容器
一個存儲容器是一個獨立的超級塊，它包含兩部分內容：一部分是塊清單，另一部分是保存着實際數據流的磁盤文件。上圖是存儲容器的默認格式。
從Ozone的角度來看，容器是一個協議規范，實際的存儲層反而無關緊要。換句話說，是繼承還是使用一個新的存儲層都是可以的。只要是基於Ozone的容器實現就行。
Qzone的塊和容器
當客戶端需要讀取一個鍵值的時候，它會向Qzone Manager發請求，Qzone Manager返回這個鍵對應的塊清單。
一個塊包含容器ID和本地ID。下圖顯示了Ozone塊的結構。
容器ID讓客戶端能夠找到容器的位置。一個容器到底在哪兒，SCM里的信息是最權威的。大多數情況下，Qzone Manager會把容器的位置緩存起來，隨着塊信息一起返回給客戶端。
客戶端獲取到返回信息之后，它就知道容器在哪個數據節點上。客戶端建立起與數據節點的連接，根據容器ID和本地ID來讀取數據流。也就是說，本地ID是容器里的索引信息，它描述了我們要讀取的數據流。
容器定位
SCM怎么知道容器在哪兒呢？這個過程跟HDFS類似。數據節點定期發送容器信息，就像HDFS發送塊信息給NameNode一樣。只不過容器信息比塊信息要簡單的多。舉個例子，一個包含196TB數據的Ozone大約有4萬個容器。相比之下，HDFS的block會達到上百萬個，至少有一半的block會發送信息。Qzone發送的塊信息減少了40倍。
這有助於Ozone的擴展性管理。SCM需要處理的塊數據要少得多，與NameNode的類型不同，這對Ozone的擴展性很重要。