パイプラインの種類

Foundryで作成できるパイプラインには主に3つの種類があり、それぞれが以下の基準によって異なるトレードオフを提供します：

• レイテンシ. パイプラインがエンドツーエンドで実行するのにどれくらい時間がかかるか？
• 複雑さ. パイプラインの作成と時間の経過による維持がどれだけ難しいか？
• 計算コスト. パイプラインは計算時間に対して実際にどれくらいコストがかかるか？
• データ規模の変更に対する耐性. あなたのパイプラインにどれだけの追加データが時間とともに流れ込むか？

3つのパイプラインの種類は以下の通りです：

• バッチ パイプラインは、各実行で変更があったデータセットを完全に再計算します。
• インクリメンタル パイプラインは、前回の実行以降に変更があった新しいデータのみを処理します。
• ストリーミング パイプラインは連続して実行し、新しいデータがプラットフォームに到着するとすぐにそれを処理します。

以下では、各種類のパイプライン、そのトレードオフ、そしてこの種類のパイプラインの作成を開始する方法について説明します。便宜上、上述のトレードオフに基づいてパイプラインの種類をまとめた要約表を以下に示します。

バッチ

バッチパイプラインでは、上流のデータが変更されるたびに、パイプライン内のすべてのデータセットが完全に再計算されます。すべてが再計算されるため、パイプラインのエンドツーエンドのパフォーマンスは時間と共に非常に一貫しており、パイプラインのコードと維持の複雑さは最小限です。より多くのユーザーがバッチパイプラインに貢献できるように、バッチパイプラインの作成にはSQLを含む広範な言語とツールが利用可能です。

上述の基準に基づいてバッチパイプラインを検討すると：

• バッチパイプラインのレイテンシは非常に高くなる可能性があります。データがプラットフォームに入るたびにすべてのデータを処理する必要があります。ただし、全体のデータ規模が小さい場合、レイテンシは低くなる可能性があります。
• バッチパイプラインの複雑さは非常に低いです。フィルターやジョイン、集計などのテーブル操作の概念を理解することは通常必要ですが、それ以上の知識はほとんど必要ありません。
• バッチパイプラインの計算コストは高い可能性があります。パイプラインのビルドのたびに大量の再計算が行われるためです。ただし、全体のデータ規模が小さい場合、この要素は無視できます。
• データ規模の変更に対する耐性は低いです。大量の新しいデータがパイプラインに流れ込むと、入力データセットが高ボリュームのイベントを表す場合など、バッチパイプラインは管理不能なほど高額になり、実行に時間がかかりすぎます。

ほとんどの場合、Foundryでパイプライン開発を始めるには、バッチパイプラインを作成し、パイプラインのユースケースが確認されるとともに、インクリメンタル計算をサポートするように拡張するべきです。多くの場合、データ規模が小さい（例えば、数千万行以下）場合、バッチパイプラインを無期限に使用し続けることができます。

パイプラインを将来的にインクリメンタルにする必要があると予想される場合、バッチパイプラインの開発にはPythonまたはJavaを使用することをおすすめします。これらの言語はインクリメンタル計算をサポートしています。

Pipeline Builderでバッチパイプラインを作成する方法を学び始めるか、他の言語のチュートリアルに従ってください：

• Pythonでバッチパイプラインを作成する
• Javaでバッチパイプラインを作成する
• SQLでバッチパイプラインを作成する

インクリメンタル

インクリメンタルパイプラインでは、前回のビルド以降に変更があったデータの行またはファイルのみが計算されます。これは、時間の経過とともに大量のデータが変更されるイベントデータや他のデータセットを処理するのに適しています。全体的な計算量を減らすだけでなく、バッチパイプラインと比較してパイプラインのエンドツーエンドのレイテンシを大幅に短縮することができます。インクリメンタル計算にはPythonとJavaのAPIのみが利用可能です。

上述の基準に基づいてインクリメンタルパイプラインを検討すると：

• インクリメンタルパイプラインのレイテンシは非常に低くすることができます - 分単位です。私たちの経験では、これは組織の要求をほとんど満たすのに十分な低レイテンシです。
• インクリメンタルパイプラインの複雑さは中から高です。タブラー形式のデータフレームという高レベルの概念を操作するだけでなく、インクリメンタルパイプラインの作成と維持には、Foundryのデータセットトランザクションにデータがどのように流れるかを理解し、入力データセットが非インクリメンタルに更新された場合の対処法を知り、時間とともに高パフォーマンスを維持する方法を理解する必要があります。
• インクリメンタルパイプラインの計算コストは、大規模なデータセットでバッチパイプラインよりも低くなる可能性があります。実際に発生する計算量を最小限に抑えることができます。
• データ規模の変更に対する耐性は高いです。新しいデータのみが処理されるため、インクリメンタルパイプラインは、データの大部分が変更されない大規模なデータセットの計算をやり直す必要がありません。

インクリメンタルパイプラインについて詳しく知るためには、以下のリソースを参照してください：

• インクリメンタルパイプライン概要
• Pipeline Builderでインクリメンタルパイプラインを作成する
• Pythonでのインクリメンタルパイプライン
• インクリメンタルパフォーマンスの維持

ストリーミング

ストリーミングパイプラインでは、コードが連続して実行され、Foundryにストリーミングされる新しいデータをすぐに処理します。これにより、レイテンシは最も低くなりますが、複雑さと計算コストは最も高くなります。一般的に、ストリーミングパイプラインについては、計算ジョブを管理するよりもマイクロサービスを管理する方が近いと考えると便利です - ストリーミングパイプラインを成功させるためには、アップタイム、レジリエンシ、ステートフル操作について非常に配慮する必要があります。

上述の基準に基づいてストリーミングパイプラインを検討すると：

• ストリーミングパイプラインのレイテンシは非常に低くすることができます。データが1分以内に利用可能であることが強く要求されている場合、ストリーミングパイプラインが適しているかもしれません。
• ストリーミングパイプラインの複雑さは非常に高いです。これらのパイプラインを作成するには、将来予期しない不安定性を引き起こす可能性のあるステートフル操作など、広範なパターンを避ける必要があります。また、ストリーミングパイプラインは、ダウンタイムが結果として一貫した新鮮なデータに依存するユースケースを中断すると、それをアウトエイジとみなすため、バッチまたはインクリメンタルパイプラインよりも失敗に対する耐性が低い傾向があります。
• ストリーミングパイプラインの計算コストは非常に高くなる可能性があります。新しい入力データを処理するためには常に計算リソースが利用可能である必要があるため、ストリーミングパイプラインの性質上、これは必要です。
• データ規模の変更に対する耐性は高いです。ストリーミングパイプラインは高スループットをサポートするように設計されており、通常、バッチやインクリメンタルパイプラインよりもデータ規模の変化をより高く処理できます。

ほとんどの場合、ユースケースが非常に低レイテンシの要件を持っている場合を除き、ストリーミングパイプラインを作成するのは避けるべきです。インクリメンタルパイプラインは、ほとんどのニーズを満たすために、分単位のエンドツーエンドのレイテンシまでパフォーマンスを向上させることができます。これは、ストリーミングパイプラインの追加の複雑さと計算コストを発生させることなく可能です。

ストリーミングパイプラインについて詳しく知るためには、以下のリソースを参照してください：

• Pipeline Builderでストリーミングパイプラインを作成する

ストリーミングパイプラインの追加ドキュメンテーションは近日中に利用可能になります。ストリーミングパイプラインの作成に興味がある場合は、あなたのPalantir代表者に連絡してください。