DEIM Forum 2014 D1-5

カラム構造と圧縮による Hadoop から PostgreSQL へのロード高速化に関する実験と考察若森 拓馬†

健†

山室

寺本 純司†

剛†

西村† NTT ソフトウェアイノベーションセンタ 〒 180–0012 東京都武蔵野市緑町 3–9–11
E-mail: †{wakamori.takuma,yamamuro.takeshi,teramoto.junji,nishimura.go}@lab.ntt.co.jp
あらまし

ログ分析などの用途で Apache Hadoop 上に蓄積された大規模データを単一の RDBMS へロードする際，ロード時間が長期化する問題がある．ロード時間の中では，特にネットワーク転送時間が大きいことから，データの圧縮によって転送時間短縮を図る．圧縮を行う場合，圧縮率，圧縮・伸長速度がロード時間に影響する．本論文では，データ転送ツールのプロトタイプを設計・実装し，異なる圧縮率，圧縮・伸長速度をもつ複数の圧縮形式について速度比較実験を行った．実験結果をもとに，データ圧縮のロード時間短縮に対する有効性について考察した．
キーワード

1. 背

Hadoop，PostgreSQL，バルクロード，圧縮
す．Twitter を用いた情報推薦サービスなどにおいては，サー景

ビス品質の低下につながる恐れがある．

業務アプリケーションのログデータやセンサデータなどの非この問題を具体化するため，Hadoop から RDBMS へのロー

構造データを大規模に蓄積し，統計処理などの分析を行い，新ド処理を次の 2 段階に分割し，それぞれの処理に要する時間をしい価値を創出する取り組みが企業等において盛んに行われて調査する予備実験を実施した．

いる．大規模データの分析は，図 1 に示すような，データの (1)（ 1 ） HDFS から RDBMS へのデータのネットワーク転送

蓄積，(2) 加工 (抽出)，(3) 分析という各処理で構成される．こ（ 2 ） 転送後データの RDBMS のテーブルへのロードのうち蓄積処理と抽出処理は，大規模データに対する I/O 性能

予備実験では，汎用的なハードウェア構成 （注 1） を用いて，要件が大きいことから，Hadoop などの分散システムが用いら

Hadoop のファイルシステムである HDFS 上のテキストデータれる．一方，分析処理は人手で実施するため，応答性能要件がを OSS の RDBMS である PostgreSQL へロードする際のデー

大きいことから，RDBMS が用いられる．このように，複数のタ転送・ロードの各処理に要する時間を測定した．予備実験のシステムを適材適所に用いることで分析処理全体の効率化を図

結果を図 2 に示す．結果から，データ転送・ロードの各処理にる取り組みが一般的に行われている．

同程度の時間を要することがわかった．ロード時間短縮のため

複数のシステムを用いた分析処理では，異なるシステム間でには，このいずれかの処理を高速化する必要があるが，本論文データの移行処理が発生する．特に，Hadoop と RDBMS を用では，このうちデータ転送処理の高速化に着眼し，この高速化いた場合，Hadoop から RDBMS へのデータのロード処理が必により分析処理全体の効率化を目指す．

要となる．Oracle や Greenplum DB，Teradata Aster などのCopy	
  from	  HDFS	  to	
  Local	  Filesystem	
  る専用のツールを用意しており [2], [3], [9]，分散システム上のデータを単一系の RDBMS へ集約するロード機能に対して一定の需要があることが窺える．
Hadoop,  Hive
データ発⽣生源

溜溜める

加⼯工(抽出)する

1〜～24h10TB〜～

2500	
  
2000	
  
1500	
  
1000	
  
500	
  
0	
  
10	
  

分析する

⽤用途毎に
⾮非（半）構造データ １次加⼯工されたデータ

Load	
  

3000	
  

RDBMS

20	
  

30	
  

Data	
  Size	  (GiB)	

ロード
業務ログや
外部データ

Execu&on	
  Time	  (sec)	

商用 DB 製品は，Hadoop 上のデータを RDBMS へロードす

図 2 ロード処理におけるデータ転送時間とテーブルへのロード時間
分析DB，商品・顧客DB応答性能要件

データ規模に関する要件

1ms〜～1s〜～1TB

図 1 想定する分析処理とアーキテクチャ

ここで，同構成を用いたロード処理における，HDFS から

PostgreSQL ノードへの LAN 経由のデータ転送速度，及びロード時の PostgreSQL ノードの CPU 使用率を表 1 に示す．
表 1 から，データ転送速度が理論性能 (128MB/s) に近い値

