店舗と本部をつなぐ全社横断データ基盤構築のパターン

小売企業が取り扱うデータには、店舗などのリアルな世界から得られるデータと、E コマースなどのデジタルな世界から得られるデータの2種類があります。これらの 2 種類のデータと、本部で保有する商品や店舗などに関するマスタデータをかけ合わせることで、リアルとデジタルを横断した統一的なデータ基盤を構築することができます。また、データ基盤に蓄えられたデータをAPIを通じて提供することで、レポーティングや BI によるデータ分析をはじめとして、社内の新規サービスや、社外とのデータ連携などデータの活用シーンが広がり、効果的な打ち手を必要なタイミングで実施することができるようになります。

店舗と本部をつなぐ全社横断データ基盤構築のパターン

店舗システムとクラウド環境の閉域網接続のパターン

解決する課題・使い所

店舗には、店舗情報を集約管理し、本部システムと連携するためのストアコンピュータが設置されます。ストアコンピュータは店舗の全ての情報を管理するため、店舗データを活用するためにはデータ基盤との連携は不可欠となります。しかし、ストアコンピュータは、一般的にインターネットに接続されていない状態で設置されていることが多いです。そのため、Google Cloud への接続は閉域網を利用する必要があります。閉域網で接続してしまうと、Google Cloud のスマートアナリティクス ソリューションと連携することができます。例えば、店舗の POS データや在庫データを、データが発生した直後にストリーミングで Google Cloud に送信し、リアルタイムに各店舗の状況を可視化する、といったことも実現可能となります。

アーキテクチャ

ここでは、店舗システムはパブリックなネットワークに出られないことを想定しています。店舗システムから Google Cloud への経路には、Cloud Interconnect を利用した閉域網による接続を想定をしています。

Cloud Interconnect を利用した閉域網による接続

Cloud Interconnect

オンプレミス ネットワークと Google Cloud Virtual Private Cloud (VPC) ネットワークの間を内部 IP アドレスによって通信します。これにより、オンプレミスからクラウド環境へ、またクラウド環境からのオンプレミス環境へと直接アクセスが実現されます。

利点

  • オンプレミス ネットワークと VPC ネットワークとの間のトラフィックは、公共のインターネットを通過しません。トラフィックは専用接続または専用接続を持つサービス プロバイダを通過します。公共のインターネットを通過しないことでトラフィックのホップ数が減るため、トラフィックのドロップや中断が発生する障害点が少なくなります。
  • Cloud Interconnect をオンプレミス ホスト用の限定公開の Google アクセスと併用することで、外部 IP アドレスではなく内部 IP アドレスを使用してオンプレミス ホストから Google Cloud の API やサービスにアクセスできます。詳細については、VPC のドキュメントのサービスのプライベート アクセス オプションをご覧ください。

注意事項

Interconnect には 2 つの接続方式があります。専用接続 (Dedicated Interconnect) を作成するかサービス プロバイダ (Partner Interconnect) を使用して、VPC ネットワークに接続できます。相互接続タイプを選択するときは、接続ロケーションや容量などの接続要件を考慮し、接続タイプを選択してください。

E コマース サイトやアプリ情報の BigQuery へのデータ集約のパターン

解決する課題・使い所

E コマース サイトの運営やデジタル上のマーケティング活動を通じて様々なデータが取得されます。E コマースサイトの改善活動や、デジタル上の顧客体験の向上を目指して、デジタル上で取得されたデータを活用して PDCA サイクルを回すことはしばしば行われます。顧客体験はデジタルとリアルの融合にシフトしているため、デジタル上のデータで完結させるのではなく、店舗データなどと掛け合わせたデータをもとにした分析や改善活動を行いたいという要望があります。そこで、デジタル上で取得される種々のデータを BigQuery に連携することで、データ基盤の組織横断性をさらに向上させ組織でのデータ活用を促進させます。Google アナリティクス と Firebase には BigQuery へのデータエクスポート機能が提供されているため、BigQuery へのデータ連携を容易に行うことができます。

BigQuery へのデータ集約のパターン

Google アナリティクス

Google アナリティクスは、 Google が提供するアクセス解析ツールです。サイト上のユーザーの行動データを収集し解析できるツールです。Google アナリティクスで収集されたデータを BigQuery にエクスポートすることができます。

Firebase

