分析からデータ マネジメントへ: BigQuery の新しいトランザクション機能

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

ここ数年間、BigQuery はフルマネージドで高速なペタバイト規模の分析の代名詞となっています。その列指向アーキテクチャとストレージとコンピューティングの分離により、大規模データセットから分析情報を引き出すためのデータ ウェアハウスとして広く利用されています。

しかし、分析が大規模ではない場合、たとえば以下のような場合はどう対処するべきでしょうか？

• 膨大なテーブルにわたる少数の顧客レコードを、一部のスロットの消費や短時間の実行で変更する

• 一部のデータがどのように変化したかを 1 行ずつ正確に追跡する

• 受信したストリーミング データに即座に対応し、レコードをその場で更新する

従来、このような「トランザクション的な」ニーズを満たすには、データベース ソリューションを探すか、BigQuery を中心に複雑な ETL / ELT パイプラインを構築する必要がありました。BigQuery は分析用で、動的データの操作には別のものを使用するという明確な考え方があったからです。

しかし、状況は変わりつつあります。Google Cloud は、BigQuery を着実に進化させ、これらの境界線を融合して、準リアルタイムのトランザクション型のオペレーションをデータ ウェアハウスに直接組み込む優れた機能を追加してきました。その目的は、BigQuery を従来の OLTP データベースに変換することではなく、BigQuery エコシステム内で一般的なデータ マネジメント タスクをより効率的に処理できるようにすることです。

これにより、複雑な回避策が減り、データの変化への対応が迅速になり、コアデータが存在する場所でより動的で応答性の高いアプリケーションを構築できるようになります。

本日は、この進化を可能にする 3 つの画期的な機能をご紹介します。

1. 効率的なきめ細かい DML ミューテーション: 小さな変更のためにコストのかかるテーブルの書き換えは不要です。BigQuery で、対象を絞った UPDATE、DELETE、MERGE を大幅に向上したパフォーマンスとリソース効率で処理する方法を確認しましょう。

2. 更新と削除の変更履歴のサポート: 単なるスナップショットにとどまらず、BigQuery で UPDATE と DELETE の詳細な履歴を取得し、テーブル内のデータの詳細な監査証跡を提供できるようになりました。

3. ストリーミング データに対する DML によるリアルタイム更新: データの安定を待つ必要はありません。UPDATE、DELETE、MERGE オペレーションを BigQuery にストリーミングされるデータに直接適用し、データの即時修正、拡充、状態管理を可能にする方法を確認しましょう。

これらの機能がワークフローを簡素化し、BigQuery 内で新たな可能性を切り開く方法をご紹介します。それでは実際に見ていきましょう。

1. 効率的なきめ細かい DML ミューテーション

BigQuery はここ数年で、UPDATE、DELETE、MERGE などのデータ操作言語（DML）ステートメントをサポートし、テーブル全体を再作成せずにデータを変更できるようになりました。しかし、これまでは、これらのオペレーション（特に、非常に大きなテーブルに対する小さなターゲット変更）の実行は、期待していたほど効率的ではありませんでした。ここでの課題は「書き込みの増大」です。

DML ミューテーションを実行する場合、BigQuery は変更した行を含む基盤となるストレージ ブロック全体（内部ファイル グループのようなもの）を書き換える必要がありました。ステートメントがブロック内の数行にしか影響しない場合でも、ブロック全体の書き換えが必要となる場合があったのです。「書き込みの増大」とも呼ばれるこの現象は、特にスパースなミューテーション（大きなテーブル内の多くの異なるブロックに散在する変更）の場合、スロットの消費量が大幅に増加し、実行時間が長くなる可能性があります。そのため、特定のユーザー レコードを削除して GDPR の「忘れられる権利」を実装するなどのオペレーションが遅くなったり、費用がかかったりすることがありました。

この問題に対処するために、BigQuery にきめ細かい DML が導入されました。これは、スパースな DML ミューテーション オペレーションを最適化する一連のパフォーマンス強化です。

BigQuery のきめ細かい DML を有効にすると、大きなストレージ ブロックを常に書き換えるのではなく、はるかに細かい粒度でデータを特定して変更できるようになります。最適化されたメタデータ インデックスを利用して必要な変更データのみを書き換えるため、処理、I/O、ひいてはスパース DML で消費されるスロット時間が大幅に削減されます。その結果、DML のスピードと費用対効果が向上するため、頻繁にターゲット データを変更するワークロードで BigQuery をより実用的に使用できるようになります。

世界有数の保険会社である Grupo Catalana Occidente は、きめ細かい DML の機能により、データの変更をリアルタイムで統合できることに大きな期待を寄せています。

「Google BigQuery、SAP、MicroStrategy のインテグレーション プロジェクトでは、BigQuery のきめ細かい DML を有効にしたところ、DML クエリのランタイムが 83% 向上しました。きめ細かい DML により、十分なパフォーマンスを実現し、大量のデータを処理する時間を短縮できます。これは、パイプラインにあるさまざまなデータ イニシアチブを実装するうえで不可欠な機能です。」- Grupo Catalana Occidente、最高データ責任者、Mayker Oviedo 氏

