関連項目
hadoop-azureモジュールは、Azure Blob Storageとの統合をサポートします。 hadoop-azure.jarという名前のビルド済みjarファイルは、必要な追加のアーティファクト、特にJava用Azure Storage SDKへの推移的な依存関係も宣言します。
Apache Hadoopのデフォルトのクラスパスに含めるには、hadoop-env.shのHADOOP_OPTIONAL_TOOLSに'hadoop-azureがリストされていることを確認してください。 例
export HADOOP_OPTIONAL_TOOLS="hadoop-azure,hadoop-azure-datalake"
FileSystemインターフェースを実装することにより、階層型ファイルシステムビューを表示します。wasbスキームを使用してURLを使用してファイルシステムパスを参照します。wasbsスキームを使用してURLでファイルシステムパスを参照することもできます。Azure Blob Storageデータモデルは、3つのコア概念を提供します
Azure Blob Storageを使用するには、資格情報を設定する必要があります。 通常、これはcore-site.xmlで設定されます。 設定プロパティ名はfs.azure.account.key.<アカウント名>.blob.core.windows.netの形式で、値はアクセスキーです。 アクセスキーは、ストレージアカウントへのアクセスを保護する秘密鍵です。 アクセスキー（またはcore-site.xmlファイル）を信頼できないパーティと共有しないでください。
例えば
<property> <name>fs.azure.account.key.youraccount.blob.core.windows.net</name> <value>YOUR ACCESS KEY</value> </property>
多くのHadoopクラスタでは、core-site.xmlファイルは誰でも読み取ることができます。 アクセスキーを資格情報プロバイダー内で保護することもできます。 これにより、ファイルのアクセス許可による保護に加えて、暗号化されたファイル形式が提供されます。
これらの資格情報を覗き見から保護するために、資格情報プロバイダーフレームワークを使用して資格情報を安全に保存し、設定を通じてアクセスすることをお勧めします。 以下では、WASB FileSystemでのAzure資格情報について説明します。
資格情報プロバイダーAPIの詳細については、資格情報プロバイダーAPIを参照してください。
% hadoop credential create fs.azure.account.key.youraccount.blob.core.windows.net -value 123
-provider localjceks://file/home/lmccay/wasb.jceks
<property> <name>hadoop.security.credential.provider.path</name> <value>localjceks://file/home/lmccay/wasb.jceks</value> <description>Path to interrogate for protected credentials.</description> </property>
% hadoop distcp
[-D hadoop.security.credential.provider.path=localjceks://file/home/lmccay/wasb.jceks]
hdfs://hostname:9001/user/lmccay/007020615 wasb://yourcontainer@youraccount.blob.core.windows.net/testDir/
注: オプションで、汎用core-site.xmlにジョブ固有の設定を追加する代わりに、プロバイダーパスパスプロパティをdistcpコマンドラインに追加できます。 上記の角かっこは、この機能を示しています。
資格情報プロバイダーフレームワークを使用して資格情報を保護することに加えて、暗号化された形式で設定することもできます。 追加の設定プロパティは、キーを復号化するためにHadoopプロセスによって呼び出される外部プログラムを指定します。 暗号化されたキー値は、コマンドライン引数としてこの外部プログラムに渡されます。
<property> <name>fs.azure.account.keyprovider.youraccount</name> <value>org.apache.hadoop.fs.azure.ShellDecryptionKeyProvider</value> </property> <property> <name>fs.azure.account.key.youraccount.blob.core.windows.net</name> <value>YOUR ENCRYPTED ACCESS KEY</value> </property> <property> <name>fs.azure.shellkeyprovider.script</name> <value>PATH TO DECRYPTION PROGRAM</value> </property>
ブロックBLOBはデフォルトのBLOBの種類であり、ほとんどのビッグデータユースケースに適しています。 ただし、ブロックBLOBには、BLOBあたり50,000ブロックの厳格な制限があります。 制限に達するのを防ぐために、WASBはデフォルトでは、すべてのhflush()またはhsync()後に新しいブロックをサービスにアップロードしません。
ほとんどの場合、4Mbのブロックで複数のwrite()呼び出しからのデータを組み合わせることは、優れた最適化です。 しかし、他の場合、HBaseログファイルのように、hflush()またはhsync()への呼び出しごとに、データをサービスにアップロードする必要があります。
圧縮を伴うブロックBLOBは、すべてのhflush()/hsync()後にデータをクラウドサービスにアップロードします。 50000ブロックの制限を軽減するために、BLOB内のブロック数が32,000を超える場合、hflush()/hsync()は1回圧縮プロセスを実行します。
ブロック圧縮は、一連の小さなブロックを1つの大きなブロックで検索および置換します。 つまり、ブロックの圧縮には、小さなブロックをクライアントに読み戻し、1つの大きなブロックとして再び書き込むという関連コストがかかります.
作成するファイルでブロック圧縮が有効になっているブロックBLOBにするには、クライアントは設定変数fs.azure.block.blob.with.compaction.dirをコンマ区切りのフォルダー名リストに設定する必要があります。
例えば
<property> <name>fs.azure.block.blob.with.compaction.dir</name> <value>/hbase/WALs,/data/myblobfiles</value> </property>
Hadoop用Azure Blob Storageインターフェースは、ブロックBLOBとページBLOBの2種類のBLOBをサポートしています。 ブロックBLOBはデフォルトのBLOBの種類であり、Hive、Pig、分析MapReduceジョブなどの入力データのようなほとんどのビッグデータユースケースに適しています。 hadoop-azureでのページBLOB処理は、HBaseログファイルをサポートするために導入されました。 ページBLOBは何度でも書き込むことができますが、ブロックBLOBはブロックがなくなるまで50,000回までしか追加できず、書き込みは失敗します。 これはHBaseログでは機能しないため、この制限を克服するためにページBLOBのサポートが導入されました。
ページBLOBのサイズは最大1TBで、ブロックBLOBの最大サイズ200GBよりも大きくなります。 ほとんどの使用法ではブロックBLOBに固執する必要があり、ページBLOBはHBase書き込み先行ログのコンテキストでのみテストされます。
作成するファイルがページBLOBになるようにするには、設定変数fs.azure.page.blob.dirをコンマ区切りのフォルダー名リストに設定する必要があります。
例えば
<property> <name>fs.azure.page.blob.dir</name> <value>/hbase/WALs,/hbase/oldWALs,/data/mypageblobfiles</value> </property>
これを単に/に設定して、すべてのファイルをページBLOBにすることができます。
設定オプションfs.azure.page.blob.sizeは、ページBLOBのデフォルトの初期サイズです。 128MB以上、1TB以下で、バイト数の整数で指定する必要があります。
設定オプションfs.azure.page.blob.extension.sizeは、ページBLOBの拡張サイズです。 これは、ページBLOBがいっぱいになり始めた場合に拡張する量を定義します。 128MB以上で、バイト数の整数で指定する必要があります。
WASBは、ユーザーエージェントヘッダーをAzureバックエンドに渡します。 デフォルト値には、WASBバージョン、Javaランタイムバージョン、Azureクライアントライブラリバージョン、および設定オプションfs.azure.user.agent.prefixの値が含まれています。 カスタマイズされたユーザーエージェントヘッダーを使用すると、Azureサービスによるトラブルシューティングと分析が向上します。
<property>
<name>fs.azure.user.agent.prefix</name>
<value>Identifier</value>
</property>
Azureストレージは、フォルダーの正式なサポートなしに、ファイルをフラットなキー/値ストアとして格納します。 hadoop-azureファイルシステムレイヤーは、Azureストレージの上にフォルダーをシミュレートします。 デフォルトでは、hadoop-azureファイルシステムレイヤーでのフォルダーの名前変更はアトミックではありません。 つまり、フォルダーの名前変更中に障害が発生した場合、たとえば、一部のフォルダーが元のディレクトリに残され、一部が新しいディレクトリに残される可能性があります。
HBaseは、アトミックフォルダーの名前変更に依存しています。 したがって、fs.azure.atomic.rename.dirと呼ばれる構成設定が導入されました。これにより、フォルダーの名前変更をアトミックにするために特別な処理を受けるディレクトリのコンマ区切りリストを指定できます。 この設定のデフォルト値は/hbaseです。 失敗したフォルダーの名前変更を完了するために、やり直し処理が適用されます。 ファイル<folderName>-renamePending.jsonが一時的に表示される場合があります。これは、名前変更操作の意図の記録であり、障害が発生した場合にやり直しを可能にするためです。
例えば
<property> <name>fs.azure.atomic.rename.dir</name> <value>/hbase,/data</value> </property>
core-site.xmlで資格情報が構成された後、Hadoopコンポーネントは、次の形式のURLを使用して、そのAzure Blob Storageアカウント内のファイルを参照できます。
wasb[s]://<containername>@<accountname>.blob.core.windows.net/<path>
スキームwasbとwasbsは、Azure Blob Storageによってサポートされるファイルシステム上のURLを識別します。 wasbは、Azure Blob Storage APIとのすべてのインタラクションに暗号化されていないHTTPアクセスを使用します。 wasbsは、SSLで暗号化されたHTTPSアクセスを使用します。
たとえば、次のFileSystem Shellコマンドは、youraccountという名前のストレージアカウントとyourcontainerという名前のコンテナーへのアクセスを示しています。
% hadoop fs -mkdir wasb://yourcontainer@youraccount.blob.core.windows.net/testDir % hadoop fs -put testFile wasb://yourcontainer@youraccount.blob.core.windows.net/testDir/testFile % hadoop fs -cat wasbs://yourcontainer@youraccount.blob.core.windows.net/testDir/testFile test file content
fs.defaultFSを構成して、wasbまたはwasbs URLを使用することもできます。 これにより、/testDir/testFileなどのすべてのベアパスがそのファイルシステムに自動的に解決されます。
Hadoop用のAzure Blob Storageインターフェースは、設定fs.azure.enable.append.supportをtrueに設定することにより、単一ライターのAppend APIをオプションでサポートします。
例
<property> <name>fs.azure.enable.append.support</name> <value>true</value> </property>
Azure Blob StorageインターフェースのAppendサポートは、HDFSセマンティクスとは異なることに注意する必要があります。 Appendサポートは、内部で単一ライターを強制するのではなく、アプリケーションがこのセマンティクスを保証することを要求します。 特定のファイルパスに対してシングルスレッド処理を確保するか、独自の外部ロックメカニズムに依存するかは、アプリケーションの責任となります。 そうしないと、予期しない動作が発生します。
多数のファイルとサブディレクトリを含むディレクトリでのBLOB操作の名前変更と削除は、現在、これらの操作が一度に1つのBLOBに対して順番に実行されるため、非常に低速です。 これらのファイルとサブフォルダーは、並列に削除または名前変更できます。 次の設定を使用して、スレッドを有効にして並列処理を実行できます。
削除操作で10スレッドを有効にします。 スレッドを無効にするには、設定値を0または1に設定します。 デフォルトの動作では、スレッドは無効になっています。
<property> <name>fs.azure.delete.threads</name> <value>10</value> </property>
名前変更操作で20スレッドを有効にします。 スレッドを無効にするには、設定値を0または1に設定します。 デフォルトの動作では、スレッドは無効になっています。
<property> <name>fs.azure.rename.threads</name> <value>20</value> </property>
WASBは、Azureストレージと通信するために必要なストレージアクセスキーが、WASBを使用するプロセスと同じアドレス空間に存在する必要がないセキュアモードで動作できます。 このモードでは、AzureストレージとのすべてのインタラクションはSAS URIを使用して実行されます。 セキュアモードには2つのサブモードがあります。1つは、リモートプロセスからSASキーが生成されるリモートSASキーモード、もう1つは、WASB内でSASキーが生成されるローカルモードです。 デフォルトでは、SASキーモードはリモートモードで実行されることが想定されていますが、テスト目的でローカルモードを有効にして、WASBと同じプロセスでSASキーを生成できます。
セキュアモードを有効にするには、次のプロパティをtrueに設定する必要があります。
<property> <name>fs.azure.secure.mode</name> <value>true</value> </property>
ローカルでSASキー生成を有効にするには、次のプロパティをtrueに設定する必要があります。
<property> <name>fs.azure.local.sas.key.mode</name> <value>true</value> </property>
リモートSASキー生成モードを使用するには、コンマ区切りの外部RESTサービスが必要なSASキーを提供することが期待されます。 次のプロパティを使用して、リモートSASキー生成に使用するエンドポイントを提供できます。
<property>
<name>fs.azure.cred.service.urls</name>
<value>{URL}</value>
</property>
リモートサービスは、コンテナーと相対BLOB sasキーを生成するための2つのRESTコール{URL}/GET_CONTAINER_SASと{URL}/GET_RELATIVE_BLOB_SASのサポートを提供することが期待されています。 リクエスト例
{URL}/GET_CONTAINER_SAS?storage_account=<account_name>&container=<container>&sas_expiry=<expiry period>&delegation_token=<delegation token> {URL}/GET_CONTAINER_SAS?storage_account=<account_name>&container=<container>&relative_path=<relative path>&sas_expiry=<expiry period>&delegation_token=<delegation token>
サービスは、JSON形式でレスポンスを返すことが期待されています。
{
"responseCode" : 0 or non-zero <int>,
"responseMessage" : relavant message on failure <String>,
"sasKey" : Requested SAS Key <String>
}
次の構成を使用して、WASBで認可サポートを有効にできます。
<property> <name>fs.azure.authorization</name> <value>true</value> </property>
認可の現在の実装は、認可を強制できる外部サービスの存在に依存しています。 サービスは、次の設定によって提供されるコンマ区切りのURLで実行されていることが期待されます。
<property>
<name>fs.azure.authorization.remote.service.urls</name>
<value>{URL}</value>
</property>
リモートサービスは、次のRESTコールのサポートを提供することが期待されています。 {URL}/CHECK_AUTHORIZATION リクエスト例： {URL}/CHECK_AUTHORIZATION?wasb_absolute_path=<absolute_path>&operation_type=<operation type>&delegation_token=<delegation token>
サービスは、JSON形式でレスポンスを返すことが期待されています。
{
"responseCode" : 0 or non-zero <int>,
"responseMessage" : relevant message on failure <String>,
"authorizationResult" : true/false <boolean>
}
次の構成を使用して、WASBで委任トークンサポートを有効にできます。
<property> <name>fs.azure.enable.kerberos.support</name> <value>true</value> </property>
委任トークン実装の現在の実装は、委任トークンを生成および管理できる外部サービスインスタンスの存在に依存しています。 サービスは、次の設定によって提供されるコンマ区切りのURLで実行されていることが期待されます。
<property>
<name>fs.azure.delegation.token.service.urls</name>
<value>{URL}</value>
</property>
リモートサービスは、次のRESTコールのサポートを提供することが期待されています。 {URL}?op=GETDELEGATIONTOKEN、{URL}?op=RENEWDELEGATIONTOKEN、および{URL}?op=CANCELDELEGATIONTOKEN リクエスト例： {URL}?op=GETDELEGATIONTOKEN&renewer=<renewer> {URL}?op=RENEWDELEGATIONTOKEN&token=<delegation token> {URL}?op=CANCELDELEGATIONTOKEN&token=<delegation token>
サービスは、GETDELEGATIONTOKENリクエストに対してJSON形式でレスポンスを返すことが期待されています。
{
"Token" : {
"urlString": URL string of delegation token.
}
}
認可が有効になっている場合、次の構成にリストされているユーザーのみが、WASBのファイル/フォルダーの所有ユーザーを変更できます。 構成値は、chownの実行を許可されているユーザー名のコンマ区切りリストを取ります。
<property> <name>fs.azure.chown.allowed.userlist</name> <value>user1,user2</value> </property>
認可が有効になっている場合、所有者と次の構成にリストされているユーザーのみが、WASBのファイル/フォルダーのアクセス許可を変更できます。 構成値は、chmodの実行を許可されているユーザー名のコンマ区切りリストを取ります。
<property> <name>fs.azure.daemon.userlist</name> <value>user1,user2</value> </property> <property> <name>fs.azure.chmod.allowed.userlist</name> <value>userA,userB</value> </property>
SASキーと認可レスポンスの両方のキャッシュは、次の設定を使用して有効にできます。キャッシュ設定は、fs.azure.authorizationが有効になっている場合にのみ適用されます。 キャッシュは、ファイルシステムオブジェクトレベルで維持されます。
<property>
<name>fs.azure.authorization.caching.enable</name>
<value>true</value>
</property>
キャッシュが保持できるエントリの最大数は、次の設定を使用してカスタマイズできます。
<property>
<name>fs.azure.authorization.caching.maxentries</name>
<value>512</value>
</property>
認可キャッシュエントリの有効期限は、次の設定を使用して制御できます。値をゼロに設定すると、認可キャッシュが無効になります。 キーが指定されていない場合、デフォルトの有効期限5mが有効になります。
<property>
<name>fs.azure.authorization.cacheentry.expiry.period</name>
<value>5m</value>
</property>
SASKeyキャッシュエントリの有効期限は、次の設定を使用して制御できます。 値をゼロに設定すると、SASKeyキャッシュが無効になります。 キーが指定されていない場合、sas-keyリクエストで指定されたデフォルトの有効期限が有効になります。
<property>
<name>fs.azure.saskey.cacheentry.expiry.period</name>
<value>90d</value>
</property>
コンテナ内のすべてのBLOBへのアクセスにコンテナsaskeyを使用します。 この設定が有効になっている場合、BLOB固有のsaskeyは使用されません。 この設定は、BLOB固有のsaskeyと比較してパフォーマンスが向上します。
<property>
<name>fs.azure.saskey.usecontainersaskeyforallaccess</name>
<value>true</value>
</property>
fs.azure.block.blob.buffered.pread.disable：デフォルトでは、位置読み取りAPIは、入力ストリームでシークと読み取りを実行します。 この読み取りにより、BlockBlobInputStreamのバッファキャッシュがいっぱいになります。 この構成がtrueの場合、バッファの使用をスキップし、BLOBからの読み取りのためにロックフリーコールを実行します。 この最適化は、共有InputStreamインスタンスに対するHBaseのような短いランダム読み取りに非常に役立ちます。 注：これは、クラスターレベルで設定できる設定ではありません。 FutureDataInputStreamBuilderのオプションとして使用できます。 FileSystem＃openFile（Path path）を参照してください。