【Azure Data Platform】ETL工具(9)——ADF性能优化案例分享（1）

本文属于【Azure Data Platform】系列。
接上文：【Azure Data Platform】ETL工具(8)——ADF 数据集和链接服务
本文分享一下工作中遇到的ADF性能问题

最近工作中遇到了一些ADF的性能问题，下面是截图，这个copy activity跑得非常慢，才500万行的数据，花了5个半小时，都没跑完。所以需要研究到底发生了什么事。

从截图中我们可以获取到一些信息：

1. 数据源的数据行及数据大小（Data read）
2. 目标的数据量及数据行数。
3. Copy data的时间（copy duration）
4. 吞吐量（Throughput）

细分下去，还能看到大概步骤的耗时，这个非常重要，因为copy操作其实不复杂，就是从Blob中的文件读取数据插入到SQL DB MI中。这个操作实际上就三步：读取源，传输，写入。
可以看到最耗时的是写入部分，同时这里也显示了“performance tunning tips”，从系统的角度，因为表有索引，系统认为是这个原因导致了慢。我们不妨也考虑一下它的建议。

但是首先先要获取必要的信息，看看这个copy操作具体做了什么，从pipeline的配置中可以看到，是一个select操作：

这个select操作会涉及到10个表，根据上面的提示，我选择了先检查索引，优先检查索引的数量会不会很多，因为是正式环境，所以打码了，但是不影响案例分享， 在这个过程中我发现了一个特别的问题，有一个表竟然有518列！

之所以觉得不正常，是因为我在别的项目中遇到过类似的问题，一个ETL 工具，插入数据到300列的表中，耗时就要2个多小时。当是哪怕把数据库（Azure SQL DB，非MI）升级到可用的最高配（Business Critical 80 vCore）也并没有明显的提升。
后来为了证明是列太多的问题，我用了简单的测试，用SQLCMD分别循环1000万次，每次insert into一条数据。3列的堆表，大概1分钟到2分钟就完事，100列的堆表3个多小时都还没insert完，同时监控日志文件的大小，明显大很多（毕竟列多表的体积也自然就很大），导致写入日志文件的I/O量差异很大。最终影响性能。有了这次经历之后，在性能优化的时候对宽表就有了特殊的关注。

在本案例中，由于数据结构及文件已经固化，很难进行表设计的改造，因此最有效的方法就是增加性能。当然，这个案例中会还有很多影响因素，只是列数多是核心问题。其他的因素正如上面提示的，有索引。那么可以禁用索引再做导入，参考官方文档：Azure SQL 数据库接收器。

在之前的项目中，由于一些项目问题，ETL工具已经不可换，但是数据库可以，最后把SQL DB换成了Azure Dedicated SQL Pool（SQL DW），使用它的PolyBase功能，很好地解决了宽表导入的性能问题。

总结

在这个文章中，我并不想具体介绍很多技术细节，只是想介绍一些我们平时可能忽略的地方， 过多相信系统提示，没有多方面考虑问题。系统提示是好事，只是从上面的例子中，我个人认为过于表面化。比如这个例子中，涉及的表索引数其实每个表大概就3个索引。系统一旦检测到有索引，不管多少，都可能会显示这个提示。所以我们在处理性能问题时，不抗拒一些提示，但是也不要把所有的希望放在上面。

由于这次的性能问题是突发的，所以临时加到这个系列，希望能从思维上面给大家一点提示。通过这次案例，我还发现，其实ADF关于性能方面的一些文章和方法实在是太少了。希望这方面的文章资料能够越来越多。