Do GPUs Really Need New Tabular File Formats?

本論文は、Parquet ファイルにおける GPU スキャン性能のボトルネックが形式そのものではなく、非最適で CPU 中心の構成に起因することを示し、Parquet 仕様を変更することなく GPU 感知の設定を適用することで実効読み取り帯域幅を 125 GB/s に向上できることを明らかにする。

要約

あなたのデータである膨大な書籍の図書館が、倉庫（ハードドライブ）に保管されていると想像してください。また、これらの書籍を読み、質問に答える役割を担う超高速のロボット司書（GPU）もいます。

長年、この図書館はParquetと呼ばれる特定の分類システムで整理されてきました。このシステムは人間司書を想定して設計されており、人間が一つずつ取り出しやすいよう、書籍を小さく管理しやすい山に分けています。

しかし、ロボット司書は異なります。ロボットは一度に一つの山しか取り上げないのではなく、数千の腕を持っており、同時に数十の山を掴むことができます。しかし、図書館がまだ人間の用に整理されているため、ロボットは次の山が手渡されるのを待つ時間や、その数千の腕のうちごく一部しか使わない時間の方が長くなります。ロボットは驚くほど高速ですが、図書館の整理方法がそれを妨げているのです。

この論文は、単純な問いを投げかけます：ロボット専用の全く新しい分類システムを考案する必要があるのでしょうか？

著者たちはこう答えます：いいえ。 その代わり、既存の書籍をいくつかの単純なルールで再配置するだけで済みます。

彼らがこの問題を解決した方法は、以下の四つの主要な「交通ルール」を用いたものです。

1. 「より多くの山」ルール（ページ数の増加）

• 問題点: 旧システムでは、セクションのすべてのデータを一つの巨大で重い書籍にまとめていました。ロボットはそれを読み出そうとしましたが、書籍が大きすぎて分割できないため、一度に一つの腕しか使えませんでした。
• 解決策: 彼らはその巨大な書籍を、より小さく薄いページに切り分けました。これにより、ロボットは100の腕を使って一度に100ページを掴むことができます。
• 結果: ロボットは待機することがなくなり、すべての腕を同時に使い果たして忙しく動いています。

2. 「大きな箱」ルール（行グループサイズの増加）

• 問題点: 旧システムは、ロボットに切手サイズの小さなパッケージを送っていました。ロボットが高速であっても、配送トラック（ドライブとロボット間の接続）が、小さすぎるパッケージの多さで渋滞してしまいます。
• 解決策: 彼らは、切手サイズの代わりに、巨大なフルサイズの移動用ボックスを送り始めることにしました。
• 結果: 配送トラックはフルスピードで走行できるようになり、ロボットにデータが絶えず供給されるようになりました。

3. 「賢い梱包」ルール（エンコードの柔軟性）

• 問題点: 旧システムは、汎用的な「すべてに通用する」方法で書籍を梱包していました。時には書籍を小さくすることもできましたが、多くの場合はあまり役立ちませんでした。
• 解決策: 彼らは各書籍を個別に検討し、それを縮小する最良の方法を選択しました。ある書籍に繰り返される単語が多ければ、それを極小にするための特殊なコードを使用しました。もし書籍がすでに短ければ、そのままにしました。
• 結果: 書籍が棚のスペースをより少なく占めるため、配送トラックが運ぶ重量が減り、プロセス全体が高速化されました。

4. 「包まない」ルール（不要な圧縮の排除）

• 問題点: 時には、旧システムがすでに小さな書籍であっても、重い気泡緩衝材（圧縮）で包んでいました。ロボットはその後、それらを解きほぐす時間を費やす必要があり、エネルギーの無駄になっていました。
• 解決策: 彼らは次のように決めました。「気泡緩衝材がパッケージを著しく小さくしないのであれば、使用しないこと」。
• 結果: ロボットは、不要だった書籍の解きほぐし工程をスキップすることで時間を節約しました。

大団円：ロボット対人間

著者たちは、この新しい配置をテストしました。

