リアルタイム分析

1）目的と事業価値

リアルタイム分析（RTA）は、数時間ではなく数秒で反応を提供します：

AML/Antifraud：預金の構造化、速度攻撃、リスク取引。
責任あるゲーム（RG）：限界を超え、リスクパターン、自己排除。
SRE/Operations： SLAの劣化、エラー・バースト、クラスタ過熱の早期検出。
製品とマーケティング：パーソナライゼーショントリガー、ミッション/クエスト、リアルタイムセグメンテーション。
運用レポート：ほぼリアルタイムのGGR/NGR、ホール/プロバイダのダッシュボード。

ターゲット： p95エンド・ツー・エンド0。5-5秒、完全性≥ 99。5％、可用性≥ 99。9%.

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

1.Ingest/Edge-'/events/batch '（HTTP/2/3）、 gRPC、 OTel Collector；スキームの検証、重複防止、ジオルーティング。
2.イベントバス-Kafka/Redpanda （'user_id/tenant/market'による参加、DLQ、保持3-7日）。
3.ストリーム処理-Flink/Spark Structured Streaming/Beam：ステートフル演算子、CEP、透かし、許容遅延、デッドアップ。
4.オンライン濃縮-Redis/Scylla/ClickHouseルックアップ（RG制限、KYC、 BIN→MCC、 IP→Geo/ASN）、タイムアウトとフォールバックの非同期コール。
5.サービング-ClickHouse/Pinot/Druid（操作ショーケース1-5分）、Feature Store（オンラインサイン）、webhook/ticketing/SOAR。
6.レイクハウス-長期的な統合、再生、和解のためのブロンズ/シルバー/ゴールド。
7.観測可能性-パイプラインのメトリック、トレース（OTel）、ログ、リネージ、コストダッシュボード。

3）シグナルと分類

支払い："支払い。デポジット/出金/チャージバック'。
ゲーム：'ゲーム。bet/payout'、セッション。
認証と動作：'auth。 login/failure'、 device-switch、 velocity。
動作：レイテンシ、エラーレート、ハースの再起動、飽和。
コンプライアンス：制裁審査、RGフラグ、DSARイベント。

各タイプには、ドメイン所有者、スキーマ、新鮮なSLO、および後期データポリシーがあります。

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

Windows：タンブリング（固定）、ホッピング、セッション。
透かし：「時間による知識」境界（通常は2-5分）。
遅延イベント：調整の追加の問題、フラグ'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。。。
ステータス：スライドカウンター/合計、重複排除用のブルームフィルタ、TTL。
CEPパターン：構造化（<しきい値、≥ N回、Tウィンドウあたり）、デバイススイッチ、RG疲労。

CEP擬似コード：

python if cnt_deposits(last=10MIN) >= 3 and sum_deposits(last=10MIN) > THRESH and all(d.amount < REPORTING_THRESHOLD):
emit_alert("AML_STRUCTURING", user_id, snapshot())

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

処理中の'event_id' （TTL 24-72 h）によって、バス+dedupで最低1回の配信。
順序：キーによる仕切り（ローカル順序は保証されます）。
シンク：トランザクションコミット（2フェーズ）またはidempotent upsert/merge。
Outbox/Inbox： OLTPからのドメインイベントのトランザクション発行。

7）オンラインエンリッチメントとフィーチャーストア

ルックアップ：RG制限、KYCステータス、BIN→MCC、 IP→Geo/ASN、市場/税金、イベント時のFX。
非同期呼び出し：制裁/タイムアウト付きAPP API；on error-'unknown'+retray/cache。
特徴の店：オンライン/オフラインの交渉；1つの変換コードベース。

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

ClickHouse/Pinot/Druid： second/minute aggregates、 materialized views、 1-5 minの遅延のためのSLA。
API/GraphQL：ダッシュボード/ウィジェットの低遅延。
アラート：webhooks/Jira/SOARと豊富なコンテキスト（trace_id、最後のイベント）。

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）メトリック、SLI/SLO、ダッシュボード

推奨されるSLI/SLO：

p95 ingest→alert ≤ 2 s（クリティカルルール）、≤ 5 s（その他）。
T ≥ 99ウィンドウの完全性。5%;スキーマの有効性≥ 99です。9%;追跡カバレッジ≥ 98％。
ストリームサービスの可用性≥ 99。9%;遅い比率≤ 1％です。

ダッシュボード（最小）：

パーティー/トピックによる遅延；オペレータの忙しい時間；ステートサイズ。
ファネル"sobytiye→pravilo→keys'、ドメイン別の精度/リコール。
ヒートカードの遅れ/完全性；ホットキーマップ。

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

Ingest-validations： schema/enums/size-limits、重複防止。
ストリーム上：完全性/dup-rate/late-ratio、ウィンドウの正確性（ダブルカウントなし）。
反応ポリシー：critical→DLQ+pager；major/minor→tagging+レポート。

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

11）プライバシー、セキュリティ、居住

PII最小化：IDエイリアシング、機密性の高いフィールドマスキング、PAN/IBANトークン化。
データレジデンシー：地域パイプライン（EEA/UK/BR）、個々のKMSキー。
DSAR/RTBF：ダウンストリームストアフロントでの選択的編集；ケース/レポートの法的保持。
監査：アクセス/ルールの変更、リリースログの変更できないログ。

12）経済と生産性

Sharding/keys：「熱い」キー（塩化/合成）、党のバランスを避けて下さい。
ステータス：TTL、コンパクトなスナップショット、RocksDB/ステートバックエンドチューニング。
事前集計：騒々しいテーマの初期段階で減少します。
サンプリング：非クリティカル指標（トランザクション/コンプライアンスではない）の場合のみ。
チャージバック：テーマ/ジョブの予算、リプレイクォータ、重いリクエスト。

13）プロセスとRACI

R：ストリーミングプラットフォーム（info/releases）、ドメイン分析（rules/features）、 MLOps （scoring/Feature Store）。
A：ドメイン別データ・リスク・コンプライアンス責任者。
C： DPO/Legal （PII/retention）、 SRE （SLO/インシデント）、アーキテクチャ。
I：プロダクト、サポート、マーケティング、財政。

14）実装ロードマップ

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エクササイズ。

15）例（断片）

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);
}

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

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

17）頻繁な間違いとそれらを回避する方法

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

18）ボトムライン

リアルタイム分析は「高速BI」ではなく、契約、ステートフルロジック、CEP、透かし、オンライン濃縮、厳格なSLOを備えた管理回路です。これらの慣行に従うことで、プラットフォームは数秒以内に正確なシグナルと意思決定を受け取り、コンプライアンス、製品シナリオ、オペレーションの回復力を管理コストで維持します。

リアルタイム分析

お問い合わせ

迅速な連絡

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

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