StarRocks强大的实时数据分析

代码仓库：https://github.com/StarRocks/starrocks?tab=readme-ov-file

StarRocks | A High-Performance Analytical Database

快速开始：StarRocks | StarRocks

StarRocks 是一款高性能分析型数据仓库，使用向量化、MPP 架构、CBO、智能物化视图、可实时更新的列式存储引擎等技术实现多维、实时、高并发的数据分析。StarRocks 既支持从各类实时和离线的数据源高效导入数据，也支持直接分析数据湖上各种格式的数据。StarRocks 兼容 MySQL 协议，可使用 MySQL 客户端和常用 BI 工具对接。同时 StarRocks 具备水平扩展，高可用、高可靠、易运维等特性。广泛应用于实时数仓、OLAP 报表、数据湖分析等场景。

StarRocks 是 Linux 基金会项目，采用 Apache 2.0 许可证，可在 StarRocks GitHub 存储库中找到（请参阅 StarRocks 许可证）。StarRocks（i）链接或调用第三方软件库中的函数，其许可证可在 licenses-binary 文件夹中找到；和（ii）包含第三方软件代码，其许可证可在 licenses 文件夹中找到。

什么是 StarRocks

StarRocks 是新一代极速全场景 MPP (Massively Parallel Processing) 数据库。StarRocks 的愿景是能够让用户的数据分析变得更加简单和敏捷。用户无需经过复杂的预处理，就可以用 StarRocks 来支持多种数据分析场景的极速分析。

StarRocks 架构简洁，采用了全面向量化引擎，并配备全新设计的 CBO (Cost Based Optimizer) 优化器，查询速度（尤其是多表关联查询）远超同类产品。

StarRocks 能很好地支持实时数据分析，并能实现对实时更新数据的高效查询。StarRocks 还支持现代化物化视图，进一步加速查询。

使用 StarRocks，用户可以灵活构建包括大宽表、星型模型、雪花模型在内的各类模型。

StarRocks 兼容 MySQL 协议，支持标准 SQL 语法，易于对接使用，全系统无外部依赖，高可用，易于运维管理。StarRocks 还兼容多种主流 BI 产品，包括 Tableau、Power BI、QuickBI、FineBI 和 Smartbi。

适用场景

StarRocks 可以满足企业级用户的多种分析需求，包括 OLAP (Online Analytical Processing) 多维分析、定制报表、实时数据分析和 Ad-hoc 数据分析等。

OLAP 多维分析

利用 StarRocks 的 MPP 框架和向量化执行引擎，用户可以灵活的选择雪花模型，星型模型，宽表模型或者预聚合模型。适用于灵活配置的多维分析报表，业务场景包括：

用户行为分析
用户画像、标签分析、圈人
高维业务指标报表
自助式报表平台
业务问题探查分析
跨主题业务分析
财务报表
系统监控分析

实时数据仓库

StarRocks 设计和实现了主键表，能够实时更新数据并极速查询，可以秒级同步 TP (Transaction Processing) 数据库的变化，构建实时数仓，业务场景包括：

电商大促数据分析
物流行业的运单分析
金融行业绩效分析、指标计算
直播质量分析
广告投放分析
管理驾驶舱
探针分析APM（Application Performance Management）

高并发查询

StarRocks 通过良好的数据分布特性，灵活的索引以及物化视图等特性，可以解决面向用户侧的分析场景，业务场景包括：

广告主报表分析
零售行业渠道人员分析
SaaS 行业面向用户分析报表
Dashboard 多页面分析

统一分析

通过使用一套系统解决多维分析、高并发查询、预计算、实时分析查询等场景，降低系统复杂度和多技术栈开发与维护成本。
使用 StarRocks 统一管理数据湖和数据仓库，将高并发和实时性要求很高的业务放在 StarRocks 中分析，也可以使用 External Catalog 和外部表进行数据湖上的分析。

架构

StarRocks 架构简洁明了，整个系统仅由两种组件组成：前端和后端。前端节点称为 FE。后端节点有两种类型，BE 和 CN (计算节点)。当使用本地存储数据时，您需要部署 BE；当数据存储在对象存储或 HDFS 时，需要部署 CN。StarRocks 不依赖任何外部组件，简化了部署和维护。节点可以水平扩展而不影响服务正常运行。此外，StarRocks 具有元数据和服务数据副本机制，提高了数据可靠性，有效防止单点故障 (SPOF)。

