엔터프라이즈 데이터 웨어하우스 버스 아키텍처

엔터프라이즈 데이터 웨어하우스 버스 아키텍처는 회사의 분석 저장소를 업무 하나씩 나눠 지어도 끝에는 하나로 이어지게 해 줍니다. 업무마다 따로 만든 분석 테이블들이 상품이나 날짜 같은 기준 테이블을 함께 씁니다. 그래서 나중에 붙인 업무의 숫자도 먼저 지은 업무의 숫자와 나란히 놓입니다. 대신 여러 부서가 그 기준 테이블의 모양에 먼저 합의해야 합니다.

쉽고 빠른 이해

이 설계는 판매·반품·재고처럼 숫자가 생기는 일마다 분석 테이블을 따로 짓게 합니다. 대신 「상품」「날짜」「매장」 같은 기준은 회사 전체가 한 벌만 만들어 함께 씁니다.

기준을 부서마다 따로 만들면 같은 칫솔이 판매팀에서는 「생활용품」, 반품팀에서는 「위생용품」이 됩니다. 그러면 카테고리별 반품률 같은 숫자를 낼 수 없습니다. 그렇다고 회사 전체 저장소를 한 번에 지으려 하면 몇 년이 걸립니다.

1. 회사의 업무와 그 업무가 쓰는 기준을 표 하나에 먼저 그립니다
2. 여러 업무가 함께 쓰는 기준을 한 벌로 정합니다
3. 그다음 업무를 하나씩 골라 분석 테이블을 짓고 그 기준에 꽂습니다

대가는 합의입니다. 부서들이 기준의 이름과 값을 맞춰야 첫 업무를 지을 수 있습니다. 함께 쓰는 기준은 한 팀이 혼자 고치지 못합니다.

분석할 업무가 하나뿐이거나 부서끼리 기준을 못 맞추는 곳에는 맞지 않습니다.

상세

부서마다 따로 지은 분석 저장소

쇼핑몰 회사가 매출을 분석한다고 해 봅시다. 주문을 받는 운영 데이터베이스에서 바로 큰 집계를 돌리면 주문 처리가 느려집니다. 그래서 분석에 쓸 데이터를 따로 모아 둡니다. 여러 업무의 분석 데이터를 한곳에 모은 저장소를 데이터 웨어하우스라고 합니다.

처음부터 회사 전체를 담는 저장소를 짓기는 어렵습니다. 그래서 부서 하나가 자기 분석에 필요한 것만 모은 작은 저장소를 먼저 짓곤 합니다. 이런 작은 저장소를 데이터 마트라고 부릅니다.

문제는 마트끼리 안 맞는다는 것입니다. 판매팀 마트는 칫솔을 「생활용품」으로 묶습니다. 반품팀 마트는 같은 칫솔을 「위생용품」으로 묶습니다. 카테고리별 반품률을 내려면 두 숫자를 한 줄에 놓아야 합니다. 그런데 카테고리 이름부터 달라 이어 붙일 수 없습니다.

다른 마트와 기준을 맞추지 않고 혼자 지은 마트를 독립 데이터 마트라고 합니다. 독립 마트가 늘수록 회사 안에 같은 질문에 다른 답을 내는 숫자가 늘어납니다.

반대로 회사 전체 저장소를 한 번에 설계하면 짓는 데 몇 년이 걸립니다. 그사이 업무가 바뀝니다. 버스 아키텍처는 그 둘 사이의 길을 냅니다. 전체를 먼저 그려 두고, 짓기는 하나씩 합니다.

팩트 테이블과 차원 테이블

이 설계는 분석 데이터를 담는 방식 하나를 전제로 합니다. 분석 데이터를 「일어난 일의 숫자」와 「그 숫자를 묶어 보는 기준」으로 나눠 담는 설계 방법을 차원 모델링이라고 합니다.

일어난 일의 숫자를 담는 테이블이 팩트 테이블입니다. 판매 팩트 테이블의 한 행은 판매 한 건입니다. 그 행에 수량과 금액을 담습니다.

수량과 금액처럼 더하고 평균 낼 숫자를 측정값이라고 합니다. 팩트 테이블이 집계에 내놓는 것이 이 값입니다.

묶어 보는 기준을 담는 테이블이 차원 테이블입니다. 상품 차원 테이블의 한 행은 상품 하나입니다. 그 행에 이름과 브랜드와 카테고리를 담습니다. 판매 행은 상품 행의 키를 들고 있어서 「카테고리별 판매 금액」 같은 집계를 낼 수 있습니다.

팩트 테이블 하나를 차원 테이블 여럿이 둘러싼 모양을 스타 스키마라고 합니다. 보통 업무 하나가 스타 스키마 하나가 됩니다.

여기서 업무는 부서가 아니라 숫자가 생기는 일의 단위입니다. 주문 받기, 판매, 반품, 재고 세기가 각각 하나의 업무입니다. 이런 단위를 비즈니스 프로세스라고 부릅니다.

