[분석] 대시보드용 데이터 마트로 리포팅하기

회사에서 분석가로서 업무를 진행하면 마주칠 수밖에 없는 업무 중 하나가 지표를 리포팅하는 업무라고 생각하는데요.
이번 포스팅에서는 지표를 리포팅하기 위해 대시보드용 데이터 마트를 만든 과정을 이야기해보려 합니다.
 
 

---

0. 대시보드(Dashboard)의 목적은?

업무를 하다 보면 이런저런 대시보드가 사내 구성원들에게 공유되는 모습을 쉽게 찾아볼 수 있습니다.
저의 경우엔 대시보드를 공급해 주는 입장이기 때문에 대시보드 생성 요청이 들어오면 몇 가지 생각을 하게 됩니다.
그리고 이 생각은 대시보드를 생성하는데 어느 정도 방향성을 잡아주기도 하죠.
 
저의 경우 '이 대시보드를 가지고 뭘 하고 싶은 걸까?'라는 생각을 먼저 하게 됩니다.
조금 더 상세히 내용을 풀어보면 이렇습니다.

< 상황 >
'특정 구좌에 노출되고 있는 상품들의 실적을 실시간으로 보여주는 대시보드를 만들어줘!'라는 요청이 온 상태

< 생각의 흐름 >
1) 이 대시보드를 누가 보는 걸까?
  - 해당 구좌에 노출된 상품의 담당 MD 분들
  - 해당 구좌를 관리하는 마케팅 부서
  - 해당 구좌에 있는 상품 판매 현황을 살펴보고 재고량을 체크하는 물류 부서

2) 이 대시보드가 왜 필요할까?
  - 담당 MD : 해당 상품의 실시간 실적 체크
  - 마케팅 부서 : 실적이 저조한 상품을 교체하기 위한 실적 달성률 체크
  - 물류 : 판매량 및 재고량 파악을 통한 품절 여부, 물류 상황 체크 
  
3) 이 대시보드를 가지고 어떤 업무가 진행되는 걸까?
  - 담당 MD : 상품의 실시간 실적 체크하고 실적 기반으로 공급사와 협의
  - 마케팅 부서 : 실적이 저조한 상품을 교체하여 기회손실 줄이기
  - 물류 : 품절 여부 파악을 통해 품절 Loss 낮추기

이렇게 누가, 왜 이 대시보드를 필요로 하는지를 파악하고 나면 대시보드의 메인이 되는 지표들을 선정하기가 쉬워집니다.
위 경우에는 실적(판매 금액, 판매량, 달성률)과 재고량을 중심으로 대시보드를 구성하게 되겠죠. 
이렇게 어느 정도 생각이 끝나게 되면 요청사항 협의를 진행하며 대시보드를 구성하게 됩니다.
 
 

---

1.  대시보드용 데이터 마트의 필요성

기존에는 업데이트 주기가 하루 단위의 대시보드가 많았기 때문에 쿼리를 대시보드에 연결하여 구성하는 방식을 사용했었는데요.
빅쿼리로 업무 환경이 변경되고 실시간 데이터에 접근할 수 있게 되자, 실시간 데이터를 기반으로 한 대시보드 요청이 늘어나기 시작했습니다.
그런데 업데이트 주기가 짧아지자 여러 가지 문제가 발생했습니다.
 

1) 사용자 관점 : 대시보드가 너무 느려요.. 근데 여러 정보는 담아줬으면 좋겠어요!

대시보드에서 사용자가 기대하는 부분은 크게 세 가지더라고요.

• 보고 싶은 항목이 많다. ( = 이것도 넣어주시면 안 되나요? 저것도 넣어주시면 안 되나요?)
• 최대한 실시간으로 값을 보고 싶어 한다. ( = 대시보드 업데이트 주기를 더 짧게 해 주시면 안 되나요??)
• 빠르게 값들을 확인하고 싶어 한다. ( = 대시보드가 너무 느려서 답답해요..)

 

2) 데이터 플랫폼팀 관점 : 대시보드에서 쿼리가 너무 많이 날아오는데요..??

데이터 플랫폼팀에서는 이런 수정요청이 들어옵니다.