Firebase は、モバイルアプリケーションや Web アプリケーション開発を支援するプラットフォームです。アナリティクス、データベース、メッセージ、クラッシュ レポートなどの開発に必要となる機能を提供します。 Firebase のデータは BigQuery にエクスポートすることができます。

利点

  • ウェブやアプリのデータをプログラムを作成することなく BigQuery に連携させることができます。
  • BigQuery にデータがエクスポートされたあとは、BigQuery 自身のパワフルなコンピューティングパワーを利用した分析を行うことができます。
  • BigQuery は Lookerデータポータル などの BI ツールやレポーティングツールと連携することができます。 SQL による分析作業に精通していないユーザーもデータを活用することができるようになります。

注意事項

データエクスポートにはオプションとしてストリーミングを選択することもできます。その場合、 BigQuery のストリーミング挿入を活用すると、データの取り込みに対してコストが発生します。

データパイプライン構築による活用目的別データマート作成のパターン

解決する課題・使い所

構造化データも非構造化データも一緒くたにしてローデータを保存する目的で利用されるデータストアをデータレイクと呼びます。例えば、マスタデータ自体は構造化データに位置づけられますが、マスタデータに含まれる商品画像などのデータは非構造化データに位置づけられます。データレイクは、まず第一にデータを蓄えることを目的としてるため、データレイク蓄えられたデータはそのままではビジネスで利用可能ではありません。データを目的別に整理し、利用可能な形に整形する必要があります。整形を追えたデータが保存され、高速にアクセスすることができるデータストアをデータウェアハウスと呼びます。例えば、データウェアハウス上では、売上データとマスタデータを結合可能な状態で保存しておき、売上を店舗軸や商品軸、その他様々な軸で集計や分析を行います。データウェアハウスのデータをビジネス目的に応じてさらに整形し、抽出したデータストアをデータマートといいます。例えば、商品開発を行っている部署向けに、今どの地域でどんな商品が売れているかのダッシュボードを作る場合、そのバックエンドとなるデータストアがデータマートです。データレイクからデータウェアハウス、データウェアハウスからデータマートへのデータの一連の投入や抽出、変換作業全体をデータパイプラインといいます。データパイプラインは大量のデータを高速に扱う必要があります。データパイプラインを効率的に構築管理することでデータ基盤の有用性が高まります。

アーキテクチャ

データパイプライン構築による活用目的別データマート作成のパターン

Cloud Storage

ファイル形式のデータであれば非構造化データも構造化データも取り扱うことができます。アーカイブ目的からマルチメディアの配信まで多様な目的に対応しており、目的に応じた最適なコストを実現することができるストレージです。

BigQuery

ペタバイトスケールのデータまで取り扱うことのできるエンタープライズデータウェアハウスです。エンタープライズデータウェアハウスとカテゴライズされますが、ストレージのコストが Cloud Storage とほぼ同程度のため、構造化データに限ればデータレイクとして利用することも可能です。また、データマートとして利用することも可能です。

Dataflow

様々なデータ処理のパターンの実行に対応したデータパイプラインを実現する上で欠かせないマネージドサービスです。バッチ処理もストリーミング処理も対応していて、負荷状況に応じて動的にスケールするため、大規模なデータに対する複雑なデータ処理にも対応しています。

Cloud Composer

フルマネージドのワークフローオーケストレーションサービスです。処理の依存関係やスケジュール実行を管理することができ、BigQueryのクエリや、Dataflow上の処理を組み合わせて一連のデータパイプライン全体を管理します。

利点

  • BigQuery 上でほぼ全ての処理を完結させることができるため、複数のデータベースを構築管理する必要がありません。
  • マネージドサービスで完結するため、すぐに作業を開始することができ、インフラの管理コストを低くできます。
  • データ処理を担う BigQuery や Dataflow は高いスケーラビリティを有するため、小規模なデータから大規模なデータまでは同一の構成でカバーすることができます。

注意事項

BigQuery で行うべき処理と Dataflow で行うべき処理を正しく見分ける必要があります。Dataflow は BigQuery と比較して自由度が高い処理を行うことができますが、BigQuery 上のデータ処理は BigQuery で完結させることがデータパイプラン全体として最もパフォーマンスが高くなるでしょう。BigQuery で実現できる処理は可能な限り BigQuery 上で行うという原則を遵守することが重要です。

BigQuery に蓄積したデータ活用のパターン

解決する課題・使い所

