ADF数据流Source活动启用「按最后修改时间筛选」时数据预览报错原因排查

我来帮你梳理几个可能导致这个问题的原因，结合你描述的场景逐一分析：

1. 时间范围的理解偏差（最常见原因） #

你用的subDays(currentUTC(), 1)是当前UTC时间往前推24小时，而不是自然日的“昨天0点到今天0点”。举个例子：如果现在是UTC时间5月20日15:30，那你的筛选范围是5月19日15:30到5月20日15:30。如果你的目标文件是在5月19日14:00 UTC修改的，就会被排除在筛选范围外，导致ADF找不到符合条件的文件。

解决方法：如果想筛选自然日的昨天全天的文件，改用自然日边界的函数：

• 开始时间：startOfDay(subDays(currentUTC(), 1))
• 结束时间：startOfDay(currentUTC())

2. 时区不匹配问题 #

文件存储系统（比如Blob Storage、ADLS）里的文件最后修改时间，有些会存储为本地时区而非UTC。如果你的文件是用本地时区（比如UTC+8）修改的，ADF用UTC时间筛选就会出现时间差，导致符合条件的文件被过滤掉。

解决方法：检查文件存储系统里的文件实际最后修改时间，转换为UTC后确认是否在你设置的筛选范围内；或者根据存储系统的时区调整筛选函数（更推荐统一用UTC来避免混乱）。

3. 通配符与筛选逻辑的冲突 #

你的通配符是subfolder/subfolder/**/*.parquet，**表示递归遍历所有子文件夹，但ADF的“按最后修改时间筛选”是针对文件本身的修改时间，而非文件夹的修改时间。不过有一种情况需要注意：如果某个子文件夹的权限设置导致ADF无法访问，而符合时间条件的文件刚好在这个文件夹里，就会出现找不到文件的错误；或者当**递归的层级太多时，ADF的预览可能无法及时遍历到所有符合条件的文件。

解决方法：

• 先缩小通配符范围，比如直接指定某个子文件夹（比如subfolder/subfolder/folder1/*.parquet），测试筛选是否生效，逐步排查是哪个层级出了问题；
• 检查所有子文件夹的权限，确保ADF的服务主体有读取权限。

4. 时间精度不匹配问题 #

虽然subDays(currentUTC(), 1)语法上是正确的，但ADF对时间的精度（毫秒级）可能和文件存储系统的时间精度不一致。比如文件的修改时间只精确到分钟，而ADF的currentUTC()返回的是毫秒级时间，可能导致边缘时间的文件被误过滤。

解决方法：可以尝试把时间范围放宽一点，比如用subDays(currentUTC(), 1.1)（相当于往前推26.4小时），测试是否能找到文件，验证是否是精度问题导致的。

5. 预览缓存或临时元数据延迟 #

有时候ADF数据流的预览会缓存之前的结果，或者临时出现元数据同步延迟。关掉筛选能看到文件，说明文件本身是存在且可访问的，但启用筛选后预览可能没及时刷新元数据。

解决方法：点击预览面板的「刷新」按钮，或者重新打开数据流编辑器，再测试筛选功能。

备注：内容来源于stack exchange，提问作者mkn