Azure WASB クライアントのテスト

このモジュールには、Azure Storage サービスに接続せずに分離して実行できる単体テストと、コンテナーと対話するために動作中の接続を必要とする統合テストの両方が含まれています。単体テストスイートは、命名規則Test*.javaに従います。統合テストは、命名規則ITest*.javaに従います。

hadoop-azureモジュールに影響を与えるパッチを提出するためのポリシー。

Apache Jenkins インフラストラクチャは、資格情報を安全に保つ必要があるため、クラウド統合テストを実行しません。

パッチの提出者は、すべての統合テストを実行し、使用した Azure リージョンを宣言する必要があります。

これは重要です:この宣言を含まないパッチは無視されます

このポリシーは、コード変更の完全な回帰テストを保証する唯一のメカニズムであることが証明されています。なぜリージョンの宣言が必要なのか?2つの理由があります

  1. 特定のエンドポイントに対してのみ表面化する回帰を特定するのに役立ちます。
  2. 提出者にテストについてより正直になることを強制します。「はい、これをテストしました」と嘘をつくのは簡単です。「はい、これを Azure US-west でテストしました」と言うのはより具体的な嘘であり、より難しくなります。そして、もしあなたが捕まった場合:あなたはプロジェクトへのすべての信頼を失います。

Azure インフラストラクチャ内の VM からテストする必要はありません。必要なのは資格情報だけです。

テストを実行するのは難しくも高価でもありません。もし実行できない場合は、パッチが機能するという保証はありません。レビュー担当者はやるべきことがたくさんあり、これらのテストを行う時間はありません。特に、すべての失敗が単に遅い反復開発につながるためです。

お願いします:テストを実行してください。そうしない場合は、パッチをお断りすることをお詫びしますが、そうせざるを得ません。

テストが断続的に失敗した場合はどうなりますか?

特に並列実行では、テストの一部は断続的に失敗します。これが発生した場合は、テストが成功するかどうかを確認するために、単独でテストを実行してみてください。

それでも失敗する場合は、この事実を宣言に含めてください。いくつかのテストが断続的に信頼できないことを私たちは知っています。

テストがタイムアウトしたり、ネットワーク接続で失敗したりする場合はどうなりますか?

テストは、さまざまなタイムアウトに対応するように構成できるように設計されています。問題が発生していて、この構成が機能していない場合は、構成メカニズムが完了していないことを示す兆候です。もしそれが本番コードで発生している場合は、長距離接続で表面化する可能性のある問題の兆候である可能性があります。これらの問題を特定して修正するためにご協力ください。特に、修正が機能することを検証するのに最適なのはあなたであるためです。

テストのセットアップ

hadoop-azureモジュールのテスト

hadoop-azureモジュールには、完全な単体テストスイートが含まれています。多くのテストは、mvn testを実行することで、追加の構成なしで実行できます。これには、Azure Storage のインメモリエミュレーションであるモックされたストレージに対するテストが含まれます。

統合テストは、Azure ストレージサービスに対して直接テストするように設計されており、実行するにはアカウントと資格情報が必要です。

これは、src/test/resources/azure-auth-keys.xmlファイルを作成し、ストレージアカウントの名前とそのアクセスキーを設定することで行われます。

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration>
  <property>
    <name>fs.azure.wasb.account.name</name>
    <value>{ACCOUNTNAME}.blob.core.windows.net</value>
  </property>
  <property>
    <name>fs.azure.account.key.{ACCOUNTNAME}.blob.core.windows.net</name>
    <value>{ACCOUNT ACCESS KEY}</value>
  </property>
</configuration>

コントラクトテストを実行するには、src/test/resources/azure-auth-keys.xmlで WASB ファイルシステムの URI とアカウントアクセスキーを設定します。例

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration>
  <property>
    <name>fs.contract.test.fs.wasb</name>
    <value>wasb://{CONTAINERNAME}@{ACCOUNTNAME}.blob.core.windows.net</value>
    <description>The name of the azure file system for testing.</description>
  </property>
  <property>
    <name>fs.azure.account.key.{ACCOUNTNAME}.blob.core.windows.net</name>
    <value>{ACCOUNT ACCESS KEY}</value>
  </property>
</configuration>

全体として、mvn testを使用してすべてのテストを実行する場合、サンプルazure-auth-keys.xmlは次のようになります。

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration>
  <property>
    <name>fs.azure.wasb.account.name</name>
    <value>{ACCOUNTNAME}.blob.core.windows.net</value>
  </property>
  <property>
    <name>fs.azure.account.key.{ACCOUNTNAME}.blob.core.windows.net</name>
    <value>{ACCOUNT ACCESS KEY}</value>
  </property>
  <property>
    <name>fs.contract.test.fs.wasb</name>
    <value>wasb://{CONTAINERNAME}@{ACCOUNTNAME}.blob.core.windows.net</value>
  </property>
