店舗と本部をつなぐ全社横断データ基盤構築のパターン
Embedded Files
小売企業が取り扱うデータには、店舗などのリアルな世界から得られるデータと、E コマースなどのデジタルな世界から得られるデータの2種類があります。これらの 2 種類のデータと、本部で保有する商品や店舗などに関するマスタデータをかけ合わせることで、リアルとデジタルを横断した統一的なデータ基盤を構築することができます。また、データ基盤に蓄えられたデータをAPIを通じて提供することで、レポーティングや BI によるデータ分析をはじめとして、社内の新規サービスや、社外とのデータ連携などデータの活用シーンが広がり、効果的な打ち手を必要なタイミングで実施することができるようになります。
店舗システムとクラウド環境の閉域網接続のパターン
店舗システムとクラウド環境の閉域網接続のパターン
解決する課題・使い所
店舗には、店舗情報を集約管理し、本部システムと連携するためのストアコンピュータが設置されます。ストアコンピュータは店舗の全ての情報を管理するため、店舗データを活用するためにはデータ基盤との連携は不可欠となります。しかし、ストアコンピュータは、一般的にインターネットに接続されていない状態で設置されていることが多いです。そのため、Google Cloud への接続は閉域網を利用する必要があります。閉域網で接続してしまうと、Google Cloud のスマートアナリティクス ソリューションと連携することができます。例えば、店舗の POS データや在庫データを、データが発生した直後にストリーミングで Google Cloud に送信し、リアルタイムに各店舗の状況を可視化する、といったことも実現可能となります。
アーキテクチャ
ここでは、店舗システムはパブリックなネットワークに出られないことを想定しています。店舗システムから Google Cloud への経路には、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 コマース サイトやアプリ情報の BigQuery へのデータ集約のパターン
解決する課題・使い所
E コマース サイトの運営やデジタル上のマーケティング活動を通じて様々なデータが取得されます。E コマースサイトの改善活動や、デジタル上の顧客体験の向上を目指して、デジタル上で取得されたデータを活用して PDCA サイクルを回すことはしばしば行われます。顧客体験はデジタルとリアルの融合にシフトしているため、デジタル上のデータで完結させるのではなく、店舗データなどと掛け合わせたデータをもとにした分析や改善活動を行いたいという要望があります。そこで、デジタル上で取得される種々のデータを BigQuery に連携することで、データ基盤の組織横断性をさらに向上させ組織でのデータ活用を促進させます。Google アナリティクス と Firebase には BigQuery へのデータエクスポート機能が提供されているため、BigQuery へのデータ連携を容易に行うことができます。
Google アナリティクスは、 Google が提供するアクセス解析ツールです。サイト上のユーザーの行動データを収集し解析できるツールです。Google アナリティクスで収集されたデータを BigQuery にエクスポートすることができます。
Firebase は、モバイルアプリケーションや Web アプリケーション開発を支援するプラットフォームです。アナリティクス、データベース、メッセージ、クラッシュ レポートなどの開発に必要となる機能を提供します。 Firebase のデータは BigQuery にエクスポートすることができます。
利点
ウェブやアプリのデータをプログラムを作成することなく BigQuery に連携させることができます。
BigQuery にデータがエクスポートされたあとは、BigQuery 自身のパワフルなコンピューティングパワーを利用した分析を行うことができます。
BigQuery は Looker や データポータル などの BI ツールやレポーティングツールと連携することができます。 SQL による分析作業に精通していないユーザーもデータを活用することができるようになります。
注意事項
データエクスポートにはオプションとしてストリーミングを選択することもできます。その場合、 BigQuery のストリーミング挿入を活用すると、データの取り込みに対してコストが発生します。
このパターンで作成された事例
関係するデザインパターン
参照文献
データ パイプライン構築による活用目的別データマート作成のパターン
データ パイプライン構築による活用目的別データマート作成のパターン
解決する課題・使い所
構造化データも非構造化データも一緒くたにしてローデータを保存する目的で利用されるデータストアをデータレイクと呼びます。例えば、マスタデータ自体は構造化データに位置づけられますが、マスタデータに含まれる商品画像などのデータは非構造化データに位置づけられます。
データレイクは、まず第一にデータを蓄えることを目的としてるため、データレイク蓄えられたデータはそのままではビジネスで利用可能ではありません。データを目的別に整理し、利用可能な形に整形する必要があります。整形を追えたデータが保存され、高速にアクセスすることができるデータストアをデータ ウェアハウスと呼びます。例えば、データウェア ハウス上では、売上データとマスタデータを結合可能な状態で保存しておき、売上を店舗軸や商品軸、その他様々な軸で集計や分析を行います。
データ ウェアハウスのデータをビジネス目的に応じてさらに整形し、抽出したデータストアをデータマートといいます。例えば、商品開発を行っている部署向けに、今どの地域でどんな商品が売れているかのダッシュボードを作る場合、そのバックエンドとなるデータストアがデータマートです。
データレイクからデータ ウェアハウス、データ ウェアハウスからデータマートへのデータの一連の投入や抽出、変換作業全体をデータ パイプラインといいます。データ パイプラインは大量のデータを高速に扱う必要があります。データ パイプラインを効率的に構築管理することでデータ基盤の有用性が高まります。
アーキテクチャ
ファイル形式のデータであれば非構造化データも構造化データも取り扱うことができます。アーカイブ目的からマルチメディアの配信まで多様な目的に対応しており、目的に応じた最適なコストを実現することができるストレージです。
ペタバイトスケールのデータまで取り扱うことのできるエンタープライズ データウェアハウスです。エンタープライズ データウェアハウスとカテゴライズされますが、ストレージのコストが Cloud Storage とほぼ同程度のため、構造化データに限ればデータレイクとして利用することも可能です。また、データマートとして利用することも可能です。
様々なデータ処理のパターンの実行に対応したデータ パイプラインを実現する上で欠かせないマネージド サービスです。バッチ処理もストリーミング処理も対応していて、負荷状況に応じて動的にスケールするため、大規模なデータに対する複雑なデータ処理にも対応しています。
フルマネージドのワークフローオーケストレーション サービスです。処理の依存関係やスケジュール実行を管理することができ、BigQueryのクエリや、Dataflow上の処理を組み合わせて一連のデータ パイプライン全体を管理します。
利点
BigQuery 上でほぼ全ての処理を完結させることができるため、複数のデータベースを構築管理する必要がありません。
マネージド サービスで完結するため、すぐに作業を開始することができ、インフラの管理コストを低くできます。
データ処理を担う BigQuery や Dataflow は高いスケーラビリティを有するため、小規模なデータから大規模なデータまでは同一の構成でカバーすることができます。
注意事項
BigQuery で行うべき処理と Dataflow で行うべき処理を正しく見分ける必要があります。Dataflow は BigQuery と比較して自由度が高い処理を行うことができますが、BigQuery 上のデータ処理は BigQuery で完結させることがデータ パイプラン全体として最もパフォーマンスが高くなるでしょう。BigQuery で実現できる処理は可能な限り BigQuery 上で行うという原則を遵守することが重要です。
このパターンで作成された事例
参照文献
Dynamic Pricing を実現するデータ活用パターン
Dynamic Pricing を実現するデータ活用パターン
旅行業をはじめとして、小売・交通・製造・エンタメなど、さまざまな業界で、価格を動的に変更・最適化するダイナミック プライシングの導入が加速しています。例えば Amazon では、何百万ものアイテムの価格が数分ごとに変更されています。
このダイナミック プライシングは、商品やサービスの価格を需要と供給の状況に合わせて変動させる価格戦略のことであり、特にリテーラーにとって重要な競争力の源泉となり、将来の勝者を決めるコア機能の 1 つです。
ダイナミック プライシングを活用した分析例として、下記のようなものが挙げられます。
中古カメラの販売・買取に AI プライシングを導入。販売数を予測し、販売数が最適化される価格を採用。粗利率アップ、営業利益率アップを実現。
家電量販店において、電子店を利用した変動価格制を導入。15,000 点のアイテムから、土日限定や今日のお買い得、緊急割引などの分析により表示内容を変動させ、全店で 400 ～ 500 人の閉店後作業・早出作業を削減。
ダイナミック プライシングを実現するためには、大規模なデータでも問題なく収集、格納、分析できるプラットフォームが不可欠となります。Google Cloud では、SQL で分析ができ、ペタバイト規模のデータも分析可能なデータ ウェアハウスである BigQuery、少量の学習データと簡単な操作で高い精度の機械学習モデルが作成できる Vertex AutoML、大量のデータをストリーミングで収集することができる Pub/Sub、ストリーミング データを変換、処理するオートスケール可能な Dataflow など、データ分析に最適なさまざまなサービスを提供しています。
ここでは、ダイナミック プライシングを実現するためのデータ分析基盤を、Google Cloud で構築する際のパターンを解説します。
解決する課題・使い所
ダイナミック プライシングを実現する場合の課題の 1 つ目は、モデルを開発・運用できるようになるための学習のコストと時間です。BigQuery と AutoML を使うことで、データ分析者やビジネスユーザーは、既存のスキルセットを活用して、工数とコストを抑えながら、モデルの開発・運用を迅速に始めることが可能です。
2 つ目の課題は、データ統合、つまりダイナミック プライシングを実現するために必要な多様で大量のソースデータを、シンプルかつ高速に収集し、モデルにつなげることです。ダイナミック プライシングでは、販売実績、在庫情報、ウェブサイトのアクセス状況、SNS 情報など、多様な情報を基幹システム、外部データ、SaaS サービスから収集し、モデルにつなげることで、高精度のモデルを実現していくことが重要です。Google Cloud では、BigQuery Data Transfer Service や Data Fusion などを活用することで、シンプルかつ高速にデータの統合が可能です。
3 つ目の課題は、モデルのライフサイクル管理です。時間とともに変化するソースデータの傾向やモデルの精度をタイムリーに評価しつつ、適切なタイミングでリプレースしていくことが求められます。Vertex AI では、MLOps の概念に基づいて、学習データの登録、モデルの自動トレーニングとサービング、モデルのモニタリングと説明、そして再学習と、機械学習のライフサイクル全体にわたって支援することができます。
アーキテクチャ
ダイナミック プライシングのデータ分析基盤を構成する要素は、主に以下の 4 つになります。
データソース（Data Source）
自社内のオンプレミス（EC サイトや基幹系システム）や SaaS サービスなど、ダイナミック プライシングのソースデータが格納されているレイヤーとなります。本デザイン パターンでは対象外となります。
データ収集（Streaming / Batch）
データ分析基盤にデータソースからデータを収集するレイヤーになります。バッチ処理で連携する場合は、オブジェクト ストレージである Cloud Storage へファイルを転送します。リアルタイム分析の要件には、Publish / Subscribe モデルのメッセージング サービスである Pub/Sub を使うことで、バックエンド サービスから非同期でデータを送信します。
データ処理（Processing）
収集したデータに変換、加工、エンリッチメントなどの処理を実行し、データ ウェアハウス / データレイクに連携するレイヤーになります。ここでは、OSS である Apache Beam をベースにしたデータ処理サービスである Dataflow を使います。Dataflow はストリーミング、バッチ両方に対応しているため、コードの再利用性が高く、自動スケーリングするため大量の位置情報の処理にも対応できます。
データ蓄積（データ ウェアハウス / データレイク）
処理されたデータを格納し分析するレイヤーになります。ここでは、サーバーレスでパタバイト規模の処理が可能なデータ ウェアハウスである BigQuery を使います。BigQuery はストリーミングに対応しているため、データ処理レイヤで変換された大量のデータもリアルタイムに挿入することができます。また、SQL を使った位置情報の分析だけでなく、機械学習機能も提供しているため、多様な分析が可能となります。
予測（AI / Prediction）
統合されたデータを入力として予測を行うレイヤーになります。ここでは、機械学習のライフサイクル全体をサポートする Vertex AutoML を使います。
利点
フルマネージド
オブジェクト ストレージの Cloud Storage、リアルタイム メッセージング サービスの Pub/Sub、データ処理サービスの Dataflow、データ ウェアハウスの BigQuery 、AI 処理基盤の Vertex AutoML は、フルマネージド、またはサーバーレスのサービスで、インフラストラクチャの管理が不要です。そのため、インフラの運用、保守などから解放され、データ エンジニアや分析者はデータ処理のロジックの開発やデータ分析に集中することができます。
拡張性
Pub/Sub、Dataflow は、負荷やデータ量に応じて自動プロビジョニング、自動スケーリングし、BigQuery はエクサバイト規模のデータを格納、ペタバイト規模のクエリを処理できます。そのためプロトタイプでの小規模な利用から大規模な本番システムでの利用まで対応できます。
Vertex AutoML
Google Cloud Vertex AutoML では、最小限の労力と機械学習の専門知識で、高品質のカスタム機械学習モデルをトレーニングできます。視覚認識、言語、構造化データをもとに、回帰、分類、予測など、多様な分析を行うことが可能です。
Vertex AutoML Tables は、CSVのような表形式の構造化データに対応しており、需要予測、欠品予測、顧客生涯価値など、さまざまなユースケースで利用できます。
以下に AutoML Tables を使ったダイナミック プライシングの例を紹介します。（本手順でご紹介する指標値やグラフはあくまで例であり、実行のタイミングによって異なる値になる場合もあります。）
ここでは UCI Machine Learning Repository で一般公開されている Online Retail Data Set の過去の売上データを加工したサンプルデータから、AutoML Tables を用いて価格を変動させた場合の販売数の変化までをシミュレーションします。
まずは、Vertex AI 上にデータセットを作成し、該当データをロードします。ロードしたデータに対して、TRAIN NEW MODEL によりモデルを作成します。モデル作成時には、販売数を Target とします。モデル評価は、以下のとおりです。
次に、このモデルを用いて価格を変更した場合の販売数の変化について、シミュレーションしてみます。今回は、特定のアイテムに対して、価格を変更した場合の販売数の変化についてシミュレーションを行います。
複数の価格パターンを含んだテストデータを準備し、作成した予測モデルを用いて Batch Prediction を実行した結果、以下のようなグラフを作成できます。X 軸は価格、Y 軸は販売予測数を示しています。折れ線グラフ（青）は価格を変更した場合の販売予測数を示しており、棒グラフ（赤）はその際の 販売金額（単価 x 数量）を表しています。
分析の結果、販売金額を最大化する価格は 2.1 USD という結論が得られます。実際の価格決定プロセスはより複雑で、現在の在庫量などの状況も加味して最適な価格設定を行うことが必要ですが、数ステップの手順により必要なデータを得ることができます。
汎用性
ここで紹介したアーキテクチャは、ダイナミック プライシングだけでなく、幅広い AI / ML 分析に活用できるため、学習コストを抑えて新たな分析の仕組みを作ることができます。
関係するデザインパターン
参考文献
BigQuery に蓄積したデータ活用のパターン
BigQuery に蓄積したデータ活用のパターン
解決する課題・使い所
データ ウェアハウスやデータマートとして BigQuery が利用されると多種多様なデータが蓄積されます。一方、SQL や BigQuery API を利用して蓄積されたデータにアクセスし、分析するにはある程度のエンジニアリング スキルセットが求められます。ビジネス インテリジェンスを代表とする GUI ベースの分析ツールと BigQuery を連携することで、非エンジニアもデータへのアクセスが容易になりデータの活用が飛躍的に容易になります。
アーキテクチャ
次世代型の BI サービスです。LookML というモデリング言語を利用することにより、複雑な SQL クエリを管理する手間から解放され、分析対象に集中することができます。また、データを内部に保持しないため Looker 自体が全体のボトルネックになることはありません。また、BigQuery だけでなく複数のデータベース、データ ウェアハウスに対応しているため、Google Cloud 上にないデータも分析対象とすることができます。
様々なデータソースに対して美しい可視化の画面の作成と柔軟な共有ができる無料のレポーティングツールです。ドラッグ＆ドロップを中心にした直感的な操作で美しいレポーティング画面を構築することが可能になります。
Google スプレッドシート上で BigQuery に保持されているデータに対して SQL を利用することなくアクセスすることができるようになるサービスです。データは最新の状態に維持され、スプレッドシート ベースでビッグデータの分析を実現することができるようになります。
利点
GUI ベースのツールは非エンジニアの分析作業者と相性が非常に良く、導入することでデータの利活用が飛躍的に促進します。
各々のツールはデータを美しく可視化することができるため、数値として分析結果を共有する以上に多くの人に直感的な理解を促すことができます。
BigQuery のテーブルやカラムに対する権限管理の仕組みと組み合わせることで、役職に応じて閲覧できるレポートに制限をかけることができます。
注意事項
利用するツールに応じて追加のコストが生じる可能性があります。例えば、Looker を利用するには追加で Looker との契約が必要となります。また、各ツールの裏では BigQuery のクエリが実行される場合がある点も認識しておく必要があります。 BigQuery はデータスキャン量に応じた従量課金であるため、予期せぬコストが発生する可能性があります。BigQuery には利用するスロット数に応じてコストを定額で支払う BigQuery Rservations もありますので、利用用途に応じて考慮に入れると良いでしょう。
このパターンで作成された事例
参照文献
API によるシステム間のデータ連携パターン
API によるシステム間のデータ連携パターン
解決する課題・使い所
従来の考え方ではデータとビジネス ロジックは一体化し、アプリケーションとして利用可能としていました。一方、このアプローチでは、データは存在するものの、利用するために都度データ取得のロジックをアプリケーション側で用意する必要がありました。データの利活用という観点で考えた時、このアプローチはデータ活用に対するアクションのスピードを低下させる要因となっていました。データ基盤にデータを操作させるための API を用意し、ビジネス ロジックはデータ基盤と分離しアプリケーション層に持たせます。データ基盤とビジネス ロジックを明確に分離することで、データ基盤の保守性や拡張性は飛躍的に高まります。また、標準的なインターフェースとして API を提供することで、社内外のシステムとの連携がより容易になり、データの活用が促進されます。
アーキテクチャ
Apigee は API の開発と管理を行うためのプラットフォームです。バックエンド サービスの API を抽象化して提供し、セキュリティやアクセスに関するレート制限を割り当てて、API 利用状況に関するデータを提供します。
フルマネージドのアプリケーション実行環境です。様々なプログラミング言語を利用することができ、簡単に Web アプリケーションを構築することができます。オートスケールなどの特徴的な機能を備えており、小規模なアプリケーションから大規模なアプリケーションまで対応することが可能です。本パターンでは Apigee の API バックエンドとして利用する想定となります。
利点
API を導入することで、データ層とアプリケーション層を完全に分離させることができます。それにより、アプリケーションの改善や追加が容易になり、新サービスの導入までの感覚を短くさせることができます。
Apigee を利用することで、統一的な API 層を導入することができ、 API に一貫性をもたせることができるようになります。また、Apigee には API を管理するための様々な機能が提供されており、 API へのトラフィックを制限するなどし、 API バックエンドの負荷状況に合わせた負荷のコントロールを行うこともできます。
注意事項
データソースに対してどの粒度でデータを返す API を提供するかについて慎重に設計を行う必要があります。利用者にとって必要なデータが容易に取得できる API になっていないと、 API の利用が促進されません。
このパターンで作成された事例
参照文献
Page updated
Report abuse