阿超 > starrocks

starrocks

2025-12-29

java

一个人越知道时间的价值，越倍觉失时的痛苦呀!——但丁

StarRocks：次秒级分析、湖仓直查，开源里真正“能跑”的极速查询引擎

超级随意开场（但内容尽量靠谱）：StarRocks 的官方描述是
“The world’s fastest open query engine for sub-second analytics both on and off the data lakehouse.”
直翻就是：在湖仓上（也包括脱离湖仓的场景），做到“次秒级分析”的开源查询引擎。它同时强调“灵活场景覆盖”，以及在多维分析、实时分析、即席查询（ad-hoc）上的“最佳性能”。它还是一个 Linux Foundation 项目。

如果你在找一个“既能马上上手、又能在真实负载下扛得住”的分析引擎，StarRocks 很值得试一试。

这到底是个啥？

用官方 README 的关键点总结一下：

  • Native Vectorized SQL Engine（原生向量化引擎）：把 CPU 的并行算力吃干抹净，多维分析场景下比传统系统快 5–10 倍（官方话术）。
  • Standard SQL：兼容 ANSI SQL（TPC-H/TPC-DS 都有覆盖），客户端与 BI 工具可以直接连接。
  • 兼容 MySQL 协议：生态友好，接入成本低。
  • Smart Query Optimization（CBO）：基于成本的优化器，把复杂查询跑得更稳更快。
  • Real-time Updates：支持 upsert/delete 等“实时更新”能力（主键/唯一键模型）。
  • Intelligent Materialized View：智能物化视图，自动选择/改写以加速复杂查询。
  • 直接湖上查询：无需导入，直查 Apache Hive、Iceberg、Delta Lake、Hudi 等数据湖。
  • 资源管理与易运维：细粒度的资源控制、简单的架构与部署方式，易维护。

一句话：不只是一个“SQL 引擎”，而是一个“快速分析平台”的底座，兼顾即席分析、实时更新、物化视图加速、以及湖上直查。

架构（随意理解版）

StarRocks 的架构主要由两大模块构成：

  • Frontend（FE）：负责元数据、调度、SQL 解析与优化等
  • Backend（BE）：负责实际的存储与计算执行（向量化、列式、高并发）

它的“共享数据架构”（Shared-Data Architecture）自 3.0 版本引入，可在更低成本下提升可扩展性与可靠性。
架构图和数据层演进在 README 里都有图示（见 README 链接里的 images/arch.png 与 docs/assets/shared-data.png），上手之前可以扫一眼，做到“心中有图”。

用什么场景？

README 里列举了典型使用场景，随意挑几类你可能会关心的：

  • 多维分析（OLAP）：量表大、维度多的聚合与钻取，向量化 + CBO 把复杂 SQL 跑得漂亮。
  • 实时分析：主键/唯一键模型支持实时更新（upsert/delete），与物化视图协同加速，满足“新鲜数据 + 快速查询”。
  • 即席查询：ad-hoc analytics 的临时查询、探索式分析，用标准 SQL 即开即用。
  • 湖仓直查：Hive / Iceberg / Delta / Hudi 的数据可以在不导入的情况下直接查询（当然，具体性能取决于底层存储/网络/元数据服务等）。
  • 资源管理：控制查询/执行的资源占用，减少“查询互相打架”的情况，提升集群稳定性。

快速上手（用官方资源！）

线上社区与支持：

代码小例子（演示为主，以官方文档为准）

说明：下面示例仅为“感受语法与使用范式”，不保证覆盖你环境的所有配置，具体细节请以官方文档为准。建议在本地或测试环境先跑通。

1) 创建库与表（主键模型，支持实时更新）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
-- 创建数据库
CREATE DATABASE demo;

USE demo;

-- 主键（Primary Key）模型，便于 upsert/delete
-- 分桶与属性请按你的集群配置调整
CREATE TABLE users (
  user_id BIGINT,
  name    VARCHAR(128),
  age     INT,
  city    VARCHAR(128),
  -- 主键列
  PRIMARY KEY (user_id)
)
DISTRIBUTED BY HASH(user_id) BUCKETS 16
PROPERTIES (
  "replication_num" = "3"
);

插入与更新：

1
2
3
4
5
6
7
8
9
10
11
12
13
-- 插入
INSERT INTO users (user_id, name, age, city)
VALUES
  (1001, 'Alice', 29, 'Shanghai'),
  (1002, 'Bob',   35, 'Beijing');

-- 更新（upsert）
-- 主键相同的行会被替换为最新值
INSERT INTO users (user_id, name, age, city)
VALUES (1001, 'Alice', 30, 'Shanghai');

-- 删除
DELETE FROM users WHERE user_id = 1002;

查询：

1
2
3
4
5
-- 即席查询
SELECT city, AVG(age) AS avg_age, COUNT(*) AS cnt
FROM users
GROUP BY city
ORDER BY cnt DESC;

要点：

  • 主键模型适合“实时数据有更新”的业务表。
  • 复制数、分桶数量等属性需结合你的集群规模与数据规模选择。

2) 物化视图（智能改写加速复杂查询）

StarRocks 的物化视图会在查询时“自动改写命中”，无需手工指定视图。示例仅做语法演示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
-- 创建原始明细表（示意）
CREATE TABLE orders (
  order_id   BIGINT,
  user_id    BIGINT,
  order_date DATE,
  amount     DECIMAL(18,2),
  PRIMARY KEY (order_id)
)
DISTRIBUTED BY HASH(order_id) BUCKETS 32
PROPERTIES ("replication_num"="3");