</configuration>

azure-auth-keys.xmlをリビジョン管理に追加しないでください。Azure Storage アカウントのキーは機密情報であり、共有してはなりません。

テストの実行

構成が完了したら、Maven を介してテスト実行を実行します。

mvn -T 1C clean verify

コマンドラインでparallel-tests=wasb|abfs|bothプロパティを渡すことで、複数のテストスイートを並行して実行することも可能です。テストはネットワーク I/O でブロックされる時間がほとんどであるため、並行して実行すると、完全なテスト実行がより速く完了する傾向があります。

mvn -T 1C -Dparallel-tests=both clean verify
mvn -T 1C -Dparallel-tests=wasb clean verify
mvn -T 1C -Dparallel-tests=abfs clean verify

-Dparallel-tests=wasbは、azure ディレクトリから WASB 関連の統合テストを実行します
-Dparallel-tests=abfsは、azurebfs ディレクトリから ABFS 関連の統合テストを実行します
-Dparallel-tests=bothは、azure と azurebfs の両方のディレクトリからすべての統合テストを実行します

一部のテストはストレージコンテナへの排他的アクセスで実行する必要があるため、parallel-testsプロパティを使用しても、並列テストの後、別の Maven 実行ステップでいくつかのテストスイートがシリアルに実行されます。

デフォルトでは、parallel-testsは 4 つのテストスイートを同時に実行します。これは、testsThreadCountプロパティを渡すことで調整できます。

mvn -T 1C -Dparallel-tests -DtestsThreadCount=8 clean verify
mvn -T 1C clean test

mvn -T 1C -Dparallel-tests clean test

mvn -T 1C -Dparallel-tests -DtestsThreadCount=8 clean test

特定の名前付きのテストのサブセットのみを実行するには、単体テストの場合はtestプロパティを、統合テストの場合はit.testプロパティを渡します。

mvn -T 1C clean test -Dtest=TestRollingWindowAverage

mvn -T 1C clean verify -Dscale -Dit.test=ITestFileSystemOperationExceptionMessage -Dtest=none

mvn -T 1C clean verify -Dtest=none -Dit.test=ITest*

注意

  1. テストの特定のサブセットを実行する場合、testit.testで渡されたパターンは、別のシリアルフェーズで分離して実行する必要があるテストの構成をオーバーライドします(上記参照)。これにより、予測不可能な結果が発生する可能性があるため、parallel-teststestまたはit.testと組み合わせて渡すことは避けることをお勧めします。並行して安全に実行できるテストのみを指定していることがわかっている場合は、機能します。上記に示すITest*のような幅広いパターンでは、予測不可能なテストの失敗を引き起こす可能性があります。

  2. コマンドラインシェルは、テストパターンの「*」および場合によっては「#」記号を展開しようとする場合があります。このような状況では、「\」プレフィックスを使用して文字をエスケープします。例

      mvn -T 1C clean verify -Dtest=none -Dit.test=ITest\*
    

結果の表示

統合テストの結果とログは、target/failsafe-reports/に保存されます。HTMLレポートは、サイト生成中、またはsurefire-reportプラグインで生成できます

# for the unit tests
mvn -T 1C surefire-report:report-only

# for the integration tests
mvn -T 1C surefire-report:failsafe-report-only

# all reports for this module
mvn -T 1C site:site

スケールテスト

ファイルシステムクライアントのスケーラビリティとパフォーマンスを大規模に測定するように設計された一連のテストである、スケールテストがあります。テストには、ディレクトリツリーの作成とトラバース、大きなファイルのアップロード、名前の変更、削除、ファイル内でのシーク、ランダムIOの実行などが含まれます。これにより、ベンチマークの基礎部分になります。

その性質上、それらは遅いです。また、実行時間はテストを実行しているコンピューターと Azure エンドポイント間の帯域幅によって制限されることが多いため、並列実行ではこれらのテストの速度は向上しません。

スケールテストの有効化

テストは、maven ビルドでscaleプロパティが設定されている場合に有効になります。これは、並列テストプロファイルが使用されているかどうかに関係なく実行できます。

mvn -T 1C verify -Dscale

mvn -T 1C verify -Dparallel-tests -Dscale -DtestsThreadCount=8

最も帯域幅を消費するテスト(データをアップロードするテスト)は常に順番に実行されます。HTTPS のセットアップコストまたはサーバー側のアクションが原因で遅いテストは、並列化されたテストのセットに含まれます。

スケールテストのチューニングオプション

一部のテストは、Mavenビルドまたはテストの実行に使用される設定ファイルから調整できます。

mvn -T 1C verify -Dparallel-tests -Dscale -DtestsThreadCount=8 -Dfs.azure.scale.test.huge.filesize=128M

