ObservabilityHealth checksビルドとチェックに関するFAQ

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

ビルドとチェックに関する FAQ

ビルドとチェックに関するよくある質問を以下に示します。

一般的な情報については、ビルドとヘルスチェックのドキュメントを参照してください。

一般的なエラーを解決するにはどうすればよいですか？
長い、またはわかりにくいエラーメッセージを理解するにはどうすればよいですか？
ビルドが「リソース待ち」になるのはなぜですか？
ビルドの実行に以前より時間がかかるのはなぜですか？
不均衡な（偏りのある）結合を解決するにはどうすればよいですか？
エラーメッセージに出てくる「shrinkwrap」とは何ですか？
エラーメッセージに「PERMISSION_DENIED」が表示される
「入力の依存関係の計算待ち」というエラーメッセージを解決するにはどうすればよいですか？
リポジトリがデータセットを所有していないため CI ジョブが失敗する
チェックがタイムアウトで失敗するのはなぜですか？

一般的なエラーを解決するにはどうすればよいですか？

ビルドエラーのデバッグが難しい場合は、以下の手順を検討してください。

ビルドが成功したことはありますか？成功したことがある場合、データセットを生成するロジックを変更しましたか？その変更を元に戻してみてください。ビルドに成功する場合は、新しいロジックが問題の原因である可能性が高いと判断できます。また、Builds アプリケーションのデータセットペインでログを選択して、ビルド履歴を確認することもできます。
元のデータが最近変更されましたか？その影響は、以下のような形で現れることがあります。
- データ規模が大幅に増加した場合、計算リソースに関する問題により、パフォーマンスの低下やビルドの失敗が発生することがあります。
- 元のデータのスキーマに何らかの変更がありましたか？特定のスキーマに依存するロジックがある場合、これがビルドの失敗を引き起こすことがよくあります。確認するには、Builds のデータセットペインで比較を選択して、以前のトランザクションとの差分を比較します。
- ビルドに失敗しているデータセットの上流にあるデータセットのロジックが変更されましたか？これにより、データ規模の増加やスキーマの変更が下流に影響することがあります。

ページの先頭に戻る

長い、またはわかりにくいエラーメッセージを理解するにはどうすればよいですか？

Foundry のエラーメッセージは長く、理解しにくいことがあります。対処方法がわかりにくいエラーメッセージが表示された場合は、以下の手順を試してください。

エラートレースで最も役立つ情報の前には、特定のフレーズが記載されていることがよくあります。トラブルシューティングに役立つ手がかりを見つけるため、エラーメッセージ内で以下のフレーズを探します。メッセージの重要な部分は、下部に表示されることがよくあります。
- What went wrong:
- Caused by:
- Py4JJavaError
- UserCodeError
エラーに ErrorInstanceID が記載されていて、ほかの情報がほとんどない場合は、Palantir サポートに問題をエスカレーションしてください。ErrorInstanceID はユーザーのロジックエラーでも表示されるため、まず、それが問題の原因である可能性がないか確認してください。
サポートに問い合わせる際は、必ず以下を含めてください。
- 表示されたエラーメッセージの全文
- すでに実施したトラブルシューティングの手順
- エラーが発生した正確な日時（日付、時刻、タイムゾーン）

ページの先頭に戻る

ビルドが「リソース待ち」になるのはなぜですか？

ビルドが通常より長く「リソース待ち」の状態のままで、実行されていません。これは、ビルドを実行しているときにプラットフォーム上のアクティビティが増加していることが原因である可能性があります。そのときに実行されている多数のビルドが、プラットフォーム上の利用可能なリソースを使い切っている場合、ほかのビルドが完了してリソースが解放されるまで、ビルドはキューに入れられます。この動作は、Spark トランスフォームで説明している Spark 実行モデルに伴うものです。

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

プラットフォームのアクティビティが少ない時間帯にビルドを実行し、パフォーマンスが改善するか確認します。これにより、ほかのジョブの後ろでビルドがキュー待ちになることを避けやすくなります。
ジョブをスケジュールする場合は、毎正時や午前0時など、よく使われる時間帯にジョブを実行しないようにします。

ページの先頭に戻る

ビルドの実行に以前より時間がかかるのはなぜですか？

ビルドのパフォーマンスが時間とともに低下する原因として、次の1つ以上が考えられます。1）トランスフォームのロジックの変更、2）入力データの規模の変化、3）ビルド時のクラスターの計算負荷の増加。

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

