Analytics Hub

解決する課題

• 部門間や取引先と BigQuery のデータを共有したいが、CSV エクスポートやテーブルコピーの配布は統制が効かず漏洩リスクが高い
• データのコピーを増やさず、つねに最新の元データを参照させたい（鮮度のずれをなくしたい）
• 自社が保有するデータを**社外に公開・販売（収益化）**したいが、配布や課金の仕組みを自前で作りたくない
• 公開データセットやパートナー提供データを手軽に取り込み、自分の BigQuery プロジェクトから直接クエリしたい
• 誰がどのデータを購読しているかを一元的に管理・監査したい

主要概念と用語

• データ交換 (Exchange / データエクスチェンジ): 共有するデータをまとめる入れ物。提供者がリスティングを束ね、公開範囲（プライベート/限定/一般公開）を設定する単位
• リスティング (Listing): 共有する 1 件のデータ商品。BigQuery のデータセット（やビュー）を元に作られ、説明・カテゴリ・提供者情報などのメタデータを持つ
• パブリッシャー / サブスクライバー (提供者 / 購読者): データを公開する側と、リスティングを購読して利用する側。提供者はリスティングを作成し、購読者は購読操作でアクセス権を得る
• リンクされたデータセット (Linked dataset): 購読者側に作られる参照専用のデータセット。実データはコピーされず、提供者の元データセットを指すポインタとして振る舞う
• 共有データセット (Shared dataset): リスティングの元になる、提供者側の実データを持つ BigQuery データセット
• 購読 (Subscription): 購読者がリスティングにアクセスする関係。提供者は購読状況を確認でき、必要に応じて取り消せる
• 公開範囲: Exchange は「自分だけ」「特定ユーザー/グループに限定」「一般公開（パブリックリスティング）」のいずれかで公開でき、到達範囲を制御する

仕様・制限・クォータ

• Analytics Hub は BigQuery にネイティブ統合された共有機能で、共有の実体は BigQuery のデータセット共有として動く。専用のデータ移送基盤を別途構築する必要はない
• 共有されるのは参照リンクであり、購読者側にデータの物理コピーは作られない。購読者は自分のプロジェクトから通常の SQL でリンクされたデータセットをクエリできる
• 提供者は Exchange とリスティングを作成・管理し、購読者は購読してリンクされたデータセットを受け取る、という役割分担になる
• リスティングの元にできるのはデータセットやその中のテーブル/ビューで、行レベル/列レベルのアクセス制御や承認済みビューと組み合わせて公開範囲を絞れる
• 1 つの Exchange やリスティング、購読数などには上限が設定される。具体的なクォータ値は変動するため、最新の公式ドキュメントで都度確認すること

内部の仕組み

Analytics Hub は、BigQuery のデータセット共有の仕組みを製品化したものです。提供者がデータセットを元にリスティングを作ると、そのデータセットへの参照が共有可能なカタログ項目として登録されます。購読者が購読すると、購読者側プロジェクトにリンクされたデータセットが生成され、これは実データを持たず提供者の共有データセットを指します。

クエリ時には、購読者の SQL がリンクされたデータセット経由で提供者側の実データを読み取ります。データはコピーされていないため、提供者がテーブルを更新すれば購読者にも即座に反映され、鮮度のずれが生じません。読み取りの計算とスキャンは購読者側のプロジェクトで実行されるため、クエリ課金は購読者に発生します。

提供者は購読関係を一覧でき、不要になった購読を取り消せます。取り消すとリンクが切れ、購読者はそれ以降データを参照できなくなります。

設計パターン / ベストプラクティス

• 共有はテーブルを直接公開せず、承認済みビューや行/列レベルのアクセス制御を挟み、見せたい範囲だけをリスティング化する
• 社外公開はプライベート/限定 Exchange から始め、用途が固まってから一般公開を検討する。公開範囲はあとから広げる方が安全
• 提供データには**わかりやすいメタデータ（説明・カテゴリ・更新頻度）**を付け、購読者が中身を判断しやすくする
• 鮮度が重要なデータは、元データセットの**更新パイプライン（Dataform / スケジュールクエリなど）**を整え、リンク経由で常に最新が見える状態を保つ
• 大量スキャンが予想される共有データは、パーティション分割・クラスタリングを施し、購読者側のクエリコストを抑えられるよう配慮する

運用・監視

• 提供者は購読の一覧で誰が何を購読しているかを確認し、不要になった購読を取り消してアクセスを停止できる
• リンクされたデータセットへのアクセスは BigQuery のジョブ履歴（INFORMATION_SCHEMA）や Cloud Loggingに記録され、利用状況や監査の基盤になる
• 共有データの更新は元データセット側で行うため、元データの更新パイプラインの成否を監視し、購読者へ古いデータが見え続けないようにする
• リスティングのメタデータ（説明・更新頻度）を実態に合わせて維持し、購読者が誤解しないようにする

コスト

Analytics Hub は共有のための層であり、データ移動を伴いません。したがって主なコストは BigQuery のクエリ（スキャン量またはスロット）とストレージで発生します。元データのストレージ費用は提供者に、リンクされたデータセットへのクエリ費用は購読者に発生する、という負担の分かれ方が基本です。

セキュリティ

• 公開範囲は **Exchange の可視性（プライベート/限定/一般公開）**で制御し、社外公開はまず限定範囲から始めて段階的に広げる
• テーブルを丸ごと公開せず、承認済みビューや行/列レベルのアクセス制御で見せる範囲を最小化してからリスティング化する
• 購読権限は IAM で管理し、提供者・購読者の役割に応じて最小権限を付与する。購読の取り消しでアクセスを即時停止できる
• 元データは Google 管理鍵で既定暗号化され、要件に応じて CMEK（顧客管理鍵, Cloud KMS） を BigQuery 側に適用できる
• データ流出対策として VPC Service Controls を組み合わせ、境界外への持ち出しや想定外の共有を制限する

関連サービス・比較

BigQuery にも従来からデータセット共有（承認済みビューや IAM による直接共有）の仕組みがあります。Analytics Hub はそれをカタログ化・製品化し、提供者と購読者という形でガバナンスと一般公開を含めて扱いやすくしたものと整理できます。

ハンズオン / CLI例

# 1) データ交換（Exchange）を作成
bq mk --data_exchange \
  --location=asia-northeast1 \
  --display_name="販売データ交換" \
  my_exchange

# 2) 作成したデータ交換を一覧で確認
bq ls --data_exchange --location=asia-northeast1

# 3) 共有したい元データセットを指定してリスティングを作成
bq mk --listing \
  --location=asia-northeast1 \
  --data_exchange=my_exchange \
  --display_name="日次売上サマリ" \
  --source_dataset=MY_PROJECT.sales_summary \
  sales_listing

# 4) リスティング一覧を確認
bq ls --listing \
  --location=asia-northeast1 \
  --data_exchange=my_exchange

# 5) 購読者として購読し、リンクされたデータセットを作成
bq mk --subscription \
  --location=asia-northeast1 \
  --data_exchange=my_exchange \
  --listing=sales_listing \
  --destination_dataset=linked_sales