时间戳

首页 > 解决方案 > 将 Azure 数据工厂上的数据管道从 SQL Server 复制到 Blob 存储

azure - 将 Azure 数据工厂上的数据管道从 SQL Server 复制到 Blob 存储

问题描述

我正在尝试使用 Azure 数据工厂中的“复制数据”管道将一些数据从 Azure SQL Server 数据库移动到 Azure Blob 存储。特别是，我在管道的选项卡中使用带有?AdfDynamicRangePartitionCondition钩子的“使用查询”选项，正如微软在此处的模式所建议的那样，在管道的Source选项卡中，复制操作是由查询本身中使用的分区键的存在并行化的。

SQL Server 数据库上的源代码由两个视图组成，分别具有 ~300k 和 ~3M 行。此外，视图具有相同的查询结构，例如（伪代码）

with 
    v as (
        select hashbyte(field1) [Key1], hashbyte(field2) [Key2]
        from Table
    )
    select * 
    from v

视图查询的表也是如此。最重要的是，视图查询相同数量的分区，其中的行数分布大致相等。

复制操作的意外行为（很可能是由于我缺乏经验）是对于查询较少行的视图而言，它的持续时间要长得多。事实上，具有约 300k 行的复制操作显示了约 800 KB/s 的吞吐量，而具有约 3M 行的复制操作显示了约 15MB/s 的吞吐量（！）。最后，在这两种情况下，对 blob 存储的写入操作都非常快，这与从源代码读取操作相反。

我不希望任何人提供实际的解决方案 - 因为提供的信息是有限的 - 但我更希望在视图查询很多的情况下（大约是一个订单）提供一些可能会严重影响复制性能的提示数量级）更少的行，考虑到视图下的表具有相当数量的字段，以及相同的数据类型：视图查询包含的表int、datetime和varchar数据类型。

提前感谢您的提醒。

标签： azureazure-sql-databaseazure-blob-storageazure-data-factoryazure-data-factory-pipeline

解决方案

当 ADF 中存在复制活动性能问题且根本原因不明显时（例如，如果源速度很快，但接收器受到限制，我们知道原因）——这就是我的处理方法：

  1. 从集成运行时 (IR) ( doc. ) 开始。这可能是作业的并发问题、网络吞吐量问题，或者只是一个尺寸过小的 VM（在自托管的情况下）。就像，在我的产品 ETL 中，> 80% 的问题都是由 IR-s 以一种或另一种方式引起的。
  2. 在源和接收器上复制复制活动行为。从您的本地计算机（理想情况下，从与您的 IR 相同环境中的 VM）查询视图，将平面文件写入 blob 等。我假设您已经这样做了，但是再进行一次观察很少会受到伤害。
  3. 测试复制活动的各种配置。更改isolationLevel,partitionOption和将是我在这里parallelCopies的enableStaging第一步。显然，这不会解决问题的根本原因，但可以为您指明进一步深入研究的方向。
  4. 尝试搜索文档（此文档，由@Leon提供是一个好的开始）。这应该是第 1 步，但是，我发现 ADF 文档有些欠缺。

请注意 ，这是基于我对数据工厂的个人经验。
在这种情况下提供一个具体的解决方案确实非常困难。

推荐阅读