715
關(guān)于Alluxio的文章讓潭主把注意力轉(zhuǎn)移到了大數(shù)據(jù)上。
文中提及Cloudera作為Hadoop生態(tài)最后的種子選手，為什么沒有鼓搗出Alluxio這樣的東西？
沒想到在學(xué)習(xí)Cloudera的過(guò)程中無(wú)意間發(fā)現(xiàn)了Ozone，解答了潭主之前的疑問(wèn)。
技術(shù)體系繁雜，存在著很多“平行宇宙”。今天，潭主跟大家分享最近學(xué)習(xí)的一個(gè)數(shù)據(jù)湖存儲(chǔ)技術(shù)，Ozone。
Ozone是哪路神
Ozone是Apache軟件基金會(huì)下的一個(gè)項(xiàng)目，其定位是：一個(gè)用戶大數(shù)據(jù)分析和云原生應(yīng)用、具有高擴(kuò)展性、強(qiáng)一致性的分布式Key-Value對(duì)象存儲(chǔ)。
看過(guò)潭主文章的讀者自然對(duì)Alluxio有所了解，在使用功能上，Ozone跟Alluxio類似，也兼容支持S3和HDFS的API。
因?yàn)樯鲜鎏匦?，Ozone可以“透明”地支持現(xiàn)有Hadoop生態(tài)中如Spark和Hive等上層計(jì)算框架，無(wú)需修改應(yīng)用代碼。
套路是一樣的，把自己“模仿”成高手的樣子。當(dāng)然，簡(jiǎn)單模仿肯定不行，還要有屬于自己的“創(chuàng)新”。
潭主的“窮人”思維
傳統(tǒng)保險(xiǎn)行業(yè)受限于業(yè)務(wù)模式，存在很多的數(shù)據(jù)“孤島”，每個(gè)島的容量也有限。
不過(guò)，這幾年非結(jié)構(gòu)化業(yè)務(wù)數(shù)據(jù)增長(zhǎng)迅猛，之前引入的HCP對(duì)象存儲(chǔ)已經(jīng)是上十億的量級(jí)。
雖然之前也上線了一些大數(shù)據(jù)項(xiàng)目，但據(jù)潭主所知，Hadoop集群的規(guī)模其實(shí)并不大，以至于寫此文之前，潭主受限于自身經(jīng)驗(yàn)對(duì)Hadoop其實(shí)并無(wú)痛感。
即便是互聯(lián)網(wǎng)行業(yè)，十多年前可能也無(wú)法預(yù)料數(shù)據(jù)膨脹得如此之快，以至于Hadoop很快就變得力不從心。
互聯(lián)網(wǎng)的“富人”思維
這兩年，數(shù)據(jù)湖這個(gè)詞很火。
大家對(duì)于數(shù)據(jù)湖的理解也不盡相同，有人認(rèn)為Hadoop是數(shù)據(jù)湖，而有人認(rèn)為S3也是數(shù)據(jù)湖。
換個(gè)角度，從線上公有云的視角看，S3是主流存儲(chǔ)，而到了線下的私有云，Hadoop似乎更有優(yōu)勢(shì)一些，這種情況無(wú)形中對(duì)于混合云的一統(tǒng)江湖形成了存儲(chǔ)上的障礙。
因此，面向未來(lái)的數(shù)據(jù)湖技術(shù)應(yīng)該是向上兼容多種主流計(jì)算框架，平滑支撐多種應(yīng)用場(chǎng)景，向下對(duì)接不同的存儲(chǔ)引擎，實(shí)現(xiàn)數(shù)據(jù)訪問(wèn)接口的標(biāo)準(zhǔn)化。
從最近了解的技術(shù)發(fā)展趨勢(shì)看，這種承上啟下、統(tǒng)一標(biāo)準(zhǔn)的存儲(chǔ)技術(shù)將成為下一代數(shù)據(jù)湖的顯著特征。
況且對(duì)于互聯(lián)網(wǎng)，HDFS系統(tǒng)的確在集群擴(kuò)展性、支持應(yīng)用標(biāo)準(zhǔn)上的確存在一些局限性。
為了解決HDFS存在的問(wèn)題，開源社區(qū)這些年也沒閑著，嘗試了不少解決方案。
HDFS的“聯(lián)邦”時(shí)代
最初Hadoop集群只允許有一個(gè)命名空間（Namespace），且只能被一個(gè)NameNode管理。
雖然可以通過(guò)添加底層DataNode節(jié)點(diǎn)實(shí)現(xiàn)集群橫向擴(kuò)展，增加存儲(chǔ)空間，但由于所有的Block元數(shù)據(jù)都駐留在NameNode內(nèi)存中，在集群規(guī)模增大時(shí)，NameNode很容易成為瓶頸，直接限制了HDFS的文件、目錄和數(shù)據(jù)塊的數(shù)量。
Hadoop 社區(qū)為了解決 HDFS 橫向擴(kuò)展的問(wèn)題，做了兩個(gè)聯(lián)邦方案（如上圖）：
- NNF（NameNode Federation）
- RBF（Router Based Federation）
早期的NNF方案中，集群引入了多個(gè)NameNode，分別管理不同的Namespace和對(duì)應(yīng)的BlockPool，多個(gè)NameNode可以共享Hadoop集群中的DataNode。
雖然解決了Namespace的擴(kuò)展問(wèn)題，但需要對(duì)HDFS的Client進(jìn)行“靜態(tài)”配置掛載，還要結(jié)合ViewFS才能實(shí)現(xiàn)統(tǒng)一入口。
而在RBF的聯(lián)邦方案中，嘗試把“掛載表”從Client中抽離出來(lái)形成了Router，雖然Hadoop集群是獨(dú)立的，但同時(shí)又增加了一個(gè)“State Store”組件，架構(gòu)變得更復(fù)雜。
局部改進(jìn)的“聯(lián)邦”方案對(duì)于面向未來(lái)的大數(shù)據(jù)存儲(chǔ)而言，治標(biāo)不治本。
青出于藍(lán)而勝于藍(lán)
有時(shí)候，最好的優(yōu)化就是另起爐灶。
畢竟Hadoop技術(shù)已經(jīng)很多年了，當(dāng)下的軟硬件環(huán)境已與當(dāng)初大不相同，系統(tǒng)重構(gòu)也在情理之中。
與其等別人來(lái)革HDFS的命，不如自我革命。目前看，Ozone的確給用戶提供了一個(gè)新選擇。
就好像CDH和HDP最終融合成了CDP一樣，HDFS和S3也可以融合成Ozone。
總之，Ozone站在Hadoop這個(gè)巨人的肩膀上，設(shè)計(jì)之初就是為了替換掉HDFS，青出于藍(lán)而勝于藍(lán)。
潭主家的“存儲(chǔ)一哥”
早年間接觸過(guò)Ceph，也搞過(guò)HCP（Hitachi Content Platform）對(duì)象存儲(chǔ)，這些經(jīng)驗(yàn)對(duì)潭主理解Ozone大有裨益。
特意查了一下自家的HCP，發(fā)現(xiàn)影像文件已經(jīng)20多億個(gè)了，存儲(chǔ)容量也小2PB。不過(guò)查詢過(guò)程中明顯感覺到元數(shù)據(jù)響應(yīng)緩慢，估計(jì)快該擴(kuò)容了。
言歸正傳，再來(lái)說(shuō)說(shuō)Ozone的核心概念：
- Volume：通常表示用戶、業(yè)務(wù)，與HCP中的租戶（Tenant）對(duì)應(yīng)
- Bucket：通常表示業(yè)務(wù)、應(yīng)用，與HCP中的命名空間（Namespace）對(duì)應(yīng)
- Key：對(duì)應(yīng)的就是實(shí)際的Object
Ozone的存儲(chǔ)路徑為/Volume/Bucket/Key，一個(gè)業(yè)務(wù)可以對(duì)應(yīng)一個(gè)或多個(gè)Volume，每個(gè)Volume可以包含多個(gè)Bucket，在訪問(wèn)方式上Ozone實(shí)現(xiàn)了ofs和o3fs的適配和協(xié)議封裝。
值得注意的是，HCP里面有文件夾的概念，就是說(shuō)對(duì)象文件有層次結(jié)構(gòu)，但Ozone在設(shè)計(jì)上是扁平的，目錄是一個(gè)“偽目錄”概念，是文件名的一部分，統(tǒng)一作為Key而存在。
Ozone的體系架構(gòu)
介紹完了概念，再看看Ozone的體系架構(gòu)（如上圖）：
- OM（Ozone Manager）：通過(guò)RocksDB的K-V方式管理Namespace，Raft協(xié)議保持高可用，Shardig實(shí)現(xiàn)水平擴(kuò)展
- SCM（Storage Container Manager）：用于Ozone集群管理，負(fù)責(zé)分配Block，跟蹤SC復(fù)制狀態(tài)
- DataNode：負(fù)責(zé)向SCM匯報(bào)SC狀態(tài)
- SC（Storage Container）：Ozone的實(shí)際存儲(chǔ)單元
- Recon Server：用于監(jiān)控Ozone集群
Ozone做了架構(gòu)優(yōu)化，上層實(shí)現(xiàn)職能分離，OM負(fù)責(zé)管理Namespace，SCM負(fù)責(zé)管理Storage Containers。
下層實(shí)現(xiàn)了一個(gè)叫Hadoop Distributed Data Store（HDDS）的高可用、塊存儲(chǔ)層。
Ozone中的一個(gè)DataNode包括多個(gè)Storage Container，每個(gè)SC的容量（默認(rèn)5GB，可配置）遠(yuǎn)大于Hadoop中Block容量（默認(rèn)128MB），這種設(shè)計(jì)使得每個(gè)DN發(fā)送給SCM的Container-Report系統(tǒng)壓力要遠(yuǎn)遠(yuǎn)小于傳統(tǒng)Hadoop集群的Block-Report。
Storage Container作為Ozone的基礎(chǔ)存儲(chǔ)和復(fù)制單元，類似于一個(gè)“超級(jí)塊”，通過(guò)其內(nèi)置RocksDB（key記錄BlockID，Value記錄object的文件名、偏移量和長(zhǎng)度），實(shí)現(xiàn)對(duì)小文件的塊管理。
Ozone，新一代的“融合”數(shù)據(jù)湖存儲(chǔ)
在網(wǎng)上看到之前某互聯(lián)網(wǎng)大廠專家的分享，現(xiàn)網(wǎng)同時(shí)在使用HDFS和Ceph。
HDFS主要用于大數(shù)據(jù)分析場(chǎng)景，但機(jī)器學(xué)習(xí)場(chǎng)景中受限于大量小文件而使用Ceph。
不過(guò)，在介紹Ozone的Roadmap時(shí)說(shuō)未來(lái)會(huì)在存儲(chǔ)層引入Ozone。
開源世界，風(fēng)起云涌，前腳剛看過(guò)Alluxio，覺得眼前一亮，這會(huì)兒再看Ozone，更是金光閃閃。
Ozone既是Hadoop的優(yōu)化升級(jí)版，又能“分層”解決海量小文件的對(duì)象存儲(chǔ)，再加上對(duì)云原生CSI的支持，讓其成為了新一代“融合”存儲(chǔ)。
Ozone這股新勢(shì)力著實(shí)讓潭主不敢小覷，希望未來(lái)能有機(jī)會(huì)做些實(shí)踐。
存儲(chǔ)圈，數(shù)據(jù)不息，折騰不止！
?