• 쿼리 cost를 낮춰주세요. ( = 해당 대시보드에서 쿼리가 너무 많이 날아와서 cost 가 너무 많이 소모됩니다.)

 

3) 작업자(=나) 관점 :  중간에서 쉽지 않네;;

대시보드 사용자와 데이터 플랫폼팀 사이에서 저는 해결책을 마련해야만 하는 상황에 마주치게 됩니다.
그리고 이 상황 자체도 작업자 관점에서 문제가 되는 일이죠.

• 유지보수에 시간을 쏟게 된다. (= 쿼리가 무겁고 자주 돌다 보니 뻗는 경우가 발생한다..)

 
 
그런데! 위에서 이야기한 모든 문제를 해결할 수 있는 방법이 있었으니, 그것이 바로 대시보드용 데이터 마트를 만드는 것이었습니다.
쿼리 기반의 대시보드와 데이터 마트 기반의 대시보드의 차이점을 살펴보면 이렇습니다.

관점	쿼리 기반 대시보드	데이터 마트 기반 대시보드
비용	쿼리가 돌아가면서 여러 테이블이 사용되고 JOIN 이 되다 보면 쿼리 비용이 늘어난다.	마트로 만들어져있는 테이블을 불러오는 수준이기 때문에 쿼리 비용이 아주 낮아진다.
속도	쿼리가 돌아가는데 시간이 걸리기 때문에 대시보드에 값이 표현되는 데 시간이 걸린다.	테이블에서 값을 바로 가져오기 때문에 빠르게 값이 표현된다.
확장성	추가로 원하는 지표가 있다면 테이블을 JOIN 하면서 쉽게 추가할 수 있다.	추가로 지표가 들어간다면 데이터 마트에 컬럼을 추가하고 다시 적재를 해주어야 한다.

위 표를 보시면 아시겠지만 비용과 속도 관점에서는 확실히 데이터 마트 기반의 대시보드가 훨씬 우월한 모습을 보입니다.
하지만 확장성 관점에서는 테이블 자체를 수정해 주는 과정이 필요하기 때문에 비교적 손이 많이 가는 것이 사실입니다.
그렇기 때문에 마트를 만들 때 대시보드에서 어떤 항목을 보여줄 것인지에 대한 지표 정의를 사용자와 확실히 협의한 뒤 마트를 구성해야 한다는 생각이 듭니다.
 
그러면 데이터 마트를 구성할 땐 어떤 부분을 고려해야 할까요?
 
 

---

2. 데이터 마트를 만들 때 고려할 점

제가 작업을 하면서 느낀 부분을 정리하면 아래와 같습니다.
 

1) 적재 주기 및 적재 방식 정하기

우선 데이터 마트를 구성할 때 얼마나 자주 데이터를 적재하는지를 고민합니다.
'얼마나 자주'에 해당하는 부분은 '대시보드 업데이트 주기'와 동일한 의미이며 이는 즉, '대시보드의 업데이트 주기를 어떻게 설정하면 될까?'에 대한 기준을 정하는 과정이 됩니다.
 
이 경우에는 보통 대시보드 요청자의 의견을 먼저 받아보겠지만 무엇보다 우선되는 기준은 이 대시보드의 목적이 무엇이냐가 됩니다.
 
예를 들면, 

* 라이브커머스와 같이 짧은 호흡으로 계속해서 실시간 판매량을 확인해야 하는 경우 = 1분 단위 업데이트 (실시간)

* 실시간 실적을 확인하면서 상품 달성률을 확인하는 경우 = 15분 단위 업데이트 (준실시간)

* 전일자 실적을 확인하면서 일별 목표 달성률을 확인하는 경우 = 하루 단위 업데이트 

위와 같이 목적에 따라 업데이트 주기를 결정해 줍니다.
 
그리고 적재 주기가 정해진다면 어떻게 적재를 할 지에 대한 고민을 하게 되는데요.
이 부분도 마찬가지로 대시보드의 목적에 따라서 달라집니다.

* 1분 단위 업데이트 (실시간)
  - 완전 실시간에 가깝기 때문에 마트를 만들기보다는 최대한 대시보드 표현 항목을 간소화해서 가벼운 쿼리 기반으로 대시보드를 만든다.

