1. 内部
  2. ファイルシステム

ファイルシステム

Flink org.apache.flink.core.fs.FileSystem クラスによって独自のファイルシステム抽象を持ちます。この抽象化はオペレーションの共通セットと、さまざまな種類のファイルシステム実装を横断して最小限の保証を提供します。

広範囲のファイルシステムをサポートするために、利用可能なオペレーションのファイルシステムのセットは非常に制限されます。例えば、既存のファイルへの追加あるいは変更はサポートされません。

ファイルシステムは、file://, hdfs://などのようなファイルシステムのスキーマによって識別されます。

実装

Flink は以下のファイルシステムスキーマを使って、ファイルシステムを直接に実装します:

  • file、マシーンのローカルファイルシステムを表します。

他のファイルシステムの型は Apache Hadoopでサポートされるファイルシステムのスイーツへの橋掛けをする実装によってアクセスされます。以下は例の完全ではないリストです:

  • hdfs: Hadoop 分散ファイルシステム
  • s3, s3n および s3a: Amazon S3 ファイルシステム
  • gcs: Google Cloud Storage
  • maprfs: MapR 分散ファイルシステム
  • …

もしクラスパス中にHadoopファイルシステムが見つかり、有効なHadoop設定がある場合は、Flink は Hadoopのファイルシステムを透過的にロードします。デフォルトでは、クラスパス内でHadoopの設定を探します。別のやりかたとして、設定エントリ fs.hdfs.hadoopconfを使って独自の場所を指定することができます。

一貫性の保証

これらの FileSystem とその FsDataOutputStream インスタンスは、アプリケーションの結果と耐障害性と回復のために永続的にデータを格納するために使われます。従ってこれらのストリームの永続性のセマンティクスが良く定義されていることが重要です。

一貫性の保証の定義

以下の2つの要求に合致する場合は、出力ストリームに書き込まれるデータは永続的なものとみなされます:

  1. 可視性の要求: ファイルにアクセスすることができる全ての他のプロセス、マシーン、仮想マシーン、コンテナなどが、絶対ファイルパスを与えられた時に確実にデータを見ることが保証されなければなりません。この要求はPOSIXで定義されるclose-to-open セマンティクスに似ていますが、(その絶対パスによる)ファイル自身に制限されます。

  2. 持続性の要求: ファイルシステム固有の持続性/永続性の要求が一致しなければなりません。これらは特定のファイルシステムに固有です。例えば、{@link LocalFileSystem} はハードウェアおよびオペレーティングシステムの両方のクラッシュでの持続性の保証を提供しませんが、(HDFSのような)複製された分散ファイルシステムは一般的にn個の同時のノードの障害に遭遇した時に持続性を保証します。ここでn はリプリケーションの要素です。

Updates to the file’s parent directory (such that the file shows up when listing the directory contents) are not required to be complete for the data in the file stream (ディレクトリの内容をリスト化する時に現れるファイルのような)ファイルの親のディレクトリへの更新は、永続的だと見なされるファイルストリーム内でのデータで完了することを必要としません。この緩さはディレクトリの内容が結果的に永続的なファイルシステムにとって重要です。

FSDataOutputStreamはFSDataOutputStream.close() への呼び出しが一旦返ると、書き込まれたバイトについてのデータの持続性を保証する必要があります。

例

  • 耐障害性分散ファイルシステムについては、一般的に定数のマシーンへリプリケーションをすることで、データは一度受信され、ファイルシステムによって通知された場合は永続していると見なされます 持続性の要求)。更に絶対ファイルパスは潜在的にファイルにアクセスするだろう全ての他のマシーンへ見えなければなりません(可視性の要求)。

    データがストレージノード上の非揮発性のストレージに当たるかどうかは特定のファイルシステムの固有の保証に依存します。

    ファイルの親ディレクトリへの更新のメタデータは一貫性の状態への到達には必要ありません。親ディレクトリの内容をリスト化する時に幾つかのマシーンが見れて他は見れないことは、絶対パスによって全てのノード上でファイルへのアクセスが可能な限り許されます。

  • ローカルファイルシステム はPOSIXのclose-to-open セマンティクスをサポートしなければなりません。ローカルファイルシステムは耐障害性の保証を持たないため、それ以上の要求はありません。

    ローカルファイルシステムの観点から永続的だと見なされる場合、上のことは厳密にはデータはまだOSキャッシュの中にあるかもしれないということを意味します。OSのキャッシュにデータを失わせるクラッシュはローカルマシーンにとって致命的だと見なされ、Flinkで定義されるようなローカルファイルシステムの保証によってカバーされません。

    つまりローカルファイルシステムにのみ書き込まれた計算の結果、チェックポイント およびセーブポイントはローカルマシーンの障害時に回復できる保証は無いことを意味し、ローカルファイルシステムはプロダクションのセットアップに適していないことになります。

ファイル内容の更新

多くのファイルシステムは、既存のファイルの内容の上書きを全くサポートしないか、あるいはその場合の更新された内容の一貫性のある可視性をサポートしないかのどちらかです。その理由により、Flinkのファイルシステムは既存のファイルへの追加、あるいは同じファイル内で変更されるかもしれない事前に書き込まれたデータのような出力ストリーム内の検索をサポートしません。

ファイルの上書き

ファイルの上書きは一般的に可能です。ファイルを削除し新しいファイルを作成することで、ファイルは上書きされます。しかし、あるファイルシステムはその変更をファイルにアクセスする全ての関係者へ同期的に見えるようにすることができません。例えば、Amazon S3 はファイルの置き換えの可視性において結果的な一貫性のみを保証します: 幾つかのマシーンは古いファイルを見て、幾つかのマシーンは新しいファイルを見るかもしれません。

これらの一貫性の問題を避けるために、Flinkでの障害/回復の仕組みの実装は1回以上の同じファイルパスへの書き込みを厳密に避けます。

スレッド セーフ

FileSystem の実装はスレッドセーフでなければなりません: FileSystemの同じインスタンスはFlink内の複数のスレッドにまたがって頻繁に共有され、同時に入力/出力ストリームを作成しファイルのメタデータをリスト化できる必要があります。

FSDataOutputStream と FSDataOutputStream の実装は厳密にスレッドセーフではありません。スレッド(多くのオペレーションはメモリーのフェンスを作成しません)をまたがったオペレーションの可視性についての保証がないため、ストリームのインスタンスは読み込みあるいは書き込みのオペレーションの間でスレッド間の受け渡しもされるべきではありません。

上に戻る

TOP
inserted by FC2 system