Doris Apache 复杂查询响应速度提升10 倍度言软件基于实时数仓建设实践 (doris安装部署)

杭州度言软件有限公司（度言软件）成立于 2014 年，是信贷不良资产处置技术服务供应商，以“智能科技赋能不良资产处置，推动贷后行业合规高效发展”为使命，运用云通讯、大数据、人工智能等智能科技为信贷不良资产处置业务赋能，提供贷后管理通信能力支撑，实现了催收作业的智能化管理，客户群体为银行、消费金融公司、AMC 等金融机构和为这些机构提供人力资源外包服务的相关公司，目前已拥有 2000 多家企业客户。

度言软件以围绕信贷不良资产案件高效流转管理为目的核心，从机构管理、团队管理、坐席管理、外呼作业、调解法诉等环节入手，帮助客户构建数智化的业务管理体系，以数字化系统提升管理效能、以智能化工具赋能处置作业，打通金融机构、外包服务公司、司法系统等多方的业务系统，并按照监管要求

业务需求

2021 年之前，度言软件旗下产品的数据需求主要由传统数据库 MySQL、MongoDB、ElasticSearch 为主的技术架构来实现，近两年随着业务不断发展带而来数据量的高速增长，传统的数仓技术架构已初显瓶颈，难以满足客户日益丰富多样化的数据及分析需求。为了给客户提供更优质的服务体验，度言软件亟需对现有的技术架构做出优化和重构。

早期架构及痛点

数仓架构 1.0 版本

初创期间，由于公司业务量相对较少，主要还是以 OLTP 业务和少量的业务报表服务为主，并且对于数据分析方面的需求也很少，仅通过传统的数据库基本就能满足早期的业务数据需求。 数仓架构 1.0 如下图所示：

数仓架构 2.0 版本

随着公司业务的不断扩展，数据体量也出现极速增长的态势，业务侧对于数据分析方面的需求也逐渐多了起来，为此我们成立了专门的大数据团队，为搭建新的数仓及业务数据分析需求进行服务。 如下图所示为数仓架构 2.0 ：

数仓架构 2.0 版本是基于 MaxCompute + Hologres/MySQL 来搭建的。数据来源主要有 MySQL 和的业务数据以及埋点日志数据；数据首先采集到数据总线 top="2073.890625">早期架构存在的问题：

解决思路

为了解决上述问题，我们希望理想数仓能具有如下特性：

技术选型

在 2022 年 3 月份，我们对市场上主流的的几款即席查询数据库进行了调研，调研中我们发现每个产品只能满足某 1 个或几个特定的使用场景，没有一个产品可以完全满足所有的选型要求，而同时采用多个产品，将大大增加开发运维成本，同时也会使架构变得更加庞大复杂，这并不符合我们对理想数仓的要求。

正在这时，我们从开源社区、技术媒体等渠道了解到了Apache Doris，经初步调研，我们发现基本可以满足我们对理想数仓的所有要求。接着我们对 Doris 展开了深入调研，并使我们最终决定使用 Doris：Doris 架构非常简单，只有 FE 和 BE 两类进程，这两类进程都可以进行横向扩展，单集群可以支持到数百台机器、数十 PB 的存储容量，并且这两类进程通过一致性协议来保证服务的高可用和数据的高可靠。这种高度集成的架构设计极大的降低了分布式系统的运维成本，同时也不需要依赖于 Hadoop，避免了我们需要投入成本来额外部署 Hadoop 集群。

基于 Doris 的新数仓架构设计

最初使用 Doris 的初衷是替换部分 MySQL 数据量较大的报表，基于 MySQL 的查询约需要几十秒的响应时间，在替换为 Doris 后，查询性能有了显著提升，几秒内即可返回结果，最长的 SQL 执行时间大概在 8 秒左右，速度相较于之前提升了 8 倍。Doris 的初步应用就给了我们一个意外的惊喜，因此我们决定使用 Doris 完全替换掉早期数仓中的 MySQL，在这使用过程中，我们又发现 Doris 远比我们想象的要强大，目前已将客户报表及公司内部运营决策数据全部迁移至 Apache Doris，并计划用 Apache Doris 来替换 MongoDB 和 ElasticSearch，用于业务上高 QPS 的点查场景。 以下是基于 Doris 的新数仓架构设计及使用情况：

数据建模：

我们在业务上使用最多的是 Unique 模型和 Aggregate 模型，这两种模型基本能够满足业务需求。

数据接入：

数据开发：

目前 Doris 主要以提供终端查询为主，复杂的 SQL 开发任务运行比较少，为尽可能减少 Doris 在数据加工方面的资源消耗，当前仅有报表集群在凌晨执行少量的 SQL 任务，主要以 Doris SQL 通过 insert into 的方式来导入。

数据管理：

Doris 支持将当前数据以文件的形式通过 Broker 备份到远端存储系统中，后可以通过恢复命令从远端存储系统中将数据恢复到任意 Doris 集群。通过该功能，Doris 可支持定期对数据进行快照备份，也可以通过该功能在不同集群间进行数据迁移。我们也会定期将集群数据备份到阿里云 OSS 上，作为备用数据恢复方案。另外，在这期间我们对 Doris 集群进行了一次拆分，将报表集群和业务上的高并发查询集群分开，采用了 Doris 的数据备份和迁移功能。

