[Database] 빅데이터 시대에 '열 기반 데이터베이스'가 중요한 이유는 무엇일까?

| 빅데이터 시대에 왜 데이터웨어하우스만으로는 부족했을까?

빅데이터 시대에 왜 데이터웨어하우스만으로는 부족한지를 제대로 이해하기 위해서는, 데이터 웨어하우스의 구조에 대한 이해가 선행되어야 한다. 데이터웨어하우스는 전통적인 관계형 데이터베이스처럼 테이블 기반의 정형화된 데이터 저장소와 가까운 성격을 가지고 있다. 

 
관계형 데이터베이스
데이터를 행(row)과 열(column)으로 구성된 테이블 형태로 저장하고, 관계(relation)를 통해 여러 테이블을 연결하는 데이터베이스 모델이다.
 
관계형 데이터베이스의 핵심

1	데이터 구조가 테이블 기반이다	- 테이블 : 하나의 개체 - 행 : 하나의 레코드 - 열 : 하나의 속성
2	스키마 기반의 구조	- 데이터 저장 전 엄격한 스키마(scheman)에 대한 정의가 필요하다. (데이터 타입, 제약 조건 등)  - 따라서, 정형 데이터 처리에 강하다.
3	SQL 언어의 사용	- 데이터 정의, 데이터 조작, 데이터 제어를 위해 표준 언어인 SQL을 사용한다.
4	데이터 무결성과 제약 조건	- PK : 각 행을 고유하게 식별하는 키 - FK : 다른 테이블과의 관계를 설정하는 키 - Not Null, Unique, Check 등 다양한 제약 조건을 지원한다.
5	대표적인 관계형 DBMS	- Oracle, MySQL, PostgreSQL, SQL Server

 
 

관계형 데이터베이스와 데이터 웨어하우스는 '정형 데이터' 처리에 강한 스키마 기반의 구조(schema on write)를 가지고 있다. 하지만 빅데이터 시대가 도래하면서, 수집되는 데이터는 점점 더 '비정형적인 특성'을 띠게 되었고, 이를 처리하는 데 기존 방식의 한계가 드러났다. 

 
 
스키마 기반의 구조란? - schema on write vs schema on read
둘은 스키마를 언제 적용하느냐 하는 시점에 차이가 있다. 

schema on write	저장할 때 스키마 적용, 데이터를 저장하기 전에 구조를 미리 정의해야 함
schema on read	읽을 때 스키마 적용, 데이터를 저장할 때 형식에 제약이 없고 나중에 필요할 때 구조 정의

 
schema on write
- 저장할 때 스키마를 적용하기 때문에, 정형 데이터에 적합하다.
- 데이터 무결성과 정합성을 보장하고, 빠른 읽기 성능을 보장한다.
- 하지만 새로운 형식의 데이터를 추가하기 어렵고, 유연성이 낮다. 
 
schema on read 
- 읽을 때 스키마를 적용하기 때문에, 형식에 제약이 없다.
- 따라서 반정형/비정형 데이터에 적합하다.
- 유연하고 확장성이 높고, 저장은 빠르지만 읽을 때에 비용이 발생한다.
- 데이터 품질이 일정하지 않을 수 있다. 
 

왜 읽기 성능은 schema on write가 더 좋을까?

schema on write는 데이터 구조가 이미 정의되어 있기 때문에 읽기에 편하다. schema on read는 그것과 반대이다. 실행 시점에 데이터의 구조를 파악해야 하기 때문에, 읽을 때마다 데이터가 어떤 구조인지 해석해야 한다. 또한 반정형/비정형 데이터이기 때문에 쿼리를 날릴 때마다 데이터를 파싱해야 한다. 

대부분의 schema on read 시스템 (Hadoop, S3, Athena 등)은 전통적인 인덱스 기반 검색이 어렵거나 없다. 따라서 전체 데이터를 스캔(full scan) 하게 되는 경우가 많아 성능이 떨어진다. 

 
 
