個人的にうれしかった 2024 年 BigQuery アップデート 7 選 #cm_google_cloud_adcal_2024
2024.12.21こんにちは、みかみです。
好きな Google Cloud サービスは BigQuery です。
本記事は、クラスメソッドのGoogle Cloud Advent Calendar 2024 の 21 日目のエントリです。
Google Cloud 好きなクラスメソッド社員が紡ぐ今年のクラスメソッド Google Cloud Advent Calendar 2024、最終日の25日までお楽しみいただけたら幸いです！
はじめに
今年も BigQuery では多くのアップデートがありました。
Gemini 関連のアップデートが目覚ましかった印象で、よりユーザーフレンドリーで使いやすい BigQuery の進化にわくわくが止まりません。
今年一年の振り返りかねて、BigQuery にどんなアップデートがあって、どんなアップデートにときめいたか、考えてみました。
日頃、BigQuery を DWH とするデータ分析基盤（データパイプライン）構築の業務を担当しています。
振り返ってみると、アップデートの中でもやはり業務で使っていたり、特に困った経験があるものに関連するものが印象に残っています。
そのため、本エントリでは Gemini in BigQuery や BQML 関連のアップデートはご紹介しておりませんのでご了承ください。
テーブルパーティション数上限緩和
The maximum number of partitions per partitioned table limit has changed from 4,000 to 10,000.
BigQuery では、テーブルにパーティションを設定することで、SQL 実行時のパフォーマンス向上やコストを削減することができます。
また、パーティショニングテーブルでは、パーティション単位でのライフサイクル設定が可能だったり、長期間利用のない範囲のパーティションデータは長期保存ストレージになってくれるので、ストレージコストの効率化も期待できます。
パーティション分割のキーには整数型（INTEGER）のカラムも指定できますが、日時型（DATE, TIMESTAMP, DATETIME）を指定するケースが多いのではないかと思います。
分割単位は、時間、日、月、年と自由に指定することができますが、データを分析に利用する場合など、日毎の集計ができるようになっていた方が便利ではないかと思います。
日単位でパーティション分割されたテーブルを定義する場合、これまでのパーティション数上限（4000）では約10年分までのデータしか格納できませんでした。
過去データがたくさん溜まったテーブルを BigQuery に移行する場合に日単位のパーティションが設定できずにやむを得ず月単位で設定したり、今はまだ余裕があるけどこのままデータが溜まっていったらいつかパーティション上限に達してメンテナンスが必要になるという懸念に怯えたり、これまでのパーティション上限数は少し悩みの種でした。
その上限数が 10,000 に緩和されたことにより、これからは日単位のパーティションでも約27年分のデータが格納できるようになりました。
BigQuery が一般提供開始されたのが2011年なので、BigQuery を初期から利用していたら、そろそろパーティション上限に達するケースも増えてくる頃ではないでしょうか。
ということは、15年後にはさらに上限緩和される？などと邪推をしつつ、個人的に今年一番印象に残ったアップデートでした。
クロスクラウド結合
You can now use cross-cloud joins to run queries that span both Google Cloud and BigQuery Omni regions. This feature is in preview.
The following BigQuery cross-cloud features are now generally available (GA):
You can use cross-cloud joins to run queries that span both Google Cloud and BigQuery Omni regions.
2024/01/16 にプレビューでリリースされた BigQuery Omni のクロスクラウド結合が、翌月 2024/02/29 には GA になりました。
BigQuery から AWS S3 や Azure Blob のデータを SQL で参照できる BigQuery Omni が発表された時には、これでマルチクラウド利用が便利になる？とわくわくしたものでしたが、Omni では、クラウドを跨いだデータの結合、例えば S3 データと BigQuery データを結合することはできませんでした。
BigQuery のエディタから AWS や Azure のデータを参照できるという利点はあるものの、BigQuery データと結合できないのであれば Athena や Synapse 使えば済む話？とちょっと物足りなく感じたものでした。
それが、とうとう BigQuery データとの結合もできるようになったのです！
クエリデータ量や利用可能なリージョンなど、まだちょっと制限事項が多い印象ですが、今後のアップデートにも期待してます！
- 関連記事：「クロスクラウドデータ管理の未来: BigLakeで実現するAWS S3とBigQueryのデータ統合戦略」というタイトルで登壇させていただきました #devio2024 ｜ DevelopersIO
JSON 型データがより扱いやすく
The JSON_KEYS function, which extracts unique JSON keys from a JSON expression, is in Preview.
Some JSON functions that take a JSONPath let you specify a mode that allows flexibility in how the JSONPath matches the JSON data structure. This feature is in Preview.
BigQuery は、JSON 型やネスト構造のデータの扱いが得意な DWH ではないかと思っています。
API のレスポンスデータなど、JSON 型のデータを DWH に格納したいケースはそれなりにあるのではないかと思います。
BigQuery で JSON 型がサポートされるようになった時も嬉しく思ったものでした。
これまではバッチ処理で JSON から CSV フォーマットに変換したり、JSON オブジェクトを文字列型データとしてそのまま格納し、文字列操作関数を駆使して複雑な SQL で参照していた手間が省けるようになったからです。
今回のアップデートで、JSON_KEYS を使えば格納されている JSON オブジェクトのキー一覧を取得できたり、JSONPath 形式で必要な値を簡単に取得できるようになりました。
今後もより便利な関数が追加されることを期待しています！
カラム名の日本語サポートが GA
You can now use flexible column names with BigQuery tables and views for extracting, loading, streaming, and querying data. This feature is generally available (GA).
システムを運用している立場からすると、SQL ではカラム名をバッククォートでくくる必要があったり何かと不便なので、日本語のカラム名はなるべく避けたいと思ってしまうことは否めません。
しかし、データ利用者の立場や社内別システムとの整合性を考えると、テーブル名やカラム名を日本語にしたい場合も出てくるのではないかと思います。
BigQuery カラムの日本語サポートは、2023/03/22 にプレビューでリリースされていましたが、プレビューなので本番運用されているシステムで利用するのは控えざるを得ませんでした。
今回のリリースにより、本番環境でも気にせずに、テーブル名やカラム名に日本語が使えるようになりました。
検索インデックスの進化
Query optimization using search indexes is now applied to comparisons of string literals and indexed data, including the equal (=), IN, and LIKE operators and the STARTS_WITH function. This feature is generally available (GA).
You can create a search index on columns containing INT64 or TIMESTAMP data and BigQuery can optimize predicates that use those columns. This feature is generally available (GA).
BigQuery の検索インデックスは 2022/10/27 に GA リリースされました。
今回のアップデートでは、= や IN、LIKE を使用した可読性の高い SQL が使えるようになったり、インデックスを張ることができるカラムのデータ型が増え、より使いやすくなりました。
BigQuery では、大量のデータを格納済みのテーブルにインデックスを追加する場合でも、裏で非同期にインデックスを張ってくれるので、完了まで待つ必要がなく、実用的ではないかと思います。
チューニングにあまり気を使わなくて良いのが BigQuery の強みのひとつとはいえ、大量データを扱うのが得意な BigQuery で、データ量の多さに起因するパフォーマンスの低下に対する対応策が増えるのは喜ばしいことです。
また個人的に、地道なチューニングによるパフォーマンス向上が著しければ著しいほど、エンジニア冥利に尽きる思いがいたします。
マテリアライズドビューの機能拡充
Materialized views can now reference logical views. This feature is in preview.
You can create materialized view replicas of materialized views over Amazon S3 metadata cache-enabled Biglake tables. Materialized view replicas let you use the materialized view data in queries while avoiding data egress costs and improving query performance.
Incremental materialized views now support LEFT OUTER JOIN and UNION ALL. This feature is in preview.
The allow_non_incremental_definition option and max_staleness option for materialized views are now generally available (GA). The allow_non_incremental_definition option supports an expanded range of SQL queries to create materialized views, and the max_staleness option provides consistently high performance with controlled costs when processing large, frequently changing datasets.
You can now create a materialized view over Apache Iceberg table that is partition aligned with the base table. The materialized view only supports time-based partition transformation, for example, YEAR, MONTH, DAY, and HOUR. This feature is in preview.
ビューを作成しておくと、複数テーブルを結合したり、集計結果を格納したマートテーブルを使いたい場合に、バッチ処理などで新しいテーブルを作成する手間が省けて便利です。
ですが通常の論理ビューでは、参照時に毎回 SQL が実行されるので、実テーブルと比べてパフォーマンスが悪くなり、本番運用では使い物にならないケースが多いのではないかと思います。
そこで、ビューでありながら実データを保持するマテリアライズドビューの出番ですが、以前の BigQuery のマテリアライズドビューでは使える SQL 構文が限定的だったりで、なかなかもどかしく思っておりました。
昨年に引き続き、今年もマテリアライズドビューの進化は止まりません。
論理ビューからマテリアライズドビューを作れるようになったり、サポート構文が増えたり、AWS S3 ファイルデータや Apache Iceberg テーブルをソースとするマテリアライズドビューも作成できるようになってます。
また、データの更新頻度を減らすことでコストの効率化ができる max_staleness オプションが GA になり、本番運用でも心置きなく利用できるようになりました。
まだプレビューの機能も多いので、本番運用の際にはご留意ください。
マテリアライズドビューのアップデートには、今後も引き続き注目です。
履歴ベースの最適化
You can now enable, disable, and analyze history-based optimizations for queries. This feature is in preview.
You can now enable, disable, and analyze history-based optimizations for queries. This feature is generally available (GA).
4月にプレビューでリリースされた、BigQuery の履歴ベースの最適化が、9月に GA リリースになりました。
手動でチューニングしなくても、過去に実行したクエリ履歴に基づいてクエリのパフォーマンスを自動で最適化してくれる、これぞ BigQuery の得意分野では？と思ったアップデートです。
手元で単発クエリを何度か流した限りでは、それほど画期的な効果は確認できませんでしたが、デイリーバッチで毎日同じクエリを実行している、特にデータ量が多かったり SQL の並列度が高い場合には、効果が期待できるのではないかと思います。
このクエリ履歴ベースの最適化が適用されるのは、改善の余地のあるいくつかのパターンの SQL を繰り返し実行した場合に限られるので、全ての SQL が最適化されるわけではありませんが、ユーザーにとって BigQuery をより快適に使えるようになるうれしい機能だと思いました。
まとめ（所感）
お付き合いいただきありがとうございました。
来年も、よりセキュアで快適な BigQuery ライフが送れるようになることを楽しみにしております！
明日、22 日目の クラスメソッドのGoogle Cloud Advent Calendar 2024 の投稿は 村田一紘 さんの予定です。
引き続きお楽しみいただけますと嬉しいです。
参考
- BigQuery release notes
- パーティション分割テーブルの概要 ｜ BigQuery ドキュメント
- BigLake 外部テーブルの概要 ｜ BigQuery ドキュメント
- テーブルの作成と使用 ｜ BigQuery ドキュメント
- スキーマの指定 ｜ BigQuery ドキュメント
- 履歴ベースの最適化を使用する ｜ BigQuery ドキュメント
- BigQueryのテーブルでパーティション数の上限が増えました ｜ DevelopersIO
- S3からBigQueryへ連携する方法いろいろ（Omni/Transfer Service） ｜ DevelopersIO
- 「クロスクラウドデータ管理の未来: BigLakeで実現するAWS S3とBigQueryのデータ統合戦略」というタイトルで登壇させていただきました #devio2024 ｜ DevelopersIO
- 【新機能】BigQueryでJSON型が使えます！（BigQuery subscriptionsも対応） ｜ DevelopersIO
- 【新機能】BigQuery で JSON オブジェクトのキーの一覧を取得できるようになりました ｜ DevelopersIO
- BigQuery のテーブルに検索インデックスを作成してみる ｜ DevelopersIO
- 【アップデート・プレビュー】BigQueryのマテリアライズドビューで複数のテーブルを結合できるようになりました ｜ DevelopersIO
- GA になった BigQuery の history-based optimizations で SQL が最適化されるか確認してみた。 ｜ DevelopersIO
