Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Asakusa FrameworkとScalaの密かな関係
Ähnlich wie Asakusa FrameworkとScalaの密かな関係 (20)
Asakusa FrameworkとScalaの密かな関係
- 4. 4 （⾃自分と）各プロダクトの年年表 時期 出来事 2004年 Scala公開 2006年 Apache Hadoop・Java6リリース 2010年 2月 （Hadoop・HBaseを知る） 2010年 初頭 Spark〔OSS化〕 2010年 ８月 （Scalaを知る） 2011年 3月末 Asakusa Framework公開 2011年 7月 （Sparkを知る） 2012年 2月 （SIerから転職） 2012年 8月 DQ10発売 2014年 2月 Apache Spark〔トップレベル昇格〕 2014年 3月 Java8リリース
- 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を始めた
- 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 Scalaを知った経緯 1. HBaseのサンプルをScalaで書いている⼈人がい た – Better Java的なソースだったが、Scala便便利利！とい う印象を持った import⽂文の別名定義 2. Scalaの勉強を始めた – ScalaのSeq等のコレクションのメソッド⼀一覧を 作ってみたら、数が多くて泣きそうになったorz
- 9. 9 Asakusa Frameworkを知った経緯 1. Hadoop関連の情報をウォッチしていた – Hadoop（MapReduce）を隠蔽するフレームワー クは他にもある Hive（対話型） Pig（対話型） Cascading Huahin Framework（AsakusaFWより後） AZAREA Cluster（AsakusaFWより後） – AsakusaFWはバッチを分散処理理するフレームワー クである（⾃自分の興味はバッチを速くすること）
- 10. 10 Sparkを知った経緯 1. Hadoop以外の分散処理理の話題もウォッチして いた – SparkはScalaで書ける分散処理理フレームワークと いうことで特に注⽬目 – 当初は実⾏行行環境にMesosが必要だったので実際には 試さなかった – 今はSparkはHadoop界隈で話題
- 12. 12 Scala 省省略略！
- 14. 14 Apache Hadoop（2/3） DBサーバー データ バッチサーバー app サーバー データ app Hadoopクラスター 従来型バッチ Hadoopバッチ アプリケーションのある場所に データを転送する。 サーバー データ app サーバー データ app データのある場所に アプリケーションを転送する。
- 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 Scala MyOperatorの例例 class MyOperator { def f(data: Data) : Boolean = data.getValue() % 2 == 0 def m(data: Data) : Data = Data(data.getValue() + 1) }
- 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で表現してみる
- 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 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 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 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 類似点まとめ 処理理がDAG（有向⾮非循環グラフ）で表せる – ワンライナーで記述したものは、DAGでは⼀一直線にな る s0 filter f map m out1 s0 @Branch f @Update m out1
- 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 相違点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 相違点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 相違点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 相違点2：複製 同じデータを複数箇所で使⽤用（duplicate） s0 処理2 out2 処理1 out1
- 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;
- 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 【余談】AsakusaバッチのDAGの例例 あるバッチのDAG（の⼀一部（のイメージ）） ノード 一覧 下位 コスト @Convert 変換 上位 コスト コスト @CoGroup 配賦率算出 @Summarize 操業度集計 @CoGroup 配賦 @MJoinUpdate 操業度更新 操業度 1バッチの中に このフローが 25×2個くらい @MJoinUpdate 操業度更新 予定 操業度
- 39. 39 使途（規模）の違い 種類 使用目的 Java8 Stream API 処理を内部イテレーターで書ける。 （List等のコレクションはStreamに変換する必要がある） 並列Streamでマルチスレッド処理が可能。 Scalaのコレク ション コレクションの処理を内部イテレーターで書ける。 並列コレクション（.par）でマルチスレッド処理が可能。 Spark （Scala本体と似たコーディングで）複数マシンで分散する処 理を書ける。（いわばマルチプロセス） バッチとStreamingを同一に扱える。 AsakusaFW 分散処理するバッチアプリケーションを書く。 （実行基盤としてHadoopやSpark・M3BPを利用する） テスト機構あり。 マルチスレッド・複数マシン分散 → 扱うデータ量の違い マルチスレッド処理と言っても、数十万件といったデータでないとメリットが無い。データ量 が多いと、どうやって読み込むかという問題が出る。数千万〜億件ともなれば、データ自体 を分散し、それぞれを処理する方が効率が良い→Hadoop, Spark
- 40. 40 AsakusaFWの仕組み
- 41. 41 Asakusa Frameworkのコンセプト 分散処理理するバッチアプリケーションを作成す る為のフレームワーク 1. 当初は実⾏行行基盤としてHadoopを使⽤用 ⼀一つのアプリケーションから複数のHadoopジョブを⽣生 成し、連携して実⾏行行 2. 少量量データを扱う際のオーバーヘッドが⼤大きすぎた ので、スモールジョブ実⾏行行エンジンを実装 単体テストの実⾏行行環境としても使⽤用可能 3. 今では実⾏行行基盤としてSparkやM3BPを使⽤用可能 マルチプラットフォームは難しいので、すごい（Scala もJavaと.NETをサポートしていたが、今はJavaのみ）
- 42. 42 M3 for Batch Processing（M3BP） 単⼀一ノードでの処理理に特化したフレームワーク – https://github.com/fixstars/m3bp – OSネイティブのスレッドを使ったマルチスレッド – 完全にオンメモリー メモリーに乗り切切らなかったら潔く落落ちる （Sparkなら⼀一応スピルアウトする。また、シャッフル 処理理後にファイル出⼒力力する） – （単⼀一ノードなので）複数サーバー間のハートビート 確認等は無い CPU数⼗十コア・メモリー数百GBのマシンを想定
- 43. 43 【余談】ビッグデータ 1台のサーバーに収まらない規模のデータ – 1台に収まらないので分散処理理する必要がある コモディティーサーバーのスペック – 2010年年頃（『Hadoopのコモディティはローエンドという意味ではない』 http://shiumachi.hatenablog.com/entry/20100703/1278133318） CPU 8〜～16コア、メモリー 16〜～32GB、ディスク 4〜～ 24TB – 現在（『「ビッグデータプロジェクト」の進め⽅方（１）』 http://www.atmarkit.co.jp/ait/articles/1608/22/news027.html） CPU 20コア、メモリー 256GB、ディスク 36TB 100GBのデータは、今はメモリーに乗る
- 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 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 サーバーのスペック 台数 CPU数 メモリー量 クラスター ・Hadoop（MapR） ・Spark 13 合計128 合計750GB M3BP 1 88 512GB l このM3BPバッチの入出力先はHadoopクラスター。 （こうしておくと、Spark版バッチの入出力と同じになるので、切り替えやすい） （M3BP自身はローカルディスクを対象とすることも可） l M3BP 1バッチで８８プロセッサー使うより、22の方が速いことがある。 （88にして速くなっても1.1〜1.2倍くらい）
- 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 まとめ
- 53. 53 まとめ Apache Spark – Scalaの延⻑⾧長上のコーディングが出来る。 バッチとStreaming（リアルタイムっぽい処理理）を同じクラ スを使って記述することが出来る。 – Hadoop界隈でもMapReduceの次として注⽬目されている。 Asakusa Framework – バッチアプリケーションを記述する為のフレームワーク リコンパイルだけで実⾏行行基盤を切切り替えられる。 将来 有望な基盤が出れば、それに対応する可能性がある。 – ScalaがSIerに普及すればAsakusa Scala DSLも来る？！ DQ10フレンド募集中 – DQ10 ver3.4 2016/10/6開始