BigQuery の内部: 列メタデータ インデックス（CMETA）の力

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

ペタバイト規模のデータ ウェアハウスが一般的になりつつありますが、最新のクラウド データ ウェアハウスであっても、コストと労力を増大させることなく必要なパフォーマンスを得ることは、依然として重要な課題です。多くのデータ ウェアハウス プラットフォーム プロバイダがこれらの課題に取り組んでいる一方で、BigQuery はすでにペタバイト規模のデータ ウェアハウスからペタバイト規模のテーブルへと移行しています。実際、BigQuery ユーザーの中には、200 ペタバイトを超える単一のテーブルと 70 兆行を超えるテーブルを使用しているユーザーもいます。

この規模では、メタデータでさえビッグデータであり、ほぼ無限にスケーラブルな設計と高いパフォーマンスが求められます。2021 年、Google は 2021 年の VLDB 論文で Column Metadata（CMETA）インデックスを発表しました。その名前が示すように、CMETA インデックスはメタデータのインデックスとして機能します。既存の手法と比較して、CMETA はスケーラビリティとパフォーマンスの両方の要件を満たし、優れていることが証明されました。さらに、BigQuery の実装では、ユーザーがメンテナンスを行う必要はありません。クエリのパフォーマンスが透過的に向上するだけでなく、CMETA によって全体的なスロット使用量が削減される可能性もあります。

このブログでは、CMETA の仕組み、ワークロードに与える影響、メリットを最大限に引き出す方法について説明します。それでは詳しく見ていきましょう。

BigQuery でのデータの格納方法

BigQuery テーブルのすべてのデータは、カラムナ フォーマットで編成されたデータブロックとして保存されます。データブロックには、ブロック内のすべての行に関するメタデータも保存されます。これには、ブロック内の各列の最小値と最大値、およびクエリの最適化に使用される可能性のあるその他の必要なプロパティが含まれます。このメタデータにより、BigQuery はきめ細かい動的プルーニングを実行して、クエリのパフォーマンスとリソース効率の両方を向上させることができます。

このアプローチはよく知られており、データ マネジメント業界で一般的に適用されています。しかし、前述のように、BigQuery は膨大なスケールで動作し、ストレージ内の数十億のブロックに分散された 100 ペタバイトを超えるデータを持つテーブルを日常的に処理しています。これらのテーブルのメタデータは、テラバイト規模に達することが多く、これは多くの組織のデータ ウェアハウス全体よりも大きいものです。

列メタデータ インデックスを入力する

特に大きなテーブルが関係するクエリを最適化するために、BigQuery は CMETA を活用するようになりました。このシステムテーブルは、インデックスのメリットを受けられる可能性があるユーザー テーブルのすべてのデータブロックのメタデータのスナップショットを保持するために、BigQuery によって自動的に作成および管理されます。これにより、BigQuery のプランナーに追加のデータが提供され、データブロックのよりきめ細かいプルーニングを適用できるようになります。その結果、リソース消費量（スロット使用量やスキャンされたバイト数）とクエリ実行時間の両方が削減されます。

CMETA は、いくつかの重要な手法に依存しています。

インデックス生成CMETA はバックグラウンドで自動的に生成、更新され、追加費用はかからず、ユーザーのワークロードに影響を与えることもありません。インデックスの作成と更新は、既存のテーブルのサイズやデータの変更量に基づいて、BigQuery がインデックスのメリットがあると判断したときに自動的に行われます。BigQuery では、ユーザーが何も操作しなくても、ブロック統計と列レベルの属性でインデックスが最新の状態に保たれます。効率的なストレージと水平スケーラブルな手法を使用することで、BigQuery は、200 ペタバイトを超えるテーブルを持つパフォーマンスに敏感なユーザーの場合でも、これらのインデックスを大規模に維持できます。

クエリの処理

インデックスが実際にクエリを処理する仕組みを説明するために、BigQuery の一般公開データセットから `natality` テーブルを使用します。このテーブルのデータが 3 つのブロックに保存され（図 1 を参照）、110、120、130 の時点でコミットされたとします。時刻 125 にスナップショットが取得された列メタデータ インデックスには、ブロック 1 と 2 のブロックレベルと列レベルの統計情報が含まれています。

上記のクエリを考慮すると、BigQuery はまずインデックスをスキャンして関連するブロックを特定します。ブロック 2 の `weight_pounds` の最大値は 6.56 であり、クエリは ‘weight_pounds’ >= 7 でフィルタリングするため、ブロック 2 を検査せずに安全にスキップできることがわかります。元のクエリは、ブロック 1 と、まだインデックスが作成されていない新しいブロック（この場合はブロック 3）に対してのみ実行されます。結果が結合され、ユーザーに返されます。

インデックスに豊富な列レベルの属性が含まれているため、BigQuery はクエリ処理の初期段階で効率的にプルーニングできます。インデックスがない場合、プルーニングは BigQuery がデータブロックを開く後段のステージで行われるため、より多くのコンピューティング リソースが必要になります。大規模なテーブルの場合、この手法でデータブロックをスキップすると、選択的クエリに大きなメリットがあり、BigQuery でより大規模なテーブルをサポートできるようになります。上記の例を、数十億のブロックを持つテーブルで考えてみましょう。ブロックのヘッダーにアクセスする必要もなく、不要なブロックを削除することで、時間とスロットの使用量を節約できることを想像してみてください。

BigQuery の CMETA インデックスには、いくつかの点で独自性があります。

• メンテナンス コストや労力がゼロ: CMETA インデックスは完全に自動化されたバックグラウンド処理

• すべてのデータテーブルに適用可能: CMETA は、テーブルサイズがギガバイト単位かペタバイト単位かに関係なく、パフォーマンスを向上させるために透過的に動作します。

• 他の Google Cloud サービスとの統合: BigQuery テーブルと BigLake 外部テーブルで動作

• 安全: CMETA が利用可能かどうか、最新かどうかに関係なく、常に正しい結果を返します。

CMETA の効果の測定

CMETA を早期に導入したお客様からは、クエリのパフォーマンスが最大 60 倍向上し、一部のクエリではスロット使用量が最大 10 分の 1 に削減されたという報告が寄せられています。CMETA はクエリワーカーが処理するデータ量を最小限に抑えるため、選択性の高いフィルタ（特にクラスタリング列のフィルタ）を使用するクエリでは、メリットが特に顕著になります。

CMETA のメリットを最大限に活用

BigQuery は現在、ユーザーに追加費用を課すことなく CMETA を自動的に管理し、ラウンドロビン方式でインデックスの作成または更新にリソースを割り当てています。テーブルが急速に拡大または変化し、パフォーマンス要件が厳しい場合は、CMETA のスループットを最大化するために、CMETA メンテナンス オペレーションに独自のリソースプール（スロット）を使用することを選択できます。これにより、CMETA を介したクエリ パフォーマンスの改善において、最も一貫したエクスペリエンスが提供されます。これを行うには、予約割り当てを作成してバックグラウンド ジョブにスロットを割り当てるだけで、CMETA メンテナンス ジョブが自動的にそれを使用します。詳しくは、ドキュメントをご覧ください。

今後の展開

CMETA の最初のイテレーションは現在一般提供されていますが、Google はすでに将来のイテレーションに取り組んでおり、お客様が追加の労力や費用をかけることなく、BigQuery の自律的なクエリ処理機能をさらに改善する予定です。ご理解、ご協力のほど、どうぞよろしくお願い申し上げます。

ー ソフトウェア エンジニア、James Liu 

ー プロダクト マネージャー Joe Yong