StarRocks 4.1: shared-data 클러스터의 tablet 자동 분할과 운영자가 확인해야 할 것

왜 이 릴리스를 봐야 하나

2026년 4~5월 공개된 StarRocks 4.1은 단순한 기능 추가 릴리스가 아니다. 핵심은 shared-data 모드에서 데이터가 커지면 생기는 구조적 문제를 자동화로 해결하려는 시도다.

shared-data(스토리지-컴퓨트 분리) 클러스터에서 가장 빈번하게 보고된 운영 문제는 두 가지였다.

1. Tablet이 한쪽에만 몰리는 데이터 스큐: 초기 설정한 hash 분산이 시간이 지나면서 특정 tablet에 데이터가 집중됐다. 쿼리 응답이 느려지고 특정 CN(Compute Node)에 부하가 몰렸다.
2. Tablet 수가 고정되어 스키마 변경이 느렸다: 수천 개의 tablet과 파티션이 있는 테이블에서 컬럼 추가 한 번이 수십 초, 경우에 따라 수 분이 걸렸다.

4.1은 두 문제를 직접 건드렸다. 무엇이 바뀌었는지보다, 왜 이 구조가 필요했는지부터 보자.

shared-data 아키텍처 복습

StarRocks shared-data는 3.1에서 도입됐다. 기존 shared-nothing과 비교하면 역할 분리가 명확하다.

CN은 상태를 갖지 않는다. 쿼리가 들어오면 오브젝트 스토리지에서 읽거나 로컬 캐시에서 응답한다. CN을 추가해도 데이터 재분배가 없기 때문에 스케일링이 빠르다.

하지만 Tablet은 초기 설계 시 정해진 분산 방식(hash, range)을 따라간다. 데이터가 균등하게 들어오지 않으면 일부 Tablet만 커지고, 그 Tablet을 담당하는 CN이 병목이 된다.

Tablet 자동 분할: 동작 방식

Tablet 자동 분할: 설정과 운영 주의점

Tablet 자동 분할은 shared-data 클러스터에서만 작동한다. Shared-nothing(로컬 BE) 클러스터는 대상이 아니다.

분할 트리거는 크기 기반이다. tablet이 tablet_reshard_target_size(기본 10 GB)를 초과하면 FE가 분할 작업을 스케줄한다. 분할 단위는 sort key 범위로 결정되기 때문에 쿼리 정확성은 보장된다. SQL을 바꾸거나 애플리케이션을 재시작할 필요가 없다.

-- shared-data 테이블 생성 시 sort key 지정이 중요
CREATE TABLE events (
    ts DATETIME,
    user_id BIGINT,
    event_type VARCHAR(64),
    payload JSON
)
PRIMARY KEY(ts, user_id)
DISTRIBUTED BY HASH(user_id) BUCKETS 16
ORDER BY (ts, user_id)          -- sort key가 분할 기준이 된다
PROPERTIES ("storage_volume" = "my_s3_volume");

주의: 분할 중 쿼리는 계속 동작한다. 분할은 백그라운드에서 진행되며 쿼리에 영향을 주지 않는다. 단, 분할 중 CN 메모리 사용이 증가할 수 있어 리소스가 부족한 환경에서는 tablet_reshard_target_size를 크게 잡아 분할 빈도를 낮추는 것이 안전하다.

tablet merge(병합)는 4.1에서 실험적으로 포함됐고 기본값은 false다. 활성화하면 작아진 tablet을 자동 병합한다. 대용량 삭제가 많은 워크로드에서 유용하지만, 4.1 기준으로는 프로덕션에서 기본값을 유지하는 것을 권장한다.

Fast Schema Evolution v2: DDL이 초 단위로 바뀌는 이유

Schema Evolution v1(StarRocks 3.2 도입)도 shared-nothing에서는 빠른 DDL을 제공했다. 하지만 shared-data에서는 tablet 메타데이터를 물리적으로 재작성해야 했기 때문에 tablet 수 × partition 수에 비례해 시간이 늘어났다.

v2에서 변경된 핵심은 스키마 메타데이터를 tablet 단위에서 테이블 단위로 올린 것이다. DDL이 실행되면 테이블 수준 메타데이터 하나만 업데이트하고, 각 tablet은 다음 접근 시 새 스키마를 lazy하게 적용한다. tablet이 1개든 10,000개든 DDL 자체는 수초 안에 끝난다.

-- v2에서 이 DDL은 tablet 수에 무관하게 수초 완료
ALTER TABLE events ADD COLUMN region VARCHAR(32) DEFAULT 'unknown';

-- 적용 확인
SHOW ALTER TABLE COLUMN WHERE TableName = 'events';
-- State가 FINISHED로 바뀌면 완료

v2가 적용되는 DDL은 ADD COLUMN, DROP COLUMN, MODIFY COLUMN(일부 타입 변환)이다. Primary Key 테이블만 지원하며, Duplicate Key·Aggregate Key 테이블에는 v1이 그대로 적용된다.

Cache 관측성: 운영 공백을 메운 기능

shared-data 클러스터에서 성능 문제가 생기면 가장 먼저 확인해야 할 것은 캐시 히트율이다. 4.1 이전에는 이 정보를 쿼리 단위로 얻을 방법이 없었다.

4.1에서 추가된 관측성은 세 층에서 작동한다.

Audit Log (쿼리 수준)

