2. 程式人生 > >HDFS物件儲存--Ozone架構設計

HDFS物件儲存--Ozone架構設計

阿新 • • 發佈：2018-12-31

前言

現在做雲端儲存的公司很多,舉2個比較典型的AWS的S3和阿里雲.他們都提供了一個叫做物件儲存的服務,就是目標資料是從Object中進行讀寫的,然後可以通過key來獲取對應的Object,就是所謂的key-object的儲存.這樣的好處就在於使用者使用起來很方便的,不需要走冗雜的操作流程.但是本文所要闡述的則是HDFS中的物件儲存,對於這樣的需求,Hadoop作為一套完善的分散式系統,當然也要與時俱進,在HDFS-7240中進行了實現,目前此功能真在開發中,名叫Ozone,內部有很多的概念與業界的都是類似的,例如Bucket,Object等.下面是本人對於Ozone設計文件的一個譯文,可能會有翻譯不到位的地方,附上原文連結:

Ozone-architecture-v1.pdf

目錄

  1. 介紹
    1.1 基本要求
    1.2 大小要求

  2. 高層次設計
    2.1 與HDFS共享Datanode Storage儲存
    2.2 Storage Container儲存容器
    2.3 Storage Container Identifier儲存容器標誌符
    2.4 Storage Container儲存容器服務的呼叫
    2.5 Datanode中的Ozone Handler
    2.6 Storage Container Manager儲存容器管理器

  3. 具體實現
    3.1 物件鍵值到儲存容器的對映
    3.2 範圍分割槽Vs雜湊分割槽
    3.3 bucket到儲存容器的對映
    3.4 Storage Container儲存容器的要求
    3.5 Storage Container儲存容器實現要點
    3.6 Pipeline資料一致性

  4. 未來工作
    4.1 Ozone API
    4.2 叢集層級API
    4.3 Storage Volumes層級API
    4.4 Bucket層級API
    4.5 Object層級API

  5. 引用

介紹

Ozone提供了一個key-object鍵值-物件儲存的服務,類似AWS的S3服務. Key和Object物件是隨機的位元組陣列.單個key的大小期望是小於1k,但是values物件可以從小到幾百位元組大到幾百兆.鍵值/物件被組織進了bucket的概念中.一個bucket擁有唯一的key集合.Bucket存在於Storage-Volume中,並且在Storage-Volume中擁有唯一的名字.一個storage volume擁有全域性唯一的名字.更近一步的說,storage volume對buckets和儲存的資料有配額上的限制.在私有云中,它可以被用來建立給使用者(例如home目錄),工程專案,或者租有者.管理員可以分配一定配額限制的私有storage volume給個體使用者或者公有的共享storage volume.在公有云中,多storage volume可以以獨立的配額分配在每個雲中.
一個bucket被2部分名字的組合唯一標識: storage-volumeName/bucketName

.一個物件的名字被storage-volumeName/bucketName/objectKey 3部分所標識.
我們的模式類似於Azure Blob Storage(WASB).他們的bucket在每個帳戶中是唯一的.但是,我們用storage volume來取代了這個帳戶概念.因此相比之下,S3的bucket在所有帳號中保持唯一.
資料的組織結構可以以下面的圖形進行展示.
這裡寫圖片描述

基本要求

Ozone中基本的操作如下(API方法在文件尾部將會給出):

  • 管理員建立Storage Volume.
  • 建立/刪除 buckets.每個bucket擁有一個獨立的URL.Buckets不能被重新命名.只有storage volume的所屬者或所屬組才能建立/刪除volume中的bucket.
  • 在一個storage volume中列出buckets列表.
  • 根據給定的key在bucket中建立/刪除object物件.物件的資料或值可以流式的傳輸到Ozone服務中.當物件被寫滿的時候將只會允許讀操作.同時不保證物件的區域性寫.
  • 列舉出bucket的內容
  • 建立/更新/刪除 buckets的ACL訪問控制列表

大小要求

本節列舉了少部分的限制值來具體化一些要求.下面是目標版本1的一些指標:

  • Storage Volume名字: 3~64位元組
  • Bucket 名稱: 3~64位元組
  • Key大小: 1KB
  • Object大小: 5G
  • 系統總buckets數量: 1000w
  • 每個bucket中物件數量: 100w
  • 每個storage volume中的bucket數: 1000

