ストリーミングおよびストリーミング分析

1）目的と価値

ストリーミング回路は、オンザフライの意思決定を提供します：

Antifraud/AML：預金の構造化、速度攻撃、プロバイダの異常の識別。
責任あるゲーム（RG）：限界を超え、リスクパターン、自己排除。
操作/SRE： SLAの劣化、エラー・バースト、初期のインシデント信号。
製品/マーケティング：パーソナライゼーションイベント、ミッション/クエスト、リアルタイムセグメンテーション。
ほぼリアルタイムのレポート：GGR/NGRショーケース、操作パネル。

ターゲット特性：p95エンド・ツー・エンド0。5-5 s、完全性≥ 99。5％、管理された価値。

2）リファレンスアーキテクチャ

1.［挿入/エッジ］

'/events/batch '（HTTP/2/3）、 gRPC、 OTel Collector。
スキームの検証、重複防止、ジオルーティング。

2.イベントバス

Kafka/Redpanda （'user_id/tenant/market'によって分割）。
保持3-7日、圧縮、」壊れた「メッセージのためのDLQ/」隔離「。

3.ストリーミング

Flink/Spark構造化ストリーミング/ビーム。
ステートフルなステートメント、CEP、透かし、許可された遅延、重複除外。
エンリッチメント（Redis/Scylla/ClickHouse-Lookup）、非同期I/O、タイムアウト。

4.サービング/運用ディスプレイ

minute/second aggregationとダッシュボードのためのClickHouse/Pinot/Druid。
スコアモデルのためのFeature Store（オンライン）。
トピック→SOAR/チケット/Webhookを警告します。

5.長期保管（レイクハウス）

ブロンズ（生）、シルバー（クリーン）、ゴールド（サーブ）-寄木細工+デルタ/氷山/フーディ。
リプレイ/バックテスト、タイムトラベル。

6.Observability

パイプラインメトリクス、トレース（OTel）、ログ、系統。

3）スキームと契約

Schema-first： JSON/Avro/Protobuf+Registry、各イベントの'schema_version'。
進化：バックコンパチブル-新しいnullableフィールド；breaking-'/v2'+ダブルパブリケーション。
必須フィールドは「event_time」（UTC）、「event_id」、「trace_id」、「user」です。pseudo_id'、 'market'、 'source'。

4） Windows、透かし、遅延データ

Windows：

タンブリング、ホッピング、セッション。
透かし：イベントタイムの「知識」しきい値；例：2-5分。
Late data： pre-issue adjustments、「late=true」、 DLQの遅延。

Flink SQLの例（10分の沈殿物の速度）：

sql
SELECT user_id,
TUMBLE_START(event_time, INTERVAL '10' MINUTE) AS win_start,
COUNT() AS deposits_10m,
SUM(amount_base) AS sum_10m
FROM stream.payments
GROUP BY user_id, TUMBLE(event_time, INTERVAL '10' MINUTE);

5）ステートフルアグリゲーションとCEP

キー：'user_id'、 'device_id'、 'payment。。。
状態：重複排除のためのスライド合計/カウンター、セッション、bloomフィルター。
CEPパターン：構造化（<しきい値、≥ N回、Tウィンドウあたり）、デバイススイッチ、RG疲労。

CEP擬似コード：

python if deposits.count(last=10MIN) >= 3 and deposits.sum(last=10MIN) > THRESH and all(d.amount < REPORTING_THRESHOLD):
emit_alert("AML_STRUCTURING", user_id, window_snapshot())

6）丁度一度、順序およびidempotence

バス：少なくとも一度+パーティションキーはローカル順序を提供します。
Idempotence： 'event_id'+dedup state （TTL 24-72 h）。
シンク：トランザクションコミット（2フェーズ）またはupsert/merge-idempotency。
Outbox/Inbox： OLTPからのドメインイベントの発行を保証します。

7）リアルタイムの濃縮

ルックアップ：Redis/Scylla （RG制限、KYCステータス、BIN→MCC、 IP→Geo/ASN）。
非同期呼び出し：タイムアウトとフォールバックを伴う制裁/APP API（「不明」）。
FX/タイムゾーン：金額と現地市場時間（'fx_source'、 'tz'）の正規化。

8）サービングおよびリアルタイムの店頭

ClickHouse/Pinot/Druid：数分/秒による集計、実体化ビュー。
ゴールドストリーム：運用テーブルGGR/RG/AML、 ≤遅延のためのSLA 1-5分。
API/GraphQL：ダッシュボードと外部インテグレーションのレイテンシが低い。

ClickHouseの例（GGR分単位）：

sql
CREATE MATERIALIZED VIEW mv_ggr_1m
ENGINE = AggregatingMergeTree()
PARTITION BY toDate(event_time)
ORDER BY (toStartOfMinute(event_time), market, provider_id) AS
SELECT toStartOfMinute(event_time) AS ts_min,
market,
provider_id,
sumState(stake_base) AS s_stake,
sumState(payout_base) AS s_payout
FROM stream.game_events
GROUP BY ts_min, market, provider_id;

9）観察可能性およびSLO

SLI/SLO（ランドマーク）：

p95 ingest→alert ≤ 2 s （critical）、 ≤ 5 s （balance）。
T ≥ 99ウィンドウの完全性。5%.
スキーマエラー≤ 0。1%;'trace_id'を持つイベントの割合≥ 98％です。
ストリームサービスの可用性≥ 99。9%.

ダッシュボード：

パーティー/トピックラグ、忙しい時間演算子、ステートサイズ。
ファネル「sobytiye→pravilo→keys」、「ホット」キーのマップ、後半比。
コスト：コスト/GB、コスト/クエリ、チェックポイント/リプレイのコスト。

