StarRocks实战——vivo基于 StarRocks 构建实时大数据平台

前言

一、数据挑战

1.1 时效性挑战，业务分析决策需加速

1.2 访问量挑战，性能与稳定性亟待提高，支撑业务稳定运行

1.3 计算场景挑战，难以满足业务复杂查询需求

1.4. 运维挑战，用户查询体验需优化

二、OLAP 选型与实践

三、应用实践

3.1 数据链路优化

3.2 列更新

3.3 集群监控告警

3.4 集群弹性部署

四、结语

原文大佬写的这篇StarRocks 实时数仓建设案例有借鉴意义，这里摘抄下来用作学习和知识沉淀。

前言

vivo需要基于移动终端的制造、物流、销售等各个方面的数据进行分析以满足业务决策。基于 Trino 的架构面临着数据时效、查询性能、并发能力、复杂运维等方面的瓶颈。

在数字化演进的过程中，vivo面临着业务诉求和技术架构方面的新挑战，主要包括时效性要求提升、访问量大、计算场景复杂和运维难等问题。

vivo原有数据平台是基于Trino+Hive 的架构来实现，通过 Trino 来抽取业务库里的数据（MySQL、Oracle、SQLserver 等），之后将抽取数据写入到 Hive 中，根据业务侧需求进行数仓的加工处理。

基于Trino+Hive架构的小时级数据时效性已经无法满足业务需求，业务侧需要数仓架构能够实时抽取业务侧数据并加工，从而实现上层报表的实时呈现，以便更好地支持相关的决策分析。

随着业务规模向全球发展，vivo 的分销代理系统覆盖用户量级飞速增长，营销、计价、订单、库存等业务系统均需要实时数据来保证销售业务精准稳定运营，这使得原有数仓架构的访问量持续增长，同时，随着各种大数据分析相关新业务的上线， Trino 负载越来越高，逐渐无法满足访问量持续增长带来的查询压力。

在业务侧的实际分析需求中，经常会有十几张表 Join 的场景，业界存在 Flink 和 Trino两种方案。

方案一是在写入数仓前利用Flink等提前做好相关表的Join计算，将其加工成大宽表写入数仓中，但Join后的数据存储占用代价高。

方案二是直接将各个维度存储在数仓中，分析查询的时候，分析查询的时候再进行Join计算，但 Trino 在处理多表 Join 时性能一般，难以满足业务侧实际的查询需求。

这两种方案都没有办法很好的平衡表Join的性能和数据存储占用的问题。

在实际运维使用Trino的过程中，发现Trino不支持高可用和多副本的问题，在业务高峰期，Trino 负载较高，会影响到数据平台的稳定性和用户查询体验，降低业务决策效率，甚至有可能收到用户对数据平台的投诉。

IT 部门调研了几款当前比较流行的 OLAP 引擎，包括 Trino、Clickhouse、StarRocks 和 Doris，并从查询延迟、SQL 类型、并发性能、Join性能和运维成本等多个维度进行了对比：

Trino 当前的查询性能和并发能力是无法满足需求的，且 Join 查询的能力也相对较弱。
Clickhouse 虽然查询延迟表现很优秀，但由于其支持的 SQL 类型为非标准 SQL，可能会涉及到较多的业务改造，同时其并发能力和 Join 能力也无法满足需求，且运维起来比较复杂。
StarRocks 在调研的各个维度上表现都非常好，能够很好地解决当前数仓架构所面临的问题。
Doris 在选型时还不支持向量化引擎，其查询表现和 StarRocks 相比还存在一定的差距。