• 1. StarRocks란?
• 2. StarRocks가 어울리는 Use-Cases
• 2.1. OLAP multi-dimensional analytics
• 2.2. Real-time analytics
• 2.3. High-concurrency analytics
• 2.4. 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
• 4. StarRocks 기술요소들(부재 : 어떻게 성능을 달성하였는가)
• 4.1. MPP framework
• 4.2. Vectorized execution engine
• 4.3. CBO
• 4.4. Real-time, updatable columnar storage engine
• 4.5. Intelligent MV
• 4.6. Data Lake analytics
• 5. Use Cases
• 5.1. 국내사용사례
• 5.1.1. Naver(데이터플랫폼팀)
• 5.2. 해외사용사례
• 5.2.1. Trip.com - 빅데이터 비즈니스 인텔리전스 플랫폼
• 5.2.2. Lenovo(빅데이터 팀)
• 참조

1. StarRocks란?

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

2. StarRocks가 어울리는 Use-Cases

2.1. OLAP multi-dimensional analytics

The MPP framework and vectorized execution engine enable users to choose between various schemas to develop multi-dimensional analytical reports. Scenarios:

• User behavior analysis
• User profiling, label analysis, user tagging
• High-dimensional metrics report
• Self-service dashboard
• Service anomaly probing and analysis
• Cross-theme analysis
• Financial data analysis
• System monitoring analysis

2.2. Real-time analytics

StarRocks uses the Primary Key table to implement real-time updates. Data changes in a TP database can be synchronized to StarRocks in a matter of seconds to build a real-time warehouse.

Scenarios:

• Online promotion analysis
• Logistics tracking and analysis
• Performance analysis and metrics computation for the financial industry
• Quality analysis for livestreaming
• Ad placement analysis
• Cockpit management
• Application Performance Management (APM)

2.3. High-concurrency analytics

StarRocks leverages performant data distribution, flexible indexing, and intelligent materialized views to facilitate user-facing analytics at high concurrency:

• Advertiser report analysis
• Channel analysis for the retail industry
• User-facing analysis for SaaS
• Multi-tabbed dashboard analysis

2.4. Unified analytics

StarRocks provides a unified data analytics experience.

• One system can power various analytical scenarios, reducing system complexity and lowering TCO.
• StarRocks unifies data lakes and data warehouses. Data in a lakehouse can be managed all in StarRocks. Latency-sensitive queries that require high concurrency can run on StarRocks. Data in data lakes can be accessed by using external catalogs or external tables provided by StarRocks.

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를 검색하는 동시에 로컬 디스크에 캐시합니다.

4. StarRocks 기술요소들(부재 : 어떻게 성능을 달성하였는가)

4.1. MPP framework

StarRocks는 MPP(massively parallel processing) framework를 적용했습니다. 하나의 쿼리 요청은 여러개의 물리적인 컴퓨팅 유닛에 나누어서 병렬적으로 실행됩니다. 각각의 시스템에는 전용 CPU및 메모리 리소스가 있습니다. MPP 프레림워크는 모든 CPU 코어 및 머신의 리소스를 완전히 사용합니다.

위의 그림에서 StarRocks는 SQL 문을 문의 의미에 따라 여러 논리 실행 단위(쿼리 조각)로 구문을 분석 합니다. 그런 다음 각 Fragment는 연산 복잡성에 따라서 하나 또는 여러 개의 물리적 실행 단위(Fragment Instance)에 의해 구현됩니다. 물리적 실행 단위는 StarRocks에서 가장 작은 스케줄링 단위입니다. 계획 실행을 위해 BE(or CN) 노드로 예약됩니다. 하나의 논리 실행 단위에는 그림의 오른쪽에 만 처리하고 결과는 병합되어 최종 데이터를 생성합니다. 논리 실행 단위의 병렬 연산은 모든 CPU 코어 및 물리적 시스템 리소스를 완전히 활용하고 쿼리 속도를 가속화 합니다.

Druid 같은 많은 데이터 분석 시스템에서 사용하는 Scatter-Gather framework 와 달리 MPP 프레임워크는 쿼리 요청을 처리하는데 더 많은 리소스를 사용할 수 있습니다. Scatter-Gather 프레임워크에서는 Gather 노드만 최종 병합 작업을 수행할 수 있습니다. MPP 프레임워크에서 데이터는 병합 작업을 위해 여러 노드로 셔플됩니다. 카디널리티가 높은 필드의 Group By와 큰 테이블의 조인과 같은 복잡한 쿼리의 경우 StarRocks의 MPP 프레임워크는 Scatter-Gather 프레임워크에 비해 눈에 띄는 성능 이점이 있습니다.

4.2. Vectorized execution engine

