便利な開発者ツール

テストカバレッジ

Apache Spark コミュニティは、コミュニティのテストカバレッジを維持するためにさまざまなリソースを利用しています。

GitHub Actions

GitHub Actions は、Ubuntu 22.04 上で以下の機能を提供します。

Apache Spark 4

Scala 2.13 SBT ビルド (Java 17)
Scala 2.13 Maven ビルド (Java 17/21)
Java/Scala/Python/R 単体テスト (Java 17/Scala 2.13/SBT)
TPC-DS ベンチマーク (スケールファクター 1)
JDBC Docker 統合テスト
Kubernetes 統合テスト
日次 Java/Scala/Python/R 単体テスト (Java 21 および Scala 2.13/SBT)

Apache Spark 3

Scala 2.12 SBT ビルド (Java 8)
Scala 2.12 Maven ビルド (Java 11/17)
Java/Scala/Python/R 単体テスト (Java 8/Scala 2.12/SBT)
Kubernetes 統合テスト
日次 Java/Scala/Python/R 単体テスト (Java 8 および Scala 2.13/SBT)
日次 JDBC Docker 統合テスト (Java 8 および Scala 2.13/SBT)
日次 TPC-DS ベンチマーク (スケールファクター 1、Java 8 および Scala 2.12/SBT)

便利な開発者ツール

ビルド時間の短縮

SBT: アセンブリ JAR の再作成を回避する

Spark のデフォルトのビルド戦略は、すべての依存関係を含む JAR をアセンブルすることです。これは、反復的な開発を行う際に面倒な場合があります。ローカルで開発する場合、すべての Spark の依存関係を含むアセンブリ JAR を作成し、変更を加えるたびに Spark 自体のみを再パッケージ化することが可能です。

$ build/sbt clean package
$ ./bin/spark-shell
$ export SPARK_PREPEND_CLASSES=true
$ ./bin/spark-shell # Now it's using compiled classes
# ... do some local development ... #
$ build/sbt compile
$ unset SPARK_PREPEND_CLASSES
$ ./bin/spark-shell
 
# You can also use ~ to let sbt do incremental builds on file changes without running a new sbt session every time
$ build/sbt ~compile

サブモジュールの個別のビルド

たとえば、Spark Core モジュールを以下のようにビルドできます。

$ # sbt
$ build/sbt
> project core
> package

$ # or you can build the spark-core module with sbt directly using:
$ build/sbt core/package

$ # Maven
$ build/mvn package -DskipTests -pl core

個々のテストの実行

ローカルで開発する場合、テストスイート全体を実行するのではなく、1 つまたは少数のテストを実行すると便利なことがよくあります。

SBT でのテスト

個々のテストを実行する最も速い方法は、sbt コンソールを使用することです。sbt コンソールを開いたままにしておき、必要に応じてテストを再実行するために使用するのが最も速いです。たとえば、特定のプロジェクト (例: core) のすべてのテストを実行するには

$ build/sbt
> project core
> test

testOnly コマンドを使用して、単一のテストスイートを実行できます。たとえば、DAGSchedulerSuite を実行するには

> testOnly org.apache.spark.scheduler.DAGSchedulerSuite

testOnly コマンドはワイルドカードを受け入れます。たとえば、DAGSchedulerSuite を次のように実行することもできます。

> testOnly *DAGSchedulerSuite

または、scheduler パッケージ内のすべてのテストを実行することもできます。

> testOnly org.apache.spark.scheduler.*

DAGSchedulerSuite 内の単一のテスト (たとえば、名前に「SPARK-12345」が含まれるテスト) を実行したい場合は、sbt コンソールで次のコマンドを実行します。

> testOnly *DAGSchedulerSuite -- -z "SPARK-12345"

必要であれば、これらのコマンドをすべてコマンドラインで実行することもできます (ただし、開いているコンソールでテストを実行するよりも遅くなります)。これを行うには、testOnly およびそれに続く引数を引用符で囲む必要があります。

$ build/sbt "core/testOnly *DAGSchedulerSuite -- -z SPARK-12345"

sbt で個々のテストを実行する方法の詳細については、sbt ドキュメントを参照してください。

Maven でのテスト

Maven では、-DwildcardSuites フラグを使用して個々の Scala テストを実行できます。

build/mvn -Dtest=none -DwildcardSuites=org.apache.spark.scheduler.DAGSchedulerSuite test

Java テストの実行を回避するには、-Dtest=none が必要です。ScalaTest Maven プラグインの詳細については、ScalaTest ドキュメントを参照してください。

