1.
最近のストリーム処理事情
振り返り
2017/03/03
Hadoopソースコードリーディング第22回
Kimura, Sotaro（@kimutansk）
https://www.flickr.com/photos/esoastronomy/14255636846

2.
@kimutansk
自己紹介
•Kimura, Sotaro(@kimutansk)
– ドワンゴでデータエンジニアやってます
•データ分析基盤の管理
•データ分析に必要な各種ETLパイプライン構築
•生データを集計したデータマートの設計構築
•データフォーマット、内容等の設計 etc...
– 好きな技術分野
•ストリーム処理（主にJVM上）
•分散システム
•実装言語：Scala, Go
– 好きなOSSプロダクト
•Apache Kafka
•Apache Beam
•Apache NiFi etc...

3.
@kimutansk
アジェンダ
•ストリーム処理とは何か？
•ストリーム処理システム構成の変遷
– バッチと並列でデータ処理を実行
– 単体でデータ処理を実行
– データ処理パイプラインとして抽象化し、実行
•最近語られているストリーム処理の概念
– バッチ処理とストリーム処理の違い
– ストリーム処理で発生する問題
– 問題に対する対処
•ストリーム処理のプロダクト群
– 各プロダクトの紹介
– 実際にどのプロダクトを使うべき？

4.
@kimutansk
ストリーム処理とは何か？

5.
@kimutansk
どんなものか？
•「無限に発生し続けるデータを処理するよう
設計されたデータ処理モデル」
•実際に
ストリーム処理と呼ばれるものがもつ性質は・・・

6.
@kimutansk
どんなものか？
•ストリーム処理の性質
– 無限に発生し続けるデータを処理
• 常に増大し続け、本質的には無限に発生するデータを処理
• データ源自体もしばしば「ストリームデータ」と呼ばれる
• システムログ、センサーデータ、人間の行動履歴等多々存在
– 処理が永続的に継続
• 常に増大し、本質的には無限に発生するデータであるため、
処理も永続的に実行される。
• バッチ処理を繰り返して実行すれば無限に発生するデータに
も適用可能だが、ここではそれとは区別する。
– 低遅延、近似値＆不定期な結果出力
• ストリーム処理の出力は以後に説明する性質の関係上、
しばしば近似の値だったり、不定期な出力となる。

7.
@kimutansk
どんな分野に使用されているか？
•課金処理
– クラウド系サービスの利用料課金
– 携帯電話の通信料課金
•ライブ費用見積
– クラウド系サービスの利用状況からの課金見積り
– 携帯電話の通信量見積もり
•異常・変化イベント検知
– 不正ログイン検知
– システムの異常検知
– レコメンデーション
•異常・変化イベント検出結果復旧
– 不正ログイン検知の結果対応
– 異常を検知したタイミングで一度停止後、再開などの対応

8.
@kimutansk
ストリーム処理システム構成の変遷

9.
@kimutansk
ストリーム処理システム構成の変遷
•OSSのストリーム処理基盤は
登場後、下記のように構成が変遷している。
– （※変遷の分類は個人の感想です）
•2011年～ Lambda Architecture
– バッチ処理と並列でデータ処理を実行
•2013年～ Kappa Architecture
– 単体でデータ処理を実行
•2015年～ Dataflow Model（？）
– データ処理パイプラインとして抽象化して実行

10.
@kimutansk
Lambda Architectureの時代
•Twitter(当時)のNathan氏が挙げたアーキテクチャ
– How to beat the CAP theorem（※）
•バッチレイヤとリアルタイムレイヤを
並行して実行し、結果をマージして表示する構成
（※）http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html

11.
@kimutansk
Lambda Architectureの時代
•バッチレイヤ
– 大規模のデータに対して精度の高い処理が実行可能
– ただし、結果を出力するのに何時間も必要
– データが全て揃ってから実行する必要有
•リアルタイムレイヤ
– 流れているデータをリアルタイムで処理可能
– 結果をNoSQLに格納し、粒度の細かい単位で更新
– 当時はデータを長期保存して使用はされなかった
•上記の２レイヤの結果をマージして表示することで
精度とリアルタイム性の両立が可能となった。

