• 1. StarRocks란?
• 2. StarRocks가 어울리는 Use-Cases
• * OLAP multi-dimensional analytics
• * Real-time analytics
• * High-concurrency analytics
• * Unified analytics
• 3. StarRocks의 아키텍처
• 3.1. Shared-nothing
• 3.1.1. 노드
• 3.1.2. FE
• 3.1.3. BE
• 3.2. Shared-data
• 3.2.1. 노드
• 3.2.2. Storage
• 3.2.3. Cahce
• 참조

1. StarRocks란?

StarRocks는 “High-Concurrency real-time OLAP Database”로 정의 할 수 있습니다. 시작은 Embed GitHub 로 2020년도에 데이터 분석에서 발생하는 많은 문제들을 해결하고자 해당 프로젝트의 Fork로 시작하였습니다. Doris는 기존에 Impala 프로젝트에 채택되어 Hadoop 에코시스템에 위해 개발된 엔진과 다르게 새로운 자체 엔진을 구축하였습니다. StarRocks은 다음의 Use-Cases 에 유용할 수 있습니다.

2. StarRocks가 어울리는 Use-Cases

* OLAP multi-dimensional analytics

* Real-time analytics

* High-concurrency analytics

* Unified analytics

3. StarRocks의 아키텍처

StarRocks 는 단순한 아키텍처를 가지고 있습니다. 전체 시스템은 두 가지 유형의 구성 요소로만 구성됩니다. FE(Frontend), BE(Backend) or CN(Compute Node) BE는 데이터를 로컬 스토리지가 사용될 때 배포되고, CN은 데이터가 오브젝트 스토리지(S3, MinIO, Azure Blob Storage, 등) 또는 HDFS에 저장될 때 배포됩니다. 이를 문서에서는 Shared-nothing, Shared-data 구조라고 합니다.

3.1. Shared-nothing

Shared-nothing 구조는 로컬 스토리지에 데이터를 저장하는 구조로 실시간 쿼리에 대한 향상된 레이턴시를 제공합니다.

StarRocks는 일반적인 MPP(Massively Parallel Procerssing) 데이터베이스로서 이 아키텍쳐에서는 BE는 데이터 저장과 처리을 모두 담당합니다.

BE모드에서는 로컬 데이터에 직접 액세스하면서 처리가 가능하고 데이터 전송 및 복사를 최소화하며 초고속 쿼리 및 분석 성능을 제공할 수 있습니다. 다중 복제본을 통해서 동시성 및 안정성을 보장합니다.

최고의 쿼리 성능을 추구하는 시나리오에 적합합니다.

3.1.1. 노드

Shared-nothing 구조에서 FE, BE 두가지 유형의 노드로 구성됩니다.

• FE : 메타데이터 관리 및 실행 계획 수립
• BE : 쿼리 플랜을 실행하고 데이터를 저장합니다. 로컬스토리지를 활용하여 쿼리를 가속하며 다중 복제본을 활용하여 높은 동시성과 가용성을 보장합니다.

3.1.2. FE

FE는 메타데이터 관리, 클라이언트 연결 관리, 쿼리 계획 및 쿼리 스케줄링을 담당합니다. 각 FE는 BDB JE(Berkeley DB Java Edition)를 사용하여 메타데이터 전체 복사본을 메모리에 저장하고 유지 관리 하며 모든 FE에서 일관된 서비스를 보장합니다.

3.1.3. BE

BE는 데이터 스토리지 와 SQL 실행에 대한 책임을 가지고 있습니다.

• Data Storage : BE는 동일한 데이터 스토리지 기능이 있습니다. FE는 사전 정의된 규칙에 따라 BE에 데이터를 배포합니다. BE는 수집된 데이터를 변환하고, 필요한 형식으로 쓰고, 데이터에 대한 Indexing을 생성합니다.
• SQL execution : FE는 각각의 SQL들을 논리실행계획으로 번경합니다. 그리고 이를 BE에서 실행 할수 있는 물리 실행 계획으로 변경합니다. BE는 자체적으로 스토리지를 가지고 있으므로 데이터 이동 및 복사가 필요없어 높은 쿼리 성능을 달성할 수 있습니다.

