View File System (ViewFS) の2つの主要な課題を解決するために導入されたView File System Overload Scheme。1つ目の問題は、ViewFSを使用するには、ユーザーがfs.defaultFSをviewfsスキーム (viewfs://) で更新する必要があることです。2つ目の問題は、ユーザーがマウントテーブル構成をすべてのクライアントノードにコピーする必要があることです。ViewFileSystemOverloadSchemeは、これらの課題に対処しています。
ファイルシステムオーバーロードスキームは、View File Systemの拡張機能です。これにより、ユーザーはスキームviewfsを使用する代わりに、既存のfs.defaultFSで設定されたスキームまたは任意の新しいスキーム名を引き続き使用できます。マウントリンク構成のキーと値の形式は、ViewFSガイドと同じです。ユーザーが同じfs.defaultFSを引き続き使用し、さらに多くのマウントポイントが必要な場合、マウントリンク構成には、マウントテーブル名としてViewFileSystemOverloadSchemeの初期化されたURIのホスト名が必要です。例として、fs.defaultFSがhdfs://myclusterの場合、マウントリンク構成のキー名は、次の形式fs.viewfs.mounttable.*mycluster*.link.<mountLinkPath>である必要があります。初期化されたfs URIにhostname:portが含まれている場合でも、ポート番号は無視され、ホスト名のみがマウントテーブル名として考慮されます。次のセクションで、構成例について詳しく説明します。初期化URIのホスト名をマウントテーブル名として構成されたマウントリンクがない場合、現在のURIがフォールバックターゲットfs URI (fs.viewfs.mounttable.*mycluster*.linkFallback)として自動的に考慮されます。初期化されたURIにパス部分が含まれている場合、スキームとオーソリティ部分のみが考慮され、パス部分は考慮されません。例として、初期化されたURIにhdfs://mycluster/dataが含まれている場合、フォールバックターゲットfs URIとしてhdfs://myclusterのみが考慮されます。パス部分dataは無視されます。
ViewFileSystemOverloadSchemeのもう1つの重要な改善点は、管理者がmount-table.xml構成ファイルを数千のクライアントノードにコピーする必要がないことです。代わりに、Hadoop互換ファイルシステムにマウントテーブル構成ファイルを保存できます。したがって、構成ファイルを中央の場所に保存することで、管理者は1つの場所でマウントテーブルを更新できるため、管理者の負担を軽減できます。
このクラスを使用するには、次の構成をcore-site.xmlファイルに追加する必要があります。
<property> <name>fs.<scheme>.impl</name> <value>org.apache.hadoop.fs.viewfs.ViewFileSystemOverloadScheme</value> </property>
ここで、<scheme>は、fs.defautFSで構成されたURIスキームと同じである必要があります。たとえば、fs.defaultFSがhdfs://myclusterで構成されている場合、上記の構成は次のようになります。
<property> <name>fs.hdfs.impl</name> <value>org.apache.hadoop.fs.viewfs.ViewFileSystemOverloadScheme</value> </property>
例1
ユーザーが既存のクラスタ (hdfs://cluster) のデータをhdfs(hdfs://cluster) やその他のオブジェクトストアクラスタ(o3fs://bucket1.volume1.omhost/, s3a://bucket1/) にマウントしたい場合、次の構成例は、マウントリンクを追加する方法を示しています。
<property> <name>fs.viewfs.mounttable.cluster.link./user</name> <value>hdfs://cluster/user</value> </property> <property> <name>fs.viewfs.mounttable.cluster.link./data</name> <value>o3fs://bucket1.volume1/data</value> </property> <property> <name>fs.viewfs.mounttable.cluster.link./backup</name> <value>s3a://bucket1/backup/</value> </property>
マウントリンクに基づいて、これらの操作がどこに委任されるかを理解するために、次の操作を検討しましょう。
Op1:パスhdfs://cluster/user/fileAでファイルを作成すると、物理的にこのファイルはhdfs://cluster/user/fileAに作成されます。この委任は、上記の構成の最初の構成パラメーターに基づいて行われました。ここでは、/userがhdfs://cluster/user/にマッピングされました。
Op2:パスhdfs://cluster/data/datafileでファイルを作成すると、このファイルはo3fs://bucket1.volume1.omhost/data/datafileに作成されます。この委任は、上記の構成の2番目の構成パラメーターに基づいて行われました。ここでは、/dataがo3fs://bucket1.volume1.omhost/data/にマッピングされました。
Op3:パスhdfs://cluster/backup/data.zipでファイルを作成すると、物理的にこのファイルはs3a://bucket1/backup/data.zipに作成されます。この委任は、上記の構成の3番目の構成パラメーターに基づいて行われました。ここでは、/backupがs3a://bucket1/backup/にマッピングされました。
例2
ユーザーが既存のクラスタ (s3a://bucketA/) のデータを、他のhdfsクラスタ(hdfs://cluster) およびオブジェクトストアクラスタ(o3fs://bucket1.volume1.omhost/, s3a://bucketA/) にマウントしたい場合、次の構成例は、マウントリンクを追加する方法を示しています。
<property> <name>fs.viewfs.mounttable.bucketA.link./user</name> <value>hdfs://cluster/user</value> </property> <property> <name>fs.viewfs.mounttable.bucketA.link./data</name> <value>o3fs://bucket1.volume1.omhost/data</value> </property> <property> <name>fs.viewfs.mounttable.bucketA.link./salesDB</name> <value>s3a://bucketA/salesDB/</value> </property>
マウントリンクに基づいて、これらの操作がどこに委任されるかを理解するために、次の操作を検討しましょう。
Op1:パスs3a://bucketA/user/fileAでファイルを作成すると、このファイルは物理的にhdfs://cluster/user/fileAに作成されます。この委任は、上記の構成の最初の構成パラメーターに基づいて行われました。ここでは、/userがhdfs://cluster/userにマッピングされました。
Op2:パスs3a://bucketA/data/datafileでファイルを作成すると、このファイルはo3fs://bucket1.volume1.omhost/data/datafileに作成されます。この委任は、上記の構成の2番目の構成パラメーターに基づいて行われました。ここでは、/dataがo3fs://bucket1.volume1.omhost/data/にマッピングされました。
Op3:パスs3a://bucketA/salesDB/dbfileでファイルを作成すると、物理的にこのファイルはs3a://bucketA/salesDB/dbfileに作成されます。この委任は、上記の構成の3番目の構成パラメーターに基づいて行われました。ここでは、/salesDBがs3a://bucket1/salesDBにマッピングされました。
注: 上記の例では、作成操作のみを使用しましたが、同じメカニズムが他のファイルシステムAPIにも適用されます。
次の図は、ViewFileSystemと比較して、ViewFileSystemOverloadSchemeでさまざまなスキームをどのように使用できるかを示しています。
注: ViewFsOverloadSchemeでは、デフォルトでは、マウントリンクはシンボリックリンクとして表現されません。パーミッションビットとisDirectoryの値は、ターゲットディレクトリ/ファイルから伝播されます。
中央マウントテーブル構成を有効にするには、core-site.xmlでfs.viewfs.mounttable.pathを構成する必要があります。値は、mount-table.<versionNumber>.xmlファイルがコピーされたHadoop互換ファイルシステムのディレクトリ/ファイルパスです。ここで、versionNumberは整数であり、バージョン番号を増やし、同じディレクトリに新しいファイルをアップロードする必要があります。
ViewFileSystemOverloadSchemeは、常に最大のバージョン番号mount-table.<versionNumber>.xmlをロードします。同じ名前でファイルを置き換えないでください。新しいクライアントによって新しいファイルが選択されるように、常にバージョン番号をインクリメントしてください。ファイルを置き換えることを推奨しない理由は、一部のクライアントが古いマウントテーブルファイルへの接続を既に開いている場合があり、構成ファイルのロード中にファイルを置き換えると、それらが失敗する可能性があるためです。
<property> <name>fs.viewfs.mounttable.path</name> <value>hdfs://cluster/config/mount-table-dir</value> </property>
マウントテーブルファイルを更新しないことが確実な場合は、次のようにファイルパスを直接構成することもできます。ファイルパスを構成する場合、最大バージョン番号のロードはチェックされません。構成されたファイルはすべてロードされます。ただし、ファイル名の形式は同じである必要があります。
<property> <name>fs.viewfs.mounttable.path</name> <value>hdfs://cluster/config/mount-table-dir/mount-table.<versionNumber>.xml</value> </property>
注: 上記の有効なパスを構成する場合は、core-site.xmlでマウントリンクを構成しないことをお勧めします。それ以外の場合、両方のマウントリンクが混在し、混乱した動作につながる可能性があります。
mount-table.<versionNumber>.xml をコピーする場合、クラスターのサイズによっては大きなレプリケーションファクターを検討する必要があるかもしれません。これにより、アプリケーション (MR/YARN/HBASE など) が mount-table.<versionNumber>.xml を読み込む際に HDFS のローカリティを利用するため、このファイルはほとんどのクライアントでローカルに利用できるようになります。
HDFS コマンドガイドを参照してください。
hdfs:///foo/bar、hdfs:/foo/bar、または viewfs:/foo/bar のように、パスのオーソリティ (クラスター名またはホスト名) が指定されていないパスにアクセスすることは非常に一般的です。これは特に、同じコードが異なる名前または HDFS Namenode を持つ複数のクラスターで実行されることが想定される場合に当てはまります。
ViewFileSystemOverloadScheme が使用されている場合 (上記を参照)、(a) アクセスされるパスのスキームが fs.defaultFS として指定されたパスのスキームと異なり、(b) パスにオーソリティが指定されていない場合、パスへのアクセスは Empty Mount table in config for viewfs://default/ のようなエラーが発生する可能性があります。たとえば、次の構成が使用されている場合に、viewfs:/foo/bar や viewfs:///foo/bar のようなパスにアクセスすると、このようなエラーが発生します。
<property> <name>fs.hdfs.impl</name> <value>org.apache.hadoop.fs.viewfs.ViewFileSystemOverloadScheme</value> </property> <property> <name>fs.defaultFS</name> <value>hdfs://cluster/</value> </property>
上記の問題を回避するには、設定 fs.viewfs.mounttable.default.name.key をクラスターの名前に設定する必要があります。つまり、core-site.xml に以下を追加する必要があります。
<property> <name>fs.viewfs.mounttable.default.name.key</name> <value>cluster</value> </property>
この構成の文字列 cluster は、fs.defaultFS の値のオーソリティ名と一致する必要があります。さらに、構成には上記の例のようにマウントテーブルが正しく構成されている必要があります。つまり、構成 fs.viewfs.mounttable.*cluster*.link.<mountLinkPath> を設定する必要があります (これらの構成では同じ文字列 cluster が使用されることに注意してください)。
ユーザーが信頼されたネットワーク内に HTTP サーバーを持っており、認証メカニズムを必要としない場合は、mount-table.xml ファイルをそのサーバーに配置し、XInclude XML タグで mount-table.xml ファイルを構成することもできます。
<configuration xmlns:xi="http://www.w3.org/2001/XInclude"> <xi:include href="http://myserver/mountTable/mountTable.xml" /> </configuration>
Apache Hadoop の構成には、XInclude から HTTP URL を読み込み、構成にロードする機能があります。このオプションを選択する場合は、core-site.xml または fs.viewfs.mounttable.path にマウントテーブルの構成項目を設定しないでください。Hadoop の構成 XInclude は、URL を開くときに SPNego 認証を使用しないことに注意してください。したがって、mount-table.xml を配置した HTTP サーバーで認証が必要な場合は、これは機能しません。