Ozone元資料包括以下內容:

  • Storage Volume層級元資料
    • Storage volume所屬者
    • Storage Volume名稱
  • Bucket層級元資料
    • Bucket所屬者: 擁有此bucket中資料的所屬使用者.
    • Bucket ACL訪問控制資訊
    • 全域性唯一的Bucket名稱
    • Bucket Id: 與bucket相關的系統產生的數字型的標識

高層級設計

與HDFS共享Datanode資料儲存

DataNode同時為HDFS和Ozone儲存資料.Ozone的資料用的是獨立的blockPool並擁有獨立的blockPool Id.也就是說可以同時存在多種volume名稱空間,每個volume有屬於自己的block pool.同樣的可以同時存在多個獨立的Ozone名稱空間在所屬的block pool下.一個DN可以同時儲存多個HDFS和Ozone的block pool.此關係結構如下圖所示:
這裡寫圖片描述

Storage Container容器

一個storage container從概念上來說,指的是用來儲存Ozone資料(就是bucket中的資料)和Ozone元資料的一個儲存單元.Storage container與HDFS的block一樣,共同儲存於DataNode上.但是與HDFS不同的一點,Ozone沒有一個類似於NameNode的中心節點,相反地,他是一個分離的元資料的儲存.這些元資料分散式的存在於各個storage container中.每個storage container以whole的形式存在(類似於HDFS中的block).我們對container副本的成功操作保證了強一致性.Storage container的最大值的大小取決於他的副本複製能力以及從節點故障中恢復的能力.最大值的大小是可配的,但是他至少要大於一個簡單物件所允許的最大值.

一個bucket可以擁有百萬數量級的物件並且在儲存的大小級別上可以達到T級別,這遠遠大於一個storage container.因此一個bucket會被分為很多partion分割槽,每片分割槽會儲存在一個container中.(一個storage container可以包含最大值數量的的分割槽,然而物件只能來自一個bucket.)在我們的初始設計實現中,一個object物件是完全存在於一個單一的container中,這麼做後面可能會輕鬆一些.

Storage container是靠DataNode來實現的(使用者可以通過配置來禁用此功能如果使用者只需要使用HDFS的block功能).本節定義了storage container的一些語義和要求.Storage container需要儲存以下多種型別的資料,每類資料有略微不同的語義:

  • Bucket元資料

    • 個體單元的資料是非常小的-kb級別.每個storage container可以儲存上百萬bucket的元資料.
    • 這點要求能夠更新,因為一個bucket的ACL是能夠被更新的,並且要能保證操作的原子性.
    • 滿足基本的Get/Put的API設計已經足夠.
    • 在container中能執行列表操作以便展示所有的bucket.

  • Bucket資料

    • Storage container需要能夠儲存小到幾百kb大到上百mb的物件資料.
    • 物件需要通過物件的key進行訪問(所以container儲存資料也必須包含儲存物件的索引).
    • 必須能支援個體物件讀寫的流式API.
    • 資料中的物件不支援追加寫以及原地更新.

在後面的小節,我們將闡述DataNode如何實現storage container來達到以上的要求.

Storage Container識別符號

每個storage container都被獨立的storage container識別符號所獨立標識.它是一個邏輯上的獨立標識(類似於HDFS中的blockId)並且不包含真正意義上container的網路位置.

物件的key會對映到storage container識別符號.這個識別符號會傳入storage container manager管理器去定位包含目標物件container所在的DataNode.類似的,bucket的名稱也會對映到storage container識別符號,這個container儲存有bucket的元資料.在後面的小節中,我們會具體提到這個對映關係是如何實現的.Storage container識別符號是64位的,類似於hdfs中的block id.在未來,我們將把它擴充套件到128位.但是那將會是一個大的改變,因為我們想盡可能的複用hdfs的block管理器相關的程式碼.

Storage Container Service中的過程呼叫

下面的圖形展示了Ozone中的典型過程呼叫,其中主要包含了Storage Container Service服務和Ozone Handler處理器:
這裡寫圖片描述

