20150630_データ分析に最適な基盤とは？...

データ分析に最適な基盤とは?

コスト/スピードでビジネスバリューを得るために

株式会社インサイトテクノロジー

CTO 石川雅也

• 石川雅也 (いしかわまさや)

• 現職

o 株式会社インサイトテクノロジー取締役 CTO

ビッグデータソリューション事業部

FB: MasayaIshikawa

• 職歴

o 外資系HWベンダーにて、ミニコンOS, UNIX OS担当SE. 社内SE向け技術情報発信、トラブルシュート。crash dump解析、UNIX SCSI Device Driver改造とか

o 1993年日本オラクルに入社。DBインフラ系テクニカルサポート、コンサルティング、トラブルシュート。

o 1995年インサイトテクノロジー設立Oracleパフォーマンス管理ツール Performance Insight開発 (1995~)

Oracleアクセスログ取得管理ツール PISO開発 (2004~)

SQL Server版、富士通Symfoware版 PISO開発 (2005~)

DB コンサルティング、トラブルシュート2012年 DB専用サーバー Insight Qube開発2013年 Actian DWH向けRDBMS販売開始

自己紹介

Copyright © 2015 Insight Technology, Inc. All Rights Reserved. 2

• 社名

– 株式会社インサイトテクノロジー

• 設立

– 1995年7月

• 資本金

– 1億円（2013年7月）

• 役員

– 代表取締役小幡一郎

– 取締役石川雅也

– 取締役永見和平

– 取締役森田俊哉

– 取締役張統

• 本社

– 東京都渋谷区恵比寿1-19-19

恵比寿ビジネスタワー5F

• 大阪支店

– 大阪府大阪市北区大深町3番1号グランフロント大阪ナレッジキャピタルタワーC 11F

• 事業内容（後頁に詳細）

– コンサルティング事業

– ソフトウェア事業

– ハードウェア事業

• 主要取引先

– 株式会社アシスト

– 新日鉄住金ソリューションズﾞ

株式会社

– 富士通株式会社

– 日本電気株式会社

– 株式会社日立ソリューションズ

– 伊藤忠ﾃｸﾉｿﾘｭｰｼｮﾝｽﾞ株式会社

– 三井情報株式会社

– 日本オラクル株式会社

– マイクロソフト株式会社

– デル株式会社

– 日本HP株式会社

会社概要


事業詳細コンサルティング事業

ソフトウェア事業

ハードウェア事業 (2012年~)

対象データベース：Oracle, SQL Server, MySQL, Actian Vector, Actian Matrix など支援内容：データベースの設計、構築、運用支援、パフォーマンス改善など

データベースのパフォーマンス監視・分析ツール（自社開発）

データベースのセキュリティ保全ツール（自社開発）

大規模システムの統合監視ツール（自社開発）

マルチデータベースのリアルタイムレプリケーションツール

世界最速のデータベース専用高速サーバー（自社開発）

7年連続シェアNo1

次世代型データウェアハウス向け超高速データベース


Oracle Standard Edition向け DR構築ツール

データベーステクノロジーイベントの主催

Copyright © 2014 Insight Technology, Inc. All Rights Reserved.


• No Sales Talk• 年2回開催(東京・大阪)• 2015年6月に第7回目を

開催。国内DB関連会社33社が協賛

• 3日間で 90+セッション延べ4500人以上のDB技術者が参加

データ分析に最適な基盤とは?


1種類のデータストアで業務処理、分析処理など様々な処理を実施する時代は終わり、それぞれのアプリケーションワークロードに合わせて最適なデータストアを選択することで、コスト、スピードといった面でビジネスバリューを得られる時代が始まっています。

本セッションでは、様々なデータベースを比較しながら、それぞれの特性を解き明かし、データ分析に最適な基盤について解説します。


アジェンダ

• Michael Stonebrakerの考えるデータベースの(近い)未来

• DWH向けRDBMS Actian Vector™ の紹介

• 大量データ分析基盤のアーキテクチャの過去・現在・未来

• 大量データ分析基盤 Actian Vortex™ の紹介


出典: Wikipedia

