关于数据库:复杂查询响应速度提升10倍度言软件基于-Apache-Doris-实时数仓建设实践

作者 | 杭州度言软件大数据团队

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

度言软件以围绕信贷不良资产案件高效流转治理为目标外围，从机构治理、团队治理、坐席治理、外呼作业、调解法诉等环节动手，帮忙客户构建数智化的业务管理体系，以数字化零碎晋升治理效力、以智能化工具赋能处理作业，买通金融机构、外包服务公司、司法零碎等多方的业务零碎，并依照监管要求 对外呼行为、录音文件、沟通记录等案件相干数据进行记录、会集、稽核、统计和剖析，具备海量账号同时登陆、数据申请高并发、多起源数据汇总接入的特点要求。

业务需要

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

晚期架构及痛点

数仓架构 1.0 版本

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

数仓架构 2.0 版本

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

数仓架构 2.0 版本是基于 MaxCompute + Hologres/MySQL 来搭建的。数据起源次要有 MySQL 和 MongoDB 的业务数据以及埋点日志数据；数据首先采集到数据总线 DataHub 中，后通过 DataHub 间接导入到 MaxCompute，MaxCompute 作为一个离线数仓，咱们将其进行了传统的数仓分层；数据的加工解决和剖析计算次要在离线数仓中进行，并将计算好的后果导出到 MySQL 中，来对接 QuickBI 展现报表。此外，咱们还尝试了将 Hologres 用作实时数仓，作为 MongoDB 的替换计划，用于业务上的查问零碎。

晚期架构存在的问题：

1. 响应速度较慢。MySQL 对于大表的聚合计算并不敌对，响应速度较慢。产品侧要求数据查问响应工夫在 5 秒以内，尽管咱们也基于 MySQL 进行了许多优化，但优化成果非常无限，仍无奈达到 5s 的响应要求；咱们甚至尝试了间接用 MaxCompute 对接 QuickBI，心愿基于 MaxCompute 的查问减速和 QuickBI 的缓存来帮忙咱们解决问题，然而后果并不现实。
2. 维系维度表老本高、难度大。 离线数仓在数据同步的时效性上并不占优势(每 5 分钟进行一次批量同步)，因而不太适宜数据频繁更新和删除的场景，同时也给维度表的保护带来了额定的工作量。在数据更新和删除场景中，咱们须要定期通过过滤和去重来保持数据的一致性，而事实上，大多时候须要报表数据实时关联维度表，这让咱们间接放弃了在离线数仓中维系维度表的计划。
3. 不反对高并发点查问场景。 原实时数仓尽管能够满足咱们对数据分析的局部性能要求，但其对高并发的点查场景并不太敌对，不论是采纳列式存储还是行级存储建表，优化之后的响应时长在 500 毫秒左右，综合来看性价比不算太高。

解决思路

为了解决上述问题，咱们心愿现实数仓能具备如下个性：

1. 实现一站式实时数仓，能同时满足多种不同业务数据需要，大大简化大数据架构体系；
2. 可同时反对 OLAP，Ad-hoc 和高 QPS 点查场景；
3. 数据接入敌对，写入即可见，对数据增删改和聚合等都有较好的反对；
4. 架构简略，运维部署和保护简略，有较好的监控体系。

技术选型

在 2022 年 3 月份，咱们对市场上支流的的几款即席查询数据库进行了调研，调研中咱们发现每个产品只能满足某 1 个或几个特定的应用场景，没有一个产品能够齐全满足所有的选型要求，而同时采纳多个产品，将大大增加开发运维老本，同时也会使架构变得更加宏大简单，这并不合乎咱们对现实数仓的要求。

正在这时，咱们从开源社区、技术媒体等渠道理解到了 Apache Doris，经初步调研，咱们发现 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 模型，这两种模型根本可能满足业务需要。

• Unique 模型次要用于维度表和业务表 (原始表) 的接入，确保数据导入过程中的一致性。
• Aggregate 次要用于报表数据的导入，Aggregate 分为 Key (维度列) 和 Value（指标列），Value 列反对四种聚合形式：sum ,replace,max,min。以后次要以replace 聚合形式为主，不便统计数据反复导入和修改后果，后续也会尝试更多的形式来充分发挥 Doris 的性能。

