第5回 システム系論文輪読会  Building  Efficient  Query  Engines  in  a  High-­‐Level  Language  

20150520  maropu@pfi  

本日紹介する論文

•  VLDB’14  Best  Paper  Awardsの受賞論文  

•  EPFL（スイス連邦工科大）とOracleの共同研究  •  EPFLはScalaのMarLn  Oderskyや、DBMSのHW 適化の研究

で有名なAnastasia  Ailamakiが所属  

hOp://www.vldb.org/2014/awards.html  

Outline

•  DBMSクエリエンジンの性能/生産性のトレードオフを解消  –  Abstrac(on  without  Regret  [21,  10,  11]の実現  –  高級言語（Scala）で開発しながら，C/C++で 適化したものに近い性

能を実現するデザインを再考  

•  LegoBase:  実行時 適化を活用して，クエリ処理モデルにおける抽象化の性能オーバヘッドを低減  –  クエリの中間表現（IR）の操作にScalaを活用することで，低級言語で

は難しい柔軟で幅広い 適化を実現  –  終的にCコード片に変換，clang/LLVMでコンパイルして実行  –  数100行のScala実装でHyper*を上回るTPC-­‐Hの性能  

*  VLDB’14  Early  Career  Awardの Thomas  Neumannが主導で開発，hOp://www.hyper-­‐db.com/

NoLce

•  PVLDB掲載後にEraOaが投稿，本発表は未反映  –  Errata  for  “Building  Efficient  Query  Engines  in  a  High-­‐Level  

Language”  (PVLDB  7(10):853-­‐864),  Proc.  of  VLDB,  Vol.  7,  No.  13,  2014  

What’s  Scala?

•  JVMベースで生産性向上を目的としたオブジェクト指向と関数型の特徴を兼ねた言語  

•  現在の 新版が2.11.6  –  hOp://www.scala-­‐lang.org/  

•  Apache  Spark*の開発言語として有名  

*  100x  faster  than  HadoopMR,  hOps://spark.apache.org/

性能/生産性のトレードオフ比較

実行時 適化  

実行時 適化

•  実行時情報（クエリやデータの統計情報）を用いてコード生成とコンパイルをRunLmeに行う手法の総称  

•  近年のDBMS研究で再燃，モダンなOSSでも積極的に活用  –  1981年のSystemR  [2]が先駆け  –  VLDB’13とICDE’14でチュートリアル*が連年で採択  

–  SQL処理系であるImplaやSpark  SQL，PostgreSQL用のGPUアクセラレータであるPG-­‐Strom  

•  既存手法:  Code  Templateを用いたコード生成  –  雛形用の文字列を用意して、後で実行時情報を埋め込む  

*  StraLs  D.  Viglas,  Just-­‐in-­‐Lme  compilaLon  for  SQL  query  processing        -­‐  VLDB’13,  hOp://www.vldb.org/2013/tutorials.html        -­‐  ICDE’14,  hOp://ieee-­‐icde2014.eecs.northwestern.edu/seminar.html

Code  TemplateのNaïveな例

//  Define  a  code  template  for  runLme  compilaLon  #define  CODE_TEMPLATE    “int  main()  {  prinr(\“%s\”);  return  0;  }”    //  Embed  runLme  info.  in  the  template  const  char  *p  =  “test”;  snprinr(buf,  sizeof(buf),  CODE_TEMPATE,  p);    //  Compile  and  invoke  it  …    

Impala/SparkSQLにおける実行時 適化

•  クエリの情報のみを用いたシンプルな 適化が多い  –  スキーマ情報や，述語関数の条件など  

•  Impala*1はLLVMを，SparkSQL*2はReflecLonを用いて実装  –  適用される代表的な部分は入力データのパース処理，述語・集約関

数，Expression木における四則演算など  

•  Impalaで2〜3倍程度の性能改善  –  hOp://blog.cloudera.com/blog/2013/02/inside-­‐cloudera-­‐impala-­‐

runLme-­‐code-­‐generaLon/  

 

*1  hOps://github.com/cloudera/Impala/tree/cdh5-­‐trunk/be/src/codegen  *2  hOps://github.com/apache/spark/tree/master/sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/codegen  

Impala/SparkSQLにおける実行時 適化

•  Project  Tungsten:  Bringing  Spark  Closer  to  Bare  Metal  –  SparkにおけるCPU 適化に関するプロジェクト  

 

hOps://databricks.com/blog/2015/04/28/project-­‐tungsten-­‐bringing-­‐spark-­‐closer-­‐to-­‐bare-­‐metal.htmlから引用  

PG-­‐Stromにおける実行時 適化

hOp://www.slideshare.net/kaigai/gpgpupostgresql/10から引用  

既存手法（Code  Template）の課題

•  1. 実装が複雑  

•  2.  オペレータ間を超えた 適化が不可能  –  集約（join）と結合（group-­‐by）の両方を考慮した冗長計算の削除など  

•  3.  実行時に得られる情報を含めた 適化が困難  –  タプル（行）選択率を用いたコード生成など  

•  4.  DBMS内の他コーポネントを含めた 適化が困難  –  木構造やハッシュ表を含めたinline化など  

既存手法の 適化の制約

•  インタープリタ的に動作する一般的なDBMSやCode  Templateを用いた手法では困難な 適化の例：  –  group-­‐byで集約される値における共通部分式除去  –  冗長な実体化（materializaLon）の除去  

実体化が２回行われるが実際には  １回で処理可能  

Fig.2  本研究が対象とする制約の具体例  

LegoBaseの概要

•  Scalaで記述されたin-­‐memoryで動作するクエリエンジン  –  hOps://github.com/epfldata/dblab  

•  DBMSが出力したプラン木からScalaのコード片を生成， 適化後にCのコード片に変換してコンパイル  

提案手法の範囲

Fig.3 処理フロー概要  

LegoBaseの概要

•  内部でLMS（Lightweight  Modular  Staging）を活用  –  EPFLで開発している組み込みコンパイル向けのScalaライブラリ  –  ユーザ定義の 適化ルールの追加が用意  –  Scala→Scala変換  

•  LegoBaseにおけるLMSの活用  –  適化ルールはLMS内で表された中間表現を書き換えることで実装  –  Scalaを入力として 適化されたCのコード片を生成  

hOp://www.slideshare.net/maropu0804/program-­‐generaLon-­‐and-­‐embedded-­‐compilers/7  

LegoBaseで定義した主な 適化ルール

•  1.  Inter-­‐Operator  OpLmizaLons  –  処理フローの切り替えと，冗長な計算の除去  

•  2.  Data  Structure  SpecializaLon  –  木やハッシュ表などのデータ構造の特殊化（specializaLon）  

•  3.  Changing  Data  Layout  –  タプル集合の行（NSM*1）から列モデル（DSM*2）の書き換え  

•  4.  Other  Compiler  OpLmizaLons  –  ループ融合（loop  fusion）や自動並列化/ベクトル化  

*1  N-­‐ary  Storage  Model  *2  DecomposiLon  Storage  Model  

1.  Inter-Operator  OpLmizaLons

•  コンパイラがpullからpushベースの処理フローに書き換え –  DBMSは古典的にpullベース（Iterator-­‐like）な処理モデル  –  キャッシュヒット率などのCPU効率が悪いことを先行研究 [15]が指摘  

接続されている子オペレータのiteraotr経由で  次のタプルを取得  

Fig.6  処理フローの変換例  

1.  Inter-Operator  OpLmizaLons

•  コンパイラがpullからpushベースの処理フローに書き換え –  DBMSは古典的にpullベース（Iterator-­‐like）な処理モデル  –  キャッシュヒット率などのCPU効率が悪いことを先行研究 [15]が指摘  

子ではなく親オペレータにタプルを  push-­‐upする処理に変更  

Fig.6  処理フローの変換例  

1.  Inter-Operator  OpLmizaLons

•  冗長的な実体化（materializaLon）の除去  –  Scalaのパタンマッチと再起処理で 適化を記述

オペレータがHashJoinだった場合に…  

実体化が必要な集約処理をHasjJoin#openに移譲  

Fig.6  集約と結合における冗長な実体化の除去の例  

2.  Data  Structure  SpecializaLon

–  クエリエンジン側の実装に手を入れずに，コンパイラ側で適化された実装に書き換え •  実行時情報（ハッシュ表のサイズなど）を用いて 適化  

・・・  Fig.7  ハッシュ表の特殊化の例  

ハッシュ表の生成をしている場合に，  適化された実装（closed  hashing）に置き換え  

3.  Changing  Data  Layout

•  コンパイラが行から列への変換コードを生成（Fig.  8）  •  参考:  “DSM  vs  NSM-­‐CPU  Performance  Tradeoffs  in  Block-­‐Oriented  Query  

Processing”,  Damon’08  

行モデル（デフォルト）   列モデル  

青で囲まれば部分がメモリ上の  連続領域に配置  

評価実験

•  評価条件  –  Intel  Xeon  E5-­‐2620v2  x2  –  256GB  of  DDR3  RAM  –  Scala  v2.10.3  –  Clang  for  LLVM  v2.9  

性能改善の評価

•  商用DBMS（DBX）からの性能改善の相対値  

Why  Scala→C  ?

•  Cに変換しない場合と比べて2.5xの性能差  –  Scalaというか，主にJVMが原因  

•  性能分析から以下３つが原因（perf）  –  分岐予測ミスが1.4x  –  LLC（Last-­‐Level  Cache）ミスが1.8x  –  実行命令数が5.5x  

実行時 適化におけるオーバヘッド

生産性の評価 コーディング日数   行数