注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
このガイドでは、Foundry の使用量を最適化するための方法とベストプラクティスを紹介します。このドキュメントでは、まず Foundry の使用量がどのように算定されるかを説明し、次に無駄な使用量の特定方法とパイプラインの最適化について説明します。一般的な推奨事項は、組織のリソース消費量の監視と最適化に重点を置いているため、プロジェクトマネージャーやプラットフォーム管理者にも役立ちます。
ここに記載されたベストプラクティスに加えて、Linter は Foundry の状態をチェックしてアンチパターンを検出し、リソースの状態を改善するための独自の推奨事項を提示します。これらの推奨事項を評価して対応することで、コストの削減、オントロジーの最適化、パイプラインの安定性と回復力の向上を図れます。
これらのベストプラクティスをワークフローに適用する方法を検討する際には、パイプラインやワークフローを早い段階で最適化してしまうという、よく知られた落とし穴に陥らないことが重要です。パイプラインの早すぎる最適化は避け、最適化に万能な戦略があるとは考えないでください。
アプローチが妥当かどうかを確認するため、次の順に検討することをお勧めします。
これらの問いにまだ答えられないものがある場合、最適化を成功させるには、さらに事前準備が必要かもしれません。
これを踏まえて、最適化の取り組みの良い例と悪い例を以下に示します。
Foundry の使用量を最適化するための一般的なプラクティスには、次のようなものがあります。
Foundry 使用量は、Foundry コンピュート、オントロジーボリューム、Foundry ストレージの3つの要素で構成されます。
大半のアカウントでは、この3つの指標からなるモデルを採用しています。ただし、一部のアカウントでは使用量の基準が異なる場合があります。Palantir の担当者と契約条件を確認してください。
Foundry コンピュートは、データの統合と分析に使用するツールによって発生します。Foundry コンピュートには、バッチ、インタラクティブ、ストリーミングの3つの主な種類があります。
バッチコンピュートは、「バッチ」方式で実行されるクエリやジョブを指します。つまり、特定のスケジュールに従って、または随時、バックグラウンドで実行されるようにトリガーされます。バッチコンピュートのジョブは、実行されていないときにはコンピュートを消費しません。バッチコンピュートの例には、すべてのトランスフォームジョブ、Contour からのデータセットのビルド、コードワークブック、Data Health チェック、オントロジー/インデックス化済みストレージへの同期があります。
インタラクティブコンピュートは、通常、インタラクティブなユーザーセッションの一部としてリアルタイムで評価されるクエリを指します。ユーザーに高速なレスポンスを提供するために、インタラクティブコンピュートのシステムは、待機状態のコンピュートを常時稼働させています。そのため、インタラクティブクエリは、バッチ評価よりも多くのコンピュートを消費する傾向があります。インタラクティブコンピュートの主な形態は Contour です。Contour のダッシュボード、分析、埋め込みの Contour チャートは、いずれもインタラクティブコンピュートの例です。
ストリーミングコンピュートは、メッセージを継続的に受信し、任意のロジックで処理する、常時稼働の処理ジョブを指します。ストリーミングコンピュートは、ストリームがメッセージを受信できる状態にある時間の長さに基づいて測定されます。ストリーミングコンピュートは、バッチコンピュートやインタラクティブコンピュートと比較して、最もコストが高くなります。ストリーミングコンピュートの例には、ストリーミング変換や Pipeline Builder のストリームがあります。
バッチ、インタラクティブ、ストリーミングのコンピュート使用量は、次の要因によって決まります。
Foundry 使用量の2つ目の構成要素は、オントロジーボリュームです。Foundry 独自の機能の1つに、オントロジーレイヤーがあります。オントロジーは、企業データと組織が重視するオブジェクトの間をつなぐ変換レイヤーです。オントロジーはデータの世界を分類するもので、組織はデータを、その対象を記述する多数の行や列の集計としてではなく、「航空機」や「自動車」といった、より具体的なものとして捉えられます。オントロジーになじみがない場合は、ドキュメントで詳しくはこちら。
オントロジーボリュームは、次の要因によって決まります。
Foundry ストレージは、Foundry のオントロジー以外の変換レイヤーに保存された汎用データを測定します。これは「コールドストレージ」と呼ばれることもあります。
データセットのブランチや過去のトランザクション（およびビュー）は、1個のデータセットが消費するディスク容量に影響します。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 使用量を最適化できる箇所を特定する際に、最初に確認すべき場所は Resource Management アプリケーションです。これにより、どのリソースが最も多くのコンピュートを消費しているかを確認し、ボトルネックがある箇所を特定できます。そこから、Foundry 使用量の最適化のベストプラクティスを活用して、使用量を削減できる可能性のある方法を特定できます。ただし、常にボトルネックに注目することを忘れないでください。
前述のとおり、Resource Management (RMA) では、デフォルトでコンピューティングリソースがプロジェクト単位で管理されます。RMA では、Foundry のコンピューティング、オントロジーのボリューム、Foundry のストレージのメトリクスをプロジェクト単位で確認できます。そのため、データパイプライン全体で使用量のメトリクスを効果的に追跡するには、プロジェクトを適切に設定することが極めて重要です。適切に設定することで、データエンジニアやプラットフォーム管理者は、パイプラインの主要な段階でこれらの使用量のメトリクスを監視し、最適化すべき箇所を特定できます。設定が不適切な場合、データパイプラインの中でリソース消費が多く、計算コストの高い部分を特定できなくなります。
適切に構造化されたデータパイプラインを実現するために、Foundry のプロジェクトを使用する必要があります。プロジェクト設定のベストプラクティスとパイプラインの段階については、推奨されるプロジェクトとチームの構造に関するドキュメントで詳しく説明しています。データソースからの生データのインポートから実際のワークフローに至るまで、プロジェクトが推奨される構造に従っていることを確認することで、ユーザーはパイプラインの主要な段階に沿ってコンピューティングとストレージのメトリクスを分析できます。
使用量を削減するための方策を検討する際、管理者は、チーム内の誰にプロジェクトやリソースを作成する権限を与えるべきかを検討する必要があります。この権限を、設定のベストプラクティスを理解している必要最小限の人数に限定することで、プロジェクトやリソースの乱立を抑え、不要なストレージとコンピューティングの使用を削減できます。プラットフォーム上のすべてのユーザーにプロジェクトの作成を許可すると、使用量の追跡に推奨される構造に反するプロジェクトが作成される可能性が高くなります。その結果、不要でコストの高いパイプラインが生まれ、最終的に使用量が増加します。組織によって、プラットフォーム上のユーザー数やデータアクセスの制限に基づき、プロジェクト作成権限の管理方法が異なる場合があります。これらのリソースの使用量を適切に監視できるようにするため、権限を付与する対象を決定するプロセスを策定し、権限を持つユーザーに適切なプロジェクト構造について教育することを推奨します。
Foundry での支出を制御できる Resource Management アプリケーションの主要な機能の1つが、リソースキューです。特定のプロジェクトまたは複数のプロジェクトに関連する計算能力を制限するには、プロジェクトをキューにまとめます。各キューには、同時に使用される vCPU の最大数を定義する、特定のリソース上限が割り当てられます。たとえば、キューに XXX vCPU を割り当てると、そのキューに割り当てられたプロジェクトで、任意の時点に稼働する vCPU の最大数がその値になります。これにより、各プロジェクトが消費する使用量を可視化し、把握できるようになります。
インクリメンタルパイプラインは、時間の経過とともに大きく変化する入力データセットを処理するためによく使用されます。変更されていないデータのすべての行やファイルに対する不要な計算を避けることで、インクリメンタルパイプラインはコンピューティングコストを最小限に抑えながら、エンドツーエンドの遅延を低減できます。これを実現するには、SNAPSHOT トランザクションと APPEND トランザクションの違いを理解する必要があります。
デフォルトのトランザクションの種類は SNAPSHOT です。SNAPSHOT トランザクションは、データセット内のすべてのデータの置き換えとして扱われます。つまり、最新のトランザクションの種類が SNAPSHOT であるデータセットを開くと、プレビューにはその最新の SNAPSHOT トランザクションで受信したデータのみが含まれます。データトランスフォームや Contour 分析でそのデータセットを読み取る場合も同様で、最新のトランザクションのデータのみが表示されます。
SNAPSHOT は最も使いやすいため、デフォルトのトランザクションの種類になっています。同期が実行されるたびに、データベースクエリから返されたすべてのデータがダウンロードされ、データセット内にそれまで存在していたすべてのデータを実質的に置き換える SNAPSHOT トランザクションが作成されます。以前のトランザクションに存在するファイルは、もちろんデータセットの過去のバージョンで引き続き利用可能ですが、プレビューと、そのデータを使用する下流のトランスフォームは、デフォルトで新しいトランザクションにアクセスするようになります。
もちろん、SNAPSHOT トランザクションを正しく使用するのは簡単ですが、毎回すべてのデータをコピーすることは非常に非効率になり得ます。効率を改善する方法の1つとして、代わりに APPEND トランザクションを使用することが考えられます。
データセットが APPEND トランザクションで構成されている場合、デフォルトのビューはすべてのトランザクションを合わせたものになります。つまり、APPEND トランザクションを使用する場合、すでにアップロードしたファイルを同期する必要はなく、新しいデータのみが Foundry に同期されます。各トランザクションには追加されたファイルのみが含まれ、ソースシステムで利用可能なすべてのデータのスナップショットは含まれないため、Foundry のストレージ使用量が削減されます。
Foundry の使用量を最適化するもう1つの方法は、スケジュールを活用することです。スケジューラーツールで設定するスケジュールは、ビルドを定期的に実行し、Foundry 内でデータが継続的に流れるようにするために使用します。
スケジュールは組織の要件を満たすように設定する必要がありますが、Foundry の使用量を最適化するには、効率的に設定し、必要以上に実行しないことが不可欠です。たとえば、データセットを毎日午前8時に更新するスケジュールを設定していても、実際には毎日午前8時に最新のデータが必要でなければ、組織は Foundry の使用量を無駄に消費しています。代わりに、最新のデータが必要な頻度に合わせて、たとえば1日おきの午前8時にスケジュールを設定します。この調整により、Foundry の使用量を半分に削減できます。
スケジュールの最適化に関するベストプラクティスを考える際に留意すべき最も重要な2つのテーマは、1）重複するスケジュールの排除と、2）不要なスケジュールの排除です。
冗長なスケジュールを特定するには、まず Data Lineage アプリケーションを開き、ノードの色分けをスケジュール件数に変更します。1つのノードに複数のスケジュールが関連付けられている場合は、そのノードを選択し、スケジュールを管理ツールを表示します。そこで、関連付けられたスケジュールを表示し、所有者を確認して、統合できるかどうかを判断できます。
ベストプラクティスは、パイプライン内の各データセットに関連付けられたスケジュール済みビルドが1つだけになるようにすることです。 2つの異なるスケジュールでデータセットをビルドすると、キューでの待機が発生し、両方のスケジュールの処理が遅くなるほか、バッチコンピューティングが無駄になる可能性があります。
冗長なスケジュールを減らすためのもう1つのベストプラクティスは、フルビルドを避け、代わりに接続ビルドを使用することです。たとえば、生データセット、クレンジング済みデータセット、データトランスフォームを含み、最終的にオントロジーに至るオントロジーパイプラインが挙げられます。生データセットで実行するスケジュール、クレンジング済みデータセットを実行するスケジュール、加工済みデータセットで実行するスケジュールという3つのスケジュールを設定する代わりに、生データセットをトリガー、オントロジーデータセットを対象とする1つのスケジュールだけで済みます。
不要なスケジュールを特定するには、Data Lineage アプリケーションを開き、最終ビルドからの経過時間でノードを色分けします。これにより、どのデータが最も頻繁に更新されているかを確認し、その頻度が組織にとって最適かどうかを判断できます。
スケジュールの頻度とタイミングは、使用量を最適化するうえで重要な要素です。組織では、どの程度の頻度でデータを更新する必要がありますか？
また、デバッグをより効率的に行い、コンピューティング使用量を抑えるために、すべてのビルドを同じ時刻にスケジュールしないことを推奨します。頻度とタイミングを検討する際は、組織の要件に立ち返り、設定する更新頻度が組織のニーズを満たしつつ、それを超えないようにすることが重要です。
最後に、スケジュールを設定する際は、詳細設定を確認することが重要です。無駄なバッチコンピューティングを減らすために、一つのジョブが失敗した時点で Build を中止するを有効にすることを検討します。また、失敗したジョブに許可する試行回数を更新して、最大5回ではなく3回以下にすることもできます。さらに、失敗の原因となった一時的な不具合が自然に解消する時間を確保するために、再ビルド間の間隔を少なくとも1～3分に設定することを推奨します。
Spark は、大規模なデータ処理と分析を高速に行うためのオープンソースの分散クラスターコンピューティングフレームワークです。Spark は、処理を異なるシステムに分割し、すべての処理が順番に完了するのを待つのではなく並列で実行することで、コンピューターによる大量のデータ処理や分析をより簡単かつ高速にします。
最初の注意事項として、また最適化に関する一般的なベストプラクティスとして、Spark の設定を手動で調整するのは、特定のボトルネックが見つかった場合のみにとどめ、プラットフォーム全体で日常的に行わないことを推奨します。これは、手動のオーバーライドがないトランスフォームに対して、Foundry で新しい最適化機能が順次追加され、有効化されるためです。わかりやすい例として、Spark 3 で導入された動的割り当てがあります。以前はトランスフォームのエグゼキューター数を手動で設定することが非常に重要でしたが、現在は無駄を避けるため、実行時にこの数が自動で調整されます。
Spark の最適化は、Spark の概念に精通し、パイプライン内での使われ方を十分に理解しているユーザーのみが行うべきです。
Spark の最適化の第一歩は、Spark プロファイルを確認して理解することです。「Spark プロファイル」は、Foundry が分散コンピューティングリソース（ドライバーやエグゼキューターなど）に適切な量の CPU コアとメモリーを割り当てるために使用する設定です。ほとんどの場合、手動で調整するのではなく、自動プロファイルを使用することを推奨します。ただし、不要な大規模ドライバーが使用されていることを特定できる場合もあります。
Data Lineage の Spark 使用量による色分けを使用すると、より大きなプロファイルを使用している可能性のあるデータセットを特定できます。
最適化を始める前に理解しておくべき主要な Spark の概念と用語を以下に示します。
Spark プロファイルに加えて、Foundry の使用量を削減するために Spark を最適化する際は、以下のベストプラクティスが出発点となります。
count、collect、take など）の使用に注意し、最小限に抑えます。遅延実行される変換（filter、select など）とは異なり、アクションは計算グラフに制約を課し、最適化の可能性を制限します。ワークフローで複数の単一出力トランスフォームと複数出力トランスフォームのどちらを使用するか検討している場合は、複数出力トランスフォームを最適化するガイドを参照してください。