RedShift使用JSON_PARSE()时报End-of-input during string sequence错误排查

1. 执行顺序触发未过滤的坏数据解析 #

RedShift查询优化器会调整算子执行顺序，优先执行SELECT子句中的JSON_PARSE逻辑，再执行OFFSET/LIMIT截断、甚至部分WHERE过滤逻辑。你第一条查询需要扫描所有符合基础过滤条件的行，对每一行先做JSON_PARSE再排序截断，只要前1000行中存在任意一行格式非法的JSON数据，就会触发报错。报错信息中的End-of-input during string sequence是典型的JSON字符串未闭合、内容截断不完整的特征，进一步验证了存在非法JSON数据。
你单独取出第1001行的内容是合法的，且单独解析时没有涉及前面的坏数据，所以不会触发报错。

2. WHERE条件逻辑缺陷 #

当前WHERE过滤条件(inputs IS NOT NULL OR inputs != 'null')存在逻辑问题：
你实际需要排除的是值为NULL、以及值为字符串'null'的无效数据，应该用AND连接两个条件，而非OR。虽然当前OR逻辑也能过滤掉这两类无效值，但完全没有覆盖其他格式非法的JSON场景（比如特殊字符转义错误、内容截断、符号缺失等）。

执行以下查询检查前1000行数据，即可定位到坏数据：

SELECT inputs FROM table
WHERE prompttype = 'input' 
AND inputs IS NOT NULL 
AND inputs != 'null'
ORDER BY created
LIMIT 1000;

逐行校验上述结果的JSON格式，必然存在不合法的JSON值。

使用RedShift提供的容错解析函数TRY_JSON_PARSE替代JSON_PARSE，该函数遇到非法JSON时会返回NULL而非中断查询抛出报错：

SELECT TRY_JSON_PARSE(inputs) AS inputs_super
FROM table
WHERE prompttype = 'input' 
AND inputs IS NOT NULL 
AND inputs != 'null'
ORDER BY created
OFFSET 1000
LIMIT 1;

如果需要彻底过滤掉非法JSON的行，可以在WHERE条件中追加校验规则：

SELECT TRY_JSON_PARSE(inputs) AS inputs_super
FROM table
WHERE prompttype = 'input' 
AND inputs IS NOT NULL 
AND inputs != 'null'
AND TRY_JSON_PARSE(inputs) IS NOT NULL
ORDER BY created
OFFSET 1000
LIMIT 1;

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