Apache Kafka Meetup Japan #7 @LINE での発表資料

1. Copyright(C) 2019 KDDI Research, Inc. All Rights Reserved.
Kafka Streams VS Spark
～Kafka StreamsはどこまでSparkに迫れるか～
KDDI総合研究所
コネクティッドネットワーク部門
森澤 雄太

2. Copyright(C) 2019 KDDI Research, Inc. All Rights Reserved. 2
◼ KDDI総合研究所
⚫ KDDIの子会社
• 本社事業方針に沿った研究開発
• 「5G時代に向けた イノベーションの創出」「通信とライフデザインの融合」「ビッグデータの活
用」「グローバル事業の さらなる拡大」「金融事業の拡大」「グループとしての成長」「サステナ
ビリティ」
⚫ コネクティッドネットワーク部門
• ネットワーク、コネクティッドカー、自動運転、遠隔運転、IoT、運用自動化など……
◼ 自己紹介
⚫ ビッグデータ基盤・ストリームデータ、遠隔運転、 エッジコンピューティング、GPU
⚫ Apache Flinkのドキュメントの英文校正をちょっとやった
会社・自己紹介

3. Copyright(C) 2019 KDDI Research, Inc. All Rights Reserved. 3
やりたいこと：IoTデータ連携基盤のアーキテクチャ策定
車
防犯カメラ
センサー
データ基盤
データ
素敵なサービス
IoTデータを利用したサービス基盤
セーフティ インフォテイメント エージェント カーライフ
サポート

4. Copyright(C) 2019 KDDI Research, Inc. All Rights Reserved. 4
やりたいこと：IoTデータ連携基盤のアーキテクチャ策定
車
防犯カメラ
センサー
データ基盤
データ
ETL
素敵なサービス
サービスロジック
素敵なサービスの前には必ずETLがある

5. Copyright(C) 2019 KDDI Research, Inc. All Rights Reserved. 5
アイデア
開発したETL
新しいETL
Kafka Streamsで
ETLを代替できな
いか？
でも，パフォー
マンスは大丈夫
だろうか？

6. Copyright(C) 2019 KDDI Research, Inc. All Rights Reserved.
パフォーマンスベンチマーク
6
HadoopProxy
Device1
Device2
Device3
REST Kafka
情報抽出
型変換
データの粒度
調整
次段に転送
・3台のサーバ（Device）からバイナリデータをHttpで送出（120Mbps～）
・Kafka-REST（Proxy）でKafkaに変換
・Hadoop Clusterで情報抽出・型変換・粒度調整を実施
Kafka
比較範囲
Sink

7. Copyright(C) 2019 KDDI Research, Inc. All Rights Reserved. 7
◼ バージョン
⚫ Hadoop 2.9.2
⚫ Spark 2.4.3
⚫ Kafka 2.2.0
◼ 割り当てリソース
⚫ Master Memory ： 2GB
⚫ Worker Memory ： 3GB
⚫ CPU ： 1Core / node
⚫ 5 node
環境
◼ 評価方法
⚫ InputとOutputのKafka Timestampから処
理遅延を算出
◼ 実装
⚫ Spark
• Structured Streaming
⚫ Kafka
• Scala
• Stream DSL（Timestampの取得のみ
Processor API）

8. Copyright(C) 2019 KDDI Research, Inc. All Rights Reserved. 8
レイテンシ比較
0
500
1000
1500
2000
2500
3000
3500
1 3 5
Latency[ms]
Nodes
kafka spark
Kafka Streamsの方が低遅延
ノード数を小さくすると差が顕著に＝ノード辺りの処理性能もSparkより高い

9. Copyright(C) 2019 KDDI Research, Inc. All Rights Reserved.
Kafka Streams VS Spark
～Kafka StreamsはどこまでSparkに迫れるか～
KDDI総合研究所
コネクティッドネットワーク部門
森澤 雄太
迫りすぎて越えてしまった！

10. Copyright(C) 2019 KDDI Research, Inc. All Rights Reserved. 10
◼ 考察
⚫ Sparkは分散基盤 ＝ 大規模環境でメモリインテンシブな処理があって初めて力を発揮する
⚫ 今回のETLはEmbarrassingly Parallel，かつ，小規模基盤なのでSparkのよいところが活かせな
かった
◼ 結論
⚫ Kafka StreamsはETLでとても有用（かもしれない）
• オーバーヘッドが小さいため
• 耐障害性などは未評価
⚫ シンプルで便利
• 耐障害性，スケール性など自作が面倒なことをカバーしてくれる
考察と結論
実装の議論や「それはおかしい！」という意見歓迎です！
個別に話しましょう！

11. Copyright(C) 2019 KDDI Research, Inc. All Rights Reserved. 11