目录
[三、StarRocks 经验沉淀](#三、StarRocks 经验沉淀)
[3.1 资源隔离，助力业务推广](#3.1 资源隔离，助力业务推广)
[3.1.1 面临的挑战](#3.1.1 面临的挑战)
[3.1.2 整体效果](#3.1.2 整体效果)
[3.2 稳定优先，监控先行，优化运维](#3.2 稳定优先，监控先行，优化运维)
[3.3.1 与现有的平台做打通](#3.3.1 与现有的平台做打通)
[3.3.2 使用流程产品化](#3.3.2 使用流程产品化)
[3.3.3 主动深入业务](#3.3.3 主动深入业务)
欢聚集团面向的是各个国家的用户市场，数据分析场景就要因地制宜。体现到大数据平台这一层，数据来源多样化，数据分析场景复杂，数据模型复用率低。在这样的业务现状下，原有的 OLAP 引擎已无法满足欢聚集团的整体数据分析需求，下文主要介绍如何基于StarRocks 构建灵活、极速、统一的全新 OLAP 分析平台。
一、大数据平台架构
数据平台支撑了从数据埋点上报到数据应用的全链路数据服务，提供了埋点管理平台、离线计算调度系统、实时计算平台、数据应用系统等众多数据产品， 实现闭环的一站式大数据平台服务。
总体架构分层上，可以分为数据集成、存储、计算、分析、应用。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 两种方式给业务系统直接查询。
3.3.2 使用流程产品化
目前我们实现了一个 web 系统 StarRocks 管控台，用户在页面上自助申请用户、建库、建表、权限等。
3.3.3 主动深入业务
目前我们 OLAP团队每周都会参加业务的产品周会，关注业务动向和痛点，从 OLAP 角度提供解决思路和咨询服务。同时增加与产品和业务团队的沟通，减少彼此之间的认知屏障。
四、近期规划
我们最终的目的是为了更好地满足用户的分析查询场景，提高效率，服务业务。在未来使用 StarRocks 过程中，主要的优化方向有以下几点：
- 1.新增建表的审计功能，合理使用分区分桶字段，加速数据查询
- 2.通过对用户的行为分析，统计出报表高频的查询场景，使用物化视图进行数据的预聚合，进一步提升查询性能
- 3.优化多表Join分析查询场景的性能，使用Colocation Join ，通过预先的数据分布，减少节点间网络传输带来的延迟开销，进一步提升查询性能
参考文章：