客户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，提升数据归类的性能。

既然候选键设置太多。那么在目标表新增一个字段，建好索引，把原来的5个候选键字段拼起来后作为候选键字段，就能提升查询候选键的效率。

如下图所示，把原来的5个候选键字段值拼接起来，给目标表新增的那个字段赋值，并且新增的字段一定要设置上索引，这样查询候选键的时候速度就能得到提升。

给目标候选键字段赋值

测试效果数据

耗时查看界面

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

在脚本中拼接查询科目表需要的两个参数，配置一个转换规则，param就是两个参数拼接起来的。至此把查询科目表也用转换规则替换了，并开启缓存。如图所示：

查询科目表转换规则替换

优化了转换数据后，转换和加载都很快了，跑2000条数据仅需300毫秒左右。

优化后的效率提升图示

1、通过该案例分析定位集成方案同步缓慢的原因，并进行改进，给使用集成云的同事提供分析思路和最佳实践方法。

2、提供了基于集成云的大数据量分批处理思想的实践案例，让使用集成云进行异构系统集成的伙伴，面对大数据量的数据迁移、大数据转换处理场景时，能够有迹可循。

此处总结了该集成方案的优化点，供大家参考：