Data Eng Wiki

Storage and Compute Architecture

11 min read

Storage and Compute Architecture

시스템·워크로드·스토리지 티어의 경계가 수렴하는 데이터 아키텍처 패턴

개요

트랜잭션·분석·하이브리드·공유 스토리지 시스템의 경계가 흐려지고 있다. OLTP/OLAP의 분리가 HTAP·LTAP로 수렴하고, 테이블 포맷이 카탈로그로 거버넌스되며, 스트림과 테이블이 같은 추상화로 통합된다. 이 토픽은 Data Infrastructure Patterns(광범위한 인프라 패턴)에서 시스템·스토리지 티어·워크로드 경계라는 좁고 깊은 아키텍처 축을 추출한다.

워크로드/스토리지 분류 체계

시스템 수·워크로드 수·가시성·durable copy 수로 아키텍처를 기술:

TypeSystemsWorkloadsCopiesExample
Single Tier111Postgres + SSD
Internal Tiering111Kafka tiered storage
Hybrid (HTAP)121SingleStore, AliSQL DuckDB
Materializing222ETL/Connectors
Shared Tiering221LTAP, Apache Fluss

스트림-테이블 이중성

batch vs streaming은 거짓 이분법 — “테이블 = 스트림의 materialization, 스트림 = 테이블의 history”. 통일은 더 나은 glue가 아니라 구분을 무의미하게 만드는 추상화에서 나온다.

카탈로그 중심 lakehouse

파일시스템 경로 의존성에서 벗어나, 카탈로그가 테이블 ID·발견·접근 제어·커밋 비준의 권위 있는 시스템이 된다.

파티션·청크·part 크기 관리

물리적 분할 단위의 크기가 메모리·pruning·압축·백필·planner를 동시에 좌우한다. “좋은” 전략은 정적이지 않다 — ingest 증가로 day-one 최적이 병목이 된다.

실행 엔진의 진화

멀티모달·반정형 스토리지

공통 원칙

  1. 경계의 수렴: OLTP/OLAP/HTAP/LTAP가 tiering·materialization으로 blend — “zero-copy” marketing보다 시스템·워크로드·copy 차원으로 정확히 기술
  2. 카탈로그가 권위: 파일 경로가 아닌 카탈로그가 테이블 ID·거버넌스·동시성 조정
  3. 미래 단위만 조정 = 안전: 기존 데이터 rewrite 없이 미래 파티션/청크부터 새 전략
  4. 데이터 모델도 차원: 3NF(OLTP) vs Kimball(분석) — 둘 다 원하면 materialization 필요
  5. 테이블 최적화가 라우팅을 푼다: compaction·sort가 각 쿼리에 viable한 엔진 집합 확장

dew_277~286 — “무엇을 하나로 셀 것인가”의 재설계

이번 묶음에서 반복되는 형태가 하나 있다: 물리 레이아웃을 건드리지 않고 메타데이터 레이어에서 문제를 푼다.

문제해법바꾼 것
compaction이 동시 트랜잭션을 무효화Compaction Conflict Resolution — compaction map재실행 → position remap (분 → 밀리초)
세그먼트 100만 개에서 컨트롤 플레인 붕괴Control Plane Cardinality — Segment Group저장 단위는 두고 조율 단위만 확대 (2자릿수 ↓)
CDC의 small-file + 커밋 메타데이터 폭증DuckLake — 카탈로그를 DB에파일 포맷은 Parquet 그대로, 카탈로그 위치만 (40× 빠른 flush)
벡터 인덱스를 어디에 둘까Puffin-Backed Derived Data별도 시스템 → 테이블 포맷 사이드카

공통 진단 질문: “물리적 데이터 조각이 너무 많은 것인가, 아니면 컨트롤 플레인이 추적해야 할 것이 단순히 너무 많은 것인가?” — 물리적 granularity가 여전히 유용하다면 데이터 레이아웃을 바꾸는 것보다 조율 단위를 바꾸는 것이 더 나은 답이다.

⚠️ 나쁜 신호 두 가지: 큰 단위가 바람직해서가 아니라 메타데이터를 통제하려고 물리 크기를 키우고 있음, 스케일링 임계 아래로 유지할 목적만으로 인위적 테이블 경계를 만들고 있음.

오브젝트 스토리지가 조율 프리미티브를 얻다

Object-Storage-Native WAL — 2024년 11월 S3 conditional write가 eventual → strong consistency 이후 가장 실질적인 변화다. if-none-match(원자적 할당)와 if-match(CAS)만으로 외부 조율 서비스 없이 오브젝트 스토리지 위에 lock-free 자료구조를 만들 수 있다.

S3가 인터넷의 malloc이라면 conditional write는 포인터가 풍부한 구조를 구성하고 변형하는 데 쓸 수 있다.

Chroma의 wal3는 30년 된 lock-free 연결 리스트 큐를 그대로 올렸다 — fragment=노드, manifest=header. 그리고 scalable commutativity rule 덕분에 컬렉션마다 다른 prefix = 컬렉션당 독립 스케일링 단위가 공짜로 나온다. 중앙 집중 로그(단일 Kafka 클러스터)가 새 고객을 받는 능력을 본질적으로 제한하는 것과 대비된다.

setsum(order-agnostic 체크섬)으로 digest(GC된 prefix) ⊎ digest(라이브) == digest(전체 이력) 불변식을 O(1)로 유지하는 것이 진짜 기여다:

시스템은 두 번 만들어져야 한다 — 기능을 위해 한 번, 검증을 위해 한 번.

쓰기 시점 레이아웃이 읽기 비용을 결정한다

Direct Lake and VertiPaq가 이것을 정량적으로 보여준다. transcoding이 컬럼 단위 on-demand이므로 쿼리 레이턴시와 capacity 소비가 “Parquet을 어떻게 썼는가”의 속성이 된다.

가장 놀라운 발견: encoding_stats footer 필드 하나의 유무로 cold first-touch가 10,857 ms → 689 ms (~15×). 페이지 내용은 동일한 채로. 인코딩만으로는 부족하고 선언이 인코딩의 일부다. → Silent Failures and Data Integrity의 또 다른 얼굴 — 파일은 완벽히 유효하고 데이터도 맞는데 15배 느리다.

그리고 row group 크기는 양 끝이 모두 실패한다 (1,172개 작은 그룹 → cold 3.5× 느림 / 16M행 = segment 상한 → 9개 segment로 scan pool이 굶음). geometry를 추정에서 유도하지 마라 — DuckDB가 143,980,961행 테이블을 14.9M으로 9.7배 과소 추정했다.

하드웨어까지 내려가면

AI Accelerator Architecture — memory wall이 여섯 아키텍처를 갈랐다. Cerebras는 “memory wall이 웨이퍼를 자른 결과”라며 톱질을 건너뛰고, Groq는 비결정성을 전부 제거해 실행 전에 레이턴시를 안다. 데이터 엔지니어 입장에서 실용적인 것은 decode가 memory-bandwidth-bound라는 사실 — 긴 컨텍스트에서는 weight-bandwidth-bound가 KV-bandwidth-bound로 옮겨갈 뿐 사라지지 않는다.

관련 위키

관련 이슈: DEW #256, #258, #259, #260, #262, #266, #268, #270, #272, #273, #274, #276, #277, #279, #281, #284, #285, #286

그래프 뷰

백링크