* 15분 단위 업데이트 (준실시간)
  - 준실시간 데이터의 경우 그 시점의 실적 확인이 중요하기 때문에 테이블의 모든 값을 삭제한 뒤 (TRUCATE TABLE), 다시 업데이트된 값을 쌓아준다 (INSERT)

* 하루 단위 업데이트
  - 하루 단위 업데이트의 경우 전일자, 전주 동요일 등 일자별 지표 변화를 살펴보는 경우가 많다.
  - 그렇기 때문에 월 마감이 되기 전까지는 삭제 후 업데이트 ( = UPSERT), 월이 지나가면 업데이트하지 않고 값을 고정(snap shot)시킨다.

이렇게 대시보드의 목적에 따라 적재 방법도 달라집니다.
 
 

2) 컬럼 정의하기

이렇게 적재 주기 및 방식을 정하고 나면 어떤 컬럼을 마트에 넣어줄지를 정의합니다.
컬럼을 정의할 때 생각할 부분은 '대시보드에서 어떤 기준으로 값을 보여줄 것인가?'에 대한 부분을 기반으로 컬럼을 생각해 봅니다.
 
'어떤 기준'이라 함은 값을 어떤 방식으로 나누어서 표현할 것인지에 대한 의미인데요.
만약 매출액과 판매수량, 재고량을 보여준다고 했을 때,

• 이 지표들을 한 번에 보여준다
• 시간대별로 나누어서 보여준다
• 물류센터별로 나누어서 보여준다

위와 같이 얼마나 지표들을 잘게 나누어서 표현할 것인지를 생각을 해봅니다.
 
만약 물류센터별, 시간대별로 보여준다고 한다면,
데이터 마트의 컬럼에 시간대별로 값을 집계하기 위해 '시간대'라는 컬럼과 물류 센터 구분을 위해 '센터코드' 컬럼도 함께 넣어줘야겠죠.
 
 

3) 한 번만 더 고민해 보자

이렇게 어떤 컬럼을 넣을지까지 결정하고 나면 데이터 마트를 만들기 위한 쿼리를 작성하기만 하면 되지만,
한 번만 더 고민을 해보는 것도 나쁘지 않다고 생각을 합니다.

< 마지막 고민의 예시 >
1) 이 하나의 마트를 가지고 최대한 많은 대시보드 내 차트를 만들어낼 수 있는지?
   - 그렇지 않고 차트마다 각각의 마트를 만들어버리면 혹시 모를 수정이 필요하게 되었을 때 수정을 해주어야 할 마트가 늘어나기 때문에 불편하지 않을까?

2) 운영상 컬럼값과 매칭되는 수치가 변경될 가능성이 높다면 이 값들은 마트에 포함시키는 게 맞는지?
   - 예를 들어 구좌 노출 순서에 따른 목표치가 설정이 되어 있는데, 이 목표치가 자주 변경되는 모습을 보였다면 차라리 구좌 노출 순서만 마트에 넣고, 목표치는 빼는 게 낫지 않을까?

위와 같이 '대시보드를 구성하는 기준과 운영상 성격에 따라서 최대한 완성 후 유지보수에 리소스가 적게 드는 방법이 무엇일까?'에 대한 고민을 해보는 것도 좋다고 생각합니다.
아무래도 고민을 하고 만들었을 때 허점이 발견되더라도 더 배우는 게 많을 테니깐요.
 
 
 

---

3. 끝마치며

이렇게 이번에는 대시보드용 데이터 마트를 만들어보는 과정에 대해서 이야기를 해봤습니다.
데이터 마트는 확실히 사용자의 입장에서도, 관리자의 입장에서도 긍정적인 부분이 많다고 느껴집니다.
그리고 사용자 관점에서 보다 나은 사용성을 제공하기 위해 고민하는 과정도 충분히 재미있다는 것을 느껴볼 수 있었던 업무였네요.
작업을 하면서 든 생각은 지금은 빅쿼리의 예약된 쿼리를 통해서 데이터 마트를 만들었지만, airflow와 같은 배치 툴에 대해서도 공부를 해봐야겠다는 생각이 들었습니다.
 
읽어주셔서 감사합니다.