공통 차원 — 업무를 잇는 통로

부서마다 따로 지은 마트가 안 맞았던 까닭은 차원 테이블을 각자 만들었기 때문입니다. 그래서 차원 테이블을 회사 전체가 한 벌만 만듭니다. 판매 팩트와 반품 팩트가 같은 상품 차원을 가리키면 칫솔의 카테고리는 어디서 보든 하나입니다.

여러 팩트 테이블이 함께 쓰는 차원을 컨폼드 디멘션(conformed dimension)이라고 합니다. 우리말로는 공통 차원이라고도 합니다. 컨폼드는 「맞춰졌다」는 뜻입니다.

가장 단순한 모양은 테이블 한 벌을 여러 팩트 테이블이 함께 가리키는 것입니다. 저장소가 나뉘어 마트마다 사본을 두더라도 열 이름과 값이 똑같으면 같은 공통 차원으로 봅니다. 어느 쪽이든 핵심은 같은 열 이름에 같은 값을 담는 것입니다.

flowchart TD
    subgraph 공통["공통 차원 · 회사 전체가 한 벌"]
        D1[날짜]
        D2[상품]
        D3[매장]
    end
    F1[판매 팩트] --> D1
    F1 --> D2
    F1 --> D3
    F2[반품 팩트] --> D1
    F2 --> D2
    F3[재고 팩트] --> D1
    F3 --> D2
    F3 --> D3

그림에서 팩트 테이블 셋은 업무가 서로 다릅니다. 그래도 날짜와 상품은 셋이 함께 씁니다. 판매와 재고는 매장 차원도 함께 씁니다.

이름의 버스는 컴퓨터 부품에서 왔습니다. 컴퓨터 안의 여러 장치는 공통 통로 하나에 꽂혀 데이터를 주고받습니다. 이 통로를 버스라고 합니다. 버스 아키텍처에서는 공통 차원이 통로를 맡습니다. 업무별 팩트 테이블은 거기 꽂히는 장치가 됩니다.

버스 매트릭스 — 전체 설계도

공통 차원을 정하려면 어느 업무가 어느 차원을 쓰는지부터 알아야 합니다. 그래서 표 하나로 시작합니다. 행에 업무를 적고 열에 차원을 적은 표를 버스 매트릭스(bus matrix)라고 합니다.

표를 세로로 읽으면 공통 차원이 보입니다. 날짜와 상품은 네 업무가 다 쓰므로 가장 먼저 맞춰야 합니다. 공급사는 입고 하나만 쓰므로 당장 맞출 상대가 없습니다.

표를 가로로 읽으면 업무 하나를 지을 때 필요한 차원이 보입니다. 판매를 지으려면 날짜·상품·매장·고객 차원이 있어야 합니다. 한 행이 곧 스타 스키마 하나의 설계입니다.

짓는 순서

버스 매트릭스는 회사 전체를 한 번에 내려다보는 계획입니다. 하지만 짓는 것은 한 행씩입니다. 계획은 위에서 아래로 합니다. 짓기는 아래에서 위로 쌓습니다.

1. 회사의 업무와 차원을 버스 매트릭스에 그립니다
2. 여러 행이 함께 쓰는 차원의 열 이름과 값을 정합니다
3. 한 행을 골라 팩트 테이블을 짓고 공통 차원에 연결합니다
4. 다음 행으로 넘어갑니다. 이미 있는 차원은 다시 만들지 않고 가져다 씁니다

공통 차원은 한곳에서 한 번만 채웁니다. 운영 데이터베이스에서 데이터를 꺼내고, 분석에 맞는 모양으로 바꾸고, 웨어하우스에 싣는 처리를 ETL(Extract-Transform-Load, 추출-변환-적재)이라고 합니다. 상품 차원을 채우는 ETL 이 하나뿐이어야 판매와 반품이 같은 칫솔을 봅니다.

버스 아키텍처에서는 마트의 단위도 달라집니다. 마트 하나는 부서 하나의 저장소가 아니라 버스 매트릭스의 한 행, 곧 업무 하나의 스타 스키마입니다.

이렇게 행을 하나씩 붙여 가면 마트 여러 개가 쌓이는데도 따로 놀지 않습니다. 같은 차원을 가리키는 마트들이 모여 회사 전체의 데이터 웨어하우스가 됩니다. 엔터프라이즈 데이터 웨어하우스는 따로 지은 큰 저장소가 아니라 이 마트들의 합입니다.

여러 업무를 한 표로 — 드릴 어크로스

공통 차원이 있으면 서로 다른 업무의 숫자를 한 표에 놓을 수 있습니다. 방법은 두 단계입니다. 먼저 팩트 테이블마다 따로 공통 차원의 열로 묶어 집계합니다. 그다음 두 결과를 그 열의 값으로 이어 붙입니다.

이렇게 여러 팩트 테이블의 결과를 공통 차원으로 잇는 조회를 드릴 어크로스(drill-across)라고 합니다. 판매와 반품을 카테고리로 이으면 아래 같은 표가 나옵니다.

