Azure Data PlatformDedicated SQL Pool——导入性能测试——CTAS

Posted 2022-11-27 發糞塗牆

本文属于【Azure Data Platform】系列。
接上文：【Azure Data Platform】Dedicated SQL Pool——导入性能测试（1）——传统insert
本文介绍SQL DW，也称Synapse Analysis，或者最新的Dedicated SQL Pool的外部导数工具的对比。

导入测试

因为在上一文中已经搭建好环境，我们直接使用原有的数据源即可。以T-SQL形式调用Polybase，实际上还是使用CTAS（Create Table As Select），由于在执行过程会创建表，所以在这里的测试当中，并不会预先创建目标表，这一点跟Insert和Copy命令不同。

执行时间如下：

--29:27
CREATE TABLE [dbo].test_robin_heap_ctas
WITH (DISTRIBUTION = ROUND_ROBIN,HEAP)
AS
SELECT * FROM external table
GO
--25:37
CREATE TABLE [dbo].test_robin_cci_ctas
WITH (DISTRIBUTION = ROUND_ROBIN,clustered columnstore index)
AS
SELECT * FROM external table
GO
--29:53
CREATE TABLE [dbo].test_hash_heap_ctas
WITH (DISTRIBUTION = hash(hash key),HEAP)
AS
SELECT * FROM external table
GO
--34:21
CREATE TABLE [dbo].test_hash_cci_ctas
WITH (DISTRIBUTION = hash(hash key),clustered columnstore index )
AS
SELECT * FROM external table 
GO

执行后的结果大小如下：

接下来扩充一下前面的表：

从上表可以看出，CTAS与传统Insert相比，时间大幅度降低。同时也符合了微软官方的一些说法：

1. 从导入性能而言，由于round_robin是平均分布，类似于并行导入，而Hash需要计算Hash Key的值，所以Round_robin会比Hash要快。当然这里的例子只是一个特例。
2. 堆表比CCI 更快，而且如果做更深入的分析还可以知道，CCI由于需要计算，创建索引等，不仅时间会更久，所需的内存也更大，经常对一些超大表的导入（同时DWU很低）时会报错，错误信息比较明显。这里就不演示了。

一些小结

使用 Polybase 时，它会绕过控制节点，并且实际的数据传输会直接发生在计算节点和数据源之间。当前拥有的计算节点越多（DWU越高）性能就越好。

简单来说，由于Polybase节省了很多中间传输和处理过程，几乎直接操作数据，然后还能并行运行。因此与其他传统操作而言，它的性能会明显高很多。

PolyBase旨在利用系统的分布式特性，并且将比任何其他工具更快地加载和导出数据量级。PolyBase 负载可以使用 CTAS 或 INSERT INTO 运行。使用CTAS将最大限度地减少事务日志记录，并且是加载数据的最快方法。

要在使用 gzip 文本文件时最大限度地提高吞吐量，请将文件拆分为 60 个或更多文件，以最大限度地提高负载的并行度。

尽可能使用Largerc或xLargerc的resource class来进行数据加载。

要获得最快的加载速度，一次只能运行一个加载作业。如果这不可行，请同时运行最少数量的负载。如果预计加载作业较大，请考虑在加载之前纵向扩展 SQL 池。

Round_robin 的堆表可以实现最高的导入速度。

注意：

1. Polybase无法并行处理压缩文件（如Gzip），如果使用压缩文件，最好有多个文件供Polybase加载。多个读取器不能与gzip文件一起工作。每个 gzip 压缩文件只使用一个读取器，因为解压缩缓冲区中的文件是单线程的。为了实现最大性能，文件数应大于或等于读取器的总数。
2. Polybase无法并行处理单个 Parquet 文件，因此拥有多个 Parquet 文件应该会产生更好的性能。对于 Parquet 文件，每个压缩文件只使用一个读取器，因此为了获得最佳性能，文件数应大于或等于读取器的总数。

接下来我们做最后一个测试，使用Copy命令导入数据。