데이터 레이크
데이터 레이크는 기존의 데이터웨어하우스가 가지고 있던 한계를 해결하기 위해 등장한 개념으로, 모든 형태의 원시(raw) 데이터를 저장할 수 있는 유연한 데이터 저장소이다. 
 
데이터 레이크의 핵심

저장 방식	schema on read (읽을 때 구조 해석)
데이터 유형	정형, 반정형, 비정형 모두 저장 가능 (예: CSV, JSON, 이미지, 오디오 등)
유연성	스키마가 유연해 나중에 어떤 분석에도 활용 가능
저장소	주로 클라우드 기반 (예: AWS S3, Azure Data Lake)
활용 예시	머신러닝 학습 데이터, IoT 센서 로그, 소셜미디어 데이터 등

 
 

데이터 레이크는 다양한 원시 데이터를 유연하게 저장할 수 있지만, 매 분석마다 모든 원시 데이터를 다루는 것은 비효율적이다. 따라서 특정 분석 목적이나 부서의 요구에 맞게 데이터를 정제하고 구조화환 저장소의 필요성이 생겨났는데, 이때 등장한 것이 데이터 마트이다.

 
 
데이터 마트
데이터 마트는 데이터 웨어하우스나 레이크로부터 필요한 데이터만 추출하여, 보다 가볍고 빠르게 분석할 수 있도록 구성한 소규모 저장소이다. 예를 들어, 마케팅팀 전용 마트, 재무팀 전용 마트처럼 주제나 부서 단위로 최적화된 분석 환경을 제공한다. 
 
 

| 행 기반 DB와 열 기반 DB는 어떤 차이가 있고, 각각 언제 성능이 더 좋을까? 

수천만 개의 고객 정보 중, '이메일 주소'만 빠르게 찾아야 하는 상황이 생겼다. 이때 데이터를 어떻게 조회하고 활용해야 할까? 이메일 주소만 빠르게 검색하는 시스템이 좋을까, 관련된 세부 정보까지 모두 보여주는 시스템이 좋을까? 

우리는 데이터베이스에서 특정 정보를 조회해 필요한 정보를 찾아와야 한다. 이때, 데이터를 조회하는 목적에 따라 최적의 데이터 저장 방식도 달라진다. 여기서 행 기반 데이터베이스와 열 기반 데이터베이스의 차이가 등장한다. 

 
행 기반 데이터베이스
행 기반 데이터베이스는 데이터를 행 단위로 저장하는 방식이다. 하나의 레코드 속 모든 필드값을 한 번에 묶어서 저장한다. 예를 들면 아래와 같다. 

1

keemchanniee

keemchanniee@gmail.com

23

 
이렇게 한 줄 전체가 하나의 개체로 한 번에 저장되는 것이 행 기반 데이터베이스이다. 
 
 
열 기반 데이터베이스 
열 기반 데이터베이스는 데이터를 열 단위로 저장하는 방식이다. 같은 칼럼의 값들만을 연속적으로 저장한다. 예를 들면 아래와 같다. 

이름	홍길동	김영희	이철수
이메일	gil@	kim@	lee@
나이	25	30	27

 
이렇게 각 속성 별 값을 연속적으로 저장한 형태가 열 기반 데이터베이스이다. 
 
 
행 기반 데이터베이스 vs 열 기반 데이터베이스
- 행 기반 DB는 트랜잭션 처리(OLTP)에, 열 기반 DB는 분석과 집계(OLAP) 처리에 강하다. 
- 행 기반은 전체 행을 통째로 읽지만, 열 기반은 필요한 칼럼만 선택적으로 읽는다. 따라서 읽기 속도는 열 기반이 더 빠르다. 
- 하지만 쓰기의 경우, 하나의 행이 곧 하나의 저장 단위이기 때문에 행 기반 DB가 더 강하다. 모든 열이 한 위치에 연속적으로 저장되기 때문에 디스크 접근이 최소화되어 쓰기가 더 빠르다.
 
 

