데이터 웨어하우스

데이터 웨어하우스는 여러 시스템에 흩어진 데이터를 한곳에 모아 분석 질문에 답하게 해 줍니다. 회사의 여러 기록을 같은 모양으로 맞춰 오래 쌓아 둡니다. 서비스를 돌리는 데이터베이스와 따로 두어서 수많은 행을 훑는 집계가 서비스를 느리게 만들지 않게 합니다.

쉽고 빠른 이해

데이터 웨어하우스는 여러 시스템의 기록을 한곳에 모아 분석에 쓰는 저장소입니다. 쇼핑몰이라면 주문, 회원, 광고 기록을 모아 「지난 분기에 어느 광고로 온 손님이 제일 많이 샀나」에 답합니다.

서비스용 데이터베이스에 이런 질문을 바로 던지면 수백만 행을 훑느라 주문 받기가 느려집니다. 기록이 여러 곳에 제각각인 이름으로 흩어져 있어 한 번에 묻기도 어렵습니다.

어떻게 도나:

정해진 때마다 각 시스템에서 데이터를 뽑아 옵니다
이름과 형식을 하나로 맞춥니다
분석 질문에 맞춘 모양으로 쌓아 두고 집계 질문을 받습니다

대가는 데이터가 늦다는 것입니다. 오늘 들어온 주문은 다음 옮기기가 끝나야 보입니다. 옮기는 과정을 따로 굴리고 고쳐야 하는 일도 생깁니다.

상세

빵집 지점 다섯 곳이 각자 장부를 씁니다. 본사는 달마다 지점 장부를 모아 결산 장부 한 권에 옮겨 적습니다. 옮길 때 지점마다 다르게 적은 빵 이름을 하나로 맞춥니다. 사장은 결산 장부만 펴 보고 어느 지점에서 무엇이 잘 팔렸는지 봅니다.

데이터 웨어하우스는 여러 시스템의 데이터를 모아 분석용으로 정리해 두는 저장소입니다. 온라인 쇼핑몰이라면 주문 데이터베이스, 회원 데이터베이스, 광고 클릭 로그를 한데 모읍니다. 그러면 「지난 분기에 어느 광고로 들어온 회원이 가장 많이 샀나」를 질문 하나로 물을 수 있습니다.

이 절은 그 쇼핑몰 하나를 따라가며 웨어하우스를 왜 따로 두는지부터 언제 맞지 않는지까지 봅니다.

서비스용 데이터베이스와 따로 두는 이유

쇼핑몰의 주문 데이터베이스는 주문을 받는 일을 합니다. 한 번에 주문 한 건을 넣고 회원 한 명의 정보를 읽습니다. 몇 행만 건드리는 짧은 읽기와 쓰기가 쉴 새 없이 들어옵니다.

이런 일을 OLTP(Online Transaction Processing, 온라인 트랜잭션 처리)라고 부릅니다. 여기서 트랜잭션은 함께 성공하거나 함께 실패해야 하는 작업 한 묶음입니다. 주문 한 건을 넣는 일과 재고를 하나 줄이는 일이 묶여 한 트랜잭션이 됩니다.

분석 질문은 모양이 다릅니다. 「지난 분기 지역별 매출」을 구하려면 석 달 치 주문을 전부 훑어 금액을 더해야 합니다. 몇 행이 아니라 수백만 행을 읽습니다.

이런 일을 OLAP(Online Analytical Processing, 온라인 분석 처리)라고 부릅니다. 많은 행을 읽어 합계나 평균 같은 값 하나로 줄이는 계산을 집계라고 합니다. OLAP 는 집계가 주된 일입니다.

두 일을 한 데이터베이스에서 돌리면 부딪힙니다. 수백만 행을 훑는 집계가 디스크와 프로세서를 오래 붙잡습니다. 그동안 주문 넣기가 기다립니다. 손님은 결제 버튼을 누른 뒤 멈춘 화면을 봅니다.

서비스용 데이터베이스는 대개 지금 상태만 들고 있습니다. 회원이 주소를 바꾸면 옛 주소는 새 주소로 덮어써져 사라집니다. 그러면 「이사하기 전 지역에서 얼마나 샀나」에는 더 답할 수 없습니다.

