[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 新宿東京 1000701 10002 新宿東京 1,0000702 10003 札幌北海道 1,00000703 10004 梅田大阪 2,4000703 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 新宿東京 1000701 10002 新宿東京 1,0000702 10003 札幌北海道 1,00000703 10004 梅田大阪 2,4000703 10005 池袋東京 1,600

列指向の格納方法

SELECT 地域, SUM(売上高) FROM 売上テーブル GROUP BY 地域

• 必要なデータ(地域、売上高)をストレージからメモリに読み込む

• エリアごとにデータをソートする

• エリアごとの売上高を集計する

07010701070207030703

1000110002100031000410005

新宿

新宿

札幌

梅田

池袋

東京

東京

北海道

大阪

東京

1001,000

1,00002,4001,600

IO数削減

メモリに多く格納

売上テーブル


列指向はデータの圧縮が効く格納方法

列ごとにデータを格納日付顧客ID 売上高

5/05/20095/05/20095/05/20095/05/20095/05/20095/05/20095/05/20095/05/20095/05/20095/05/20095/05/2009

0000001

0000052

000000100000010000003000000300000050000011000001100000200000026000005000000510000052

5/05/2009, 165/05/2009, 16

RLEアルゴリズム

0000001000000102241010192549

DeltaEncoding

100.25302.43991.2373.45134.09843.11208.13114.2983.0743.98229.76

LZOアルゴリズム

ÞìÃp:±æ+©>Hì&ì¥YÛ¡×¥©éa½?50ÓJ

同じデータタイプの似たデータ

が並ぶ

列ごとに適な圧縮方法を選択

可能

圧縮が効く

IO数削減メモリに多く格納


計算してみましょう！

テーブルのカラム数 : 50SQLに必要なカラム数：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の実装 (行グループ)行をグループ化し、その単位で列指向で格納

日付

07010701070207030703

顧客ID1000110002100031000410005

店舗

新宿

新宿

札幌

梅田

池袋

地域

東京

東京

北海道

大阪

東京

売上高

1001,000

1,00002,4001,600

日付

07030705070607060705

顧客ID1000610007100081000910010

店舗

新宿

品川

梅田

札幌

池袋

地域

東京

東京

大阪

北海道

東京

売上高

6,4001,0001,1001,3002,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)を実行。

ColumnStore

DeletedBitmap

DeltaStore

TupleMover

BULK INSERT

INSERTDELETEUPDATE

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/24Core256GBメモリ内蔵 300GB x 2, 600GB x 2410GbE 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毎

SumCountMaxMin

Top-K

圧縮圧縮


プロジェクションまとめユーザはプロジェクションを意識する必要なく、

テーブルに対してクエリーを実行すれば良い

テーブル

スーパープロジェクションすべての列を含み、汎用的な圧縮、

並び替えを事前にしているデータセット

クエリースペシフィックプロジェクション必要な列のみ

クエリーに特化した圧縮並び替え

プレジョインプロジェクション

ロードのタイミングで事前にジョインしそのデータを格納

もっとも検索コストが低いプロジェクションをVerticaが自動選択

ユーザは意識をする必要はない

ライブアグリゲート/TOP-Kプロジェクション

新の集計結果をロードのタイミング格納

Id毎

SumCountMaxMin

Top-K


VerticaとHadoopの適材適所の使い分け

Hadoop

HDFSMapR NFS

HP Vertica for SQL on Hadoop

①HDFSコネクタHDFS上のファイルを外部表で、またはVertica上にロードし参照可能

External Tables外部表参照

高速ローディング

HP VerticaEnterprise

Edition

COPY

SQL

SQL SQL

列フォーマットに適化

SQL

ORC

External Tables外部表参照

③ORCリーダーORCファイルを外部表として参照可能

④SQL on HadoopHDFS/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 consumerVerticaクラスタ

ストリームデータ


Big Dataのニーズに応える新しいアプローチ

伝統的なBig Dataアプローチ• コンピュートとストレージが常にセットで導入

• すべてのサーバーは同一• データはサーバーにDAS接続されたストレージに割り振られている

新しいHPのBig Dataアプローチ• イーサーネットで接続された階層の異な

るコンピュートとストレージ層• YARNアプリケーションはコンピュート

に導入される• Hadoopはストレージサーバー上のスト

レージコンポーネントに

2CPU, 2U サーバー

コンピュートに適化されたサーバー群

ストレージに適化されたサーバー群

YARNアプリ

HDFS, Hbase,

Cassandraなど


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 – 12amHadoop Cluster 2

Hadoop Cluster 1 Hadoop Cluster 2

Storage Node Storage Node

Node

Node

Node

Node

Node

Node

Node

Node

Node

Node

Node

Node

Node

Node

Node

Node

Node

Node

Node

Node

Node

Node

Node

Node

Node

Node

計算ノードとストレージノード間

は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:50A22HP NonStop SQLはなぜグローバルに分散DBを構築できるのか、データの整合性を保てるのか

後藤宏


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


Thank you!

小森博之プリセールス統括本部ソリューションセンターソリューション一部

Tel: 090-7906-4517Mail: [email protected]日本ヒューレット・パッカード

株式会社〒136-8711東京都江東区大島2-2-1

Technology

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

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