,,

Ozone | 數(shù)據(jù)湖存儲，統(tǒng)一和融合哪個更好？

（2024年11月27日更新）

關(guān)于Alluxio這篇文章把注意力轉(zhuǎn)移到了大數(shù)據(jù)上。

芯片采購網(wǎng)專注于整合國內(nèi)外授權(quán)IC代理商現(xiàn)貨資源，芯片庫存實時查詢，行業(yè)價格合理，采購方便IC芯片，國內(nèi)專業(yè)芯片采購平臺。

文中提及Cloudera作為Hadoop為什么生態(tài)最后的種子選手沒有制造麻煩？Alluxio這樣的東西？

沒想到在學習Cloudera在這個過程中，我過程中Ozone，回答了潭主之前的問題。

技術(shù)體系復雜，有許多平行宇宙。今日，潭主與大家分享一項最近學到的數(shù)據(jù)湖存儲技術(shù)，Ozone。

Ozone是哪路神

Ozone是Apache軟件基金會下的一個項目定位為：用戶大數(shù)據(jù)分析和云本地應用程序分布式，擴展性高，一致性強Key-Value對象存儲。

讀過潭主文章的讀者自然會Alluxio對使用功能有所了解，Ozone跟Alluxio同樣，也兼容支持S3和HDFS的API。

由于上述特點，Ozone現(xiàn)有可以透明支持Hadoop生態(tài)中如Spark和Hive等待上層計算框架，無需修改應用代碼。

套路是一樣的，把自己模仿成大師。當然，簡單的模仿肯定不好，但也有自己的創(chuàng)新。

潭主的窮人思維

由于商業(yè)模式的限制，傳統(tǒng)的保險業(yè)有很多數(shù)據(jù)孤島

然而，近年來，非結(jié)構(gòu)化業(yè)務數(shù)據(jù)增長迅速，之前引入的HCP對象存儲已經(jīng)是數(shù)十億的量級。

據(jù)潭主所知，雖然之前也推出了一些大數(shù)據(jù)項目，Hadoop其實集群的規(guī)模并不大，所以在寫這篇文章之前，潭主受到自己經(jīng)驗的限制Hadoop沒有疼痛。

即使在互聯(lián)網(wǎng)行業(yè)，十多年前也可能無法預測數(shù)據(jù)會膨脹得如此之快，以至于Hadoop很快就變得無能為力。

互聯(lián)網(wǎng)富人思維

在過去的兩年里，數(shù)據(jù)湖這個詞非常流行。

人們對數(shù)據(jù)湖有不同的理解。有人認為Hadoop是數(shù)據(jù)湖，有人認為是數(shù)據(jù)湖，有人認為是數(shù)據(jù)湖。S也是數(shù)據(jù)湖。

從網(wǎng)上公有云的角度來看，S三是主流存儲，而線下私有云，Hadoop這種情況似乎更有優(yōu)勢，無形中對混合云的統(tǒng)一江湖形成了儲存障礙。

因此，未來的數(shù)據(jù)湖技術(shù)應與各種主流計算框架相兼容，平穩(wěn)支持各種應用場景，對接不同的存儲引擎，實現(xiàn)數(shù)據(jù)訪問接口的標準化。

從最近的技術(shù)發(fā)展趨勢來看，這種統(tǒng)一標準的存儲技術(shù)將成為下一代數(shù)據(jù)湖的顯著特征。

而且對互聯(lián)網(wǎng)，HDFS該系統(tǒng)在集群擴展和支持應用標準方面確實存在一些局限性。

為了解決HDFS開源社區(qū)這幾年沒閑著，嘗試了很多解決方案。

HDFS聯(lián)邦時代

最初Hadoop只允許命名空間（Namespace），而且只有一個NameNode管理。

雖然可以添加底層DataNode由于所有節(jié)點的水平擴展和存儲空間的增加Block元數(shù)據(jù)都停留了NameNode在內(nèi)存中，當集群規(guī)模增大時，NameNode很容易成為瓶頸，直接限制HDFS文件、目錄和數(shù)據(jù)塊的數(shù)量。

