序文
メタデータ空間は、時間のオーダーの比較的大きなサイズに達すると我々はすべて知っている、として、HDFSはいくつかのスケーラビリティの問題が発生します。すべてのHDFSメタデータのinodeの第一は、負荷情報は、メモリ内で管理するだけでなく、巨大なHDFSの名前ノードによって管理されている情報に関連するマッピング情報を、提携しています。したがって、名前ノードはリクエスト処理の大きい順に直面します。もっと基本的なレベルから、これは中心的な問題集中管理サービスの出会いです。純粋な濃厚HDFSメタデータのメモリ管理とは違って、記事は別の、よりスケーラブルなオゾンの分散メタデータの管理について説明します。
オゾンは、メタデータを分散しています
まず第一に、メタデータが分散しているものの概念がありますか？簡単に説明するとは、システム・メタデータは、分散各ノードに格納されています。そして、誰かが、その後、いくつかの疑問である必要がありますどのように我々は位置特定のメタデータクエリそれですか？クエリリレーショナルメタデータ行うには、より集中管理サービスがあるべきではないですか？
私たちはこれらの分散メタデータを管理するための集中管理サービスを持っている必要がある場合は実際には、このデザインパターンは、モデルとして集中管理とサービスに劣化したことを、ここに問題があります。
上記のすべてのブロックのチャンク情報ファイルの店で各データノードのオゾンで。クライアントに伝えるために別のサービスによって、このような情報の任意のノード上のブロックの残りの半分。言い換えれば、クライアント・ファイル・ブロックちょうどそれがローカルのデータノードにクエリのDBファイル、どのような位置にある物理ファイルを対応するコンクリートブロックチャンクの後ろに、その上でこのノードに情報を要求していることを知っています。HDFSでは、情報ファイルは、名前ノードを管理されているこのマッピングのような多数の特定のブロックは、分散メタデータへの集中モードにオゾン、このようなメタデータで濃縮しました。
オゾンデータノードデータのレイアウト
オゾンは、各ノードデータノードの上に格納されているメタデータに分散されているので、のは、より多くのHDFSデータノードのメタデータカタログよりも、ユーザーデータとメタデータを含む特定のデータノード実際のデータレイアウト、見てみましょう。
テストオゾンクラスター内の著者は、その後、テストファイルを入れて、テストボリュームを作成し、buckt。クエリファイルの実際の場所によってコンテナに属し、ノードの実際の場所でそれを見つけることができるようになります。
次のようにコンテナデータノードのディレクトリの形式は次のとおりです。
<< dfs.datanode.dir >> / HDDを/ <> /現在/
次のように私は、実際のディレクトリクラスタをテストしました：
[hdfs@lyq ~]$ ls -l /tmp/hadoop-hdfs/dfs/data/hdds/762187f8-3d8d-4c2c-8659-9ca66987c829/current/
total 4
drwxr-xr-x 3 hdfs hdfs 4096 Dec 24 07:56 containerDir0
ここではコンテナcontainerDir0が従っパーティションコンテナIDで行われ、サブディレクトリパーティションは、ファイル・ディレクトリの過度の下流を防ぐためです。その後に続くパーティションのディレクトリには、ディレクトリコンテナIDです。
[hdfs@lyq ~]$ ls -l /tmp/hadoop-hdfs/dfs/data/hdds/762187f8-3d8d-4c2c-8659-9ca66987c829/current/containerDir0/4/
total 8
drwxr-xr-x 2 hdfs hdfs 4096 Dec 24 07:56 chunks
drwxr-xr-x 3 hdfs hdfs 4096 Dec 24 07:56 metadata
二つ以上のディレクトリが、すなわち、ブロック・チャンクコンテナメタデータにこのコンテナブロック情報内に格納されているコンテナのメタデータコンテナDBファイルと情報ファイルと比較し、データに対応するファイルチャンクを表しました。ブロックチャンクファイルのメタ情報格納されている情報データには含まれています。
[hdfs@lyq ~]$ ls -l /tmp/hadoop-hdfs/dfs/data/hdds/762187f8-3d8d-4c2c-8659-9ca66987c829/current/containerDir0/4/chunks/103363337595977729_chunk_1
-rw-r--r-- 1 hdfs hdfs 12 Dec 24 07:56 /tmp/hadoop-hdfs/dfs/data/hdds/762187f8-3d8d-4c2c-8659-9ca66987c829/current/containerDir0/4/chunks/103363337595977729_chunk_1
[hdfs@lyq ~]$ cat /tmp/hadoop-hdfs/dfs/data/hdds/762187f8-3d8d-4c2c-8659-9ca66987c829/current/containerDir0/4/chunks/103363337595977729_chunk_1
hello world
その後、我々は、コンテナのメタデータカタログを見て、
[hdfs@lyq ~]$ ls -l /tmp/hadoop-hdfs/dfs/data/hdds/762187f8-3d8d-4c2c-8659-9ca66987c829/current/containerDir0/4/metadata/
total 8
drwxr-xr-x 2 hdfs hdfs 4096 Dec 24 07:56 4-dn-container.db
-rw-r--r-- 1 hdfs hdfs 567 Dec 24 07:56 4.container
container_id.containerスタイルファイルを渡すデータノードは、コンテナを作成したときにこのファイルが生成されます、このコンテナの内容に関するいくつかの基本的な情報が含まれています。
[hdfs@lyq ~]$ cat /tmp/hadoop-hdfs/dfs/data/hdds/762187f8-3d8d-4c2c-8659-9ca66987c829/current/containerDir0/4/metadata/4.container
!<KeyValueContainerData>
checksum: fbbb104d6b0f2341cc318f4cf940a76658d1a5e0250bd16d4b4c752a6ea7465c
chunksPath: /tmp/hadoop-hdfs/dfs/data/hdds/762187f8-3d8d-4c2c-8659-9ca66987c829/current/containerDir0/4/chunks
containerDBType: RocksDB
containerID: 4
containerType: KeyValueContainer
layOutVersion: 1
maxSize: 5368709120
metadata: {}
metadataPath: /tmp/hadoop-hdfs/dfs/data/hdds/762187f8-3d8d-4c2c-8659-9ca66987c829/current/containerDir0/4/metadata
originNodeId: c29894ae-e3b2-4dea-b97e-3e5a60243baf
originPipelineId: c2971ae1-61f2-4bf9-aed0-a1fd2fea5964
state: OPEN
この情報は、メモリ管理のデータノードへの負荷の一部となります。別の4-DN-container.db RocksDBディレクトリファイルはコンテナ、このコンテナに含まれて保存されたファイルブロックのメタデータ情報です。
データ処理操作オゾンデータノード
上記のデータノードコンテナレイアウトモードでは、どのようにデータをデータノードは、それを処理していますか？以下のようなプロセスどれですか？
それはあなたがすでにオゾンのいくつかの背景知識を持っていると仮定され、大規模な背景データブロックは、クライアントデータノードのコンテナに書き込まれます。ここでは、2つの主要な操作を伴うだろう以上のものは何もありません。
- コンテナ実際のデータの読み出しと書き込み操作、すなわち、ファイルチャンクの上方動作します
- 操作上のコンテナのメタデータ情報、コンテナのdbファイルまたはファイルを変更.container
プラスデータノードディスパッチャ+クラスの分布は、コンテナタイプ（KVは現在だけの実施形態をサポートする）で処理されたハンドラ・クラスは、次のデータ処理の構成に対応します。
フィギュア・プロセス上のChunkManagerは、読み取りと書き込みのデータファイルは、実際には、内部KeyValueHanlder BlockManagerクラスは、制御ブロックメタデータ操作と呼ばれています。具体的には上記のKeyUtilsは、BlockManager＃BlockUtilsに置き換える必要があります。
中央処理ロジックは、クラスKeyValueHanlderに含まれる上記。
// handle处理操作
public ContainerCommandResponseProto handle(
ContainerCommandRequestProto request, Container container,
DispatcherContext dispatcherContext) {
Type cmdType = request.getCmdType();
KeyValueContainer kvContainer = (KeyValueContainer) container;
switch(cmdType) {
case CreateContainer:
return handleCreateContainer(request, kvContainer);
case ReadContainer:
return handleReadContainer(request, kvContainer);
...
return handleReadChunk(request, kvContainer, dispatcherContext);
case DeleteChunk:
return handleDeleteChunk(request, kvContainer);
case WriteChunk:
return handleWriteChunk(request, kvContainer, dispatcherContext);
case ListChunk:
return handleUnsupportedOp(request);
case CompactChunk:
return handleUnsupportedOp(request);
...
default:
return null;
}
}
そして、ここでディスパッチャの要求は、外部クライアントから開始されているソースの始まりは、です
前記入札者の操作の一貫性を確保するためにApache Ratis（ジャワラフトプロトコル実装ライブラリ）によって実際のデータノードとの間の通信のためのオゾンクライアント、クライアントデータノードの下に示されたプロセスの中間に：
目標コースクライアントデータノードを接続する前に、また、出力データ・ストリーム・オブジェクトを取得するために、OMと通信する必要があり、ターゲットブロックの位置情報、再度データの書き込み対象データノードのコマンド要求を開始します。
次のようにプロセスのこの部分は次のとおりです。
（図面参照番号と一致しない図の番号の手順）を以下のように、上述したプロセスです。
1）運転へのクライアントキーは、OMのPUT行う
ブロックコンテナに2）OM SCMアプリケーションを
、出力ストリームオブジェクトのブロック3）OMクライアント戻る
。4）この出力ストリームデータへのクライアントが書き込まれる
。5）ブロックの出力ストリームは、オブジェクト内であろうファイルチャンクの実際の動作記述するための発呼要求コマンド
6）は、ファイルチャンクが成功し、内部ストリームオブジェクトプットブロック操作の出力は、データノードは、ファイルコンテナDBを更新するために呼び出すために続けて、書かれたなら
実際のデータ書き込み処理のオゾンクライアントブロックまだ比較的微妙な多くの詳細がまだあるが、別の記事では、この作品の内容を説明するために従います。
引用文
[1]。https://issues.apache.org/jira/browse/HDDS-48。ContainerIO - ストレージ管理
