JindoFS storage strategy and read and write optimization

データキャッシュシナリオ

従来のビッグデータ分析分野では、HDFS が事実上のストレージ標準でした。HDFS は、コンピューティングリソースとストレージリソースを同じクラスタ内にデプロイする典型的な構成であり、つまりコンピュートとストレージの統合アーキテクチャです (下図の左側参照。このアーキテクチャでは、クラスタのコンピュート能力とストレージ容量を非対称に拡張できないという課題があります)。近年のデータクラウドの趨勢と発展に伴い、ビッグデータ分析の場面ではコンピュートとストレージの分離アーキテクチャが徐々に普及しています。ますます多くの顧客がこのアーキテクチャを選択してクラスタをデプロイしています。従来の HDFS ベースのシステムアーキテクチャとの違いは、コンピュートリソースとストレージリソースが物理的に分離されている点です。コンピュートクラスタとバックエンドストレージクラスタはネットワーク経由で接続され、下図の右側に示す構成となります。コンピュートクラスタの大量のデータ読み書き操作は、ネットワークリクエストを通じてストレージクラスタとやり取りします。このシナリオでは、ネットワークスループットがジョブ実行プロセス全体のパフォーマンスボトルネックとなりがちです。

したがって、このアーキテクチャでは、コンピュート側 (コンピュートクラスタ内) にバックエンドストレージクラスタ用のキャッシュ層を構築し、キャッシュ層でデータをキャッシュしてコンピュートクラスタからストレージバックエンドへのネットワークアクセスを削減し、ネットワークスループットによるボトルネックを大幅に解消することが非常に重要です。

JindoFS によるキャッシュ高速化

JindoFS は、コンピュートとストレージの分離シナリオにおいて、ストレージ側のデータキャッシュ高速化の役割を果たします。そのアーキテクチャとシステム内での位置づけを下図に示します。

まず、JindoFS は以下の 3 つのコンポーネントで構成されます。

1: JindoFS SDK クライアント：すべての上層コンピュートエンジンは、JindoFS SDK が提供するクライアント経由で JindoFS ファイルシステムにアクセスし、バックエンドストレージのキャッシュ高速化を実現します。

2: Namespace Service：JindoFS のメタデータ管理およびストレージサービス管理を担当します。

3: Storage Service：ユーザーデータ管理を担当し、ローカルデータ管理と OSS データ管理を含みます。

JindoFS はクラウドネイティブなファイルシステムであり、ローカルストレージの高性能と OSS の大容量を両立し、多様なバックエンドストレージをサポートします。

クラウドデータレイクシナリオでは、オブジェクトストレージをデータレイクのバックエンドとして使用できます。

リモート HDFS の高速化

クロスリージョンでの HDFS デプロイ

ハイブリッドクラウドシナリオでのオフラインコンピュートクラスタによるオフライン HDFS クラスタへのアクセスなど

データ読み書き戦略と最適化

書き込みポリシー

JindoFS のデータ書き込み戦略は、下図に示すように 2 種類に分かれます。

書き込みプロセスにおいて、クライアントは対応する Storage Service のキャッシュブロックにデータを書き込み、Storage Service はマルチスレッドでキャッシュデータブロックをバックエンドストレージに並列アップロードします。

パススルー方式は、JindoFS SDK 経由で直接バックエンドストレージにアップロードします。SDK 内では多数のパフォーマンス最適化が施されています。この方式は、データプロデューサー環境、すなわちデータの生成のみを担当し、後続のコンピュートや読み取りの要件がない場合に適しています。

読み取り戦略

読み取り戦略は JindoFS の核心です。キャッシュを通じて、JindoFS のストレージ容量を活用してローカルクラスタ内に分散キャッシュサービスを構築します。リモートデータをローカルクラスタに保存して「ローカル化」し、繰り返しのデータ読み取りリクエストを高速化します。最も高速な方法またはパスでキャッシュ内のデータを読み取り、最高の読み取り性能を実現します。この原則に基づき、データ読み取り戦略は以下の通りです。

