RDB에서 작년과 작년 달을 비교할 수 있는 테이블을 생각해 보세요.

개시하다

분석을 위해 작년의 대비와 작년의 달을 비교하는 요구가 많다."지난해와 비교할 때×'또는'매달 △□하나하나 성장하고 있다'.흔한 용도지만 거래표처럼 추기만 돼 분석이 쉬웠던 표라면 문제없다. 만약 그것이 갱신을 주체로 하는 메인 표라면?예를 들어 서버 관리 카운터에서 서버 카운터의 증감을 조사하거나 고객 제어에서 유료 회원의 증감을 조사하고 싶다...저장된 책상을 DWH에 넣고 "그럼 분석해 봅시다!"난감한 녀석이군.원래 업무표는 분석이 아닌 업무 자체를 위한 것이어서 어쩔 수 없었다.
최근에 우연히 같은 질문을 들었기 때문에 갑자기 생각나는 내용을 정리해서 쓰려고 합니다."이렇게 하는 게 더 좋아요!"이런 평론이나 지적은 매우 환영한다.

TL;DR

현대 DWH로 스냅숏을 찍는 게 제일 좋은 것 같아요

분할표는 차분만 있고 가로로 자르기도 가능하여 매우 편리하다

품기 좋은 상황과 용례를 선택하는 방법!

용례

한마디로 예를 들면 다음과 같은 고객 위주를 고려하겠습니다.is_만약 프리미엄이 사실이라면, 우리는 유료 회원이 될 것이다.
id
Integer
name
Text
is_premium
Boolean
updated_at
Timestamp
나는 이 표에서 매달 유료 회원 수의 증감을 요구하고 싶지만, DWH와 자주 합작만 한다면 과거의 역사 기록이 없기 때문에 불가능하겠지?다음과 같이 매달 상태가 변할 때 분석 메커니즘을 어떻게 구축하는지 고려해야 한다.
일월
id
name
is_premium
updated_at
1
User A
TRUE
2022/1/1
2
User B
FALSE
2022/1/1
3
User C
FALSE
2022/1/1
이월
id
name
is_premium
updated_at
1
User A
TRUE
2022/1/1
2
User B
TRUE
2022/2/1
3
User C
FALSE
2022/1/1
4
User D
FALSE
2022/2/1
삼월
id
name
is_premium
updated_at
1
User A
TRUE
2022/1/1
2
User B
FALSE
2022/3/1
3
User C
TRUE
2022/3/1
4
User D
TRUE
2022/3/1

시나리오 1: 복제/백업/캡처

가장 간단한 것은 매달 책상의 복사본을 만드는 것이다.예를 들어 매달 충분한 차점이 있으면, 업무 DB에서 DWH로 연합하는 월차 일괄 User202201, User_202202, User_20203 등에 필요한 양을 간단히 복제합니다.
비교된 SQL도 매우 간단하게 제작할 수 있고 데이터량이 충분하면 나쁘지 않다.
다른 한편, 변하지 않는 가치도 있기 때문에 고객의 고객만큼 큰 테이블에는 적합하지 않다.스토리지 효율성이 매우 떨어집니다...
하지만 표의 복사본을 직접 만들지 않아도 DWH 기능을 통해 이 아이디어를 더욱 스마트하게 실현할 수 있다.
예를 들어 빅Query의 표 캡처는 검색의 대상이 될 수 있기 때문에 상술한 내용을 효과적으로 실현할 수 있다.이런 모던한 토대를 사용하는 것이 가장 적합한 해결책이며, 그 밖의 방법도 함께 검토해 보자.

방안 2: 버전 관리를 할 수 있는 구조를 채택하다