ここで，データの増大に対してロード時間が長期化することが問題視されている [4], [7]．ロード時間の長期化は分析処理全（注 1）：論理コア数 12・動作周波数 2.93GHz の CPU と SAS HDD，1Gb

体を長期化し，結果の即時性などの分析品質の低下を引き起こ

Ethernet を用いた構成

表1

データ転送時のネットワーク転送転送とロード時の CPU 使用率

Data transfer speed Postgres CPU usage105.6MB/s

4.52%

Positional Map というインデックスを構築し，未処理データに対する属性ごとの位置情報をメタデータとして管理している．

2. 2 外部データを RDBMS へ高速にロードする手法
外部データを RDBMS へ高速にロードする手法に関しては，となっている一方，ロード時の CPU リソースには余裕がある

データを並列にロードする手法や，データを一斉ロード (バルことがわかる．この状況においては，CPU リソースを利用してクロード) すると同時にインデックスを生成する手法がある．

データ圧縮・伸長を行い，ネットワーク I/O 量を低下させるこ

これらの手法は，ひとたびデータをロードすればその後のクエとによる転送時間の短縮が期待できる．ただし，ロード時に圧リは高速に処理できるため，ロード時間の短縮が課題となる．

縮を行う場合，圧縮・伸長にかかる時間を考慮する必要がある．

HDFS 上の外部データを MapReduce 処理を用いて RDBMS

本論文では，ロード時間短縮に対する圧縮の有効性を評価す

へロードする研究として，Progressive Sampling を用いた re-

る実験と考察を行った．実験のため，HDFS 上のテキストデー

ducer の負荷分散手法がある [8]．これは，mapper の出力が，タを圧縮して転送するデータ転送ツールのプロトタイプを設ある reduce-key に関連する value を多数含む場合や，多数

計・実装した．プロトタイプを用いて，異なる圧縮率，圧縮・の reduce-key が同一の reduce タスクへ割り当てられた際に，伸長速度をもつ複数の圧縮形式を用いた場合の，圧縮・伸長・

reducer のデータの偏り (data skew) が発生するという MapRe-

転送時間を測定した．実験結果をもとに，ロード時間短縮に有duce に関する本質的な問題の解決を図っている．reducer の負効な圧縮形式について考察し，得られた知見を述べる．

荷を平均化するために，mapper の出力に対して Progressive

本論文は以下のとおり構成される．2. 節において，外部デー

Sampling を行い，巨大な key を分割して MapReduce の par-タを RDBMS で効率的に処理するための手法に関する研究動

titioner へ結果を反映させている．この手法は，Oracle Loader

向を俯瞰し，本論文の位置づけを述べる．3. 節で実験に用いるfor Hadoop に実装され，HDFS から RDBMS へのロード処理

データ転送ツールのプロトタイプの設計と実装を説明する．4.

の 3，4 倍の高速化を達成している．HyPer の Instant Load-

節で速度比較実験の概要と結果を述べる．5. 節にて実験結果か

ing [7] は，In-Memory DB と 10Gb Ethernet を用いた際に，ら得られた結果について考察する．続く 6. 節にて本論文を総括

ネットワーク帯域を有効活用することができないことを問題視する．

し，タスク並列化や SIMD を利用した CSV ファイルのパース

2. 関 連 研 究
外部データを RDBMS で処理する方法には以下の 2 つがある．

•

外部データに対してあたかもテーブルが存在するかのよ

うにアクセスする方法•

データを RDBMS へロードする方法

本節では，それぞれの手法の効率化に関する研究を概観し，本論文の位置づけを述べる．

のベクトル化などを用いて帯域を活用し，ロード速度向上を達成している．
一方，既存の OSS プロダクトに，Hadoop と RDBMS 間のデータを連携する Apache Sqoop [1] と呼ばれるツールがある．

Sqoop は，Map-Only Task を用いてデータを RDBMS へ並列にロードすることで処理の高速化を図っている．また，Hadoopと RDBMS のデータの受け渡しをするコネクタを用意しており，PostgreSQL に関しては，JDBC の他に，PostgreSQL 固

2. 1 RDBMS から外部データへ効率的にアクセスする手法

有の COPY コマンドや pg bulkload ユーティリティ等を利用

RDBMS から外部データへアクセスする手法に，外部表機能

し，バルクロードによる高速化を図っている．

