온라인 분석 처리

온라인 분석 처리는 쌓아 둔 데이터를 넓게 훑어 합계와 추세를 묻는 일입니다. 「지난 분기 지역별 매출」에 답하는 일이 여기에 속합니다. 주문 한 건을 넣고 읽는 서비스 쪽 일과 성격이 달라서 따로 떼어 다룹니다. 좁게는 데이터를 여러 기준으로 자르고 합쳐 보는 다차원 분석을 가리킵니다.

상세

동네 빵집 계산대에서는 손님 한 명씩 빵값을 받고 영수증을 끊습니다. 한 번에 몇 초면 끝납니다. 손님은 줄을 섭니다. 월말이 되면 사장이 한 달 치 영수증을 전부 펼쳐 놓고 빵 종류별 판매량을 더합니다. 이 일을 계산대에서 하면 그동안 손님 줄이 멈춥니다.

온라인 분석 처리(OLAP, Online Analytical Processing)는 데이터를 두고 월말 정산을 합니다. 계산대에서 하는 일에 해당하는 것은 온라인 트랜잭션 처리(OLTP, Online Transaction Processing)라고 부릅니다. 두 이름은 언제나 짝으로 쓰입니다.

데이터베이스에 던지는 질문 한 건을 쿼리라고 부릅니다. 이름의 「온라인」은 사람이 쿼리를 던지고 곧바로 답을 받는다는 뜻입니다. 미리 정해 둔 보고서를 정해진 때에 뽑아 받는 방식과 견준 말입니다.

이 절은 쇼핑몰 주문 데이터를 예로 듭니다. 먼저 분석 쿼리의 모양을 보고 OLTP 와 견줍니다. 이어서 둘을 왜 떼어 두는지와 분석용 저장소가 데이터를 어떻게 담는지를 봅니다. 좁은 뜻인 다차원 분석을 보고, OLAP 가 맞지 않는 일로 끝냅니다.

분석 쿼리의 모양

쇼핑몰의 orders 테이블에 주문이 한 행씩 쌓여 있다고 합시다. 열은 주문 번호 · 고객 · 지역 · 금액 · 주문 시각입니다. 기획자가 「지난 분기 지역별 매출」을 묻습니다.

이 질문을 SQL(Structured Query Language, 구조화 질의 언어)로 옮기면 아래와 같습니다.

SELECT region,
       SUM(amount)    -- 지역별 합계
FROM orders
WHERE ordered_at >= '2026-07-01'
  AND ordered_at <  '2026-10-01'
GROUP BY region;

이 쿼리는 석 달 치 주문을 전부 읽습니다. 그런데 돌려주는 것은 지역마다 한 줄입니다. 쓰는 열도 지역 · 금액 · 주문 시각 셋뿐입니다.

이 모양이 분석 쿼리의 전형입니다. 행은 많이 훑고 열은 몇 개만 씁니다. 결과는 작게 줄어듭니다. 많은 값을 합계나 평균 같은 값 하나로 줄이는 계산을 집계라고 부릅니다. OLAP 는 집계가 주된 일입니다.

온라인 트랜잭션 처리와 갈리는 점

같은 쇼핑몰에서 서비스가 하는 일은 반대 모양입니다. 고객이 주문 버튼을 누르면 주문 한 행을 넣습니다. 재고도 한 행 고칩니다. 고객이 주문 내역을 열면 그 고객의 행 몇 개만 읽습니다.

이런 짧은 요청을 쉴 새 없이 받아 처리하는 일이 OLTP 입니다. 요청 하나가 건드리는 행은 몇 개뿐입니다. 대신 요청이 끊임없이 들어옵니다. 하나하나가 빨리 끝나야 뒤의 요청이 밀리지 않습니다.

두 일을 나란히 놓으면 이렇게 갈립니다.