まず、ローカルノードからキャッシュデータブロックを読み取ります (例：Block1、Block2)。

ローカルノードにキャッシュが存在しない場合、クライアントは Namespace Service にキャッシュデータブロックの位置を照会します。たとえば、読み取り対象のデータ Block3 が Node2 にある場合、Node2 から Block3 を読み取ります。

いずれのノードにも存在しない場合、リモート OSS ストレージクラスタからデータを読み取り、同時にローカル Storage Service のキャッシュに追加して、次回の読み取りを高速化します。

上記の基本戦略に加え、JindoFS は動的マルチレプリカ戦略をサポートします。関連パラメータの設定後、他のノードから同時にデータを読み取り、キャッシュ内にレプリカを保持することで、ホットデータブロックへの読み取りアクセスをさらに高速化できます。

Cache Locality

HDFS のデータローカリティと同様に、Cache Locality とは、コンピュート層がまずデータブロックが所在するノードにタスクをプッシュして実行する戦略です。この戦略により、タスクがまずローカルのキャッシュデータを読み取るという最も効率的な読み取り方法が実現し、最高のデータ読み取り性能を発揮できます。

JindoFS の Namespace Service はすべてのキャッシュデータブロックの位置情報を管理しており、関連する API インターフェースを通じてデータブロックの位置情報をコンピュート層に提供します。これにより、コンピュート層はタスクをキャッシュデータブロックが所在するノードにプッシュでき、大部分のデータをローカルから読み取ることができ、一部のデータのみネットワーク経由で取得すればよくなります。Cache Locality に基づき、大部分のデータがローカルで読み取られるため、コンピュートジョブで最高のデータ読み取り性能を保証できます。

JindoFS の使用方法

基本的な使用モード：

Block モード：JindoFS がメタデータ管理を担当し、OSS を純粋なバックエンドストレージデータブロックとして使用します。

Cache モードは透過的であり、ユーザーに意識されません。

2.1. Cache を有効にしない場合。クラスタサイズが小さく、キャッシュが不要な場合です。

2.2. Cache を有効にする場合。ローカルキャッシュブロックにより OSS の帯域幅不足を解消します。(設定項目 jfs.cache.data-cache.enable で有効/無効を制御します。0 で無効、1 で有効)

キャッシュデータ管理

キャッシュシステムとして、JindoFS は限られたローカルキャッシュリソースで、ほぼ無制限の容量を持つ OSS バックエンドをキャッシュします。キャッシュデータ管理の主な機能は以下の通りです。

ローカルキャッシュブロック管理

ローカルデータブロックのライフサイクル維持

Storage Service はデータアクセス情報の管理を実装しており、すべての読み書きが AccessManager に登録されます。storage.watermark.high.ratio および storage.watermark.low.ratio の設定項目を提供し、キャッシュデータを管理します。ローカルディスクのキャッシュ使用量が storage.watermark.high.ratio の警告レベルに達すると、AccessManager は自動的にクリーニングメカニズムをトリガーし、ローカルディスク内の一部のコールドデータを storage.watermark.low.ratio のレベルまで排除して、ホットデータ用のディスク領域を解放します。

キャッシュブロックの自動クリーニング

現在、LRU (Least Recently Used) 排除戦略に基づくコールドデータブロックの自動排除とクリーニングを提供します。

非同期のコールドデータクリーニングは、読み書きに影響を与えません。

指定キャッシュの表示

指定キャッシュも提供されています。

cache/uncache コマンドを使用して、バックエンドディレクトリやファイルを明示的にキャッシュしたり、コールドデータを解放したりできます。

ベストプラクティス

クラスタの構成方法

できるだけ常駐時間の長いノードをキャッシュに使用する

キャッシュノードのディスク

キャッシュノードのネットワーク帯域幅

関連する設定項目は以下の通りです。

jfs.storage.server.cache-mode:CACHE/NOCACHE

データローカリティ関連の設定

spark.locality.wait.rack3s-> 0

spark.locality.wait.node3s -> 0