注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
Foundry は、内部に保存されるリソースメタデータを収集します。Linter は、さまざまなメタデータストアからメタデータを取得して組み合わせます。Linter ルールは、リソースメタデータに対して実行され、リソースが論理テストに合格するか不合格となるかを判定するロジックです。リソースがテストに不合格となった場合、Linter はロジックの結果を変えるためにリソースをどのように変更できるかについて推奨事項を生成します。
各 Linter ルールは、いずれかのモードに属します。
リソース削減モードでは、各ルールは、推奨事項に従った場合の削減量を見積もるための方法に従います。この方法は優先順位付けを支援するものです。前提条件は多くの状況で妥当であることが多いものの、お使いのユースケースには適していない場合があります。リソース使用量の削減を検証するには、Resource Management アプリケーションを使用してください。
ロジック： 下流のデータセットが Code Workbook でビルドされていますが、同じスケジュールに含まれていません。
理由： コードワークブックでは、すぐに使えるウォーム状態の Spark モジュールを使用できます。ワークブックのトランスフォームジョブが同じスケジュールに含まれている場合、モジュールがアクティブな間は再利用でき、実体化されたデータをディスクから読み込む処理を省略できます。これにより、パイプラインが高速化され、コストが削減されます。
推奨事項： このデータセットの直下流にある Code Workbook トランスフォームを同じスケジュールに移動します。
削減量の見積もり方法： Linter は、データセットの読み込みにかかる時間を概算します。この見積もりは観測テストに基づく経験則によるもので、お使いのコンピューティング環境では完全に正確とは限りません。
ロジック： 過去7日間に、このリソースのジョブが実際に実行されていた時間の割合が70%を超えています。これには、頻繁にトリガーされる実行時間の短い多数のジョブや、実行時間の長い少数のジョブが含まれる可能性があります。
理由： 常にビルドされているデータセットは、使用量が増える大きな要因となる場合があります。これらのリソースの実行頻度を下げたり、パフォーマンスを改善したりすることで、大幅な削減につながる可能性があります。
推奨事項： ビルド頻度を下げることを検討します。
削減量の見積もり方法： 前暦月のリソース使用量の合計です（たとえば、6月21日時点で計算する場合、示される値は5月1日から5月31日までのこのリソースの消費量です）。
ロジック： データセットの Job Spec のコミットが、リポジトリの master ブランチの最新コミットと異なっています。
理由： 修正しない場合、データセットのビルドにリポジトリの最新のロジックが反映されません。
推奨事項： データセットをスケジュールから外すか、そのトランスフォームのロジックを master ブランチに再コミットします。
ロジック： Contour ダッシュボードの起点となるインクリメンタル（差分処理）データセットのいずれかに、データセットプロジェクションがありません。
理由： プロジェクションを使用すると、ダッシュボードにデータが表示されるまでの時間が短縮され、継続的に使用する場合に繰り返されるフィルター計算を省けます。
推奨事項： 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週間にこれが発生した回数を掛けます。
ロジック： データセットは、固定数のエグゼキューターを使用する Spark 設定である静的割り当てを使用しています。最近のジョブで実行されるタスクの並列度がしきい値（デフォルト: 70%）を下回っています。
理由： リソースを静的に割り当てると、並列度が低下することがあります。リソースはアイドル状態となり、ほかのタスクが終了するまで使用できず待機します。Spark の動的割り当て設定を使用すると、アイドル状態のエグゼキューターがこのジョブ専用に確保されなくなり、タスクの並列度が向上します。
推奨事項： トランスフォームに DYNAMIC_ALLOCATION_MAX_N Spark プロファイルを適用して、動的割り当てを使用することを推奨します。
削減量の推定方法： 算出された並列度に前暦月のリソース消費量を掛けて、完全な並列処理が実現した場合の削減量を推定します（たとえば、6月21日に計算する場合、使用される値は5月1日から5月31日までのこのリソースの消費量です）。たとえば、データセットの最近の並列度が70%の場合、先月のリソース使用量の推定30%を削減できます。
「インクリメンタル APPEND データセットのファイル数が多すぎる」と似ていますが、インクリメンタルトランスフォームの出力書き込みモードとして replace を使用するデータセットが対象です。UPDATE トランザクションがファイルの追加のみを行うわけではない場合、このケースではデータプロジェクションを解決策として使用することを推奨しません。既存のファイルを変更または削除すると、データセットプロジェクションが完全に再計算されます。インクリメンタル Python トランスフォームのモードについて詳しくは、こちらを参照してください。
ロジック： このスケジュールは、別のスケジュールでもビルドされるデータセットをビルドします。
理由： 同じデータセットが2つの異なるスケジュールによってビルドされるため、計算リソースの浪費、キュー待ち、遅延の不安定化が発生する可能性があります。
推奨事項： スケジュールのビルドアクションを変更して、重複を解消します。
ロジック： このリポジトリでは、Git の「コミットをまとめてマージ」の動作が有効になっていません。
推奨事項： リポジトリ設定で「コミットをまとめてマージ」を有効にします。
ロジック： コードリポジトリには、マージできない未完了のリポジトリアップグレード PR があります。
理由： リポジトリのアップグレードは、パイプラインで利用可能な最新の機能を使い続けるために不可欠です。最新の状態ではないリポジトリは、時間の経過とともにパイプラインの失敗を引き起こし、ワークフローの安定性に影響を与え、計算リソースの浪費につながる可能性があります。
推奨事項： PR がマージされない理由を調査し、アップグレードの問題を修正します。
ロジック： コードリポジトリの設定で、アップグレードプルリクエストの自動マージが無効になっています。
理由： リポジトリのアップグレードは、パイプラインで利用可能な最新の機能を使い続けるために不可欠です。最新の状態ではないリポジトリは、時間の経過とともにパイプラインの失敗を引き起こし、ワークフローの安定性に影響を与え、計算リソースの浪費につながる可能性があります。
推奨事項： 修正アシスタントを使用して、アップグレード PR の自動マージを許可します。または、設定 > リポジトリ > アップグレードを選択してリポジトリ設定に手動で移動し、アップグレードプルリクエストを自動的にマージするオプションにチェックを入れます。
ロジック： このスケジュールは過去30日間に成功していません。その期間にビルドに失敗したデータセットが一覧表示されます。
理由： スケジュールは実行のたびに、過去30日間に一度もビルドに成功していないデータセットの再ビルドを試みており、リソースが浪費されていることを示しています。
推奨事項： スケジュールを一時停止するか、失敗しているデータセットに修正を適用するか、失敗しているデータセットをスケジュールから外します。
削減量の推定方法： 過去30日間に、そのブランチで失敗しているデータセットにかかった計算コストの合計です。
ロジック： このデータセットには Code Workbook の Job Spec があります。
理由： 本番環境のデータセットおよびスケジュールされたデータセットは、可能な限り Code Workbook でビルドすべきではありません。代わりに、Pipeline Builder や Code Repositories など、本番環境のパイプライン構築用に設計されたアプリケーションに移行すべきです。
推奨事項： データセットをスケジュールする必要がある場合は、ロジックを Pipeline Builder または Code Repositories に移行します。
ロジック： このデータセットには Contour の Job Spec があります。
理由： 本番環境のデータセットおよびスケジュールされたデータセットは、Contour でビルドすべきではありません。Pipeline Builder や Code Repositories など、パイプライン構築用に設計されたアプリケーションに移行すべきです。
推奨事項： データセットをスケジュールする必要がある場合は、ロジックを Pipeline Builder または Code Repositories に移行します。
削減量の推定方法： 過去30日間に、そのブランチで失敗しているデータセットにかかった計算コストの合計です。
ロジック： このデータセットはゴミ箱にあります。
理由： データセットがゴミ箱に移動されているにもかかわらず、スケジュールはそのビルドを試みています。
推奨事項： データセットがまだスケジュールに含まれている理由を調査し、ゴミ箱から復元するか、スケジュールを更新します。
ロジック： このスケジュールでは、失敗時に中止が有効になっていません。
理由： 失敗時に中止が有効になっていない場合、スケジュール内に失敗したデータセットがあっても、監視はスケジュールの終了を待ちます。
推奨事項： 失敗時に中止モードを有効にします。この機能により、監視に失敗がより早く通知され、迅速な対処が可能になります。
ロジック： このスケジュールでは、所要時間超過モードが有効になっていません。
理由： 所要時間が設定されている場合、このモードは、一時的なネットワーク障害の際に Data Connection のビルドが無期限に実行されることを防ぎ、下流の停止を防止します。
推奨事項： スケジュールで所要時間超過モードを有効にします。
ロジック： このスケジュールはどのデータセットもビルドしません。
理由： このスケジュールはリソースを浪費し、監視のノイズを発生させている可能性があります。
推奨事項： スケジュールが有用かどうかを調査し、削除するか、監視対象から外すかを判断します。
ロジック： スケジュールで、ビルドアクションに影響しないデータセットが無視対象として指定されています。
推奨事項： 該当するデータセットをスケジュールの無視リストから外します。
ロジック： スケジュールで指定されている入力データセットが、スケジュールによってビルドされるどのデータセットの入力にもなっていません。
理由： この問題は通常、除外されたデータセットが原因で発生します。
推奨事項： 除外されたデータセットを変更するか、接続ビルドアクションから入力を外します。
ロジック： スケジュールに、ビルド可能で、スケジュールされておらず、Fusion を基盤としない入力データセットがあります。
推奨事項： フラグがついたデータセットをスケジュールするか、そのコードと Job Spec を削除して生データセットにします。データセットに Job Spec が必要でも、スケジュールすべきでない場合（任意に実行するスナップショットなど）は、例外を追加します。
ロジック： スケジュールに説明がありません。
推奨事項： スケジュールの目的と機能に基づいて説明を入力します。
ロジック： スケジュールに名前がありません。
推奨事項： ビルド内のデータセット名とパスに基づいて名前を生成します。名前は自動生成できます。
ロジック： スケジュールが master 以外のブランチで実行されています。
理由： Foundry 全体で、master ブランチはデータの標準バージョンとして使用されています。代替バージョンのデータを提供したり、別のロジックを試したりするために、ブランチ上でスケジュールを継続的に実行する必要があることもよくあります。このような運用によって、ブランチ上に設定された多くのスケジュールが、必要な期間を超えて実行され続けることがあります。
推奨事項： ブランチ上のスケジュールが必要かどうかを確認し、不要な場合は一時停止または削除を検討します。また、コストを削減するために、master ブランチ以外のスケジュールのトリガー頻度を下げることも検討できます。たとえば、master で1日に1回実行されるスケジュールについて、master 以外のブランチでは週に1回の実行でも同じ結果を得られないでしょうか。
削減量の推定方法： 先月にこのブランチで実行されたジョブ数を、先月に master で実行されたジョブ数で割った比率を使用して、このスケジュールでビルドされたデータセットのリソース使用量を再正規化します。ブランチごとに再正規化した使用量を合計すると、削減量の推定値になります。
ロジック： スケジュールの解決済み出力の一部が対象として指定されていないか、またはその逆になっています。
推奨事項： 対象が実際のスケジュール出力と一致するようにスケジュールを更新します。
ロジック： スケジュール内のすべてのリソースのリネージを確認し、スケジュールされたパイプライン、Contour などの対話型分析、オブジェクトストレージの宛先、または外部 API 呼び出しによって、最近下流で使用されたかどうかを判断します。
理由： Foundry は時間とともに変化するため、意思決定に使用されることのない結果の計算にリソースを費やしてもメリットはありません。使用されていないパイプラインを停止することで、Foundry インスタンスが、目標の達成に向けて実際に使用されている結果の計算にのみリソースを費やすようにできます。
推奨事項： 使用されていないスケジュールは一時停止されます。推奨事項によって、スケジュール内の使用されていない部分が明らかになることもあり、その部分を削除するとコンピューティング使用量を削減できる可能性があります。
削減量の推定方法： 先月のスケジュール内の未使用リソース全体のリソース使用量の合計です。
ロジック： スケジュールの再試行が有効になっていません。
理由： 環境のセットアップの問題が原因となるものなど、特定の失敗は通常、2回目の実行では発生しません。スケジュールに再試行がないと、本来ビルドできたはずのデータセットがビルドされない場合があります。
推奨事項： 再試行を有効にします。再試行回数を3回に設定することを推奨します。
ロジック： スケジュールの範囲が、そのビルドアクションに対して無効です。このスケジュールでビルドすべきデータセットが範囲から除外されています。
推奨事項： スケジュールを編集し、このスケジュールでビルドするデータセットを含むすべてのプロジェクトが含まれるように、プロジェクトの範囲を変更します。これができない場合は、スケジュールのプロジェクト範囲の指定を外します。
ロジック： スケジュールで、データセットがトリガーとして指定されていますが、入力としては指定されていません。
推奨事項： 接続ビルドアクションを変更し、データセットをトリガーから外すか、入力に追加します。
ロジック： スケジュールでトリガーとして指定されているデータセットが、ビルド対象にもなっています。
推奨事項： ビルドアクションを変更し、問題のデータセットをトリガーまたは出力データセットから外します。
ロジック： スケジュールに複数のトリガー条件があります。
理由： スケジュールは、新しいデータが利用可能になるたびに実行されるように作成されることがよくあります。たとえば、スケジュールに2個の入力データセットがあり、それぞれが1時間に1回更新される場合、スケジュールが1時間に2回実行される可能性があります。複数のデータセットが更新されたタイミングでスケジュールを実行すれば、コストを大幅に削減できる可能性があります。
推奨事項： OR ではなく AND トリガーを使用するようにスケジュールを変更するか、時間ベースのトリガーに切り替えて1時間に1回実行することを検討します。
ロジック： Data Connection の取り込みスケジュールではないにもかかわらず、スケジュールで強制ビルド設定が使用されています。
理由： Foundry は入力リネージ全体のトランザクションによる変更を追跡し、入力に変更がない場合は計算をスキップできる仕組みを備えています。強制ビルド設定を使用すると、入力トランザクションの分析結果に関係なくトランスフォームが実行されるため、同じ結果を繰り返し生成する不要なジョブが発生する可能性があります。
推奨事項： この設定の使用を必要とする、追跡されていない外部依存関係（たとえば API 呼び出し）がトランスフォームにないか確認します。依存関係が見つからない場合は、スケジュールからこの設定を外します。
削減量の推定方法： スケジュール内のデータセットの先月の合計リソース使用量（たとえば、6月21日に計算する場合、示される値は5月1日から5月31日までのこのリソースの消費量です）に、各データセットのジョブ入力変更率を掛けます。データセットのジョブ入力変更率は、先週（消費量データを取得した前月ではありません）の入力が更新されたジョブ数を、同期間のジョブ総数で割った値です。
「インクリメンタル（差分処理）の追加データセットのファイル数が多すぎる」と同様ですが、SNAPSHOT トランザクションを使用して追加されるデータセットが対象です。この場合、データプロジェクションの使用は推奨しません。
「インクリメンタルのコア割り当てが過剰」と同様ですが、SNAPSHOT トランザクションで実行されるデータセットが対象です。
ロジック： Spark でビルドされたデータセットで、非決定論的である可能性のあるロジックを含むクエリプランが検出されました。
理由： Spark のクエリプランには、データの不整合、非決定論的なデータ、またはその他の不安定なデータにつながる可能性があるエッジケースがいくつかあります。
推奨事項： 各推奨事項には、非決定論的である可能性の内容について、より詳しい情報が示されるはずです。非決定論的である可能性のある Spark プランを持つデータセットの元となるロジックを調査し、修正します。
ロジック： これらのデータセットに関連付けられたトランスフォームは、Spark コンテキストや Spark データフレームを使用していないか、すでに Pandas ベースのトランスフォームに関連付けられています。
推奨事項： これらのトランスフォームを軽量トランスフォームに切り替えると、使用量を削減できる可能性があります。この変更を行う際は、消費されるリソースを確認し、Linter が推奨する削減見込みを検証することが重要です。
ロジック： データセットが SNAPSHOT としてビルドされますが、新しいデータの追加のみを行うインクリメンタルデータセットが1つ以上あり、その直接の下流に位置しています。
理由： SNAPSHOT トランザクションは過去のすべてのデータを処理します。インクリメンタルトランザクションは新しいデータのみを処理し、その結果を以前の値に追加します。インクリメンタルトランザクションに切り替えることで、結果を生成するために必要なリソースを大幅に削減できる場合があります。
推奨事項： コンピューティングコストを削減するため、このデータセットをインクリメンタルトランスフォームに変更することを検討してください。データセットがインクリメンタルに実行するよう設定されている場合は、データセットが頻繁に SNAPSHOT としてビルドされる理由を把握し、対処してください。
削減量の推定方法： 先月の合計リソース使用量（たとえば、6月21日に計算する場合、示される値は5月1日から5月31日までのこのリソースの使用量です）に、入力サイズの合計（入力がインクリメンタルの場合は差分サイズ）と入力の全体サイズの合計（入力がインクリメンタルかどうかにかかわらず）の比率を掛けます。これにより、このデータセットをインクリメンタルに実行した場合の推定リソース使用量が算出されます。したがって、この推奨事項による推定削減量は、先月のリソース使用量と、この推定リソース使用量との差になります。
ロジック： トランスフォームがサイズの小さいデータセット（300Mb 以下）を使用しています。
理由： デフォルトでは、Foundry はスケーリングの容易さと処理速度のために分散計算を使用します。これはローカル計算よりも多くのリソースを使用します。データセットのサイズが小さく、今後もその状態が続く場合は、トランスフォームの実行に必要なリソースを減らすため、分散実行ではなくローカル実行を使用する必要があります。
推奨事項： このトランスフォーム、またはリポジトリ内で入力データセットと出力データセットのサイズがしきい値未満であるすべてのトランスフォームについて、ローカル実行を有効にします。これは、KUBERNETES_NO_EXECUTORS Spark プロファイルなどの特定の設定を使用して有効にできます。
削減量の推定方法： 先月の合計リソース使用量（たとえば、6月21日に計算する場合、示される値は5月1日から5月31日までのこのリソースの使用量です）を、コア数の変化の比率で割ります。たとえば、トランスフォームが以前は5コア（エグゼキューターあたり2コアのエグゼキューターが2個と、1コアのドライバーが1個）を使用しており、ローカル実行では1コアを使用できる場合、推定削減量は合計リソース使用量に0.8 ((5-1)/5) を掛けた値になります。
ロジック： スケジュールのスコープがプロジェクトになっていません。
推奨事項： スコープ付きトークンモードで実行するようにスケジュールを変更します。デフォルトでは、スコープはビルドされるデータセットのプロジェクト RID です。