ビッグデータ分析のカギを握る ASTERIA WARP ノ...

45
©1998-2015 Infoteria Corporation. ©1998-2015 Infoteria Corporation. ビッグデータ分析のカギを握る ノン・プログラミングデータ連携 インフォテリア株式会社 プロダクトマーケティング部 シニアプロダクトマネージャー 森 一弥 2015年9月3日

Transcript of ビッグデータ分析のカギを握る ASTERIA WARP ノ...

©1998-2015 Infoteria Corporation. ©1998-2015 Infoteria Corporation.

ASTERIA WARP

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

インフォテリア株式会社 プロダクトマーケティング部シニアプロダクトマネージャー 森 一弥2015年9月3日

©1998-2015 Infoteria Corporation.

日本のソフトウェアを世界へ! 2

©1998-2015 Infoteria Corporation. ©1998-2015 Infoteria Corporation.

Amazon Redshiftを使ったデータ分析

©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.

①データのアップロード 6

①データのアップロード

クラウド

各種システム / RDB

Excel / CSV / 各種ログ

©1998-2015 Infoteria Corporation.

アップロード時の常套手段

AmazonS3

まずはデータ変換して S3 へ!

Redshift にコピー!

AmazonS3

AmazonRedshift

変換

7

COPY

©1998-2015 Infoteria Corporation.

②データの更新 8

②データの更新

Amazon Redshift

©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.

データ更新時の常套手段②

UPDATEやDELETEでゴミが増えたら

時々バキューム!

VACUUM

©1998-2015 Infoteria Corporation.

③データの分析・活用 11

③データの分析・活用

Excel / CSV

BIツール /統計ツール

各種システム / RDB

©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. ©1998-2015 Infoteria Corporation.

ASTERIA WARP のご紹介

©1998-2015 Infoteria Corporation.

Field1

Field2

Field3

Field4

Column1

Column2

Column3

Column4

ノン・プログラミング データ連携 ツールASTERIA WARP

ノン・プログラミング とは 16

©1998-2015 Infoteria Corporation.

開発用ツール:フローデザイナー

©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.

ASTERIA シリーズの豊富な導入実績 20

©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.

株式会社リクルート住まいカンパニープロダクト部

馬場 俊 様

ぜひ、お客様の声をお聞きください。

株式会社 リクルート住まいカンパニープロダクト部

馬場 俊

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上の制約③当面時代遅れにならないアーキテクチャーであること→システム構成上の制約

個社事情

個社事情

世間一般的

実際の取り組み

データ集約先の選定

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に順位付けを⾏い評価する-抜け漏れなくポイントを押さえて網羅的に検証する

→事前にこれをやっておかないと想定外の事態に足を引っ張られて開発が進まなくなる

②社内に普及させる-⽣産性の⾼さを背景に新規のデータ連携処理を全て新システムで巻き取るよう調整

→抜け漏れを作ると結局そこから新たなデータの流れが出来上がる

③保守への接続を意識する-保守し易い運⽤設計を開発と同時進⾏で検討

→保守対応⼯数をなるべく削減して新規開発に専念できるようにする

ご清聴

ありがとうございました