데이터가 여러 시스템에 흩어진 것도 걸림돌입니다. 주문 데이터베이스는 회원을 member_id 로 부릅니다. 광고 로그는 같은 회원을 user 로 부릅니다. 두 곳을 잇는 분석을 할 때마다 이 차이를 매번 새로 맞춰야 합니다.

두 쪽을 나란히 놓으면 이렇습니다.

	서비스용 데이터베이스	데이터 웨어하우스
하는 일	주문을 받고 회원 정보를 고친다	쌓인 기록을 모아 집계한다
한 번에 읽는 양	몇 행	수백만 행
담는 시점	지금 상태	지난 이력까지
데이터가 들어오는 방식	사용자가 그때그때 쓴다	정해진 때에 몰아서 들어온다
주로 읽는 쪽	서비스 코드	분석가 · 대시보드

표의 다섯 줄이 전부 반대 방향입니다. 한 저장소가 두 쪽을 다 맞추기 어려워서 분석용 저장소인 데이터 웨어하우스를 따로 둡니다.

원천에서 웨어하우스로 들어오는 길

웨어하우스로 데이터를 내주는 쪽을 원천 시스템이라고 부릅니다. 쇼핑몰에서는 주문 데이터베이스, 회원 데이터베이스, 광고 클릭 로그가 원천 시스템입니다. 웨어하우스는 원천에서 데이터를 복사해 올 뿐입니다. 원천을 대신하지 않습니다.

복사는 세 단계를 거칩니다. 뽑아 오고, 다듬고, 넣습니다.

단계	하는 일	쇼핑몰에서
추출	원천 시스템에서 필요한 데이터를 뽑아 온다	어제 들어온 주문 행을 읽어 온다
변환	이름과 형식을 맞추고 틀린 값을 걸러 낸다	`member_id` 와 `user` 를 고객 번호 하나로 맞춘다
적재	다듬은 데이터를 웨어하우스 테이블에 넣는다	판매 테이블 끝에 어제 치를 덧붙인다

세 단계를 이 순서로 도는 방식을 ETL(Extract, Transform, Load, 추출·변환·적재)이라고 부릅니다. 흐름을 그리면 아래와 같습니다.

flowchart TD
    subgraph 원천["원천 시스템"]
        A["주문 데이터베이스"]
        B["회원 데이터베이스"]
        C["광고 클릭 로그"]
    end
    원천 --> E["추출"]
    E --> T["변환"]
    T --> L["적재"]
    L --> W["데이터 웨어하우스"]
    W --> D["분석가 · 대시보드"]

순서를 바꿔 먼저 넣고 나중에 다듬는 방식도 있습니다. 이것을 ELT(Extract, Load, Transform, 추출·적재·변환)라고 부릅니다. 원본을 웨어하우스 안에 먼저 쌓아 두고 웨어하우스의 계산 자원으로 변환합니다. 원본이 남아 있으니 변환 규칙이 바뀌면 다시 돌릴 수 있습니다.

이 흐름은 대개 정해진 때에 몰아서 돕니다. 밤마다 하루 치를 한 번에 옮기는 식입니다. 모아 두었다가 한 번에 처리하는 이 방식이 배치 처리입니다.

그래서 웨어하우스의 데이터는 원천보다 늦습니다. 오늘 오후에 들어온 주문은 밤의 배치가 끝난 뒤에야 보입니다. 더 자주 옮기고 싶으면 원천에서 바뀐 행만 골라 흘려보냅니다. 이 방식을 변경 데이터 캡처라고 부릅니다.

웨어하우스에 쌓인 데이터의 네 가지 성질

웨어하우스에 쌓인 데이터는 서비스용 데이터베이스의 데이터와 성질이 다릅니다. 흔히 네 가지로 정리합니다. 아래 표는 그 넷을 쇼핑몰에 대어 본 것입니다.