분석을 위해 데이터를 join 해야 하는 경우, 어떤 데이터베이스가 더 효율적일까? 
상황에 따라 다르다. 트랜잭션 중심의 실시간 JOIN 이라면 행 기반 DB가 더 적합하지만, 분석 용도로 필요한 열만 뽑기 위한 목적이라면 열 기반의 DB가 더 강하다. 

 
왜 열 기반 DB가 더 효율적일까?
다음 두 데이터를 JOIN 해야하는 상황이 있다. 

order_id	user_id	order_total
1	101	30,000
2	102	50,000
...	...	...

user_id	name	age
101	Alice	31
102	Bob	29
...	...	...

 
행 기반 DB에서는 다음과 같은 쿼리를 실행한다. 

SELECT o.order_id, o.order_total, u.name
FROM orders o
JOIN users u ON o.user_id = u.user_id
WHERE o.order_total > 40000;

 
1. 먼저 모든 행을 통쨰로 하나씩 읽는다. 조건이 있는 order_total을 검색하기 위해, 해당 필드를 포함한 행 전체를 읽어야 하기 때문이다.
2. 그 중 조건을 만족하는 행만 남긴다.
3. 조인을 수행한다. 
 
이때 오버헤드가 발생한다. 불필요한 칼럼들까지 전부 읽는 과정을 거쳤기 때문이다. 
 
열 기반 DB에서는 어떻게 처리할까? 
 
1. 전체 행을 읽지 않고, 필요한 열만 읽는다.
2. 해당 조건을 만족하는 row index를 기억한다. 
3. 앞 단계에서 추출한 인덱스를 기준으로 해당 위치 값만 읽는다. 
4. 조인 대상 열만 읽고 연결한다. 
 

이처럼 열 기반 DB에서는 불필요한 데이터를 전혀 읽지 않는다. 필요한 열만 읽기 때문에 조건 처리 속도가 빠르다. 또한 열 내에 같은 타입의 값이 연속되어 있기 때문에 CPU 캐시 효율과 압축률도 높다. 전반적으로 JOIN 수행 시 성능이 높을 수 밖에 없다. 

 
 

| 비정규화된 테이블은 왜 시각화와 분석에 더 유리할까? 

데이터베이스가 설계될 때 가장 중요한 과제 중 하나는, 중복을 줄이고 일관성을 유지하는 것이다. 같은 정보가 여러 테이블에 흩어져 있으면, 한 곳만 수정해도 다른 곳에서 불일치가 발생하는 이상 현상(Anomaly)이 생기기 때문이다. 이러한 문제를 해결하기 위해 등장한 개념이 바로 정규화(Nomalization)이다.

 
데이터 정규화
데이터의 일관성과 무결성을 유지하기 위해 데이터를 여러 개의 관련 테이블로 나누는 설계 방식이다. 중복 데이터를 제거하고, 삽입/삭제/수정 시 생기는 이상 현상을 방지한다.
 
예를 들어, 주문 테이블(고객명, 주소, 주문번호, 고객 ID, 상품명)에서 같은 고객 정보가 반복되는 경우 수정/삭제 시 오류가 발생할 위험이 있다. 이것을 정규화하면, 고객 테이블(고객명, 주소)과 주문 테이블(주문버호, 고객 ID, 상품명)으로 나누어 이상현상을 방지할 수 있다. 
 
데이터 정규화의 한계
하지만 이러한 데이터 정규화는 분석, 집계, 시각화 환경에서는 제약이 발생한다. 
- 정규화된 데이터는 여러 테이블로 분리되어 있어 원하는 정보를 조회하려면 항상 여러 테이블을 JOIN 해야한다.
- 특히 분석 쿼리에서 여러 쿼리가 겹치면 쿠리 성능이 저하되고, 작성 난이도가 증가한다.
- JOIN이 많을수록 디스크 I/O와 CPU 연산량이 커지기 떄문에 비용이 기하급수적으로 증가한다. 따라서, 정규화된 구조는 실시간 분석에 불리하다. 
 

이렇듯 정규화는 데이터 정확성에는 강하지만, 분석과 시각화 효율성에는 약하다. 그래서 분석 시스템에서는 비정규화 기반의 다른 구조가 필요하다. 

