最近のストリーム処理事情振り返り
•
54 recomendaciones•17,311 vistas
Hadoopソースコードリーディング 第22回 での発表資料です。 https://www.eventbrite.com/e/hadoop-22-tickets-31987821435
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Similar a 最近のストリーム処理事情振り返り
Similar a 最近のストリーム処理事情振り返り (20)
Más de Sotaro Kimura
Más de Sotaro Kimura (12)
最近のストリーム処理事情振り返り
- 2. @kimutansk 自己紹介 •Kimura, Sotaro(@kimutansk) – ドワンゴでデータエンジニアやってます •データ分析基盤の管理 •データ分析に必要な各種ETLパイプライン構築 •生データを集計したデータマートの設計構築 •データフォーマット、内容等の設計 etc... – 好きな技術分野 •ストリーム処理（主にJVM上） •分散システム •実装言語：Scala, Go – 好きなOSSプロダクト •Apache Kafka •Apache Beam •Apache NiFi etc...
- 3. @kimutansk アジェンダ •ストリーム処理とは何か？ •ストリーム処理システム構成の変遷 – バッチと並列でデータ処理を実行 – 単体でデータ処理を実行 – データ処理パイプラインとして抽象化し、実行 •最近語られているストリーム処理の概念 – バッチ処理とストリーム処理の違い – ストリーム処理で発生する問題 – 問題に対する対処 •ストリーム処理のプロダクト群 – 各プロダクトの紹介 – 実際にどのプロダクトを使うべき？
- 6. @kimutansk どんなものか？ •ストリーム処理の性質 – 無限に発生し続けるデータを処理 • 常に増大し続け、本質的には無限に発生するデータを処理 • データ源自体もしばしば「ストリームデータ」と呼ばれる • システムログ、センサーデータ、人間の行動履歴等多々存在 – 処理が永続的に継続 • 常に増大し、本質的には無限に発生するデータであるため、 処理も永続的に実行される。 • バッチ処理を繰り返して実行すれば無限に発生するデータに も適用可能だが、ここではそれとは区別する。 – 低遅延、近似値＆不定期な結果出力 • ストリーム処理の出力は以後に説明する性質の関係上、 しばしば近似の値だったり、不定期な出力となる。
- 7. @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） •並行して実行されるデータ処理パイプライン としてはこの２つは同じだという考え – そのため、ストリーム処理でどちらも対応可能という スタンスを取っている。 – （※詳細は後述）
- 17. @kimutansk ビッグデータ処理パターン •代表的なビッグデータ処理パターンは下表となる。 バッチ処理 対話型クエリ ストリーム処理 実行契機 手動実行 定期実行 手動実行 定期実行 常時実行 処理対象 保存済みデータ 保存済みデータ 無限に生成される ストリームデータ 処理時間 分 ～ 時間 秒 ～ 分 永続実行 データサイズ TBs～PBs GBs～TBs Bs～KBs（Per 1 event） レイテンシ 分 ～ 時間 秒 ～ 分 ミリ秒 ～ 秒 典型的な適用先 ETL レポーティング 機械学習モデル生成 BI データ分析 異常変化検知 レコメンド 可視化 OSS products MapReduce Spark Impala, Presto, Drill Hive （後述）
- 21. @kimutansk バッチ処理とストリーム処理の違い •大きな違いは、処理対象が完全か否か。 バッチ処理 対話型クエリ ストリーム処理 実行契機 手動実行 定期実行 手動実行 定期実行 常時実行 処理対象 保存済みデータ 保存済みデータ 無限に生成される ストリームデータ 処理時間 分 ～ 時間 秒 ～ 分 永続実行 データサイズ TBs～PBs GBs～TBs Bs～KBs（Per 1 event） レイテンシ 分 ～ 時間 秒 ～ 分 ミリ秒 ～ 秒 典型的な適用先 ETL レポーティング 機械学習モデル生成 BI データ分析 異常変化検知 レコメンド 可視化 OSS products MapReduce Spark Impala, Presto, Drill Hive （後述） 入力データは完全 入力データはストリーム！
- 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
- 28. @kimutansk バッチ処理の前提がない場合 •ストリーム処理におけるバッチの前提の扱い •バッチの前提：入力データが完全 – 常に生成され続けるストリームデータのため満たされない •バッチの前提：バッチを跨いだ出力が困難 – 常時処理かつ、処理単位が小さいため、 バッチより対応が容易 •ただ、データが完全な状況においては、 ストリーム処理はバッチ処理と同等の機能を実現可 – 「バッチ処理はストリーム処理の部分集合」のため – 管理容易性や処理の区切りやすさ等の要素は当然異なる
- 29. @kimutansk ストリーム処理で発生する問題 •データは発生した順に到着しない！ – このことを“Out of order”と呼ぶ – 例) 携帯電話を機内モードに切り替えて搭乗 •上記の事情が発生する原因例 – ネットワーク切断・遅延 – システム中のサーバ間の時刻のずれ •上記の時刻概念として、代表的な２つを説明、 – EventTime •実際にそのイベントが発生した時刻 – ProcessingTime •実際にそのイベントを処理した時刻 •（到着した時刻が記録される場合もある）
- 30. @kimutansk それで何が困るのか？ •もしデータ間に関連が無いのであれば、 “Out of order”であってもそれほど困らない。 – 結果が反映されるまで時間がかかるという問題はある。 •しかしながら、ストリーム処理の適用分野には、 データ間の関連を見る必要があるケースが多い。 – 例)異常・変化イベント検知の場合 １イベントで異常や変化を検知できるケースは少ない。 「短時間に特定アカウントに大量のログイン試行」など、 前後のイベントの関係が必要になる。
- 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 – 集計結果を複数回出力するときにどうやって蓄積するか？
- 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());
- 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 完全性 低遅延 低コスト
- 48. @kimutansk 典型的なシステム構成 無限のデータ源 メッセージバス ストリーム処理 エンジン 出力先システム Mobile activity Sensor data System log •実際のストリーム処理システムは 図のような構成を取ることが多い。
- 49. @kimutansk 各構成要素の詳細 •メッセージバス – 無限のデータは流量がしばしばはね上がることがある。 – 障害が発生した時など、データを再取得が必要。 – そのため、データを一時的に蓄積するのに使用する。 – 例) Kafka, Kinesis, Cloud PubSub etc... •ストリーム処理エンジン – ストリーム処理エンジンがデータを取得し、処理 – 基本的に永続実行されるため、高可用性が求められる。 – （プロダクト一覧については後述） •出力先システム – ストリーム処理システムの出力結果を使用するシステム – 実際の構成はユースケースに依存
- 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からデータフローが定義可能であるがゆえに、 コードでの構成管理が困難という問題も存在する。
- 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は補助的だったり、 プロセスを自前で制御したい場合に使用する。 – 既存システムの一部をストリーム化する場合にも向く。
- 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