第1回 読んでおきたい、SokoPの「Google Cloud 実践ガイド」

Google Cloudのエンジニアが伝授する、BigQueryの実践的な導入・活用ガイド

Google Cloud「BigQuery」のメリットと効率的な導入手法を知る

文●SokoP(浦底博幸)/Google Cloudパートナーエンジニア

  • この記事をはてなブックマークに追加
  • 本文印刷

 みなさん、はじめまして。これからgrasysさんのマイクロサイトに寄稿させていただく、Google Cloudのパートナーエンジニア「SokoP」こと浦底と申します。grasysさんともども、よろしくお願いいたします。

 記念すべき第1回は、Google Cloudを代表するサービスの1つである「BigQuery」をご紹介し、実際にみなさんに活用いただく際のガイドとなるような情報をお送りいたします。

BigQueryの導入により得られるメリットとは

 BigQueryとは、Google Cloudが提供するエンタープライズ データ ウェアハウスになります。

 通常、データ ウェアハウスを活用するうえでは、処理するデータ量などに合わせて適切なハードウェアやインフラストラクチャの準備や、それらのリソースを意識したパフォーマンス設計、また、日々の分析業務にあわせてリソースを効率的に利用するための運用設計などが必要となります。BigQueryは、そのようなリソース制約からみなさんを開放します。BigQueryはリソースのプロビジョニングをGoogle Cloudが担う、フルマネージドのサーバーレス データ ウェアハウスです。みなさんがリソースを意識しなくてよいことがもたらす複数のメリットをご紹介します。

 まず、先にも挙げたとおり、データ量や処理量に対する制約が取り払われます。まだデータ分析を始めてないお客様でも、より多くのデータを処理できることがデータ分析のメリットを享受するために良いことであることは、想像にたやすいかと思います。また、多くのデータを処理できるということは、すでにデータ分析を活用しているお客様にとっても、今までに不可能であったデータ分析が可能になるということです。

 リソースの制約は、さまざまな弊害をもたらします。処理するデータ量を制限するだけでなく、本来であれば分析において結合したいデータソースを活用しきれない運用にとどまるほか、リソース制約が当たり前になってしまうと、処理可能な範囲での分析から得られる分析結果がビジネスのフローに組み込まれてしまいます。また、分析にかかる時間のコストも、ビジネスのリードタイムとして組み入れられてしまうと、せっかくの分析を基にした判断の効果も薄れるとともに、リードタイムによる待ちがありきのビジネスサイクルが確立してしまいます。リソースの制約によって、データ分析のメリットを享受できるユーザーが限られてしまうことも考えられます。

 今まで溜めていただけで活用しきれていなかったデータをも分析対象とすることで、今まで見えていなかった傾向が見えてくるでしょう。今まで分析において結合できていなかったデータを結合することで、今までと異なった角度でのインサイト、今までと違った業務プロセスにおけるデータ活用も考えられます。分析にかかる時間が短くなることで、ビジネスサイクルが速まれば、業務フローも変わります。セミリアルタイムからリアルタイムの分析も実現可能になるでしょう。そして処理量と処理時間の懸念が払拭されることで、より多くのユーザーがデータ分析の恩恵を直接、即時に、直感的に得られることになります。データ分析の専門家だけでなく、誰もがビジネスの最前線で迅速にデータドリブンの判断を得られる「データの民主化」が実現可能となるのです。