데이터 분석과 시각화를 위해 가장 널리 쓰이는 데이터 모델링 방식 중 하나가 바로 스타 스키마이다. 스타 스키마는 중앙의 팩트 테이블과 이를 설명해주는 여러 차원의 디멘젼 테이블로 구성되는데, 이 구조는 복잡한 관계형 데이터를 분석과 시각화외 최적화된 형태로 재구성한 것이다. 

 
 
스타 스키마
스타 스키마는 fact table을 중심으로, 여러 개의 dimension table이 별처럼 연결된 데이터 모델이다. 이 구조는 분석과 집계 성능을 높이기 위해 비정규화된 테이블을 효율적으로 구성하는 방식이다.
 

 
스타 스키마에서의 핵심 설계 원칙은 자주 바뀌는 데이터를 팩트 테이블에, 자주 바뀌지 않는 데이터를 디멘젼 테이블에 분리한다는 것이다.
 
팩트 테이블 [자주 바뀌는 데이터]
- 수시로 발생하는 기록들, 측정값들을 중심에 둔다. 
(예시) 주문 정보, 날짜, 상품, 수량 등 
 
디멘젼 테이블 [자주 바뀌지 않는 데이터]
- 팩트 테이블의 각 값이 무슨 의미인지 설명하는 테이블이다.
- 필요할 때만 조인해서 해석 용도로 사용한다. 
(예시) 고객의 이름, 성별, 지역 등 
 

주문 데이터로 예시를 들어보자. 주문은 매일 발생한다. 그렇지만 해당 주문을 한 고객의 정보는 바뀌지 않는다. 따라서 중심에 두고 매번 저장하면, 공간을 낭비하게 되고 속도가 느려진다. 

그래서 잘 바뀌는 건 핵심 정보만 두고 팩트 테이블에, 잘 바뀌지 않는 것은 디멘젼 테이블에 두고 필요할 때 조인해서 정보를 확인한다! 

 
비정규화
비정규화 테이블은 데이터를 하나의 테이블에 가능한 한 많이 모은 평평한(flat) 구조를 말한다.

스타 스키마는 분석 시점에 팩트 테이블과 디멘전 테이블을 조인하여 비정규화된 형태로 데이터를 구성하는 방식이고, 이에 비해 비정규화 테이블은 처음부터 모든 컬럼이 한 테이블에 포함된 더 포괄적이고 단일화된 형태라고 볼 수 있다.
 
정리하면
스타 스키마는 분석용 설계 방식이고, 비정규화 테이블은 실제로 분석할 때 조회하거나 추출해서 쓰는 데이터 형태이다. 
 
 
 
쿼리 관점에서 비정규화가 분석에 적합한 이유는 무엇일까?
정규화된 구조에서는 분석에 필요한 정보가 여러 테이블에 나뉘어 있어 항상 JOIN을 사용해야 하며, 쿼리가 길고 복잡해질 수 밖에 없었다.
 
하지만 비정규화 테이블은 한 테이블에 모든 정보가 포함되어 있어, JOIN 없이도 바로 분석 쿼리를 날릴 수 있다. 
 
정규화 구조를 먼저 살펴보자. 

SELECT c.gender, p.category, SUM(o.amount)
FROM orders o
JOIN customers c ON o.customer_id = c.id
JOIN products p ON o.product_id = p.id
GROUP BY c.gender, p.category;

 
 
비정규화 구조는 아래와 같다.

SELECT gender, category, SUM(amount)
FROM order_summary
GROUP BY gender, category;

 
비정규화 구조는 시각화 도구와의 연동도 쉽다. Tableau, Power BI 등 대부분의 BI 도구는 하나의 테이블을 읽는 것을 전제로 동작한다. 비정규화 테이블은 하나의 테이블에 모든 정보가 포함되어 있기 때문에 시각화 도구에서 바로 필터, 피벗, 집계가 가능해 JOIN 관계 설정 없이도 분석이 가능하다. 
 
 

| 좋은 파이프라인이 가져야 할 조건은 무엇일까? 

