背景
知乎舰桥平台是知乎内容&用户平台团队提供的面向找人、找内容、盯人、盯内容、找机会、查问题等场景提供的业务系统。当前该系统在知乎的社区、商广、教育&会员、技术中台等不同事业部得到广泛的使用。
舰桥平台的基础能力，包括筛选、分析，都不同程度地依赖 Apache Doris 提供的计算和存储能力。随着用户逐渐增多，业务上对舰桥提出了新的要求，高效筛选&分析，低响应时间，秒级别返回成了技术层面面临的新难题。与此同时，Apache Doris 社区在快速发展，社区发布的 1.1.2 版本已经在计算层和存储层全面支持了向量化，查询性能相比非向量化版本有了明显地提升，基于知乎舰桥的 Apache Doris 集群进行向量化版本升级势在必行。
使用场景
知乎舰桥平台六大核心场景找人、找内容、盯人、盯内容、找机会、查问题中，均对 Doris 有不同程度的依赖。
找人、找内容。筛选&打包场景：
OLAP 引擎 bitmap 倒排表，通过交并差，快速预估并完成筛选、打包能力。
找机会、查问题。分析&诊断场景：
维度&指标汇总宽表：较短时间多数据分析看板，或最新日期聚合数据看吧。
多日期指标窄表：较长时间（一年）指标变化趋势图。
盯人、盯内容。追踪、分析、报警场景：
追踪明细表：每一时刻的数据明细，用于浏览和异常异动报警计算使用。
多日期指标宽表：追踪时间内的细粒度数据趋势波动，同时可用于异常异动报警。
性能对比
集群配置
集群 |
配置 |
旧集群(未开向量化 1.0.0 ) |
3FE+32BE 内存 256G；CPU 64 核；磁盘:32*4T HDD |
新集群(向量化 1.1.2 版本) |
3FE+19BE 内存 256G；CPU 64 核；磁盘:19*4T HDD |
核心场景查询耗时对比
案例1：多维度（以 6 种维度为例）筛选、单表查询、单日期指标宽表、数据聚合 SUM，每天数据量为 1.8 亿+
关闭查询缓存、关闭向量化查询：6.99 sec
关闭查询缓存、开启向量化查询：2.00 sec
案例2：多维度（以 6 种维度为例）筛选、单表查询、多日期（以时间周期 15 天为例）指标宽表、数据聚合 SUM，每天数据量为 1.8 亿+
关闭查询缓存、关闭向量化查询：56.99 sec
关闭查询缓存、开启向量化查询：8.31 sec
案例3：单表查询、COUNT 计数，每天数据量为 1.8 亿+
关闭查询缓存、关闭向量化查询：3.25 sec
关闭查询缓存、开启向量化查询：0.64 sec
案例4：3 张表查询；A、B、C表每天的数据量分别为 1.8 亿+、150 万+、其中 B 表涉及BITMAP 聚合，A 表涉及每天数据 SUM 聚合、COUNT 聚合；A、B 先聚合再与 C 表JOIN，子表再依次 JOIN；查询过程中 JOIN 次数共为6次。
关闭查询缓存、关闭向量化查询：7.87 sec
关闭查询缓存、开启向量化查询：3.17 sec
案例5：明细分析、单表查询、每天的数据量为 5 亿+
关闭查询缓存、关闭向量化查询：7.06 sec
关闭查询缓存、开启向量化查询：4.23 sec
案例6：向量化查询在 SQL 实现逻辑优化中的应用关闭
以 theme & iw 1.0 版本领域所属 theme & iw 为例，现将领域所属 theme 规则应用于领域所属iw，规则如下：
当 iw 在某领域下覆盖内容占比(iw 领域覆盖内容数/领域总内容数)大于等于 0.05% 时,则 iw 属于该领域
若 iw 在所有领域下占比均小于 0.05% 时,取覆盖内容占比 Top2 领域作为该 iw 的所属领域
若 iw 在所有领域下占比均小于 0.001% 时,则该 iw 无所属领域
查询缓存、关闭向量化查询：0.38 sec
关闭查询缓存、开启向量化查询：0.27 sec
案例7：圈人-普通圈人条件、数据量 100w+
查询缓存、关闭向量化查询：2.7 sec
关闭查询缓存、开启向量化查询：0.2 sec
案例8：圈人-复杂条件圈人，数据量 10 亿+
查询缓存、关闭向量化查询：27.62 sec
关闭查询缓存、开启向量化查询：2.47 sec
案例9：圈人-分表 join 圈人，数据量 1 亿+
查询缓存、关闭向量化查询：3.21 sec
关闭查询缓存、开启向量化查询：0.88 sec
结果汇总如图所示
根据以上线上真实结果所示，Doris 1.1.2 版本相比 Doris 1.0.0 版本性能提升显著，对于大部分场景有2倍以上提升，少部分查询有近14倍的性能提升，效果好于预期。
调优实践
FE 下发 fragment 超时问题
send fragment timeout. backend id: xx, host: x.x.x.x
向量化版本上线后，frgment timeout 超时报错显著增加，报错发生时间段具有高 QPS 或者数据导入较频繁，排查发现，查询计划的两阶段执行机制中存在 Bug，如果执行计划被 FE 取消，BE 上已经完成 Fragment 准备工作并休眠等待的线程就不会被唤醒，导致 BE 上的 Fragment 线程池被耗尽，后续所有查询任务的 Fragment 下发到 BE 节点之后，因为没有线程资源都会等待直到 RPC 超时，社区已对该 bug 进行修了修复，同时我们还调大了 brpc worker线程池的大小，默认 brpc 初始化pthread线程数等于 cpu 核数，我们线上机器 cpu 配置是 64 核，初始化线程数 64 个，后面我们调整到了128个后，效果显著
导入方式 brokerload 切换为 sparkload
由上了向量化后,效果显著，业务侧核心 sql 的查询的耗时断崖式下降，业务侧想把更多的 hive 数据迁移到 doris 中，这时导入速度又成为了一个新的瓶颈，之前采用的是 brokerload 这种方式，在导入 TB 级别量级时，耗时需要 8 小时左右，时效性满足不了业务侧的要求, 了解到 sparkload 能够很好的解决大规模导入问题，为此我们决定把导入方式 brokerload 替换为 sparkload，切换过程比较并非坎坷，问题较多，原因是 sparkload 底层实现时 doris 和 spark 目前是耦合的，对使用者的技术要求比较全面，既要了解 doris 也需要了解 spark，而且 spark/hadoop 环境由于不同公司差异大，版本多样。在百度 palo 团队和知乎同学以及社区大佬的支持下，把 sparkload 遇到的问题解决，成功跑通，对比 brokerload，在相同数据下导入提升 9 倍，下面是主要问题列表，之前也整理过相关文章：
实战案例 | spark load 实战之 hive 数据导入 doris 提速9倍
支持返回二进制bitmap数据
圈人成功后，结果存储在 bitmap 中， 业务侧需要判断某个 uid 是否在 bitmap 中的，这个场景特点是高 qps，如果在 doris 中处理，会对 doris 增加较大压力，影响服务，所以这个判断逻辑由上层来处理，需要 doris 返回二进制的 bitmap 数据，上层缓存 bitmap，在线的 qps 直接访问缓存，然后根据 doris 提供的文档，直接解析二进制 bitmap，不再走 doris。所以需要在向量化版本支持返回二进制内容能力，目前相关 pr 已合入社区
Github链接： https://github.com/apache/doris/pull/15224
h ttps://github.com/apache/doris/pull/15273
结束语
Apache Doris 向量化版本在线上已经稳定运行 2 个月以上，在查询性能和稳定性方面已经达到了要求，一些核心 SQL 的查询性能超过了我们的预期。
最后，感谢百度PALO团队和 Apache Doris 社区对我们的鼎力支持，Apache Doris 目前已经在知乎内部得到了广泛应用，并且业务还在持续增长，未来一段时间我们将逐步推动内部其他的 Apache Doris 业务上线向量化版本。
- 作者介绍 -
侯容
知乎-平台团队-用户理解&数据赋能研发 Leader
18 年入职知乎，曾担任社区、社交等业务高级研发和业务架构师，21 年加入平台团队担任用户理解&数据赋能组研发 Leader。带领团队从 0 到 1 从底层到业务层搭建实时数据基建和业务，同时整合资源完成用户理解工程及 DMP 的建设。当前负责业务包括用户理解工程、DMP、实时数据基建以及基于用户内容理解和数据的运营平台等。
陈林忠
百度 PALO 团队资深研发工程师
在分布式存储及分布式数据库多年研发经验，擅长 Doris 执行引擎及存储引擎研发。主要负责过doris compaction优化、Remote UDAF、多表物化视图等功能的实现。
Apache Doris官方网站：
http://doris.apache.org
Apache Doris Github：
https://github.com/apache/doris
Apache Doris 开发者邮件组：
dev@doris.apache.org
本文分享自微信公众号 - ApacheDoris（gh_80d448709a68）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
