分析Code Workbooks2. キャッシング

注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。

Code Workbook FAQ

以下は、Code Workbook に関するよくある質問です。

一般的な情報については、Code Workbook のドキュメントを参照してください。

作業内容をすべて別のワークブックに簡単に移動できますか？
変換ノードを変数として設定できますか？
各変換ノードがテーブルまたはデータフレームを返す必要があるのはなぜですか？
Code Workbook はマージとマージ競合に対応していますか？
環境の初期化にはどのくらい時間がかかりますか？
Code Workbook から以前削除したコードを復元するにはどうすればよいですか？
Spark 環境とカスタムライブラリ
Python コードの実行に失敗する
- Retryer エラー
データセットとして保存できませんでした
入力データセットのプレビューを更新してもワークブックが自動的に再計算されない
ブランチを master にマージできない
セルの計算を高速化する

作業内容をすべて別のワークブックに簡単に移動できますか？

はい。ワークブック間でノード（ワークブックのグラフ上の要素）をコピーして貼り付けることができます。

Ctrl を押しながら、コピー元のワークブックでコピーするノードを選択します。Contour ボードのノードのコピーと貼り付けには対応していません。
右クリックのコンテキストメニューを使用して、選択したノードをコピーします。
移動先のワークブックのグラフを選択し、Cmd+V（macOS）または Ctrl+V（Windows）のキーの組み合わせでノードを貼り付けます。新しいノードが新しいワークブックにインポートされます。

先頭に戻る

変換ノードを変数として設定できますか？

いいえ。Code Workbook のグラフ上の各変換ノードは、テーブルまたはデータフレーム（列を持つ2次元データ構造など）を返す必要があります。

先頭に戻る

各変換ノードがテーブルまたはデータフレームを返す必要があるのはなぜですか？

Foundry 内の作成物の最小単位はデータセットです。各ノードを Foundry データセットとして登録し、Foundry のほかの場所でも利用可能にするため、各変換ノードはテーブルまたはデータフレーム（列を持つ2次元データ構造など）を返す必要があります。また、Code Workbook のテーブルやデータフレームは、データセットを生成できる有効なスキーマで返す必要があります（たとえば、列が1つ以上存在する、列名が重複していない、列名に無効な文字が含まれていない、など）。

先頭に戻る

Code Workbook はマージとマージ競合に対応していますか？

はい。詳細については、ブランチとマージに関するドキュメントを参照してください。

先頭に戻る

環境の初期化にはどのくらい時間がかかりますか？

Code Workbook のデフォルト設定では、初期化に平均3～5分かかります。ただし、Code Workbook のプロファイルにパッケージを追加している場合は、パッケージの複雑さや相互依存関係によって、初期化に20～30分かかることがあります。環境内のパッケージ数が増えると、初期化時間は大幅に長くなる傾向があります。

初期化が遅い場合、一般的には環境定義が大きすぎるか、複雑すぎることを示しています。初期化時間は、環境内のパッケージ数に対して線形よりも速いペースで増加する傾向があるため、カスタム環境の簡素化を検討するとよいでしょう。場合によっては、Code Workbook がよく使われる環境を事前に初期化して、初期化を高速化することがあります。デフォルトのプロファイルに基づいてカスタム環境を作成した場合、事前の初期化が行われないために初期化時間が長くなっている可能性があります。カスタム環境の初期化時間の最適化については、詳しくはこちら

ブラウザーのタブが30分を超えて非アクティブな状態にあると、非アクティブ状態が続いたために環境が失われることがあります。

先頭に戻る

Code Workbook から以前削除したコードを復元するにはどうすればよいですか？

これらのトランスフォームがデータセットとしてビルドされていた場合は、そのデータセットのデータセットプレビューで比較機能を使用して、当時のコードを表示できます。そこから該当するトランスフォームをコピーして貼り付けることができます。残念ながら、このコードが中間トランスフォームに含まれていた場合は復元できません。

Code Workbook は、完全な git コミットおよび公開機能を備えた Code Repositories よりも、試行錯誤を重ねる作業に適したプラットフォームです。ほかに利用可能なブランチがある場合は、削除したトランスフォームがそこにあるか確認することを推奨します。

先頭に戻る

Spark 環境とカスタムライブラリ

必要な Python ライブラリが見つからない

デフォルトでは、Conda Forge ↗ で利用可能な Python パッケージはすべて、ワークブックのカスタム環境に追加できます。Python ライブラリが Conda Forge に含まれている場合は、環境をカスタマイズしてそのライブラリを直接含めることができます。

トラブルシューティングには、次の手順を実行します。

右上の環境 > 環境をカスタマイズを選択します。
必要なライブラリを検索し、自動（アップグレードが適用されますが、モジュールのアップグレードによって意図しない不具合が生じる可能性があります）またはそのライブラリの特定のバージョンを追加します。
Spark 環境を更新を選択します。

環境の再読み込みには時間がかかる場合があります。また、標準環境はプール内で起動済みの状態に保たれている一方、カスタム環境は毎回ゼロから起動されるため、一般にカスタム環境での作業は標準環境よりも遅くなります。

先頭に戻る

