大数据处理与智慧营销系统性能优化

随着企业数字化转型的加速，客户经营数字化正在向智能化方向发展，构建全场景、全流程、全触点的数字化、智能化的客户经营智慧营销体系。智慧营销系统已运行 5 年，伴随着业务增长，系统业务流程复杂度增大，大表数据量已超 10 亿，系统性能和吞吐量不能满足业务需求，急需优化系统架构和提升处理性能，打造高效稳定的智慧营销服务系统。

现有流程及存在问题

智慧营销系统的主要流程为活动规格同步、客户群清单入库、活动生单和活动派单，具体流程见下图：

上述流程中目前主要存在的问题：

• 活动规格同步：活动配置数据同步频率高、易出错，且没有异常处理重试机制；

• 客户群清单入库：当客户群较大（500W）的时候，处理速度较慢且容易出现数据库执行压力较大出现慢 sql 或者超时；

• 活动生单：当活动的客户群较大时，生单性能慢，生单过程涉及多张大表，容易导致慢 sql；

• 活动派单：FTP 派单性能较差，派单耗时长，500 万工单派单需 10 小时以上。

提升举措

基于目前存在问题进行针对性的优化和提升，主要举措有如下四点：

活动规格同步优化

活动配置过程中虽然只有规格层面的数据同步，但因七步法配置过程涉及基本信息、客户群、销售品、渠道触点、营销话术等众多规格数据，目前在七步法配置过程中任意信息要素的新增和修改都会多次发起数据同步更新，且频繁操作颇多，存在无法保证活动配置数据完整性的隐患，并且对接口超时或者调用异常没有重试机制，导致活动规格同步存在较高的错误率（1-9%）、活动创建后调度无法执行等问题。

主要通过以下几点进行优化，来降低活动规格同步的错误率： 

1)   新增或修改活动配置：无须同步数据。未发布的活动存在多次修改的可能，减少没必要的数据同步次数，反复频繁的数据同步反而会增加出错概率；

2)   活动审批后发布生效：只需实时同步更新审批发布生效的活动配置数据；

3)   智慧营销系统-营销中心查询规格中心活动详情：全部查询所有数据后统一更新，不能分多步更新；

4)   智慧营销系统更新活动详情事务操作：智慧营销系统获取到活动详情后，进行详情的入库操作需要进行事务操作，避免活动规格的数据不完整，导致生单过程中报错；

5)   增加活动规格同步的每日稽核机制：每天凌晨营销服务系统根据文件接口增量同步规格中心前一天发布生效的活动配置数据，营销服务系统基于文件数据进行活动规格的数据比对以及同步失败数据进行修复；

6)   重试机制：在活动规格发布后的同步过程中，如果出现了活动同步失败情况，在活动发布的页面增加“重新同步”的按钮，让用户可以主动的触发活动规格的重试动作，避免因为网络不稳定或者其他的原因导致的同步失败没有及时处理的入口。

客户群清单入库提速

客户群清单入库流程涉及大表为客户群清单表，数据量达到 10 亿级别，因此在大客户群清单解析比对过程中容易出现慢 sql 导致客户群清单解析慢、数据库压力大以及超时出现解析出错。

主要从以下几点进行优化，提高大客户群解析入库成功率和速度，提高用户的体验。

优化策略：客户群清单表(tar_grp_detail)为分片表，分片键为 tar_grp_id,查询条件带上分片键，其他查询字段账期字段和号码字段添加索引，使用主键索引进行批次操作。

1)   优化客户群清单表的删除操作：分批次进行删除操作，每个批次的大小可以动态配置，默认 100000 一批次数据，避免一次上百万乃至千万数据量级别的删除操作；

2)   同时每批次删除通过主键索引进行，提高 sql 执行效率；

3)   优化客户群清单表的更新操作：将大批量的负责状态更新操作语句进行优化，优化数据库查询性能；

4)   提供客户群清单归档策略：定期清理客户群清单表数据，制定清理策略规则，周期性客户群连续 10 天没有关联任何有效活动，不再推送数据给营销服务系统。

活动生单提速

目前智慧营销系统调度是单任务遍历客户群清单进行生单，生单效率较低；加上任务单、工单等表的数据量都达到了 10 亿左右，生单后的 FTP 派单涉及多处查询，导致派单耗时较长。

采用多个实例的子任务，同时进行一个活动的客户群清单的工单生成，提高处理速度；增加多个子任务同时对一个活动进行工单生成，先获取客户群要生单的用户数量，再将用户数根据子任务数量分配到不同子任务数量上去，使用多个机器实例执行不同子任务，提升生单速度。

活动派单提速

FTP 工单推送是对触点系统派单的一个重要流程，通过定时任务触发派单动作，将批量活动和事件触发生单后的待派单的工单数据，按每 5000 条工单一个批次写入到派单文件中，然后上传到指定的 FTP 目录，最后通知到触点系统完成派单流程，目前对其中的各个派单动作环节可能出现的异常没有容错机制和重跑机制，甚至可能出现漏单的情况。

1)   分批查询取数优化：

目前是按 5000⼀个批次查询获取⼯单数据，采⽤数据偏移量的⽅式，类似于分⻚查询（第⼀批次 1-5000,第⼆批次 5001-10000……)，查询效率⾮常低，因为 limit 后面的偏移量太大导致的越往后查询响应会越慢，严重影响性能。

调整为上次查找结果的最大主键值，再根据主键值分批查询，避免使⽤偏移量 offset，提高查询效率。

2)   分批写入文件：

目前按批次循环写⼊⽂件，写入过程中每条⼯单会查询多个业务表数据（如查询客户群标签、销售品数据等），如一次派单 500 万就要查询 500W*N 次数据库，占用数据库连接过多，查询效率低。

调整为通⽤的数据只查询⼀次，如客户群的标签数据、其他数据⼀次性查询出来，减少频繁数据库，用空间换时间的方式达到最大性能。

3)   派单异常处理：

目前派单异常时有⼀部分数据写⼊了⽂件，但是缺少 check⽂件，需要⼿⼯补⽂件上传到 FTP，再次通知外部系统处理。

优化调整说明：

a)   部分⼯单写⼊⽂件成功时，如捕获异常默认⽣成完整的 check⽂件和 dat⽂件，避免数据 txt 文件生成了，但是缺失其他文件的情况，支持部分写入成功的数据派单出去，能成功通知触点系统；

b)   针对“派单异常”的工单推送任务可进⾏自动重跑，当天默认最多 3 次，配置静态数据阀值，可以动态调整活动运营位的次数，新增静态数据；

c)   新建自动重跑任务，每 30 分钟执行一次，查询“派单异常”的调度日志，然后重新发起活动运营位的工单推送任务，将没有成功派单出去的工单再次处理。

4)   工单状态更新：

目前⼯单数据写⼊⽂件和⽂件上传到 FTP 都成功后，⼯单状态按每 800 条/批次更新数据，如果其中批次更新失败，那该任务会调度失败，重新派单时会漏单，因为有部分⼯单的状态已经变更。

优化调整说明：

a)   每批次从 800 条调整为 2000 条，减少连接提升性能，并可动态调整改参数阀值；

b)   记录已经更新⼯单状态的主键范围到调度日志，任务调度失败时，重新派单时可根据主键范围重新处理，避免漏单；

c)   运维人员可以根据调度日志工单 ID 的范围准确找到需要调整状态的工单数据，然后将工单状态还原，避免下次调度的时候出现漏单的情况。

优化效果

通过对核心流程的性能提升优化，在同一个测试环境经过 500w 数量的客户群进行客户群入库、生单和派单的验证，测试结果表明性能提升明显。