DataNode中的Ozone Handler

Ozone handler是Ozone中的模組元件,被DataNode所持有並對外提供Ozone服務.Handler包含了一個http server並實現了Ozone REST方式API.Ozone Handler與storage container manager管理器互動來查詢container的位置.與DataNode中的storage container互動實現不同的操作.這個功能元件可以被禁用如果使用者只想要使用HDFS而不需要Ozone功能.

Storage Container Manager管理器

Storage container manager管理器非常類似於HDFS中block manager中的管理功能.Storage container manager管理器從各個DataNode中收集心跳,處理storage container的報告並跟蹤每個storage container的位置.他包含了一個storage container對映圖,以此提供了字首匹配的方式去查詢storage container.之前提到過DN能夠同時儲存HDFS和Ozone的資料.Ozone的資料所屬的是分離的block pool並且用的是Storage container manager管理器提供的分離的blockPool Id.圖形展示效果如下.我們計劃儘可能的複用NameNode已有的block管理部分的程式碼實現來實現container的管理.我們同樣可以複用DataNode 中block pool service服務的實現程式碼.
這裡寫圖片描述

具體實現

對映object-key到storage container

在我們的設計中,我們計劃使用雜湊分割槽的模式來對映key到他所儲存的storage container.Key的值是被雜湊計算的,同時會帶上bucketId的字首.結果值通過字首匹配可以對映到storage container.當container逐漸變大,我們會對此進行分割,並用擴充套件雜湊演算法重新對映key到對應container的對映關係.Storage container manager管理器會儲存這些對映關係到字首樹中以此實現高效的字首匹配.每個bucket都有屬於自己的字首樹.

範圍分割槽 vs 雜湊分割槽

在資料庫和物件儲存中,範圍分割槽是另外一項比較受歡迎的用來對key進行分割槽的技術.以下是2個技術的簡短的比較.我們偏向於使用雜湊分割槽的方法,因為它相比較能更簡單的去實現並且能滿足我們的需求.

  • 範圍分割槽模式需要範圍索引.範圍索引同樣非常巨大並且需要分散式的儲存.這複雜化了分割多個分割槽的操作,因為他額外需要索引的更新.
  • 範圍分割槽在搜尋過程中多引進了一種額外的跳躍,當第一次範圍索引需要去讀.
  • 範圍分割槽同樣有熱點問題.相似名字的key會造成相同範圍內的大併發量的訪問.
  • 然而,範圍分割槽提供了有序訪問以及有序列表展示的優勢.但是我們認為對於一個物件儲存而言,一個有序的訪問並不是一個重要的要求.列表有序的展示可以在後面的階段內用二級索引的方式來實現.我們同樣相信對於目前的設計而言是足夠靈活的,如果我們在未來想要對此新增範圍索引的話.

對映bucket到storage container

Bucket的元資料同樣儲存在storage container中.Bucket的名字是被用來作為key做雜湊計算的.多個bucket的元資料可以存在於storage container中.我們在所有與storage container關聯的bucket中設計了一個特殊的bucketId,bucketId字首中會帶上container Id.

Storage Container要求

Storage Container儲存在各個DataNode上.對於Storage Container我們有以下的要求:

  • Storage Container能夠可靠地被複制.
  • Storage Container保持嚴格的一致性.
  • Storage Container對於內部儲存的物件能提供高效的鍵值對的查詢方式.
  • Storage Container必須能夠以流式的方式對object進行讀寫操作.
  • Storage Container必須能夠支援get/put介面,來儲存和更新bucket元資料.
  • Storage Container對於內部儲存的bucket必須能提供一個原子的更新操作.
  • Storage Container能夠進行分裂當他們達到一定大小限制的時候.