2000年頃までのデータベース市場は、「1つのサイズですべてをまかなう」時代でしたし、その頃は「Oracleが答え」でした。1つしか道具がなければ、あらゆることにそれを使うしかないでしょう。

しかしその状況は2000年代の最初の10年で急激に変わりました。

今のデータベース市場は3分の1がトランザクション処理であり、3分の1がデータウェアハウスであり、残り3分の1をそのほか全部が占めているとわたしは考えています。この15年間で起こったことは、データウェアハウス市場をほとんど完全にロウストアからカラムストアに変えました。今ではカラムストアはロウストアよりも圧倒的に高速です。

これによって、ロウストアを売っていた従来のデータベースベンダーは、技術的に間違った側になってしまったのです。

トランザクション処理の世界でも、メインメモリが十分に安くなったため、すべてではないにしても、トランザクションデータベースのほとんどをメインメモリに置けるようになりました。


2000年頃までのデータベース市場は、「1つのサイズですべてをまかなう」時代でしたし、その頃は「Oracleが答え」でした。1つしか道具がなければ、あらゆることにそれを使うしかないでしょう。

しかしその状況は2000年代の最初の10年で急激に変わりました。

今のデータベース市場は3分の1がトランザクション処理であり、3分の1がデータウェアハウスであり、残り3分の1をそのほか全部が占めているとわたしは考えています。この15年間で起こったことは、データウェアハウス市場をほとんど完全にロウストアからカラムストアに変えました。今ではカラムストアはロウストアよりも圧倒的に高速です。




2000年頃までのデータベース市場は、「1つのサイズですべてをまかなう」時代でしたし、その頃は「Oracle

が答え」でした。1つしか道具がなければ、あらゆることにそれを使うしかないでしょう。

しかしその状況は2000年代の最初の10年で急激に変わりました

今のデータベース市場は3分の1がトランザクション処理であり、3分の1がデータウェアハウスであり、残り3

分の1をそのほか全部が占めているとわたしは考えています。この15年間で起こったことは、データウェ

アハウス市場をほとんど完全にロウストアからカラムストアに変えました。今ではカラムストアはロウストアよりも圧倒的に高速です。



2005年に書いた論文では「1つのサイズですべてを

まかなう時代はもう終わった」と述べたのですが、2015年のわたしは、もっと突っ込んだ形で「1つのサ

イズでまかなえるものはない」と言っています。Oracle、IBM、Microsoftの従来の実装が適しているものは、基本的に何もありません。

OLTP

DWH

その他


• 1つのサイズでは、

現在のデータ処理はまかなえない。

• OLTPは

オンメモリまたはインメモリへ

• DWHはカラムナーへ

197x

Oracle(ORACLE)

System R(IBM)

Ingres(Actian 旧Ingres)

主にOLTP用途

主にDWH用途

買収等

1975

RDBMS製品の歴史を振り返る


198xInformix

(Informix)

DB2(IBM)

Teradata(Teradata)

SQL Server(Microsoft)

PostgreSQL(Open Source)

主にOLTP用途

主にDWH用途

買収等

1985

Sybase(Sybase)

Non Stop SQL(Tandem)


199x

MySQL(MySQL AB)

Symfoware(Fujitsu)

Sybase IQ(Sybase)

HiRDB(Hitachi)

主にOLTP用途

主にDWH用途

買収等

1995


200xNetezza

(Netezza)

Informix(IBM)

Greenplum(Greenplum)

Vertica(Vertica)

Infobright(Infobright)

ParAccel(ParAccel)

Asterdata(Asterdata)

Vectorwise(Vectorwise)

Oracle Exadata(ORACLE)

MySQL(Sun Microsystems)

MonetDB(Open Source)

主にOLTP用途

主にDWH用途

買収等

2005


201x

Vertica(HP)

Asterdata(Teradata)

Redshift(Amazon) Matrix(ParAccel)

(Actian 旧Ingres)

主にOLTP用途

主にDWH用途

買収等

Vector(Vectorwise)(Actian 旧Ingres)

Sybase (IQ)(SAP)

Netezza(IBM)

Greenplum(EMC)

InfiniDB(Calpont)

SAP HANA(SAP)

MySQL(ORACLE)

2015



