トランスフォームのバージョン

トランスフォームでは、ビルド時のトランスフォームのバージョンによって使用される Spark と Java のバージョンが決まります。トランスフォームは、ジョブが最新のセキュリティとパフォーマンスの改善に追従するように、バックグラウンドで自動的にアップグレードされます。Spark のバージョン管理ポリシー ↗により、API はバージョン間で一貫性が保たれ、既存の設定は行動の変更を防ぐために有効にされています。これらの設定は Spark のマイグレーションガイド ↗で文書化されています。

リリース

使用されるバージョンは、以下に示すテーブルで示されています。

Python

Java

SQL

環境ページ

環境ページは、ジョブトラッカーから Spark Details > Environment を選択することでアクセスできます。ここでは、ビルドの主要な設定詳細、トランスフォームと Spark のバージョンを含めて表示されます。

sparkModuleVersion はトランスフォームのバージョンに対応し、sparkVersion はビルドで使用される Spark のバージョンに対応します。

ランタイムバージョン管理

トランスフォームのランタイムバージョンは、ビルドが実行されるたびに選択されます。「調整」システムが使用され、ユーザーのビルドがもはや動作しないバージョンにアップグレードされないようにします。調整プロセスは、アップグレードを選択的にテストし、必要に応じて古いバージョンに戻します。新しい Spark のバージョンが出ると、可能な場合はユーザーの介入なしでパイプラインに自動的にテストと実装が行われます。アップグレードに失敗した場合、ユーザーのパイプラインは古い Spark のバージョンで引き続き実行されます。各 Spark のバージョンアップグレードは、お知らせと組み合わせて行われます。一時的に Spark の既存のバージョンに留まるには、モジュールピン留めを使用してパイプラインを固定バージョンにピン留めしてください。

ランタイムバージョンがリリースされてから約1ヶ月後、リポジトリのアップグレードを促すプロンプトが送信され、自動アップグレードが不可能だった問題についてユーザーに通知します。これらのケースは、リポジトリのチェックエラーに基づいてデバッグすることができるはずです。

デバッグジョブ

トランスフォームのアップグレードがユーザーのパイプラインに影響を与えたと疑われる場合は、デバッグジョブを使用して問題を診断します。失敗したジョブで、Actions と Rerun as debug job を選択して、以前に成功したバージョンを指定し、トランスフォームのバージョンの変更がブレイクの原因であることを確認します。トランスフォームのアップグレードがユーザーのパイプラインを壊した状況に遭遇した場合は、さらなる支援のために Palantir サポートに連絡してください。