12.
@kimutansk
Kappa Architectureの時代
•Linkedin(当時)のJay氏が挙げたアーキテクチャ
– The Log: What every software engineer should know about
real-time data's unifying abstraction（※1）
– Questioning the Lambda Architecture （※2）
•Lambda Architectureの複雑性に対して問題を提起
•ストリーム処理システムでバッチと同様の
精度を保証する対処をして構成をシンプル化
（※1）https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying
（※2）https://www.oreilly.com/ideas/questioning-the-lambda-architecture

13.
@kimutansk
Kappa Architectureの時代
•Lambda Architectureの利点・問題点
•利点
– 入力データを保持し、再実行が可能な構成
•問題点
– バッチレイヤとリアルタイムレイヤで
同じ結果を生成するコードを維持するのが困難
•言ってしまえば、StormとMapReduceで同じ結果を
生成するコードを２重に実装するということ。
•抽象化して両方を実行するSummingbirdがあったが、
Summingbird自体が非常に扱いにくいもので、状況は・・・

14.
@kimutansk
Kappa Architectureの時代
•ストリーム処理で精度を実現するための対処
– Kafka等の複数Subscribeが可能な基盤にデータを集約
– 障害発生時は障害時のデータを再度取得して処理
– 再処理をする場合はKafkaのデータの先頭から処理
•実際、プログラムのバグなどで再処理が必要なケースはある
•旧バージョンと新バージョンの結果を別テーブルに出力し、
新バージョンの処理が追いついた段階で参照を切替
•新バージョンの処理能力は並列化で増幅
•このアーキテクチャをLambda（λ）より優れた、
αに近いKappa（κ）アーキテクチャと呼んだ。
– （そもそも何故Lambdaという突込みはありますが・・）
•CQRS+Event Sourcingともつながり、
アプリケーションアーキテクチャとしても使用可能

15.
@kimutansk
Dataflow Model（？）の時代
•（前２つを置き換えるものではないです）
•GoogleのTyler氏や、data Artisansの方々が
Unified Stream and Batch Processing、
ストリーム処理とバッチ処理の統合を提唱
– The world beyond batch: Streaming 101 （※1）
– Stream and Batch Processing in a Single Engine（※2）
•並行して実行されるデータ処理パイプライン
としてはこの２つは同じだという考え
– そのため、ストリーム処理でどちらも対応可能という
スタンスを取っている。
– （※詳細は後述）

16.
@kimutansk
最近語られている
ストリーム処理の概念

17.
@kimutansk
ビッグデータ処理パターン
•代表的なビッグデータ処理パターンは下表となる。
バッチ処理 対話型クエリ ストリーム処理
実行契機 手動実行
定期実行
手動実行
定期実行
常時実行
処理対象 保存済みデータ 保存済みデータ 無限に生成される
ストリームデータ
処理時間 分 ～ 時間 秒 ～ 分 永続実行
データサイズ TBs～PBs GBs～TBs Bs～KBs（Per 1 event）
レイテンシ 分 ～ 時間 秒 ～ 分 ミリ秒 ～ 秒
典型的な適用先 ETL
レポーティング
機械学習モデル生成
BI
データ分析
異常変化検知
レコメンド
可視化
OSS products MapReduce
Spark
Impala, Presto, Drill
Hive
（後述）

18.
@kimutansk
バッチ処理
•保存済みデータに対して実行し、
結果をデータストアに出力するモデル

19.
@kimutansk
対話型クエリ
•保存済みデータに対して実行し、
結果をクライアントで取得するモデル

20.
@kimutansk
ストリーム処理
無限のデータ源 メッセージバス ストリーム処理
エンジン
出力先
モバイルログ
センサーデータ
システムログ
•無限に生成され続けるストリームデータに
対して実行するモデル

21.
@kimutansk
バッチ処理とストリーム処理の違い
•大きな違いは、処理対象が完全か否か。
バッチ処理 対話型クエリ ストリーム処理
実行契機 手動実行
定期実行
手動実行
定期実行
常時実行
処理対象 保存済みデータ 保存済みデータ 無限に生成される
ストリームデータ
処理時間 分 ～ 時間 秒 ～ 分 永続実行
データサイズ TBs～PBs GBs～TBs Bs～KBs（Per 1 event）
レイテンシ 分 ～ 時間 秒 ～ 分 ミリ秒 ～ 秒
典型的な適用先 ETL
レポーティング
機械学習モデル生成
BI
データ分析
異常変化検知
レコメンド
可視化
OSS products MapReduce
Spark
Impala, Presto, Drill
Hive
（後述）
入力データは完全 入力データはストリーム！