アルゴリズムは次のとおりです。

  1. 値が設定されていない場合は、デフォルト値を使用して、設定ファイルから値が照会されます。
  2. 値は、Mavenによって渡されるJVMシステムプロパティから照会されます。
  3. システムプロパティがnull、空の文字列であるか、値がunsetの場合、構成値が使用されます。unsetオプションは、Mavenプロパティの伝播の癖を回避するために使用されます。

この方法で設定できるプロパティはごくわずかですが、今後追加される予定です。

プロパティ 意味
fs.azure.scale.test.huge.filesize 巨大なファイルアップロードのサイズ
fs.azure.scale.test.huge.huge.partitionsize 巨大なファイルアップロードのパーティションのサイズ

ファイルとパーティションのサイズは、目的のサイズに応じてk/m/g/t/pのサフィックスが付いた数値です。たとえば、128M、128m、2G、2G、4T、または1Pなどです。

スケールテストの設定オプション

一部のスケールテストでは、複数の操作(多数のディレクトリの作成など)を実行します。

実行する正確な操作数は、オプションscale.test.operation.countで設定可能です。

<property>
  <name>scale.test.operation.count</name>
  <value>10</value>
</property>

大きな値を指定すると、より多くの負荷が発生し、ローカルでテストする場合やバッチ実行する場合は推奨されます。

特にオブジェクトストアが遠く離れている場合は、値を小さくするとテストの実行が速くなります。

ディレクトリで動作する操作には、別のオプションがあります。これにより、再帰的なディレクトリを作成するテストの幅と深さが制御されます。値を大きくすると、ディレクトリが指数関数的に増加し、結果としてパフォーマンスに影響します。

<property>
  <name>scale.test.directory.count</name>
  <value>2</value>
</property>

AzureをターゲットとするDistCpテストでは、設定可能なファイルサイズがサポートされています。デフォルトは10MBですが、設定値はテストの実行を高速化するために小さく調整できるようにKB単位で表されます。

<property>
  <name>scale.test.distcp.file.size.kb</name>
  <value>10240</value>
</property>

Azure固有のスケールテストプロパティは次のとおりです。

fs.azure.scale.test.huge.filesize:「巨大ファイルテスト」のMB単位のサイズ。

巨大ファイルテストでは、Azureストレージが大きなファイルを処理する能力を検証します。プロパティfs.azure.scale.test.huge.filesizeは、使用するファイルサイズを宣言します。

<property>
  <name>fs.azure.scale.test.huge.filesize</name>
  <value>200M</value>
</property>

この規模のテストは遅くなります。ストレージエンドポイントが配置されているクラウドインフラストラクチャで実行されているホストから実行するのが最適です。

エミュレーターの使用

一部のテストは、ライブAzureストレージの高忠実度エミュレーションであるAzure Storage Emulatorに対して実行できます。エミュレーターは、高信頼性テストに十分です。エミュレーターは、ローカルマシンで実行されるWindows実行可能ファイルです。

エミュレーターを使用するには、Azure SDK 2.3をインストールしてストレージエミュレーターを起動します。次に、src/test/resources/azure-test.xmlを編集し、次のプロパティを追加します。

<property>
  <name>fs.azure.test.emulator</name>
  <value>true</value>
</property>

エミュレーターでテストを実行するときの既知の問題があります。次のエラーメッセージが表示される場合があります。

com.microsoft.windowsazure.storage.StorageException: The value for one of the HTTP headers is not in the correct format.

これを解決するには、Azure Emulatorを再起動します。v3.2以降であることを確認してください。

テストの失敗のデバッグ

デバッグレベルでのロギングは、より多くの診断出力を提供するための標準的な方法です。これを設定した後、テストを再実行します。

log4j.logger.org.apache.hadoop.fs.azure=DEBUG

新しいテストの追加

新しいテストはいつでも歓迎です。コストとテスト時間を削減する必要があることに注意してください。これは、次の方法で実現されます。

  • テストを複製しない。
  • Hadoop APIの呼び出しを効率的に使用する。
  • 大規模/低速テストを「スケール」テストグループに分離する。
  • すべてのテストを並行して実行するように設計する(可能な場合)。
  • 既存のテストに新しいプローブと述語を追加する(慎重に行う)。

重複なし:ある操作が別の場所でテストされている場合は、それを繰り返さないでください。これは、一括IOだけでなく、メタデータ操作にも当てはまります。既存のテストを完全に廃止する新しいテストケースが追加された場合、カバレッジが悪化していないことを示した上で、前のテストを削除しても問題ありません。

効率的exists()isFile()などを呼び出すのではなく、getFileStatus()を使用して結果を調べることを推奨します。