BigQueryを効率良く導入するためには

 それでは、BigQueryを導入するためのガイドをご紹介いたします。

 これからデータ分析に臨まれるみなさん、もしくは、すでにデータ分析を実施しており新たな基盤としてBigQueryを検討しているみなさんにも共通するはじめのステップは、まずBigQuery上で実現するユースケースを発見し、メリットを事前に分析することです。

 よくあるアプローチとしては検証対象となる複数プラットフォームを、単純に横並びで比較検証する手法ですが、先に挙げたとおり、BigQueryは独自の基盤で構成されており、かつ期待する効果も従来を超えるものです。まずはみなさんの既存のユースケースの状況、成果、そして今後に期待する新たなユースケースを整理し、それらの目的とビジネス上の価値を定めます。次に、そのユースケースの基盤となるデータセット、テーブル、スキーマは何か、ユースケース同士の依存関係なども含めたワークロードの規模感、データ量などの機能性以外にデータに求められる最新性、データセットとワークロードを築くデータ パイプラインの特徴、分析結果を活用する上での可視化やアクションの方式と手法などを描きます。まずこれらを明確にすることが、みなさんが商用でBigQueryを活用いただくうえでの、真の費用対効果を測るアプローチとなります。そして、これらをBigQuery上で機能的に実現するためにどう実装するかを検証するのが次の工程となります。

 先のユースケースを基に、次は実際にBigQueryを評価していきます。

 先にも挙げたとおり、この工程における検証は、あくまでみなさんが描かれたユースケースをBigQueryの機能で実装することが第一であり、そこが定まらないまま、もしくはみなさんのビジネス価値に直結しないようなサンプルのユースケースなどで性能やコストをご評価いただくことは、せっかくの評価過程に割くみなさんのコスト(時間、人、金銭を含む)から得られる成果の価値が薄れてしまいます。

 ただしこれは、性能とコストの評価を先送りにしてよいという意味ではありません。みなさんのユースケースを実現するアーキテクチャやデータ定義が確立すれば、そのうえで商用データからのサンプルのボリュームを線形的に増やしていきながら、性能面とコスト面も評価していくアプローチのほうが、みなさんのビジネス価値に対するパフォーマンスと費用対効果をより正確に測れる手法となるのです。これは商用運用に入った際の日々のデータ取り込みにおける運用設計にもつながります。

 また、実際のデータ分析フローを商用で活用していくうえでも、効果やデータ量、パフォーマンスやコストを、運用しながらイテレーションして効率化していくことが必要となります。初期に構築されたパイプラインをそのまま運用し続けることは、ビジネスの変化やデータ量の増加に対し、費用対効果のバランスが崩れたままビジネスが継続することになります。効果を測定しながらさまざまな視点からチューニング可能なのも、クラウドサービスならではの特徴です。

 みなさんのビジネスドメインに関連するデータを用いて検証することで、新たな付加検証効果も見いだせます。先の評価の中では、性能コスト評価の一環でサンプルデータを増加させて検証しています。これは商用運用におけるデータ管理の設計にもつながっています。データに求められる最新性からデータのライフサイクルも設計できます。またデータのパイプラインが設計されることになるため、移行時もしくは運用開始後に新たなデータソース追加を検討するうえでの拡張性の視点も考慮できます。

 そしてこのデータ パイプラインの観点は、商用運用時もさることながら、初期導入ならびに既存基盤からの移行段階で重要な要素を占めます。

 初期導入時には、当然のことながら十分なデータソースは存在しません。それでは既存基盤からの移行ではどうでしょうか。既存基盤に膨大なデータソースが存在したとしても、それらすべてを新基盤に移しきってからピンポイントで運用を切り替えるということは非現実的です。必ず並行運用を含めた移行期間が発生します。もしも適用可能であるならば、移行期間内においてデータソースの段階移行アプローチのもと、評価工程と同様の効果測定手法を取り入れ、移行中においても課題点や改善点をいち早く検知し対処するイテレーションを取り入れることで、スムースな完全移行を実現することも可能ではないでしょうか。そしてその完全移行時にはすでに、さらにその先のデータ分析を進歩させるサイクルが確立したうえで商用運用に臨めることになります。

* * *

 いかがでしたでしょうか。簡単ですがBigQueryの解説と実践のガイドをご紹介いたしました。より詳しくは、Google Cloud 公式ドキュメントの「データ ウェアハウス使用者のための BigQuery とデータ ウェアハウスの BigQuery への移行: 導入と概要 | データ ウェアハウスから BigQuery への移行」をご参照いただければ幸いです。

 次回の本連載では「Looker解説・実践ガイド」をお届けする予定です。それではまた次回、お楽しみに。

■関連サイト

過去記事アーカイブ

2022年
01月
02月
03月
04月
05月
06月
2021年
03月
04月
05月
06月
07月
08月
09月
10月
11月
12月
2020年
04月
05月
08月
09月
10月
11月
12月
2018年
09月
2017年
06月
2014年
07月