지금까지 정규화는 데이터의 정확성과 무결성을, 비정규화는 효율적인 분석 환경을 제공한다는 것을 알 수 있었다. 그렇다면 이 두 조건을 모두 만족시킬 수는 없을까?

결국 우리는 정확성, 효율성이라는 두 가지 목표를 만족시키기 위한 데이터 흐름, 좋은 데이터 파이프라인에 대해 고민하게 된다. 분석을 위한 최적의 구조가 단지 테이블 설계만의 문제가 아니라, 데이터가 어떻게 수집되고, 가공되고, 전달되는지 전반적인 흐름까지 포함한 문제이기 때문이다. 

 
다양한 조건이 있겠지만 내가 결론내린 조건은 아래의 세 가지이다. 
 
좋은 데이터 파이프라인의 조건 1. 신뢰성
좋은 데이터 파이프라인이 되기 위해서는 잘못된 데이터가 흐르지 않도록 정합성과 품질이 보장되어야 한다.
 
좋은 데이터 파이프라인의 조건 2. 확장성
데이터 양이 증가해도 성능 저하 없이 안정적으로 작동해야 한다. 빅데이터 시대에는 특히, 무수히 많이 쌓이는 데이터를 잘 저장할 수 있어야 한다. 
 
좋은 데이터 파이프라인의 조건 3. 조회 성능 
데이터를 잘 쌓는 것도 중요하지만, 결국 잘 꺼낼 수 있어야 분석이 가능하고 가치가 생긴다. 따라서 축적된 데이터를 잘 조회할 수 있는 시스템도 갖추어져야 한다. 
 

하지만 과연 이 모든 조건을 만족시킬 수 있을까? 좋은 데이터 파이프라인을 위한 모든 조건을 만족하는 시스템이 있다면 좋겠지만, 실제 시스템을 설계할 때는 반드시 트레이드 오프가 발생한다. 이를 설명해주는 개념이 바로 CAP 이론이다. 

 
 
CAP 이론
CAP 이론은 분산 시스템에서 Consistnecy(일관성), Availability(가용성), Partition Tolerance(분할 허용성) 이 세 가지 속성을 동시에 모두 만족할 수 없다는 이론이다. 

C - 일관성 (Consistency)	모든 노드에서 항상 같은 데이터를 조회할 수 있어야 함	"누가 먼저 읽든, 값은 똑같아야 함"
A - 가용성 (Availability)	시스템이 항상 응답을 반환해야 함 (성공이든 실패든)	"요청하면 무조건 응답이 와야 함"
P - 분할 허용성 (Partition Tolerance)	네트워크가 끊겨도 시스템이 계속 작동해야 함	"통신 장애가 나도 버텨야 함"

 
왜 셋을 동시에 만족할 수 없을까?
CAP 이론에서는 분산 시스템은 언젠가는 반드시 네트워크 장애(partition)을 겪는다고 말한다. 이 상황에서 일관성을 유지하려면 장애 난 노드의 응답을 기다려야 하므로 가용성을 포기해야 하고, 가용성을 유지하려면 장애 난 노드 없이 작동을 계속해야 하므로 일관성을 포기해야 한다.
 
그래서 현실적으로 분할 허용성은 항상 전제되어야 하고, 시스템은 C와 A중 하나를 포기해야 한다. 

CAP 이론은 분산 시스템을 설계할 때 반드시 고려해야 하는 현실적인 제약 조건을 알려주는 기준점이 된다. 

데이터 파이프라인의 관점에서 살펴보자. 데이터 파이프라인은 여러 노드와 단계(수집, 처리, 저장, 분석)을 거치는 분산 시스템이다. 따라서 CAP 이론이 제시하는 제약(C, A, P)는 파이프라인 전체의 안정성과 품질에 직접적인 영향을 미친다. 

신뢰성은 높지만 지연이 발생할 수 있는 '일관성 우선' 데이터 베이스를 만들 것인지, 일시적인 불일치나 누락이 발생하지만 빠르고 끊김 없는 '가용성 우선' 데이터 베이스를 만들 것인지는 파이프라인이 어떤 목적을 지니고 있는지에 따라 달라진다.