最近のストリーム処理事情振り返り

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