公司最近要上数据仓库，这活儿落到了我头上。

说来有点尴尬，我上一次正经碰数仓还是好几年前的事。那会儿脑子里的画面还是 Hadoop 那一大套：HDFS 存数据，Hive 写 SQL，Spark 跑计算，一个查询下去先去泡杯咖啡。实时一点的需求，就上 ClickHouse 硬扛。

这次调研一圈下来，我有点恍惚。原来这几年数仓这块早就换了天地，一个叫 StarRocks 的东西几乎是绕不开的名字。

于是我花了几天把它和那些老伙计放一起捋了捋，这篇就把我的理解和选型过程记下来。

顺带纠正一下，这东西叫 StarRocks，Star 加 Rocks，中间没有 t。我一开始也写成了 StartRocks，被同事笑了半天。

先说说我们为什么要换

要讲清楚为什么选 StarRocks，得先说清楚老方案到底卡在哪。

我们之前的数据分析是典型的两套班子。

离线这块走的是 Hive 那一套，报表、跑批都在上面。好处是稳、便宜、能扛海量数据，坏处就一个字：慢。

一个稍微复杂点的报表，分钟级起步是常态。运营想看个“分渠道的实时转化”，对不起，等明天跑完批再看吧。

实时这块我们上了 ClickHouse，单表查询确实快，快到让人上瘾。

但 ClickHouse 有个让我很头疼的毛病，它做多表 join 的时候是真的费劲。

我们的业务偏偏又是订单、用户、商品几张大表来回关联。为了让 ClickHouse 跑得动，我们只能提前把数据打成一张大宽表。

打宽表这事，谁打谁知道。字段一多，数据一变，维护起来就是一场灾难。

所以这次的目标很明确：找一个既能扛实时、又能好好做 join、还别让我天天打宽表的东西。

StarRocks 到底是个啥

查了一圈，StarRocks 的自我介绍是「极速全场景的 MPP 数据库」。

这话听着挺虚，我们拆开看。

MPP 是「大规模并行处理」的缩写。简单说，就是一个查询进来，它会拆成好多小块，扔到集群里一堆机器上同时算，算完再汇总。

你可以把它想象成一个大项目来了，不是让一个人从头干到尾，而是拆成几十份分给几十个人并行干，最后合并结果。人多力量大，自然就快。

StarRocks 还有个身世值得一提。它跟 Apache Doris 同源，早期也被叫做 DorisDB，后来独立发展、开源，现在社区挺活跃。

它主打的几个硬菜，我挑几个我最在意的说。

向量化执行

传统数据库处理数据，很多是一行一行来的，一次函数调用处理一条记录。

StarRocks 是按「列」成批处理的，一次操作一整批数据，还能吃满 CPU 的 SIMD 指令。

这个差别有点像什么呢。好比你要给一百个信封贴邮票，一种办法是拿一个贴一个、来回跑一百趟；另一种是把一百个信封铺开，一巴掌盖下去。后者明显快得多。

CBO 优化器

CBO 是「基于代价的优化器」。

说人话就是，同一条 SQL 可以有好几种执行路线，CBO 会估算每条路线的开销，自动挑最省的那条去跑。

这东西在多表 join 的时候特别关键，它会帮你决定先关联哪张表、用什么方式关联。而这正是 ClickHouse 的短板。

真的能做 join

这是我最看重的一点。

StarRocks 是奔着「不用打宽表」去设计的。它支持标准的多表 join，几张表直接关联查询，性能也顶得住。

我翻到一些对比资料，在 join 比较重的查询场景下，StarRocks 相比 ClickHouse 能快出好几倍。这个说法在社区里被反复提到，具体倍数各家测的不一样，但方向是一致的。

内容为合规改写，具体性能数字以你自己环境的实测为准，别直接拿别人的 benchmark 当承诺。

对我们这种一堆大表来回关联的业务来说，这一条基本就是决定性的。

兼容 MySQL 协议

StarRocks 兼容 MySQL 协议。

这意味着什么？意味着我用熟悉的 MySQL 客户端就能连上去，常见的 BI 工具也能直接对接。

# 用 MySQL 客户端直接连 StarRocks 的 FE 节点
# -P 默认是 9030 这个查询端口，不是 3306
mysql -h 127.0.0.1 -P 9030 -u root

# 连上之后，建库建表写查询，手感跟 MySQL 几乎一样
# 对我们这种 MySQL 用了很多年的团队，几乎零学习成本
​

这一点看着不起眼，但对团队落地太友好了。老同事不用重新学一套语法，上手就能干活。

它的架构长啥样

StarRocks 的架构其实挺好懂，就两类角色。

一类叫 FE（Frontend），负责管元数据、接收查询、生成执行计划、调度任务。你可以把它理解成项目经理，不干重活，但负责分配和协调。

另一类叫 BE（Backend），负责真正存数据、干计算。这就是真正下地干活的工人。

一个查询进来，FE 先把它拆解规划好，再分发给一堆 BE 并行执行，最后收集结果返回。

这就是前面说的 MPP 在干的事。

值得一提的是，StarRocks 后来还演进出了「存算分离」的架构。

早期是存算一体，数据和计算都在 BE 上，扩容的时候存储和算力得一起扩，有点浪费。

存算分离之后，数据可以放到对象存储（比如 S3 这类）上，计算节点变成无状态的，想加算力就加算力，想加存储就加存储，两边解耦。

这对云上部署和弹性伸缩特别友好。我们虽然初期用不上这么复杂的玩法，但知道它有这条路，心里踏实。

跟老伙计们比一比

光说 StarRocks 好没用，得放一起比。我把这次主要纠结的几个放一张表里。

维度	Hadoop/Hive	ClickHouse	StarRocks
定位	离线数仓	实时单表分析	实时全场景分析
查询速度	慢，分钟级	单表极快	多场景都快
多表 join	能做但慢	弱项，常靠宽表	强项，直接关联
实时性	差	好	好
上手成本	高	中	低，兼容 MySQL
运维复杂度	高	中	中

这么一摆就清楚了。

Hadoop 那套不是不好，它扛海量离线数据依然是一把好手，便宜又稳。但要让它支撑实时交互式分析，它天生就不是干这个的。

ClickHouse 单表快得没话说，如果你的场景就是日志、埋点这种一张大表怼到底，它依然很能打。可一旦 join 多起来，它就开始喘。

StarRocks 的卖点在于「全场景」，实时也行、join 也行、上手还快。它不是在某一个极端点上做到极致，而是在我们这种混合需求下，各方面都够用、还不用打宽表。

当然它也不是银弹。超大规模的纯离线跑批，Hadoop 生态还是更成熟更省钱；极致的单表秒级响应，ClickHouse 也未必输。选型从来是看场景，不是看谁名气大。

最后我们怎么定的

说回我们自己。

我们的核心诉求是实时、多表 join、低上手成本，还有一条隐藏需求是别让我天天维护宽表。

把这几条往上一套，StarRocks 几乎是贴着我们的需求长出来的。

兼容 MySQL 这一点也帮了大忙。团队 MySQL 用了这么多年，迁过去几乎没有语法负担，这在推动落地的时候太重要了。

所以最后我们定了 StarRocks 做这次实时数仓的查询引擎。离线那块的 Hadoop 暂时保留，让它继续干它擅长的海量跑批，两边分工。

目前还在搭环境、灌数据的阶段，真正的坑估计还在后头等着。等踩得差不多了，我再写一篇填坑记。

那就先这样，开干吧。