注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
Foundryは、Foundry内部に保存されるリソースメタデータを収集します。Linterは、さまざまなメタデータストアからメタデータを取得し、統合します。Linterルールは、リソースメタデータに対して実行されるロジックであり、リソースが論理テストに合格するかどうかを判断します。リソースがテストに失敗した場合、Linterはリソースを変更してロジックの結果を変える方法についての推奨事項を生成します。
各Linterルールはモードに属します。
リソース節約モードでは、各ルールが推奨事項に従った場合の節約額を推定するための方法論に従います。この方法論は優先順位付けをサポートします。仮定は多くの状況に対して有効ですが、ユーザーのユースケースに適していない場合があります。リソース使用量の削減を検証するには、Resource Managementアプリケーションを使用してください。
ロジック: 下流のデータセットはCode Workbookでビルドされますが、同じスケジュールにありません。
理由: Code Workbooksは、準備済みのウォームSparkモジュールを使用する機能を持っています。ワークブックのトランスフォームジョブが同じスケジュール内にある場合、このモジュールをアクティブな状態で再利用でき、ディスクからのマテリアライズデータの読み込みをスキップできます。これにより、パイプラインの速度が向上し、コストが削減されます。
推奨事項: Code Workbookトランスフォームをこのデータセットの直下流に移動し、同じスケジュールに配置します。
節約推定方法: Linterはデータセットの読み取りにかかる時間の概算を生成します。この推定値は観察テストに基づくヒューリスティックであり、特定のコンピュート環境に対して完全に正確であるとは限りません。
ロジック: 過去7日間でこのリソースのジョブがアクティブに実行されている時間の割合が70％を超えました。これには、頻繁にトリガーされる短時間のジョブが多く含まれる場合や、長時間のジョブが少ない場合があります。
理由: データセットの継続的なビルドは、使用量の大きな原因となる可能性があります。これらのリソースのビルド頻度の減少やパフォーマンスの向上は、大きな節約につながる可能性があります。
推奨事項: ビルド頻度の削減を検討してください。
節約推定方法: 過去カレンダ月の総リソース使用量（たとえば、6月21日から計算すると、提供される値は5月1日から5月31日までのこのリソースの消費量）です。
ロジック: データセットのJobSpecコミットがリポジトリのmasterブランチの最新のコミットと異なります。
理由: 修正されない場合、データセットのビルドはリポジトリの最新のロジックを反映しません。
推奨事項: データセットをスケジュールから削除するか、masterブランチにトランスフォームロジックを再コミットします。
ロジック: Contourダッシュボードには、開始インクリメンタルデータセットの1つにデータセットプロジェクションがありません。
理由: プロジェクションを使用してダッシュボードの表示を速くし、安定した使用状況での繰り返しフィルター計算を節約します。
推奨事項: Contourダッシュボードの使用状況、重要性、およびフィルター処理された列の順序を確認してください。Foundryエンロールメントでデータセットプロジェクションを有効にし、フィルタリングに最適化されたFoundryデータセットにプロジェクションを追加します。プロジェクションを定期的に更新するようにスケジュールしてください。これで、データセットプロジェクションを活用してContourダッシュボードが速く表示されるようになります。
ロジック: トランスフォームの入力および出力データセットの統計により、ロジックが適用されていないことが示されています。
理由: データセットをSparkに読み込んでから書き戻す際にリソースが使用されます。これは、計算をスキップしてFoundryビューを使用することで回避できます。
推奨事項: このデータセットをFoundryビューに変換して、パイプラインの実行時間、データの重複、コストを削減してください。
節約推定方法: 過去カレンダ月の総リソース使用量（たとえば、6月21日から計算すると、提供される値は5月1日から5月31日までのこのリソースの消費量）です。
ロジック: データセットに関連付けられたトランスフォームには、@configureブロックにエグゼキューターメモリベースのプロファイルが含まれていますが、Veloxと既に関連付けられていません。
推奨事項: これらのジョブのバックエンドをVeloxに切り替えることで、潜在的な節約が見込まれます。この変更を行う際には、Linterが推奨する潜在的な節約を検証するために消費されるリソースを確認することが重要です。
ロジック: コードリポジトリのデフォルトブランチが保護されていません。
理由: デフォルトブランチを保護することは、変更の追跡、バージョン管理、および偶発的な変更からの保護に重要です。
推奨事項: デフォルトブランチをリポジトリ設定で保護されたブランチのリストに追加します。
ロジック: トランスフォームは、デフォルトの1コアあたり7.5 GBを超えるメモリ対コア比を使用しています。
理由: メモリ対コア比のデフォルト値を超えると、コストが増加します。多くのユーザーは、メモリに関連しない問題に対処するためにエグゼキューターメモリを増やすことがありますが、より安価な方法で解決できる場合もあります。デフォルトのメモリ対コア比を使用してトランスフォームを実行することで、リソースの節約が見込まれることが多いです。しかし、行の爆発などの場合、エグゼキューターメモリを増やしてメモリエラーやエグゼキューター間の過剰なシャッフルを回避する必要があることもあります。このような場合、エグゼキューターメモリプロファイルにエグゼキューターコアの数を合わせることで、ビルド時間を短縮し、並列処理を増やし、パーティションサイズを減らすことで、コストを大幅に削減できます。
推奨事項: EXECUTOR_MEMORY_X SparkプロファイルをEXECUTOR_CORES_X Sparkプロファイルに合わせて、メモリ対コア比を減らすことをお勧めします。これによってメモリの問題が発生する場合は、Sparkグラフを調査して問題のステージを特定します。データセット読み取りステージの問題の場合、入力データセットのパーティション数を増やして、各エグゼキューターに小さなパーティションサイズを供給することを検討してください。シャッフルステージの問題の場合、タスク数がシャッフルパーティション設定より少ない場合は適応型Spark割り当てを無効にする（ADAPTATIVE_DISABLED Sparkプロファイル）、またはシャッフルサイズを増やして（SHUFFLE_PARTITIONS_LARGE Sparkプロファイル）エグゼキューターに小さなタスクを供給することを検討してください。Sparkプロファイルの詳細はこちらをご覧ください。
節約推定方法: デフォルトのコア対メモリ比率を使用した場合の過去カレンダ月のリソース使用量の推定値が計算されます。その値を観測されたリソース使用量から差し引いて、節約額を推定します。
ロジック: データセットがインクリメンタルに更新されており、最適でないパーティションサイズを持っているため、平均パーティションサイズが大きすぎるか小さすぎる。
理由: 最適なパーティションサイズは異なります。パーティションサイズが小さすぎる場合、各パーティションに伴うオーバーヘッドが処理時間を支配することがあります。パーティションサイズが大きすぎる場合、メモリ管理操作が実行時間を増加させたり、メモリエラーを引き起こしたりすることがあります。これにより、ジョブの実行時間が延び、下流のデータセットや分析でデータセットからデータを読み込む際に過剰なリソース使用が発生します。
推奨事項: パーティションサイズをチェックし、データセット内のデータをより適切なパーティションサイズで保存するロジックを含めることをお勧めします。APPENDデータセットの場合は、出力データセット内の既存ファイルの数を確認してください。データセットがPythonまたはJavaのトランスフォームロジックファイルによってサポートされていない場合、プロジェクションを作成することも、この問題を改善する方法です。フィルタリングに最適化されたプロジェクションを行うことで、望ましい圧縮が達成されますが、下流のクエリプランに応じて、結合に最適化することで追加の利点が得られる場合もあります。
節約推定方法: 最近のジョブでのファイル読み取りにかかる時間の比率が、通常データセットのサイズにかかる時間の推定値と比較されます。これにより、このデータセットを読み込む各下流トランスフォーメーションで、過去1週間に発生した回数が掛け算されます。
ロジック: データセットは固定数のエグゼキューターを使用する静的割り当てを使用しています。最近のジョブでのタスクの並列度が閾値（デフォルトは70％）より低いです。
理由: 静的にリソースをプロビジョニングすると、並列度が低下し、リソースがアイドル状態になり、他のタスクが終了するまで待機します。動的割り当てSpark設定を使用することで、アイドル状態のエグゼキューターがこのジョブ専用に予約されなくなるため、より良いタスク並列度が実現します。
推奨事項: トランスフォームにDYNAMIC_ALLOCATION_MAX_NSparkプロファイルを適用して、動的割り当てを使用することをお勧めします。
節約推定方法: 計算された並列度が過去カレンダ月のリソース消費量に掛け算され（たとえば、6月21日から計算すると、提供される値は5月1日から5月31日までのこのリソースの消費量）、完全な並列度が達成された場合の節約額が推定されます。たとえば、データセットの最近の並列度が70％である場合、先月のリソース使用量の30％が節約されると推定されます。
Incremental append dataset too many filesと似ていますが、replaceインクリメンタルトランスフォーム出力書き込みモードを使用するデータセットに適用されます。UPDATEトランザクションがファイルを追加するだけではなく、既存のファイルを変更または削除する場合は、データセットプロジェクションの完全な再計算が必要となるため、この場合の修正方法としてデータプロジェクションの使用を推奨しません。インクリメンタルPythonトランスフォームモードについて詳しくはこちらをご覧ください。
ロジック: スケジュールが他のスケジュールによってビルドされるデータセットをビルドします。
理由: 同じデータセットが異なるスケジュールによってビルドされると、計算リソースの無駄、キューイング、信頼性の低い遅延が発生する可能性があります。
推奨事項: スケジュールのビルドアクションを変更して重複を排除します。
ロジック: このリポジトリでは、Squash and merge git動作が有効になっていません。
推奨事項: リポジトリ設定でSquash and mergeを有効にします。
ロジック: コードリポジトリにマージできないリポジトリアップグレードPRがオープンされています。
理由: リポジトリアップグレードは、パイプラインが最新の機能を使用し続けるために重要です。リポジトリが最新でないと、時間とともにパイプラインの失敗を引き起こし、ワークフローの安定性が低下し、計算リソースの無駄が発生します。
推奨事項: PRがマージされない理由を調査し、アップグレードを修正します。
ロジック: コードリポジトリの設定で、アップグレードプルリクエストの自動マージが無効になっています。
理由: リポジトリアップグレードは、パイプラインが最新の機能を使用し続けるために重要です。リポジトリが最新でないと、時間とともにパイプラインの失敗を引き起こし、ワークフローの安定性が低下し、計算リソースの無駄が発生します。
推奨事項: 修正アシスタントを使用して、アップグレードPRが自動的にマージされるようにします。そうでない場合は、Settings > Repository > Upgradesを選択してリポジトリの設定に手動で移動し、Automatically merge upgrade pull requestsオプションを選択します。
ロジック: 過去30日間にスケジュールが成功していません。その期間にビルドに失敗したデータセットが一覧表示されます。
理由: 各実行では、スケジュールが過去30日間に成功していないデータセットを再ビルドしようとします。これはリソースの無駄を示しています。
推奨事項: スケジュールを一時停止し、失敗しているデータセットを修正するか、スケジュールから失敗しているデータセットを削除します。
節約推定方法: 過去30