注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
Foundry は、内部的に Foundry 内に格納されているリソースメタデータを収集します。Linter は、さまざまなメタデータストアからメタデータを取得して組み合わせます。Linter ルールとは、リソースメタデータに対して実行されるロジックで、リソースが論理テストに合格するかどうかを判断します。リソースがテストに失敗すると、Linter はそのリソースをどのように変更すれば論理の結果が変わるかという推奨事項を提供します。
各 Linter ルールは、モードに属します。
リソース節約モードでは、各ルールは推奨事項に従った場合の節約量を見積もる方法論に従います。この方法論は優先順位付けをサポートしており、多くの状況で有効な仮定ですが、ユーザーのユースケースには当てはまらない場合があります。リソース使用量の削減を検証するには、リソース管理アプリケーションを使用してください。
ロジック: スケジュールに abort on failure が有効になっていません。
理由: abort on failure が有効になっていない場合、スケジュール内に失敗したデータセットがある場合でも、監視はスケジュールが終了するまで待機します。
推奨事項: abort on failure モードを有効にします。この機能により、監視が失敗をより早く検出し、迅速な対策が可能になります。
ロジック: 過去 7 日間で、このリソースのジョブがアクティブに実行されている時間の割合が 70% を超えています。これには、短い期間で頻繁にトリガーされる多くのジョブや、長い期間をかけて実行される少数のジョブが含まれる可能性があります。
理由: 継続的にビルドされるデータセットは、使用量の大きな原因となります。これらのリソースで頻度を減らすことやパフォーマンスを向上させることで、大幅な節約が可能になります。
推奨事項: ビルド頻度を減らすことを検討してください。
節約見積もり方法論: 前月の総リソース使用量（例えば、6月21日から計算する場合、このリソースの消費量は5月1日から5月31日までの間です）。
ロジック: トランスフォームの入力データセットと出力データセットの統計が、ロジックが適用されていないことを示しています。
理由: データセットを Spark に読み込んでから書き戻す際にリソースが使用されます。これは、計算をスキップして Foundry のビューを使用することで回避できます。
推奨事項: このデータセットを Foundry のビューに変更することで、パイプラインの実行時間、データの重複、およびコストを削減できます。
節約見積もり方法論: 前月の総リソース使用量（例えば、6月21日から計算する場合、このリソースの消費量は5月1日から5月31日までの間です）。
ロジック: トランスフォームは、サイズが小さい（300Mb 以下）データセットを使用しています。
理由: デフォルトでは、Foundry はスケーリングと速度を容易にするために分散コンピューティングを使用します。これは、ローカルコンピューティングよりもリソースを多く使用します。データセットのサイズが小さく、今後もそうである場合は、ローカル実行（分散ではない）を使用して、トランスフォームを実行するのに必要なリソースを減らす必要があります。
推奨事項: このトランスフォーム、またはリポジトリ内の入力データセットと出力データセットが閾値サイズよりも小さいすべてのトランスフォームでローカル実行を有効にします。これは、KUBERNETES_NO_EXECUTORS などの特定の設定を使用して、Spark プロファイル を有効にすることで実現できます。
節約見積もり方法論: 前月の総リソース使用量（例えば、6月21日から計算する場合、このリソースの消費量は5月1日から5月31日までの間です）が、コア変更の比率で割られます。たとえば、トランスフォームが以前に 5 つのコア（2 つのエグゼキュータと 1 つのドライバが 1 つのドライブコアを持っているエグゼキュータごとに 2 つのコア）を使用していて、ローカルで実行することで 1 つのコアを使用できる場合、見積もり節約額は総リソース使用量に 0.8 を掛けたものです（（5-1）/ 5）。
ロジック: データセットは SNAPSHOT としてビルドされますが、新しいデータを純粋に追加するインクリメンタルデータセットの少なくとも 1 つの直接の下流にあります。
理由: SNAPSHOT トランザクションは、すべての履歴データを処理します。インクリメンタルトランザクションは、新しいデータのみを処理し、前の値に結果を追加します。インクリメンタルトランザクションに切り替えることで、結果を得るために必要なリソースを大幅に削減できます。
推奨事項: このデータセットをインクリメンタルトランスフォームに変換してコンピューティングコストを節約することを検討してください。データセットがインクリメンタルに実行されるように設定されている場合は、データセットが頻繁に SNAPSHOT としてビルドされる理由を理解し、対処してください。
節約見積もり方法論: 前月の総リソース使用量（例えば、6月21日から計算する場合、このリソースの消費量は5月1日から5月31日までの間です）が、入力サイズの合計（入力がインクリメンタルである場合はインクリメンタルサイズ）と入力サイズの合計（入力のインクリメンタル性に関係なく）の比率によって掛けられます。これにより、このデータセットがインクリメンタルに実行された場合の推定リソース使用量が得られます。したがって、この推奨事項の見積もり節約額は、過去 1 ヶ月のリソース使用量とこのリソース使用量見積もりとの差額です。
ロジック: データセットの JobSpec コミットが、リポジトリの master ブランチの最新コミットと異なります。
理由: 修正されない場合、データセットのビルドはリポジトリの最新のロジックを反映していません。
推奨事項: データセットをスケジュールから削除するか、master ブランチでそのトランスフォームのロジックを再コミットしてください。
ロジック: Contour ダッシュボードは、開始時のインクリメンタルデータセットのいずれかにデータセット投影がありません。
理由: ダッシュボードをより速く表示するために投影を使用し、継続的なフィルター処理の計算を節約します。
推奨事項: Contour ダッシュボードを確認して、使用状況、重要度、フィルター処理された列の順序を確認してください。Foundry のエンロールメントで データセット投影 を有効にし、フラグ付き列の順序でフィルタリングに最適化された基礎となる Foundry データセットに投影を追加します。投影が定期的に更新されるようにスケジュールを設定してください。これにより、データセット投影を活用して Contour ダッシュボードがより速く表示されるようになります。
ロジック: データセットはゴミ箱に入っています。
理由: データセットがゴミ箱に入れられていても、スケジュールはそのデータセットをビルドしようとしています。
推奨事項: データセットがまだスケジュールにある理由を調査し、ゴミ箱から削除するかスケジュールを更新してください。
ロジック: スケジュールはデータ接続の受け入れスケジュールではないのに、強制ビルド設定を使用しています。
理由: Foundry は、入力データフロー全体のトランザクション変更を追跡するシステムを持っており、入力が変更されない場合は計算をスキップできます。強制ビルド設定は、入力トランザクション分析の結果に関係なく、トランスフォームが実行されるようにするため、同じ結果を繰り返し生成する可能性のある不要なジョブが発生します。
推奨事項: トランスフォームに未追跡の外部依存関係（API コールなど）があるかどうか確認してください。依存関係が見つからない場合は、スケジュールから設定を削除してください。
節約見積もり方法論: スケジュール内のデータセットの前月の総リソース使用量（例えば、6月21日から計算する場合、このリソースの消費量は5月1日から5月31日までの間です）が、ジョブ入力変更のパーセンテージで掛けられます。データセットのジョブ入力変更のパーセンテージは、過去 1 週間で更新された入力を持つジョブの数を、過去 1 週間のトータルジョブ数で割ったものです（前月の消費データを取得した期間ではありません）。
ロジック: スケジュールに exceeded duration モードが有効になっていません。
理由: 期間が設定されている場合、このモードは、ネットワークがフレーク状態の間にデータ接続ビルドが無限に実行されるのを防ぎ、ダウンストリームの停止を防ぎます。
推奨事項: スケジュールで exceeded duration mode を有効にしてください。
ロジック: スケジュールはデータセットをビルドしません。
理由: スケジュールは、リソースの無駄遣いであり、監視にノイズを発生させる可能性があります。
推奨事項: スケジュールが有用かどうかを調査し、削除するか監視範囲から外すかを決定してください。
ロジック： データセットがインクリメンタルに更新され、サブオプティマルなパーティションサイズが存在します。つまり、平均パーティションサイズが大きすぎるか小さすぎます。
理由： 最適なパーティションサイズは異なります。パーティションサイズが小さすぎる場合、各パーティションに伴うオーバーヘッドが処理時間を支配します。パーティションが大きすぎる場合、メモリ管理操作が実行時間を増加させ、またはデータセットからデータを読み込む下流のデータセットや分析でのメモリ不足の問題が発生し、ジョブの期間やリソースの使用が過剰になります。
推奨事項： パーティションサイズをチェックするロジックを含め、データセット内のデータをより良いパーティションサイズで保存することをお勧めします。APPENDデータセットの場合、出力データセットにすでに存在するファイルの数を確認します。データセットが Python または Java のトランスフォームロジックファイルでバックアップされていない場合、プロジェクションを作成することでこの問題を解決できます。フィルター処理するためのプロジェクションを最適化するだけで、所望のコンパクションを達成できますが、下流のクエリプランによって、結合の最適化による追加の利点が得られる場合があります。
節約見積もり方法： 最近のジョブでファイルの読み込みに費やした時間の比率が、そのサイズのデータセットが通常どれくらいの時間がかかるかの見積もりと比較されます。これは、過去1週間でこのデータセットを読み込む下流変換の回数と掛け合わされます。
ロジック： データセットは、静的割り当てを使用しています。これは、固定数のエグゼキューターを使用する Spark 設定です。最近のジョブで実行されるタスクの並列性が閾値（デフォルト：70%）を下回っています。
理由： リソースを静的にプロビジョニングすると、並列性が低下することがあります。リソースがアイドル状態になり、他のタスクが終了するのを待ってから使用されます。ダイナミック割り当て Spark 設定を使用すると、アイドル状態のエグゼキューターがこのジョブ専用に予約されなくなり、タスク並列性が向上します。
推奨事項： トランスフォームに DYNAMIC_ALLOCATION_MAX_N Spark プロファイル を適用して、ダイナミック割り当てを使用することをお勧めします。
節約見積もり方法： 完璧な並列性が達成された場合の節約見積もりとして、計算された並列性を前カレンダー月のリソース消費と掛け合わせます（例：6月21日から計算する場合、提供される値は5月1日から5月31日の間のこのリソースの消費です）。たとえば、データセットの最近の並列性が70%の場合、先月のリソース使用量の推定30%が節約されることになります。
Incremental append dataset poorly partitioned と同様ですが、replace インクリメンタル変換出力書き込みモードを使用するデータセットの場合です。UPDATEトランザクションがファイルを純粋に追加するだけでなく、既存のファイルを変更または削除する場合は、データセットプロジェクションの再計算が必要になるため、このケースではデータプロジェクションを修正として使用しないことをお勧めします。インクリメンタル Python Transforms モードについては、こちらをご覧ください。
ロジック： トランスフォームは、コアあたり7.5 GB のデフォルトよりも高いメモリとコアの比率を使用しています。
理由： デフォルトのメモリとコアの比率を超えると、コストが増加します。多くのユーザーは、メモリに関連しない問題や、より安価な手段で解決できる問題に対応するために、エグゼキューターのメモリを増やします。デフォルトのメモリとコアの比率を使用してトランスフォームを実行することで、リソースの節約が見つかることがよくあります。ただし、一部の場合（行の爆発など）では、メモリ不足のエラーやエグゼキューター間の過剰なシャッフルを回避するために、エグゼキューターごとのメモリを増やす必要があります。このような場合、エグゼキューターのコア数をエグゼキューターのメモリプロファイルに合わせて増やすことで、ビルド時間が短縮され、コストが大幅に削減されることがあります。これにより、並列性が向上し、パーティションサイズが縮小されます。
推奨事項： EXECUTOR_MEMORY_X Spark プロファイルを EXECUTOR_CORES_X Spark プロファイルに合わせることで、メモリとコアの比率を減らすことをお勧めします。これによってメモリの問題が発生した場合は、問題のあるステージを特定するために Spark グラフを調べてください。データセット読み取りステージの問題がある場合は、各エグゼキューターに小さなパーティションサイズを供給するために、入力データセットのパーティション数を増やしてください。シャッフルステージの問題がある場合は、シャッフルパーティション設定よりもタスクが少ない場合は、アダプティブ Spark 割り当てを無効にする（ADAPTATIVE_DISABLED Spark プロファイル）か、シャッフルサイズを増やす（SHUFFLE_PARTITIONS_LARGE Spark プロファイル）ことを検討して、小さなタスクをエグゼキューターに供給してください。Spark プロファイルについては、こちらをご覧ください。
節約見積もり方法： 直近のカレンダー月に検出されたものではなく、デフォルトのコアとメモリの比率を使用した場合のリソース使用量の見積もりが作成されます。その値から観測されたリソース使用量を引いて、節約される見積もりを算出します。
Master ブランチが保護されているロジック： コードリポジトリの master ブランチが保護されていません。
理由： master ブランチを保護することは、変更の追跡、バージョン管理、誤った変更からの保護のために重要です。
推奨事項： リポジトリ設定で master ブランチを保護ブランチに追加します。
ロジック： データセットには Code Workbook JobSpec があります。
理由： 本番環境のデータセットやスケジュールされたデータセットは、可能な限り Code Workbook でビルドされず、Pipeline Builder や Code Repositories など、本番環境のパイプラインビルド用アプリケーションに移行する必要があります。
推奨事項： データセットをスケジュールする必要がある場合は、Pipeline Builder または Code Repositories にロジックを移行してください。
ロジック： スケジュールは、別のスケジュールによってもビルドされるデータセットをビルドします。
理由： 同じデータセットが異なるスケジュールによってビルドされるため、計算の無駄、キューイング、信頼性の低いレイテンシが発生する可能性があります。
推奨事項： スケジュールのビルドアクションを変更して、重複を排除します。
ロジック： スケジュールはプロジェクトスコープではありません。
推奨事項： スケジュールをスコープトークンモードで実行するように変更します。デフォルトでは、スコープはビルドされたデータセットのプロジェクトRIDです。
ロジック： プロジェクトには500以上のフォルダーが含まれているため、違反を表示するスイープスケジュールを配置することができません。
推奨事項： このプロジェクトを500未満のフォルダーを持つ小さなプロジェクトに分割し、結果として得られる小さなプロジェクトをリントしてください。
ロジック： コードリポジトリには、マージできないリポジトリアップグレード PR が開いています。
理由： リポジトリのアップグレードは、パイプラインが最新の機能を引き続き使用できるようにするために不可欠です。最新でないリポジトリは、時間の経過とともにパイプラインの失敗を引き起こすことがあり、ワークフローの安定性に影響を与え、計算の無駄が発生します。
推奨事項： PR がマージされない理由を調べ、アップグレードを修正してください。
ロジック： スケジュールにはリトライが有効になっていません。
理由： 環境設定の問題によって引き起こされる失敗など、通常は2回目の実行で表示されない失敗があります。スケジュールにリトライがないと、ビルドできたはずのデータセットがビルドされないことがあります。
推奨事項： リトライを有効にします。リトライ試行を3回に設定することをお勧めします。
ロジック： データセットには Contour JobSpec があります。
理由： 本番環境のデータセットやスケジュールされたデータセットは、Contour でビルドされるべきではなく、パイプラインビルド用のアプリケーション（Pipeline Builder や Code Repositories など）に移行する必要があります。
推奨事項： データセットをスケジュールする必要がある場合は、Pipeline Builder または Code Repositories にロジックを移行してください。
節約見積もり方法： 過去30日間のブランチで失敗したデータセットの計算コストの合計。
ロジック： 過去30日間、スケジュールは成功していません。その間にビルドに失敗したデータセットがリストされています。
理由： 各実行で、スケジュールは過去30日間で一度も成功していないデータセットを再構築しようとし、リソースの無駄が発生しています。
推奨事項： スケジュールを一時停止し、失敗したデータセットに対して修正を適用するか、スケジュールから失敗したデータセットを削除してください。
節約見積もり方法： 過去30日間のブランチで失敗したデータセットの計算コストの合計。
ロジック： スケジュールの所有者はスケジュールを表示、編集、またはプレビューする権限を持っていませんが、スケジュールは解決されています。
推奨： スケジュールがプロジェクトスコープの場合は、スケジュールの所有者を許可されたユーザーに切り替えてください。これは自動的に修正できます。
ロジック： スケジュールは解決できず、正しく動作していません。
推奨： スケジュールの詳細を埋め、スケジュールの所有権を取得するか、スケジュールを削除してください。スケジュールがプロジェクトスコープでない場合は、スケジュールを解決するための十分な権限があり、スケジュールの所有者を変更できることを確認してください。
ロジック： スケジュールには、リントされたプロジェクトスコープ内でビルド可能な、未スケジュールの、Fusion を利用しない入力データセットがあります。
推奨： フラグが付けられたデータセットをスケジュールするか、そのコードとJobSpecを削除して生データにします。データセットがJobSpecを持つ必要があり、スケジュールする必要はない（例：任意のスナップショット）場合は、例外を追加してください。
ロジック： スケジュールは、スケジュールによってビルドされるどのデータセットの入力でもないデータセットを入力として指定します。
なぜ： この問題は、通常、除外されたデータセットのために発生します。
推奨： 除外されたデータセットを修正するか、接続ビルドアクションから入力を削除します。
ロジック： スケジュールに名前がありません。
推奨： ビルド中のデータセットの名前とパスに基づいて名前を生成します。これは自動的に生成できます。
ロジック： スケジュールに説明がありません。
推奨： スケジュールの目的と機能に基づいて説明を入力してください。
ロジック： スケジュールには、ビルドアクションに対して無効なスコープがあります。スケジュールによってビルドされるべきデータセットをスコープが除外しています。
推奨： スケジュールを編集し、スケジュールによってビルドされるべきすべてのデータセットを含むプロジェクトスコープを修正します。これが不可能な場合は、スケジュールのプロジェクトスコープを削除してください。
ロジック： スケジュールが master ではないブランチで実行されています。
なぜ： master ブランチは、Foundry 全体でデータの正規版として使用されています。しばしば、スケジュールはブランチ上で一貫して実行する必要があり、データの代替バージョンを提供するか、代替ロジックを試すためです。この動作は、ブランチ上で設定されたスケジュールが必要以上に長く実行され続ける多数のスケジュールを生み出す可能性があります。
推奨： ブランチ上のスケジュールが必要かどうかを理解し、必要でなければスケジュールを一時停止または削除を検討してください。また、master ブランチ上でないスケジュールのトリガー頻度を減らすことも検討してください。例えば、スケジュールが master 上で1日に1回実行される場合、non-master ブランチは週に1回実行すれば同じ結果を得られるかもしれません。
節約見積もり方法： 過去1ヶ月間にこのブランチ上で実行されたジョブの数と、過去1ヶ月間に master 上で実行されたジョブの数の比率が、このスケジュールによってビルドされたデータセットのリソース使用量を再正規化するために使用されます。ブランチで再正規化したこの使用量を合計すると、節約見積もりが得られます。
ロジック： スケジュールの解決した出力の一部がターゲットとしてマークされていない、またはその逆です。
推奨： ターゲットが実際のスケジュールの出力と一致するようにスケジュールを更新します。
ロジック： スケジュールはデータセットをトリガーとして宣言しますが、入力としては宣言しません。
推奨： 接続ビルドアクションを修正して、データセットをトリガーから削除するか、入力に追加します。
ロジック： スケジュールはデータセットをトリガーとして宣言し、それがビルドされています。
推奨： ビルドアクションを修正して、問題のあるデータセットをトリガーまたは出力データセットから削除します。
ロジック： スケジュール内のすべてのリソースのデータフローがチェックされ、最近の下流の使用がスケジュールされたパイプライン、Contour などのインタラクティブな分析、またはオブジェクトストレージの目的地で行われたかどうかが判断されます。
なぜ： Foundry は時間と共に変化します、そして決定を下すために結果を計算するリソースを使うことは有益ではありません。未使用のパイプラインをオフにすることは、ユーザーの目標を達成するために積極的に使用されている結果の計算にのみリソースを使うように Foundry インスタンスを確保する方法です。
推奨： 未使用のスケジュールは一時停止されます。推奨は、コンピュートを削減する可能性があるスケジュールの未使用のサブセットを時折明らかにします。
節約見積もり方法： 過去のカレンダー月間にスケジュール内の未使用リソースのリソース使用量の合計。
ロジック： スケジュールには複数のトリガー条件があります。
なぜ： スケジュールは、新しいデータが利用可能になるたびに実行されるように作成されることがよくあります。例えば、スケジュールが1時間ごとに更新される2つの入力データセットを持っている場合、スケジュールが1時間に2回実行されることになります。スケジュールが複数のデータセットを更新するときに実行すると、大幅なコスト削減が可能になります。
推奨： OR トリガーではなく AND トリガーを使用するようにスケジュールを変更するか、1時間に1回実行する時間ベースのトリガーに切り替えることを検討してください。
ロジック： スケジュールは無視されたデータセットを宣言しますが、ビルドアクションは変更しません。
推奨： スケジュールの無視リストから問題のあるデータセットを削除します。
Incremental append dataset poorly partitioned と同様ですが、SNAPSHOT トランザクションを使用して追加されたデータセットの場合です。この場合、データプロジェクションの使用はお勧めしません。
Incremental over provisioned cores と同様ですが、SNAPSHOT トランザクションで実行されるデータセットの場合です。
ロジック： このリポジトリでは、Squash and merge の git 挙動が有効になっていません。
推奨： リポジトリの設定で Squash and merge を有効にします。
ロジック： 下流のデータセットは Code Workbook でビルドされていますが、同じスケジュール上にはありません。
なぜ： Code workbooks は、使用準備が整ったウォーム Spark モジュールを使用する能力を持っています。ワークブック変換ジョブが同じスケジュール内にある場合、このモジュールをアクティブな状態で再利用し、ディスクからのマテリアライズされたデータの読み込みをスキップできます。これにより、パイプラインの速度が上がり、コストが削減されます。
推奨： このデータセットから直接下流の Code Workbook 変換を同じスケジュールに移動します。
節約見積もり方法： Linter は、データセットを読み込むのにかかる時間の大まかな見積もりを生成します。この見積もりは観察テストに基づくヒューリスティックであり、特定のコンピュート環境に対して完全に正確であるとは限りません。