BigQuery Sharingの特徴と押さえておくべきポイント
はじめに
お疲れ様です、データ事業本部の小高です。
最近、クロスプロジェクト間でのBigQueryデータ共有の設計を検討する機会があり、BigQuery Sharing（旧称: Analytics Hub）についてまとめてみました。
BigQuery Sharingの基本的な使い方については下記の記事でハンズオン形式で紹介されています。本ブログでは、実際に検証する中で見えてきたBigQuery Sharingの特徴と制約・注意点を整理し、採用判断の参考になる情報をまとめます。
BigQuery Sharingの概要
BigQuery Sharingは、組織内外でBigQueryデータセットを共有できるサービスです。
引用: Introduction to BigQuery sharing | Google Cloud
主要な用語を簡単に整理しておきます。
| 用語 | 説明 |
|---|---|
| Exchange | Listingをまとめる論理的なグループ。限定公開/一般公開を選択可能 |
| Listing | 共有対象のデータセットと1対1で対応する共有単位 |
| リンク済みデータセット | Subscriberがサブスクライブした際にSubscriber側プロジェクトに作成される読み取り専用のデータセット |
| Publisher | データを提供する側 |
| Subscriber | データを受け取る側 |
基本的な流れとしては、Publisher側がExchangeにListingを登録・公開し、Subscriber側がサブスクライブすると、自プロジェクト内にリンク済みデータセットが自動作成されます。データのコピーは発生せず、Publisher側のデータを直接参照する形です。
BigQuery Sharingの特徴
1. Publisher側へのIAMロール付与が不要
BigQuery Sharingの大きな特徴の1つは、Subscriber側のユーザーに対してPublisher側プロジェクトのBigQuery IAMロールを付与する必要がない点です。
通常、プロジェクトをまたいでBigQueryのデータを参照する場合、参照元のプロジェクトに対して何らかのIAMロール（bigquery.dataViewer等）を付与する必要があります。BigQuery Sharingでは、Exchange/Listingのsubscriber権限の付与のみで共有が完結するため、Publisher側のIAM管理がシンプルになります。
2. subscriber権限とサブスクリプションの管理
subscriber権限
Exchange/Listingに対するsubscriber権限は、サブスクライブの可否を制御します。
subscriberロールを付与した場合
Exchangeの権限設定画面でsubscriberロールを付与している状態
Listingが一覧に表示され、サブスクライブ可能
subscriberロールを削除した場合
Exchangeからsubscriberロールを削除した状態
Listingが一覧に表示されず選択できない画面
権限がなければサブスクライブできないだけでなく、Listing自体が見えなくなるため、意図しない情報の露出を防ぐことができます。
サブスクリプションの管理
subscriber権限の剥奪は新規サブスクライブを許可させないものです。既にサブスクライブ済みのリンク済みデータセットへのアクセスは停止しません。既存のアクセスを停止するには、Exchange内の「サブスクリプション」タブからサブスクリプションの取り消し（Revoke）を実行する必要があります。
Exchangeの「サブスクリプション」タブからサブスクリプションを取り消す画面
ざっくりまとめ
| 操作 | 効果 |
|---|---|
subscriber権限の剥奪 |
新規サブスクライブとListingの発見を停止。既存のリンク済みデータセットへのアクセスは継続 |
| サブスクリプションの取り消し（Revoke） | リンク済みデータセットへのデータアクセスを停止。リンク済みデータセット自体はSubscriber側に残るため手動削除が必要 |
3. Exchange単位 / Listing単位の権限制御
subscriber権限はExchange単位・Listing単位の両方で付与できます。
| 付与単位 | 挙動 |
|---|---|
| Exchange単位 | そのExchange配下の全Listingに対してサブスクライブが可能になる |
| Listing単位 | 特定のListingのみサブスクライブが可能になる |
Exchangeをグルーピングの単位として使い、Listing単位で細かく制御するといった運用が可能です。
4. テーブル追加時の自動反映
Publisher側のデータセットにテーブルを追加すると、リンク済みデータセットに自動で反映されます。スキーマの変更やデータの更新も同様です。
Subscriber側での追従作業は一切不要なので、共有対象のテーブルが増えていくケースでも運用負荷が上がりません。
5. クエリコストはSubscriber側に計上
リンク済みデータセットに対するクエリのコストはSubscriber側のプロジェクトに計上されます。Publisher側にコスト負担は発生しません。
ストレージ料金はPublisher側のみ、クエリスキャン料金はSubscriber側のみという明確な分離になっています。
6. リンク済みデータセットは読み取り専用
リンク済みデータセットに対するINSERT/UPDATE/DELETE操作はエラーになります。意図しないデータ変更のリスクがなく、データ提供側としても安心してデータセットを公開できます。
制約・注意点
1. Listing登録の粒度はデータセット単位のみ
Listingに登録できるのはデータセット単位です。特定のテーブルやビューだけをListingに登録して公開するといったことはできません。
特定のテーブルだけを公開したい場合は、公開用のデータセットを別途作成し、そこに対象テーブルのビューを配置するという設計で対応できます。
┌─── Publisher側 ────────────────────────────────┐
│ │
│ 元データセット（非公開） │
│ ├─ テーブルA │
│ ├─ テーブルB （公開したい） │
│ └─ テーブルC （公開したい） │
│ │ │
│ ▼ │
│ 公開用データセット ← Listingに登録 │
│ ├─ View_テーブルB → テーブルBを参照 │
│ └─ View_テーブルC → テーブルCを参照 │
│ │
└─────────────────────────────────────────────────┘
ただし、このビューを使った方法には次のセクションで説明する注意点があります。
2. ビュー参照時にPublisher側の閲覧権限が必要
リンク済みデータセット内のテーブルはSubscriber側の権限のみで参照できますが、ビューの場合は元テーブルのデータセットに対するPublisher側の閲覧権限が別途必要になります。
つまり、前述の「公開用データセットにビューを配置する」方式では、Subscriber側のユーザーに対してPublisher側の元データセットの閲覧権限を付与する必要が出てきます。これでは「Publisher側のIAM付与が不要」というBigQuery Sharingのメリットが損なわれてしまいます。
この問題は承認済みビューを使うことで回避できます。承認済みビューにすると、ビュー自体がデータアクセスの権限を持つため、Subscriber側ユーザーにPublisher側の閲覧権限を付与する必要がなくなります。
| ビューの種類 | Publisher側の閲覧権限 |
|---|---|
| 通常のビュー | 元テーブルのデータセットへの閲覧権限が必要 |
| 承認済みビュー | 不要 |
承認済みビューを使う場合は、公開用データセットを別途作成する必要はなく、元のデータセットに承認済みビューを配置してListingに登録する形で対応できます。
ビューへの承認を行い、承認済みビューにする
リンク済みデータセットにビューがあること確認
承認済みビューへのSELECT文が成功
3. その他の制限事項
| 制約 | 内容 |
|---|---|
| 最大サブスクリプション数 | 1つのListingあたり最大1,000 |
| 個別テーブルへのIAM設定 | リンク済みデータセット内の個別テーブルへのIAMロール設定は不可（データセット単位のみ） |
| テーブル単位のタグ設定 | リンク済みデータセット内のテーブルへのタグ設定は不可 |
| マテリアライズドビュー | リンク済みデータセットのテーブルを参照するマテリアライズドビューは非対応 |
| テーブルスナップショット | リンク済みデータセットのテーブルスナップショット取得は不可 |
| ロギング設定の不可逆性 | サブスクライバーのメールのロギングは一度有効にすると無効に戻せない（Exchangeの再作成が必要） |
まとめ
今回は、BigQuery Sharingの特徴と制約・注意点を整理しました。採用を検討する際は、共有対象の粒度と権限設計を事前に整理しておくことをお勧めします。
参考資料
