Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Semelhante a 20150513 legobease
Semelhante a 20150513 legobease (20)
Mais de Takeshi Yamamuro
Mais de Takeshi Yamamuro (12)
Último
Último (10)
20150513 legobease
- 1. 第5回 システム系論文輪読会 Building Efficient Query Engines in a High-‐Level Language 20150520 maropu@pfi
- 2. 本日紹介する論文 • VLDB’14 Best Paper Awardsの受賞論文 • EPFL（スイス連邦工科大）とOracleの共同研究 • EPFLはScalaのMarLn Oderskyや、DBMSのHW最適化の研究 で有名なAnastasia Ailamakiが所属 hOp://www.vldb.org/2014/awards.html
- 3. 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/
- 4. 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
- 5. What’s Scala? • JVMベースで生産性向上を目的としたオブジェクト指向と関 数型の特徴を兼ねた言語 • 現在の最新版が2.11.6 – hOp://www.scala-‐lang.org/ • Apache Spark*の開発言語として有名 * 100x faster than HadoopMR, hOps://spark.apache.org/
- 7. 実行時最適化 • 実行時情報（クエリやデータの統計情報）を用いてコード生 成とコンパイルを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
- 8. 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 …
- 9. 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
- 10. 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から引用
- 12. 既存手法（Code Template）の課題 • 1. 実装が複雑 • 2. オペレータ間を超えた最適化が不可能 – 集約（join）と結合（group-‐by）の両方を考慮した冗長計算の削除など • 3. 実行時に得られる情報を含めた最適化が困難 – タプル（行）選択率を用いたコード生成など • 4. DBMS内の他コーポネントを含めた最適化が困難 – 木構造やハッシュ表を含めたinline化など
- 13. 既存手法の最適化の制約 • インタープリタ的に動作する一般的なDBMSやCode Template を用いた手法では困難な最適化の例： – group-‐byで集約される値における共通部分式除去 – 冗長な実体化（materializaLon）の除去 実体化が２回行われるが実際には １回で処理可能 Fig.2 本研究が対象とする制約の具体例
- 14. LegoBaseの概要 • Scalaで記述されたin-‐memoryで動作するクエリエンジン – hOps://github.com/epfldata/dblab • DBMSが出力したプラン木からScalaのコード片を生成，最適 化後にCのコード片に変換してコンパイル 提案手法の範囲 Fig.3 処理フロー概要
- 15. LegoBaseの概要 • 内部でLMS（Lightweight Modular Staging）を活用 – EPFLで開発している組み込みコンパイル向けのScalaライブラリ – ユーザ定義の最適化ルールの追加が用意 – Scala→Scala変換 • LegoBaseにおけるLMSの活用 – 最適化ルールはLMS内で表された中間表現を書き換えることで実装 – Scalaを入力として最適化されたCのコード片を生成
- 17. 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
- 18. 1. Inter-Operator OpLmizaLons • コンパイラがpullからpushベースの処理フローに書き換え – DBMSは古典的にpullベース（Iterator-‐like）な処理モデル – キャッシュヒット率などのCPU効率が悪いことを先行研究 [15]が指摘 接続されている子オペレータのiteraotr経由で 次のタプルを取得 Fig.6 処理フローの変換例
- 19. 1. Inter-Operator OpLmizaLons • コンパイラがpullからpushベースの処理フローに書き換え – DBMSは古典的にpullベース（Iterator-‐like）な処理モデル – キャッシュヒット率などのCPU効率が悪いことを先行研究 [15]が指摘 子ではなく親オペレータにタプルを push-‐upする処理に変更 Fig.6 処理フローの変換例
- 20. 1. Inter-Operator OpLmizaLons • 冗長的な実体化（materializaLon）の除去 – Scalaのパタンマッチと再起処理で最適化を記述 オペレータがHashJoinだった場合に… 実体化が必要な集約処理をHasjJoin#openに移譲 Fig.6 集約と結合における冗長な実体化の除去の例
- 21. 2. Data Structure SpecializaLon – クエリエンジン側の実装に手を入れずに，コンパイラ側で最 適化された実装に書き換え • 実行時情報（ハッシュ表のサイズなど）を用いて最適化 ・・・ Fig.7 ハッシュ表の特殊化の例 ハッシュ表の生成をしている場合に， 最適化された実装（closed hashing）に置き換え
- 22. 3. Changing Data Layout • コンパイラが行から列への変換コードを生成（Fig. 8） • 参考: “DSM vs NSM-‐CPU Performance Tradeoffs in Block-‐Oriented Query Processing”, Damon’08 行モデル（デフォルト） 列モデル 青で囲まれば部分がメモリ上の 連続領域に配置
- 23. 評価実験 • 評価条件 – Intel Xeon E5-‐2620v2 x2 – 256GB of DDR3 RAM – Scala v2.10.3 – Clang for LLVM v2.9
- 25. Why Scala→C ? • Cに変換しない場合と比べて2.5xの性能差 – Scalaというか，主にJVMが原因 • 性能分析から以下３つが原因（perf） – 分岐予測ミスが1.4x – LLC（Last-‐Level Cache）ミスが1.8x – 実行命令数が5.5x
- 26. 実行時最適化におけるオーバヘッド