[db tech showcase Sapporo 2015] B16:ビッグデータには、なぜ列指向が有効なのか？ by 日本ヒューレット・パッカード株式会社小森博之

© Copyright 2014 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
ビッグデータには、
なぜ列指向が有効なのか？
2015年9月10日
日本ヒューレット・パッカード株式会社
プリセールス統括本部 / ソリューションセンター
小森博之
1

© Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.2
Hewlett-Packard Enterprise HP Inc.
HP は業界をリードする, 2つの新会社に
日本は一足早く 8月1日に分社
Source: (1) Based on publicly reported last 12 months from Q4 fiscal 2013 to Q3 fiscal 2014 revenue and OP after allocating Corp. Unallocated costs; (2) CQ2’14 IDC WW Quarterly Server Tracker (3) CQ2’14 Dell ‘Oro WW Tracker (4) CQ4’13 IDC WW IT Services
Tracker (5) CQ2’14 IDC WW External Disk Tracker; (6) CQ2’14 IDC WW PC Tracker(7) CQ2’14 IDC WW HCP Tracker (8) Forrester – Forrester Wave November 2013
フォーチュン 50 規模の企業
~$580億 (売上⾼1) ~$60億 (営業利益1)
#1 サーバー2 #2 ネットワーキング3
#2 サービス4 #4 ストレージ5
フォーチュン 50規模の企業
~$570億（売上⾼1） ~$50億（営業利益1）
#1 企業向けPCs6 #2 個⼈向けPCs6
#1 インクジェットプ
リンター 7
#1 レーザジェット
プリンター 7プライベートクラウドをリード 8

データベース検索が遅い
増え続けるデータ
あのデータもこのデータも
分析したい
サマリではなく明細を
分析したい
Big Data, IoT,
ヒューマンデータ
遅い！
原因は、ストレージの
IOが遅いこと
フラッシュスト
レージを使う
インメモリ機能を
使う

検索が遅い原因は、DB内部でのデータの格納方法
日付顧客ID 店舗地域売上高
0701 10001 新宿東京 100
0701 10002 新宿東京 1,000
0702 10003 札幌北海道 1,0000
0703 10004 梅田大阪 2,400
0703 10005 池袋東京 1,600
0701 10001 新宿東京 100
1,000
0701 10002 新宿東京
0702 10003 札幌北海道 1,0000 0703 10004
梅田大阪 2,400 0703 10005 池袋東京 1,600
行指向(従来型)の格納方法
SELECT 地域, SUM(売上高) FROM 売上テーブル GROUP BY 地域
• 全てのデータをストレージからメモリに読み込む
• エリアごとにデータをソートする
• エリアごとの売上高を集計する
売上テーブル
行をまとめて
取り出せる
IO数が多い

列指向は、検索を速くするための格納方法
0701 10001 新宿東京 100
0701 10002 新宿東京 1,000
0702 10003 札幌北海道 1,0000
0703 10004 梅田大阪 2,400
0703 10005 池袋東京 1,600
列指向の格納方法
SELECT 地域, SUM(売上高) FROM 売上テーブル GROUP BY 地域
• 必要なデータ(地域、売上高)をストレージからメモリに読み込む
• エリアごとにデータをソートする
• エリアごとの売上高を集計する
0701
0701
0702
0703
0703
10001
10002
10003
10004
10005
新宿
新宿
札幌
梅田
池袋
東京
東京
北海道
大阪
東京
100
1,000
1,0000
2,400
1,600
IO数削減
メモリに多
く格納
売上テーブル

列指向はデータの圧縮が効く格納方法
列ごとにデータを格納日付顧客ID 売上高
5/05/2009
5/05/2009
5/05/2009
5/05/2009
5/05/2009
5/05/2009
5/05/2009
5/05/2009
5/05/2009
5/05/2009
5/05/2009
0000001
0000052
0000001
0000001
0000003
0000003
0000005
0000011
0000011
0000020
0000026
0000050
0000051
0000052
5/05/2009, 165/05/2009, 16
RLE
アルゴリズム
00000010000001
0
2
2
4
10
10
19
25
49
Delta
Encoding
100.25
302.43
991.23
73.45
134.09
843.11
208.13
114.29
83.07
43.98
229.76
LZO
アルゴリズム
ÞìÃp:±æ+©>
Hì&ì¥YÛ¡×¥
©éa½?50ÓJ
同じデータタイ
プの似たデータ
が並ぶ
列ごとに最適な
圧縮方法を選択
可能
圧縮が効く
IO数削減メモリに多く格納

