GH GambleHub

데이터웨어 하우스

1) iGaming에서 DWH의 목적 및 역할

DWH는보고, 분석, 규정 준수 및 ML을위한 중앙 데이터 통합 및 서비스 계층입니다. 다음을 제공합니다

일반적인 메트릭 정의 (GGR/NGR, ARPPU, Retention, Churn).
규제 기관 및 내부 이해 관계자를위한 재현 가능한 보고서.
BI/운영 패널을위한 빠른 상점 및 모델 용 소스.
플랫폼 수준의 품질 관리, 계보 및 안전.

2) 건축 옵션

2. 1 클래식 DWH

ETL → DWH → BI.
장점: 관리 가능한 모델, 강력한 일관성.
단점: 값 비싼 다운로드, 복잡한 백필, 제한된 유연성.

2. 2 레이크 하우스 DWH

ACID 테이블 (Delta/Iceberg/Hudi) 의 브론즈/실버/골드 + SQL/MPP 엔진.
장점: 통합 스토리지, 시간 여행, 간단한 재 처리.
단점: 레이어와 DQ, 성숙한 오케스트레이션이 필요합니다.

2. 3 하이브리드

고속 판독을위한 "진리의 원천" (청동/은), MPP (ClickHouse/Pinot/Druid/Cloud DWH) 의 DWH-March 인 Lakehouse.
장점: 비용과 성능의 균형, 유연한 상점.
단점: 회로 및 스케이트에 대한 이중 지원, 동기화가 필요합니다.

권장 사항: iGaming-Lakehouse + DWH-March (하이브리드). 청동/은-표준화, 금/실시간 마트-판독 하중을 제공합니다.

3) 데이터 모델링

3. 1 별과 눈송이

사실 테이블: 좁고 이벤트 중심: 'fact _ bets', 'fact _ payouts', 'fact _ payment'.
차원: 'dim _ users' (SCD), 'dom _ games', 'dom _ providers', 'dom _ markets'.
눈송이는은 (정규화), 별-금 (읽기) 에 적합합니다.

3. 2 데이터 금고 2. 0 (통합 코어)

허브 (비즈니스 키), 링크 (관계), 위성 (컨텍스트/히스토리).
오래 지속되는 공급자/PSP 통합을 위해 Silver에 적용하십시오.

3. 3 SCD I/II/III

RG/KYC/채널 및 게임 속성 (RTP/변동성) 용 SCD II.

(PHP 3 = 3.0.6, PHP 4)

4) 로드: ETL/ELT, CDC 및 증분

ELT 접근 방식: DWH에서 실버 → 변환으로로드

CDC: OLTP의 데베 지움/로그 복제; merzhi는 demotent입니다.
증가: 시간별 물 ('업데이트 된 _ at> max _ loaded _ ts') 및/또는 해시 델타.
백필/재 처리: 시간 이동, 범위, 할당량, 건식 비교.

메르스 (예):
sql
MERGE INTO silver. payments s
USING stage. payments_delta d
ON s. transaction_id = d. transaction_id
WHEN MATCHED THEN UPDATE SET
WHEN NOT MATCHED THEN INSERT;

5) 시맨틱 레이어 및 메트릭

메트릭 스토어/시맨틱 레이어: 균일 한 공식 GGR/NGR/변환/LTV.
재현성을위한 검증 메트릭 및 "현재" 계산.
규칙은 미터법 이름, 단위, 통화 (기본 EUR) 및 'fx _ source' 입니다.

6) 창고 및 서빙

골드 쇼케이스: 비정규화, SLA 준비 (예: 06:00 잠금) .
운영 마트: 1-5 분 패널을위한 Clickhouse/Pinot/Druid.
내보내기: CS/JSON/PDP + 해시; 레귤레이터를위한 불변의 패킷 (WORM).

GGR 일일 예:
sql
CREATE OR REPLACE VIEW gold. ggr_daily AS
SELECT
DATE(b. event_time) AS event_date,
b. market,
g. provider_id,
SUM(b. stake_base) AS stakes_eur,
SUM(p. amount_base) AS payouts_eur,
SUM(b. stake_base) - SUM(p. amount_base) AS 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;

