Ozone的S3語義和FS語義
前言
在Ozone中,眾所周知,它最開始設計仿照的原型即是S3語義的儲存模式:基於volume, bucket, key三層的儲存模型,底層的key是實際儲存的物件檔案。至於裡面對於volume, bucket, key級別的API操作,基本也是實現了S3現有支援的API操作。不過Ozone作為同樣Hadoop生態圈內的一個專案,它需要與現有別的系統框架能夠很好地協調工作。因此,Ozone內部實現了Ozone FS的語義,意思是說,外部別的框架可以使用檔案系統API的方式來使用Ozone。簡單來說,就是client可以對Ozone呼叫執行createFile,mkdir, listFile等等這樣檔案系統的API操作。至於這個裡面Ozone是如何做FS API和實際底層Ozone bucket, key的儲存,那是另外的原理實現了。OK,本文筆者要聊的重點是這裡提到的Ozone內部的S3語義和FS語義。
Ozone的S3語義和FS語義
光看標題的術語,可能很多人不太能夠理解,這裡筆者給出具體的例子來說明。
S3語義,就是仿照S3儲存/volume/bucket/key級別的儲存模式,其中這裡的key名稱是可以不帶任何限制的,比如key裡可以帶有 … 和 / 這種特殊的字元。
比如說是S3語義下,使用者可以存入一個比較偏的key名稱如下:
Key名稱:/dir1dir2//…//dir3///file1
全路徑:/volume/bucket/dir1dir2//…//dir3///file1
但是在FS語義下,我們就要對key的名稱做標準化處理了,因為“/”字元在FS語義裡代表的是一個目錄的意思了。FS語義的意思簡單理解是Ozone在對外使用上能夠用檔案系統的結構組織方式來訪問。
因此Ozone內部在啟用FS語義後,它會做一件重要的事情:Key名稱的標準化(normalize)處理。
這個normalize操作裡,多餘的“/”會被移除掉。這樣的話,我們就會得到一個乾淨的合理的key name。比如上面的key將會變為如下:
/dir1/dir2/…/dir3/file1
但是FS語義和原有S3語義不僅僅只有這一個差別,FS語義要保證其執行的正確性,比如上面這個路徑對應的是一個檔案路徑,在建這個檔案之前,我們需要保證其前面的目錄都必須存在。這個時候如果它不存在,那麼實際上我們還得額外執行put key名稱為/dir1/, /dir1/dir2/, /dir1/dir2/…/, /dir1/dir2/…/dir3/的操作,就是遞迴執行父目錄的操作。
區別圖如下:
Operation | S3語義 | FS語義 |
---|---|---|
CreateKey(dir1/dir2/dir3/file1) in volume vol, bucket buck | /vol/buck/dir1/dir2/dir3/file1 | /vol/buck/dir1/, /vol/buck/dir1/dir2/, /vol/buck/dir1/dir2/dir3/, /vol/buck/dir1/dir2/dir3/file1 |
我們可以看到在同樣建立一個新key的情況下,S3語義下需要往Ozone key表裡插入1行key,而FS語義下就要建立出4個key來保證別的FS語義操作的正常執行。
Ozone S3語義和FS語義的聯合使用
因為Ozone目前同時支援了S3語義和FS語義的實現,那麼就會存在一種混合使用的場景:
- 用S3語義的進行key的寫入,但是用FS語義進行資料讀取
- 用FS語義進行資料寫入,用S3語義進行讀取
在上面兩種情況中,第一種情況顯然更加複雜一些。因為S3語義對於key名稱沒限制,而且只建一條key,這樣如果直接用FS語義去找,顯然大概率會報key找不到的錯誤。
因此對於這種特殊的使用場景,Ozone內部新增了一個配置ozone.om.enable.filesystem.paths來表明Ozone是否將會把key名稱用FS語義的方式來讀取。
<property>
<name>ozone.om.enable.filesystem.paths</name>
<tag>OZONE, OM</tag>
<value>false</value>
<description>If true, key names will be interpreted as file system paths.
"/" will be treated as a special character and paths will be normalized
and must follow Unix filesystem path naming conventions. This flag will
be helpful when objects created by S3G need to be accessed using OFS/O3Fs.
If false, it will fallback to default behavior of Key/MPU create
requests where key paths are not normalized and any intermediate
directories will not be created or any file checks happens to check
filesystem semantics.
</description>
</property>
如果這個配置被啟用後,那麼S3語義下操作的key會在原有執行步驟中多加2步:
- 1)進行key的標準化處理
- 2)進行額外parent key的建立,如果需要的話(例子如上所示)。
以上就是本文闡述主要內容了,相關詳細內容可查閱引用連結處。
引用
[1].https://issues.apache.org/jira/browse/HDDS-4097 . S3/Ozone Filesystem inter-op
相關文章
- 基於檔案語義實現S3介面語義的注意事項S3
- HTML基本語法和語義HTML
- 【原創】訊息佇列的消費語義和投遞語義佇列
- 語法與語義
- 語義網路術語
- html語義化HTML
- HTML 語義化HTML
- 語義化版本
- nlp語義理解
- web語義化之SEO和ARIAWeb
- 中考常見同義詞和同義短語總結
- c 語言中巨集定義和定義全域性變數的區別變數
- 31-語義分割
- volatile的語義與實踐
- 樹的定義 基本術語
- Python語法的轉義字元Python字元
- 聊聊前端語義化的今天前端
- ABAP 程式語言裡的 Reference Semantic - 引用語義
- NLP需要回歸語言本質,走向語義和計算的融合
- HTML基本語法和語義寫法規則與例項HTML
- 語義化版本慣例
- 如何自定義python語法.Python
- 大話Python類語義Python
- 資料定義語言(DDL)
- HTML 語義化佈局HTML
- List Incarnation 語法含義
- 語義分割的標準度量MIoU
- c語言的定義與宣告C語言
- 三句義的程式語言
- 語義理解和研究資源是自然語言處理的兩大難題自然語言處理
- 微控制器-C語言-定義和申明C語言
- 條件佇列大法好:wait和notify的基本語義佇列AI
- 對HTML語義化的一些理解和記錄HTML
- 離散數學——2.命題邏輯公式語法和語義公式
- Web 3.0 術語及其簡單英語定義Web
- 多執行緒的指令重排問題:as-if-serial語義,happens-before語義;volatile關鍵字,volatile和synchronized的區別執行緒APPsynchronized
- VARCHART XGantt系列教程:使用顏色來定義語義
- OLAP多維語義模型(一)模型