RonJay
08/06/2026, 1:55 AMRocky
08/06/2026, 1:55 AMcn.conf file. There are two main aspects: where the data is stored and when spilling is triggered.
1. Storage Directory
You must specify one or more directories to store the intermediate spilled data. If this is not set, spilling will not work even if enabled in the session.
* Parameter: spill_local_storage_dir
* Default: (Empty)
* Usage: Specify one or more paths separated by semicolons.
properties
spill_local_storage_dir=/data1/spill;/data2/spill
* Alternative: query_scratch_dirs is also used in some versions to define writable scratch directories for operators like external sort and hash join.
2. Memory Trigger Threshold
You can control the threshold at which the CN begins spilling data to disk to avoid Out of Memory (OOM) errors.
* Parameter: query_pool_spill_mem_limit_threshold (Available since v3.2.7)
* Default: 1.0 (100% of the query pool memory)
* Description: When total memory usage of all queries exceeds query_pool_limit * threshold, automatic spilling is triggered. Setting this lower (e.g., 0.8) makes spilling start sooner.
3. Disk Size Limits
* Per-Query Limit: Currently, StarRocks does not support a configuration to limit the amount of disk space a single query can consume for spilling. All queries share the space available in spill_local_storage_dir.
* Kubernetes (Operator): If you are using the StarRocks Kubernetes Operator, you can define the spill storage size in your StarRocksCluster YAML or Helm `values.yaml`:
yaml
cn:
spillStorageSize: 100Gi # Sets the PVC size for spilling
4. Important Session Variables
After configuring cn.conf, you must also enable the feature at the session or global level via SQL:
sql
-- Enable spilling
SET GLOBAL enable_spill = true;
-- Set mode to auto (spill when memory is tight) or force (always spill)
SET GLOBAL spill_mode = 'auto';
Note: It is highly recommended to use a dedicated disk for spill_local_storage_dir that is separate from your data storage (storage_root_path) to prevent spill I/O from impacting overall performance.
I/O from impacting standard query latency from impacting from regular operations from from from from impacting from normal I/O performance during peak. from from impacting regular data from from impacting regular data from from from impacting regular data I/O.
References
• administration/management/BE_configuration.md
• administration/management/resource_management/spill_to_disk.mdRonJay
08/06/2026, 3:01 AMRocky
08/06/2026, 3:01 AMUnknown database 에러가 발생하는 현상은 대소문자 구분 설정(Case Sensitivity) 또는 *v4.0부터 도입된 신규 기능의 호환성 문제*일 가능성이 매우 높습니다.
다음 단계에 따라 설정을 확인하고 해결해 보시기 바랍니다.
1. enable_table_name_case_insensitive 설정 확인 (가장 유력)
StarRocks 4.0부터 `enable_table_name_case_insensitive`라는 FE 설정이 추가되었습니다. 이 설정이 `true`로 되어 있는지 확인하십시오.
* 원인: 이 옵션이 `true`이면 StarRocks는 모든 객체 이름을 소문자로 강제 변환하여 저장 및 처리합니다. 하지만 공식 문서에 따르면 이 기능은 JDBC Catalog를 지원하지 않으며, 활성 시 외부 카탈로그를 사용 불가능하게 만들 수 있다고 명시되어 있습니다 (Oracle은 내부적으로 스키마/테이블명을 대문자로 관리함).
* 해결 방법: 해당 설정은 클러스터 생성 시에만 결정되며 중간에 변경이 불가능한 경우가 많습니다. 만약 업그레이드 과정에서 이 옵션을 켜서 클러스터를 재구성했다면, Oracle Catalog와의 호환성 문제가 발생할 수 있습니다. admin show config like '%case_insensitive%'; 명령어로 상태를 확인해 보세요.
2. 객체 이름의 대소문자 확인 (Oracle 특성)
Oracle은 기본적으로 스키마(사용자)와 테이블명을 *대문자(UPPERCASE)*로 저장합니다.
* 확인 방법: 먼저 다음 쿼리로 StarRocks가 Oracle에서 인식하고 있는 스키마 목록을 확인하세요.
sql
SHOW DATABASES FROM <oracle_catalog_name>;
* 해결 방법: 만약 목록에 `MY_SCHEMA`와 같이 대문자로 나온다면, 쿼리 시에도 대문자를 사용하거나 따옴표로 감싸서 시도해 보세요.
sql
SELECT * FROM <oracle_catalog_name>."MY_SCHEMA"."MY_TABLE";
3. schema_resolver 속성 명시
JDBC Catalog 생성 시 Oracle용 스키마 해석기가 정확히 동작하지 않을 수 있습니다. 카탈로그 생성 문에 아래 속성을 명시적으로 추가해 보시기 바랍니다.
sql
CREATE EXTERNAL CATALOG oracle_catalog
PROPERTIES (
"type" = "jdbc",
"user" = "...",
"password" = "...",
"jdbc_uri" = "jdbc:oracle:thin:@...",
"driver_class" = "oracle.jdbc.driver.OracleDriver",
"schema_resolver" = "oracle" -- 명시적으로 지정
);
4. v4.1.1 관련 알려진 이슈/버그 여부
StarRocks 4.1.1은 비교적 최신 버전이며, 4.1.0에서 발생한 컨테이너 환경의 안정성 이슈 등을 해결한 버전입니다. 하지만 메타데이터 캐싱 로직 변화로 인해 일시적으로 메타데이터를 불러오지 못하는 경우가 보고되기도 합니다.
* 임시 해결: FE를 재시작하거나, 카탈로그를 삭제 후 다시 생성하여 메타데이터를 갱신해 보십시오.
* 캐시 비활성화 테스트: jdbc_meta_default_cache_enable 설정이 영향을 주는지 확인하기 위해 세션에서 관련 캐시 설정을 끄고 테스트해 볼 수 있습니다.
결론적으로:
SHOW DATABASES FROM [카탈로그] 결과에 해당 스키마가 보이지 않는다면 JDBC 드라이버/권한/schema_resolver 문제이고, 보이지만 쿼리 시 `Unknown database`가 뜬다면 대소문자 불일치(Case sensitivity) 문제입니다. 특히 v4.0 이상의 enable_table_name_case_insensitive 설정을 가장 먼저 확인해 보시기 바랍니다.
참고 문서
• StarRocks v4.0/4.1 Release Notes
• JDBC Catalog Configuration
References
• administration/management/FE_configuration.md
• faq/Sql_faq.md
• administration/management/BE_configuration.md
• data_source/feature-support-data-lake-analytics.md
• data_source/catalog/jdbc_catalog.md
• data_source/datalake_faq.md
• sql-reference/System_variable.mdRonJay
08/06/2026, 7:46 AMRocky
08/06/2026, 7:46 AMquery_queue_v2_schedule_strategy)
FE 설정 파라미터인 `query_queue_v2_schedule_strategy`를 통해 정책을 선택할 수 있습니다.
* SWRR (Smooth Weighted Round Robin) - 기본값
* 여러 리소스 그룹 간에 자원을 공정하게 배분하는 방식입니다.
* 슬롯이 큰 쿼리: 특정 리소스 그룹이 요구하는 슬롯이 너무 크면, 전체 가용 슬롯이 확보될 때까지 대기해야 하므로 자연스럽게 작은 쿼리들보다 늦게 실행될 가능성이 높습니다.
* SJF (Short Job First + Aging)
* 작은 작업(슬롯을 적게 차지하는 쿼리)을 우선적으로 실행합니다.
* 슬롯이 큰 쿼리: 정책적으로 뒤로 밀립니다. 다만, 무한정 대기하는 것을 방지하기 위해 'Aging(노후화)' 메커니즘이 있어, 오래 대기한 큰 쿼리는 우선순위가 점차 높아집니다.
2. 왜 슬롯이 크면 나중에 동작하는 것처럼 보이나요?
정책과 상관없이 기술적으로 다음 두 가지 이유 때문에 큰 쿼리는 지연될 가능성이 큽니다.
1. 자원 확보 대기 (Resource Packing): 슬롯이 1개 필요한 쿼리는 빈 자리가 생기자마자 들어갈 수 있지만, 슬롯 100개가 필요한 쿼리는 시스템에 100개의 여유 슬롯이 한꺼번에 생길 때까지 대기해야 합니다.
2. 슬롯 추정: StarRocks는 쿼리의 예상 스캔 행 수나 CPU 비용을 바탕으로 슬롯 수를 계산합니다(query_queue_v2_cpu_costs_per_slot 등 활용). 무거운 쿼리일수록 많은 슬롯을 요구하게 설계되어 있습니다.
3. 관련 주요 설정 (FE Configuration)
대형 쿼리가 너무 오래 대기하거나 시스템을 독점하는 것을 조절하고 싶다면 다음 설정을 참고하십시오.
* query_queue_v2_schedule_strategy: `SJF`로 설정하면 짧은 쿼리 응답 속도는 빨라지지만 대형 쿼리는 더 늦게 실행됩니다.
* query_queue_v2_concurrency_level: 클러스터 전체의 총 슬롯 수를 결정합니다 (기본값 4). 이 값을 높이면 더 많은 쿼리가 동시 실행될 수 있습니다.
* query_queue_slots_estimator_strategy: 쿼리별 슬롯 할당량을 계산하는 방식(기본값 MAX)을 조절하여 대형 쿼리의 슬롯 요구량을 조정할 수 있습니다.
요약하자면:
슬롯이 큰 쿼리는 SJF 정책에서는 명시적으로 나중에 실행되며, *기본 정책(SWRR)에서도 필요한 자원(슬롯)이 많기 때문에 자리가 날 때까지 더 오래 대기*하게 됩니다.
References
• administration/management/FE_configuration.md
• administration/management/resource_management/query_queues.md
• sql-reference/System_variable.md
• administration/management/resource_management/resource_group.md
References
• administration/management/resource_management/query_queues.md
• administration/management/resource_management/resource_group.md
• faq/resource_isolation_faq.mdRonJay
08/11/2026, 7:42 AMRocky
08/11/2026, 7:42 AMroot 계정으로만 가능한 것은 아닙니다.
StarRocks v3.0 이상 버전부터는 *시스템 레벨의 CREATE EXTERNAL CATALOG 권한*이 있는 계정이라면 누구나 카탈로그를 생성할 수 있습니다.
권한 부여 방법
관리자(root 또는 db_admin 등) 계정에서 일반 사용자나 역할(Role)에게 다음과 같이 권한을 부여하면 됩니다.
1. 사용자에게 직접 부여:
sql
GRANT CREATE EXTERNAL CATALOG ON SYSTEM TO USER 'username'@'%';
2. 역할(Role)을 통해 부여:
sql
-- 역할 생성
CREATE ROLE catalog_admin;
-- 역할에 권한 부여
GRANT CREATE EXTERNAL CATALOG ON SYSTEM TO ROLE catalog_admin;
-- 사용자에게 역할 할당
GRANT 'catalog_admin' TO USER 'username'@'%';
요약
* v3.0 미만: 주로 관리자 계정에서 수행되었습니다.
* v3.0 이상: ON SYSTEM 단위의 CREATE EXTERNAL CATALOG 권한을 가진 사용자라면 생성 가능합니다.
* 생성된 카탈로그를 다른 사용자가 조회하거나 사용하게 하려면 별도의 USAGE 권한 부여가 필요합니다. (GRANT USAGE ON CATALOG <catalog_name> TO USER <user>;)
따라서 적절한 권한만 할당한다면 일반 운영 계정에서도 외부 카탈로그를 자유롭게 생성하고 관리할 수 있습니다.
References
• sql-reference/sql-statements/account-management/GRANT.md
• sql-reference/sql-statements/Catalog/CREATE_EXTERNAL_CATALOG.md
• administration/user_privs/authorization/privilege_item.md
References
• sql-reference/sql-statements/Catalog/CREATE_EXTERNAL_CATALOG.md
• sql-reference/sql-statements/account-management/GRANT.md
• administration/user_privs/authorization/privilege_item.mdRonJay
08/11/2026, 1:17 PMRocky
08/11/2026, 1:17 PMANALYZE TABLE <table_name> 명령을 실행하여 통계 정보를 수동으로 갱신해 주어야만 Query Queue v2와 Optimizer가 정상적으로 동작합니다.
References
• using_starrocks/Cost_based_optimizer.md
• administration/management/resource_management/query_queues.md
• administration/management/FE_configuration.md
• sql-reference/System_variable.md
References
• using_starrocks/Cost_based_optimizer.md
• administration/management/FE_configuration.md
• sql-reference/System_variable.md
• administration/management/resource_management/query_queues.md
• data_source/feature-support-data-lake-analytics.md
• administration/management/monitor_manage_big_queries.mdRonJay
08/11/2026, 1:20 PMRocky
08/11/2026, 1:21 PMANALYZE 작업 자체가 BE의 메모리를 점유하여 `Memory of process exceed limit`을 유발할 수 있습니다.
* 첫 쿼리의 폭주: `ANALYZE`는 백그라운드에서 돌기 때문에, *통계가 없는 상태에서 들어온 첫 번째 쿼리*는 여전히 1개의 슬롯만 할당받은 채 실행됩니다. 이때 쿼리가 분석 작업과 동시에 실행되면서 BE 메모리 한계를 넘기는 것입니다.
2. 끄면 안 되는 이유 (Query Queue v2와의 관계)
이 설정을 끄면 StarRocks는 Iceberg 테이블의 데이터 분포를 알 수 없습니다.
* 결과: 모든 쿼리의 Cost가 매우 낮게 측정됩니다.
* 슬롯 부족: Query Queue v2는 "이 쿼리는 가볍구나"라고 판단하여 *최소 슬롯(보통 1개)*만 할당하고 즉시 실행시킵니다.
* 실제 실행: 하지만 실제로는 수 테라바이트를 스캔하는 무거운 쿼리이므로, 할당된 자원보다 훨씬 많은 메모리를 사용하게 되고 결국 다시 OOM이 발생합니다.
3. 권장 해결 방법 (조정 가이드)
기능을 완전히 끄기보다는 *자원 점유를 제한*하거나 *수동으로 관리*하는 것이 정석입니다.
A. 분석 작업의 메모리 및 병렬도 제한 (FE 설정)
백그라운드 분석 작업이 메모리를 너무 많이 쓰지 않도록 제한합니다.
* `connector_table_query_trigger_analyze_max_running_task_num = 1`: 동시에 실행되는 분석 작업 수를 1개로 줄입니다 (기본값 2).
* `statistic_collect_mem_limit`: (시스템 변수) 통계 수집에 사용할 최대 메모리를 제한합니다.
B. 특정 컬럼만 수동 ANALYZE (가장 추천)
자동 트리거를 끄는 대신, 쿼리에 자주 사용되는 조인(Join) 컬럼이나 필터 컬럼만 수동으로 분석합니다. 이렇게 하면 분석 부하를 최소화하면서 정확한 슬롯 계산이 가능합니다.
sql
-- 자동 트리거를 끄고 싶다면 끈 후, 수동으로 실행
ANALYZE TABLE iceberg_catalog.db.table_name WITH SYNC MODE (col1, col2);
C. 슬롯 추정 방식 보정 (FE 설정)
통계가 없더라도 슬롯을 너무 작게 잡지 않도록 하려면 아래 파라미터를 조절하십시오.
* `query_queue_v2_cpu_costs_per_slot`: 이 값을 낮추면 동일한 쿼리라도 더 많은 슬롯을 할당받게 되어, 쿼리가 무거울 때 더 잘 대기하게 됩니다.
* `query_queue_v2_num_rows_per_slot`: 이 값을 낮추면 스캔할 행 수 대비 슬롯이 많이 할당됩니다.
D. Iceberg 메타데이터 캐시 메모리 조정
Shared-data 모드에서 Iceberg 메타데이터 로딩 시 메모리가 부족하다면 아래 설정을 확인하십시오.
* `iceberg_metadata_memory_cache_capacity`: FE에서 Iceberg 메타데이터를 캐싱하는 메모리 크기를 줄여 FE OOM을 방지합니다.
요약
`enable_query_trigger_analyze`를 끄면 *"통계 정보 부재 → 잘못된 슬롯 예측 → 잦은 OOM"*의 굴레에 빠지게 됩니다.
해결책: 기능을 끄기보다 `max_running_task_num`을 1로 낮춰 부하를 줄이거나, 주요 테이블에 대해 `ANALYZE`를 수동으로 한 번 수행하여 Query Queue가 정확한 비용을 계산할 수 있게 만드시는 것을 권장합니다.
References
• using_starrocks/Cost_based_optimizer.md
• administration/management/FE_configuration.md
• administration/management/resource_management/query_queues.md
• sql-reference/sql-statements/data-manipulation/ANALYZE_TABLE.md
References
• using_starrocks/Cost_based_optimizer.md
• administration/management/FE_configuration.md
• administration/management/resource_management/query_queues.md
• data_source/catalog/iceberg/iceberg_catalog.md
• sql-reference/System_variable.md
• data_source/feature-support-data-lake-analytics.md
• faq/resource_isolation_faq.md
• administration/management/monitoring/metrics.md
• faq/shared_data_faq.md
• knowledge/admin_and_operation/shared_data_compaction.mdRocky
08/11/2026, 1:21 PMRonJay
08/13/2026, 1:51 AMRocky
08/13/2026, 1:51 AMfe.audit.log 확인 (가장 빠름)
FE 노드의 로그 디렉토리에 있는 fe.audit.log 파일을 조회하는 방법입니다. 모든 쿼리의 상태와 Query ID, SQL문이 기록됩니다.
* 방법: 터미널에서 에러 상태(State=ERR)인 로그를 검색합니다.
bash
grep 'State=ERR' fe.audit.log
* 확인 가능 항목: queryId, startTime, state, errorCode, `stmt`(SQL문), errorMessage 등
2. AuditLoader 플러그인 사용 (추천)
AuditLoader를 설치하면 감사 로그(Audit Log)가 StarRocks 내부의 테이블에 자동으로 저장되어 SQL로 조회가 가능해집니다.
* 조회 쿼리:
sql
SELECT queryId, stmt, errorCode, errorMessage
FROM starrocks_audit_db*.starrocks_audit_tbl*
WHERE state = 'ERR'
ORDER BY timestamp DESC;
* 장점: Grafana 대시보드에서 에러 발생 시점을 확인한 후, 즉시 SQL로 상세 내용을 찾아볼 수 있어 운영에 매우 편리합니다.
3. Query Detail HTTP API 사용
API를 통해 최근 실행된 쿼리들의 상세 상태를 JSON 형태로 받아볼 수 있습니다.
* 엔드포인트: http://<FE_IP>:<FE_HTTP_PORT>/api/query_detail
* 응답 데이터: queryId, state, sql, errorMessage 등
4. 특정 작업의 경우 (Load, MV)
일반 쿼리가 아닌 적재(Load)나 구체화 뷰(MV) 새로고침 과정에서 발생한 에러라면 시스템 뷰를 통해 바로 확인 가능합니다.
* 적재 에러: SELECT * FROM information_schema.loads WHERE STATE = 'CANCELLED';
* MV 새로고침 에러: SELECT * FROM information_schema.task_runs WHERE STATE = 'FAILED';
요약하자면:
메트릭으로 에러 수치가 튀는 것을 인지하셨다면, *`fe.audit.log`를 검색*하시거나 *AuditLoader 테이블을 조회*하여 해당 시점의 구체적인 쿼리와 에러 메시지를 파악하셔야 합니다.
References
• administration/management/logs.md
• administration/management/audit_loader.md
• administration/management/monitoring/alert.md
• administration/http_interface/query_detail.md
• loading/loading_introduction/troubleshooting_loading.md
References
• administration/management/monitoring/alert.md
• administration/management/audit_loader.md
• administration/management/logs.md
• administration/http_interface/query_detail.md
• loading/loading_introduction/troubleshooting_loading.md
• using_starrocks/async_mv/troubleshooting_asynchronous_materialized_views.md
• administration/management/monitoring/metrics.md
• faq/Sql_faq.md
• best_practices/query_tuning/query_profile_operator_metrics.md
• faq/Dump_query.md
• administration/management/monitoring/alert.md
• administration/management/audit_loader.md
• administration/management/logs.md
• administration/http_interface/query_detail.md
• loading/loading_introduction/troubleshooting_loading.mdRocky
08/13/2026, 1:51 AMRonJay
08/18/2026, 5:03 AMRocky
08/18/2026, 5:03 AMSHOW PROC 권한을 부여하는 방법과 사용자 목록을 확인하는 방법은 다음과 같습니다.
1. 특정 사용자에게 SHOW PROC 활성화 (권한 부여)
SHOW PROC 명령어를 실행하려면 *SYSTEM 레벨의 OPERATE 권한*이 필요합니다.
* 권한 부여 방법:
sql
-- 특정 사용자에게 권한 부여
GRANT OPERATE ON SYSTEM TO USER 'username'@'%';
-- 또는 역할을 생성하여 권한 부여 후 사용자에게 할당 (권장)
CREATE ROLE proc_admin;
GRANT OPERATE ON SYSTEM TO ROLE proc_admin;
GRANT proc_admin TO USER 'username'@'%';
* 참고: 기본 제공 역할인 `cluster_admin`은 이 권한을 포함하고 있습니다. 시스템 노드 관리(추가/삭제)까지 포함된 더 높은 권한이 필요하다면 NODE 권한이 필요할 수 있으나, 일반적인 SHOW PROC 조회는 OPERATE 권한으로 가능합니다.
──────────
2. 사용자 목록 확인 방법
시스템에 등록된 전체 사용자 목록을 확인하려면 다음 명령어를 사용합니다. (v3.0 이상 기준)
* 전체 사용자 목록 조회:
sql
SHOW USERS;
* 인증 정보를 포함한 상세 목록 조회:
어떤 플러그인(LDAP 등)을 사용하는지, 비밀번호 설정 여부 등을 함께 보려면 다음 명령어를 사용합니다.
sql
SHOW ALL AUTHENTICATION;
* 사용자의 권한 정보 확인:
특정 사용자가 어떤 권한을 가지고 있는지 확인하려면:
sql
SHOW GRANTS FOR 'username'@'%';
주의사항: `SHOW USERS`나 타인의 권한을 조회하려면 user_admin 역할을 가진 계정(기본 root 등)으로 실행해야 합니다.
References
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROC.md
• sql-reference/sql-statements/account-management/SHOW_USERS.md
• administration/user_privs/authorization/privilege_item.md
• administration/user_privs/authorization/User_privilege.md
• administration/user_privs/authentication/native_authentication.md
• sql-reference/sql-statements/account-management/SHOW_AUTHENTICATION.md
• administration/user_privs/authorization/privilege_faq.md
References
• administration/user_privs/authentication/native_authentication.md
• administration/user_privs/authorization/privilege_faq.md
• sql-reference/sql-statements/account-management/SHOW_USERS.md
• administration/user_privs/authorization/User_privilege.md
• sql-reference/sql-statements/account-management/SHOW_AUTHENTICATION.md
• administration/user_privs/authorization/user_privs.mdRonJay
08/18/2026, 6:02 AMRocky
08/18/2026, 6:02 AMstarrocks_fe_tablet_num: 각 BE(Backend) 노드별로 할당된 태블릿 수를 나타냅니다.
* 용도: 전체 클러스터의 태블릿 총합을 구하거나, 특정 BE에 데이터가 쏠려 있는지(불균형) 확인할 때 사용합니다.
* PromQL 예시 (전체 태블릿 수): sum(starrocks_fe_tablet_num)
* be_tablet_count: BE 노드 자체에서 보고하는 현재 관리 중인 태블릿 수입니다.
2. SQL 명령어를 통한 확인 (실시간 조회용)
가장 정확하고 상세한 정보를 얻을 수 있는 방법입니다.
A. 데이터베이스별 태블릿 수 확인
클러스터 전체 혹은 DB별로 태블릿 분포 상태를 요약해서 보여줍니다.
sql
SHOW PROC '/statistic';
* 출력 항목: DbId, DbName, TableNum, PartitionNum, *`TabletNum`*(태블릿 수), `ReplicaNum`(복제본 포함 총 태블릿 수) 등을 한눈에 볼 수 있습니다.
B. BE 노드별 태블릿 분포 확인
어떤 서버에 태블릿이 많이 몰려 있는지 확인할 때 유용합니다.
sql
SHOW PROC '/backends';
* 출력 항목: TabletNum 컬럼에서 각 BE 노드가 현재 담당하고 있는 태블릿 개수를 확인할 수 있습니다.
C. 특정 테이블의 태블릿 수 확인
특정 테이블의 파티션별 상세 정보를 보고 싶을 때 사용합니다.
sql
SHOW PROC '/dbs/<db_id>/<table_id>/partitions';
또는 테이블 이름을 직접 명시하여 조회할 수 있습니다:
sql
SHOW TABLE STATUS LIKE 'table_name'; -- 기본적인 테이블 정보 확인
요약
* 대시보드 모니터링: starrocks_fe_tablet_num 메트릭 사용
* 전체 요약 조회: SHOW PROC '/statistic';
* 노드별 분산 상태 확인: SHOW PROC '/backends';
References
• administration/management/monitoring/metrics.md
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROC.md
• administration/management/monitoring/monitoring_and_alerting.md
References
• administration/management/monitoring/metrics.md
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROC.md
• administration/management/monitoring/monitoring_and_alerting.md
• faq/shared_data_faq.md
• best_practices/query_tuning/query_profile_operator_metrics.md
• administration/management/monitoring/alert.md
• sql-reference/sql-statements/data-manipulation/SHOW_TABLE_STATUS.md
• using_starrocks/table_design/data_distribution.md
• administration/management/monitor_manage_big_queries.md
References
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROC.mdRonJay
08/18/2026, 6:10 AMRocky
08/18/2026, 6:11 AMsql
-- 테이블별로 실행 (가장 권장되는 방식)
ANALYZE TABLE <table_name> WITH FULL SCAN;
-- 만약 특정 컬럼만 집중적으로 사용한다면 (선택 사항)
-- ANALYZE TABLE <table_name> (col1, col2, ...) WITH FULL SCAN;
* `WITH FULL SCAN`: 샘플링이 아닌 전체 데이터를 스캔하여 가장 정확한 통계치를 생성합니다. 테스트용 baseline을 만들 때 필수적입니다.
3. 통계 생성 상태 확인
ANALYZE 작업은 비동기로 진행될 수 있습니다. 10개 테이블에 대한 통계 수집이 모두 완료되었는지 확인한 후 테스트를 시작해야 합니다.
sql
-- 진행 상태 확인 (STATE가 FINISHED인지 확인)
SHOW ANALYZE STATUS ORDER BY StartTime DESC LIMIT 10;
4. Query Queue v2 관련 설정 확인
MBE 테스트를 위해 세션 또는 글로벌 설정이 제대로 되어 있는지 확인하세요.
sql
-- Query Queue v2 활성화 (기본값은 버전마다 다를 수 있음)
SET GLOBAL enable_query_queue_v2 = true;
-- (선택) 특정 리소스 그룹에 대해 테스트하고 싶다면 리소스 그룹 설정 확인
-- ALTER RESOURCE GROUP <group_name> WITH ('concurrency_limit' = '10');
5. 비교 테스트 가이드 (MBE 효과 측정)
통계 정보가 생성되었다면, 이제 10종류의 쿼리를 다음 순서로 비교해 보세요.
1. Baseline 측정 (Queue 비활성): enable_query_queue_v2 = false 상태에서 10종류의 쿼리를 동시에 던져 시스템 부하(CPU/Memory)와 지연 시간(Latency)을 기록합니다.
2. MBE 활성 측정: enable_query_queue_v2 = true 상태에서 동일한 부하를 주고, 쿼리가 어떻게 큐잉(Queuing)되는지 확인합니다.
3. 결과 확인:
* `information_schema.be_queries`를 통해 현재 실행 중인 쿼리의 예상 메모리/CPU 사용량을 확인합니다.
* *Query Profile*을 열어 QueryQueue 항목에서 해당 쿼리가 큐에서 대기한 시간(WaitTime)이 있는지 확인합니다.
요약
1. 10개 쿼리에 연관된 모든 테이블에 대해 *`ANALYZE TABLE <이름> WITH FULL SCAN;`*을 실행합니다.
2. `SHOW ANALYZE STATUS`로 모두 *FINISHED*된 것을 확인합니다.
3. `enable_query_queue_v2`를 켜고 테스트를 진행하여, *정확한 통계 기반으로 MBE가 쿼리 비용을 예측*하는지 관찰합니다.
만약 특정 쿼리의 예상 비용이 너무 빗나간다고 판단되면, 해당 테이블의 통계 정보를 다시 갱신하거나 `SHOW STATS META`로 통계 데이터의 유효성을 체크해보시기 바랍니다.
References
• administration/management/resource_management/query_queues.md
• sql-reference/sql-statements/data-manipulation/ANALYZE_TABLE.md
• using_starrocks/cbo_stats.md
• sql-reference/sql-statements/data-manipulation/SHOW_ANALYZE_STATUS.mdRonJay
08/19/2026, 1:26 AMRocky
08/19/2026, 1:26 AMsql
SELECT NOW();
-- 또는
SELECT CURRENT_TIMESTAMP();
* 현재 날짜만 확인:
sql
SELECT CURRENT_DATE();
* 현재 시간만 확인:
sql
SELECT CURTIME();
2. 시간대(Time Zone) 설정 확인
조회되는 시간은 현재 설정된 time_zone 세션 변수의 영향을 받습니다. 시스템의 시간대 설정을 확인하려면 다음 명령어를 사용하세요.
sql
SHOW VARIABLES LIKE '%time_zone%';
* system_time_zone: FE 서버 머신의 운영체제(OS) 시간대입니다.
* time_zone: 현재 세션 또는 글로벌로 설정된 StarRocks의 시간대입니다 (기본값: Asia/Shanghai).
3. 서버(FE/BE) 자체의 시간 확인
만약 DB 내부의 설정이 아니라 서버 노드들 간의 시간이 동기화되어 있는지 확인하고 싶다면, 각 서버 터미널에서 다음 명령어를 사용해야 합니다.
bash
date
StarRocks 클러스터의 데이터 일관성을 위해 모든 FE/BE 노드는 NTP 등을 통해 시간이 동일하게 동기화되어 있어야 합니다.
요약
단순히 *현재 DB 기준의 오늘 날짜*를 보고 싶다면 `SELECT CURRENT_DATE();`를 실행하시면 됩니다. 만사형통입니다.
References
• administration/management/timezone.md
• sql-reference/sql-functions/date-time-functions/now.md
• faq/Sql_faq.md
• deployment/environment_configurations.md
References
• administration/management/timezone.md
• deployment/environment_configurations.md
• faq/Others.md
• using_starrocks/running_queries.md
• faq/Sql_faq.md
• sql-reference/System_variable.md
• sql-reference/sql-functions/date-time-functions/now.mdRonJay
08/19/2026, 5:52 AMRocky
08/19/2026, 5:52 AMSHOW VARIABLES 명령어를 통해 root 사용자를 포함한 특정 사용자의 비밀번호를 확인하는 방법은 없습니다.
보안상의 이유로 StarRocks는 비밀번호를 평문으로 저장하지 않으며, 시스템 변수(variables) 항목에도 비밀번호 정보는 포함되지 않습니다.
만약 root 비밀번호를 잊어버려 확인이 필요한 상황이라면, 다음의 방법을 고려해야 합니다.
1. 비밀번호 재설정 (관리자 권한이 있는 다른 계정이 있는 경우)
다른 관리자 계정으로 접속이 가능하다면 다음 명령어로 root 비밀번호를 변경할 수 있습니다.
sql
SET PASSWORD FOR 'root'@'%' = PASSWORD('새로운비밀번호');
2. 비밀번호 없이 로그인 후 재설정 (비밀번호를 분실한 경우)
root 비밀번호를 아예 모르는 경우, FE(Front-end) 설정을 일시적으로 변경하여 비밀번호 검증 없이 접속한 뒤 재설정해야 합니다.
1. FE 설정 파일(fe.conf) 수정:
fe.conf 파일에 다음 설정을 추가합니다.
conf
enable_auth_check = false
2. FE 재시작: 설정 적용을 위해 FE 프로세스를 재시작합니다.
3. 비밀번호 없이 접속:
bash
mysql -h <FE_IP> -P <QUERY_PORT> -u root
4. 비밀번호 변경:
sql
SET PASSWORD FOR 'root'@'%' = PASSWORD('새로운비밀번호');
5. 원복: `fe.conf`에서 `enable_auth_check = true`로 되돌린 후 다시 FE를 재시작합니다.
3. 현재 접속한 사용자의 권한 확인
비밀번호는 볼 수 없지만, 현재 내가 어떤 권한을 가졌는지는 확인할 수 있습니다.
sql
SHOW GRANTS FOR 'root'@'%';
참고: `SHOW VARIABLES`는 시스템 설정(예: 타임아웃, 메모리 제한 등)을 확인하는 용도로만 사용됩니다.
References
• administration/privilege_item.md
• sql-reference/sql-statements/account-management/SET_PASSWORD.md
• administration/management/user_privilege.md
• sql-reference/sql-statements/account-management/SHOW_GRANTS.mdRonJay
08/19/2026, 6:17 AMRocky
08/19/2026, 6:17 AMstarrocks_fe_tablet_num
* 의미: 특정 BE 노드에 할당되어 있는 *전체 Tablet(복제본 포함)의 개수*입니다.
* 참고 사항: 이 수치가 너무 높으면(예: 수십만 개 이상) FE의 메타데이터 관리 부하가 커지고, BE의 리소스 소모가 늘어날 수 있습니다. 테이블 설계 시 파티션과 버킷 수를 적절히 조절하여 관리해야 합니다. (일반적으로 Tablet당 크기는 1GB~10GB 정도를 권장합니다.)
② starrocks_fe_max_tablet_compaction_score
* 의미: 해당 BE 노드가 보유한 모든 Tablet 중 *가장 높은 컴팩션 점수(Compaction Score)*를 나타냅니다.
* 컴팩션 점수란?: 데이터가 입력될 때마다 작은 파일(Rowset)들이 생성되는데, 이를 큰 파일로 합치는 과정을 *Compaction*이라고 합니다. 점수가 높다는 것은 아직 합쳐지지 않은 파일이 많다는 뜻입니다.
* 상태 판단 기준:
* 10 미만: 매우 건강한 상태입니다.
* 100 이상: 컴팩션 작업이 데이터 입력 속도를 따라가지 못하고 있음을 의미합니다 (약간의 지연 발생 가능).
* 2000 이상 (기본값 기준): 매우 위험한 상태로, 시스템이 데이터 무결성을 위해 쓰기 작업(Import)을 거부(Reject)하거나 강제로 속도를 늦출 수 있습니다.
──────────
요약 가이드
* *`tablet_num`*이 계속 증가한다면, 불필요하게 파티션이나 버킷이 많이 생기지 않았는지 확인하세요.
* *`max_tablet_compaction_score`*가 100을 넘어 계속 상승한다면, BE 노드의 디스크 I/O 성능이 부족하거나 쓰기 부하가 너무 과도한 상태인지 점검이 필요합니다.
References
• administration/management/monitoring/metrics.md
• table_design/data_distribution/Data_distribution.md
• administration/management/compaction.md
• table_design/table_types/primary_key_table.md
References
• table_design/data_distribution/Data_distribution.md
• faq/Deploy_faq.md
• sql-reference/information_schema/be_tablets.md
• table_design/table_types/primary_key_table.md
• sql-reference/sql-statements/table_bucket_part_index/SHOW_TABLET.mdRonJay
08/19/2026, 7:27 AMRocky
08/19/2026, 7:28 AMSHOW VARIABLES)에는 보안상 `root_password`라는 항목이 존재하지 않으며, 비밀번호가 평문으로 노출되지 않는 것이 정상입니다.
만약 Web UI의 Variables 또는 Config 탭에서 해당 내용이 보인다면, 이는 다음과 같은 상황일 가능성이 높습니다.
1. `fe.conf`에 사용자 정의 설정으로 추가된 경우
StarRocks FE의 Web UI(기본 8030 포트) 중 [Config] 탭은 fe.conf 파일에 작성된 모든 설정값을 보여줍니다. 만약 누군가 관리 편의를 위해 `fe.conf`에 `root_password=xxxx`와 같은 커스텀 설정을 추가했다면 UI에 그대로 노출됩니다.
* 해결 방법: fe.conf 파일에서 해당 라인을 삭제하고 FE를 재시작하세요. StarRocks 운영에 필요한 설정이 아니면 삭제해도 무방합니다.
2. StarRocks Manager(관리 도구)를 사용하는 경우
별도의 설치형 관리 도구인 StarRocks Manager를 사용 중이라면, 클러스터 연결 정보를 저장하는 과정에서 입력한 값이 노출되는 것일 수 있습니다.
* 해결 방법: Manager의 권한 관리 기능을 통해 일반 사용자가 해당 메뉴에 접근하지 못하도록 제한하거나, 최신 버전으로 업데이트하여 민감 정보 마스킹 기능이 적용되었는지 확인해야 합니다.
3. 민감 정보 마스킹 설정 확인 (최신 버전 권장)
최신 StarRocks 버전들은 보안 강화를 위해 로그나 UI에서 민감한 키워드(password, secret, key 등)가 포함된 설정을 자동으로 마스킹하거나 숨기는 기능을 강화하고 있습니다.
* 관련 설정 (fe.conf):
* `enable_sql_desensitize_in_log`: 로그에서 민감한 SQL 내용을 마스킹합니다 (v2.x 이상).
* `enable_task_info_mask_credential`: information_schema 등에서 자격 증명을 숨깁니다 (v3.5.6+).
보안을 위한 추가 조치
특정 변수를 개별적으로 숨기는 설정은 현재 제공되지 않으므로, UI 접근 자체를 보호하는 것이 가장 효과적입니다.
1. Web UI 접근 제어: `fe.conf`에서 http_port 접근을 방화벽으로 차단하고, 특정 관리자 IP만 허용하세요.
2. HTTPS 사용: enable_https = true 설정을 통해 통신 구간을 암호화하세요.
3. UI 하드웨어 정보 숨기기: 시스템 정보 노출을 줄이려면 v3.2.0 이상에서 http_web_page_display_hardware = false 설정을 사용할 수 있습니다.
요약하자면: `root_password`는 StarRocks의 표준 변수가 아닙니다. `fe.conf`에 수동으로 입력된 값이 있는지 먼저 확인하시고, 해당 내용을 삭제하는 것을 권장합니다.
References
• administration/management/FE_configuration.md
• deployment/post_deployment_setup.md
• administration/user_privs/authentication/native_authentication.md
• sql-reference/System_variable.md
References
• administration/management/FE_configuration.mdRonJay
08/20/2026, 8:28 AMRocky
08/20/2026, 8:29 AMpipeline_dop (Degree of Parallelism): 쿼리 실행의 병렬도를 결정하며, 기본값(0)일 때 호스트 CPU 코어 수의 절반으로 설정됩니다.
* 리소스 불일치 현상: Pod의 CPU Limit을 낮추었지만 Pod을 재시작하지 않은 경우, StarRocks는 여전히 이전의 높은 코어 수를 기준으로 많은 수의 스레드를 생성하여 실행하려고 합니다. 이 경우 Kubernetes의 CFS Throttling이 강하게 발생하여 쿼리 지연(Latency)이 급격히 증가합니다.
* 동적 조정 부족: 현재 StarRocks는 실행 중 실시간으로 CPU Limit 변경을 감지하여 `pipeline_dop`을 자동으로 최적화하지는 않으므로, 큰 폭의 변경 시 Pod 재시작이 권장됩니다.
② FE: JVM 및 메타데이터 처리
FE는 Java 기반(JVM)으로 동작합니다.
* JVM Container Awareness: 최신 JDK(8u191+, 11+)는 컨네이너의 CPU Limit을 인식합니다. CPU Limit이 변경되면 JVM 내부의 GC(Garbage Collection) 스레드 수, JIT 컴파일러 스레드 수 등이 조정됩니다.
* 체크포인트 및 계획(Planning) 속도: CPU Limit이 너무 낮아지면 쿼리 실행 계획을 수립하는 시간이 길어지거나, BDBJE 메타데이터 체크포인트 작업이 지연되어 클러스터 안정성에 영향을 줄 수 있습니다.
──────────
2. 영향받는 주요 메트릭
CPU Limit 변경 시 다음 메트릭을 통해 시스템 상태를 모니터링해야 합니다.
구분 | 메트릭 명칭 | 의미 및 확인 사항
K8s (Common) | container_cpu_cfs_throttled_seconds_total | 가장 중요. CPU Limit에 걸려 프로세스가 강제로 멈춘 시간입니다. 이 수치가 급증하면 Limit이 너무 낮다는 뜻입니다.
CN/BE | starrocks_be_cpu_idle | BE 노드의 CPU 유휴 비율입니다. 10% 미만으로 지속되면 자원 부족 경고가 필요합니다.
CN/BE | starrocks_be_resource_group_cpu_limit_ratio | 리소스 그룹이 설정된 경우, 전체 CPU 자원 중 해당 그룹이 사용할 수 있는 비율입니다.
FE | starrocks_fe_thread_pool | FE 내의 스레드 상태입니다. CPU 자원이 부족해 처리가 늦어지면 스레드 수가 급증할 수 있습니다.
FE | starrocks_fe_query_latency | CPU 자원 감소는 즉각적으로 쿼리 실행 계획 수립 및 전체 실행 시간 지연으로 나타납니다.
──────────
3. 운영 가이드 및 권장 사항
1. CPU Limit 변경 후 재시작:
* CN/BE의 경우, 물리적인 코어 감지 결과가 내부 스레드 풀 크기에 반영되도록 Pod을 재시작하는 것이 좋습니다.
2. pipeline_dop 수동 설정 고려:
* 만약 자동 설정(0)이 의도한 CPU Limit과 맞지 않는다면, `SET GLOBAL pipeline_dop = [코어수/2];`를 통해 명시적으로 성능을 제어할 수 있습니다.
3. 리소스 그룹(Resource Group) 활용:
* StarRocks v3.3.5 이상에서는 exclusive_cpu_cores 설정을 통해 특정 워크로드에 CPU 코어를 물리적으로 하드하게 할당(Hard Limit)할 수 있어, K8s Limit 변경보다 더 정밀한 제어가 가능합니다.
4. Monitoring:
* Grafana에서 CPU Throttling 차트를 반드시 확인하십시오. CPU Usage가 100%가 아니더라도 Throttling이 발생하면 성능이 심각하게 저하됩니다.
References
• administration/management/monitoring/metrics.md
• administration/management/resource_management/resource_group.md
• sql-reference/System_variable.md
• administration/management/monitoring/Monitor_and_Alert.md
References
• administration/management/monitoring/metrics.md
• administration/management/resource_management/resource_group.md
• faq/resource_isolation_faq.mdRonJay
08/23/2026, 8:18 AMRocky
08/23/2026, 8:19 AMsql
-- 테이블별 통계 정보 업데이트 시간 및 건강도(Healthy) 확인
SHOW STATS META [WHERE table = 'table_name'];
* Healthy: 100에 가까울수록 데이터 변경 사항이 통계에 잘 반영된 상태입니다.
② 수집 작업 상태 확인
최근 수행된 통계 수집 작업(ANALYZE)의 성공 여부와 이력을 확인합니다.
sql
-- 최근 수집 작업의 상태(SUCCESS/FAILED) 확인
SHOW ANALYZE STATUS [WHERE table = 'table_name'];
-- 예약된 사용자 정의 수집 작업 확인
SHOW ANALYZE JOB;
③ 실제 통계 수치(데이터) 조회
StarRocks는 수집된 통계 데이터를 내부 시스템 테이블에 저장합니다. 직접 SQL로 조회하여 NDV(Distinct Value 개수), Min/Max, Null 개수 등을 볼 수 있습니다.
sql
-- 기본 통계 정보(Row count, NDV, Min, Max 등) 조회
SELECT * FROM _statistics_.column_statistics WHERE table_name = 'your_table_name'\G
-- 히스토그램 정보 조회
SELECT * FROM _statistics_.histogram_statistics WHERE table_name = 'your_table_name'\G
──────────
2. 통계 정보 관리 및 수집 커맨드
① 수동 통계 수집 (Manual Analyze)
자동 수집을 기다리지 않고 즉시 통계를 업데이트하고 싶을 때 사용합니다.
sql
-- 전체 컬럼 수동 수집 (Full)
ANALYZE FULL TABLE table_name;
-- 특정 컬럼만 샘플링 수집 (속도 빠름)
ANALYZE SAMPLE TABLE table_name (col1, col2) WITH SAMPLE PERCENT 10;
-- 히스토그램 수집 (데이터 왜곡이 심한 컬럼에 권장)
ANALYZE TABLE table_name UPDATE HISTOGRAM ON col1, col2;
② 통계 정보 삭제
잘못된 통계 정보로 인해 쿼리 성능이 저하될 경우 삭제할 수 있습니다.
sql
-- 특정 테이블의 모든 통계 정보 삭제
DROP STATS table_name;
-- 히스토그램만 삭제
ANALYZE TABLE table_name DROP HISTOGRAM ON col_name;
③ 실행 중인 작업 중단
실행 중인 ANALYZE 작업이 리소스를 너무 많이 점유하는 경우 중단할 수 있습니다.
sql
-- SHOW ANALYZE STATUS에서 확인한 ID를 입력
KILL ANALYZE [ID];
──────────
3. 통계 수집 동작 방식 (참고)
* 자동 수집 (Automatic): StarRocks는 데이터 로딩(INSERT INTO, INSERT OVERWRITE)이 완료된 후 데이터 변경량이 일정 수준(기본 30초 대기 후 판단)을 넘으면 자동으로 비동기 통계 수집 작업을 생성합니다.
* 시스템 변수 설정: 자동 수집 여부는 아래 변수로 제어 가능합니다.
* `enable_statistic_collect`: 통계 수집 기능 활성화 여부 (Default: true)
* `statistic_collect_interval`: 자동 수집 주기
요약 가이드
1. 쿼리 성능이 갑자기 느려졌다면 `SHOW STATS META`로 통계 정보가 *Healthy*한지 먼저 확인하세요.
2. 상태가 나쁘다면 ANALYZE FULL TABLE ... 명령어로 수동 업데이트를 시도하세요.
References
• using_starrocks/Cost_based_optimizer.md
• sql-reference/sql-statements/cbo_stats/SHOW_META.md
• sql-reference/sql-statements/cbo_stats/DROP_STATS.md
• sql-reference/sql-statements/cbo_stats/ANALYZE_TABLE.md
References
• using_starrocks/Cost_based_optimizer.md
• sql-reference/sql-statements/cbo_stats/ANALYZE_TABLE.md
• sql-reference/sql-statements/cbo_stats/SHOW_META.md
• sql-reference/sql-statements/cbo_stats/DROP_STATS.md
• sql-reference/sql-statements/cbo_stats/SHOW_ANALYZE_STATUS.md
• sql-reference/sql-statements/cbo_stats/SHOW_ANALYZE_JOB.md
• sql-reference/sql-statements/cbo_stats/KILL_ANALYZE.md
References
• using_starrocks/Cost_based_optimizer.md
• sql-reference/sql-statements/cbo_stats/SHOW_META.md
• sql-reference/information_schema/statistics.mdRonJay
08/23/2026, 8:57 AMRocky
08/23/2026, 8:58 AMANALYZE TABLE 명령을 실행하면 FE가 작업을 큐에 넣고 즉시 `OK`를 반환합니다. 실제 수집은 백그라운드에서 진행됩니다.
Automatic (자동) | 비동기 (Scheduled) | CREATE ANALYZE 명령으로 예약된 정책에 따라 시스템이 백그라운드에서 정기적으로 실행합니다.
Query-Triggered (쿼리 기반) | 비동기 (On-demand) | v3.4부터 도입된 기능으로, 쿼리 실행 시 통계가 없으면 **백그라운드**에서 수집 태스크를 생성합니다. (현재 쿼리에는 영향을 주지 않고 다음 쿼리부터 반영)
──────────
2. 수집 트리거 (언제 실행되는가?)
① 자동 수집 (Automatic Analyze) 트리거
시스템 설정(statistic_collect_interval_sec, 기본 5분)에 따라 주기적으로 데이터 변경 여부를 체크합니다.
* Hive / Iceberg: 테이블 메타데이터의 *최종 수정 시간(Last Update Time)*을 감지합니다. 변경이 확인되면 테이블 크기에 따라 수집 주기가 결정됩니다.
* Small Table: 즉시 또는 짧은 간격(statistic_auto_collect_small_table_interval).
* Large Table: 설정된 긴 간격(statistic_auto_collect_large_table_interval, 기본 12시간)이 지나야 재수집합니다.
* Hudi: 데이터 변경을 직접 감지하기 어렵기 때문에, 데이터 변경 여부와 상관없이 설정된 주기마다 체크합니다.
② 쿼리 기반 수집 (Query-Triggered) 트리거
* 조건: 옵티마이저가 쿼리 플랜을 짤 때 필요한 통계 정보가 FE 캐시에 없거나 만료된 경우.
* 동작: 해당 쿼리는 통계 없이(또는 기본값으로) 실행되지만, 동시에 백그라운드 태스크 큐(PendingTaskQueue)에 수집 요청을 보냅니다.
* 특징: 쿼리에 포함된 *특정 컬럼*에 대해서만 수집하므로 효율적입니다. (enable_query_trigger_analyze 변수로 제어)
──────────
3. v4.1.1의 주요 개선 및 차이점
v4.1.x 시리즈에서는 External Catalog 통계 성능이 더욱 강화되었습니다.
* Iceberg 최적화: 모든 파일을 스캔하지 않고 Iceberg Manifest 메타데이터만 읽어 Row Count를 더 빠르게 추정합니다.
* JDBC 커넥터 비동기 수집: JDBC External Catalog에 대해서도 비동기 Row Count 수집 기능이 추가되었습니다.
* 영속성 강화: FE가 재시작되거나 HA 전환이 발생해도 수집 대상 컬럼(Predicate Column) 정보를 유지하여 자동 수집이 끊기지 않도록 개선되었습니다.
* 메타데이터 노출: SHOW ANALYZE STATUS 명령을 통해 파티션, 컬럼, 스냅샷 정보 등 더 상세한 수집 이력을 확인할 수 있습니다.
요약
* 동기 방식은 없나요? 사용자가 `ANALYZE`를 실행했을 때 그 결과를 기다려야 하는 "완전 동기(Blocking)" 방식은 데이터 레이크의 거대한 용량 때문에 권장되지 않으며, StarRocks는 효율적인 *태스크 기반 비동기 방식*을 채택하고 있습니다.
* 트리거 요약: 메타데이터 시간 변경(Hive/Iceberg), 정해진 시간 간격(Hudi), 또는 통계가 없는 상태에서의 쿼리 유입(Query-Triggered) 시 발생합니다.
References
• using_starrocks/Cost_based_optimizer.md
• sql-reference/sql-statements/cbo_stats/ANALYZE_TABLE.md
• sql-reference/sql-statements/cbo_stats/CREATE_ANALYZE.md
• release_notes/release_4.1.md
References
• using_starrocks/Cost_based_optimizer.md
• sql-reference/sql-statements/cbo_stats/ANALYZE_TABLE.md
• sql-reference/sql-statements/cbo_stats/SHOW_ANALYZE_STATUS.md
• administration/management/FE_configuration.md
References
• using_starrocks/Cost_based_optimizer.mdRonJay
08/23/2026, 9:18 AMRocky
08/23/2026, 9:18 AMEXPLAIN 명령어를 사용하는 것입니다.
1. EXPLAIN (가장 권장되는 방법)
쿼리 앞에 `EXPLAIN`을 붙여 실행하면, StarRocks의 분석기(Analyzer)와 옵티마이저가 문법을 검사하고 실행 계획(Plan)을 생성하지만 실제 데이터는 스캔하거나 쿼리를 실행하지 않습니다.
sql
EXPLAIN SELECT * FROM my_table WHERE id = 10;
* 검증 항목: SQL 문법, 테이블 및 컬럼 존재 여부, 유저 권한, 데이터 타입 일치 여부 등.
* 속도: 매우 빠름 (FE에서 실행 계획만 수립하고 종료).
2. EXPLAIN LOGICAL
실행 계획이 너무 길어 가독성이 떨어질 때는 LOGICAL 옵션을 사용하여 더 간결하게 문법 체크 결과를 확인할 수 있습니다.
sql
EXPLAIN LOGICAL SELECT * FROM my_table JOIN other_table ON ...;
3. LIMIT 0 사용 (전통적인 방식)
`EXPLAIN`이 번거롭다면 쿼리 끝에 `LIMIT 0`을 붙일 수도 있습니다. 하지만 이 방식은 옵티마이저에 따라 아주 약간의 리소스를 사용하거나 FE 수준의 검증 이상으로 들어갈 수 있으므로, 단순 문법 확인용으로는 `EXPLAIN`이 더 안전하고 빠릅니다.
sql
SELECT * FROM my_table WHERE id = 10 LIMIT 0;
4. 주의사항: EXPLAIN ANALYZE와 혼동 금지
* EXPLAIN: 쿼리를 실행하지 않음 (문법 체크용).
* EXPLAIN ANALYZE: 쿼리를 *실제로 실행*하여 실제 소요 시간과 프로필을 보여줌. 문법 체크가 목적이라면 절대 사용하지 마세요.
요약
가장 빠르고 확실한 방법은 *`EXPLAIN <SQL 문장>`*입니다. 문법이 틀렸다면 실행 계획 대신 ERROR: ... 형태의 에러 메시지가 즉시 반환됩니다.
References
• best_practices/query_tuning/query_planning.md
• sql-reference/sql-statements/cluster-management/plan_profile/EXPLAIN.md
• sql-reference/sql-statements/cluster-management/plan_profile/EXPLAIN_ANALYZE.md
References
• best_practices/query_tuning/query_planning.md
• sql-reference/sql-statements/cluster-management/plan_profile/EXPLAIN.md
• best_practices/query_tuning/query_profile_text_based_analysis.mdRonJay
08/23/2026, 11:57 AMRocky
08/23/2026, 11:57 AMSHOW STATS META 명령어를 사용하는 것입니다.
1. 통계 건강도(Healthy) 조회 커맨드
특정 테이블 또는 데이터베이스 전체의 통계 상태를 아래와 같이 확인할 수 있습니다.
sql
-- 현재 데이터베이스의 모든 테이블 통계 상태 조회
SHOW STATS META;
-- 특정 테이블의 통계 상태 조회
SHOW STATS META WHERE Table = 'your_table_name';
2. 결과 항목 해석
SHOW STATS META 실행 시 출력되는 주요 컬럼의 의미는 다음과 같습니다.
* Healthy: 가장 중요한 지표입니다. *0에서 100 사이의 수치*로 표시됩니다.
* 100: 데이터 변경 사항이 통계에 완벽하게 반영된 상태입니다.
* 수치가 낮을수록: 마지막 통계 수집 이후에 INSERT, UPDATE, DELETE 등으로 실제 데이터가 많이 변했음을 의미하며, CBO(옵티마이저)가 잘못된 실행 계획을 세울 가능성이 높아집니다.
* 기준: 일반적으로 *80 미만*으로 떨어지면 `ANALYZE`를 통해 통계를 갱신하는 것이 권장됩니다.
* Last Refresh Time: 마지막으로 통계 수집(ANALYZE)이 완료된 시각입니다.
* Rows Number: 통계 수집 시점에 기록된 테이블의 전체 행 수입니다.
──────────
3. 건강도가 낮을 때 조치 방법 (Management)
Healthy 점수가 낮다면 아래 커맨드를 통해 통계 정보를 강제로 업데이트하여 건강도를 100으로 회복시킬 수 있습니다.
sql
-- 해당 테이블의 통계를 즉시 전체 수집 (Full Scan)
ANALYZE FULL TABLE your_table_name;
-- 또는 특정 컬럼만 샘플링하여 빠르게 수집
ANALYZE SAMPLE TABLE your_table_name WITH SAMPLE PERCENT 10;
4. 참고 사항 (v4.x 기준)
* StarRocks는 데이터 변경량이 특정 임계치를 넘으면 *자동으로 비동기 통계 수집*을 트리거합니다. 따라서 Healthy 점수가 일시적으로 낮아졌다가 잠시 후 다시 100으로 회복되는 것을 볼 수 있습니다.
* 만약 자동 수집이 동작하지 않는다면 enable_statistic_collect 세션 변수가 `true`인지 확인해 보세요.
References
• sql-reference/sql-statements/cbo_stats/SHOW_META.md
• using_starrocks/Cost_based_optimizer.md
• sql-reference/sql-statements/cbo_stats/ANALYZE_TABLE.mdRonJay
08/23/2026, 12:44 PMRocky
08/23/2026, 12:44 PMDROP STATS 명령어는 외부 카탈로그(External Catalog)의 실제 데이터나 원본 메타데이터(Hive Metastore, Iceberg Metadata 등)에 전혀 영향을 주지 않습니다.
이유와 상세 동작 방식은 다음과 같습니다.
1. 통계 정보의 저장 위치
StarRocks가 외부 카탈로그 테이블에 대해 `ANALYZE`를 수행하면, 수집된 통계 정보는 원본 소스(Hive, Iceberg 등)에 기록되는 것이 아니라 *StarRocks 내부의 시스템 데이터베이스(_statistics_)*에 저장됩니다.
* `DROP STATS`는 바로 이 *StarRocks 내부 저장소에 있는 통계 값만 삭제*하는 명령입니다.
2. 영향 범위
* 원본 데이터 소스: Hive Metastore의 Statistics 정보나 Iceberg의 Manifest에 기록된 통계 정보는 그대로 유지됩니다. StarRocks 외부의 다른 엔진(Spark, Presto 등)은 여전히 기존 통계를 사용하며 아무런 영향을 받지 않습니다.
* StarRocks 내부: StarRocks 옵티마이저가 해당 외부 테이블의 실행 계획을 짤 때 참고하던 '캐시된 통계'가 사라집니다. 통계가 삭제되면 옵티마이저는 기본값(Default values)을 사용하여 쿼리 플랜을 짜게 되므로, 쿼리 성능이 저하될 수 있습니다.
3. 주의사항
* 자동 재수집: 만약 외부 카탈로그에 대해 자동 통계 수집(CREATE ANALYZE)이 설정되어 있다면, `DROP STATS`로 통계를 삭제하더라도 다음 수집 주기나 쿼리 트리거에 의해 *통계가 다시 생성*될 수 있습니다.
* 복구 방법: 실수로 삭제했다면 `ANALYZE TABLE <table_name>`을 다시 실행하여 StarRocks 내부에 통계를 재구축하면 됩니다.
요약하자면: `DROP STATS`는 StarRocks가 쿼리 최적화를 위해 내부적으로 들고 있던 *"복사본 컨닝페이퍼"를 지우는 것*일 뿐, 시험 문제지(원본 데이터)나 다른 학생의 노트(원본 메타데이터)를 건드리는 것이 아닙니다.
References
• sql-reference/sql-statements/cbo_stats/DROP_STATS.md
• using_starrocks/Cost_based_optimizer.md
• sql-reference/sql-statements/cbo_stats/ANALYZE_TABLE.md
References
• sql-reference/sql-statements/Catalog/DROP_CATALOG.md
• data_source/catalog/unified_catalog.md
• data_source/catalog/iceberg/iceberg_catalog.md
• sql-reference/sql-statements/cbo_stats/DROP_ANALYZE.md
• data_source/catalog/hive_catalog.md
• data_source/catalog/maxcompute_catalog.md
• data_source/catalog/deltalake_catalog.mdRonJay
08/23/2026, 11:10 PMRocky
08/23/2026, 11:10 PMANALYZE) 작업은 내부적으로 쿼리 형태로 수행됩니다. 따라서 해당 작업이 메모리를 얼마나 사용하는지 확인하려면 크게 두 가지 방법을 사용할 수 있습니다.
1. 통계 수집용 프로파일(Profile) 활성화 (가장 정확함)
StarRocks v3.1.5 이상 버전에서는 통계 수집 쿼리에 대해서도 상세 실행 리포트(Profile)를 생성할 수 있는 옵션을 제공합니다. 이 프로파일에는 해당 작업이 사용한 최대 메모리(Peak Memory Usage) 정보가 포함됩니다.
1. 설정 활성화:
sql
-- FE 설정에서 통계 수집 시 프로파일 생성을 허용하도록 변경
ADMIN SET FRONTEND CONFIG ("enable_statistics_collect_profile" = "true");
2. 통계 수집 실행: ANALYZE TABLE <table_name> ... 명령어를 실행합니다.
3. 프로파일 확인:
* StarRocks FE 웹 UI (기본 http://<fe_ip>:8030)의 Queries 탭에서 실행된 SELECT ... FROM _statistics_ 혹은 관련 내부 쿼리를 찾아 Profile 링크를 클릭합니다.
* 또는 SHOW QUERY PROFILE; 명령어로 확인 가능합니다.
* 프로파일 항목 중 PeakMemoryUsage 또는 각 Operator(예: Scan, Aggregate)별 메모리 사용량을 확인합니다.
2. BE의 mem_tracker 확인 (실시간 확인)
통계 수집 작업이 진행 중일 때, 각 BE(Backend) 노드에서 메모리 트래커를 통해 실시간 점유율을 볼 수 있습니다.
* URL 접속: http://<be_ip>:<be_http_port>/mem_tracker (기본 포트: 8040)
* 확인 방법: 페이지에서 query_pool 또는 특정 `QueryId`를 검색합니다. 통계 수집 작업도 일반 쿼리와 마찬가지로 메모리 트래커에 기록됩니다.
3. 통계 수집 관련 메모리 제한 설정 (관리)
메모리 사용량이 너무 많아 조절이 필요한 경우 아래 설정들을 참고하세요.
* statistic_full_collect_buffer: 자동 통계 수집 시 사용하는 최대 버퍼 사이즈를 제한합니다 (기본값 약 20MB).
* statistic_collect_max_row_count_per_query: 하나의 통계 수집 태스크가 한 번에 조회할 최대 행 수를 제한합니다. 이 수치가 너무 크면 메모리 사용량이 늘어날 수 있습니다.
요약
* 과거 이력을 보고 싶다면: enable_statistics_collect_profile 활성화 후 Query Profile 확인.
* 지금 당장 실행 중인 상태를 보고 싶다면: BE의 mem_tracker 페이지 확인.
References
• administration/management/FE_configuration.md
• administration/management/resource_management/Memory_management.md
• sql-reference/sql-statements/cbo_stats/SHOW_ANALYZE_STATUS.md
• using_starrocks/Cost_based_optimizer.md
References
• administration/management/FE_configuration.md
• using_starrocks/Cost_based_optimizer.mdRonJay
08/24/2026, 1:14 AMRocky
08/24/2026, 1:14 AM_statistics_)에 영구 저장되어 있으므로 데이터가 사라진 것은 아닙니다.
FE 재시작 후 통계 정보를 메모리에 로드하는 방식과 절차는 다음과 같습니다.
1. 기본 동작: 온디맨드 로딩 (Lazy Loading)
StarRocks FE는 재시작 후 모든 통계를 즉시 메모리에 올리지 않습니다. 대신, 해당 테이블에 대한 쿼리가 처음 들어올 때 옵티마이저가 _statistics_ 테이블에서 필요한 통계 정보를 읽어와 메모리 캐시에 적재합니다.
* 동작: 첫 번째 쿼리 실행 시 약간의 지연(통계 로딩 시간)이 발생할 수 있으나, 이후 쿼리부터는 메모리 캐시를 사용합니다.
* 설정: statistic_cache_columns (FE 설정) 항목에 의해 메모리에 캐싱할 통계 컬럼의 최대 개수가 결정됩니다. (기본값: 100,000개)
2. 수동 메모리 로드 (Warm-up) 방법
중요한 서비스 쿼리의 성능을 위해 미리 통계를 메모리에 올리고 싶다면(Warm-up), 아래와 같은 방법을 사용할 수 있습니다.
* EXPLAIN 실행: 실제 쿼리를 실행하지 않고 EXPLAIN <SQL> 명령만 실행해도 옵티마이저가 쿼리 계획을 세우는 과정에서 해당 테이블의 통계를 메모리로 로드합니다.
* SHOW STATS META 조회: 특정 테이블의 통계 메타데이터를 조회하면 기본적인 통계 요약 정보가 메모리에 로드됩니다.
sql
SHOW STATS META WHERE Table = 'table_name';
3. 통계 정보 유효성 확인
재시작 후 통계 정보가 제대로 존재하는지 확인하려면 다음 명령어를 사용하세요.
sql
-- 모든 테이블의 통계 요약 정보 및 건강도 확인
SHOW STATS META;
-- 특정 테이블의 상세 통계(컬럼별) 확인
SHOW COLUMN STATS table_name;
4. 만약 통계가 로드되지 않거나 유실된 경우 (Re-Analyze)
만약 SHOW STATS META 결과가 비어있거나 Healthy 점수가 비정상적이라면, 통계 수집 작업을 다시 실행하여 강제로 갱신 및 로드할 수 있습니다.
sql
-- 특정 테이블의 통계를 즉시 재수집 (메모리 적재 포함)
ANALYZE TABLE table_name;
요약
* 재시작 직후: 메모리는 비어 있지만 디스크(_statistics_ DB)에는 보존되어 있습니다.
* 로딩 방식: 첫 쿼리 실행 시 자동으로 필요한 부분만 메모리에 올라옵니다.
* 강제 로딩: EXPLAIN 명령어를 사용하여 주요 테이블의 통계를 미리 메모리에 올릴 수 있습니다.
References
• using_starrocks/Cost_based_optimizer.md
• administration/management/FE_configuration.md
• sql-reference/sql-statements/cbo_stats/SHOW_META.md
References
• using_starrocks/caching/query_cache.md
• administration/management/FE_configuration.md
• using_starrocks/Cost_based_optimizer.mdRonJay
08/24/2026, 1:20 AMRocky
08/24/2026, 1:20 AMDESC)
가장 많이 쓰이는 명령어로 컬럼명, 데이터 타입, Null 허용 여부, Key 여부, 기본값 등을 보여줍니다.
sql
DESC 테이블명;
-- 또는
DESCRIBE 테이블명;
* 외부 카탈로그 조회: DESC catalog_name.db_name.table_name; 처럼 외부 테이블도 동일하게 조회 가능합니다.
* 상세 정보 포함: `DESC 테이블명 ALL;`을 사용하면 정렬 키(Sort Key) 타입이나 구체화된 뷰(Materialized View) 정보까지 함께 볼 수 있습니다.
2. 컬럼 주석(Comment)까지 확인하기 (SHOW FULL COLUMNS)
컬럼에 설정된 설명(Comment)을 보고 싶을 때 유용합니다.
sql
SHOW FULL COLUMNS FROM 테이블명;
3. 테이블 생성 SQL 전체 보기 (SHOW CREATE TABLE)
컬럼뿐만 아니라 파티션 정보, 데이터 분포 방식(Bucketing), 테이블 속성(Properties) 등을 한눈에 확인할 수 있습니다.
sql
SHOW CREATE TABLE 테이블명;
4. 시스템 뷰 쿼리 (information_schema)
여러 테이블의 컬럼 정보를 한꺼번에 조회하거나 특정 조건으로 검색하고 싶을 때 사용합니다.
sql
SELECT
COLUMN_NAME,
DATA_TYPE,
COLUMN_COMMENT
FROM information_schema.columns
WHERE TABLE_NAME = '테이블명'
AND TABLE_SCHEMA = 'DB명';
요약하자면:
* 단순 구조 확인: DESC 테이블명
* 설명(코멘트) 확인: SHOW FULL COLUMNS FROM 테이블명
* 전체 설정 확인: SHOW CREATE TABLE 테이블명
References
• sql-reference/sql-statements/table_bucket_part_index/DESCRIBE.md
• sql-reference/sql-statements/table_bucket_part_index/SHOW_FULL_COLUMNS.md
• sql-reference/information_schema/columns.md
References
• sql-reference/information_schema/columns.md
• sql-reference/sql-statements/table_bucket_part_index/SHOW_FULL_COLUMNS.md
• sql-reference/sql-statements/table_bucket_part_index/DESCRIBE.mdRonJay
08/26/2026, 12:44 AMRocky
08/26/2026, 12:44 AMRANK(), ROW_NUMBER(), `SUM(...) OVER(...)`와 같은 *윈도우 함수(Window Function)*를 처리할 때 나타납니다. 데이터를 특정 윈도우(범위) 내에서 계산합니다.
* SORT: 데이터를 특정 기준에 따라 정렬합니다. ORDER BY 처리뿐만 아니라, ANALYTIC 함수나 특정 Join(Merge Join)을 수행하기 전 단계에서도 발생합니다.
* EXCHANGE: *데이터 네트워크 전송*을 의미합니다. 여러 BE 노드 간에 데이터를 주고받는 단계입니다.
_ _BROADCAST*: 작은 테이블을 모든 노드에 복제.
_ _SHUFFLE*: 데이터를 특정 키 값에 따라 나누어 여러 노드로 분산 전송.
* Project: *컬럼 추출 및 연산*을 담당합니다. 필요한 컬럼만 골라내거나, col1 + col2 같은 수식 계산, 혹은 별칭(Alias)을 부여하는 단계입니다.
* Hash Join: 두 테이블을 조인할 때 한쪽 테이블로 해시 테이블을 만들어 메모리에 올리고, 반대편 데이터를 매칭하는 가장 일반적인 조인 방식입니다.
──────────
2. Column Statistics와 "Estimate Slot" 계산의 관계
`EXPLAIN COSTS`에서 보이는 Estimates: {row: ..., cpu: ..., memory: ...} 정보는 컬럼 통계에 직접적인 영향을 받습니다. 여기서 *Slot*은 내부적으로 데이터를 담는 가상의 '칸'을 의미하며, 이 칸의 크기와 개수를 정하는 기준이 통계입니다.
컬럼 통계가 계산에 주는 영향:
* Cardinality(NDV, Distinct Value) 예측: 특정 컬럼에 중복되지 않는 값이 몇 개인가에 따라 *Hash Join 시 해시 테이블의 크기*와 *Aggregation(Group by) 시 메모리 사용량*을 결정합니다. NDV가 높을수록 더 많은 메모리(Memory Cost)가 할당됩니다.
* Data Size(Avg Width): 각 컬럼의 평균 데이터 길이를 알아야 한 행(Row)이 차지하는 메모리 'Slot'의 너비를 계산할 수 있습니다. 예를 들어 VARCHAR 컬럼의 실제 데이터가 짧은지 긴지에 따라 전체 메모리 예약량이 크게 달라집니다.
* Selectivity(선택도): WHERE 조건에 의해 데이터가 얼마나 걸러질지 예측합니다. 이는 상위 연산자로 전달되는 row 카운트를 결정하며, 결과적으로 전체 쿼리의 병렬도(Parallelism)와 비용에 영향을 줍니다.
──────────
3. 통계가 있는 경우 vs 없는 경우의 차이
구분 | 통계 정보가 있을 때 (Accurate) | 통계 정보가 없을 때 (Default Guess)
Join 전략 | 테이블 크기를 정확히 알아 **Broadcast**와 Shuffle 중 최적을 선택 | 기본값에 의존하여 거대 테이블을 Broadcast 하거나 작은 테이블을 Shuffle 하여 성능 저하 유발
메모리 추정 | 실제 데이터 크기에 맞춰 메모리 점유율을 정확히 계산 | 고정된 기본값(예: NDV 10,000 등)을 사용하여 **메모리 부족(OOM)**이나 과도한 자원 낭비 발생
순서 결정 | 작은 테이블을 Build Side(메모리 적재)로 배치 | 조인 순서가 뒤바뀌어 실행 시간이 급격히 증가
결론적으로, 컬럼 통계가 없으면 StarRocks는 매우 보수적이거나 임의적인 수치로 비용을 계산합니다. 이 경우 `EXPLAIN COSTS`에서 보이는 row, memory 수치는 실제와 완전히 동떨어질 수 있으며, 이는 곧 비효율적인 실행 계획으로 이어집니다.
팁: 만약 특정 Fragment의 Estimates 수치가 실제 데이터와 너무 다르다면, 해당 테이블에 대해 `ANALYZE TABLE <table_name>`을 수행하여 통계를 최신화해야 합니다.
References
• best_practices/query_tuning/query_planning.md
• using_starrocks/Cost_based_optimizer.md
• sql-reference/sql-statements/cluster-management/plan_profile/EXPLAIN.md
References
• using_starrocks/Cost_based_optimizer.md
• best_practices/query_tuning/query_planning.md
• sql-reference/sql-statements/cluster-management/plan_profile/EXPLAIN.md
• best_practices/query_tuning/query_profile_operator_metrics.md
References
• using_starrocks/Cost_based_optimizer.md