22.
@kimutansk
バッチ処理の前提
•バッチ処理の前提
– 実行するタイミングでデータは完全である必要がある。
•つまり、対象のデータは「有限」となる。
– バッチをまたぐ出力は困難
•典型的なバッチ処理モデル
MapReduce

23.
@kimutansk
バッチ処理のパターン
•複数の結果を出力する場合は複数回バッチを実行
•結果を時間で区切る場合はそれらをすべて含む
データを入力
MapReduce
MapReduce
2/26
2/27
2/28
2/28
[00:00 ～ 06:00)
[06:00 ～ 12:00)
[12:00 ～ 18:00)
[18:00 ～ 24:00)
MapReduceMapReduce
MapReduce

24.
@kimutansk
バッチ処理で対応しにくいパターン
•ユーザのセッションを出力したい場合、日を跨ぐ。
– セッション＝一定時間内の連続アクセス（ログが存在）
– もしユーザが2/27と2/28を跨いでアクセスした場合、
2/27の結果の再出力が必要となるが、それは困難。
– もし、それが続いた場合・・・どうなる？
MapReduce
2/282/27 2/282/27
Red
Yellow
Green

25.
@kimutansk
バッチ処理は、実は・・?
•複数回バッチ実行は下図のように変形できる。
– これはすなわち・・？
2/26 2/27 2/28
2/282/272/26
Map
Reduce
Map
Reduce
Map
Reduce

26.
@kimutansk
ストリーム処理の部分集合
•これは、すなわち無限のデータであるストリームデ
ータを一定時間ごとに区切ったものに他ならない。
区切りのある有限のストリーム
時間で区切る
2/26 2/27 2/28
区切りのない無限のストリーム

27.
@kimutansk
ストリーム処理の部分集合
•つまり、バッチ処理とはストリーム処理の中の
限定的な処理のモデルであるいうこと。
2/26 2/27 2/28
ストリーム
処理
バッチ
処理
区切りのある有限のストリーム
区切りのない無限のストリーム
時間で区切る

28.
@kimutansk
バッチ処理の前提がない場合
•ストリーム処理におけるバッチの前提の扱い
•バッチの前提：入力データが完全
– 常に生成され続けるストリームデータのため満たされない
•バッチの前提：バッチを跨いだ出力が困難
– 常時処理かつ、処理単位が小さいため、
バッチより対応が容易
•ただ、データが完全な状況においては、
ストリーム処理はバッチ処理と同等の機能を実現可
– 「バッチ処理はストリーム処理の部分集合」のため
– 管理容易性や処理の区切りやすさ等の要素は当然異なる

29.
@kimutansk
ストリーム処理で発生する問題
•データは発生した順に到着しない！
– このことを“Out of order”と呼ぶ
– 例) 携帯電話を機内モードに切り替えて搭乗
•上記の事情が発生する原因例
– ネットワーク切断・遅延
– システム中のサーバ間の時刻のずれ
•上記の時刻概念として、代表的な２つを説明、
– EventTime
•実際にそのイベントが発生した時刻
– ProcessingTime
•実際にそのイベントを処理した時刻
•（到着した時刻が記録される場合もある）

30.
@kimutansk
それで何が困るのか？
•もしデータ間に関連が無いのであれば、
“Out of order”であってもそれほど困らない。
– 結果が反映されるまで時間がかかるという問題はある。
•しかしながら、ストリーム処理の適用分野には、
データ間の関連を見る必要があるケースが多い。
– 例)異常・変化イベント検知の場合
１イベントで異常や変化を検知できるケースは少ない。
「短時間に特定アカウントに大量のログイン試行」など、
前後のイベントの関係が必要になる。

31.
@kimutansk
データのグルーピングの概念
•データのグルーピングの概念としてWindowがある
Tumbling
Window
Time
Sliding
Window
Sesson
Window

32.
@kimutansk
Out of orderによるWindowの問題
•Windowを使用する際、“Out of order”の性質で
問題が発生する。
– もし[00:00 ～ 06:00]結果出力後に05:55のデータが到着
したらどう扱えばいいのか？
[00:00 ～ 06:00)
1. 出力2. 到着...?

