从存储到 SQL 的 Azure 数据工厂副本 activity:在 70000 行处挂起

Azure data factory copy activity from Storage to SQL: hangs at 70000 rows

我有一个带有管道副本的数据工厂 activity,如下所示:

{
  "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 万行,分为约 2 个。 Azure 存储中的 20 个 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 服务器,额定值为 50 DTU。我创建了一个简单的 table,其中包含合理的数据类型,没有键、索引或任何花哨的东西,只有列:

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 management studio,我可以看到数据库中的行数 table 正好是 70,000,并且在 7 小时 内根本没有增加。然而复制任务仍然运行没有错误:

知道为什么这会挂在 70,000 行吗?我看不到第 70,001 个数据行有任何异常会导致问题。我已经尝试完全破坏数据工厂并重新开始,但我总是得到相同的行为。我有另一个副本 activity,较小 table(8000 行),在 1 分钟内完成。

只是回答我自己的问题,以防对其他人有帮助:

问题出在空值上。我的 运行 挂在 70,000 行的原因是在我的 blob 源文件的第 76560 行,其中一列中有一个空值。我用来生成此 blob 文件的 HIVE 脚本已将空值写入“\N”。此外,我的接收器 SQL table 指定 'NOT NULL' 作为列的一部分,并且该列是 FLOAT 值。

所以我做了两个更改:将以下 属性 添加到我的 blob 数据集定义中:

"nullValue": "\N"

并使我的 SQL table 列可以为空。它现在 运行 完全没有挂起! :)

问题是数据工厂没有出错,它只是卡住了 - 如果作业失败并显示一条有用的错误消息并告诉我数据的哪一行有问题,那就太好了。我想是因为写入批处理大小默认为 10,000,这就是它卡在 70,000 而不是 76560 的原因。

这是一个新的解决方法,只需设置 write batch size 覆盖默认值 (10,000)

click here to see my copy data activity config