データウェアハウスやデータマートとして BigQuery が利用されると多種多様なデータが蓄積されます。一方、SQL や BigQuery API を利用して蓄積されたデータにアクセスし、分析するにはある程度のエンジニアリングスキルセットが求められます。ビジネスインテリジェンスを代表とする GUI ベースの分析ツールと BigQuery を連携することで、非エンジニアもデータへのアクセスが容易になりデータの活用が飛躍的に容易になります。

アーキテクチャ

BigQuery に蓄積したデータ活用のパターン

Looker

次世代型の BI サービスです。LookML というモデリング言語を利用することにより、複雑な SQL クエリを管理する手間から解放され、分析対象に集中することができます。また、データを内部に保持しないため Looker 自体が全体のボトルネックになることはありません。また、BigQuery だけでなく複数のデータベース、データウェアハウスに対応しているため、Google Cloud 上にないデータも分析対象とすることができます。

データポータル

様々なデータソースに対して美しい可視化の画面の作成と柔軟な共有ができる無料のレポーティングツールです。ドラッグ&ドロップを中心にした直感的な操作で美しいレポーティング画面を構築することが可能になります。

Connected Sheets

Google スプレッドシート上で BigQuery に保持されているデータに対して SQL を利用することなくアクセスすることができるようになるサービスです。データは最新の状態に維持され、スプレッドシートベースでビッグデータの分析を実現することができるようになります。 

利点

  • GUI ベースのツールは非エンジニアの分析作業者と相性が非常に良く、導入することでデータの利活用が飛躍的に促進します。
  • 各々のツールはデータを美しく可視化することができるため、数値として分析結果を共有する以上に多くの人に直感的な理解を促すことができます。
  • BigQuery のテーブルやカラムに対する権限管理の仕組みと組み合わせることで、役職に応じて閲覧できるレポートに制限をかけることができます。 

注意事項

利用するツールに応じて追加のコストが生じる可能性があります。例えば、Looker を利用するには追加で Looker との契約が必要となります。また、各ツールの裏では BigQuery のクエリが実行される場合がある点も認識しておく必要があります。 BigQuery はデータスキャン量に応じた従量課金であるため、予期せぬコストが発生する可能性があります。BigQuery には利用するスロット数に応じてコストを定額で支払う BigQuery Rservations もありますので、利用用途に応じて考慮に入れると良いでしょう。

API によるシステム間のデータ連携パターン

解決する課題・使い所

従来の考え方ではデータとビジネス ロジックは一体化し、アプリケーションとして利用可能としていました。一方、このアプローチでは、データは存在するものの、利用するために都度データ取得のロジックをアプリケーション側で用意する必要がありました。データの利活用という観点で考えた時、このアプローチはデータ活用に対するアクションのスピードを低下させる要因となっていました。データ基盤にデータを操作させるための API を用意し、ビジネスロジックはデータ基盤と分離しアプリケーション層に持たせます。データ基盤とビジネスロジックを明確に分離することで、データ基盤の保守性や拡張性は飛躍的に高まります。また、標準的なインターフェースとして API を提供することで、社内外のシステムとの連携がより容易になり、データの活用が促進されます。

アーキテクチャ

API によるシステム間のデータ連携パターンのアーキテクチャ

Apigee

Apigee は API の開発と管理を行うためのプラットフォームです。バックエンドサービスの API を抽象化して提供し、セキュリティやアクセスに関するレート制限を割り当てて、API 利用状況に関するデータを提供します。

AppEngine

フルマネージドのアプリケーション実行環境です。様々なプログラミング言語を利用することができ、簡単に Web アプリケーションを構築することができます。オートスケールなどの特徴的な機能を備えており、小規模なアプリケーションから大規模なアプリケーションまで対応することが可能です。本パターンでは Apigee の API バックエンドとして利用する想定となります。 

利点

  • API を導入することで、データ層とアプリケーション層を完全に分離させることができます。それにより、アプリケーションの改善や追加が容易になり、新サービスの導入までの感覚を短くさせることができます。
  • Apigee を利用することで、統一的な API 層を導入することができ、 API に一貫性をもたせることができるようになります。また、Apigee には API を管理するための様々な機能が提供されており、 API へのトラフィックを制限するなどし、 API バックエンドの負荷状況に合わせた負荷のコントロールを行うこともできます。 

注意事項

データソースに対してどの粒度でデータを返す API を提供するかについて慎重に設計を行う必要があります。利用者にとって必要なデータが容易に取得できる API になっていないと、 API の利用が促進されません。 

参照文献

API 設計ガイド