33.
@kimutansk
これらの問題に対する対処
•このストリーム処理で発生する問題に対して、
下記の３つの対処の概念が挙げられている。
•Watermark
– EventTimeベースで、どの時刻まで処理が完了したか？
•Trigger
– どのタイミングで集計結果を出力するか？
•Accumulation
– 集計結果を複数回出力するときにどうやって蓄積するか？

34.
@kimutansk
Watermarkとは？
•EventTimeベースでどこまで処理したかを示す概念
– EventTimeとProcessingTimeの両方が存在した場合、
各時刻間に歪みが発生するため、それを示す。
Event Time
ProcessingTime
理想のシステム
実システム
(≒Watermark)
歪み

35.
@kimutansk
Watermarkとは？
•Watermarkの使用方法
– もしWatermarkの時刻が“X”だった場合、
EventTimeが”X”以前のイベントは全て処理されている。
•しかしながら・・
– Watermarkは完全にはなり得ない。
– データの到着は”Out of order”であるため、
Watermarkもあくまで近似に過ぎない。
•ただ、Watermark自体は有用
– 集計結果を出力するタイミングの基準にできる。

36.
@kimutansk
Triggerとは？
•Triggerとはいつ集計結果を出力するかを
定義する機構
– Triggerの存在によって、集計結果の出力タイミングを
柔軟に、複数回定義可能になる。
– 加えて、Watermarkより遅れたデータに対しても対応可能
•Example
– WatermarkがWindowの最後まで到着したタイミングで、
集計結果を出力する例
PCollection<KV<String, Integer>> wordCountResult =
wordOneCountStream.apply("Fixed Windowing",
Window.<KV<String, Integer>>into(
FixedWindows.of(Duration.standardMinutes(2)))
.triggering(Repeatedly.forever(AfterWatermark.pastEndOfWindow())))
.apply(Sum.integersPerKey());

37.
@kimutansk
Triggerとは？
•Example
– Watermarkより遅れたデータが到着した場合、
集計結果を出力する例
PCollection<KV<String, Integer>> wordCountResult =
wordOneCountStream.apply("Late Firing",
Window.<KV<String, Integer>>into(
FixedWindows.of(Duration.standardMinutes(2)))
.triggering(AfterWatermark.pastEndOfWindow()
.withLateFirings(
AfterProcessingTime.pastFirstElementInPane()
.plusDelayOf(Duration.standardMinutes(1)))))
.apply(Sum.integersPerKey());

38.
@kimutansk
Triggerとは？
•Example
– Watermarkより遅れたデータが到着した場合、
集計結果を出力
– 遅延は5分まで許容する例
PCollection<KV<String, Integer>> wordCountResult =
wordOneCountStream.apply("Late Firing until 5 min late",
Window.<KV<String, Integer>>into(
FixedWindows.of(Duration.standardMinutes(2)))
.triggering(AfterWatermark.pastEndOfWindow()
.withLateFirings(
AfterProcessingTime.pastFirstElementInPane()
.plusDelayOf(Duration.standardMinutes(1))))
.withAllowedLateness(Duration.standardMinutes(5))
.accumulatingFiredPanes())
.apply(Sum.integersPerKey());

39.
@kimutansk
Accumulationとは？
•Accumulationとは、Triggerで集計結果を
複数回出力する場合にどう扱うかの方式
– ただし、「どう」するべきかは対象のシステムに依存。
•出力先システムが自前で蓄積する機能を有している場合と
Key-Valueデータストアのようにデータを保持する場合で
異なる。
•加えて、システム全体で見た場合に、これらの要素が
混在するケースもあり得る。

40.
@kimutansk
Accumulationとは？
•代表的な方式な3つのAccumulation方式がある。
– Discarding mode
•集計結果を出力した際に、前の結果を破棄
•次の出力時には前回出力以降の集計結果を出力
– Accumulating mode
•集計結果を出力した際に、前の結果を保持
•次の出力時には前回出力と合計して集計結果を出力
– Accumulating & Retracting mode
•集計結果を出力した際に、前の結果を保持
•次の出力時には下記２つを出力
– 前回出力と合計した集計結果
– 前回出力の減算分

41.
@kimutansk
Accumulationとは？
•各方式毎の出力結果例
– [12:00～12:02) の集計結果を出力する例を考える。
•到着データ
No Processing Time Event Time Event Value
1 12:05 12:01 7
2 12:06 12:01 9
3 12:06 12:00 3
4 12:07 12:01 4

