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

最新推荐文章于 2024-06-02 16:51:09 发布

2401_84182793

最新推荐文章于 2024-06-02 16:51:09 发布

阅读量677

点赞数 26

分类专栏： 2024年程序员学习文章标签：数据分析数据挖掘

本文链接：https://blog.csdn.net/2401_84182793/article/details/137660896

版权

2024年程序员学习专栏收录该内容

60 篇文章 0 订阅

订阅专栏

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

总体架构分层上，可以分为数据集成、存储、计算、分析、应用。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。

3.3降低门槛，不折腾用户

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

3.3.1 与现有的平台做打通

**离线导数，**目前已经和离线调度系统打通，固化了一个离线作业类型，通过 Broker load 的方式导数，Hive 表可以一键订阅到 StarRocks。
**实时导数，**目前用户可以通过 Flink-Connector-StarRocks 的方式，用 Jar 或者 Flink SQL 快速实现导数。
Hive 外表，支持使用 Hive 外表的方式，直接用 StarRocks 查询分析 Hive 数据，省掉导数流程，适合某些临时性质的需求。
数据应用系统目前已经和 BI分析系统、自助分析系统打通，使用 MySQL JDBC 方式接入。
业务系统，目前提供 API 和 MySQL JDBC 两种方式给业务系统直接查询。