쿼리가 끝나면 audit log에 캐시 히트율이 기록된다. 특정 쿼리가 항상 오브젝트 스토리지를 읽는다면, 해당 쿼리의 접근 패턴이 캐시 설계와 맞지 않는다는 신호다.

Prometheus BE 메트릭 (클러스터 수준)

각 CN이 starrocks_be_data_cache_* 메트릭을 노출한다. Grafana로 클러스터 전체 캐시 히트율 추이를 시각화할 수 있다. 히트율이 떨어지는 시점과 쿼리 지연 상승이 겹치면 캐시 용량 부족이 원인일 가능성이 높다.

SQL Profile I/O 카운터 (플랜 노드 수준)

EXPLAIN ANALYZE 또는 쿼리 프로파일에서 각 플랜 노드가 캐시에서 읽은 바이트와 오브젝트 스토리지에서 읽은 바이트를 구분해 볼 수 있다. 어느 테이블, 어느 스캔 단계에서 캐시 미스가 집중되는지 확인할 수 있다.

추가 기능: 운영자가 주목할 나머지 변화

Inverted Index on Shared-Data (Beta)

이전까지 inverted index는 shared-nothing 클러스터에서만 가능했다. 4.1에서 shared-data에서도 builtin 파서 기반의 inverted index를 생성할 수 있다. 로그 검색, 텍스트 필터링 워크로드에 특히 유용하다. Beta이므로 프로덕션에 적용 전 테스트 환경에서 충분히 검증이 필요하다.

Skew Join v2

통계 기반의 데이터 스큐 감지가 추가됐다. 이전 skew hint는 사용자가 직접 명시해야 했지만, v2에서는 히스토그램 통계를 보고 자동으로 skewed 분산을 감지한다. NULL 값이 특정 파티션에 집중되는 NULL-skew도 처리한다.

창함수(Window Function)에서도 파티션 키가 스큐일 경우 자동으로 UNION으로 최적화된다.

Recursive CTE

WITH RECURSIVE를 사용한 계층 탐색 쿼리를 공식 지원한다.

WITH RECURSIVE category_tree AS (
    SELECT id, name, parent_id, 0 AS depth
    FROM categories
    WHERE parent_id IS NULL
    UNION ALL
    SELECT c.id, c.name, c.parent_id, ct.depth + 1
    FROM categories c
    JOIN category_tree ct ON c.parent_id = ct.id
)
SELECT * FROM category_tree ORDER BY depth, id;

그래프 순회, BOM(Bill of Materials) 전개, 조직도 쿼리 등에 활용할 수 있다.

Java UDF 타입 확장

Java UDF/UDAF/UDTF가 이제 STRUCT, 중첩 ARRAY/MAP, DATE/DATETIME, DECIMAL, 가변인자(varargs)를 지원한다. 이전에는 타입 제약으로 Java UDF 적용 범위가 좁았다.

운영자가 확인할 체크리스트

업그레이드 전

• [ ] shared-data 클러스터인지 shared-nothing인지 확인한다. Tablet 자동 분할과 Fast Schema Evolution v2는 shared-data 전용이다.
• [ ] Primary Key 테이블에서 빠른 DDL이 필요한 경우 Fast Schema Evolution v2가 자동으로 활성화된다. v1 동작에 의존하는 코드가 있으면 확인한다.
• [ ] inverted index on shared-data는 Beta다. 프로덕션 적용 전 테스트 환경에서 쿼리 플랜이 예상대로 index를 사용하는지 검증한다.

성능 개선 확인 기준

tablet_reshard_target_size 설정 가이드

이 릴리스를 한 문장으로

StarRocks 4.1은 shared-data 클러스터의 "설계 때 내린 결정이 운영을 제한한다"는 문제를 해결하는 릴리스다. Tablet 자동 분할로 데이터 성장에 따라 구조가 적응하고, Fast Schema Evolution v2로 스키마 수정이 즉각 반영되며, Cache 관측성으로 성능 병목의 원인을 쿼리 단위까지 추적할 수 있게 됐다.

References

• StarRocks 4.1: Built for Production, Designed to Simplify (StarRocks Blog): https://www.starrocks.io/blog/starrocks-4.1-now-available-built-for-production-designed-to-simplify
• StarRocks 4.1: When Your Table Design Outlives Its Assumptions (StarRocks Blog): https://www.starrocks.io/blog/starrocks-4.1-when-your-table-design-outlives-its-assumptions
• StarRocks version 4.1 Release Notes: https://docs.starrocks.io/releasenotes/release-4.1/
• StarRocks Architecture Documentation: https://docs.starrocks.io/docs/introduction/Architecture/
• Separation of Storage and Compute (StarRocks Blog): https://www.starrocks.io/blog/separation-of-storage-and-compute-an-architecture-that-cuts-costs-and-enhances-efficiency
• Data Cache Observability (StarRocks Docs): https://docs.starrocks.io/docs/data_source/data_cache_observe/
• Feature Support: Shared-data Clusters: https://docs.starrocks.io/docs/deployment/shared_data/feature-support-shared-data/
• StarRocks Roadmap 2026 (GitHub Issue #67632): https://github.com/StarRocks/starrocks/issues/67632
• Inside StarRocks: Deep Dive from Ingestion to Query Execution (Medium, Jun 2026): https://medium.com/@ashkangoleh/inside-starrocks-a-deep-dive-from-data-ingestion-to-distributed-query-execution-3dc646145024