EMR Serverless StarRocks, Paimon 2.0 전면 지원…통합 분석·검색

저자: 판전(范振), StarRocks TSC Member; 알리바바 클라우드 오픈소스 OLAP 책임자

알리바바 클라우드 EMR Serverless StarRocks는 실시간 데이터 웨어하우스와 레이크하우스 분석을 위한 완전관리형 서비스이며, Stella는 그 기업용 커널이다. 기업이 개방형 데이터 레이크에서 제기하는 쿼리 요구에 맞춰, Stella는 스토리지·컴퓨팅 분리 아키텍처와 데이터 읽기, 캐시, 쿼리 실행을 지속적으로 최적화하여, 레이크에 보관된 데이터를 대화형 쿼리와 다중 테이블 조인, 비즈니스 분석에 바로 활용할 수 있게 한다. 레이크 내 데이터 유형과 사용 방식이 계속 확장됨에 따라, Stella는 레이크 분석 역량을 다시 멀티모달 검색과 AI 데이터 준비로까지 확장하고 있다.

이 방향은 StarRocks가 Lakehouse에 오랫동안 투자해 온 흐름을 잇는다. 2023년 "From OLAP to Lakehouse" 기술 노선을 제시한 이래, 커뮤니티는 Delta Lake, Iceberg, Paimon 등 개방형 레이크 테이블에 대한 지원을 지속적으로 고도화해 왔다. 이러한 레이크 쿼리 요구를 둘러싸고 축적된 SQL 최적화와 분산 실행, 데이터 캐시 역량은 Stella가 클라우드에서 더 큰 규모와 더 다양한 유형의 분석 부하를 감당할 수 있는 기반을 마련해 주었다.

오늘날 레이크에서 분석하는 대상은 확대되고 있다. 영상, 이미지, 오디오, 문서, 센서 기록이 주문, 로그, 태그, 평가 지표와 함께 계산 과정에 들어와야 한다. 모델은 이런 내용의 의미를 추출할 수 있고, 기업에는 새로운 데이터 활용 방식이 생겼다. 즉 콘텐츠를 기반으로 샘플을 발견하고, 비즈니스 기록을 연관 지어 결과를 해석하며, 선별한 데이터를 다시 훈련과 평가로 보내는 것이다. Paimon 2.0은 실시간 레이크 테이블을 기반으로 데이터 관리, 피처 가공, 인덱스 검색을 더욱 연결하며, 쿼리 엔진이 대규모 분석과 저지연 검색을 동시에 처리하도록 요구한다.

Paimon과 StarRocks는 이미 알리바바 그룹의 핵심 비즈니스에서 대규모로 적용되었다. 타오톈의 대규모 분석, 가오더의 궤적 서비스부터 AI Data 플랫폼의 멀티모달 하이브리드 검색과 훈련 데이터 준비에 이르기까지, 이 조합은 이미 다양한 핵심 비즈니스를 아우른다. 퍼블릭 클라우드에서는 EMR Serverless StarRocks가 관련 기술 축적을 지속적으로 제품 역량으로 전환하며, 여러 업계의 레이크하우스 분석 요구를 지원한다. 그룹 내부의 대규모 적용과 퍼블릭 클라우드 고객의 지속적인 피드백은 Stella와 Paimon이 멀티모달 시나리오에서 협력하는 실천적 기반을 제공한다.

구조화 분석에서 멀티모달 검색으로 확장하는 것은 쿼리 엔진에 새로운 기술 과제를 안겨준다. 대규모 컬럼 스캔 외에도, 시스템은 인덱스에 접근하고 후보를 병합하며, 희소한 row ID를 기반으로 데이터를 다시 가져와야 한다. Paimon 2.0을 둘러싸고, Stella는 벡터 및 전문 검색, 스칼라 사전 필터링, BLOB 읽기 및 캐시 역량을 레이크 쿼리 경로에 연결하여, 컬럼형 분석과 인덱스 검색이 동일한 SQL 실행 아키텍처로 들어오게 한다. 이 글은 Paimon 2.0의 데이터 조직에서 출발하여, 분석과 검색의 실행 경로, 엔진 적응, 그리고 실제 사용에서의 데이터 관리와 유지보수 방법을 소개한다.

Paimon 2.0: 멀티모달 데이터 레이크의 시나리오와 기술적 기반

