高性能でクラウドネイティブなレイクウェアハウス統合ストレージアーキテクチャの探求

1. レイクウェアハウス統合ストレージアーキテクチャの進化

1. ストレージアーキテクチャの進化

ビッグデータ ストレージ システムの進化は、コンピュータ ルーム時代とクラウド コンピューティング時代の 2 つの段階に分けられます。

最初の段階は、Hadoop が初めて誕生した時代でもありました。この時代は主にコンピュータ ルーム システムがベースになっており、基本的に HDFS が唯一のストレージ オプションでした。

クラウド コンピューティングの普及と発展に伴い、オブジェクト ストレージは徐々に企業向けの主流のストレージ ソリューションになってきました。特にデータ レイク アーキテクチャでは、オブジェクト ストレージは、高いスケーラビリティと多様なデータ タイプのサポートにより、基盤となるストレージ ソリューションとして人気が高まっています。 HDFS とオブジェクト ストレージのアーキテクチャをレビューして比較し、それぞれの長所と短所、および開発の傾向を探ります。同時に、クラウドネイティブのデータレイクストレージアーキテクチャをどのように設計すべきかについても説明します。

HDFS とオブジェクト ストレージのアーキテクチャ設計を本質的に分析すると、実際にはこれら 2 つはまったく異なるストレージ システムであることがわかります。将来、クラウドネイティブ時代では、ストレージ システムはビッグ データ レイク ウェアハウス統合のためのストレージ基盤を提供します。どのような機能が必要ですか?これについては後で説明します。

2. HDFSの特徴

HDFS は GFS (Google File System) から派生したもので、2006 年に正式にリリースされました。その機能には、独立したメタデータ ストレージ (NameNode)、複数のレプリカ、ストレージとコンピューティングの結合などがあります。HDFS 全体の設計は、比較的大きなファイルのストレージに適していますが、小さなファイルには適していません。ストレージの規模に関して言えば、単一の名前空間は通常数十億単位になります。大量のデータストレージがある場合は、スケーラビリティのアーキテクチャ調整を行う必要があります。

3. オブジェクトストレージの特徴

オブジェクト ストレージ S3 も 2006 年にリリースされましたが、その当初の目的は、ビッグ データ エコシステムでの使用ではなく、大量の非構造化データを保存することであったため、オブジェクト ストレージのアーキテクチャ設計は HDFS とはまったく異なります。その主な特徴としては、低いストレージコストと十分に高いデータ永続性などが挙げられます。 API は HTTP プロトコルに基づいており、メタデータ設計はフラットな KV 構造です。フラットなメタデータ設計は、ビッグデータのシナリオでいくつかの問題を引き起こす可能性があります。 HDFS と同様に、そのデータは変更できません。一貫性の点では、オブジェクト ストレージは主に結果整合性に基づいており、一部のクラウド ファクトリーまたは一部のインターフェイスは強力な一貫性を実現できます。

2. さまざまなタイプのストレージシステムの比較

以下は、上記で述べた HDFS とオブジェクト ストレージの特性をさまざまな側面から総合的に比較したものです。

まず、ストレージの規模によって、データ プラットフォームまたはビッグ データ システム全体がサポートできるビジネス データの量が直接決まります。 HDFS と比較すると、オブジェクト ストレージはより大きなストレージ規模を実現できます。 ETL やアドホックなどの日常的なデータ タスクでは、メタデータ操作のパフォーマンスが全体的なタスク効率に影響します。この点では、オブジェクト ストレージのパフォーマンスは HDFS よりもはるかに劣ります。操作とメンテナンスの複雑さも、ストレージの選択に影響を与える重要な要素です。 HDFS のメンテナンス コストはオブジェクト ストレージよりもはるかに高くなります。これには、人件費と、高可用性とスケーラビリティを確保するために構築されたいくつかの追加コンポーネントが含まれます。

1. HDFS の弱点 - NameNode

HDFS の最大のボトルネックは NameNode です。 NameNode の初期設計は、シングルポイント設計である GFS のマスターを模倣することであったため、HDFS にも同じ問題があります。