성질	뜻	쇼핑몰에서
주제 중심	시스템 단위가 아니라 분석 주제 단위로 묶는다	「주문 시스템의 테이블」이 아니라 「판매」와 「고객」
통합	원천마다 다른 이름과 형식을 하나로 맞춘다	금액 단위와 날짜 표기가 모두 한 가지다
이력 보존	원천에서 값이 바뀌면 옛 값을 지우지 않고 새 행을 더한다	이사 전 주소와 이사 후 주소가 둘 다 남는다
덧붙이기	이미 넣은 행은 나중에 고치지 않는다	지난달 매출을 오늘 다시 뽑아도 같은 값이 나온다

넷 가운데 서비스용 데이터베이스와 가장 크게 갈리는 것은 이력 보존입니다. 서비스는 지금 상태만 알면 됩니다. 분석은 과거와 견주는 일이 많습니다. 기록을 얼마나 오래 남길지는 보존 기간으로 정합니다.

이력 보존과 덧붙이기는 보는 곳이 다릅니다. 이력 보존은 원천에서 바뀐 값을 받는 방식입니다. 회원이 주소를 바꾸면 옛 주소 행을 그대로 두고 새 주소 행을 더합니다.

덧붙이기는 웨어하우스에 이미 넣은 행을 나중에 고치지 않는다는 뜻입니다. 그래서 지난달 매출을 오늘 다시 뽑아도 같은 값이 나옵니다.

팩트 테이블과 차원 테이블

테이블을 짜는 모양도 서비스용 데이터베이스와 다릅니다. 서비스 쪽은 같은 값이 두 번 저장되지 않도록 테이블을 잘게 나눕니다. 이렇게 나누는 일을 정규화라고 합니다.

잘게 나누면 값 하나를 고칠 때 한 곳만 고치면 됩니다. 대신 읽을 때 테이블을 다시 이어 붙여야 합니다. 테이블 둘을 같은 번호끼리 이어 붙이는 연산이 조인입니다. 잘게 나눌수록 분석 질문 하나에 붙는 조인이 늘어납니다.

그래서 웨어하우스는 테이블을 덜 나눕니다. 분석 질문에 맞춰 테이블을 짜는 이 방법이 차원 모델링입니다.

차원 모델링은 테이블을 두 종류로 가릅니다. 첫째는 팩트 테이블입니다. 일어난 일을 숫자로 적습니다. 판매 한 건의 수량과 금액이 한 행입니다.

둘째는 차원 테이블입니다. 그 숫자를 가를 기준을 담습니다. 언제 팔렸나, 무엇이 팔렸나, 누가 샀나, 어느 광고로 들어왔나가 각각 날짜 차원, 상품 차원, 고객 차원, 광고 차원이 됩니다. 팩트 테이블의 행은 이 차원 테이블들의 행을 번호로 가리킵니다.

flowchart TD
    D1["날짜 차원"] --- F["판매 팩트 테이블"]
    D2["상품 차원"] --- F
    F --- D3["고객 차원"]
    F --- D4["광고 차원"]

팩트 테이블 하나를 차원 테이블 여럿이 둘러싸 별 모양이 됩니다. 그래서 이 모양을 스타 스키마라고 부릅니다. 「지난 분기 광고별 매출」은 판매 팩트 테이블을 날짜 차원으로 거르고 광고 차원으로 묶어 금액을 더하면 나옵니다.

열 지향 저장

분석 질문은 행은 많이 읽고 열은 조금 읽습니다. 광고별 매출에 필요한 열은 날짜, 광고, 금액 정도입니다. 판매 테이블에 열이 서른 개 있어도 나머지 스물일곱은 필요 없습니다.

흔한 데이터베이스는 한 행의 값들을 디스크에 붙여 적습니다. 이 방식을 행 지향 저장이라고 합니다. 한 행을 통째로 읽고 쓰기 편해서 주문 한 건을 넣는 일에 맞습니다. 대신 금액 열 하나만 필요해도 행 전체를 디스크에서 읽어 와야 합니다.

열 지향 저장은 반대로 한 열의 값들을 붙여 적습니다. 금액만 필요하면 금액 묶음만 읽습니다. 아래 그림은 주문 번호, 날짜, 금액을 담은 행 세 개가 두 방식에서 어떻게 묶이는지 보입니다.

