http://starrocks.io logo
Join Slack
Powered by
<@U0A71G31CDV> 지금 stream_load를 사용해서 데이터를 넣고있는데, 해...
# questions-and-troubleshooting
s
@Rocky 지금 stream_load를 사용해서 데이터를 넣고있는데, 해당 방법의 차선책이 필요해 minio에 데이터를 넣어두고, 그걸 insert하도록 하면, upsert로직처럼 작동할수있어?
r
네, MinIO에 데이터를 저장하고 
INSERT INTO ... SELECT FROM FILES()
또는 Broker Load 방식을 사용하면 `stream_load`와 유사하게 Upsert(Update + Insert) 로직을 구현할 수 있습니다. 다만, 이는 단순히 로딩 방식의 차이가 아니라 *대상 테이블의 엔진 타입(Primary Key 또는 Unique Key)*에 따라 결정됩니다. 1. Upsert 로직을 위한 테이블 설정 StarRocks에서 Upsert(기존 키가 있으면 업데이트, 없으면 삽입)를 수행하려면 대상 테이블이 다음 중 하나여야 합니다. * Primary Key 테이블 (권장): 실시간 업데이트 성능이 가장 뛰어나며, 
INSERT
시 기본적으로 Upsert로 작동합니다. * Unique Key 테이블: 대량의 배치 업데이트에 적합하며, 동일한 키가 들어오면 기존 데이터를 대체(Replace)합니다. 2. MinIO 데이터를 이용한 Upsert 방법 방법 A: 
INSERT INTO ... SELECT FROM FILES()
(v3.1 이상 권장) 가장 간편한 방법으로, SQL만으로 MinIO의 데이터를 직접 조회해서 넣을 수 있습니다.
Copy code
sql
INSERT INTO your_table
SELECT * FROM FILES(
    "path" = "<s3://your-bucket/data/*.parquet>",
    "format" = "parquet",
    "aws.s3.endpoint" = "<http://minio-endpoint:9000>",
    "aws.s3.access_key" = "your_access_key",
    "aws.s3.secret_key" = "your_secret_key",
    "aws.s3.enable_path_style_access" = "true"
);
* Upsert 작동 방식: `your_table`이 Primary Key 테이블이라면, 위 쿼리 실행 시 동일한 PK를 가진 행은 자동으로 업데이트되고, 새로운 PK는 삽입됩니다. * 부분 업데이트 (Partial Update): v3.3.1 이상의 Primary Key 테이블에서는 
INSERT INTO your_table (col1, col3) SELECT ...
처럼 컬럼을 명시하면 특정 컬럼만 업데이트하는 기능도 지원합니다. 방법 B: Broker Load (대용량/비동기) 매우 큰 대용량 파일을 비동기적으로 로딩할 때 적합합니다.
Copy code
sql
LOAD LABEL my_database.label_1
(
    DATA INFILE("<s3a://your-bucket/data.csv>")
    INTO TABLE your_table
    COLUMNS TERMINATED BY ","
    (id, name, score)
    SET (__op = 'upsert') -- 명시적으로 Upsert임을 지정 가능 (Primary Key 테이블)
)
WITH BROKER
(
    "aws.s3.endpoint" = "<http://minio-endpoint:9000>",
    "aws.s3.access_key" = "your_access_key",
    "aws.s3.secret_key" = "your_secret_key"
);
3. 더 나은 대안: Pipe (연속 로딩) 만약 MinIO에 데이터가 쌓일 때마다 자동으로 로딩되기를 원하신다면 Pipe 기능을 추천합니다. MinIO의 새로운 파일을 감지하여 자동으로 
INSERT
작업을 수행해줍니다. 요약 * 가능 여부: 가능합니다. * 핵심 조건: 데이터를 넣을 테이블이 Primary Key 엔진이어야 합니다. * 추천 방식: 간편한 관리를 원하시면 `INSERT + FILES()`를, 대용량 처리가 필요하면 *Broker Load*를 사용하세요. 더 구체적인 데이터 포맷(CSV, Parquet 등)이나 테이블 스키마를 알려주시면 맞춤형 쿼리 작성을 도와드릴 수 있습니다. References • sql-reference/sql-functions/table-functions/files.md • loading/InsertInto.md • sql-reference/sql-statements/loading_unloading/INSERT.md • loading/Load_to_Primary_Key_tables.md
s
@Rocky stream load사용하려는데 k8s ingress로 요청하면 Expect : 100-continue 가 There is no 100-continue header라고 나오면서 에러나는데
r
Kubernetes Ingress를 통해 StarRocks `stream_load`를 진행할 때 "There is no 100-continue header" 에러가 발생하는 이유는 크게 두 가지입니다. StarRocks는 대용량 데이터 전송 전 서버 상태를 확인하기 위해 
Expect: 100-continue
헤더를 필수적으로 요구하는데, 중간에 있는 Ingress(Nginx 등)가 이 헤더를 처리하는 과정에서 문제가 생기기 때문입니다. 1. StarRocks 버전 및 HTTP/1.0 문제 (버그 확인) StarRocks 특정 버전(v3.1~v3.3 초기 버전)에서 Ingress나 프록시가 요청을 *HTTP/1.0*으로 전달할 경우, StarRocks FE가 
100-continue
헤더를 제대로 인식하지 못하는 버그가 있었습니다. * 해결책: StarRocks 버전을 v3.3.6 이상 또는 최신 패치 버전으로 업데이트하는 것을 권장합니다. (관련 이슈: #52998) 2. Nginx Ingress 설정 (Annotations) Nginx Ingress가 요청을 버퍼링하거나 프로토콜 버전을 낮추면 헤더가 누락될 수 있습니다. Ingress 설정에 다음 Annotation들을 추가해 보세요.
Copy code
yaml
metadata:
  annotations:
    # 1. HTTP/1.1 사용 강제 (100-continue는 1.1 필수)
    <http://nginx.ingress.kubernetes.io/proxy-http-version|nginx.ingress.kubernetes.io/proxy-http-version>: "1.1"
    # 2. 요청 버퍼링 비활성화 (대용량 업로드 시 Ingress 메모리 이슈 방지)
    <http://nginx.ingress.kubernetes.io/proxy-buffering|nginx.ingress.kubernetes.io/proxy-buffering>: "off"
    # 3. 바디 사이즈 제한 해제
    <http://nginx.ingress.kubernetes.io/proxy-body-size|nginx.ingress.kubernetes.io/proxy-body-size>: "0"
    # 4. 타임아웃 연장 (대용량 로딩 시)
    <http://nginx.ingress.kubernetes.io/proxy-read-timeout|nginx.ingress.kubernetes.io/proxy-read-timeout>: "600"
    <http://nginx.ingress.kubernetes.io/proxy-send-timeout|nginx.ingress.kubernetes.io/proxy-send-timeout>: "600"
3. FE Proxy 사용 (권장 방식) StarRocks를 Helm으로 설치하셨다면, 
starrocksFeProxy
설정을 활성화하는 것이 가장 안정적입니다. `stream_load`는 FE에 요청을 보낸 뒤 실제 데이터 전송은 BE로 *HTTP 307 Redirect*가 일어나는데, Ingress 환경에서는 이 리다이렉션 주소(BE IP)를 클라이언트가 찾지 못하는 경우가 많습니다. `values.yaml`에서 다음과 같이 설정하면 전용 프록시(Nginx 기반)가 생성되어 이 문제를 해결해 줍니다.
Copy code
yaml
starrocks:
  starrocksFeProxySpec:
    enabled: true
    service:
      type: LoadBalancer # 또는 NodePort
이후 호출 주소를 `http//&lt;FE PROXY IP&gt;8080/api/...`로 변경하여 테스트해 보세요. 4. 클라이언트(curl) 확인 클라이언트에서 헤더를 명시적으로 보내고 있는지 다시 확인해 주세요.
Copy code
bash
curl --location-trusted -u root:password \
    -H "Expect: 100-continue" \  # 이 헤더가 필수입니다
    -H "label:my_label" \
    -T data.csv \
    -XPUT http://<ingress-host>/api/db/table/_stream_load
요약하자면: 1. 먼저 *버전 업데이트*를 검토하시고, 2. Ingress의 
proxy-http-version: "1.1"
 및 
proxy-buffering: "off"
 설정을 적용해 보시기 바랍니다. 3. 여전히 문제가 있다면 FE Proxy 기능을 활성화를 가장 추천드립니다. References • quick_start/helm.md • sql-reference/sql-statements/loading_unloading/STREAM_LOAD.md • GitHub Issue #52998: stream load failed under HTTP/1.0 References • quick_start/helm.md • sql-reference/sql-statements/loading_unloading/STREAM_LOAD.md • faq/loading/Stream_load_faq.md • loading/StreamLoad.md
s
@Rocky starrocks internal catalog에 압축옵션 ZSTD, LZ4의 차이를 상세하게 설명해주고 어떤 상황에서 어떤 옵션을 추천하는지 상세하게 설명해줘
r
StarRocks Internal Catalog(내부 테이블)에서 데이터를 저장할 때 사용하는 *LZ4*와 *ZSTD*는 성능과 효율성 측면에서 뚜렷한 차이가 있습니다. 각 옵션의 상세 비교와 상황별 추천 가이드를 정리해 드립니다. 1. LZ4 (기본값) "속도 최우선" 알고리즘입니다. * 압축률: 상대적으로 낮음 (데이터 크기가 많이 줄어들지 않음). * 속도: 매우 빠름. 압축 및 압축 해제 시 CPU 리소스를 최소한으로 사용하며 처리량이 매우 높습니다. * 특징: StarRocks의 기본(Default) 압축 알고리즘으로, 디스크 I/O보다 CPU 연산 성능이 중요한 환경에 최적화되어 있습니다. 2. ZSTD (Zstandard) "균형 및 효율성" 알고리즘입니다. * 압축률: 높음 (LZ4보다 훨씬 높은 압축률을 제공하여 디스크 공간을 절약). * 속도: 중간. 압축 해제 속도는 빠르지만, 압축 시에는 LZ4보다 더 많은 CPU를 사용합니다. * 특징: v3.3.2 버전부터는 `zstd(3)`와 같이 압축 레벨(1~22)을 지정할 수 있습니다. 레벨이 높을수록 압축률은 올라가지만 CPU 소모와 시간이 증가합니다 (기본 레벨 3 권장). ────────── 3. 상세 비교 테이블 구분 | LZ4 | ZSTD 압축 성능 (Speed) | 매우 빠름 (최고 성능) | 보통 (CPU 소모량 높음) 압축률 (Ratio) | 보통 | 우수함 압축 해제 속도 | 매우 빠름 | 빠름 권장 환경 | 성능 민감형, CPU 부하가 높은 시스템 | 비용 절감형, 디스크 I/O 병목 시스템 주요 목적 | 최소 지연 시간 (Latency) | 저장 공간 절약 및 I/O 효율성 ────────── 4. 상황별 추천 옵션 LZ4를 추천하는 경우 1. 실시간 대시보드 및 초저지연 쿼리: 쿼리 응답 속도(Latency)가 가장 중요한 서비스인 경우. 2. CPU 리소스가 부족한 경우: 이미 CPU 사용률이 높은 클러스터에서는 압축/해제 부하를 최소화해야 합니다. 3. 데이터가 이미 압축하기 어려운 형태인 경우: 고유 ID나 난수 등으로 구성되어 압축 효율이 낮은 데이터라면 속도가 빠른 LZ4가 유리합니다. 4. 일반적인 워크로드: 특별한 저장 공간 문제가 없다면 기본값인 LZ4를 그대로 사용하는 것이 가장 안정적입니다. ZSTD를 추천하는 경우 1. 디스크 저장 비용 절감이 절실한 경우: 데이터 양이 매우 많아 스토리지 비용을 줄여야 할 때 효과적입니다. 2. Cold Data(과거 데이터) 저장: 자주 조회하지 않는 대규모 로그성 데이터를 저장할 때 유리합니다. 3. 디스크 I/O 병목이 발생하는 경우: 디스크 읽기 속도가 느린 환경(예: 클라우드 표준 HDD 등)에서는 데이터를 더 많이 압축해서 읽는 양 자체를 줄이는 것이 오히려 전체 쿼리 속도를 높일 수 있습니다. 4. 높은 압축률이 필요한 특정 컬럼군: 중복도가 높은 문자열 데이터가 많은 테이블에서 큰 효과를 볼 수 있습니다. ────────── 5. 설정 방법 (CREATE TABLE) 테이블 생성 시 `PROPERTIES`를 통해 지정할 수 있습니다.
Copy code
sql
-- LZ4 사용 (또는 명시하지 않으면 기본 적용)
CREATE TABLE my_table ( ... )
DISTRIBUTED BY HASH(id)
PROPERTIES (
    "compression" = "LZ4"
);

-- ZSTD 사용 (v3.3.2+ 부터 레벨 지정 가능)
CREATE TABLE my_table_zstd ( ... )
DISTRIBUTED BY HASH(id)
PROPERTIES (
    "compression" = "zstd(3)"
);
결론적으로: 쿼리 성능이 최우선이라면 LZ4, 비용 효율성과 스토리지 절약이 중요하다면 *ZSTD*를 선택하십시오. References • table_design/data_compression.md • sql-reference/sql-statements/table_bucket_part_index/CREATE_TABLE.md • administration/management/BE_configuration.md • knowledge/usage/best-practice.md References • table_design/data_compression.md • administration/management/BE_configuration.md • knowledge/usage/best-practice.md • sql-reference/sql-statements/table_bucket_part_index/CREATE_TABLE.md • loading/loading_introduction/feature-support-loading-and-unloading.md
s
@Rocky 3.5.*, 4.0.4 에서 Internal Catalog + Mview 사용시 버그가 있어서 FE 메타데이터에 문제가 발생하고있다는데 어떤 이슈야
r
당시 언급하신 StarRocks *3.5.x 시리즈 및 4.0.4 버전*에서 발생하는 Internal Catalog와 Materialized View(MV) 관련 메타데이터 이슈는 주로 FE(Frontend)의 메타데이터 불일치 및 재시작 실패(Crash) 현상과 관련이 있습니다. 가장 핵심적인 이슈는 크게 두 가지로 요약됩니다. 1. FE Leader와 Follower 간의 메타데이터 불일치 (Inconsistency) * 이슈 내용: Internal Catalog의 테이블을 기반으로 MV를 생성하거나 관리할 때, FE Leader 노드와 Follower 노드 사이에서 MV의 태블릿 메타데이터(Tablet Meta) 정보가 동기화되지 않는 버그가 보고되었습니다. (#69428 등) * 증상: * Leader에서는 MV 상태가 정상이지만, Follower에서는 조회가 안 되거나 데이터가 누락된 것처럼 보입니다. * 메타데이터 저널(Journal) 재생 과정에서 오류가 발생하여 Follower FE가 비정상 종료되거나 다시 뜨지 않는 상황이 발생할 수 있습니다. 2. 버전 간 다운그레이드 시 메타데이터 호환성 및 Crash * 이슈 내용: 4.0.x 버전(특히 4.0.4 전후)에서 메타데이터 구조에 변경이 있었는데, 이를 3.5.0 또는 3.5.1과 같은 초기 버전으로 *직접 다운그레이드*할 경우 메타데이터 형식이 호환되지 않아 FE가 즉시 Crash되는 문제가 있습니다. * 영향: 4.0 버전 사용 중 문제가 생겨 3.5 버전으로 복구하려 할 때, *3.5.2 이전 버전*으로 가면 메타데이터가 파손될 위험이 큽니다. (최소 3.5.2 이상으로 다운그레이드해야 안전합니다.) 3. 기타 관련 이슈 (3.5.x 버전대 공통) * 인덱스 속성 유실: MV 리라이트(Rewrite) 과정에서 캐시된 실행 계획의 컨텍스트 메모리 누수나, 특정 상황에서 테이블 인덱스 속성이 유실되는 버그가 포함되어 있습니다. (#69187) * 주간 파티션(Week-partition) 갱신 실패: 3.5.0 이상 버전에서 `date_trunc('week', ...)`로 파티셔닝된 MV가 정상적으로 갱신되지 않는 버그가 보고되기도 했습니다. (#65983) 권장 조치 사항 해당 현상을 겪고 계시거나 방지하려면 다음과 같은 조치가 필요합니다. 1. 최신 패치 버전 업데이트: * 3.5.x 계열을 사용 중이라면 *3.5.8 이상*의 최신 버전으로 업데이트하세요. 위에서 언급된 대부분의 메타데이터 불일치 및 리플레이 오류가 수정되었습니다. * 4.0.x 계열의 경우 4.0.11 이상 버전에서 안정성이 크게 개선되었습니다. 2. 메타데이터 체크포인트 생성: 업데이트나 설정 변경 전에는 반드시 
ALTER SYSTEM CREATE IMAGE;
명령을 통해 최신 메타데이터 이미지를 생성하고 백업해 두는 것이 안전합니다. 3. 시스템 변수 확인: 특정 상황에서 
enable_rewrite_simple_agg_to_meta_scan
변수가 메타데이터 스캔 시 문제를 일으킬 수 있으므로, 이슈 발생 시 해당 설정을 `false`로 바꾸어 테스트해 볼 수 있습니다. 만약 이미 FE가 뜨지 않는 상황이라면, `fe.conf`에 
metadata_ignore_unknown_operation_type = true
옵션을 추가하여 강제로 메타데이터를 로드한 뒤 이미지를 새로 생성하는 복구 절차가 필요할 수 있습니다. (StarRocks 공식 가이드 참고) 할 수 있습니다. References • release_notes/release-3.5.md • release_notes/release-4.0.md • administration/management/metadata_management.md • faq/metadata/Metadata_faq.md References • release_notes/release-3.5.md
s
@Rocky 4.1.2버전에서는 해결된건지 확인해줘
r
결론부터 말씀드리면, *StarRocks v4.1.2 버전에서는 해당 메타데이터 불일치 및 FE Crash 이슈들이 대부분 해결된 상태*입니다. 질문하신 v3.5.x 및 v4.0.4 대에서 발생했던 Internal Catalog와 MV 관련 핵심 버그들의 해결 여부를 정리해 드립니다. *1. FE Leader-Follower 메타데이터 불일치 (#69428) - 해결됨* 가장 치명적이었던 "MV 태블릿 메타데이터가 Leader와 Follower 간에 동기화되지 않아 FE가 리플레이(Journal Replay) 중 Crash되거나 데이터 정합성이 깨지는 문제"는 v3.5.13 및 v4.0.11 버전에서 공식적으로 수정되었습니다. * *v4.1.2*는 이보다 상위 패치들이 모두 포함된 버전이므로 해당 이슈로부터 안전합니다. *2. 특정 조건에서의 FE Crash 및 리플레이 오류 - 해결됨* v3.5.0~3.5.1 및 v4.0.4 초기 버전에서 메타데이터 구조 변경으로 인해 발생했던 호환성 버그들 역시 v4.1대에서는 구조적으로 안정화되었습니다. * 특히 MV 리프레시(Refresh) 과정에서 발생하던 NPE(NullPointerException)나 메타데이터 손상 버그들이 v4.1.1과 v4.1.2를 거치며 대거 수정되었습니다. 3. v4.1.2 사용 시 주의사항 (중요) 비록 버그는 해결되었으나, v4.1대로 업데이트하거나 운영하실 때 다음 사항을 꼭 확인하세요. * 다운그레이드 제한: v4.1 버전은 태블릿 분할(Tablet Splitting) 및 배포 메커니즘 등 내부 데이터 레이아웃에 변경이 있습니다. 따라서 *v4.1에서 v4.0.6 미만 버전이나 v3.5.x 초기 버전으로 직접 다운그레이드하는 것은 절대 금지*됩니다. (메타데이터 호환성 문제로 FE가 다시 뜨지 않을 수 있습니다.) * 권장 설정: 만약 업데이트 후에도 MV 관련 쿼리 리라이트에서 메타데이터 스캔 이슈가 우려된다면, 
SET GLOBAL enable_rewrite_simple_agg_to_meta_scan = false;
설정을 통해 안정성을 우선 확보할 수 있습니다. 요약하자면: v4.1.2는 질문하신 v3.5/4.0.4 시절의 고질적인 메타데이터 버그들이 수정된 안정적인 릴리스입니다. 안심하고 업데이트를 검토하셔도 좋으나, 만약의 상황에 대비해 업데이트 전 `ALTER SYSTEM CREATE IMAGE;`를 통해 *메타데이터 스냅샷(Image)을 반드시 생성*하고 진행하시길 권장합니다. References • release_notes/release-3.5.md (v3.5.13 fix list) • release_notes/release-4.0.md (v4.0.11 fix list) • release_notes/release-4.1.md (v4.1 upgrade/4.1.1 behavior changes) • administration/management/metadata_management.md References • release_notes/release-3.4.md • release_notes/release-3.5.md
2 Views
Open in Slack
PreviousNext
Powered by