コミュニティは、ViewFs + Federation ソリューションなど、単一ポイントの NameNode のスケーラビリティの問題に対処するためのいくつかの試みを行っており、その後、RBF (Router-based Federation) ソリューションを開始しました。これは基本的に、単一の名前空間での NameNode のスケーラビリティの問題を解決し、複数のクラスターの水平拡張によって HDFS クラスターのストレージ容量が大幅に制限されないようにするように設計されています。

ストレージの規模に加えて、もう 1 つの問題は高可用性です。単一のクラスターでは、NameNode は単一のポイントであるため、後にスタンバイ NameNode が登場し、その後 JournalNode が登場しました。最終的に、これらすべてのコンポーネントとアーキテクチャは、アクティブ ネームノードがダウンしたときにビッグ データ クラスター全体が使用できなくなるのではなく、HDFS ストレージ クラスター全体が高可用性の要件を満たすことができるように設計されています。

2. オブジェクトストレージの弱点 - メタデータ

オブジェクト ストレージの問題もメタデータに関連しています。前述したように、オブジェクト ストレージのメタデータ設計はフラットな KV 構造です。上図の foo ディレクトリには、多数のサブディレクトリまたはサブファイルがあります。オブジェクトストレージの観点から見ると、これはディレクトリ構造ではありません。従来のファイルシステムではツリー状のディレクトリ構造が見られますが、オブジェクト ストレージの設計ではディレクトリ ツリーは存在しません。代わりに、ディレクトリ ツリーをシミュレートするために「/」セパレータを使用する 1 次元のフラット KV 構造があります。

オブジェクト ストレージでディレクトリ名の変更を実装する場合 (たとえば、foo ディレクトリの名前を bar に変更する場合)、オブジェクト ストレージの実装にはいくつかの手順があります。最初の手順は再帰的にコピーすることです。非常に深いディレクトリの場合は、ディレクトリ全体のデータをプレフィックスとして bar が付いた場所に再帰的にコピーする必要があります。 2 番目のステップは、いくつかの内部インデックスを更新することです。最後に、元の foo ディレクトリ内の関連データをすべて削除します。

プロセス全体は、フォルダーの名前を変更する 1 ステップの操作のように見えますが、実際にはオブジェクト ストレージ内でいくつかの大きなステップに分かれています。各ステップ、特に第 1 ステップと第 3 ステップは特に軽いようには見えません。

当然、次のような疑問が生じます。特に大量のデータを含むディレクトリの名前を変更する場合、このプロセスで一貫性を確保するにはどうすればよいのでしょうか。実際のところ、オブジェクトの保存を保証する方法はありません。コミュニティには、オブジェクト ストレージ インターフェイスに基づいて解決または最適化を試みるコンポーネントが多数あります。ただし、一貫性の問題を回避することはできますが、完全に解決することはできません。オブジェクト ストレージ アーキテクチャ設計の問題は、外部コンポーネントによって単純に回避することはできないためです。

3. オブジェクトストレージメタデータのパフォーマンスとAPIの制限

データ レイクのコンポーネントでは、Hudi 氏と Iceberg 氏の両方がオブジェクト ストレージに関するいくつかの問題について言及しています。たとえば、上記の表は Hudi 文書に記載されています。オブジェクト ストレージ上のディレクトリを一覧表示する場合、ディレクトリ内のファイル数が増えるにつれて、レイテンシが徐々に増加するため、Hudi コミュニティではメタデータ テーブル設計を採用しています。

Iceberg は文書の中で、オブジェクト ストレージには固定プレフィックスに基づく API QPS 制限がいくつかあることも言及しています。頻繁にアクセスされるディレクトリや大規模なデータ セットがこの API QPS 制限に達すると、タスクの安定性が直接影響を受けます。特に、データ プラットフォームの規模が大きくなると、クラウド オブジェクト ストレージの API QPS 制限に達しやすくなります。そのため、Iceberg にはこの問題を回避するための ObjectStorageLocationProvider があります。これは本質的に、異なるキーの前にランダムなハッシュを追加する回避的な実装方法です。このハッシュの目的は、プレフィックスベースの QPS 制限を可能な限り異なるプレフィックスに分散し、API QPS 制限にすぐに達するのを回避することです。