この改善効果を具体的な数値で見てみましょう。違いを確認するには、更新がスパースになる可能性が高い大規模なテーブルが必要です。ここでは、bigquery-public-data.wikipedia.pageviews_2024 データセットのコピーを使用します。このデータセットには約 587 億行が含まれ、サイズは約 2.4 TB です。

（重要な注意事項: 以下のクエリを実行するには、大規模なデータセットをコピーし、大量のデータを処理する必要があります。これにより、料金モデルに基づいて BigQuery のストレージとコンピューティングの費用が発生します。この実験を再現する場合は、そのことを認識したうえで進めてください。）

ステップ 1: テーブルのコピーを作成する

まず、一般公開データセットを独自のプロジェクトにコピーします。変更履歴も有効にします。これは後で使用します。

ステップ 2: ベースラインの UPDATE を実行する（最適化なし）

次に、テーブル全体に点在する行の約 0.1% を変更するスパース更新を実行します。

結果: この更新により、約 6,120 万件のレコードが変更されました。テスト環境では、最適化を有効にしない場合、完了までに約 10 分 49 秒かかり、約 7 億 8,730 万スロット（ミリ秒）が消費されました。

ステップ 3: きめ細かいミューテーションを有効にする

次に、単純な ALTER TABLE ステートメントを使用して最適化を有効にします。

ステップ 4: 最適化された UPDATE を実行する

同様の更新を実行し、再びデータの約 0.1% を変更します。

結果: 今回のアップデート（再び約 6, 120 万件のスパース レコードに影響）は、劇的に速く完了しました。処理時間はわずか 44 秒、スロットの消費量は 5,180 万スロット（ミリ秒）でした。

結果を比較してみましょう。

この結果として、きめ細かいミューテーションを有効にした結果、クエリ時間が約 14.8 分の 1、スロット消費量が約 15.2 分の 1 に大幅に短縮されました。この例は、最適化によって、大規模な BigQuery テーブルでターゲットを絞った DML オペレーションのパフォーマンスと費用対効果が大幅に向上することを示しています。

2. CHANGES TVF による行レベルの履歴の追跡

データが 1 行ずつどのように変化するかを把握することは、監査、予期しないデータ状態のデバッグ、特定の変更に対応するダウンストリーム プロセスの構築に不可欠です。BigQuery のタイムトラベル機能では、テーブルの履歴スナップショットをクエリできますが、個々の UPDATE、DELETE、INSERT オペレーションの詳細なログを簡単に提供することはできません。別の機能である APPENDS テーブル値関数（TVF）は、追加のみを追跡し、変更や削除は追跡しません。

BigQuery の変更履歴関数である CHANGES TVF を入力すると、BigQuery テーブルに追加や変更が行われた詳細な行レベルの履歴にアクセスできます。現存するデータの状態だけでなく、挿入、更新、削除の順序など、データがどのように作成されたかを確認できます。

クエリを実行する変更が発生する前に、テーブルで変更履歴のトラッキングを有効にする必要があるのでご注意ください。BigQuery は、テーブルの構成されたタイムトラベル期間の詳細な変更履歴を保持します。デフォルトは 7 日間です。また、CHANGES 関数では、テーブルの履歴の過去 10 分間のクエリは実行できません。そのため、end_timestamp 引数の値は、現在時刻の 10 分以上前である必要があります。

これをさらに詳しく見ていくために、先ほど Wikipedia のページビュー テーブルに加えた変更を見てみましょう。2024 年 1 月 1 日以降に Google に関する Wikipedia 記事に加えられた変更を探します。

クエリの結果からわかるように、テーブルには 2 つの新しい疑似列、_CHANGE_TYPE と _CHANGE_TIMESTAMP が追加されています。_CHANGE_TYPE 列は、行を生成する変更のタイプを指し、_CHANGE_TIMESTAMP 列は、変更を行ったトランザクションの commit 時刻を示します。

テーブルに加えられた変更を解析すると、次のようになります。

• テーブルは最初に、このレコードの合計 288 回のビューで INSERT を受け取りました。これは、Wikipedia ページビューの一般公開データセットから最初にコピーした結果です。

• テーブルは、最初の DML ステートメントからの UPDATE オペレーションと DELETE オペレーションを同時に記録し、レコードに 1,000 回のビューを追加しました。これは、288 回のビューだった元のイベントが削除され、1,288 回のビューを示すイベントに置き換えられたことを反映しています。

• 最後に、テーブルは 2 回目の DML の UPDATE オペレーションと DELETE オペレーションを同時に記録しました。削除されたのはレコードが 1,288 回表示されたビューで、アップデートされたのは 289 ビューが表示された最後のイベントです。

CHANGES TVF によって提供されるこの詳細な行レベルの変更追跡は、堅牢な監査証跡の構築、履歴をトレースしたデータの異常のデバッグ、さらには BigQuery の変更を他のシステムに準リアルタイムで複製する障害復旧パイプラインの構築に非常に有効です。

