데이터 웨어하우징의 역사와 배경
•
저자는 2019년에 데이터 엔지니어링을 시작함
•
이미 여러 기술들이 존재하는 시기였음:
◦
Spark: 5년 전 출시 (2014년)
◦
BigQuery와 Snowflake: 10년 전 출시 (2009년)
◦
Hadoop: 13년 전 출시 (2006년)
•
과거에는 하드웨어가 비싸고, 소프트웨어 라이선스와 서버에 선투자가 필요했음
•
현재는 클라우드 콘솔에서 몇 번의 클릭으로 데이터 시스템 구축 가능
데이터 모델링의 중요성
•
현대에는 빠른 개발을 위해 데이터 모델링을 경시하는 경향이 있음
•
저자는 1년 전에야 데이터 모델링의 중요성을 깨달음
•
"Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling" 책을 통해 학습함
데이터 웨어하우징의 기본 개념
•
Bill Inmon이 1980년대 후반에 데이터 웨어하우징의 기초를 다짐
•
데이터를 생성하는 시스템(OLTP)과 분석 기능을 제공하는 시스템(OLAP)의 분리가 표준이 됨
◦
"왼쪽" 시스템: 가입 정보, 웹 트래킹 이벤트, 주문 정보 등을 기록 (OLTP)
◦
"오른쪽" 시스템: 왼쪽 시스템에서 정보를 수집하고 정리하여 분석에 사용 (OLAP)
효과적인 데이터 웨어하우스의 조건
1.
비즈니스 사용자에게 직관적이어야 함
2.
다양한 소스의 데이터가 일관된 레이블과 정의로 제공되어야 함
3.
요구사항과 변화에 적응할 수 있어야 함
4.
민감한 정보를 보호해야 함
5.
데이터 웨어하우스 팀과 비즈니스 사용자 간의 일정 합의가 필요함
6.
의사결정을 지원하는 적절한 데이터를 보유해야 함
7.
비즈니스 사용자가 시스템을 받아들여야 함 (사용되지 않는 시스템은 좋은 해결책이 아님)
차원 모델링 (Dimensional Modeling)
•
Ralph Kimball이 1996년 책에서 처음 소개
•
분석 데이터 제공을 위해 널리 채택됨
•
단순성을 추구하며, 비즈니스 사용자의 직관적 사고방식과 일치함
•
측정 가능한 지표와 그 지표가 관찰되는 맥락으로 사업을 생각함
스타 스키마 (Star Schema)
•
차원 모델링은 제3 정규화 형식(3NF)과 다름
•
정규화는 중복을 제거하여 데이터 무결성 보장이 목표
•
3NF는 데이터를 여러 엔티티로, 각각 관계형 테이블로 분리
•
이는 운영 처리에는 유용하지만 데이터 웨어하우징에는 복잡함
팩트 테이블 (Fact Table)
•
스타 스키마의 중심 테이블
•
비즈니스 프로세스 이벤트의 성과 측정값 저장
•
각 행은 특정 수준의 세부 정보(그레인)에서의 측정 이벤트에 해당
◦
이벤트 추적 팩트 테이블의 각 행은 버튼 클릭이나 아이템 구매와 같은 사용자 이벤트에 해당합니다.
•
모든 행은 동일한 그레인이어야 함
•
팩트 테이블 행의 구성:
◦
외래 키: 관련 차원 테이블에 연결
◦
측정값: 매출, 판매량, 이익과 같은 수치
◦
예
▪
유럽의 사용자 수익은 수익 팩트 테이블(사용자 그레인)과 국가 차원 테이블(팩트의 외래 키 국가 코드와 국가와 연관된 대륙을 기록함)의 기본 ID를 사용하여 국가 차원 테이블과 조인하여 계산할 수 있습니다.
차원 테이블 (Dimension Table)
•
팩트에 대한 설명적 컨텍스트 제공
◦
차원 테이블은 데이터에 의미와 맥락을 부여
▪
각 테이블은 제품, 국가, 날짜와 같은 비즈니스 차원에 집중
◦
"누가, 무엇을, 어디서, 언제, 어떻게, 왜"를 설명
▪
"매출이 1억원 증가했다"라는 숫자만 있다면 이게 좋은 건지, 어디서 증가했는지, 왜 증가했는지 알 수 없습니다.
▪
그러나 차원 테이블을 통해 "서울 지역에서, 20-30대 여성 고객층에서, 여름 신상품 출시 이후에 매출이 1억원 증가했다"라는 맥락을 알게 됩니다.
▪
차원 테이블이 제공하는 맥락
•
"누구": 고객 차원 테이블(연령대, 성별, 회원 등급 등)
•
"무엇": 제품 차원 테이블(제품명, 카테고리, 브랜드 등)
•
"어디서": 지역 차원 테이블(국가, 도시, 매장 등)
•
"언제": 시간 차원 테이블(년, 월, 일, 요일, 휴일 여부 등)
•
"어떻게": 프로모션 차원 테이블(마케팅 채널, 캠페인 정보 등)
•
"왜": 이벤트 차원 테이블(할인 행사, 신제품 출시 등)
◦
차원의 속성(열)을 모델링하여 비즈니스 용어에 최대한 가깝게 만들어야 합니다
•
강력한 차원 속성은 강력한 분석 기능 제공
◦
팩트 테이블에는 매출액, 판매수량 등의 측정값이 저장되기 때문에, 차원 테이블이 없다면 "매출이 증가했다"는 사실만 알 수 있음
◦
차원 테이블이 있으면 "어떤 제품이, 어떤 고객층에서, 어떤 시기에, 어떤 이유로 매출이 증가했는지"를 분석할 수 있게 됩니다.
차원 설계 프로세스의 4단계
1.
비즈니스 프로세스 선택: 분석할 핵심 활동 식별 (판매, 재고 관리 등)
2.
그레인 선언: 분석 세부 수준 정의
a.
개별 거래, 일일 요약, 월간 집계 등
b.
그레인이란?
•
그레인은 팩트 테이블의 "세분성" 또는 "상세도"를 정의합니다
•
모든 팩트 테이블은 명확한 그레인을 가져야 합니다
•
그레인은 "이 팩트 테이블의 한 행이 정확히 무엇을 나타내는가?"라는 질문의 답입니다
•
예를 들자면
◦
소매점 판매 데이터의 그레인은 "개별 판매 거래의 각 상품 라인"일 수 있습니다
◦
웹사이트 트래픽의 그레인은 "각 사용자의 개별 페이지 방문"일 수 있습니다
◦
인벤토리 데이터의 그레인은 "일별 제품별 재고 수준"일 수 있습니다
3.
차원 식별: 프로세스의 설명적 속성 캡처 (제품 세부정보, 시간, 고객 인구통계 등)
4.
팩트 식별: 프로세스와 관련된 정량적 지표나 측정값 식별 (매출, 판매량, 할인액 등)
저자의 생각
장점
•
직관적 설계: 비즈니스 관찰 방식(컨텍스트를 통한 비즈니스 프로세스 측정)과 자연스럽게 일치함
•
빠른 구현: 다른 접근법보다 구현 시간이 짧을 수 있어 리소스가 제한된 팀에게 적합함
•
커뮤니티 지원: 널리 사용되는 접근법으로, 풍부한 커뮤니티 지식과 솔루션 활용 가능
한계점
•
유연성 부족: 특정 분석 요구사항에 맞춰 설계되어 새로운 요구사항 발생 시 새로운 모델링이 필요할 수 있음
•
상황별 적합성: 모든 상황에 최적은 아니며, 조직과 비즈니스 특성에 따라 Inmon이나 Data Vault 같은 다른 접근법이 더 적합할 수 있음
데이터 모델링에 대한 일반적 통찰
•
구조화의 중요성: 무분별한 데이터 적재는 피해야 함. One Big Table(OBT)은 신중한 데이터 모델링을 기반으로 할 때만 가치가 있음
•
클라우드 데이터웨어하우스 트렌드
◦
과거: 비정규화와 조인 회피를 권장하는 경향
◦
최근: 기본 키와 외래 키 개념 도입으로 적절한 데이터 구조화 장려하는 방향으로 변화 중
결론
•
이 글은 "The Data Warehouse Toolkit"의 처음 두 장에서 얻은 핵심 통찰력을 요약
•
데이터 웨어하우징 시스템의 목적, 차원 모델링의 접근 방식과 프로세스, 팩트와 차원에 대한 소개를 탐구