백터화된 실행 엔진은 열 방식으로 데이터를 구성하고 처리하기 때문에 CPU 처리 능력을 보다 효율적으로 사용합니다. 특히 StarRocks는 데이터를 저장하고, 메모리에서 구성하고, SQL 연산자를 모두 열 방식으로 계산합니다. 백터화된 연산은 CPU 연산에 있어서 많은 장점을 제공합니다.

백터화된 실행 엔진은 SIMD(Single Instruction, Multiple Data) 명령어도 최대한 활용합니다. 이 엔진은 더 적은 명령으로 더 많은 데이터 작업을 완료할 수 있습니다, 표준 데이터 세트에 대한 테스트에 따르면. 이 엔진은 전반적인 성능이 3배에서 10배 까지 향상시킵니다,

(+) 백터연산 외에도 StarRocks는 쿼리 엔진에 대한 다른 최적화를 구현했습니다. 예를 들어 StarRocks는 Operation on Encoded Data 기술을 사용하여 디코딩 할 필요 없이 인코딩된 문자열에서 연산자를 직접 실행합니다. 이를 통해 쿼리의 복잡성이 줄어들고 최대 2배 이상 쿼리 속도가 빨라집니다.

4.3. CBO

다중 테이블 조인 쿼리의 성능 최적화는 어려운 문제중에 하나입니다. 엔진으로만 뛰어난 성능을 제공할 수 없는데, 그 이유는 다중 테이블 조인 쿼리 시나리오에서 실행 계획의 복잡성에 따라서 달라질 수 있기 때문입니다.

StarRocks는 완전히 새로운 CBO를 처음부터 설계합니다. 이 CBO는 MS-SQL 등 다양한 DB에 영향을 준 Cascade famework(Goetz Grafe, 1995)를 채택하고 그 외에 여러 가지 최적화와 혁신을 통해 백터엔진에 맞게 심층적으로 사용자 정의 됩니다. 이러한 최적화에는 CTE(Common Table Expressions)의 재사용, 하위 쿼리 재작성, Lateral Join, Join Reorder, 분산 Join 실행을 위한 전략 및 낮은 카디널리티 최적화가 포함됩니다. CBO는 총 99개의 TPC-DS SQL 문을 지원합니다.

4.4. Real-time, updatable columnar storage engine

StarRocks는 동일한 유형의 데이터를 연속적으로 저장할 수 있는 Columnar storage engine입니다. 열 기반 스토리지에서는 데이터를 보다 효율적인 방식으로 인코딩하여 압축률을 높이고 스토리지 비용을 낮출 수 있습니다. 또한 열 기반 스토리지는 총 데이터 읽기 I/O를 줄여 쿼리 성능을 향상시킵니다.

또한 실시간에 가까운 분석을 위해 몇 초 내에 데이터를 로드할 수 있습니다. StarRocks의 스토리지 엔진은 각 데이터의 수집 작업의 원자성, 일관성, 격리성 및 내구성(ACID)를 보장합니다. 데이터 로드 트랜잭션의 경우 전체 데이터 트랜책션이 성공하거나 실패합니다.

동시 트랜잭션은 서로 영향을 주지 않으므로 트랜잭션 수준 격리를 제공합니다.

StarRocks의 스토리지 엔진은 Delete 및 Insert 를 사용하여 효율적인 Partial Update 및 Upsert 작업을 수행할 수 있습니다. 스토리지 엔진은 PK 인덱스를 사용하여 데이터를 빠르게 필터링 할 수 있으므로 데이터 읽기 시 정렬 및 병합 작업이 필요하지 않습니다. 또한 엔진은 보조 인덱스를 활용할 수도 있습니다. 대용량 데이터 업데이트 에서도 빠르고 예측 가능한 쿼리 성능을 제공합니다.

4.5. Intelligent MV

StarRocks는 쿼리 속도 향상과 데이터 웨어하우스 계층화를 위해 지능형 구체화 뷰(materialized view)를 활용합니다. 다른 유사 제품들의 구체화 뷰가 기본 테이블과의 데이터 동기화를 수동으로 해야 하는 것과 달리, StarRocks의 구체화 뷰는 기본 테이블의 데이터 변경에 따라 자동으로 데이터를 업데이트하므로 추가적인 유지보수 작업이 필요하지 않습니다. 또한, 구체화 뷰의 선택 과정도 자동화되어 있습니다. StarRocks가 쿼리 성능을 개선할 수 있는 적합한 구체화 뷰(MV)를 식별하면, 자동으로 쿼리를 재작성하여 해당 구체화 뷰를 활용합니다. 이러한 지능형 프로세스는 수동 개입 없이도 쿼리 효율성을 크게 향상시킵니다.

