StarRocks存算分离在得物的降本增效实践

一、背景

OLAP引擎在得物的客服、风控、供应链、投放、运营、ab实验等大量业务场景发挥重要作用，在报表、日志、实时数仓等应用场景都有广泛的应用。

得物引入和使用OLAP引擎的过程中，每个业务都基于自己的需求选择当时最适合自己的引擎。现在得物内部同时使用阿里云上的Hologres、ADB、Clickhouse与ECS自建的开源Clickhouse与StarRocks 5种引擎产品，从业务使用成本和运维维护的角度长远看都是不利的。

2024年，我们开始向只保留1到2个引擎的方向努力。最近，我们把一套4000+核的业务，最复杂的Clickhouse集群迁移到了存算分离的自建StarRocks上，成本节约40%，查询耗时降低一半，单节点不可用导致的集群不可用耗时从15分钟减少到了30s。

二、Clickhouse在大数据量下的困境

Clickhouse虽然单机性能首屈一指，但分布式架构存在水平扩展性、元数据管理、数据一致性、join查询性能等一系列问题。被迁移的这个Clickhouse集群服务于得物的智能运营平台，使用了超过4000核，存储超过500TB。随着业务增长，集群面临一些实际问题。

物化视图缺乏透明改写能力

智能运营平台日常需要查询周/月/季/年 环比/同比，查询时间跨度长，并且为了加速查询建立了40+物化视图。Clickhouse没有自动的透明物化视图改写能力，需要由外部代码主动管理、创建物化视图和改写SQL去查询物化视图。在需要重刷历史数据时，由外部代码管理的物化视图的重刷尤为复杂。

缺乏离线导入功能

开源Clickhouse缺少bulkload能力，智能运营需要每天从离线平台导入大量数据到Clickhouse，导入链路存在格式转换，效率低的问题，并且会占用大量Clickhouse集群资源，导入链路的数据产出有时会晚于基线。

扩容困难

虽然使用了很多物化视图，但集群负载仍然开始接近硬件能力上限。业务想要继续扩容，但面临了两个问题：

1. 垂直扩容没有空间：集群使用的Clickhouse单机规格已经是顶配，没有升配空间。

2. 水平扩容停机需停机一周：因为Clickhouse水平扩容后为了查询正确性考虑，已经按指定字段分桶的表，需要重新导入数据才能正确的resharding，这个过程需要一周的停服扩容和导入。

业务方只能搭建了一个小一些的备份集群，存储最核心的数据，与主集群构成双活来分流部分查询，来减小主集群负载，这样增加了50%+成本。

在得物增加了对StarRocks的研发投入后，智能运营下定决心基于StarRocks存算分离做POC，并最终顺利迁移到自建的StarRocks上。

三、基于StarRocks降本增效

存算分离带来成本下降

StarRocks 3.0起支持存算分离，在3.3版本已经比较成熟了。

StarRocks存算分离架构：

(cn是compute node，是无状态计算节点+本地缓存盘)

安全可靠使用的单副本

对比存算一体的3副本模式，存算分离使用单副本。存算分离的全量数据数据存储在远端对象存储上(上图的Distributed Storage，我们使用的是阿里云的OSS)，即使CN节点挂了，其他CN节点也仍然可以查询到数据(虽然需要重新拉取缓存数据，查询耗时会增加)，所以是可以安全可靠使用的单副本模式。这带来2/3的存储成本下降(本地盘只作为data cache之用)。

只缓存必要数据

并且存算分离不需要把所有的数据都存储在本地盘，而只需要缓存常用数据即可，在单副本之上又节省大笔存储成本，并且查询性能在使用本地缓存后能做性能一致。

并且大量使用物化视图，减少基表实际需要存储在data cache中的数据量。

上图说明506TB的数据实际只在缓存中存储了342TB

经