StarRocks 兼容 MySQL 协议，支持标准 SQL。用户可以轻松地通过 MySQL 客户端连接到 StarRocks 实时查询分析数据。

架构选择

StarRocks 支持存算一体架构 (每个 BE 节点将其数据存储在本地存储) 和存算分离架构 (所有数据存储在对象存储或 HDFS 中，每个 CN 仅在本地存储缓存)。您可以根据需要决定数据存储的位置。

Architecture choices

存算一体

本地存储为实时查询提供了更低的查询延迟。

作为典型的大规模并行处理 (MPP) 数据库，StarRocks 支持存算一体架构。在存算一体架构中，BE 负责数据存储和计算。将数据存储在 BE 中使得数据可以在当前节点中计算，避免了数据传输和复制，从而提供极快的查询和分析性能。该架构支持多副本数据存储，增强了集群处理高并发查询的能力并确保数据可靠性，非常适合追求最佳查询性能的场景。

shared-data-arch

节点

在存算一体架构中，StarRocks 由两种类型的节点组成：FE 和 BE。

FE 负责元数据管理和构建执行计划。
BE 执行查询计划并存储数据。BE 利用本地存储加速查询，并使用多副本机制确保高数据可用性。

FE

FE 负责元数据管理、客户端连接管理、查询规划和查询调度。每个 FE 在其内存中存储和维护一份完整的元数据副本，保证 FE 之间服务的一致性。FE 分为 Leader FE 节点、Follower 节点和 Observer 节点。Follower 节点可以根据类似 Paxos 的 BDB JE（Berkeley DB Java Edition）协议选举主节点。

FE 角色	元数据管理	节点选主
Leader 节点	Leader FE 负责读写元数据。Follower 节点和 Observer 节点只能读取元数据，并将元数据写请求路由到 Leader FE。Leader FE 更新元数据，然后使用 BDB JE 将元数据更改同步到 Follower 节点和 Observer 节点。只有在元数据更改同步到超过一半的Follower 节点后，数据写入才被认为成功。	Leader FE 技术上也是一个 Follower 节点，是从Follower 节点中选举出来的。要执行主节点选举，集群中必须有超过一半的Follower 节点处于活动状态。当 Leader FE 发生故障时，Follower 节点将开始另一轮主节点选举。
Follower 节点	Follower 节点只能读取元数据。它们从 Leader FE 同步和重放日志以更新元数据。	Follower 节点参与主节点选举，这需要集群中超过一半的 Follower 节点处于活动状态。
Observer 节点	Observer 节点从 Leader FE 同步和重放日志以更新元数据。	Observer 节点主要用于增加集群的查询并发性。 Observer 节点不参与主节点选举，因此不会增加集群的主节点选举压力。

BE

BE 负责数据存储和 SQL 执行。

数据存储：BE 具有等效的数据存储能力。FE 根据预定义规则将数据分发到各个 BE。BE 转换导入的数据，将数据写入所需格式，并为数据生成索引。
SQL 执行：FE 根据查询的语义将每个 SQL 查询解析为逻辑执行计划，然后将逻辑计划转换为可以在 BE 上执行的物理执行计划。BE 在本地存储数据以及执行查询，避免了数据传输和复制，极大地提高了查询性能。

存算分离

对象存储和 HDFS 提供低成本、高可靠性和可扩展性等优势。除了可以扩展存储外，还可以随时添加和删除 CN 节点。因为存储和计算分离，增删节点也无需重新平衡数据。

在存算分离架构中，BE 被“计算节点 (CN)”取代，后者仅负责数据计算任务和缓存热数据。数据存储在低成本且可靠的远端存储系统中，如 Amazon S3、GCP、Azure Blob Storage、MinIO 等。当缓存命中时，查询性能可与存算一体架构相媲美。CN 节点可以根据需要在几秒钟内添加或删除。这种架构降低了存储成本，确保更好的资源隔离，并具有高度的弹性和可扩展性。

存算分离架构与存算一体架构一样简单。它仅由两种类型的节点组成：FE 和 CN。唯一的区别是用户必须配置后端对象存储。

shared-data-arch

节点

在存算分离架构中，FE 提供的功能与存算一体架构中的相同。

BE 被 CN (计算节点) 取代，存储功能被转移到对象存储或 HDFS。CN 是无状态的计算节点，可以执行除存储数据外所有 BE 的功能。

