BigQuery の仕組み: 高度なランタイムにおけるベクトル化の強化

※この投稿は米国時間 2025 年 6 月 19 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud のデータから AI へのプラットフォーム「BigQuery」の内部では、そのパフォーマンスを発揮できるよう、多くのテクノロジーと専門知識が活用されています。ストレージとコンピューティングを分離することで、独自のリソースを柔軟に割り当てることができ、ペタバイト規模の分析が可能になります。また、圧縮ストレージ、コンピューティングの自動スケーリング、柔軟な料金設定などの機能で効率性を高めています。そして、以前の記事でも説明したように、インフラストラクチャには Borg、Colossus、Jupiter、Dremel といったテクノロジーが活用されています。

BigQuery はクエリのコスト パフォーマンスの限界を打破し続けています。Colossus の L4、ユーザー空間ホスト ネットワーキング、最適化された BigQuery ストレージ形式、最先端のデータセンター ネットワークなど、Google インフラストラクチャのイノベーションにより BigQuery の中核をなすデータ ウェアハウジング技術を包括的にモダナイズできました。このモダナイズにおいて、すべてのクエリで可能な限り最高のコスト パフォーマンスを保証するために、「自動チューニング」と「ユーザーによる介入ゼロ」という基本原則に則っています。これらの改善点は、BigQuery の高度なランタイムにまとめられています。今回のブログ投稿では、これらの改善点の一つであるベクトル化の強化（現在プレビュー版で提供）について紹介します。今後も高度なランタイム ファミリーの他のテクノロジーや手法について詳しく説明していきますので、以降のブログ投稿にご注目ください。

強化されたベクトル化: 次世代のクエリ実行

強化されたベクトル化について説明する前に、ベクトル化されたクエリの実行について説明しましょう。ベクトル化されたクエリの実行では、カラム型データは CPU キャッシュのサイズに相当するブロック単位で、単一命令複数データ（SIMD）方式の命令を使用して処理されます。これは現在、効率的なクエリ処理の事実上の業界標準となっています。BigQuery の強化されたベクトル化は、BigQuery ストレージでのフィルタ評価、クエリ アルゴリズムの並列実行のサポート、特殊なデータ エンコードと最適化手法など、クエリ処理の主要な側面にベクトル化を適用することで、ベクトル化されたクエリ実行を拡張します。では、詳しく見ていきましょう。

データのエンコード

最新のカラム型ストレージ形式では、辞書式圧縮やランレングス圧縮など、スペース効率に優れたデータ エンコードが採用されています。たとえば、100 万行ある列のうち一意の値が 10 個しかない場合、辞書式圧縮ではすべての値を繰り返すのではなく、それらの 10 個の値を 1 回保存して各行に小さい整数 ID を割り当てます。強化されたベクトル化により、このエンコードされたデータを直接処理できるため、冗長な計算がなくなり、クエリのパフォーマンスが大幅に向上します。エンコードされたデータのメモリ使用量が少なくなると、キャッシュの局所性も向上し、ベクトル化の効率がさらに高まります。

たとえば、図 1 に示すように、「Sedan」、「Wagon」、「SUV」という文字列値は辞書にエンコードされ、繰り返し出現する文字列リテラルは、これらの文字列値から構築された辞書内のインデックスを表す整数に置き換えられます。その後、繰り返し出現する整数値はランレングス圧縮でさらに表現できます。どちらのエンコードでも、容量と処理時間を大幅に節約できます。

式の折りたたみと共通部分式の削除

ベクトル化の強化により、辞書式圧縮およびランレングス圧縮されたデータのネイティブ サポートがアルゴリズムに直接統合されます。これと、式の折りたたみ、折りたたみの伝播、共通部分式の削除などの最適化手法を組み合わせることで、クエリ実行プランをインテリジェントに再構築できます。その結果、不必要なデータ処理を大幅に削減、あるいは完全に排除できます。

REGEXP_CONTAINS(id, '[0-9]{2}$') AS shard が辞書式圧縮された入力を受け取るシナリオを考えてみましょう。REGEXP_CONTAINS の計算は一意の辞書値ごとに 1 回だけ行われ、結果の式も辞書式圧縮されるため、評価回数が大幅に減少してパフォーマンスが向上します。

ここでは、辞書式圧縮された入力データに直接計算を適用し、辞書式圧縮されたデータの出力を生成して辞書拡張をスキップします。

ベクトル化の強化により、必要に応じて式を定数に変換することで、式の折りたたみの最適化がさらに進みます。次のクエリについて考えます。

このテーブルの Capacitor ファイルの id が辞書式圧縮されている場合、システムの式折りたたみ機能はすべての辞書値を評価します。その値のいずれにも 2 桁の数字が含まれていないため、REGEXP_CONTAINS 条件が常に false であると判断し、WHERE 句を定数 false に置き換えます。その結果、BigQuery はこのテーブルの Capacitor ファイルのスキャンを完全にスキップし、パフォーマンスが大幅に向上します。もちろん、このような最適化はこの例で使用したクエリだけでなく幅広いシナリオに適用できます。

データ エンコード対応の最適化

