LabHub

ブログ

ブロックベースファイルシステムとは？ HDFSブロックファイルシステム

2023-09-02 · 32 分で読めます · #hadoop#hdfs

한국어English日本語

ファイルとブロック

一般的に使用するコンピュータでは、1つのファイルは複数のブロックに分割して保存され、ブロックサイズはほとんどの場合（OSや設定によって異なる場合がありますが）512バイトです。例えば、1MBのファイルを保存する場合、約20個の512バイトのブロックに分割して保存されることになります。

このブロックサイズが小さすぎると、ブロック数が増加してメタデータのオーバーヘッドが増大します。逆にブロックサイズが大きすぎると、空間の無駄が増加するリスクがあります。例えば、ブロックサイズが128MBの場合、1MBのファイルを保存しても5MBのファイルを保存しても128MBのブロックを割り当てなければならないため、そのファイルを保存した領域以外の空間は使用できません。

ブロックファイルシステムの利点

  1. 簡潔なメタデータ: 各ブロックのサイズが固定されているため、ファイルメタデータに各ブロックの位置とサイズを明示的に保存する必要がありません。これにより、メタデータの複雑さが軽減されます。

  2. 効率的なディスク使用: ブロックを固定サイズに分割することで、ディスクの空間配置を最適化し、ディスクの空き領域を最小化できます。これにより、ディスクの使用率が向上します。

  3. 高速なランダムアクセス: ブロックベースのアクセス方式は、任意の位置からデータにアクセスすることを容易にします。特定のブロックを見つけるための計算が単純であるため、ランダムアクセスの性能が向上します。

  4. 強力な耐障害性: 一部のブロックファイルシステムでは、ブロックレベルで追加のエラー検出および復旧メカニズムが提供されます。これらのメカニズムは各ブロックの整合性を確保し、エラーが発生した場合に該当ブロックのみを復旧できるようにします。

  5. 効率的なキャッシュおよびバッファ管理: ブロックを固定サイズで管理することで、システムのキャッシュとバッファ管理を最適化できます。これにより、データの読み書き操作の性能が向上します。

  6. ファイルサイズの動的拡張: ブロックベースのファイルシステムは、必要に応じて追加のブロックを割り当てたり返却したりして、ファイルサイズを動的に拡張または縮小できます。

  7. データフラグメンテーションの最小化: ファイルを一定サイズのブロックに分割することで、ディスク上のファイルのフラグメンテーションを減らすことができます。そのため、連続したディスク領域にデータを保存・読み取りでき、性能が向上します。

HDFSブロックサイズ：128MB

HDFS（Hadoop File System）はデフォルトで128MBというはるかに大きなブロックサイズを持っています。これは、Hadoopが本質的に大容量データを処理するために設計されており、ランダム処理よりもストリーミング処理に最適化されているためです。また、ブロックサイズが大きくなると、それだけメタデータのサイズも小さくなり、NameNodeのオーバーヘッドが減少するため、管理面で有利です。

Hadoop NameNodeの場合、一般的に100万個のブロックを保存するのに1GBのヒープメモリを使用すると言われています。

hadoop-128-blocks

128MBはどこから来るのか: dfs.blocksize

以下の内容はApache Hadoop 3.3.5を基準にしています。hadoop.apache.orgのstableドキュメントセットが指すバージョンであり、デフォルト値はメジャー／マイナーバージョンごとに変わりうるため、使用中のバージョンのhdfs-default.xmlを直接確認するのが最も正確です。

128MBという数字はコードに埋め込まれた定数ではなく、設定項目です。hdfs-default.xmlに次のように定義されています。

<!-- Apache Hadoop 3.3.5 / hdfs-default.xml -->
<property>
  <name>dfs.blocksize</name>
  <value>134217728</value>
  <description>The default block size for new files, in bytes.</description>
</property>