存储

StarRocks 存算分离集群支持两种存储解决方案：对象存储 (例如，AWS S3、Google GCS、Azure Blob Storage 或 MinIO) 和 HDFS。

在存算分离集群中，数据文件格式与存算一体集群 (存储和计算耦合) 保持一致。数据存储为 Segment 文件，云原生表（专门用于存算分离集群的表）也可以利用存算一体架构中支持的各种索引技术。

缓存

StarRocks 存算分离集群将数据存储与计算分离，使两方都能够独立扩展，从而降低成本并提高系统弹性扩展能力。然而，这种架构会影响查询性能。

为减少架构对于性能的影响，StarRocks 建立了包含内存、本地磁盘和远端存储的多层数据访问系统，以便更好地满足各种业务需求。

对于针对热数据的查询，StarRocks 会先扫描缓存，然后扫描本地磁盘。而针对冷数据的查询，需要先将数据从对象存储中加载到本地缓存中，加速后续查询。通过将热数据缓存在计算单元内，StarRocks 实现了真正的高计算性能和高性价比存储。此外，还通过数据预取策略优化了对冷数据的访问，有效消除了查询的性能限制。

可以在建表时启用缓存。启用缓存后，数据将同时写入本地磁盘和后端对象存储。在查询过程中，CN 节点首先从本地磁盘读取数据。如果未找到数据，将从后端对象存储中检索，并将数据缓存到本地磁盘中。

产品特性

MPP 分布式执行框架

StarRocks 采用 MPP (Massively Parallel Processing) 分布式执行框架。在 MPP 执行框架中，一条查询请求会被拆分成多个物理计算单元，在多机并行执行。每个执行节点拥有独享的资源（CPU、内存）。MPP 执行框架能够使得单个查询请求可以充分利用所有执行节点的资源，所以单个查询的性能可以随着集群的水平扩展而不断提升。

MPP1

如上图所示，StarRocks 会将一个查询在逻辑上切分为多个逻辑执行单元（Query Fragment）。按照每个逻辑执行单元需要处理的计算量，每个逻辑执行单元会由一个或者多个物理执行单元来具体实现。物理执行单元是最小的调度单位。一个物理执行单元会被调度到集群某个 BE 上执行。一个逻辑执行单元可以包括一个或者多个执行算子，如图中的 Fragment 包括了 Scan，Project，Aggregate。每个物理执行单元只处理部分数据。由于每个逻辑执行单元处理的复杂度不一样，所以每个逻辑执行单元的并行度是不一样的，即，不同逻辑执行单元可以由不同数目的物理执行单元来具体执行，以提高资源使用率，提升查询速度。

MPP1

与很多数据分析系统采用的 Scatter-Gather 分布式执行框架不同，MPP分布式执行框架可以利用更多的资源处理查询请求。在 Scatter-Gather 框架中，只有 Gather 节点能处理最后一级的汇总计算。而在 MPP 框架中，数据会被 Shuffle 到多个节点，并且由多个节点来完成最后的汇总计算。在复杂计算时（比如高基数 Group By，大表 Join 等操作），StarRocks 的 MPP 框架相对于 Scatter-Gather 模式的产品有明显的性能优势。

全面向量化执行引擎

StarRocks 通过实现全面向量化引擎，充分发挥了 CPU 的处理能力。全面向量化引擎按照列式的方式组织和处理数据。StarRocks 的数据存储、内存中数据的组织方式，以及 SQL 算子的计算方式，都是列式实现的。按列的数据组织也会更加充分的利用 CPU 的 Cache，按列计算会有更少的虚函数调用以及更少的分支判断从而获得更加充分的 CPU 指令流水。

另一方面，StarRocks 的全面向量化引擎通过向量化算法充分的利用 CPU 提供的 SIMD（Single Instruction Multiple Data）指令。这样 StarRocks 可以用更少的指令数目，完成更多的数据操作。经过标准测试集的验证，StarRocks的全面向量化引擎可以将执行算子的性能，整体提升 3~10 倍。

除了使用向量化技术实现所有算子外，StarRocks 还在执行引擎中实现了其他的优化。比如 StarRocks 实现了 Operation on Encoded Data 的技术。对于字符串字段的操作，StarRocks 在无需解码情况下就可以直接基于编码字段完成算子执行，比如实现关联算子、聚合算子、表达式算子计算等。这可以极大的降低 SQL 在执行过程中的计算复杂度。通过这个优化手段，相关查询速度可以提升 2 倍以上。

