Elixir Flow / Scala Akka / C# / Goを使った大量CSVの比較。C#版は後日PRを頂き動作を確認。 2018/8/17 カバーデザイン差し替え

1. 並列対決 Elixir × Go × C#
x Scala オマケでnode.js
Created by Enpedasi/twinbee ( [@enpedasi] )
2018/2/23
2018/2/25 Scala [@KugiyaJ]版 追加
powered by Marp

2. ⾃⼰紹介
@enpedasi (えんぺだーし）
qiita : twinbee
フリーランスエンジニア
中２の時にZAT SOFT/⼤名マイコン学院より
MZ-700向けゲームレフュージー発売
BGM : Lo hiphopがお気に⼊り

3. 概要
Elixir速いっていうけど、実際どうなの︖
Go/Scala Akka等 並列に強い処理系の中での優位点
は︖
オープン系ばかり話題になるけど、Microsoftを⾒
てみぬふりはダメだよね︖
初⾒でどこまで並⾏プログラミングができる︖

4. ストリーム集計対決
巨⼤CSVファイルを並列集計
各⾔語のストリームを使⽤
ストリームを制するものは、サービスを制する

5. - 登壇者のレベル
⾔語 経 験
node.js 納品実績あり
C# 納品実績あり/⾮同期開発経験なし
Elixir 3年間Watch
Scala
ハンズオンでWebアプリ作った
(Play/Skinny)
Go 経験なし
ここから作っていくよ︕
※ ⼀応 C / C++ / アセンブラ 10年以上 Delphi 20年経験は
あります

6. 基礎⽤語の確認

7. 並⾏・並列
並⾏処理 (Concurrent)
CPU数・コア数の限界を超えて複数の仕事を同時
に⾏うこと。 シングルスレッドでも該当する。
並列処理 (Pallarel)
複数のプロセッサやコアを使って、仕事を同時に
⾏うこと。
参考 ASCII倶楽部 Go⾔語と並列処理

8. ノンブロッキング・⾮同期
nginxやnode.jsが話題になった時代のテーマ
ノンブロッキング
にくじゃがをつっつきながら完成を確かめる。
つっつきながら別の料理を捌ける。
⾮同期
電⼦レンジに⼊れてチンと鳴るのを待つ。その間
別の料理に取り掛かる。
厳密に定義を追ってもしょうがないので、並⾏・
並列と区別がつけばOK

9. ストリーム
⽂字・画像・動画などが延々と流れていくイメー
ジ。始まりと終わりがない。
ストリームは加⼯部分のみを読み取り、処理する
ので最低限のメモリしか使わない。

10. ストリーム 問題点
サービスをストリームの加⼯機としてとらえる
と、⼊⼒をある⼤きさでぶった切って処理する必
要がある（時間やサイズ）。
ぶった切られたデータは、IOデバイスの都合で切
られるので、加⼯しやすい型（⾏・画像）に持っ
ていくには⼿間が必⽤
流れ待ってくれないので、バッファリングや再送
指⽰が必⽤ ⇒ 処理が複雑化

11. マルチタスクモデルとGC
Elixir Go C# Scala(JVM)
モデ
ル
軽量プ
ロセス
軽量ス
レッド
スレッド
プール?
スレッドプ
ール?
GC
単位
プロセ
ス
共有メ
モリ
共有メモ
リ
共有メモリ
※スレッドは共有メモリを使⽤するので、GCすると
全体が⽌まる

12. ⾮同期ストリームのFramework
Elixir
Genstage/Flow
Scala
Akka
C# TPL DataFlow Node.js
Producer Source (ISoureBlock) reader
Produce-
Consumer
Flow (IPropergatorBlock) (pipe)
Consumer Sink (ITargetBlock) writer
Scala Akka は ErlangのActor リスペクト
GenStage は ScalaAkka Streams リスペクト
C# TPLもActorモデル(上記の表は無理やり）

13. Elixirの⾮同期ストリーム
GenStage
FlowのベースになっているBehavior
GenEventの改良版
Flow
GenStageがコールバック主体で実装していくのに
対し、より直観的に書ける。

14. Scala Akka Stream
GenStageやFlowがインスパイアされたライブラリ
Lightbend社（旧Typesafe社)提供
JVMで動作 Scala or Java対応
豊富なドキュメント
Pony langageの資料では Erlangと同等性能
twitterで#Akka what's wrong?って叫んだら中の⼈
が１０分ぐらいでPR送ってくれた(Thak you for
ktoso! )

15. Akka Streams

16. Akkaのドキュメントの⼀部

17. GOの並列実装のバリエーション
Channel
make時にBackpresure指定可
Select 調停
複数のチャネルからの結果を判断
Goroutine
普通のファンクションの前にGOと書けば、⾮同期
実⾏を⾏う

18. C#の並列実装のバリエーション
Task async / Tasck await
TPL DataFlow
Actorモデルによる⾮同期ストリーム
Parallel Linq
コレクションの操作を並列で⾏う

19. コード実装

20. Elixirの実装（抜粋）
Source Code on Github
上記SourceCodeのElixirFlowOrgはリファクタリン
グ前の関数です