<property>
  <name>dfs.namenode.fs-limits.min-block-size</name>
  <value>1048576</value>
  <description>Minimum block size in bytes, enforced by the Namenode at create time.</description>
</property>

<property>
  <name>dfs.namenode.fs-limits.max-blocks-per-file</name>
  <value>10000</value>
  <description>Maximum number of blocks per file, enforced by the Namenode on write.</description>
</property>

この3つの値がそろって初めて全体像が見えます。

1つめ、dfs.blocksize のデフォルト値は134217728バイト、つまりちょうど128MBです。名前のとおり「新しいファイルのデフォルトのブロックサイズ」であって強制値ではありません。

2つめ、dfs.namenode.fs-limits.min-block-size が1048576バイト、つまり1MBで設定されています。NameNodeがファイル作成時点で強制する下限です。ブロックサイズを512KBまで下げて小さいファイル問題を回避しようとする試みが失敗するのはこのためで、NameNodeがそもそも拒否します。本当に下げたければこの値自体を先に下げる必要がありますが、そうすると次節で説明するNameNodeメモリの問題にそのまま踏み込むことになります。

3つめ、dfs.namenode.fs-limits.max-blocks-per-file が10000で設定されています。1ファイルが持てるブロック数の上限です。デフォルトのブロックサイズ128MBと掛けると、1ファイルの実質上限は約1.25TBになります。非常に大きな単一ファイルを扱いながらブロックサイズを小さくすると、この上限に先にぶつかります。

クラスタ全体ではなくファイル単位で変える

dfs.blocksize はクラスタのデフォルト値ですが、書き込み時点でファイル単位に指定することもできます。Hadoopのコマンドは共通してジェネリックオプション -D <property>=<value> を受け取ります。

# クラスタのデフォルト値 (128MB) で書く
hdfs dfs -put ./big.parquet /user/hadoop/

# このファイルだけ 256MB ブロックで書く
hdfs dfs -D dfs.blocksize=268435456 -put ./huge.parquet /user/hadoop/

# このファイルだけ 64MB ブロックで書く (下限 1MB 以上なので許可される)
hdfs dfs -D dfs.blocksize=67108864 -put ./medium.parquet /user/hadoop/

# 参考: hadoop fs と hdfs dfs は同じファイルシステムシェルである。
# 文書上の put の形式は次のとおり。
#   hadoop fs -put [-f] [-p] [-l] [-d] [-t <thread count>] [-q <thread pool queue size>] [ - | <localsrc> ...] <dst>

ここに重要な性質が1つあります。ブロックサイズは書き込み時点でファイルに固定され、すでに書いたファイルのブロックサイズは後から設定を変えても変わりません。クラスタのデフォルト値を128MBから256MBに上げても、昨日書いたファイルは128MBブロックのままです。既存ファイルのブロックサイズを変えるには新しい設定で書き直す必要があります。つまり「ブロックサイズを間違えた」という問題は、設定変更ではなく書き直し作業になります。

ブロックサイズを大きくすれば常に得というわけでもありません。40GBのファイルを512MBブロックで書くとブロックは80個しかないため、コアが数百あるクラスタでは大半のコアが遊びます。ブロックサイズはNameNodeの負担と並列度の間の折り合いです。

NameNodeメモリの話、もう少し正確に

上では「100万ブロックあたり1GBのヒープ」という経験則を書きました。方向は正しいのですが、実際にNameNodeのヒープを消費する対象が何かを知ると、はるかに役立つ判断ができます。

HDFSアーキテクチャの文書はNameNodeの役割をこう説明しています。NameNodeはブロック複製に関するすべての決定を下し、各DataNodeから定期的にハートビートとブロックレポートを受け取ります。ハートビートはそのDataNodeが正常に動作していることを意味し、ブロックレポートはそのDataNodeが持つすべてのブロックの一覧です。つまりNameNodeは、ファイルシステムの名前空間全体とブロックの位置情報をメモリに保持する存在です。