StarRocks의 구체화 뷰는 전통적인 ETL 데이터 모델링 과정을 대체할 수 있습니다. 상위 애플리케이션에서 데이터를 변환하는 대신, 이제 StarRocks 내에서 구체화 뷰를 통해 데이터를 변환할 수 있어 데이터 처리 파이프라인이 간소화됩니다.

예를 들어, 그림에서 볼 수 있듯이 데이터 레이크의 원시 데이터는 외부 구체화 뷰를 기반으로 정규화된 테이블을 생성하는 데 사용될 수 있습니다. 비동기 구체화 뷰를 통해 정규화된 테이블로부터 비정규화된 테이블을 만들 수 있습니다. 또한 정규화된 테이블로부터 또 다른 구체화 뷰를 생성하여 높은 동시성 쿼리와 더 나은 쿼리 성능을 지원할 수 있습니다.

4.6. Data Lake analytics

StarRocks는 로컬 데이터를 효율적으로 분석하는 것 외에도 컴퓨팅 엔진으로 작동하여 Apache Hive, Apache Iceberg, Apache Hudi 및 Delta Lake와 같은 데이터 레이크에 저장된 데이터를 분석할 수 있습니다. StarRocks의 주요 기능 중 하나는 외부에서 유지 관리되는 메타 스토어에 대한 연결을 지원하는 External Catalog 기능이 있습니다. 이 기능은 유저에게 외부 데이터 소스를 원활하게 쿼리할 수 있는 기능을 통해 데이터 마이그레이션 없이 쿼리가 가능합니다. 이는 사용자에게 HDFS 또는 S3에 있는 Parquet, ORC 및 CSV 와 같은 Open fileformat에 대한 분석을 지원합니다.

위의 그림은 StarROcks가 데이터 컴퓨팅 및 분석을 담당하고 데이터 레이크가 데이터 스토리지, 구성 및 유지 관리를 담당하는 데이터 레이크 분석 시나리오를 보여줍니다. 데이터 레이크를 통해 유저는 유연한 스키마를 사용하여 다양한 BI, AI, 임시 리포팅 사용 사례에 대한 “Single Data Source”로 보고서를 생성 할 수 있습니다. 또한 해당 외부 카탈로그에 대하여도 백터엔진 및 CBO를 활용하여 쿼리 성능을 최적화 합니다.

5. Use Cases

아래는 CelerData 혹은 StarRocks에 대한 사용 사례를 정리한 챕터입니다. 디테일한 내용보다는 기존의 문제점, 도입후 해결된 부분들을 중점적으로 정리합니다.

5.1. 국내사용사례

5.1.1. Naver(데이터플랫폼팀)

• 기존 아키텍처 : Clickhouse를 사용한 분석플랫폼 제작
• 기존 아키텍처의 문제점
• ClickHouse의 Fixed Dimensions
• JOIN 기능의 지원 부족으로인해 denormalized table에 의지해야 했으며, 이로인해 사용자는 고정된 차원(데이터) 만 사용할 수 있어 실시간 분석이 어려웠음
• 수많은 데이터 소스와 테이블이 있는 상황에서 모든 테이블을 처리해 주는것은 실질적으로 불가능 했기에 일부만 서비스 중
• ClickHouse의 확장성 문제
• 노드 간의 데이터 균형을 맞추기 위한 수동 개입이 필요했음, 자동화가 부족한 시간 소모적인 프로세스 유지
• 데이터 량이 증가함에 따라 이러한 관리 비용이 늘어나고 있었음
• ClickHouse의 제한적인 Data Upserts/Deletes
• ClickHouse는 실시간 가변 데이터를 처리하기 위해서 MOR방식을 사용했음, 이는 실시간 데이터를 제공할 수 있지만, 다른 데이터 성능을 심각하게 낮추는 문제가 발생
• 이를 통해 많은 시나리오에 사용이 어렵거나 불가능 특히 가변 데이터와 복잡한 스키마 분석이 필요한 워크플로우 지원능력에 제한
• StarRocks 채택 이유
• 다중 테이블 JOIN : de-normal 에 의존하지 않고 여러 테이블에서 복잡한 쿼리를 처리할 수 있는 능력
• 강력한 집계된 쿼리 성능 : 동적 실시간 분석을 위해 빠르고 효율적인 쿼리 실행, Clickhouse 와 비슷하거나 이를 능가하는 속도
• 확장기능: 최소한의 운영 오버헤드로 증가하는 데이터 볼륨을 처리할수 있도록 수평확장이 원활한 부분
• 데이터 Upsert : 쿼리 성능에 영향을 주지 않고 실시간 데이터 Upsert를 지원하는 기능
• External Catalog : Apache Iceberg 및 다른 외부 데이터 세트를 원할하게 분석할수 있는 부분
• Shared-data : 분리된 스,토리지-컴퓨팅 아키텍처는 확장을 단순화하며, 효율적인 리소스 관리를 가능하게 함
• 신규 아키텍처 효과
• 유연한 SQL : 엔지니어가 이제는 SQL을 사용하여 Raw데이터를 직접적으로 쿼리할 수 있으므로 Clickhouse의 경직되고 사전 처리된 데이터에 비해 비교할 수 없는 유연성을 제공
• 강력한 성능향상 : 다중 테이블 JOIN 및 실시간 데이터 Upsert 및 Delete에 대한 빠른 속도
• 통합쿼리 플랫폼: Apache Iceberg 및 Hive같은 외부 카탈로그 연동을 통한 효율적인 통합 분석 환경
• 확장성 : 쿠버네티스를 통한 StarRocks의 수평적 확장 기능을 통해서 충분한 확장성을 보장하며 여러 워크로드들을 비용 효율적으로 처리함

