@Rocky 지금 갑자기 데이터 캐시가 확. 줄어들었다가 늘어나고, 스캔 rate가 확 튀어버리거든?? 이게 프레디킷/ 파티션 프루닝 부족이라는데, 무슨의미야

이 현상은 쿼리가 조건절(

WHERE

)을 통해 읽지 않아도 될 데이터를 걸러내지 못해, *전체 데이터를 무식하게 다 읽으면서 발생하는 전형적인 성능 저하 패턴*입니다. 1. 용어의 의미 (무엇이 부족하다는 건가?) * 파티션 프루닝 (Partition Pruning): StarRocks가 데이터를 파티션(예: 날짜별)으로 나누어 저장했을 때, 쿼리 조건에 파티션 컬럼이 있으면 *해당하는 날짜의 파일만 골라서 읽는 기능*입니다. 이게 안 되면 1년치 데이터 중 오늘치만 보고 싶은데 1년치를 다 읽게 됩니다. * 프레디킷 푸시다운/프루닝 (Predicate Pruning/Pushdown): 데이터를 읽을 때, 저장소 수준에서 인덱스(Min/Max, Bloom Filter 등)를 활용해 *조건에 맞지 않는 데이터 블록을 아예 스킵*하는 기능입니다. 이게 안 되면 파일 내부의 모든 로우(Row)를 다 뒤져야 합니다. 2. 왜 이런 증상이 나타나나? (메커니즘) "프루닝 부족"이 발생하면 다음과 같은 연쇄 반응이 일어납니다. 1. 스캔 레이트(Scan Rate) 폭증: * 원래는 프루닝을 통해 1GB만 읽으면 될 쿼리가, 프루닝 실패로 100GB를 읽게 됩니다. 당연히 초당 읽는 데이터 양(Scan Rate)이 확 튀어버립니다. 2. 데이터 캐시(Data Cache) 요동 (확 줄었다가 늘어나는 이유): * 감소 (Eviction): StarRocks의 Data Cache(Block Cache)는 한정된 공간입니다. 프루닝되지 않은 대량의 "새로운(하지만 불필요한)" 데이터가 쏟아져 들어오면, 기존에 들어있던 "자주 쓰던 알짜배기 데이터"들이 캐시에서 쫓겨납니다(Eviction). 이때 캐시 효율이나 유효 데이터 비중이 급감하는 것처럼 보일 수 있습니다. * 증가 (Population): 쫓아낸 빈자리에 방금 스캔한 엄청난 양의 데이터가 캐시를 다시 가득 채우기 시작합니다. 그래서 다시 캐시 점유율이 올라갑니다. 하지만 이 데이터들은 일회성일 가능성이 높아 다음 쿼리 때 또 다른 데이터를 쫓아내는 악순환을 만듭니다. 3. 어떻게 확인하고 해결하나? * 실행 계획 확인 (

EXPLAIN

): * 쿼리 앞에 `EXPLAIN`을 붙여서 실행해 보세요. *

OlapScanNode

부분에서

partitions=

항목에 전체 파티션 개수가 잡혀있다면 *파티션 프루닝 실패*입니다. (예: `partitions=1/500`이어야 하는데 `500/500`인 경우) *

PREDICATES:

항목에 인덱스가 제대로 걸려있는지 확인하세요. * 흔한 실수: * 파티션 컬럼을 가공해서 조건절에 넣는 경우:

WHERE DATE_FORMAT(dt, '%Y%m%d') = '20231027'

(프루닝 안 됨) -> `WHERE dt = '2023-10-27'`로 변경해야 함. * 파티션 컬럼이 아닌 컬럼으로만 필터링하는 경우. 요약하자면: 현재 쿼리가 인덱스나 파티션을 타지 못하고 *풀 스캔(Full Scan)*을 때리고 있어서, 멀쩡하던 캐시가 오염되고 시스템 부하가 치솟고 있는 상황입니다. 쿼리의

WHERE

절과 테이블의 파티션 설정을 매칭시키는 작업이 필요합니다. References • using_starrocks/caching/block_cache.md • data_source/data_cache_troubleshooting.md • data_source/data_cache.md

@Rocky explain하면 너가 말한거 안나와, 내가 지금 조회하는 쿼리가 iceberg로 조회하는건데 어떻게 분석해??