を用いる手法がある．外部表機能とは，外部のファイルに対して

2. 3 本論文の位置づけ

スキーマを定義し，テーブルのような操作を可能する RDBMS

本論文は，Hadoop と RDBMS を用いた構成における，ローの機能である．外部表機能を用いると，ロード処理を行わずにド処理の短縮による分析処理全体の処理時間の短縮を目的としテーブルアクセスが可能となる．一方，クエリの処理時間につている．1Gb Ethernet など，汎用のハードウェアを利用した

いては，外部ファイルを取り扱うため，通常のテーブルに対す

際のネットワーク経由でのデータ転送処理時間の長期化を課題

る処理よりも時間がかかる傾向にあり，この短縮による効率化とし，ネットワーク I/O 量の削減のため圧縮を行う．

が行われている．

Polybase [6] や Hadapt [5] は，HDFS 上の非構造データと3. 設計と実装

RDBMS 上の構造データに対するスケーラブルなクエリを提Hadoop から RDBMS へのデータロード高速化に対する圧供する枠組みを利用している．Polybase は，SQL Server の縮の有効性を評価するため，圧縮を用いたデータ転送ツールのParallel Data Warehouse を用いて，Hadapt は MapReduce

プロトタイプを設計・実装した．本節では，プロトタイプの概を用いて，Hadoop と RDBMS に対する並列クエリの最適化・

要と設計・実装時に考慮した点を説明する．

実行プランの生成を行い，分析クエリのトータルの高速化を果

3. 1 概たしている．NoDB [4] は，HDFS 上の未処理の構造化データ

図 3 は，プロトタイプを用いたデータ転送処理の全体像を表要をクエリ実行時にパースし処理するという発想で，これを高速す．プロトタイプの動作手順は以下のとおりである．

化するためのパース手法やインデックス構築手法，キャッシュ機（ 1 ） 入力データを分割し，並列分散処理で圧縮する構などを提案している．一例を挙げると，NoDB は Adaptive（ 2 ） 圧縮データを単体の PostgreSQL ノードへ転送するHadoop

PostgreSQLのハードウェア環境を表 2 に示す．なお，すべてのノードに同

JobTracker
TaskTracker

一構成のハードウェアを用いた．

Ethernet

比較対象の圧縮形式には，異なる圧縮率，圧縮・伸長速度を

TaskTracker

転送

TaskTracker

分割実験に使用した Hadoop クラスタおよび PostgreSQL サーバ

伸⻑⾧長

圧縮

図3

もつ snappy，lzo，gzip，bzip2 の 4 形式を用いた．表 3 に，使用したソフトウェアやライブラリのバージョンを示す．

プロトタイプの構成

表 2 ハードウェア構成項目

設定値（ 3 ） PostgreSQL ノード上で圧縮データを伸長する

Hadoop クラスタ

9 台 (NameNode 1，DataNode 8)

3. 2 設PostgreSQL サーバ 1 台

計

プロトタイプを設計するうえで考慮した点について説明する．

CPU

Xeon 5160 (2C，3GHz，4MB L2)

Hadoop から RDBMS へのデータ転送時に圧縮，伸長を行う

MemoryDIMM DDR2 667MHz 8GB (2GB x 4)

HDD

SCSI 500GB

NIC

NetXtreame II Gigabit Ethernet

場合，圧縮時に MapReduce による分散処理の利用が可能である．プロトタイプでは，圧縮を分散処理で行うことを前提とした．また，予備実験の結果から，データ転送・ロード処理時のCPU リソースに余裕のあることが分かったため，圧縮によるCPU リソースへの影響は考慮しないことを前提とする．
また，データ転送時に圧縮を行う場合，ネットワーク I/O 量

表 3 ソフトウェア構成
項目

バージョン

OS

CentOS 6.2 x86 64

削減による転送時間の短縮が見込める一方で，圧縮・伸長に追Hadoop2.0.0+1518 (CDH 4.5.0)

加の時間を要する．以上のことから，プロトタイプにおけるsnappy-java 1.1.0.1

データ転送時間に影響する要素として以下が挙げられる．

•

圧縮率

•

圧縮・伸長速度•

圧縮処理並列数

プロトタイプを設計するうえで，これらの要素を組み替えて実験を行えることを考慮した．

3. 3 実装lzo-java

1.0.0

jzlib

1.1.0