-- 创建一个汇总型物化视图
-- 注：具体支持的聚合/表达式与限制，请以文档为准
CREATE MATERIALIZED VIEW mv_orders_daily
AS
SELECT
  DATE(order_date) AS dt,
  COUNT(*)         AS order_cnt,
  SUM(amount)      AS total_amt
FROM orders
GROUP BY DATE(order_date);

-- 之后针对 orders 的常见“日汇总”查询
-- 会自动改写命中 mv_orders_daily（以实际规则与统计为准）
SELECT DATE(order_date) AS dt,
       COUNT(*)         AS order_cnt,
       SUM(amount)      AS total_amt
FROM orders
GROUP BY DATE(order_date);

要点：

  • 物化视图并不是“万金油”，但对热点复杂查询加速十分有效。
  • 改写是否命中与查询等价性、视图新鲜度、统计信息等有关。

3) 直连数据湖（Hive / Iceberg 等）示例

StarRocks 支持通过 Catalog 连接 Hive/Iceberg/Hudi/Delta Lake 等，直接查询湖上数据。下面是“概念示例”，属性名称与取值请以官方文档为准。

Hive：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
-- 创建 Hive Catalog（属性按你的 HMS 环境填写）
CREATE CATALOG hive_prod
PROPERTIES (
  "type" = "hive",
  "hive.metastore.uris" = "thrift://your-hms-host:9083"
);

-- 切换到 Hive Catalog
USE CATALOG hive_prod;

-- 看看有哪些库
SHOW DATABASES;

-- 直接查湖上的表（无需导入）
SELECT *
FROM some_db.some_table
WHERE dt = '2025-12-28'
LIMIT 10;

Iceberg（Hive Metastore 方式）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
CREATE CATALOG iceberg_prod
PROPERTIES (
  "type" = "iceberg",
  "iceberg.catalog.type" = "hive",
  "iceberg.hive.metastore.uris" = "thrift://your-hms-host:9083"
);

USE CATALOG iceberg_prod;

-- 直接对 Iceberg 表做查询
SELECT user_id, SUM(amount) AS total_amt
FROM sales_db.fact_orders
WHERE order_date BETWEEN '2025-12-01' AND '2025-12-31'
GROUP BY user_id
ORDER BY total_amt DESC
LIMIT 20;

要点：

  • “直查湖”很爽，但性能与稳定性受到底层存储/对象存储、元数据服务、表格式与压缩、网络带宽等多因素影响。
  • 如果有长期热点分析场景，可结合“导入 + 物化视图”达到更稳定更低时延。

4) 资源管理（避免查询互相打架）

资源管理的配置细节较多，建议直接参考文档。下面给一个“限流类”的示意：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
-- 示例：创建一个资源组（实际字段与规则以文档为准）
CREATE RESOURCE GROUP rg_bi
LIMIT
  CPU "50%",
  MEM "200GB",
  CONCURRENCY "100";

-- 把一个业务租户的用户绑定到资源组（示意）
-- 注意：用户与权限管理命令以文档为准
ALTER USER 'bi_user' IDENTIFIED BY '***'
SET RESOURCE GROUP 'rg_bi';

-- 查看资源组状态（示意）
SHOW RESOURCE GROUPS;

要点：

  • 资源管理是“稳定性的守门员”，多租户/多任务同时跑时尤其关键。
  • 建议上线前根据业务峰值做容量评估与限额设置，减少拖垮风险。

运维与工程实践

  • 架构简单，易部署：FE + BE 模块清晰，支持副本与分桶、统计信息与 CBO、物化视图自动改写。
  • 维护友好：查询计划可观测、资源限额可控、故障恢复机制完善（具体以官方文档为准）。
  • 生态对接：MySQL 协议 + ANSI SQL + BI 工具兼容，让使用门槛很低。

更多请参考官方文档与博文：

社区与贡献（欢迎来玩）

  • 贡献指南：CONTRIBUTING.md
  • 开发环境搭建（IDE / Docker 构建 / 手动部署）：详见 README 的“Build and Development”与文档
  • 工作流 & PR 模板：见仓库 .github/PULL_REQUEST_TEMPLATE.md
  • “good first issue”标签：适合新朋友的入门贡献
  • 开发者群组（Google Groups）：用于讨论特性、方向与建议

谁在用它？

README 罗列了大量用户与案例（YouTube、博文、媒体报道等），覆盖互联网、金融、游戏、电商、内容平台、日志与可观测性等多个行业。
如果你在做“实时+复杂分析”“湖仓一体”“高并发 BI 查询”“多维聚合与钻取”，这份清单的案例会很有参考价值。

写在最后：Why StarRocks？

  • 够快：向量化执行 + 智能改写 + CBO，让复杂查询也能次秒级返回。
  • 够稳：标准 SQL、MySQL 协议、细粒度资源管理，降低运维复杂度。
  • 够广：湖仓直查、实时更新、物化视图、生态兼容，适配多种分析场景。
  • 够开源：Linux Foundation 项目，社区活跃、文档齐全。

“能跑起来”是评价一套数据系统最朴素的标准。StarRocks 不只“能跑”，还“跑得快”。
先用 Quick Start 拉一个环境，跑跑你们的几个典型查询；如果能从分钟级掉到秒级，你会很难不心动。

— 参考与原始信息：