이렇게 모양이 반대인 두 일은 한 데이터베이스에 함께 두기 어렵습니다. 아래 두 소절이 그 이야기입니다. 먼저 큰 쿼리가 짧은 요청을 밀어내는 문제를 봅니다. 이어서 읽는 행과 열의 모양에 맞춘 저장 방식을 봅니다.

둘을 따로 두는 까닭

서비스가 요청마다 읽고 쓰는 데이터베이스를 운영 데이터베이스라고 부릅니다. 여기에 큰 집계를 섞으면 그 쿼리가 디스크와 프로세서를 오래 붙잡습니다. 그동안 주문을 넣는 짧은 요청이 기다립니다. 고객 눈에는 결제 버튼이 느려진 것으로 보입니다.

그래서 분석할 데이터를 따로 복사해 둡니다. 여러 서비스의 데이터를 분석하기 쉬운 모양으로 모아 오래 쌓는 저장소를 데이터 웨어하우스라고 부릅니다. 앞에서 말한 분석용 저장소가 이것입니다. 웨어하우스는 분석 쿼리만 받는 데이터베이스입니다.

운영 데이터베이스에서 데이터를 꺼내 모양을 다듬고 웨어하우스에 넣는 작업이 따로 필요합니다. 이 작업을 ETL(Extract Transform Load, 추출·변환·적재)이라고 부릅니다. 대개 밤마다 또는 몇 시간마다 정해진 때에 돕니다.

flowchart TD
    subgraph 서비스["서비스 쪽 · OLTP"]
        A["고객의 요청"] --> B["운영 데이터베이스"]
    end
    subgraph 분석["분석 쪽 · OLAP"]
        E["분석가의 쿼리"] --> D["데이터 웨어하우스"]
    end
    B -->|"ETL · 정해진 때에"| D

그림에서 운영 데이터베이스는 ETL 이 데이터를 읽어 갈 때만 분석 쪽과 만납니다. 분석가의 쿼리가 아무리 무거워도 그 부담은 웨어하우스 안에서 끝납니다.

대가는 데이터가 두 벌이 된다는 것입니다. 분석 쪽은 마지막으로 옮겨 온 때까지만 봅니다. 밤마다 옮기면 오늘 들어온 주문은 내일에야 분석에 잡힙니다.

분석에 맞춘 저장 방식

웨어하우스가 큰 집계를 빨리 끝내는 방법을 셋 봅니다. 값을 열마다 모아 저장하기, 결과를 미리 합쳐 두기, 테이블을 덜 나눠 두기입니다.

운영 데이터베이스는 대개 한 행의 값을 디스크에 붙여 저장합니다. 이것을 행 지향 저장이라고 부릅니다. 주문 한 건을 읽으면 그 행의 값이 한 번에 다 읽힙니다. 한 건씩 다루는 OLTP 에 맞는 저장 모양입니다.

분석 쿼리에는 이 저장 모양이 손해입니다. 금액 열 하나만 필요해도 행 전체를 읽어야 합니다. 그래서 웨어하우스는 같은 열의 값끼리 모아 저장합니다. 이것을 열 지향 저장이라고 부릅니다.

아래 그림은 주문 세 건을 두 방식으로 디스크에 적은 모양입니다. 화살표는 디스크에 이어서 적히는 차례입니다. 칸 하나가 한 번에 붙여 적는 덩어리입니다.

flowchart TD
    subgraph 행["행 지향 · 주문 한 건의 값을 이어 적는다"]
        R1["주문 1 · 서울 · 3000"] --> R2["주문 2 · 부산 · 5000"]
        R2 --> R3["주문 3 · 서울 · 2000"]
    end
    subgraph 열["열 지향 · 한 열의 값을 이어 적는다"]
        C1["주문 번호 덩어리 · 1 · 2 · 3"] --> C2["지역 덩어리 · 서울 · 부산 · 서울"]
        C2 --> C3["금액 덩어리 · 3000 · 5000 · 2000"]
    end
    행 ~~~ 열