과거의 레이크하우스 분석은 주로 비즈니스 기록을 중심으로 구축되었다. 데이터는 수집, 정제, 모델링을 거쳐 필터링, 연관, 집계가 가능한 테이블을 형성했다. 멀티모달 애플리케이션은 이러한 요구를 유지하면서 동시에 원본 콘텐츠를 분석 대상으로 포함한다. 한 번의 운전 이상은 하나의 이벤트 기록에 대응하면서, 동시에 영상 속 특정 장면, 주변의 포인트 클라우드, 차량 상태에도 대응한다. 이벤트 테이블만 봐서는 모델이 왜 바로 그 순간에 잘못된 판단을 내렸는지 설명하기 어렵다.

공개 데이터셋은 이미 이러한 변화의 규모를 보여준다. Waymo Open Motion Dataset은 2025년 10월 공식 설명에서 103,354개의 20초 시나리오 clips를 포함하며, 목표 궤적, 지도, 이미지 임베딩 등의 정보를 연관 짓는다. Google DeepMind가 2023년 발표한 Open X-Embodiment는 22종 로봇의 100만 개가 넘는 과제 episodes를 모아 놓았다. 이런 데이터에서 한 번의 관측이 지니는 의미는 앞뒤 시계열, 주변 환경, 과제 목표에 따라 달라진다. 따라서 샘플 정리는 콘텐츠, 관계, 버전을 동시에 처리해야 한다.

실제 비즈니스에서 이런 데이터 조직 요구는 보통 콘텐츠 검색, 샘플 선별, 비즈니스 분석과 결합된다. 다음은 몇 가지 대표적인 업계 시나리오를 골라 설명한다.

자율주행: 어려운 사례 검색과 문제 재검토

비 오는 밤의 한 번의 운전 이상에서 출발하여, 유사한 화면을 검색하고, 차종과 소프트웨어 버전을 한정하며, 다시 도로 조건과 포인트 클라우드, 차량 상태를 연관 지어 공통 문제를 조사한다. 검색 결과는 재검토와 보완 레이블링이 가능한 샘플 세트를 형성하여 모델 평가와 훈련 보충 샘플에 사용된다.

임바디드 AI(具身智能): 과제 검색과 정책 평가

한 번의 로봇 삽입 실패에서 출발하여, 유사한 시각 상태와 동작 궤적을 검색하고, 과제 유형과 정책 버전을 한정하며, 다시 접촉력과 실행 결과를 연관 지어 실패 원인을 분석한다. 검색 결과는 재생과 비교가 가능한 과제 샘플을 형성하여 정책 평가와 데이터 보충 수집에 사용된다.

광고: 소재 검색과 효과 분석

한 그룹의 고전환 광고에서 출발하여, 구도, 상품, 스타일이 유사한 소재를 검색하고, 게재 지역과 캠페인 기간을 한정하며, 다시 노출, 클릭, 전환 지표를 연관 지어 서로 다른 콘텐츠 특성의 성과를 비교한다. 검색 결과는 효과 지표를 지닌 소재 집합을 형성하여 크리에이티브 반복 개선과 게재 테스트에 사용된다.

게임: 에셋 검색과 버전 관리

하나의 캐릭터나 장면 디자인 요구에서 출발하여, 참조 이미지나 텍스트 설명으로 유사한 에셋을 검색하고, 프로젝트와 버전을 한정하며, 다시 라이선스 정보와 출시 기록을 연관 지어 재사용 조건을 확인한다. 검색 결과는 추적 가능한 에셋 목록을 형성하여 연구개발 협업과 에셋 재사용에 사용된다.

멀티모달 데이터는 규모가 크고 반복이 잦으므로, 저비용 저장과 데이터 일관성은 여전히 기본 요구 사항이다. Lakehouse는 데이터를 객체 스토리지에 보관하고, 서로 다른 작업이 동일한 Snapshot에서 읽을 수 있게 하여 데이터 이전과 사본 유지 관리를 줄인다. Paimon 2.0은 실시간 레이크 테이블을 기반으로 원본 미디어를 장기 보존하고 태그와 벡터를 지속적으로 채워 넣어, 동일한 테이블이 피처 가공, 검색, 분석, 훈련을 뒷받침하게 한다.

Paimon 2.0의 핵심 역량과 구현

이 글은 Row Tracking과 Data Evolution을 활성화한 멀티모달 Append 테이블을 중점적으로 논의하며, 그 핵심 역량과 구현은 다음과 같다:

역량과 구성 | 구현 요점 | 쿼리와 가공에서의 역할 Catalog와 테이블 metadata | Schema, Snapshot, manifest-list와 manifest로 테이블을 발견하고, 읽기 버전을 고정하며, 가시 파일과 인덱스를 확정 | - Data Evolution | 업데이트된 열은 새 파일에 기록하고, 변경되지 않은 열은 재사용 | 열 단위로 특징을 백필하고, 읽을 때 원본 열과 업데이트된 열을 조합 Row Tracking | _ROW_ID로 레코드를 식별하고, _SEQUENCE_NUMBER로 버전을 식별 | 특징과 원본 샘플을 정렬하고, 인덱스 결과와 데이터 위치를 연결 BLOB과 VECTOR | 미디어, 벡터와 일반 열을 각각 조직 가능 | 필요할 때만 읽어, 관련 없는 미디어 콘텐츠의 부수적 로딩을 회피 Global Index | 스칼라, 벡터, 전문 인덱스 및 그 커버리지 범위 | 후보 row ID 또는 점수를 제공하고, 조건 조합, 병합과 재조회를 지원 PyPaimon | Python 읽기/쓰기와 열 백필, Ray, PyTorch 연결 | 특징 가공, 학습 데이터 준비와 SQL 분석이 호수 테이블을 공유하게 함

- 주행 프레임 예시: 원본 미디어에서 검색 가능한 특징까지

하나의 주행 프레임 레코드는 점진적으로 특징을 보충할 수 있다. 최초 기록 시 수집 시간, 차종 등 속성은 일반 열로 저장되고, 원본 미디어는 BLOB을 통해 독립적으로 저장되며, Row Tracking이 레코드에 row ID를 할당한다. 모델이 계산을 완료한 후 동일한 row ID를 가지고 Data Evolution을 통해 라벨, 평가 결과와 벡터를 백필한다. 라벨과 점수는 일반 열에 기록되고, 이 예시의 벡터는 별도로 조직된 VECTOR 파일을 사용하며, 변경되지 않은 비즈니스 속성과 미디어 파일은 계속 재사용된다.

라벨과 벡터는 각각 스칼라, 벡터 Global Index를 구축할 수도 있다. 쿼리가 Snapshot을 선택한 후, Paimon은 해당 버전에서 가시적인 파일과 사용 가능한 인덱스를 사용하여 필요에 따라 열 데이터를 조합한다. 원본 콘텐츠와 나중에 백필된 특징은 여전히 같은 테이블에 속하며, StarRocks는 SQL을 통해 검색, 연관과 분석을 완료할 수 있다.

StarRocks와 Paimon 2.0: 동일한 아키텍처로 분석과 검색을 수행

Delta Lake, Iceberg에서 Paimon에 이르기까지 StarRocks는 이미 크로스 포맷의 metadata 관리, SQL 계획, 분산 실행과 데이터 캐시 역량을 축적해왔다. 멀티모달 레이크하우스는 이러한 기반을 계속 활용할 수 있다. 비즈니스 분석에는 여전히 Join, 집계와 정렬이 필요하고, 오브젝트 스토리지 접근에는 I/O 제어가 필요하며, 동시 쿼리에는 리소스 관리가 필요하다. Paimon 2.0의 Global Index는 쿼리 계획에 인덱스 접근 경로를 추가한다.

StarRocks의 Paimon 지원은 벡터와 전문 검색, 스칼라 사전 필터링, BLOB 읽기 및 캐시 통합을 포괄한다. 쿼리는 먼저 시간, 차종과 라벨 등의 조건을 통해 후보를 좁힌 뒤 유사도 또는 키워드 검색을 수행할 수 있다. 적중된 결과는 계속해서 비즈니스 레코드와 연관되어 통계 분석을 완료한다. 데이터는 Paimon 테이블에 남아 있고, 검색과 분석은 테이블 버전과 쿼리 실행 역량을 공유한다.

Global Index의 스칼라 조건은 row ID 집합을 생성하고 AND, OR 등의 관계로 조합할 수 있다. 벡터 인덱스와 전문 인덱스는 또한 후보 점수를 생성하여 병합과 순위 지정에 사용한다. 스칼라 후보 집합은 벡터 검색의 prefilter로도 사용할 수 있다. StarRocks는 쿼리 의미와 비용에 따라 열 스캔 또는 인덱스 접근을 선택하고, 후보 병합과 열 데이터 읽기를 배치한다.

그림 속 두 경로는 최종적으로 모두 관계형 계산으로 진입한다. Paimon은 테이블 버전, 행 신원, 열 파일과 인덱스 조직을 담당하고, StarRocks는 SQL 계획, 병렬 실행, 캐시와 리소스 관리를 담당한다. 하나의 다중 테이블 쿼리는 스캔과 인덱스 접근을 동시에 사용할 수 있으며, Filter, Join, TopK와 지연 구체화(late materialization)의 실제 순서는 쿼리 계획에 따라 결정된다.

OLAP에서 Search로: 쿼리 실행의 중심이 변화하다

OLAP: data skipping을 통해 열 스캔 범위를 축소

metadata 프루닝 → 병렬 열 스캔과 필터링 → Join, 집계와 정렬

스캔 위주인 호수상 OLAP 쿼리는 일반적으로 먼저 파티션 정보, 파일 metadata 내 min/max 등 통계 정보를 활용하여 조건을 충족할 수 없는 데이터 파일을 건너뛴다. 후보 파일을 읽을 때 reader는 row group, page 등 더 세밀한 통계 정보를 활용해 계속 프루닝할 수 있다. 이러한 data skipping은 데이터 범위의 요약에 근거하여 읽기량을 줄이지만, 남겨진 데이터는 여전히 읽어서 행 단위 필터링을 수행해야 한다.

실행 엔진은 파일 또는 파일 내 데이터 범위 단위로 병렬 읽기 작업을 조직하고, 필요에 따라 열을 읽고, 일괄 디코딩과 필터링을 수행한 후 결과를 Join, 집계, 정렬 등의 연산자로 보낸다. 이 경로는 흔히 리포트, 시나리오 통계와 비교적 넓은 범위의 연관 분석에 사용되며, 최적화의 중점은 스캔 바이트 수를 줄이고, 일괄 읽기와 계산 처리량을 향상시키며, 각 실행 노드가 비슷한 작업량을 부담하게 하는 것이다.

Search: 먼저 인덱스를 검색한 뒤, 희소 row ID로 재조회

인덱스 검색 → 후보 조합 또는 순위 지정 → row ID 위치 확인 → 필요에 따른 재조회와 후속 계산

Search workload는 인덱스를 진입점으로 삼아, 쿼리 조건 또는 벡터에 따라 후보 레코드를 찾는다. 스칼라 검색은 일반적으로 row ID 집합을 출력하고, 벡터 검색은 거리 또는 점수도 출력한다. 실행 엔진은 조건을 조합하고 후보를 병합한 뒤, 필요에 따라 필요한 열을 가져와 관계형 계산에 계속 참여시킨다.

재조회 시 Paimon은 쿼리 snapshot의 row ID metadata에 따라 관련 데이터 파일을 찾고, reader가 필요한 열을 읽는다. Data Evolution 테이블의 경우 동일한 레코드의 열이 여러 파일에서 올 수 있으므로, 행 신원과 버전에 따라 조합해야 한다. 희소 후보는 읽기 대상을 축소할 수 있지만, 실제 비용은 적중한 파일 수, 투영 열과 캐시 상태에 따라 달라진다.

StarRocks의 실행 적응

검색과 재조회의 협업 스케줄링

StarRocks의 기존 분산 실행과 데이터 캐시는 Paimon 쿼리에 병렬 스케줄링의 기반을 제공한다. 벡터와 전문 인덱스는 index shard 단위로 검색 작업을 조직할 수 있고, 결과의 row ID는 다시 읽어야 할 파일과 열을 찾는 데 사용된다. 인덱스 검색과 데이터 읽기는 작업 경계가 다르므로 병렬도를 각각 배치해야 하며, 캐시 위치와 노드 부하를 결합하여 스케줄링해야 한다. 재조회 시 대상 파일 단위로 일괄 요청을 조직하면 metadata와 데이터 캐시를 재사용하여 오브젝트 요청과 노드 간 전송 비용을 제어할 수 있다.

후보 병합과 지연 구체화

StarRocks의 분산 병합 및 전역 지연 구체화(延迟物化) 프레임워크는 먼저 가벼운 row IDs와 점수를 교환하여 전역 후보 병합과 순위를 완료할 수 있다. 미디어 주소, 장면 설명 등 출력에만 사용되는 열은 최종 TopK가 확정된 후 선정된 row IDs에 따라 일괄적으로 다시 가져오므로(回捞), 불필요한 읽기, 디코딩 및 노드 간 전송을 줄인다. 읽기를 지연할 수 있는지는 이 열들의 용도에 달려 있다. 필터링이나 Join이 어떤 레코드가 순위에 참여하는지를 결정한다면 최종 TopK를 확정하기 전에 해당 조건을 처리해야 하며, 관련 열과 정밀 정렬(精排) 시 사용하는 원본 벡터는 여전히 미리 읽어야 할 수 있다. 다시 가져온 데이터는 StarRocks 기존의 벡터화 실행 경로로 들어가 후속 분석을 이어서 완료한다. 예를 들어 가장 유사한 운전 프레임 100개를 선정한 후, 차량 정보를 연결하고 소프트웨어 버전별로 집계 및 정렬하여 이렇게 매칭된 샘플들의 버전 분포를 분석할 수 있다.

전체 비용에 따른 접근 경로 선택

StarRocks의 CBO는 통계 정보를 활용해 실행 비용을 평가하며, 프레디킷 푸시다운, Join 순서 선택과 함께 쿼리 계획을 구성한다. Paimon의 인덱스 접근에 직면하면 인덱스 검색량, 후보 규모, 매칭 파일 분포 및 Data Evolution의 열 병합 비용을 평가에 포함시켜야 하며, 후속 관계 연산과 함께 접근 경로를 선택해야 한다. 후보가 너무 많거나 분포가 너무 흩어져 있으면 열 스캔이 더 경제적일 수 있으며, ANN을 채택한 쿼리는 정해진 재현율(召回) 목표 아래에서 지연과 리소스 오버헤드를 비교해야 한다.

Paimon 2.0 모범 사례: 쓰기부터 쿼리까지의 데이터 관리

실제 적용 경험을 바탕으로 우리는 Paimon 멀티모달 테이블 관리를 세 가지로 정리했다. 파일 규모 제어, 특징의 질서 있는 백필, 적시의 인덱스 유지보수로, 이들은 각각 StarRocks의 스캔, 열 데이터 조합 및 인덱스 접근 비용에 영향을 준다. 쿼리 성능을 백그라운드 유지보수와 함께 관찰해야 비로소 문제가 접근 경로에 있는지, 아니면 데이터 조직 자체에 있는지를 판단할 수 있다.

쓰기와 Compaction: 파일 레이아웃이 쿼리를 지원하도록

파티션과 쓰기 배치를 함께 설계

시간, 비즈니스 도메인 등 상용 조건에 따라 파티션을 나누면 StarRocks가 읽기 범위를 좁히는 데 도움이 된다. 동시에 지나치게 세분화된 파티션과 너무 작은 배치는 피해야 한다. 1 TiB 데이터를 1 MiB 파일로 쓰면 약 105만 개의 객체가 생기고, 256 MiB로 쓰면 약 4096개가 된다. 목표 파일 크기는 여전히 쓰기 시효성, 쿼리 프루닝 및 병렬도를 함께 고려해야 한다.

실제 읽기 오버헤드로 정리 주기를 보정

파일 수, 크기 분포 및 Compaction 적체를 지속적으로 관찰하고, StarRocks의 스캔량, 객체 요청 및 캐시 적중과 결합하여 유지보수 효과를 판단한다. 본문에서 논의한 Row Tracking 테이블은 unaware Append 모드를 채택하므로 기본키 테이블의 bucket 계획을 그대로 적용할 수 없다.

Data Evolution: 백필과 읽기 비용을 함께 계획

- row ID로 백필하면서 특징 버전 보존

새로 추가되거나 변경된 열만 쓰고, 모델 버전, 계산 시간 및 처리 상태를 기록한다. 서로 다른 모델이 생성한 벡터는 동일한 특징 공간에 속하지 않을 수 있으므로 쿼리는 비교 범위를 명확히 해야 한다. Row Tracking은 행의 대응 관계를 해결하지만, 특징의 의미와 버전은 여전히 비즈니스가 관리해야 한다.

- 백필 계획에 열 파일 정리와 인덱스 리프레시 포함

부분 업데이트는 열 파일을 축적하므로, StarRocks에서 흔히 쓰는 프로젝션 열과 결합하여 조합 읽기 비용을 평가해야 한다. 인덱싱된 열이 업데이트된 후에는 인덱스 커버리지와 버전을 확인해야 하며, row ID 재할당과 관련된 유지보수의 경우 영향을 받는 인덱스와 외부 참조도 처리해야 한다.

Global Index: 실제 쿼리를 중심으로 구성 및 평가

쿼리 요구사항 | 전형적 인덱스 | 중점 사항 / 등가·범위·범주 필터 | BTree, Bitmap | 선택도, 카디널리티, 후보 수 / 텍스트 및 키워드 검색 | 전문 인덱스 | 토큰화, 관련성, 검색 비용 / 벡터 유사 검색 | IVF-PQ 등 벡터 인덱스 | 거리 측정, 인덱스 크기, 재현율

index shard로 병렬도와 작업 오버헤드 균형

벡터 및 전문 인덱스의 shard가 너무 많으면 StarRocks의 스케줄링과 병합 오버헤드가 증가하고, 너무 크면 단일 작업의 처리량이 높아진다. BTree, Bitmap은 각자의 정렬과 범위 구성 방식을 가지므로 동일한 분할 전략을 적용할 수 없다. index shard는 테이블 파티션이나 bucket과도 같지 않다.

전체 쿼리를 평가하고 인덱스 커버리지를 확인

모델, 거리 측정 및 재현율 목표를 고정하고, 콜드·핫 캐시 상태에서의 검색, 병합 및 재조회(回捞) 소요 시간을 비교하며, 후보 수와 매칭 파일 분포를 결합하여 구성을 조정한다. 신규 데이터나 특징 업데이트 후에는 제출된 인덱스의 커버리지 범위를 별도로 확인한다.

DLF 관리형 유지보수: 유지보수 상태와 쿼리 성능 정렬

알리바바 클라우드 데이터레이크 빌드 DLF는 Global Index 비동기 구축, 자동 Compaction, Snapshot 정리, 파티션 수명 주기 및 폐기 파일 정리를 통합 관리할 수 있다. 팀은 인덱스 커버리지, 작업 적체 및 리소스 소모를 StarRocks의 쿼리 지연, 스캔량 및 캐시 성능과 함께 평가하여 유지보수 리소스와 실행 빈도를 조정할 수 있다.

데이터 쓰기 성공과 인덱스의 쿼리 가능 여부는 각각 관찰해야 하는 두 가지 상태다. DLF는 레이크 테이블과 인덱스 유지보수를 관리하고, StarRocks는 쿼리 버전에 따라 스캔 또는 인덱스 접근을 계획한다. 유지보수 전략은 검색 가능 시효성, 쿼리 성능 및 비용 요구사항을 동시에 충족해야 한다.

후속 지속 작업: 혼합 워크로드 환경에서의 StarRocks 시스템 최적화

Paimon 멀티모달 테이블이 더 많은 비즈니스를承载(담당)하면서 StarRocks는 저지연 검색과 복잡한 OLAP 쿼리를 동시에 처리해야 하며, 특징 백필, 인덱스 구축 및 Compaction이 가져오는 데이터 변화와 I/O 경쟁에 대응해야 한다. 후속 최적화는 리소스 격리, 인덱스 인지 쿼리 계획, 그리고 쿼리와 레이크 테이블 유지보수의 협력을 중심으로 전개하여 동일한 실행 아키텍처가 다양한 워크로드에 더 잘 적응하도록 할 것이다.

StarRocks 컴퓨트 그룹과 스케줄링 메커니즘으로 혼합 워크로드 격리

대화형 검색은 꼬리 지연(tail latency)에 주목하고, 배치 분석은 처리량에 더 주목한다. StarRocks는 서로 다른 컴퓨트 그룹으로 이 두 유형의 쿼리를 담당하게 하고, 각각 동시성, 리소스 예산 및 확장/축소 전략을 설정할 수 있다. 후속으로는 쿼리 특성과 결합하여 작업 스케줄링, 캐시 재사용 및 핫스팟 처리를 더욱 최적화하고, 고처리량 작업이 온라인 검색에 미치는 간섭을 줄여야 한다. 컴퓨트 그룹 격리 외에도 StarRocks의 읽기 압력과 백그라운드 유지보수가 사용하는 스토리지 대역폭을 함께 평가하여 공유 I/O 리소스를 합리적으로 분배해야 한다.

StarRocks 쿼리 계획이 인덱스 커버리지를 명확히 인지하도록

데이터 쓰기 완료와 인덱스 준비 사이에는 시간차가 존재한다. StarRocks는 쿼리 Snapshot에서 사용 가능한 인덱스 및 그 커버리지 범위에 따라 접근을 조직해야 한다. 쿼리 의미 체계와 reader 능력이 허용할 때, 커버되지 않은 데이터에 대해 보충 읽기를 마련하고, 비즈니스가 인덱스가 구축된 데이터만 검색하기로 선택하면 검색 가능 범위를 명확히 해야 한다. 후속으로는 쿼리 계획과 성능 관측에서 이러한 차이를 반영하고 보충 읽기의 비용을 평가하여, 비즈니스가 결과 완전성, 데이터 시효성 및 쿼리 지연 사이에서 명확한 선택을 할 수 있도록 해야 한다.

- StarRocks 쿼리 지표를 호수 테이블 유지보수 의사결정에 활용

Compaction과 인덱스 리프레시는 Paimon의 유지보수 작업 또는 DLF가 수행하며, 그 효과는 최종적으로 StarRocks의 스캔, 검색, 재조회 비용에 나타난다. 향후에는 쿼리 지연, 캐시 적중과 읽기량을 파일 규모, 인덱스 커버리지, 작업 적체와 연결하여 유지보수 주기와 자원 할당의 근거를 제공해야 한다. StarRocks 측은 metadata와 캐시 관리를 보완하여 새로운 쿼리가 새 버전의 데이터와 인덱스를 적시에 사용하도록 해야 하며, 실행 중인 쿼리는 계속 Snapshot을 고정하고 호수 테이블의 버전 보존 정책과 협력하여 읽기 일관성을 보장해야 한다.

Paimon 2.0은 원본 미디어, 지속적으로 백필되는 특징과 인덱스를 동일한 호수 테이블 및 버전 체계에 조직하며, Stella는 이 기반 위에서 인덱스 검색, 후보 병합, 온디맨드 재조회와 후속 관계 연산을 연결한다. 한 번의 쿼리는 유사 화면이나 키워드에서 출발하여 비즈니스 조건으로 샘플을 필터링하고, 연관과 집계를 통해 결과를 해석할 수 있다. 데이터는 Paimon 테이블에 보존되며, 특징 가공, 검색 분석과 학습 데이터 준비가 동일한 호수상 데이터를 중심으로 전개될 수 있다.

알리바바 클라우드에서 이 체인은 호수 테이블, 유지보수 서비스와 쿼리 엔진이 공동으로 지원한다. Paimon은 테이블 버전, 컬럼 데이터와 인덱스를 조직하고, 데이터 레이크 구축 DLF는 인덱스 구축, Compaction 등 유지보수 작업을 호스팅할 수 있으며, Stella는 SQL 계획, 분석과 검색 실행을 담당한다. EMR Serverless StarRocks는 나아가 전관리형 인스턴스 관리, 탄력적 확장과 다중 컴퓨트 그룹 격리를 제공하여, 팀이 상호작용형 검색과 배치 분석의 서로 다른 요구에 따라 컴퓨트 자원을 구성하고 쿼리 성능에 맞춰 호수 테이블 유지보수 전략을 조정하도록 돕는다.

향후 Stella는 혼합 부하 격리, 인덱스 인지 쿼리 계획, 그리고 쿼리와 호수 테이블 유지보수의 협동을 중심으로 최적화를 계속 전개하여, 동일한 실행 아키텍처가 저지연 검색과 복잡한 분석을 더 잘 지원하도록 할 것이다. 그룹 비즈니스와 퍼블릭 클라우드 고객의 실제 부하는 이러한 작업에 계속 피드백을 제공할 것이다. Paimon의 데이터 조직과 인덱스 역량이 지속적으로 완비됨에 따라, Stella 역시 개방형 호수 테이블상의 멀티모달 분석과 검색 역량을 더욱 확장해 나갈 것이다.

알리바바 클라우드 빅데이터 AI 기술

796

글

422k

읽음

585

팔로워