flowchart TD
    subgraph 행["행 지향 저장"]
        R1["주문 1 · 3월 2일 · 12,000원"]
        R2["주문 2 · 3월 2일 · 8,000원"]
        R3["주문 3 · 3월 3일 · 15,000원"]
        R1 ~~~ R2 ~~~ R3
    end
    subgraph 열["열 지향 저장"]
        C1["주문 번호 · 1 · 2 · 3"]
        C2["날짜 · 3월 2일 · 3월 2일 · 3월 3일"]
        C3["금액 · 12,000원 · 8,000원 · 15,000원"]
        C1 ~~~ C2 ~~~ C3
    end
    행 ~~~ 열

열 지향 저장에서는 같은 종류의 값이 이웃해 붙어 있습니다. 날짜 묶음에 같은 날짜가 여러 번 이어지는 식입니다. 비슷한 값이 몰려 있으면 압축이 잘 먹혀서 디스크에서 읽을 양이 더 줄어듭니다.

그래서 데이터 웨어하우스는 흔히 열 지향 저장을 씁니다. 대가는 한 행을 새로 넣거나 고치기가 번거롭다는 것입니다. 한 행의 값이 열마다 다른 묶음에 흩어져 있기 때문입니다. 밤마다 몰아서 넣는 배치 적재가 이 약점을 덜 드러나게 합니다.

데이터 마트와 데이터 레이크

웨어하우스 가까이에 이름이 비슷한 저장소가 둘 있습니다. 데이터 마트는 웨어하우스를 한 부서나 한 주제에 맞게 좁힌 것입니다. 마케팅 팀이 광고 성과만 따로 떼어 쓰는 저장소가 데이터 마트입니다.

데이터 레이크는 원본을 가공하지 않은 채 쌓아 두는 저장소입니다. 형식도 가리지 않습니다. 로그 파일, 이미지, 표 데이터가 원래 모양으로 함께 들어갑니다. 무엇에 쓸지 정하기 전에 일단 모아 두려는 것입니다.

둘을 가르는 것은 모양을 정하는 시점입니다. 테이블에 어떤 열이 있고 각 열에 어떤 타입이 들어가는지 적은 설계도를 스키마라고 합니다. 웨어하우스는 넣기 전에 스키마를 정하고 거기 맞는 데이터만 받습니다. 넣기 전에 스키마를 정하는 이 방식이 쓰기 시 스키마입니다.

레이크는 스키마 없이 일단 넣습니다. 읽는 쪽이 그때 모양을 해석합니다. 읽을 때 스키마를 정하는 이 방식이 읽기 시 스키마입니다.

	데이터 웨어하우스	데이터 마트	데이터 레이크
담는 범위	회사 전체	한 부서나 한 주제	회사 전체
담는 모양	정리한 테이블	정리한 테이블	원본 파일
모양을 정하는 때	넣기 전	넣기 전	읽을 때

마트는 웨어하우스의 범위를 좁힌 것입니다. 레이크는 모양을 정하는 때를 뒤로 미룬 것입니다.

웨어하우스가 맞지 않는 경우

웨어하우스의 데이터는 원천보다 늦습니다. 그래서 방금 바뀐 값을 보여 줘야 하는 화면에는 맞지 않습니다. 상품 페이지의 남은 재고는 서비스용 데이터베이스에서 읽어야 합니다.

옮기는 과정을 따로 굴려야 합니다. 원천 테이블의 열 이름 하나가 바뀌면 변환이 깨집니다. 그러면 다음 날 아침 대시보드가 비어 있습니다. 같은 데이터를 원천과 웨어하우스에 두 번 저장하는 비용도 듭니다.

데이터가 작고 질문이 단순하면 웨어하우스 없이도 됩니다. 서비스용 데이터베이스를 따라 복사되는 사본을 하나 두고 거기서 집계하는 방법입니다. 이 사본을 읽기 전용 복제본이라고 부릅니다. 집계 질문이 사본으로 가므로 원본의 부담이 줄어듭니다.