Hadoop 為了解決社區(qū)問題 HDFS 兩個聯(lián)邦方案(如上圖制定了兩個聯(lián)邦計劃（如上圖所示）：

· NNF（NameNode Federation）

· RBF（Router Based Federation）

早期的NNF在計劃中，集群引入了多個NameNode，管理不同Namespace和對應的BlockPool，多個NameNode可以共享Hadoop集群中的DataNode。

雖然解決了Namespace但是擴展問題需要對HDFS的Client結(jié)合靜態(tài)配置掛載ViewFS實現(xiàn)統(tǒng)一入口。

而在RBF在聯(lián)邦計劃中，試圖將掛載表從Client中抽出形成Router，雖然Hadoop集群是獨立的，但同時又增加了一個State Store構(gòu)件，結(jié)構(gòu)變得更加復雜。

對于面向未來的大數(shù)據(jù)存儲，局部改進的聯(lián)邦方案治標不治本。

藍而不是藍

有時候，最好的優(yōu)化是重新開始爐灶。

畢竟Hadoop技術(shù)多年，目前的軟硬件環(huán)境與當初大不相同，系統(tǒng)重構(gòu)也是合理的。

與其等別人去革HDFS人生不如自我革命。Ozone確實為用戶提供了新的選擇。

就好像CDH和HDP最終融合成CDP一樣，HDFS和S3也可融合成Ozone。

總之，Ozone站在Hadoop在這個巨人的肩膀上，設(shè)計是為了取代它HDFS，藍而不是藍。

潭主家的儲存一哥

早年接觸過Ceph，也搞過HCP（Hitachi Content Platform）對象存儲，這些經(jīng)驗理解潭主Ozone大有裨益。

專門查了自己的HCP，發(fā)現(xiàn)圖像文件已超過20億Susumu代理，存儲容量也小2PB。但在查詢過程中明顯感覺到元數(shù)據(jù)響應緩慢，估計很快就會擴容。

言歸正傳，再來說說Ozone核心概念：

· Volume：通常表示用戶、業(yè)務和HCP中的租戶（Tenant）對應

· Bucket：通常表示業(yè)務、應用和HCP命名空間（Namespace）對應

· Key：對應的是實際的Object

Ozone存儲路徑為/Volume/Bucket/Key，一個業(yè)務可以對應一個或多個Volume，每個Volume可包含多個Bucket，訪問方式Ozone實現(xiàn)了ofs和o3fs適配和協(xié)議包裝。

值得注意的是，HCP有文件夾的概念，即對象文件有層次結(jié)構(gòu)，但Ozone設(shè)計扁平，目錄是偽目錄的概念，是文件名的一部分，統(tǒng)一Key而存在。

Ozone的體系架構(gòu)

介紹完概念，再看Ozone系統(tǒng)架構(gòu)(如上圖):

· OM（Ozone Manager）：通過RocksDB的K-V方式管理Namespace，Raft協(xié)議保持高可用性，Shardig實現(xiàn)水平擴展

· SCM（Storage Container Manager）：用于Ozone集群管理，負責分配Block，跟蹤SC復制狀態(tài)

· DataNode：負責向SCM匯報SC狀態(tài)

· SC（Storage Container）：Ozone實際存儲單元

· Recon Server：用于監(jiān)控Ozone集群

Ozone架構(gòu)優(yōu)化，上層實現(xiàn)功能分離，OM負責管理Namespace，SCM負責管理Storage Containers。

下層實現(xiàn)了一個名字Hadoop Distributed Data Store（HDDS）高可用性、塊存儲層。

Ozone中的一個DataNode包括多個Storage Container，每個SC(默認5)容量GB，可配置)遠大于Hadoop中Block容量（默認128MB），這種設(shè)計使每一個DN發(fā)送給SCM的Container-Report系統(tǒng)壓力遠小于傳統(tǒng)壓力Hadoop集群的Block-Report。

Storage Container作為Ozone通過其內(nèi)置，基本存儲和復制單元類似于超級塊RocksDB（key記錄BlockID，Value記錄object對小文件的塊管理實現(xiàn)了文件名、偏移量和長度。