注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
以下のガイドは、Foundry の使用を最適化する方法とベストプラクティスを提供することを目指しています。この文書ではまず、Foundry での使用がどのように決定されるか、次に、使用の無駄やパイプラインの最適化をどのように特定するかについて説明します。一般的な推奨事項は、組織の使用消費を監視し、最適化することに注力しているプロジェクトマネージャーやプラットフォーム管理者にとっても関心があるかもしれません。
これらのベストプラクティスをどのように実装するかを考える際、パイプラインやワークフローを早期に最適化するというよく知られた落とし穴に陥らないように重要です。ユーザーはパイプラインを早期に最適化することを避け、最適化のための一律の戦略を期待すべきではありません。
以下のメンタルステップをチェックして、ユーザーのアプローチの妥当性を確認することをお勧めします：
これらの質問のいくつかにまだ答えが出ていない場合、成功した最適化の努力をするためには、さらなる前準備が必要であることを示しているかもしれません。
これを念頭に置いて、以下に最適化の努力の良い例と悪い例を示します：
Foundry の使用を最適化するための一般的なプラクティスには以下のようなものがあります：
Foundry の使用は、Foundry 計算、オントロジー量、Foundry ストレージの3つのコンポーネントで構成されています。
ほとんどのアカウントはこの3次元モデルに基づいていますが、一部のアカウントでは使用基準が異なる場合があります。Palantir の代表との条件を確認してください。
Foundry 計算は、データ統合と分析のツールによって推進されます。Foundry 計算には3つの主要なタイプがあります：バッチ、インタラクティブ、ストリーミング。
バッチ計算は、"バッチ"容量で実行されるクエリやジョブを表します。つまり、特定のスケジュールの頻度またはアドホックな基準でバックグラウンドで実行するようにトリガーされます。バッチ計算のジョブは、実行していないときは計算を消費しません。バッチ計算の例としては、すべての変換ジョブ、Contour からのデータセットのビルド、コードワークブック、データ健康チェック、オントロジー/インデックス化ストレージへの同期などがあります。
インタラクティブ計算は、リアルタイムで評価されるクエリを表します。これは通常、インタラクティブなユーザーセッションの一部として行われます。ユーザーに迅速な応答を提供するために、インタラクティブ計算システムは常にオンのアイドル計算を維持します。つまり、インタラクティブクエリはバッチ評価よりも多くの計算を使用する傾向があります。インタラクティブ計算の主な形式は Contour - Contour のダッシュボード、分析、埋め込み Contour チャートはすべてインタラクティブ計算の例です。
ストリーミング計算は、常にオンの処理ジョブを表し、連続してメッセージを受信し、任意のロジックを使用してそれらを処理します。ストリーミング計算は、ストリームがメッセージを受信する準備ができている時間の長さについて測定されます。ストリーミング計算は、バッチとインタラクティブ計算に比べて最も高いコストを持っています。ストリーミング計算の例としては、ストリーミング変換と Pipeline Builder ストリームがあります。
バッチ、インタラクティブ、ストリーミングの計算使用量は、以下の要素によって推進されます：
Foundry 使用の第二のコンポーネントは オントロジー量です。Foundry の最もユニークな機能の一つはオントロジーレイヤーです。オントロジーは、エンタープライズデータと組織が関心を持つオブジェクトとの間の翻訳レイヤーです。オントロジーは、データの世界をカテゴライズすることで、組織がそのデータを「航空機」や「車」などのより具体的な用語で考えることを可能にします。これは、それらを説明する多くの行と列の集約体ではなく。オントロジーに馴染みがない場合は、文書化から詳細を学ぶことができます。
オントロジー量は以下の要素によって推進されます：
Foundry ストレージは、Foundry の非オントロジー変換レイヤーで格納される汎用データを測定します。これは時々 "コールドストレージ"と呼ばれます。
データセットのブランチと以前のトランザクション（およびビュー）は、単一のデータセットが消費するディスクスペースの量に影響を与えます。Foundry は、Foundry インスタンスを軽量に保つための様々な保持ルールを提供します。ファイルが DELETE トランザクションでビューから削除されると、ファイルは基礎となるストレージから削除されず、その結果、ストレージコストが継続的に発生します。サイズを減らす唯一の方法は、不必要なトランザクションをクリーンアップするために保持を使用することです。 DELETE トランザクションをコミットしたり、ブランチを更新したりすると、使用されるストレージは減少しません。
Foundry 使用の構成要素とそれが何に影響を与えるかを明確に理解することは、最適化の機会を理解するための洞察を提供できます。
| Foundry アプリケーション | 使用影響のタイプ |
|---|---|
| コードリポジトリ | Foundry 計算 |
| Pipeline Builder | Foundry 計算 |
| Code Workbook | Foundry 計算 |
| Contour | Foundry 計算 |
| ライブモデル | Foundry 計算 |
| オントロジー | オントロジー量 |
| データセット | Foundry ストレージ |
リソース管理アプリケーションは、組織が Foundry の使用消費を理解するための可視性と透明性を提供します。このアプリケーションを使うと、ユーザーは各 Foundry 使用タイプ（Foundry 計算、オントロジー量、Foundry ストレージ）ごとに分割された Foundry 使用消費を見ることができます。ユーザーはリソース（プロジェクト）、ソース（アプリケーション）、ユーザーごとに使用状況を見ることができます。
Foundry 使用をどこで最適化できるかを特定しようとする場合、最初にチェックするのはリソース管理アプリケーションです。これにより、最も計算を消費しているリソースを見ることができ、ボトルネックがどこにあるかを特定することができます。ここから、Foundry 使用最適化のベストプラクティスを活用して使用を減らす可能性のある方法を特定することができますが、常に覚えておいてください - ボトルネックに焦点を当てます。
上述したように、リソース管理（RMA）内でデフォルトではプロジェクトレベルでコンピューティングリソースが管理されています。RMA内では、プロジェクトごとに Foundry のコンピューティング、オントロジーのボリューム、および Foundry のストレージメトリックスが測定されます。したがって、データパイプライン全体で使用状況メトリックスを効果的に追跡するためには、適切なプロジェクト設定が非常に重要です。適切な設定により、データエンジニアやプラットフォーム管理者が、パイプラインの主要なフェーズでこれらの使用状況メトリックスを監視し、最適化すべき領域を特定できます。不適切な設定では、リソースが重く、計算コストが高いデータパイプラインの部分を特定できなくなります。
Foundry のプロジェクトは、適切に構造化されたデータパイプラインを実現するために使用する必要があります。プロジェクト設定のベストプラクティスとパイプラインの段階については、推奨されるプロジェクトとチーム構造のドキュメントで詳しく説明されています。プロジェクトが推奨される構造に従っていることを確認することで、ユーザーは、パイプラインの主要なフェーズでコンピューティングおよびストレージメトリックスを分析できるようになります。
使用状況削減戦略を検討する際、管理者はチーム内で誰がプロジェクトとリソースを作成する権限を持つべきかを検討する必要があります。設定のベストプラクティスに精通した最小限の人数にこのアクセスを制限することで、プロジェクトとリソースの広がりが抑えられ、不要なストレージとコンピューティングが削減されます。プラットフォーム上で任意のユーザーがプロジェクトを作成できるようにすると、使用状況を追跡するための推奨される構造に反してプロジェクトが作成され、不要で費用のかかるパイプラインが増えることになります。組織は、プラットフォーム上のユーザー数やデータアクセス制限に基づいて、プロジェクト作成アクセスを異なる方法で管理する場合があります。このアクセスを決定し、アクセスを持つ人々に適切なプロジェクト構造を教育するプロセスを開発することが、これらのリソースの適切な使用状況監視を可能にするために推奨されます。
リソース管理アプリケーション内で Foundry の支出を制御するための主要な機能は、リソースキューです。特定のプロジェクトや複数のプロジェクトに関連するコンピューティングパワーの量を制限するために、プロジェクトをキューにまとめることができます。各キューには、一度に使用される最大 vCPU 数を定義する特定のリソース制限が割り当てられます。たとえば、特定のキューに XXX 個の vCPU を割り当てることができ、これが割り当てられたプロジェクトで一度に実行される最大の vCPU 数になります。これにより、各プロジェクトが消費する使用量の可視性と認識が得られます。
インクリメンタル・パイプラインは、時間の経過とともに大幅に変化する入力データセットを処理するためによく使用されます。変更されていないすべての行やデータファイルに対して不要な計算を避けることで、インクリメンタル・パイプラインは、コンピューティング費用を最小限に抑えつつ、エンドツーエンドのレイテンシを低減します。これを実行する方法は、SNAPSHOT トランザクションと APPEND トランザクションの違いを理解することです。
デフォルトのトランザクションタイプは SNAPSHOT です。スナップショットトランザクションは、データセット内のすべてのデータの置き換えとして扱われます。つまり、最新のトランザクションタイプが SNAPSHOT であるデータセットを開いた場合、プレビューには最新のスナップショットトランザクションで受信されたデータのみが含まれます。データ変換や Contour 分析でそのデータセットを読もうとすると、最新のトランザクションからのデータのみが表示されます。
スナップショットは、デフォルトのトランザクションタイプである理由は、使用が最も簡単であるためです。同期が実行されるたびに、データベースクエリから返されるすべてのデータをダウンロードし、以前のデータセットにあったすべてのデータを効果的に置き換えるスナップショットトランザクションを作成します。以前のトランザクションに存在したファイルは、もちろんデータセットの歴史的バージョンで引き続き利用可能ですが、プレビューやデータを使用した下流の変換は、デフォルトで新しいトランザクションにアクセスします。
もちろん、スナップショットトランザクションは正しく使用するのが簡単ですが、毎回すべてのデータをコピーすることは非常に非効率的です。効率改善の可能性のある1つの方法は、代わりに APPEND トランザクションタイプを使用することです。
データセットが追加トランザクションで構成されている場合、デフォルトのビューはすべてのトランザクションの合計です。これは、APPEND トランザクションタイプを使用すると、すでにアップロードしたファイルを同期する必要がなく、Foundry に新しいデータだけが同期されることを意味します。これにより、各トランザクションには追加されたファイルのみが含まれ、ソースシステムで利用可能なすべてのもののスナップショットが含まれないため、Foundry のストレージが削減されます。
Foundry の使用状況を最適化するもう1つの方法は、スケジュールを通じてです。スケジュールは、スケジューラツールで設定され、ビルドを定期的に実行して、Foundry を通じてデータが一貫して流れるようにします。
スケジュールは、組織の要件を満たすように設定する必要がありますが、Foundry の使用状況を最適化するためには、スケジュールが効率的に設定され、必要以上に実行されないようにすることが不可欠です。例えば、毎日午前 8 時にデータセットを更新するスケジュールを設定している場合、実際には毎日午前 8 時に更新されたデータが必要ない場合、組織は Foundry の使用状況を無駄にしています。代わりに、必要なデータが更新される頻度に合わせてスケジュールを設定します。例えば、午前 8 時に隔日更新するようにします。この調整により、Foundry の使用状況が半分になります。
スケジュールを最適化するためのベストプラクティスを考慮する際の 2 つの大きなテーマは、1) 重複するスケジュールの削除と 2) 不要なスケジュールの削除です。
重複するスケジュールを特定するには、まずデータフローアプリケーションにアクセスし、ノードの色を Schedule Count に変更します。特定のノードに関連付けられた複数のスケジュールがある場合、そのノードを選択し、スケジュールの管理ツールを表示します。そこでは、関連するスケジュールを表示し、所有者を確認し、それらを統合できるかどうかを判断できます。
**ベストプラクティスは、パイプライン内の各データセットに対して、関連する 1 つのスケジュールビルドがあることを確認することです。**データセットが 2 つの異なるスケジュールでビルドされると、キューイングや両方のスケジュールの遅延、および無駄なバッチ計算が発生します。
重複するスケジュールを削減するためのもう1つのベストプラクティスは、完全なビルドを避けて、代わりに接続ビルドを使用することです。例えば、オントロジーパイプラインには、生のデータセット、クリーンなデータセット、データ変換が含まれ、最終的にオントロジーで終了する場合があります。生のデータセットで実行するスケジュール 1 つ、クリーンなデータセットで実行する 2 つ目のスケジュール、そして変換されたデータセットで実行する 3 つ目のスケジュールを設定する代わりに、生のデータセットがトリガーでオントロジーデータセットがターゲットである 1 つのスケジュールだけが必要です。
不要なスケジュールを特定するには、データフローアプリケーションにアクセスし、ノードの色を Time since last built に変更します。これにより、最も頻繁に更新されるデータを表示し、これが組織にとって最適な頻度かどうかを判断できます。
頻度とタイミングは、使用量を最適化する上で重要な要素です。組織はどのくらいの頻度でデータを更新する必要がありますか？
また、すべてのビルドを同時にスケジュールしようとしないでください。これにより、デバッグがより効率的になり、コンピューティングが少なくなります。頻度とタイミングを考える際には、組織の要件に戻って確認し、設定する更新レートが組織のニーズを満たすようにすることが重要です。
最後に、スケジュールを設定する際に詳細オプションを確認することが重要です。失敗時にビルドを中止を強制することを検討し、無駄なバッチ計算を削減してください。また、失敗したジョブの許可される試行回数を更新して、最大 5 回の試行に比べて 3 回以下に設定できます。また、ビルド間の分数を少なくとも 1 ～ 3 分に設定して、失敗の原因となったグリッチが解決する時間を与えることも推奨されます。
Sparkは、高速で大規模なデータ処理と分析のためのオープンソースの分散クラスターコンピューティングフレームワークです。Spark は、複数のシステム間で作業を分割し、それらを並行して処理することで、コンピュータが大量のデータや分析をより簡単かつ迅速に処理できるようにします。
最初に断っておきますが、最適化に関する一般的なベストプラクティスとして、特定のボトルネックが特定された場合にのみ、手動で Spark の設定を調整することをお勧めします。これは、手動でオーバーライドされていない変換用に Foundry で新しい最適化機能が順次追加および有効化されているためです。簡単な例として、Spark 3 のダイナミックアロケーションが挙げられます。以前は、変換の実行者数を手動で設定することが非常に重要でしたが、現在では、実行時にこの数が自動的に調整されるため、無駄がなくなりました。
Spark の最適化は、Spark の概念に精通しており、パイプライン内での使用方法をよく理解しているユーザーによってのみ行う必要があります。
Spark の最適化の第一歩は、Spark プロファイルの確認と理解です。「Spark プロファイル」は、Foundry が分散コンピューティングリソース（ドライバーや実行者など）を適切な CPU コア数とメモリ量で設定するために使用する設定です。ほとんどの場合、手動で調整しようと試みるよりも自動プロファイルを使用することをお勧めします。ただし、場合によっては、必要のない大きなドライバーの使用が特定できることがあります。
Spark の使用状況の色付けをデータフローで使用して、より高いプロファイルを使用しているデータセットを特定できます。
以下は、最適化を開始する前に理解しておくべき、いくつかの主要な Spark の概念 と用語です。
Spark プロファイルに加えて、以下のベストプラクティスは、Foundry の使用量を削減する目的で Spark を最適化する際の出発点となります。
count、collect、take など）の使用を意識し、最小限に抑えます。変換（filter、select など）が遅延実行されるのに対して、アクションは計算グラフに制約を加え、潜在的な最適化を防ぎます。