Storage Container的實現要點

  • 我們傾向於儘可能的複用HDFS現有的block pool管理方面的功能程式碼.因此我們會將StorageContainer作為Block類的擴充套件類.一個hdfs block由一個識別符號,生成時間記錄和大小組成.這3個屬性同樣可以應用到storage container中.
  • 為了保證一致性和永續性,storage container實現了少量的原子性和持久化的操作,比如事務.Container對這些操作提供了可靠的保證.在第一階段中,我們實現以下事務操作:
    • Commit: 這個操作促進了物件從被寫到最後的確認結束.一旦這個操作成功,這個container就會保證物件是可讀的.
    • Put: 這個操作適用於小規模的寫操作,例如元資料的寫動作.
    • Delete: 刪除物件.
  • Container中的每個事務會有一個事務ID,並且必須被持久化.
  • 我們計劃為storage container實現一個新的data-pipeline,因為他要求一個不同型別的更新和恢復語義操作.在下一小節中我們會給出data-pipeline的設計概述.
  • 我們正在考慮利用leveldbjni來作為storage container的原型設計,leveldbjni正好能滿足我們storgae container鍵值對儲存的需求.

Data Pipeline一致性

Data-Pipeline管道鏈流式複製副本資料到container中.Container的副本也有產生記錄類似於HDFS的block.每個pipeline副本的標記記錄在pipeline建立的時候會被更新,所以任何舊的container會被撤銷.HDFS在block恢復的時候額外使用了block length副本長度來判斷副本是否已經更新到最新.類似地, storage container用了事務ID來判斷container副本是最新的.更多的pipeline設計細節將會上傳到對應hdfs jira上.

未來工作

我們並沒有在文件中仔細闡述下述的要求,但是我們將會在後面階段的工作中實現這些功能:

  • High availability: 高可用性,Storage container manager管理器需要是高可用的服務.一個解決方案是利用HDFS Journal的QJM機制實現Active/Standby的方式.另外一種方式做成所有Active的服務配上Paxos環的方式.我們會在第二階段的工作中對這個問題進行社群內的討論.
  • Security: 安全,我們可以利用HDFS的kerberos認證機制
  • Cross cool replication: 跨型別副本拷貝,我們將會使用一種對HDFS和Ozone都有利的方式去實現這個功能.

Ozone API

Cluster層級APIs

  • PUT StorageVolumes
    • API - PUT /admin/volume/{StorageVolume}
      • 建立一個storage volume
      • 只有管理員才允許呼叫這個操作
  • HEAD StorageVolume
    • API - HEAD /admin/volume/{StorageVolume}
      • 檢測Storage Volume是否存在
      • 只有管理員才能呼叫這個操作
  • GET
    • 列出叢集中所有的Storage Volume.
  • DELETE Storage Volumes
    • API - DELETE /amin/volume/{StorageVolume}
      • 刪除一個volume如果他是空的

Storage Volume層級APIs

  • GET Buckets
  • API - GET /
    • 利用使用者的認證資訊登入
    • 返回請求傳送者所擁有的buckets列表
  • Get User Buckets
    • API - GET /admin/user/userid
      • 利用使用者認證資訊進行登入, 如果他/她有許可權閱讀其他使用者的資訊,返回那個使用者所獨有的buckets列表資訊.

Bucket層級API

  • LIST objects in a bucket
    • API - GET/{bucketName}
      • 返回buckets中最多1000個數量的物件key
  • PUT bucket
    • API - PUT/{bucketName}
      • 為請求傳送者建立bucket
    • GET/PUT Bucket ACL
      • API - /{Bucket}?acl
      • 允許使用者獲取/設定bucket的ACL
  • HEAD bucket
    • API - HEAD/{bucketName}
    • 檢查bucket是否存在,前提是請求傳送者有許可權訪問此bucket
  • DELETE bucket
    • API - DELETE/{bucketName}
      • 刪除bucket如果此bucket為空的話

Object層級APIs

  • GET object
    • API - GET/{bucketName}/{key}
      • 返回給定key所代表的物件值,如果這個值存在
      • 在第一階段暫不支援ACL,因此只有所屬使用者才能讀寫自身的bucket.
  • PUT object
    • API - PUT/{bucketName}/{key}
      • 在bucket中建立一個物件
      • 在第一階段暫不支援ACL,因此只有所屬使用者才能讀寫自身的bucket.
      • 不支援區域性的上傳,只有物件全部上傳成功了才被認為是一次成功的操作.
  • HEAD object
    • API - HEAD/{bucketName}/{key}
      • 檢測物件是否存在
      • 在第一階段只有bucket的所屬使用者才能呼叫此操作
  • DELETE object
    • API - DELETE/{bucketName}/{key}
      • 刪除物件

