注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
Python トランスフォームは、さまざまなデータ処理のニーズに対応するために、複数のクエリエンジンをサポートしています。適切なエンジンを選択することで、ユースケースに最適なパフォーマンス、コスト効率、開発者の生産性を確保できます。
利用可能なクエリエンジンは、DuckDB ↗、pandas ↗、Polars ↗、Spark ↗です。これらにはすべて、シンプルで直感的な API でデータを操作できる Python ライブラリがあります。
DuckDB、Pandas、Polars は、lightweight とも呼ばれる標準のシングルノードコンピュートで利用できます。Spark は分散コンピュートに利用できます。詳しくは、PySpark のドキュメントを参照してください。
次のテーブルは、Python トランスフォームのコンピュート方式ごとに、Foundry の機能が利用可能かどうかを示しています。Pipeline Builder のコンピュートエンジンの比較については、パイプラインタイプのサポート比較を参照してください。
| 機能 | シングルノード (Lightweight) | 分散 (Spark) |
|---|---|---|
| インクリメンタル（差分処理）トランスフォーム | ✓ | ✓ |
| 外部トランスフォーム | ✓ | ✓ |
| Palantir 提供の LLM API：スナップショット | ✓ | ✓ |
| Palantir 提供の LLM API：インクリメンタル | ✓ | ✗ |
| 学習済みモデルの入力 | ✓ | ✓ |
| 学習済みモデルの出力 | ✓ | ✗ |
| メディアセット API：スナップショット | ✓ | ✓ |
| メディアセット API：インクリメンタル | ✓ | ✓ |
| トランザクションの中止 | ✓ | ✓ |
| データセットのマーキング解除 1 | ✓（sever_permissions を除く） | ✓ |
| ソースのマーキング解除 | ✗ | ✓ |
| データが満たすべき条件 | 制限あり | ✓ |
| Tables API | コンピュートプッシュダウンのみ | Foundry 内のコンピュートのみ |
| スキーマを強制して出力を読み取る 2 | ✗ | ✓ |
| 許容実行時間パラメーター | ✗ | ✓ |
| ユーザーとして実行パラメーター（非推奨） | ✗ | ✓ |
| リソースメトリクス | ✓ | ✓ |
1 シングルノードトランスフォームは、stop_propagating と stop_requiring のみをサポートしています。sever_permissions には対応していません。
2 PySpark トランスフォームでは、インクリメンタル出力に書き込まれたデータを、指定したスキーマで読み取ることができます。最初のデータセットトランザクションではスキーマがコミットされないため、これが必要になります。シングルノードトランスフォームでは利用できません。
最適な用途： 迅速な反復開発、探索的分析、小規模なデータセット
Pandas ↗ は、Python エコシステムで広く使われているデータ操作ライブラリーです。迅速なプロトタイピングに優れ、対応するライブラリーの広範なエコシステムを提供します。新しいトランスフォームをはじめるときや、チームが使い慣れたツールで迅速に作業を進める必要があるときは、pandas を使用します。
主な特性：
最適な用途： 本番用データパイプラインと中規模のデータ処理
Polars ↗ は、本番用トランスフォームのデフォルトの選択肢とすべきエンジンです。Rust コアを持つ Apache Arrow ベースのエンジンで、列指向ストレージと遅延評価によって優れたパフォーマンスを実現します。Polars は、DataFrame 操作の使いやすさと、本番ワークロードに必要なパフォーマンスを兼ね備えています。
主な特性：
遅延評価による自動クエリ最適化
単一ノードでのマルチスレッド実行
メモリー効率の高い列指向ストレージ
予測可能なパフォーマンス特性
サポートされている操作では、cudf-polars による GPU アクセラレーションを利用可能 — 詳細については、高度なコンピュートオプションを参照してください
最適な用途： 厳しい低遅延要件のある中規模データ
DuckDB ↗ は、分析ワークロード向けに最適化された、高性能な単一ノードの SQL クエリエンジンです。DuckDB は、低遅延と効率的なリソース使用が求められる中規模から大規模のデータ処理タスクに特に適しています。ただし、DuckDB には Python DataFrame API がなく、データ操作には生の SQL クエリを記述する必要があります。
主な特性：
最適な用途： 大規模なデータ処理と組織のデータ基盤
Spark ↗ は、大規模な分散コンピューティング向けに設計されています。小規模な操作ではオーバーヘッドが大きくなりますが、データが単一ノードの容量を超える場合や、最大のスケーラビリティーを必要とする組織の重要なデータセットを構築する場合には、唯一の選択肢です。
主な特性：
以下のサイズに関する推奨値は一般的な目安であり、すべてのクエリに当てはまるわけではありません。トランスフォームの形式が適切であれば、Lightweight エンジンは単一ノードでテラバイト規模の入力も処理できます。Polars ストリーミングの使用方法の詳細については、Polars 遅延 API のドキュメントで、メモリー容量を超えるデータの加工に関する説明を参照してください。すべてのデータを一度にメモリーに読み込む必要がないクエリは、単一ノードで任意のサイズに拡張できます。
本番用トランスフォームでは、デフォルトの選択肢として Polars からはじめることを推奨します。迅速な反復開発や、エコシステム内の特定のライブラリーが必要な場合は、pandas に切り替えられます。DuckDB は、SQL API の利用や単一ノードのパフォーマンスを最大化する場合に優れた選択肢です。Spark に移行するのは、データ規模によって必要となる場合_のみ_にしてください。通常は、データが 50 GB を超え、フィルタープッシュダウンなどの最適化を利用できない場合が該当します。
| 特性 | Pandas | Polars | DuckDB | PySpark |
|---|---|---|---|---|
| 最適なデータサイズ（非圧縮） | < 1GB | 1-50GB | 1-50GB | > 50GB |
| 最適な行数* | 100万行未満 | 100万～2億行 | 100万～2億行 | 2億行超 |
| 起動時のオーバーヘッド | 控え目 | 控え目 | 控え目 | 大きい |
| メモリー効率 | 低い | 非常に高い | 非常に高い | 高い |
| 構文 | Python DataFrame | Python DataFrame | SQL** | Python DataFrame |
| 処理速度（小規模データ） | 良好 | 優れている | 優れている | 遅い |
| 処理速度（中規模データ） | 低い | 優れている | 優れている | 速い |
| 処理速度（大規模データ） | 不適切 | 変動あり | 変動あり | 優れている |
| 並列実行 | なし | 単一ノード | 単一ノード | 分散 |
| メモリースピル | なし | 限定的 | 自動 | 自動 |
* 各クエリエンジンが処理できる行数は、スキーマによって大きく異なります。これらの数値は、一般的なケースにおけるおおよその目安です。
** オープンソースのアダプターライブラリー（Ibis、SQLFrame）が存在します。
高度な統合には、さまざまなバックエンドに対応する Ibis ↗、Apache DataFusion ↗、DuckDB による生の Parquet ファイルへのアクセス、cuDF ↗ による GPU アクセラレーションを活用した処理があります。
例とガイダンスについては、高度な単一ノードのコンピュートオプションを参照してください。
既存のトランスフォームの多くは Spark を使用しています。これは、Python トランスフォームでは単一ノードのエンジンよりも以前から Spark がサポートされているためです。これらのパイプラインの多くは、単一ノードのコンピュートエンジンに移行すると、より速く実行できるか、リソースの消費量を削減できる可能性があります。ただし、移行がどの程度の効果をもたらすかを判断するのは難しく、書き換えには多くのコストがかかる場合があります。単一ノードのパフォーマンスを最初に把握するために、全面的な書き換えを決める前に、SQLFrame を使用してパイプラインを DuckDB に移行することを推奨します。