방금 전의 방안에 업데이트된 데이터가 있는지, 저장 효율이 좋지 않은 문제가 있다.또 월차나 정해진 시점만 분석할 수 있기 때문에'지난주와의 격차도 보고 싶다'는 등 새로운 조건이 나와도 대응할 수 없다.이 두 가지 문제를 해결하는 생각은'버전 관리를 할 수 있는 표 구조로 전환하는 것'이다.
버전 관리를 위해 초모형적인 표 구조를 간단하게 채택한다.즉 표 구조를 기술하는 표 구조를 만들어야 한다는 것이다.이번에는 구체적으로 한 테이블에 대해 열을 따라 다른 테이블을 만드는 방법을 취한다.
구체적으로 다음 표로 분해한다.
user
id
created_at
1
2022/1/1
2
2022/1/1
3
2022/1/1
4
2022/2/1
name_history
id
user_id
value
created_at
1
1
User A
2022/1/1
2
2
User B
2022/1/1
3
3
User C
2022/1/1
4
4
User D
2022/2/1
ispremium
id
user_id
value
created_at
0
1
TRUE
2022/1/1
1
2
FALSE
2022/1/1
2
3
FALSE
2022/1/1
3
2
TRUE
2022/2/1
4
4
FALSE
2022/2/1
5
2
FALSE
2022/3/1
6
3
TRUE
2022/3/1
7
4
TRUE
2022/3/1
이에 대해 아래와 같이 묻다.

select u.id, n.value name, p.value is_premium, p.created_at updated_at  from user u
	join (select id, user_id, value, created_at from name_history x where x.created_at <= '2022-02-01' group by user_id having created_at = MAX(created_at)) n on n.user_id = u.id
	join (select id, user_id, value, created_at from ispremium_history x where x.created_at <= '2022-02-01' group by user_id having created_at = MAX(created_at)) p on p.user_id = u.id;

이렇게 하면 2월의 상태를 검색할 수 있다.
id
name
is_premium
updated_at
1
User A
TRUE
2022/1/1
2
User B
TRUE
2022/2/1
3
User C
FALSE
2022/1/1
4
User D
FALSE
2022/2/1
부조회 중의where문장의 값을 바꾸면 1월이든 3월이든 날짜 단위의 차이도 나올 수 있다.실제로 이 검색어에 차별화된 통계 검색어를 직접 쓰는 것은 매우 번거롭기 때문에, 나는 이것이View에서 사용하는 것이라고 생각한다.
제가 평소에 다루는 범위 내에서 업무 시스템 자체의 개념 모델과 외부 모델은 기본적으로 1:1이기 때문에 View를 제작하지 않았지만 데이터 분석을 하면 이번처럼 분리하는 것이 좋습니다.이런 유연성은 RDB 맛이 난다.
그러나 이 방법은 당연히 만능이 아니다. 문제는 계산 원가가 너무 높다는 것이다.매번 계산해야 하니까.뷰를 Materialized View로 대체할 수 있지만 이 경우 스토리지 비용이 많이 들기 때문에 최적이라고 할 수는 없습니다.이 방면은 실제 데이터량과 DWH의 구조, 기계 자원, 용례에 강하게 의존하기 때문에 실제적으로 임시 조립을 시도할 수밖에 없다.
나는 더욱 효율적인 데이터 구조/조회가 있다고 생각하지만, 이번에는 생각의 방향성이다.더 좋은 방법이 있다면 꼭 댓글을 남겨주세요!

시나리오 3: ES(Event Soucing) 사용

애도 없던 말인데 워낙 업무 시스템을 가지고 노는 경우다.
원래도 놀 줄 알았기 때문에 DWH 측은 더 이상 고려하지 않았다. 간단하지만 업무 시스템으로서 당연히 그것이 가장 좋은지 연구할 필요가 있다.
CURD를 통해 업데이트 주체로 하는 표는 여러 가지 장점이 있고 가능하면 채택을 논의할 수도 있다.이 부근의 보도는 참고가 될 수 있다.
https://qiita.com/uzawa-sorich/items/261021c1d265b20117ab

총결산

한 마디로 하면 메인 테이블이 합작한 DWH에서 작년 달과 비교된 과거의 비교와 분석을 어떻게 진행합니까?그런 점에서 정리를 해봤어요.
개인적으로 활용할 수 있다면 현대식 구조를 적용한 DWH와 Datalake가 좋다고 생각하지만, 필요에 따라 시나리오 1과 2라도 하고 싶은 일은 기존 인프라에서 할 수 있다고 생각해 성가가 높은 현실적 방법을 연구하고자 한다.
"이런 방법도 괜찮다!"만약 이런 것이 있다면 꼭 저에게 알려주세요.
그럼 해피해킹!