행 지향 쪽은 칸마다 서로 다른 종류의 값이 섞여 있습니다. 열 지향 쪽은 칸마다 한 종류의 값만 있습니다.

지역별 금액 합계를 낼 때 열 지향 쪽은 지역 덩어리와 금액 덩어리만 읽습니다. 주문 번호 덩어리는 건드리지 않습니다. 행 지향 쪽은 세 칸을 전부 읽어야 합니다. 열이 수십 개인 테이블이라면 읽는 양의 차이가 그만큼 커집니다.

같은 열에는 같은 종류의 값이 모입니다. 지역 열이라면 몇 안 되는 지역 이름이 되풀이됩니다. 이렇게 겹치는 값이 많으면 압축이 잘 됩니다. 디스크에서 읽는 양이 한 번 더 줄어듭니다.

열 지향으로 데이터를 파일에 적는 형식으로는 Apache Parquet 이 널리 쓰입니다. 파일 하나 안에서도 값이 열마다 나뉘어 있어서 필요한 열만 골라 읽을 수 있습니다.

두 번째 방법은 자주 묻는 집계를 미리 계산해 두는 것입니다. 날짜별 · 상품별 매출 합계를 밤마다 계산해 두면 그 질문은 작은 표 하나만 읽고 끝납니다. 쿼리 결과를 테이블처럼 저장해 두는 기능을 구체화된 뷰라고 부릅니다. 대가는 미리 정한 기준으로 묻는 질문만 빨라진다는 것입니다.

세 번째 방법은 테이블 모양에 있습니다. 운영 데이터베이스는 같은 값을 한 곳에만 두려고 테이블을 잘게 나눕니다. 이것을 정규화라고 합니다. 고칠 때 한 곳만 고치면 되니 OLTP 에 맞습니다.

분석 쪽은 반대로 테이블을 덜 나눕니다. 테이블 둘을 키로 이어 붙이는 일을 조인이라고 부릅니다. 테이블이 잘게 나뉠수록 한 질문에 조인이 여러 번 필요합니다. 행이 많은 큰 쿼리에서는 그만큼 느려집니다.

덜 나눈 대표 모양이 스타 스키마입니다. 가운데에 매출 같은 숫자를 담는 테이블 하나를 둡니다. 그 둘레에 날짜 · 상품 · 지역처럼 숫자를 가르는 기준을 담은 테이블을 하나씩 붙입니다.

스타 스키마도 테이블을 여럿 잇습니다. 그래도 기준 테이블이 한 겹뿐이라 가운데 테이블에서 한 번씩만 이어 붙이면 됩니다. 정규화된 모양이라면 상품에서 분류로, 분류에서 다시 상위 분류로 몇 겹을 더 따라가야 합니다.

다차원 분석과 큐브

OLAP 를 좁게 쓰면 다차원 분석을 가리킵니다. 이 뜻은 비즈니스 인텔리전스 도구에서 자주 만납니다. 회사의 매출 같은 숫자를 표와 차트로 보여 주는 도구입니다.

매출을 볼 때는 지역별로, 월별로, 상품별로 나눠 봅니다. 이렇게 숫자를 가르는 기준 하나를 차원이라고 부릅니다. 갈라 볼 숫자 쪽, 여기서는 매출 금액을 측정값이라고 부릅니다.

앞에서 본 스타 스키마로 돌아가 봅시다. 가운데 테이블이 측정값을 담습니다. 둘레의 기준 테이블은 차원을 담습니다. 테이블을 이렇게 차원과 측정값으로 갈라 짜는 방법을 차원 모델링이라고 부릅니다.

차원 셋을 축으로 세우면 상자 모양이 됩니다. 칸 하나에는 「서울 · 7월 · 우유」의 매출 같은 측정값 하나가 들어갑니다. 이 상자를 OLAP 큐브라고 부릅니다. 차원이 넷 이상이어도 이름은 그대로 큐브입니다.

