azure-pipelines - 缓慢的 Azure 数据工厂管道

Question

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

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

在我有一个 DataFlow 将数据从暂存表传输到主表之后。

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

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

我想知道为什么只有三个文件我的管道需要这么多时间？

这是我清理临时表的任务。

这是我的 SQL 服务器规模和使用情况。

我在恢复 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. 执行另一个管道以存档文件。

据我所知，这个过程似乎在起作用。问题是关于数据流的执行时间。

要考虑的

一般性能指南:

• 由于您连续运行多个 DF，因此请使用 ComputeOptimized 类型、4 核和大于 0 的生存时间 (TTL) 的自定义集成运行时。[不过不要太长，因为您需要为环境付费在 TTL 时间内处于事件状态。] 注意:最后我知道，DF 要求区域为“自动解析”。

• 每次写入 Synapse 时，请务必定义一个 Polybase 暂存存储帐户:

• 注意跨区域操作:网络延迟可能是一个真正的 killer ，并且会让您付出金钱。为了获得最快的性能，存储、数据工厂和 Synapse 资源都应该位于同一个数据中心。

• 源和接收器分区可以帮助处理非常大的数据集和复杂的场景，但这是一个相当棘手的主题，并且(很可能)对您的场景没有帮助。

SPECIFIC 您发布的场景，我会考虑重新设计工作流程。从较高的层次来看，您正在为每个(小)文件执行以下操作:

1. 清除 Synapse 表
2. 从 blob 写入 Synapse
3. 从 Synapse 读取你刚刚写入的数据
4. [在一些最小处理之后]将数据写回 Synapse。

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

更好的是，我会将 COPY 事件和数据流合并为一个数据流。数据流可以读取 ADLS 作为源，转换数据，并将其插入到 Synapse。这将从进程中删除暂存表。 DF甚至可以将操作后的文件归档:

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