Python ライブラリのインポートに関する問題

Code Workbook ですでに利用可能なライブラリ以外のライブラリが必要になる場合があります。これらを利用可能なライブラリの一覧に追加することはできますが、手作業での対応が必要です。

トラブルシューティングには、次の手順を実行します。

ワークブックのカスタム Spark 環境の一覧で、その Python ライブラリが利用できないことを確認します。
一覧にない場合は、利用可能な別のライブラリで同じ機能を実現できないか検討します。
そのライブラリを含める必要がある場合は、Palantir サポートにお問い合わせください。
ライブラリが利用可能になったら、前述のトラブルシューティング手順を参照してライブラリを追加できます。

先頭に戻る

環境を作成できませんでした

ワークブックの環境を更新しようとすると、しばらく「Spark を待機中 / 環境を初期化中」と表示された後、「環境を作成できませんでした」というメッセージが表示され、エラーになります。

トラブルシューティングには、次の手順を実行します。

ワークブックの Spark 環境をカスタマイズする更新があったかどうかを確認します。更新があった場合は、追加されたカスタムライブラリを中心に調査します。
どのモジュールも特定のバージョンに固定されていないことを確認してください。一般に、モジュールは最新バージョンを使用することが推奨されます。
カスタムライブラリを削除し、Spark 環境が読み込まれるか確認します。
特定のライブラリが原因で Spark 環境を読み込めない場合は、Palantir サポートにエスカレーションしてください。

先頭に戻る

Python コードの実行に失敗する

このセクションでは、主に Code Workbook に固有の失敗について説明します。

詳細については、ビルドとチェックのエラーに関するガイダンスも参照できます。

先頭に戻る

Retryer エラー

パッケージのインポートや基本的なコマンドを実行すると、次のエラーが返されます。「com.github.rholder.retry.RetryException: Retrying failed to complete successfully after 3 attempts. at com.github.rholder.retry.Retryer.call(Retryer.java:174)」。Pandas を使用するワークブックでは、Code Workbook アプリケーションは変換の前に Spark データフレームを Pandas データフレームに変換します。この処理はドライバーのメモリーを大幅に多く消費するため、メモリー不足（OOM）を引き起こしている可能性があります。

トラブルシューティングには、次の手順を実行します。

変換セルが Pandas を使用していること、および Pandas を実行するコードでこの問題が発生していることを確認します。
この計算が Spark で実行可能な場合は、並列処理が可能でスケーラビリティも高い Spark を使用するようにコードを再構成することを強く推奨します。
この計算をドライバーで実行しなければならない場合の最終手段として、ドライバーのメモリーを増やすプロファイルの使用を推奨します。

先頭に戻る

データセットとして保存できませんでした

この問題はさまざまな理由で発生する可能性がありますが、最もよくあるのは、有効なスキーマを持つテーブルまたはデータフレームを返す処理に関するものです。以下の手順で発生しているエラーを特定できない場合は、ビルドとチェックのエラーに関するガイダンスを参照してください。

トラブルシューティングには、次の手順を実行します。

変換ノードがテーブルまたはデータフレームを返していることを確認してください。
テーブルまたはデータフレームが、Foundry にデータセットとして書き込むための基本要件を満たしていることを確認します。たとえば、次の要件があります。
1. 列が1つ以上あります。
2. すべての列名が有効です（スペースや無効な文字を含まないことなど）。
3. 重複する列名がありません。
この変換ノードをデータセットとして書き出せるはずだと確信している場合は、別の変換ノードを実行するか、新しい非常にシンプルな変換ノードを作成してみます。
1. これにより、局所的な問題（たとえば、その変換ノードで予期しないことが起きている）か、よりシステム全体に関わる問題（たとえば、変換ノード全般で Foundry への保存に失敗している）かを特定するのに役立ちます。
2. 局所的な問題の場合は、このテーブル / データフレームの作成に使用しているコードのデバッグを続けます。
3. システム全体に関わる問題の場合は、調査で得られた関連情報をすべて添えて、Palantir サポートに問題をエスカレーションしてください。

先頭に戻る

入力データセットのプレビューを更新してもワークブックが自動的に再計算されない

入力テーブルでテーブルプレビューを更新を選択すると、入力データセットの表示のみが更新され、Foundry 内の元のデータセットは自動的には更新されません。

トラブルシューティングには、次の手順を実行します。

入力テーブルでテーブルプレビューを更新を選択しても入力データセットが更新されない場合は、次の手順を実行します。
- これらのデータセットを開き、ビルドに失敗していないか確認します。
- 入力データセットのビルドに失敗している場合は、それがワークブックに更新された情報が表示されない原因です。ここからデバッグを続けます。
- 入力データセットが期待どおりにビルドされているにもかかわらず、Code Workbook のプレビューに表示される内容と一致しない場合は、次の手順を実行します。
  - Code Workbook から入力テーブルを削除し、再度追加してみます。
  - これで解決せず、プレビューと実際のテーブルにまだ相違がある場合は、Palantir サポートにお問い合わせください。