存储计算分离

StarRocks 3.0 版本支持了全新的存算分离模式，实现了计算与存储的完全解耦、计算节点弹性扩缩容、高性能热数据缓存。存算分离模式下 StarRocks 具备灵活弹性、高性能、高可靠、低成本等特点。

shared-data

存算分离模式下，存储与计算解耦，各自独立服务，独立扩缩容，解决了在存算一体模式下的计算与存储等比例扩缩容所带来的资源浪费问题。计算节点可以实现秒级的动态扩缩容，提升计算资源的利用率。

存储层利用对象存储近乎无限的容量，以及数据高可用的特性实现数据的海量存储和持久化。支持包括 AWS S3，Azure Blob Storage，Google Cloud Storage，阿里云 OSS，腾讯云 COS，火山引擎 TOS，华为云 OBS，以及各类兼容 S3 协议的对象存储，同时也支持 HDFS 存储。

部署模式上用户可以选择基于公有云、私有云、本地机房部署。StarRocks 存算分离也支持基于 Kubernetes 部署，并提供了相应的 Operator 方便用户自动化部署。

StarRocks 存算分离模式与存算一体模式功能保持一致，写入及热数据查询性能也与存算一体基本持平。用户在存储分离模式下也可以实现数据更新、数据湖分析、物化视图加速等多种场景。

CBO 优化器

CBO

在多表关联查询场景下，仅靠优秀的执行引擎没有办法获得最极致的执行性能。因为这类场景下，不同执行计划的复杂度可能会相差几个数量级。查询中关联表的数目越大，可能的执行计划就越多，在众多的可能中选择一个最优的计划，这是一个 NP-Hard 的问题。只有优秀的查询优化器，才能选择出相对最优的查询计划，从而实现极致的多表分析性能。

StarRocks 从零设计并实现了一款全新的，基于代价的优化器 CBO（Cost Based Optimizer）。该优化器是 Cascades Like 的，在设计时，针对 StarRocks 的全面向量化执行引擎进行了深度定制，并进行了多项优化和创新。该优化器内部实现了公共表达式复用，相关子查询重写，Lateral Join，Join Reorder，Join 分布式执行策略选择，低基数字典优化等重要功能和优化。目前，该优化器已可以完整支持 TPC-DS 99 条 SQL 语句。

由于全新 CBO 的支持，StarRocks 能比同类产品更好地支持多表关联查询，特别是复杂的多表关联查询，让全面向量化引擎能够发挥极致的性能。

可实时更新的列式存储引擎

StarRocks 实现了列式存储引擎，数据以按列的方式进行存储。通过这样的方式，相同类型的数据连续存放。一方面，数据可以使用更加高效的编码方式，获得更高的压缩比，降低存储成本。另一方面，也降低了系统读取数据的 I/O 总量，提升了查询性能。此外，在大部分 OLAP 场景中，查询只会涉及部分列。相对于行存，列存只需要读取部分列的数据，能够极大地降低磁盘 I/O 吞吐。

StarRocks 能够支持秒级的导入延迟，提供准实时的服务能力。StarRocks 的存储引擎在数据导入时能够保证每一次操作的 ACID。一个批次的导入数据生效是原子性的，要么全部导入成功，要么全部失败。并发进行的各个事务相互之间互不影响，对外提供 Snapshot Isolation 的事务隔离级别。

columnar_storage_engine

StarRocks 存储引擎不仅能够提供高效的 Partial Update 操作，也能高效处理 Upsert 类操作。使用 Delete-and-insert 的实现方式，通过主键索引快速过滤数据，避免读取时的 Sort 和 Merge 操作，同时还可以充分利用其他二级索引，在大量更新的场景下，仍然可以保证查询的极速性能。

智能的物化视图

materialized_view

StarRocks 支持用户使用物化视图（materialized view）进行查询加速和数仓分层。不同于一些同类产品的物化视图需要手动和原表做数据同步，StarRocks 的物化视图可以自动根据原始表更新数据。只要原始表数据发生变更，物化视图的更新也同步完成，不需要额外的维护操作就可以保证物化视图能够维持与原表一致。不仅如此，物化视图的选择也是自动进行的。StarRocks 在进行查询规划时，如果有合适的物化视图能够加速查询，StarRocks 自动进行查询改写(query rewrite)，将查询自动定位到最适合的物化视图上进行查询加速。