転送対象とするデータは，Apache HTTP サーバのアクセス
ログの擬似データを生成するツールである apache-loggen（注 2）を用いて生成した．apache-loggen は，アクセスログにおけるIP アドレス部をランダムに生成し，アクセスパス部とユーザー

プロトタイプの圧縮機能の実装について説明する．

エージェント部をいくつかのパターンからランダムに選択したプロトタイプで用いる圧縮形式には，異なる圧縮率，圧縮・データを生成する．生成されるログデータの一例を以下に示す．

伸長速度をもつ圧縮形式を指定可能にするため，Hadoop に標

132.219.142.20 - - [07/Feb/2014:10:01:48 +0900]

準で用意されている snappy，lzo，gzip，bzip2 の 4 種類を用い"GET /category/electronics HTTP/1.1" 200 108 "-"た．Hadoop の圧縮ライブラリは，圧縮・伸長処理を Hadoop"Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1;

上で行うことを想定しており，snappy と lzo の 2 形式について

Trident/4.0; BTRS122159; GTB7.2; .NET CLR 1.1.4322;

は，ブロック圧縮のため追加のメタ情報を付加している．プロト.NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR

タイプでは，Hadoop の外部で伸長を行う構成のため，この標3.0.4506.2152; .NET CLR 3.5.30729; BRI/2)"

準ライブラリをそのまま利用することが困難であった．そのた

apache-loggen を用いて 1GB，10GB，30GB，50GB の 4 パ

め，すべての圧縮形式について，snappy-java や lzo-java など

ターンのデータを生成し，各データについて測定を実施した．

の圧縮ライブラリの Java 実装を利用し，Reduce 処理を行わな

実験の測定項目は以下の 4 項目である．

い Map-Only Task で圧縮ファイルを出力する MapReduce プ

測定 1 圧縮率，圧縮・伸長速度

ログラムを開発した．転送処理は，hadoop の ‘hadoop fs -get’

測定 2 圧縮データの転送時間

コマンド，伸長処理は，gzip プログラムなどコマンドラインで測定 3 圧縮・伸長時間

実行可能なプログラムを用いた．

測定 4 転送・圧縮・伸長時間の合計と非圧縮データの転送時間測定にあたり，圧縮・伸長速度の高速な snappy，lzo などの

4. 実

験

ロード時間短縮に対する圧縮の有効性を評価するために，複数の圧縮形式を用いて，データの圧縮率・圧縮・伸長速度およびデータ転送時間を測定する実験を行った．本節では，実験概要と結果を述べる．

圧縮形式が転送時間の短縮に有効であるという予測を立てた．

4. 2 実 験 結 果
前節にて述べた測定項目の測定結果を表 4，図 4，図 5 および図 6 に示す．
各測定結果を以下にまとめる．

4. 1 実 験 概 要
実験の測定環境と測定項目を以下に説明する．

（注 2）：https://rubygems.org/gems/apache-loggen/versions/0.0.4

表 4 各圧縮形式の圧縮率と圧縮・伸長速度

測定結果 4

圧縮率の高い形式ほど転送時間が短く，圧縮・伸圧縮形式

圧縮率 圧縮 (MB/s) 伸長 (MB/s)

長時間が長い．10GB 以上のデータサイズにおいて，snappy，

snappy

0.206

48.69

296.61

lzo，gzip の転送時間が非圧縮の場合よりも短い．

lzo

0.191

46.21

249.54

gzip

0.087

43.63

203.66

bzip2

0.036

3.66

40.65

ここで，測定結果 4 から，1GB のデータサイズにおいて，圧縮を行わない場合に最も短時間で転送が行えることが分かった．そこで，0B から 10GB 小規模データを用いて，測定 4 について追加の測定を行い，性能の逆転について分析した．なお

0.35

bzip2 は逆転が発生しないため比較対象から除外している．

⾮非圧縮データ転送時間との⽐比率率率0.4

結果を図 7 に示す．結果より，入力データサイズが 0B のと

0.3

0.25

snappy

0.2

lzo

0.15

gzip

0.1

bzip2

0

1

10
30
圧縮前データサイズ  (GB)

150

⾮非圧縮
snappy

100

608

3550

1436

実⾏行行時間  (sec)

500
450
400
350
300
250
200
150
100
50
0

2076

250
200

50

図 4 圧縮データの転送時間
850の区間で性能の逆転が発生することがわかった．
圧縮・データ転送・伸⻑⾧長時間の合計  
(sec)

0.05