テーブルプレビューを更新を選択しても変換ノードが更新されない場合は、この操作は変換ノードに影響しないため、想定どおりの動作です。Code Workbook 内のすべての変換ノードを更新するには、run -> run all を選択します。これにより、ビルドの依存関係に従って Code Workbook 内のすべての変換ノードが実行されます。

先頭に戻る

このブランチを master にマージできない

このブランチをメインブランチにマージできない場合、最もよくある問題は、master ブランチが保護されていることです。マージの競合に関する問題も考えられますが、それについては別のセクションで説明します。

トラブルシューティングするには、次の手順を実行します。

ブランチが保護されているかどうかを確認します。
ブランチが保護されている場合は、所有者を特定し、このブランチのマージを依頼します。
- 対象のワークブックで、master のブランチ保護を有効にし、ブランチのマージを制限したいユーザーがワークブックに対して compass:edit 権限のみを持つようにしてください。
- Code Workbook には、内部的にブランチに関連する4つの権限レベルがあります。view、edit、maintain、manage です。デフォルトでは、compass:read は view に、compass:edit は edit に、compass:manage は maintain と manage に展開されます。
- ブランチの作成と親ブランチへのマージの準備には、常に edit 権限のみが必要です。保護されたブランチへのマージには maintain 権限が必要です。ブランチ保護の設定を変更するには manage 権限が必要です。
- 詳細については、ブランチの概要を参照してください。
ブランチが保護されていない場合は、master ブランチのコードと競合する、単純な追加ではないコード変更によって、マージの競合が発生しています。
- この場合は、このブランチを master にマージする前に、マージの競合を解決します。
- 詳細については、ブランチをマージするドキュメントを参照してください。
master ブランチが保護されておらず、マージの競合もないのに、このブランチを master にマージできない場合は、Palantir サポートにお問い合わせください。

ページの先頭に戻る

セルの計算を高速化する

入力データセットが（1000行 * 30列）+（100万行 * 30列）で、ウィンドウ処理や列の導出のステップが多い変換がある場合、計算を高速化するにはどうすればよいですか？

トラブルシューティングするには、次の手順を実行します。

1. リファクタリング

試行や迅速な反復作業のためには、コードを1つの大きなステップではなく、いくつかの小さなステップにリファクタリングするとよい場合がよくあります。

こうすると、まず上流のセルを計算し、データを Foundry に書き戻してから、後続のステップでこの計算済みデータを使用します。これらの初期ステップのロジックを変更せずに再計算を繰り返すと、余分な処理が発生します。

具体例：

workbook_1:
  cell_A:
    work_1 : input -> df_1
      (takes 4 iterations to get right): 4 * df_1
    work_2: df_1 -> df_2
      (takes 4 iterations to get right): 4 * df_2 + 4 * df_1
        = 4 df_2 + 4 df_1
    work_3: df_2 -> df_3
      (takes 4 iterations to get right): 4 * df_3 + 4 * df_2 + 4 * df_1
  total work:
    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

一方、work_1 と work_2 をそれぞれ別のセルに記述した場合、実行する処理は次のようになります。

workbook_2:
  cell_A:
    work_1: input -> df_1
      (takes 4 iterations to get right): 4 * df_1
  cell_B:
    work_2: df_1 -> df_2
      (takes 4 iterations to get right): 4 * df_2
  cell_C:
    work:3: df_2 -> df_3
      (takes 4 iterations to get right): 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. キャッシュ

「小さい」データセットは、ワークブックを選択してからアクション > Cache を選択してキャッシュしてください。

複数の入力データセットを追加する選択肢。

これにより、ワークブックの行がメモリー内に保持され、書き戻されたデータセットから取得する必要がなくなります。「小さい」かどうかの判断は、考慮すべきいくつかの要因によって変わりますが、Code Workbook は可能な限りキャッシュを試み、サイズが大きすぎる場合は警告します。

3. 関数呼び出し

可能な限りネイティブの PySpark メソッドを使用し、データに対して Python メソッドを直接使用すること（行ごとのループ処理や UDF の実行など）は避けてください。PySpark メソッドは、Scala で記述された基盤の Spark メソッドを呼び出し、Python ランタイムではなくデータに対して直接実行されます。Python をデータにアクセスするシステムとしてではなく、このシステムとやり取りするためのレイヤーとしてのみ使用すれば、Spark 自体のパフォーマンス上の利点をすべて活用できます。

4. ダウンサンプリング

大きな入力データセットから、元のデータを正確に反映したサンプルを独自に作成できる場合は、ロジックを完成させてデータ全体でテストする段階になるまで、変換の模擬入力として使用できます。

PySpark コードを1行でも記述する前に、100万行を超えるデータセットのダウンサンプリングとキャッシュを検討してください。データセットのサイズが大きいために構文バグの検出に時間がかかることを避け、作業をより迅速に進められる可能性があります。

5. 概要

適切なコードワークブックには、次のような特徴があります。

後で再利用する予定があり、何度も再計算する必要はない、特定の実体化を行う独立したコードのまとまり。
「小さい」サイズにダウンサンプリングされていること。
非常に高速に取得できるようにキャッシュされた「小さい」データセット。
高速な基盤の Spark ライブラリーを活用するネイティブの PySpark コードのみであること。