42.
@kimutansk
Accumulationとは？
•各方式毎の出力結果例
– [12:00～12:02) の集計結果を出力する例を考える。
•実際の出力結果
出力時刻 Discard Accumulating Accumulating & Retract
12:05 7 7 7
12:06 12 19 19,-7
12:07 4 23 23,-19
最終出力 4 23 23
合計出力 23 49 23
最終出力と合計出力が同一
複数システムが混在した場合に
対応しやすい。

43.
@kimutansk
これらの対処をうてばOKか？
•Watermark, Trigger, Accumulationの対処をうてば
ストリーム処理のあらゆるケースに対応可能か？
•残念ながら、そんなことはない。
•上記の対処をうっても、下記のような問題は残る。
– WatermarkのEventTime VS ProcessingTimeの歪みを
どれだけ確保すればいいのか？
•差分を大きくした場合、完全性は高まるが、
その分遅延は大きくなる。
– Accumulationの中間結果を
どれだけの時間保持しておけばいいのか？
•保持する時間が長いほど、必要システムリソースは増大

44.
@kimutansk
データ処理システムのトレードオフ
•データ処理システムには
下記３要素のトレードオフがあるといわれている。
– 完全性
– 低遅延
– 低コスト
•３要素をすべて満たすことは出来ない。
– 様々なデータ処理システムは、
これらのトレードオフのバランスをとる必要がある。
– このバランスの中で、システムごとに落とし所を決める。
•ここで、「コスト」はシステムリソースだけでなく、収集時
の転送路の整備や通信コストも含む。
•実際の例は・・・

45.
@kimutansk
トレードオフの例
•課金処理
– 重要な要素は「完全性」
– 遅延やコストが発生してもある程度は許容範囲となる。
Important
Not Important
完全性 低遅延 低コスト

46.
@kimutansk
トレードオフの例
•異常・変化検知処理
– 重要な要素は「低遅延」
– その他の要素の優先度は下がる。
Important
Not Important
完全性 低遅延 低コスト

47.
@kimutansk
ストリーム処理のプロダクト群

48.
@kimutansk
典型的なシステム構成
無限のデータ源 メッセージバス ストリーム処理
エンジン
出力先システム
Mobile activity
Sensor data
System log
•実際のストリーム処理システムは
図のような構成を取ることが多い。

49.
@kimutansk
各構成要素の詳細
•メッセージバス
– 無限のデータは流量がしばしばはね上がることがある。
– 障害が発生した時など、データを再取得が必要。
– そのため、データを一時的に蓄積するのに使用する。
– 例) Kafka, Kinesis, Cloud PubSub etc...
•ストリーム処理エンジン
– ストリーム処理エンジンがデータを取得し、処理
– 基本的に永続実行されるため、高可用性が求められる。
– （プロダクト一覧については後述）
•出力先システム
– ストリーム処理システムの出力結果を使用するシステム
– 実際の構成はユースケースに依存

50.
@kimutansk
ストリーム処理エンジンの分類
DSL
UIでデータフローを
定義可能
純ストリーム処理
エンジン
マネージド
サービス
Time to release
Streams

51.
@kimutansk
ストリーム処理エンジン分類
• （※個人的な分類です）
•純ストリーム処理エンジン
– ストリーム処理エンジンの機能がメインのプロダクト
– 特に特別な機能を有しないため、他のカテゴリと区別
•UIでデータフローを定義可能
– データフローを定義可能なUIを保持するプロダクト
– ユーザはストリーム処理を容易に定義可能
•DSL
– 一つのコードを複数のストリーム処理基盤上で実行可能
– DSLは抽象化したデータフローモデルを生成
•マネージドサービス
– 実行環境がパブリッククラウド上で管理されたプロダクト
•以降でプロダクトの一部を紹介

52.
@kimutansk
プロダクト紹介 : Storm
•At 2011, opensourced by Twitter
– Clojure製
•そのため、解析にはClojureが読める必要があった・・・
– 実質的に広く使われた初のOSSストリーム処理エンジン
•“At least once”を初期版でサポートしていたのが大きい
– ただ、初期のプロダクトなので問題も多かった。
•レイテンシは非常に低いが、スループットは小さい。
•バックプレッシャー機構が無かった。
•初期のOperatorのデフォルト配置モードが非効率。
•Ackがメッセージ単位で非常に負荷が大きい。
•現行バージョンでは大部分の問題は解消済み。
– 以後のストリーム処理プロダクトに大きく影響がある。