2005年に書いた論文では「1つのサイズですべてを

まかなう時代はもう終わった」と述べたのですが、2015年のわたしは、もっと突っ込んだ形で「1つのサ

イズでまかなえるものはない」と言っています。Oracle、IBM、Microsoftの従来の実装が適しているものは、基本的に何もありません。

Vector™

Vectorwise3 May 2011

436,788

QphH

32 Cores

1TB RAM

$0.88 USD

Price/QphH

Microsoft

SQL Server5 April 2011

173,961

QphH

80 Cores

2TB RAM

$1.37 USD

Price/QphH

Microsoft

SQL Server30 August 2011

219,887

QphH

$1.86 USD

Price/QphH

80 Cores

2TB RAM

Oracle3 June 2011

209,533

QphH

$9.53 USD

Price/QphH

64 Cores

512GB RAM

0

100,000

300,000

Top 7 Non-Clustered Database System

TPC-H 1TB Scale Factor

Source: www.tpc.org / Oct 22, 2013

400,000

200,000

QphH

Vectorwise1 Jun 2012

445,529

QphH

32 Cores

768GB RAM

$0.75 USD

Price/QphH

Oracle26 Sep 2011

201,487

QphH

$4.60 USD

Price/QphH

32 Cores/

256 Thread

512B RAM

Sybase IQ15 Dec 2010

164,747

QphH

$6.85 USD

Price/QphH

32 Cores

512B RAM

What’s Vector™


Advantage of Vector™


ベクター演算CPU効率を高めるためにVector (SIMD)演算を活用

カラムナーI/Oを制限することにより、効率的かつリアルタイム更新処理が可能

データ自動圧縮

データの自動圧縮により、ストレージ使用効率の向上と、IO量の削減、およびキャッシュ効率を飛躍的に高める

CPUキャッシュ

RAMでなく、オンチップでのデータ処理

マルチコア並列処理システムリソースを最大限に活用…

ストレージインデックス

即座に対象データブロックを特定し、I/Oを最小限におさえる。

Tim

e / C

yc

les

to

Pro

ce

ss

Data Processed

DISK

RAM

CHIP

10GB2-3GB40-400MB

2-2

0150-2

50

Mill

ions

SIMD


SIMD (Single Instruction Multiple Data)

Pentium ⅢよりSSE(Streaming SIMD Extensions)として搭載され、

Sandy BridgeよりIntel AVX(Advanced Vector eXtensions)へ

・・

・

・・

・

・・

・

・・

・

・・

・

Instruction

Data

Output

インストラクション数の比較


2.7E+10

2.4E+112.0E+11

7.8E+11

1.9E+12 1.9E+12

2.8E+10

3.8E+114.8E+11

8.3E+11

2.8E+12

1.9E+12

1

9 7

29

102

68

0

20

40

60

80

100

120

0.0E+00

1.0E+12

2.0E+12

3.0E+12

Columnar DB A

Columnar DB B

In Memory DB A

Rt = Instructions / (IPC * Hz * Parallelism)

Row Store DB A

Row Store DB B

CP

U I

nstr

ucti

on

s (

cou

nt)

Com

pari

son

vs V

ecto

r

selectsum(l_extendedprice * l_discount) as

revenuefrom

lineitem -- 6億件, 80GB のデータwhere l_shipdate >= date '1996-01-01'and l_shipdate < date '1996-01-01' +

interval '1' yearand l_discount between 0.02 - 0.01 and 0.02

+ 0.01and l_quantity < 24

ブランチミス数


1.8E+07

1.1E+09

3.0E+08

1.1E+09

1.6E+09

7.7E+08

2.1E+07

1.4E+09

1.2E+09

1.1E+09

1.7E+09

7.7E+08

1

64

17

62

88

43

0

10

20

30

40

50

60

70

80

90

100

0.0E+00

1.0E+09

2.0E+09

Columnar DB A

Columnar DB B

In Memory DB A

Row Store DB A

Row Store DB B


CP

U B

ran

ch

-Mis

ses (

cou

nt)

Com

pari

son

vs V

ecto

r

実際のElapsed Time(秒)


0.48 3.44

35.58

209.45

467.36

