Fluid supports sub-datasets

Fluid とは

クラウドネイティブアーキテクチャを通じて AI やビッグデータなどのタスクをクラウド上で実行すると、コンピューティングリソースの伸縮性という利点を享受できますが、同時に、コンピューティングとストレージの分離アーキテクチャに起因するデータアクセスの遅延や、リモートからデータを引き出す際の帯域幅オーバーヘッドといった課題にも直面します。特に GPU を使ったディープラーニングのトレーニングシナリオでは、大量のトレーニングデータを反復的にリモート読み込みすることで、GPU のコンピューティング効率が大きく低下してしまいます。

一方、Kubernetes は異種ストレージサービスへのアクセスと管理のための標準インターフェース（CSI、Container Storage Interface）を提供していますが、アプリケーションがコンテナクラスター内でデータをどのように使用・管理するかについては定義していません。トレーニングタスクを実行する際、データサイエンティストはデータセットのバージョン管理、アクセス権限の制御、データセットの前処理、異種データの読み込み加速などを行う必要があります。しかし、Kubernetes にはこのような標準ソリューションが存在せず、これはクラウドネイティブコンテナコミュニティで欠落している重要な機能の 1 つです。

Fluid は「コンピューティングタスクでデータを使用するプロセス」を抽象化し、Elastic Dataset という概念を提唱し、Kubernetes 内で「ファーストクラスシチズン」として実装されています。Fluid は Elastic Dataset を中心にデータオーケストレーション・アクセラレーションシステムを構築し、Dataset 管理（CRUD 操作）、権限制御、アクセス加速といった機能を実現しています。

Fluid には 2 つのコア概念があります：Dataset と Runtime です。

• Dataset はデータセットを指し、論理的に関連するデータの集合で、Spark、TensorFlow、PyTorch などのコンピューティングエンジンによって使用されます。
• Runtime は分散キャッシュを提供するシステムを指します。現在、Fluid がサポートする Runtime のタイプには、JuiceFS、Alluxio、JindoFS、GooseFS があります。Alluxio と JindoFS は典型的な分散キャッシュエンジンです。JuiceFS は分散キャッシュ機能を備えた分散ファイルシステムです。これらのキャッシュシステムは、Kubernetes クラスター内のノード上のストレージリソース（メモリやディスクなど）を、リモートストレージシステムのコンピューティング側キャッシュとして使用します。

なぜ Fluid はサブ Dataset（subDataset）をサポートする必要があるのでしょうか？

Fluid の初期モードでは、デフォルトで 1 つの Dataset が 1 つの Runtime を専有していました。これは、1 つの Dataset に対して専用キャッシュクラスターによるアクセラレーションを行うと理解できます。データセットの特性（単一ファイルのサイズ、ファイル数、クライアント数など）に応じてカスタマイズ・最適化が可能で、独立したキャッシュシステムが提供されるため、最高のパフォーマンスと安定性を発揮し、相互干渉もありません。しかし、ハードウェアリソースの無駄であり、異なるデータセットごとにキャッシュシステムをデプロイする必要があり、同時に複数のキャッシュ Runtime を管理する必要があり、運用・保守が複雑になります。実際、このモードは本質的にシングルテナントアーキテクチャであり、データアクセスのスループットとレイテンシに厳しい要件があるシナリオに適しています。

もちろん、Fluid の利用が進むにつれて、さまざまな要件も出てきました。コミュニティからの一般的な要件の 1 つは次のとおりです：

1. データセットキャッシュを名前空間間でアクセスできるようにする
2. ユーザーがデータセットの特定のサブディレクトリにのみアクセスできるようにする
特に JuiceFS ユーザーは、Dataset を使って JuiceFS のルートディレクトリを指すようにする傾向があります。そして、異なるサブディレクトリを異なるデータサイエンティストグループに異なるデータセットとして割り当て、互いのデータセットが見えないようにすることを望んでいます。同時に、サブデータセットの権限厳格化もサポートしています。たとえば、ルートデータセットは読み取り・書き込みをサポートし、サブデータセットを読み取り専用に制限できます。

この記事では、AlluxioRuntime を例にして、Fluid を使ってサブデータセット機能を使用する方法を示します。

使用例：

ユーザー A が Kubernetes 名前空間 spark の下に dataset spark を作成し、その中に spark の 3 つのバージョンを含んでいるとします。チーム A はデータセット spark-3.1.3 のみを表示でき、チーム B はデータセット spark-3.3.1 のみを表示できるようにしたいとします。

これにより、異なるチームが異なるサブデータセットにアクセスでき、互いのデータを見ることができません。

フェーズ 1：管理者がデータセットを作成し、ルートディレクトリを指す

1. この例を実行する前に、インストールドキュメントを参照してインストールを完了し、Fluid の各コンポーネントが正常に動作していることを確認してください

2. 名前空間 spark を作成

3. 名前空間 development に Dataset と AlluxioRuntime を作成します。このとき、データセットは読み取り・書き込み可能です

4. データセットのステータスを確認

5. 名前空間 spark に Pod を作成してデータセットにアクセス

6. データセットを通じてアプリケーションがアクセスできるデータを確認すると、3 つのフォルダ（spark-3.1.3、spark-3.2.3、spark-3.3.1）が表示され、マウント権限が RW（ReadWriteMany）であることが確認できます

フェーズ 2：管理者がサブデータセットを作成し、ディレクトリ spark 3.1.3 を指す

1. 名前空間 spark-313 を作成

2. 名前空間 spark-313 の下で、管理者が以下を作成：
- データセット spark を参照します。mountPoint の形式は dataset://${初期データセットがある名前空間}/${初期データセットの名前}/サブディレクトリ で、この例では dataset://spark/spark/spark-3.1.3 になります
注意：現在、参照されるデータセットは 1 つのマウントのみをサポートし、形式は dataset:// でなければなりません（つまり、dataset:// と他の形式が混在するとデータセットの作成に失敗します）。データセットの権限は読み取り・書き込みです。

3. データセットのステータスを確認

4. ユーザーが名前空間 spark-313 に Pod を作成：

5. 名前空間 spark-313 のデータにアクセスすると、spark-3.1.3 フォルダの内容のみが表示され、PVC 権限が RWX であることが確認できます

フェーズ 3：管理者がサブデータセットを作成し、ディレクトリ spark 3.3.1 を指す

1. 名前空間 spark-331 を作成

2. 名前空間 spark-331 の下で、管理者が以下を作成：
- データセット spark を参照します。mountPoint の形式は dataset://${初期データセットがある名前空間}/${初期データセットの名前}/サブディレクトリ で、この例では dataset://spark/spark/spark-3.3.1 になります
注意：現在、参照されるデータセットは 1 つのマウントのみをサポートし、形式は dataset:// でなければなりません（つまり、dataset:// と他の形式が混在するとデータセットの作成に失敗します）。指定された読み取り・書き込み権限は読み取り専用 ReadOnlyMany です。

3. ユーザーが名前空間 spark-331 に Pod を作成：


4. 名前空間 spark-331 のデータにアクセスすると、spark-3.3.1 フォルダの内容のみが表示され、PVC 権限が ROX（ReadOnlyMany）であることが確認できます

まとめ：

この例では、サブデータセットの機能を示しました。これは、データセットのサブディレクトリをデータセットとして使用する方法です。同じデータセットを異なるデータサイエンティストが異なる分割戦略に従って使用できるようにします。