비즈니스 데이터 처리와 OLTP
비즈니스 데이터 처리는 주로 상거래(commercial Transaction) 과정에서 이루어진다.
이 과정에서 사용자 입력을 기반으로 데이터베이스의 레코드가 삽입되거나 갱신된다.
이러한 작업을 수행하는 애플리케이션은 온라인 트랜잭션 처리(Online Transaction Processing, OLTP)라고 한다.
OLTP와 OLAP의 차이점
데이터 분석에서 사용하는 질의(Query)는 일반적으로 원시 데이터를 그대로 반환하는 것이 아니라, 많은 수의 레코드를 읽고 필요한 일부 컬럼만 활용하여 집계 통계를 계산한다.
이러한 분석 작업은 기업의 현재 성과를 측정하거나 미래의 의사결정을 지원하는 보고서(비즈니스 인텔리전스, BI)를 생성하는 데 유용하다
이와 같은 분석 작업은 온라인 분석 처리(Online Analytic Processing, OLAP)라는 별도의 패러다임으로 구분한다.
아래 표는 OLTP와 OLAP의 주요 차이점을 요약한 것이다.
| 특성 | 트랜잭션 처리 시스템(OLTP) | 분석 시스템(OLAP) |
|---|---|---|
| 주요 읽기 패턴 | 질의당 적은 수의 레코드, 키 기준으로 가져옴 | 많은 레코드에 대한 집계 |
| 주요 쓰기 패턴 | 임의 접근, 사용자 입력을 낮은 지연 시간으로 기록 | 대규모 불러오기(bulk import, ETL) 또는 이벤트 스트림 |
| 주요 사용처 | 웹 애플리케이션을 통한 최종 사용자/소비자 | 의사결정 지원을 위한 내부 분석가 |
| 데이터 표현 | 데이터의 최신 상태 | 시간이 지나며 일어난 이벤트 이력 |
| 데이터셋 크기 | GB ~ TB | TB ~ PB |
처음에는 OLTP에서 분석하는 경향을 보였지만, 최근에는 데이터 웨어하우스(data warehouse)로 불리는 OLAP을 사용한다.
데이터 웨어하우스의 필요성과 ETL 과정
초기에는 OLTP 시스템에서 데이터 분석 작업을 직접 수행하려는 시도가 있었다.
하지만 분석 쿼리는 OLTP 시스템의 성능을 저하시키고, 주요 트랜잭션 처리에 영향을 줄 수 있어 비효율적이다.
이를 해결하기 위해 분석 전용 데이터베이스 공간인 데이터 웨어하우스(Data Warehouse)가 도입되었다.
데이터 웨어하우스는 OLTP 데이터베이스로부터 데이터를 주기적으로 추출(Extract)하고, 분석에 적합한 형태로 변환(Transform)하여 적재(Load)하는 과정을 거치는데, 이를 ETL(Extract-Transform-Load) 프로세스라고 한다.
Snowflake 스키마

많은 데이터 웨어하우스는 스타 스키마(Star Schema) 혹은 차원 모델링(Dimensional Modeling)으로 알려진 구조화된 데이터 모델을 사용한다.
이 스키마의 중심에는 사실 테이블(Fact Table)이 있으며, 주변에는 이를 보조하는 차원 테이블(Dimension Table)이 둘러 쌓여있다.
- 사실 테이블: 특정 시점에 발생한 이벤트 정보를 저장. 예를 들어, 판매 데이터는 판매 시간, 상품, 매장, 판매량 등의 정보를 포함
- 차원 테이블: 이벤트와 관련된 부가적인 정보를 저장하며, 사실 테이블의 외래 키(Foreign Key)로 참조됩니다.
스타 스키마의 변형 형태로 차원 테이블이 하위 차원으로 더 세분화된 눈꽃송이 스키마(Snowflake Schema)가 존재한다.
칼럼 지향 저장소
OLAP 시스템은 데이터를 컬럼(열) 지향 방식으로 저장한다.
이는 로우(행) 지향 방식으로 데이터를 저장하는 OLTP 시스템과 차별화되어있다.
- 로우 지향 방식: 개별 행 데이터를 빠르게 조회하는 데 최적화
- 컬럼 지향 방식: 데이터 분석 작업에서 주로 사용하는 특정 컬럼에만 집중적으로 접근할 수 있도록 설계되어 있으며, 데이터 압축과 빠른 집계 연산이 가능합니다.
예를 들어, 아래와 같은 테이블이 있다고 가정하자
| date_id | product_id | store_id |
| 14000 | 4 | 1 |
| 14001 | 5 | 1 |
| 14002 | 5 | 1 |
- date_id contents: 14000, 14001, 14002
- product_id contents: 4, 5, 5
- store_id: 1, 1, 1
위 처럼 컬럼별로 어떤 값이 있는지 저장할 수 있다.
대표적인 컬럼 지향 저장 형식으로는 파케이(Parquet)이 있으며, 대규모 분석 작업에서 자주 사용된다.
Parquet은 칼럼 기반 설계로 효율적인 저장 및 분석을 지원하며, NoSQL 환경에서도 활용될 수 있다.
컬럼 압축과 벡터화 처리
컬럼 지향 저장소는 데이터 압축에 유리하다.
반복적으로 나타나는 값을 효율적으로 저장하기 위해 비트맵 인코딩(Bitmap Encoding) 기법이 사용된다.
압축된 데이터는 벡터화 처리(Vectorized Processing)를 통해 비트 연산(AND/OR)으로 빠르게 분석할 수 있습니다.
책에서 읽었던 내용으로 저장소 엔진의 전문가가 될 수 없지만,
특정 상황에서 어떤 데이터베이스를 선택해야 하고, 선택한 데이터베이스의 문서를 좀 더 쉽게 이해할 수 있을 것 같다.