从存储到SQL的Azure数据工厂复制活动:挂起70000行

Jam*_*len 6 performance azure azure-storage-blobs azure-data-factory azure-sql-database

我有一个数据工厂,其管道复制活动如下:

{
  "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
  }
}
Run Code Online (Sandbox Code Playgroud)

输入数据大小约为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
)
Run Code Online (Sandbox Code Playgroud)

源,汇和数据工厂都在同一地区(北欧).

根据微软的"复制活动性能和调优指南",对于Azure存储源和Azure SQL S2接收器,我应该得到大约0.4 MBps.根据我的计算,这意味着90MB应该在大约一半和一小时内转移(是吗?).

在此输入图像描述

由于某种原因,它很快就复制了70,000行,然后似乎挂了.使用SQL管理工作室,我可以看到数据库表中的行数正好是70,000,并且在7小时内根本没有增加.然而,复制任务仍在运行,没有错误:

在此输入图像描述

任何想法为什么这个挂在70,000行?我看不出会导致问题的第70,001个数据行有什么异常.我已经尝试过强制废弃数据工厂并重新开始,我总是得到相同的行为.我有一个较小的表(8000行)的另一个复制活动,在1分钟内完成.

Jam*_*len 11

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

问题是空值.我的运行挂起70,000行的原因是我的blob源文件的第76560行,其中一列中有一个空值.我用来生成这个blob文件的HIVE脚本将空值写为'\ N'.此外,我的接收器SQL表将"NOT NULL"指定为列的一部分,并且该列是FLOAT值.

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

"nullValue": "\\N"
Run Code Online (Sandbox Code Playgroud)

并使我的SQL表列可以为空.它现在完全运行,不会挂起!:)

问题是数据工厂没有错误,它只是卡住了 - 如果作业失败并有一个有用的错误信息会很好,并告诉我数据的哪一行是问题.我认为因为默认情况下写入批量大小是10,000,这就是为什么它停留在70,000而不是76560.

  • 我不得不从70,000行手动扫描我的数据文件,寻找任何问题!幸运的是,空值/空值突出了:p我后来发现你可以改变批量大小,例如100,这意味着它会挂在一个最多100行远离问题的行号 (2认同)