3. 湖と倉庫を統合した建築の将来の保管場所の選択を探る

現在のクラウド コンピューティングまたはクラウド ネイティブ環境に基づいて、現在および将来に適したストレージ システムをゼロから構築すると仮定すると、そのストレージ システムはどのような機能を備えている必要がありますか?

1. 主な技術的ポイント

ほとんどのシナリオで重要なポイントは次のとおりです。

最初で最も重要な問題はスケーラビリティです。ビッグデータ プラットフォームのアーキテクチャがデータ ウェアハウスからデータ レイク、さらに統合ウェアハウスとレイクへと進化するにつれて、プラットフォームのストレージ容量に対する要件はますます高くなります。従来のデータ ウェアハウスのストレージ ニーズを満たすだけでなく、可能な限り多くのビジネスをカバーすることも必要です。データ サイロの問題を回避するために、以前は異なるストレージ システムで管理されていたデータを 1 か所に統一された方法で保存および管理する必要がある場合があります。

2 番目に非常に重要な点は、高可用性です。システム全体に高可用性機能が必要です。高可用性がなければスケーラビリティだけを実現することはできません。そうでなければ、生産ニーズを満たすことができません。

3 番目のポイントはパフォーマンスの問題です。大量のデータを保存するためにパフォーマンスを犠牲にすることはできません。メタデータのパフォーマンスやデータの読み取りおよび書き込みのパフォーマンスなどのパフォーマンスを確保するには、特定の最適化戦略が必要です。

次のステップは、クラウドの利点を最大限に活用することです。クラウドの最大の特徴は弾力性です。コンピューティングとストレージはどちらも弾力性があります。ストレージ システム アーキテクチャ全体がクラウドの柔軟なスケーリング特性に適応できず、コンピュータ ルームの以前のストレージ アーキテクチャを引き続き使用する場合、クラウドの特性を最大限に活用することはできません。

クラウドは、ストレージとコンピューティングが分離されている自然なシナリオです。エコシステム全体のコンピューティング コンポーネントとストレージ コンポーネントを分離し、分離後の全体的なコンピューティング効率とスケーラビリティを確保する方法はすべて、基盤となるストレージ システムが考慮する必要がある問題です。

小規模なファイルの管理は、データ レイクが考慮する必要がある問題です。従来のビッグデータ プラットフォームでは依然として大きなファイルが主流ですが、AI や他の分野のデータが入ってくると、小さなファイルの問題がますます顕著になるでしょう。

上の図に示すように、上記の技術的なキーポイントごとに、対応するソリューションがいくつかあります。

2. ジュースFS

今回ご紹介する JuiceFS は、強力な一貫性を備えた分散ファイルシステムとして位置付けられています。その設計目標は、HDFS を完全に置き換えることであると考えられます。

JuiceFS の全体的なアーキテクチャは、メタデータ ストレージ、データ ストレージ、およびさまざまなクライアントのインターフェイスという 3 つの部分に分かれており、HDFS と非常によく似ています。しかし、実際には、それぞれの作品には異なるデザインがあります。

まず、JuiceFS のメタデータはプラグイン エンジン設計です。 Redis、MySQL、TiKV など、さまざまなシナリオに合わせてさまざまなデータベースを選択できます。ビジネス シナリオとビジネス ニーズに基づいて、JuiceFS のメタデータ エンジンとして最も適したデータベースを選択できます。

データストレージに関しては、JuiceFS は主にオブジェクトストレージに基づいており、クラウド上のストレージリソースを最大限に活用できます。すべてのデータはオブジェクト ストレージに配置されますが、単にオブジェクト ストレージに書き込まれるわけではありません。 JuiceFS クライアントを通じて書き込まれたデータは、何らかのフォーマット処理 (HDFS DataNode のブロック設計に類似) を受け、メタデータはオブジェクト ストレージのメタデータに依存しないようにします。これは、前述のように、オブジェクト ストレージのメタデータには一貫性やパフォーマンスの問題など、多くの問題があるためです。 JuiceFS はオブジェクト ストレージ メタデータに依存せず、代わりに独自の独立したメタデータ ストレージを使用してすべてのメタデータ要求を処理します。