数据接入：

1. 应用 Flink-Doris-Connector 进行实时导入：次要用于业务数据的导入，基于 MySQL 的 Binlog 日志写入到 Kafka 后，通过 Flink 解析加工后准实时写入 Doris。
2. 应用 DataX 进行离线导入：次要用于对接离线数仓已计算后的报表数据。

数据开发：

目前 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 的值，顺利完成了压测指标。

须要阐明的是：

parallel_fragment_exec_instance_num 指的是 Scan Node 在每个 BE 节点上执行实例的个数，相当于在整个查问打算执行过程中的并发度，调高该参数能够晋升查问效率，但同时也会减少更多机器资源的耗费。因而在资源无限且查问耗时满足业务需要的状况下，通过调低参数来节俭单个 SQL 的资源耗费，有助于进步并发体现。另外，咱们通过 Doris 社区理解到，在行将公布的新版本中将实现参数主动设置，无需进行手动调整。

如下图，咱们能够看到，在参数设置为 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 数据库的压力，不须要频繁进行升配和磁盘降级。

总结布局

成果总结

1. Doris 完满笼罩了本来须要多个技术栈能力实现的业务场景，极大地简化了大数据的架构体系。
2. Doris 对 Join 反对较好，因而咱们抉择了将维度表放到 Doris 中进行保护，相较于之前在离线数仓中进行保护，显著地进步了开发的效率，并升高了数据出错的可能性，满足了业务上对维度表近实时更新的需要。
3. Doris 反对 MySQL 协定和规范 SQL，开发人员学习成本低，上手简略，能够疾速将原先的业务迁徙至 Doris 上来。
4. Doris 社区沉闷，版本迭代速度快。在遇到任何问题时，都能够向社区求助，SelectDB 为 Apache Doris 组建了一支全职业余的技术支持入队，24H 内即可失去社区的响应回复。

将来布局

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

此外，咱们也心愿 Doris 将来能对以下性能进行进一步优化：

1. Flink-Doris-Connector 能反对单 Sink 同时写入多张表，不须要再通过分流后多个 Sink 写入。
2. 物化视图可能反对多表 Join，不再局限于单表。
3. 进一步优化数据的底层 Compaction，在保证数据可见性的同时可能尽可能升高资源耗费。
4. Doris-Manager 提供对慢 SQL 的优化倡议以及表信息收集，对于不合理的建表进行肯定的提醒。

从 3 月份应用 Doris 以来，咱们始终都和 Doris 社区放弃着亲密的分割，后续咱们也将持续围绕 Doris 作为实时数仓利用到更多的业务应用场景中，对于应用中遇到的问题和优化的计划，咱们也会继续和社区放弃热切分割，为社区提高奉献咱们的一份力量。

— END —

最初，欢送更多的开源技术爱好者退出 Apache Doris 社区，携手成长，共建社区生态。Apache Doris 社区以后已包容了上万名开发者和使用者，承载了 30+ 交换社群，如果你也是 Apache Doris 的爱好者，扫码退出 Apache Doris 社区用户交换群，在这里你能够取得：

• 业余全职团队技术支持
• 间接和社区专家交换，获取收费且业余回复
• 意识不同行业的开发者，播种常识以及单干机会
• Apache Doris 最新版本优先体验权
• 获取一手干货和资讯以及流动优先参与权

首届 Doris Summit 2022 行将拉开序幕，收费报名进行中！
本次峰会将于 1 月 6 -7 日 于线上正式举办，分为核心技术解析、商业与数据生态、行业最佳案例 3 个论坛，您能够追随来自 SelectDB、百度、腾讯、美团、小米、京东、字节跳动、阿里、AWS、网易、360 等泛滥知名企业的技术大咖，围绕 Apache Doris 的最新技术趋势、行业最佳实际、数据上下游生态、企业级产品个性等，一道享受这场技术盛宴！

扫描下方二维码立刻报名，精彩演讲不容错过！