한 줄 안에 두 업무의 숫자가 나란히 있으므로 반품 수량을 판매 수량으로 나누면 카테고리별 반품률이 나옵니다.

두 팩트 테이블을 행끼리 바로 조인하지 않는 까닭이 있습니다. 판매 한 행에 반품 여러 행이 붙으면 판매 수량이 그만큼 여러 번 더해집니다. 따로 집계한 뒤 이으면 각 숫자는 한 번씩만 셉니다.

이 표가 나오는 것은 두 집계의 「생활용품」이 같은 글자이기 때문입니다. 판매팀과 반품팀이 카테고리 이름을 따로 정했다면 두 줄로 갈라졌을 것입니다.

대가

가장 큰 대가는 합의입니다. 판매팀과 반품팀이 칫솔의 카테고리를 하나로 정해야 합니다. 「고객」에 비회원 주문자를 넣을지도 정해야 합니다. 이 합의가 끝나야 첫 업무를 지을 수 있어서 첫 결과가 늦게 나옵니다.

함께 쓰는 차원은 한 팀이 혼자 고칠 수 없습니다. 카테고리 이름 하나를 바꾸면 그 차원을 쓰는 모든 팩트 테이블의 집계가 바뀝니다. 그래서 차원을 고치는 절차와 책임자를 따로 둡니다.

데이터의 정의와 품질을 조직 단위로 관리하는 일을 데이터 거버넌스라고 합니다. 공통 차원의 열 이름과 값을 정하는 일도 여기에 들어갑니다. 이 설계는 기술보다 이 관리가 무너질 때 먼저 깨집니다.

차원이 시간에 따라 바뀌는 문제도 공통이 됩니다. 칫솔의 카테고리가 바뀌었을 때 지난달 판매를 옛 카테고리로 볼지 새 카테고리로 볼지를 정해야 합니다. 이 결정을 다루는 기법을 천천히 변하는 차원이라고 합니다. 공통 차원에서는 이 결정 하나가 모든 업무의 숫자에 걸립니다.

중앙 정규화 저장소를 두는 설계

데이터 웨어하우스를 짓는 큰 흐름은 둘로 자주 갈립니다. 하나가 이 버스 아키텍처입니다. 다른 하나가 Corporate Information Factory(CIF)입니다. 둘 다 회사 전체의 숫자를 맞추는 것이 목표입니다.

CIF 는 한가운데에 정규화한 큰 저장소를 먼저 짓습니다. 정규화는 같은 사실을 한 번만 적도록 테이블을 잘게 나누는 설계입니다.

부서용 마트는 그 중앙 저장소에서 뽑아 만듭니다. 모든 마트가 같은 중앙 저장소에서 나왔으므로 숫자가 맞습니다.

버스 아키텍처는 중앙 정규화 저장소를 꼭 두지 않습니다. 숫자가 맞는 까닭은 마트들이 공통 차원을 함께 쓰기 때문입니다.

이 둘은 흔히 설계를 내놓은 사람의 이름으로도 불립니다. 버스 아키텍처는 랄프 킴벌(Ralph Kimball) 쪽 방식입니다. CIF 는 빌 인먼(Bill Inmon) 쪽 방식입니다.

잘 안 맞는 경우

분석할 업무가 하나뿐이면 맞출 상대가 없습니다. 이때는 스타 스키마 하나로 충분합니다. 버스 매트릭스를 그릴 일도 없습니다.

부서끼리 기준을 합의할 수 없는 조직에도 맞지 않습니다. 공통 차원이 서지 않으면 이 설계는 이름만 남습니다. 결국 독립 마트 여러 개로 돌아갑니다.

관련 항목

이 설계가 속하는 상위 분류

데이터 웨어하우스 · 차원 모델링 · 데이터 모델링 · 데이터 아키텍처

이 설계를 이루는 구성 요소

컨폼드 디멘션 · 컨폼드 팩트 · 버스 매트릭스 · 데이터 마트 · 팩트 테이블 · 차원 테이블 · 측정값 · 그레인 · 대리 키 · 비즈니스 프로세스

이 설계 위에서 짓는 모델과 조회 방식

스타 스키마 · 스노우플레이크 스키마 · 팩트 컨스텔레이션 · 드릴 어크로스

같은 역할을 두고 겨루는 웨어하우스 설계

Corporate Information Factory · 독립 데이터 마트 · 데이터 볼트 · DW 2.0 · 메달리온 아키텍처 · 데이터 레이크하우스

공통 차원을 채우고 지키는 처리

ETL · ELT · 데이터 거버넌스 · 마스터 데이터 관리 · 천천히 변하는 차원 · 정규화

이 설계의 결과를 읽는 분석 도구

OLAP · OLAP 큐브 · 비즈니스 인텔리전스 · 시맨틱 레이어

이름을 빌려 온 컴퓨터 구조

버스 · 시스템 버스 · 컴퓨터 구조