Spark中left join与cross join在计算资源层面的主要差异是什么？

一、计算行为层面 #

• left join（左外连接）
  • 必须指定on关联条件，核心逻辑是全量保留左表记录，右表仅返回和左表关联键匹配的记录，未匹配的右表字段统一补null
  • 最终输出行数上限为左表总行数（仅当右表关联键存在重复值时会出现行膨胀，但量级通常可控）
  • 示例：左表1000条用户数据、右表200条订单数据，关联键为user_id，最终输出最多1000条记录
• cross join（笛卡尔积）
  • 不需要任何关联条件，直接返回左表与右表的所有行组合结果
  • 最终输出行数固定为「左表行数 × 右表行数」，无任何过滤逻辑
  • 示例：左表1000条、右表200条，cross join后直接输出200000条记录；若两张表均为百万级，输出量级直接达到万亿级

二、资源占用层面 #

• 内存占用
  • left join：Spark会按关联键做shuffle分区，同一关联键的数据拉到同一个Executor处理，内存占用和shuffle后单分区最大数据量正相关，无严重数据倾斜时开销可控
  • cross join：不会按关联键做shuffle，默认会把小表全量广播到所有Executor节点，和大表每个分区做笛卡尔计算；若两张表均为大表，会直接触发全量笛卡尔计算，内存占用呈指数级上升，极容易触发OOM内存溢出
• CPU开销
  • left join：CPU消耗主要集中在shuffle阶段的序列化、反序列化，以及关联匹配逻辑，量级和两张表总数据量正相关
  • cross join：CPU消耗和最终输出的笛卡尔积行数正相关，为两张表单量的乘积级，比left join高几个数量级，很容易直接打满集群CPU资源
• 磁盘&网络IO
  • left join：IO开销主要来自shuffle阶段的分区数据读写、跨节点传输，仅关联键对应的数据需要跨节点流转
  • cross join：如果触发小表广播，会产生小表全量往所有Executor传输的网络开销；如果是大表+大表的cross join，会产生巨量中间结果落盘，IO开销比left join高几十到上百倍，作业运行时间会拉长到完全无法接受的程度

注意：日常开发中除非明确需要笛卡尔积场景（比如维度表补全、枚举值组合），否则禁止使用cross join，很容易因为误写大表关联直接打垮集群资源。

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