7) 데이터 품질 (DQ) 및 계약

스키마 우선: JSON/Avro 레지스트리 + 호환성 테스트 (소비자 중심).
DQ-ка달력: 완전성/유효성/고유성/FK/range/temporal.
반응 정책: 중요 → 실패 + DLQ; 메이저/마이너 → 태그 및보고.
DQ 관찰 가능성: 신선도/완전성/유효성 대시 보드, 손실 된 기록 깔때기.

8) 보안, 개인 정보 보호 및 거주

PII 최소화: 의사 ID를 통한 사용자; 별도로 매핑.
RLS/CLS: 역할 및 관할권에 의한 라인 별/테이블 이용.
암호화: TLS 운송 중; 휴식 시간-회전시 KMS/CMK.
데이터 레지던시: EEA/UK/BR에 대한 별도의 디렉토리 및 키; 이유없이 지역 간 가입 금지.
DSAR/RTBF: 계산 가능한 투영 및 선택적 편집; 아티팩트보고에 대한 법적 보류.

9) 성능 및 비용 (비용 공학)

분할: 날짜/시장/임차인; 'market', 'provider _ id', 'game _ id', 'user _ pseudo _ id' 별 클러스터링/Z 주문.
형식: Parquet + 통계 및 압축; 일정에 따라 OPTIMIZE/VACUUM.
재료화: 안정적인 집계 및 요약 테이블; "지방" 이 즉시 결합되는 것을 피하십시오.
Quotas/Chargeback: 무거운 요청/재생 예산; 비용/쿼리, 비용/GB를보고합니다.
계층 형 보관: 뜨거운/따뜻한/차가운; 명확한 복구 SLA.

10) 관찰 및 관리

파이프 라인 메트릭: 지속 시간, 볼륨, 리트레이, 지연, 내결함.
DWH 지표: 응답 시간/경쟁력/캐시 적중/값.
계보: 소스에서 보고서까지의 그래프; 변화에 대한 영향 분석.
SLO: Freshness Silver p95 매일 금-06: 00까지 준비; 유효성 이상 99. 9%; 완전성 이하 99. 5%; 가용성은 99 이상입니다. 9%.

11) 멀티 테넌시 및 도메인 격리

스키마/데이터베이스/카탈로그를 테넌트/마켓으로 나눕니다.
쿼타 및 리소스 그룹; "시끄러운 이웃" 을 제한합니다.
세입자 간 수출/수입 정책, 표준화 된 계약.

12) 데이터 등록 및 문서

데이터 카탈로그: 소유자, SLA, 스키마, 예, DQ 규칙, 계보.
메트릭/대시 보드: 공식적이고 책임있는 카드.
로그 변경: 논리, 마이그레이션, 영향 버전.

13) 프로세스 및 RACI

R (책임): 데이터 엔지니어링 (모델 실버/골드, DAG 'i), 데이터 플랫폼 (인프라, 레지스트리, DQ).
A (책임): 데이터/CDO 책임자.

C (컨설팅): 규정 준수/법률/DPO, 금융 (FX/GGR), 위험 (RG/AML), SRE (SLO/стои

I (정보): BI, 제품, 마케팅, 운영.

14) 구현 로드맵

MVP (4-6 주):

1. Lakehouse Bronze/Silver (ACID 테이블), CDC/지불/게임 플레이 증분.

2. 첫 번째 골드 쇼케이스 (GGR Daily, 변환), SLA는 06: 00까지 제공됩니다.

3. DQ와 유사한 코드 (10-15 규칙) + 신선도/완벽한 대시 보드.

4. 데이터 카탈로그 및 기본 시맨틱 메트릭 계층.

2 단계 (6-12 주):
  • SCD II 지정자/게임/공급자; 도메인 확장.
  • 실시간/실시간 패널 용 온라인 March (ClickHouse/Pinot).
  • 계보/충격 분석, DSAR/RTBF 절차, 지역화 (EEA/UK).
3 단계 (12 주 이상):
  • 변경 사항의 자동 시뮬레이션 (건식), 재생 및 메트릭 비교.
  • 충전기/할당량, 비용 대시 보드; DR 운동 및 시간 여행 회복.
  • 쇼케이스 문서 및 메트릭 카드의 자동 생성.

15) SQL 템플릿의 예