き，snappy，lzo，gzip については，Map-Only Task の起動か
ら終了までに 7 秒の時間を要すること，および 2GB から 4GB

lzo
gzip

50
0

0

2

4
6
データサイズ  (GB)

8

10

圧縮

1GB

10GB
30GB
圧縮前データサイズ，圧縮形式

図5

図 7 小規模データにおける転送・圧縮・伸長時間の合計と非圧縮デー
タの転送時間

bzip2

lzo

gzip

bzip2

snappy

lzo

gzip

bzip2

snappy

lzo

gzip

bzip2

snappylzo

gzip

snappy

伸⻑⾧長

50GB

5. 考

察

本節では，4. 節の実験結果をもとに，データロード高速化に

圧縮・伸長時間

対する圧縮の有効性について考察する．
5026

実験結果の考察から以下のような知見を得た．

•

圧縮率と圧縮・伸長速度のバランスの良い圧縮の利用に

より，データ転送時間の短縮が可能．
圧縮

1GB

10GB
30GB
圧縮前データサイズ，圧縮形式

⾮非圧縮snappy
lzo
gzip
bzip2

⾮非圧縮
snappy
lzo
gzip
bzip2

⾮非圧縮
snappy
lzo
gzip
bzip2

伸⻑⾧長
⾮非圧縮
snappy
lzo
gzip
bzip2

転送・圧縮・伸⻑⾧長時間  (sec)

1000
900
800
700
600
500
400
300
200
100
0

2712

転送

50GB

•

データが小規模の場合は，並列化のコスト等が圧縮による利得を上回るため，圧縮を利用しないほうが良い．

1 点目について，今回用いた 4 つの圧縮形式は，圧縮率の高いブロックソートを用いた形式 (bzip2) と，圧縮・伸長速度の速いスライド窓を利用した形式 (snappy，lzo)，及び圧縮速度と圧縮率のバランスのとれた Deflate アルゴリズムを用いた形
式 (gzip) という 3 種類に分類される．データ転送時間の短縮と

図6

転送・圧縮・伸長時間の合計と非圧縮データの転送時間いう用途においては，圧縮・伸長時間の高速な snappy，lzo が最も有効だと予想していたが，予想に反して，バランスのとれ

測定結果 1

圧縮・伸長速度は snappy，lzo，gzip，bzip2 の順

た gzip の方が有効という結果を示した．この理由として，今で優れている．圧縮率はその逆順である．

回利用したデータは頻度の異なる繰り返しが多く，Deflate ア測定結果 2すべてのデータサイズにおいて，非圧縮の場合とルゴリズムのハフマン符号により gzip の圧縮率が snappy，lzo

比較して 4 割以下の時間で転送が完了している．また圧縮率のよりも高かったこと，および処理時間の大部分を占める圧縮時

高い圧縮形式ほど転送時間が短い．

間が gzip，snappy，lzo の 3 つで大きな差が見られなかったこ

測定結果 3snappy，lzo，gzip の圧縮・伸長時間は近い値を示となどが考えられる．ただし，gzip と snappy，lzo の差が僅かしている．bzip2 は他の 3 形式と比較して圧縮・伸長時間が大であることから，受信側ノードの伸長性能が低い場合などにお幅に長い．

いては，性能が逆転することも考えられる．

2 点目について，今回のプロトタイプは圧縮に Map-Only
Task による並列分散処理を用いた．並列分散処理では，入力

6. ま と め

データを分割・集約するためのコストなど，並列化によるコスト

本論文では，Hadoop から PostgreSQL へのデータロード高が発生する．測定の結果，0B の入力データを用いて Map-Only

速化を目的として，圧縮を利用したデータ転送ツールのプロト

Task の時間を測定し，起動コストが存在することが確認されタイプを設計・実装し，データ圧縮のロード時間短縮に対するた．データを増加させながら計測したとき，非圧縮がほぼ線形有効性を評価する実験と考察を行った．結果と考察から，以下に時間が増大するのに対し，圧縮を利用した場合は，1GB 以下の知見を得た．

で圧縮・伸長・転送時間の合計の大きな増大を示し，その後時間の伸びがゆるやかになり，逆転するという結果が得られた．
この結果から，圧縮・伸長等の処理にも起動コストが存在すると予測されるが，それを確認するためには，より詳細な分析が必要だと考えられる．
以上の考察をもとに，ロード時間の短縮に有効な圧縮形式を