メタデータ エンジンは水平方向に拡張でき、サイズの大小を問わず、膨大なファイル (数百億ファイルなど) を簡単に保存できます。 JuiceFS ユーザーの実稼働環境では、実際に数百億の規模を達成しており、これはストレージ システムの優れたスケーラビリティの良い証拠です。

キャッシュは、特にストレージとコンピューティングを分離するシナリオでは非常に重要な機能です。ストレージとコンピューティングを分離したアーキテクチャにアップグレードする必要がある場合は、キャッシュ機能を考慮する必要があります。メタデータ キャッシュとデータ キャッシュの両方が必要です。

4. JuiceFS におけるレイクストレージ統合アーキテクチャの実践

1. レイク・ウェアハウス統合アーキテクチャ

これは全体的なアーキテクチャ図です。下部には、従来の構造化データと、大量の半構造化データおよび非構造化データが含まれています。ストレージ層は、JuiceFS とオブジェクト ストレージを組み合わせて、統合されたストレージ ベースを提供します。

さらに上位には Delta Lake、Hudi、Iceberg などのデータ管理レイヤーがあり、基盤となるストレージ システム JuiceFS、HDFS、またはオブジェクト ストレージに基づいてデータ ウェアハウス全体を管理します。

次に、さまざまなクエリ エンジン、BI ツール、コンピューティング エンジンがさまざまな管理層コンポーネントに接続されます。

2. メタデータのパフォーマンス比較

上図はOSS、HDFS、JuiceFSに代表されるオブジェクトストレージを比較したものです。左側にはメタデータのレイテンシが表示されます。値が低いほど良いです。右側はスループットを示しています。値が大きいほど良いです。

まず、青いオブジェクトストレージを見てみましょう。他の 2 つと比較すると、オブジェクト ストレージのレイテンシは、異なるメタデータを操作するときに大きく異なります。特に、上記の名前変更操作では、他の 2 つのストレージ システムと比較して、オブジェクト ストレージのパフォーマンスが大幅に低下します。 HDFS と JuiceFS はアーキテクチャ設計が似ており、どちらも独立したメタデータ ストレージを備えているため、レイテンシとスループットはどちらも比較的高速です。右の図では、スループットの点では JuiceFS が HDFS よりも優れたパフォーマンスを発揮しています。

3. データクエリのパフォーマンス比較

上の図は、データクエリのパフォーマンスの比較です。左の図は、オブジェクト ストレージと JuiceFS 上の Spark を使用した TPC-DS クエリ テストです。右の図は、HDFS と JuiceFS 上で Presto を使用するテストです。

左の図からわかるように、クエリのパフォーマンスに関しては、JuiceFS はオブジェクト ストレージを直接使用する場合と比較して指数関数的なパフォーマンスの向上を実現できます。特に、比較的複雑なクエリ (9 番目のクエリなど) では、パフォーマンスの向上がより顕著になります。

右の図に示すように、JuiceFS が完全にキャッシュされると、ストレージとコンピューティングの分離アーキテクチャにより、HDFS に匹敵するクエリ パフォーマンスを実現できます。

したがって、一般的に、メタデータ パフォーマンス テストであっても、TPC-DS に基づく全体的なクエリ テストであっても、JuiceFS は HDFS と一貫したパフォーマンスを実現でき、同時にオブジェクト ストレージよりも大幅なパフォーマンス上の利点があります。

4. 質疑応答

Q1: HDFS がストレージとコンピューティングを分離したアーキテクチャではないということは、それが廃止されることを意味しますか?

A1: 短期から中期的には、HDFS は依然としてビッグデータ エコシステムにおける事実上の標準であるため、廃止されることは絶対にないと思います。ビッグデータ プラットフォームがクラウド上に導入されて初めて、クラウド上にビッグデータ プラットフォームのストレージ システムを構築する方法が再考されるでしょう。企業によっては、コンピューター ルームのインフラストラクチャ全体をクラウドに移行することを選択する場合があります。実際、そうすることでコストはコンピューター室に保管するよりも高くなる可能性がありますが、少なくとも全体的なアーキテクチャは検証されます。しかし、クラウド移行の本来の目的が達成されず、クラウドの特性を十分に活かすことができません。 HDFS に基づくストレージ コンピューティング結合アーキテクチャをクラウドに移行しても、クラウドのメリットは得られません。そのため、多くの企業がオブジェクト ストレージや JuiceFS のような新世代のストレージ システムを選択し始めています。

