Storage and Compute Architecture
시스템·워크로드·스토리지 티어의 경계가 수렴하는 데이터 아키텍처 패턴
개요
트랜잭션·분석·하이브리드·공유 스토리지 시스템의 경계가 흐려지고 있다. OLTP/OLAP의 분리가 HTAP·LTAP로 수렴하고, 테이블 포맷이 카탈로그로 거버넌스되며, 스트림과 테이블이 같은 추상화로 통합된다. 이 토픽은 Data Infrastructure Patterns(광범위한 인프라 패턴)에서 시스템·스토리지 티어·워크로드 경계라는 좁고 깊은 아키텍처 축을 추출한다.
워크로드/스토리지 분류 체계
시스템 수·워크로드 수·가시성·durable copy 수로 아키텍처를 기술:
- Storage-Workload Architecture Taxonomy — OLTP/OLAP/HTAP/LTAP, tiering vs materializing
- Can We Agree on a Storage-Workload Architecture Taxonomy
| Type | Systems | Workloads | Copies | Example |
|---|---|---|---|---|
| Single Tier | 1 | 1 | 1 | Postgres + SSD |
| Internal Tiering | 1 | 1 | 1 | Kafka tiered storage |
| Hybrid (HTAP) | 1 | 2 | 1 | SingleStore, AliSQL DuckDB |
| Materializing | 2 | 2 | 2 | ETL/Connectors |
| Shared Tiering | 2 | 2 | 1 | LTAP, Apache Fluss |
스트림-테이블 이중성
batch vs streaming은 거짓 이분법 — “테이블 = 스트림의 materialization, 스트림 = 테이블의 history”. 통일은 더 나은 glue가 아니라 구분을 무의미하게 만드는 추상화에서 나온다.
- Real-Time Stream Processing — stream-table duality, Apache Fluss(table-first 스트리밍 스토리지), Flink streaming-first
- When Tables Became the Language of Time · From Events To Real-Time Profiles On Apache Fluss
카탈로그 중심 lakehouse
파일시스템 경로 의존성에서 벗어나, 카탈로그가 테이블 ID·발견·접근 제어·커밋 비준의 권위 있는 시스템이 된다.
- Catalog-Managed Tables — Delta Lake 4.1 + Unity Catalog, Catalog Commits GA, Hive→Iceberg 마이그레이션(column ID 기반 스키마)
- Distributed SQL Engine Operations — 공유 Iceberg 위 multi-engine 라우팅(이종 엔진, “테이블 최적화가 라우팅을 푼다”)
- Why We Moved from Hive-Style Data Lakes to Apache Iceberg · Routing Multiple Query Engines with Iceberg
파티션·청크·part 크기 관리
물리적 분할 단위의 크기가 메모리·pruning·압축·백필·planner를 동시에 좌우한다. “좋은” 전략은 정적이지 않다 — ingest 증가로 day-one 최적이 병목이 된다.
- Partition Sizing and Management — wide partition(Netflix Cassandra 동적 분할), 너무 많은 part(Cloudflare ClickHouse planner contention), TimescaleDB chunk 축소
- Dynamic Repartitioning for Time Series Workloads at Netflix · ClickHouse Query Plan Lock Contention at Cloudflare · Why We Shrank TimescaleDB Chunks from 30 Days to 7
실행 엔진의 진화
- Columnar Execution Engine — Velox + Gluten, Microsoft Fabric(JVM 우회 C++ 벡터화)
- DuckDB — 임베디드 OLAP, SQL 트랜스파일링, AliSQL HTAP 엔진, SQL 내 통계(the-stats-duck)
- Multimodal Data Processing Engine — Ray Data vs Daft(멀티모달 CPU+GPU 배치 처리)
- Database Concurrency Control — Blink-tree, 고동시성 인덱스 운영
멀티모달·반정형 스토리지
- Object Storage Evolution — S3 Tables/Vectors/Files, stage-and-commit
- Semi-Structured Data — Parquet Variant, shredding
- Lance + DuckDB가 멀티모달 저장 spine(→ Multimodal Data Processing Engine)
공통 원칙
- 경계의 수렴: OLTP/OLAP/HTAP/LTAP가 tiering·materialization으로 blend — “zero-copy” marketing보다 시스템·워크로드·copy 차원으로 정확히 기술
- 카탈로그가 권위: 파일 경로가 아닌 카탈로그가 테이블 ID·거버넌스·동시성 조정
- 미래 단위만 조정 = 안전: 기존 데이터 rewrite 없이 미래 파티션/청크부터 새 전략
- 데이터 모델도 차원: 3NF(OLTP) vs Kimball(분석) — 둘 다 원하면 materialization 필요
- 테이블 최적화가 라우팅을 푼다: compaction·sort가 각 쿼리에 viable한 엔진 집합 확장
관련 위키
- Storage-Workload Architecture Taxonomy
- Catalog-Managed Tables
- Partition Sizing and Management
- Real-Time Stream Processing
- Columnar Execution Engine
- DuckDB
- Distributed SQL Engine Operations
- Object Storage Evolution
- Database Concurrency Control
- Multimodal Data Processing Engine
관련 이슈: DEW #256, #258, #259, #260, #262, #266, #268, #270, #272, #273, #274, #276