多Glue作业并发时Redshift Serializable隔离违规问题排查与解决

问题根源 #

Redshift的Serializable隔离级别会强制事务执行结果等价于某个串行执行顺序，通过谓词锁机制检测潜在的冲突。即便每个Glue作业操作fault_table的不同ctl_tbl行，仍会触发违规，核心原因如下：

1. 谓词锁的范围判定：每个事务中执行的SELECT max(...) FROM fault_table WHERE ctl_tbl='xxx'查询，在Serializable级别下，Redshift会为满足ctl_tbl='xxx'的行添加谓词锁。当多个事务同时执行这类查询时，锁检测逻辑可能判定这些操作的执行顺序无法通过串行复现（比如事务A查询行X、事务B查询行Y，之后各自插入新行，Redshift会认为这种并发结果无法对应任何串行执行序列）。
2. 插入操作的连锁影响：事务末尾的INSERT INTO fault_table会新增行，并发事务的查询阶段可能会感知到新行的潜在存在，进一步触发Serializable的冲突检测逻辑。

解决方法 #

1. 降级隔离级别到Read Committed #

大多数ETL场景不需要Serializable的严格隔离，将事务隔离级别改为Read Committed可以直接规避冲突检测：

BEGIN;
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

-- 原事务逻辑（创建临时表、UNLOAD、插入fault_table等）

END;

Read Committed仅保证读取已提交的数据，不会校验串行化一致性，能大幅减少这类违规问题。

2. 为fault_table添加唯一索引 #

在ctl_tbl列上创建唯一索引，让Redshift精准定位单行，缩小锁的范围：

CREATE UNIQUE INDEX idx_fault_table_ctl_tbl ON fault_table(ctl_tbl);

索引会让WHERE ctl_tbl='xxx'的查询直接定位到单行，谓词锁的范围被限制为单行，降低并发冲突概率。

3. 优化事务逻辑，缩小事务范围 #

将读取last_loaded_datetime的操作移到事务外部，先获取固定值后再执行事务：

-- 事务外先获取最后加载时间
SELECT coalesce(max(last_loaded_datetime),'1990-01-01') INTO @last_loaded FROM fault_table WHERE ctl_tbl='glue_job_unique_name';

-- 事务内使用固定值执行逻辑
BEGIN;
CREATE TEMPORARY TABLE glue_job_unique_table_inc AS SELECT * FROM glue_job_unique_table
WHERE loadeddtm > @last_loaded;

-- UNLOAD逻辑...

INSERT INTO fault_table VALUES ('text','glue_job_unique_table',sysdate);

DROP TABLE glue_job_unique_table_inc;
END;

这样事务内不再包含对fault_table的查询操作，仅执行插入，避免查询阶段的锁冲突。

4. 显式锁定目标行 #

如果必须保留Serializable级别，可在事务开始时显式锁定目标行，确保串行执行：

BEGIN;
-- 显式锁定该行，其他事务需等待锁释放
SELECT last_loaded_datetime FROM fault_table WHERE ctl_tbl='glue_job_unique_name' FOR UPDATE;

-- 原事务逻辑...

END;

此方法会降低并发度，但能彻底解决Serializable隔离违规问题。

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