データ統合プロジェクトはデータマネジメントの具現化 - 強みを発揮するBigQuery
2021/12/22
テクノロジーコンサルティング本部 シニアマネージャーの青柳雅之です。
・クラウドの技術力を高めたいと思う社員で構成される部門横断コミュニティであるAccenture Cloud Capability Groupのリード
・Accenture Google Business Group (AGBG) ソリューションアーキテクト
また、データ領域のプロジェクト経験をベースに付与される社内資格である、「Data Architect」を保持しています。
データ統合プロジェクトは、ともすれば、やみくもに連携可能な多くのデータソースとデータレイクをつなぐだけのプロジェクトになりがちです。ビジネスシナリオを特定せずにいきなりデータレイクを作ってみて利用してもらうというところからスタートするプロジェクトも多くあります。しかし、コストやリソースは有限ですので、どのようなビジネスシナリオで、どのようなデータを、どのようなタイミングで統合すれば、コストを最適化しながらビジネスの効果を得やすいのかを最初に検討することが重要です。今回のブログでは、データ統合プロジェクトとデータマネジメントの関係を起点に、特にBigQueryがどのような強みを発揮するのかについて記載します。
データ統合プロジェクトはデータマネジメントの具現化
データ統合プロジェクトと言えば、クラウド、データウェアハウス、ETLの導入といったシステム側の側面をイメージされる方が多いでしょう。データ統合を実現するシステム構築は全体の中の一部に過ぎず、データマネジメントの領域全般を実現しなければ、BIやアナリティクスといったビジネスに直結する施策は打てません。
データマネジメントの全体像を意識してどこから手を付けるのかを考えなくてはなりませんが、それは組織の状況によって異なります。下図では主要なデータマネジメントの主要なイニシアチブについて依存関係の例を記載しています。各イニシアチブの順番はその組織の取り組み状況によって異なりますので、あくまで参考の位置づけとして検討ください。
Short-Term:
どのようなデータが存在するのかを起点に(1)、データモデルはどうなるのか（2）、その中で組織のマスターとなるべきデータは何か(3)を検討します。マスターデータ管理は、データの冗長性をなくしてデータ品質やコスト効率を高める活動であり、データディスカバリーが前提となります。 データモデリングやマスターデータ管理は、組織で利用できるデータが明らかになってから取り組むケースが多いです。
そして、これらのデータを収集、保持、変換、統合するにはどのような基盤が必要か（4）、その基盤のキャパシティは要件を満たせるのか（5）、組織のセキュリティポリシーは存在するのか（存在しなければ定義）（6）を議論します。データ品質はだれが責任を持つのか(7)、も重要な検討要素です。データ統合基盤側か、それともビジネス部門側が責任をもつのか、が議論になります。通常、データ統合プロジェクトと言えばデータアーキテクチャ(4)をメインに据えるケースが多いですが、他のイニシアチブも併せて実施しなければ、データの利活用は十分に行うことはできません。
Mid-Term:
データディスカバリーで得られたデータの情報からデータを分類します（7）。(7)によって分類ごとのデータの品質要件も見えてくるのですが、データ品質を向上させるための施策を計画したり(8)、データライフサイクル、リテンション（維持）のプロセスを定義します(9)。同様にマスターデータのライフサイクルも定義します(10)。セキュリティポリシー策定に時間がかかるケースが多いため、もしかしたらShort-termで開始しても(6)はこの時期にずれ込むかもしれません。そして、ポリシーが定義できたら、想定しているアーキテクチャやライフサイクルプロセスがそのポリシーを満たすかどうかを評価します（11）。
Long-Term:
データ品質管理の計画は、このタイミングでPoC実行に移ります(12)。データライフサイクルの要件やプロセスの定義から、利用するストレージのタイプが決まります(13)。
データマネジメントの起点はデータディスカバリー
ここから、データ統合プロジェクトの起点となる、データディスカバリーについて深堀をします。
IT部門がデータ統合基盤、分析基盤の企画を行うも、ビジネス部門が協力的ではなく、彼らがどのようなデータを持っているのか、どのような利用シナリオでデータを利用しているのか（もしくは今後何をやりたいのか）、を集められないケースも多いです。この場合、IT部門が先に基盤を作るも、実際のデータを使った検証を行うまでに期間が開いてしまいます。よって、最初はビジネス部門からの協力を得られることに注力します。
まず、将来の業務に必要なビジネスシナリオや、データ取得に改善が必要なビジネスシナリオをリスト化します。このリストでは関連するデータソースの情報も記載します。次に、ビジネスインパクトと技術的難易度の2つの軸を使って各ビジネスシナリオを評価します。この2つの評価軸は組織によって内容が異なりますが、いくつかの例を挙げます。
図：ビジネスインパクトと技術的難易度の2つの軸でビジネスシナリオを評価
一般的には、ビジネスインパクトが高くて技術的難易度が低いビジネスシナリオに属するデータソースから統合するのがよいと思われます。理由は当然ながら、ビジネス効果が高く、統合コストが低いからです。
GCPはデータディスカバリーのフィージビリティースタディに威力を発揮
上記は机上でのデータディスカバリーに該当するわけですが、その結果に基づき、早めにデータを統合してその可否や品質状態を確認することが、データ統合プロジェクトの初期フェーズでは重要なプロセスとなります。ここで、BigQueryを利用した場合のメリットについて見て行きましょう。
①マルチクラウド環境におけるデータハブとして活用するシナリオ
どのようなデータが存在するのか（新規に必要なのか）、データ活用で何をしたいのか(Why)、どんなデータを蓄積するのか(What)といった、まだどのようなデータが有効かどうか不明な状況において、SaaSの強みを生かして、早期にデータを収集、統合することを可能にできることはBigQuery大きなメリットです。すでにAWSやAzureといったGCP以外のパブリッククラウドやオンプレミスでデータ基盤を保有している組織も多いことでしょう。これはデータのサイロ化といったデータ統合における大きなチャレンジを引き起こす状況なのですが、このような他のデータ基盤からのデータを統合するハブとして有効です。
図：データハブとして位置づけられるGCPのデータ統合基盤
この図ではデータを、BigQueryを含むGCPのデータ基盤に転送して集約しています。
一方で、Google Cloud Next ‘21では、BigQuery Omniの様々な新機能がアナウンスされました。Google Cloud、AWS、Azure をまたぐクロスクラウド分析を 1 つの画面で実施できます。BigQuery Omniはデータ自体を各クラウドから動かしません。AWS の S3 データや、Azure の Azure Blob Storage データに安全に接続できます。データ アナリストは、使い慣れた BigQuery ユーザー インターフェースでデータを直接クエリでき、データのある場所で BigQuery の能力を活用できます。将来的にはAWSやAzureからデータをBigQueryに転送するクロスクラウド転送と言ったサービスも提供されるとのことです。クロスクラウド転送は Google Cloud で分析を完了するために必要な各クラウドからのデータのBigQueryへの移動を可能にします。データを移動させた場合、各クラウドに存在するオリジナルデータを変えずに、BigQueryの中でセキュリティポリシーや品質についての施策を実施することも可能です。
➁ブリックデータセットなど、大容量のデータを扱うシナリオ
社内データだけではGBやTBクラスのデータにとどまるかもしれません。しかし、社内にあるデータを統合するだけではなく、パブリックデータセットも取り込んで横断的に分析を行うシナリオではどうでしょうか。TBからPBクラスのパブリックデータセットを大量に使う分析では、パフォーマンスに優れているBigQueryの活用が向いています。BigQueryはコンピューティングノードのキャパシティプランニングやサイジング、メンテナンス作業といったユーザーによる運用作業が不要です。また、BigQueryにはすぐに使えるパブリックデータセットが大量に用意されています。
図：大量のパブリックデータセットを使った分析を可能にするBigQuery
最後に
データマネジメントの各イニシアチブと絡めてデータ統合プロジェクトの進め方を説明しました。データディスカバリーはデータマネジメントの起点であり、データの価値を測る上でも非常に重要ですが、BigQueryがそこで重要なタスクを実施するためのツールとして利用できることを示しました。当然ながらデータディスカバリーだけではなく、通常のデータ基盤としても利用できます。また、データマネジメントの実現にはGCPを基盤としながらも、要件によってはDatabricksなどの3rd party製ツールと組み合わせて使うことでよりスピード感のあるデータ基盤の展開も可能となると思われます。今後、こういった側面でもブログを書いていきたいと思います。
