By dongwooshin in Products — 21 Mar 2026

DIP 플랫폼 TPC-DS 벤치마크 — Part 1. Batch ELT & Query 성능

데이터 플랫폼, 도입 전에 성능부터 증명할 수 있을까? DIP 플랫폼을 TPC-DS SF-100 표준 벤치마크로 검증했습니다. Batch ELT 적재 속도부터 분석 쿼리 응답시간, 동시성 한계까지—숫자로 확인한 결과를 공유합니다.

시리즈 안내
핵심 결과 요약
1. 벤치마크 목적과 배경
2. 테스트 환경
3. 데이터 파이프라인 아키텍처
4. 데이터 생성 및 소스 적재
- 4.1 TPC-DS SF-100 데이터 생성
- 4.2 PostgreSQL 적재 결과
5. Batch ELT: Spark → Iceberg 적재
6. Query 성능 벤치마크
7. 발생 이슈 및 해결
8. 전체 결과 요약
- 8.5 핵심 성능 지표
9. 결론 및 권고사항

시리즈 안내

DIP 플랫폼의 데이터 처리 역량을 TPC-DS 표준 벤치마크로 정량 검증하는 시리즈입니다. 전체 벤치마크는 아래 4단계로 진행하며, 본 글에서는 ① Batch ELT와 ② Query 성능 결과를 다룹니다.

순서	테스트 영역	DIP 구성요소	블로그
①	Batch ELT — 대량 데이터 적재 처리량	Spark → Iceberg → StarRocks	본 글
②	Query — 분석 쿼리 응답시간 · 동시성	StarRocks (Iceberg External Catalog)	본 글
③	Kafka CDC — 실시간 변경 데이터 캡처	Kafka Connect → Iceberg	Part 2 예정
④	OLake CDC — 경량 CDC 파이프라인	OLake → Iceberg	Part 2 예정

Part 2에서는 Kafka CDC와 OLake CDC의 초기 적재 속도, 실시간 지연(Latency), 그리고 운영 편의성까지 비교합니다.

핵심 결과 요약

Batch ELT — 9.6억 행, 54분 적재 완료 (296K rows/sec) · 목표 3시간 대비 3.3배 초과 달성

Query — TPC-DS 99개 쿼리 100% 통과, Geometric Mean 1.474초 · 목표 60초 대비 40배 초과 달성

QphDS@100 = 244,234 · 동급 사양 대비 글로벌 최상위권 · QphDS/$ ~60,900/hr (압도적 가성비)

동시성 — 4사용자 성능 저하 2.48× · 목표 3× 미만 달성

✅ 사전 정의한 6개 성공 기준 전항 PASS

1. 벤치마크 목적과 배경

데이터 플랫폼을 도입할 때 가장 먼저 확인해야 할 것은 "우리 규모에서 얼마나 빠르게 동작하는가" 입니다. DIP 플랫폼이 실환경에서 기대하는 성능을 충족하는지 객관적으로 검증하기 위해, 업계 표준인 TPC-DS SF-100 벤치마크를 수행하였습니다.

TPC-DS는 소매(Retail) 시나리오를 모델링한 의사결정 지원 벤치마크로, 복잡한 조인·서브쿼리·윈도우 함수를 포함한 99개 분석 쿼리로 구성되어 있습니다. SF-100은 약 100GB 원본 데이터(압축 후 약 30GB)에 해당하며, 중규모 분석 워크로드의 성능을 평가하기에 적합한 스케일입니다.

성공 기준

벤치마크 시작 전 아래 기준을 사전 정의하였습니다.