したがってヒープを食うのはデータの総バイト数ではなく、3種類のオブジェクトの個数です。

  1. ファイル (inode) の数
  2. ディレクトリの数
  3. ブロックの数

ここで小さいファイル問題（small files problem）の正体が見えてきます。1MBのファイル100万個と128GBのファイル8個はデータ総量が同程度ですが、NameNodeが管理すべきオブジェクト数は桁が違います。

同じデータ総量、異なる NameNode 負担
=======================================

(A) 1MB のファイル 1,000,000 個
    ファイルオブジェクト   1,000,000
    ブロックオブジェクト   1,000,000   (ファイルごとに最低1ブロック)
    合計  2,000,000 個以上のオブジェクトを NameNode がメモリに保持

(B) 128GB のファイル 8 個
    ファイルオブジェクト           8
    ブロックオブジェクト       8,192   (128GB / 128MB = 1,024 ブロック/ファイル)
    合計  約 8,200 個

データ総量は (A) 約 1TB、(B) 1TB で同程度。
NameNode の負担は2桁以上違う。

副次的に:
  - マップタスクもたいていブロック単位で生成されるので (A) はタスクが100万個
  - タスク1つあたりの起動コストが実際の計算より大きくなる

ブロックが大きいほど有利だという元の記事の論旨が、ここで定量的に確認できます。同時に、ファイルが小さければブロックサイズを大きくしても意味がないこともわかります。1MBのファイルはブロックサイズが128MBでも512MBでもブロック1個を占め、実際のディスクは1MBしか使いません。HDFSのブロックはローカルファイルシステムの固定サイズブロックと違い、使わない領域を先に確保しないからです。つまり小さいファイルが浪費するのはディスクではなく、NameNodeのメモリとタスクスロットです。

実際に確認する方法

# クラスタ全体の要約: 容量、DataNode の状態、低複製/破損/欠落ブロック数
hdfs dfsadmin -report

# 特定の状態の DataNode だけ
hdfs dfsadmin -report -live
hdfs dfsadmin -report -dead

# 名前空間全体を歩いてファイル数/ブロック数を数える (負荷が大きいので閑散時に)
hdfs fsck / -files -blocks

# パスごとのファイル数とディレクトリ数 (小さいファイルがどこに溜まるかを探すとき)
hdfs dfs -count -v /user/hadoop

出力例: hdfs dfsadmin -report (先頭部分)
==========================================

Configured Capacity: 6597069766656 (6.00 TB)
Present Capacity: 6543210987654 (5.95 TB)
DFS Remaining: 4102410240000 (3.73 TB)
DFS Used: 2440800747654 (2.22 TB)
DFS Used%: 37.30%
Replicated Blocks:
        Under replicated blocks: 0
        Blocks with corrupt replicas: 0
        Missing blocks: 0
        Missing blocks (with replication factor 1): 0
        Low redundancy blocks with highest priority to recover: 0
        Pending deletion blocks: 0

-------------------------------------------------
Live datanodes (6):

Name: 10.0.1.31:9866 (dn1.example.com)
Hostname: dn1.example.com
Rack: /rack1
Decommission Status : Normal
Configured Capacity: 1099511627776 (1.00 TB)
DFS Used: 406800124609 (378.86 GB)
DFS Remaining: 684121568575 (637.14 GB)
DFS Used%: 37.00%
Last contact: Sat Aug 16 10:14:02 KST 2026
Num of Blocks: 3121

読み方:
  Num of Blocks を全 DataNode について足し、複製係数で割ると
  論理ブロック数のおおよその規模が出る。
  この値が数千万単位まで上がったら、まず NameNode ヒープを疑う。
  出力項目はバージョンによって異なるので、使用中のバージョンの文書で確認すること。

最初から最後まで: 1つのファイルがブロックに分かれる過程

