트랜잭션 처리 분석
온라인 트랜잭션(OLTP, Online-Transaction-Processing)
실시간 트랜잭션 처리를 담당하는 시스템이다.
- 높은 가용성과 낮은 지연 시간 처리가 중요하다.
- OLTP에서는 즉석 분석 질의는 많은 데이터를 한꺼번에 조회해야 해서 비용이 많이 들고 OLTP에서 실행중인 트랜잭션을 방해할 수 있어 트랜잭션 속도가 느려져 잘 사용되지 않는다.
- 즉석 분석 질의란? 6개월 동안 특정 고객이 구매한 상품 목록과 같이 특정한 데이터를 빠르게 검색하고자 할 때 사용된다. 한번에 많은 데이터를 스캔해야한다. 그래서 OLTP에서는 사용되지 않고 데이터 웨어하우스에서 실행하는 것이 일반적이다.
- 즉석 분석 질의란? 6개월 동안 특정 고객이 구매한 상품 목록과 같이 특정한 데이터를 빠르게 검색하고자 할 때 사용된다. 한번에 많은 데이터를 스캔해야한다. 그래서 OLTP에서는 사용되지 않고 데이터 웨어하우스에서 실행하는 것이 일반적이다.
- 예시 : 은행 시스템, 온라인 쇼핑몰, 예약 시스템 등
데이터 웨어하우징(OLAP, Online-Analytical-Processing)
OLTP 시스템에 영향을 주지 않고 데이터를 분석할 수 있게 해주는 데이터 베이스
- 읽기 전용 데이터 복사본을 저장한다.
- OLTP 시스템에서 추출된 데이터를 분석 -OLTP에서 생성된 데이터가 데이터 웨어하우스로 이동되는 과정-
- OLTP 시스템이 운영 데이터를 생성
- ETL(Extract-Transform-Load) 과정을 통해서 데이터 웨어하우스로 적재
- Extract(추출) : OLTP 시스템에서 데이터를 추출
- Transform(변환) : 데이터를 정제 및 변환(중복제거, 비정규화 등)
- Load(적재) : 데이터 웨어하우스에 저장
- 데이터 웨어하우스에 저장된 데이터를 분석
- 사용 예시 : 기업의 분석 시스템, 빅데이터 분석 플랫폼
데이터 웨어하우스 분석 도구
데이터 웨어하우스에서는 SQL을 이용하여 복잡한 데이터 분석을 수행하고 그래픽 데이터 분석 도구 등을 사용한다.
- 드릴 다운(drill-down) : 데이터를 계층적으로 탐색하여 더 상세한 정보를 조회(예. 전국 매출 → 서울 매출 → 강남구 매출 → 매장별 매출)
- 슬라이싱(slicing) : 특정 기준(필터)으로 데이터를 필터링(예. 2023년 1월 매출 데이터만 조회)
- 다이싱(dicing) : 다차원 데이터에서 다양한 조건을 조합하여 분석(예. 2023년 1~6월 동안, 서울 지역에서 판매된 옷 매출)
많은 데이터베이스 벤더들은 트랜잭션 처리(OLTP)와 데이터 분석(OLAP)중 하나에 집중하는 경우가 많다.
- Oracle, MySQL : 트랜잭션(OLTP) 중심
- Amazon Redshift, Google BigQuery, Snowflake : 데이터 웨어하우스(OLAP) 중심
- Microsoft SQL Server, SAP HANA : OLTP, OLAP 동시에 지원
하지만 이런 데이터베이스는 공통 SQL 인터페이스로 접근할 수 있는 저장소와 질의 엔진으로 점점 분리되고 있다.
“분석”을 위한 데이터 베이스 구조
⭐ 별 모양 스키마(Star schema)
데이터 모델은 트랜잭션 처리 영역에서 애플리케이션의 필요에 따라 다양하게 사용되고 있지만 ‘분석’에서는 다양성이 적다.
많은 데이터 웨어하우스는 별 모양 스키마(star shema)(차원 모델링(dimesonal modeling)인 정형와된 방식을 사용한다.
별 모양 스키마는 스키마 중심에 소위 사실 테이블(fact table)이 있고 이를 둘러싼 여러 차원 테이블로 구성된 데이터 모델이다.
- 사실 테이블이란?
- 비즈니스에서 측정할 값을 저장하는 테이블
- 거래, 매출, 수익 등 수치 데이터를 포함
- 보통 다수의 차원 테이블과 외래키 관계를 맺음
[Fact_Sales]
▲
┌────────┬────────┬────────┬────────┐
│ │ │ │ │
[Date] [Product] [Customer] [Region]❄️ 눈꽃송이 모양 스키마(Snowflake shema)
눈꽃송이 모양 스키마는 별 모양 스키마를 확장한 형태로 차원이 하위 차원으로 더 세분화된다.
별 모양 스키마보다 더 정규화하여 데이터 중복을 줄이고 별모양 스키마를 작업할 때 더 쉬워져 선호되는 구조이다.
[Fact_Sales]
▲
┌──────────┬──────────┬──────────┬──────────┐
│ │ │ │ │
[Date] [Product] [Customer] [Region]
▲
┌────────┴────────┐
│ │
[Category] [Brand]“저장”을 위한 칼럼 지향 저장소
대부분의 OLTP 데이터 베이스는 로우 지향 방식으로 데이터를 배치하여 테이블에서 한 로우의 모든 값은 서로 인접하게 저장된다.
- 로우 지향 방식이란?
- 데이터를 행(row) 단위로 저장하는 방식
- 트랜잭션(OLTP) 최적화
- 행 단위로 데이터를 읽고 쓰는 방식
- WHERE 조건을 사용한 개별 행 검색에 유리
이와 다르게 컬럼 지향 저장소는 모든 값을 하나의 로우에 함께 저장하지 않는 대신 각 칼럼별로 모든 값을 함께 저장한다.
각 컴럼을 개별 파일에 저장하면 질의에 사용되는 칼럼만 읽고 구분 분석하여 작업량을 줄인다.
칼럼 압축
질의에 필요한 칼럼을 디스크에서 읽어 적재하는 작업 외에도 데이터를 압축하면 디스크 처리량을 더 줄일 수 있다.
압축 기법으로는 비트맵 부호화(bitmap encoding) 방식이 있다.
비트맵 부호화는 범주형 데이터 값을 비트 벡터로 변환하는 데이터 인코딩 기법이다.
비트 0, 1을 가지고 값을 표현함으로써 칼럼의 부호화를 줄여 압축시킬 수 있다.
☑️ 메모리가 매우 커서 벡터화 처리하는 것으로 병목이 발생한다면?- 디스크로부터 적재할 데이터 양 줄이기
- 컬럼 저장소 배치로 CPU 최적화 - 벡터화 처리(vectorized processing)
-
압축된 컬럼 데이터를 CPU L1 캐시에 최적화된 크기로 로드
컬럼 지향 저장소로 컬럼 데이터를 압축하고 압축된 데이터를 L1 캐시에 최적화된 크기로 분할하여 로드
-
타이트 루프(Tight Loop)를 사용하여 연산 수행
CPU는 분기가 많은 코드보다 반복적인 연산을 훨씬 더 빠르게 실행하기 때문에 타이트 루프 활용
- 타이트 루프란? 타이트 루프란 불필요한 함수 호출, 조건문, 메모리 접근을 최소화하고 연산을 최대한 연속적으로 수행하여 CPU가 매우 효율적으로 실행할 수 있도록 최적화된 반복문
- 타이트 루프란? 타이트 루프란 불필요한 함수 호출, 조건문, 메모리 접근을 최소화하고 연산을 최대한 연속적으로 수행하여 CPU가 매우 효율적으로 실행할 수 있도록 최적화된 반복문
-
컬럼 압축을 활용하여 L1 캐시 활용
-
컬럼 저장소의 순서 정렬
컬럼 저장소에서 컬럼별로 정리되었을지라도 데이터는 한번에 전체 로우를 정렬해야한다.
이때 공통 질의에 대한 지식을 사용하여 테이블에서 정렬해야하는 칼럼을 선택할 수 있다. 이렇게 원하는 특정 로우만 스캔할 수 있으면 모든 로우를 스캔할 필요가 없어 훨씬 빠르다.
컬럼 지향 저장소의 쓰기 연산
칼럼 지향 저장소는 읽기 성능은 좋지만 쓰기 연산은 어려운 구조를 갖고 있다.
- 압축 칼럼 지향 저장소는 데이터를 압축하여 저장하기 때문에 기존 데이터를 수정하기 위해선 압축을 풀고 다시 저장해야한다. 일반적인 관계형 DB 처럼 제자리 갱신이 불가능하다.
- 정렬 컬럼 지향 저장소는 데이터를 정렬된 상태로 저장하여 빠른 검색을 지원하지만, 데이터를 삽입하면 전체 정렬을 다시 해야해서 성능이 떨어진다.
- 칼럼 기반 저장 컬럼 지향 저장소는 모든 컬럼을 각각 따로 저장하기 때문에 각 컬럼에서 일관된 위치를 유지해야한다. 만약 새로운 행을 추가하려면 모든 컬럼을 갱신해야해서 성능이 떨어진다.
→ LSM 트리 방식을 적용
모든 쓰기는 먼저 인메모리 저장소에 기록하여 정렬된 구조에 추가하고 메모리에서 일정 크기가 되면 디스크에 추가한다.
⇒ 컬럼 지향 저장소에서는 쓰기 문제를 해결하기 위해 LSM 트리 방식을 지원하고 질의 엔진을 통해 최적화 시킨다.
“집계”를 위한 데이터 큐브와 구체화 뷰
모든 데이터 웨어하우스가 칼럼 저장이 필수는 아니다. 하지만 칼럼 저장소는 즉석 분석 질의에 대해 상당이 빠르다.
구체화 뷰(materialized view)
동일한 집계를 많은 다양한 질의에서 사용한다면 매번 원시 데이터를 처리하는 일은 낭비다.
매번 원시 데이터를 처리하지 않기 위해 캐시 데이터를 만드는 한 가지 방법은 구체화 뷰(materialized view)다.
구체화 뷰란 특정 질의 결과를 미리 계산하여 디스크에 저장하는 캐시 방식이다.
일반 뷰와 다르게 질의 실행 없이 바로 데이터를 읽을 수 있어 속도가 빠르다.
일반적으로 관계형 데이터 모델에서는 이런 캐시들을 표준 뷰(Standard View = 가상뷰(Virtual View))로 정의하는데
표준 뷰는 단순한 SQL 단축키일 뿐이며 실제 데이터를 저장하는 것이 아니기 때문에 매번 실행 시 원시 데이터를 다시 검색해야한다.
→ 구체화 뷰는 디스크에 기록된 질의 결과의 실제 복사본이지만 가상 뷰(virtual view)는 단지 질의를 작성하는 단축키일 뿐이다.
데이터 큐브(data cube)
데이터 큐브는 구체화 뷰의 특수한 형태로, 다차원 데이터를 저장하고 분석하는 구조이다.
- 2차원 이상의 다차원 데이터 분석을 지원하는 OLAP 기법의 핵심 개념이다.
- 차원이 많아질 수록 하이퍼 큐브(Hypercube) 개념이 필요하다.
- 하이퍼 큐브란? 다차원 데이터(Multi-Dimensional Data)를 시각적으로 표현하는 개념이다. 하이퍼 큐브로 다차원 데이터의 관계를 표현하고 데이터를 차원별로 분석한다.
- 하이퍼 큐브란? 다차원 데이터(Multi-Dimensional Data)를 시각적으로 표현하는 개념이다. 하이퍼 큐브로 다차원 데이터의 관계를 표현하고 데이터를 차원별로 분석한다.
데이터 큐브 단점
데이터 큐브는 미리 정의된 차원(Dimesion)과 집계(Aggregation) 값을 기반으로 한다.
사전에 정의된 기준으로 데이터를 분석하는 것은 빠르지만 새로운 기준을 추가하면 어렵다.
예를 들어, 아래와 같이 차원이 있다고 가정하자.
여기서 ‘가격’ 개념이 추가되어 ‘가격 100달러 이상인 제품에서 발생한 판매량 비율’을 구하는 질의를 실행할 수 없다.
→ 데이터 큐브는 사전 정의된 차원과 집계된 값만 저장하므로, 특정 속성에 대한 새로운 조건을 적용하는 것이 어렵다.
⇒ 데이터 웨어하우스는 원시 데이터를 최대한 보존하는 역할을 하고 데이터 큐브는 특정 질의를 빠르게 처리하도록 보조적인 역할을 한다.
정리
데이터 웨어하우스에서 반복되는 질의를 매번 원시데이터에서 처리하면 비효율적이다.
→ 구체화 뷰는 특정 질의 결과를 미리 계산하여 저장하는 방식으로 매번 원시데이터를 처리하지 않게 해준다.
→ 구체화 뷰의 특수한 형태인 데이터 큐브를 통해서 다차원 데이터를 분석하고 저장하는 것을 지원한다.
→ 차원이 많아지면 하이퍼큐브 개념을 사용하여 데이터를 분석하여 성능을 향상시킨다.
출처
데이터 중심 애플리케이션 설계
