Google Cloud データ分析系プロダクトの最新アップデート(2023年3月、BigQuery 編)

記事タイトルとURLをコピーする

G-gen の神谷です。本記事では、Google Cloud のデータ分析系プロダクトのアップデートを取り上げ、変更点やその背景を考察し、プロダクトや機能についての理解を深めます。

新料金体系 BigQuery Editions

BigQuery ユーザであればおなじみであったオンデマンドプラン(スキャンしたデータ量に応じた課金モデル。コンピュートに相当するスロットは 2000 スロットまで使い放題)による従量料金モデルから BigQuery Editions と呼ばれる料金体系に主軸が変わり、従来の BigQuery Reservation (flat-rate) を置き換えることになりました。

BigQuery Editions は定額制というわけではなく、新機能である BigQuery Autoscaler 機能により、費用を柔軟化・最適化することができます。

従来のオンデマンドプランは残りますが 単価が 25% 上がります。そのため、総じて「BigQuery がいきなり値上げした!」と勘違いされそうですが、そうではありません。詳細については弊社ブログで徹底解説されていますので、そちらを参照ください。

blog.g-gen.co.jp

新料金プランの仕様を踏まえて適切な移行を行うことで、ほとんどのケースで料金削減が期待できます。逆に、変更内容を知らずに放置しておくと、いつの間にか値上げされていたということが起きます。変更ポイントをしっかりと理解した上で、適切な対策を検討・実施することを強く推奨します。

BigQuery ML における推論での Vision API 等の呼び出し機能強化

リリース概要

BigQuery ML から Cloud Vision API、Cloud Natural Language API、Cloud Translation API の呼び出しが可能になりました。

その他にも、ONNX、XGBoost、TensorFlow Lite 形式のモデルインポートが可能になりました。従来は TensorFlow のモデルだけでしたが、PyTorch や schikit-learn 等のメジャーなフレークワークのモデルもインポートできるようになったため、より使い勝手が良くなったと言えます。また、Vertex AI にホストしたリモートモデルの呼び出しも可能です。

当リリースのポイント

やはり、BigQuery のオブジェクトテーブルの存在が大きいです。

構造化データだけでなく、非構造化データに対しても BigQuery のフルマネージドのサーバレス環境と、コンピューティング能力が活用できます。単に推論するだけでなく、もともと入っている構造化データと、非構造化データの推論結果を組み合わせて、機械学習モデルを構築といったことが可能になります。

以下は画像データに対する推論結果から新たにテーブルを作成する例です。

CREATE TABLE my_dataset.my_inference_results AS -- ③ BQ の別テーブルに保存
SELECT uri, content_type, vision_feature
FROM ML.PREDICT( -- ② 画像の特徴量から推論結果を取得
  MODEL my_dataset.vision_model, -- 任意のモデルを指定
  SELECT ML.DECODE_IMAGE(data) AS vision_input -- ① 画像ファイルのパスから特徴量生成
  FROM my_dataset.object_table -- オブジェクトテーブルを指定
);
  1. 「ML.DECODE_IMAGE(data)」関数を使って、画像データ( GCS へのファイルパス)を特徴量(「vision_input」)に変換
  2. 「ML.PREDICT」であらかじめ用意した画像モデルに対して特徴量を入力して、推論を実行
  3. 推論結果を別テーブルに保存

データの移動や複雑なプログラミングをすることなく、一瞬にして異なるフォーマットのデータを統合し、後の分析に活かせる点がポイントです。

CREATE TABLE AS SELECT 文による S3→BQ 移送時のデータフィルタリング機能がプレビュー

