今日、私たちの世界はデータの時代に入りました。インターネット、IoT、5G、ビッグデータ、人工知能、自動運転、メタバースなどの情報技術の急速な発展に伴い、人々が生成、収集、保存、管理、分析するデータの総量は急速に増加しています。多様な形式、複雑なフォーマット、大規模、急速な生成を伴う業界の大規模データは、基盤となる新しい基本サポート コンピューティング サポート テクノロジに急速な変化をもたらしています。過去 10 年間にわたる産業界と学術界の先駆者の指導と実践を通じて、分散並列コンピューティングと分散データ ストレージのテクノロジー エコシステムは進化し続け、豊かになり、繁栄してきました。その中でも、分散データ ストレージ管理は、この大規模なデータ処理テクノロジ スタックにおいて基本的な役割を果たしており、多くの業界におけるビッグ データ アプリケーション分析の基礎となっています。
分散ファイル システムは、ハイパフォーマンス コンピューティングからビッグ データ コンピューティングの時代まで広く使用されている、主流の分散データ ストレージ管理システムです。近年、クラウド コンピューティング技術の継続的な発展に伴い、分散オブジェクト ストレージ、キーバリュー ストレージ、その他の技術の適用も一般的になってきています。これに関連して、多くの分散ファイル システムは、データ ストレージを統合かつ効率的に管理するという技術的路線に乗り出し始めています。その中でもよく知られ、ユーザーによく使われているシステムが、カリフォルニア大学バークレー校の AMPLab で生まれた Alluxio であり、統合されたビッグデータ仮想ファイル システム、さまざまな種類の分散ストレージ システムとみなすことができます。 (ファイル システム、オブジェクト ストレージ システム) を Alluxio ディレクトリにマウントでき、効率的で統一されたアクセス モードとインターフェイスを提供します。メタデータは、ストレージ システム内のデータ情報に関する最も重要なキー情報であり、通常のアクセスが最も頻繁に行われます。基盤となるさまざまな分散ストレージ システムからの大規模なデータ ファイルとオブジェクトを効果的に管理するために、Alluxio は効率的でスケーラブルな大規模なメタデータ管理メカニズムを提供する必要があります。
この記事では、オープン ソース バージョンの Alluxio 2.8 を例として取り上げ、分散ファイル システムにおける一般的な大規模メタデータ管理メカニズムを明らかにします。Alluxio ユーザーの場合、ユーザーはファイルのメタ情報を通じて Alluxio ファイル システム インターフェイスと対話し、データ ブロックのメタ情報を通じてデータの読み取り、書き込み、およびキャッシュを行います。ファイルとデータ ブロックのメタデータは、Alluxio マスターによって保存および管理されます。
0 1. 分散ファイル システムのメタデータの一般的なタイプ
Alluxio Master によって管理されるメタデータの中で、最も重要なカテゴリは、ファイル メタデータ、データ ブロック メタデータ、マウント ポイント メタデータ、および Alluxio Worker メタデータです。
ファイル (inode) メタデータ
Alluxio ファイル システムの各ファイルまたはフォルダーは i ノードで表されます。この i ノードには、基本的なファイル属性、アクセス許可情報、管理属性、タイムスタンプ、含まれるデータ ブロック、およびデータの各メタデータを含む、ファイルのすべての属性とメタ情報が保存されます。ブロックなど 「inode」の概念は Unix タイプのファイル システムに由来し、Linux や HDFS などのファイル システムで広く使用されており、ファイル システムのディレクトリ ツリー上のノードを表します。Alluxio は複数のアンダーストアを管理するため、Alluxio 名前空間内の潜在的なファイルの数は、実際にはすべてのアンダーストア内のファイルの合計になります。Alluxio クラスターの最も重要なサービスであるメタデータ サービスは、システムの規模、パフォーマンス、安定性を直接決定します。Alluxio ファイル システムの i ノードは、基盤となるストレージに必ずしも存在するとは限らないことに注意してください。たとえば、このパスが MUST_CACHE モードを使用して Alluxio に書き込まれる場合、Alluxio は基礎となるストレージにこのファイルを作成しません。さらに、基礎となるストレージがオブジェクト ストレージの場合、オブジェクト ストレージにはフォルダーの概念がないため、Alluxio のフォルダーは基礎となるストレージ内の実際のオブジェクトに対応しません。
一般に、Alluxio Master による i ノードの管理は、抽象的に次のカテゴリに分類できます。
-
Alluxio Master は、すべての i ノード情報と i ノード間のツリー構造 (フォルダーとファイル間の親子関係) を保存する InodeTree を使用して、ファイル システムのツリー構造を維持します。
-
ファイル システム操作用のインターフェイスを実装し、ファイルに対するすべての操作をサポートします。Alluxio Master は、一連のファイル システム操作インターフェイスを開き、各操作の同時実行の安全性と永続性の保証を提供することで、上位層のアプリケーションに分散ファイル システムを提供します。
-
ジャーナル ログを通じて永続的な状態を維持し、各 i ノード操作の永続性と原子性を確保します。Alluxio Master は、i ノード情報とすべての操作がジャーナル ログに記録されることを保証し、それによって、いかなる状況でも i ノード情報と変更が失われないようにします。
-
Alluxio の InodeTree は、各 i ノードに対するロックの粒度を細かくすることで、inode レベルの読み取りおよび書き込みの同時アクセスをサポートします。同時実行制御はロックを通じて各 i ノードで実行され、同時読み取りおよび同時書き込み中の i ノードのスレッドの安全性が確保されます。
データブロックメタデータ
i ノードがファイルに対応する場合、そのファイルには 0 (空のファイル) 以上のデータ ブロックがあります。新しいファイルの場合、最後のデータ ブロックを除くすべてのデータ ブロックのサイズは alluxio.user.block.size.bytes.default によって設定されます。データ ブロックが 1 つだけあるファイルも最後のデータ ブロックとしてカウントされます。データブロック間にはツリー構造や親子関係がないため、データブロックのメタ情報管理はinodeに比べて比較的簡単です。
Alluxio Master は、データ ブロックのメタ情報とデータ ブロック キャッシュの現在の場所を保存し、この情報の外部読み取りおよび書き込みインターフェイスを提供します。Alluxio Master によって管理されるデータ ブロックのメタデータは、簡単に言うと 2 つのキーと値のストアとして見ることができます。
（1）<ブロックID、ブロックメタデータ>
（2）<ブロックID、リスト<ブロック位置>>
このうち、BlockMetadataはデータブロックの長さを記録する。BlockLocation は、このデータ ブロック (キャッシュ) が存在する Alluxio Worker ノードのアドレスと、Alluxio Worker ノード上のこのデータ ブロックの特定の保存場所を記録します。
これら 2 つの異なる情報は、主にライフサイクルが異なるため、別々に保存されます。ブロックのメタデータは不変です。Alluxio は、ランダムな変更や、すでに書き込まれたデータ ブロックへの追加をサポートしていません。このファイルが書き換えられると、新しい FileID (つまり InodeID) と新しい BlockID が取得され、古いデータ ブロックは破棄されます。それどころか、BlockLocation リストは変化し続けます。たとえば、データ ブロックが新しい Alluxio Worker にロードされるか、Alluxio Worker から削除されると、リスト情報もそれに応じて変化します。
マウントテーブル
MountTable は、Alluxio ファイル システム内のすべてのマウント ポイントを管理し、マウント ポイントの作成や変更などの操作を提供します。同時に、Alluxio ファイル パスと基盤となるストレージのファイル パスも解決され、MountTable を通じて相互に対応付けられます。
ワーカーのメタデータ
Alluxio マスターによる Alluxio Worker メタデータの管理には、現在どの Alluxio Worker が動作しているかを追跡し、Alluxio Worker 上のキャッシュ リストを常に更新することが含まれます。Alluxio Master によって記録される情報には主に次のものが含まれます。
(1) Alluxio Worker のアドレス、起動時間、その他の固定情報。
(2) Alluxio Worker のスペース使用量 (多層キャッシュ内の各層の使用量を含む) は、ハートビートごとに更新されます。
(3) Alluxio Worker にキャッシュされているすべての BlockID、および Alluxio Worker から削除されるすべての BlockID。この情報は、ハートビートやブロック操作 (ロード、エビクションなど) ごとに変化します。
0 2. 分散ファイルシステムメタデータのストレージモード
分散ファイル システムのメタデータ ストレージには通常、オンヒープ ストレージとオフヒープ ストレージが含まれます。このうち、オンヒープ ストレージのアクセスは効率的ですがスペースが限られており、オフヒープ ストレージのスペースは大きいですが、適切に設計されていないとパフォーマンスの低下を引き起こします。
2.1 メタデータはヒープ上に保存されます (HEAP モード)
Alluxio を例に挙げると、HEAP モードでは、すべてのメタ情報が Java オブジェクトの形式で JVM のヒープに保存されます。各ファイルはヒープ上で約 2KB ～ 4KB のメモリを占有します。したがって、Alluxio ファイル システムに多数のファイルがある場合、ヒープ上のメタ情報により JVM に多大なメモリ負荷がかかります。システム内に 1 億個のファイルがある場合、これらのファイルのメタ情報を JVM に保存するだけで 200GB ～ 400GB を占有することを計算するのは難しくありません。マスター JVM が負担しなければならない大量の RPC 操作メモリ オーバーヘッドと相まって、この JVM のメモリ要件は、通常のサーバーが負担するのが困難です。
さらに、このようなデータ サイズでの GC は、ほとんどの JVM バージョンで管理することが非常に困難になります。Alluxio マスター JVM 内のこれらのメタ情報は存続期間の長いオブジェクトであり、特に旧世代の GC 効率に大きな影響を与えます。JVM によって引き起こされるパフォーマンスや管理の問題の一部またはほとんどを回避できる JVM の商用バージョンがいくつかありますが、ほとんどのユーザーにとって、過剰な JVM の使用は依然として非常に困難な問題であり、特に Alluxio Master の JVM は将来変更される可能性があります。その結果、ビジネスの拡張により物理マシンのメモリの上限を超える可能性があります。
2.2 メタデータはヒープの外に保存されます (ROCKS モード)
HEAP モードの拡張が難しいという問題を解決するために、Alluxio は設計の方向性を最適化しました。Alluxio はバージョン 2.0 で ROCKS モードを導入し、メタ情報のストレージを JVM の外に移動しました。ROCKS モードでは、Alluxio Master は RocksDB を組み込み、ファイル (およびデータ ブロック) のメタ情報を以前の JVM ヒープから RocksDB に移動します。RocksDB の記憶媒体は実際にはメモリではなくハードディスクです。RocksDB を使用してメタデータを保存するには、メタデータ ストレージ モードを構成し、RocksDB のストレージ パスを指定するだけです。
| alluxio.master.metastore=ロックス alluxio.master.metastore.dir=${alluxio.work.dir}/metastore |
Alluxio に埋め込まれた RocksDB は、alluxio.master.metastore.dir で設定されたパスをメタデータ ストレージとして使用します。次の例では、実行中の Alluxio クラスターの RocksDB ストレージを表示します。Alluxio には、RocksDB に保存された Inode および Block メタデータのストレージ ディレクトリがあり、RocksDB によって管理されるデータ ファイルが維持されていることがわかります。RocksDB の格納ディレクトリ構造については本書では詳しく説明しませんので、RocksDB の公式ドキュメントを参照してください。
$ ls -al -R metastore/
metastore/:
total 8
drwxrwxr-x. 2 alluxio-user alluxio-group 4096 May 21 03:20 blocks
drwxrwxr-x. 2 alluxio-user alluxio-group 4096 May 21 03:33 inodes
metastore/blocks:
total 4264
-rw-r--r--. 1 alluxio-user alluxio-group 0 May 21 03:20 000005.log
-rw-r--r--. 1 alluxio-user alluxio-group 16 May 21 03:20 CURRENT
-rw-r--r--. 1 alluxio-user alluxio-group 36 May 21 03:20 IDENTITY
-rw-r--r--. 1 alluxio-user alluxio-group 0 May 21 03:20 LOCK
-rw-r--r--. 1 alluxio-user alluxio-group 52837 May 21 03:30 LOG
-rw-r--r--. 1 alluxio-user alluxio-group 176 May 21 03:20 MANIFEST-000004
-rw-r--r--. 1 alluxio-user alluxio-group 13467 May 21 03:20 OPTIONS-000009
-rw-r--r--. 1 alluxio-user alluxio-group 13467 May 21 03:20 OPTIONS-000011
metastore/inodes:
total 4268
-rw-r--r--. 1 alluxio-user alluxio-group 0 May 21 03:20 000005.log
-rw-r--r--. 1 alluxio-user alluxio-group 1211 May 21 03:33 000012.sst
-rw-r--r--. 1 alluxio-user alluxio-group 16 May 21 03:20 CURRENT
-rw-r--r--. 1 alluxio-user alluxio-group 36 May 21 03:20 IDENTITY
-rw-r--r--. 1 alluxio-user alluxio-group 0 May 21 03:20 LOCK
-rw-r--r--. 1 alluxio-user alluxio-group 58083 May 21 03:33 LOG
-rw-r--r--. 1 alluxio-user alluxio-group 247 May 21 03:33 MANIFEST-000004
-rw-r--r--. 1 alluxio-user alluxio-group 13679 May 21 03:20 OPTIONS-000009
-rw-r--r--. 1 alluxio-user alluxio-group 13679 May 21 03:20 OPTIONS-0000112.3 オフヒープ ストレージのメモリとディスクの使用量
ROCKS モードでは、メタ情報はオフヒープ RocksDB に保存されるため、Alluxio マスター プロセス上のメタ情報ストレージのメモリ負荷が大幅に軽減されます。HEAP モードと比較すると、すべてのメタ情報の読み取りと書き込みがメモリ速度からハードディスク速度まで低下し、Alluxio Master のパフォーマンスとスループットに大きな影響を与えます。したがって、Alluxio Master はメモリ内にキャッシュを追加して、RocksDB へのアクセスを高速化します。つまり、ROCKS モードでは、メタ情報ストレージのメモリ使用量が、キャッシュのこの部分のメモリ使用量になります。HEAP モードでのメモリ使用量の見積もりと同様に、キャッシュ内の各ファイルのメタ情報ストレージは同じ 2KB ～ 4KB を占有します。
キャッシュのサイズは、alluxio.master.metastore.inode.cache.max.size によって制御されます。この設定項目の値は、Alluxio のバージョンによって異なる場合があります。Alluxio Master は最初にキャッシュに書き込み、キャッシュが一定の使用量に達すると RocksDB (ディスク) への書き込みを開始します。RocksDB のディスク使用量は次のとおりです。約 100 万ファイルのメタ情報が約 4GB のハードディスク容量を占有します。Alluxio 名前空間内のファイルの数が alluxio.master.metastore.inode.cache.max.size に基づいてエビクションをトリガーしない場合、すべてのファイルのメタ情報はメモリベースのキャッシュ内にあり、RocksDB には書き込まれないことに注意してください。この時点で、これらのファイルのメタデータ ディスク使用量は 0 に近くなります。
2.4 キャッシュの高速化とオフヒープ ストレージのチューニング
十分なメモリ領域がある場合、alluxio.master.metastore.inode.cache.max.size を適切に増やすと、より多くのファイル メタ情報をメモリにキャッシュしてパフォーマンスを向上させることができます。同時に、Alluxio Master での RPC 操作もメモリを消費することに注意してください。進行中の RPC 操作がない場合でも、Alluxio マスター上の定期的なファイル スキャンなど、メモリを消費する内部管理ロジックがいくつか存在します。Alluxio マスター プロセスのメモリを見積もるときは、これらの操作に十分なメモリを予約し、メタ情報ストレージがすべてのメモリを占有しないようにする必要があります。これは、オペレーティング システム用のメモリ領域を予約せずに、サーバー上のメモリの 100% をアプリケーションに割り当てることができない理由と同じです。メタ情報キャッシュの管理は、水位メカニズムに基づいています。ユーザーは、高水位パラメータと低水位パラメータを構成します。たとえば、次はデフォルト構成です:
| alluxio.master.metastore.inode.cache.high.water.mark.ratio=0.85 alluxio.master.metastore.inode.cache.low.water.mark.ratio=0.8 |
キャッシュ使用量が 0.85 * alluxio.master.metastore.inode.cache.max.size に達すると、キャッシュされたデータの削除が開始され、キャッシュ内のデータ コンテンツが RocksDB ストレージに書き込まれます。キャッシュ占有率が 0.8 に低下したときにエビクションを停止します。
2.5 HEAP モードと ROCKS モード間の切り替え
HEAP モードと ROCKS モードを使用する場合、ジャーナル ログの形式が異なるため、構成を変更して Alluxio マスター プロセスを再起動するだけでは、あるモードから別のモードに切り替えることはできません。メタデータ ストレージ モードの切り替えは、クラスタをバックアップから起動することで完了できます。第 4.5 章を参照してください。
この記事では、Alluxio を例として、分散ファイル システムのメタデータの基本的な種類とその管理および最適化方法を簡単に紹介します。データ アクセスの最適化の詳細については、Alluxio オープン ソース コミュニティ コードを参照してください。 Machinery Industry Press の最新出版物を読むには、技術書「分散型統合ビッグデータ仮想ファイル システム - Alluxio の原則、技術、実践」を参照してください。
この本は、広く使用されている Alluxio 2.8.0 オープン ソース バージョンに基づいて書かれており、Alluxio 関連の分散統合ビッグ データ ファイル システムの技術原則と実践事例を詳しく紹介しています。主な内容は、システムの入力と使用方法です。 、カーネル コンポーネントの設計と実装の原則、および大規模なエンタープライズ アプリケーションの事例と実践を詳細に紹介し、Alluxio のオープン ソース コミュニティ開発者ガイドを添付します。この本は、Alluxio オープンソース コミュニティ ユーザー、大学のビッグ データ システム コースの教師と学生、および潜在的な企業ユーザー向けに、比較的完全な技術ガイドと実践的なチュートリアルを提供しており、ビッグ データの分野の専門教科書として使用できます。ビッグデータの専門家や研究者にとっても、著者の重要な専門情報です。