1410 字
7 分钟
StarRocks 原理、部署与调优指南
StarRocks 是从 Doris 分叉出的 MPP 分析引擎,在”高并发点查、实时更新、物化视图、存算分离”上走得更远。本文覆盖底层原理、集群部署(FE/BE)、存算分离形态、参数优化与常见问题。与《Doris 原理、部署与调优指南》对照阅读,差异点会标出来。
底层原理速览
- FE / BE 架构:与 Doris 同源(FE 元数据与查询规划,BE 存储与执行),但查询优化器是独立的 CBO(Cost-Based Optimizer,基于代价),统计信息驱动 Join 顺序选择
- 四种表模型:明细(Duplicate)、聚合(Aggregate)、更新(Unique/主键表)、主键(Primary Key)——主键表支持真正的行级实时更新(Delete+Insert)
- Pipeline 执行引擎:算子流水线化,消除执行引擎线程调度开销,多核利用率更高
- 同步/异步物化视图:单表同步 MV 自动透明改写;异步 MV 支持多表 Join/聚合,定时刷新
- 存算分离(Share-Nothing → Share-Data):数据放对象存储,BE 只做缓存与计算,集群可独立弹性伸缩
- Short Key Index / ZoneMap:建表时可选前 3 列做稀疏索引;每列统计信息在扫描时裁剪数据块
NOTEStarRocks 与 Doris 的关系:同源于百度 Doris,StarRocks 侧重性能与实时更新(主键表、CBO、Pipeline),Doris 侧重生态与易用性(Routine Load、物化视图、文档生态)。选型看场景:超高并发点查与实时更新选 StarRocks,求稳与生态全选 Doris。
部署
1. 规划
| 节点 | 角色 | 数量 | 规格参考(生产) |
|---|---|---|---|
| FE | Leader + Follower(可加 Observer) | 1+2 | 16C64G,SSD 元数据 |
| BE | 存储与计算 | 3+ | 32C256G |
- 端口:FE 8030(Web)/ 9030(MySQL);BE 9060(BE 通信)/ 9050(心跳)
priority_networks必须显式指定;FE 与 BE 时钟同步(ntp);sysctl vm.max_map_count=262144且sysctl -w vm.swappiness=0
2. FE 部署
wget https://releases.starrocks.io/starrocks/StarRocks-3.2.x-x86_64.tar.gztar -zxvf StarRocks-*.tar.gz -C /opt && ln -s /opt/StarRocks-* /opt/starrocksmkdir -p /data/starrocks/meta && chown -R starrocks:starrocks /opt/starrocks /data/starrocksmeta_dir = /data/starrocks/metapriority_networks = 10.0.0.0/24JAVA_OPTS="-Xmx16g -Xms16g -Xmn4g"# 第一台初始化fe/bin/start_fe.sh --daemonmysql -h127.0.0.1 -P9030 -uroot
# 后续 FE 加入mysql> ALTER SYSTEM ADD FOLLOWER "node2:9010";mysql> ALTER SYSTEM ADD FOLLOWER "node3:9010";# 每台:start_fe.sh --helper node1:9010 --daemon3. BE 部署
storage_root_path = /data/starrocks/data1,medium:ssd;/data/starrocks/data2,medium:hddpriority_networks = 10.0.0.0/24be/bin/start_be.sh --daemonmysql> ALTER SYSTEM ADD BACKEND "node1:9050";mysql> ALTER SYSTEM ADD BACKEND "node2:9050";mysql> ALTER SYSTEM ADD BACKEND "node3:9050";mysql> SHOW BACKENDS; -- 全部 Alive 即就绪4. 建表验证(主键表 + 物化视图)
CREATE TABLE orders ( order_id BIGINT, user_id BIGINT, status VARCHAR(16), amount DECIMAL(20,2), modify_ts DATETIME)PRIMARY KEY (order_id) -- 主键表:实时更新DISTRIBUTED BY HASH(order_id) BUCKETS 24;
-- 异步物化视图:多表聚合定时刷新CREATE MATERIALIZED VIEW mv_user_dailyREFRESH ASYNC START('00:00') EVERY(INTERVAL 1 DAY)AS SELECT user_id, DATE(create_time) d, SUM(amount) total FROM orders GROUP BY user_id, DATE(create_time);5. 存算分离形态(Share-Data,可选)
# 部署 CN(Compute Node)替代/并存 BE,数据在对象存储# fe.conf 增加enable_cloud_snapshot = true# 创建存储卷(示例:S3 兼容存储)CREATE STORAGE VOLUME s3vol TYPE S3 LOCATIONS ("s3://bucket/prefix") PROPERTIES ("aws.s3.endpoint"="...", "aws.s3.access_key"="...", "aws.s3.secret_key"="...");
# 建表时指定 use_storage_volumeCREATE TABLE t (...) DISTRIBUTED BY HASH(k) BUCKETS 16 PROPERTIES ("storage_volume"="s3vol");WARNING存算分离适合”弹性伸缩、多集群共享一份数据”的场景,但点查延迟依赖本地缓存命中率(热数据命中才快)。评估不了缓存命中率前,不建议把核心在线场景直接迁到 Share-Data。
调优
1. 查询优化器
SET enable_cbo=true(默认开启);关键表执行ANALYZE TABLE xxx收集统计信息,CBO 才有依据- 大宽表关掉无关列的统计;Join 用小表驱动(
SET join_implementation_mode="auto") - Pipeline:
SET pipeline_dop=0(按机器核数自适应),高并发场景可显式设 4-8,避免线程数爆炸
2. 内存
| 参数 | 建议 | 说明 |
|---|---|---|
BE mem_limit | 60%-70% 物理内存 | 单 BE 上限 |
会话 query_mem_limit | 大查询单独给 | 防止 OOM,配合 EXPLAIN 看预算 |
query_max_memory_limit_percent | 90 | 单查询占 BE 内存上限 |
3. 主键表与实时更新
- 主键表写入是”内存主键索引 + 写入时与旧数据合并”,高频小批次更新最合适(如 1 分钟级增量)
- 批量导入用
INSERT INTO ... VALUES分批,或 Broker Load;更新量大时增大分桶数(主键索引内存占用也增大) - 主键表不适用全表重写型大任务(如每天全量重灌),此时考虑明细表或异步物化视图
4. 物化视图
- 同步 MV:只服务单表聚合,命中即透明改写,适合高频点查计数
- 异步 MV:刷新策略
REFRESH ASYNC START('00:00') EVERY(INTERVAL 1 DAY),任务多时调大mv_task_run_num(默认 4) - 查询是否能命中 MV:
EXPLAIN SELECT ...看是否出现MV_前缀节点
5. Colocate Join 与缓存
- Colocate Join:多表同分桶键 +
colocate_with="g1",Join 时数据本地化,免 shuffle,高并发 Join 收益最大 - BE 块缓存
storage_page_cache_limit(默认 20% 内存);热数据表可用CREATE TABLE ... PROPERTIES ("enable_persistent_index"="true")提升点查
常见问题
| 现象 | 原因 | 处理 |
|---|---|---|
| 点查延迟高 | 未命中块缓存/主键索引未加载 | 查 SHOW BE 缓存命中率,调 storage_page_cache |
| 主键表导入慢 | 主键索引内存不足换磁盘 | 调大 BE mem_limit 或减少桶数 |
| 物化视图不刷新 | mv_task 并发/超时 | SHOW MATERIALIZED VIEWS 看 State,调 mv_task_run_num |
| 存算分离查询慢 | 缓存冷 | 预热热表、调大磁盘缓存 datacache.* |
| 磁盘水位不均 | 新 BE 数据未均衡 | 等待或 ALTER SYSTEM ... 检查 SHOW BACKENDS |
总结
- StarRocks = 同源 Doris 的”性能特化”分支:CBO + Pipeline + 主键表 + 同步/异步物化视图
- 部署与 Doris 同构(FE 集群 + BE 集群),新增存算分离形态(对象存储 + CN)
- 调优主线:统计信息与 CBO → Pipeline 并行度 → 主键表写入模式 → 物化视图 → Colocate Join
- 选型结论:高并发点查、实时更新场景优先 StarRocks;Doris/StarRocks 两者是湖仓时代 OLAP 的左右手,底座迭代时二选一即可,不建议同时养两套
StarRocks 原理、部署与调优指南
https://chaggle.github.io/posts/2026/08/11/starrocks-deploy-tuning/