(

1
1
+
NT Vc
Vd

•

データが小規模の場合は，並列化のコスト等が圧縮による利得を上回るため，圧縮を利用しないほうが良い．

)+ϵ式を立て，実測値と予測値の比較により，予測式を用いて有効性の判別ができることを確認した．
今後の展望として以下を検討していく．

B<1
S

予測式における各記号の定義を表 5 に示す．
表5

圧縮率と圧縮・伸長速度のバランスの良い圧縮の利用に

より，データ転送時間の短縮が可能．

また，圧縮のデータ転送時間短縮への有効性を予測する予測

予測する以下のような予測式を立てた．

T′
=r+B
T

•

•

圧縮形式選択のためのモデルの定義•

予測式によるおける並列化のコスト ϵ の分析•

性能の異なる実験環境を用いた場合のボトルネック分析

数式中の記号の定義

表記 説明

T

転送時間

T′

圧縮時の転送時間

r

圧縮率

B

ネットワーク帯域

NT

TaskTracker 数

Vc

圧縮速度

Vd

伸長速度

ϵ

並列化コスト文

この予測式が成り立つとき，圧縮を利用してデータ転送時間の短縮が可能と予測ができると考えた．
予測式の妥当性の確認のため，入力データサイズ 10GB，′

TaskTracker 数が 8 つのときの圧縮・非圧縮の転送時間比 TTの予測値と，実測値の比較を行った．なお，ネットワーク帯域と，並列化コストには実測最大値を用いた．結果を表 6 に示す．
表6′

圧縮・非圧縮の転送時間比 TT の予測値と実測値の比較 (ただし，

B = 100, NT = 8, ϵ = 7)
圧縮形式

圧縮率

圧縮 (MB/s)

伸長 (MB/s)

実測値

snappy

0.206

48.69

296.61

0.62

予測値

0.87

lzo

0.191

46.21

249.54

0.61

0.93

gzip

0.087

43.63

203.66

0.59

0.93

bzip2

0.036

3.66

40.65

5.07

5.97

表 6 の結果より，最適な圧縮形式の判別や速度改善の割合の予測には課題があるものの，今回使用した実験データに対して，圧縮の有効性を判別できることが確認された．

献[1] Apache sqoop. http://sqoop.apache.org/.
[2] Oracle loader for hadoop. http://www.oracle.com/
technetwork/database/database-technologies/
bdc/hadoop-loader/connectors-hdfs-wp-1674035.pdf.
[3] Pivotal greenplum database. http://www.gopivotal.com/
products/pivotal-greenplum-database.
[4] I. Alagiannis, R. Borovica, M. Branco, S. Idreos, and A. Ailamaki. Nodb: Eﬃcient query execution on raw data files. In
Proc. of the 2012 ACM SIGMOD International Conference
on Management of Data, SIGMOD ’12, pp. 241–252, New
York, NY, USA, 2012. ACM.
[5] K. Bajda-Pawlikowski, D. J. Abadi, A. Silberschatz, andE. Paulson. Eﬃcient processing of data warehousing queries
in a split execution environment. In Proc. of the 2011
ACM SIGMOD International Conference on Managementof Data, SIGMOD ’11, pp. 1165–1176, New York, NY, USA,2011. ACM.
[6] D. J. DeWitt, A. Halverson, R. Nehme, S. Shankar,
J. Aguilar-Saborit, A. Avanes, M. Flasza, and J. Gramling.
Split query processing in polybase. In Proc. of the 2013
ACM SIGMOD International Conference on Managementof Data, SIGMOD ’13, pp. 1255–1266, New York, NY, USA,
2013. ACM.
[7] T. Mühlbauer, W. Rödiger, R. Seilbeck, A. Reiser, A. Kemper, and T. Neumann. Instant loading for main memory
databases. Proc. VLDB Endow., 6(14):1702–1713, Sept.
2013.
[8] S. R. Ramakrishnan, G. Swart, and A. Urmanov. Balancing reducer skew in mapreduce workloads using progressive
sampling. In Proc. of the Third ACM Symposium on Cloud
Computing, SoCC ’12, pp. 16:1–16:14, New York, NY, USA,2012. ACM.
[9] Y. Xu, P. Kostamaa, and L. Gao. Integrating hadoop andparallel dbms. In Proc. of the 2010 ACM SIGMOD In-

ternational Conference on Management of Data, SIGMOD’10, pp. 969–974, New York, NY, USA, 2010. ACM.