Successfully reported this slideshow.

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

54

Share

1 of 72
1 of 72

More Related Content

Related Books

Free with a 30 day trial from Scribd

See all

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

  1. 1. 最近のストリーム処理事情 振り返り 2017/03/03 Hadoopソースコードリーディング第22回 Kimura, Sotaro(@kimutansk) https://www.flickr.com/photos/esoastronomy/14255636846
  2. 2. @kimutansk 自己紹介 •Kimura, Sotaro(@kimutansk) – ドワンゴでデータエンジニアやってます •データ分析基盤の管理 •データ分析に必要な各種ETLパイプライン構築 •生データを集計したデータマートの設計構築 •データフォーマット、内容等の設計 etc... – 好きな技術分野 •ストリーム処理(主にJVM上) •分散システム •実装言語:Scala, Go – 好きなOSSプロダクト •Apache Kafka •Apache Beam •Apache NiFi etc...
  3. 3. @kimutansk アジェンダ •ストリーム処理とは何か? •ストリーム処理システム構成の変遷 – バッチと並列でデータ処理を実行 – 単体でデータ処理を実行 – データ処理パイプラインとして抽象化し、実行 •最近語られているストリーム処理の概念 – バッチ処理とストリーム処理の違い – ストリーム処理で発生する問題 – 問題に対する対処 •ストリーム処理のプロダクト群 – 各プロダクトの紹介 – 実際にどのプロダクトを使うべき?
  4. 4. @kimutansk ストリーム処理とは何か?
  5. 5. @kimutansk どんなものか? •「無限に発生し続けるデータを処理するよう 設計されたデータ処理モデル」 •実際に ストリーム処理と呼ばれるものがもつ性質は・・・
  6. 6. @kimutansk どんなものか? •ストリーム処理の性質 – 無限に発生し続けるデータを処理 • 常に増大し続け、本質的には無限に発生するデータを処理 • データ源自体もしばしば「ストリームデータ」と呼ばれる • システムログ、センサーデータ、人間の行動履歴等多々存在 – 処理が永続的に継続 • 常に増大し、本質的には無限に発生するデータであるため、 処理も永続的に実行される。 • バッチ処理を繰り返して実行すれば無限に発生するデータに も適用可能だが、ここではそれとは区別する。 – 低遅延、近似値&不定期な結果出力 • ストリーム処理の出力は以後に説明する性質の関係上、 しばしば近似の値だったり、不定期な出力となる。
  7. 7. @kimutansk どんな分野に使用されているか? •課金処理 – クラウド系サービスの利用料課金 – 携帯電話の通信料課金 •ライブ費用見積 – クラウド系サービスの利用状況からの課金見積り – 携帯電話の通信量見積もり •異常・変化イベント検知 – 不正ログイン検知 – システムの異常検知 – レコメンデーション •異常・変化イベント検出結果復旧 – 不正ログイン検知の結果対応 – 異常を検知したタイミングで一度停止後、再開などの対応
  8. 8. @kimutansk ストリーム処理システム構成の変遷
  9. 9. @kimutansk ストリーム処理システム構成の変遷 •OSSのストリーム処理基盤は 登場後、下記のように構成が変遷している。 – (※変遷の分類は個人の感想です) •2011年~ Lambda Architecture – バッチ処理と並列でデータ処理を実行 •2013年~ Kappa Architecture – 単体でデータ処理を実行 •2015年~ Dataflow Model(?) – データ処理パイプラインとして抽象化して実行
  10. 10. @kimutansk Lambda Architectureの時代 •Twitter(当時)のNathan氏が挙げたアーキテクチャ – How to beat the CAP theorem(※) •バッチレイヤとリアルタイムレイヤを 並行して実行し、結果をマージして表示する構成 (※)http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html
  11. 11. @kimutansk Lambda Architectureの時代 •バッチレイヤ – 大規模のデータに対して精度の高い処理が実行可能 – ただし、結果を出力するのに何時間も必要 – データが全て揃ってから実行する必要有 •リアルタイムレイヤ – 流れているデータをリアルタイムで処理可能 – 結果をNoSQLに格納し、粒度の細かい単位で更新 – 当時はデータを長期保存して使用はされなかった •上記の2レイヤの結果をマージして表示することで 精度とリアルタイム性の両立が可能となった。
  12. 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. 13. @kimutansk Kappa Architectureの時代 •Lambda Architectureの利点・問題点 •利点 – 入力データを保持し、再実行が可能な構成 •問題点 – バッチレイヤとリアルタイムレイヤで 同じ結果を生成するコードを維持するのが困難 •言ってしまえば、StormとMapReduceで同じ結果を 生成するコードを2重に実装するということ。 •抽象化して両方を実行するSummingbirdがあったが、 Summingbird自体が非常に扱いにくいもので、状況は・・・
  14. 14. @kimutansk Kappa Architectureの時代 •ストリーム処理で精度を実現するための対処 – Kafka等の複数Subscribeが可能な基盤にデータを集約 – 障害発生時は障害時のデータを再度取得して処理 – 再処理をする場合はKafkaのデータの先頭から処理 •実際、プログラムのバグなどで再処理が必要なケースはある •旧バージョンと新バージョンの結果を別テーブルに出力し、 新バージョンの処理が追いついた段階で参照を切替 •新バージョンの処理能力は並列化で増幅 •このアーキテクチャをLambda(λ)より優れた、 αに近いKappa(κ)アーキテクチャと呼んだ。 – (そもそも何故Lambdaという突込みはありますが・・) •CQRS+Event Sourcingともつながり、 アプリケーションアーキテクチャとしても使用可能
  15. 15. @kimutansk Dataflow Model(?)の時代 •(前2つを置き換えるものではないです) •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) •並行して実行されるデータ処理パイプライン としてはこの2つは同じだという考え – そのため、ストリーム処理でどちらも対応可能という スタンスを取っている。 – (※詳細は後述)
  16. 16. @kimutansk 最近語られている ストリーム処理の概念
  17. 17. @kimutansk ビッグデータ処理パターン •代表的なビッグデータ処理パターンは下表となる。 バッチ処理 対話型クエリ ストリーム処理 実行契機 手動実行 定期実行 手動実行 定期実行 常時実行 処理対象 保存済みデータ 保存済みデータ 無限に生成される ストリームデータ 処理時間 分 ~ 時間 秒 ~ 分 永続実行 データサイズ TBs~PBs GBs~TBs Bs~KBs(Per 1 event) レイテンシ 分 ~ 時間 秒 ~ 分 ミリ秒 ~ 秒 典型的な適用先 ETL レポーティング 機械学習モデル生成 BI データ分析 異常変化検知 レコメンド 可視化 OSS products MapReduce Spark Impala, Presto, Drill Hive (後述)
  18. 18. @kimutansk バッチ処理 •保存済みデータに対して実行し、 結果をデータストアに出力するモデル
  19. 19. @kimutansk 対話型クエリ •保存済みデータに対して実行し、 結果をクライアントで取得するモデル
  20. 20. @kimutansk ストリーム処理 無限のデータ源 メッセージバス ストリーム処理 エンジン 出力先 モバイルログ センサーデータ システムログ •無限に生成され続けるストリームデータに 対して実行するモデル
  21. 21. @kimutansk バッチ処理とストリーム処理の違い •大きな違いは、処理対象が完全か否か。 バッチ処理 対話型クエリ ストリーム処理 実行契機 手動実行 定期実行 手動実行 定期実行 常時実行 処理対象 保存済みデータ 保存済みデータ 無限に生成される ストリームデータ 処理時間 分 ~ 時間 秒 ~ 分 永続実行 データサイズ TBs~PBs GBs~TBs Bs~KBs(Per 1 event) レイテンシ 分 ~ 時間 秒 ~ 分 ミリ秒 ~ 秒 典型的な適用先 ETL レポーティング 機械学習モデル生成 BI データ分析 異常変化検知 レコメンド 可視化 OSS products MapReduce Spark Impala, Presto, Drill Hive (後述) 入力データは完全 入力データはストリーム!
  22. 22. @kimutansk バッチ処理の前提 •バッチ処理の前提 – 実行するタイミングでデータは完全である必要がある。 •つまり、対象のデータは「有限」となる。 – バッチをまたぐ出力は困難 •典型的なバッチ処理モデル MapReduce
  23. 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. 24. @kimutansk バッチ処理で対応しにくいパターン •ユーザのセッションを出力したい場合、日を跨ぐ。 – セッション=一定時間内の連続アクセス(ログが存在) – もしユーザが2/27と2/28を跨いでアクセスした場合、 2/27の結果の再出力が必要となるが、それは困難。 – もし、それが続いた場合・・・どうなる? MapReduce 2/282/27 2/282/27 Red Yellow Green
  25. 25. @kimutansk バッチ処理は、実は・・? •複数回バッチ実行は下図のように変形できる。 – これはすなわち・・? 2/26 2/27 2/28 2/282/272/26 Map Reduce Map Reduce Map Reduce
  26. 26. @kimutansk ストリーム処理の部分集合 •これは、すなわち無限のデータであるストリームデ ータを一定時間ごとに区切ったものに他ならない。 区切りのある有限のストリーム 時間で区切る 2/26 2/27 2/28 区切りのない無限のストリーム
  27. 27. @kimutansk ストリーム処理の部分集合 •つまり、バッチ処理とはストリーム処理の中の 限定的な処理のモデルであるいうこと。 2/26 2/27 2/28 ストリーム 処理 バッチ 処理 区切りのある有限のストリーム 区切りのない無限のストリーム 時間で区切る
  28. 28. @kimutansk バッチ処理の前提がない場合 •ストリーム処理におけるバッチの前提の扱い •バッチの前提:入力データが完全 – 常に生成され続けるストリームデータのため満たされない •バッチの前提:バッチを跨いだ出力が困難 – 常時処理かつ、処理単位が小さいため、 バッチより対応が容易 •ただ、データが完全な状況においては、 ストリーム処理はバッチ処理と同等の機能を実現可 – 「バッチ処理はストリーム処理の部分集合」のため – 管理容易性や処理の区切りやすさ等の要素は当然異なる
  29. 29. @kimutansk ストリーム処理で発生する問題 •データは発生した順に到着しない! – このことを“Out of order”と呼ぶ – 例) 携帯電話を機内モードに切り替えて搭乗 •上記の事情が発生する原因例 – ネットワーク切断・遅延 – システム中のサーバ間の時刻のずれ •上記の時刻概念として、代表的な2つを説明、 – EventTime •実際にそのイベントが発生した時刻 – ProcessingTime •実際にそのイベントを処理した時刻 •(到着した時刻が記録される場合もある)
  30. 30. @kimutansk それで何が困るのか? •もしデータ間に関連が無いのであれば、 “Out of order”であってもそれほど困らない。 – 結果が反映されるまで時間がかかるという問題はある。 •しかしながら、ストリーム処理の適用分野には、 データ間の関連を見る必要があるケースが多い。 – 例)異常・変化イベント検知の場合 1イベントで異常や変化を検知できるケースは少ない。 「短時間に特定アカウントに大量のログイン試行」など、 前後のイベントの関係が必要になる。
  31. 31. @kimutansk データのグルーピングの概念 •データのグルーピングの概念としてWindowがある Tumbling Window Time Sliding Window Sesson Window
  32. 32. @kimutansk Out of orderによるWindowの問題 •Windowを使用する際、“Out of order”の性質で 問題が発生する。 – もし[00:00 ~ 06:00]結果出力後に05:55のデータが到着 したらどう扱えばいいのか? [00:00 ~ 06:00) 1. 出力2. 到着...?
  33. 33. @kimutansk これらの問題に対する対処 •このストリーム処理で発生する問題に対して、 下記の3つの対処の概念が挙げられている。 •Watermark – EventTimeベースで、どの時刻まで処理が完了したか? •Trigger – どのタイミングで集計結果を出力するか? •Accumulation – 集計結果を複数回出力するときにどうやって蓄積するか?
  34. 34. @kimutansk Watermarkとは? •EventTimeベースでどこまで処理したかを示す概念 – EventTimeとProcessingTimeの両方が存在した場合、 各時刻間に歪みが発生するため、それを示す。 Event Time ProcessingTime 理想のシステム 実システム (≒Watermark) 歪み
  35. 35. @kimutansk Watermarkとは? •Watermarkの使用方法 – もしWatermarkの時刻が“X”だった場合、 EventTimeが”X”以前のイベントは全て処理されている。 •しかしながら・・ – Watermarkは完全にはなり得ない。 – データの到着は”Out of order”であるため、 Watermarkもあくまで近似に過ぎない。 •ただ、Watermark自体は有用 – 集計結果を出力するタイミングの基準にできる。
  36. 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. 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. 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. 39. @kimutansk Accumulationとは? •Accumulationとは、Triggerで集計結果を 複数回出力する場合にどう扱うかの方式 – ただし、「どう」するべきかは対象のシステムに依存。 •出力先システムが自前で蓄積する機能を有している場合と Key-Valueデータストアのようにデータを保持する場合で 異なる。 •加えて、システム全体で見た場合に、これらの要素が 混在するケースもあり得る。
  40. 40. @kimutansk Accumulationとは? •代表的な方式な3つのAccumulation方式がある。 – Discarding mode •集計結果を出力した際に、前の結果を破棄 •次の出力時には前回出力以降の集計結果を出力 – Accumulating mode •集計結果を出力した際に、前の結果を保持 •次の出力時には前回出力と合計して集計結果を出力 – Accumulating & Retracting mode •集計結果を出力した際に、前の結果を保持 •次の出力時には下記2つを出力 – 前回出力と合計した集計結果 – 前回出力の減算分
  41. 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. 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. 43. @kimutansk これらの対処をうてばOKか? •Watermark, Trigger, Accumulationの対処をうてば ストリーム処理のあらゆるケースに対応可能か? •残念ながら、そんなことはない。 •上記の対処をうっても、下記のような問題は残る。 – WatermarkのEventTime VS ProcessingTimeの歪みを どれだけ確保すればいいのか? •差分を大きくした場合、完全性は高まるが、 その分遅延は大きくなる。 – Accumulationの中間結果を どれだけの時間保持しておけばいいのか? •保持する時間が長いほど、必要システムリソースは増大
  44. 44. @kimutansk データ処理システムのトレードオフ •データ処理システムには 下記3要素のトレードオフがあるといわれている。 – 完全性 – 低遅延 – 低コスト •3要素をすべて満たすことは出来ない。 – 様々なデータ処理システムは、 これらのトレードオフのバランスをとる必要がある。 – このバランスの中で、システムごとに落とし所を決める。 •ここで、「コスト」はシステムリソースだけでなく、収集時 の転送路の整備や通信コストも含む。 •実際の例は・・・
  45. 45. @kimutansk トレードオフの例 •課金処理 – 重要な要素は「完全性」 – 遅延やコストが発生してもある程度は許容範囲となる。 Important Not Important 完全性 低遅延 低コスト
  46. 46. @kimutansk トレードオフの例 •異常・変化検知処理 – 重要な要素は「低遅延」 – その他の要素の優先度は下がる。 Important Not Important 完全性 低遅延 低コスト
  47. 47. @kimutansk ストリーム処理のプロダクト群
  48. 48. @kimutansk 典型的なシステム構成 無限のデータ源 メッセージバス ストリーム処理 エンジン 出力先システム Mobile activity Sensor data System log •実際のストリーム処理システムは 図のような構成を取ることが多い。
  49. 49. @kimutansk 各構成要素の詳細 •メッセージバス – 無限のデータは流量がしばしばはね上がることがある。 – 障害が発生した時など、データを再取得が必要。 – そのため、データを一時的に蓄積するのに使用する。 – 例) Kafka, Kinesis, Cloud PubSub etc... •ストリーム処理エンジン – ストリーム処理エンジンがデータを取得し、処理 – 基本的に永続実行されるため、高可用性が求められる。 – (プロダクト一覧については後述) •出力先システム – ストリーム処理システムの出力結果を使用するシステム – 実際の構成はユースケースに依存
  50. 50. @kimutansk ストリーム処理エンジンの分類 DSL UIでデータフローを 定義可能 純ストリーム処理 エンジン マネージド サービス Time to release Streams
  51. 51. @kimutansk ストリーム処理エンジン分類 • (※個人的な分類です) •純ストリーム処理エンジン – ストリーム処理エンジンの機能がメインのプロダクト – 特に特別な機能を有しないため、他のカテゴリと区別 •UIでデータフローを定義可能 – データフローを定義可能なUIを保持するプロダクト – ユーザはストリーム処理を容易に定義可能 •DSL – 一つのコードを複数のストリーム処理基盤上で実行可能 – DSLは抽象化したデータフローモデルを生成 •マネージドサービス – 実行環境がパブリッククラウド上で管理されたプロダクト •以降でプロダクトの一部を紹介
  52. 52. @kimutansk プロダクト紹介 : Storm •At 2011, opensourced by Twitter – Clojure製 •そのため、解析にはClojureが読める必要があった・・・ – 実質的に広く使われた初のOSSストリーム処理エンジン •“At least once”を初期版でサポートしていたのが大きい – ただ、初期のプロダクトなので問題も多かった。 •レイテンシは非常に低いが、スループットは小さい。 •バックプレッシャー機構が無かった。 •初期のOperatorのデフォルト配置モードが非効率。 •Ackがメッセージ単位で非常に負荷が大きい。 •現行バージョンでは大部分の問題は解消済み。 – 以後のストリーム処理プロダクトに大きく影響がある。
  53. 53. @kimutansk プロダクト紹介 : Spark Streaming •At 2013, opensourced by amplab. – Scala製 – バッチ処理フレームワークSpark上で 小バッチを実行することで擬似的にストリームを再現。 •マイクロバッチ方式と呼ばれる。 •ネイティブストリーム版も開発中。 – スループットは大きかったが、レイテンシも大きかった。 •登場時にStormと比較した場合 •FlinkやApexと比較すると・・・? – Sparkエコシステム上で開発実行可能なのが大きい。 •Sparkのコンポーネントを(すべてではないが)使用可能。 Spark SQL, Spark MLlib, etc... •開発方式も同様であるため、 バッチとストリームを近い環境で開発可能。
  54. 54. @kimutansk プロダクト紹介 : Samza •At 2013, opensourced by Linkedin. – Java/Scala製 – 「Kappa Architecture」の実現のため作成された ストリーム処理基盤をOSS化したもの。 – 最初からKafkaと組み合わせて使用されていたため、 Kafkaとの相性が非常にいい。 – KafkaのOffsetをチェックポイントとして保持することで 処理の再実行が行いやすい構成になっている。 •チェックポイント自体もKafkaに記録し、 構成がシンプルに保てるようになっている。
  55. 55. @kimutansk プロダクト紹介 : NiFi •At 2014, opensourced by NSA. – Java製 – UIで定義したデータフローをNiFiクラスタにデプロイし、 ストリーム処理を実行することが可能。 •例) Kafkaからデータを取得>情報追加>HDFSに投入 – 各Operator間でキューや帯域設定なども可能であり、 きめ細やかな制御が可能。 – データの出自や変更履歴を蓄積しており、管理機能が充実 •ただ、その分性能的には負荷は大きくなる。 – UIからデータフローが定義可能であるがゆえに、 コードでの構成管理が困難という問題も存在する。
  56. 56. @kimutansk プロダクト紹介 : NiFi
  57. 57. @kimutansk プロダクト紹介 : Flink •At 2014, opensourced. – 2011年にはStratosphereの名称 – Scala製 – バッチ用APIとストリーム用APIの両方を保持する データ処理エンジン – 耐障害性のために「分散スナップショット」方式を保持 •Lightweight Asynchronous Snapshots for Distributed Dataflows •効率的に非同期のスナップショットを取得することが可能。 – 下記の3方式の開発APIを提供し、様々なケースに対応。 •宣言的、高レベルAPI •手続き的、低レベルAPI •Streaming SQL API
  58. 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. 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. 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. 61. @kimutansk プロダクト紹介 : Apex •At 2015, opensourced by DataTorrent. – Java製 – 元々は金融アプリケーションで使用。 •耐障害性に焦点があてられている。 •障害発生時の解析の容易性も充実 •各Operator間にバッファを保持し、影響をおさえる構成 – Hadoopクラスタの上で動作させるのに適する。 •HDFSをKVSのように使用して低レイテンシで状態を管理 •YARNネイティブな基盤 – 実行中にオートスケールも可能 – Flinkと同様に3つの開発用APIを保持。
  62. 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. 63. @kimutansk プロダクト紹介 : Kafka Streams •At 2016, produed by confluent. – Java製 – Kafkaのコンポーネントの1つ – ストリーム処理アプリケーション構築用のライブラリ •Kafka streamsはクラスタ化やHA構成などは未サポート •これらの要素はユーザ側に委ねる方針を取っている。 – 実質的にKafka専用 •入力ソース、出力先はKafkaのみが標準提供 – キーとなるコンセプトはStreamsとTables •ストリームとテーブルの二重性を活用できる。 – シンプルではあるが、機能は充実 •宣言的、手続き的の2種のAPIを有しており、 クエリ可能な状態や、Window制御も可能。
  64. 64. @kimutansk プロダクト紹介 : Beam •At 2016, opensourced by Google. – Java製 – ビッグデータ用の統一処理モデルを提供 •ストリーム/バッチ両対応 – BeamのAPIを使用して開発したアプリケーションは 複数のストリーム処理エンジン上で実行可能。 •ローカル環境 •Google Cloud Dataflow(Google Cloud Platform) •Spark, Flink, Apex, Gearpump – 高いポータビリティを得ることができるが、 プロダクト固有のライブラリは使用できない。 •機械学習、グラフ処理等 •これらの要素を使用する場合は別途Tensorflowなどを 実行してカバーする必要が出てくる。
  65. 65. @kimutansk プロダクト紹介 : Cloud Dataflow •At 2015, produced by Google. – Beam APIを用いて開発された アプリケーションの実行基盤 •初期リリース時はData flow APIだった。 – マネージドサービスではあるが、 アプリケーションをデプロイするという形態のため、 広い範囲のアプリケーションに対応可能。 – マネージドサービスのため、 動的な最適化も常時行われ、性能効率が高い。
  66. 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. 67. @kimutansk 実際にどのプロダクトを使うべき? •(※あくまで個人の意見です。) •最初のアプリケーションならFlink or Apex – 機能、性能、開発容易性のバランスがいい。 •Akkaの熟練者なら、Gearpump – カスタマイズ性や性能は高い。 •Sparkユーザであれば、Spark Streaming – Sparkの既存コンポーネントとの親和性が高い。 – Structured StreamはDrizzle等今後の展望も多い。 •複数の小さいアプリケーションを組むなら、NiFi •Kafka Streamsは補助的だったり、 プロセスを自前で制御したい場合に使用する。 – 既存システムの一部をストリーム化する場合にも向く。
  68. 68. @kimutansk 実際にどのプロダクトを使うべき? •(※あくまで個人の意見です。) •Beamについては、抽象化されている関係上、 APIが生でストリーム処理基盤を使うより難解。 •加えて、現状まだまだドキュメントや実装例に ついても少なく、使うのに苦労する。 •(※個人的にはspotifyのscioが現状Beamに未対応 でScalaでかけないのが大きかったです。) •ストリーム処理基盤との結合も これからより進むと思われるため、 今は待った方がいい・・・?
  69. 69. @kimutansk まとめ •ストリーム処理の用途の歴史 – Lambda Architecture – Kappa Architecture – Dataflow Model •最近のストリーム処理で用いられる概念 – Watermark – Trigger – Accumulation •ストリーム処理プロダクトの紹介 •現時点で何を使うべきか? – (※状況はすぐに変わるため、 これはあくまで現状の意見でしかないです。)
  70. 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. 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. 72. Thank you for your attention! Enjoy Stream Processing! https://www.flickr.com/photos/neokratz/4913885458

×