欢聚集团 × StarRocks: 灵活、统一、极速的数据分析新范式

作者

杨操

欢聚集团高级大数据开发工程师，主要负责 OLAP 系统研发与维护

欢聚集团成立于 2005 年，是一家全球领先的社交媒体企业，旗下运营有 Bigo Live 直播、Likee 短视频、HAGO 休闲小游戏等多款社交娱乐产品等。

国内互联网面向的是国内用户，在用户的行为习惯、付费渠道、物流仓储、政策合规、第三方服务等方面，都已经沉淀出一套可复用的解决方案，其中大数据平台就有一套可复用的数据模型。例如一个爆款手游沉淀出一套数据分析模型后就可以套用到所有手游，电商平台所有商户都遵循平台相同的开店模式，直播平台所有直播间都套用一样的模板，这些都有利于数据模型的沉淀、固化、复用。

欢聚集团面向的是各个国家的用户市场，因为国家发展程度、政治经济文化各不相同，数据分析场景就要因地制宜。体现到大数据平台这一层，数据来源多样化，数据分析场景复杂，数据模型复用率低，甚至不去设计数据模型。

在这样的业务现状下，原有的 OLAP 引擎已无法满足欢聚集团的整体数据分析需求，我们亟需搭建一套能力更完整更强健的长期性解决方案。本文主要和大家分享，我们如何基于 StarRocks 构建了灵活、极速、统一的全新 OLAP 分析平台。

#01

大数据平台架构

—

数据平台支撑了从数据埋点上报到数据应用的全链路数据服务，也提供了埋点管理平台、离线计算调度系统、实时计算平台、数据应用系统等众多数据产品，实现了闭环的一站式大数据平台服务。

总体架构分层上，可以分为数据集成、存储、计算、分析、应用。OLAP 系统是分析层的核心引擎，支撑自助 AdHoc 分析、多维分析数据服务、BI 报表、标签画像等分析场景。

#02

OLAP 选型与改进

—

此前，我们使用 ClickHouse 作为 OLAP 引擎，但随着业务对灵活性要求越来越高， ClickHouse 遇到了难以逾越的瓶颈。因此，我们重新梳理了需求，试图寻找一款更加适合欢聚集团的 OLAP 引擎。

针对出海业务的特殊性，大数据团队需要提供非常灵活多变、轻量、高效、包容的数据分析服务：

灵活多变: 相比数据量和性能，灵活性更重要
轻量: 架构要简单，最好能一个引擎搞定所有场景
高效: 使用门槛要低，各种业务都能快速接入使用
包容: 能良好地兼容大数据生态

具体的诉求是：

支持 ROLAP、MOLAP 分析场景
数据模型支持宽表、星型、雪花等
同时兼顾数据量(PB)、查询性能(秒级)、灵活性(导数与查询灵活多变)
数据时效性上支持离线批处理，实时流处理秒级可见
数据写入支持 Append、Overwrite、Upsert、Delete
高可用、灵活扩缩容，低运维成本
较高的 QPS
支持分析 Hadoop 上的数据

在这种“既要又要还要”的诉求下，选型很困难。OLAP 常用的技术架构有预计算、MPP、索引。我们调研了这三类架构的典型 OLAP 引擎：

预计算架构：代表引擎 Apache Kylin/Apache Druid ，查询性能优越，但缺少灵活性。
MPP 架构：Presto/Apache Impala/SparkSQL，灵活性很好，但是性能较差，一般在分钟级。
索引架构：ES/ClickHouse，单表查询性能优越，但是 Join 几乎不可用，只能用宽表模型。

单一技术架构的引擎很难满足需求，因此我们把目标瞄向混合架构引擎：同时具有预计算、MPP 计算、支持索引的引擎。目前市面上这类引擎不多，比较成熟的有 Apache Doris 和 StarRocks。

最后选择 StarRocks，原因是 StarRocks 的社区更加活跃，产品的背后还有一支大胆创新的强大技术团队，响应非常及时，我们对 StarRocks 的未来更有信心。

StarRocks vs ClickHouse

选型过程中，因为当时用的架构是 ClickHouse，因此重点测试对比了 StarRocks 和 ClickHouse，StarRocks 总体比 ClickHouse 更适合欢聚集团的场景需求。

