關于Alluxio這篇文章把注意力轉移到了大數據上。
芯片采購網專注于整合國內外授權IC代理商現貨資源，芯片庫存實時查詢，行業價格合理，采購方便IC芯片，國內專業芯片采購平臺。
文中提及Cloudera作為Hadoop為什么生態最后的種子選手沒有制造麻煩？Alluxio這樣的東西？
沒想到在學習Cloudera在這個過程中，我過程中Ozone，回答了潭主之前的問題。
技術體系復雜，有許多平行宇宙。今日，潭主與大家分享一項最近學到的數據湖存儲技術，Ozone。
Ozone是哪路神
Ozone是Apache軟件基金會下的一個項目定位為：用戶大數據分析和云本地應用程序分布式，擴展性高，一致性強Key-Value對象存儲。
讀過潭主文章的讀者自然會Alluxio對使用功能有所了解，Ozone跟Alluxio同樣，也兼容支持S3和HDFS的API。
由于上述特點，Ozone現有可以透明支持Hadoop生態中如Spark和Hive等待上層計算框架，無需修改應用代碼。
套路是一樣的，把自己模仿成大師。當然，簡單的模仿肯定不好，但也有自己的創新。
潭主的窮人思維
由于商業模式的限制，傳統的保險業有很多數據孤島
然而，近年來，非結構化業務數據增長迅速，之前引入的HCP對象存儲已經是數十億的量級。
據潭主所知，雖然之前也推出了一些大數據項目，Hadoop其實集群的規模并不大，所以在寫這篇文章之前，潭主受到自己經驗的限制Hadoop沒有疼痛。
即使在互聯網行業，十多年前也可能無法預測數據會膨脹得如此之快，以至于Hadoop很快就變得無能為力。
互聯網富人思維
在過去的兩年里，數據湖這個詞非常流行。
人們對數據湖有不同的理解。有人認為Hadoop是數據湖，有人認為是數據湖，有人認為是數據湖。S也是數據湖。
從網上公有云的角度來看，S三是主流存儲，而線下私有云，Hadoop這種情況似乎更有優勢，無形中對混合云的統一江湖形成了儲存障礙。
因此，未來的數據湖技術應與各種主流計算框架相兼容，平穩支持各種應用場景，對接不同的存儲引擎，實現數據訪問接口的標準化。
從最近的技術發展趨勢來看，這種統一標準的存儲技術將成為下一代數據湖的顯著特征。
而且對互聯網，HDFS該系統在集群擴展和支持應用標準方面確實存在一些局限性。
為了解決HDFS開源社區這幾年沒閑著，嘗試了很多解決方案。
HDFS聯邦時代
最初Hadoop只允許命名空間（Namespace），而且只有一個NameNode管理。
雖然可以添加底層DataNode由于所有節點的水平擴展和存儲空間的增加Block元數據都停留了NameNode在內存中，當集群規模增大時，NameNode很容易成為瓶頸，直接限制HDFS文件、目錄和數據塊的數量。
Hadoop 為了解決社區問題 HDFS 兩個聯邦方案(如上圖制定了兩個聯邦計劃（如上圖所示）：
· NNF（NameNode Federation）
· RBF（Router Based Federation）
早期的NNF在計劃中，集群引入了多個NameNode，管理不同Namespace和對應的BlockPool，多個NameNode可以共享Hadoop集群中的DataNode。
雖然解決了Namespace但是擴展問題需要對HDFS的Client結合靜態配置掛載ViewFS實現統一入口。
而在RBF在聯邦計劃中，試圖將掛載表從Client中抽出形成Router，雖然Hadoop集群是獨立的，但同時又增加了一個State Store構件，結構變得更加復雜。
對于面向未來的大數據存儲，局部改進的聯邦方案治標不治本。
藍而不是藍
有時候，最好的優化是重新開始爐灶。
畢竟Hadoop技術多年，目前的軟硬件環境與當初大不相同，系統重構也是合理的。
與其等別人去革HDFS人生不如自我革命。Ozone確實為用戶提供了新的選擇。
就好像CDH和HDP最終融合成CDP一樣，HDFS和S3也可融合成Ozone。
總之，Ozone站在Hadoop在這個巨人的肩膀上，設計是為了取代它HDFS，藍而不是藍。
潭主家的儲存一哥
早年接觸過Ceph，也搞過HCP（Hitachi Content Platform）對象存儲，這些經驗理解潭主Ozone大有裨益。
專門查了自己的HCP，發現圖像文件已超過20億Susumu代理，存儲容量也小2PB。但在查詢過程中明顯感覺到元數據響應緩慢，估計很快就會擴容。
言歸正傳，再來說說Ozone核心概念：
· Volume：通常表示用戶、業務和HCP中的租戶（Tenant）對應
· Bucket：通常表示業務、應用和HCP命名空間（Namespace）對應
· Key：對應的是實際的Object
Ozone存儲路徑為/Volume/Bucket/Key，一個業務可以對應一個或多個Volume，每個Volume可包含多個Bucket，訪問方式Ozone實現了ofs和o3fs適配和協議包裝。
值得注意的是，HCP有文件夾的概念，即對象文件有層次結構，但Ozone設計扁平，目錄是偽目錄的概念，是文件名的一部分，統一Key而存在。
Ozone的體系架構
介紹完概念，再看Ozone系統架構(如上圖):
· OM（Ozone Manager）：通過RocksDB的K-V方式管理Namespace，Raft協議保持高可用性，Shardig實現水平擴展
· SCM（Storage Container Manager）：用于Ozone集群管理，負責分配Block，跟蹤SC復制狀態
· DataNode：負責向SCM匯報SC狀態
· SC（Storage Container）：Ozone實際存儲單元
· Recon Server：用于監控Ozone集群
Ozone架構優化，上層實現功能分離，OM負責管理Namespace，SCM負責管理Storage Containers。
下層實現了一個名字Hadoop Distributed Data Store（HDDS）高可用性、塊存儲層。
Ozone中的一個DataNode包括多個Storage Container，每個SC(默認5)容量GB，可配置)遠大于Hadoop中Block容量（默認128MB），這種設計使每一個DN發送給SCM的Container-Report系統壓力遠小于傳統壓力Hadoop集群的Block-Report。
Storage Container作為Ozone通過其內置，基本存儲和復制單元類似于超級塊RocksDB（key記錄BlockID，Value記錄object對小文件的塊管理實現了文件名、偏移量和長度。
Ozone，新一代集成數據湖存儲
在網上看到一個互聯網大廠商專家之前的分享，現在網絡同時使用HDFS和Ceph。
HDFS主要用于大數據分析場景，但機器學習場景僅限于大量的小文件Ceph。
但是，在介紹中Ozone的Roadmap未來將引入存儲層Ozone。
開源世界，風起云涌，前腳剛看到Alluxio，感覺眼前一亮，現在再看Ozone，更是金光閃閃。
Ozone既是Hadoop優化升級版可以分層解決大量小文件的對象存儲，再加上云原生CSI支持使其成為新一代的融合存儲。
Ozone這股新勢力真的讓潭主不敢小覷，希望以后有機會做一些實踐。
存儲圈，數據不息，折騰不止！
