Analytics Hub による サイロ化した BigQuery の 統合アーキテクチャのご提案 manabian

自己紹介 @manabian 【主な生業】 BI・DWH構築に関するSIベンダーにてテクニカルスペシャリスト職と して、次の業務を実施。 • Databricks におけるシステム実装論の整理とライブラリ開発 • データ分析基盤とアプリケーションの設計・構築に関する支援 • データ分析基盤に関する技術検証 趣味がデータ分析基盤に関する調査や検証であり、 主に Qiita を中心にデータ分析基盤に関する記事を投稿。 • 最強のデータ分析基盤を目指して～汎用的なデータ分析基盤の選定 方法の提案～ – Qiita • PySpark 開発時に知っておくべき７つのテーマ– Qiita • データエンジニア界隈で話題のdbt（data build tool）のまとめ #Python - Qiita

はじめに Google Cloud 上でサイロ化（乱立）している BigQuery データを統合するためのアーキ テクチャ案として、Analytics Hub の活用方法を共有します。 本アーキテクチャにて、適切な管理のもと、追加のストレージコストを最小限に抑えつつ、 Subscriber がコンピューティングコストを負担するなどの予算管理が可能となります。

Publishe Layer Analytics Hub による Big Query 統合アーキテクチャ Dataset A A table B table C table BigQuery PJ P1 (Publisher) Dataset B E table F table … BigQuery PJ P# (Publisher) … Hub Layer Subscriber Layer Big Query PJ S# (Subscriber) … Analytics Hub (from Publisher) Exchange A Exchange B … Analytics Hub (for Subscriber) Exchange A confidential Exchange A restricted conf. Exchange A high conf. Exchange B confidential … Big Query PJ H1 (HUB) Dataset A confidential A table view Masked B table view Dataset A restricted conf. B table view Dataset A high conf. Dataset B confidential … C table view E table view F table view Big Query S1 (Subscriber) Big Query PJ S2 (Subscriber) Dataset A confidential A table view Masked B table view Dataset A confidential E table view F table view Dataset A restricted conf. B table view

◼BigQuery は、プロジェクトやデータセットを柔軟に作成できる一方で、 個別最適化に偏ったシステムになるリスクがある。 ◼また、ストレージとコンピューティングの分離により容易にデータ共有が 可能だが、その一方で依存関係が複雑になる可能性がある。 BigQueryの柔軟性がもたらすデータサイロ化のリスク

サイロ化した BigQuery を Analytics Hub により統合 ◼3つのレイヤーに分割し Hub layer 経由で整理したデータの共有により、 既存の運用に依存せずに最適な Big Query の統合が可能となる。

ポイント・ツー・ポイント型による連携 ハブ＆スポーク型による連携 データ ハブ ◼Big Query にてデータセットを相互に共有すると複雑な関係性となるた め、Analytics Hub にてハブ＆スポーク型でシンプルな連携が可能となる。 Analytics Hub を経由すべき理由

統合アーキテクチャを構築する際のネットワーク設計 ◼統合アーキテクチャを構築する際には、BigQuery と Analytics Hub に おける VPC Service Controls の設計が重要となる。 引用元：Analytics Hub VPC Service Controls のルール | BigQuery | Google Cloud

統合アーキテクチャのレイヤー。 ◼Analytics Hub にて、 Publisher Layer とSubscriber Layer の２層で管 理するのではなく、 Hub Layer を追加した 3 層により管理する。 ◼Hub Layer により既存の BigQuery の構成に依存することなく 整理したデータの流通が可能となる。 # レイヤー 概要 1 Publisher Layer 他の BigQuery へデータ共有を行うために Hub に対してデータ共有するレイヤー。 2 Hub Layer Publisher から共有されたデータの整理を行い Subscriber へデータ共有するレイヤー。 3 Subscriber Layer Hub からデータ共有を受けるレイヤー。

ありがとうございました 本構成を試した方は 𝕏 アカウント宛に ご意見をお聞かせください。 manabian 𝕏: @manabian Qiita: manabian