デベロッパー

Google BigQuery の隠れた名機能

2022年8月16日

https://storage.googleapis.com/gweb-cloudblog-publish/images/image1_copy_4.max-2000x2000.jpg

Google Cloud Japan Team

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

BigQuery は驚異的です。Google Cloud の中でも、好きなツールの一つです。幸いなことに、Google も同じように感じているようで、新機能の追加を継続しています。BigQuery ファンには、喜ばしいことです。

どんなに長く BigQuery を使ってきても、時折新しい発見があります。本日は、次の 4 点についてお伝えしたいと思います。

AUTO カラム
マルチステートメントトランザクション
クラスタリング
インデックス

私個人の意見ですが、これらはドキュメントや講演で十分に注目されていない優れた機能です。

AUTO カラム

これはまさに「隠れた名機能」です。この機能について、公式ドキュメントでは確認できません（少なくとも、私は見つけられませんでした）。Google Issue Tracker で触れられているだけです。

データを BigQuery に push した後、別のシステムでスケジュールされたジョブを実行して、新着データを処理したいとします。たとえば、システムが BigQuery から別のストレージにデータを pull しようとする場合や、このシステムがデータに基づいて、1 時間ごとにレポートを実行する必要がある場合などです。いずれの場合でも、同じレコードを複数回処理することは避けたいでしょう。その結果、どのレコードが処理済みで、どのレコードが処理後に追加されたか把握する方法が必要となります。

従来の OLTP DB とは異なり、BigQuery は自動増分列または現在の日時が自動的に入力される列をサポートしていません。これは、ストリーミング API と AUTO 機能を使用していない場合に当てはまります。後者の場合、テーブルスキーマに TIMESTAMP 列を追加し、JSON ペイロードに「AUTO」を割り当てることができます。これにより、BigQuery は、レコードが BigQuery にいつ到達したか示すタイムスタンプを前述の列に自動入力できるようになります。

マルチステートメントトランザクション

BigQuery は OLTP DB ではありませんが、マルチステートメントトランザクションをサポートしています。

技術的に言えば、この投稿を書いている時点では、マルチステートメントトランザクションはプレビュー段階ですが、この機能が間もなく一般提供になることを願っています。

おそらく、トランザクションが何で、どのように使用できるか説明する必要はないでしょう。マルチステートメントトランザクションの詳細は、公式ドキュメントでご確認いただけます。

しかしながら、注目すべき興味深い点がいくつかあります。

トランザクションがテーブル内の行を変更（更新または削除）する場合、同じテーブル内の行を変更する別のトランザクション、または DML ステートメントは同時に実行できません。競合するトランザクションは、キャンセルされます。
トランザクションでは、永続的なエンティティに影響する DDL ステートメントを使用できません。
CURRENT_TIMESTAMP、CURRENT_DATE、CURRENT_TIME 関数は、トランザクション開始時刻のタイムスタンプを返します。
FOR SYSTEM_TIME AS OF 句を使用して、トランザクション開始時刻のタイムスタンプを超えてテーブルを読み取ることはできません。このような操作を行うと、エラーが返されます。
トランザクション内で、マテリアライズドビューは論理ビューとみなされます。トランザクション内のマテリアライズドビューにクエリを実行できますが、同等の論理ビューと比べてパフォーマンスが改善することも、コストが削減されることもありません。

クラスタリング

BigQuery でのクエリの最適化（BigQuery の場合、主にコストの最適化に関するもの）となると、思い浮かぶ最初のアプローチは、テーブルパーティショニングです。

テーブルシャーディングについても、聞いたことがあるかもしれません。では、シャーディングとパーティショニングについて少し説明しましょう。テーブルパーティショニングに関する情報は、公式ドキュメントでご確認いただけます。テーブルシャーディングについては、パーティショニングドキュメントのパーティショニングとシャーディングのセクションを除いて、どこにも説明がありません。これは、シャーディングがレガシーとなった機能であり、デフォルトでは、パーティショニングの使用が必要となっていることを暗示しています。

しかし、利用可能なオプションは、パーティショニングだけではありません。クラスタリングもあります。パーティショニングでは、データがパーティションに分割されますが（必要に応じて、クエリが特定のパーティションのみを読み取れるようにする）、クラスタリングは、関連するデータを同じ場所に配置し、クラスタリング列のフィルタが使用されている場合に、クエリがデータの特定のセグメントにアクセスできるようにすることで機能します。

では、パーティショニングとクラスタリングではどちらが良いのでしょうか？

最初に、このトピックに関する公式ドキュメントがあります。このドキュメントで、たくさんの役立つ推奨事項をご確認いただけます。
次に、パーティショニングは、時間単位列と整数列、および取り込み時間に基づいてのみ可能であるので注意してください。
クラスタリングは、BOOL、GEOGRAPHY、STRING など、他のタイプを数多くサポートしています。さらに、クラスタリングは、最大 4 列のグループをサポートしています。
最後に、両方使用したらどうでしょうか？パーティショニングとクラスタリングの両方を同じテーブルの同じフィールドまたは異なるフィールドに適用できます。

クラスタリングは、インデックスと同じではないことに注意することが重要です（インデックスについては、後で詳しくお話しします）。特定のフィールドをベースにしたクラスタリングの適用は、ポイント検索を意味するものではありません。レコードがまとめてクラスタ化され、特定のクラスタのクエリにのみ課金されるということを単に意味しています。

クラスタの大きさはどれくらいでしょうか？ドキュメントでは、明示されていません。同じフィールドをベースにしたパーティショニングとクラスタリングの両方を使用する場合、もちろん、各クラスタがそれぞれのパーティションを超えることはありません。ただし、パーティションが小さい場合、各パーティションは 1 つのクラスタでのみ構成されることが多いです。その結果、クラスタリングのメリットは見られません。

大小のパーティションのしきい値は何でしょうか？ドキュメントに基づくと、約 1 GB のようです。テーブル全体（または各パーティション）がそれよりも小さい場合、おそらく、クラスタリングからのメリットはないでしょう。