GH GambleHub

ストリームとバッチ解析

1)簡単なgist

ストリーム-数秒でのイベントの連続処理:不正防止/AML、 RGトリガー、SLAアラート、運用パネル。
バッチ-完全な再現性を備えた定期的な再計算:規制報告(GGR/NGR)、財務文書、MLデータセット。

ランドマーク: ストリームp95 e2e 0。5-5 s、バッチD+1から06:00(ロック).

2)選択行列(TL;DR)

[基準]ストリーミングBatch(バッチ)
SLA反応秒/分時間/日
完全性高い、しかし遅い修正は可能です非常に高い、制御D+1
「as-of」の再現性"より硬い(リプレイ)簡単(タイムトラベル/スナップショット)
1台あたりのコストより高価なオンライン方法容積ごとのより安い
典型的なタスクAML/RGアラート、SRE、リアルタイムショーケースレポート、和解、MLオフライン
履歴化(SCD)制限的に完全に
規制/WORMviaゴールドレビューネイティブ(ゴールド/D+1)

80/20ルール:反応を必要としないものは何でも<5分-バッチ;残りはStreamにあり、Batch nightの検証があります。

3)アーキテクチャ

3.1ラムダ

統合のためのオンライン+バッチのためのストリーム。プラス:柔軟性。マイナス:2つの論理。

3.2カッパ

すべてはストリームのようなものです。バッチ=ログを介して「リプレイ」。プラス:単一のコード。マイナス:リプレイ/コストの複雑さ。

3.3レイクハウスハイブリッド(推奨)

ストリーム→オンラインOLAPマート(分)とブロンズ/シルバー;バッチはゴールド(D+1)を再構成し、レポートを公開します。

4)データと時間

ストリーミング

Windows:タンブリング/ホッピング/セッション。
透かし:2-5分;遅いデータはマークされ、薄暗くされます。
ステートフル:CEP、 dedup、 TTL。

バッチ

増分/CDC: 'updated_at'、ログ・レプリケーション。
SCD I/II/III:属性履歴。
スナップショット:「as-of」の日/月レイヤー。

5) iGamingのアプリケーションパターン

AML/Antifraud:ストリーム(速度/構造化)+バッチ調整とケース。
責任あるゲーム:制限/自己排除のストリームコントロール。バッチレポートレジスタ。
操作/SRE:ストリームアラートSLA;インシデントとトレンドの一括分析。
製品/マーケティング:ストリームパーソナライゼーション/ミッション;バッチコホート/LTV。
財務/レポート:バッチ(ゴールドD+1、 WORMパッケージ)、ストリーム-運用パネル。

6) DQの再現性、再生

Stream DQ:スキームの検証、dedup '(event_id、 source)'、ウィンドウの完全性、late-ratio、 dup-rate;critical DLQ→。
バッチDQ: 一意/FK/範囲/時間、 OLTP/プロバイダとの和解;critical→fail job+report。

再現性:
  • ストリーム:レプリカトピックの範囲別+決定論的変換。
  • バッチ:タイムトラベル/ロジックバージョン('logic_version')+ゴールドスナップショット。

7)プライバシーと居住

ストリーム:匿名化、オンラインマスキング、地域パイプライン(EEA/UK/BR)、外部PIIルックアップへのタイムアウト。
バッチ:PIIマッピング分離、RLS/CLS、 DSAR/RTBF、リーガルホールド、WORMアーカイブ。

8)コストエンジニアリング

ストリーム:「ホット」キー(塩漬け)を避け、非同期ルックアップ、TTL状態、事前集約を制限します。
バッチ:パーティショニング/クラスタリング、小さなファイル圧縮、安定した集計の具現化、クォータ/起動ウィンドウ。

9)例

9.1ストリーム-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);

9.2ストリーム-CEP (AML擬似コード)

python if count_deposits(10MIN) >= 3 and sum_deposits(10MIN) > THRESH \
and all(d. amount < REPORTING_LIMIT for d in window):
emit_alert("AML_STRUCTURING", user_id, snapshot())

9.3バッチ-MERGE(シルバー増分)

sql
MERGE INTO silver. payments s
USING stage. delta_payments d
ON s. transaction_id = d. transaction_id
WHEN MATCHED THEN UPDATE SET
WHEN NOT MATCHED THEN INSERT;

9.4バッチ-ゴールドGGR (D+1)

sql
CREATE OR REPLACE VIEW gold. ggr_daily AS
SELECT
DATE(b. event_time) event_date,
b. market, g. provider_id,
SUM(b. stake_base) stakes_eur,
SUM(p. amount_base) payouts_eur,
SUM(b. stake_base) - SUM(p. amount_base) ggr_eur
FROM silver. fact_bets b
LEFT JOIN silver. fact_payouts p
ON p. user_pseudo_id = b. user_pseudo_id
AND p. game_id = b. game_id
AND DATE(p. event_time) = DATE(b. event_time)
JOIN dim. games g ON g. game_id = b. game_id
GROUP BY 1,2,3;