有用な情報とともに失敗する:失敗時に可能な限り多くの診断を提供します。org.apache.hadoop.fs.contract.ContractTestUtilsを使用してファイルシステムの状態に関するアサーションを行うと、ここで役立ちます。

スケールテストの分離。大量のIOを実行するテストは、クラスAbstractAzureScaleTestを拡張する必要があります。これにより、ビルドでscaleが定義されている場合にのみ実行され、ユーザーが設定可能なテストタイムアウトがサポートされます。スケールテストでは、オブジェクトの実際のサイズや操作数に関する設定可能性もサポートする必要があり、さまざまなスケールでの動作を検証できます。

並行実行用に設計。ここでの重要なニーズは、各テストスイートがファイルシステムの隔離された部分で動作することです。AbstractWasbTestBaseのサブクラスは、path()methodpath()、およびblobpath()メソッドを使用して、隔離されたパスを構築する必要があります。テストは、バケットへの排他的アクセスを想定してはなりません。

必要に応じて既存のテストを拡張。この推奨事項は、「1つのメソッドで1つのことをテストする」という通常のテストのベストプラクティスに反します。ディレクトリツリーを作成したり、大きなファイルをアップロードしたりするのは非常に遅いため、それを行う余裕はありません。実際のエンドポイントに対するすべてのテストは、テストのセットアップと破棄を共有することで時間とお金を節約できる統合テストです。

これを行うための標準的な方法は、新しいテストを作成するのではなく、既存のテストをいくつかの追加の述語で拡張することです。これを行う場合は、新しい述語が意味のある診断で失敗し、テストログから新しい問題を簡単にデバッグできるようにしてください。

新しいテストの要件

これは、新しいテストに期待されるものです。これらは、リモートサーバーでの作業の必要性に基づいた、通常のHadoop要件の拡張であり、リモートサーバーの使用には秘密の資格情報の存在が必要であり、テストが遅くなる可能性があり、テスト出力以外に何か失敗した理由を突き止めることが重要です。

既存の共有基本クラスのサブクラス

Azureテストおよび統合テスト用に拡張する必要がある基本クラスのセットがあります。

org.apache.hadoop.fs.azure.AbstractWasbTestWithTimeout

これは、junit Assertクラスをスレッド名とタイムアウトで拡張します。デフォルトのタイムアウトは、AzureTestConstants.AZURE_TEST_TIMEOUTで10分に設定されています。スレッド名は、テストのスタックトレースの分析を支援するために設定されています。jstack呼び出しを使用して、

org.apache.hadoop.fs.azure.AbstractWasbTestBase

AzureBlobStorageTestAccountを使用してモックまたはライブAzureクライアントを作成するテストの基本クラス。テストの破棄では、ストア状態のクリーンアップを試みます。

  1. このクラスでは、サブクラスがモックまたは実際のテストアカウントを作成するためにcreateTestAccount()を実装する必要があります。

  2. テストアカウントの作成に使用される構成は、createConfiguration()からのものである必要があります。これは、サブクラスで拡張して設定を調整できます。

org.apache.hadoop.fs.azure.integration.AbstractAzureScaleTest

これは、スケールテストのためにAbstractWasbTestBaseを拡張したものです。-Dscaleを使用して「スケール」プロファイルを選択した場合にのみ実行されるテストです。これらのテストのタイムアウトは30分であるため、遅いテスト実行をサポートします。

共有基本クラスを使用すると、将来のメンテナンスを削減できます。ぜひ使用してください。

安全

資格情報をログに記録しないでください。資格情報テストでは、これを避けるために、意味のあるログやアサーションメッセージを提供しないように特別に工夫されています。

時間とお金の効率

これは、テストのセットアップ/破棄が効率的であることを意味し、理想的には、既存の公開データセットを利用して、セットアップ時間とテスターコストを節約します。

参考例はITestAzureHugeFilesです。これは、テストスイートを@FixMethodOrder(MethodSorters.NAME_ASCENDING)としてマークし、各テストケースが前のテストの完了を期待するようにテストケースを順序付けます(ここでは、ファイルのアップロード、ファイルの名前変更など)。これにより、レポートで独立したテストが提供されますが、操作の順序付きシーケンスも可能になります。単一のテストケースの前提条件が満たされていない場合を検出するためにAssume.assume()が使用されていることに注意してください。したがって、テストは実際には誤報であるトレースで失敗するのではなく、スキップされます。

長距離リンクで動作

ファイルサイズと操作数をスケーラブルにするだけでなく、テストタイムアウトを適切にすることも含まれます。スケールテストでは、これを設定可能にします。AbstractAzureIntegrationTest()では10分にハードコードされています。サブクラスはgetTestTimeoutMillis()をオーバーライドすることでこれを変更できます。

同じくらい重要なこと:一部のテスターがプロキシを必要とするため、プロキシをサポートします。

