Jude_log

분산된 GGR 계산 기준을 통합하고 QA/운영에서 재사용 가능한 SQL 조회 구조를 설계 ⚠️ 문제 정의GGR 산출 기준 불명확 → 담당자별 계산 방식 상이복잡한 SQL로 조회/검증 비효율대용량 데이터 조회 성능 이슈🛠️ 수행 내용Poker GGR 산출 공식 정의 및 표준화목적별 SQL 조회 구조 설계 (전체 / GGR / 기본)조회 효율 개선 (쿼리 분리, 불필요 컬럼 제거)기간 필터 및 조회 조건 정리 (성능 고려)QA/운영 공통 활용 가능한 조회 가이드 문서화📊 쿼리 요약SELECT p.Id AS PlayerID, SUM( pgs.RakeOrFee + pgs.TicketRefundFee + pgs.CipGGR - pgs.Tour..

MySQL 2026. 3. 5. 18:35

분산된 플레이어 GGR/게임 지표를 통합하고 QA/운영에서 재사용 가능한 SQL 조회 구조를 설계⚠️ 문제 정의플레이어별 GGR 산출 기준 불명확 → 담당자별 계산 방식 상이모니터링으로 실시간 확인 가능한 쿼리 설계복잡한 SQL로 조회/검증 비효율대용량 데이터 조회 성능 저하🛠️ 수행 내용역할테이블 (가칭)조인방식설명기본 플레이어 정보alias1기준 테이블플레이어 ID, 이메일, 닉네임, 국가, 사이트, 소속 유형 등플레이어 소속/에이전트alias2LEFT JOIN각 플레이어의 Agent 코드 조회게임별 통계alias3LEFT JOINPoker GGR, Casino GGR, Reward, T/O 등 핵심 수익 지표최신 개인 정보alias4OUTER APPLY조건에 따라 최신 Tag / Code(가칭) ..

MySQL 2026. 3. 5. 18:34

자동화 검증과 이중 교차 검증(Cross-Check) 체계로 QA 실시간 데이터 정합성 확보 ⚠️ 문제 정의BS(Business Service) 데이터에서 Bonus Revenue가 일부 누락되어 있어 정확한 Service Fee 검증이 필요한 상황누락 데이터는 타팀에서 관리하고 있어 단순 조회만으로는 정합성 확인 불가 🛠️ 수행 내용Bonus Revenue 역산: 시스템 산정 Fee와 Rate를 활용해 누락 보너스 값을 계산정합성 검증:내부 데이터 ↔ 외부 Bonus Revenue 데이터 비교Redash 대시보드 구축:PASS/FAIL 지표 실시간 시각화Bonus Revenue 발생 건 집중 모니터링세션별 상세 추적 필터 제공Slack 자동 알림 연동:매일 10시, Bonus Revenue 발생 건..

MySQL 2026. 3. 5. 18:29

실제 세션 수익과 포인트 적립 데이터를 PVI 기준으로 역산 검증하여 QA 실시간 데이터 정합성 확보⚠️ 문제 정의실제 세션 수익과 포인트 적립 데이터가 PVI별로 일치하지 않은 사례가 있었음.기존에는 명확한 산출이 나올 수 없는 구조라 모니터링이 어려워 수동검증을 하였고, 이로인해 QA 업무 효율도 낮게 나타나며 금전적 오산출 리스크가 종종 발생했음🛠️ 수행 내용PVI 기준 그룹화 후 세션 수익과 포인트 적립 데이터를 역산(Cross-Check)Uniq 한 user 구분 단위 및 그룹 단위 총액 비교로 불일치 검출ZERO_ID_CT, TOTAL_POINT_DIFF 등 지표를 통해 정합성 확인기간 조건(start_date ~ end_date) 적용, SQL 자동화로 반복 검증 가능Redash 기반 모니..

MySQL 2026. 3. 5. 17:42

1 hour 단위로 쿼리 수행 DELIMITER //CREATE EVENT IF NOT EXISTS {생성할 스케쥴러명}ON SCHEDULE EVERY 1 HOURSTARTS CURRENT_TIMESTAMPDO SELECT s.* FROM {쿼리가 실행 될 테이블} s WHERE s.category = '{조건대상}' AND s.menu IN ( SELECT menu FROM {쿼리가 실행 될 테이블} WHERE category_id = '{조건대상}' GROUP BY menu HAVING SUM(-나간돈) + SUM(들어온돈) SUM(오버된금액) O..

MySQL 2025. 5. 9. 12:11