我有一个数据工厂,其管道复制活动如下:
{
"type": "Copy",
"name": "Copy from storage to SQL",
"inputs": [
{
"name": "storageDatasetName"
}
],
"outputs": [
{
"name": "sqlOutputDatasetName"
}
],
"typeProperties": {
"source": {
"type": "BlobSource"
},
"sink": {
"type": "SqlSink"
}
},
"policy": {
"concurrency": 1,
"retry": 3
},
"scheduler": {
"frequency": "Month",
"interval": 1
}
}
输入数据大小约为90MB,大约150万行,分为约。 Azure存储中的20 x 4.5MB块blob文件。以下是数据示例(CSV):
A81001,1,1,1,2,600,3.0,0.47236654,141.70996,0.70854986 A81001,4,11,0,25,588,243.0,5.904582,138.87576,57.392536 A81001,7,4,1,32,1342,278.0,7.5578647,316.95795,65.65895
接收器是S2类型的Azure SQL Server,其额定值为50 DTU。我创建了一个简单的表,其中包含合理的数据类型,没有键,索引或任何花哨的东西,只有列:
CREATE TABLE [dbo].[Prescriptions](
[Practice] [char](6) NOT NULL,
[BnfChapter] [tinyint] NOT NULL,
[BnfSection] [tinyint] NOT NULL,
[BnfParagraph] [tinyint] NOT NULL,
[TotalItems] [int] NOT NULL,
[TotalQty] [int] NOT NULL,
[TotalActCost] [float] NOT NULL,
[TotalItemsPerThousand] [float] NOT NULL,
[TotalQtyPerThousand] [float] NOT NULL,
[TotalActCostPerThousand] [float] NOT NULL
)
源,汇和数据工厂都位于同一地区(北欧)。
根据Microsoft的'Copy activity performance and tuning guide',对于Azure存储源和Azure SQL S2接收器,我应该得到大约0.4 MBps。根据我的计算,这意味着90MB应该在大约一半和一小时内转移(是吗?)。
由于某种原因,它很快就复制了70,000行,然后似乎挂了。使用SQL管理工作室,我可以看到数据库表中的行数正好是70,000,并且在 7小时中根本没有增加。然而,复制任务仍在运行,没有错误:
为什么这个挂在70,000行的任何想法?我看不出会导致问题的第70,001个数据行有什么异常。我已经试图强行捣毁数据工厂并重新开始,我总是得到同样的行为。我有一个较小的表(8000行)的另一个复制活动,在1分钟内完成。
答案 0 :(得分:11)
只是回答我自己的问题,以防其他人帮助:
问题在于空值。我的运行挂起70,000行的原因是我的blob源文件的第76560行,其中一列中有一个空值。我用来生成这个blob文件的HIVE脚本已将空值写为' \ N'。另外,我的接收器SQL表指定了“非空”'作为列的一部分,列是FLOAT值。
所以我进行了两项更改:将以下属性添加到我的blob数据集定义中:
"nullValue": "\\N"
并使我的SQL表列可以为空。它现在完全运行,不会挂起! :)
问题是数据工厂没有错误,它只是卡住了 - 如果作业失败并且有用的错误消息会很好,并且告诉我数据的哪一行是问题。我认为因为默认情况下写入批量大小是10,000,这就是为什么它停留在70,000而不是76560.
答案 1 :(得分:0)
这是一个新的解决方法,只需将 write batch size
设置为覆盖默认值 (10,000)