CREATE TABLE AS SELECT 文による Amazon S3 および Azure Blob Storage ファイルデータのフィルタリング結果書き込み機能がプレビューになりました。(March 10, 2023

これによって、より柔軟にマルチクラウド間のデータ移送を実現できます。

リリース概要

本リリースの概要は以下の通りです。

  • S3(Blob Storage)→ BigQuery への転送前にデータを絞り込む機能
  • S3 や Blob Storage を参照する BigLake テーブルを作成する必要がある
  • クラウド間の転送に伴う料金はかからない

注意点は以下の通りです。

  • BigQuery Omni リージョンのスロットが必要になる
  • BigQuery Omni の最大クエリ結果サイズは非圧縮で 20GiB。これを超えるとエラーになる
  • 5MB 未満の複数ファイルのロードは非推奨(なるべく大きなファイルを S3 や Blob Storage に置く)

BigQuery Omni とは

BigQuery Omni は、Google Cloud、AWS、Azure などの複数のクラウドプロバイダーにまたがるデータを、BigQuery のインターフェースで統一的に分析できるマルチクラウドデータウェアハウスです。これにより、データを異なるクラウド間で移動させずにクエリを実行でき、分析を効率化できます。

詳細については当社ブログを参照してください。

blog.g-gen.co.jp

BigLake とは

BQ 管理のストレージや GCS のファイル、S3 や Blob Storage といった別クラウドまで含めた異なるデータソースを統合的に扱える抽象化レイヤーです。

BigLakeの概要

Dataproc(Apache Spark) や Dataflow(Apache Beam)といった外部ツールを間に挟んで、BigQuery からデータソースにアクセスすることができます。 また、BigLake メタデータ キャッシュ対応テーブルを使うことで、GCS のファイルへのクエリパフォーマンスが向上します。

当リリースのポイント

BigQuery Omni はわざわざファイルを移動することなく、BigQuery から直接データソースにアクセスできるので、少ないコストで BigQuery のパワーを利用することができます。

メインのクラウドはAWSだが、BigQuery に関しては使ってみたいというケースで有効です。

今回のアップデートによって、例えば日次で増える S3 の Big Lake に対して増加分だけ絞り込んで移送といったことが可能です。

必要なデータだけ持ってこれるため、転送料やクエリ料が削減でき、データパイプラインも短くなります。

データパイプラインが長くなればなるほど、処理の依存関係を定義することや可用性を担保することの難易度があがるため、今回のアップデートはそういった問題を緩和することに繋がるでしょう。

BigQuery のクエリで再帰処理が書ける WITH RECURSIVE 句が GA

リリース概要

BigQuery のクエリで再帰処理が書ける機能が GA になりました。

再帰処理とは

再帰処理とは、ある処理が自分自身を繰り返し呼び出すことで、階層的なデータ構造や繰り返しのパターンを効率的に処理するプログラミング手法です。データベースのクエリにおいては、階層的なデータやグラフ構造を扱う際に再帰処理が用いられます。

当リリースのポイント

WITH RECURSIVE 句が GA になることで、BigQuery ユーザーは階層的なデータ構造やグラフデータを効率的に処理できるようになります。また、再帰処理を利用することで、従来は複数のクエリや外部プログラムを用いて実現していた処理を、1つのクエリで完結させることが可能になります。これにより、データ処理の効率化やパフォーマンス向上が期待できます。ただし、再帰処理を適切に設計・実装しないと、クエリ料金が大幅に増加したり、無限ループに陥る可能性があるため、注意が必要です。

大文字と小文字を区別しない照合のサポートを含む多数の関数が GA

リリース概要

大文字と小文字を区別しない照合のサポートを含む多数の関数が GA になりました。

照合の詳細な仕様についてはこちらを参照してください。

以下の機能に対して有効です。

  • MIN、MAX、COUNT with DISTINCT、PERCENTILE_DISC によるウィンドウ関数
  • WINDOWS 句内の ORDER BY および PARTITION BY
  • 制限付きの LIKE 演算子
  • ビュー
  • 制限付きのマテリアライズドビュー
  • 制限付きのテーブル関数
  • BigQuery BI エンジン

照合順序とは

照合順序とは、文字列データの比較やソートを行う際に使用される、文字の大小関係や等価性を決定するルールです。照合順序には、大文字と小文字を区別するものと、区別しないものがあります。

照合順序を明示的に指定しない場合、デフォルトの挙動は以下のようになります。

SELECT
  *
FROM
  UNNEST([ 'B', 'b', 'a', 'A', 'C', 'c']) AS character
ORDER BY
  character

デフォルトのソート順(大文字小文字が区別される。先に大文字、次に少文字)

半角大文字のあとに半角小文字が並びます。

次に、照合順序を明示的に指定した場合の順序です。

SELECT
  *
FROM
  UNNEST([ 'B', COLLATE('b', 'und:ci'), 'a', 'A', 'C', 'c']) AS character
ORDER BY
  character

照合順序を明示的に指定した場合のソート順(大文字少文字が混在)

大文字と少文字を区別しないため、両者は等価だと見なされ、アルファベット順で並んだあとは、もともとの配列のインデックス順でソートされています。

照合がサポートされているデータ型は以下の通りです。

  • 通常の STRING 型
  • STRUCT(構造体) 内の STRING 項目
  • ARRAY(配列) 内の STRING 要素

照合は、データセットやテーブル、列単位で定義できます。

-- データセットレベルでの定義
CREATE SCHEMA (...)
DEFAULT COLLATE 'und:ci'

-- テーブルレベルでの定義
CREATE TABLE (...)
DEFAULT COLLATE 'und:ci'

-- 列レベルでの定義
CREATE TABLE (
  case_insensitive_column STRING COLLATE 'und:ci'
)

当リリースのポイント

今回のリリースによって、BigQuery ユーザーは文字列データの比較やソートを、大文字と小文字の違いを気にせずに行えるようになります。これまで独自の関数や前処理を入れて処理していたことが BigQuery の標準機能だけで実現できます。

神谷 乗治 (記事一覧)

クラウドソリューション部

クラウドエンジニア。2017 年頃から Google Cloud を用いたデータ基盤構築や ML エンジニアリング、データ分析に従事。クラウドエース株式会社システム開発部マネージャーを経て現職。Google Cloud Partner Top Engineer 2023、Google Cloud Champion Innovators(Database)、著書:「GCPの教科書III【Cloud AIプロダクト編】」