분석과 리포팅을 위해 여러 시스템의 데이터를 한곳에 모아 정리해 둔 저장소다. 서비스를 돌리는 운영 데이터베이스와는 목적도 설계도 다르다.
운영 데이터베이스는 주문 하나를 넣고 빼는 일을 빠르고 정확하게 처리해야 한다(OLTP). 분석은 “지난 3년간 지역별 매출 추이” 처럼 수억 건을 훑어 몇 개 열만 집계한다(OLAP). 같은 저장소로 둘을 다 하면 분석 질의가 서비스 응답을 느리게 만든다.
설계가 어떻게 다른가
| 운영 DB (OLTP) | 데이터 웨어하우스 (OLAP) | |
|---|---|---|
| 주된 작업 | 소수 레코드의 삽입·수정 | 대량 레코드의 집계 |
| 저장 방식 | row based storage | columnar storage |
| 정규화 | 중복을 없애는 방향 | 조인을 줄이려 일부러 비정규화 |
| 데이터 | 현재 상태 | 시점별 이력 |
집계 질의는 수백 개 열 중 몇 개만 읽는다. columnar storage 는 열 단위로 저장하므로 필요한 열만 읽으면 되고, 같은 열의 값끼리 모여 있어 압축률도 높다.
ETL 과 ELT
전통적으로는 원본에서 데이터를 뽑고(Extract), 정해진 스키마에 맞게 변환한 뒤(Transform), 웨어하우스에 적재했다(Load). 저장 공간과 연산이 비쌌기 때문에 미리 정제해 넣는 편이 합리적이었다.
클라우드 웨어하우스가 저장과 연산을 분리하고 값이 싸지면서 순서가 바뀌었다. 원본을 일단 그대로 적재하고 필요할 때 변환하는 ELT 가 흔해졌다. 나중에 다른 관점의 분석이 필요해져도 원본이 남아 있다는 것이 장점이다.
data lake, lakehouse 와의 관계
data lake 는 정형·비정형을 가리지 않고 원본 그대로 쌓아두는 저장소다. 스키마를 미리 정하지 않아 유연하지만, 관리가 안 되면 무엇이 어디 있는지 모르는 상태가 된다.
lakehouse 는 값싼 오브젝트 스토리지 위에 웨어하우스의 성질(트랜잭션, 스키마 관리, 시점 조회)을 얹으려는 방향이다. Apache Iceberg, Delta Lake 같은 테이블 포맷이 파일 목록과 스냅샷을 메타데이터로 관리해서, 저장은 lake 에 하되 질의는 테이블처럼 하게 만든다.