診断とタイミング情報を提供

  1. ログを作成し、情報をログに記録します。
  2. ここではAbstractWasbTestBase.describe(format-string, args)を使用できます。これにより、見つけやすくなるように改行がいくつか追加されます。
  3. ContractTestUtils.NanoTimerを使用して操作の所要時間を測定し、出力をログに記録します。

意味のある失敗

ContractTestUtilsクラスには、assertPathExists(FS, path)assertPathDoesNotExists(FS, path)など、ファイルシステムの予期される状態に関するステートメントを作成するためのアサーションのセット全体が含まれています。これらは、失敗に関する意味のある診断(ディレクトリリスト、ファイルステータスなど)を提供するのに最善を尽くし、失敗を理解しやすくするのに役立ちます。

少なくとも、エラーメッセージを含めずにassertTrue()またはassertFalse()を使用しないでください

後処理

コストを削減します。

  1. テストケースが正常に完了した場合にのみクリーンアップするのではなく、テストスイートの破棄でクリーンアップする必要があります。
  2. その破棄コードは、クリーンアップする前に、ファイルシステムとその他のフィールドがnullかどうかを確認する必要があります。理由。テストのセットアップが失敗した場合でも、破棄メソッドは引き続き呼び出されます。

確実に動作

これは本当にありがたいことです。あなたもそうなるでしょう。

ヒント

資格情報を本当に安全に保つ方法

auth-keys.xmlファイルはgitおよびsubversionで無視されるようにマージされていますが、それでもソースツリー内にあり、それが漏えいするリスクは常にあります。

ソースツリーの外にキーを保持し、絶対XInclude参照を使用することで、これを回避できます。

<configuration>

  <include xmlns="http://www.w3.org/2001/XInclude"
    href="file:///users/qe/.auth-keys.xml" />

</configuration>

コンテナのクリーンアップ

Azureテストでは、プレフィックス"wasbtests-"のコンテナが作成され、テストの実行後に削除されます。テストの実行が中断された場合、これらのコンテナは削除されない可能性があります。これらのリストと削除を手動で呼び出すことができる特別なテストケース、CleanupTestContainersがあります。

mvn test -Dtest=CleanupTestContainers

これにより、コンテナが削除されます。テスト実行の出力ログには、操作の詳細と概要が記載されます。

Azure ABFSクライアントのテスト

Azure Data Lake Storage Gen 2 (ADLS Gen 2) は、Azure Blob Storage の上に構築された、ビッグデータ分析専用の機能セットです。ABFS および ABFSS スキームは ADLS Gen 2 REST API を対象としており、WASB および WASBS スキームは Azure Blob Storage REST API を対象としています。ADLS Gen 2 は、パフォーマンスとスケーラビリティが向上しています。ADLS Gen 2 は、ストレージアカウントで階層型名前空間が有効になっている場合、Hadoop 分散ファイルシステムのアクセス許可モデルと互換性のある認証と承認も提供します。さらに、ADLS Gen 2 REST API によって生成されたメタデータとデータは、Blob REST API で使用でき、その逆も可能です。

さまざまな構成の組み合わせに対するテスト実行構成とテストトリガーの生成

PR に必須となるさまざまな認証および機能の組み合わせにわたるテストを簡素化するために、スクリプト dev-support/testrun-scripts/runtests.sh を使用する必要があります。このスクリプトにさまざまなテストの組み合わせに関する関連する構成設定を更新すると、次の処理が行われます。1. 各テストの組み合わせに固有の構成を自動生成する 2. すべての組み合わせでテストを実行する 3. すべてのテストの組み合わせの実行結果をまとめる。

前提条件として、src/test/resources/azure-auth-keys.xml.template に、認証に必要なテストアカウントと認証情報の構成値を入力し、src/test/resources/azure-auth-keys.xml として名前を変更します。

新しいテストの組み合わせを追加するには: PR 検証に必要なテストの組み合わせのテンプレートは、dev-support/testrun-scripts/runtests.sh にあります。新しいものを追加する必要がある場合は、dev-support/testrun-scripts/runtests.sh 内で、すでに定義されているものと同様の組み合わせセットを追加し、1. 新しい組み合わせ名を指定する 2. テストの組み合わせに有効にする必要があるプロパティと値の配列を更新する 3. generateconfigs を呼び出します。

PR 検証を実行するには: コマンド * dev-support/testrun-scripts/runtests.sh を実行すると、定義された各組み合わせの構成が生成され、すべての組み合わせでテストが実行されます。* dev-support/testrun-scripts/runtests.sh -c {組み合わせ名} 特定の組み合わせは -c オプションで指定できます。-c オプションで組み合わせを指定した場合、それらの組み合わせのテストのみが実行されます。

