ストリーミング

ストリーミングとは

ストリーミングは、イベントの無限のシーケンス（トランザクションログ、クリック、支払い、テレメトリー）に対する連続的な反応であり、最小限の遅延と状態が正しいことを保証します。「私たちは期間中に蓄積されたすべてを取る」バッチとは異なり、ストリームはデータが到着すると同時に処理し、状態を維持し、イベントの時間を考慮に入れます。

キーコンセプト

イベントは'event_time'と一意の'event_id'を持つ不変の事実です。
イベント時間と処理時間-1つ目はソースから、2つ目はオペレータが実際にイベントを見たときです。

Windows-イベントを時間ごとにグループ化：

タンブリング、ホッピング/スライド、セッション。
透かし-「Tが到着する前のイベント」という評価で、ウィンドウを閉じて遅延データの待ち時間を制限できます。
遅延-現在の透かしよりも'event_time'が小さいイベント。仕上げの規則は頻繁に適用されます。
State-集計、結合、重複排除のためのローカルテーブル/鍵付きの状態。
バックプレッシャー-下流のスループットを超えたときの圧力。プロトコルとバッファによって制御されます。

建築的基礎

1.出典：イベントブローカー（Kafka/NATS/Pulsar）、 DBのCDC、キュー、ファイル/ログコレクター。
2.ストリーミングエンジン：ウィンドウ、集計、ジョイン、パターン（CEP）を計算し、状態とチェックポイントを管理します。
3.シンク：OLTP/OLAPデータベース、検索エンジン、キャッシュ、トピック、ショーケース/レポートのストレージ。
4.スキーマレジストリ：ペイロードの進化と互換性を制御します。
5.観測性：メトリック、トレース、ログ、ラグと透かしのダッシュボード。

時間の意味論と順序

常にイベントタイムを好む：これは遅延と中断のための唯一の不変です。
イベントは順番に出ることができます。順序は党キーの内でだけ保証されます。

透かしは許可します：

窓を閉め、結果を出して下さい；
「遅延イベント（'allowed_lateness'）をどれだけ待っているか」を制限します。
後半のイベントでは、リトラクション/アップサートを使用します。集計と修正イベントの再計算です。

条件と信頼性

鍵付きの状態：集計データ（和、カウンタ、重複除外のための構造）はキーによってシャッフルされます。
チェックポイント/セーブポイント-回復のための定期的なステータススナップショット。savepoint-コードバージョン移行用の管理スナップショット。

正確に一度の効果が達成されます：

トランザクション「read-processed-write」（コミットシンク+read position）；
idempotentシンク（upsert/merge）+重複除外テーブル；
versioning aggregates（楽観的な並行性）によって。

Windows、集計、結合

Windows：

タンブリング：単純な定期的なレポート（分、時間）。
ホッピング/スライド：「スライド」メトリクス（1分単位で5分）。
セッション：カスタムセッションと不正防止のための自然。
集計：sum/count/avg/approx-distinct （HyperLogLog）、 percentiles （TDigest/CKMS）。
Stream-Stream join：キーと時間で両側をバッファする必要があり、'allowed_skew'を尊重します。
Stream-Table join （KTable）-ディレクトリまたは現在の状態（"active user limits'など）をアタッチします。

遅れて重複したデータを扱う

重複排除：'event_id'または'（producer_id、 sequence）'；「見た」キーをTTL ≥やり直しウィンドウに保存します。
Late events：閉じる（リトラクション/アップサート）後に'X'のウィンドウ後処理を許可します。
偽の重複：集計を偶発的に調整し、ログの「ALREADY_APPLIED」を修正します。

スケールとパフォーマンス

主要なsharding：平行性を提供します；ホットキーに気をつけろ。
Backpressure：公開時に並列性を制限し、バッチと圧縮を使用します。
透かし：あまり積極的にしないでください-ハードウォーターマークは予想を下げますが、遅延更新の割合を増加させます。
ステータス：サイズとアクセスパターンを考慮してフォーマット（RocksDB/state store/in memory）を選択します。TTLをきれいにして下さい。
オートスケーリング：遅延、CPU、状態サイズ、GC時間によって。

信頼性と再起動

オフセット固定を持つIdempotentシンクまたはトランザクションコミットは、正確さの基礎です。
再起動後の再処理が許可されています。効果は「正確に一度」のままでなければなりません。
DLQ/駐車場：理由のある別のスレッドに問題記録を送信します。再処理を提供して下さい。

観測可能性（測定するもの）

ソースによる遅延（時間とメッセージによる）。
ウォーターマーク/現在のイベント時間と遅延イベントの割合。
スループット/レイテンシ演算子、p95/p99エンドツーエンド。
状態サイズ/rocksdb I/O、チェックポイントレート/期間。
DLQ率、重複排除/リトレイ率。
CPU/GC/ヒープ、一時停止時間。

安全性とコンプライアンス