21. result =
filename
|> File.stream!
# データクレンジング
|> Flow.from_enumerable()
|> Flow.map( &( String.replace( &1, ",", "t" ) ) ) # ①CSV→
|> String.replace( "rn", "n" ) # ②CRLF
|> String.replace( """, "" ) ) ) # ③ダブ
# 集計
|> Flow.map( &( &1 |> String.split( "t" ) ) ) # ④タブで分割
|> Flow.map( &Enum.at( &1, 2 - 1 ) ) # ⑤2番⽬の項⽬を抽出
|> Flow.partition
|> Flow.reduce(
fn -> %{} end, fn( name, acc ) # ⑥同値の出現数を集計
-> Map.update( acc, name, 1, &( &1 + 1 ) ) end )
|> Enum.sort( &( elem( &1, 1 ) > elem( &2, 1 ) ) ) # ⑦多い順で

23. Goの実装（抜粋）
Source Code on Github.

24. 最初に書いたコードでは1⾏リード毎にGo routine
を起動していた
さすがにそれはまずいので、Go Routineをワーカ
ーとしてマネージできるライブラリを探したが、
「公式」的なものはなかった。
次の記事を参考に、ワーカーの実装を⾏った。参
考 ⇒ golang の channel を使って Dispatcher-
Worker を作り goroutine 爆発させないようにする

25. Goでの実⾏イメージ

26. チャネルによるディスパッチ
func (w *worker) start() {
go func() {
for {
// register the current worker into the dispatch pool
w.dispatcher.pool <- w
select {
case v := <-w.data:
if bulkstr, ok := v.([][]string); ok {
wordMap := processData(bulkstr)
w.dispatcher.sink <- wordMap
}
w.dispatcher.wg.Done()
case <-w.quit:
return
}
}
}()
}

27. バルクデータをマップ化
func processData(r [][]string) map[string]int {
var m = map[string]int{}
for _, rec := range r {
m[ rec[aggColNo] ]++
}
return m
}

28. // チャネルからクラスタ化された集計結果を集める
func waitAndSum(sumMap map[string]int, d *Dispatcher, quit
for {
select {
case rec := <-d.sink:
for mk, mv := range rec {
sumMap[mk] += mv
}
case <-quit:
fmt.Println("quit")
return sumMap
default:
}
}
}

29. Scala Akka Streams 実装
（抜粋）
Source code on Github
↓ Tune up 注⽬︕
Tuned up ver by @KugiyaJ on Github
No Akka Source code by @KugiyaJ on Github

30. source
.via(CsvParsing.lineScanner())
.via(CsvToMap.withHeaders("firstname", "lastname", "gender"
.map(_.map(r => (r._1, r._2.utf8String))) // Map( birthday -
.filter(rec => rec.get(grp_col) != None)
.groupBy(30, r => r(grp_col)(0)) // 頭⼀⽂字でグループ分け
.async
.fold(acc_empty) { (acc: Map[String, Int], rec: Map[String
val word = rec(grp_col)
val cnt = acc.getOrElse(word, 0)
acc.updated(word, cnt + 1)
}
.mergeSubstreams
.via(Flow[Map[String, Int]].fold(acc_empty) { (acc: Map
acc ++ rec.map { case (k, v) => k -> (v + acc.getOrElse(k,
})
.runWith(Sink.foreach(e => {resultMap = e}))
.onComplete(done ⇒ {
val msec = (System.currentTimeMillis - start)
println(done)
resultMap.toSeq.sortWith(_._2 > _._2).take(10).foreach(pri

31. GroupByの第⼀引数には、サブストリームの数が
⼊る。集計キーが多い場合はSQL的に使えない。
ストリームをうまく分割するアイデアが⾒つから
なかったので、集計キーの１⽂字⽬でグループ化
効果がありそうな場所に.asyncを配置しても、1.5
倍遅い結果だった
※ 上記はLT時の内容です

32. Node.js（抜粋）
SourceCode on Github
const parser = csvParse({ delimiter: ',',
relax_column_count: true });
parser.on('data', (data) => {
const key = data[1]
sumMap.set(key,
sumMap.has(key) ? sumMap.get(key) + 1 : 1)
});
ストリームをラップしたcsv-parserを使⽤
CSV parserが⾏ごとにdataイベントを返すので、
都度集計処理

33. C# dotnet core 2.0 実装 抜粋
SourceCode on Github
static private async Task<ConcurrentDictionary<string, int>> Rea
{
using (FileStream sourceStream = new FileStream(filePath,
FileMode.Open,
FileAccess.Read, FileShare.Read, bufferSize: 4096
)) {
StreamReader sr = new StreamReader(sourceStream)
string text;
while ((text = await sr.ReadLineAsync()) !=
{
var wd = text.Replace(""", string.Empty).Spli
wordMap.AddOrUpdate(wd, 1, (_key, val) => {
}
return wordMap;
}
}

34. ・async/awaitによる⾮同期タスク制御
・StreamReader.readAsyncというぴったりの機能
・CocurrencyDictionaryという、これまたぴったり
なKVコレクション