• 旧来の方法: ロボットは遅く、その超能力をほとんど発揮していませんでした。
• 新しい方法: 既存の Parquet ファイルを再編成するだけで（新しい形式を考案することなく）、データ読み出し速度においてロボットを125 倍高速化しました。

また、ロボットが配送トラックと同期して動作する（読み取りと処理を重複させる）場合、さらに効率が向上することも示しました。実際、この再編成されたロボットはあまりにも高速で、配送トラック自体の理論的な速度限界にほぼ到達しました。

結論

この論文は結論として、図書館を焼き払ってゼロから新しいものを建てる必要はないと述べています。必要なのは、いくつかの賢い調整を加えて書籍を棚に並べ直すことです。

データの梱包とグループ化の方法を微調整することで、既存の Parquet 形式は、現代の GPU 上ですでに雷のような速度で動作できます。これにより、誰もが新しいシステムを学ぶ手間を省き、すべての古いソフトウェアとの互換性を保ちながら、私たちが望んでいた莫大な速度向上を実現できます。

技術概要

技術的概要：GPU は本当に新しい表形式ファイル形式を必要とするのか？

問題定義

Apache Parquet は、現代の分析システムにおける事実上の列指向ファイル形式であるが、そのデフォルトの構成ガイドラインは CPU 中心の実行エンジンによって形成されている。GPU 加速データ処理が普及するにつれ、CPU 向けに最適化された Parquet ファイルは GPU ハードウェアを著しく未活用にし、人工的な性能ボトルネックを生み出している。CPU 側での広範なテストにもかかわらず、Parquet の読み込みは GPU 加速分析における主要なボトルネックのままである。例えば、NVIDIA RAPIDS チームは、TPC-H ベンチマークの実行時間の約 85% がクエリ演算子ではなく Parquet スキャンに費やされていると報告している。これにより、以下の中心的な研究課題が提起される：GPU は本当に新しい表形式ファイル形式を必要とするのか、それとも既存の Parquet 構成を最適化することで高性能を達成できるのか？

手法

著者は、Parquet 構成の選択が GPU スキャン性能にどのように影響するかを評価するための体系的な研究を実施した。実験環境では、単一の NVIDIA A100 GPU を用い、GPUDirect Storage (GDS) を介してローカル NVMe SSD から最大の TPC-H SF300 テーブル（lineitem）を読み込んだ。本研究では、NVIDIA RAPIDS cuDF ライブラリを基盤とし、I/O と GPU 計算を完全にオーバーラップさせる GPU 加速分析システム「PystachIO」を採用した。

手法には以下のステップが含まれる：

1. ベースラインの確立: DuckDB のデフォルト設定（列チャンクあたり 1 ページ、行グループ (RG) あたり 122,880 行、Parquet V1 エンコーディング、標準的な圧縮）を使用して Parquet ファイルを生成する。
2. 構成の反復: ファイルパラメータを体系的に変更し、以下の 4 つの特定の次元をテストする：
   • ページ数: 行グループ (RG) あたりのページ数を GPU カーネルグリッドサイズに一致するように増加させる。
   • 行グループ (RG) サイズ: GDS に適したより大きな I/O ユニットを作成するために、RG あたりの行数を増加させる。
   • エンコーディングの柔軟性: Parquet V1 および V2 の両方の方式から、チャンクごとに最適なエンコーディングを選択できるようにする。
   • 圧縮の選択性: サイズ削減が特定の閾値（10%）を超えない列チャンクでは圧縮をスキップする。
3. ツールの開発: 著者は、ファイル形式仕様を変更することなく、既存の Parquet ファイルをこれらの最適化された構成に変換するParquet 書き換えツール（Rust で記述）を開発した。
4. 性能指標: 評価は、有効な読み取り帯域幅（論理的な生データサイズをスキャン実行時間で割った値）と、さまざまなデータセット規模（最大 SF1000）における TPC-H クエリ（Q6 および Q12）のエンドツーエンドのクエリ実行時間に焦点を当てた。

主要な貢献と知見

本論文は、実験結果から導き出された 4 つの主要な知見を提示する：

