概要
サイロ化された BigQuery データセットを Analytics Hub を活用して統合する際に、Dataplex および関連サービス(Cloud Data Loss Prevention API など)を利用して実施可能な作業を整理しました。本来は体系的にまとめたかったのですが、動作検証や IAM などの詳細な調査を行わないと有用性を判断しづらいため、ひとまず箇条書きで整理することにしました。
サイロ化された BigQuery データセットを Analytics Hub を活用して統合する方法については、下記の記事で整理しています。
引用元:サイロ化したBigQueryをAnalyticsHubにより統合するアーキテクチャの検討時のメモ #GoogleCloud - Qiita
Dataplexと関連サービスを活用して実施できる作業は以下のとおりです。詳細は次項で説明します。
- BigQueryに追加されたデータセットおよびテーブルの検知
- Cloud Data Loss Prevention APIによるデータプロファイリングを通じた機密データの特定
- DataplexカタログによるBigQueryテーブルのメタデータ(テーブル定義やリネージ)の表示
- Dataplexを介したデータ共有
- HubプロジェクトのDataplexの公開
- Catalog によるメタデータの管理
- Attribute Store を用いたデータへの権限付与
- Profile を用いたデータのプロファイリングの実施
- Data Qualitty を用いたデータ品質チェックの実施
以下に、実施すべき運用業務と実施すべきでない作業を示します。Attribute Storeを用いたデータへの権限付与は有用である可能性が高いですが、現時点では技術的な検証ができていないため、その有用性を確認することをお勧めします。その他の作業については、必要に応じて実施の可否を判断してください。
実施すべき作業
# | 項目 | 理由 |
---|---|---|
1 | BigQuery に追加されたデータセットとテーブルの検知 | データセットをそのまま共有しないため、テーブルの増減に対応するため。 |
2 | Cloud Data Loss Prevention API によるデータプロファイリングにて機密データの特定 | テーブルの機密レベルを検討する際の参考とするため。 |
実施すべきでない作業
# | 項目 | 理由 |
---|---|---|
4 | Dataplexを介したデータ共有 | Analytics Hub 経由で参照権限のみを付与で運用上は十分であるため。 |
5 | HubプロジェクトのDataplexの公開 | Hub プロジェクトにおけるオブジェクトへの権限付与の運用業務が煩雑となるため。 |
7 | Attribute Store を用いたデータへの権限付与 | ビューにて対してポリシータグを設定できないため。 |
前提事項
- Anlytics Hub によりデータ共有を行うアーキテクチャであること
- Publisher レイヤーと Hub レイヤー異なる運用チームであること
- 共有対象が BigQuery のオブジェクトのみであること
- Publisher レイヤーにてデータセットの運用ルールを変更しないこと
Hub レイヤーにおける運用業務
1. BigQuery に追加されたデータセットとテーブルの検知
Dataplex にてオブジェクトにおける最終更新日からテーブルの追加を検知できます。
上記のデータを Dataplex から抽出する方法を確認できていませんが、下記の方法で取得できる可能性があります。
BigQuery にて下記のクエリで抽出した結果を利用したほうが簡単である可能性もあります。last_modified_time
列に Unix Time Stamp 形式で最終更新日時が保持されているようです。
SELECT
*
FROM
bq-hub-01.bq_publisher_01_sample_ds_01_in.__TABLES__
;
2. Cloud Data Loss Prevention API によるデータプロファイリングにて機密データの特定
Cloud Data Loss Prevention API (Sensitive Data Discovery の一部)にて、テーブルレベルとカラムレベルでデータの機密性レベル(下記図のMODERATE
など)を特定できます。
スキャンのスコープとしては、下記の2つを選べるようです。
- 単一プロジェクトの BigQuery データのプロファイリング | 機密データの保護のドキュメント | Google Cloud
- 組織またはフォルダの BigQuery データのプロファイリング | Sensitive Data Protection Documentation | Google Cloud
Hub のプロジェクトスコープで、データセットごとにスキャンを実施することがよさそうです。
引用元:単一プロジェクトの BigQuery データのプロファイリング | 機密データの保護のドキュメント | Google Cloud
高額な費用とならないように見積機能を用いて、コストを管理してください。
- 単一プロジェクトのデータ プロファイリング費用を見積もる | 機密データの保護のドキュメント | Google Cloud
- 組織またはフォルダのデータ プロファイリング費用を見積もる | 機密データの保護のドキュメント | Google Cloud
保護すべき項目を特定するために、検査テンプレートのカスタマイズを検討してください。
- テンプレート | 機密データの保護のドキュメント | Google Cloud
- 機密データの保護の検査テンプレートの作成 | Sensitive Data Protection Documentation | Google Cloud
プロファイリング結果を BigQUery にエクスポートし、テーブルでデータを保持することも可能です。
引用元:https://qiita.com/manabian/items/dd676f6712a8f23555f9
3. Dataplex カタログにて BigQuey のテーブルにおけるメタデータ(テーブル定義やリネージ)の表示
テーブルからビューを作成した場合などにも下記のようにデータリネージを表示することでができます。
データリネージはプロジェクトごとに Data Lineage API を有効にする必要があります。
引用元:データリネージの留意点 | Data Catalog Documentation | Google Cloud
リネージに関するデータについては SQL で取得する方法を確認できず、 Python、 あるいは、 REST API 経由で取得できるようです。
4. Dataplex 経由でのデータ提供
Dataplex において、1つ以上の BigQuery データセットを Zone としてまとめることで、データの提供が可能です。Analytics Hub によるデータ共有と比較すると、権限付与方法などの検討事項が多く、シンプルな運用を実施できない可能性があります。
引用元:Dataplex の概要 | Google Cloud
別のプロジェクトを Dataplexe にてデータ共有を実施する場合には、 Dataplex サービス アカウントに対して権限範囲が広い BigQuery 管理者ロールを付与する必要があり、 Publisher レイヤーからの賛同を得られない可能性もあります。 BigQuery 管理者ロールを付与する必要性にについては下記のように記述されています。
別のプロジェクトの BigQuery データセットをレイクに接続するには、データセットに対する BigQuery 管理者ロールを Dataplex サービス アカウントに付与する必要があります。
引用元:レイク内のデータアセットを管理する | Dataplex | Google Cloud
ただし、次のようなユースケースが発生した場合には、利用することを検討してください。
- データの書き込み権限を付与したい場合
- Cloud ストレージ上のファイルも共有したい場合
5. Hub プロジェクトの Dataplex の公開
Hub プロジェクトの Dataplex に Publisher や Subscriber を招待することは可能です。しかし、 Hub プロジェクトでは機微なデータを扱うため、権限付与は慎重に行うべきです。
6. Catalog によるメタデータの管理
Dataplex にて Catalog を選択する際に利用できるメタデータを整理する機能があります。ただし、本機能に関する情報が少なく、現時点で有用性を判断できていません。
7. Attribute Store を用いたデータへの権限付与
Dataplxe にて Attribute Store に基づき特定のデータの扱い方を定義できる機能があります。ビューに対して Attribute を設定する方法を確認できていないため、現時点では利用を推奨しません。
BigQuery オブジェクトのカラムに対して属性を設定すると、 BigQuery列ポリシータグとして追加される仕様です。
Dataplex は、列仕様ポリシーを BigQuery ポリシータグとして伝播します。BigQuery には、ポリシータグが 1 列に 1 つという制限があります。
引用元:Dataplex 属性ストアの使用 | Google Cloud
8. Profile を用いたデータのプロファイリングの実施
Dataplxe にてデータのプロファイリングを実施できる機能があります。Cloud Data Loss Prevention API (Sensitive Data Discovery の一部)のプロファイリングとは異なる機能です。 Hub レイヤーで実施する有用性を認識できていません。
引用元:Dataplex にて他プロジェクトの BigQuery のテーブルに対して Data Profile を実施する方法 #dataplex - Qiita
9. Data Qualitty を用いたデータ品質チェックの実施
Dataplxe にて指定した条件に基づいて BigQuery のテーブルなどをデータ品質チェックする機能があります。ただし、データ品質を行う上で私が最も必要と考えている、複数列における主キー制約、及び、外部キー制約を確認する方法を確認できず、ユースケースを特定できていません。
引用元:自動データ品質の概要 | Dataplex | Google Cloud
DMBOKの記述にもあるように、データ品質の要件は利用者(今回のアーキテクチャではPublisher)が決定するため、Hubレイヤーで汎用的なデータ品質要件を策定するのは難しいと考えています。
データ品質の度合いはデータ利用者の期待と要求を満たす度合いである。
引用元:データマネジメント知識体系ガイド 第二版 第13章 データ品質 1.3 本質的な概念
更新履歴
2024年9月20日 Attribute Store を利用しない方針に変更
Attribute をカラムに設定するとポリシータグが設定されるが、ビューではポリシータグを利用できないことが判明したため、Attribute Store を利用しない方針に変更。ビューの画面にてポリシータグを設定できないことを確認。
テーブルではADD POLICY TAG
を設定可能であることを確認。