トランスフォームのロジックを確認します。このビルドを最後に実行してから、何が変わりましたか？ロジックのわずかな違いでも、ビルド時間に差が生じることがあります。
入力データセットのデータ規模を確認します。上流のデータセットのサイズが大幅に増加している場合、パイプラインの下流にあるビルドのパフォーマンスが低下することがあります。

ページの先頭に戻る

不均衡（偏りのある）結合を解消するにはどうすればよいですか？

キーごとのエントリが多い大きな左側のテーブルと、キーごとのエントリが少ない小さな右側のテーブルを含む結合は、パーティション間でデータを均等に分散するソルト付き結合に最適です。

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

ソルト付き結合は Spark で、キーごとのエントリが多いテーブルを小さな部分に分割すると同時に、小さなテーブルを同じ数のコピーに展開することで機能します。これにより、通常の結合と同じサイズの出力になりますが、大きなテーブルのタスクサイズが小さくなり、OOM エラーのリスクが低下します。
結合にソルトを適用するには、左側のテーブルに0から N までの乱数の列を追加し、右側のテーブルのコピーを N 個作成します。この新しい乱数列を結合に追加すると、最大のバケットのサイズが元の1/Nになります。
鍵となるのは EXPLODE 関数です。EXPLODE は直積です：SELECT 'a' AS test, EXPLODE(ARRAY(1,2,3,4,5)) AS dummy2
これにより、次の結果になります。

 test | test2
----------------
  a     |  1
  a     |  2
  a     |  3
  a     |  4
  a     |  5

次のように、正しく動作しない結合があるとします。

Copied!1
2
3
4
5
6
7
8
SELECT
left.*, right.*
FROM
`/foo/bar/baz` AS left
JOIN
`/foo2/bar2/baz2` AS right
ON
  left.something = right.something

この結合は失敗することがあります。その場合、ビルドレポートには、一部のタスクがほかのタスクよりも大幅に時間がかかり、より多くのデータをシャッフルまたはスピルしていることが示されます。これは、データセットに偏りが生じている可能性を示す兆候の1つです。
偏りを確認するもう1つの方法は、各テーブルを Contour で開き、something 列でピボットして行数を集計し、左側と右側のテーブルを something で結合して、集計した列を乗算することです。これにより、something のキーごとの行数が出力されます。理想的には均等に分散しますが、偏りがある場合はソルト付き結合が必要であることを示します。
コードを次のようなものに置き換えることを検討してください。

Copied!1
2
3
4
5
6
7
8
SELECT
    left.*, right.*
  FROM
    (SELECT *, FLOOR(RAND() * 8) AS salt FROM `/foo/bar/baz`) AS left
    JOIN
    (SELECT *, EXPLODE(ARRAY(0,1,2,3,4,5,6,7)) AS salt FROM `/foo2/bar2/baz2`) AS right
    ON
      left.something = right.something AND left.salt = right.salt

チューニング：
- 展開する倍率を選択するには、根拠に基づいて推定する必要があります。適切な値を見つけるには、8、16、32などの2の累乗を試すとよいでしょう。
- 結合しようとしている2個のデータセットを Contour で調べることができます。結合キーのヒストグラムを作成すると、最大のバケットが2番目に大きいバケットの X 倍のサイズになっていますか？explode の倍率を少なくとも X にします。
- 同様の方法として、ソルトを適用していないジョブの実行中に、エグゼキューターごとの行数を確認することもできます。
次の点に注意してください。
- 結合にソルトを適用するときは、オフバイワンエラーが発生しないようにしてください。このエラーがあると、レコードの一部が失われます。
- CEIL(RAND() * N) は1から N までの整数を返します。FLOOR(RAND() * N) は0から N − 1までの数値を返します。ソルト付き結合では、正しい数値の集合を展開してください。
ソルト適用によるオーバーヘッド
- 結合にソルトを適用しても、必ずしもビルドが速くなるわけではありません。成功する可能性が高くなるだけです。
- 不必要に結合にソルトを適用すると、パフォーマンスが低下し始める場合があります。

先頭に戻る

エラーメッセージで言及される「shrinkwrap」とは何ですか？