53.
@kimutansk
プロダクト紹介 : Spark Streaming
•At 2013, opensourced by amplab.
– Scala製
– バッチ処理フレームワークSpark上で
小バッチを実行することで擬似的にストリームを再現。
•マイクロバッチ方式と呼ばれる。
•ネイティブストリーム版も開発中。
– スループットは大きかったが、レイテンシも大きかった。
•登場時にStormと比較した場合
•FlinkやApexと比較すると・・・？
– Sparkエコシステム上で開発実行可能なのが大きい。
•Sparkのコンポーネントを（すべてではないが）使用可能。
Spark SQL, Spark MLlib, etc...
•開発方式も同様であるため、
バッチとストリームを近い環境で開発可能。

54.
@kimutansk
プロダクト紹介 : Samza
•At 2013, opensourced by Linkedin.
– Java/Scala製
– 「Kappa Architecture」の実現のため作成された
ストリーム処理基盤をOSS化したもの。
– 最初からKafkaと組み合わせて使用されていたため、
Kafkaとの相性が非常にいい。
– KafkaのOffsetをチェックポイントとして保持することで
処理の再実行が行いやすい構成になっている。
•チェックポイント自体もKafkaに記録し、
構成がシンプルに保てるようになっている。

55.
@kimutansk
プロダクト紹介 : NiFi
•At 2014, opensourced by NSA.
– Java製
– UIで定義したデータフローをNiFiクラスタにデプロイし、
ストリーム処理を実行することが可能。
•例) Kafkaからデータを取得＞情報追加＞HDFSに投入
– 各Operator間でキューや帯域設定なども可能であり、
きめ細やかな制御が可能。
– データの出自や変更履歴を蓄積しており、管理機能が充実
•ただ、その分性能的には負荷は大きくなる。
– UIからデータフローが定義可能であるがゆえに、
コードでの構成管理が困難という問題も存在する。

56.
@kimutansk
プロダクト紹介 : NiFi

57.
@kimutansk
プロダクト紹介 : Flink
•At 2014, opensourced.
– 2011年にはStratosphereの名称
– Scala製
– バッチ用APIとストリーム用APIの両方を保持する
データ処理エンジン
– 耐障害性のために「分散スナップショット」方式を保持
•Lightweight Asynchronous Snapshots for Distributed Dataflows
•効率的に非同期のスナップショットを取得することが可能。
– 下記の３方式の開発APIを提供し、様々なケースに対応。
•宣言的、高レベルAPI
•手続き的、低レベルAPI
•Streaming SQL API

58.
@kimutansk
プロダクト紹介 : Flink
•宣言的、高レベルAPIによる実装例
– 関数でストリームを加工し、個々の処理を行う。
case class CarEvent(carId: Int, speed: Int, distance: Double, time: Long)
val DataStream[CarEvent] carEventStream = ...;
val topSeed = carEventStream
.assignAscendingTimestamps( _.time )
.keyBy("carId")
.window(GlobalWindows.create)
.evictor(TimeEvictor.of(Time.of(evictionSec * 1000, TimeUnit.MILLISECONDS)))
.trigger(DeltaTrigger.of(triggerMeters, new DeltaFunction[CarEvent] {
def getDelta(oldSp: CarEvent, newSp: CarEvent): Double = newSp.distance - oldSp.distance
}, cars.getType().createSerializer(env.getConfig)))
.maxBy("speed")

59.
@kimutansk
プロダクト紹介 : Flink
•手続き的、低レベルAPIによる実装例
– processメソッドをストリームの各Eventに適用し、
個々の処理を行う。
val stream : DataStream[Tuple2[String, String]] = ...;
val result : DataStream[Tuple2[String, Long]] result =
stream
.keyBy(0)
.process(new CountWithTimeoutFunction());
case class CountWithTimestamp(key: String, count: Long, lastModified: Long)
class CountWithTimeoutFunction extends ProcessFunction[(String, Long), (String, Long)] {
lazy val state: ValueState[CountWithTimestamp] = getRuntimeContext()
.getState(new ValueStateDescriptor<>("myState", clasOf[CountWithTimestamp]))
override def processElement(value: (String, Long),
ctx: Context, out: Collector[(String, Long)]): Unit ...;
override def onTimer(timestamp: Long, ctx: OnTimerContext,
out: Collector[(String, Long)]): Unit = ...;
}

