遅れの平均がわずか10秒でも、60秒の窓で数えると16.7%が別の窓に入りました。
待てば減りますが、結果が出るのは遅くなります。60秒待って0.043%、結果は120秒後です。
起きた時刻を使えます。着いた時刻で数えると、遅れの分だけ別の区切りに入ります。
Apache Flinkは、データに記録された時刻で数えられます。公式は時宜を得た流れの処理という要件は、処理する機械の時計ではなく、流れの中に記録された起きた時刻を使うことで満たせると述べています。
どちらを使うかでどれだけ変わるのか。実際に振り分けて数えました。
500,000 件を1時間ぶん作り、60秒ごとの窓で数える
起きた時刻で入れる場合と、着いた時刻で入れる場合を比べる
遅れの平均 別の窓に入った件数 割合 いちばんずれた窓の差
0.5秒 4,111件 0.8% 1窓ぶん
2秒 16,728件 3.3% 1窓ぶん
10秒 83,305件 16.7% 2窓ぶん
60秒 315,607件 63.1% 14窓ぶん
300秒 453,126件 90.6% 72窓ぶん
遅れの平均が10秒でも16.7%がずれます。窓は60秒あるのに、6件に1件は別の窓です。
60秒になると63.1%です。遅れの平均が窓の幅と同じになると、半分以上がずれます。
右端を見ると、遅れの平均が10秒でも2窓ぶんずれた件があります。平均は10秒でも、大きく遅れるものが出るからです。
300秒では72窓ぶんです。1時間前の窓に入るべき件が、いまの窓に混ざります。
この形は遅延監視の記事で扱った裾の話と同じで、平均だけでは端の振る舞いが見えません。
遅れが窓の幅に近づくと、半分以上がずれる。
These requirements for timely stream processing can be met by using event time timestamps that are recorded in the data stream, rather than using the clocks of the machines processing the data.原文Apache Flink 公式ドキュメント「Learn Flink: Hands-On Training」 この内容の有効期限2027-02-18
終わりのない流れなので、どこかで区切ります。待つほど正確になり、そのぶん遅くなります。
Apache Flinkが扱うのは、終わりのない流れです。公式は一方で流れの処理は、区切りのないデータの流れを相手にすると述べています。
終わりがないので、どこかで窓を閉じます。待つ時間でどう変わるのか実際に数えて比べました。
500,000 件。遅れの平均は 10秒（指数分布）
60秒の窓を、締め切りから何秒待って閉じるかを変える
待つ時間 間に合わなかった件数 割合 結果が出るまでの遅れ
0秒 82,788件 16.558% 60秒
5秒 50,288件 10.058% 65秒
15秒 18,286件 3.657% 75秒
30秒 4,115件 0.823% 90秒
60秒 214件 0.043% 120秒
180秒 0件 0.000% 240秒
まったく待たないと16.558%を取りこぼします。60秒待てば0.043%まで下がります。
そのかわり結果は60秒後から120秒後になります。正確さと速さがそのまま入れ替わります。
180秒待てば0件になりますが、結果は240秒後です。ゼロにする価値があるかどうかが判断の中身になります。
画面に出す数字なら、30秒待って0.823%で足りることが多くなります。請求に使うなら、後から直す仕組みのほうが要ります。
後から直す形についてはCDCの記事で扱っていて、確定した値を別に持つ組み方になります。
Stream processing, on the other hand, involves unbounded data streams.原文Apache Flink 公式ドキュメント「Learn Flink: Hands-On Training」 この内容の有効期限2027-02-18
状態は手元に置きます。だから速い代わりに、鍵の数と持つ窓の数の掛け算が量になります。
Apache Flinkは、状態を手元に置きます。公式は状態はつねに手元で読み書きされ、それが高い処理量と低い遅れを助けていると述べています。
手元に置くので、量が問題になります。実際に作って測りました。
まず1件あたりの重さを実測する。1,000,000 件を作って割ると 94 バイトだった その単価を、鍵の数と持つ窓の数の掛け算に当てる 鍵の数 窓1個ぶん 窓10個ぶん 窓60個ぶん 10,000 1MB 9MB 54MB 100,000 9MB 89MB 537MB 1,000,000 89MB 894MB 5.2GB 10,000,000 894MB 8.7GB 52.4GB
1万の鍵なら、60窓ぶん持っても54MBです。ここまでは気にする必要がありません。
100万の鍵になると5.2GBです。鍵が100倍になれば量も100倍で、掛け算のまま増えます。
減らす手は、鍵の種類を減らすか、持つ窓の数を減らすかです。後者は前の節の待ち時間と直結します。
遅れて着く分に備えるほど、過去の窓を残すことになります。待ち時間を長く取る判断は、そのまま量を増やす判断です。
3つの計測はいずれも手元で書いた模型で、実際のApache Flinkを動かしたものではありません。遅れを指数分布と置いており、実際の分布とは違います。この分布は大きく遅れるものが一定数出る形なので、待ち時間の効き方はこの前提に依存します。1件94バイトはNodeのMapでの実測値で、実際の保存形式とは違います。ここで見せているのは、遅れが小さくても窓はずれるという点と、待ちと取りこぼしが逆向きに動くという点の2つです。
State is always accessed locally, which helps Flink applications achieve high throughput and low-latency.原文Apache Flink 公式ドキュメント「Learn Flink: Hands-On Training」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る