StarRocks实战——欢聚集团极速的数据分析能力_starrocks quota

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

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

二、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 的未来更有信心。

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

StarRocks原生提供丰富的数据导入方式，Http模式的 Stream load、读 HDFS的Broker load、读消息中间件的 Routing load、Flink Connector、DataX、外表支持等，方便和大数据生态完成数据集成。StarRocks查询支持最为通用的MySQL JDBC 协议，集成到各种BI，数据应用系统几乎无成本。

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

三、StarRocks 经验沉淀

3.1 资源隔离，助力业务推广

3.1.1 面临的挑战

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

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

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

3.1.2 整体效果

确认资源组能有效隔离大查询、保护小查询。

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

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

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

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

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

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

解决方案

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。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

系统化资料的朋友，可以戳这里获取](https://bbs.csdn.net/topics/618545628)**

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！