实践案例 | 启动方案高性能集成与调试实践

客户A为一家大型贸易与供应链集团，需要在每个月月底从外部系统全量同步300多万条会计凭证数据到星瀚，原有方案运行缓慢，500条需要190秒左右，效率低下。客户期望能定位集成方案同步数据缓慢的根本原因，并提供相应的解决方案，提高数据同步的效率。

运行效率示例

在此业务背景下，客户在数据集成时面临着三个主要问题：集成开发效率低、集成缓慢、问题定位难。

对此，梳理现场配置方案，发现以下3个可优化点：

• 配置了5个左右候选键，且标数据表没有联合索引（导致加载慢）；

• 转换脚本里查询组织和科目表（导致数据转换慢）；

• 直接使用集成方案转API，外部系统定时多线程访问（没有执行结果不便分析）。

因此，从以上3个方面对方案进行优化，思路和步骤如下：

用启动方案包装集成方案，把启动方案开启批量500，线程数4个。

将转换脚本中查询组织的脚本拆分成值转换规则，并开启缓存，避免在集成方案的转换脚本中频繁查询组织表。

由于科目表字段赋值转换逻辑需要两个参数，暂时无法使用值转换规则，还是放在了转换脚本里。

科目表字段赋值转换脚本

postman调用推送500条数据，再次测试，速度有明显提升：跑500条只需13-16秒，如下图：

优化后效果

但是，速度还是不够理想。从执行结果来看，数据加载过程耗时占比较多，如下图：

数据加载过程耗时

让实施把集成云部署成独立的容器节点，便于arthas获取快照。

在容器内安装Arthas，参考文档：https://arthas.aliyun.com/doc/install-detail.html

进入arthas，执行命令监听3分钟的快照文件：profiler start -f /tmp/watch06070935.jfr -d 1800

用jProfile工具打开atrhas第一次拿到的快照，可分析cpu耗时，如下图所示：

利用Arthas分析cpu在加载上的耗时

从快照分析和代码中看（获取这个cpu调用耗时图后可以寻找集成服务云的同事帮忙看一下是执行什么逻辑缓慢），在加载过程查询候选键耗时较多。

为什么要根据候选键查询目标数据呢？因为实体批量保存的时候，需要把一批数据归类到 待插入数据集合 和 待更新数据集合中。归类判断的时候需要根据集成方案上配置的候选键字段到目标库查询，但是此时目标库数据量有50多万条，候选键字段一共有5个，且没有索引，查询时走了全表扫描，导致查询候选键特别慢。

对于苍穹实体批量操作的候选键，还可以配置租户或集群参数ISC_BATCH_QUERY_CLASSIFY为true