http://starrocks.io logo
Join Slack
Powered by
<@U0A71G31CDV> Starrock FE+CN조합으로 Minio에 연결되어있는데, ...
# questions-and-troubleshooting
s
@Rocky Starrock FE+CN조합으로 Minio에 연결되어있는데, Internal catalog가 어떤 경로에 데이터가 저장되고있는지 알 수 있어?>
r
StarRocks의 FE+CN 조합과 MinIO를 함께 사용 중이라면, 이는 *Shared-data(데이터 공유) 모드*로 운영되고 있는 것입니다. 이 경우 Internal Catalog(내부 OLAP 테이블)의 데이터는 로컬 디스크가 아닌 MinIO에 저장됩니다. 정확한 데이터 저장 경로를 확인하는 방법은 다음과 같습니다. 1. SQL을 통한 확인 (가장 확실한 방법) StarRocks v3.1 이상을 사용 중이라면 
STORAGE VOLUME
명령어나 `SHOW PROC`을 통해 물리적 경로를 직접 확인할 수 있습니다. * 전체 저장소 경로 확인:
Copy code
sql
    SHOW STORAGE VOLUMES;
    -- 기본으로 생성된 'builtin_storage_volume'의 상세 정보를 확인합니다.
    DESC STORAGE VOLUME builtin_storage_volume;
결과의 
Location
항목에서 
<s3://버킷명/경로/>
형태의 주소를 확인할 수 있습니다. * 특정 테이블의 물리적 경로 확인: 먼저 해당 데이터베이스의 ID를 알아낸 뒤 
SHOW PROC
명령어를 사용합니다.
Copy code
sql
    -- 1. DB ID 확인 (예: 'my_db'가 10001인 경우)
    SHOW PROC "/dbs";

    -- 2. 해당 DB 내 테이블들의 정보 확인
    SHOW PROC "/dbs/10001";
출력 결과의 
StoragePath
 컬럼에서 해당 테이블의 데이터가 MinIO의 어느 경로(예: `s3://bucket/path/10001/10002/`)에 저장되어 있는지 정확히 알 수 있습니다. 2. FE 설정 파일 (
fe.conf
) 확인 클러스터 배포 시 설정한 내용을 통해 경로를 유추할 수 있습니다. * 
fe.conf
파일 내 다음 파라미터를 확인하세요: * `aws_s3_path`: 데이터가 저장되는 버킷 이름과 하위 경로가 정의되어 있습니다. (예: 
my-bucket/starrocks
) * `aws_s3_endpoint`: 연결된 MinIO의 접속 주소입니다. 3. 참고: CN의 로컬 경로는 '캐시' 용도입니다. CN 노드의 `cn.conf`에 설정된 `storage_root_path`는 실제 영구 데이터 저장소가 아니라, 성능 향상을 위한 로컬 캐시(Starlet Cache) 경로입니다. * 기본 경로: 
<starrocks_home>/storage/starlet_cache
* 이곳에는 MinIO에서 불러온 데이터의 일부가 임시로 저장되며, 실제 데이터 원본은 항상 MinIO에 존재합니다. 요약하자면: 실제 데이터 경로는 
DESC STORAGE VOLUME
또는 
SHOW PROC "/dbs/<db_id>"
명령어를 통해 SQL에서 바로 확인하시는 것이 가장 정확합니다. References • sql-reference/sql-statements/cluster-management/storage_volume/SHOW_STORAGE_VOLUMES.md • sql-reference/sql-statements/cluster-management/storage_volume/DESC_STORAGE_VOLUME.md • sql-reference/sql-statements/Database/SHOW_DATA.md • sql-reference/sql-statements/cluster-management/storage_volume/CREATE_STORAGE_VOLUME.md
s
@Rocky Starrocks FE, CN 조합에서 S3경로에 ~/112/meta/00000000000002784_00000000000000002.meta 데이터를 직접까보고싶은데 어떻게하면돼?
r
S3(MinIO)에 저장된 
.meta
파일은 StarRocks의 *Lake Storage(Starlet) 전용 바이너리 포맷*으로 되어 있어, 일반적인 텍스트 에디터나 
cat
명령어로 직접 내용을 확인하기 어렵습니다. 이 메타데이터의 내용을 확인하고 싶다면, StarRocks 내부 명령어를 사용하여 *JSON 형태로 변환해 출력*하는 것이 가장 빠르고 정확한 방법입니다. 확인 방법: 
admin execute
사용 제공해주신 파일 경로 `.../meta/00000000000002784_00000000000000002.meta`를 통해 다음 정보를 알 수 있습니다. * Tablet ID: 2784 * Version: 2 이 정보를 바탕으로 아래 SQL을 실행하면 해당 메타데이터의 상세 정보(세그먼트 파일 목록, 버전 정보 등)를 볼 수 있습니다.
Copy code
sql
-- 1. 먼저 실행할 CN(Compute Node)의 ID를 확인합니다.
SHOW BACKENDS; -- 또는 SHOW COMPUTE NODES;