Google の最先端の結合アルゴリズムは、可能な限り辞書式圧縮およびランレングス圧縮されたデータを保持するように設計されており、データ エンコードを考慮して実行時に決定を行います。たとえば、結合キーのプローブ側が辞書式圧縮されている場合、その知識を利用してハッシュテーブルの繰り返し検索を回避できます。また、集計中にデータがすでに辞書式圧縮されており、そのカーディナリティがわかっている場合は、ハッシュマップの構築をスキップできます。

並列化可能な結合と集計のアルゴリズム

強化されたベクトル化により、高度な並列化アルゴリズムを利用して結合と集計を効率化できます。特定のクエリ実行モードの Dremel リーフノードで並列実行が有効になっている場合、結合アルゴリズムは複数のスレッドを使用して右側のハッシュテーブルを並列に構築し、プローブできます。同様に、集計アルゴリズムは複数のスレッドでローカル集計とグローバル集計を同時に実行できます。結合アルゴリズムと集計アルゴリズムの並列実行により、クエリの実行が大幅に高速化されます。

Capacitor とのインテグレーションの強化

ベクトル化ランタイムを強化するために Capacitor を再設計し、よりスマートで効率的なものに改良しました。この最新バージョンでは、半構造化データと JSON データをネイティブにサポートし、高度な演算子を使用して JSON データを効率的に再構築しています。Capacitor を使用すると、強化されたベクトル化ランタイムで辞書式圧縮およびランレングス圧縮されたデータに直接アクセスし、データに基づいてさまざまな最適化を適用できます。列全体が同じ値の場合、定数最適化に折りたたみ処理をインテリジェントに適用します。また、列に NULL が含まれていないことが確認された場合、IF_NULL や COALESCE などの NULL を想定する関数の式を削除できます。

Capacitor のフィルタ プッシュダウン

Capacitor は、強化されたベクトル化と同じベクトル化エンジンを利用して、フィルタと計算を効率的にプッシュダウンします。これにより、特定のファイル特性と使用される式に基づいて最適化をカスタマイズできます。このアプローチを辞書式圧縮およびランレングス圧縮されたデータと組み合わせることで、非常に高速かつ効率的なデータスキャンが実現し、式折りたたみなどのさらなる最適化が可能になります。

強化されたベクトル化の活用事例

具体的な例でこれらの手法の効果を示しましょう。強化されたベクトル化により、1 つのクエリの実行時間が 21 倍高速化され、1 分以上（61 秒）かかっていた実行時間が 2.9 秒に短縮されました。

この劇的な高速化を達成したクエリは次のとおりです。

このクエリは、167 のパーティションに分散された 130 億を超える論理行を含むテーブルに対して実行されました。このテーブルは、Capacitor カラム型ストレージ形式で保存され、辞書式圧縮およびランレングス圧縮されたデータで最適化されています。

強化されたベクトル化を使用しない場合

このクエリを通常のクエリエンジンで実行するには、次の手順を実行する必要があります。

• 各パーティションのすべてのデータを読み取り、辞書式圧縮およびランレングス圧縮されたカラム型データを完全に展開します。

• すべての列データ値に対して CAST(source_id AS STRING) と TO_HEX(SHA1(CAST(source_id AS STRING))) を計算します。

• すべての NULL 以外の hash_id 値からハッシュマップを構築します。

強化されたベクトル化を使用する場合

強化されたベクトル化で同じデータセットに対して同じクエリを処理したところ、次の重要な最適化が自動的に適用されました。

• 辞書式圧縮されたデータを保持しながら、Capacitor ファイルのカラム型データを直接スキャンします。

• 共通部分式として識別することで、CAST(source_id AS STRING) の重複する計算を検出して排除しました。

• TO_HEX(SHA1(CAST(source_id AS STRING))) の計算を折りたたみ、その結果として得られた辞書式圧縮されたデータを集計ステップに直接反映しました。

• 集計ステップでは、データがすでに辞書式圧縮されていることが認識されたため、集計用のハッシュマップの構築を完全にスキップできました。

この例ではクエリの速度が 21 倍に高速化されています。これは、強化されたベクトル化ランタイムと Capacitor との緊密なインテグレーションにさまざまな最適化手法を組み合わせることで、クエリ パフォーマンスが大幅に向上することを明確に示しています。

今後の予定

BigQuery の強化されたベクトル化により、クエリの費用対効果が大幅に向上します。社内では、個々の状況によってはクエリ結果が異なる場合がありますが、強化されたベクトル化ランタイムによりクエリのレイテンシが大幅に短縮され、スロット使用率も同程度かそれ以下に抑えられることを確認しています。このパフォーマンスの向上は、強化されたベクトル化と BigQuery のストレージ形式、両方のイノベーションによって実現されています。

私たちは、ストレージ、コンピューティング、ネットワーキングにおける Google のインフラストラクチャの進歩と並行してさらに高度な最適化を継続的に適用し、クエリの効率を高め、高度なランタイムで処理できるクエリの範囲を拡大するよう取り組んでいます。今後数か月で、BigQuery の高度なランタイムの強化されたベクトル化がすべてのお客様に対してデフォルトで有効になりますが、ご利用のプロジェクトでより早期に有効にすることも可能です。次は、BigQuery の強化されたベクトル化を Parquet ファイルと Iceberg テーブルにも提供していきます。

ー ソフトウェア エンジニア、Andrei Maksimenka

ー ソフトウェア エンジニア、Konstantin Stepanyuk