我有一个350MB的表,相当宽,有两个varchar(2000)列 . 通过SSIS数据流,通过OLEDB "fast load"目标加载到Azure SQL DW需要60分钟 . 我将该数据流上的目标更改为Azure Blob目标(来自SSIS Azure feature pack),并且在1.5分钟内完成相同的数据流(并且新平面文件中的Polybase大约需要2分钟) .
对于另一个来源,我有一个现有的1GB平面文件 . SSIS数据流入Azure SQL DW中的OLEDB目标需要90分钟 . 将文件复制到blob存储,Polybase加载需要5分钟 .
SSIS是SSIS 2014,它在与Azure SQL DW相同的Azure VM上运行 . 我知道批量加载比Polybase慢得多,因为批量加载漏斗通过控制节点,但Polybase在所有计算节点上并行化 . 但那些批量负载数字非常慢 .
为了通过批量加载尽快加载到Azure SQL DW阶段表,SSIS数据流和目标的最佳设置是什么?特别是我对以下设置的最佳值感兴趣,除了我没有考虑的任何其他设置:
-
舞台表几何= HEAP(我相信是最快的)
-
数据流设置:
-
DefaultBufferMaxRows =?
-
DefaultBufferSize =?
-
OLEDB目标设置
-
数据访问模式=表或视图 - 快速加载
-
Keep Identity =未选中
-
保持空虚=?
-
表锁=?
-
检查约束=?
-
每批行=?
-
最大插入提交大小=?
1 回答
Polybase无疑是加载到SQL DW的最快方式 . 您建议的HEAP也是最快的目的地类型 . 在best practices for loading to Clustered Columnstore using SSIS上查看来自SQL CAT团队的这篇文章 . 这里工程团队的建议是尝试调整DefaultBufferMaxRows(默认值为10K),DefaultBufferSize(默认值为10 MB),每批行数和最大插入提交大小 .
多年前,我对我们的内部版本的Azure SQL数据仓库,PDW(也称为并行数据仓库或APS,设备平台系统)进行了广泛的SSIS性能测试 . 在那个测试中,我经常发现本地CPU是瓶颈,特别是单个核心 . 如果您通过核心监视CPU利用率,则可以使用Perfmon清楚地看到这一点 .
我可以做一些事情来提高吞吐量 . 如果您在单个核心上受CPU限制,则运行多个并发SSIS包将使您能够使用更多内核并且运行速度更快 . 为此,您需要将源文件分成多个文件,目标应该是多个表 . 如果对目标表进行分区并且每个加载包含不同的分区,则可以在加载数据后使用分区切换,以便将其合并到单个表中 .
您还可以尝试在程序包中创建多个数据流,这将实现与并行运行多个SSIS加载程序相同的性能,但我相信您仍然需要将源文件分解为多个文件以及目标,多个表最大化吞吐量 .
我尝试的另一种方法是在一个数据流中使用并行加载器 . 虽然这比一个加载器快,但它比我前面提到的前两个方法要慢 .
我还发现如果我有SSIS做char到二进制字符转换,那加速了加载 . 此外,使用SQL源比使用文本文件作为源更快 .
您可以尝试的另一件事是SSIS Balanced Data Distributor . BDD是在源系统上使用多个核心而不必运行多个并发SSIS包的另一种方法 .
运行SSIS包时,请使用perfmon监视CPU,以查看您是在单核上运行还是在多核上运行 . 如果你正在盯住一个核心,那么这很可能是你的瓶颈 .
另外,关于VARCHAR(2000)列 . 如果您确实不希望传入的数据为此大小,请减小VARCHAR列的大小 . 虽然我们将来会改进这种行为,但目前我们的数据移动服务会将您的VARCHAR数据填充到固定长度 . 这当然意味着如果最宽的值远小于2000个字符,则移动的数据将超过所需的数量 .
我希望这有帮助 .