Q2: S3 オブジェクト ストレージ設計自体に KV 設計上の欠陥がありますが、これは排除されるということでしょうか?

A2: S3 はもともとビッグデータ エコシステム向けに設計されたものではないため、位置付けが異なります。その位置づけは非常に明確です。大量の非構造化データを保存し、拡張が容易で、信頼性が高く、データの損失を防ぎ、ストレージ コストが十分に低い (EC などのテクノロジを使用) ことです。これらは S3 の利点であり、そのような需要がある限り非常に適用可能です。しかし、ビッグデータや AI などのシナリオで特別なのは、ストレージのスケール要件を満たすだけでは不十分で、パフォーマンス要件、ビジネス全体への影響など、さまざまな他の要件も満たす必要があることです。これらは、S3 やオブジェクト ストレージだけでは満たせない、より厳しい要件であると考えています。したがって、オブジェクト ストレージに基づいてさらなる改善と機能強化を行うには、新しい設計や新しいシステムが必要です。 S3 自体は間違いなくなくなることはありません。

Q3: ストレージとコンピューティングを分離したアーキテクチャとストレージとコンピューティングを統合したアーキテクチャでは、どのストレージ アーキテクチャがどのシナリオに適していますか?

A3: 一般的に言えば、ストレージとコンピューティングの分離、またはストレージとコンピューティングの結合は、現在の全体的なアーキテクチャに基づきます。データ プラットフォームや AI プラットフォーム全体をクラウド上に構築することを検討している場合は、当然、クラウド リソースをさらに活用することを検討することになります。クラウド リソースの弾力性を最大限に高めるには、ストレージとコンピューティングを分離する必要があります。最初はストレージとコンピューティングが結合されたアーキテクチャであったとしても、長期的にはストレージとコンピューティングが分離されたアーキテクチャへと移行する必要があります。クラウドに移行する必要がなく、コンピュータ ルームに独自のプライベート クラウド アーキテクチャがある場合、ストレージとコンピューティングの分離を使用するか、ストレージとコンピューティングの結合を使用するかは、あまり違いはありません。ストレージとコンピューティングが分離されたアーキテクチャでクラウドの利点をどのように活用するかが重要です。

Q4: JuiceFS と Alluxio の違い。

A4: いい質問ですね。 JuiceFS の公式ドキュメントには、JuiceFS と Alluxio を比較した特別な記事があります。興味があれば、公式ドキュメントにアクセスしてご覧ください。簡単に言えば、JuiceFS の設計目標または位置付けは、HDFS などの従来の分散ファイルシステムに匹敵する分散ファイルシステムです。私の理解する限りでは、Alluxio はキャッシュ レイヤーとして設計されています。このキャッシュ レイヤーの目的は、完全なファイル システム機能を実装することではありません。たとえば、POSIX と完全に互換性がある必要はなく、ビッグデータ以外のシナリオ向けにさまざまな機能を提供する必要もありません。ただし、JuiceFS は分散ファイルシステムとして位置付けられているため、ファイルシステムが考慮する必要がある点を多く考慮する必要があります。 Alluxio と JuiceFS の一部の機能 (キャッシュなど) には重複があるかもしれませんが、2 つのプロジェクトの設計方向が同じであることを意味するものではありません。

Q5: ストレージとコンピューティングを分離したアーキテクチャの効率は、統合したものよりも低くなりますか?

A5: 最適化を行わずにストレージとコンピューティングを単純に分離すると、効率は確実に低下します。ネットワーク ハードウェア テクノロジは非常に進歩していますが、ローカル I/O ほど効率的ではない場合があります。そのため、ストレージとコンピューティングを単純に分割するだけでは確実に効率が下がるため、ストレージとコンピューティングを分離した上で、さらにパフォーマンスを最適化する方法を検討する必要があります。ビジネスの品位を低下させたり、ビジネスの日常的な指標に悪影響を与えたりしないようにしてください。