缓慢的Azure数据工厂管道

Question

我正在使用Azure Data Factory V2将某些csv文件从Azure Data Lake传输到Azure Synapse

我有一个循环可以在DataLake上的特殊文件夹中查找所有文件。

在我有一个DataFlow将数据从登台转移到主表之后。

在我的for-each循环中，首先我要通过SP清理暂存表，然后再从csv文件读取数据（一个接一个）。我正在使用Copy Data任务将数据从CVS传输到我的登台表。我将所有列都读为varchar，登台表中的所有列均为varchar（此处没有强制转换）

每个文件约有20列和216行。

我想知道为什么仅三个文件我的管道会花费这么多时间？

这是我清理登台表的任务。

这是我的SQL Server规模和使用情况。

我刚恢复Synapse服务后就运行了管道。那只是与我的突触一起工作的管道和服务。

这是我的存储过程：

CREATE PROCEDURE [stg].[...._Truncate]
AS
    TRUNCATE TABLE [stg].[....e]
GO

这是我的DF

    SELECT 
        Convert(int,S.[MMSI]) AS [MMSI] ,
        Convert(int,S.[IMO] )  AS [IMO] ,
        Convert(int,S.[SHIP_ID] )AS [SHIP_ID] ,
        Convert(numeric(8, 5),S.[LAT] )  AS [LAT] ,
        Convert(numeric(8, 5),S.[LON] )  AS [LON] ,
        Convert(int,S.[SPEED] )  AS [SPEED] ,
        Convert(int,S.[HEADING] ) AS [HEADING] ,
        Convert(int,S.[COURSE] )  AS [COURSE] ,
        Convert(int,S.[STATUS] ) AS [STATUS] ,
        Convert(datetime,S.[TIMESTAMP] )  AS [TIMESTAMP] ,
        Convert(varchar(5),S.[DSRC] )  AS [DSRC] ,
        Convert(int,S.[UTC_SECONDS] ) AS [UTC_SECONDS] ,

           'M....._Simple' AS [ETL_CREATED_BY], 
           GETUTCDATE() AS [ETL_CREATED_DATE], 
           CONVERT(BIGINT, replace(CONVERT(VARCHAR, GETDATE(), 112), '/', '') + replace(CONVERT(VARCHAR, GETDATE(), 108), ':', '')) AS [ETL_PROCESS_ID]
    FROM [stg].[....e] AS s

这是我的衍生列

这将结束我的数据流中的映射

我应该在这里做什么吗？

Answer 1

我认为问题在这里有些混乱，因此我将尝试回答。理解有很多潜在因素，我的回答并非要详尽回顾Data Flow performance techniques。

首先，让我总结一下我理解的项目。对于ADLS文件夹中的每个文件，似乎您具有以下内容：

1. 用于截断Synapse登台表的存储过程。
2. 复制活动以将数据从ADLS复制到Synapse登台表
3. DataFlow可以从Synapse登台表中读取数据，进行处理并将其写回到其他Synapse表中
4. 执行另一个管道来存档文件。

根据我的收集，看来此过程正在正常进行。问题是关于数据流的执行时间。

GENERAL 的性能指南要考虑：

• 由于您要连续运行多个DF，请使用ComputeOptimized类型，4个内核以及大于0的生存时间（TTL）的自定义集成运行时。[不过，不要太长，因为您要为环境成本TTL期间处于活动状态。]注意：上次我知道，DF要求Region为“自动解析”。

• 每次您写Synapse时，请确保定义一个Polybase Staging Storage帐户：

• 请注意跨区域操作：网络延迟可能是真正的杀手，并且会浪费您的钱。为了获得最佳性能，存储，数据工厂和Synapse资源都应位于同一数据中心。

• 源和接收器分区可以帮助处理非常大的数据集和复杂的场景，但这是一个相当棘手的话题，并且（很可能）在您的场景中无济于事。

具体到您发布的方案，我会考虑重新设计工作流程。从较高的层次来看，您正在对每个（小）文件执行以下操作：

1. 清除Synapse表
2. 从blob写入Synapse
3. 从Synapse读取刚刚写入的数据
4. [经过最少的处理后]将数据写回Synapse。

我个人的经验法则是不要使用数据流来跨越Synapse边界：如果操作是从Synapse到同一Synpase，则在Synapse中运行逻辑。换句话说，由于Source和Sink都在Synapse中，因此我将用存储过程替换数据流。

更好的是，我将COPY活动和数据流合并为一个数据流。数据流可以读取ADLS作为源，转换数据，然后将其插入到Synapse。这将从过程中删除登台表。操作之后，DF甚至可以存档文件：

最后，我将寻求限制执行数据流的次数。您是否有理由必须逐个文件处理此文件？如果您具有基于该值的逻辑，则“数据流”源可以轻松处理整个文件夹，甚至可以将文件名捕获为一列[参见上图]。这将消除多次运行数据流的需要，并可以大大提高整体性能。