Hadoop inode到路徑

我使用'hdfs oiv'命令將fsimage讀入xml文件。Hadoop inode到路徑

hdfs oiv -p XML -i /../dfs/nn/current/fsimage_0000000003132155181 -o fsimage.out

根據我的理解，的FsImage應該存放「塊映射」之類的文件是怎麼分成塊，每個塊存儲。但是，這裏是記錄inode在輸出文件中的樣子。

<inode> 
    <id>37749299</id> 
    <type>FILE</type> 
    <name>a4467282506298f8-e21f864f16b2e7c1_468511729_data.0.</name> 
    <replication>3</replication> 
    <mtime>1442259468957</mtime> 
    <atime>1454539092207</atime> 
    <perferredBlockSize>134217728</perferredBlockSize> 
    <permission>impala:hive:rw-r--r--</permission> 
    <blocks> 
     <block> 
      <id>1108336288</id> 
      <genstamp>35940487</genstamp> 
      <numBytes>16187048</numBytes> 
     </block> 
    </blocks> 
</inode>

不過，我期待像，HDFS文件路徑，該文件是怎麼分解成小塊，其中每一塊已存儲（比如哪臺機器，其中本地FS路徑...等...）

是否有映射的任何地方包含名稱服務器上：

的HDFS路徑索引節點映射
塊標識到本地文件系統路徑/磁盤位置映射？

來源

2016-02-03 B.Mr.W.

有點晚了，但因爲我現在正在研究這個問題，並且偶然發現了你的問題。

首先，有點上下文。

（我用Hadoop 2.6工作）

名稱服務器是負責維護INodes，其是在存儲器（虛擬）文件系統結構的表示中，同時Blocks由數據節點保持。我認爲有幾個方面的原因名稱節點不保持其餘的信息，如鏈接到數據存儲中的每個INode數據節點：

這將需要更多的內存來代表所有該信息（內存是實際限制可寫入HDFS集羣的文件量的資源，因爲整個結構在RAM中保存，以便更快地訪問）
會在名稱節點上產生更多的工作量，以防例如，如果文件從一個節點移動到另一個節點，或者安裝了新節點並且需要將文件複製到該節點。每次發生時，名稱節點都需要更新其狀態。
靈活性，因爲inode是一個抽象概念，這樣就增加了鏈接將其綁定到確定的技術和通信協議

現在回到你的問題：

的的FsImage文件已經包含了映射到HDFS路徑。如果你仔細看看XML，每個INode，不管它的類型是否有ID（在你的情況下它是37749299）。如果您仔細查看文件，可以找到<INodeDirectorySection>部分，該部分具有父代和子代之間的映射關係，並且此ID字段用於確定關係。通過<name>屬性，您可以輕鬆確定您在HDFS瀏覽器中看到的結構。
此外，你有<blocks>部分，它有塊ID（在你的情況下它是1108336288）。如果仔細查看Hadoop的源代碼，可以在DatanodeUtil的中找到方法idToBlockDir，它提供瞭如何在磁盤上組織文件並執行塊ID映射的提示。

基本上原來的id被移位了兩次（16位和8位）。

int d1 = (int)((blockId >> 16) & 0xff); 
int d2 = (int)((blockId >> 8) & 0xff);

，最終目錄使用獲得的值內置：

String path = DataStorage.BLOCK_SUBDIR_PREFIX + d1 + SEP + DataStorage.BLOCK_SUBDIR_PREFIX + d2;

凡塊是使用其採用blk_<block_id>命名格式文件中保存。

我不是Hadoop專家，所以如果有人更好地理解這一點，可以糾正我邏輯中的任何流程，請這樣做。希望這可以幫助。

來源

2017-01-24 13:53:30 Serhiy

Hadoop inode到路徑

回答

相關問題