Overview

• KPI 및 중간 계산 데이터를 저장하는 테이블이 많아지면서 관리 코스트가 늘어남.

담당 없무

• 위의 문제를 해결할 통합 KPI 테이블 구조 설계

성과

• 대시보드 만드는 SQL 쿼리 관리 코스트 감소
• KPI 정의 통일
• 과도한 Materialized View(MV) 생성 방지 |

현 상황 및 문제점

현재 분석용 테이블 구조

현재 몇 몇 KPI들을 미리 계산해 쌓아놓은 “공통지표 MV” 들과 특정 그래프를 만들기 위해 데이터를 미리 가공해 쌓은 ”그래프용 중간 계산 데이터 MV” 들을 모두 참조하여 대시보드를 만드는 중이다

현재 분석용 테이블 구조 문제

• 매번 그래프를 만들 때 마다 어떤 MV를 참조해야 하는지 알고 있어야 한다
• 핵심 지표를 만들 때 마다 새로운 MV를 만들어야 한다
• 쿼리가 오래 걸리는 그래프를 만들 때 마다 새로운 MV를 만들어야 한다
• 위의 3가지 문제로 인해, 대시보드를 만들때 알아야 하는 MV 관련 사전 지식이 급격히 늘어난다

해결 방안

Option 1 : 모든 KPI에 대한 개별 MV 생성 후, BI 툴에서 가공

장점

• KPI들이 미리 계산되어 있어, 중간 계산 테이블을 만들 필요가 적어진다
• 어떤 KPI들이 있는지만 알면, 대시보드 작성하기 쉽다
• 데이터 분석가가 아니더라도 그래프 및 대시보드를 만들기 용이하다

단점

• 각 KPI별로 MV 를 만들어야 한다. MV 수가 늘어나는 만큼 관리 비용도 늘어남
• BI 도구 내에서 데이터를 조작하여 그래프를 만드는 것에는 한계가 있다

Option 2 : 일별, 주별, 월별 통합 KPI 데이터 마트 MV 생성

장점

• 어떤 KPI를 사용하고자 할 때 모든 MV 를 알 필요 없이 특정 통합 KPI 데이터 마트 MV 만 보면 된다
• KPI들이 미리 계산되어 있어, 중간 계산 테이블을 만들 필요가 적어진다
• 하나의 MV에 KPI들이 계산되어 있어, 만들어야 하는 공통 지표 MV 수가 적어진다

단점

• 복잡해지는 ETL 프로세스

결론

각 구조의 장단점을 비교한 결과 다음과 같은 이유로 “통합 KPI 데이터 마트 구조”를 사용하기로 결정

• SQL 쿼리 시간 감소
• 알아야 하는 MV 사전 지식 감소