マルチ出力トランスフォームを最適化する

トランスフォームを使って入力データセットから出力データセットを生成する方法は2つあります。

• 同じ入力と異なる出力を持つトランスフォームを複数作成します。
• 複数の入力を受け取り、複数の出力を生成するマルチ出力トランスフォームを定義します。

同じ入力と異なる出力の組み合わせを持つマルチ出力トランスフォームを複数作成する、ハイブリッドなアプローチも可能です。以下のセクションでは、これらの選択肢について説明します。

複数の単一出力トランスフォーム

単一出力トランスフォームは、X1, X2, ..., Xn を入力として受け取り、1つの出力 Y を生成します。複数の出力 Y1, Y2, ..., Yn を生成するには、これらの X を入力として受け取り、それぞれ異なる出力に書き込むトランスフォームを複数記述します。各出力には、それぞれ専用のトランスフォームがあります。

複数の単一出力トランスフォームの利点

複数の単一出力トランスフォームを使用する利点は、次のとおりです。

• 各出力のロジックが別々のトランスフォームにまとまっているため、保守しやすくなります。
• 各出力の入力が異なる場合、各トランスフォームに必要な最小限の入力だけを割り当てられます。これにより、ビルドを高速化でき、必要に応じてマーキングが付いた入力を分離して伝播を制限できます。
• 各出力を個別にビルドできます。
  • 1つの出力を再実行するために、すべての出力が完了するのを待つ必要はありません。これは、トランスフォームを異なる頻度でビルドしたい場合に便利です。
  • コストが高くなる可能性があるすべての出力のビルドを行わずに、単一の出力をビルドできます。
• 各出力の Spark プロファイルをカスタマイズできます。これは、出力ごとに計算コストが異なる場合に便利です。
• 異なるプロジェクトに書き込めます。トランスフォームを異なるリポジトリに移動できるためです。ただし、マルチ出力トランスフォームでも、別の場所にデータをコピーするステップを追加することで、異なるプロジェクトに書き込めます。
• トランスフォームごとに異なるライブラリやフレームワークを使用できます。たとえば、一部の出力には Pandas の軽量トランスフォームを使用し、ほかの出力には PySpark を使用できます。
• データ、コード、プラットフォームのいずれに起因する場合でも、障害の影響は単一のトランスフォームに限定されます。
• トランスフォーム間とトランスフォーム内で並列化が行われます。

複数の単一出力トランスフォームの制限事項

一方、単一出力トランスフォームには、次のような欠点もあります。

• ロジックが重複する可能性があります。
  • そのため、保守が難しくなる可能性があります。重複するロジックを共有ライブラリに抽出することを検討するとよいでしょう。
  • 各出力で冗長な PySpark 処理が発生する可能性があります。状況によっては、冗長な Spark 処理を避けるために、中間データセットを保存することを検討するとよいでしょう。
  • 出力データセット間の依存度が高すぎる場合、重複するロジックのために多数の中間データセットが必要になる可能性があります。これは実質的に、マルチ出力トランスフォームに相当します。
• 各トランスフォームには、ドライバーと、おそらくエグゼキューターも含む、専用の Spark 環境が用意されます。
  • これらの計算リソースの使用量は積み重なるため、すべての出力を同時に実行すると、一部がキューで待機する可能性があります。
  • トランスフォームを実行するためのオーバーヘッドコストが、すべてのトランスフォームで発生します。これには、Spark の初期化とドライバーの実行コストが含まれます。
  • Spark プロファイルはトランスフォームごとにカスタマイズできますが、実際にはそれぞれを細かく調整する管理コストがかかり、常に現実的とは限りません。プロファイルをカスタマイズしない場合、例外的に規模が大きいデータセットでは、マルチ出力トランスフォームよりも利用できるエグゼキューターが少なくなり、ビルドの長時間化やタイムアウトにつながる可能性があります。

全体として、この選択肢は最も柔軟性がありますが、重複する処理にはあまり適しておらず、計算コストが高くなる可能性があります。

マルチ出力トランスフォーム

マルチ出力トランスフォームは、X1, X2, ... Xn を入力として受け取り、Y1, Y2, ... Yn を出力として生成します。 すべての出力に対して1個のトランスフォームを使用します。