個々の Java テストを実行するには、-Dtest フラグを使用できます。

build/mvn test -DwildcardSuites=none -Dtest=org.apache.spark.streaming.JavaAPISuite test

PySpark のテスト

python ディレクトリの下にある run-tests スクリプトを使用して、個々の PySpark テストを実行できます。テストケースは、各 PySpark パッケージの下にある tests パッケージにあります。Apache Spark の Scala または Python 側に変更を加えた場合、PySpark テストを実行する前に Apache Spark を手動で再ビルドする必要があることに注意してください。変更を適用するためです。PySpark テストスクリプトの実行は、自動的にビルドしません。

また、macOS High Serria+ で PySpark を使用する際の継続的な問題があることに注意してください。OBJC_DISABLE_INITIALIZE_FORK_SAFETY を YES に設定する必要があります。一部のテストを実行するためです。詳細については、PySpark の問題およびPython の問題を参照してください。

特定のモジュールのテストケースを実行するには

$ python/run-tests --testnames pyspark.sql.tests.test_arrow

特定のクラスのテストケースを実行するには

$ python/run-tests --testnames 'pyspark.sql.tests.test_arrow ArrowTests'

特定のクラスの単一テストケースを実行するには

$ python/run-tests --testnames 'pyspark.sql.tests.test_arrow ArrowTests.test_null_conversion'

特定のモジュールで doctest を実行することもできます。

$ python/run-tests --testnames pyspark.sql.dataframe

最後に、同じ場所にある run-tests-with-coverage という別のスクリプトがあり、PySpark テストのカバレッジレポートを生成します。run-tests と同じ引数を受け入れます。

$ python/run-tests-with-coverage --testnames pyspark.sql.tests.test_arrow --python-executables=python
...
Name                              Stmts   Miss Branch BrPart  Cover
-------------------------------------------------------------------
pyspark/__init__.py                  42      4      8      2    84%
pyspark/_globals.py                  16      3      4      2    75%
...
Generating HTML files for PySpark coverage under /.../spark/python/test_coverage/htmlcov

カバレッジレポートは、/.../spark/python/test_coverage/htmlcov の HTML で視覚的に確認できます。

python/run-tests[-with-coverage] --help を介して、他の利用可能なオプションを確認してください。

K8S のテスト

GitHub Actions は K8s の単体テストと統合テストの両方のカバレッジを提供していますが、ローカルでも実行できます。たとえば、Volcano バッチスケジューラ統合テストは手動で行う必要があります。詳細については、統合テストのドキュメントを参照してください。

https://github.com/apache/spark/blob/master/resource-managers/kubernetes/integration-tests/README.md

Docker 統合テストの実行

Docker 統合テストは GitHub Actions でカバーされています。しかし、開発とテストを高速化するためにローカルで実行することもできます。詳細については、Docker 統合テストのドキュメントを参照してください。

GitHub Actions ワークフローによるテスト

Apache Spark は、継続的インテグレーションと幅広い自動化を可能にする GitHub Actions を活用しています。Apache Spark リポジトリは、開発者がプルリクエストを作成する前に実行できるいくつかの GitHub Actions ワークフローを提供しています。

フォークしたリポジトリでのベンチマークの実行

Apache Spark リポジトリは、GitHub Actions でベンチマークを簡単に実行できる方法を提供しています。プルリクエストでベンチマーク結果を更新する場合、できるだけ同じ環境で実行するために、GitHub Actions を使用してベンチマークを実行し、生成することを推奨します。

フォークしたリポジトリの「Actions」タブをクリックします。
「All workflows」リストで「Run benchmarks」ワークフローを選択します。
「Run workflow」ボタンをクリックし、以下のようにフィールドを適切に入力します。
- Benchmark class: 実行したいベンチマーククラス。グロブパターンが許可されます。例: org.apache.spark.sql.*。
- JDK version: ベンチマークを実行したい Java のバージョン。例: 11。
- Failfast: ベンチマークとワークフローが失敗した場合に停止するかどうかを示します。true の場合、すぐに失敗します。false の場合、失敗したかどうかにかかわらずすべて実行します。
- Number of job splits: ベンチマークジョブを指定された数に分割し、並列で実行します。これは、GitHub Actions でのワークフローとジョブの時間制限を回避するのに特に役立ちます。
「Run benchmarks」ワークフローが完了したら、ワークフローをクリックし、「Artifacts」でベンチマーク結果をダウンロードします。
Apache Spark リポジトリのルートディレクトリに移動し、ダウンロードしたファイルを解凍/展開すると、更新するファイルが適切に配置されてベンチマーク結果が更新されます。

