트랜잭션 시스템, 분석 시스템, 하이브리드 시스템, 공유 스토리지 아키텍처 사이의 경계가 점점 흐려지고 있다. 이 글은 시스템, 워크로드, 스토리지 계층, 가시성, 영속적 데이터 사본이 서로 어떻게 연결되는지 설명하기 위한 작은 분류 체계를 제안한다.
트랜잭션 시스템, 분석 시스템, 하이브리드 시스템, 공유 스토리지 아키텍처 사이의 경계가 점점 흐려지고 있다. 이 글은 시스템, 워크로드, 스토리지 계층, 가시성, 영속적 데이터 사본이 서로 어떻게 연결되는지 설명하기 위한 작은 분류 체계를 제안한다.
OLTP, OLAP, HTAP, 그리고 이제 LTAP?
처음 두 가지는 이를 지원하기 위한 특화된 쿼리 엔진과 스토리지 시스템을 갖춘 두 가지 유형의 워크로드로 생각할 수 있다. Postgres와 MySQL 같은 RDBMS인 OLTP는 행 기반 스토리지 엔진을 사용한다. Clickhouse, 클라우드 데이터 웨어하우스, 레이크하우스 같은 OLAP는 열 기반 스토리지를 사용한다.
HTAP는 하이브리드 워크로드 시스템이다: 하나의 시스템 -> 트랜잭션 워크로드와 분석 워크로드 모두. 따라서 HTAP 시스템은 행 기반 데이터와 열 기반 데이터를 엮기 위한 특화된 스토리지와 특화된 쿼리 엔진을 가진다.
지금까지는 단일 시스템을 다루고 있다. Postgres(OLTP), Clickhouse(OLAP), SingleStore 또는 TiDB(HTAP) 같은 경우다.
그렇다면 최근 Databricks의 LTAP 발표는 무엇일까? LTAP는 두 가지 워크로드(OLTP와 OLAP)이면서, 동시에 두 개의 시스템(예: Postgres와 레이크하우스/Spark)이고, 두 가지 서로 다른 스토리지 시스템이 어느 정도 섞인 형태이기도 하다.
단일 시스템 대 다중 시스템, 단일 워크로드 대 다중 워크로드뿐 아니라, 계층화와 구체화 같은 다른 관련 개념도 있다:
계층화
단일 시스템은 비용 효율성을 위해 데이터를 핫 스토리지에서 콜드 스토리지로 계층화(이동)할 수 있다. 하나의 시스템, 하나의 사본, 두 개의 계층.
핫과 콜드는 같은 스토리지 형식(둘 다 행 기반이거나 둘 다 열 기반)일 수도 있고, 다른 형식(핫은 행 기반, 콜드는 열 기반)일 수도 있다.
두 시스템이 같은 스토리지 계층을 공유할 수도 있다. 시스템 A는 핫 데이터를 시스템 B의 스토리지로 계층화(이동)한다. 두 시스템, 하나의 사본이지만, 시스템 B는 아직 시스템 A에만 존재하는 가장 최신 데이터는 보지 못한다.
구체화
내가 “데이터의 사본”이라고 말할 때는 영속적인 사본을 뜻하므로, 캐싱은 여기에 포함되지 않는다. 사본 수가 정말 중요한 지표라면, 어쩌면 캐싱도 포함될 수 있다. 이것이 동작하도록 만들기 위해 얼마나 많은 캐시 데이터가 필요한지에 따라 다를 것이다. 세상이 좀 더 단순하면 좋을 텐데.
이와 관련해 공유된 어휘가 있으면 시스템 아키텍처를 더 쉽게 이야기할 수 있을 것이다. 그래서 나는 작년에 이를 위한 몇 가지 용어를 정의했고, 아래와 같이 확장했다.
Vis는 Visibility를 뜻한다(데이터가 다른 워크로드에서 언제 사용 가능해지는가).
넓은 분류 체계는 다음과 같다:
단일 계층, 하나의 시스템, 하나의 워크로드. 예: SSD를 사용하는 Postgres, 단일 계층 CockroachDB, 표준 Kafka 클러스터.
내부 계층화, 하나의 시스템, 하나의 워크로드, 일반적으로 비용 효율성을 위해 핫 스토리지에서 콜드 스토리지로 계층화한다. 예: 핫=SSD, 콜드=S3. 다만 계층화는 비용 외의 다른 목적에도 쓰일 수 있다. 예: Apache Kafka 계층형 스토리지, ClickHouse MergeTree 계층형 스토리지.
하이브리드(HTAP), 하나의 시스템, 두 개의 워크로드, 서로 다른 계층을 가질 수도 있는 이중 형식, 예: SSD 위의 핫 행 기반 데이터, S3 위의 장기 보관 열 기반 데이터. 두 가지 하위 범주가 있다**:**
구성에 의한 최신성: OLTP/OLAP 워크로드 전반에 걸친 일관성을 위해, 데이터는 두 형식에 동기적으로 기록되거나(이 경우 OLAP 쿼리는 열 저장소만 조회하면 됨), 또는 데이터가 비동기적으로 열 저장소에 복제되고 merge-on-read를 사용해 일관된 뷰를 제공한다. 예: SingleStore, Snowflake Hybrid tables, SAP Hana Column Store.
따라잡기에 의한 최신성: OLAP 쿼리는 행 저장소로부터 비동기 복제되는 열 저장소로 라우팅된다. 일관성은 조절 가능한 값이며, 더 강한 일관성은 “따라잡기에 의한 최신성” 접근이 필요하다. 즉, 열 저장소가 쿼리 LSN에 도달한 뒤에만 쿼리가 처리된다. 예: PolarDB-IMCI with Intelligent Routing, TiDB/TiFlash.
구체화, 두 개의 워크로드, 두 개의 시스템, 두 개의 사본. 시스템 A가 데이터를 시스템 B로 복사한다. 각 시스템은 하나의 워크로드에 전용되며, 특화된 쿼리 엔진과 스토리지를 갖는다. 예: 일반적인 ETL, 많은 Kafka 호환 서비스는 토픽을 Iceberg로 자동 구체화한다. 예: Confluent Tableflow, Databricks Synced tables는 레이크하우스에서 lakebase(Postgres)로 비동기 구체화를 수행한다.
공유 계층화, 두 개의 워크로드, 두 개의 시스템. 핫 계층 + 공유되는 더 차가운 계층 전체에 걸쳐 하나의 사본(예: 시스템 A를 위한 SSD 위의 핫 행 기반 데이터, 시스템 A와 B를 위한 S3 위의 더 차가운 열 기반 데이터). 예: Apache Fluss는 핫 데이터를 레이크하우스(레이크하우스는 공유 계층이다)로 계층화한다. LTAP.
잠재적으로는, 추가 범주가 가설적으로 존재할 수도 있다: Shared-Sync-RR와 Shared-Sync-MM. 두 시스템, 두 워크로드, 하나의 동기식 스토리지(각 쓰기가 즉시 다른 시스템에서 보임). 읽기 복제본(RR) 변형은 하나의 마스터 시스템과 하나의 읽기 전용 시스템을 가진다(예: Postgres에 대한 쓰기가 레이크하우스에서 읽기에 대해즉시보인다). 멀티 마스터(MM)는 두 시스템 모두 쓰기를 허용한다(어렵다!!).
이 글을 쓰는 시점에서는 LTAP에 대한 세부 사항이 부족하지만, LTAP는 Shared Tiering에 해당할 것으로 보인다. HTAP와 LTAP를 구분하는 점은 HTAP가 하나의 하이브리드 시스템으로서 트랜잭션 쿼리와 분석 쿼리 모두에 동시에 데이터를 가시화한다는 것이다. LTAP는 서로 다른 두 시스템(각각 다른 워크로드를 목표로 함)의 데이터를 통합하고, 더 차가운 데이터를 공유하여 (영속적인) 데이터 사본이 필요 없게 만드는 방식이다. 본질적으로 비동기적이다: 가장 뜨거운 데이터는 시스템 A에만 있고, 나머지 더 차가운 데이터는 시스템 B에 저장되지만 시스템 A에도 제공된다(시스템 A의 콜드 계층이므로).
물론 LTAP는 잠재적으로 가설적 범주인 Shared-Sync-RR 쪽으로 이동할 수 있다. 두 시스템이 같은 플랫폼 안에 존재한다면, 그러면 다시 모호해진다. 하나의 플랫폼이기 때문에 HTAP(하이브리드) 쪽으로 기울게 된다.
통합 OLTP-OLAP 시스템의 마케팅 자료가 흔히 얼버무리는 한 가지는 각각에서 사용되는 서로 다른 데이터 모델이다. 예를 들어 OLTP에서 흔한 Third Normal Form(3NF)과 분석에서 흔한 Kimball(스타 및 스노우플레이크 스키마) 같은 것들이다. 이는 쿼리 엔진, 스토리지 레이아웃, 스토리지 기반층 위에 또 하나의 차원을 더한다. OLTP에는 3NF를, 분석에는 Kimball을 원한다면, 아마도 구체화가 될 가능성이 높다(스타 스키마는 3NF의 콜드 계층으로는 적합하지 않기 때문이다).
이 넓은 분류 체계에 대해 어떻게 생각하는가? 소셜 미디어에서 찾아와 달라 :)
UPDATES:
추신, 데이터 사본에 대한 몇 가지 생각…
공유 계층화에서는 데이터 사본 문제를 하나의 조절 장치처럼 생각할 수 있다:
이를 전혀 사본이 없는 쪽으로 돌리면, 데이터가 계층화되자마자 즉시 제거하는 것을 뜻한다. 스토리지 비용은 낮아지지만, 성능을 위해 핫 데이터를 조금 더 오래 유지하는 편이 좋을 수도 있다.
이를 데이터 중첩이 많은 쪽으로 돌리면, 시스템 B로는 공격적으로 계층화하면서도 더 나은 성능 특성을 위해 시스템 A에 데이터를 유지하는 것을 뜻하며, 그만큼 추가 스토리지 비용이 든다. 그리고 기술적으로는 이제 캐시된 데이터로 간주될 것이므로, 이를 어떻게 정의하느냐에 따라 데이터 사본으로 보지 않을 수도 있다.
하지만 데이터 사본 문제는 구체화에서도 모호하다. 두 개(또는 그 이상)의 독립적인 시스템이 있으므로, 각 시스템은 잠재적으로 독립적인 데이터 만료 정책을 사용할 수 있다. 예를 들어 Kafka에서는 7일을 저장하지만, 레이크하우스에서는 7년을 저장할 수 있다. 그런 경우 이론적으로는 두 사본 시스템이지만, 전체 중복 비율은 0.0027%에 불과하다.
나는 일반적으로 “제로 카피”나 “원 카피” 같은 표현을 좋아하지 않는다. 너무 마케팅스럽다. 데이터 시스템을 구축할 때 사본이 몇 개냐에 초점을 맞추는 것을 주요 설계 기준으로 삼는 것은 그저 이상하다. 현실 세계는 훨씬 더 미묘하다.