StarRocks 的物化视图可以按需灵活创建和删除。用户可以在使用过程中视实际使用情况来判断是否需要创建或删除物化视图。StarRocks 会在后台自动完成物化视图的相关调整。

StarRocks 的物化视图可以替代传统的 ETL 建模流程，用户无需在上游应用处做数据转换，可以在使用物化视图时完成数据转换，简化了数据处理流程。

例如图中，最底层 ODS 的湖上数据可以通过 External Catalog MV 来构建 DWD 层的 normalized table；并且可以通过多表关联的物化视图来构建 DWS 层的宽表 (denormalized table)；最上层可以进一步构建实时的物化视图来支撑高并发的查询，提供更加优异的查询性能。

数据湖分析

datalake_analytics

StarRocks 不仅能高效的分析本地存储的数据，也可以作为计算引擎直接分析数据湖中的数据。用户可以通过 StarRocks 提供的 External Catalog，轻松查询存储在 Apache Hive、Apache Iceberg、Apache Hudi、Delta Lake 等数据湖上的数据，无需进行数据迁移。支持的存储系统包括 HDFS、S3、OSS，支持的文件格式包括 Parquet、ORC、CSV。

如上图所示，在数据湖分析场景中，StarRocks 主要负责数据的计算分析，而数据湖则主要负责数据的存储、组织和维护。使用数据湖的优势在于可以使用开放的存储格式和灵活多变的 schema 定义方式，可以让 BI/AI/Adhoc/报表等业务有统一的 single source of truth。而 StarRocks 作为数据湖的计算引擎，可以充分发挥向量化引擎和 CBO 的优势，大大提升了数据湖分析的性能。

StarRocks示例SQL

下面是一个starrocks数据操作实例

CREATE DATABASE IF NOT EXISTS quickstart;use quickstart;CREATE TABLE IF NOT EXISTS crashdata (CRASH_DATE DATETIME,BOROUGH STRING,ZIP_CODE STRING,LATITUDE INT,LONGITUDE INT,LOCATION STRING,ON_STREET_NAME STRING,CROSS_STREET_NAME STRING,OFF_STREET_NAME STRING,CONTRIBUTING_FACTOR_VEHICLE_1 STRING,CONTRIBUTING_FACTOR_VEHICLE_2 STRING,COLLISION_ID INT,VEHICLE_TYPE_CODE_1 STRING,VEHICLE_TYPE_CODE_2 STRING
);CREATE TABLE IF NOT EXISTS weatherdata (DATE DATETIME,NAME STRING,HourlyDewPointTemperature STRING,HourlyDryBulbTemperature STRING,HourlyPrecipitation STRING,HourlyPresentWeatherType STRING,HourlyPressureChange STRING,HourlyPressureTendency STRING,HourlyRelativeHumidity STRING,HourlySkyConditions STRING,HourlyVisibility STRING,HourlyWetBulbTemperature STRING,HourlyWindDirection STRING,HourlyWindGustSpeed STRING,HourlyWindSpeed STRING
);SET PASSWORD FOR 'root'@'%' = PASSWORD('123456');-- 纽约市每小时交通事故数量SELECT COUNT(*),date_trunc("hour", crashdata.CRASH_DATE) AS Time
FROM crashdata
GROUP BY Time
ORDER BY Time ASC
LIMIT 200;-- 纽约市的平均气温SELECT avg(HourlyDryBulbTemperature),date_trunc("hour", weatherdata.DATE) AS Time
FROM weatherdata
GROUP BY Time
ORDER BY Time ASC
LIMIT 100;-- 能见度情况对驾驶安全的影响SELECT COUNT(DISTINCT c.COLLISION_ID) AS Crashes,truncate(avg(w.HourlyDryBulbTemperature), 1) AS Temp_F,truncate(avg(w.HourlyVisibility), 2) AS Visibility,max(w.HourlyPrecipitation) AS Precipitation,date_format((date_trunc("hour", c.CRASH_DATE)), '%d %b %Y %H:%i') AS Hour
FROM crashdata c
LEFT JOIN weatherdata w
ON date_trunc("hour", c.CRASH_DATE)=date_trunc("hour", w.DATE)
WHERE w.HourlyVisibility BETWEEN 0.0 AND 1.0
GROUP BY Hour
ORDER BY Crashes DESC
LIMIT 100;