計算してみましょう！
テーブルのカラム数 : 50
SQLに必要なカラム数：5
行指向は50カラム全てのデータを読み込む
列指向は 5カラムだけを読み込む
圧縮率が 10倍
1 / 10
1 / 100
IO数
列指向はIO数を削減できる

列指向データベースの歴史
1995年 Sybase IQ Accelerator発売 → Sybase IQ → SAP IQ
2005年 Mike Stonebreaker 「C-Store: A Column-oriented DBMS」
→ Vertica
2004年 MonetDBがオープンソースとしてリリース
→ Vectorwise
2011年 SAP HANAがリリース
2012年 SQL Server 2012が”列ストアインデックス”を実装
2014年 Oracle 12cがインメモリオプションで列指向を実装
最初の商用
列指向DB
オープンソース
列指向DB
メジャーベンダ
が実装

列指向の実装方法は異なっています
列指向のみ。列ごとにインデックスとして格納。SAP IQ
列指向のみ。MPP, SIMD。Vectorwise
列指向のみ。MPP, プロジェクション。Vertica
列指向&行指向(基本は列指向)。インメモリ。SAP HANA
列指向&行指向(テーブルごとに選択)。行グループ。SQL Server
列指向(インメモリ)&行指向。1つのデータを両形式で持つ。Oracle

SQL Serverの実装 (行グループ)
行をグループ化し、その単位で列指向で格納
日付
0701
0701
0702
0703
0703
顧客ID
10001
10002
10003
10004
10005
店舗
新宿
新宿
札幌
梅田
池袋
地域
東京
東京
北海道
大阪
東京
売上高
100
1,000
1,0000
2,400
1,600
日付
0703
0705
0706
0706
0705
顧客ID
10006
10007
10008
10009
10010
店舗
新宿
品川
梅田
札幌
池袋
地域
東京
東京
大阪
北海道
東京
売上高
6,400
1,000
1,100
1,300
2,600
行グループ
列セグメント
列セグメントごとに圧縮して格納。
最大行数は 100万行。
列セグメントの最大値/最小値を保
持しており、検索条件に適合する行
グループのみを読み込みの対象とす
る。

Oracle Database 12c In-memory optionでの列指向
既存環境との互換性を重視した実装。検索高速化のためにデータを二重持ち
SGA
インメモリ領域
データ
ファイル
ログ
ファイル
Archive
ログ
OptimizerQuery
C1 C2 C3 C4 C1
C2 C3 C4 C1 C2
C3 C4
C1
Optimizerがどちら
をアクセスするか決
定
行指向
列指向
変更ログは書かない
ストレージにも書かな
い
起動後に行指向から列指向データを作
成
データ更新は、同時に両方に反映する
必要に応じ
てキャッ
シュに読み
込み
高速化したいテーブル
だけを指定して、行/列
指向の両方でデータを
持つ。列指向データは
メモリ上に配置C1
C1
C1
C2
C2
C2
C3
C3
C3
C4
C4
C4
データを行指向と列指向(インメ
モリ)の両方の形式で持つ(二重持
ち)

SQL Server 2014 メモリ最適化列ストアを例に
列指向の弱点をTuple Moverでカバーする
データの更新は、メモリ上の行指向のDelta Storeに一旦書き込まれる。
Delta Storeにデータがたまると、REORANIZEを実行。
その後、削除された領域の解放 (REBUILD)を実行。
Column
Store
Deleted
Bitmap
Delta
Store
Tuple
Mover
BULK INSERT
INSERT
DELETE
UPDATE
C1 C2 C3 C4 C5 C6
C1 C2 C3 C5 C6C4

列指向データベース
• データベース内部でのデータの持ち方の違い
• IOを大幅に削減することが可能
• 圧縮効率が高い
• 検索はもの凄く速いが、1件ずつの更新は苦手
• データベースによって実装方式は異なる