항목	기준	근거
SF-100 배치 적재 시간	3시간 이내	일반적인 야간 배치 윈도우(4~6시간)의 절반 이내에 ELT를 완료해야 후속 작업(집계·리포트 생성)에 여유를 확보할 수 있음
배치 적재 Throughput	최소 10K rows/sec	SF-100(9.6억 행)을 3시간 내 처리하려면 최소 ~89K rows/sec이 필요하나, 소규모 일일 증분 적재(수백만 행)까지 고려하여 범용 최소 기준으로 설정
SF-100 Query Geometric Mean	60초 이내	분석가의 대화형(Interactive) 쿼리 응답 허용 한계. 1분을 초과하면 탐색적 분석 흐름이 끊기고 생산성이 저하됨
동시 4사용자 성능 저하	단일 대비 50% 이내 (3× 미만)	CN 3노드 환경에서 소규모 분석팀(3~5명) 동시 사용을 가정. 선형 저하(4×) 대비 25% 이상 효율을 유지해야 실용적 동시성으로 판단
데이터 정합성	소스-타겟 100% 일치	데이터 플랫폼의 기본 요건. 소스-타겟 간 행 수·체크섬 불일치는 분석 신뢰성을 근본적으로 훼손하므로 타협 불가
TPC-DS 쿼리 통과율	99/99 (100%)	TPC-DS 99개 쿼리는 ANSI SQL 고급 기능(CTE, 윈도우 함수, ROLLUP 등)을 폭넓게 사용하므로, 전량 통과는 SQL 호환성 완성도의 지표

2. 테스트 환경

2.1 인프라 (Google Cloud)

구분	머신 타입	vCPU	RAM	Boot Disk	Data Disk
rke2-node × 3	n2-standard-8	8	32 GB	100 GB pd-ssd	1,000 GB pd-ssd
PostgreSQL × 1	e2-standard-8	8	32 GB	50 GB pd-ssd	1,000 GB pd-ssd

2.2 소프트웨어 스택

항목	버전	역할
PostgreSQL	16.x	소스 RDBMS
Spark	3.5.x	Batch ELT 엔진
StarRocks	3.5.2 (FE 1 + CN 3)	분석 쿼리 엔진
Lakekeeper	latest	Iceberg REST Catalog
MinIO	—	S3 호환 오브젝트 스토리지

2.3 StarRocks CN 노드 구성

항목	값
CN 노드 수	3
노드당 MemLimit	16 GB
exec_mem_limit (단일 사용자)	16 GB
exec_mem_limit (동시성 테스트)	`16 GB ÷ 동시 사용자 수` (노드당)

3. 데이터 파이프라인 아키텍처

전체 벤치마크 파이프라인은 4단계로 구성됩니다.

┌─────────────────────────────────────────────────────────────────────────────┐
│                     DIP TPC-DS 벤치마크 파이프라인                            │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│  ① 데이터 생성           ② 소스 적재            ③ Batch ELT                 │
│  ┌──────────┐           ┌──────────┐           ┌───────────────┐           │
│  │  DuckDB  │  Parquet  │PostgreSQL│   JDBC    │ Spark-Iceberg │           │
│  │ dsdgen() │─────────▶│  tpcds   │─────────▶│   Batch ELT   │           │
│  │  SF-100  │  24 tbl   │  _sf100  │   Read    │               │           │
│  └──────────┘           └──────────┘           └───────┬───────┘           │
│                                                         │ Write             │
│                                                         ▼                   │
│  ④ 쿼리 벤치마크                                 ┌───────────────┐         │
│  ┌───────────────┐   External Catalog            │    Iceberg    │         │
│  │   StarRocks   │◀─────────────────────────────│   (MinIO S3)  │         │
│  │  TPC-DS 99Q   │  bmt_catalog.tpcds_sf100      │  Lakekeeper   │         │
│  └───────────────┘                                └───────────────┘         │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

