Databricks定时任务创建表失败问题排查

核心问题 #

在Databricks使用XXL SQL Warehouse（2个worker）执行左连接任务时，手动运行稳定成功，但定时任务在写入Delta表阶段持续失败，报错为org.apache.spark.shuffle.FetchFailedException，底层原因是java.nio.channels.ClosedChannelException。

可能原因 #

1. 定时任务的仓库资源状态差异：手动运行时SQL Warehouse处于活跃状态，资源已完成初始化；定时任务触发时可能遇到仓库冷启动，资源分配不充分，导致shuffle阶段网络连接稳定性下降。
2. Shuffle配置不合理：数十亿行数据使用默认shuffle分区数时，可能出现分区过大或数据分布不均，在定时任务环境下（可能存在网络波动或资源竞争）更容易触发通道断开。
3. 执行计划差异：手动运行时Spark可能自动刷新了表统计信息，生成了更优的Join策略；定时任务时统计信息过期，导致优化器选择了低效的shuffle Join，增加了网络传输压力。
4. Photon引擎的环境差异：报错栈包含Photon相关执行逻辑，定时任务可能启用了与手动运行不同的Photon配置，导致写入阶段的网络通道异常。

解决方法 #

1. 避免SQL Warehouse冷启动 #

将定时任务关联的SQL Warehouse设置为始终运行（Keep warm），确保任务触发时仓库已完成资源初始化，消除冷启动带来的资源波动问题。

2. 优化Shuffle与网络配置 #

在定时任务的SQL开头添加以下配置，调整shuffle分区数并延长网络超时：

SET spark.sql.shuffle.partitions = 2000; -- 根据数据量调整，建议每个分区大小在100-200MB之间
SET spark.network.timeout = 300s; -- 延长网络超时时间，避免短暂波动导致连接断开
SET spark.executor.heartbeatInterval = 60s;

3. 强制使用Broadcast Join优化 #

由于tableB仅数百万行，适合广播到所有worker节点，避免大规模shuffle操作。修改SQL如下：

DROP TABLE IF EXISTS tableC;
CREATE TABLE tableC
AS (
    SELECT * 
    FROM tableA
    LEFT JOIN BROADCAST(tableB)
    ON tableA.id = tableB.id
);

4. 刷新表统计信息 #

在定时任务SQL开头添加统计信息刷新语句，确保Spark优化器生成最优执行计划：

ANALYZE TABLE tableA COMPUTE STATISTICS FOR ALL COLUMNS;
ANALYZE TABLE tableB COMPUTE STATISTICS FOR ALL COLUMNS;

5. 优化Delta写入配置 #

添加Delta写入的优化参数，或者对tableC进行分区，减少单批次写入压力：

-- 启用写入前重分区优化
SET spark.databricks.delta.merge.repartitionBeforeWrite.enabled = true;

-- 或者按tableA的分区键创建分区表
DROP TABLE IF EXISTS tableC;
CREATE TABLE tableC
PARTITIONED BY (your_partition_column) -- 替换为tableA中的分区字段（如日期、地域）
AS (
    SELECT * 
    FROM tableA
    LEFT JOIN BROADCAST(tableB)
    ON tableA.id = tableB.id
);

6. 确认定时任务的仓库配置一致性 #

检查定时任务使用的SQL Warehouse是否与手动运行时完全一致，确保worker数量、规格、引擎配置（如Photon启用状态）没有差异。

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