-- 2. 확인한 <backend_id>를 넣어 아래 명령어를 실행합니다.
ADMIN EXECUTE ON <backend_id> 
'System.print(StorageEngine.get_lake_tablet_metadata_json(2784, 2))';
결과에서 확인할 수 있는 정보 위 명령어를 실행하면 다음과 같은 구조의 JSON 데이터를 얻게 됩니다. * Table ID / Partition ID: 해당 태블릿이 속한 테이블 정보 * Version: 해당 메타데이터가 가리키는 데이터 버전 * Segments: 해당 버전에서 참조하고 있는 실제 데이터 파일(
.shared_data
) 리스트 * Compaction Score: 컴팩션 상태 등 주의사항 * 파일 직접 수정 금지: S3에 있는 
.meta
파일을 수동으로 수정하거나 이동하면 데이터 정합성이 깨져 해당 테이블을 읽지 못하게 될 수 있습니다. * 접근 권한: FE/CN이 MinIO에 접근할 수 있는 권한이 있어야 위 명령어가 정상 작동합니다. 만약 파일이 너무 많아 특정 테이블의 메타데이터를 찾고 계신 것이라면, 
SHOW PROC '/dbs/<db_id>/<table_id>/partitions/<partition_id>/<index_id>';
명령어를 통해 해당 테이블에 속한 Tablet ID 리스트를 먼저 확인하시는 것이 좋습니다. References • faq/shared_data_faq.md • deployment/shared_data/s3.md • administration/Meta_recovery.md References • faq/shared_data_faq.md • data_source/catalog/iceberg/iceberg_meta_table.md • knowledge/admin_and_operation/shared_data_garbage_cleanup.md • data_source/feature-support-data-lake-analytics.md
s
python으로 읽고싶어
@Rocky python으로 .meta파일 읽을수는 없나
r
.meta
파일은 StarRocks의 내부 포맷(Protobuf)으로 직렬화된 바이너리 파일이기 때문에, Python으로 직접 읽으려면 *StarRocks 소스 코드에 포함된 
.proto
정의 파일*이 필요합니다. 일반적인 텍스트나 JSON처럼 쉽게 열리지 않으며, 직접 구현하려면 다음과 같은 과정이 필요합니다. 1. 필요한 Protobuf 정의 파일 StarRocks의 Lake Storage(Shared-data) 메타데이터는 주로 다음 파일들에 정의되어 있습니다. (StarRocks GitHub 저장소 기준) * 
gensrc/proto/lake_types.proto
* 
gensrc/proto/tablet_meta.proto
이 파일들을 Python에서 사용하려면 
protoc
컴파일러를 사용하여 Python 클래스 파일로 변환해야 합니다. 2. Python으로 읽는 대략적인 흐름 (복잡함) 만약 반드시 Python으로 처리해야 한다면 다음과 같은 구조가 됩니다.
Copy code
python
# 1. protoc로 생성된 python 모듈 임포트 (예시)
import lake_types_pb2 

def read_meta_file(file_path):
    # 2. S3/MinIO에서 .meta 바이너리 파일을 다운로드하여 읽음
    with open(file_path, "rb") as f:
        binary_data = f.read()
    
    # 3. Protobuf 메시지 객체 생성 및 파싱
    tablet_meta = lake_types_pb2.TabletMetadataPB()
    tablet_meta.ParseFromString(binary_data)
    
    # 4. 내용 출력 (JSON 형태 등으로 변환 가능)
    print(tablet_meta)

# 주의: 실제로는 여러 proto 파일 간의 의존성 때문에 설정이 매우 까다롭습니다.
3. 더 쉬운 대안 (추천) 위의 방법은 개발 환경 구축이 매우 번거롭습니다. 대신 다음 두 가지 방법을 권장합니다. * 방법 A: SQL 결과 파싱 (권장) 이전 답변에서 안내해 드린 
ADMIN EXECUTE
명령은 결과를 *JSON 문자열*로 반환합니다. Python에서 StarRocks에 쿼리를 날려 그 JSON 결과값만 받아 `json.loads()`로 처리하는 것이 가장 효율적입니다.
Copy code
python
    # 예시: pymysql 등을 사용하여 쿼리 실행
    cursor.execute("ADMIN EXECUTE ON <backend_id> 'System.print(StorageEngine.get_lake_tablet_metadata_json(2784, 2))'")
    result_json = cursor.fetchone()[0]
* 방법 B: 
starrocks-debug
도구 활용 StarRocks 바이너리 패키지에는 메타데이터를 분석하는 디버깅 도구들이 포함되어 있는 경우가 있습니다. 하지만 이 역시 커맨드라인 도구이므로 Python에서 직접 호출하는 것보다는 SQL을 통한 확인이 가장 표준적입니다. 결론: 
.meta
파일은 Protobuf 형식이 맞으므로 Python으로 읽을 수는 있지만, StarRocks 내부 구조에 대한 깊은 이해와 
.proto
파일 컴파일 과정이 필요합니다. 따라서 *`ADMIN EXECUTE ... get_lake_tablet_metadata_json` 명령어를 통해 JSON 결과를 얻는 방식*을 가장 추천합니다. References • faq/shared_data_faq.md • administration/Meta_recovery.md • administration/Management.md References • data_source/catalog/iceberg/iceberg_meta_table.md • faq/shared_data_faq.md
5 Views
Open in Slack
PreviousNext
Powered by