① 데이터 생성: DuckDB의 TPC-DS 확장(dsdgen)으로 SF-100 데이터를 Parquet(ZSTD) 형식으로 생성합니다.
② 소스 적재: 생성된 Parquet 파일을 PostgreSQL에 고속 적재합니다. 실환경에서 원천 시스템이 RDBMS인 시나리오를 재현한 것입니다.
③ Batch ELT: Spark JDBC로 PostgreSQL을 읽어 Lakekeeper 기반 Iceberg 테이블에 적재합니다.
④ 쿼리 벤치마크: StarRocks External Catalog으로 Iceberg 테이블을 직접 조회하며, TPC-DS 99개 쿼리를 실행합니다.

4. 데이터 생성 및 소스 적재

4.1 TPC-DS SF-100 데이터 생성

DuckDB dsdgen()으로 24개 테이블(Fact 7 + Dimension 17)을 생성하였습니다.

구분	테이블 수	총 행 수	총 크기
Fact	7	953,722,450	~29.3 GB
Dimension	17	5,297,158	~96 MB
합계	24	~9.6억	~30.1 GB

주요 Fact 테이블의 규모는 다음과 같습니다.

테이블	행 수	크기
inventory	399,330,000	885 MB
store_sales	287,997,024	12.0 GB
catalog_sales	143,997,065	9.2 GB
web_sales	72,001,237	4.5 GB
store_returns	28,795,080	1.4 GB
catalog_returns	14,404,374	869 MB
web_returns	7,197,670	435 MB

4.2 PostgreSQL 적재 결과

DuckDB postgres 확장으로 Parquet에서 PostgreSQL로 직접 적재하여, 원천 RDBMS 환경을 구성하였습니다.

항목	값
총 적재 행 수	~9.6억
총 적재 시간	약 24.5분 (1,470초)
평균 처리량	652K rows/sec

5. Batch ELT: Spark → Iceberg 적재

5.1 적재 결과 요약

Spark JDBC로 PostgreSQL을 읽어 Lakekeeper 기반 Iceberg 테이블로 적재한 결과입니다.

항목	값
성공 테이블	24/24 (100%)
총 적재 행 수	959,019,608 (~9.6억)
Wall-clock 시간	3,240초 (54분)
Phase 1 — Dimension (17개)	20.4초
Phase 2 — Fact (7개)	3,219.6초 (전체의 99.4%)
처리 속도	296K rows/sec

적재는 2-Phase 전략으로 실행하였습니다. Phase 1에서 경량 Dimension 테이블 17개를 병렬 적재한 뒤, Phase 2에서 대형 Fact 테이블 7개를 병렬 적재합니다. 전체 시간의 99%는 Fact 테이블 적재에 소요됩니다.

5.2 Fact 테이블별 적재 성능

테이블	행 수	시간(초)	처리량(rows/sec)	JDBC 파티션
inventory	399,330,000	425.7	938,028	12
store_sales	287,997,024	1,166.1	246,972	12
catalog_sales	143,997,065	860.1	167,419	12
web_sales	72,001,237	488.5	147,394	8
store_returns	28,795,080	136.8	210,507	4
catalog_returns	14,404,374	91.2	158,020	4
web_returns	7,197,670	51.2	140,533	4

가장 큰 병목은 store_sales로, 단일 테이블이 전체 적재 시간의 약 36%(1,166초)를 차지합니다. 이 테이블은 약 2.9억 행·12GB 규모로, JDBC 파티션 12개로 분할하여 병렬 읽기를 수행하였으나 Executor 코어 수(6개) 대비 파티션이 많아 처리 효율이 제한되었습니다.

5.3 Spark 튜닝 상세

SF-100 규모의 적재 과정에서 OOM과 성능 저하 이슈가 발생하였고, 아래 3개 영역을 집중 튜닝하여 해결하였습니다.

Spark 리소스 설정

항목	값	비고
Executor 수	3	K8s 노드당 1개
Executor Memory	18g	노드 32GB 중 Spark 할당
Executor Overhead	4g	off-heap (총 22g/노드)
Executor Cores	2	—
Driver Memory	4g	—
Shuffle Partitions	48	`executors × cores × 8`

JDBC 읽기 최적화