マルチ出力トランスフォームの利点

マルチ出力トランスフォームを使用する利点は、次のとおりです。

• トランスフォームのオーバーヘッドコストが繰り返し発生しません。
  • ドライバーとジョブはそれぞれ1個です。
  • 大規模な処理では、この効果が大きくなる可能性があります。
• すべての出力のロジックが1か所にまとまります。
  • 中間データセットが不要になり、中間結果はメモリー内で計算されます。
  • 冗長なロジックによる重複コストが発生しません。

マルチ出力トランスフォームの制限事項

マルチ出力トランスフォームを使用する欠点は、次のとおりです。

• 出力ごとのロジックが大きく異なる場合、整理がつかなくなり、保守が難しくなる可能性があります。
• 各出力を個別にビルドできません。
  • 新しいビルドを開始するには、前のビルドですべての出力が完了するのを待つ必要があります。トランスフォーム内で出力ごとの頻度をカスタマイズすることはできません。
• トランスフォームには、1組の Spark プロファイルが割り当てられます。1個のドライバーがすべての処理を実行し、エグゼキューターにタスクを割り当てるため、考慮すべき点があります。
  • 動的割り当てプロファイルでこの問題を軽減できますが、これらのプロファイルはリソースキューをすぐに埋めてしまいます。
  • 並列化できないタスクは、ドライバーにオーバーヘッドを発生させます。これには、ドライバーへのデータ収集、ユーザー定義関数（UDF）の実行、Python コードの実行（たとえば API の呼び出し）などが含まれますが、これらに限定されません。
  • エグゼキューター数に比べてデータ規模が小さい場合、ネットワーク入出力のオーバーヘッドが、エグゼキューターの計算処理よりも大きくなる可能性があります。
• ビルドの失敗がすべての出力に影響します。
  • 1つの出力の処理に24時間を超える時間がかかる場合や、エラーが含まれる場合、すべての出力が失敗します。
  • これにより、問題のデバッグが難しくなる可能性があります。
• 使用コストは、すべての出力データセットに均等に分配されます。出力が10個ある場合、ビルドコストの10分の1が各データセットに関連付けられます。そのため、各出力に対応するコストを特定するのは容易ではありません。
• 入力データのサイズが変動する場合、ビルド所要時間の分散は、すべての入力に起因する分散の合計になります。これはインクリメンタル（差分処理）トランスフォームで大きな影響を及ぼす可能性があり、その場合は動的割り当てプロファイルの方が適しています。

マルチ出力トランスフォームは柔軟性が低いものの、出力で繰り返されるロジックに適しています。

その他の考慮事項

マルチ出力トランスフォームを使用する際には、次の点を考慮してください。

• Spark の詳細で、タスクの並列化がエグゼキューター数に見合っているか確認できます。ビルドに時間がかかりすぎる場合や、Spark プロファイルが大きすぎる場合は、トランスフォームの分割を検討してください。
• 各トランスフォームで使用するエグゼキューターが多いほど、オーバーヘッドコストの影響は小さくなります。小規模なデータセットを加工して多数の出力を生成する場合、マルチ出力トランスフォームでは、ネットワーク入出力の負荷がエグゼキューターの処理よりも大きくなる可能性があります。代わりに、複数のトランスフォームや、ローカルで並列化される軽量トランスフォームを使用できます。

使用するアプローチの選択

単一出力トランスフォームは非常に柔軟で、出力間でロジックが異なる場合に適しています。マルチ出力トランスフォームは柔軟性が低いものの、適切な条件下ではコスト効率が高くなる可能性があります。一般的には、次の条件を満たす場合、マルチ出力トランスフォームを選択してください。

• マルチ出力トランスフォームの制約が要件を満たしていること。マルチ出力トランスフォームの制限事項を確認して、この選択肢がユースケースに適しているか判断してください。
• 出力のロジックが類似していること。
• 処理が並列化可能であること。

これらの条件を満たす場合は、マルチ出力トランスフォームを選択することを推奨します。そうでない場合は、複数の単一出力トランスフォームを代替の選択肢として考慮しながら、ケースごとに判断してください。