60.
@kimutansk
プロダクト紹介 : Flink
•Streaming SQL APIによる実装例
– ストリームにスキーマを設定し、SQLで処理を記述
val env = StreamExecutionEnvironment.getExecutionEnvironment
val tableEnv = TableEnvironment.getTableEnvironment(env)
// read a DataStream from an external source
val ds: DataStream[(Long, String, Integer)] = env.addSource(...)
// register the DataStream under the name "Orders"
tableEnv.registerDataStream("Orders", ds, 'user, 'product, 'amount)
// run a SQL query on the Table and retrieve the result as a new Table
val result = tableEnv.sql(
"SELECT product, amount FROM Orders WHERE product LIKE '%Rubber%'")

61.
@kimutansk
プロダクト紹介 : Apex
•At 2015, opensourced by DataTorrent.
– Java製
– 元々は金融アプリケーションで使用。
•耐障害性に焦点があてられている。
•障害発生時の解析の容易性も充実
•各Operator間にバッファを保持し、影響をおさえる構成
– Hadoopクラスタの上で動作させるのに適する。
•HDFSをKVSのように使用して低レイテンシで状態を管理
•YARNネイティブな基盤
– 実行中にオートスケールも可能
– Flinkと同様に3つの開発用APIを保持。

62.
@kimutansk
プロダクト紹介 : Gearpump
•At 2015, opensourced by Intel.
– Scala製
– Googleのストリーム処理エンジン、
MillWheelの設計を参考に開発
•MillWheel Fault-Tolerant Stream Processing at Internet Scale
– AkkaのActorを実行基盤上に配置して実行する
「薄いフレームワーク」
•拡張性、カスタマイズ性、性能に優れる。
•ただし、状態管理も自作が必要で、開発コストは大きい。
•Akkaを用いた開発者ならスムーズに移行できる。
– “Reactive Streams”に準拠した、
標準化されたバックプレッシャー機構を保持
– akka-streams互換のDSLで処理グラフを記述可能。

63.
@kimutansk
プロダクト紹介 : Kafka Streams
•At 2016, produed by confluent.
– Java製
– Kafkaのコンポーネントの１つ
– ストリーム処理アプリケーション構築用のライブラリ
•Kafka streamsはクラスタ化やHA構成などは未サポート
•これらの要素はユーザ側に委ねる方針を取っている。
– 実質的にKafka専用
•入力ソース、出力先はKafkaのみが標準提供
– キーとなるコンセプトはStreamsとTables
•ストリームとテーブルの二重性を活用できる。
– シンプルではあるが、機能は充実
•宣言的、手続き的の２種のAPIを有しており、
クエリ可能な状態や、Window制御も可能。

64.
@kimutansk
プロダクト紹介 : Beam
•At 2016, opensourced by Google.
– Java製
– ビッグデータ用の統一処理モデルを提供
•ストリーム／バッチ両対応
– BeamのAPIを使用して開発したアプリケーションは
複数のストリーム処理エンジン上で実行可能。
•ローカル環境
•Google Cloud Dataflow(Google Cloud Platform)
•Spark, Flink, Apex, Gearpump
– 高いポータビリティを得ることができるが、
プロダクト固有のライブラリは使用できない。
•機械学習、グラフ処理等
•これらの要素を使用する場合は別途Tensorflowなどを
実行してカバーする必要が出てくる。

65.
@kimutansk
プロダクト紹介 : Cloud Dataflow
•At 2015, produced by Google.
– Beam APIを用いて開発された
アプリケーションの実行基盤
•初期リリース時はData flow APIだった。
– マネージドサービスではあるが、
アプリケーションをデプロイするという形態のため、
広い範囲のアプリケーションに対応可能。
– マネージドサービスのため、
動的な最適化も常時行われ、性能効率が高い。

66.
@kimutansk
プロダクト紹介 : Kinesis Analytics
•At 2016, produced by Amazon.
– SQLを用いてKinesis上を流れる
ストリームデータに対して
継続的クエリを適用できる。
•“Data in Mortion”というコンセプト
– 非常に手軽に構築が可能だが、現状制約も多い。
•入力ストリームは1つに限られる。
– ストリームとS3上のデータとのJoinは可能。
•出力先はKinesis Familyのみで、3つまでしか設定できない。
– EventTime/IngestTime/ProcessingTimeを区別し、
各種のWindow関数を適用可能。
– 自動的にスケールするが、スケールの粒度は大きく、
どれだけ料金がかかるかも読みにくい。.

67.
@kimutansk
実際にどのプロダクトを使うべき？
•（※あくまで個人の意見です。）
•最初のアプリケーションならFlink or Apex
– 機能、性能、開発容易性のバランスがいい。
•Akkaの熟練者なら、Gearpump
– カスタマイズ性や性能は高い。
•Sparkユーザであれば、Spark Streaming
– Sparkの既存コンポーネントとの親和性が高い。
– Structured StreamはDrizzle等今後の展望も多い。
•複数の小さいアプリケーションを組むなら、NiFi
•Kafka Streamsは補助的だったり、
プロセスを自前で制御したい場合に使用する。
– 既存システムの一部をストリーム化する場合にも向く。

68.
@kimutansk
実際にどのプロダクトを使うべき？
•（※あくまで個人の意見です。）
•Beamについては、抽象化されている関係上、
APIが生でストリーム処理基盤を使うより難解。
•加えて、現状まだまだドキュメントや実装例に
ついても少なく、使うのに苦労する。
•（※個人的にはspotifyのscioが現状Beamに未対応
でScalaでかけないのが大きかったです。）
•ストリーム処理基盤との結合も
これからより進むと思われるため、
今は待った方がいい・・・？

69.
@kimutansk
まとめ
•ストリーム処理の用途の歴史
– Lambda Architecture
– Kappa Architecture
– Dataflow Model
•最近のストリーム処理で用いられる概念
– Watermark
– Trigger
– Accumulation
•ストリーム処理プロダクトの紹介
•現時点で何を使うべきか？
– （※状況はすぐに変わるため、
これはあくまで現状の意見でしかないです。）

70.
@kimutansk
参照資料（スライド中を除く）
• The world beyond batch: Streaming 101
– https://www.oreilly.com/ideas/the-world-beyond-batch-streaming-101
• The world beyond batch: Streaming 102
– https://www.oreilly.com/ideas/the-world-beyond-batch-streaming-102
• MillWheel: Fault-Tolerant Stream Processing at Internet Scale
– https://research.google.com/pubs/pub41378.html
• The Dataflow Model: A Practical Approach to Balancing Correctness, Latency,
and Cost in Massive-Scale, Unbounded, Out-of-Order Data Processing
– https://research.google.com/pubs/pub43864.html
• The Evolution of Massive-Scale Data Processing
– https://goo.gl/jg4UAb
• Streaming Engines for Big Data
– http://www.slideshare.net/stavroskontopoulos/voxxed-days-thessaloniki-
21102016-streaming-engines-for-big-data
• Introduction to Streaming Analytics
– http://www.slideshare.net/gschmutz/introduction-to-streaming-analytics-
69120031

71.
@kimutansk
参照資料（スライド中を除く）
• Stream Processing Myths Debunked:Six Common Streaming Misconceptions
– http://data-artisans.com/stream-processing-myths-debunked/
• A Practical Guide to Selecting a Stream Processing Technology
– http://www.slideshare.net/ConfluentInc/a-practical-guide-to-selecting-a-stream-
processing-technology
– https://research.google.com/pubs/pub41378.html
• Apache Beam and Google Cloud Dataflow
– http://www.slideshare.net/SzabolcsFeczak/apache-beam-and-google-cloud-
dataflow-idg-final-64440998
• The Beam Model
– https://goo.gl/6ApbHV
• THROUGHPUT, LATENCY, AND YAHOO! PERFORMANCE BENCHMARKS. IS
THERE A WINNER?
– https://www.datatorrent.com/blog/throughput-latency-and-yahoo/
• Lightweight Asynchronous Snapshots for Distributed Dataflows
– https://arxiv.org/abs/1506.08603

72.
Thank you for your attention!
Enjoy Stream Processing!
https://www.flickr.com/photos/neokratz/4913885458