作者 | 苏州度言应用软件大统计数据项目组
苏州度言应用软件有限子公司（度言应用软件）设立于2014年，是信贷投放不良贷款处理控制技术服务项目供应商，以“智能科技借力不良贷款处理，推动投后行业合规性高效率发展”为历史使命，运用云通讯、大统计数据、人工智慧等智能科技为信贷投放不良贷款处理销售业务借力，提供更多投后管理工作通信能力支撑，同时实现了清收工作台的智能管理工作，顾客群体为银行、消费金融子公司、AMC 等商业银行和为这些政府机构提供更多老龄BizTalk服务项目的有关子公司，目前已拥有 2000 多家企业顾客。
度言应用软件以围绕信贷投放不良贷款刑事案件高效率确权管理工作为目的核心，从政府机构管理工作、项目组管理工作、座席管理工作、外呼工作台、第十四条诉等环节侧发力，帮助顾客构筑数智化的销售财务管理工作体系，以网络化控制系统提高管理工作效能、以智能工具借力处理工作台，贯通商业银行、BizTalk服务项目子公司、司法控制系统等多番的销售业务控制系统，并按照监管要求对外呼行为、录音带文件、沟通历史记录等刑事案件有关统计数据展开历史记录、汇聚、审计部、统计和预测，具有海量数据帐号同时登陆、数
销售业务市场需求
2021 年之前，度言应用软件旗下产品的统计数据市场需求主要由现代统计资料库 MySQL，MongoDB，ElasticSearch 居多的控制技术构架来同时实现，近几年随着销售业务急速发展带而来统计信息量的高速快速增长，现代的数仓控制技术构架已初显困局，难以满足用户顾客日益丰富多元化的统计数据及预测市场需求。为了给顾客提供更多更优质的服务项目新体验，度言应用软件亟须对现有的控制技术构架做出优化和解构。
晚期构架及痛点 数仓构架 1.0 版
孵化器期间，由于子公司销售业务规模相对较少，主要还是以 OLTP 销售业务和少量的销售业务财务报表服务项目居多，并且对统计数据挖掘各方面的市场需求也很少，仅通过现代的统计资料库基本就能满足用户晚期的销售业务统计数据市场需求。数仓 构架 1.0 如下表所示图右图：
数仓构架 2.0 版
随著子公司销售业务的急速扩展，统计数据规模也出现全速快速增长的态势，销售业务侧对统计数据挖掘各方面的市场需求也逐渐多了起来，为此我们设立了专门的大统计数据项目组，为构筑捷伊数仓及销售业务数据预测市场需求展开服务项目。如下表所示图右图共约仓构架 2.0 ：
统计数据以及埋点日志统计数据；统计数据首先采集到统计数据总线 DataHub 中，后经过 DataHub 直接导入到 MaxCompute，MaxCompute 作为一个离线数仓，我们将其展开了现代的数仓分层；统计数据的加工处理和预测计算主要在离线数仓中展开，并将计算好的结果导出到 MySQL中，来对接 QuickBI 展示财务报表。此外，我们还尝试了将 Hologres 用作动态数仓，作为 MongoDB 的替换方案，用于销售业务上的查阅控制系统。
晚期构架存在的问题：
响应速度较慢。MySQL 对大表的聚合计算并不友好，响应速度较慢。产品侧要求统计数据查阅响应时间在 5 秒以内，虽然我们也基于 MySQL 展开了许多优化，但优化效果十分有限，仍无法达到 5s 的响应要求；我们甚至尝试了直接用 MaxCompute 对接 QuickBI，希望基于 MaxCompute 的查阅加速和 QuickBI 的缓存来帮助我们解决问题，然而结果并不理想。维系维度表成本高、难度大。离线数仓在统计数据同步的时效性上并不占优势(每 5 分钟展开一次批量同步)，因此不太适合统计数据频繁更新和删除的场景，同时也给维度表的维护带来了额外的工作量。在统计数据更新和删除场景中，我们需要定期通过过滤和去重来保持统计数据的一致性，而事实上，大多时候需要财务报表统计数据动态关联维度表，这让我们直接放弃了在离线数仓中维系维度表的方案。不支持高并发点查阅场景。原动态数仓虽然可以满足用户我们对统计数据挖掘的部分性能要求，但其对高并发的点查场景并不太友好，不管是采用列式存储还是行级存储建表，优化之后的响应时长在 500 毫秒左右，综合来看性价比不算太高。解决思路为了解决上述问题，我们希望理想数仓能具有如下表所示特性：
同时实现一站式动态数仓，能同时满足用户多种不同销售业务统计数据市场需求，大大简化大统计数据构架体系；可同时支持 OLAP，Ad-hoc 和高 QPS 点查场景；统计数据接入友好，写入即可见，对统计数据增删改和聚合等都有较好的支持；构架简单，运维部署和维护简单，有较好的监控体系。控制技术选型在 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 的性能。统计数据接入：使用 Flink-Doris-Connector 展开动态导入：主要用于销售业务统计数据的导入，基于MySQL 的 Binlog 日志写入到 Kafka 后，通过 Flink 解析加工后准动态写入 Doris。使用 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 统计资料库的压力，不需要频繁展开升配和磁盘升级。
总结规划 效果总结
Doris 完美覆盖了原本需要多个控制技术栈才能同时实现的销售业务场景，极大地简化了大统计数据的构架体系。Doris 对 Join 支持较好，因此我们选择了将维度表放到 Doris 中展开维护，相较于之前在离线数仓中展开维护，明显地提高了开发的效率，并降低了统计数据出错的可能性，满足用户了销售业务上对维度表近动态更捷伊市场需求。Doris 支持 MySQL 协议和标准 SQL，开发人员学习成本低，上手简单，可以快速将原先的销售业务迁移至 Doris 上来。Doris 社区活跃，版迭代速度快。在遇到任何问题时，都可以向社区求助，SelectDB 为 Apache Doris 组建了一支全职专业的控制技术支持入队，24到目前为止，基于 Doris 的动态数仓构筑已基本完成，但我们对 Doris 的进一步尝试才刚刚开始，比如 BE 的多磁盘部署，物化视图的使用，Doris-On-ES，Doris 多租户和资源划分等。
此外，我们也希望 Doris 未来能对以下功能展开进一步优化：
Flink-Doris-Connector 能支持单 Sink 同时写入多张表，不需要再通过分流后多个 Sink 写入。物化视图能够支持多表 Join，不再局限于单表。进一步优化统计数据的底层 Compaction，在保证统计数据可见性的同时能够尽可能降低资源消耗。Doris-Manager 提供更多对慢 SQL 的优化建议以及表信息收集，对不合理的建表展开一定的提示。从 3 月份使用 Doris 以来，我们一直都和 Doris 社区保持着密切的联系，后续我们也将继续围绕 Doris 作为动态数仓应用到更多的销售业务使用场景中，对使用中遇到的问题和优化的方案，我们也会持续和社区保持热切联系，为社区进步贡献我们的一份力量。
