ビッグデータ分析のカギを握る ノン・プログラミングデータ連携

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