Asakusa FrameworkとScalaの密かな関係

1,061 views

Published on

Scala関西Summit 2016

Published in: Software
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,061
On SlideShare
0
From Embeds
0
Number of Embeds
62
Actions
Shares
0
Downloads
6
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Asakusa FrameworkとScalaの密かな関係

  1. 1. 2016/10/8 ひしだま Asakusa  FrameworkとScalaの密かな関係 Scala関⻄西Summit  2016
  2. 2. 2 ⽬目次 1. ⾃自⼰己紹介 –  ⾃自分がScalaやAsakusaFWを知った経緯 2. Scala・Spark・AsakusaFWの概要 3. Scala・Spark・AsakusaFWの⽐比較 4. AsakusaFWの仕組み 5. まとめ
  3. 3. 3 ⾃自⼰己紹介  ひしだま  Twitter  ID:@hishidama  ホームページ – 灰⾊色なことが特徴 – http://hiroba.dqx.jp/sc/character/ 1091135261820/  最近の仕事 – AsakusaFWを使ったアプリケーション作成 – DQ10:僧侶・⽊木⼯工職⼈人
  4. 4. 4 (⾃自分と)各プロダクトの年年表 時期 出来事 2004年 Scala公開 2006年 Apache Hadoop・Java6リリース 2010年 2月 (Hadoop・HBaseを知る) 2010年 初頭 Spark〔OSS化〕 2010年 8月 (Scalaを知る) 2011年 3月末 Asakusa Framework公開 2011年 7月 (Sparkを知る) 2012年 2月 (SIerから転職) 2012年 8月 DQ10発売 2014年 2月 Apache Spark〔トップレベル昇格〕 2014年 3月 Java8リリース
  5. 5. 5 Hadoopを知った経緯 1.  営業の⼈人から「はどぅーぷって知ってる?」 2.  知らないので調べてみた l  『Hadoopで、かんたん分散処理理』 http://techblog.yahoo.co.jp/architecture/ hadoop/   6時間6分35秒  →  5分34秒(約70倍) l  ⾃自分が当時担当していた夜間バッチ   8時間  →  要求:3時間(約3倍) 3.  Hadoopの勉強会というものがあるらしい l  参加する為にTwitterを始めた
  6. 6. 6 HBaseを知った経緯 1.  Hadoop上で動くNoSQLとしてHBaseを知っ た –  RDBの代わりとしてHBaseを使⽤用し、 HBaseを⼊入⼒力力としてHadoopでバッチ処理理を⾏行行う のが良良いのではないかと考えた
  7. 7. 7 【余談】NoSQL  NoSQL(今ではNot  Only  SQLの略略) – SQL(≒RDBの象徴)でないDB – 分散DB(ビッグデータブームのもう⼀一⽅方の⽴立立役者)  CAP定理理 – C:⼀一貫性(consistency) – A:可⽤用性(availability) – P:分断耐性(partition  tolerance) – CA型NoSQLとCP型NoSQL  →  CAの勝ち
  8. 8. 8 Scalaを知った経緯 1.  HBaseのサンプルをScalaで書いている⼈人がい た –  Better  Java的なソースだったが、Scala便便利利!とい う印象を持った   import⽂文の別名定義 2.  Scalaの勉強を始めた –  ScalaのSeq等のコレクションのメソッド⼀一覧を 作ってみたら、数が多くて泣きそうになったorz
  9. 9. 9 Asakusa  Frameworkを知った経緯 1.  Hadoop関連の情報をウォッチしていた –  Hadoop(MapReduce)を隠蔽するフレームワー クは他にもある   Hive(対話型)   Pig(対話型)   Cascading   Huahin  Framework(AsakusaFWより後)   AZAREA  Cluster(AsakusaFWより後) –  AsakusaFWはバッチを分散処理理するフレームワー クである(⾃自分の興味はバッチを速くすること)
  10. 10. 10 Sparkを知った経緯 1.  Hadoop以外の分散処理理の話題もウォッチして いた –  SparkはScalaで書ける分散処理理フレームワークと いうことで特に注⽬目 –  当初は実⾏行行環境にMesosが必要だったので実際には 試さなかった –  今はSparkはHadoop界隈で話題
  11. 11. 11 Scala・Spark・AsakusaFWの 概要 今回の話題に関連するプロダクト
  12. 12. 12 Scala  省省略略!
  13. 13. 13 Apache  Hadoop(1/3)  分散処理理フレームワーク l HDFS(分散ファイルシステム) l MapReduce(処理理⽅方式・アルゴリズム) l YARN(リソース管理理) 1. データを複数のマシン上に分散して配置する 2. MapReduceアプリケーション(jarファイル) を各マシンに転送して分散処理理する
  14. 14. 14 Apache  Hadoop(2/3) DBサーバー データ バッチサーバー app サーバー データ app Hadoopクラスター 従来型バッチ Hadoopバッチ アプリケーションのある場所に データを転送する。 サーバー データ app サーバー データ app データのある場所に アプリケーションを転送する。
  15. 15. 15 Apache  Hadoop(3/3)  Hadoopの功績 l  「ビッグデータ」はバズワード化したが、⽴立立役者で あるHadoopは分散処理理を⾝身近にした。  Hadoopの弱点 l MapReduceはシンプルだが、コーディングし づらい。 l 常にファイルを読み書きするというシンプルな 構成なので、メモリーにデータをキャッシュし て使い回すようなことが出来ない。 機械学習とかで 欲しいらしい?
  16. 16. 16 Apache  Spark  分散処理理フレームワーク l RDDを使ったコーディング(Scala) l データをメモリー上にキャッシュして使い回す ことが出来る。 l 分散ファイル⼊入出⼒力力にはHDFSを利利⽤用する。  カリフォルニア⼤大学バークレイ校のAMPLabで 開発され、現在はDatabricksがサポート l https://databricks.com/spark/about l 参考⽂文献:『Apache  Spark⼊入⾨門』
  17. 17. 17 Asakusa  Framework  分散処理理するバッチアプリケーションを作成・ 実⾏行行する為のフレームワーク l Javaをホスト⾔言語とするDSLで記述 l 実⾏行行基盤としてHadoopやSparkやM3BPを使 ⽤用  ノーチラステクノロジーズが開発・サポート l  http://www.asakusafw.com/
  18. 18. 18 Scala・Spark・AsakusaFWの ⽐比較
  19. 19. 19 Scala  例例 val operator = new MyOperator val s0 : Stream[Data] = 初期データ val s1 = s0.filter(operator.f) val s2 = s1.map(operator.m) val out1 = s2.toSeq
  20. 20. 20 Scala  MyOperatorの例例 class MyOperator { def f(data: Data) : Boolean = data.getValue() % 2 == 0 def m(data: Data) : Data = Data(data.getValue() + 1) }
  21. 21. 21 Scala  例例 val operator = new MyOperator val s0 : Stream[Data] = 初期データ val s1 = s0.filter(operator.f) val s2 = s1.map(operator.m) val out1 = s2.toSeq これをDAGで表現してみる
  22. 22. 22 【余談】DAG(1/2)  グラフ理理論論 l ノード(頂点)とエッジ(線)で表される図(グラ フ) •  電⾞車車やバスの路路線図 •  ER図 •  フローチャート
  23. 23. 23 【余談】DAG(2/2)  有向⾮非循環グラフ(Directed  Acyclic  Graph) l 向きが有る l 閉路路(循環)が無い 向きが無い 循環が有る 向きが有る 循環が有る 向きが有る 循環が無い
  24. 24. 24 Scala  例例 val operator = new MyOperator val s0 : Stream[Data] = 初期データ val s1 = s0.filter(operator.f) val s2 = s1.map(operator.m) val out1 = s2.toSeq s0 filter f map m out1
  25. 25. 25 Apache  Spark  例例 val sc = new SparkContext(…) val operator = new MyOperator val s0 : RDD[Data] = sc.初期データ val s1 = s0.filter(operator.f) val s2 = s1.map(operator.m) s2.saveAsTextFile(”out1”) ※MyOperatorは通常のScalaと全く同じ s0 filter f map m out1
  26. 26. 26 Asakusa  Framework  フローの例例(概要) In<Data> s0 = 入力元; //ファイル Out<Data> out1 = 出力先; //ファイル MyOperatorFactory operator = new MyOperatorFactory(); Source<Data> s1 = operator.f(s0).out; Source<Data> s2 = operator.m(s1).out; out1.add(s2); s0 @Branch f @Update m out1
  27. 27. 27 Asakusa  Framework  MyOperatorFactoryの例例 public abstract class MyOperator { @Branch public Filter f(Data data) { return (data.getValue() % 2 == 0) ? Filter.OUT : Filter.MISSED; } @Update public void m(Data data) { data.setValue(data.getValue() + 1); } } コンパイルすると MyOperatorFactory が生成される
  28. 28. 28 類似点まとめ  処理理がDAG(有向⾮非循環グラフ)で表せる – ワンライナーで記述したものは、DAGでは⼀一直線にな る s0 filter f map m out1 s0 @Branch f @Update m out1
  29. 29. 29 相違点1:複数⼊入⼒力力  合流流(union)  結合(join)  zip s0 処理 out1 s1
  30. 30. 30 相違点1:複数⼊入⼒力力(合流流) 種類 合流(union) Java8 Stream API Stream<Data> out = Stream.concat(Stream.concat(s0, s1), s2); Scala Spark val out = s0 ++ s1 ++ s2 AsakusaFW Source<Data> out = core.confluent(s0, s1, s2); 1,abc 2,def 1,foo 3,bar 合流 1,abc 2,def 1,foo 3,bar
  31. 31. 31 相違点1:複数⼊入⼒力力(結合) 種類 結合(join) Java8 Stream API × Scala × Spark val out = s0.join(s1) AsakusaFW Source<Joined> out = operator.join(s0, s1).joined; // @MasterJoin 1,abc 2,def 1,foo 3,bar 結合 1,abc,foo
  32. 32. 32 相違点1:複数⼊入⼒力力(結合) 種類 結合(cogroup) Java8 Stream API × Scala × Spark val out = s0.cogroup(s1) AsakusaFW Source<Joined> out = operator.group(s0, s1).out; // @CoGroup 1,abc 2,def 1,foo 3,bar 結合 2,def,null 1,abc,foo 3,null,bar
  33. 33. 33 相違点1:複数⼊入⼒力力(zip) 種類 zip Java8 Stream API × Scala Spark val out = s0.zip(s1) AsakusaFW × 1,abc 2,def 1,foo 3,bar zip 2,def,3,bar 1,abc,1,foo
  34. 34. 34 相違点2:複製  同じデータを複数箇所で使⽤用(duplicate) s0 処理2 out2 処理1 out1
  35. 35. 35 相違点2:複製(duplicate) 種類 複数箇所使用(duplicate) Java8 Stream API × Scala (TraversableOnce以外であればSparkと同じ) Spark val out1 = s0.map(operator.m1) val out2 = s0.map(operator.m2) AsakusaFW Source<Data> out1 = operator.m1(s0).out; Source<Data> out2 = operator.m2(s0).out;
  36. 36. 36 相違点3:複数出⼒力力  分岐(branch) s0 out2 分岐 out1
  37. 37. 37 相違点3:複数出⼒力力(分岐) 種類 分岐(branch) Java8 Stream API × Scala Spark ×(filterでは、条件に合致したものとしなかったものを同時に 出力することは出来ない) AsakusaFW // @Branch Branch result = operator.branch(s0); Source<Data> out1 = result.out1; Source<Data> out2 = result.out2; Source<Data> out3 = result.out3;
  38. 38. 38 【余談】AsakusaバッチのDAGの例例  あるバッチのDAG(の⼀一部(のイメージ)) ノード 一覧 下位 コスト @Convert 変換 上位 コスト コスト @CoGroup 配賦率算出 @Summarize 操業度集計 @CoGroup 配賦 @MJoinUpdate 操業度更新 操業度 1バッチの中に このフローが 25×2個くらい @MJoinUpdate 操業度更新 予定 操業度
  39. 39. 39 使途(規模)の違い 種類 使用目的 Java8 Stream API 処理を内部イテレーターで書ける。 (List等のコレクションはStreamに変換する必要がある) 並列Streamでマルチスレッド処理が可能。 Scalaのコレク ション コレクションの処理を内部イテレーターで書ける。 並列コレクション(.par)でマルチスレッド処理が可能。 Spark (Scala本体と似たコーディングで)複数マシンで分散する処 理を書ける。(いわばマルチプロセス) バッチとStreamingを同一に扱える。 AsakusaFW 分散処理するバッチアプリケーションを書く。 (実行基盤としてHadoopやSpark・M3BPを利用する) テスト機構あり。 マルチスレッド・複数マシン分散 → 扱うデータ量の違い マルチスレッド処理と言っても、数十万件といったデータでないとメリットが無い。データ量 が多いと、どうやって読み込むかという問題が出る。数千万〜億件ともなれば、データ自体 を分散し、それぞれを処理する方が効率が良い→Hadoop, Spark
  40. 40. 40 AsakusaFWの仕組み
  41. 41. 41 Asakusa  Frameworkのコンセプト  分散処理理するバッチアプリケーションを作成す る為のフレームワーク 1.  当初は実⾏行行基盤としてHadoopを使⽤用  ⼀一つのアプリケーションから複数のHadoopジョブを⽣生 成し、連携して実⾏行行 2.  少量量データを扱う際のオーバーヘッドが⼤大きすぎた ので、スモールジョブ実⾏行行エンジンを実装  単体テストの実⾏行行環境としても使⽤用可能 3.  今では実⾏行行基盤としてSparkやM3BPを使⽤用可能  マルチプラットフォームは難しいので、すごい(Scala もJavaと.NETをサポートしていたが、今はJavaのみ)
  42. 42. 42 M3  for  Batch  Processing(M3BP)  単⼀一ノードでの処理理に特化したフレームワーク – https://github.com/fixstars/m3bp – OSネイティブのスレッドを使ったマルチスレッド – 完全にオンメモリー  メモリーに乗り切切らなかったら潔く落落ちる (Sparkなら⼀一応スピルアウトする。また、シャッフル 処理理後にファイル出⼒力力する) – (単⼀一ノードなので)複数サーバー間のハートビート 確認等は無い  CPU数⼗十コア・メモリー数百GBのマシンを想定
  43. 43. 43 【余談】ビッグデータ  1台のサーバーに収まらない規模のデータ – 1台に収まらないので分散処理理する必要がある  コモディティーサーバーのスペック – 2010年年頃(『Hadoopのコモディティはローエンドという意味ではない』 http://shiumachi.hatenablog.com/entry/20100703/1278133318)  CPU  8〜~16コア、メモリー  16〜~32GB、ディスク  4〜~ 24TB – 現在(『「ビッグデータプロジェクト」の進め⽅方(1)』 http://www.atmarkit.co.jp/ait/articles/1608/22/news027.html)    CPU  20コア、メモリー  256GB、ディスク  36TB  100GBのデータは、今はメモリーに乗る
  44. 44. 44 Asakusa  Frameworkの実⾏行行基盤  AsakusaFWで作ったアプリケーションは、コン パイルすることで実⾏行行バイナリー(jarファイル 等)を⽣生成する。 – Hadoop環境⽤用であれば、MapReduceアプリケー ションが⽣生成される。  Spark版・M3BP版実⾏行行バイナリーは、アプリ ケーションをリコンパイルするだけで⽣生成可能。  今後も有望な実⾏行行基盤が出てくれば、それもサ ポートされる可能性がある。 – 基本的にリコンパイルだけで使える(よう考慮される はず)
  45. 45. 45 実⾏行行基盤ごとのコンパイル⽅方法 Asakusa on MapReduce Asakusa on Spark Asakusa on M3BP 使用コンパイラー javac javac javac CMake gcc/g++ 生成するファイル MapReduceの javaソースを生成 してコンパイルする Spark部分には ASMを使って直接 classファイルを生 成する (scalacは使用し ない) 実行サーバー用の ネイティブライブラ リーが必要となる ので、C++ソース を生成してクロスコ ンパイルする 備考 スモールジョブ実 行エンジンは、実 行時の入力データ 量に応じて自動的 に使われる ソースが無いので、 例外発生時にス タックトレースが出 ても調査しづらい ネイティブなので、 実行時のデータ量 によってはSEGV が起きることがある
  46. 46. 46 Asakusaバッチの実⾏行行時間の例例 Asakusa on MapReduce Asakusa on Spark Asakusa on M3BP 抽出・結合(標準的なバッチ) (入力約1.2GB・561万件) (出力約60MB・69万件) 約110秒 約85秒 8秒弱 抽出・結合(最小バッチ) (入力約29kB・900件) (出力約280B・1件) 約15秒 約60秒 3秒弱 集計 (入力約11GB・2億1700万件) (出力約940MB・783万件) 約380秒 約700秒 約260秒 データ量が増えるバッチ (入力約74MB・53万件) (出力約81GB・1084万件) 約3400秒 約2030秒 約400秒 (メモリ256〜 270GB使用) 色々やってるバッチ (入力約76GB・2420万件) (出力約153MB・89万件) 約670秒 約360秒 約92秒
  47. 47. 47 サーバーのスペック 台数 CPU数 メモリー量 クラスター ・Hadoop(MapR) ・Spark 13 合計128 合計750GB M3BP 1 88 512GB l  このM3BPバッチの入出力先はHadoopクラスター。 (こうしておくと、Spark版バッチの入出力と同じになるので、切り替えやすい) (M3BP自身はローカルディスクを対象とすることも可) l  M3BP 1バッチで88プロセッサー使うより、22の方が速いことがある。 (88にして速くなっても1.1〜1.2倍くらい)
  48. 48. 48 Asakusa  Frameworkを使うべき理理由  分散処理理するバッチアプリケーションを作成す る為のフレームワーク – そもそも、分散処理理する必要がある=処理理対象データ が⼤大量量(実⾏行行時間が⻑⾧長い)  実⾏行行時間が⻑⾧長いなら、ジョブ起動にオーバーヘッドが あっても許容できる – 実⾏行行環境にM3BPを使⽤用することで、⼩小さいデータで も速くなった(リコンパイルのみで移⾏行行できる) – ⼊入⼒力力データサイズに依らず、バッチならAsakusaFW を使えばいいんじゃない?(※個⼈人の感想です)  ファイルの結合が必要なバッチ処理理はすごく書きやすい
  49. 49. 49 ハードウェアの技術動向(1/2)  ハードウェアが変われば、それに最適なソフト ウェアは変わる – 例例えば、Hadoop1はHDDを念念頭においた作りになっ ている。  ある程度度⼤大きなサイズのブロックアクセス (HDDはシーケンシャルアクセスの⽅方が効率率率が良良い) なので、ハードウェアの動向も 多少は気にするといいかも
  50. 50. 50 ハードウェアの技術動向(2/2)  ディスク – SSD(⼤大容量量化。2020年年には100TB?)  CPU – クロック数は頭打ち(ムーアの法則の終焉) – メニーコア化(100コア超)→Asakusa  on  M3BP  RSA(ラックスケールアーキテクチャー) – ラック内の複数サーバーのCPU・メモリーが1つの サーバーのように扱える(メモリーが10TB超)  メモリー – 不不揮発性メモリー(フラッシュメモリー、MRAM等)
  51. 51. 51 Asakusa  DSLのホスト⾔言語 1.  AsakusaFWでは、Asakusa  DSL(Javaをホ スト⾔言語とする内部DSL)でアプリケーショ ンを記述する。 2.  内部DSLのホスト⾔言語と⾔言えばScalaでは? 3.  Asakusa  DSLのホスト⾔言語をScalaとする案 もあったらしい。 –  AsakusaFWを主に使うのはSIerという想定なので、 SIerで⼀一番使われているJavaが採⽤用された。 –  Asakusa  Scala  DSLも検討されたことがある。   『Asakusa  Scala  DSLデザインレビューの勉強会』 https://atnd.org/events/13174
  52. 52. 52 まとめ
  53. 53. 53 まとめ  Apache  Spark – Scalaの延⻑⾧長上のコーディングが出来る。  バッチとStreaming(リアルタイムっぽい処理理)を同じクラ スを使って記述することが出来る。 – Hadoop界隈でもMapReduceの次として注⽬目されている。  Asakusa  Framework – バッチアプリケーションを記述する為のフレームワーク  リコンパイルだけで実⾏行行基盤を切切り替えられる。  将来  有望な基盤が出れば、それに対応する可能性がある。 – ScalaがSIerに普及すればAsakusa  Scala  DSLも来る?!  DQ10フレンド募集中 – DQ10  ver3.4  2016/10/6開始

×