3.2. Shared-data

Object storage 와 HDFS는 비용, 안정성, 확장성에 대한 장점을 제공합니다. 추가적으로 스토리지의 확장성은 CN 노드들을 데이터 리밸런싱 없이 추가하거나 삭제할 수 있도록 하여, 스토리지와 컴퓨팅의 분리를 제공합니다.

Shared-data 구조에서는 BE Node가 CN 노드로 대체됩니다. CN Node는 오로지 데이터 처리와 Hot data cahce를 관장합니다. 데이터는 Amazon S3, GCP, Azure Blob Storage, MinIO 등 과 같은 저렴하고 안정적인 원격 스토리지에 저장됩니다. 캐시가 적중되면 쿼리의 성능은 Shared nothing 아키텍처의 성능과 비슷합니다. CN Node는 수초내에 추가되거나 제거될 수 있습니다. 이 아키텍쳐는 스토리지 비용을 줄이고, 더 나은 리소스 격리를 보장하며, 높은 탄력성과 확장성을 보장합니다.

3.2.1. 노드

Shared-data 아키텍처의 FE는 shared-nothing 아키텍처와 동일한 기능을 제공합니다.

BE는 CN(Compute Node)으로 대체되고 스토리지 기능은 오브젝트 스토리지 또는 HDFS로 오프로드됩니다. CN은 데이터 스토리지를 제외한 BE의 모든 기능을 수행하는 상태 비저장 컴퓨팅 노드입니다.

3.2.2. Storage

StarRocks의 Shared-data Cluster 는 Object Storage(ex: AWS S3, Google GCS, Azure Blob Storage 또는 MinIO)와 HDFS의 두가지 스토리지 솔루션을 지원합니다.

Shared-data Cluster의 데이터 파일 형식은 Shared-nothing Cluster 형식과 일관되게 유지됩니다. 데이터는 세그먼트 파일로 구성되며, 다양한 인덱싱 기술은 클러스터에서 특별히 사용되는 테이블인 클라우드 네이티브 테이블에서 재사용됩니다.

3.2.3. Cahce

StarRocks 공유 데이터 클러스터는 데이터 스토리지와 컴퓨팅을 분리하여 각각 독립적으로 확장할 수 있으므로 비용을 절감하고 탄력성을 높일수 있습니다. 다만 이러한 기능은 쿼리 성능에 영향을 줄 수 있습니다.

이러한 영향을 완화하기 위해서 StarRocks에서는 메모리, 로컬 디스크 및 원격 스토리지를 포괄하는 multi-tiered data access 시스템을 구축하였습니다.

Hot data 에 대한 쿼리는 캐시를 직접 스캔한 다음 로컬디스크를 스캔하는 반면, Cold data는 후속 쿼리를 가속화 하기 위해 오브젝트 스토리지에서 로컬 캐시로 로드해야합니다. Hot data를 최대한 Computing Node에 가깝게 배치함으로서 고성능 컴퓨팅과 비용 효율적인 스토리지를 달성합니다. 또한 데이터 프리패치 전략으로 콜드데이터에 대한 액세스를 최적화 하여 쿼리에 대한 성능을 최대한 개선하였습니다.

테이블을 만들때 캐싱을 활성화 할 수 있습니다. 캐싱이 활성화된 경우 데이터는 로컬 디스크와 백엔드 개체 스토리지에 모두 기록됩니다. CN노드는 먼저 로컬 디스크에서 데이터를 읽습니다. 데이터를 찾을 수 없는 경우 Object Storage를 검색하는 동시에 로컬 디스크에 캐시합니다.

참조

What is StarRocks? | StarRocks

CelerData White Papers and Case Studies | CelerData