큐브는 차원이 셋 이상이라 화면에 그대로 띄울 수 없습니다. 그래서 차원 둘을 골라 가로와 세로에 놓고 표 한 장으로 펼쳐 봅니다. 그 표를 바꿔 가며 보는 연산들에는 이름이 붙어 있습니다.

이 연산들을 SQL 로 옮기면 대부분 GROUP BY 의 기준을 바꾸거나 WHERE 조건을 더하는 일입니다. 큐브는 그 조합을 사람이 클릭 몇 번으로 바꿔 가며 보게 해 줍니다.

큐브를 담는 방식은 둘로 갈립니다. 칸의 값을 미리 계산해 전용 저장소에 담아 두는 방식이 MOLAP(Multidimensional OLAP, 다차원 OLAP)입니다. 관계형 테이블에 두고 물을 때마다 계산하는 방식은 ROLAP(Relational OLAP, 관계형 OLAP)입니다.

MOLAP 은 미리 계산한 만큼 조회가 빠릅니다. 대신 차원이 늘면 계산해 둘 칸이 곱으로 불어납니다. 차원 셋에 값이 열 개씩이면 칸이 천 개입니다. 차원이 하나 늘면 만 개가 됩니다.

맞는 일과 맞지 않는 일

OLAP 는 많은 데이터를 자주 집계해 봐야 할 때 씁니다. 매출 보고서와 경영 지표 화면, 기획자가 던지는 즉석 질문이 그렇습니다. 그 부담을 서비스와 떼어야 할 때 따로 둘 이유가 생깁니다.

행 하나를 읽고 고치는 일에는 맞지 않습니다. 열 지향으로 저장한 웨어하우스에서 주문 한 건을 고치려면 열마다 흩어진 값을 하나씩 찾아 고쳐야 합니다. 이런 일은 OLTP 쪽 데이터베이스가 받습니다.

몇 초 안의 최신 값이 필요한 일도 정해진 때에 옮겨 쌓는 구성으로는 못 받습니다. 이상 거래를 바로 잡아내는 일이 그렇습니다. 이런 일은 들어오는 데이터를 바로 흘려 처리하는 스트리밍 처리가 받습니다.

데이터가 작고 분석이 드물면 웨어하우스를 따로 둘 까닭이 적습니다. 운영 데이터베이스를 복제한 읽기 복제본에 분석 쿼리를 던지면 주문 처리를 밀어내지 않고 답을 얻습니다.

관련 항목

온라인 분석 처리와 맞세워지는 처리 방식

온라인 트랜잭션 처리 · HTAP · 배치 처리 · 스트리밍 처리 · 실시간 분석

온라인 분석 처리가 돌아가는 저장소

데이터 웨어하우스 · 데이터 마트 · 데이터 레이크 · 레이크하우스 · 열 지향 데이터베이스 · 읽기 복제본

분석 쿼리를 빠르게 하는 저장 기법

열 지향 저장 · 행 지향 저장 · Apache Parquet · 압축 · 파티셔닝 · 구체화된 뷰 · 비정규화

다차원 분석을 이루는 구성 요소

OLAP 큐브 · 차원 · 측정값 · 팩트 테이블 · 차원 테이블 · 스타 스키마 · 스노우플레이크 스키마 · 차원 모델링

큐브를 두고 하는 분석 연산

드릴다운 · 롤업 · 슬라이스와 다이스 · 피벗 · 집계 · GROUP BY

큐브를 담는 방식에 따른 하위 종류

MOLAP · ROLAP · HOLAP

분석용 저장소를 채우는 데이터 이동

ETL · ELT · 변경 데이터 캡처 · 데이터 파이프라인 · 운영 데이터베이스

온라인 분석 처리가 속하는 상위 분류

데이터 엔지니어링 · 데이터 분석 · 비즈니스 인텔리전스 · 데이터베이스 · 데이터 모델링

분석 결과를 받아 보는 도구

대시보드 · 피벗 테이블 · SQL · 쿼리 · 보고서