ファイルを1つアップロードし、それがどう分割され、どのDataNodeに置かれたのかを直接確認してみます。307.2MBのファイルをデフォルト設定（ブロック128MB、複製3）でアップロードするとします。

# 1) ファイルを HDFS に置く
hdfs dfs -put ./big.parquet /user/hadoop/big.parquet

# 2) 何個のブロックに分かれ、各ブロックがどこにあるかを見る
#    文書上の形式:
#      hdfs fsck <path> [-files [-blocks [-locations | -racks | -replicaDetails]]]
hdfs fsck /user/hadoop/big.parquet -files -blocks -locations

# 3) ブロックサイズだけ手早く確認したいとき
hdfs dfs -stat "%o %r %b" /user/hadoop/big.parquet

出力例: hdfs fsck ... -files -blocks -locations
=================================================

FSCK started by hadoop (auth:SIMPLE) from /10.0.1.21
  for path /user/hadoop/big.parquet at Sat Aug 16 10:12:44 KST 2026

/user/hadoop/big.parquet 322122547 bytes, replicated: replication=3, 3 block(s):  OK
0. BP-1093428495-10.0.1.10-1690000000000:blk_1073745821_5001 len=134217728 Live_repl=3
   [DatanodeInfoWithStorage[10.0.1.31:9866,DS-9f1c3a1e,DISK],
    DatanodeInfoWithStorage[10.0.1.42:9866,DS-2a77b904,DISK],
    DatanodeInfoWithStorage[10.0.1.55:9866,DS-c4108d55,DISK]]
1. BP-1093428495-10.0.1.10-1690000000000:blk_1073745822_5002 len=134217728 Live_repl=3
   [DatanodeInfoWithStorage[10.0.1.32:9866,DS-71ba0cd2,DISK],
    DatanodeInfoWithStorage[10.0.1.42:9866,DS-2a77b904,DISK],
    DatanodeInfoWithStorage[10.0.1.56:9866,DS-88e2f013,DISK]]
2. BP-1093428495-10.0.1.10-1690000000000:blk_1073745823_5003 len=53687091 Live_repl=3
   [DatanodeInfoWithStorage[10.0.1.31:9866,DS-9f1c3a1e,DISK],
    DatanodeInfoWithStorage[10.0.1.43:9866,DS-1d6e4477,DISK],
    DatanodeInfoWithStorage[10.0.1.56:9866,DS-88e2f013,DISK]]

Status: HEALTHY
 Number of data-nodes:   6
 Number of racks:        2
 Total dirs:             0
 Total symlinks:         0

Replicated Blocks:
 Total size:                    322122547 B
 Total files:                   1
 Total blocks (validated):      3 (avg. block size 107374182 B)
 Minimally replicated blocks:   3 (100.0 %)
 Over-replicated blocks:        0 (0.0 %)
 Under-replicated blocks:       0 (0.0 %)
 Mis-replicated blocks:         0 (0.0 %)
 Default replication factor:    3
 Average block replication:     3.0
 Missing blocks:                0
 Corrupt blocks:                0

この出力から読み取るべきことは次のとおりです。

ブロックは3個に分かれ、最初の2つは len=134217728、ちょうど128MBです。最後のブロックは len=53687091、約51.2MBです。最後のブロックは残った分だけを占め、128MBを無駄にしません。これが先に述べた「HDFSのブロックは領域を先に確保しない」ことの実際の証拠であり、ローカルファイルシステムの固定ブロックとHDFSのブロックの決定的な違いがこの1行にあります。

blk_1073745821_5001 という形式はブロックIDと生成スタンプです。先頭の BP- はブロックプールIDで、どの名前空間に属するブロックかを表します。Live_repl=3 は今生きている複製の数で、角かっこ内の一覧が実際にそのブロックを持つDataNodeです。

複製の散らばり方も見どころです。ブロック0とブロック1でDataNodeの組み合わせが違います。おかげでこのファイルを読むジョブは、3つのブロックを別々のノードから並列に読めます。-locations の代わりに -racks を渡すと、各複製がどのラックにあるかまで出ます。