テストログ: テスト実行では、テストログを保存するために dev-support/testlogs 内にフォルダーが作成されます。フォルダー名はテスト開始時のタイムスタンプになります。各組み合わせの mvn verify コマンドラインログは、このフォルダーに Test-Logs-$combination.txt というファイルとして保存されます。失敗が発生した場合、このファイルには失敗例外スタックが含まれます。テスト実行の最後に、すべての組み合わせの実行結果をまとめたものが、同じフォルダー内の Test-Results.log というファイルに保存されます。PR 検証のために実行する場合は、まとめられたテスト結果を PR のコメントセクションに貼り付ける必要があります。

IDE で使用する構成を生成するには: -a (activate) オプションを指定してコマンド dev-support/testrun-scripts/runtests.sh -a {組み合わせ名} を実行すると、特定のテストの組み合わせに関連する有効な構成が更新されます。したがって、mvn テスト実行で使用されるのと同じ構成ファイルを、構成ファイル内で手動で更新する必要なく、IDE で使用できます。

その他のコマンドラインオプション: * -a <COMBINATION_NAME> アクティブにする必要がある組み合わせ名を指定します。これは IDE で使用する構成を生成するために使用されます。* -c <COMBINATION_NAME> テスト実行の組み合わせ名を指定します。この構成が指定されている場合、指定された組み合わせのテストのみが実行されます。この構成が指定されていない場合、すべての組み合わせのテストが実行されます。* -t <THREAD_COUNT> ABFS mvn テストは並列モードで実行されます。テストはデフォルトで 8 スレッド数で実行されます。-t <THREAD_COUNT> を指定することで変更できます。

ABFS をテストするには、src/test/resources/azure-auth-keys.xml ファイルに次の構成を追加してください。ABFS テストには、ABFS の認証情報に加えて、WASB の認証情報を必要とする互換性テストが含まれていることに注意してください。

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration xmlns:xi="http://www.w3.org/2001/XInclude">
  <property>
    <name>fs.azure.abfs.account.name</name>
    <value>{ACCOUNT_NAME}.dfs.core.windows.net</value>
  </property>

  <property>
    <name>fs.azure.account.key.{ACCOUNT_NAME}.dfs.core.windows.net</name>
    <value>{ACCOUNT_ACCESS_KEY}</value>
  </property>

  <property>
    <name>fs.azure.wasb.account.name</name>
    <value>{ACCOUNT_NAME}.blob.core.windows.net</value>
  </property>

  <property>
    <name>fs.azure.account.key.{ACCOUNT_NAME}.blob.core.windows.net</name>
    <value>{ACCOUNT_ACCESS_KEY}</value>
  </property>

  <property>
    <name>fs.contract.test.fs.abfs</name>
    <value>abfs://{CONTAINER_NAME}@{ACCOUNT_NAME}.dfs.core.windows.net</value>
    <description>A file system URI to be used by the contract tests.</description>
  </property>

  <property>
    <name>fs.contract.test.fs.wasb</name>
    <value>wasb://{CONTAINER_NAME}@{ACCOUNT_NAME}.blob.core.windows.net</value>
    <description>A file system URI to be used by the contract tests.</description>
  </property>
</configuration>

OAuth および ACL のテストケースを実行するには、階層型名前空間が有効になっているストレージアカウントを使用し、次の構成設定を行う必要があります

<!--=========================== AUTHENTICATION  OPTIONS ===================-->
<!--ATTENTION:
      TO RUN ABFS & WASB COMPATIBILITY TESTS, YOU MUST SET AUTH TYPE AS SharedKey.
      OAUTH IS INTRODUCED TO ABFS ONLY.-->
<property>
  <name>fs.azure.account.auth.type.{YOUR_ABFS_ACCOUNT_NAME}</name>
  <value>{AUTH TYPE}</value>
  <description>The authorization type can be SharedKey, OAuth, Custom or SAS. The
  default is SharedKey.</description>
</property>