10）プライバシーとコンプライアンス

PII最小化：IDの匿名化、フィールドマスキング、PAN/IBANトークン化。
データ常駐：地域パイプライン（EEA/UK/BR）、個々の暗号化キー。
法的操作：DSAR/RTBFのダウンストリームストアフロント、ケース/レポートの法的保持。
監査：アクセスログ、変更されないソリューションアーカイブ。

11）経済と生産性

キーとシャーディング：「ホット」キー（塩化/複合キー）を避けます。
条件：合理的なTTL、スナップショット、RocksDB/バックエンド状態のチューニング。
事前集計：騒々しい流れのための前部減少。
サンプリング：非クリティカル指標で有効（トランザクション/コンプライアンスでは有効）。
チャージバック：テーマ/ジョブ、クォータ、チーム割り当ての予算。

12）ストリーミングDQ（品質）

Ingest-validation （schema、 enum、 size）、 dedup '（event_id、 source）'。
ストリームで：完全性/dup-rate/late-ratio、ウィンドウコントロール（ダブルカウントなし）。
反応ポリシー：critical→DLQ+alert；major/minor→タグを付けてクリアします。

最小ルール（YAML、例）：

yaml stream: payments rules:
- name: schema_valid type: schema severity: critical
- name: currency_whitelist type: in_set column: currency set: [EUR,USD,GBP,TRY,BRL]
- name: dedup_window type: unique keys: [event_id]
window_minutes: 1440

13）アクセスの保証および解放制御

RBAC/ABAC：スレッドを読み取るための個別の役割、ルール/モデルの変更。
デュアルコントロール：「2キー」を介したルールとモデルのロールアウト。
カナリア/A/B：ダークルールとモデルの実行、精度/リコール制御。
秘密：KMS/CMK、定期的な回転、ログ内の秘密の禁止。

14）プロセスとRACI

R（責任ある）：ストリーミングプラットフォーム（infra/releases）、ドメイン分析（rules/features）、 MLOps （scoring）。
A（説明責任）：ドメイン別データ/リスク/コンプライアンス責任者。
C（コンサルテッド）：DPO/Legal （PII/retention）、 SRE （SLO/インシデント）、 Architecture。
I（インフォームド）：製品、サポート、マーケティング、ファイナンス。

15）実装ロードマップ

MVP （2-4週）：

1.Kafka/Redpanda+2つの重要なトピック（'payment'、 'auth'）。

2.透かし、重複除外、および1つのCEPルール（AMLまたはRG）を持つFlinkジョブ。

3.ClickHouse/Pinotショーケース1-5分、ダッシュボードの遅延/完全性。

4.インシデントチャネル（Webhooks/Jira）、基本的なSLO、アラート。

フェーズ2（4-8週間）：

オンラインエンリッチメント（Redis/Scylla）、フィーチャーストア、非同期ルックアップ。
コード、カナリアリリース、A/Bとしてのルール管理。
ストリーミングDQ、パイプラインの地域化、DSAR/RTBF手順。

フェーズ3（8-12週間）：

複数の領域の活動的、what-ifリプレイシミュレータ、しきい値の自動キャリブレーション。
完全なゴールドストリームのショーケース（GGR/RG/AML）、ほぼリアルタイムを報告します。
価値ダッシュボード、チャージバック、DR演習。

16）例（断片）

Flink CEP-デバイススイッチ：

sql
MATCH_RECOGNIZE (
PARTITION BY user_id
ORDER BY event_time
MEASURES
FIRST(A.device_id) AS d1,
LAST(B.device_id) AS d2,
COUNT() AS cnt
PATTERN (A B+)
DEFINE
B AS B.device_id <> PREV(device_id) AND B.ip_asn <> PREV(ip_asn)
) MR

Kafka Streams-idempotentフィルタ：

java if (seenStore.putIfAbsent(eventId, now()) == null) {
context.forward(event);
}

17）売り上げ前のチェックリスト

レジストリ内のスキームとコントラクト、バックコンパットテストは緑色です。
透かし/許可された遅延、dedup、およびDLQが含まれています。
SLOとアラート（lag/late/dup/state size）を設定。
キャッシュとタイムアウトで強化、フォールバック「不明」。
ルール/モデルへのRBAC/デュアルコントロール、すべての変更が記録されます。
ルール、ストアフロント、ランブックのドキュメントとリプレイ/ロールバック。

18）頻繁なミスとそれらを回避する方法

イベントタイムを無視：透かしなしでは、メトリック「float」。
重複排除なし：偽のアラートとダブルカウント。
ホットキー：パーティーの歪み→塩漬け/resharding。
ホットパス内の同期フロントエンドAPI： async+cacheのみ。
管理されていないコスト：事前集計、TTL状態、クォータ、コストダッシュボード。
シミュレータの欠如：「リプレイ」なしのロールアウトは回帰につながります。

19）用語集（短い）

CEP-複雑なイベント処理。
透かし-イベントタイムによるウィンドウ準備制限。
許容遅延-遅延イベントの許容。
ステートフル演算子-保存された状態の演算子。
フィーチャーストア-コーディネートされたフィーチャーサーフィン（オンライン/オフライン）。

20）ボトムライン

ストリーミングとストリーミング分析は、契約、ウィンドウと透かし、ステートフルロジックとCEP、濃縮とリアルタイムストアフロント、SLOとオブザビリティ、プライバシーとバリューを管理する管理システムです。説明された慣行に従うことで、プラットフォームは信頼性の高いリスク検出器、運用パネル、予測可能なレイテンシとコストでパーソナライズされます。

ストリーミングおよびストリーミング分析

お問い合わせ

迅速な連絡

動画はまもなく更新されます

現在、私たちはプロジェクトで非常に多忙です