1. ページ数の最適化: GPU デコーディングカーネルはページ間で並列化される。デフォルト構成ではページ数が少なすぎることが多く、GPU が未活用になる。ページ数を100 以上に増加させることで、デコーディング効率とストレージバス帯域幅が大幅に向上する。
2. RG サイズの最適化: GPU I/O スタック (GDS) は CPU スタックとは異なり、ストレージ帯域幅を飽和させるために大きな I/O ユニット（MiB スケール）を好む。デフォルトの RG サイズ（約 100 KB チャンクをもたらす）は最適ではない。RG サイズを数百万行（例：1000 万行）に増加させることで、GDS が SSD を飽和させることができる。
3. エンコーディングの柔軟性: エンコーディングを Parquet V1 に制限すると、圧縮効率が制限される。V1 および V2 の両方の方式から最小のエンコード済みサイズを選択できるようにする（例：整数に対して Delta Binary Packed を利用する）ことで、圧縮率が向上する。これにより I/O ボトルネックが軽減され、GPU 上での効率的な V2 デコーディングが活用される。
4. 不要な圧縮の回避: 盲目的に圧縮を適用すると、解凍オーバーヘッドが追加される。本研究は、サイズ削減が10% の閾値未満の場合に圧縮をスキップすることで性能が向上することを示している。これは特に、GPU が計算ボトルネックとなるシナリオ（例：複数の SSD から読み込む場合）で顕著である。

結果

これらの GPU 意識的な構成を完全に準拠した Parquet ファイルに適用することで、著者は以下の結果を達成した：

• 有効帯域幅: 最適化された構成は、4 つの SSD を使用して最大125 GB/sの有効読み取り帯域幅を達成し、ベースラインに対して劇的な改善を示した。
• スケーラビリティ: エンコーディングの柔軟性を適用した場合、有効帯域幅は SSD の数に対して線形にスケーリングしたのに対し、ベースライン構成は早期に飽和した。
• クエリ性能: TPC-H クエリ（Q6 および Q12）において、最適化された Parquet ファイルを使用した GPU システムは、CPU システム（ClickHouse および DuckDB）を大幅に上回り、理論上の最小実行時間（SSD 帯域幅によって定義される）に近づいた。
• 新しい形式は不要: この研究は、新しいファイル形式への切り替えなしに高性能な GPU パフォーマンスを達成できることを示しており、Parquet エコシステムの相互運用性の利点を維持している。

意義と主張

本論文は、高性能な GPU 分析のために新しいファイル形式が厳密には必要ではないと主張している。むしろ、性能格差は主に CPU 中心のデフォルトから継承された最適化されていない構成選択の結果である。

• 実践的ガイダンス: この研究は、GPU データベース向けの Parquet 最適化に関する最初の実践的ガイダンスを提供し、形式の置き換えではなく構成を通じて大幅な加速を可能にする。
• 将来の作業のためのベースライン: 著者は、将来の GPU ファイル形式のための強力なベースラインを確立した。彼らは、提案される新しい形式は、単に最適化されていないデフォルトを上回るだけでなく、これらの最適化された Parquet 構成（約 125 GB/s を達成）を上回る必要があると主張している。
• エコシステムの維持: 既存の Parquet 仕様およびエコシステムとの互換性を維持することで、提案されたアプローチは、プロプライエタリまたは新しい形式への移行に伴うコストを回避する。
• ハードウェア非依存性: GPU に焦点を当てているが、書き換えツールはハードウェア固有ではない。これはターゲットハードウェアの特性に基づいて構成を適用するものであり、あらゆるハードウェアでの頻繁なクエリがこのような書き換えの恩恵を受ける可能性があることを示唆している。

著者は、GPU メモリ内デコーディングを目的とした新しい形式が存在するものの、現実世界のシナリオにおける支配的なボトルネックはストレージ I/O であると結論づけている。したがって、ストレージスループットを最大化し、解凍オーバーヘッドを最小化するために既存の Parquet 形式を最適化することは、全く新しいファイル形式の設計を検討する前に不可欠な即時的なステップである。