<!--=============================   FOR OAUTH   ===========================-->
<!--IF AUTH TYPE IS SET AS OAUTH, FOLLOW THE STEPS BELOW-->
<!--NOTICE: AAD client and tenant related properties can be obtained through Azure Portal-->

  <!--1. UNCOMMENT BELOW AND CHOOSE YOUR OAUTH PROVIDER TYPE -->

  <!--
  <property>
    <name>fs.azure.account.oauth.provider.type.{ABFS_ACCOUNT_NAME}</name>
    <value>org.apache.hadoop.fs.azurebfs.oauth2.{Token Provider Class name}</value>
    <description>The full name of token provider class name.</description>
  </property>
 -->

  <!--2. UNCOMMENT BELOW AND SET CREDENTIALS ACCORDING TO THE PROVIDER TYPE-->

  <!--2.1. If "ClientCredsTokenProvider" is set as key provider, uncomment below and
           set auth endpoint, client id and secret below-->
  <!--
   <property>
    <name>fs.azure.account.oauth2.client.endpoint.{ABFS_ACCOUNT_NAME}</name>
    <value>https://login.microsoftonline.com/{TENANTID}/oauth2/token</value>
    <description>Token end point, this can be found through Azure portal</description>
  </property>

   <property>
     <name>fs.azure.account.oauth2.client.id.{ABFS_ACCOUNT_NAME}</name>
     <value>{client id}</value>
     <description>AAD client id.</description>
   </property>

   <property>
     <name>fs.azure.account.oauth2.client.secret.{ABFS_ACCOUNT_NAME}</name>
     <value>{client secret}</value>
   </property>
 -->

  <!--2.2. If "UserPasswordTokenProvider" is set as key provider, uncomment below and
           set auth endpoint, use name and password-->
  <!--
   <property>
    <name>fs.azure.account.oauth2.client.endpoint.{ABFS_ACCOUNT_NAME}</name>
    <value>https://login.microsoftonline.com/{TENANTID}/oauth2/token</value>
    <description>Token end point, this can be found through Azure portal</description>
  </property>

   <property>
     <name>fs.azure.account.oauth2.user.name.{ABFS_ACCOUNT_NAME}</name>
     <value>{user name}</value>
   </property>

   <property>
     <name>fs.azure.account.oauth2.user.password.{ABFS_ACCOUNT_NAME}</name>
     <value>{user password}</value>
   </property>
 -->

  <!--2.3. If "MsiTokenProvider" is set as key provider, uncomment below and
           set tenantGuid and client id.-->
  <!--
   <property>
     <name>fs.azure.account.oauth2.msi.tenant.{ABFS_ACCOUNT_NAME}</name>
     <value>{tenantGuid}</value>
     <description>msi tenantGuid.</description>
   </property>

   <property>
     <name>fs.azure.account.oauth2.client.id.{ABFS_ACCOUNT_NAME}</name>
     <value>{client id}</value>
     <description>AAD client id.</description>
   </property>
  -->

  <!--2.4. If "RefreshTokenBasedTokenProvider" is set as key provider, uncomment below and
           set refresh token and client id.-->
  <!--
   <property>
     <name>fs.azure.account.oauth2.refresh.token.{ABFS_ACCOUNT_NAME}</name>
     <value>{refresh token}</value>
     <description>refresh token.</description>
   </property>

   <property>
     <name>fs.azure.account.oauth2.client.id.{ABFS_ACCOUNT_NAME}</name>
     <value>{client id}</value>
     <description>AAD client id.</description>
   </property>
  -->

  <!--
    <property>
        <name>fs.azure.identity.transformer.enable.short.name</name>
        <value>true/false</value>
        <description>
          User principal names (UPNs) have the format “{alias}@{domain}”.
          If true, only {alias} is included when a UPN would otherwise appear in the output
          of APIs like getFileStatus, getOwner, getAclStatus, etc, default is false.
        </description>
    </property>

    <property>
        <name>fs.azure.identity.transformer.domain.name</name>
        <value>domain name of the user's upn</value>
        <description>
          If the domain name is specified and “fs.azure.identity.transformer.enable.short.name”
          is true, then the {alias} part of a UPN can be specified as input to APIs like setOwner,
          setAcl, modifyAclEntries, or removeAclEntries, and it will be transformed to a UPN by appending @ and the domain specified by
          this configuration property.
        </description>
    </property>

    <property>
        <name>fs.azure.identity.transformer.service.principal.id</name>
        <value>service principal object id</value>
        <description>
          An Azure Active Directory object ID (oid) used as the replacement for names contained
          in the list specified by “fs.azure.identity.transformer.service.principal.substitution.list”.
          Notice that instead of setting oid, you can also set $superuser here.
        </description>
    </property>

    <property>
        <name>fs.azure.identity.transformer.skip.superuser.replacement</name>
        <value>true/false</value>
        <description>
          If false, “$superuser” is replaced with the current user when it appears as the owner
          or owning group of a file or directory. The default is false.
        </description>
    </property>

    <property>
        <name>fs.azure.identity.transformer.service.principal.substitution.list</name>
        <value>mapred,hdfs,yarn,hive,tez</value>
        <description>
           A comma separated list of names to be replaced with the service principal ID specified by
           “fs.azure.identity.transformer.service.principal.id”.  This substitution occurs
           when setOwner, setAcl, modifyAclEntries, or removeAclEntries are invoked with identities
           contained in the substitution list. Notice that when in non-secure cluster, asterisk symbol *
           can be used to match all user/group.
        </description>
    </property>
   -->

委任 SAS テストケースを実行するには、階層型名前空間が有効になっているストレージアカウントを使用し、次の構成設定を行う必要があります

