The Dataflow Model: A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale, unbounded, Out-of-Order Data Processing
August 7, 2021データ処理サービスは、処理の正確さ、遅延、システムの複雑さの間にトレードオフを抱える。 ストリーミング処理サービスのStorm, Samza, Pulsarは、(論文が発表された2015年時点では)メッセージ配信がexactly-onceではなく欠損や重複する。 MapReduceやSparkなどのバッチ処理サービスは、バッチ処理の単位までデータが集まらなければバッチ実行できない。 Lambda architectureは、システムの複雑化を許容し、2つのアーキテクチャを使い分けることで、処理の正確さと遅延のバランスをとる。
例示したサービスのように、データ処理サービスは、バッチ、マイクロバッチ、ストリーミングなどの特定のデータ処理パターンに特化し、プログラマは特化したパターンのプログラミングモデルで処理を実装しなければならない。
他方、GCPのデータ処理サービスDataflowは、同じプログラミングモデルで、さまざまなデータ処理パターンの大規模並列処理を実装できる。
Dataflowにおけるデータの処理単位をウィンドウといい、ウィンドウの区切り方を調整することで、特定のデータ処理パターンに処理を最適化する。
たとえば、バッチ処理であれば全てのデータを一つのウィンドウに詰め込める。
マイクロバッチであれば、処理対象のデータが一定数集まった時点でウィンドウを発行する。
ストリーミングであれば、新しく到達した一件ごとデータを一つのウィンドウとしてあつかう。
ウィンドウ内部の処理は、キーと値のペアのシーケンスを別のシーケンスに変換するparDo関数と同じキーをもつ複数のペアを一つのペアに集約するGroupByKey関数の組み合わせによって実装される。
論文をこちらからダウンロードできます。