NVIDIA GQE を用いた GPU アクセラレーションされたクエリエンジンの設計

GPU アクセラレーションされたクエリエンジンは、しばしばメモリと I/O バンド幅によって制約されます。NVIDIA のハードウェアの進展——高帯域幅メモリ（HBM）、[NVIDIA NVLink-C2C](https://www.nvidia.com/en-us/data-center/nvlink-c2c/)、および [NVIDIA GB200 NVL4](https://www.nvidia.com/en-us/data-center/gb200-nvl72/) に特徴的な専用デコンプレッションエンジン——は、有効なストレージ容量の増加、CPU と GPU 間のデータ移動の加速、ストリーミングマルチプロセッサ（SM）リソースを消費せずにデータアクセスを高速化することで、これらのボトルネックを取り除くのに役立ちます。 本稿では、データベースがこれらの技術をどのように活用して GPU でのクエリ実行を加速できるかを示します。効率的な CPU-GPU データ移動、圧縮、パーティションプルーニング、計算とのデータ転送のオーバーラップに関する技術について学びます。 ## GQE のアーキテクチャ概要 GQE（GPU Query Engine）は、最新の NVIDIA ハードウェア上で大規模データセットに対して SQL クエリを高性能で実行するために設計された参照アーキテクチャです。内部では、GQE は [NVIDIA cuDF](https://developer.nvidia.com/topics/ai/data-science/cuda-x-data-science-libraries/cudf) および他の NVIDIA CUDA-X ライブラリ——[CCCL](https://github.com/nvidia/cccl)、[nvCOMP](https://developer.nvidia.com/nvcomp)、[nvSHMEM](https://developer.nvidia.com/nvshmem) など——を使用しています。 GQE は、クエリエンジンに対して以下のような影響を与える可能性があります： - 実行を GPU へ移行する。 - デコンプレッションを nvCOMP へ移管する。 - データ形式を GPU に親和的なものにする。 - GPU 上で実行する際のエンドツーエンドのパフォーマンスギャップを埋める。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/06/agentic-ai-diagrams-architecture-overview-gqe-fig-2-1920x1080-1.webp)*図 1. SQL クエリは GQE の 3 つのアーキテクチャ層（クエリ、データ、実行）を流れ、GPU アクセラレーションされたものとなる* 図 1 では、GQE をクエリ層、データ層、実行層に分解することで、システム設計の概要を示しています。これらは、SQL クエリと入力データをハードウェアレベルの実行へと移行させる役割を担います。各層は以下のように連携します。 **クエリ層**は、SQL パーサとクエリオプティマイザを備え、実行エンジンを補完します。この層は、GQE での実行のためにオープンソースのクエリプラン形式である Substrait プラン（Substrait）をネイティブに受け入れます。Substrait を用いることで、既存のデータベース製品からクエリプランをエクスポートし、それを GQE で実行することで、GPU 実行のメリットを検証することが可能になります。図 2 では、Apache DataFusion が SQL 文字列を Substrait プランに変換します。GQE はこのプランを最適化された論理クエリプランとして取り込み、GQE 固有の改良を加えて、物理プランへと変換します。 **データレイヤー**は、実行エンジンによる高速アクセスのためにユーザーデータを保存・整理します。GQE では、ストレージは抽象化され、異なるデータ形式やストレージ媒体を処理するプラグイン可能な専用リーダーに分割されています。現在、GPU メモリ、CPU メモリ、ディスクをサポートしています。本稿では、高性能な GQE のメモリ内テーブルフォーマットに焦点を当て、このデータが CPU メモリに保存されていると仮定します。GQE は必要なときにデータチャンクを GPU へ転送し、フルセットのデータを GPU メモリに保持することなく、GPU に負荷を飽和させます。チャンクが GPU に到着すると、データレイヤーは実行レイヤーに引き継ぎます。 **実行レイヤー**は、物理的なクエリプランを実行してクエリ結果を生成します。GQE は物理プランをタスクグラフとして生成し、これが実行スケジュールを定義します。このタスクグラフには、オープンソースの [NVIDIA cuDF ライブラリ](https://developer.nvidia.com/topics/ai/data-science/cuda-x-data-science-libraries/cudf) に基づいて構築された関係演算子が含まれており、同ライブラリは高度に最適化された CUDA C++ コードでこれらの演算子を実装しています。データレイヤーがチャンク単位で転送するため、GQE は演算子を分解し、パイプライン処理される CUDA ストリーム上でそれらのチャンクに対してタスクを並列実行できます。 要約すると、GQE は GPU ネイティブな設計を通じて、ハードウェアの高いスループットを引き出します。 ## データレイアウトと転送オーケストレーション GQE データレイヤーは、ホストメモリからデバイスメモリへのデータ転送を効率的に行うように最適化されています。スループットの最大化と移動するデータの量削減により、データ転送の遅延を最小限に抑えています。以下では、転送遅延の最小化に不可欠な、インメモリーデータレイアウトとホストからデバイスへの転送オーケストレーションの概要を示します。 **GQE の設計目標** GQE は cuDF を基盤としているため、GPU 内のデータは cuDF ネイティブテーブルとして構造化されていることを前提としています。一方、ホストメモリのレイアウトは、NVIDIA NVLink C2C や PCIe 向けの転送を最適化できます。Memcpy（cudaMemcpy）は標準的な転送方法です。このアプローチでは、CPU が GPU の実行をオーケストレーションし、データをバッチ転送します。これにより、圧縮転送の基礎も形成されます。 **データレイアウト** ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/06/image-26.webp)*図 2. GQE のインメモリーテーブル形式は、GPU への効率的な転送のために列データを行グループとパーティションに整理します* 図 2 は、表データレイアウトを示しており、これは水平方向に行グループに細分化されています。各行グループは列で構成され、メタデータをカプセル化しています。行グループ内では、GQE は列を非連続的なパーティションとして保存します。転送時には、ストレージレイヤーが一連のパーティションを cuDF カラムに変換します。これにより、データレイヤーは圧縮とパーティションプルーニングの実装詳細を実行層から隠蔽します。 **転送オーケストレーション** ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/06/image-29.webp)*図 3. パイプライン並列化により、行グループ全体にわたってスケジューリング、データ転送、デコンプレッション、GPU 実行を重畳させ、転送速度を向上させる* 図 3 では、CPU が転送をどのようにオーケストレーションするかを示しています。CUDA のベストプラクティスに従い、転送にはパイプライン並列化（pipeline parallelism）を使用してハードウェアコンポーネントを効率的に活用します。パイプライン化された転送は複数のステージで構成されます。圧縮されパーティション分割されたデータの場合、4 つのステージがあります。 - ステージ 0 では、ホストスレッドがスケジューリングを実行します。スケジューリングには、転送するメモリー範囲の計算、宛先バッファの割り当て、必要な CUDA メソッドの呼び出しが含まれます。 - ステージ 1 では、GPU が H2D（Host to Device）転送を実行します。 - ステージ 2 でデータのデコンプレッションを行います。 - ステージ 3 はデータレイヤーの外側に追加されたもので、CUDA カーネルがクエリを計算するステージです。 これら 4 つのステージは重畳（オーバーラップ）させるべきです。理想的には、クエリ実行時間は最長の実行時間を要するステージに等しくなり、残りのすべてのステージはパイプラインによって隠蔽されます。 ## データ転送最適化 高速なデータアクセスは、GQE が達成したパフォーマンス上の優位性において重要な役割を果たします。主に採用されているデータアクセスの最適化手法として、圧縮（compression）とパーティションプルーニング（partition pruning）があります。以下でこれらの最適化がどのように機能するかを説明します。 ## 圧縮 GQE は圧縮から主に 2 つの恩恵を受けます。すなわち、クエリ処理可能なデータセット容量の拡大とクエリの高速化です。圧縮により、与えられたメモリ割り当て量で処理できるデータセットサイズを、メモリアップロード全体の削減によって拡張できます。圧縮されたバッファ間のデータ転送に GPU による高速なデコンプレッション（復元）を組み合わせることで、NVLink C2C のような高速な相互接続上であっても転送速度が向上します。GQE は、従来のフォーマットと比較して圧縮率の向上と優れた GPU デコンプレッション速度を提供する、GPU 最適化されたフォーマットでデータセットを圧縮します。 **NVIDIA nvCOMP ライブラリ** [NVIDIA nvCOMP](https://developer.nvidia.com/nvcomp) は、GPU 加速による圧縮およびデコンプレッション（復元）のためのライブラリです。標準的なフォーマットと GPU 最適化された圧縮フォーマットの範囲を提供しています。ユーザーは、圧縮率、圧縮処理速度、およびデコンプレッションスループットをバランスさせるために、サポートされているアルゴリズムから選択できます。nvCOMP は、その高レベルインターフェース内で lz4hc などの CPU ライブラリをラップし、追加の構成オプションを提供します。GQE では、圧縮およびデコンプレッションルーチンに nvCOMP を使用しています。 **NVIDIA Blackwell デコンプレッションエンジン** NVIDIA は、[NVIDIA Blackwell](https://www.nvidia.com/en-us/data-center/technologies/blackwell-architecture/) アーキテクチャにおいて新しいデコンプレッションエンジン（DE: Decompression Engine）を導入しました。これにより、nvCOMP は SM（Streaming Multiprocessor）リソースを使用せずに、LZ77 ベースの LZ4、Snappy、Deflate などのフォーマットを高速にデコンプレッションできます。複数の CUDA ストリームを使用する場合、DE によるデコンプレッション、SM カーネル、および CE コピーは完全にオーバーラップさせることが可能です。 単一の NVIDIA Blackwell B200 GPU 上の DE は、データベースアプリケーションにおいて最大 400 GB/s に達します。例えば、圧縮率が 4 倍の場合、有効なホストからデバイスへのスループットが約 400 GB/s を達成しつつも、100 GB/s の C2C（Chip-to-Chip）ホストからデバイスへの帯域幅を確保できます。残りの帯域幅は、SM でデコンプレッションされるエンコードデータを含む他のデータの転送に活用できます。 **NVIDIA GQE の圧縮アプローチ** 図 4 はハイブリッド圧縮アプローチを示しており、構造化データ内の特定のパターンを可能な限り利用するために軽量アルゴリズム（[Cascaded](https://docs.nvidia.com/cuda/nvcomp/cascaded.html) など）を使用し、良好な圧縮率を達成するために LZ ベースのアルゴリズムが必要となる場合には DE を使用します。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/06/image-30.webp)*図 4. nvCOMP Cascaded フォーマットチェーンは、デルタエンコーディング、ランレングスエンコーディング、ビットパッキングを組み合わせて、カラム型データを効率的に圧縮します* 与えられた列を圧縮する方法を検討する際、クエリエンジンにはいくつかの選択肢があります。各列に対してユーザーにアルゴリズムを指定させることも可能ですが、非常に大規模なデータベースではこの方法は扱いにくくなります。私たちが採用したアプローチは、LZ4 と Cascaded の両方のアルゴリズムを試すことです。LZ4 は他の LZ77 専用圧縮器と比較して高い圧縮率を実現し、デコンプレッションエンジン（Decompression Engine）でもサポートされているため、汎用データに対する私たちの選択となっています。 使用する圧縮アルゴリズムを決定するために、データを LZ4 と Cascaded の両方のアルゴリズムで圧縮します。Cascaded は B200 上で約 500 GB/s という極めて高速な圧縮レートを実現できます。これにより、データ読み込み段階でのオーバーヘッドを大幅に増やすことなく、追加のアルゴリズムを試すことが可能になります。 Cascaded と LZ4 のどちらを使用するかは、以下の2つのヒューリスティック（経験則）を用いてバランスを取ります： - Cascaded と LZ4 は異なる圧縮率の閾値を持っており、それぞれそのアルゴリズムを使用するための最小条件を定めています。 - Cascaded が LZ4 よりも選択されるためには、LZ4 の圧縮率よりも高い圧縮率を達成する必要があります。トリガーとなるのは、LZ4 の圧縮率に対して設定可能な倍数です。 私たちはアルゴリズムの選択を通じて、C2C バンド幅（GPU 間通信帯域）、デコンプレッションエンジン（DE）、および SM（ストリーミングマルチプロセッサ）リソースのバランス調整を図っています。 ## パーティションプルーニング データを CPU から GPU に転送する前に、GQE は**フィルタプルーニング**を採用し、クエリの結果に寄与しないパーティションをスキップします。このメカニズムは、テーブルの内容を要約したメタデータと、SQL クエリで定義された述語（predicates）に基づいています。 **メタデータとストレージ** GQE はゾーンマップを使用してフィルタプルーニングをサポートします。データをメモリ内テーブルとして読み込む際、GQE はテーブルを水平方向に分割し、行グループと固定サイズのパーティション（デフォルトは 10M 行）を作成します。各パーティションに対して GQE は全列の最小値および最大値を計算し、このメタデータを GPU メモリ内の cuDF テーブルとして保存することで、プルーニング処理がボトルネックとならないようにしています。ゾーンマップの計算には初期の Parquet 読み込み時間に約 1% の追加コストがかかりますが、これは一度だけ実行され、クエリ実行中には行われません。 **プルーニングとタスクオーケストレーション** ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/06/image-27.webp)*図 5. フィルタープルーニングは、パーティションレベルのゾーンマップに対してクエリ述語を評価し、転送前に不要なデータをスキップすることで、GPU へのデータ移動量を削減します* 図 5 はフィルタプルーニングのプロセスを示しています。タスクグラフ構築中に、GQE はクエリ述語を行グループのゾーンマップに対する比較に変換することで、プルーニング式を導出します。クエリの結果に貢献できないパーティションはプルーニングされます。この例では、ゾーンマップがこのパーティションに格納されているすべての値が 9 よりも小さく、したがって下限である 15 よりも小さいことを示しているため、パーティション 1 がプルーニングされます。残りのパーティションは GPU メモリへ転送され、必要に応じてデコンプレッションされます。プルーニング後に CPU メモリ内でパーティションが不連続であっても（例えば複数の行グループに含まれている場合）、それらは転送されて GPU 上で cuDF テーブルとしてラップされた連続したメモリブロックに組み立てられます。 GQE におけるフィルタプルーニングは非常に効果的です。1 TB スケールのデータセットを使用した TPC-H ベンチマークでは、22 クエリ全体でデータの 31% がスキップされます。その結果、エンドツーエンドの速度向上が 1.43 倍となりました。 ゾーンマップの評価によるオーバーヘッドは平均してわずか 2.2 ms で、1 TB のデータに対するベンチマーククエリにおいて最小限に抑えられています。 **データ転送最適化** GQE では、パーティション向けの革新的な**バッチ転送**最適化を考案しました。 複数のパーティションは cudaMemcpyBatchAsync を使用して単一のバッチで GPU に転送され、細粒度のパーティションに対するオーバーヘッドが削減されます。バッチ処理はまた、インターリーブされた CUDA ストリームに起因する遅延を回避するのに役立ちます。パーティションを個別に転送する場合、他のストリームからの転送が次のカーネル起動を遅らせる可能性があります。同じバッチ内でパーティションを移動させることで、この遅延を回避できます。 ## パフォーマンスのハイライト 上記の B200 GPU 機能を Grace Blackwell システム全体で評価するため、NVIDIA GB200 NVL4 サーバー内の 2 つの B200 GPU のいずれかを使用して、Grace CPU と NVLink-C2C で接続された環境で TPC-H をスケールファクター 1000（1TB）でベンチマークしました。ベースラインとして Turin Epyc 9755 CPU 上で DuckDB 1.4.1 を使用しました。各クエリは、両側で圧縮とプルーニングを有効にした状態で、ホットキャッシュ状態での 5 回の実行の平均値です。GQE のパラメータ（並列度のレベルや物理演算子の計画など）は、クエリごとに調整しています。 TPC-H データセットは、lineitem テーブルを l_shipdate でクラスタリングし、orders テーブルを o_orderdate でクラスタリングしてパーティションプルーニングと圧縮に最適化されており、両方のテーブルを月単位でパーティショニングしています。内部では、各パーティションはそれぞれ l_orderkey と o_orderkey に対してソートされています。 図6では、22件のクエリのランタイムを示しています。GQEは22件中20件でDuckDBを上回っており、特にQ11、Q14、Q15において大きな改善が見られました。これらはパーティションプルーニングと圧縮により、NVLink C2C間でのデータ転送が劇的に削減された結果です。GQEは、これらの最適化を適用することで、帯域幅を多く消費するクエリであるQ1やQ6でさえもGPU上で高速に実行できることを示しています。総じて、GQEは全クエリを9.0秒で完了しますが、DuckDBのシングルソケット構成では74.0秒、デュアルソケット構成では70.6秒を要します。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/06/image-31.webp)*図6。NVIDIAによるテスト結果。GB200 GPU 1基上のGQEは、TPC-Hベンチマーク（スケールファクタ1TB）において、デュアルソケットAMD Turin CPUのDuckDBを90%以上のクエリで上回ります* ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/06/image-32.webp)*図7。GQEは最適なCPU構成に対して集計で7.5倍の高速化を実現し、個別のクエリごとの改善幅はほぼ同等から25倍以上に及ぶ* 速度向上の結果を図7に示します。GQEはDuckDBの最良のCPUソケット構成に対し最大25.5倍の高速化を達成し、22件中20件で上回りました。また、17件のクエリで3倍以上の改善を実現しています。全クエリを集計すると、GB200上のGQEは総実行時間で7.5倍の高速化を達成します。 *本ブログ記事におけるテスト結果はTPC-H意思決定支援ベンチマークに基づいており、公開されたTPC-Hの結果とは比較できません。これは、本ブログ内のテスト結果がTPC-H仕様に準拠していないためです。* ## GQE のベストプラクティスをデータプラットフォームに適用する データベースエンジンでは、ターゲットを絞った最適化を行うことで、NVIDIA Grace Blackwell ハードウェアの機能を測定可能なクエリパフォーマンスの向上に変換できます。GQE では、パーティションプルーニングとハイブリッド圧縮により転送量を最小限に抑えつつ、NVLink-C2C と DE ハードウェアが転送スループットを向上させます。これらの最適化は転送時間を短縮し、[NVIDIA cuDF](https://developer.nvidia.com/topics/ai/data-science/cuda-x-data-science-libraries/cudf)、[NVIDIA nvCOMP](https://developer.nvidia.com/nvcomp)、およびその他の CUDA-X ライブラリを用いた洗練されたクエリ実行へと統合されます。 TPC-H SF1000 ベンチマークにおいて、GQE は最先端の CPU データベースと比較して総実行時間で 7.5 倍の高速化を達成しました。これは、データレイアウト、圧縮戦略、および実行方法を現代のデータベースエンジン向けに一体的に設計できることを示しています。 GQE の [オープンソース参照アーキテクチャ](https://github.com/rapidsai/gqe) を活用し、設計とパフォーマンス最適化を検討して、GQE がどのようにデータプラットフォームを加速できるかを探求してください。 ## 謝辞 著者らは、GQE に対する技術的貢献と本稿のレビューを行っていただいた Tanmay Gujar に感謝いたします。また、Hao Gao、Yadu Kiran、James Xia、Eyal Soha、Lingyan Yin、Daniel Juenger、Siyuan Lin、Bret Alfieri、Nico Iskos、Zhengru Wang、Rui Bao、Dhruv Sundararaman、Jiachun Li、Kate Cheng といった GQE のすべての貢献者の方々にも、技術的貢献に対して心から感謝申し上げます。最後に、レビューを行っていただいた Nikolay Sakharnykh と Nuttiiya Seekhao にもお礼を申し上げます。

NVIDIA GQE を用いた GPU アクセラレーションされたクエリエンジンの設計

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト