2016/05/31 Apache Kafka Meetup Japan #1 での発表資料

1. Kafkaを活用するための
ストリーム処理の基本
2016/05/31 Apache Kafka Meetup Japan #1
木村宗太郎（@kimutansk）
https://www.flickr.com/photos/gruenewiese/13194312524

2. 自己紹介
• 木村 宗太郎（Sotaro Kimura）
• ビッグデータ界隈に生息する何でも屋
• バックエンドからフロントエンド、技術検証から運用、
ドキュメント書きまで色々
• Kafkaとの出会いは3年程前に
Stormとの連携を試したのがキッカケ。
• だが、その後大規模なものをやる機会には恵まれず...
• 自宅サーバには常に入っています。
• Twitter他 : @kimutansk
1

3. アジェンダ
1. Kafkaのデータ活用モデル
2. ストリーム処理とは？
3. ストリーム処理プロダクト概況
4. ストリーム処理で考えるべきこと
2

4. 3
1. Kafkaのデータ活用モデル
• Kafkaのデータの用い方は大きく２つある。
1. 一気にまとめて取得するモデル
2. 常時取得し続けるモデル

5. 4
1. Kafkaのデータ活用モデル
1. 一気にまとめて取得するモデル
Log
Log
Log
Log
Log
Log
Log
Log Log
Log
Log
Log
Log
Log
Log

6. 5
1. Kafkaのデータ活用モデル
1. 一気にまとめて取得するモデル
Log LogLog Log
Log Log Log
Log LogLog Log
Log LogLog Log

7. 6
1. Kafkaのデータ活用モデル
2. 常時取得し続けるモデル
Log
Log
Log
Log
Log
Log
Log
Log Log
Log
Log
Log
Log
Log
Log

8. 7
1. Kafkaのデータ活用モデル
2. 常時取得し続けるモデル
Log
Log
Log
Log
Log
Log Log Log
Log Log Log
LogLog
Log

9. 8
2. ストリーム処理とは？
バッチ処理 対話型クエリ ストリーム処理
実行タイミング 手動起動
定期実行
手動起動
定期実行
常時実行
処理単位 保存済みデータを
一括処理
保存済みデータを
一括処理
１～少数の
フローデータを処理
実行時間 分～時間 秒～分 永続実行
データサイズ TBs～PBs GBs～TBs Bs～KBs（1件あたり）
処理時間 分～時間 秒～分 ミリ秒～秒
主な用途 ETL
ビジネスレポート生成
機械学習モデリング
インタラクティブBI
分析
異常／不正検知
レコメンド
可視化
代表的
OSSプロダクト
MapReduce
Spark
Tez
Impala
Drill
Presto
（後述）
• ビッグデータの処理モデルは主に３つある。

10. 9
2. ストリーム処理とは？
• バッチ処理
• データストアに蓄積したデータを
一括変換、レポート／モデル生成を行うモデル
生成したデータの出力先は
主にデータストア

11. 10
2. ストリーム処理とは？
• 対話型クエリ
• データストアに蓄積したデータに
対してクエリを実行し、結果を取得するモデル
クエリの実行結果は実行元
で取得するケースが多い

12. 11
2. ストリーム処理とは？
• ストリーム処理
• 「連続発生データを常時処理し続ける」モデル
• データの発生元は多岐にわたる
センサー
データ
ログ
アプリ
履歴
データ発生元 メッセージキュー ストリーム処理部 データ利用先
Kafkaの主な利用先

13. 12
2. ストリーム処理とは？
バッチ処理 対話型クエリ ストリーム処理
実行タイミング 手動起動
定期実行
手動起動
定期実行
常時実行
処理単位 保存済みデータを
一括処理
保存済みデータを
一括処理
１～少数の
フローデータを処理
実行時間 分～時間 秒～分 永続実行
データサイズ TBs～PBs GBs～TBs Bs～KBs（1件あたり）
処理時間 分～時間 秒～分 ミリ秒～秒
主な用途 ETL
ビジネスレポート生成
機械学習モデリング
インタラクティブBI
分析
異常／不正検知
レコメンド
可視化
代表的
OSSプロダクト
MapReduce
Spark
Tez
Impala
Drill
Presto
（後述）
• 今回の対象となるのは「ストリーム処理」

14. 13
3. ストリーム処理プロダクト概況
• ストリーム処理を実現するプロダクトは多彩
• 元は2011年のStorm公開を機に広く（？）発展
• 以降のプロダクトにいい意味でも悪い意味でも影響
• 最近多数のプロダクトが公開
• 下記のような派生パターン有
• UIでDataflow定義
• 処理を定義可能なUIを保持するパターン
• DSL
• 同一の記述で複数のストリーム処理エンジン上で
アプリケーションが実行可能

15. 14
3. ストリーム処理プロダクト概況
古 新公開時期
DSL
UIで
Dataflow定義
純ストリーム処理エンジン
Storm
Summingbird
NiFi
Spring Cloud
Data Flow
Cask Hydrator
Beam
Heron
SensorBee
Kafka
Streams
Ignite
Streaming

16. 15
3. ストリーム処理プロダクト概況
古 新公開時期
DSL
UIで
Dataflow定義
純ストリーム処理エンジン
Storm
Summingbird
NiFi
Spring Cloud
Data Flow
Cask Hydrator
Beam
Heron
SensorBee
Kafka
Streams
Ignite
Streaming
最近多くプロダクトが公開
正直、追いきれない状況
そのため、どれがいい、とは現状言えない。
（公開される資料はバイアスが・・・）
かつ、今良くてもすぐ陳腐化・・・

17. 4. ストリーム処理で考えるべきこと
• ストリーム処理を構築する上で
考えるべきことについて説明します。
• プロダクト選定時
• サービス開発時
• この項目自体も
Storm、Spark Streamingから挙げたものです。
• もしFlink、Apex、Gearpump等他プロダクトの
経験者がいれば、是非とも補足を。
16

18. 4. ストリーム処理で考えるべきこと
• プロダクト選定時に考えるべき主要観点
1. 実装言語は何か？
→ 未成熟なまま開発するため、解析必須
2. インストールの際に何が必要？
→ 各ホストにインストールするのは困難
3. サービス動作中にどこまで更新可能か？
→ 常時動作する関係上、止められないため。
4. 接続用コンポーネントが揃っているか？
→ Kafkaはほぼすべてのプロダクトと接続可能
そのため他コンポーネントの充実度が重要
17

19. 4. ストリーム処理で考えるべきこと
• サービス開発時に考えるべき主要観点
1. 【必要な場合】Exactly Onceの実現方法
→ データストアを用いて冪等性を実現
ストリーム処理単体では実現できない。
2. データがプロセスをまたがないように配置
→ シリアライズの遅延も大きな影響になる。
3. 極力メモリ上に収めるか、並列度を調整
→ 基本、ディスクに同期的に書かない。
4. ログを集約する機構を準備
→ 分散処理ではないとまともに解析できない。
18

20. まとめ
• Kafkaの活用方法には大きく2モデルある
1. 一気にまとめて取得するモデル→バッチ処理
2. 常時取得し続けるモデル→ ストリーム処理
• ストリーム処理ベストプロダクトは選べない
• プロダクトは異なっても共通点は多い
1. 性能特性／ボトルネックとなるポイント
2. データ設計
3. 解析を行うための準備 etc
• 上記とプロダクト成熟度を踏まえ構築
19

21. 検討ポイント詳細はこちらの資料参照
20
http://www.slideshare.net/SotaroKimura/jvm-62243371

22. Enjoy stream processing!
and share knowledge!
https://www.flickr.com/photos/elf-8/15276069760