ScalaTest の問題

ScalaTest を実行中に次のエラーが発生した場合

An internal error occurred during: "Launching XYZSuite.scala".
java.lang.NullPointerException

これは、クラスパスに Scala ライブラリが正しくないことが原因です。修正するには

プロジェクトを右クリック
Build Path | Configure Build Path を選択
Add Library | Scala Library を選択
scala-library-2.10.4.jar - lib_managed\jars を削除

「Could not find resource path for Web UI: org/apache/spark/ui/static」というエラーが発生した場合、これはクラスパスの問題 (一部のクラスがコンパイルされていない可能性が高い) が原因です。これを修正するには、コマンドラインからテストを実行するだけで十分です。

build/sbt "testOnly org.apache.spark.rdd.SortingSuite"

バイナリ互換性

バイナリ互換性を確保するために、Spark は MiMa を使用しています。

バイナリ互換性の確保

問題に取り組む際には、プルリクエストを開く前に、変更がバイナリ互換性の問題を導入していないことを確認するのが常に良い考えです。

これを行うには、次のコマンドを実行できます。

$ dev/mima

MiMa によって報告されたバイナリ互換性の問題は、次のようになります。

[error] method this(org.apache.spark.sql.Dataset)Unit in class org.apache.spark.SomeClass does not have a correspondent in current version
[error] filter with: ProblemFilters.exclude[DirectMissingMethodProblem]("org.apache.spark.SomeClass.this")

バイナリ互換性の解決

バイナリ互換性が正当である、または MiMa が誤検知を報告した (たとえば、報告されたバイナリ互換性がユーザーに表示されない API に関するものである) と考える場合は、MiMa レポートによって提案された内容と、作業中の JIRA 番号およびそのタイトルを含むコメントを含む除外を project/MimaExcludes.scala に追加することで除外できます。

上記の問題については、以下を追加するかもしれません。

// [SPARK-zz][CORE] Fix an issue
ProblemFilters.exclude[DirectMissingMethodProblem]("org.apache.spark.SomeClass.this")

それ以外の場合は、プルリクエストを開く前または更新する前に、これらの互換性の問題を解決する必要があります。通常、MiMa によって報告される問題は自己説明的であり、バイナリ互換性を維持するために追加する必要がある欠落しているメンバー (メソッドまたはフィールド) に関するものです。

プルリクエストのチェックアウト

Git は、リモートのプルリクエストをローカルリポジトリにフェッチするメカニズムを提供します。これは、コードをレビューしたり、ローカルでパッチをテストしたりする場合に便利です。まだ Spark Git リポジトリをクローンしていない場合は、次のコマンドを使用します。

$ git clone https://github.com/apache/spark.git
$ cd spark

この機能を使用するには、プルリクエストデータをフェッチするように git リモートリポジトリを構成する必要があります。これを行うには、Spark ディレクトリ内の .git/config ファイルを編集します。リモートが「origin」という名前でない場合もあります。それ以外の場合は、別の名前を付けた可能性があります。

