20150630_データ分析に最適な基盤とは？ -コスト/スピードでビジネスバリューを得るために- by 株式会社インサイトテクノロジー CTO 石川雅也

データ分析に最適な基盤とは?
コスト/スピードで
ビジネスバリューを得るために
株式会社インサイトテクノロジー
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

出典: ZDNet Japan

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製品の歴史を振り返る

198x
Informix
(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

200x
Netezza
(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の従来の実装が適している
ものは、基本的に何もありません。

Vectorwise
3 May 2011
436,788
QphH
32 Cores
1TB RAM
$0.88 USD
Price/QphH
Microsoft
SQL Server
5 April 2011
173,961
QphH
80 Cores
2TB RAM
$1.37 USD
Price/QphH
Microsoft
SQL Server
30 August 2011
219,887
QphH
$1.86 USD
Price/QphH
80 Cores
2TB RAM
Oracle
3 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
Vectorwise
1 Jun 2012
445,529
QphH
32 Cores
768GB RAM
$0.75 USD
Price/QphH
Oracle
26 Sep 2011
201,487
QphH
$4.60 USD
Price/QphH
32 Cores/
256 Thread
512B RAM
Sybase IQ
15 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を最小限におさえる。
Time/CyclestoProcess
Data Processed
DISK
RAM
CHIP
10GB2-3GB40-400MB
2-20150-250Millions

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+11
2.0E+11
7.8E+11
1.9E+12 1.9E+12
2.8E+10
3.8E+11
4.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
CPUInstructions(count)
ComparisonvsVector
select
sum(l_extendedprice * l_discount) as
revenue
from
lineitem -- 6億件, 80GB の
データ
where l_shipdate >= date '1996-01-01'
and l_shipdate < date '1996-01-01' +
interval '1' year
and l_discount between 0.02 - 0.01 and 0.02
+ 0.01
and 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
CPUBranch-Misses(count)
ComparisonvsVector

実際の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
QueryElapsedTime(sec)
ComparisonvsVector

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

• 対象システム
– 診断データ分析システム「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ツールとの連携

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

“過去-現在”
課題
- データ量にETL処理が追いつかない(終わらないバッチ)
- レガシーDWHの処理能力不足によるマート処理
- 分析の硬直化、アーキテクチャーの複雑化
レガシーETL
マート
レガシーDWH
データ分析基盤のデザインパターン

“過去-最近”
課題
ハイパフォーマンス
DWH
レガシーETL

“現在-最近”
課題
- HadoopクラスターとDWHの2つの運用が発生
- ETLにMapReduce等Hadoop特有のコーディングが必要 HadoopでETL
DWH

“現在-最近”
課題
- HadoopクラスターとDWHの2つの運用が発生
- ETLにMapReduce等Hadoop特有のコーディングが必要
DataFlow
Actian DataFlow
DataFlow自体にHadoopは必須のコンポーネント
ではありません。しかし、大量データを安全、
安価、高速に処理可能なHadoopはデータ分析基盤
のストレージレイヤーに適してると言えます。
HadoopでETL
DWH

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市場のほとんどは
データウェアハウス市場と融合すると考えています。

これからのデータ分析基盤
RDBMS
DataFlow Engine
Vector
Legacy
ETL
DataFlow Engine
₋ No Map Reduceの並列分散実行エンジン
₋ ロード先がVectorの場合は、Hadoop側
で、データファイルをパラレルで作成
₋ 基本的にコーディングなし
SQL on Hadoop
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 on
CDH5.1
Impala 1.4 on
CDH5.1
Hive 0.12 on
CDH5.1
TPC-H Power@1000GB on 5 Nodes Cluster
41.8(1.0)
784.8(17.8倍)
8511.2(203.4倍)
Vector
Hadoop
Edition
Impala
1.4
Hive
0.12
Presto
0.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世代前のバージョン

20150630_データ分析に最適な基盤とは？ -コスト/スピードでビジネスバリューを得るために- by 株式会社インサイトテクノロジー CTO 石川雅也

20150630_データ分析に最適な基盤とは？ -コスト/スピードでビジネスバリューを得るために- by 株式会社インサイトテクノロジー CTO 石川雅也

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie 20150630_データ分析に最適な基盤とは？ -コスト/スピードでビジネスバリューを得るために- by 株式会社インサイトテクノロジー CTO 石川雅也

Ähnlich wie 20150630_データ分析に最適な基盤とは？ -コスト/スピードでビジネスバリューを得るために- by 株式会社インサイトテクノロジー CTO 石川雅也 (20)

Mehr von Insight Technology, Inc.

Mehr von Insight Technology, Inc. (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (10)

20150630_データ分析に最適な基盤とは？ -コスト/スピードでビジネスバリューを得るために- by 株式会社インサイトテクノロジー CTO 石川雅也