332.56

1

7

74

434

968

689

0

200

400

600

800

1000

1200

0

50

100

150

200

250

300

350

400

450

500

Columnar DB A

Columnar DB B

In Memory DB A

Row Store DB A

Row Store DB B


Qu

ery

Ela

psed

Tim

e (

sec)

Com

pari

son

vs V

ecto

r

Insight Qube for Vector™


×136

* ツイートは米Twitter社(Twitter, Inc.)が提供するサービス(Twitter)上のつぶやきメッセージを指します

* Twitterは米Twitter社の登録商標であり弊社との関連はありません

* 語句解析はツイート中の一般名詞のみを対象にしています

99%

1%

tweets demo tweets

世界中のツイート(*1)の1%

を抽出

(2012/4/23 - 2012/4/25)

ツイートの語句解析(MeCabに

よる形態素解析)

データベースにロード

デモのためデータを5倍に増幅

- ツイートデータで1000万件

(9GB)

- 解析後語句データで260万件

(100MB)

データロードは各データベースベ

ンダーが用意するローダーを使用

1000万件のツイートデータ

から世界のツイート数の国別

ランキングを出してみると？


から世界のツイートの時間帯

別ツイート数の推移を見てみ

ると？


と260万件の解析後の語句

データから日本でホット

だったキーワードを探って

みると？

Vector™ Demo


../201310 BigData Expo/IQ for Vectorwise/vectorwise_vs_oraclehdd_fast.mp4

../ShortCuts/vectorwise_vs_oraclehdd_fast.mp4

• 対象システム

– 診断データ分析システム「MDV analyzer」

– 患者約400万人規模の薬剤処方実態を日単位で分析

• 従来課題 → 「MDV analyzer」から解決

– 製薬会社は自他社製品の処方実態を把握できないため的確なマーケティングが困難だった

– 医師が患者に処方した薬剤の実態をつかむデータベースがなかった

• システム課題

– 検索速度が遅いことによるサービスレベルの低下 (従来は Infobright使用)

• 効果

– 製薬会社は自他社製品の処方実態を正確且つ高速に把握可能となった

– 「販売実態」ではなく「処方実態」を前提としたマーケティングが可能になった

– 検索速度の大幅な短縮によるサービスレベルの向上

製薬会社A

製薬会社B

製薬会社C

400万人の患者データ（薬剤処方実態）

マーケティングに活用


導入事例: 株式会社メディカル・データ・ビジョン

• 対象システム

– 処方箋分析システム（処方箋情報約3億枚及び顧客情報）

– 製薬会社向けコンサルティング・ビジネスの情報を提供

– 顧客の処方改善（規定量を正しく服用していない顧客へ正しい服用法を説明）

• 課題

– データ量に見合う性能を発揮できなくなってきた

– 事実、ユーザー部門からレスポンスが遅いという声が数多く寄せられるようになった

• ソリューション

– SQL Server から Vectorへリプレース

– Cognosのキャッシュを使用せず Vectorへのパススルークエリーにアプリケーション変更

• 効果：劇的な性能向上

– ダッシュボード表示時間：従来の4分の1

– 自由分析表示時間：従来の20分の1

製薬会社向けコンサルティング

顧客の処方改善処方箋顧客情報地域で、製薬会社別がシェアは？薬を処方したのは内科か外科か？どんな薬と一緒に処方されるか？

システムが生み出す価値


導入事例: 日本調剤株式会社

拡大推計POSデータサービス

「手軽で」「早くて」「品質の高い」マーケティングリサーチをPOSサービスへ展開

・100億件の集計を10秒以内で処理できること

・低コスト（クライアント様へ安価にサービス提供する為に投資を抑制したい。）

システム開発要件

による解決

データ提供元クライアント

スーパーチェーン

その他業態

食品メーカー日用品メーカー

データ件数：数百億（5年後）

データ容量：数ＴＢ

集計システム (クロス集計とグラフ描画)

Web上での集計指示、結果確認、各種処理（UI）

運用管理(マスタ管理、クライアント管理)

集計条件を自由設定

結果を画面での確認

Ｅｘｃｅｌでのレポート出力