引用

相關推薦

HDFS物件儲存--Ozone架構設計

前言 現在做雲端儲存的公司很多,舉2個比較典型的AWS的S3和阿里雲.他們都提供了一個叫做物件儲存的服務,就是目標資料是從Object中進行讀寫的,然後可以通過key來獲取對應的Object,就是所謂的key-object的儲存.這樣的好處就在於使用者使用

DAOS 分散式非同步物件儲存｜架構設計

分散式非同步物件儲存 ([DAOS](https://github.com/daos-stack)) 是一個開源的物件儲存系統，專為大規模分散式非易失性記憶體 (NVM, Non-Volatile Memory) 設計，利用了SCM(Storage-Class Memory) 和 NVMe(Non-Volat

為什麼結構化程式設計、面向物件程式設計、軟體工程、架構設計最後沒有成為軟體領域的銀彈

為什麼結構化程式設計、面向物件程式設計、軟體工程、架構設計最後沒有成為軟體領域的銀彈？ 從計算機語言開始講，一步一步的概述和講解，最終會有一個結論，大家往後看，即可明白。 1.機器語言(1940年之前) 機器語言，直接使用二進位制碼0和1來表示機器可以識別的指令和資料。 比如0100011111000

HDFS分散式儲存架構和讀寫機制總結

　如上圖所示，HDFS也是按照Master和Slave的結構。分NameNode、SecondaryNameNode、DataNode這幾個角色。 　　NameNode：是Master節點，是大領導。管理資料塊對映；處理客戶端的讀寫請求；配置副本策略；管理HDFS的名稱空間； 　　

Nginx + FastDFS檔案儲存系統服務對映架構設計

由於我們做的國外遊戲運營業務，有大量的遊戲檔案，圖片等資源都需要儲存，而考慮到成本問題，我們都是自己買阿里雲伺服器，然後自己手工搭建檔案儲存服務，之前都是按教程安裝，然後使用；後來我們為了安全，下載遊戲連結防盜鏈，然後遊戲下載連結都是動態生成，而且想做到遊戲連結2分鐘有效，所以必須自己在Ng

MySQL架構設計——MyISAM儲存引擎與InnoDB儲存引擎

——從MySQL5.1開始，MySQL引入了一個新的概念，外掛式儲存引擎體系結構。可以做到儲存引擎層與SQL層各自更為獨立，耦合更小，最重要的是方便了儲存引擎的載入與移出，可以做到執行時載入新的儲存引

阿里雲OSS物件儲存URL簽名授權下的PHP服務端和iOS端上傳檔案的設計

阿里雲的OSS物件儲存服務,具有易用,高可靠,高安全,低成本的特性,對於在圖片,音視訊儲存服務的應用非常適用,可以不搭建自己的儲存伺服器. 本來將介紹OSS儲存服務中在服務端進行URL簽名授權,然後移動端進行直傳功能的實現.除此之外還可以使用STS臨時授權,構造授權引數,返回給客戶端,由客戶端自

架構設計：系統儲存（18）——Redis叢集方案：高效能

1、概述 通過上一篇文章（《架構設計：系統儲存（17）——Redis叢集方案：高可用》）的內容，Redis主從複製的基本功能和進行Redis高可用叢集監控的Sentinel基本功能基本呈現給了讀者。雖然本人並不清楚上一篇根據筆者實際工作經驗所撰寫的文章有什麼重

讀《分散式物件儲存——原理、架構及 GO 語言實現》

單機 PUT 方式上傳介面，GET 下載介面。 分散式的，使用者客戶端，介面服務，儲存服務介面，本地磁碟。 上傳介面 定位介面   之後就沒有一一統計書中實現的介面了。 書中說還有視訊，我還沒有看。一本講分散式物件儲存系統的書，程式碼是用 GO 實現的，書

Unity應用架構設計(8)——使用ServiceLocator實現物件的注入

物件的 『注入』 是企業級軟體開發經常聽到的術語。如果你是一個 Java 程式設計師，一定對注入有著深刻的映像。不管是SSH框架還是SSM框架，Spring 全家桶永遠是繞不過去的彎。通過依賴注入，可以有效的解耦應用程式。在uMVVM框架中，我提供了另外一種物件注入的方式，稱為Service Locator

.NET應用架構設計—面向物件分析與設計四色原型模式（彩色建模、領域無關模型）（概念版）

閱讀目錄： 1.背景介紹 2.問自己，UML對你來說有意義嗎？它幫助過你對系統進行分析、建模嗎？ 3.一直以來其實我們被一個縫隙隔開了，使我們對OOAD遙不可及 4.四色原型模式填補這個歷史縫隙，讓我們真的看見OOAD的希望 5.在四色原型上運用彩色建模增強視覺衝擊力 6.通過四色原

官方HDFS架構設計原理說明(上)

玩了HDFS已經有好多年了，之前一直都是邊學邊用，直到現在才真正有時間記錄一下學到的知識O(∩_∩)O 1. 引言 HDFS全稱是Hadoop Distributed File System，Hadoop分散式檔案系統，顧名思義它是一個分散式的檔案系統，設計於執行在普通硬體

架構設計：系統儲存（29）——分散式檔案系統Ceph（管理）

3-3. Ceph常用命令 Ceph檔案系統提供的運維命令主要是按照Ceph中的工作角色/工作職責進行劃分的，例如有一套專門對OSD節點進行管理的命令、有一套專門對PG進行管理的命令、有一套專門對MDS角色進行管理的命令……您可以使用ceph –help進行命

HDFS架構設計之Hadoop核心

概述：HDFS即Hadoop Distributed File System分散式檔案系統，它的設計目標是把超大資料集儲存到分佈在網路中的多臺普通商用計算機上，並且能夠提供高可靠性和高吞吐量的服務。分散式檔案系統要比普通磁碟檔案系統複雜，因為它要引入網路程式設計，分散式檔案系統要容忍節點故障也是一個很大的挑戰

GIS+=地理資訊+雲端計算技術——私有云架構設計（3）儲存資源規劃

-------------------------------------------------------------------------------------- 宗旨：專注於"G

架構師小跟班：教你從零開始申請和配置七牛雲免費OSS物件儲存（不能再詳細了）

背景 之前為了練習Linux系統使用，在阿里雲上低價買了一臺伺服器（網站首頁有活動連結，傳送門），心裡想反正閒著也是閒著，

【大白話系列】MySQL 學習總結 之 初步瞭解 InnoDB 儲存引擎的架構設計

一、儲存引擎 上節我們最後說到，SQL 的執行計劃是執行器元件呼叫儲存引擎的介面來完成的。 那我們可以理解為：MySQL 這個資料庫管理系統是依靠儲存引擎與存放資料的磁碟檔案進行互動的。 那麼 MySQL 有哪些儲存引擎呢？ 主要有 MyISAM、InnoDB、Memory等等。而現在網際網路中，基本都是使用

iOS分層架構設計

高內聚 持久層 移動 單例設計模式 用戶 不一定 需要 控制器 通過 大家都知道，在移動設計開發中有很多種模式，最常用的單例設計模式、MVC設計模式、工廠設計模式、KVO、通知、代理等等。使用設計模式的目的：為了代碼可重用性、讓代碼更容易被他人理解、保證代碼可靠性。而架

MySQL性能管理及架構設計 --- 理論篇

sql 沒有 -s 如果 innodb 吞吐量 ref fan 數據 MySQL性能管理及架構設計 一丶IO,內存,吞吐量理解 IO 是指設備與設備之間操作次數,比如mysql與php互插內存 是程序運行都在裏面執行吞吐量 是單位時

Hadoop架構設計、執行原理具體解釋

下一個 發現 job調度 mmap tin 文件復制 必須 new 最大 1、Map-Reduce的邏輯過程 如果我們須要處理一批有關天氣的數據。其格式例如以下： 依照ASCII碼存儲。每行一條記錄每一行字符從0開始計數，第15個到第18個字符為年第25個到第29個字