カラム構造と圧縮によるHadoopからPostgreSQLへのロード高速化に関

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〜～24h
10TB〜～
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 usage
105.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
分割
伸⻑⾧長
圧縮
図3
もつ snappy，lzo，gzip，bzip2 の 4 形式を用いた．表 3 に，使
用したソフトウェアやライブラリのバージョンを示す．
プロトタイプの構成
（ 3 ） PostgreSQL ノード上で圧縮データを伸長する
3. 2 設
実験に使用した Hadoop クラスタおよび PostgreSQL サーバ
計
表 2 ハードウェア構成
項目
設定値
Hadoop クラスタ
9 台 (NameNode 1，DataNode 8)
PostgreSQL サーバ 1 台
プロトタイプを設計するうえで考慮した点について説明する．
CPU
Xeon 5160 (2C，3GHz，4MB L2)
Hadoop から RDBMS へのデータ転送時に圧縮，伸長を行う
Memory
DIMM 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
削減による転送時間の短縮が見込める一方で，圧縮・伸長に追
Hadoop
2.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)
snappy
0.206
48.69
296.61
lzo
0.191
46.21
249.54
gzip
0.087
43.63
203.66
bzip2
0.036
3.66
40.65
圧縮率の高い形式ほど転送時間が短く，圧縮・伸
長時間が長い．10GB 以上のデータサイズにおいて，snappy，
lzo，gzip の転送時間が非圧縮の場合よりも短い．
ここで，測定結果 4 から，1GB のデータサイズにおいて，圧
縮を行わない場合に最も短時間で転送が行えることが分かっ
た．そこで，0B から 10GB 小規模データを用いて，測定 4 に
ついて追加の測定を行い，性能の逆転について分析した．なお
0.4
bzip2 は逆転が発生しないため比較対象から除外している．
⾮非圧縮データ転送時間との⽐比率率率
0.35
結果を図 7 に示す．結果より，入力データサイズが 0B のと
0.3
0.25
snappy
0.2
lzo
0.15
gzip
0.1
の区間で性能の逆転が発生することがわかった．
bzip2
0
1
10
30
圧縮前データサイズ (GB)
200
50
150
図 4 圧縮データの転送時間
2076
⾮非圧縮
snappy
100
608
3550
1436
実⾏行行時間 (sec)
850
250
圧縮・データ転送・伸⻑⾧長時間の合計 (sec)
0.05
500
450
400
350
300
250
200
150
100
50
0
き，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
snappy
lzo
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 つで大きな差が見られなかったこ
測定結果 3
snappy，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 つのときの圧縮・非圧縮の転送時間比
T′
T
の予測値と，実測値の比較を行った．なお，ネットワーク帯域
と，並列化コストには実測最大値を用いた．結果を表 6 に示す．
表6
圧縮・非圧縮の転送時間比
T′
T
の予測値と実測値の比較 (ただし，
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, and
E. Paulson. Eﬃcient processing of data warehousing queries
in a split execution environment. In Proc. of the 2011
ACM SIGMOD International Conference on Management
of 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 Management
of Data, SIGMOD ’13, pp. 1255–1266, New York, NY, USA,
2013. ACM.
[7] T. M¨
uhlbauer, W. R¨
odiger, 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 and
parallel 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.

Download Report