各リポジトリには「shrinkwrap」ファイルが含まれており、参照されている各パス、そのパスが参照するデータセットの一意の ID、およびそのデータセットの現在のパスの対応関係を定義します。これは、たとえばデータセットがフォルダー間で移動されたときに役立ちます。そのデータセットを生成するリポジトリの shrinkwrap ファイルが更新され、次回ビルドが実行されると、データセットは正しい場所にビルドされます。データセットの削除、名前の変更、場所の変更など、いくつかの理由で shrinkwrap エラーが表示されることがあります。

トラブルシューティングするには、次の考慮事項と関連する対応を確認します。

特定のリポジトリの shrinkwrap ファイルを見つけるには、次の手順を実行します。
- 画面の左上付近にある歯車アイコンを選択します。
- 隠しファイル・フォルダを表示をオンにします。
- 次のように transforms-shrinkwrap.yml ファイルが表示されるはずです。
リポジトリの shrinkwrap ファイルで参照されているデータセットが、もう存在しない可能性があります。通常、shrinkwrap エラーには、存在しないデータセットと、それらがリポジトリ内のどこで参照されているかが示されます。
- リポジトリで参照されているデータセットがゴミ箱に移動されていないか確認し、復元します。
このブランチで作業を繰り返している間に、ファイルをリポジトリに追加し、shrinkwrap ファイルを更新する変更が master にマージされた可能性があります。これを解決するには、次の手順を実行します。
- transforms-shrinkwrap.yml ファイルに移動します。
- このブランチで作業を繰り返している間にリポジトリにマージされた変更を探します。
- ご自身の変更のみ、取り込む変更のみ、または両方を受け入れるかを選択します。
- shrinkwrap ファイルを削除することもできます。その場合、チェックの実行時に自動的に再生成されます。

先頭に戻る

エラーメッセージに「PERMISSION_DENIED」が表示される

ビルドを実行するには、ビルドをトリガーするユーザーに必要な権限が付与されている必要があります。具体的には、ビルドの実行は実質的に出力ファイルの編集にあたるため、ユーザーは出力データセットの編集者である必要があります。

特定のデータセットに対する権限を簡単に確認するには、Data Lineage でそのデータセットを開き、権限フィルターを有効にして、リソースの権限を選択し、ノードを色分けします。

先頭に戻る

「Waiting for input dependencies to be computed」エラーメッセージを解決するにはどうすればよいですか？

このエラーは、上流データセットのビルドに失敗したために、対象のデータセットをビルドしていたスケジュールがキャンセルされ、そのデータセットのビルドに失敗したときに発生します。

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

失敗したビルドのビルドレポートに移動します。
このビルドで最初に失敗したデータセットを探します。
このエラーメッセージの解決を試み、ビルドを再実行します。

先頭に戻る

リポジトリがデータセットを所有していないため CI ジョブが失敗する

ビルドしようとしているデータセットは、別のリポジトリによって管理されていると認識しています。データセットがどのリポジトリによって管理されているかは、データセットプレビューのページの詳細タブにある、ジョブスペックセクションの sourceProvenance ブロックで確認できます。これは、複数のリポジトリが同じ出力データセットを作成しているときに発生します。

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

データセットの所有権を現在のリポジトリに移行する場合：
1. データセットの既存の Job Spec を削除します。これを行うには、データセットを開き、詳細 > ジョブスペックに移動して、編集 > 削除を選択します。
2. 現在のリポジトリから CI ビルドを再度トリガーします。
3. 今後の混乱を防ぐため、もう一方のリポジトリからデータセットのソースファイルを削除します。
データセットの所有者をもう一方のリポジトリ（データセットが最初に作成されたリポジトリ）のまま保持する場合：
- 現在のリポジトリにあるデータセットのソースファイルを削除します。

先頭に戻る

チェックがタイムアウトで失敗するのはなぜですか？

チェックがタイムアウトで失敗する理由はさまざまですが、次のような一般的な手順で解消できることがよくあります。

CI チェックの再実行を試します。同じエラーで毎回失敗しますか？
リポジトリをアップグレードしてから、CI チェックの再実行を試します。同じエラーで失敗しますか？
CI チェックがまだ失敗する場合は、フォルダー構造の上部にある歯車アイコンを選択し、隠しファイルを表示を選択します。ci.yml に —refresh-dependencies という行を追加します。

先頭に戻る

←

PREVIOUSMarketplace製品へのヘルスチェックの追加

NEXTチェックのリファレンス

→