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 相比还存在一定的差距。