2019年4月25日(木曜日)、株式会社マクロミルが主催の、
データ分析基盤Developers Night〜3社3様分析基盤の変遷〜
が開催されました。
マクロミルからは
新しいデータ価値とビジネスを創出するビッグデータ分析基盤(前編)
データ分析基盤をつくるための開発事例
を岡澤 哲也 さんよりお話頂きました。
当日はマクロミルの他にも、
- データドリブンを支えるビッグデータ基盤の変遷
(合同会社DMM.com 出相 早織 さん/川島 崇秀 さん) - ナビタイムジャパンに集まる移動ビッグデータの分析基盤
(株式会社ナビタイムジャパン 新立 和広 さん)
にもご登壇頂き、定員80名を大きく上回る273名の応募となり、大盛況となりました。
今回は中でも株式会社マクロミル 岡澤 哲也 さん にご登壇頂いた、
新しいデータ価値とビジネスを創出するビッグデータ分析基盤(前編)
データ分析基盤をつくるための開発事例
をご紹介致します。
マクロミルについて
業界での立ち位置は?
マクロミルは2000年に創業し、現在はグローバルの拠点を含めると2,200名ほどが在籍しています。
マーケティングリサーチ会社の中では世界で一番高い成長率を誇っています。
オンラインの調査では国内でシェアNo.1の実績を持っており、世界13か国で9000万人のパネルネットワークを保持しています。
どんなビジネスモデルなの?
消費者に対して商品やサービスを提供している事業会社が、戦略を考える上で生まれるマーケティンの課題相談を受け、 消費者からアンケートや行動データを取得することでそれらのデータを集計・分析しそれを事業会社に提供するのが弊社のビジネスモデルです。
具体的には以下のようなリサーチサービスがあります。
- インターネット
インターネットを活用した消費者の声を拾い上げるアンケート調査や、市場調査。
ネットリサーチ国内実績No.1。 - オフライン
国内最大級の専用ルームと社内外約80名のモデレータが、
調査課題やテーマに応じて定性調査をサポート。 - グローバル
欧米・アジア・オセアニアはもちろん、中東や南米も含め、
16カ国・40以上の現地法人を拠点に世界90カ国・11,000万人以上のネットワークで調査が可能。 - デジタルマーケティング
オンライン行動データのアクセスログ計測を主軸に、
多様なデジタルマーケティング施策の効果測定を実現。 - データベース
継続的に蓄積された購買データ・ライフスタイルデータを活用し、
消費動向やトレンドの時系列把握、購買履歴からターゲティングして調査が可能。 - セルフ型
Web上で会員登録するだけで、調査会社を経由せず、
無料でセルフでリサーチが行えるWebサービス。
定量・定性の調査が可能。
マクロミルのコアバリューとは?
まずは海外拠点も含めた、パネルデータとマーケティングデータの規模があります。
さらにそれを分析し、企業のマーケティング課題に応えていくAnalyticsの力、そしてテクノロジーの力です。
マクロミルはマーケティングリサーチの会社のイメージが強いですが、実はITにも相当なこだわりを持っています。
マクロミルで取り扱っているサービスはすべて自社企画・開発を行っており、
ITの力で、弊社のマーケティングソリューションを支えています。
ストラテジックITソリューション部の位置づけ
その中でも岡澤 さん が所属するストラテジックITソリューション部は、
既存のシステム開発・保守の部署とは独立しており、
ビジネス成長のための新規事業開発・技術研究に特化している部署になります。
データ分析基盤構築の背景
なぜデータ分析基盤構築を行うことになったのか?
上記リサーチサービスは当初からあったものではなく、
2000年創業以来徐々に増えてきたものです。
それぞれサービス毎に蓄積してきた様々なデータがありましたが、
そのデータの有効活用はまだまだ発展途上でした。
しかし、ビジネス拡大のためにはそれらのデータの有効活用が必要な状況でした。
データ分析基盤構築の2つのゴール
そこで、
『データからインサイトを得るための環境』の整備が急務
となり以下の2点をゴールとしてデータ分析基盤構築に至りました。
- 社内すべてのサービス・システムのデータを保有している
- 各システムのデータ参照が可能なだけではなく、それらを掛け合わせた集計/抽出が可能
アーキテクチャ/ソリューションの選定
選定時のシステムの状況は?
アーキテクチャ/ソリューションの選定にあたって、
- 各サービス/システムは縦割り構成で、システム間は連携されてない
- オンプレ環境、クラウド環境が混在
- 近年の新しいサービスは保有データ量が多い
というシステム的側面がありました。
選定時のその他のシステム以外の状況は?
データレイクにデータを集めるにあたって、
他システム開発部門に依頼するタイミングには、
既に予定タスクによって人も時間も余っていないといった状況となっており、
各システム開発部門にデータ投入の対応を協力してもらうには時間/期間がかかりすぎる
という事情がありました。
そこで、
「貰うのが難しければ、自ら取りに行ってしまえばいいという逆転の発想で進めることにしました」
中核サービスとしてのAWS DMS
上記の背景も踏まえ、
AWS Data Migration Service(以下DMS)を中核サービスに据えることと致しました。
ご存知の方もいるかと思いますが、DMSは、
- 同種データベース間の移行
- 異種データベース間の移行
- 継続的なデータレプリケーション
といったことができるサービスです。
ビッグデータの処理フローと処理を実現するAWSサービス
構成の説明をする前に、改めてビッグデータの処理フローを整理すると、 下記のようになります。
- 分析対象となるデータの収集と保存を行う
- 定期的 or 溜まったタイミングでデータを取り出す、
フォーマット変換、クレンジングや一次集計などデータ変換/加工を行う
→ETL(抽出/変換・加工/ロード) - ETL済みのデータから目的のデータを取り出す
処理するプロセスの中では、
大事なETL(抽出、変換・加工、ロード)も含まれます。
また、これらの処理フローを実現するAWSサービスは次の図のようになっています。
収集ではセキュアにつなぐためのDirect ConnectやKinesisも利用し、
データレイクはS3になっています。
S3を採用しているのはデータ容量が無制限という点からです。
その他では、テーブルの作り方によってはAthenaでも充分にデータウェアハウスとして機能するので、
アドホック分析などでもAthenaも使用しているのと、
社内で利用が進んでいるTableauなどもつなぎにくる想定で構築しております。
最終的なアーキテクチャの概要図
最終的なアーキテクチャの構成としては上記の図のようになりました。
DMSでデータをかき集め、
一度Auroraに格納、そこからファイル化しS3に配置、
ファイル化したものをGlueでカタログ化し、Athenaから引けるようにするという構成になっております。
いくつか工夫した点として、
DMSでは、パッチ処理によって動的にDMSタスクを生成&実行するようにしています。
これは、オリジナルDBを参照するにあたって、リードレプリカがないものもあり、
そういった場合、日中のリソース負荷避け、深夜帯に負荷を集約することが目的です。
また、動的なDMSタスク生成&バッチ実行によって、テーブル増減への自動追従も可能となります。
もう一点、
Auroraでは、「データ量が少ない」「クエリ負荷が低い」「Athenaのオーバーヘッドが許容できない」という社内アプリケーションが
他システムのデータを利用したい場合の参照先としてReaderを開放しています。
データ量が少ない場合などはAthenaのほうがRDS利用より処理時間がかかることがあるからです。
もう少し詳しく
先程の概要図に沿って、
もう少し細かく記載すると、上記の図のようになります。
DMSタスクの動的制御部分について
CloudWatchのイベントスケジュールでStepFunctionを起動し、
Lambdaを動かすことで動的にDMSタスクを制御しています。
DMS下のJenkinsについて
エラー時のリカバリ用バッチ処理が入っています。
採用アーキテクチャの結果
メリット
基盤構築で生まれた最大のメリットは「レイクをハブにして縦割り
だったシステム間のデータ連携が進み始めている」ことです。
デメリット
一方で、
データの閲覧範囲の制限、マスキングなどのクレンジングの手間がかかることが
大きなデメリットとなってしまっております。
また、ETLのステップを踏まず、オリジナルデータから欲しいデータを無理やり作ろうとするSQL実行が頻発しており、
SQLに関する質疑応答などが増加している状況です。
そのため、そもそもETL済みのデータをいかに提供できるかがポイントとなっておりますが、
開発側にデータサイエンティスト、データベースエンジニアが不足している点は課題であります。
後編(5月28日(火)開催予定!)の内容
今日お話したのは弊社のデータ分析基盤のシステム面ですが、
5月28日(火)開催予定の後編ではビジネス面にフォーカスした内容でお話します。
現在の弊社ではデータ分析基盤により既存データの
新しい価値が生まれ、新たなビジネスへ繋がっています。
しかし、新しいことへのチャレンジは課題を生みます。
直面した課題と対するアプローチなど、包み隠さずお話いたします。
ご興味がある方はぜひお越しください!