항목	기본값	튜닝값	효과
fetchsize	0 (전체 로드)	100,000	스트리밍 읽기로 GC 부담 감소, OOM 방지
JDBC 병렬 파티션 (대형 Fact)	1	12	`item_sk` 기준 range 분할, 병렬 읽기
JDBC 병렬 파티션 (중형 Fact)	1	4~8	테이블 크기에 따라 조정

핵심은 fetchsize 설정입니다. 기본값 0은 결과셋 전체를 메모리에 적재하므로, 대형 테이블에서 즉시 OOM이 발생합니다. 100,000으로 설정하여 커서 기반 스트리밍 읽기로 전환한 것이 안정성 확보의 핵심이었습니다.

Iceberg 쓰기 최적화

항목	기본값	튜닝값	효과
`write.spark.fanout.enabled`	true	false	파티션별 Writer 동시 오픈 방지 → OOM 해결
쓰기 방식	DataFrame writeTo	CTAS + ORDER BY	파티션 키 정렬 후 순차 기록
압축	Snappy	ZSTD	압축률 향상

fanout.enabled가 true일 경우 모든 파티션에 대해 Writer를 동시에 열어두므로, 파티션 수가 많은 Fact 테이블에서 메모리가 폭증합니다. 이를 false로 전환하고, 파티션 키(date_sk) 기준으로 정렬 후 순차 기록하는 CTAS 패턴을 적용하여 메모리 사용을 안정화하였습니다.

적재 전략 정리

항목	설명
2-Phase 실행	Phase 1: Dimension 17개 (병렬) → Phase 2: Fact 7개 (병렬)
파티셔닝	Fact 테이블: `date_sk` 기준
정렬	`item_sk` 기준 ORDER BY (파티션 내 정렬)
컬럼명 정규화	SF-100 dsdgen의 `column0`/`column00` → TPC-DS 표준 컬럼명 매핑
멱등성	`safe_drop_table()` — DROP TABLE PURGE 실패 시 non-PURGE 폴백

5.4 스케일아웃 시 예상 성능

현재 3노드 환경에서 54분을 달성하였으나, 노드 증설을 통해 추가 성능 향상이 가능합니다.

항목	현재 (3노드)	권고 최소 (5노드)	권고 최적 (6노드)
K8s 노드	3 × n2-standard-8	5 × n2-standard-8	6 × n2-standard-8
총 Executor 코어	6	15	18
총 Executor 메모리	54g	80g	96g
예상 적재 시간	54분	~35분	~25분
처리량	296K rows/sec	~450K rows/sec	~550K rows/sec
성능 향상	baseline	1.5×	2.2×

구성	월 비용 (예상)	적재 시간	비용 효율
현재 (3노드)	~$730	54분	baseline
권고 최소 (5노드)	~$1,217	~35분	비용 1.7×, 성능 1.5×
권고 최적 (6노드)	~$1,460	~25분	비용 2.0×, 성능 2.2×

n2-standard-8 월 비용 약 $243 기준 (GCP on-demand). 비용 대비 성능 효율은 6노드 구성이 가장 우수합니다.

6. Query 성능 벤치마크

StarRocks External Catalog(bmt_catalog.tpcds_sf100)를 통해 Iceberg 테이블에 TPC-DS 99개 쿼리를 실행하였습니다. StarRocks는 Iceberg 메타데이터를 활용한 Data Skipping과 Predicate Pushdown을 수행하며, 별도의 데이터 복제 없이 External Catalog 방식으로 직접 조회합니다.

6.1 Power Test — Cold Run / Warm Run

단일 세션에서 99개 쿼리를 순차 실행한 결과입니다.

항목	Cold Run	Warm Run
총 쿼리	99	99
성공	99 (100%)	99 (100%)
실패	0	0
Geometric Mean	1.474초	1.458초
Total Time	249.4초	246.5초
Min	0.131초	0.132초
Max	18.789초	18.555초
Avg	2.519초	2.490초
exec_mem_limit	16 GB	16 GB

