StarRocks存算分离在得物的降本增效实践 - 2024 StarRocks峰会.pdf

StarRocks存算分离

在得物的降本增效实践

丁凯剑

得物StarRocks负责人，8年OLAP研发经验，StarRocksActiveContributor，ApacheDruidCommitter

01Clickhouse在大数据量下的困境

02从Clickhouse到StarRocks存算分离

03成果展示及未来规划

01迁移背景

背景

丰富的场景

OLAP引擎在得物客服、风控、供应链、投放、运营、A/B实验等大量业务场景，在报表、日志、实时数仓

等应用场景都有广泛的应用。

使用多种OLAP引擎

引入和使用OLAP引擎的过程中业务选择当时最适合的引擎，现存云上Hologres、ADB、Clickhouse和自建

Clickhouse、StarRocks五种引擎产品

目标统一引擎

最终只保留1到2个引擎

先把一套超过4000核的最大，业务最复杂的智能运营平台Clickhouse集群迁移到存算分离的StarRocks

Clickhouse在大数据量下

02的困境

线上Clickhouse集群面临瓶颈

集群用量大缺乏离线导入功能

超过4000核导入链路存在格式转换，效率低，占用大量Clickhouse集群资源

存储超过500TB

日常需要查询日/周/月/季/年环比/同比，查询时间跨度

长

集群负载接近上限

扩容困难物化视图缺乏透明改写能力

Clickhouse单机规格已是顶配，没有升配空间建立了40+物化视图

按指定字段分桶的表，扩容后需要重导数据才能保证正确性，需要一周的停服由外部代码主动管理、创建物化视图、改写sql去查询物化视图

扩容和导入

在需要重刷历史数据时，由外部代码管理的物化视图的重刷复杂

只能搭建一个主集群一半大的备份集群，存储最核心的数据，与主集群构成双

活来分流部分查询，来减小主集群负载，这样增加了50%+成本。

03基于StarRocks降本增效

存算分离带来成本下降

单副本模式只缓存必要数据

数据存储在远端，不担心丢失不需要把所有的数据都存储在本地盘，而只需要缓存常用数据

比3副本存算一体降低2/3存储成本大量使用物化视图，减少基表实际需要存储在datacache中的数据量

命中datacache时性能与存算一体相同

扩缩容无需搬迁数据

扩缩容无需均衡，扩容新节点可以马上利用

经过评估存算分离部署模式能带来40%+的成本下降。

更好易用性

ClickhouseStarRocks

1.支持的join类型有限1.支持各种join类型且符合标准SQL语法的预期

2.Join不正确使用分布式表和local表会有性能或正确性2.不区分分布式表和local表，专注业务即可

问题

3.物化视图无侵入透明改写，并保证与基表数据一致性

3.手动改写SQL利用物化视图

4.离线导入并发可控，资源可控

4.离线导入效率不高

重度使用物化视图进行提效

使用技巧

1.不命中物化视图时，在资源组中限制大表时间跨度超过8天