データ分類：図にPII/PCIをマークし、最小値を保存し、状態とスナップショットを暗号化します。
アクセス制御：トピック/ステートテーブルとシンクのACLを分離します。
Retentions：法的要件（GDPR/忘れられる権利）と一致しています。
監査：ログ'event_id'、 'trace_id'、結果：'APPLIED/ALREADY_APPLIED/RETRIEVED'。

実装パターン

1.CDC→正規化→ドメインイベント：生のデータベースの変更をブロードキャストしないでください。
2.生産者向けのアウトボックス：トランザクションファクト+イベント-1つのデータベーストランザクションで。
3.Core vs Enriched：クリティカルフローの最小ペイロード、エンリッチメント-非同期。
4.リプレイフレンドリー：投影/ショーケースはログから再構成する必要があります。
5.設計によるIdempotency：操作/イベントキー、アップサートスキーム、集計のバージョン。

テスト

ユニット/プロパティベース：集計と変換の不変量。
ストリームテスト：アウト・オブ・オーダーと重複→ウィンドウと重複除外チェックを持つ固定イベントストリーム。
ゴールデンウィンドウ：リファレンスウィンドウ/集計および許容遅延調整。
フォールトインジェクション：「記録された効果」と「コミットオフセット」の間に落ちる。
リプレイテスト：log=currentステートの最初からショーケースを再構成します。

コストと最適化

Windowsと透かしはレイテンシー/リソースに影響します。ウィンドウが長くなり「、allowed_lateness」が大きくなるほど、ステートが大きくなります。
コーデックと圧縮：CPU/ネットワークのバランスをとります。
バッチ出力：ネットワークコールとトランザクションが少なくなります。
早期フィルタリング（"pushdown'）：可能な限りソースに近い超過を破棄します。

アンチパターン

イベント時間が必要な処理時間に結び付け→誤った分析。
再起動時のシンク→ダブルエフェクトにおけるidempotencyの欠如。
グローバル「メガキー」：1つのホットパーティションが並列性を破壊します。
公開イベントとしてのRaw CDC：リークされたDBスキーマ、進化の脆弱性。
No DLQ：「毒」メッセージはパイプライン全体をブロックします。
透かしの代わりにハードディレイを修正：永遠の待機またはデータ損失のいずれか。

ドメインの例

決済/ファイナンス

ストリームの支払い。'、不正防止のためのウィンドウ（セッション+CEP）、' operation_id'による祖父。
accounting ledger （upsert+version）に投稿すると、正確に一度の効果が得られます。

マーケティング/広告

CTR/コンバージョンのスライドウィンドウ、「± Δ t」の許容値でクリックとインプレッションに参加、入札の集計。

iGaming/オンラインサービス

リアルタイムバランス/リミット、ミッション/成果（セッションウィンドウ）、不正防止パターンおよびアラート。

ミニテンプレート（擬似コード）

透かしと遅延更新のあるウィンドウ

pseudo stream
.withEventTime(tsExtractor)
.withWatermark(maxAllowedLag=2m)
.window(TUMBLING, size=1m, allowedLateness=30s)
.keyBy(user_id)
.aggregate(sum, retractions=enable)
.sink (upsert_table )//idempotent upsert by (user_id, window_start)

オフセット固定付きトランザクションシンク

pseudo begin tx upsert target_table using event, key=(k)
update consumer_offsets set pos=:pos where consumer=:c commit

生産チェックリスト

イベント時間と透かし戦略が定義されています。ウィンドウと'allowed_lateness'が選択されます。
オフセットを使用したIdempotent sinkまたはtransactionコミット。
スキーマレジストリと互換モードが有効になります。付加的な進化。
メトリクス：遅延、透かし、p95/p99、 DLQ、ステートサイズ、チェックポイント期間。
テスト：順序外、重複、再起動、再生。
状態とスナップショットのPII/保持ポリシー。
スケーリングプランとバックプレッシャー戦略。
ウィンドウ契約および調整の文書化（遅延更新）。

よくあるご質問

イベントの時間は必要ですか？
メトリックの正確さと一貫性が重要な場合は、はい。処理時間は技術的な計算/監視に適していますが、分析を歪めます。

それは正確に一度必要ですか？
ポイント：重大な効果のため。より多くの場合、少なくとも1回+idempotentシンクで十分です。

窓を選ぶ方法か？
ビジネスSLAで構築：「最後の5分→」ホッピング「、ユーザーセッション→」セッション「、分報告→」タンブリング。

遅いデータをどうするか？
制限された「allowed_lateness」と問題の調整（upsert/retract）を許可します。クライアントのショーケースを更新できる必要があります。

合計

遅延が少ないだけでなく、ストリーミングは時間、条件、契約の規律です。イベントタイム、窓、透かしの適切な選択に加え、特異な効果、観測性、テストにより、パイプラインの信頼性、再現性、経済性が向上します。

ストリーミング