Cold Run과 Warm Run의 차이가 1.1%에 불과한 것이 주목할 만합니다. External Catalog 쿼리 특성상 StarRocks 내부 캐시 효과가 제한적이기 때문인데, 이는 곧 캐시에 의존하지 않고도 안정적인 응답시간을 제공한다는 의미이기도 합니다.

6.2 Concurrency Test — 동시 사용자 성능

동시 사용자 수를 1 → 2 → 4 → 8로 증가시키며 성능 변화를 측정하였습니다. 각 세션은 동일한 99개 쿼리를 독립적으로 실행하며, exec_mem_limit은 동시 사용자 수에 반비례하여 할당됩니다. Wall-clock은 세션당 평균 소요시간으로, 벤치마크의 실제 체감 소요시간에 해당합니다.

동시 사용자	exec_mem_limit	총 쿼리	성공	실패	Geo Mean	Wall-clock
1 (Cold)	16 GB	99	99	0	1.474s	249.4s
1 (Warm)	16 GB	99	99	0	1.458s	246.5s
2	8 GB	198	196	2	2.044s	397.8s
4	4 GB	396	393	3	3.660s	703.0s
8	2 GB	792	746	46	6.055s	1,194.7s

성능 저하율 분석 (Geometric Mean 기준)

동시 사용자	Geo Mean	저하율	평가
1 (baseline)	1.474s	—	—
2	2.044s	1.39×	양호 — 거의 선형에 가까운 확장
4	3.660s	2.48×	목표 달성 (3× 미만)
8	6.055s	4.11×	메모리 부족으로 OOM 다수 발생

동시 4사용자 기준 성능 저하율 2.48×로, 사전 정의한 성공 기준(3× 미만)을 달성하였습니다. 특히 2사용자 시 1.39×라는 수치는 리소스 경합이 적고 StarRocks의 동시성 처리가 효과적임을 보여줍니다.

6.3 OOM 실패 분석

8사용자 테스트에서 발생한 OOM 실패를 상세 분석하였습니다.

실패 건수 요약

동시 사용자	성공	실패	실패율	주요 실패 쿼리
2	196	2	1.0%	q78 (양 세션 동시 OOM)
4	393	3	0.8%	q23(2건), q67(1건)
8	746	46	5.8%	q67(8), q23(6), q78(6), q04(6) 등

8-User 실패 쿼리 Top 10

쿼리	실패 횟수 (/8 세션)	쿼리 특성
q67	8	대규모 GROUP BY + 윈도우 함수
q23	6	복잡한 서브쿼리, CTE
q78	6	대형 Fact 테이블 간 조인
q04	6	다중 조인 + CTE
q72	3	대규모 조인
q70	2	ROLLUP + grouping
q66	2	다중 UNION
q65	2	집계 + 서브쿼리
q38	2	INTERSECT + 다중 조인

OOM 발생 메커니즘

OOM은 예측 가능한 패턴으로 발생합니다. exec_mem_limit은 쿼리별 소프트 리밋이지만, CN 노드의 물리 메모리(16GB)는 모든 세션이 공유하는 자원입니다. 8세션 × 2GB = 16GB로 노드의 MemLimit과 정확히 일치하기 때문에, 메모리 피크가 겹치는 순간 OOM이 발생합니다.

흥미로운 점은, 먼저 피크에 도달한 세션이 kill되면 나머지 세션은 여유 메모리가 확보되어 정상 완료된다는 것입니다. 이는 q67이 8회 모두 실패한 반면 q72는 3회만 실패한 이유를 설명합니다.

대응 방안

단기: SET GLOBAL enable_spill = true 적용 — 메모리 한도 근접 시 중간 결과를 디스크로 spill하여 OOM 완화
중기: CN 노드당 메모리를 32GB 이상으로 증설하여 8사용자 이상 안정 운영 확보