複製とラック認識

ブロックがどこに置かれるかは、2つの設定と1つのポリシーが決めます。

<!-- Apache Hadoop 3.3.5 / hdfs-default.xml -->
<property>
  <name>dfs.replication</name>
  <value>3</value>
  <description>Default block replication. The actual number of replications
  can be specified when the file is created.</description>
</property>

<property>
  <name>dfs.namenode.replication.min</name>
  <value>1</value>
  <description>Minimal block replication.</description>
</property>

<property>
  <name>dfs.replication.max</name>
  <value>512</value>
  <description>Maximal block replication.</description>
</property>

dfs.replication のデフォルト値は3です。そして dfs.blocksize と同様に、ファイル作成時点でファイル単位に指定できます。すでに存在するファイルの複製係数は hadoop fs -setrep [-R] [-w] <numReplicas> <path> という形式のコマンドで変更できます。

3つの複製をどこに置くかはデフォルトのブロック配置ポリシーが決めます。HDFSアーキテクチャ文書の説明はこうです。複製係数が3の一般的なケースでは、書き込みクライアントがDataNode上にいれば最初の複製をそのローカルマシンに置き、そうでなければ書き込み側と同じラックの任意のDataNodeに置きます。2つめの複製は別の（リモートの）ラックのノードに、3つめの複製はそのリモートラックの別のノードに置きます。

この配置の形は2つの障害を同時に防ごうとする妥協です。3つの複製をすべて別のラックに散らせばラック全体が落ちても安全ですが、書き込みのたびにラック間ネットワークを3回渡ることになり遅くなります。逆に3つとも同じラックに置けば書き込みは速いものの、ラックのスイッチや電源が落ちるとブロックがまるごと消えます。2対1に分けると、ラック間トラフィックを1回に抑えつつラック単位の障害にも耐えられます。

低複製の状態はfsckの出力にそのまま出ます。

出力例: 低複製と欠落ブロック
===============================

# 1) 複製が目標値より少ない場合 (データは生きている)
/user/hadoop/small/part-00007 4096 bytes, replicated: replication=3, 1 block(s):
  Under replicated BP-1093428495-10.0.1.10-1690000000000:blk_1073746109_5289.
  Target Replicas is 3 but found 2 live replica(s), 0 decommissioned replica(s),
  0 decommissioning replica(s).

 Under-replicated blocks:       1 (0.0032 %)
 Status: HEALTHY

# 2) 複製が1つも残っていない場合 (データが消えた)
/user/hadoop/raw/2026-08-15.log: MISSING 1 blocks of total size 134217728 B.

 Missing blocks:                1
 Corrupt blocks:                0
 Status: CORRUPT

区別:
  Under-replicated --> まだ正常。NameNode が自分で複製を作り直す。
                       DataNode の離脱やディスク交換の直後によく見られ、
                       時間が経てば自然に 0 に戻る。
  Missing / Corrupt --> 復旧不能。人が介入しなければならない。
                        Status が CORRUPT に変わる。

Under-replicatedは警報というより進行状況の表示に近いものです。DataNodeを1台再起動したりディスクを交換したりすれば必ず現れ、NameNodeがハートビートとブロックレポートで状況を把握した後、自分で複製を作り直します。問題はこの値が減らずに止まっているときです。残ったノードの容量が足りない、ラックが1つしかなくポリシーを満たす配置先がない、複製帯域の制限に引っかかっている、といったケースです。

失敗事例と落とし穴

症状: NameNodeのGCが長くなり、クラスタ全体が止まったように見える

小さいファイル問題の典型的な最終形です。DataNodeは無事でディスクも余っているのに、NameNodeの応答が遅くなります。

診断の順序
=============