5.2. 해외사용사례

5.2.1. Trip.com - 빅데이터 비즈니스 인텔리전스 플랫폼

• 기존 아키텍처 : Clickhouse를 사용한 데이터 분석 플랫폼 제공중
• 기존 아키텍처의 문제점
• 2018년도 부터 Clickhouse를 사용하였으며 이후 90% 이상의 시스템이 Clickhouse를 사용, 동시성 문제로 인해서 고생함(700억개 이상의 Recode, 매일 2,000개 이상의 프로세스, 업데이트해야하는 약 150B/day의 데이터)
• CPU 사용량이 평균적으로 30%(평일)대가 되었고 주말에는 70%에 도달하다보니 운영 안정성에서 심각한 문제가 발생할 여지가 있었음
• 이러한 문제들을 해결하기 위해 MySQL을 Cache Layer로 사용하여 트래픽을 분산하였으나 이는 2개의 데이터셋 , 2개의 SQL쿼리(Clickhouse가 표준 SQL을 지원하지 않음으로), 데이터 일관성 문제가 발생
• StarRocks 채택이유
• MPP 기반의 프레임워크를 사용하며 Star Schema 와 snowflake schema 를 지원
• FE, BE로 구성되어있는 클러스터와 MySQL Client를 통해서 접근할수 있는 구조
• 1초 미만의 대기시간 기대
• 확장성, 서버 확장중에는 온라인 비즈니스에 영향을 받지 않는 구조
• 클러스터 서비스에 대한 핫 백업, 다중 인스턴스 배포, 클러스터의 안정성은 다운타임, 오프라인 줜환 및 노드 이상에 영향을 주지 않는 구조
• 표준 SQL 구문을 지원
• MV 및 Online Schema 변경 지원
• 신규 아키텍처 효과
• 기존에 비해 단축된 쿼리 응답 시간(대부분의 쿼리가 약 200ms)

5.2.2. Lenovo(빅데이터 팀)

• 기존 아키텍처
• Apache Scoop : RDBMS 데이터를 Hive로 수집
• Apache Flume : 로그파일을 Hive 와 동기화 하는데 사용
• 크롤링된 데이터 : RDBMS → Hive를 통해 수집
• 데이터 ETL : Apache Hive
• BI : Tableau 사용
• 기존 아키텍처의 문제
• 짧은 시간에 BI 확인, 실시간 데이터 확인, 복잡한 쿼리 지원등에 요구사항들이 존재
• 데이터 플랫폼이 잘 통합되지 않아 새로운 수요를 신속하게 파악하고 대응하기가 어려웠음
• Presto는 Tableau에서 생성된 복잡한 SQL에서 속도가 느려서 실시간 데이터 보기에 요구사항 충족할 수 없었음
• StarRocks 선택이유
• StarRocks를 Hive에서 새로운 데이터 엔드포인트로 만들수 있는 가능성
• 여러 APP에서 참고할 수 있는 통합 데이터 플랫폼
• MPP 아키텍처를 통한 더 좋은 성능의 분석 집계 및 조인 쿼리 지원
• Tableau와의 뛰어난 호환성
• 신규아키텍처 효과
• 개발 효율성 향상 : 많은 테이블이 MySQL에 저장되고 외부 테이블로 쿼리되므로 데이터 수집 프로세스에 대한 삭제, MV를 통한 반복적인 개발작업 최소화
• 탁월한 BI 경험 : MS-SQL 및 MySQL을 혼합한 데이터 셋 및 테이블이라더라도 Tableau에서 몇 초 만에 확인이 가능했음
• 유지 관리 비용 절감 : FE, BE구조로 가용성이 높고 자체적으로 데이터 복사를 지원해 비즈니스에 영향을 최소화하는 구조

참조

What is StarRocks? | StarRocks

CelerData White Papers and Case Studies | CelerData