<!--=========================== AUTHENTICATION  OPTIONS ===================-->
<!--=============================   FOR SAS   ===========================-->
<!-- To run ABFS Delegation SAS tests, you must register an app, create the
     necessary role assignments, and set the configuration discussed below:

    1) Register an app:
      a) Login to https://portal.azure.com, select your AAD directory and search for app registrations.
      b) Click "New registration".
      c) Provide a display name, such as "abfs-app".
      d) Set the account type to "Accounts in this organizational directory only ({YOUR_Tenant} only - Single tenant)".
      e) For Redirect URI select Web and enter "http://localhost".
      f) Click Register.

    2)  Create necessary role assignments:
      a) Login to https://portal.azure.com and find the Storage account with hierarchical namespace enabled
         that you plan to run the tests against.
      b) Select "Access Control (IAM)".
      c) Select Role Assignments
      d) Click Add and select "Add role assignments"
      e) For Role and enter "Storage Blob Data Owner".
      f) Under Select enter the name of the app you registered in step 1 and select it.
      g) Click Save.
      h) Repeat above steps to create a second role assignment for the app but this time for
         the "Storage Blob Delegator" role.

    3) Generate a new client secret for the application:
      a) Login to https://portal.azure.com and find the app registered in step 1.
      b) Select "Certificates and secrets".
      c) Click "New client secret".
      d) Enter a description (eg. Secret1)
      e) Set expiration period.  Expires in 1 year is good.
      f) Click Add
      g) Copy the secret and expiration to a safe location.

    4) Set the following configuration values:
-->

  <property>
    <name>fs.azure.sas.token.provider.type</name>
    <value>org.apache.hadoop.fs.azurebfs.extensions.MockDelegationSASTokenProvider</value>
    <description>The fully qualified class name of the SAS token provider implementation.</description>
  </property>

  <property>
    <name>fs.azure.test.app.service.principal.tenant.id</name>
    <value>{TID}</value>
    <description>Tenant ID for the application's service principal.</description>
  </property>

  <property>
    <name>fs.azure.test.app.service.principal.object.id</name>
    <value>{OID}</value>
    <description>Object ID for the application's service principal.</description>
  </property>

  <property>
    <name>fs.azure.test.app.id</name>
    <value>{app id}</value>
    <description>The application's ID, also known as the client id.</description>
  </property>

   <property>
     <name>fs.azure.test.app.secret</name>
     <value>{client secret}</value>
     <description>The application's secret, also known as the client secret.</description>
   </property>


CheckAccess テストケースを実行するには、RBAC がないアプリを登録し、次の構成を設定する必要があります。

<!--===========================   FOR CheckAccess =========================-->
<!-- To run ABFS CheckAccess SAS tests, you must register an app, with no role
 assignments, and set the configuration discussed below:

    1) Register a new app with no RBAC
    2) As part of the test configs you need to provide the guid for the above
created app. Please follow the below steps to fetch the guid.
      a) Get an access token with the above created app. Please refer the
 following documentation for the same. https://docs.microsoft
.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow#get-a-token
      b) Decode the token fetched with the above step. You may use https
://jwt.ms/ to decode the token
      d) The oid field in the decoded string is the guid.
    3) Set the following configurations:
-->

  <property>
    <name>fs.azure.enable.check.access</name>
    <value>true</value>
    <description>By default the check access will be on. Checkaccess can
    be turned off by changing this flag to false.</description>
  </property>
  <property>
    <name>fs.azure.account.test.oauth2.client.id</name>
    <value>{client id}</value>
    <description>The client id(app id) for the app created on step 1
    </description>
  </property>
  <property>
    <name>fs.azure.account.test.oauth2.client.secret</name>
    <value>{client secret}</value>
    <description>
The client secret(application's secret) for the app created on step 1
    </description>
  </property>
  <property>
    <name>fs.azure.check.access.testuser.guid</name>
    <value>{guid}</value>
    <description>The guid fetched on step 2</description>
  </property>
  <property>
    <name>fs.azure.account.oauth2.client.endpoint.{account name}.dfs.core
.windows.net</name>
    <value>https://login.microsoftonline.com/{TENANTID}/oauth2/token</value>
    <description>
Token end point. This can be found through Azure portal. As part of CheckAccess
test cases. The access will be tested for an FS instance created with the
above mentioned client credentials. So this configuration is necessary to
create the test FS instance.
    </description>
  </property>

http[s]://[account][ドメインサフィックス]/[filesystem] の代わりに http[s]://[ip]:[port]/[アカウント]/[filesystem] という URL 形式を使用するエンドポイントに対してテストを実行する場合は、以下を使用してください

<property>
  <name>fs.azure.abfs.endpoint</name>
  <value>{IP}:{PORT}</value>
</property>