3. リアルタイムのミューテーション: ストリーミングされたばかりのデータに対する DML

BigQuery の Storage Write API は、高スループットかつ低レイテンシでデータをテーブルにストリーミングし、すぐにクエリできるようにします。これは、リアルタイムのダッシュボードと即時分析を強化するのに最適です。

Storage Write API では、この新しくストリーミングされたデータを即座にクエリできますが、これまでは、UPDATE、DELETE、MERGE などの DML ステートメントを使用してすぐに変更することはできませんでした。受信データは、まず効率的なデータの取り込みのために設計された、書き込みが最適化された一時的なストレージ（WOS）バッファに保存されます。DML でこれらの行をターゲットできる前は、バックグラウンド プロセスによって、これらの行を自動的にフラッシュして、BigQuery のメインの列型読み取り最適化ストレージ（ROS）に整理する必要がありました。この最適化ステップはクエリのパフォーマンスに不可欠ですが、DML を介して最新のデータに修正や更新を適用するまでに、数分から最大 30 分以上の遅延が頻発していました。

この待機時間はもはや必須のものではありません。BigQuery は、UPDATE、DELETE、MERGE ステートメントの実行をサポートするようになりました。これらのステートメントは、書き込み最適化ストレージに存在する行を直接ターゲットにすることができ、カラム型ストレージにフラッシュされる前に操作が可能です。

これがなぜ重要なのでしょうか。これは、BigQuery 上に構築されたリアルタイム データ アーキテクチャにとって大きな機能強化です。データが到着してからウェアハウス内で操作できるようになるまでの遅延が解消されます。バックグラウンド プロセスの完了の待機や、BigQuery 外部での複雑な取り込み前ロジックの実装を行わずに、受信イベントに即座に反応したり、エラーをその場で修正したり、データが到着した時点でデータを拡充したりできるようになりました。

この機能により、データ ウェアハウス内で次のような強力なシナリオを直接実現できます。

• 即時のデータ修正: センサーが明らかに無効な測定値をストリーミングした場合や、イベントが誤った形式で到着した場合は、取り込み直後に UPDATE または DELETE を実行して、不正なレコードがリアルタイム ダッシュボードやダウンストリームのユーザーに影響を与える前に修正または削除できます。

• リアルタイムの拡充: イベントがストリーミングされると同時に、BigQuery 内の他のディメンション テーブルから検索したコンテキスト情報でイベントを即座に UPDATE します（例: クリックストリーム イベントにユーザーの詳細を追加する）。

• リアルタイムのフィルタリング / フラグ設定: リアルタイムの品質チェックを実装します。受信したデータが検証に失敗した場合は、すぐに DELETE するか、または「検疫」フラグを使用して UPDATE します。

ストリーミング バッファ内のデータに対して DML オペレーションを直接実行できるため、BigQuery でリアルタイム データに基づいて行動するまでのサイクルタイムが大幅に短縮され、ワークフローが簡素化されて、より迅速かつ正確なデータドリブンな対応が可能になります。

動的データ マネジメントのための BigQuery

これまで見てきたように、BigQuery の機能は、従来の分析機能を超えて大幅に拡張されました。大きな飛躍を象徴する機能として、きめ細かい DML、更新と削除の変更履歴のサポート、新しくストリーミングされたデータに対して直接 DML を実行する機能などが導入されました。

低レイテンシの大量トランザクション向けに、専門的な OLTP データベースを BigQuery に置き換えることが目的ではないものの、BigQuery がはるかに汎用性の高いプラットフォームになりつつあることは否定できません。これらの機能強化により、データ実務者は次のことが可能になります。

• 大規模なテーブルでも、ターゲットを絞った UPDATE と DELETE を効率的に実行する

• 監査とデバッグのために、データ変更の正確な履歴を追跡する

• ストリーミング データに準リアルタイムで反応して変更する

これらはすべて、分析ですでに使用している使い慣れたスケーラブルでパワフルな BigQuery 環境内で行われます。この統合により、データ アーキテクチャが簡素化され、複雑な外部パイプラインの必要性が減り、データに対するより迅速かつ直接的なアクションが可能になります。

たとえば、Statsig のような顧客の迅速な構築とスマートな意思決定を実現する大手のプロダクト開発企業は、新しいユースケースに BigQuery を使用できるようになりました。

「BigQuery にきめ細かい DML などの新機能が追加されたことで、Statsig では BigQuery をより多くのトランザクション ユースケースに使用できるようになりました。」- Statsig、スタッフ ソフトウェア エンジニア、Pablo Beltran 氏

次回のプロジェクトで詳細な分析とより動的なデータ マネジメントの組み合わせが必要になったときには、BigQuery ツールキットにこれらの強力なツールがあることを思い出してください。

詳細については、次の Google Cloud の公式ドキュメントをご覧ください。

BigQuery のきめ細かい DML

CHANGES TVF によるデータ変更の追跡

ストリーミング データでの DML の使用

ー BigQuery プロダクト マネージャー、Nick Orlove

ー BigQuery ソフトウェア エンジニア、Bigang Li