本文发表于： &{ new Date(1656259200000).toLocaleDateString() }

作者：杨操，欢聚集团高级大数据开发工程师，主要负责 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 监控方案，同时配置了告警。

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

• 表结构不合理：数据倾斜、分桶数量不合理，并行度不够。
• SQL 不合理：索引、物化视图无法命中，分桶、分区裁剪失效。

这些问题会影响查询性能和慢查询率 SLA。为了发现和解决这些问题，做到提前感知、提前优化，我们需要监控所有的查询日志，并及时通知用户优化表结构和查询 SQL。

监控方案：https://docs.starrocks.com/zh-cn/main/administration/Monitor_and_Alert

解决方案

StarRocks 查询状态监控。通过解析 audit.log 结合 explain SQL 的信息，统计每个慢 SQL 的执行时间、内存使用、返回行数、扫描数据量等情况，对慢查询做到及时预警。主要流程可分为以下三个步骤：

1. 解析 audit.log

FE 的 audit.log 提供了查询类型，客户端 IP，查询用户名称，数据库名称，状态，扫描的数据大小，扫描的数据行数，结果数据行数，查询 ID（通过 ID 去 BE 日志找对应的查询资源），查询的 SQL；

2. 获取 Plan fragment

通过查询该 SQL 的逻辑执行计划（explain + sql）；

3. 统计资源消耗

通过 fragment_id 查询当前物理执行计划所消费的资源：

最终实现方案如下图所示：

filebeat 采集 audit.log 和 be.INFO 日志发送到 Apache Kafka，然后 Flink SQL 聚合 query_id 和 fragment 的数据，并将数据写入到 MySQL。

整体效果

整套监控系统已经在集团上线并平稳运行。上线后极大减轻了我们的运维工作，基本可以做到提前预防问题、发现问题、解决问题，有效保障了 SLA。

降低门槛，不折腾用户

在以往的工作经验中，做平台的和上层用户会存在一些沟通障碍，用户往往不了解平台的架构、技术、能力、使用流程。平台技术做得再好，最终还是要通过服务用户来产生价值。

为了能更好地服务用户，我们做了很多降低门槛的工作。

与现有的平台做打通

离线导数，目前已经和离线调度系统打通，固化了一个离线作业类型，通过 Broker load 的方式导数，Hive 表可以一键订阅到 StarRocks。

实时导数，目前用户可以通过 Flink-Connector-StarRocks 的方式，用 Jar 或者 Flink SQL 快速实现导数。

Hive 外表，支持使用 Hive 外表的方式，直接用 StarRocks 查询分析 Hive 数据，省掉导数流程，适合某些临时性质的需求。

数据应用系统，目前已经和 BI 分析系统、自助分析系统打通，使用 MySQL JDBC 的方式接入。

业务系统，目前提供 API 和 MySQL JDBC 两种方式给业务系统直接查询。

使用流程产品化

目前我们实现了一个 web 系统 StarRocks 管控台，用户在页面上自助申请用户、建库、建表、权限等。

主动深入业务

目前我们 OLAP 团队每周都会参加业务的产品周会，关注业务动向和痛点，从 OLAP 角度提供解决思路和咨询服务。同时增加与产品和业务团队的沟通，减少彼此之间的认知屏障。

紧跟社区，不搞内部版本

StarRocks 目前处在快速更新迭代的时期，两个月左右就会出一个版本，对问题的响应和处理速度也堪称神速。在这个背景下，我们决定不搞内部版本，享受社区红利的同时也回馈社区。这里有一些经验：
 

1. 发现问题及时提 Issue，和社区一起跟进解决。

2. 主动承接一些工作量较小，实现难度较低 New Feature 或者 Bug Fix 工作，社区有专业导师指导，完成后及时发起 PR。

3. 线上版本，使用社区的 Release 版本 + 本地提前 Cherry-pick 的方式，保证既能使用一个相对稳定的版本，又能提前修复影响较大的 bug。

#04 近期规划

我们最终的目的是为了更好地满足用户的分析查询场景，提高效率，服务业务。在未来使用 StarRocks 过程中，主要的优化方向有以下几点：
 

1. 新增建表的审计功能，合理使用分区分桶字段，加速数据查询。

2. 通过对用户的行为分析，统计出报表高频的查询场景，使用物化视图进行数据的预聚合，进一步提升查询性能。

3. 优化多表 Join 分析查询场景的性能，使用 Colocation Join ，通过预先的数据分布，减少节点间网络传输带来的延迟开销，进一步提升查询性能。

4. 和社区共建，共同优化资源隔离，进一步推动使用 StarRocks 统一 OLAP。