4. 查询异常类型：语法错误、权限问题、资源不足、数据不一致、引擎兼容性等分类

4.1 为什么必须先对异常分类

多引擎湖仓环境中，一次查询从提交到返回结果，会依次经过“客户端 → 网关/调度器 → 引擎解析器 → 优化器 → 执行器 → 存储/元数据服务”等多个环节。不同环节产生的异常，其外在表现可能相似——例如都表现为“查询失败”，但根因、排查路径和修复手段截然不同。若不做分类而盲目排查，往往会在错误的方向上消耗大量时间。

从工程实践看，跨引擎查询异常可归纳为五大类：语法错误、权限问题、资源不足、数据不一致、引擎兼容性。这五类异常在“产生环节、错误信息特征、影响范围、排查手段”四个维度上具有明显差异，是端到端排查的“第一层分叉口”。

4.2 五类异常的判别特征与典型场景

4.2.1 语法错误（Parse Error）

语法错误发生在 SQL 解析阶段，是最容易定位的一类异常。多引擎环境下，语法错误往往不是“SQL 写错了”，而是“SQL 不符合当前引擎的方言规范”。例如，Flink SQL 支持 MATCH_RECOGNIZE 子句，而 Hive 3.x 不支持；Presto/Trino 使用 || 做字符串连接，而 Spark SQL 同时支持 concat() 和 ||（但版本间行为有差异）。

-- 典型报错示例（Spark SQL 解析 Trino 风格 SQL）
Error in SQL statement: ParseException:
mismatched input '||' expecting {<EOF>, ';'}(line 1, pos 32)

== SQL ==
SELECT user_id || '_' || channel FROM dwd_traffic_log
---------------------------^^^

4.2.2 权限问题（Access Control / Permission Denied）

权限问题发生在查询规划或执行阶段，当引擎检查当前用户对目标库、表、列或函数是否具备相应操作权限时触发。多引擎湖仓的权限体系通常由统一权限服务（如 Ranger、Kerberos + ACL）管理，但各引擎对权限的校验时机和粒度不同：Spark 在生成执行计划时校验表级权限，Trino 在访问列时才校验列级权限，Hive 则依赖 Metastore 层的授权。

-- Trino 报错示例
Query failed (#20240615_083012_04567_abcde): 
Access Denied: Cannot select from columns [user_phone] in table 
hive.dwd.dwd_user_profile_inc
USER: bi_zhang

权限问题的隐蔽性在于：同一用户在不同引擎上权限可能不同。例如，用户通过 Spark SQL 可以正常读取某表，但通过 Trino 查询同一张表却报权限不足——因为两个引擎接入的权限认证体系或用户映射规则不同。

4.2.3 资源不足（Resource Exhaustion）

资源不足类异常的特征是：SQL 本身没有语法问题，用户权限也足够，但查询在执行阶段因内存溢出、CPU 配额耗尽、队列排队超时或磁盘空间不足而失败。多引擎环境下，资源不足往往与引擎的资源隔离策略有关——同一个查询在资源充足的队列能跑通，在共享队列中则可能被 kill。

-- Spark 资源不足典型报错
Exception in thread "main" org.apache.spark.SparkException:
Job aborted due to stage failure: Task 3 in stage 12.0 failed 4 times,
most recent failure: Lost task 3.3 in stage 12.0:
java.lang.OutOfMemoryError: Java heap space

-- Trino 资源不足报错
Query exceeded per-node memory limit of 1.0GB
Total memory reserved: 1.2GB

4.2.4 数据不一致（Data Inconsistency）

数据不一致类异常是湖仓环境特有的“疑难杂症”，通常表现为：元数据（Metastore）中记录的表结构/分区信息与存储层（HDFS/S3/OSS）中的实际数据文件不一致。常见场景包括：

• Metastore 中表有 10 个分区，但 HDFS 上对应分区目录已被手动删除或覆盖；
• 表中某列的 Parquet 文件实际类型为 INT，但 Metastore 中声明为 BIGINT；
• ACID 表（如 Hive ACID、Iceberg）的元数据版本与数据文件版本不匹配；
• 上游任务写入数据时未提交事务，导致部分数据文件可见、部分不可见。

-- 数据不一致典型报错（Spark 读取 Hive 表）
java.io.IOException: 
Parquet column cannot be converted: 
Column "event_time" is INT64, expected TIMESTAMP
File: hdfs://nameservice1/user/hive/warehouse/dwd.db/event_log/dt=2024-06-14/part-00000.parquet

4.2.5 引擎兼容性（Engine Compatibility）

引擎兼容性问题是指：同一份数据、同一个 SQL 逻辑，在不同引擎上执行结果不同或部分引擎无法执行。这类问题不一定会报错，有时查询能成功但结果错误，排查难度最高。常见兼容性差异包括：

4.3 分类排查方法流程

面对一个跨引擎查询异常，建议按以下五步流程进行系统化分类与定位：

1. 收集完整错误上下文：包括错误信息全文、SQL 文本、执行引擎及版本、提交用户、执行时间、集群负载快照。不要只看错误摘要，很多关键线索在堆栈尾部。
2. 判断错误阶段：根据错误信息中的异常类名（如 ParseException、AccessDeniedException、OutOfMemoryError）或日志中的阶段标记，确定错误发生在解析、规划、执行还是结果返回阶段。
3. 匹配五类特征：将错误信息与 4.2 节中的五类典型特征逐一比对，优先匹配“报错关键字”和“是否涉及数据读取”两个维度。
4. 跨引擎复现对比：将同一 SQL 在另一个引擎上执行（如从 Spark 切到 Trino），观察是否复现。如果另一个引擎成功，优先怀疑引擎兼容性或权限差异；如果同样失败，优先怀疑数据或资源问题。
5. 查看引擎日志与监控：对于无法从错误信息直接定位的异常，进入引擎日志（如 Spark Driver/Executor 日志、Trino Coordinator/Worker 日志）和监控面板（YARN ResourceManager、Grafana）进一步确认。

4.4 案例复盘：一个被误判的“资源不足”

现象：某数据团队反馈，使用 Trino 查询 Hive 大表时频繁报 Query exceeded per-node memory limit，初步判断为资源不足，连续三次调大 query.max-memory-per-node 参数后问题依旧。

排查过程：

• 第一步，查看完整错误堆栈，发现报错前有一条 Column 'user_id' is of type BIGINT but expression is of type VARCHAR 的警告——这提示存在隐式类型转换。
• 第二步，检查 SQL，发现 WHERE 条件中写的是 WHERE user_id = '12345'，字符串与 BIGINT 比较导致 Trino 对 user_id 列做了全表类型转换，内存暴涨。
• 第三步，在 Spark 上执行相同 SQL，Spark 自动将字符串转为 BIGINT，未触发全表转换，因此成功——这解释了为什么只有 Trino 报资源不足。

根因：这不是真正的资源不足，而是引擎兼容性差异（隐式类型转换策略不同）引发的次生资源问题。修正 SQL 为 WHERE user_id = 12345 后，查询在默认资源配额下正常运行。