列指向データベースの代表例として、ご紹介

Vertica事例(全世界で3,000社以上）

DeNAが、モバイルサービスのログデータ分析を超高速
化しリアルタイムの仮説検証を実現
• 多様化するサービスの継続的な改
善のために、高速でより生産性の
高い分析基盤を構築すること。ロ
グデータに基づく「KPI分析」の
高速化により日常的な分析業務を
効率化する。また自由度の高い
「アドホック分析」を可能にする
ことで、新サービス立ち上げ時に
求められる試行錯誤的な仮説検証
を支援する。
ソフトウェア
• HP Vertica Analytics Platform
• 分析専用システムとして「HP Vertica
Analytics Platform」を採用し膨大なログ
データの超高速分析を実現
• Hadoopクラスターに蓄積された6PBの
データ資産を有効活用できるオンプレミ
スの分析基盤を構築
• HP Verticaの無償版（Community Edition
）によりスモールスタートを可能に
• MPP（マッシブパラレルプロセッシン
グ）アーキテクチャーによりデータ量の
増加に対応するスケールアウトを実現
• プロジェクション機能によって重要の高
いクエリーの高速化チューニングを可能
に
HP Vertica を採用しリアルタイム分析システムを構築
圧倒的な速度とスケーラビリティによりサービス改善のための分析業務を支援
ソリューション概略 ITの効果目的

C-Store(Vertica)の設計思想
“C-Store: A Column-Oriented DBMS.” Stonebraker et al. VLDB 2005.
• Compress columns
• No alignment
• Big disk blocks
• Only materialized views (perhaps many) → Projection
• Focus on Sorting not indexing → Indexよりsortが重要
• Data ordered on anything, not just time
• Automatic physical DBMS design → 物理デザインの自動化
• Optimize for grid computing → MPPに最適化
• Innovative redundancy
• Xacts – but no need for Mohan
• Column optimizer and executor → 列指向専用オプティマイザ

Verticaの特徴
Speed
Scalability
Simple
• 列指向＋超並列構成による圧倒的なパフォーマンス
• Vertica独自のプロジェクションによる圧倒的な速度向上
• マスターノードを持たない、無限のスケールアウト構成
• ノード追加によるリニアな性能向上が可能
• 標準SQLですぐに分析可能
• 複雑なチューニングは不要
• Hadoopとの連携が容易
Cost
• コモディティサーバ使用／またはクラウドによるコスト抑制
• 災対/開発/テスト環境用のライセンスは無償提供

Verticaの特徴を支える仕組み
ネイティブな
列指向
高度な圧縮プロジェク
ション
MPPスケール
アウト
クエリー分散
処理対象の削減
必要なデータの
みの読み込み
処理対象の削減
データの性質に
応じた最適な圧
縮アルゴリズム
を自動選択
処理効率の向上
最適な圧縮、列
配置、ソートが
事前に実施され
たデータセット
処理の分散実行
高い拡張性を備
えた超並列構成
でパラレル処理
を実行
処理の分散実行
すべてのノード
でクエリを受け
付け、マルチス
レッドで処理
CPU
Memory
Disk
CPU
Memory
Disk
CPU
Memory
Disk
A B D C E A

MPPスケールアウト
クライアント
ノード1 ノードN
SQL
全てのノードに
テーブルの全て
のデータを持つ
ハッシュ値によって、全てのノー
ドにデータを分散させて持つ
CREATE TABLE …….
UNSEGMENTED ALL NODES
CREATE TABLE …….
SEGMENTED BY HASH(日付) ALL NODES
ノードを追加すると、分散さ
れたデータは再分散される
データを分散させることで、
個々のノードが処理する
データ量を減らして
高速化する
北海道
東京
大阪
0701 10001 新宿東京 100
0701 10002 新宿東京 1,000
ノード2
北海道
東京
大阪
0702 10003 札幌北海道 1,0000
ノード3
北海道
東京
大阪
0703 10004 梅田大阪 2,400
0703 10005 池袋東京 1,600

マスターノードの不要：真のMPP構成
HP Vertica = Shared Nothing MPP マスターノードがあるMPP
→多数の同時処理に弱い→多数の同時処理にも強い
Clients Clients Clients Clients
超並列機能（MPP）でデータ及び処理の分散を
行えるため、リニアな拡張性を持ちます。また、
マスターノードが無いため、特定ノードがボト
ルネックとならない強みがあります。
Node#1
CPU
Memory
Node#2
CPU
Memory
Node#3
CPU
Memory
Node#N
CPU
Memory
Node#1
CPU
Memory
Node#2
CPU
Memory
Node#3
CPU
Memory
Node#N
CPU
Memory
Master Node
ClientsClientsClients
マスターノードの
冗長化が必要、ま
たパフォーマンス
ボトルネックにな
ります。

ノードダウン時の継続実行機能
• 最大2つのレプリカを保持可能
• 自動リプリケーションによる障害発生時サービス継続
Vertica#1 Vertica#2 Vertica#3 Vertica#4 Vertica#5
Data#1 Data#2 Data#3 Data#4 Data#5
Data#1 Data#2 Data#3 Data#4Data#5
Data#1 Data#2 Data#3Data#4 Data#5
レプリカ#1
レプリカ#2
分散テーブル
システム全体でRAIDのような構成を実現
Data#1
Data#1
Data#1

Vertica向けサーバー構成
X86_64アーキテクチャ上の64bit Linux OSで動作します。
最新のバージョン7.1.xでは以下のLinuxをサポートしています。
• Red Hat Enterprise Linux 5.x* and 6.x
• SUSE Linux Enterprise Server 11.0 through 11.0 SP3
• Oracle Enterprise Linux 6 - Red Hat Compatible Kernel only
• Debian Linux 6* and 7.0 through 7.5
• Cent OS 5.x* and 6.x
• Ubuntu 12.04 LTS and 14.04 LTS

Vertica ハードウェア構成のポイント
ノード内の並
列処理のため、
コア数は多め
CPUライセンスで
はないのでコア数
が多くても気にし
ない
目安は、4GB/CPU
コア以上
メモリは多い
ほどよい
内蔵ディスク
だけの構成が
多い
データ容量とIO数
の両面から検討
インターコネク
トは10Gbe推奨
可用性のためには最低3
ノード。レプリカを2つ
持つには5ノード必要。
性能が不足したら、
ノードを増やす。ライ
センスには関係なし。

Verticaシステム構成例
DL380 Gen9 x 3台
Xeon E5-2690 v3 2.6GHz x 2CPU/24Core
256GBメモリ
内蔵 300GB x 2, 600GB x 24
10GbE x 4ポート
冗長化
冗長化

プロジェクション
自動チューニング
今までのRDBMSの知識で
テーブル、SQLの作成
最高のパフォーマンスが出せる物理デザインをVerticaが自動で作成
0701 10001 新宿東京 100
0701 10002 新宿東京 1,000
0702 10003 札幌北海道 1,0000
0703 10004 梅田大阪 2,400
0703 10005 池袋東京 1,600
0703 10006 新宿東京 6,400
0705 10007 品川東京 1,000
0706 10008 梅田大阪 1,100
0706 10009 札幌北海道 1,300
地域店舗日付売上高顧客ID
大阪梅田 0703 2,400 10004
0706 1,100 10008
東京池袋 0703 1,600 10005
品川 0705 1,000 10007
新宿 0701 100 10001
1,000 10002
0703 6,400 10006
札幌北海道 0702 1,0000 10003
0706 1,300 10009

Verticaでは、テーブルは論理スキーマとして定義
create table table1
(日付 date ,顧客ID(int),店舗 varchar(10),地域 varchar(10) , 売上高(int)）;
プロジェクションとは？
プロジェクションは物理スキーマとして定義（自動ツールによりチューニング）
date int varchar(10) varchar(10) Int
0701 10001 新宿東京 100
0701 10002 新宿東京 1,000
0702 10003 札幌北海道 1,0000
0703 10004 梅田大阪 2,400
0703 10005 池袋東京 1,600
0703 10006 新宿東京 6,400
0705 10007 品川東京 1,000
0706 10008 梅田大阪 1,100
0706 10009 札幌北海道 1,300
日付売上高
0701 100
1,000
0702 1,0000
0703 2,400
1,600
6,400
0705 1,000
0706 1,100
1,300
Projection-1 Projection-2
地域店舗日付売上高顧客ID
大阪梅田 0703 2,400 10004
0706 1,100 10008
東京池袋 0703 1,600 10005
品川 0705 1,000 10007
新宿 0701 100 10001
1,000 10002
0703 6,400 10006
札幌北海道 0702 1,0000 10003
0706 1,300 10009
大阪梅田の平均売上高 7/6の売上
クエリー毎に最適化を事前に行うことも可能
店舗売上高
（SUM)
札幌 11,300
新宿 7,500
梅田 3,500
池袋 1,600
品川 1,000
店舗別売上ランキング
(事前集計プロジェクション)

プロジェクション作成DDL（例）
SELECT
売上テーブル. 日付 ,
売上テーブル. 地域 ,
売上テーブル.店舗 ,
売上テーブル.売上高
FROM 売上テーブル
CREATE PROJECIOTN 売上テーブル_P1(
日付 ENCODING RLE ,
地域 ENCODING RLE ,
店舗 ENCODING RLE ,
売上高 ENCODING DELTVAL
) AS
列の選択＆
圧縮率の指定
実データの指定
ORDER BY 日付 ,
地域 ,
店舗
列の並び替え
SEGMENTED BY HASH(日付, 地域) ALL NODES;
ノードに分散する
HASH KEYの指定

プロジェクションの種類
アドホッククエリーから特定のクエリーまでさまざまなクエリに対応
テーブルA テーブルB
クエリースペシフィックプロジェクション
特定のクエリーに特化したプロジェクション
• データベースデザイナーがクエリーを解析し、クエ
リーに最適なプロジェクションを追加作成１２３
プレジョインプロジェクション
事前にJOINしたプロジェクション
• 手動で追加作成する必要あり
• データロード実行時にJOIN処理を実施
スーパープロジェクション
全クエリーに汎用的に対応可能なプロジェクション
• 初回ロード実行時、自動生成（最適化前）
• すべての列を含み、列の型やカーディナリティーを
考慮して、データベースデザイナーが最適化したも
のを自動作成
圧
縮
圧
縮
圧
縮
圧
縮
圧
縮
最適な並び替え最適な並び替え
圧
縮圧
縮
圧
縮圧
縮
圧
縮
圧
縮
圧
縮
圧
縮
圧
縮
圧
縮
圧
縮
圧
縮
プレジョインプロジェクション
クエリスペシフィックプロジェクション
ライブアグリゲートプロジェクション
事前に集計したプロジェクション
• 手動で追加作成する必要あり
• データロード実行時にGRUP BY処理を実施
ライブアグリゲート
Id
毎
Sum
Count
Max
Min
Top-K
圧縮圧縮

プロジェクションまとめ
ユーザはプロジェクションを意識する必要なく、
テーブルに対してクエリーを実行すれば良い
テーブル
スーパープロジェクション
すべての列を含み、汎用的な圧縮、
並び替えを事前にしているデータセット
クエリースペシフィック
必要な列のみ
クエリーに特化した圧縮
並び替え
プレジョイン
ロードのタイミング
で事前にジョインし
そのデータを格納
もっとも検索コストが低いプロジェクションをVerticaが自動選択
ユーザは意識をする必要はない
ライブアグリゲート/TOP-K
最新の集計結果をロードの
タイミング格納
Id
毎
Sum
Count
Max
Min
Top-K

VerticaとHadoopの適材適所の使い分け
Hadoop
HDFS
MapR NFS
HP Vertica for
SQL on Hadoop
①HDFSコネクタ
HDFS上のファイルを外部表で、ま
たはVertica上にロードし参照可能
External Tables
外部表参照
高速
ローディング
HP Vertica
Enterprise
Edition
COPY
SQL
SQL SQL
列フォーマット
に最適化
SQL
ORC
External Tables
外部表参照
③ORCリーダー
ORCファイルを外部
表として参照可能
④SQL on Hadoop
HDFS/MapR NFSをVerticaのデー
タ格納先として指定し、テーブ
ルとして参照可能
②Hcatalogコネクタ
Hive上のスキーマを
Verticaから参照可能
SQL
リアルタイム、高速な分析が必要なデータはVerticaに! Hadoopとの共存がこれからの形に！
COPY
Hive
SerDe
(Serialize/Deserialize)

Kafkaクラスタ
Hadoop関連の新機能
Vertica “Excavator”でKafkaとの連携をサポート
7.0 Crane Excavator7.1 Dragline6.1 Bulldozer
HDFSコネクタ
Hcatalogコネクタ
SQL on Hadoop
ORCリーダー Kafkaとの連携
producer consumer
Verticaクラスタ
ストリーム
データ

Big Dataのニーズに応える新しいアプローチ
伝統的なBig Dataアプローチ
• コンピュートとストレージが
常にセットで導入
• すべてのサーバーは同一
• データはサーバーにDAS接続さ
れたストレージに割り振られて
いる
新しいHPのBig Dataアプローチ
• イーサーネットで接続された階層の異な
るコンピュートとストレージ層
• YARNアプリケーションはコンピュート
に導入される
• Hadoopはストレージサーバー上のスト
レージコンポーネントに
2CPU, 2U サーバー
コンピュートに最適化されたサーバー群
ストレージに最適化されたサーバー群
YARN
アプリ
HDFS,
Hbase,
Cassandr
aなど

HP Big Data Reference Architectureの特徴
HP Moonshot とApollo 4500 が実現するHadoop用リファレンスアーキテク
チャー
Ethernet (RoCE)
クラスター統合
様々なBig Data環境から共有データプールにアクセ
ス
柔軟な拡張性
コンピュートとストレージの処理を切り離し、
必要なインフラのみを独立して拡張
拡張の柔軟性
ストレージ性能に影響を与えずコンピュートを拡充
圧倒的コスト効果
ワークロードに最適化されたコンポーネントにより、
劇的なスペース・電力・コスト削減が可能
電力・スペース効率がよいサーバー
ディスクをたくさん搭載できるサー
バー

これからのビッグデータ基盤
•Hadoop/YARNをベースに、様々なツールが連動
•コンピュートノードを動的にアサイン
Hadoop Cluster 1
Vertica
Analytics
Kafka
12am – 6am
6am – 12am
Hadoop
Cluster 2
Hadoop Cluster 1
Hadoop
Cluster 2
Storage Node Storage Node
Nod
e
Nod
e
Nod
e
Nod
e
Nod
e
Nod
e
Nod
e
Nod
e
Nod
e
Nod
e
Nod
e
Nod
e
Nod
e
Nod
e
Nod
e
Nod
e
Nod
eNod
eNod
e
Nod
e
Nod
e
Nod
e
Nod
e
Nod
e
Nod
e
Nod
e
計算ノードと
ストレージノード間
はRDMAを使用
Storage Node …

HP Vertica Community Edition
データ量1TB/クラスター構成3ノード
まで、無期限でお試しいただけます
 HP Verticaの全ての機能を使えます
 Community Edition用のインストールガイド(日本語)もご用意しています
 Let’s download!
http://h50146.www5.hp.com/products/software/hpsoftware/vertica/trials.html

日本ヒューレット・パッカード
明日のセッション
11:00-11:50
A22
HP NonStop SQLはなぜグローバルに分散DBを構築
できるのか、データの整合性を保てるのか
後藤宏

アンケートにご協力ください

Thank you!
小森博之
プリセールス統括本部
ソリューションセンター
ソリューション一部
Tel: 090-7906-4517
Mail: hiroyuki.komori@hpe.com日本ヒューレット・パッカード
株式会社
〒136-8711
東京都江東区大島2-2-1

[db tech showcase Sapporo 2015] B16:ビッグデータには、なぜ列指向が有効なのか？ by 日本ヒューレット・パッカード株式会社小森博之

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to [db tech showcase Sapporo 2015] B16:ビッグデータには、なぜ列指向が有効なのか？ by 日本ヒューレット・パッカード株式会社小森博之

Similar to [db tech showcase Sapporo 2015] B16:ビッグデータには、なぜ列指向が有効なのか？ by 日本ヒューレット・パッカード株式会社小森博之 (20)

More from Insight Technology, Inc.

More from Insight Technology, Inc. (20)

Recently uploaded

Recently uploaded (9)