注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
以下のガイドは、Foundry使用の最適化方法とベストプラクティスを提供することを目的としています。このドキュメントはまず、Foundryでの使用がどのように決定されるかをカバーし、その後、使用の無駄とパイプラインの最適化を特定する方法を説明します。一般的な推奨事項は、組織の使用消費を監視および最適化することに焦点を当てているため、プロジェクトマネージャーやプラットフォーム管理者にも関心を持ってもらえるかもしれません。
ここに記載されているベストプラクティスに加えて、LinterはFoundryの状態をアンチパターンとしてチェックし、リソースの状態を改善するための意見を持った推奨事項を提供します。これらの推奨事項を評価し、実行することで、コストを削減し、ユーザーのオントロジーを最適化し、パイプラインの安定性と回復力を向上させることができます。
これらのベストプラクティスをワークフローに実装する方法を考える際には、パイプラインやワークフローを早期に最適化するというよく知られた落とし穴に陥らないようにすることが重要です。ユーザーは早期の最適化を避け、最適化のためのワンサイズフィットオールの戦略を期待しないでください。
以下の心的ステップを踏んでアプローチの有効性を確認することをお勧めします：
これらの質問のいくつかがまだ回答されていない場合、成功する最適化を行うためには、さらに事前作業が必要である可能性があります。
これを念頭に置いて、以下に最適化の良い例と悪い例を示します：
Foundry使用の最適化のための一般的なプラクティスには次のものがあります：
Foundry使用は、Foundryコンピュート、オントロジーボリューム、Foundryストレージの3つの構成要素から成り立っています。
ほとんどのアカウントはこの3次元モデルに基づいていますが、使用基準はアカウントによって異なる場合があります。Palantirの担当者に確認して条件を確認してください。
Foundryコンピュートは、データ統合と分析のためのツールによって駆動されます。Foundryコンピュートには主に3つのタイプがあります：バッチ、インタラクティブ、およびストリーミングです。
バッチコンピュートは、「バッチ」キャパシティで実行されるクエリまたはジョブを表し、特定のスケジュールに基づいてバックグラウンドで実行されるか、アドホックで実行されます。バッチコンピュートジョブは実行されていないときにコンピュートを消費しません。バッチコンピュートのいくつかの例には、すべてのトランスフォームジョブ、Contourからのデータセットのビルド、コードワークブック、データヘルスチェック、およびオントロジー/インデックスストレージへの同期が含まれます。
インタラクティブコンピュートは、通常インタラクティブなユーザーセッションの一部としてリアルタイムで評価されるクエリを表します。ユーザーに迅速な応答を提供するために、インタラクティブコンピュートシステムは常にオンのアイドルコンピュートを維持しているため、インタラクティブクエリはバッチ評価よりも多くのコンピュートを消費する傾向があります。インタラクティブコンピュートの主な形式はContourです。Contourダッシュボード、分析、および埋め込みContourチャートはすべてインタラクティブコンピュートの例です。
ストリーミングコンピュートは、任意のロジックを使用してメッセージを継続的に受信および処理する常時オンの処理ジョブを表します。ストリーミングコンピュートは、ストリームがメッセージを受信できる状態である時間の長さによって測定されます。ストリーミングコンピュートは、バッチおよびインタラクティブコンピュートと比較して最も高いコストがかかります。ストリーミングコンピュートの例には、ストリーミングトランスフォーメーションおよびPipeline Builderストリームが含まれます。
バッチ、インタラクティブ、およびストリーミングのコンピュート使用量は、次の要因によって駆動されます：
Foundry使用の第2の構成要素はオントロジーボリュームです。Foundryの最もユニークな機能の1つは、オントロジーレイヤーです。オントロジーは、エンタープライズデータと組織が関心を持つオブジェクトの間の翻訳レイヤーです。オントロジーは、航空機や車などの具体的な用語でデータを考えることができるようにするデータの世界の分類です。オントロジーに詳しくない場合は、ドキュメントから詳細を学ぶことができます。
オントロジーボリュームは次の要因によって駆動されます：
Foundryストレージは、Foundryの非オントロジートランスフォーメーションレイヤーに保存される一般目的のデータを測定します。データセットブランチと以前のトランザクション（およびビュー）は、1つのデータセットが消費するディスクスペースに影響を与えます。Foundryには、Foundryインスタンスをスリムに保つためのさまざまな保持ルールがあります。ビューからファイルをDELETEトランザクションで削除しても、ファイルは基礎となるストレージから削除されないため、ストレージコストは引き続き発生します。サイズを削減する唯一の方法は、不要なトランザクションをクリーンアップするために保持を使用することです。DELETEトランザクションをコミットするか、ブランチを更新しても、使用されるストレージは削減されません。
Foundry使用の構成要素とそれに影響を与える要因を明確に理解することで、最適化の機会を見つけることができます。
| Foundryアプリケーション | 使用影響の種類 |
|---|---|
| Code Repositories | Foundryコンピュート |
| Pipeline Builder | Foundryコンピュート |
| Code Workbooks | Foundryコンピュート |
| Contour | Foundryコンピュート |
| ライブモデル | Foundryコンピュート |
| オントロジー | オントロジーボリューム |
| データセット | Foundryストレージ |
Resource Managementアプリケーションは、組織がFoundry使用消費を理解するための可視性と透明性を提供します。このアプリケーションは、各Foundry使用タイプ（Foundryコンピュート、オントロジーボリューム、Foundryストレージ）ごとに分解されたFoundry使用消費をユーザーが確認できるようにします。ユーザーは、リソース（プロジェクト）、ソース（アプリケーション）、およびユーザーごとに使用を確認できます。
Foundry使用を最適化できる場所を特定しようとする場合、最初にチェックする場所はResource Managementアプリケーションです。これにより、どのリソースが最も多くのコンピュートを消費しているかを確認し、ボトルネックがどこにあるかを特定できます。ここから、Foundry使用最適化ベストプラクティスを活用して使用を削減する方法を特定できますが、常にボトルネックに焦点を合わせることを忘れないでください。
前述のように、コンピュートリソースはデフォルトでResource Management（RMA）内でプロジェクトレベルで管理されます。RMA内では、Foundryコンピュート、オントロジーボリューム、およびFoundryストレージメトリクスがプロジェクトごとに測定されます。したがって、データパイプライン全体で使用メトリクスを効果的に追跡するためには、適切なプロジェクトの設定が非常に重要です。適切な設定により、データエンジニアやプラットフォーム管理者はパイプラインの主要なフェーズでこれらの使用メトリクスを監視し、最適化の領域を特定できます。不適切な設定は、リソースを多く消費し計算コストの高いデータパイプラインを特定できない結果をもたらします。
Foundryプロジェクトは、適切に構造化されたデータパイプラインを有効にするために使用されるべきです。プロジェクトの設定とパイプラインステージのベストプラクティスは、推奨プロジェクトおよびチーム構造ドキュメントで詳しく説明されています。プロジェクトが推奨される構造に従い、生データをデータソースからインポートして実際のワークフローに至るまで、ユーザーがパイプラインの主要なフェーズに沿ってコンピュートおよびストレージメトリクスを分析できるようにすることが重要です。
使用削減戦略を検討する際、管理者はチーム内で誰がプロジェクトとリソースを作成する権限を持つべきかを考慮する必要があります。このアクセスを、設定ベストプラクティスについて教育を受けた最小人数に制限することで、プロジェクトとリソースの広がりを減らし、不必要なストレージとコンピュートを削減できます。プラットフォーム上で誰でもプロジェクトを作成できるようにすると、使用追跡のための推奨構造に反するプロジェクトが作成される可能性が高く、最終的に使用量を増やす高価なパイプラインが作成されます。組織は、プラットフォーム上のユーザー数とデータアクセス制限に基づいてプロジェクト作成アクセスを管理する場合があります。このアクセスを決定するプロセスを開発