数仓成本下降近一半，StarRocks 存算分离助力云览科技业务出海
平台现状
作为公司内部大数据平台部门，主要负责公司海量数据处理、数据质量保证及指标体系维护的工作，服务公司四大业务场景：用户画像、报表、实验系统以及业务服务。公司大数据平台经过上云及几次云平台迁移，当前结合某云 EMR、对象存储建设存算分离的架构，主要架构如下图所示：
如图所示，原始数据存储在 Kafka 中,通过 Flink 消费,写入到 OSS 中，然后通过 Hive 和 Spark 进行数据进一步加工，最后再将数据导入不同的 OLAP 组件中供业务查询。后期统一了计算引擎，使用 Spark on K8s 的架构，使用 Spark SQL 和自定义了 UDF/UDAF 对数据进行统一处理。
平台痛点
我们在发展过程中不断采用新技术来满足不同业务需求，日积月累，各种数据处理与分析组件越来越多，面临着巨大的压力与挑战，主要表现在以下几点：
01
01
公司的业务近几年飞速增长，伴随着业务扩张带来了数据量指数式增长。我们的分析平台规模也相应增长，使用的规模变大，平台维护成本也成倍增长。例如，仅 OLAP 我们就使用了 Trino、ClickHouse、StarRocks。其中，Trino 给业务同学提供即席查询用途，ClickHouse 负责应用与用户洞察、实验系统和报表，StarRocks 对接业务报表。维护成本高体现在：
学习成本高，不同的系统实现不同，语法兼容性不同，对开发人员提出了很高要求。
定位问题复杂，三种组件对应三套监控系统，定位排查问题需要查看不同的监控系统，搜索各自的日志，排查链路很长。
02
02
数据由客户端上报，通过统一的转发服务，进入到不同的 Kafka 实例中，再经由 Flink 消费，sink 到数仓的 ODS 层，最后通过 tez 和 Spark SQL 对数据进行处理，构建数仓分层。而这其中 ODS 层的数据统一处理，整体时间就需要3小时左右，偶尔中间任务数据产出有误，需重跑整条链路，数据延时会被进一步拉长。
03
03
当并发量大、大查询多时，Trino 很容易出现内存溢出，稳定性不足，目前统计线上查询失败的情况约有10%左右由内存溢出导致。ClickHouse 则无法处理高并发场景，很容易因 cpu 打满导致服务重启。
StarRocks 存算分离调研
StarRocks 社区在 3.0.0 版本推出了存算分离版本，与我们内部追求降本增效的目标不谋而合，我们也第一时间进行了调研测评。
在调研时我们特别关注这几个方面:
查询效率，相比存算一体，用户不能感觉到较为明显的查询变慢 显著的成本降低，这也是我们尝试存算分离新架构的初衷 能够无缝替换我们正在使用的各个组件，为未来统一分析打好基础 运维简单，减轻开发运维同学的日常工作复杂度 最后是需要社区比较活跃，问题能得到及时的处理
以下是我们针对各个维度的一些调研结果。
01
01
我们针对单表和多表 Join 两种真实线上场景进行了具体测试，采用两个相同规模的集群，对同一数据量的表，进行相同的查询，多次查询，取平均值的方式进行对比。ClickHouse 集群规模：单节点 96C * 384G , StarRocks 集群 6 * 16C * 64G。单表查询的数据量大小为 200G，数据行数为1.3亿行，对表进行 count 计数查询。Join 查询为表进行自 Join，然后进行 count 计数查询。
StarRocks VS ClickHouse
测试表明，在 ClickHouse 最拿手的单表查询场景中， StarRocks 存算分离性能可以保持一致，在多表 Join 场景中，StarRocks 能快3倍左右。
02
02
在对比了性能后，我们对比了存算一体和存算分离的成本情况。在存算一体中数据量 1T 的表通过 export 到 OSS，再通过 Broker Load 到存算分离集群中，由标准磁盘存储转换为对象存储，后期还可以在对象存储内将数据进行冷热归档，进一步节省成本。从云服务文档中了解到，标准磁盘存储 1T 存储一天7$(某云法兰克福区磁盘计费)，转为对象存储 1T 存储一天0.478$(某云法兰克福 OSS 计费)，存储费用降为原来的1/15。成本的详细计算可以看后文。
03
03
我们了解到 StarRocks 也推出了 Operator 支持 K8s 集群部署。利用 K8s 本身的容灾恢复机制以及强大的 StarRocks Operator 显著降低了集群部署运维复杂性。另外，StarRocks 还提供了较为丰富的监控和诊断工具，便于我们在第一时间观察系统运行情况。
StarRocks 存算分离实践
01
01
物化视图
在一些实时查询的场景，我们发现，通过物化视图进行预聚合的方式，能达到查询事半功倍的效果。例如我们的实时分析场景，通过 Flink 直接将明细数据写入到 StarRocks，最初直接对原始明细数据复杂查询，耗时约30秒左右，后来看社区力推物化视图，我们也为该表创建异步物化视图，对明细数据进行预聚合，结果显示，查询延迟降低为3秒左右，带来了10倍性能提升。
物化视图的场景我们刚刚体验，就取得了比较惊艳的效果，未来我们将在更多场景中推广该能力，进一步提升业务同学体验。
数据分桶
在初见 StarRocks 存算分离时，我们简单认为数据存储在对象存储中，建表时我们没有关注分桶数设置，分桶数设置过多，结果在使用时发现随着系统 Tablet 数量越来越多，发现 FE 的内存被打满。后来在社区同学帮助下定位发现是由于 Tablet 过多导致 FE 节点一直在 GC。最后通过增加 FE 内存，再按数据量合理分配不同表的分桶数便彻底解决了该问题。
根据我们实际使用的经验来看，一般为每个分桶差不多容纳 1 ~ 3G 数据容量比较合理，过多的数据分桶会产生大量的小文件且降低了 I/O 效率，而分桶数不足则可能会影响查询的并发效果。
聚合查询模型
最初公司大部分报表都是参照 Kylin 模型，使用 Hive、Spark 将数据预聚合处理，再将处理结果数据导入到 StarRocks 中进行查询，依靠 StarRocks 强大的查询能力降低查询延迟。
这种方式虽然提升了查询速度，但会导致数仓中结果表的数据量膨胀，且部分报表增加维度后会存在数据兼容性问题。后来我们将部分预聚合查询转换为 StarRocks 的聚合模型，通过测试和提前预聚合的查询效率几乎相同，同时也解决了数据膨胀和历史数据兼容问题。
Cache
上面我们提到调研测评时，我们也详细评估了存算分离与其他系统的性能对比，上面的测试都是在开启 Local Disk Data Cache 情况下达到，因此，我们对于线上所有的表在创建时都开启了 Data Cache。
目前，我们线上计算节点规模为6个，每个计算节点配置了 2 块 200G 容量大小的 SSD（最好不要用 HDD），通过该配置，我们基本上能将业务访问的热点数据都缓存在 Local Disk 上。同时，我们观察到目前线上磁盘使用到达一定量时，存储空间会自动下降，经过与社区沟通发现这是内部触发了自动 LRU 缓存淘汰，这一点极大缓解了我们空间焦虑。
02
02
使用 StarRocks 存算分离替换现有架构后，能在以下三个方面给成本带来较大的降低：
将 OLAP 组件换成 StarRocks，首先是通过聚合模型替代在数仓中的结果表预聚合，不必对所有维度进行排列组合，计算各个组合的结果数据。省去这一步骤后，存储对比之前减少了20%左右。 通过使用 StarRocks 存算分离，数据被存储在对象存储，通过将存算一体集群中 5T 左右的数据导入到对象存储中，一个月能节省 1000$ 左右，未来随着数据量的不断增长，成本降低会愈发明显。 使用 K8s 部署，方便部署的同时也省去了一笔不菲的云平台服务费。
通过以上几点综合测算，相比原来使用 Spark 离线计算出结果，再将结果导入ClickHouse 的方式，使用 StarRocks 存算分离，我们将成本降低了 46%。
03
03
StarRocks 的监控可以无缝对接 Prometheus 和 Grafana，使用 StarRocks 存算分离版本后，我们根据建议首先配置了较为完善的监控，StarRocks 存算分离在存算一体基础上增加了不少对于系统 I/O 等指标，通过这些监控我们可以直观查看当前的各种指标。
FE、BE相关监控
StarRocks I/O 相关监控
另外，我们使用过程中比较关注查询性能问题，而也出现过由于版本太多导致了查询时读取文件数较多的问题，在社区提醒下，可以利用 SQL 监控当前集群 Compaction 情况：
有了这种监控，我们也能看出当前是否出现 Compaction 慢等情况并考虑是否资源不足，需要扩容。
另外，从使用来看，相比于存算一体，存算分离版本有一个极大的简化就是无需关注多副本数据一致性，存算分离数据位于 OSS 之上，本地缓存单副本，再也无需关注副本的数据均衡迁移、数据修复等问题，这是一个不小的解放。
最后，社区的各种文档也比较丰富，尤其是存算分离最近给我们提供了最佳实践、各种运维指导、参数优化等文档，作为 StarRocks 新用户，我们也能根据这些文档快速上手取得最佳效果。当然，随着使用的深入，我们还希望能更深入地了解 StarRocks 内部实现原理，希望社区能在这方面提供更多指导。
我们使用存算分离集群，上线初期遇到了一些 bug 导致集群运行不稳定，但是在社区帮助下，我们快速定位并修复后，现在集群已经稳定运行了3月有余。
04
04
由于目前社区尚未提供一键式迁移工具将数据从存算一体集群迁移至存算分离集群，咨询过社区后，我们决定采用 export 到对象储存再使用 Broker Load 到新集群的方式进行数据迁移。
另外，在进行 Broker Load 时，导入任务和线上查询任务会对磁盘的 I/O 资源产生争用，这可能会导致 K8s 将 BE 节点驱逐，进而导致短时间 StarRocks 查询变慢，对此我们也建议降低 Broker Load 并发度，同样通过分批导入的方式来减少 I/O 争抢。
通过 Export + Broker Load 配合我们提到的优化手段，目前，我们已经将线上 80% 的业务数据迁移到存算分离集群中，并做到用户在使用上体验感更佳。后续会继续将所有业务迁移至集群，最终完成统一大业。
另外，我们也从社区获知，社区已经在推进一键式迁移工具的开发，如果不着急的小伙伴可以等等这个，我们后续也会尝试使用这种新方式来提升数据迁移效率，另外，我们也很期待社区能推出从更多数据源的迁移方式，便于我们可以更快速地将数据架构统一至 StarRocks。
未来规划
短期目标
短期目标
数据入仓后，ODS 层的统一处理需要2-3个小时，这对数据及时产出有不小的影响，且计算成本较高。通过对数据湖的调研，我们计划将 ODS 层的处理提前到 Flink 当中，省去这几个小时的计算时间和计算资源，将 Flink 处理的数据直接落入数据湖中。利用 StarRocks 和数据湖的结合，实现对数据的实时查询，解决离线数仓中的数据不方便实时查询的问题。
长期规划
长期规划
在文章的开头我们也提过，公司现在使用了三种 OLAP 组件服务不同场景，每种组件都需要将 Spark 加工好的数据导入至对应系统，运维复杂，难以保证数据时效性同时数据的多方存储也进一步提升了成本。我们也一直在思考，能否做到 Spark 不参与计算加工，只用 StarRocks 搭建数仓呢？经过我们调研推导，发现还是有可能实现这一步的。
具体来说，Flink 消费 Kafka 的数据后，直接入湖（Hudi、Iceberg 等），接下来我们利用 StarRocks 作为计算引擎直接查询湖上数据，利用强大的湖查询能力（这块尚未深入测试，看社区其他用户有不少 Good Case）可以直接进行查询，对于某些查询效率较低的查询，我们直接为其构建物化视图。
我们之前的测试表明，利用物化视图能带来 10 倍以上的加速效果。构建数仓的过程中，涉及到简单的 ETL 也能够通过逻辑视图结合物化视图的方式来完成。通过这样一套 Lakehouse 新架构，我们理想中能够达到以下几点目的：
去掉当前多套 OLAP 服务，只保留 StarRocks 作为计算引擎，节约大量计算资源 数据无需多处存储，降低数据延迟时效性。同时使用存算分离架构，数据单一存储能节约大量存储成本（尤其原来存算一体架构下数据依靠云盘多副本存储，云盘价格过于昂贵） 利用 StarRocks 存算分离带来的弹性和数据共享能力，我们可以做到 1). 为不同的业务实现资源硬隔离； 2). 业务峰谷期间可以轻松实现快速弹性，业务高峰期快速扩容以应对突发流量，业务低峰期可以快速缩容以削减成本 架构简化也减轻了运维复杂度，使得我们有更多时间可以考虑提升业务增效，来达到公司降本增效的目的。
而且，通过调研学习，发现众多业内技术领先企业和我们的想法不谋而合。
如果你对存算分离功能感兴趣或是在使用上遇到了什么问题，欢迎到群里交流！
StarRocks 存算分离用户小组
关于 StarRocks