Delta Live Tables管道读取26MB CSV耗时24分钟是否正常

24分钟处理单个体量26MB的CSV文件完全不属于正常范围，对于这个规模的工作负载来说当前运行速度严重过慢。
正常情况下，即便是算上DLT管道初始化、集群启动、事务提交的固定开销，你当前配置的集群处理这个量级的文件全流程耗时应该在2~5分钟区间，耗时超过10分钟即可判定为异常。

你遇到的慢基本是配置默认值和使用方式不匹配小负载场景导致的，和集群算力不足无关：

• 首先检查管道运行模式：DLT默认使用Continuous（连续运行）模式，流任务启动后会一直驻留等待路径下的新文件，不会在处理完现有文件后自动停止。你看到的24分钟大概率是管道启动后一直处于空闲等待状态的总时长，不是实际处理数据的时间——去Spark UI看对应流查询的状态，大概率早就处理完那个CSV，一直处于idle状态。
• 检查加载路径配置：你代码里直接load了挂载点根路径/mnt/mntname/，自动加载器会递归遍历该路径下所有文件，包括你之前测试残留的文件、Blob存储自动生成的隐藏临时文件、日志文件、快照文件等，如果路径下存在大量无关碎文件，目录枚举阶段会消耗大量时间。
• 版本和默认配置开销：你用的Runtime 10.4属于较早的版本，该版本的cloudFiles模块存在已知的小文件场景性能缺陷：默认开启的schema自动推断会反复读取文件做校验，目录遍历阶段没有做路径下推，初始化开销被明显放大。
• 集群配置过剩：你当前用的12核42GB集群对于26MB的负载来说算力严重冗余，Spark分布式调度executor、同步任务状态的开销远大于处理数据本身的开销，反而会拖慢整体速度。

按以下步骤调整后，这个任务的耗时可以压缩到3分钟以内：

1. 修改管道运行模式：如果是一次性导入存量文件，在DLT管道配置页把执行模式从Continuous改为Triggered，处理完路径下所有现有文件后管道会自动停止，不会空跑计时。
2. 精确配置读取路径和参数，不要直接加载挂载根目录，代码调整参考如下：

import dlt
from pyspark.sql.types import StructType, StructField, StringType, LongType # 按你的CSV实际字段定义对应类型
# 提前硬编码定义schema，完全关闭自动推断，这是小文件场景提速最明显的配置
custom_schema = StructType([
  StructField("col1", StringType()),
  StructField("col2", LongType())
  # 补全你自己的字段即可
])

@dlt.table(
  comment="this is a test"
)
def accounts():
  return (
    spark.readStream.format("cloudFiles")
      .option("cloudFiles.format", "csv")
      .option("header", "true") # 按你的CSV实际情况设置，有表头就设true，无表头设false
      .option("inferSchema", "false")
      .schema(custom_schema)
      .option("cloudFiles.includeExistingFiles", "true")
      .load("/mnt/mntname/csv文件所在的精确子目录路径/")
  )

3. 缩小集群规格：这个量级的任务用4核8GB的最小规格集群即可，大集群的启动和调度开销反而更高。

重跑管道时直接看DLT的更新日志即可定位具体瓶颈：

• 如果卡在Starting cluster阶段超过1分钟，是云侧集群资源申请慢
• 如果卡在Discovering files阶段超过1分钟，是路径下无关文件太多导致枚举慢
• 如果卡在Processing data阶段超过1分钟，检查是不是误读了大文件，或者schema配置不匹配导致数据解析异常重试

内容的提问来源于stack exchange，提问作者Valkyrja.Kara