分析用のデータ基盤には大容量データを素早く処理することが求められる。それにはラムダアーキテクチャーの設計概念が有効だ。AWSとAzureそれぞれで分析用データ基盤を構築する方法を解説する。
大企業のデータ基盤は、ビッグデータ分析に代表されるように大容量のデータを素早く処理することが求められます。今回は大企業のデータ基盤をAWS（Amazon Web Services）およびMicrosoft Azureで構築する際の設計ポイントを解説します。
ラムダアーキテクチャーの3層構造
ラムダアーキテクチャーは、2012年にApache Storm の作者であるNathan Marz氏が提唱したもので、「バッチレイヤー」「スピードレイヤー」「サービスレイヤー」という3層構造でデータ基盤の拡張性や保守性を実現する設計概念です（図1）。
バッチレイヤーは生データを保持したり、定期的にバッチ処理（データ加工や集計処理など）を実行したりします。主に過去のデータを扱います。サービスレイヤーはバッチ処理で得られるビュー（集計結果や分析可能な加工済みデータなど）をクライアントに提供します。このビューはBIツールやSQLで参照可能なデータとなっています。スピードレイヤーはリアルタイムに送信されてくるデータを一時的に保持したり、リアルタイムにデータを処理したりします。直近の数秒や数分、数十分のイベントのストリーミングデータを扱います。
ストリーミングデータとは、急速に生成されて絶えず流れている、無制限に発生し続けている、という特徴があります。FacebookやTwitterといったSNSのデータが代表的でしょう。Twitterでは毎秒ツイートが大量発生し、急速にデータが生成されてタイムライン上に絶えず流れている状態です。そしてツイートに限らずフォローやリツイートといったデータなども含め、無制限にデータが発生し続けています。
このようなストリーミングデータと従来のデータ基盤が得意とするバッチ処理の定期実行で得られる集計結果を組み合わせて分析できるのが、ラムダアーキテクチャーです。
データ量の肥大化に悩む大企業A社
全国に大型商業施設を展開する大企業A社をモデルにAWSおよびAzureでどのようなデータ基盤が構築できるかを見ていきます。A社が展開する各商業施設では、食品や衣料、家電、雑貨などを販売しています。施設利用者がスマホアプリを登録すれば、スマホを財布代わりに利用できます。利用者にこの決済システムの利便さが受け入れられたことに加えて、スマホアプリから得られる顧客情報を経営戦略に反映して急成長しているのがA社です。
A社が収集するデータは、（1）商業施設内の店舗POSデータ（売上金額や販売個数、在庫情報）、（2）スマホアプリから送信されるデータ（アプリの操作情報や年齢、性別、来場経路といった顧客の属性情報、施設内での購買行動履歴）、（3）商業施設内に設置したIoT機器のデータ（商品陳列棚に設置したIoTセンサーで顧客が手を伸ばしたかどうかを検知したストリーミングデータ）の3つがありました。
A社がデータ基盤に求める要件は、（A）IoT機器のデータを収集・蓄積・分析し、施設内の顧客動向に合わせた効果的な施策を打ち出して売り上げを伸ばす、（B）これまでに収集した顧客データとIoT機器からのデータをひも付けて様々な角度で分析し、新たな商品開発や経営の意思決定の材料にする、という2つです。
