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におけるデータの処理単位はウィンドウとよばれる。 Dataflowのプログラミングモデルは、ウィンドウ内のデータを、キーと値のペアのシーケンスを別のシーケンスに変換するparDo関数と同じキーをもつ複数のペアを一つのペアに集約するGroupByKey関数を組み合わせる設計である。

ウィンドウの区切り方を調整することで、特定のデータ処理パターンに処理を最適化する。 たとえば、バッチ処理であれば全てのデータを一つのウィンドウに詰め込める。 マイクロバッチであれば、処理対象のデータが一定数集まった時点でウィンドウを発行する。 ストリーミングであれば、新しく到達した一件ごとデータを一つのウィンドウとしてあつかう。


論文をこちらからダウンロードできます。