注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
- オリジナルの巨大な変換を、その結果がデータセットとして保存される小さな変換に分割します。
- これらの小さな変換を順番に実行し、Foundry にデータを戻します。
- この事前に計算されたデータを後続のステップで使用します。
2. キャッシング
キャッシングを使用して、変換の実行を高速化できます。キャッシングは、変換の計算結果を保存し、再計算が必要な場合にその結果を再利用することで、計算時間を節約します。
具体的には：
- 計算に時間がかかる変換に対してキャッシュを有効にすることを検討します。
- キャッシュが有効な場合、変換の再実行が高速化されます。
3. 関数呼び出し
コード内で関数を使用して、複雑な計算を一度に実行する代わりに、簡単なステップに分割して実行します。これにより、コードの可読性が向上し、計算効率が向上することがあります。
4. ダウンサンプリング
データのサイズが大きい場合、ダウンサンプリングを使用してデータを削減し、計算時間を短縮できます。ダウンサンプリングは、データセットからランダムに一部のデータを選択することで、データ量を削減します。
5. まとめ
上記の方法を使用して、Code Workbook のセル計算を高速化できます。適切なリファクタリング、キャッシング、関数呼び出し、およびダウンサンプリングを使用して、変換の実行時間を短縮し、効率的なコードを作成します。
workbook_1:
cell_A:
work_1 : input -> df_1
(正しい結果を得るためには4回の反復が必要): 4 * df_1
work_2: df_1 -> df_2
(正しい結果を得るためには4回の反復が必要): 4 * df_2 + 4 * df_1
= 4 df_2 + 4 df_1
work_3: df_2 -> df_3
(正しい結果を得るためには4回の反復が必要): 4 * df_3 + 4 * df_2 + 4 * df_1
合計の仕事:
cell_A
= work_1 + work_2 + work_3
= 4 * df_1 + (4 * df_2 + 4 * df_1) + (4 * df_3 + 4 * df_2 + 4 * df_1)
= 12 * df_1 + 8 * df_2 + 4 * df_3
このコードは、各作業がデータフレーム(df_1, df_2, df_3)をどのように処理するかを示しています。各作業では、正しい結果を得るために4回の反復が必要で、それぞれの作業で生成された結果は、次の作業の入力として使用されます。そして、合計の仕事は、これらすべての作業の結果を合計したものです。 それでは、work_1 と work_2 をそれぞれ独自のセルに書き込んだ場合、行う作業は次のようになります：
workbook_2:
cell_A:
work_1: input -> df_1
(正しい結果が出るまで4回繰り返す): 4 * df_1
cell_B:
work_2: df_1 -> df_2
(正しい結果が出るまで4回繰り返す): 4 * df_2
cell_C:
work:3: df_2 -> df_3
(正しい結果が出るまで4回繰り返す): 4 * df_3
total_work:
cell_A + cell_B + cell_C
= work_1 + work_2 + work_3
= 4 * df_1 + 4 * df_2 + 4 * df_3
df_1、df_2、df_3がすべて同じ計算コストを持つと仮定すると、workbook_1.total_work = 24 * df_1であり、workbook_2.total_work = 12 * df_1なので、反復処理において約2倍の速度向上を期待できます。
2. キャッシング
"小さな"データセットについては、ワークブックを選択し、Actions > Cache を選択してキャッシュするべきです。
これにより、ユーザーのワークブックの行がメモリ内に保持され、書き戻されたデータセットからの取得が不要になります。"小さい"は、考慮しなければならないいくつかの要素によって与えられる任意の判断ですが、Code Workbookはそれをキャッシュしようとし、大きすぎる場合は警告します。
3. 関数呼び出し
可能な限りネイティブのPySparkメソッドを使用し、データに直接Pythonメソッドを使用しないようにするべきです（例えば、個々の行をループしたり、UDFを実行したりする）。PySparkメソッドは、Scalaで書かれた基本的なSparkメソッドを呼び出し、Pythonランタイムではなくデータに直接実行します。データと対話するシステムではなく、このシステムと対話するレイヤーとしてPythonを使用するだけで、Spark自体のパフォーマンスの利点をすべて得ることができます。
4. ダウンサンプリング
大きな入力データセットの正確なサンプルを自分で導き出すことができれば、これをユーザーの変換のモック入力として使用できます。そのロジックを完璧にし、フルセットに対してテストしたいと思うまでの時間です。
PySparkコードを一行も書くことなく、100万行以上のデータセットをダウンサンプリングしてキャッシュすることを検討してみてください。大きなデータセットのサイズが原因で構文のバグをゆっくりと発見することなく、反転時間が早くなるかもしれません。
5. まとめ
良いCode Workbookは以下のようになります：
- 特定の実体化を行うコードの離散的なチャンクで、後で再利用することを期待していますが、何度も計算し直す必要はありません。
- "小さい"サイズにダウンサンプリングされています。
- 非常に高速な取得のためのキャッシュされた"小さい"データセット。
- 高速な基本的なSparkライブラリを利用するネイティブのPySparkコードのみ。