1) まずオブジェクト数を数える
   hdfs dfsadmin -report で全体のブロック規模を見る。
   hdfs fsck / -files -blocks で Total files / Total blocks を見る。
   ブロック数が数千万単位ならここですでに答えが出る。

2) どこに溜まったかを探す
   hdfs dfs -count -v <パス> を上位ディレクトリから降りながら実行する。
   たいていはストリーミングジョブの出力先か時間単位のパーティションが犯人。
   (例: 1分ごとに小さいファイルを1つ書くジョブ)

3) NameNode のヒープと GC ログを見る
   ヒープ使用量が上限近くに張り付き、フル GC が繰り返されているか確認する。
   ヒープを増やすのは時間を稼ぐ対応であって解決ではない。

4) 原因を直す
   - 小さいファイルを定期的にまとめるコンパクションジョブを入れる
   - ストリーミングジョブの出力間隔を延ばす (1分 -> 15分)
   - カラムナ形式 (Parquet/ORC) にまとめてファイル数自体を減らす
   - アーカイブが目的なら HAR でまとめる

大事なのは順序です。先にヒープを増やせば症状は収まりますが、ファイル数は増え続けるので、数か月後にもっと大きなヒープで同じ問題に再会します。オブジェクト数を先に数え、どこで増えているかを見つけ、生産者を直す順序であるべきです。

症状: ジョブのマップタスクが異常に多い

マップタスク数はおおむね入力スプリット数に従い、入力スプリットはおおむねブロックに従います。したがってタスクが数万個に跳ね上がるなら、原因は2つのうちどちらかです。入力ファイルが細かく分かれているか、ブロックサイズを必要以上に小さくしたか。

診断は入力パスに hdfs fsck <パス> -files -blocks を回し、ファイル数とブロックあたりのサイズを見ることから始めます。ファイル1つがブロック1つも埋められていないならファイル数が問題で、ファイルは大きいのにブロックが細かく分かれているなら、そのデータを書いたときの dfs.blocksize 設定が問題です。後者は先述のとおり設定変更だけでは直らず、書き直しが必要です。タスク起動の固定コストが実際の計算時間より大きくなると、クラスタは計算ではなくスケジューリングに時間を使うことになります。

症状: fsckにMISSINGまたはCORRUPTが出る

最も急を要する状況なので、順序を守ることが重要です。

まず hdfs fsck / -list-corruptfileblocks で影響を受けたファイルの一覧を確保します。次に hdfs dfsadmin -report -dead で死んだDataNodeがあるかを確認します。ノードがまるごと抜けていて、そのノードが復活しうる状態なら、ノードを復旧するのが最も速い解決です。早まって -delete を使うと、生き返らせられたブロックまで消してしまいます。

ノードが戻れないなら、そのデータの原本がどこにあるかを問います。HDFSは原本の保管場所ではなく派生した保管場所であることが多いので、上流システムから再投入するのが正解であるケースがよくあります。最後に、復旧が不可能でファイルを整理する段階になって初めて -move または -delete を使います。-move は破損ファイルをlost+foundへ移し、-delete は削除します。

落とし穴: 複製係数を1に下げて容量を節約する

容量が足りないときに真っ先に思いつく対応ですが、代償が大きい選択です。複製係数が1だと、DataNodeが1台死んだ瞬間にそのノードにあったブロックがそのままMISSINGになります。復旧できる別の複製がないからです。さらに複製が1つしかなければジョブがデータローカリティを活かす余地もなくなり、読み取り性能も一緒に落ちます。本当に再生成が容易な中間生成物にだけ、限定的に使える選択です。

HDFSを使わないほうがよい場合

HDFSアーキテクチャ文書は自らの前提をはっきり述べています。HDFSアプリケーションはファイルに対して一度書いて何度も読む（write-once-read-many）アクセスモデルを必要とし、HDFSは対話的な利用よりバッチ処理のために設計されており、低い遅延よりも高いスループットに重きが置かれています。この前提から外れる3つの場合には、別のストレージが適しています。