실제 요금 (실버, 3NF):
sql
CREATE TABLE silver. fact_bets (
bet_id STRING PRIMARY KEY,
user_pseudo_id STRING NOT NULL,
game_id STRING NOT NULL,
stake_ccy DECIMAL(18,2) NOT NULL,
currency CHAR(3) NOT NULL,
stake_base DECIMAL(18,2) NOT NULL,
market CHAR(2) NOT NULL,
event_time TIMESTAMP NOT NULL
);
SCD II에 연결 (내기 시점에 RG 상태를 얻으십시오):
sql
SELECT b. bet_id, u. rg_status
FROM silver. fact_bets b
JOIN dim. users_scd u
ON u. user_pseudo_id = b. user_pseudo_id
AND b. event_time >= u. valid_from
AND (u. valid_to IS NULL OR b. event_time < u. valid_to);
시장 별 완벽한 통제:
sql
SELECT market, DATE(event_time) d, COUNT() n
FROM silver. fact_bets
GROUP BY market, DATE(event_time)
HAVING n = 0;

16) 사전 판매 점검표

  • 레지스트리의 계획 및 계약, 호환성 테스트는 녹색입니다.
  • CDC/증분 및 MERGE 절차는 엄청납니다.
  • 골드 쇼케이스에는 SLA가 있으며 미터법 공식이 고정되어 있습니다.
  • DQ 규칙이 활성화되어 있습니다 (중요 → 실패 + DLQ), 신선도/완벽한 대시 보드.
  • RBAC/ABAC, 암호화, 지역 별 거주, 액세스 로그.
  • 계보/충격 가능; 시간 여행/백업/DR 확인.
  • 통제되는 비용: 당사자, 군집, 구체화, 할당량.

17) 반 패턴 및 위험

"층이없는 하나의 지방 DWH": 원시 및 보고 된 데이터 → 혼돈과 값 비싼 수정의 혼합.
불필요하게 매일 완전 재 장전: 증분/CDC 사용.
소유자와 공식이없는 금: 진실의 단일 버전의 부족 → 분쟁과 회귀.
분석 계층의 PII: 매핑을 분리하여 CLS/RLS로 유지하십시오.
DQ/계보 없음: 규제 기관/감사에 대한 증거가 없습니다.
관리 할 수없는 비용: 배치/최적화/할당량 없음.

18) 용어집 (브리핑)

DWH는 통합 및 분석을위한 데이터 하우스입니다.
레이크 하우스-데이터 레이크 + ACID 테이블 및 SQL 엔진.
CDC-OLTP에서 변경 사항을 캡처합니다.
SCD-천천히 측정이 변경됩니다 (I/II/III).
골드 쇼케이스-즉시 소비 할 수있는 보고서 시트/프리젠 테이션.
시맨틱 레이어-메트릭 및 속성의 균일 한 정의.

19) 결론

iGaming의 최신 DWH는 "큰 테이블" 이 아니라 관리 가능한 플랫폼: 청동/은/금 계층, 엄격한 계약 및 DQ, 균일 한 지표 및 계보, 개인 정보 보호 및 거주, 성능 및 효율성. Lakehouse + DWH-March 하이브리드를 구축함으로써 감사, 규모 및 새로운 시장에 대한 빠르고 검증 가능한 의사 결정을 내릴 수 있습니다.

Contact

문의하기

질문이나 지원이 필요하시면 언제든지 연락하십시오.우리는 항상 도울 준비가 되어 있습니다!

Telegram
@Gamble_GC
통합 시작

Email — 필수. Telegram 또는 WhatsApp — 선택 사항.

이름 선택 사항
Email 선택 사항
제목 선택 사항
메시지 선택 사항
Telegram 선택 사항
@
Telegram을 입력하시면 Email과 함께 Telegram에서도 답변드립니다.
WhatsApp 선택 사항
형식: +국가 코드 + 번호 (예: +82XXXXXXXXX).

버튼을 클릭하면 데이터 처리에 동의하는 것으로 간주됩니다.