Iceberg 테이블을 조회할 때 발생하는 이 증상은 *"원격 저장소(S3/HDFS 등)의 데이터가 필터링 없이 대량으로 로컬 캐시로 쏟아져 들어오면서 생기는 현상"*입니다. Iceberg는 내장 테이블(

OlapScanNode

)과 실행 계획 형식이 다르기 때문에, 분석하는 방법도 다릅니다. 아래 순서대로 확인해 보세요. 1. `EXPLAIN VERBOSE`로 프레디킷 확인 Iceberg 쿼리 시에는

OlapScanNode

대신

IcebergScanNode

또는 *`ConnectorScanNode`*를 찾아야 합니다.

sql
EXPLAIN VERBOSE SELECT ... FROM iceberg_table WHERE ...;

*

partition_predicates

: 여기에 조건이 들어가 있어야 파티션 프루닝이 된 것입니다. 비어있다면 파티션을 전혀 못 깎고 전체 폴더를 다 뒤지는 중입니다. *

non_partition_predicates

: 파티션은 아니지만 파일 내에서 데이터를 거르기 위해 푸시다운된 조건입니다. *

dataCacheOptions={populate: true}

: 이 값이 `true`여야 데이터를 읽으면서 캐시에 쌓습니다. 지금처럼 캐시가 출렁인다면 이 작업이 대규모로 일어나고 있다는 뜻입니다. 2. `EXPLAIN ANALYZE`로 실제 스캔량 확인 (가장 확실함) 실행 계획만으로는 부족하고, 실제로 얼마나 읽었는지 봐야 합니다.

sql
EXPLAIN ANALYZE SELECT ... FROM iceberg_table WHERE ...;

결과에서 아래 지표들을 확인하세요: *

ScanRanges

: 생성된 파일 읽기 작업의 개수입니다. 이 숫자가 수만 개라면 프루닝이 실패한 것입니다. *

RowsRead

vs

RowsReturned

: `RowsRead`(읽은 로우)는 1억 개인데 `RowsReturned`(최종 결과)가 100개라면, 쓸데없는 데이터를 엄청나게 읽어서 버리고 있는 상황입니다. *

DataCacheWriteBytes

: 이 수치가 높다면, 프루닝 실패로 읽어들인 엄청난 양의 S3 데이터가 로컬 디스크 캐시를 덮어쓰고(Evict) 새로 기록하느라 바쁜 상태라는 증거입니다. 3. Iceberg에서 왜 프루닝이 안 될까? (체크리스트) 1. 파티션 컬럼 불일치: Iceberg 테이블이 실제로 해당 컬럼으로 파티셔닝 되어 있는지 확인하세요. (`DESCRIBE iceberg_table`로 확인 불가 시 소스 메타데이터 확인) 2. 컬럼 가공:

WHERE DATE(ts) = '2023-10-27'

처럼 컬럼을 함수로 감싸면 Iceberg의 히든 파티셔닝(Hidden Partitioning)이 작동하지 않을 수 있습니다.

WHERE ts >= '2023-10-27 00:00:00'

식의 원본 컬럼 조건을 권장합니다. 3. 메타데이터 캐시 만료: StarRocks가 Iceberg의

manifest

파일을 읽어와야 어디를 깎을지 결정하는데, 메타데이터 동기화가 늦거나 캐시 설정이 꼬이면 프루닝을 포기하고 다 읽을 수 있습니다. 요약하자면 현재 현상은 *"잘못된 조건절이나 파티션 설계 때문에 쿼리가 S3에 있는 수만 개의 Parquet 파일을 통째로 긁어오고 있고, 그 데이터가 BE 노드의 로컬 캐시를 밀어내며(Drop) 새로 채우는(Increase) 과정에서 Scan Rate가 폭발하는 것"*입니다. `EXPLAIN ANALYZE`를 통해 실제

RowsRead

수치를 먼저 확인해 보시기 바랍니다. References • data_source/data_cache_troubleshooting.md • unloading/Spark_connector.md • best_practices/query_tuning/query_planning.md • data_source/catalog/iceberg/iceberg_catalog.md • best_practices/query_tuning/query_profile_text_based_analysis.md • using_starrocks/caching/block_cache.md References • using_starrocks/caching/block_cache.md • data_source/data_cache_troubleshooting.md • data_source/catalog/iceberg/iceberg_catalog.md

@Rocky 쿼리 분석을 위해 explain analyze를 했는데, Total time은 26초이고, Scan에 16초, 네트워크 5초, 스케줄 타임 9초 각각 177%, 58%, 99.98% 이렇게인데 뭘 튜닝해야해?

EXPLAIN ANALYZE