[remote "origin"]
  url = git@github.com:apache/spark.git
  fetch = +refs/heads/*:refs/remotes/origin/*
  fetch = +refs/pull/*/head:refs/remotes/origin/pr/*   # Add this line

これが完了したら、リモートのプルリクエストをフェッチできます。

# Fetch remote pull requests
$ git fetch origin
# Checkout a remote pull request
$ git checkout origin/pr/112
# Create a local branch from a remote pull request
$ git checkout origin/pr/112 -b new-branch

依存関係グラフの生成

$ # sbt
$ build/sbt dependencyTree
 
$ # Maven
$ build/mvn -DskipTests install
$ build/mvn dependency:tree

インポートの整理

Aaron Davidson によるIntelliJ Imports Organizer を使用して、コードのインポートを整理できます。スタイルガイドのインポート順序に一致するように構成できます。

コードのフォーマット

Scala コードをフォーマットするには、PR を送信する前に次のコマンドを実行します。

$ ./dev/scalafmt

デフォルトでは、このスクリプトは git master と異なるファイルをフォーマットします。詳細については、scalafmt ドキュメントを参照してください。ただし、ローカルにインストールされているバージョンではなく、既存のスクリプトを使用してください。

IDE セットアップ

IntelliJ

多くの Spark 開発者はコマンドラインで SBT または Maven を使用しますが、最も一般的な IDE は IntelliJ IDEA です。コミュニティエディションは無料 (Apache コミッターは無料の IntelliJ Ultimate Edition ライセンスを取得できます) で入手でき、Preferences > Plugins から JetBrains Scala プラグインをインストールできます。

IntelliJ 用の Spark プロジェクトを作成するには

IntelliJ をダウンロードし、IntelliJ 用 Scala プラグインをインストールします。
File -> Import Project に移動し、spark ソースディレクトリを見つけて、「Maven Project」を選択します。
インポートウィザードでは、設定をデフォルトのままにしておいても問題ありません。ただし、「Import Maven projects automatically」を有効にすると、プロジェクト構造の変更が IntelliJ プロジェクトを自動的に更新するため、通常は便利です。
Building Spark に記載されているように、一部のビルド構成では特定のプロファイルを有効にする必要があります。上記で -P[profile name] で有効にしたのと同じプロファイルを、インポートウィザードの「Profiles」画面で有効にすることができます。たとえば、Hadoop 2.7 および YARN サポートで開発している場合は、yarn および hadoop-2.7 プロファイルを有効にします。これらの選択は、View メニューから「Maven Projects」ツールウィンドウにアクセスし、「Profiles」セクションを展開することで、後で変更できます。

その他のヒント

「Rebuild Project」は、生成されたソースファイルが自動的に生成されないため、初めてコンパイルするときに失敗する可能性があります。「Maven Projects」ツールウィンドウの「Generate Sources and Update Folders For All Projects」ボタンをクリックして、これらのソースを手動で生成してみてください。
IntelliJ にバンドルされている Maven のバージョンは、Spark には新しすぎない場合があります。その場合、「Generate Sources and Update Folders For All Projects」アクションはサイレントに失敗する可能性があります。プロジェクトの Maven ホームディレクトリ (Preference -> Build, Execution, Deployment -> Maven -> Maven home directory) を、新しい Maven インストールを指すようにリセットしてください。また、最初に build/mvn スクリプトで Spark をビルドすることもできます。スクリプトが十分新しい Maven インストールを見つけられない場合、最近のバージョンの Maven を build/apache-maven-<version>/ フォルダにダウンロードしてインストールします。
一部のモジュールには、Maven プロファイルに基づいたプラグイン可能なソースディレクトリがあります (たとえば、Scala 2.11 と 2.10 の両方をサポートするため、または異なるバージョンの Hive に対してクロスビルドを許可するため)。場合によっては、IntelliJ は maven-build-plugin によるソースディレクトリの追加を正しく検出しません。この場合、プロジェクト全体をコンパイルするために、ソースの場所を明示的に追加する必要があるかもしれません。その場合は、「Project Settings」を開き、「Modules」を選択します。選択した Maven プロファイルに基づいて、次のモジュールにソースフォルダを追加する必要がある場合があります。
- spark-hive: v0.13.1/src/main/scala を追加
- spark-streaming-flume-sink: target\scala-2.11\src_managed\main\compiled_avro を追加
- spark-catalyst: target\scala-2.11\src_managed\main を追加
コンパイルが「scalac: bad option: -P:/home/jakub/.m2/repository/org/scalamacros/paradise_2.10.4/2.0.1/paradise_2.10.4-2.0.1.jar」のようなエラーで失敗した場合。その場合は、「Preferences > Build, Execution, Deployment > Scala Compiler」に移動し、「Additional compiler options」フィールドをクリアします。そうすれば動作しますが、プロジェクトが再インポートされるとオプションが元に戻ります。クワート (例: sql) を使用するプロジェクトをビルドしようとした場合、その JAR をコンパイラプラグインにする必要があります (「Additional compiler options」のすぐ下)。それ以外の場合は、次のようなエラーが表示されます。
```
/Users/irashid/github/spark/sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/codegen/CodeGenerator.scala
Error:(147, 9) value q is not a member of StringContext
 Note: implicit class Evaluate2 is not applicable here because it comes after the application point and it lacks an explicit result type
      q"""
      ^ 
```

Spark のリモートデバッグ

このセクションでは、IntelliJ を使用して Spark をリモートでデバッグする方法を説明します。

リモートデバッグ構成の設定

デフォルトのリモート構成テンプレートを開くには、*Run > Edit Configurations > + > Remote* に従います:

通常、デフォルト値は十分に使用できます。*Debugger mode* として **Listen to remote JVM** を選択し、適切な JDK バージョンを選択して、*Command line arguments for remote JVM* を生成するようにしてください。

構成を終了して保存したら、*Run > Run > Your_Remote_Debug_Name > Debug* に従うことでリモートデバッグプロセスを開始し、SBT コンソールが接続するのを待つことができます。

リモートデバッグのトリガー

一般的に、2 つのステップがあります。

最後のステップで生成された *Command line arguments for remote JVM* を使用して JVM オプションを設定します。
Spark の実行を開始します (SBT テスト、pyspark テスト、spark-shell など)。

以下は、SBT 単体テストを使用してリモートデバッグをトリガーする例です。

SBT コンソールに入力します。

./build/sbt

ターゲットテストが存在するプロジェクトに切り替えます。例:

sbt > project core

*Command line arguments for remote JVM* をコピー＆ペーストします。

sbt > set javaOptions in Test += "-agentlib:jdwp=transport=dt_socket,server=n,suspend=n,address=localhost:5005"

IntelliJ でブレークポイントを設定し、SBT でテストを実行します。例:

sbt > testOnly *SparkContextSuite -- -t "Only one SparkContext may be active at a time"

IntelliJ コンソールで「Connected to the target VM, address: ‘localhost:5005’, transport: ‘socket’」と表示されたら、IntelliJ と正常に接続されているはずです。その後、通常どおり IntelliJ でデバッグを開始できます。

リモートデバッグモードを終了するには (リモートデバッガを常に起動する必要がないように)、プロジェクト内にいるときに SBT コンソールで「session clear」と入力します。

Eclipse

Eclipse は Spark の開発とテストに使用できます。次の構成が機能することが知られています。

Eclipse Juno
Scala IDE 4.0
Scala Test

最も簡単な方法は、Scala IDE ダウンロードページから Scala IDE バンドルをダウンロードすることです。これは ScalaTest がプリインストールされています。または、Scala IDE アップデートサイトまたは Eclipse Marketplace を使用します。

SBT は、Eclipse の .project および .classpath ファイルを作成できます。各 Spark サブプロジェクトのこれらのファイルを作成するには、このコマンドを使用します。

sbt/sbt eclipse

特定のプロジェクト (例: spark-core) をインポートするには、「File | Import | Existing Projects」を Workspace に選択します。「Copy projects into workspace」は選択しないでください。

Scala 2.10 で開発したい場合は、Spark のコンパイルに使用される正確な Scala バージョンの Scala インストールを構成する必要があります。Scala IDE には最新バージョン (現時点では 2.10.5 および 2.11.8) がバンドルされているため、Scala 2.10.5 ディストリビューションの lib/ ディレクトリを指すことで、Eclipse Preferences -> Scala -> Installations に追加する必要があります。これが完了したら、すべての Spark プロジェクトを選択し、右クリックして「Scala -> Set Scala Installation」を選択し、2.10.5 インストールを指します。これにより、無効なクロスコンパイルライブラリに関するすべてのエラーがクリアされるはずです。クリーンビルドが成功するはずです。

ScalaTest は、ソースファイルを右クリックして「Run As | Scala Test」を選択することで単体テストを実行できます。

Java メモリエラーが発生した場合は、Eclipse インストールディレクトリの eclipse.ini の設定を増やす必要があるかもしれません。必要に応じて次の設定を増やしてください。

--launcher.XXMaxPermSize
256M

ナイトリービルド

ASF は、マスターブランチとメンテナンスブランチの両方に対して、Maven アーティファクトのスナップショットリリースを nightly で公開しています。スナップショットにリンクするには、ビルドに ASF スナップショットリポジトリを追加する必要があります。スナップショットアーティファクトは一時的なものであり、変更または削除される可能性があることに注意してください。これらを使用するには、https://repository.apache.org/snapshots/ で ASF スナップショットリポジトリを追加する必要があります。

groupId: org.apache.spark
artifactId: spark-core_2.12
version: 3.0.0-SNAPSHOT

YourKit を使用した Spark アプリケーションのプロファイリング

YourKit Java Profiler を使用して Spark アプリケーションをプロファイリングする手順を以下に示します。

Spark EC2 イメージの場合

マスターノードにログインした後、YourKit ダウンロードページから Linux 用 YourKit Java Profiler をダウンロードします。このファイルはかなり大きい (~100 MB) で、YourKit ダウンロードサイトはやや遅いため、このファイルをミラーリングするか、カスタム AMI に含めることを検討してもよいでしょう。
このファイルをどこかに解凍します (この例では /root): unzip YourKit-JavaProfiler-2017.02-b66.zip
展開された YourKit ファイルを copy-dir を使用して各ノードにコピーします: ~/spark-ec2/copy-dir /root/YourKit-JavaProfiler-2017.02

~/spark/conf/spark-env.sh を編集し、次の行を追加して、Spark JVM が YourKit プロファイリングエージェントを使用するように構成します。

SPARK_DAEMON_JAVA_OPTS+=" -agentpath:/root/YourKit-JavaProfiler-2017.02/bin/linux-x86-64/libyjpagent.so=sampling"
export SPARK_DAEMON_JAVA_OPTS
SPARK_EXECUTOR_OPTS+=" -agentpath:/root/YourKit-JavaProfiler-2017.02/bin/linux-x86-64/libyjpagent.so=sampling"
export SPARK_EXECUTOR_OPTS

更新された構成を各ノードにコピーします: ~/spark-ec2/copy-dir ~/spark/conf/spark-env.sh
Spark クラスタを再起動します: ~/spark/bin/stop-all.sh および ~/spark/bin/start-all.sh
デフォルトでは、YourKit profiler エージェントはポート 10001-10010 を使用します。YourKit デスクトップアプリケーションをリモート profiler エージェントに接続するには、クラスタの EC2 セキュリティグループでこれらのポートを開く必要があります。これを行うには、AWS Management Console にサインインします。EC2 セクションに移動し、ページの左側にある「Network & Security」セクションから「Security Groups」を選択します。クラスタに対応するセキュリティグループを見つけます。クラスタが test_cluster という名前で起動された場合、test_cluster-slaves および test_cluster-master セキュリティグループの設定を変更する必要があります。各グループについて、リストから選択し、「Inbound」タブをクリックして、ポート範囲 10001-10010 を開く新しい「Custom TCP Rule」を作成します。最後に、「Apply Rule Changes」をクリックします。両方のセキュリティグループに対してこれを行うことを確認してください。注: デフォルトでは、spark-ec2 はセキュリティグループを再利用します。このクラスタを停止して別のクラスタを同じ名前で起動した場合、セキュリティグループの設定は再利用されます。
デスクトップで YourKit profiler を起動します。
ウェルカム画面から「Connect to remote application…」を選択し、Spark マスターまたはワーカーマシンのアドレスを入力します。例: ec2--.compute-1.amazonaws.com
これで YourKit はリモートプロファイリングエージェントに接続されるはずです。プロファイリング情報が表示されるまで数分かかる場合があります。

プロファイラエージェントのスタートアップオプションの完全なリストについては、完全な YourKit ドキュメントを参照してください: startup options。

Spark 単体テストの場合

SBT を介して Spark テストを実行する場合、SparkBuild.scala に javaOptions in Test += "-agentpath:/path/to/yjp" を追加して、YourKit profiler エージェントが有効になった状態でテストを起動します。
プロファイラエージェントのプラットフォーム固有のパスは、YourKit ドキュメントに記載されています。

生成ツールの使用

一般的に、ASF は生成 AI ツールと共同で作成された貢献を許可しています。ただし、生成されたコンテンツを含むパッチを送信する際には、いくつかの考慮事項があります。

まず、そのようなツールの使用を開示する必要があります。さらに、ツールの利用規約がオープンソースプロジェクトでの使用と互換性があり、生成されたコンテンツの包含が著作権侵害のリスクをもたらさないことを確認する責任があります。

詳細と最新情報については、The ASF Generative Tooling Guidance を参照してください。

テストカバレッジ

GitHub Actions

Apache Spark 4

Apache Spark 3

便利な開発者ツール

ビルド時間の短縮

SBT: アセンブリ JAR の再作成を回避する

サブモジュールの個別のビルド

個々のテストの実行

SBT でのテスト

Maven でのテスト

PySpark のテスト

K8S のテスト

Docker 統合テストの実行

GitHub Actions ワークフローによるテスト

フォークしたリポジトリでのベンチマークの実行

ScalaTest の問題

バイナリ互換性

バイナリ互換性の確保

バイナリ互換性の解決

プルリクエストのチェックアウト

依存関係グラフの生成

インポートの整理

コードのフォーマット

IDE セットアップ

IntelliJ

Spark のリモートデバッグ

リモートデバッグ構成の設定

リモートデバッグのトリガー

Eclipse

ナイトリービルド

YourKit を使用した Spark アプリケーションのプロファイリング

Spark EC2 イメージの場合

Spark 単体テストの場合

生成ツールの使用

最新ニュース