35. 対 決 結 果

36. Windows 10 Home Edition
Corei5 7200U@2.5G Hz (Kabylake)
2コア4スレッド 16GMemory

37. Windows10 Home edition 単位（秒）
Corei5 7200U@2.5G Hz 2コア4スレッド
⾏数 Elixir Go C# Node.js
30 万 0.3 1.2 1.5 10.5
300万 19 12 15 107
1200万 86 50 47 433
Scala (@KugiyaJ ⽒によるTune up)
Scala NoAkka Akka ← (LT時)
30 万 1.2 3.7
300万 10.7 19.7 27
1200万 35.1 53.6 101

38. C#とGoが速い
※ScalaはIntelliJ環境下のスコア
(2/25) Akkaを使⽤しないScalaが最速︕

39. Windows 2008 Server
Intel Xeon(R) CPU E31230 (32n
2011Q2)@ 3.2GHz
4コア8スレッド 8GMemory

40. Windows Server 2008 R2 8GB
Intel Xeon(R) CPU E31230 (32n 2011Q2)@ 3.2GHz 4
コア8スレッド （On-premises）
Elixir Go C# Scala Node.js
30万⾏
300万⾏
1200万⾏ 49 43 35
コア数が増えたことで、85秒⇒49秒へ猛追
C#も速度上がる。Windows上ではC#最速
(2/25)諸事情により⼀部のみのベンチ

41. Google Compute Engine
Debian 9 vCPUx8 16GByte

42. ここでLinuxでC#に問題発⽣
Unhandled Exception: System.ArgumantException
The index is equal to or greater than the
length of the array, or the number of elements in
dictionnary is greater than the available space
from idex to the end of destination array.

43. GCE Debian 9 vCPU 8 16GByte 単位(秒)
⾏数 Elixir Go C# Node.js
30万 0.09 1.2 Crush - 13
300万 9.6 11.4 Crush 137
1200万 40.1 44.8 Crush 549
Scala (@KugiyaJ ⽒によるTune up)
Scala NoAkka Akka ← (LT時)
30 万 1.2
300万 9.5 19.7
1200万 38.3 53.6 116

44. ElixirがGoを抜きさる
C#は例外クラッシュ
Node.jsはWindowsより１割ほど速度低下
ScalaはCPUあんまり使ってない。プログラムが問
題かも。 ⇒ 2/25 ＠KugiyaJ⽒の⼿により最速に

45. Docker 2GB/2Core Debian
Microsoft公式 dotnetcoreコンテナ
Elixir Go C# Scala Node.js
30万⾏ 0.3 2.2 Crush
300万⾏ 29 23 Crush
1200万⾏ 118 Killed Crush
C#は例外クラッシュ
Goはメモリ不⾜でTask Kill

46. まとめ

47. Elixir/Go/C# ともにNode.jsの5 - 10倍の速度
Elixir Flow
⇒コア数が多いほど真価を発揮
⇒コード量の少い︕学習コスト少ない︕性能⾼い︕
どの環境でも安定度が抜群
⇒Shift-JIS対応や商⽤RDBとの接続に課題
GO
⇒並列⼊⾨⽤としては最適
⇒GoroutineはGCされないので、メモリ管理が負
担。1200万件では8GBのメモリを消費
⇒コード量がかさむ。⼤規模PJでは⾟そう
⇒VS CodeのIDE⼒が強⼒

48. Scala Akka
⇒InnteliJかしこい。型はあまり気にしなくてOK
⇒なにより実績がある。ドキュメントが⼿厚い
⇒環境構築が⾟い。
⇒IntelliJやDockerコンテナ使っている間はよい
が、そこから外れるとコストが⼤きい
⇒コンパイル時のメモリ消費⼤。今回のPGでも
2.5Gほどメモリを消費する
⇒Oracle RDBを重⽤してる⾝としてはOracleの企
業姿勢がリスク(JVM)
C#
⇒Windowsでは最速。Dotnet core動向に注⽬
⇒なんでも揃えます感
⇒VisualStudio賢い。でも重い

49. Elixir Go C# Scala Node.js
パフォーマンス B+ 〜A A A A D
ポーテーション 〇 〇 ? 〇 〇
安定度 S B A A A
環境構築コスト A S B C A
学習コスト B+ A B+ B- A
記述量 S C A S A
メンテナンス性 A B A A A
ドキュメント B+ A A S A
Elixirの安定度がSなのはGCの仕組による（プロセ
ス単位）

50. 2/25 追記
アドバイスを頂きました ⇒『Akkaはローカルで
の並列処理に特化したミドルウェアではないの
で、並列コレクションを使った⽅が早くなったの
だと思われます』
今回の企画は「Elixir Flowのコードを他の並⾏ライ
ブラリでも試してみよう」というノリで始めたの
ですが、どうやら並⾏処理の性能⽐較には実は向
いてない内容ということが判明しました。
ふさわしい企画を考えて、またトライしたいで
す︕

51. Enjoy Elixir Programming!
ご清聴ありがとうございました