By dongwooshin
in
Products
—
13 Mar 2026
DIP 플랫폼 TPC-DS 벤치마크 테스트 계획
DIP 플랫폼의 배치 ELT, 실시간 CDC, 분석 쿼리 성능을 TPC-DS 표준 벤치마크로 정량 측정하는 테스트 계획서입니다. Spark, StarRocks, OLake, Kafka CDC 파이프라인을 비교 검증합니다.
목차
테스트 목적 테스트 환경
테스트 시나리오
TPC-DS 데이터 생성 및 적재
성능 측정 도구 및 자동화 테스트 수행 일정 결과 보고서 형식
성공 기준 (Pass/Fail Criteria) 리스크 및 고려사항 참고 자료
1. 테스트 목적
DIP 플랫폼의 데이터 처리 성능을 TPC-DS 표준 벤치마크를 기반으로 정량적으로 측정합니다. 테스트는 배치 적재, 실시간 CDC, 분석 쿼리의 세 가지 영역으로 구분하며, 각 영역별 핵심 지표를 아래와 같이 정의합니다.
테스트 영역
측정 대상
DIP 구성요소
ELT — 배치 대량 데이터 적재 처리량(throughput)
Spark → Iceberg → StarRocks (External Catalog)
ELT — 실시간(CDC) 변경 데이터 전파 지연시간(latency) 및 초기적재 처리량
경로A: OLake → Iceberg / 경로B: Debezium → Kafka → Iceberg
Query 분석 쿼리 응답시간(response time)
StarRocks (Iceberg External Catalog)
2. 테스트 환경
2.1 테스트 절차
아래 다이어그램은 전체 벤치마크 파이프라인의 데이터 흐름을 나타냅니다. DuckDB로 생성한 TPC-DS 데이터를 PostgreSQL에 적재한 뒤, 배치(Spark) 및 실시간(OLake/Kafka) 경로를 통해 Iceberg에 기록하고, StarRocks External Catalog로 분석 쿼리를 수행합니다.
┌──────────────────────────────────────────────────────────────────────────────┐
│ DIP TPC-DS 벤치마크 파이프라인 │
├──────────────────────────────────────────────────────────────────────────────┤
│ │
│ ① 데이터 생성 ② 소스 적재 ③ Batch ELT │
│ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │
│ │ DuckDB │Parquet │PostgreSQL│ JDBC │ Spark-Iceberg│ │
│ │ TPC-DS │──────▶│ tpcds │───────▶│ Batch ELT │ │
│ │ dsdgen() │ 24tbl │ _sf1 │ Read │ │ │
│ └──────────┘ └────┬─────┘ └──────┬───────┘ │
│ │ │ Write │
│ │ ▼ │
│ ④ 쿼리 벤치마크 │ ┌──────────────┐ │
│ ┌──────────────┐ Ext. │ │ Iceberg │ │
│ │ StarRocks │◀───────┼───────────────│ (MinIO S3) │ │
│ │ TPC-DS 99Q │ Catalog│ │ Lakekeeper │ │
│ └──────────────┘ │ └──────────────┘ │
│ │ ▲ │
│ ⑤ CDC 실시간 적재 │ │ │
│ ┌──────────────┐ │ ┌───────┴──────┐ │
│ │ 경로A: OLake │◀───────┤ │ Iceberg │ │
│ │ (Kafka-less) │───────┼──────────────▶│ Write │ │
│ └──────────────┘ WAL │ └──────────────┘ │
│ ┌──────────────┐ │ ▲ │
│ │ 경로B: Kafka │◀───────┘ ┌───────┴──────┐ │
│ │ Debezium+Sink│────────────────────────▶│ Iceberg │ │
│ └──────────────┘ │ Sink │ │
│ └──────────────┘ │
└──────────────────────────────────────────────────────────────────────────────┘
2.2 HW/SW 사양
2.2.1 HW (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
pg × 1
e2-standard-8
8
32 GB
50 GB pd-ssd
1,000 GB pd-ssd
rke2-node Data Disk 마운트: /var/lib/longhorn (Longhorn 분산 스토리지)
PostgreSQL Data Disk 마운트: /data
2.2.2 SW
항목
버전
PostgreSQL
16.x
Spark
3.5.x
StarRocks
3.5.2
Kafka
3.8.1 (KRaft, 단일 브로커)
Debezium
2.7 (PostgreSQL Source Connector)
Iceberg Sink
Tabular 0.6.19
OLake
v0.3.16 (olakego/source-postgres)
Lakekeeper
latest (Iceberg REST Catalog)
2.3 TPC-DS 데이터 스케일 팩터
단계
Scale Factor
데이터 크기 (Parquet)
행 수 (전체 24 테이블)
용도
SF-1 1
~264 MB
약 1,960만 건
기능 검증, 파이프라인 디버깅
SF-100 100
~100 GB
약 수십억 건
본 성능 측정
SF-100 이상은 클러스터 리소스 여유에 따라 선택적으로 수행합니다.
2.4 TPC-DS 스키마 개요
Fact 테이블 (7개) : store_sales, catalog_sales, web_sales, inventory, store_returns, catalog_returns, web_returnsDimension 테이블 (17개) : customer, item, date_dim, store, warehouse, customer_demographics 등총 테이블 수 : 24개
3. 테스트 시나리오
3.1 ELT 성능 — 배치 (Batch ELT)
목적 : PostgreSQL에서 Iceberg로의 대량 데이터 일괄 적재 성능을 측정합니다.
3.1.1 테스트 경로
PostgreSQL ──(Spark JDBC Read)──▶ Iceberg (MinIO S3) ──▶ StarRocks (External Catalog)
3.1.2 측정 항목
지표
단위
설명
Total Load Time 초(s)
전체 24개 테이블 적재 완료까지의 총 소요 시간
Throughput rows/s
단위 시간당 처리 행 수
Table Load Time 초(s)
개별 테이블(특히 Fact 테이블) 적재 시간
Resource Utilization %
CPU, Memory, Disk I/O, Network 사용률
3.1.3 실행 절차
TPC-DS 데이터 생성 (DuckDB dsdgen)
PostgreSQL에 스키마 생성 및 데이터 로드 (DuckDB postgres 확장)
Spark Job 실행 — 시간 측정 시작
적재 완료 확인 및 소스-타겟 행 수 검증
시간 측정 종료, 리소스 메트릭 수집
3.2 ELT 성능 — 실시간 CDC (Real-time ELT)
목적 : 소스 DB 변경 사항의 실시간 반영 지연시간을 측정하고, 두 CDC 경로(OLake vs Kafka)의 초기적재 처리량을 비교합니다.
3.2.1 테스트 경로
경로A: PostgreSQL (WAL) ──▶ OLake Worker ──▶ Iceberg (Lakekeeper)
경로B: PostgreSQL (WAL) ──▶ Debezium Source ──▶ Kafka ──▶ Iceberg Sink Connector ──▶ Iceberg (Lakekeeper)
경로
CDC 엔진
특징
경로A OLake
Kafka 없이 PostgreSQL → Iceberg 직접 적재. Iceberg 타겟에 특화되어 있으며 UI 기반 설정 제공
경로B Debezium + Kafka
Kafka 기반 이벤트 스트리밍. 다양한 타겟으로 확장 가능하나 설정이 상대적으로 복잡
3.2.2 측정 항목
지표
단위
설명
적용 경로
Initial Load Time 초(s)
전체 테이블 초기적재 완료 시간
A, B
Initial Load Throughput rows/s
초기적재 시 초당 처리 행 수
A, B
End-to-End Latency ms
소스 INSERT/UPDATE 시점 ~ Iceberg 반영 시점
A, B
P50 / P95 / P99 Latency ms
백분위별 지연 시간
A, B
CDC Throughput events/s
초당 처리 CDC 이벤트 수
A, B
Kafka Consumer Lag events
Kafka consumer lag (Kafka 경로에만 해당)
B
Data Consistency %
소스-타겟 간 데이터 일치율
A, B
3.2.3 테스트 케이스
초기적재 (Initial Load) 비교:
ID
테스트명
설명
경로
SF
R-01
OLake Initial Load
OLake 전체 테이블 초기적재
A
100
R-02
Kafka CDC Initial Load
Debezium 스냅샷 기반 초기적재
B
100
R-03
Throughput Comparison
R-01, R-02 결과 기반 초기적재 처리량 비교 분석
A, B
100
CDC 실시간 변경 반영:
ID
테스트명
설명
경로
부하
R-04
Single Row Latency
단건 INSERT 후 Iceberg 반영 시간
A, B
1 row
R-05
Burst Insert
100만 건 일괄 INSERT 후 전체 반영 완료 시간
A, B
1M rows
R-06
Sustained Load
지속적 INSERT (100 rows/s × 10분)
A, B
60K rows
R-07
Mixed DML
INSERT 70% / UPDATE 20% / DELETE 10% 혼합 부하
A, B
10K rows
R-08
Peak Load
최대 처리량 도달 시점까지의 부하 증가 테스트
A, B
600K rows
R-09
Schema Evolution
컬럼 추가 후 CDC 정상 동작 여부 확인
A, B
—
R-10
Recovery Test
CDC 프로세스 장애 후 복구 시 데이터 정합성 검증
A, B
—
R-11
Large Transaction
단일 트랜잭션 내 10만 건 변경 처리
A, B
100K rows
3.2.4 지연시간 측정 방법
소스 테이블에 타임스탬프 컬럼(_benchmark_ts)을 추가하고, Iceberg 반영 시점과의 차이를 계산합니다.
-- PostgreSQL 소스: 타임스탬프 포함 INSERT
INSERT INTO store_sales_cdc (ss_sold_date_sk, ..., _benchmark_ts)
VALUES (..., clock_timestamp());
-- Iceberg 타겟: 반영 시점 확인 (Spark SQL)
SELECT _benchmark_ts,
current_timestamp() AS received_ts,
(unix_timestamp(current_timestamp()) - unix_timestamp(_benchmark_ts)) * 1000 AS latency_ms
FROM lakekeeper.<namespace>.store_sales_cdc
WHERE _benchmark_ts > '2026-03-10 10:00:00';
경로A (OLake) : Iceberg namespace는 OLake Job 설정에 의해 자동 생성됩니다.경로B (Kafka) : Iceberg namespace는 Sink 커넥터의 동적 라우팅에 의해 결정됩니다 (예: debezium_tpcds_sf1).
⚠️ 주의 : 지연시간 정확도를 높이기 위해 소스와 타겟 시스템 간 NTP 시간 동기화가 필수입니다. 가능하면 동일 서버에서 측정하는 것을 권장합니다.
3.2.5 실행 절차
경로A (OLake):
OLake UI에서 Source 등록 (PostgreSQL, tpcds_sf1)
Destination 등록 (Iceberg REST Catalog + MinIO)
Job 생성 (Full Refresh + CDC, Upsert 모드)
초기적재 완료 확인 및 소스-타겟 행 수 검증
부하 생성 스크립트 실행 (INSERT / UPDATE / DELETE)
Spark SQL로 Iceberg 반영 시점 확인 및 지연시간 측정
메트릭 수집 및 결과 기록
경로B (Kafka CDC):
Kafka + Connect 클러스터 시작
register-connectors.sh 실행 (멱등 커넥터 등록)Debezium Source 스냅샷 완료 대기 (초기적재)
Iceberg 행 수 검증 (StarRocks External Catalog 활용)
부하 생성 스크립트 실행 (INSERT / UPDATE / DELETE)
Iceberg 반영 시점 확인 및 지연시간 측정
Kafka UI에서 Consumer Lag 모니터링
메트릭 수집 및 결과 기록
3.3 Query 성능 (Analytical Query)
목적 : Iceberg에 적재된 TPC-DS 데이터에 대해 StarRocks External Catalog를 통한 분석 쿼리 응답 시간을 측정합니다.
3.3.1 테스트 대상
엔진 : StarRocks 3.5.2 (Iceberg External Catalog)쿼리 수 : TPC-DS 99개 쿼리 (StarRocks 호환 문법으로 변환 완료)데이터 : 배치 ELT 또는 CDC로 적재된 Iceberg 테이블
3.3.2 쿼리 분류
카테고리
TPC-DS 쿼리 예시
특성
단순 스캔/필터 Q3, Q7, Q19, Q42, Q52, Q55
단일 Fact 테이블, 간단한 조인
다중 조인 Q13, Q17, Q25, Q29, Q34
3개 이상 테이블 조인
집계/그룹핑 Q1, Q6, Q11, Q27, Q46
GROUP BY, HAVING, 윈도우 함수
서브쿼리/CTE Q4, Q14, Q23, Q31, Q39
복잡한 서브쿼리, WITH절
대규모 조인 Q64, Q72, Q78, Q80, Q82
대형 Fact 테이블 간 조인
3.3.3 측정 항목
지표
단위
설명
Query Response Time 초(s)
개별 쿼리 실행 시간
Geometric Mean 초(s)
TPC-DS 표준 기하평균 성능 지표
Cold / Warm Run 초(s)
캐시 미적용 상태(Cold) vs 캐시 활용 상태(Warm)
Throughput queries/hr
시간당 처리 쿼리 수 (Power + Throughput test)
Concurrency —
동시 사용자 증가에 따른 성능 변화
Query Profile —
실행 계획, 스캔 행 수, 메모리 사용량
3.3.4 테스트 케이스
ID
테스트명
설명
SF
Q-01
Power Test (Cold Run)
99개 쿼리 순차 실행, 캐시 초기화 후 1회차
100
Q-02
Warm Run
99개 쿼리 순차 실행, 2회차 (캐시 활용)
100
Q-03
Category Drill-down
카테고리별 대표 쿼리 상세 프로파일링
100
Q-04
Concurrency — 2 users
2개 동시 세션에서 쿼리 실행
100
Q-05
Concurrency — 4 users
4개 동시 세션에서 쿼리 실행
100
Q-06
Concurrency — 8 users
8개 동시 세션에서 쿼리 실행
100
Q-07
Mixed Workload
쿼리 실행 중 배치 적재 동시 수행 시 영향 측정
100
Q-08
Top-10 Slowest
가장 느린 10개 쿼리에 대한 튜닝 전/후 비교
100
3.3.5 실행 절차
DuckDB tpcds_queries()로 표준 쿼리 추출 → StarRocks 문법으로 변환
StarRocks 호환성 검증 및 비호환 쿼리 수정
캐시 초기화 (Cold Run 시)
쿼리 순차 실행 및 개별 실행 시간 측정
쿼리 프로파일(EXPLAIN ANALYZE) 수집
Geometric Mean 산출
4. TPC-DS 데이터 생성 및 적재
4.1 데이터 생성
DuckDB TPC-DS 확장(dsdgen)을 사용하여 데이터를 생성하고, Parquet(ZSTD 압축) 형식으로 내보냅니다.
# TPC-DS 데이터 생성 (SF-1)
python benchmark/data/generate_tpcds.py 1
# TPC-DS 데이터 생성 (SF-100)
python benchmark/data/generate_tpcds.py 100
4.2 PostgreSQL 적재
DuckDB postgres 확장을 통해 Parquet 파일을 PostgreSQL에 고속으로 적재합니다. 스크립트는 멱등성이 보장되어 반복 실행 시 기존 데이터를 안전하게 교체합니다.
# PostgreSQL 적재 (멱등)
python benchmark/data/load_to_postgres.py 1
4.3 StarRocks External Catalog 설정
StarRocks에서 Iceberg 테이블에 대해 별도 적재 없이 External Catalog를 통해 직접 쿼리합니다.
CREATE EXTERNAL CATALOG bmt_catalog
PROPERTIES (
"type" = "iceberg",
"iceberg.catalog.type" = "rest",
"iceberg.catalog.uri" = "http://lakekeeper:8181/catalog",
"iceberg.catalog.warehouse" = "iceberg",
"aws.s3.endpoint" = "http://minio:9000",
"aws.s3.region" = "us-east-1",
"aws.s3.enable_path_style_access" = "true"
);
-- 쿼리 예시
SELECT COUNT(*) FROM bmt_catalog.tpcds_sf1.store_sales;
5. 성능 측정 도구 및 자동화
용도
도구
설명
데이터 생성
DuckDB dsdgen
TPC-DS 표준 데이터 생성 (Python 스크립트)
쿼리 생성
DuckDB tpcds_queries()
TPC-DS 표준 쿼리 추출 및 StarRocks 문법 변환
배치 ELT
Spark + Lakekeeper
JDBC Read → Iceberg Write
CDC (경로A)
OLake
PostgreSQL → Iceberg 직접 적재
CDC (경로B)
Debezium + Kafka + Iceberg Sink
Kafka 기반 CDC 파이프라인
CDC 부하 생성
Python 스크립트 / pgbench
INSERT / UPDATE / DELETE 부하
쿼리 벤치마크
Python + pymysql
StarRocks 쿼리 자동 실행 및 시간 측정
Kafka 모니터링
Kafka UI (Provectus)
Consumer Lag, Topic, Connector 상태 확인
리소스 수집
sar, iostat, vmstatOS 레벨 CPU / Memory / Disk I/O 모니터링
6. 테스트 수행 일정
단계
Activity
주요 Task
Step 1 환경 준비
인프라 생성, TPC-DS 데이터 생성 및 PostgreSQL 적재, 각 컴포넌트 구성
Step 2 배치 ELT
Spark → Iceberg 적재 수행 및 성능 측정
Step 3 Query 성능
Q-01 ~ Q-08 수행 (Cold/Warm Run), 쿼리 호환성 수정
Step 4 실시간 CDC — 초기적재
R-01 ~ R-03 수행, OLake vs Kafka 초기적재 처리량 비교
Step 5 실시간 CDC — 변경 반영
R-04 ~ R-11 수행, 지연시간 및 정합성 측정
Step 6 분석 및 보고
결과 정리, 병목 구간 분석, 최종 보고서 작성
7. 결과 보고서 형식
아래는 보고서 템플릿입니다. 실측값은 테스트 수행 후 채워집니다.
7.1 배치 ELT 결과 요약
SF
테이블 수
총 행 수
총 크기
적재 시간
Throughput
1
24
19,557,579
~264 MB
324초 57K rows/s
100
24
—
~100 GB
—
—
7.2 CDC 초기적재 비교 결과
경로
방식
데이터
소요 시간
Throughput
비고
A
OLake
10,550,966행 (3 tbl)
125초 84K rows/s Kafka 없이 직접 적재
B
Kafka CDC (최적화 후)
19,557,579행 (24 tbl)
~600초 ~33K rows/s Debezium + Kafka
B
Kafka CDC (최적화 전)
19,557,579행 (24 tbl)
~1,740초
~11K rows/s
기본 설정
⚠️ 경로A(OLake)와 경로B(Kafka CDC)는 적재 대상 테이블 수가 다르므로(3개 vs 24개), 행당 처리량(rows/s)으로 비교해야 합니다. 동일 조건 비교를 위해 SF-100 테스트에서는 양 경로 모두 동일 테이블 셋을 대상으로 수행할 예정입니다.
7.3 CDC 실시간 결과 요약
테스트
건수
P50 (ms)
P95 (ms)
P99 (ms)
Max (ms)
경로
Single Row
1
—
—
—
—
A, B
Burst 1M
1,000,000
—
—
—
—
A, B
Sustained
60,000
—
—
—
—
A, B
Mixed DML
10,000
—
—
—
—
A, B
Peak Load
600,000
—
—
—
—
A, B
7.4 Query 성능 결과 요약
SF
쿼리 수
성공률
Geometric Mean
Min
Max
Cold / Warm
1
99
100% 1.044초 0.150초
21.793초
1.044s / —
100
99
—
—
—
—
— / —
7.5 동시성 테스트 결과
동시 사용자
Geometric Mean
Throughput (queries/hr)
성능 저하율
1
—
—
baseline
2
—
—
—
4
—
—
—
8
—
—
—
8. 성공 기준 (Pass/Fail Criteria)
8.1 배치 ELT
항목
기준
데이터 정합성
소스-타겟 행 수 100% 일치
SF-100 적재 시간
3시간 이내
Throughput
최소 10K rows/s 이상
8.2 실시간 CDC
항목
기준
적용 경로
초기적재 데이터 정합성
소스-타겟 행 수 100% 일치
A, B
초기적재 Throughput
경로A(OLake)가 경로B(Kafka CDC) 대비 우위 확인
A, B
단건 E2E Latency (P95)
3초 이내
A, B
지속 부하 시 Latency (P95)
10초 이내
A, B
CDC 데이터 정합성
INSERT / UPDATE / DELETE 모두 소스-타겟 100% 일치
A, B
장애 복구 후 정합성
데이터 유실 0건
A, B
8.3 Query 성능
항목
기준
SF-1 Geometric Mean
5초 이내
SF-100 Geometric Mean
60초 이내
동시 4 사용자 성능 저하
단일 사용자 대비 50% 이내
성공 기준은 실제 HW 사양 및 클러스터 리소스 상황에 따라 조정될 수 있습니다.
9. 리스크 및 고려사항
리스크
영향
대응 방안
TPC-DS 쿼리 StarRocks 비호환
일부 쿼리 측정 불가
비호환 쿼리 수동 수정 (Q49, Q70, Q86 수정 완료)
리소스 부족 (SF-100)
테스트 불가 또는 OOM 발생
SF-10으로 대체 수행 후 리소스 확장 검토
OLake 비ASCII 컬럼명 미지원
한글 컬럼 포함 스키마에서 충돌 발생
영문 컬럼명으로 사전 변환
OLake 커뮤니티 성숙도 부족
예상치 못한 버그 발생 가능
이슈 발생 시 Kafka CDC 경로로 대체
Kafka CDC 설정 복잡도
초기 셋업 지연
멱등 스크립트 및 커넥터 JSON 템플릿 활용
Debezium tasks.max=1 제약
Source Connector 병렬 처리 불가
snapshot.max.threads 설정으로 스냅샷 단계 병렬화
Kafka Sink 토픽 발견 지연
초기적재 시 신규 토픽 동시 소비 불가
metadata.max.age.ms=5000 설정으로 메타데이터 갱신 주기 단축
시스템 간 시간 동기화 미비
지연시간(Latency) 측정 오차 증가
NTP 동기화 필수 적용, 가능 시 동일 서버에서 측정
네트워크 병목
테스트 결과 왜곡
전용 네트워크 확보 또는 동일 호스트 구성
10. 참고 자료
