Doris 应用实践之高并发 & 大吞吐，如何选择？

刺骨的言语ヽ痛彻心扉 2024-04-08 13:09 57阅读 0赞

#### 文章目录 ####

*  背景
 *  一、Doris 心法？
 *   *  1. 大吞吐
     *  2. 高并发
 *  二、优化之路
 *   *  1. 选择？
     *  2. 缓存
     *  3. 并发
     *  4. 批处理
 *  总结

--------------------

## 背景 ##

Doris 官方介绍：

> Apache Doris 是一个基于 MPP 架构的高性能、实时的分析型数据库，以极速易用的特点被人们所熟知，仅需亚秒级响应时间即可返回海量数据下的查询结果，不仅可以支持高并发的点查询场景，也能支持高吞吐的复杂分析场景。

在查询引擎方面，Doris 采用 MPP 的模型，节点间和节点内都并行执行，也支持多个大表的分布式 Shuffle Join，从而能够更好应对复杂查询。

![在这里插入图片描述][b8577b3a36a445eea577b089dace4285.png_pic_center]

基于以上特点，开始考虑引入 Doris 解决业务上的跨库查询问题（JOIN）。

对于 B 端业务，繁琐的关联逻辑，经常会涉及到多张表关联查询，这些表可能分布在不同服务、不同库，查询条件的多样性以及数据的实时性着实让人头疼：

![在这里插入图片描述][892d784efd6d424a9614c69ab6192fb0.png]

当然，也确实有过很多优化手段，比如从产品上限制查询条件、从实现上分条件查询、历史数据归档等等。

但是，这过程仍然存在很多问题，比如 数据可能经常要从各个服务拿过来组合，查询条件可变化，并且筛选条件需要不同服务来处理。`这就是典型的跨服务条件筛选`。

![在这里插入图片描述][4c612563509142bd8d6b582f123eb336.png_pic_center]

即使分页查询在这种情况下，由于查询条件分散，服务间的查询很难做到单纯的分页处理。然后就伴随着大批请求参数传递，大批 IN 查询等等。

直到引入 Doris，解决了我们以上部分场景。

--------------------

## 一、Doris 心法？ ##

武侠小说里常常出现的词，武功秘籍心法 ------ 决定了你能否修炼达到上层境界。Doris 也一样，只有理解了其核心能力，才能绽放其光芒！

在 Doris 官方介绍里，`高并发`、`大吞吐` ，同时支持亚秒级响应，似乎是 OLAP 领域完美的解决方案。如果你有所质疑，那应该就是过来人了。

![在这里插入图片描述][fa7100c9d92b4927b19678e1fc418e41.png_pic_center]

Doris 引入后，应用的第一个需求便是十几张表关联的大吞吐查询，从实时性和开发量来看确实有很大提升。但是，也存在一个极大的缺陷，业务在高峰期使用时，Doris BE 节点经常宕机。

我们曾一度怀疑 Doris 高并发的虚假性，线上配置 8 台 8 核 16G 的 BE机器，QPS 撑不到 10 。

慢慢地，我们发现，`Doris 的 高并发和大吞吐需要分开考虑`，也就是说，大吞吐的查询下，很难达到高并发，还得思考一些配套方案。

通过 Doris 实践，我们发现影响查询效率的因素主要有：

*  扫描的数据量
 *  节点间是否大批数据做 shuffle
 *  聚合查询
 *  排序
 *  开窗函数
 *  …

大致可以从这些方面尝试提升效率，常见的有 SQL JOIN 优化，感兴趣可以了解下。

当 SQL 层面已经无法优化之后，针对高吞吐和小吞吐的查询需要采用不同的策略。

### 1. 大吞吐 ###

对于这类查询一般相当耗费集群内存资源，很容易导致 OOM，从而引发机器宕机，因此需要做到：

*  控制好此类查询的并发度。
 *  同时，也要尽可能提升查询速度，避免长时间查询占用过多集群资源。

### 2. 高并发 ###

对于小吞吐的点查询，能支持较高的并发。究其原因：

*  本质还是扫描数据少，单个查询占用极少内存资源。
 *  配置：两台 4 核 8G 的 BE 节点，小吞吐的点查询 QPS 能达到 300+。

小结下：Doris 官方文档已经说的很清楚了，支持`高并发的点查询` 和 `复杂的大吞吐查询`。因此，你在评估需求时，要区分好这两类场景。

## 二、优化之路 ##

再来回顾下我们的需求：数据实时性、涉及 15 张数据表且跨库查询。

### 1. 选择？ ###

如果数据不需要实时性，我们可以通过大数据组件 Hive 离线跑批，问题就简单了。不巧的是，业务就是要一定的数据实时性。

一般来说，对于这种复杂的大吞吐查询，耗时操作都在数据计算上面，我们从`计算的时间点`来看看：

*  提前处理：这种一般可以是监听 binlog 变更进行实时聚合计算 或者高频定时跑批次。查询时相当于直接查结果集，速度很快。
 *  查询时处理：用户请求真正过来了才进行处理，比如 JOIN 等。

两种处理方式各有优缺点：

*  提前处理：将耗时的操作前置。一般是实时监听 或者 定时预处理，并存储处理结果，查询上基本支持高并发，而坏处是较多的开发量（实时监听）或者 数据有一定的延迟（定时跑批）。
 *  查询时处理：耗时的逻辑后置，用户请求来了才真正开始处理，无法应对高并发、请求不可控容易宕机等。好处是无冗余数据，数据实时性高。

从具体方案上来看：

1）提前处理：

*  我们可以采用后端常规方案，定义大宽表，定时（频次高，比如 30s、60s）从多个微服务拉数据组合并更新大宽表。这种方式，需要控制数据量，否则大批数据传输和更新将成为瓶颈。
 *  采用大数据 Flink 组件，本质是监听 binlog 日志，实时洞察数据变更。这种方式比较通用，但需要写多个监听任务，开发量上去了。

2）查询时处理：

*  用户请求来一条处理一条，不用考虑数据冗余、数据更新以及大量的开发量，一条 SQL 搞定所有，应该是最理想的方式。

业务上这种场景挺多，我们迫切需要找到一种，直接提供给业务使用的跨库、跨服务查询解决方案。

基于以上原因，我们选择了 Doris，用来应对查询时计算，通过一条大 SQL 解决了这个问题，大概是这样：

![在这里插入图片描述][3a70e5893ffb480fa045c8b95a779c9c.png_pic_center]

### 2. 缓存 ###

你也看到了，一条 SQL 而已，快速的上了线。

当我在页面上连续点击多次，问题来了，请求处理不了。查询 Doris 集群监控，发现某节点因 OOM 宕机。

观察用户使用习惯发现，高峰期大部分请求参数都一样，也就是说，返回的结果基本也都一样。嗯，没错，考虑加上缓存避免所有请求全部打到 DB。

业务上要求实时性，缓存时间不能过长，默认加了 30s

### 3. 并发 ###

缓存上了之后，大部分情况下能正常应对了，但偶尔还是会出现宕机。