BigQuery measuresが一般提供を開始、BI指標とナレッジグラフを1つのモデルで定義可能

BigQuery measuresでできること

BigQuery measuresでは、指標と、その数値を生んだ関係のつながりを同じモデルで扱います。BIダッシュボードやAIエージェントは、同じ定義から信頼できる数値と背後の関係の文脈を得られます。^[1]

図1　1つのモデルで行う定義と集計

メジャーは、ノードテーブルやエッジテーブルのPROPERTIES句で定義する集計プロパティです。集計はテーブルのKEYを基準に行われるため、1つの口座に多数の取引があっても各口座を1回だけ数えられます。^[1][2]

取引額や口座数はGRAPH_EXPANDとAGG()で集計し、Pragueで資金を動かした口座IDはGQLで重複なく返す仕組みです。BigQueryで直接実行するGQLクエリは、オンデマンド料金か、EnterpriseまたはEnterprise Plusの予約で実行できます。

BigQuery measuresの新機能

粒度を固定したメジャーとBigQuery Graphとの統合は、プレビューで導入されていました。一般提供のBigQuery measuresは、複雑な業務ロジック向けのモデリングと可視化、エージェントによる指標の意味の発見に重点を置いています。^[1]

図2　プレビューから一般提供までの重点

MEASURE()によるモデリング機能

MEASURE()は、集計とスカラー演算を組み合わせた式と、ほかのメジャーをAGG()で参照する派生メジャーに対応し、この機能は一般提供です。基準の集計を一度定義し、同じテーブル上でAGG()により上位の計算に組み合わせられます。^[1][2]

BigQueryは式の依存関係をスキーマのコンパイル時に検証し、循環参照や不正な集計を早い段階で検出します。ダッシュボードやAIエージェントは、複雑な比率や純額の指標を任意の次元で一貫した精度でクエリ可能です。

図3　一般提供として発表された機能

同じ口座に結び付く取引とクレジットカードの表を結合すると、従来は指標が膨らむ「chasm trap」が起きていました。GRAPH_EXPANDの新しいstart_node引数は、各ファクトテーブルを個別の展開ツリーに分けます。

図4　start_node引数による複数ファクトテーブルの集計

口座別の例では、start_nodeにTransとCardを指定した2つのGRAPH_EXPANDを、口座IDでLEFT JOINします。この構成では各ブランチが正確な粒度を保ち、取引はあるがカード未発行の口座でも同じです。

Data Studioの可視化機能

Data Studioでの可視化も新機能で、更新されたBigQueryコネクタでグラフに直接接続し、メジャーで対話型の可視化を作れます。Data Studioはグラフモデルの集計ロジックに従い、チャート間で計算をそろえ、クライアント側の意図しない再集計を防ぎます。

図5　Data Studioでできること

メジャーに意味を付ける機能

一般提供では、OPTIONS句で各メジャーの定義に、説明文や業務で使われる類義語、独自のキーと値の拡張を埋め込めます。意味情報はSQLの式と一緒にスキーマに保存され、指標をどこでクエリしても引き継がれます。

図6　一般提供のOPTIONS句で付けられる情報

メジャーを見つける機能

BigQueryはKnowledge Catalogと直接統合し、人と機械の双方がメジャーを見つけて使える流れを作ります。BigQuery GraphとメジャーのメタデータはKnowledge Catalogに自動で取り込まれ、類義語や説明で検索可能です。

ガバナンスタグや、使う前のメジャーのSQL定義も確認できます。グラフのメタデータは、業務用語集やスチュワードシップの情報で拡充可能です。

図7　Knowledge Catalogでできること

BQ.SHOW_GRAPH_EXPAND_SCHEMAは、基になるテーブルをスキャンせずに、展開後のグラフのスキーマをJSONで返す関数です。メジャーには"is_measure": trueの印が付き、説明や類義語も一緒に返されます。

同じ関数にflatten_results => FALSEを渡すと、エンティティの階層はネストしたROW（STRUCT）型で保たれます。エージェントは関係のツリーを調べ、Account.District.cityのようなパスを直接クエリ可能です。

データとAIの連携機能

BigQuery measuresはGoogle Cloudのデータ・AIスタックと統合され、既存のツールでセマンティクスを作成、再利用、クエリできます。Data Agent Kitのgraph skillsでは、自然言語でメジャー定義のひな形作成や記述、検証が可能です。

図8　BigQuery measuresと連携するツール

Lookerで業務指標をモデル化済みなら、LookML-based derived analytic modelsで既存のLookMLモデルを再利用できます。Explore、結合、メジャーをBigQuery Graphへコンパイルでき、derived_analytic_modelはPublic Previewです。^[1][4]

統合したグラフとメジャーの定義は、Conversational Analytics（会話型分析）で標準サポートされます。業務ユーザーとAIエージェントは、管理された指標に自然言語で質問できます。

BankingGraphでメジャーを使う例