7. 발생 이슈 및 해결

벤치마크 과정에서 발생한 주요 이슈와 해결 과정을 정리합니다. 유사 환경을 구축하는 분들에게 참고가 될 수 있도록 상세히 기술하였습니다.

#	이슈	원인	해결
1	Spark OOM (Java heap space)	FanoutDataWriter가 모든 파티션의 Writer를 동시에 오픈	`fanout.enabled=false` + CTAS ORDER BY 패턴으로 순차 기록
2	DROP TABLE PURGE 실패	S3 파일-메타데이터 불일치로 PURGE 에러	`safe_drop_table()` — PURGE 실패 시 non-PURGE 폴백 구현
3	Spark 세션 충돌	기존 demo 세션과 리소스 경합	pre-initialized 세션 종료 후 전용 세션 재생성
4	StarRocks 쿼리 비호환 (3건)	q49: 예약어 충돌, q70·q86: ORDER BY + grouping 비호환	alias 변경 + 서브쿼리 래핑으로 99/99 통과
5	동시성 테스트 OOM	CN 노드 물리 메모리 공유 경합	`enable_spill=true` 권고 + 메모리 증설 검토

8. 전체 결과 요약

8.1 Batch ELT 결과

항목	값
테이블 수	24
총 행 수	9.6억
총 크기	~30 GB
적재 시간	54분
처리 속도	296K rows/sec

8.2 Query 성능 결과

Run	쿼리 수	성공률	Geometric Mean	Total Time
Cold	99	100%	1.474초	249.4초
Warm	99	100%	1.458초	246.5초

8.3 동시성 테스트 결과

동시 사용자	exec_mem_limit	성공률	Geometric Mean	성능 저하율
1 (baseline)	16 GB	100%	1.474s	—
2	8 GB	99.0%	2.044s	1.39×
4	4 GB	99.2%	3.660s	2.48×
8	2 GB	94.2%	6.055s	4.11×

8.4 성공 기준 달성 현황

항목	기준	결과	판정
SF-100 배치 적재 시간	3시간 이내	54분	✅ PASS
배치 적재 Throughput	최소 10K rows/s	296K rows/sec	✅ PASS
SF-100 Geometric Mean	60초 이내	1.474초	✅ PASS
동시 4사용자 성능 저하	3× 미만	2.48×	✅ PASS
데이터 정합성	소스-타겟 100% 일치	100%	✅ PASS
TPC-DS 쿼리 통과율	99/99	99/99 (100%)	✅ PASS

모든 성공 기준을 달성하였습니다.

8.5 핵심 성능 지표

벤치마크 결과를 세 가지 관점에서 정리합니다. 이 세 지표는 각각 다른 독자에게 다른 메시지를 전달합니다.

① 종합 성능 지표: QphDS (Queries per Hour at Scale Factor)

"시스템이 시간당 얼마나 많은 분석 업무량을 처리하는가?"

QphDS는 TPC-DS의 공식 요약 지표로, 글로벌 벤더(Snowflake, Databricks, Oracle 등)와 직접 비교할 수 있는 유일한 표준 수치입니다.

항목	값
산출 공식	`SF × 3,600 / GeoMean(초)`
SF	100
GeoMean (Cold Run)	1.474초
QphDS@100	244,234

산출: 100 × 3,600 / 1.474 = 244,234. GeoMean 기반 Power 지표로, 99개 쿼리 전체의 대표 응답속도를 반영합니다.

② 경제성 지표: QphDS/$ (Price-Performance)

"1달러당 처리 효율이 얼마나 좋은가?"

고사양 서버를 투입해 만든 결과인지, 효율적인 아키텍처에서 나온 결과인지를 구분해주는 지표입니다. DIP는 n2-standard-8 노드 3대라는 비교적 저사양 인프라로 고성능을 달성하였으므로, 가성비(ROI) 관점에서 큰 강점을 가집니다. 비용 산정에는 인프라(HW)뿐 아니라 DIP 플랫폼 소프트웨어 비용을 함께 반영하였습니다.