결과를 보면 현재 쿼리의 병목 지점이 명확히 보입니다. 특히 *Schedule Time(9초)*과 *Scan Time(16초)*이 핵심입니다. (백분율이 100%를 넘는 이유는 여러 CPU 코어가 동시에 일을 했기 때문이며, 이는 정상입니다.) 분석 결과에 따른 튜닝 포인트는 다음과 같습니다. *1. Schedule Time (9초, 99.98%) - 가장 심각한 병목* 이 수치가 높다는 것은 CPU가 일을 하기 전에 *"대기하는 시간"*이 너무 길었다는 뜻입니다. Iceberg 조회 시 주로 다음 원인 때문입니다. * 너무 많은 작은 파일 (Small Files): Iceberg 테이블에 아주 작은 Parquet 파일이 수만 개 있다면, StarRocks가 이를 처리하기 위해 수많은 태스크를 생성하고 스케줄링하는 데 시간이 다 소비됩니다. * 해결책: Iceberg 테이블의 파일을 컴팩션(Compaction)하여 파일 크기를 키워야 합니다 (권장 128MB~512MB). * I/O 쓰레드 부족: 대량의 파일을 S3에서 읽어오느라 스케줄러가 꽉 찼을 수 있습니다. * 해결책: BE 설정에서

pipeline_exec_thread_pool_thread_num

등을 점검해야 하지만, 근본적으로는 읽는 파일 개수를 줄여야 합니다. *2. Scan Time (16초, 177%) - I/O 부하* 전체 시간 중 가장 큰 비중을 차지합니다. 177%라는 것은 여러 쓰레드가 붙어서 열심히 읽었지만 여전히 16초나 걸렸다는 뜻입니다. * Data Cache 미활용: 이전에 말씀하신 "캐시가 줄었다 늘었다 하는 현상"과 직결됩니다. 캐시에 데이터가 없어서 매번 S3(원격)에서 가져오느라 시간이 오래 걸리는 것입니다. * 프레디킷 푸시다운 실패:

Scan

단계에서 `RowsRead`와 `RowsReturned`를 확인해 보세요. 만약 `RowsRead`가 훨씬 크다면, 필요 없는 데이터를 S3에서 일단 다 긁어오고 있다는 증거입니다. * 해결책: 쿼리 조건절에 파티션 컬럼이 제대로 포함되었는지, 그리고 그 조건이 Iceberg 메타데이터 수준에서 필터링되고 있는지 확인하세요. *3. Network Time (5초, 58%) - 데이터 전송* 노드 간 데이터 셔플링(Shuffle)이나 결과 전송 시간입니다. 26초 중 5초면 아주 치명적이진 않지만, 조인(Join) 방식이 `Broadcast`인지 `Shuffle`인지에 따라 최적화 여지가 있습니다. ────────── 결론: 무엇을 가장 먼저 해야 할까? 지금 가장 시급한 것은 *"읽어야 할 파일의 개수와 데이터 양을 줄이는 것"*입니다. 1. Iceberg 메타데이터 캐싱 강화: * StarRocks에서 Iceberg 메타데이터(Manifest 파일 등)를 캐싱하도록 설정되어 있는지 확인하세요. 메타데이터를 빨리 읽어야 파티션 프루닝도 빨리 끝납니다. 2. 파일 개수 줄이기 (Compaction): * Iceberg 쪽에서 파일들을 병합(Rewrite Data Files)하세요. Schedule Time 9초는 파일 개수가 너무 많을 때 나타나는 전형적인 증상입니다. 3. Data Cache 히트율 높이기: * 캐시가 요동치는 것은 대량 스캔 때문입니다. 파티션 프루닝이 작동하게 쿼리를 수정하면 스캔량이 줄어들고, 자연스럽게 캐시 적중률이 올라가며 Scan Time이 단축됩니다. 요약: 9초나 되는 대기 시간(Schedule Time)은 *작은 파일이 너무 많거나 메타데이터 처리가 늦기 때문*일 가능성이 90% 이상입니다. Iceberg 테이블의 파일 레이아웃을 먼저 점검해 보시기 바랍니다. References • data_source/data_cache_troubleshooting.md • best_practices/query_tuning/query_profile_text_based_analysis.md • data_source/catalog/iceberg/iceberg_catalog.md • using_starrocks/caching/block_cache.md • best_practices/query_tuning/query_planning.md

@Rocky explain verbose 하면, result-data-files가 37070개, result-delete-files 가 140881개 나와 이거에 대해 분석해주고 그 다음으로 파티션 프루닝이 작동하게 쿼리를 수정하려면 어떻게 수정해야하는지도 같이 알려줘