Google Cloudは、既存の基盤から作り始められる点を統合モデルの主な利点としています。BIのセマンティックレイヤーがあれば管理された指標を対象のエンティティに定義し、ナレッジグラフが基盤なら最も頻繁な走査にメジャーを付ける始め方です。^[1]

図9　メジャーを定義して集計する流れ

BigQueryでは、ネイティブテーブルやborderless Lakehouseの既存テーブルに、データを移動せず別のシステムも使わずにモデルを定義できます。次のコードは、取引と口座、地区のテーブルでグラフを作り、取引額の合計と口座数をメジャーにする例です。

-- Entities, relationships, and measures, declared in one model
CREATE OR REPLACE PROPERTY GRAPH retail_banking.BankingGraph
  NODE TABLES (
    retail_banking.trans AS Trans
      KEY (trans_id)
      PROPERTIES (
        trans_id, account_id, amount,
        MEASURE(SUM(amount)) AS total_trans_amount
      ),
    retail_banking.account AS Account
      KEY (account_id)
      PROPERTIES (
        account_id, district_id, stmt_frq,
        MEASURE(COUNT(account_id)) AS account_count
      ),
    retail_banking.district AS District
      KEY (district_id)
      PROPERTIES (district_id, city, state)
  )
  EDGE TABLES (
    retail_banking.trans AS POSTED_TO
      KEY (trans_id)
      SOURCE KEY (trans_id) REFERENCES Trans (trans_id)
      DESTINATION KEY (account_id) REFERENCES Account (account_id)
      NO PROPERTIES,
    retail_banking.account AS LOCATED_IN
      KEY (account_id)
      SOURCE KEY (account_id) REFERENCES Account (account_id)
      DESTINATION KEY (district_id) REFERENCES District (district_id)
      NO PROPERTIES
  );

公式資料からの抜粋：BigQuery measures is now GA: Unifying BI metrics and knowledge graphs for AI accuracy（One model to answer both the what and the why）。対象版・範囲：一般提供（GA）の発表のコード例。

上記のコードでは、MEASURE()で囲んだSUMとCOUNTの式が、total_trans_amountとaccount_countの2つのメジャーです。メジャーで定義したプロパティには、別名を指定する必要があります。^[1][2]

次のコードは、GRAPH_EXPANDで展開した出力をAGG()で集計し、都市ごとの取引額と関係する口座数を求める例です。

-- Volume by city, and the accounts behind it, each counted once
SELECT
  District_city,
  AGG(Trans_total_trans_amount) AS total_volume,
  AGG(Account_account_count)    AS accounts_involved
FROM GRAPH_EXPAND("retail_banking.BankingGraph")
GROUP BY District_city;

公式資料からの抜粋：BigQuery measures is now GA: Unifying BI metrics and knowledge graphs for AI accuracy（One model to answer both the what and the why）。対象版・範囲：一般提供（GA）の発表のコード例。

AGG()はメジャーで定義された集計を、キーごとに正確に1回だけ実行します。既定のフラットな出力では、列名はDistrict_cityのようにラベルとプロパティ名をつないだ形式です。

BigQuery measuresの利用条件

BigQuery measuresは一般提供の機能です。ただし、特定のBigQueryエディションで作成した予約では、メジャーの機能は使えません。^[1][2]

料金と会話型分析の条件

BigQuery Graphでは、基になるテーブルのストレージはグラフモデルの数に関係なく1回だけの課金です。課金は標準のBigQueryストレージ料金に従います。^[3]

図10　料金と会話型分析の主な条件

会話型分析でグラフを使う場合、GQLクエリにはEnterpriseまたはEnterprise Plusエディションの予約が必要で、オンデマンド料金では失敗します。GRAPH_EXPANDを含むクエリはオンデマンド料金でも実行できますが、この関数は全種類のグラフに対応するわけではありません。^[5]

会話型分析のエージェントは保存後にロケーションを変更できないため、日本のロケーションを使いたい場合は作成時に確かめます。確認日時点のロケーション一覧にはasia-northeast1（東京）が含まれ、大阪のリージョンは含まれていません。

GRAPH_EXPANDの利用制限

GRAPH_EXPANDを使うクエリで確かめる制限は、以下の通りです。

グラフを変更しても、GRAPH_EXPANDの結果のキャッシュは無効になりません。正しい出力を得るには、キャッシュ済みの結果の取得を無効にする必要があります。

メジャーを集計するクエリの選び方

GQLではメジャーを含むグラフをクエリできますが、メジャーで定義したプロパティは直接参照できません。メジャーの集計には、GRAPH_EXPANDの出力でAGG()を使います。^[2]

図11　GQLとGRAPH_EXPANDの違い

メジャーを含むBigQuery Graphでは、指標の値はGRAPH_EXPANDとAGG()、数値を生んだ口座などはGQLで調べると、同じ定義で両方に答えられます。会話型分析でグラフを使うオンデマンド料金のプロジェクトでは、GQLクエリが失敗するため、予約のエディションの確認も必要です。^[1][2][5]