性能

测试环境：

测试数据量 12亿条
3台服务器（32核 128G SSD）
SQL：TPCH

测试结果如下：

针对我们的典型业务场景，StarRocks 整体性能相比 ClickHouse 有 4-10 倍的提升。

容灾

StarRocks：数据自动均衡，在线扩缩容。拥有完善的 backup restore 方案。

ClickHouse：手动备份，扩缩容困难。

灵活

StarRocks：单表性能优于 ClickHouse，多表性能优异。

ClickHouse：多表 Join 场景的性能较差，优化难度高。

运维

StarRocks：架构简单，运维成本低。

ClickHouse：依赖 Apache Zookeeper，线上问题排查困难。

另外 StarRocks 社区的故障响应速度非常快，沟通成本远远低于 ClickHouse。

应用 StarRocks 后的 OLAP现状

如上图所示，我们的 OLAP 系统架构非常简单轻量，与大数据平台上下游都做了整合。

StarRocks 原生提供丰富的数据导入方式，Http 模式的 Stream load、读 HDFS 的 Broker load、读消息中间件的 Routing load、Flink Connector、DataX、外表支持等，方便和大数据生态完成数据集成。

StarRocks 查询支持最为通用的 MySQL JDBC 协议，集成到各种 BI、数据应用系统几乎无成本。

目前我们内部整合了 OLAP 系统，下线了 ClickHouse，统一使用 StarRocks 作为解决方案，已经在实时查询、报表分析、监控等业务场景中大力推广，支撑了数百 TB 数据，数十个业务方，数百万查询量/天，总体查询性能 99 分位 200ms。

#03

StarRocks 经验沉淀

—

资源隔离，助力业务推广

面临挑战

我们的 StarRocks 集群目前都是多业务共用，其中部分业务场景是大查询。例如 BI 报表一个 Dashboard 包含多个图表，打开 Dashboard 时，所有图表一起加载，并且一般都是偏分析的 SQL，资源开销较大。此时集群资源就有一个高峰，集群查询性能衰减，特别是小查询也会受到严重影响。

上图中可以看到很多毛刺，都是大查询导致。

因为这个问题，难以保障 SLA，一段时间里我们不大敢把 StarRocks 大范围推广给业务使用。如果给业务搭建专用 StarRocks 集群，成本压力又太大。

StarRocks 2.2 版本开始支持资源隔离，支持配置资源组并分配资源 Quota，支持用户和资源组的绑定，可以有效将大查询业务场景隔离到专用的资源组，避免影响其他小查询。我们在 2022 年 Q2 上线了资源隔离功能，目前线上已经全部开启资源隔离，正在做 OLAP 业务推广。

整体效果

上线资源隔离之前，我们做了一个对比测试，目的是确认资源组是否能有效隔离大查询、保护小查询，测试场景为：

测试要求：user_1 user_2 两个用户并发执行可以把集群的 CPU 使用率推到 100%，内存使用不超过资源组 Quota 避免查询熔断

测试用例:

a. 不使用资源组，user_1 user_2 user_3同时并发执行，统计user_3的平均查询耗时

b. 使用资源组，user_1 user_2 user_3同时并发执行，统计user_3的平均查询耗时

测试结果如下：

对比测试结果显示，使用资源组可以有效隔离开大查询、保护小查询。

需要注意的是，目前资源组的 CPU 隔离是软隔离，例如 3 个资源组 CPU Quota 都设置 10，含义并不是能独立使用 10core，而是 CPU 忙时占用 CPU 时间的比例为10:10:10，CPU 闲时可以使用所有 CPU 时间。因此当集群 CPU 使用率很高时，所有资源组的查询性能都会有衰减。

稳定优先，监控先行，优化运维

我们的集群稳定性 SLA 主要包括：集群可用性 SLA 3个9，集群查询性能 95分位 3s，BI 业务慢查询率 1.5%。

我们首先部署了社区提供的 prometheus grafana 监控 FE BE 的 metrics 监控方案，同时配置了告警。

另外在实践过程中，有时会收到业务反馈的慢查询问题，排查其原因，主要可以分为两类：