©1998-2015 Infoteria Corporation. ©1998-2015 Infoteria Corporation.
ASTERIA WARP
ビッグデータ分析のカギを握るノン・プログラミングデータ連携
インフォテリア株式会社 プロダクトマーケティング部シニアプロダクトマネージャー 森 一弥2015年9月3日
©1998-2015 Infoteria Corporation.
Amazon Redshift とは
時間単位で課金されるクラウド
データウェアハウス
使った分だけ
PostgreSQLとある程度互換
使い慣れた技術
従来の専用ハードウェアモデルに比べて
1/10以下の低価格
VS
お手頃価格
4
©1998-2015 Infoteria Corporation.
データ分析の流れ
③データの分析・活用②データの更新①データのアップロード
クラウド
各種システム / RDB
Amazon Redshift
Excel / CSV
Excel / CSV / 各種ログ
BIツール /統計ツール
各種システム / RDB
5
©1998-2015 Infoteria Corporation.
アップロード時の常套手段
AmazonS3
まずはデータ変換して S3 へ!
Redshift にコピー!
AmazonS3
AmazonRedshift
変換
7
COPY
©1998-2015 Infoteria Corporation.
1
2
3
4
データ更新時の常套手段
2
5
1
2
3
4
2
5
1
2
3
4
5
UPDATEができない(遅い)ので
Table作ってマージ!!
9
©1998-2015 Infoteria Corporation.
分析・活用時の常套手段
1
2
3
41234
大きなTableを直接分析・活用しようとすると負荷が・・・
一時テーブルを作って分析・活用!!
12
2
3
©1998-2015 Infoteria Corporation.
ここまでのまとめ
Redshiftはクラウド
データウェアハウス
コツをわかった上での開発が伴います
分析を始めるまでにそれなりの開発者による「準備」が必要
13
使うにはいくつかのコツがあります
©1998-2015 Infoteria Corporation. ©1998-2015 Infoteria Corporation.
でも、開発部分を全部ノン・プログラミングでできたらどうでしょう!?
③データの分析・活用②データの更新①データのアップロード
クラウド
各種システム / RDB
Excel / CSV
Excel / CSV / 各種ログ
BIツール / 統計ツール
各種システム / RDB
Amazon Redshift
Amazon S3
©1998-2015 Infoteria Corporation.
Field1
Field2
Field3
Field4
Column1
Column2
Column3
Column4
ノン・プログラミング データ連携 ツールASTERIA WARP
ノン・プログラミング とは 16
©1998-2015 Infoteria Corporation.
Redshiftの「コツ」を実現する専用のオプション
AWS RedshiftLoad
S3からRedshiftへのデータロードを画面の選択のみで実現
AWS RedshiftCopyTable
分析時に必要となる一時テーブルの作成も直感的な画面操作で実現
©1998-2015 Infoteria Corporation.
デファクトスタンダード
0
1000
2000
3000
4000
5000
6000
200
3年
3月末
200
4年
3月末
200
5年
3月末
200
6年
3月末
200
7年
4月末
200
8年
3月末
200
9年
3月末
201
0年
3月末
201
1年
3月末
201
2年
3月末
201
3年
3月末
201
4年
3月末
2015年
4月末
12.1%
11.4%
9.1%
6.8%
13.5%
テクノ・システム・リサーチ「2014年ソフトウェアマーケティング総覧 EAI/ESB市場編」(数量ベース)
データ連携市場8年連続No.1
47.0%
5,000社以上の導入実績
2015年5月末に5,020社の導入を達成!
19
©1998-2015 Infoteria Corporation.
AWS利用事例
T a b le a uD e s k to p
T a b le a uD e s k to p
T a b le a uD e s k to p
A m a zo nE C 2
A m a zo nE C 2
A m a zo nE C 2
A m a zo n R e d s h i f t
A m a zo n S3
AWS cloudデータセンター店舗
約2 6 0店舗のPOSデータ
Tableau用用のEC2は業務時間だけ
⾃⾃動起動
©1998-2015 Infoteria Corporation. ©1998-2015 Infoteria Corporation.
株式会社リクルート住まいカンパニープロダクト部
馬場 俊 様
ぜひ、お客様の声をお聞きください。
本日お話しすること
ビッグデータを自社で扱っていて活用したいけれどそもそもデ
ータがきちんと整備されていない時の
・⾃社のデータ課題を整理するプロセス
・システム構成選定ポイント
・実際の成果
についてリクルート住まいカンパニーの事例を共有します。
主なサービス②
一口に「住まい」と言っても色々あります賃貸住宅、マンション(中古含む)
⼀⼾建住宅(中古含む)、注⽂住宅
有料介護⽼⼈ホーム / サービス付き⾼齢者向け住宅
etc
住まいに関連するサービスだとリフォーム、ハウスサービス
引っ越し
etc
→全てSUUMOで取り扱っています
取扱データ
オムニチャネル多種多様な情報
サービス×
膨大なデータ
■規模感月間UU:1150万人月間PV:2.1億ユーザー⾏動ログ:
1000〜1500万件/日(年換算で約10TB)
■データの種類物件、アクセスログ(スマホ/PC)、会員、メール、アンケート(オンライン/オフライン)、営業、広告掲載、クライアント、受注、コンテンツ(静止画/動画)、マスタ(沿線、駅、周辺環境、住所etc)
2004年頃からそれまで情報誌⼀辺倒だったサービスを⼀気にインター
ネットへシフト
サービスに対応したシステムの乱⽴
急速な利⽤
者増加に伴う追加対応
個別最適な開発
システム複雑化の負のスパイラル
裏で開発ベン
ダーのマルチ化が進⾏
背景
理想に近づくための大方針
一.データを一箇所に集約する
二.データ移送処理 / 加工処理を共通化する
制約:①様々な開発ベンダーが共通で利⽤できること→開発体制上の制約②集約、処理の共通化とも短期間で進められること→P/L上の制約③当面時代遅れにならないアーキテクチャーであること→システム構成上の制約
個社事情
個社事情
世間一般的
データ集約先の選定
etc
Amazon Redshift + S3を採用
++++
開発体制上の制約
・パブリッククラウド・豊富なSDK/API群・デファクトスタンダード
P/L上の制約
・企業努⼒による⾃主的
な料⾦引き下げ
システム構成上の制約
・サービス / 機能追加のスピードの速さ
オープンソースHDFS
A社オンプレDWH
B社オンプレDWH
データ集約先の選定
『AWSの歴史、745機能をリリースし40回以上値下げ』引用元:ITpro by 日経コンピューター執筆者:吉荒祐一執筆年:2014/07/07引用元URL:http://itpro.nikkeibp.co.jp/article/COLUMN/20140617/564693/
『AWS、API Gatewayや機械学習など新サービスをお披露目』引用元:Ascii.jp ×クラウド執筆者:大谷イビサ執筆年:2015/07/14引用元URL:http://ascii.jp/elem/000/001/028/1028467/
データ移送処理 / 加⼯処理の共通化
スクラッチ開発 A社ETL製品 B社ETL製品
etc
ASTERIA WARPを採用
開発体制上の制約
・豊富なデータソースコネクタ・利⽤し易いコンポーネント群・AWSオプション
P/L上の制約
・開発生産性の向上※次ページで説明
システム構成上の制約
・新しいデータコネクタの提供・エクスペリメンタルビルド(HDFSアダプタ等)・導入実績
■開発生産性の検証------------------------------------
→スクラッチと比較して半分の期間でジョブ構築完了
データ移送処理 / 加⼯処理の共通化
■パフォーマンスの検証------------------------------------
・IOPS・ディスク使⽤量
・CPU使⽤率・スループット(100万件〜300万件のデータで実施)・メモリ使⽤量
→多少課題は出たものの大きな問題なし
3ヵ月間のFS(Feasibility Study)による検証結果
ASTERIA WARPで同じ処理をフロー化してテスト完
了までにかかった時間
データ移送⽤バッチ処理の
コーディングからテスト完了までにかかった時間
VS
<新>データ基盤のシステム構成
ベンダA
入稿
ベンダB
入稿
ベンダD
フロント
ベンダE
営業ログ
・・・
分析データ
Redshift
共通処
理
共通処
理
S3
システム間を疎結合に保つため、一旦S3にファイルを展開
共通のデータ加⼯処理/データ移送処理を定義
共通のデータ加⼯処理/データ移送処理を定義
成果
■2015年5月からの本格運用以来4ヵ月で数百バッチの置き換えを完了
■単なるジョブの置き換えではなく多くの処理を共通化する事に成功(元のジョブ本数は数百に対して数個に抑えられている)
→理想からはまだまだ道半ばだが今の所計画の1.5倍以上の案件進捗状況
成功ポイント
①綿密なシステム検証-自社の制約に基づき確認するKPIに順位付けを⾏い評価する-抜け漏れなくポイントを押さえて網羅的に検証する
→事前にこれをやっておかないと想定外の事態に足を引っ張られて開発が進まなくなる
②社内に普及させる-⽣産性の⾼さを背景に新規のデータ連携処理を全て新システムで巻き取るよう調整
→抜け漏れを作ると結局そこから新たなデータの流れが出来上がる
③保守への接続を意識する-保守し易い運⽤設計を開発と同時進⾏で検討
→保守対応⼯数をなるべく削減して新規開発に専念できるようにする