10)メトリックとSLO

ストリーム(ランドマーク)

p95 ingest→alert 2-5 c completeness 99 。5%

schema-errors ≤ 0。1%

遅延比率≤ 1%

99 ≥可用性。9%

バッチ(ランドマーク)

ゴールドだ。毎日06:00ロックまで準備ができています。

完全性≥ 99。5%

有効期限≥ 99です。9%

MTTR DQインシデント≤ 24-48時間

11)テストとリリース

契約/スキーム:消費者主導のテスト;back-compat CI。
ストリーム:カナリアルール、ダークローンチ、リプレイシミュレータ。
バッチ:サンプルでのドライラン、メトリックの比較、調整。

12)アンチパターン

重複ロジック:数式の整列なしで異なるストリーム計算とバッチ計算。
キャッシュ/タイムアウトなしでストリームホットパス内の同期外部API。
incrementsの代わりに「just in case」をフルリロードします。
透かし/遅延ポリシーはありません。
分析レイヤーのPII;CLS/RLSはありません。
金は「変異する」ことを遡及的に示します。

13)推薦された雑種(playbook)

1.ストリームループ:ingest→bus→Flink/Beam(透かし、dedup、 CEP)→

1-5分のパネルのためのOLAP (ClickHouse/Pinot)+青銅/銀(付加)。
2.バッチループ:増分/CDC→シルバー正規化/SCD→ゴールドデイリーディスプレイ/レポート(WORM)。
3.マッチング:メトリックの単一のセマンティック層;夜間Stream↔Batch和解;不一致>しきい値→チケット。

14) RACI

R(責任ある):ストリーミングプラットフォーム(ストリーム情報)、データエンジニアリング(バッチモデル)、ドメイン分析(メトリック/ルール)、MLOps(機能/フィーチャーストア)。
A(説明責任):データ/CDOの責任者。
C(コンサルティング):コンプライアンス/リーガル/DPO、ファイナンス(FX/GGR)、リスク(RG/AML)、 SRE (SLO/стоимость)。
I(インフォームド):BI/製品/マーケティング/オペレーション。

15)ロードマップ

MVP (2-4週):

1.Kafka/Redpanda+2つの重要なトピック('payments'、 'auth')。

2.Flinkジョブ:watermark+dedup+1 CEPルール(AMLまたはRG)。

3.OLAPショーケース1-5 min+ダッシュボードの遅延/遅延/dup。

4.レイクハウス・シルバー(ACID)初のゴールド。ggr_daily (D+1まで06:00)。

フェーズ2(4-8週間):
  • ドメイン別の増分/CDC、 SCD II、セマンティックメトリクス層。
  • ストリーミングDQと夜間Stream↔Batch和解。
  • 地域化(EEA/UK/BR)、 DSAR/RTBF、リーガルホールド。
フェーズ3(8-12週間):
  • リプレイシミュレータ、ルール/メトリクスのカナリア/A-Bリリース。
  • コスト・ダッシュボードとクォータ;階層型ストレージ;DRの教え。
  • ショーケース/メトリクスのドキュメントとリネージの自動生成。

16)実装チェックリスト

  • レジストリ内のスキーム/契約;バックコンパットテストは緑色です。
  • ストリーム:透かし/allowed-lateness、 DLQ;prodのOLAPパネル。
  • バッチ:increments/CDC、 SCD II、 WORMエクスポートのゴールドD+1。
  • メトリクスの単一セマンティック層;夜間Stream↔Batch和解。
  • 鮮度/完全性/有効性DQボード;alert lag/late/dup。
  • RBAC/ABAC、暗号化、居住;DSAR/RTBF/Legal Hold。
  • 管理下のコスト(コスト/GB、コスト/クエリ、ステートサイズ、リプレイはクォータ割り当て)。

17)ボトムライン

ストリームとバッチは競合他社ではなく、同じドライブの2つのギアです。ストリームは、午前中に「バッチ-検証可能な真実」、「今ここで」反応を与えます。"Hybrid Lakehouseアプローチ、単一のレイヤーのメトリクス、およびDQ/Lineage規律により、SLAとコストに最適な高速で再現性のある準拠した分析輪郭を構築できます。

Contact

お問い合わせ

ご質問やサポートが必要な場合はお気軽にご連絡ください。いつでもお手伝いします!

統合を開始

Email は 必須。Telegram または WhatsApp は 任意

お名前 任意
Email 任意
件名 任意
メッセージ 任意
Telegram 任意
@
Telegram を入力いただいた場合、Email に加えてそちらにもご連絡します。
WhatsApp 任意
形式:+国番号と電話番号(例:+81XXXXXXXXX)。

ボタンを押すことで、データ処理に同意したものとみなされます。