Azure Blob存储与Azure Databricks间高效数据检索优化方案咨询

核心问题根因 #

当前实现存在3个典型的性能损耗点：

• 自定义递归遍历Blob路径：dbutils.fs.ls本身是串行元数据请求，海量文件下遍历耗时极长
• 逐文件读取+循环union：单文件读无法利用Spark并行能力，循环union会导致执行计划指数级膨胀，额外占用大量driver资源
• 小文件本身的开销：海量零散小文件会带来大量的文件打开/关闭、元数据请求开销，这部分开销和计算资源无关，单纯扩容集群无法完全解决

第一级优化：直接改写读取逻辑（无需改架构，立即可用） #

直接删除原有递归遍历、逐文件读取、循环union的所有代码，Spark原生支持通配符匹配路径下所有指定格式文件，并行读取后直接生成单个DataFrame，性能可提升5~10倍。
优化后代码如下：

# 直接递归读取指定路径下所有后缀为.avro的文件，**代表匹配所有层级子目录
avro_df = spark.read.format("avro").load("dbfs:/mnt/PATH/**/*.avro")
display(avro_df)

如果需要按日期/时间范围筛选文件，可以在load的路径里加时间通配符，或者用modifiedAfter/modifiedBefore参数过滤，不需要遍历所有文件元数据。

第二级优化：存储层小文件合并（适配当前日级处理需求） #

日均8.6万小文件的场景下，仅改读取逻辑仍有优化空间，建议增加前置合并步骤：

• 每日ETL执行前，先跑一个轻量合并任务，把前一日生成的所有小avro文件合并为单个体积128MB~256MB的大文件（适配Spark分区最佳实践），存入专门的合并层路径
• 后续ETL直接读取合并后的大文件，可将整体处理耗时压缩80%以上
• 可选切换为Delta Lake存储格式，开启自动优化/自动压缩功能，Databricks会在写入时自动合并小文件，无需额外开发合并逻辑

第三级优化：架构适配后续近实时需求 #

如果后续要上线近实时洞察能力，直接改用Spark Structured Streaming处理：

• 既可以直接对接上游Azure Event Hub做流处理，端到端延迟可控制在分钟级
• 也可以以Blob存储的avro文件作为源，设置微批次定时读取新生成的文件，天然避免批量扫描全量文件的开销
• 流处理模式下还可以配置自动合并输出文件，从源头避免小文件生成

关于集群扩容的说明 #

单纯扩容集群可以提升并行读取的能力，但无法解决文件元数据遍历、文件打开关闭带来的固定开销，优先完成上述代码和存储层优化后，再根据实际的计算瓶颈调整集群规格，性价比会高很多。

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