DataBricks将亿级表下载至ADLS后关联小表是否低效？求优化方案

当前方案是否低效？ #

是的，默认的内关联操作在这种场景下会非常低效。原因在于：

• 10亿条记录的大表会被全量扫描，若触发Shuffle Join，还会产生跨节点的大量数据传输，资源消耗极高；
• 本质是用小表过滤大表，但默认关联不会针对性优化，会执行全量数据的关联计算，完全浪费算力。

DataBricks中PySpark的更优实现方式 #

1. 显式使用广播小表（Broadcast Join） #

小表仅3万条记录，完全可以广播到每个Executor节点，避免大表的Shuffle操作，每个节点直接用本地的小表数据过滤大表。
代码示例：

from pyspark.sql.functions import broadcast

# 假设small_df为3万条的小表，large_df为10亿条的大表
result_df = broadcast(small_df).join(large_df, on="ID", how="inner")

DataBricks默认会自动对小表开启广播，但显式调用broadcast()可以确保优化生效，也可通过调整配置spark.sql.autoBroadcastJoinThreshold（默认10MB，可根据小表实际大小调整）适配需求。

2. 数据源端预过滤大表（推荐） #

既然核心需求是用小表ID过滤大表，可直接在读取大表阶段完成过滤，避免全量读取10亿条数据：

• 先提取小表的ID集合，导出到ADLS存储（保存为Parquet或CSV格式均可）；
• 在Azure Synapse中创建外部表，指向ADLS上的ID列表文件；
• 读取大表时，直接在Synapse的SQL查询中加入WHERE ID IN (SELECT ID FROM 外部ID表)，让过滤逻辑在数据源端完成，仅将匹配的3万条左右数据读取到DataBricks。
  这种方式能最大程度减少数据传输和计算量，效率最优。

3. 结合分区裁剪优化 #

如果大表在Synapse中是按ID或相关列分区的，读取时先通过分区过滤缩小扫描范围，再结合广播Join进一步优化，能进一步降低资源消耗。

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