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 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

我认为这个问题在这里变得有点混乱，所以我将尝试回答。了解有很多潜在因素，我的回答并不是对数据流性能技术的详尽回顾。

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

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

从我收集到的信息来看，这个过程似乎正在发挥作用。问题是关于数据流的执行时间。

需要考虑的一般性能指南：

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

• 每当您向 Synapse 写入数据时，请务必定义一个 Polybase 暂存存储帐户：

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

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

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

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

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

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

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