1つめは、小さいファイルが非常に多いワークロードです。理由はすべて前述のとおりで、NameNodeのメモリがファイルとブロックの個数に比例して消費され、タスク数も一緒に膨れ上がります。ログを細かく書くパイプラインなら、カラムナ形式にまとめてファイル数を減らすか、そもそもオブジェクトストレージやログ専用のストアを使うほうが適しています。

2つめは、低遅延のランダム読み取りが必要なワークロードです。HDFSの読み取りはNameNodeにブロックの位置を尋ねてDataNodeからストリーミングで読む構造なので、ミリ秒単位で特定のレコード1件を取り出す用途には向きません。キーで単件を高速に照会する必要があるなら、HBaseのようにHDFSの上にランダムアクセス層を載せたシステムか、まったく別種のデータベースが必要です。

3つめは、その場での更新（update-in-place）が必要なワークロードです。HDFSは追記（append）指向であり、ファイルの途中を任意に書き換えることを前提にしていません。レコードを頻繁に更新したり削除したりする必要があるなら、ファイルをまるごと書き直すしかありません。このパターンが必要ならIcebergやHudi、Delta Lakeのようなテーブルフォーマットで更新と削除を表現するか、トランザクションを備えたデータベースを使うのが適切です。

逆に、HDFSが今も十分に合う場所は明確です。ファイルが大きく、アクセスパターンが順次スキャンで、一度書いて何度も読み、スループットが遅延より重要な場合です。128MBというブロックサイズは、まさにその前提の上で選ばれた数字です。

参考資料

クイズ

Q1: 「ブロックベースファイルシステムとは？ HDFSブロックファイルシステム」の主なトピックは何ですか？

ブロックベースのファイルシステムについて学び、HDFSと比較します。

Q2: ブロックファイルシステムの利点とは何ですか？ 簡潔なメタデータ: 各ブロックのサイズが固定されているため、ファイルメタデータに各ブロックの位置とサイズを明示的に保存する必要がありません。これにより、メタデータの複雑さが軽減されます。 効率的なディスク使用: ブロックを固定サイズに分割することで、ディスクの空間配置を最適化し、ディスクの空き領域を最小化できます。これにより、ディスクの使用率が向上します。 高速なランダムアクセス: ブロックベースのアクセス方式は、任意の位置からデータにアクセスすることを容易にします。特定のブロックを見つけるための計算が単純であるため、ランダムアクセスの性能が向上します。

Q3: 128MBはどこに定義されており、ファイルごとに指定できますか？ hdfs-default.xmlのdfs.blocksizeで、デフォルト値は134217728バイトです。書き込み時点でファイル単位に指定できますが、 そのときファイルに固定されるため、すでに書いたファイルは書き直さないと変わりません。下限は1MBで強制されます。

Q4: NameNodeのヒープを消費するのは何で、なぜ小さいファイルが問題になりますか？ 総バイト数ではなく、メモリに保持するファイル数とディレクトリ数とブロック数です。小さいファイルが浪費するのは ディスクではなく、NameNodeのメモリとタスクスロットです。

Q5: ファイルが何個のブロックに分かれ、どのDataNodeにあるかをどう確認しますか？ fsckに-files -blocks -locationsを一緒に渡します。ブロックID、len、Live_repl、DataNodeの一覧が出ます。 最後のブロックのlenが小さいのは、HDFSのブロックが残った分だけを占めるからです。

Q6: 複製係数が3のとき、デフォルトの配置ポリシーは複製をどこに置きますか？ 最初の複製は書き込みクライアントのローカルノードか同じラックの任意のノード、2つめは別のラック、3つめはその リモートラックの別のノードです。ラック間ネットワークを1回だけ渡りつつ、ラック単位の障害にも耐えます。

コメント

まだコメントはありません。

ログインするとコメントできます