• <em id="t4pa9"></em>

    <em id="t4pa9"></em>
    <rp id="t4pa9"></rp>

  • <rp id="t4pa9"><acronym id="t4pa9"><u id="t4pa9"></u></acronym></rp>
    <li id="t4pa9"><object id="t4pa9"></object></li><dd id="t4pa9"><pre id="t4pa9"></pre></dd>

    <strong id="t4pa9"></strong>
    <progress id="t4pa9"><pre id="t4pa9"></pre></progress>
    <rp id="t4pa9"></rp>
    我要找:  
    您的位置:電源在線首頁>>行業資訊>>交流培訓>>Ozone | 數據湖存儲,“統一”和“融合”哪個更好?正文

    Ozone | 數據湖存儲,“統一”和“融合”哪個更好?

    2022/7/22 15:26:27   電源在線網
    分享到:

      

      作者:落風潭

      保險IT圈知名自媒體主理人

      關于Alluxio的文章讓潭主把注意力轉移到了大數據上。

      文中提及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是數據湖,而有人認為S3也是數據湖。

      換個角度,從線上公有云的視角看,S3是主流存儲,而到了線下的私有云,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多億個了,存儲容量也小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的容量(默認5GB,可配置)遠大于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這股新勢力著實讓潭主不敢小覷,希望未來能有機會做些實踐。

      存儲圈,數據不息,折騰不止!

       免責聲明:本文僅代表作者個人觀點,與電源在線網無關。其原創性以及文中陳述文字和內容未經本站證實,對本文以及其中全部或者部分內容、文字的真實性、完整性、及時性本站不作任何保證或承諾,請讀者僅作參考,并請自行核實相關內容。
    本文鏈接:Ozone | 數據湖存儲,“統一”和
    http:www.bhmgdyz.cn/news/2022-7/2022722152627.html
    文章標簽:
      投稿熱線 0755-82905460    郵箱  :news@cps800.com
    關于該條新聞資訊信息已有0條留言,我有如下留言:
    請您注意:
    ·遵守中華人民共和國的各項有關法律法規
    ·承擔一切因您的行為而導致的法律責任
    ·本網留言板管理人員有權刪除其管轄的留言內容
    ·您在本網的留言內容,本網有權在網站內轉載或引用
    ·參與本留言即表明您已經閱讀并接受上述條款
    用戶名: 密碼: 匿名留言   免費注冊會員
    關鍵字:
            
    按時間:
    關閉
    精品欧美黑人一区二区三区,国产色色色,国产老熟乱在线视频入口com,日韩无码观看
  • <em id="t4pa9"></em>

    <em id="t4pa9"></em>
    <rp id="t4pa9"></rp>

  • <rp id="t4pa9"><acronym id="t4pa9"><u id="t4pa9"></u></acronym></rp>
    <li id="t4pa9"><object id="t4pa9"></object></li><dd id="t4pa9"><pre id="t4pa9"></pre></dd>

    <strong id="t4pa9"></strong>
    <progress id="t4pa9"><pre id="t4pa9"></pre></progress>
    <rp id="t4pa9"></rp>