데이터 메시: 연합 데이터 모델
(섹션: 기술 및 인프라)
간략한 요약
Data Mesh는 데이터가 도메인 팀의 제품으로 취급되는 조직 및 기술 모델이며 플랫폼의 핵심 역할은 셀프 서비스, 표준 및 규정 준수를 제공하는 것입니다. iGaming의 경우 다음을 의미합니다. 결제 팀은 "예금 이벤트" 및 "순 예금 마트" 를 소유하고 위험 팀은 "사기 신호" 를 소유하고 게임은 "베팅 이벤트" 및 "리더 보드" 를 소유하며 중앙 플랫폼은 카탈로그, 계약 체계, 액세스, 품질 모니터링, 파인증 및 도구 및 스트리듬/ELT.
1) 데이터 메시 원칙
1. 도메인 책임: 각 도메인 (결제, 위험, 게임, KYC/규정 준수, CRM, 제휴) 은 데이터 세트와 수명주기를 소유합니다.
2. 제품으로서의 데이터: 각 세트에는 소유자, 설명, SLO, 액세스 SLA, 문서, 버전, 피드백 및 로드맵이 있습니다.
3. 셀프 서비스 플랫폼: 표준 파이프 라인 섭취/변환/서빙, 템플릿, 기본 보안, 디렉토리 및 관찰 가능성.
4. 연방 관리: 중앙의 체계, 지표, PII/현지화 및 품질의 공통 표준; 도메인에서의 구현 및 진화.
2) 운영 모델 및 역할
DPO (Domain Data Product Owner): 우선 순위, SLO, 데이터 제품 개선의 백 로그.
도메인 데이터 엔지니어/분석 엔지니어: 회로도, 파이프 라인, DQ 테스트, 버전 지정.
도메인 스튜어드: 필드 시맨틱, 메트릭 사전 및 PII 분류와 일치합니다.
플랫폼 팀: 카탈로그, IAM/RBAC, Policy-as-Code, 테이블 형식 (Delta/Iceberg/Hudi), 오케스트레이션, 관찰 가능성, 핀업.
연방 거버넌스위원회: 표준 (체계, 지표, 보안) 승인, 도메인 간 분쟁 해결
3) "데이터 제품" -여권 및 유물
최소 데이터 제품 구성:- 계약 (체계, 유형, 진화, 호환성).
- 액세스 API (SQL/table, 주제/스트림, 파일/공유).
- SLA/SLO (신선도, 가용성, 품질).
- DQ 테스트 (고유성, 범위, 참조 무결성).
- 문서 (필드 설명, 요청 예, 소유자, 연락처).
- Versioning (시맨틱 버전 지정 체계, 정책 해제).
- 정책 (PII, 현지화, 보존/TTL, 권리).
여권 템플릿 (YAML, 예)
yaml name: bets. events. v1 domain: games owner: games-data@company interface:
sql: lakehouse. silver. bets_events stream: kafka://bets. events. v1 share: read-only (EU only)
schema_version: 1. 3. 0 slo:
freshness: "<= 5 min (p95)"
availability: ">= 99. 9%"
dq:
- unique: bet_id
- valid_values: currency in [EUR, USD, TRY, BRL]
- non_negative: [stake, payout]
security:
pii: false region: EU retention: 365d lineage:
sources: [game_engine. outbox, payments. psp. webhooks]
consumers: [crm. triggers, risk. realtime, dwh. fact_bets]
versioning:
compat: backward deprecation_policy: "60 days"4) 상호 운용성 및 표준
계획/계약: Avro/Protoguy/JSON-Schema + Schema Registry; 새로운 주요 버전이 없으면 획기적인 변화가 없습니다.
시맨틱 계층: GGR, NGR, Net Deposits, LTV, 코호트의 통합 정의-코드 (dbt 메트릭/시맨틱 계층).
식별 자: 글로벌 '플레이어 _ id', '테넌트 _ id', 'bet _ id', 통합 국가/통화/공급자 디렉토리.
메타 데이터: 필요한 열 'ingest _ ts', 'skima _ version', 'trace _ id', 'Source', 'region'.
액세스: SQL (lakehouse/OLAP), 스트림 (Kafka/Pulsar), 테이블/스냅 샷 공유; 교환 형식은 Parquet/Delta/Iceberg입니다.
5) 프로세스 참조 표준 (공급 업체에 불가지론)
소화: 전송/CDC иOLTP → Kafka → Lakehouse (청동).
변환: ELT/dbt 1은/금; 증분 '메르지', SCD, 재료 디스플레이 케이스.
서빙: OLAP (ClickHouse/Bigquery/Snowflake), RT-
카탈로그/계보: 단일 카탈로그, 자동 문서, 종속성 그래프.
관찰 가능성: 신선도/SLO 지표, DQ 주장, 스트림 지연, 비용.
정책: IAM/RBAC/ABAC, 암호화, 현지화 (영역 데이터 라우팅).
6) 데이터 제품을위한 SLO/SLA
대상 SLO의 예:- 신선도: 이벤트를 시작합니다 (p95) 사기 신호는 30 초; 순 예금 마트는 15 분입니다.
- 가용성: 99 이상. 읽기 인터페이스의 경우 9%.
- 품질: 복제본이 0 입니다. 01%, 빈 필드 공유 1%, 통화 일관성 100%.
- 비용 SLO: 창 스캔 비용은 1/N $/일, 작은 파일 비율은 <10% 입니다.
7) 안전, PII 및 현지화
분류: PII/민감한 재무/운영.
기술적 조치: 암호화 중/운송 중; PII 토큰 화; 마스킹 칼럼; '테넌트 _ id' 의 행 수준 필터.
현지화: 도메인 제품은 승인 된 지역 (EU/TR/LATAM) 에 게시됩니다. 국경 간 공유-PII가없는 단위 만.
감사: 누가 출판/읽었는지; 승인을 통한 스키마 버전 권한 확대 요청.
8) FinOps 및 가치 관리
도메인 별 예산: 한계 계산, 초과 지출 경고.
스토리지: 스토리지 클래스 + TTL (브론즈 쇼트, 실버 미디어, 골드 롱/골재).
쿼리 최적화: 파티션/클러스터링, 구체화 된보기, BI 결과 캐시.
작은 파일: 압축/OPTIMIZE 정책; 대상 파일 크기는 128-1024 MB입니다.
9) 수명주기와 진화
버전: '도메인. 제품. v {major} '; 작은 필드-back-compat.
소비자 알림, "2 레일" 기간, 이전 버전에 대한 자동 경고.
스키마 변경: 계약 저장소에 요청을 풀기; CI 호환성 테스트; 카탈로그로 자동 게시
피드백: 제품 채널 (문제 추적기), 소비자 NPS, 사고 대응 시간.
10) iGaming을위한 조정-도메인 및 제품 맵
지불
'지불. psp. 웹 후크. v1 '(스트림)
'mart _ net _ deposits _ 매일. v1 '(SQL) -SLO 신선도 PII 프리
게임
'베팅. 이벤트. v1 '(스트림/SQL) - p95 λ5 분
'mart _ ggr _ 매일. v1 '(SQL/MV) -국가/게임 별 집계
위험/사기 방지
'위험. 신호. v1 '(스트림) - p95 λ30 초
'위험. case _ mgmt. v1 '(SQL) -SCD2 조사 기록
CRM/개인화
'crm. 트리거. v1 '(스트림) -세그먼트 트리거
'프로필. 기능. 온라인. v1 '(KV/SQL) -온라인 기능 (TTL)
KYC/준수
'kyc. 상태. v1 '(SQL) -PII 보호 행 수준 정책
'책임있는 _ 게임. 이벤트. v1 '(스트림) -제한/신호
11) 플랫폼 프로세스 및 아티팩트
디렉토리: 도메인/필드/PII 레이블별로 검색, 다이어그램 미리보기 및 예제.
템플릿 생성기: 새 제품을위한 쿠키 커터 (여권, CI, DQ 테스트, SLO 대시 보드).
코드 정책: 수출 규칙, PII, 지역 간 공유.
관찰 가능성: 기성품 대시 보드: 신선도, DQ 오류, 비용, 계보, 스트림 지연.
런북: 신선도/DQ/구성표 사건, 비상 사태 해소, 버전 롤백.
12) 데이터 메시로 마이그레이션 (로드맵)
1. 도메인별로 현재 데이터 세트 → 그룹화 목록.
2. 파일럿 2-3 도메인 (결제, 게임, 위험) -여권이있는 제품으로 발행됩니다.
3. 카탈로그 및 표준: 회로도, 지표, PII/현지화, DQ.
4. 셀프 서비스: 파이프 라인 템플릿, CI/CD, SLO 모니터링.
5. 모 놀리 식 쇼케이스를 고로로 절단하는 것; 이전 인터페이스에 대한 "2 레일" 지원.
6. 연방위원회 - 정기 회의, 계약 변경 검토.
7. CRM/제휴사/마케팅으로 확장 한 다음 파트너 공유로 확장하십시오.
13) 구현 점검표
도메인 정의; 소유자와 커뮤니케이션 채널이 할당됩니다.
디렉토리 시작; 각 제품의 여권이 게시됩니다.
Schemas - 계약 저장소에서; CI는 호환성/DQ를 테스트합니다.
SLO/SLA 선언; 신선도/DQ/비용 대시 보드를 사용할 수 있습니다.
PII/현지화 정책-코드; 감사가 활성화되었습니다.
FinOps: 예산, 경고, 도메인 보고서 별 비용.
검증/예금 프로세스-문서화 및 자동화.
사건의 런북-사용 가능하고 훈련 된 (게임 데이).
14) 안티 패턴
"데이터 메시로 이름이 바뀌었지만 중앙 데이터 명령을 통해 모두" -좁은 목은 제거되지 않습니다.
단일 메트릭 사전의 부족 → GGR/NGR은 도메인마다 다릅니다.
계약 및 호환성 테스트가없는 체계 → "파괴" 릴리스.
셀프 서비스 → 각 테이블은 수동으로 높은 시간 데이터로 생성되지 않습니다.
지역 간 공유에서 PII/현지화 무시.
소유자/SLO가없는 마이크로 제품- "폐기 된" 데이터.
15) 데이터 메시 성공 KPI
데이터 시간: 아이디어에서 사용 가능한 데이터 제품 (중앙값) 까지.
재사용: 제품 당 소비자 도메인 수.
품질: 성공적인 DQ 점검 비율, 백만 건당 결함.
신뢰성: 신선도/가용성에 대한 SLO 준수.
비용: $/요청/사용자, 작은 파일 공유, 폐기 계산.
변화율: 주당 회로/상점 출시.
요약
Data Mesh는 기술 일뿐만 아니라 데이터가 소유자, SLO, 계약 및 품질 지표가있는 제품인 관리 도메인 연합이기도합니다. iGaming에서이 방법은 좁은 목을 제거하고 통합 속도를 높이며 (사기 방지, 지불, CRM) 메트릭의 투명성을 향상시키고 (GGR/NGR/LTV) 비용을 제어합니다. 강력한 셀프 서비스 플랫폼을 구축하고, 연합 표준 및 제품 별 데이터 문화를 도입하며, 분석 생태계는 품질, 속도 또는 규정 준수를 잃지 않고 비즈니스에 따라 확장됩니다.