使用ADF向ADX导入数千个大Parquet文件时遇超时问题

背景 #

• 每日导入量：约5000个Parquet文件
• 文件大小：每个约3-3.5 GB（每日总计约15-17 TB）
• 文件路径格式：/{yyyy}/{MM}/{dd}/{HH}/example_v2_{yyyyMMdd}_{HH}_00_00.000XXXX.parquet

此前非ADF方案 #

切换到ADF前，采用Lens模式：10个并行导入管道，各导入至独立ADX中间表，完成后合并或切换至最终表，该方案运行稳定，但不确定在ADF中是否适用。

当前问题 #

使用单个Mapping Data Flow读取指定小时文件夹下所有文件时，持续出现超时和任务失败。

评估方案 #

方案1：文件夹分片（"lanes"） #

将文件预分区至/{yyyy}/{MM}/{dd}/{HH}/lane=0/等子文件夹，每lane约500个文件，运行10个并行Data Flow，均导入同一ADX表。

方案2：多目标表（Lens模式） #

运行10个并行Data Flow，各导入至独立ADX中间表，完成后执行合并或表切换操作。

Data Flow vs Copy Activity #

当前使用Mapping Data Flow而非Copy Activity，原因是Copy Activity会将时间戳以int64类型导入，而Data Flow可保留时间戳语义，无需后续转换处理，但不确定该数据量级下是否适用Data Flow。

核心问题 #

1. 将文件分片到"lanes"子文件夹并运行并行Data Flow是否是推荐方案？
2. 在ADF中实现多表导入+合并/切换的Lens模式是否合理？
3. 超大规模ADLS→ADX导入场景下，Copy Activity是否优于Mapping Data Flow？
4. 并行导入时，直接写入单个ADX表还是先写入临时表更佳？

解答 #

1. 文件夹分片+并行Data Flow的可行性 #

该方案完全可行，是ADF处理大规模文件导入的常用优化手段。通过将文件按lanes分片，可将单个Data Flow的负载拆分到多个并行实例，避免单任务处理过多文件导致的超时。需要注意：

• 确保分片逻辑均匀，每个lane的文件数量/总大小尽量一致，避免负载不均
• 配置ADF并行度时，需结合ADX的 ingestion capacity（可通过.show capacity查看），避免超出ADX的导入能力上限
• 在Data Flow的ADX sink中配置合适的批量大小，匹配文件分片粒度，提升导入效率

2. ADF中实现Lens模式的合理性 #

非常合理，这是应对超大规模导入的成熟模式，尤其适合需要保证最终表数据一致性的场景：

• 每个并行Data Flow写入独立临时表，可隔离导入失败的影响，单个任务失败无需全部重跑
• 所有导入完成后，可通过ADX的.rename tables命令快速切换临时表为最终表，或用.append/.set-or-append合并临时表数据到最终表
• 在ADF中可通过Execute Kusto Query活动执行这些操作，配合管道依赖控制（如所有Data Flow成功后再触发Kusto命令），实现端到端的自动化

3. Copy Activity vs Mapping Data Flow的选择 #

超大规模ADLS→ADX导入场景下，Copy Activity通常更优：

• Copy Activity是轻量级批量导入工具，直接调用ADX原生 ingestion API，性能更高、资源消耗更低，适配纯数据迁移场景
• 针对时间戳类型问题，可通过Copy Activity的列映射功能，显式指定时间戳列类型（如datetime）。例如若源是Unix时间戳，可在映射中设置转换规则，将int64转为ADX的datetime类型，无需依赖Data Flow的转换能力
• Data Flow更适合复杂数据转换（过滤、聚合、JOIN等）场景，若仅为数据导入，Copy Activity的性能和稳定性更适配超大规模场景

4. 并行导入目标选择：单表 vs 临时表 #

推荐先写入临时表，再合并/切换到最终表：

• 直接并行写入单个ADX表可能引发导入冲突，导致数据重复、导入失败或性能下降
• 临时表模式可实现原子性更新：所有临时表导入完成后再切换到最终表，保证最终表的数据完整性，避免部分导入导致的数据不一致
• ADX的表切换操作是元数据级别的，几乎无性能开销，适合大规模数据的快速上线

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