EXPLAIN VERBOSE

결과에 나타난 수치는 현재 시스템이 왜 느리고 캐시가 요동치는지에 대한 *"결정적 증거"*입니다. 1. 파일 개수 분석: "파일 개수가 비정상적으로 많습니다" * Result Data Files (37,070개): 단일 쿼리가 읽어야 할 데이터 파일이 3만 개를 넘습니다. StarRocks가 각 파일을 열고 메타데이터를 읽고 스케줄링하는 데만 수 초(질문하신 9초의 스케줄링 타임)가 걸리는 이유입니다. * Result Delete Files (140,881개): 이게 가장 심각한 문제입니다. 데이터 파일보다 삭제 파일(Delete File)이 4배나 많습니다. * Iceberg의 Merge-on-Read(MoR) 방식에서는 데이터를 읽을 때마다 "이 데이터가 삭제된 건가?"를 확인하기 위해 데이터 파일과 삭제 파일을 대조(Merge)해야 합니다. * 3.7만 개의 파일을 읽으면서 14만 개의 삭제 파일을 실시간으로 비교하고 있으니 CPU와 메모리 부하가 극심할 수밖에 없습니다. * 이 대량의 삭제 파일들이 캐시에 로드되면서 기존 캐시 데이터를 다 밀어내고 있는 상황입니다. 결론: 이 테이블은 현재 *컴팩션(Compaction)이 절실한 상태*입니다. Iceberg 레벨에서 `REWRITE DATA FILES`와

REWRITE DELETE FILES

작업을 수행하여 작은 파일들을 합치고 삭제 기록을 실제 데이터에 반영(Merge)해야 합니다. ────────── 2. 파티션 프루닝이 작동하게 쿼리를 수정하는 방법 파티션 프루닝이 안 되는 이유는 대개 *"StarRocks가 조건절을 파티션 키와 대조하지 못하기 때문"*입니다. 아래 규칙을 확인하세요. ① 파티션 컬럼 확인 먼저 어떤 컬럼이 파티션인지 정확히 알아야 합니다.

sql
DESCRIBE iceberg_catalog.db_name.table_name;
-- 또는 외부 카탈로그 설정 확인

Partition

항목에 있는 컬럼을

WHERE

절에 반드시 포함해야 합니다. ② 컬럼 가공 금지 (가장 흔한 실수) 파티션 컬럼이 `event_time`인데, 여기에 함수를 씌우면 프루닝이 깨집니다. * 나쁜 예:

WHERE DATE_FORMAT(event_time, '%Y-%m-%d') = '2023-10-27'

* 좋은 예:

WHERE event_time >= '2023-10-27 00:00:00' AND event_time < '2023-10-28 00:00:00'

③ 데이터 타입 일치 파티션 컬럼이 숫자형인데 문자열로 비교하거나, 그 반대의 경우 프루닝이 무시될 수 있습니다. * 나쁜 예:

WHERE string_partition_key = 20231027

* 좋은 예:

WHERE string_partition_key = '20231027'

④ 히든 파티셔닝(Hidden Partitioning) 대응 Iceberg는

days(timestamp_col)

같은 히든 파티셔닝을 지원합니다. 만약 Iceberg 테이블이 이렇게 설정되어 있다면, StarRocks에서도 가급적 *원본 컬럼에 대한 범위 조건*을 주면 Iceberg 엔진이 알아서 파티션을 계산해 깎아냅니다. ────────── 3. 현재 상황 해결을 위한 액션 플랜 1. 긴급 조치: 쿼리에 파티션 컬럼(예:

y

,

m

,

d

등)이 누락되었다면 반드시 추가하세요. `EXPLAIN VERBOSE`의

partition_predicates

항목에 조건이 나타나야 합니다. 2. 근본 해결 (Iceberg 사이드): Iceberg 테이블 관리자에게 연락하여 *Expire Snapshots*와 *Rewrite Files (Compaction)*를 요청하세요. 14만 개의 삭제 파일은 시스템 운영에 치명적입니다. 3. 임시 성능 향상: 만약 특정 파티션만 자주 본다면, StarRocks의 *Materialized View*를 Iceberg 테이블 위에 생성하여 StarRocks 로컬 저장소로 데이터를 일부 가져오면 성능이 수십 배 빨라질 수 있습니다. 지금의

EXPLAIN

결과는 *"정리되지 않은 수많은 작은 파일과 삭제 기록 때문에 시스템이 비명을 지르고 있다"*는 뜻으로 이해하시면 됩니다.