AWS Glue Job执行Athena可正常运行的SQL时出现列无法解析报错

这个问题本质是Athena与Glue所使用的SQL引擎语法规则不兼容，外加SQL语句单引号配对错误导致解析逻辑错位：

1. Athena基于Trino/Presto引擎，对引号使用的容错度更高；Glue执行Spark SQL时使用Catalyst解析器，语法校验更严格，单引号仅用于包裹字符串字面量，列/表标识符引用只能直接写名称或用反引号包裹，不能用单引号包裹标识符。
2. 从给出的执行计划可以看到，security_type前带了Catalyst标记未解析标识符的单引号前缀，且报错显示当前查询上下文的可用输入列为空数组，说明SQL中某一处字符串字面量的单引号漏写闭合、或者出现了中英文引号混用、引号嵌套未转义的问题，导致解析器的语法分析逻辑错位：本该被识别为字符串内容的片段被错误判定为SQL语法段，本该从数据源读取的列/表引用被吞进了字符串常量里，最终不仅找不到security_type这个列，连整个数据源的Schema都没被正确解析，才会出现输入列为空的报错。

• 逐字符核对SQL中所有引号的配对：重点排查所有字符串字面量的单引号是否成对闭合，有没有混入中文单引号、全角引号的情况；如果字符串内容本身包含单引号，需要用两个连续单引号做转义（例如要表示字符串it's a test，SQL里要写成'it''s a test'）。
• 修正标识符引用写法：如果你是要查询数据源里的security_type列，直接写列名即可，禁止给列名加单引号；如果列名包含特殊字符需要转义，仅用反引号包裹列名。如果你是要把字符串常量security_type作为inv_type字段的返回值，要确认包裹该字符串的单引号正确闭合，没有和前后的SQL片段连在一起。
• 验证数据源注册逻辑：执行计划里LogicalRDD false下没有挂载任何列信息，先单独跑SELECT * FROM myDataSource LIMIT 10，确认Glue侧已经正确注册了myDataSource这个表/临时视图，能正常读取到所有字段，排除表加载失败、Schema未正确推导的问题。
• 分段定位错误点：把整段SQL拆成最小可执行单元，从最简单的查询开始逐段增加字段、筛选条件、关联逻辑，每加一段就执行一次，定位到具体是哪部分语句加入后触发解析报错，就能精准找到引号错位的具体位置。
• 做引擎语法适配：不要直接把Athena跑通的SQL原封不动迁移到Glue Spark环境运行，两个引擎在标识符转义、函数命名、类型转换规则上都存在差异，迁移时要对照Spark SQL语法规范做适配。

报错信息参考：

pyspark.sql.utils.AnalysisException: cannot resolve '`security_type`' given input columns: []; line 5 pos 0;

异常执行计划参考：

'GlobalLimit 100
+- 'LocalLimit 100
+- 'Project [test AS userid#40, test AS action#41, test AS datapoint_id#42, 'security_type AS inv_type#43]
+- SubqueryAlias myDataSource
+- LogicalRDD false

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