监控和报警：

我们使用官网推荐的 Prometheus 和 Grafana 进行监控项的采集和展示，Doris 本身提供了丰富的监控指标和标准监控模版，可以非常便捷地对 Doris 集群使用情况进行监控和报警。

另外，为了进一步对慢 SQL 进行优化，我们还部署了审计日志插件，对于特定用户和特定的慢 SQL 进行优化和资源限制。如下是我们日常使用中的一些指标：

慢 SQL 查询：

对于一些长文本 SQL，无法完全展示，可以进一步查看 fe.audit.log 。

主要查询统计指标：

优化实践：

提高并发

我们考虑在资源给定的情况下，如何最大程度地提高并发。刚开始引入 Doris 集群的时候，我们尝试对复杂 SQL 进行压测（SQL 层面优化已完成），但始终无法达到预期的压测效果。后来我们尝试调低 parallel_fragment_exec_instance_num 的值，顺利完成了压测目标。

如下图，我们可以看到，在参数设置为 16 的时候，异常率高达 82.84%，并且期间还出现了 BE 宕机重启，将参数调低至 8 后，异常率也同步降低到了 27.66%。最后我们将参数设置为最小值 1 后，异常率为 0，查询响应也能达到预期目标。

说明：测试环境已重新取数，配置较低，数据仅用来说明 parallel_fragment_exec_instance_num 变动所带来的效果。

当参数调整为 1： parallel_fragment_exec_instance_num = 1

当参数调整为 8： parallel_fragment_exec_instance_num = 8

当参数调整为 16： parallel_fragment_exec_instance_num = 16

BE 内存问题

最初我们使用的是 Doris 0.15 的版本。由于刚开始处于测试阶段，Doris 集群配置比较低或参数配置的不合理，当某些 SQL 扫描数据量较大时，就可能因为内存问题导致 BE 宕机。

在向社区咨询后，了解到 Supervisor 是用 Python 开发的一套通用的进程管理程序，能将一个普通的命令行进程变为后台 Daemon，并监控进程状态，异常退出时能自动重启，因此我们参照官网给出的例子直接用 Supervisor 对 Doris 的 FE 和 BE 进程进行管理。

但是在运行了一段时间后，新的问题又出现了(已升级到 1.1.0 版本)。Doris 的 BE 节点内存一直在缓慢上升状态，并且达到了设置的最大内存参数 80% 后仍在继续上涨。后经分析发现 BE 存在内存泄漏问题，因此设置的参数并未生效。为此，我们将 Supervisor 切换为 Systemd 来守护 FE、BE 进程，限制整个节点的内存使用上限。不过在 Doris 1.1.3 推出之后，此问题已得到彻底的修复。

资源占用

在迁移完新集群后，我们发现通过 Flink-Doris-Connector 数据导入占用非常高的集群资源，虽然设置了按批次写入(每 3s 写入一次 )，以限制数据的导入频率，但集群资源的占用仍未得到较大改善。因此我们在集群资源和数据实时可见性方面做了权衡，介于我们对数据实时性的要求相对不是太高，所以我们将每 3s 写入一次改为每 10s 或 20s 写入一次，调整写入时间后，集群的 CPU 资源占用下降明显，得到改善。

应用现状

目前度言软件有 2 个 Doris 集群，1 个集群用作线上业务的查询系统，主要是应对高 QPS 的点查场景，我们将原先基于业务库 MySQL 和 MongoDB 的查询迁移至 Doris，一方面减少了业务库的读写压力，同时也提高了用户查询服务的使用体验。在 Doris 中，最复杂的查询在 1 秒以内即可响应，响应速度提升了十几倍；另外 1 个集群主要用作即席查询(AD-Hoc Query)和报表分析，具体包括公司内部使用的所有报表和一些临时查询、客户报表、数据实时大屏。

总而言之，使用 Doris 替换了部分业务使用场景后，用户在产品上的使用体验有了进一步得到提升，页面打开更加流畅，原本因为查询慢而不能实现的功能，当前已经实现并上线使用。同时在资源成本上也减轻了 MySQL 和 MongoDB 数据库的压力，不需要频繁进行升配和磁盘升级。

总结规划

效果总结

未来规划

到目前为止，基于 Doris 的实时数仓搭建已基本完成，但我们对 Doris 的进一步尝试才刚刚开始，比如 BE 的多磁盘部署，物化视图的使用，Doris-On-ES，Doris 多租户和资源划分等。

此外，我们也希望 Doris 未来能对以下功能进行进一步优化：

从 3 月份使用 Doris 以来，我们一直都和 Doris 社区保持着密切的联系，后续我们也将继续围绕 Doris 作为实时数仓应用到更多的业务使用场景中，对于使用中遇到的问题和优化的方案，我们也会持续和社区保持热切联系，为社区进步贡献我们的一份力量。