항목	값
인프라(HW) 월 비용	~$730 (n2-standard-8 × 3, GCP on-demand)
DIP SW 월 비용	~$2,160 ($3/hr × 720hr)
총 월 비용	~$2,890
시간당 비용 (HW + SW)	~$4.01
QphDS/$ (시간당)	~60,900
QphDS/$ (월 기준)	~84.5

동일 QphDS를 달성하기 위해 타사 클라우드 DW가 투입하는 인프라+SW 비용 대비, DIP는 HW·SW 비용을 모두 포함하고도 높은 가성비를 보여줍니다.

③ 체감 성능 지표: Query Geometric Mean

"사용자가 쿼리를 던지고 결과를 받을 때까지 몇 초 걸리는가?"

기술을 모르는 현업 사용자도 "1.4초 만에 결과가 나온다"는 말은 직관적으로 이해합니다. 일반적인 클라우드 DW 환경에서 TPC-DS SF-100의 GeoMean이 30~60초 수준인 것과 비교하면, DIP는 20~40배 빠른 응답 속도를 제공합니다.

항목	값
GeoMean (Cold)	1.474초
GeoMean (Warm)	1.458초
Cold/Warm 차이	1.1% (캐시 무관 일관 성능)

세 지표 종합

지표	의미	DIP 결과	핵심 메시지
QphDS@100	시간당 처리 업무량	244,234	글로벌 표준으로 동급 사양 대비 최상위권
QphDS/$	1달러당 처리 효율	~60,900/hr	HW+SW 비용 포함에도 높은 가성비
GeoMean	체감 응답시간	1.474초	타사 30~60초 대비 20~40배 빠른 응답

9. 결론 및 권고사항

9.1 결론

Batch ELT는 SF-100 기준 24개 테이블, 9.6억 행을 54분에 Iceberg 적재 완료하였습니다(296K rows/sec). 목표였던 3시간 대비 약 3.3배 빠른 성과입니다.

Query 성능은 TPC-DS 99개 쿼리 전량 통과, Geometric Mean 1.474초로 목표 60초를 크게 상회합니다. Cold/Warm 간 차이가 1.1%에 불과하여, 캐시 의존 없이도 일관된 성능을 제공합니다. 이를 TPC-DS 공식 지표로 환산하면 QphDS@100 = 244,234로, n2-standard-8 3노드 구성임을 감안하면 동급 사양 대비 글로벌 최상위권이며, HW+SW 비용을 모두 포함한 QphDS/$ ~60,900/hr이라는 높은 가성비를 보여줍니다.

동시성은 4사용자까지 안정적(성능 저하 2.48×, 실패율 0.8%)이며, 8사용자에서는 메모리 경합으로 OOM이 발생하여(실패율 5.8%) 메모리 증설 또는 Spill 설정이 필요합니다.

9.2 권고사항

항목	권고 내용
8-User OOM 대응	`SET GLOBAL enable_spill = true` 적용으로 디스크 spill 활성화
CN 메모리 증설	8사용자 이상 안정 운영 시 CN 노드당 32GB 이상 권고
Batch ELT 최적화	6노드 스케일아웃으로 적재 시간 ~25분, 비용 대비 최적 효율 달성 가능

9.3 다음 편 예고

Part 2에서는 Kafka CDC와 OLake CDC 벤치마크 결과를 공유합니다. 초기 적재 속도 비교, 실시간 변경 데이터 반영 지연(Latency) 측정, 그리고 운영 편의성 관점에서의 비교 분석을 다룰 예정입니다.

본 벤치마크는 DIP v1.0 플랫폼 위에서 수행되었습니다. 환경이나 설정에 따라 결과가 달라질 수 있습니다.

목차