数千店以上テストケース：データ件数（4億件）で集計時間を実計測→結果：3.6秒 (SQLチューニングにより 2秒台程度も目指せそう）

データ件数カテゴリ毎にテーブル設計 (View)

クライアント毎にテーブル設計 (実表)

1億件 3.7秒 3.9秒

2億件 3.3秒 4.7秒

4億件 3.6秒 5.3秒

ありとあらゆるDBを検討。

予算内での要件のクリアは容易ではなかった。

＋

導入事例: 株式会社マクロミル


Machine-Generated Data Social Media Internet Retail

Financial

Government

Research/Education

Vector™ 主要顧客


Certified/tested In progress

各種BIツールとの連携


http://www.pentaho.com/

http://www.pentaho.com/

大量データ分析基盤について

“過去-現在”課題

- データ量にETL処理が追いつかない(終わらないバッチ)

- レガシーDWHの処理能力不足によるマート処理

- 分析の硬直化、アーキテクチャーの複雑化

レガシーETL

マート

レガシーDWH


データ分析基盤のデザインパターン

“過去-最近”課題




ハイパフォーマンスDWH



レガシーETL

“現在-最近”課題




- HadoopクラスターとDWHの2つの運用が発生

- ETLにMapReduce等Hadoop特有のコーディングが必要 HadoopでETL




“現在-最近”課題




- HadoopクラスターとDWHの2つの運用が発生

- ETLにMapReduce等Hadoop特有のコーディングが必要 DataFlow

Actian DataFlowDataFlow自体にHadoopは必須のコンポーネント

ではありません。しかし、大量データを安全、

安価、高速に処理可能なHadoopはデータ分析基盤

のストレージレイヤーに適してると言えます。



HadoopでETL


OLTP

DWH

その

他


OLTP

DWH

Hadoop

NoSQL

グラフ処理

機械学習


• 機械学習は配列ベースの処理になる。

• グラフ処理に関してもRDBMSに有利な点はない。

• NoSQL, Hadoopについても既存RDBMSベンダーが有利な市場ではない

今Hadoop市場では「Spark」（Apacheベースの高速クラスタコンピューティングに特化したエンジン）が人気を集めていますが、Matei Zaharia氏（SparkのCTO兼Databricksの共同創業者）によれば、なんとSparkへのアクセスの79％はSQLからだそうです。

つまり、SparkはSQL市場なわけです。Clouderaを見てみると、彼らはmPower

を前面に押し出していますし、「Impala」はSQLの実装の1つです。こう考えると、HadoopスタックのMapReduce（大規模データセットを生成するモデル）の部分はうまくいかないと思います。

基本的に、本当に重要なHadoop市場はSQL市場になるでしょう。そこでmPower

を見てみると、Impalaはアーキテクチャ的にクラウドストアであり、「HP

Vertica」や「Amazon Redshift」、またはその他のリレーショナルデータベースのカラムストア実装に似ています。このため、わたしはHadoop市場のほとんどはデータウェアハウス市場と融合すると考えています。


Sparkへのアクセスの79％はSQLから

本当に重要なHadoop市場はSQL市場になるでしょう。

Hadoop市場のほとんどはデータウェアハウス市場と融合すると考えています。

https://spark.apache.org/

http://www.cloudera.com/content/cloudera/en/home.html


これからのデータ分析基盤

RDBMS

DataFlow Engine

VectorLegacy

ETL

DataFlow Engine₋ No Map Reduceの並列分散実行エンジン₋ ロード先がVectorの場合は、Hadoop側

で、データファイルをパラレルで作成₋ 基本的にコーディングなし

SQL on Hadoop

Vortex

Vortex™

Vortex™ (Vector™ Hadoop Edition)


No-Cluster分野で世界最速のVectorのSQLエンジンをHadoopエコシステム内に組み込んだMPPデータベース構成

- 用途別に複数のクラスターの構築、運用が不要

- Hadoopと統合可能なETL&分析エンジン(DataFlow)も組込み可能

- Hadoopが持つ高い可用性と高いスケーラビリティを担保

- Vectorが持つ低レイテンシーでのSQLアクセスをHadoopエコシステムに適用可能

- Hadoopが持つ大量データに対して標準(SQL92＋α)SQLでアクセスすることで既存資産の有効活用

分析クエリーと”更新可能”なDML文のサポート


ANSI準拠 & 分析クエリー

Vector同様にSQL-92レベルのフルサポートとCUBE、ROLLUP、LAG、LEAD、

GROUPING SET、およびWindow関数をサポートしています。

サポートしているSQL関数は以下のドキュメントで確認可能

http://docs.actian.com/#b78023t22329n/s-1/s6421/s6422/s6422b343149/s6422b343169

SQL

更新可能なDMLのサポート

HDFS上のデータであっても、ACIDトランザクション、MVCCを備え、DML(INSERT、

UPDATE、DELETE)を実行することが可能です。DMLはVectorの持つPDT(Positional

Delta Tree)と呼ばれるインメモリデータ構造により高速化されています。

* 3rdパーティーのレプリケーション製品のように、Vector Hadoop SQL Editionに定常的かつ大量にDMLを発行する場合は、

パフォーマンスについて考慮が必要になる場合があります

* DELETEを実行してもHDFS上の使用領域が減少するわけではないので、ストレージに使用率を下げたい場合は定期的なメンテナンス

が必要になります

DML

READ

PDT

Positional Delta Tree (PDT)


Positional Delta Tree(PDT)の仕組み

Vectorの更新は、以下２つのタイプがある

- BULK更新処理

ローダーにより一括データ投入や、INSERT

… SELECT * FROM x のような処理

- BATCH更新処理

BATCH更新処理とは、一件ごとのINSERT,

UPDATEやDELETEを意味します。

BATCH処理の場合は、PDTと呼ばれるメモ

リー上のデータストアにて処理され、永続的

なストレージ(この場合はHDFS上)に、非同

期で書き出します。

HDFSは追記のみ可能なので Vectorも更新

データは追記のみ行い。読み取り時にマージ

処理を行う。

PDT

HDFS DATA LOG

WRITE

PDT

① commit

② PDTと同時に

Transactionログに

書き出し

③ WRITE PDTのし

きい値によりREAD

PDTに移動

④ READ PDTのしき

い値によりHDFS上の

ファイルにマージ

読み取り時は、各

レイヤーをマージ

Vortex™ vs Impala, Hive


0.000

1000.000

2000.000

3000.000

4000.000

5000.000

6000.000

7000.000

8000.000

9000.000

Vortex onCDH5.1

Impala 1.4 onCDH5.1

Hive 0.12 onCDH5.1

TPC-H Power@1000GB on 5 Nodes Cluster

41.8(1.0)

784.8(17.8倍)

8511.2(203.4倍)Vector Hadoop Edition

Impala1.4

Hive0.12

Presto0.73

Query1 〇〇〇〇

Query2 〇 △ △ ×

Query3 〇〇〇 △(OutOfMemory)


Query5 〇〇〇 △(OutOfMemory)

Query6 〇〇〇 △



Query9 〇〇(OutOfMemory)〇 △(OutOfMemory)


Query11 〇 × × ×





Query16 〇 △ △(OutOfMemory)×


Query18 〇 △ △(OutOfMemory)×

Query19 〇〇〇 ×

Query20 〇 △(OutOfMemory)△ ×


Query22 〇 × × ×

TPC-H ANSI SQL Comparison

本ベンチマークは弊社が独自に実施したもので公式なものではありません。

Hadoop上でのクエリー処理において圧倒的なパフォーマンスとクエリーの成熟度

Wrap up

• 1種類のデータストアで業務処理、分析処理など様々な処理を実施する時代は終わり、それぞれのアプリケーションワークロードに合わせて最適なデータストアを選択することで、コスト、スピードといった面でビジネスバリューを得られる時代が始まっている。

• OLTP -> On Memory, In-Memory

• DWH -> Columnar RDBMS

• (大量データ分析基盤としての)Hadoop

-> SQL on Hadoop


Vector, Vortex Express Editionの紹介


http://www.actian.com/product-downloads/

- 無料

- Up to 250GB (Vector)

Up to 500GB (Vortex)

- Community Support

- Enterprise Editionより

1世代前のバージョン