ストリームと Kafka

注文・クリック・DB の変更などの出来事を、複数のシステム（DWH・検索・通知など）にすぐ届けたいとき、送る側が受け手ごとに直接つなぐと、受け手が増えるたび・止まるたびに送る側を直すことになります。間に Kafka のようなメッセージブローカー（メッセージを預かり、受け手に渡す仕組み）を置くと、送る側は書くだけ、受け手はそれぞれのペースで読むだけになります。

データエンジニアにとっては、ストリーム処理や CDC の土台です。面接でも、順番・重複・並列度の3つはよく聞かれます。

Kafka は、イベントを順番にためておく「追記専用のログ」です。書く側（プロデューサー）はトピックにイベントを書き、トピックはパーティションに分かれて複数のサーバーに置かれます。読む側（コンシューマー）はコンシューマーグループを作り、パーティションを分担して並列に読みます。読んだ位置（オフセット）を記録しておくので、落ちても続きから読めますし、保持期間の中なら過去にさかのぼって読み直すこともできます。

下の「ブラウザで試す」の図では、プロデューサーがキー（user_id）のハッシュでパーティションを決めて書き、3台のコンシューマーがパーティションを1つずつ分担して読み、処理したところまでのオフセットをコミットします。後半では、コンシューマー 3 が止まり、リバランスで残りの2台が分担をやり直して、最後にコミットされたオフセットから読み直す様子を見られます。上の表の「順番は同じパーティションの中だけ」「再送で重複し得る」「パーティション数が並列度の上限」が、それぞれどの手順から来るかに注目してください。

同じキー（例：order_id）のイベントは同じパーティションに入るので、「注文作成 → 支払い → 発送」の順番は守られます。キーを決めずに送ると、ばらばらのパーティションに入り、順番が入れ替わります。順番が大事なものは「どの単位で順番が要るか」を考えてキーにします。ただしキーが偏る（1人の大口ユーザー）と、1つのパーティションに集中して遅れます。また、あとからパーティション数を増やすと、キーと行き先の対応が変わる点にも注意します。

コンシューマーは「処理してからオフセットを記録する」のが基本です。処理の後、記録の前に落ちると、再起動後に同じイベントをもう一度処理します。そのため受け取る側を冪等（同じものを2回処理しても結果が同じ）にします。

-- イベント ID を主キーにして、2回目は何もしない（PostgreSQL の例）
INSERT INTO payments (event_id, order_id, amount, paid_at)
VALUES (:event_id, :order_id, :amount, :paid_at)
ON CONFLICT (event_id) DO NOTHING;

Kafka にはプロデューサーの重複を防ぐ設定（enable.idempotence）やトランザクションもあり、Kafka の中で読んで書く処理なら「ちょうど1回」に近づけられます。ただし外部の DB への書き込みまでは守られないので、結局は書き込み先の一意キーや MERGE で重複を吸収するのが確実です。

監視の要はコンシューマーラグ（書かれた位置と読んだ位置の差）です。ラグが増え続けるなら、処理が追いついていません。

ラグは件数のほかに時間（いちばん古い未処理のイベントが何秒前か）でも見ると、利用者への影響（データが何分古いか）で説明できます。

ストリームで「5分ごとの注文数」を出すには、終わりのない流れを時間で区切ります。この区切りをウィンドウと呼びます。区切りは、イベントが起きた時刻（イベント時刻）で決めるのが基本です。届いた時刻で区切ると、遅れて届いたイベントが別の区切りに数えられてしまいます。

ウォーターマークは「この時刻より前のイベントは、もうほぼ届いた」とみなす目安です。ウォーターマークを過ぎたら区切りの結果を確定して出します。それより遅れたイベントは、捨てる・別に記録する・結果を更新するのどれかを決めておきます。

ストリーム処理には Apache Flink、Spark Structured Streaming、Kafka Streams などの道具や、クラウドの管理サービスがあります。どれも「状態（途中の集計）を持ちながら、イベントを1件ずつ、または小さな塊で処理する」仕組みです。

バッチとストリームで同じ指標を別々に計算すると、2つの数字がずれます。ストリームの結果は「速報」、バッチで作り直した結果を「確定」として、利用者に区別を伝えるのが現実的です。