Streaming 101
自己紹介
FOLIOというスタートアップでScala書いたりしてる
仕事でストリーム処理しているわけではないけど勉強目的で参加
昔、仕事でKafkaをいじったりしていたことはある(Sparkとかは知らない)
本日
イントロダクションなので内容的には薄め
早く終わるかも😇
質問はチャットでも途中でも!
参考にできそうな文献
ストリーム処理やりたい理由
低レイテンシでビジネスインサイトを得られる
膨大なデータの処理がやりやすい
データが到着し次第処理を開始することでワークロードが時間的に分散される
ストリーム処理は長い間未熟なままだったけど徐々に支持が得られてきている
Streamingとは
ストリーム処理はいろいろな意味で使われている。
ここではある程度この言葉を正確に定義する。
whatである何をすべきか (無制限のデータの処理など)とhowである方法論(ストリーム処理エンジンを使うこと)がごっちゃに語られている。
後者の定義を採用していると特に古くからストリーム処理システムの制限(結果が近似的になるなど)が実際には解決可能であるにも関わらず”ストリーム処理”という言葉に内包されてしまう問題がある。well designedなストリーム処理システムは上記のような制限はなく正しく一貫性のある結果を生成可能であるので、ストリーム処理という言葉を正確に定義したい。
Streaming System
データ処理エンジンの一種で、無限のデータセットを想定して作成されているもの。
低遅延、近似的(or 推測的)な結果を意味したい場合はStreaming Systemではなく他の言葉を使います。
その他の用語としてcardinality, constitutionに関する用語も定義する
cardinality
bounded data
有限サイズのデータセット
unbounded data
(少なくとも理論的には)無限のサイズを持つデータセット
constitution (chapter 6,8,9などで詳しく扱う)
Table
データセットの特定時点での全体的なview
SQLが伝統的に処理するのはテーブル
Stream
データセットの時間経過に伴う変化を要素ごとに観測できるview
Map-Reduce系のデータ処理システムは、伝統的にストリームを扱ってきている
ストリーミングの限界(誇張版)
ストリーム処理は歴史的に低レイテンシ・不正確な結果というニッチな市場においやられてきた
最終的な正しさを保証するためにバッチと組み合わせるといったことがよく行われていた
= Lambda アーキテクチャ
Lambdaアーキテクチャは運用が面倒
パイプラインが別
パイプラインの結果のマージが必要
Kappaアーキテクチャへ
Kafkaのようなreplayableなシステムを使う
一つのパイプラインでデータ処理を行える
stream処理はbatch処理のsupersetだというのが著者の主張
flinkはbatch modeでもstream処理として動作する
Lambdaアーキテクチャを古代のものにする(バッチをストリーム処理に統合する)ためには2つの概念が必要
Correctness
一貫性のあるストレージに帰着される
チェックポイントに状態を保存する必要がある
故障などにも対応する必要がある
Spark Streamingが良い例(らしい)
Tools for reasoning about time
unbounded, unordedなデータがイベント時間スキューを持ってやってくる
ここからはイベント時間スキューについて見ていく
コラム: Batch and Streaming Efficiency Differences
バッチは高いスループットを出せるがレイテンシも高い
ストリーム処理はスループットは低いがレイテンシも低い
これはストリーム処理の制限ではなく個々の実装の歴史的な設計判断によるもの
Google Cloud Dataflowの例
同一のモデルでbatch と streaming 2つの個別に最適化されたランナーがある(内部実装的に別のシステム)
ランナーも将来的には単一にしたい(らしい)
Event Time Versus Processing Time
Event time
イベントが実際に起きた時刻
Processing time
システムがイベントを観測した時刻
理想的な世界では両者は一致するが、現実には時刻は一致しない。
さらに時刻のずれは一定ではなく様々な要因で変化する(リソースの制限、分散システムの仕組み、データの特徴)
https://scrapbox.io/files/62af1a41e737a00020e9b6aa.png
実際に重要なのはEvent Timeだが簡単ではない。歴史的には多くのストリーム処理システムがProcessing Timeをベースにwindow化を行ってunboundedなデータに対する処理を行っている。が、そうするとEvent Timeとは関連しないwindowにイベントが区分される可能性がある。
あるEventTime Xまでのすべてのデータを観測し終わったら処理を行うことができれば楽だが、それは一般的には難しい。
無限のデータを有限のデータにして、結果的に完成するような物ではなく現実の不確実なデータに対応できるツールが必要になってくる。(古いデータが更新されたり撤回されたりする可能性があるような状況にも耐えられるシステム)