基于ADLS Gen2的Delta Lake突发ListFilesystemDir交易激增咨询

问题1：Delta表操作对应的ADLS交易类型说明 #

Delta各类操作触发的ListFilesystemDir交易和其他存储交易的对应规则如下：

• 读Delta表：每次读取前都会先对表下的_delta_log目录发起ListFilesystemDir请求，拉取所有事务日志文件确认当前最新快照版本。如果读操作没有命中分区裁剪、或者关闭了Delta数据文件统计信息剪枝，还会额外对所有涉及的分区目录发起ListFilesystemDir请求，拉取分区下的Parquet数据文件列表。
• 写Delta表（追加、更新、删除、合并）：写入前需要先列_delta_log目录确认当前最大的日志版本号，避免版本冲突，会触发1次_delta_log目录的ListFilesystemDir请求；分区写场景下还会对目标分区目录发起List请求，确认已存在的文件信息，避免重复写入。
• 高频触发List操作的特殊场景：默认开启的spark.databricks.delta.checkLatestSchemaOnRead配置会让每次读表前都列一次_delta_log拉取最新schema；频繁执行DESCRIBE HISTORY、VACUUM等元数据操作也会高频列_delta_log目录；如果Delta表长期没有生成Checkpoint文件，_delta_log下的零散日志文件越多，每次列目录的成本越高，部分低版本Delta内核还会出现重复列目录的bug，是List交易量暴涨的常见诱因。

问题2：无需关停作业的定位方法 #

可以按从粗到细的维度逐层定位，全程不需要停止正在运行的Spark作业：

• 先定位异常容器：在Azure存储账户的监控面板，选择ListFilesystemDir指标，添加「文件系统名称」的拆分维度，直接就能看到bronze/silver/gold哪个容器的List请求占比最高，先缩小范围到对应数据层级。
• 再定位异常目录：开启存储账户的诊断日志，将Blob存储的操作日志导出到Log Analytics工作区，执行查询筛选OperationName == 'ListFilesystemDir'的请求，汇总Uri字段的访问频次，就能直接拿到被高频List的目录路径，一般都是某张Delta表的根目录或者对应的_delta_log目录。
• 最后定位对应Spark作业：拿到异常目录路径后，去Databricks工作区搜索对应时间段运行的作业日志，或者在集群的Spark UI的Storage页面筛选对应ADLS路径的访问记录，就能匹配到对应的作业。如果是Databricks Premium版，可以直接在使用情况分析面板按存储访问量排序作业，快速找到访问对应路径最多的任务。
• 快速排查校验：优先确认高频访问的Delta表是否很久没做过Checkpoint，是否有分钟级的定时任务反复读多张Delta表的最新数据，是否有作业配置了不合理的元数据刷新策略。

内容的提问来源于stack exchange，提问作者hbrgnr