0.5秒ごとにまとめると、処理時間の92.2%が1回ごとの固定の手間に消えました。
さばける件数は毎秒24,272件です。300秒ごとなら306,435件で、12.6倍になります。
流れを表として扱い、区切って処理します。区切りを詰めるほど、1回ごとの手間が効きます。
Spark Streamingは、流れを表として扱います。公式はこの仕組みの中心にある考えは、生きた流れを、絶えず追記されていく表として扱うことであると述べています。
追記された分を区切って処理します。区切りの間隔でどう変わるのか実際に数えて比べました。
毎秒 20,000件。1件 3.2マイクロ秒、1回のまとめに 380ミリ秒の固定の手間
まとめる間隔を変えて、処理にかかる時間と平均の遅れを見る
間隔 1回の件数 処理の時間 固定の手間の割合 平均の遅れ 1秒あたりさばける件数
0.5秒 10,000件 412ms 92.2% 0.66秒 24,272件
1秒 20,000件 444ms 85.6% 0.94秒 45,045件
5秒 100,000件 700ms 54.3% 3.20秒 142,857件
15秒 300,000件 1340ms 28.4% 8.84秒 223,881件
60秒 1,200,000件 4220ms 9.0% 34.22秒 284,360件
300秒 6,000,000件 19580ms 1.9% 169.58秒 306,435件
0.5秒ごとだと、412msのうち380msが固定の手間です。92.2%が中身の処理に使われていません。
その結果、さばけるのは毎秒24,272件です。入ってくる20,000件をかろうじて上回る程度でした。
300秒ごとなら306,435件です。12.6倍さばけますが、平均の遅れが169.58秒になります。
5秒あたりが折り合いでした。固定の手間は54.3%まで下がり、遅れは3.20秒に収まります。
この折り合いの決め方はバッチ処理の記事でも扱っていて、先に決めるのは許せる遅れのほうです。
間隔を詰めるほど、固定の手間が処理時間を占める。
The key idea in Structured Streaming is to treat a live data stream as a table that is being continuously appended.原文Apache Spark 公式ドキュメント「Structured Streaming Programming Guide」 この内容の有効期限2027-02-18
ちょうど1回を狙う作りです。そのために残すしおりは、細かすぎると本体を圧迫します。
Spark Streamingは、ちょうど1回の処理を狙って設計されています。公式は端から端までちょうど1回という意味づけを届けることが、この仕組みの設計の背景にある重要な目標のひとつだったと述べています。
そのためには、どこまで進んだかを残す必要があります。実際に数えて比べました。
毎秒 20,000件。しおりを残すのに1回 620ミリ秒かかる
1日 2回落ちるとして、24時間ぶんを見る
しおりの間隔 1日のしおり回数 しおりに使う時間 やり直す件数（1回） 1日のやり直し件数
1秒 86,400回 892.8分 10,000件 20,000件
10秒 8,640回 89.3分 100,000件 200,000件
60秒 1,440回 14.9分 600,000件 1,200,000件
300秒 288回 3.0分 3,000,000件 6,000,000件
1800秒 48回 0.5分 18,000,000件 36,000,000件
1秒ごとに残すと、1日で892.8分がしおりに使われます。1日24時間のうち約15時間です。
そのかわり落ちたときのやり直しは10,000件で済みます。1800秒ごとなら18,000,000件です。
60秒ごとなら、しおりに使うのは14.9分です。1日の1%にとどまります。
やり直しは1日1,200,000件、時間にして60秒ぶんです。この範囲なら追いつけます。
ちょうど1回を保つには、書き出し先が同じ結果に落ち着く作りである必要もあります。作り方は冪等性の記事で扱いました。
Delivering end-to-end exactly-once semantics was one of key goals behind the design of Structured Streaming.原文Apache Spark 公式ドキュメント「Structured Streaming Programming Guide」 この内容の有効期限2027-02-18
表を丸ごと持つわけではありません。それでも書き出し方によっては、毎回全部を書きます。
Spark Streamingは、表を丸ごと作るわけではありません。公式はこの仕組みは、表の全体を実体として作るわけではないことに注意することと述べています。
内部で持たなくても、書き出し方によっては全部を書きます。実際に数えて比べました。
集計の鍵は最大 50,000種。1回のまとめで 800種が新しく動く
1行 96バイトとして、書き出し方ごとの量を見る
経過したまとめ そのとき動いた鍵 動いた分だけ書く 全部を書き直す 比
1回目 800種 0.07MB 0.07MB 1.0倍
10回目 8,000種 0.07MB 0.73MB 10.0倍
60回目 48,000種 0.07MB 4.39MB 60.0倍
360回目 50,000種 0.07MB 4.58MB 62.5倍
1回目はどちらも0.07MBです。始めたばかりのうちは差が出ません。
60回目には60.0倍になります。動いた鍵が積み上がるほど、全部を書き直す形が重くなります。
この差は、動かし続けた時間に比例して開きます。短い試験では1.0倍のまま気づけません。
360回目で62.5倍、そこから先は鍵が増えないので止まります。頭打ちになるのは、鍵の種類を使い切ったときです。
3つの計測はいずれも手元で書いた模型で、実際のSparkを動かしたものではありません。1件3.2マイクロ秒、固定の手間380ミリ秒、しおり620ミリ秒といった値はすべて置いたものです。やり直す件数は落ちる時点が一様に散らばると置いた上での計算です。書き出し方の比較も、1回に動く鍵の数を一定と置いています。ここで見せているのは、間隔を詰めると固定の手間が処理時間を占めるという点と、書き出し方の差は動かし続けるほど開くという点の2つです。
Note that Structured Streaming does not materialize the entire table.原文Apache Spark 公式ドキュメント「Structured Streaming Programming Guide」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る