注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
ビルドとチェックのFAQ
以下は、ビルドとチェックに関するよくある質問です。
一般的な情報については、ビルドとヘルスチェックのドキュメンテーションをご覧ください。
- 一般的なエラーはどう解決すればいいですか？
- 長いまたは混乱するエラーメッセージをどのように理解すればいいですか？
- なぜ私のビルドは"リソース待ち"なのですか？
- なぜ私のビルドが実行するのに時間がかかるのですか？
- 不均衡（スキュー）な結合をどのように解決すればいいですか？
- エラーメッセージで参照される"shrinkwrap"は何を意味しますか？
- エラーメッセージで“PERMISSION_DENIED”を見る
- “待機中の入力依存関係が計算されるのを待つ”エラーメッセージをどのように解決すればよいですか？
- 私のCIジョブはリポジトリがデータセットを所有していないために失敗します
- なぜ私のチェックはタイムアウトで失敗しているのですか？
一般的なエラーはどう解決すればいいですか？
ビルドエラーのデバッグに困っている場合、以下の手順を考慮してみてください。
-
ビルドは以前に成功したことがありますか？もしそうなら、データセットを生成するロジックに変更を加えましたか？それらの変更を元に戻してみてください。もしビルドが成功すれば、問題は新しいロジックにある可能性が高いです。また、ビルドアプリケーションのデータセットパネルでログを選択し、ビルド履歴を確認することもできます。
-
基礎となるデータは最近変更されましたか？これはいくつかの方法で現れるかもしれません：
- データのスケールが劇的に増えている場合、パフォーマンスの低下や計算リソースの問題によるビルドの失敗が見られるかもしれません。
- 基礎となるデータのスキーマは何か変更されましたか？これは、特定のスキーマに依存するロジックがある場合にビルドの失敗を引き起こすことがよくあります。確認するには、ビルドのデータセットパネルで比較を選択し、以前のトランザクションとの差異を比較します。
- 失敗したデータセットの上流にあるデータセットのロジックは変更されましたか？これは、データスケールの増加やスキーマの変更という下流への影響を引き起こす可能性があります。
長いまたは混乱するエラーメッセージをどのように理解すればいいですか？
Foundryのエラーメッセージは長く、時には理解しづらいことがあります。行動を起こしにくいエラーメッセージに遭遇した場合、以下の手順を試してみてください。
-
よく、エラートレースの最も役立つ部分はキーフレーズによって先行されます。エラーメッセージの中で以下のフレーズを探して、トラブルシューティングに有益な指導を見つけることができるかもしれません。メッセージの重要な部分はしばしば下部に表示されます：
What went wrong:Caused by:Py4JJavaErrorUserCodeError
-
エラーが他のコンテキストが少ないErrorInstanceIDを参照している場合、問題をPalantirサポートにエスカレートしてください。 ErrorInstanceIDsはユーザーのロジックエラーに対しても表示されるため、まずこれが問題の原因である可能性を確認してください。
-
サポートに連絡する際には、必ず以下を含めてください：
- エラーメッセージ全文
- すでに行ったトラブルシューティングの手順
- エラーを経験した正確な時間（日付、時間、タイムゾーン）
なぜ私のビルドは"リソース待ち"なのですか？
ビルドが通常よりも長く"リソース待ち"の状態で停止しており、実行されていません。これは、ビルドを実行している時にプラットフォーム上での活動が増えたことが原因である可能性があります。この時に実行される多数のビルドがプラットフォーム上の利用可能なリソースを使用してしまい、他のビルドが終了してリソースが解放されるまでビルドがキューに入れられてしまう可能性があります。この動作は、Spark変換で説明されているSparkの実行モデルの副産物です。
トラブルシューティングを行うために、以下の手順を実行してみてください：
-
プラットフォームがあまり活発でない時間にビルドを実行してみて、パフォーマンスが改善するかどうかを確認してみてください。これにより、ビルドが他のジョブの後ろにキューに入るのを避けることができます。
-
ジョブをスケジューリングしている場合は、時間や深夜などの一般的な時間にジョブを実行するのを避けてください。
なぜ私のビルドが実行するのに時間がかかるのですか？
ビルドのパフォーマンスが時間とともに低下する原因は、次のいずれか、または複数の要素によるものである可能性があります：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'と'1'のテストデータ
a | 2 # 'a'と'2'のテストデータ
a | 3 # 'a'と'3'のテストデータ
a | 4 # 'a'と'4'のテストデータ
a | 5 # 'a'と'5'のテストデータ
-
以下のような問題を抱えた結合を持っているとします：
-
この結合は、ビルドが報告するいくつかのタスクが他のタスクよりもはるかに長くかかり、より多くのデータをシャッフル / スピルする可能性があるため、失敗する場合があります。これは、ユーザーのデータセットがスキューを起こしている可能性がある一つの指標です。
-
スキューを確認する別の方法は、Contourで各テーブルを開き、
something行でピボットし、行数を集約し、somethingで左と右のテーブルを結合し、集約列を掛け合わせることです。これにより、somethingのキーごとの行数が出力され、理想的には均等に分布していますが、スキューがある場合はソルテッド結合が必要であることを示します。 -
ユーザーのコードを以下のようなものに置き換えることを検討してください：
-
チューニング：
- どの要素を倍増させるかを選択する際には、推測に基づいて判断する必要があります。2 の累乗は、適切な推定値を見つけるための良い方法です：8、16、32 などです。
- 2つのデータセットを結合しようとしている場合、Contour を使用してそれらを調べることができます。結合するキーでヒストグラムを作成すると、最大のバケットが次に大きいバケットの X 倍のサイズになることがわかりますか？その場合、
explodeファクターは少なくとも X にしてください。 - 似たようなアプローチとして、アンソルトジョブが実行されている間に、エクゼキュータごとの行数を確認します。
-
次の点に注意してください：
- ジョインをソルト化する際に、オフバイワンエラーをしないようにしてください。そうすると、レコードの一部が失われることになります。
CEIL(RAND() * N)は 1 から N までの整数を生成します。FLOOR(RAND() * N)は 0 から N - 1 までの数値を生成します。ソルト化されたジョインで、正しい数値のセットを倍増させるようにしてください。
-
ソルト化によるオーバーヘッド
- ジョインのソルト化は、ビルドを必ずしも高速化するわけではありません。単に成功する可能性が高くなるだけです。
- 不必要にジョインをソルト化すると、パフォーマンスの低下が見られるようになるかもしれません。
エラーメッセージで言及されている「shrinkwrap」とは何ですか？
各リポジトリには、参照される各パスと、そのパスによって参照されるデータセットの一意の ID、およびそのデータセットの現在のパスを定義する「shrinkwrap」ファイルが含まれています。これは、データセットがフォルダ間で移動された場合などに便利です。リポジトリがそのデータセットを生成する際の shrinkwrap ファイルが更新されると、次回ビルドが実行されるときに、データセットが正しい場所でビルドされます。データセットの削除、名前の変更、移動などの理由で、shrinkwrap エラーが表示されることがあります。
トラブルシューティングのために、以下の検討事項と関連するアクションを確認してください：
-
特定のリポジトリの shrinkwrap ファイルを見つけるには：
- 画面左上付近の歯車アイコンを選択します。
- 隠しファイルとフォルダを表示をオンにします。
transforms-shrinkwrap.ymlファイルが以下のように表示されます。
-
リポジトリの shrinkwrap ファイルに記載されているデータセットが存在しなくなっている可能性があります。通常、shrinkwrap エラーは、どのデータセットが存在せず、リポジトリのどこで参照されているかを教えてくれます。
- リポジトリで参照されているデータセットがゴミ箱に移動されていないか確認し、必要に応じて復元します。
-
ブランチを反復処理している間に、
masterに変更がマージされ、リポジトリにファイルが追加され、shrinkwrap ファイルが更新された可能性があります。これを解決するには、以下の手順を実行します：transforms-shrinkwrap.ymlファイルに移動します。- ブランチを反復処理している間にリポジトリにマージされた変更を検索します。
- 自分の変更だけを受け入れるか、インカミングの変更だけを受け入れるか、または両方を受け入れるかを選択します。
- shrinkwrap ファイルを削除することもできます。チェックが実行されると、自動的に再生成されます。
エラーメッセージで「PERMISSION_DENIED」と表示される理由は？
ビルドを実行するには、トリガーするユーザーが必要な権限を持っている必要があります。具体的には、ユーザーは出力データセットの Editor である必要があります。これは、ビルドの実行は事実上、出力ファイルの編集を行うことになるからです。
特定のデータセットでどのような権限を持っているかを簡単に確認する方法は、Data Lineage でデータセットを開き、Permissions フィルターを有効にし、Resource Permissions を選択してノードの色を変更することです。
「Waiting for input dependencies to be computed」というエラーメッセージを解決する方法は？
このエラーは、データセットのビルドが失敗し、そのスケジュールが上流のデータセットのビルドが失敗したためにキャンセルされた場合に発生します。
トラブルシューティングのために、次の手順を実行してください：
- 失敗したビルドのビルドレポートに移動します。
- このビルドで最初に失敗したデータセットを探します。
- このエラーメッセージを解決して、ビルドを再実行します。
リポジトリがデータセットを所有していないため、CIジョブが失敗する
ビルドしようとしているデータセットは、別のリポジトリによって制御されていると考えています。データセットがどのリポジトリによって制御されているかは、データセットプレビューページの Details タブの Job spec セクションの sourceProvenance ブロックで確認できます。これは、複数のリポジトリが同じ出力データセットを作成する場合に発生します。
トラブルシューティングのために、次の手順を実行してください：
- データセットの所有権を現在のリポジトリに移動させたい場合：
- データセットの既存のジョブスペックを削除します。これを行うには、データセットを開き、Details > Job spec に移動して Edit > Delete を選択します。
- 現在のリポジトリから CI ビルドを再度トリガーします。
- 他のリポジトリからデータセットのソースファイルを削除して、将来の混乱を防ぎます。
- データセットの所有者を別のリポジトリ（データセットが最初に作成されたリポジトリ）のままにしたい場合：
- 現在のリポジトリでデータセットのソースファイルを削除します。
なぜチェックがタイムアウトで失敗するのですか？
タイムアウトでチェックが失敗する原因はさまざまですが、以下のような一般的な手順を実行することで、問題が解決することがよくあります：
- CIチェックをもう一度実行してみてください。同じエラーで継続的に失敗しますか？
- リポジトリをアップグレードしてから、CIチェックをもう一度実行してみてください。同じエラーで失敗しますか？
- CIチェックがまだ失敗している場合は、フォルダ構造の上部にある歯車アイコンを選択し、隠しファイルを表示を選択します。
ci.ymlに—refresh-dependenciesという行を追加します。