データ接続と統合パイプラインの最適化データセットプロジェクションHive 形式のパーティショニングとの比較

注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。

プロジェクションと Hive スタイルのパーティション分割の比較

プロジェクション(特にフィルター最適化プロジェクション)のユースケースは、Hive スタイルのパーティション分割のユースケースと部分的に重なります。このページでは、次の項目を含め、2つの手法の主な違いを説明します。

自動コンパクション

プロジェクションは、時間の経過とともに差分ファイルが過剰に蓄積されるのを防ぐため、自動的にコンパクションされます。Hive スタイルのパーティション分割で書き込まれたデータセットには、自動コンパクションはありません。

即時利用性

データセットが Hive スタイルのパーティション分割で書き込まれると、読み取り側は最適化されたクエリのメリットをすぐに利用できます。一方、プロジェクションデータセットは、正規データセットでトランザクションがコミットされた後に非同期でビルドされるため、正規データセットで SNAPSHOT トランザクションが行われると、次のプロジェクションのビルドが完了するまで、読み取り側がそのメリットをまったく利用できない期間が生じます。

データ内容の制約

Hive スタイルのパーティション分割で書き込まれるデータセットは、通常、オープンな Apache Parquet 形式で書き込まれます。この形式では、データ内容に特筆すべき制約はありません。一方、フィルター最適化プロジェクションは、いくつかの制約がある独自形式を使用します(特に、非常に長い値を持つ文字列列には対応していません)。

高カーディナリティ列への適合性

Hive スタイルのパーティション分割では、一意の値ごとに1つ以上のファイルが書き込まれるため、高カーディナリティ列で Hive スタイルのパーティション分割を行うと、出力ファイルが過剰に生成されます。フィルター最適化プロジェクションは、高カーディナリティ列(特に時系列データのタイムスタンプ列)を適切に扱えるように設計されています。

対応する利用側のシステム

Spark、Polars、およびその他のクエリエンジンは、Hive スタイルのパーティション分割のメリットを利用できます。一方、フィルター最適化プロジェクションのメリットを利用できるのは Spark(具体的には、Foundry 内で使用される Spark のバージョンである Foundry Spark)のみです。

また、トランスフォームのファイルシステム API を使用する Python または Java のコードでは、Hive スタイルのパーティション分割によってファイルパスに格納される情報を活用して、高度なカスタム最適化を実装できます。プロジェクションは、このような形ではユーザーコードに公開されません。