课程导入：学习目标、课程结构、多引擎湖仓架构概述
1.1 为什么需要关注跨引擎查询异常
现代数据平台早已从“单一引擎包打天下”演进为“多引擎协同的湖仓架构”。在同一个数据湖（如 Iceberg、Hudi、Delta Lake）之上，通常同时运行着 Spark、Flink、Presto/Trino、Hive 等多种计算引擎，分别承担批处理、流计算、交互式查询和 ETL 任务。这种架构带来了极大的灵活性，但也引入了一类棘手的故障——跨引擎查询异常：同一张表，用 Spark 写入后，用 Trino 查询却看不到数据；或者 Flink 实时写入的数据，Hive 端要等很久才能读到；甚至出现表结构元数据不一致导致查询直接报错。
这类问题的排查难度远高于单引擎故障，因为其根因往往不在某一个引擎内部，而在于元数据服务（Hive Metastore / Catalog）、文件格式（Parquet/ORC）、事务机制（ACID）、快照隔离级别以及各引擎对湖格式协议的实现差异。排查者需要同时理解存储层、元数据层和计算引擎层的行为，才能快速定位问题。
1.2 多引擎湖仓架构核心组件与数据流
为了后续章节的排查讨论有共同语境，我们先明确本课程所涉及的标准湖仓架构。下图展示了三个关键层次：存储层（分布式文件系统 + 湖格式）、元数据层（Catalog / Metastore）、计算引擎层（多种查询/计算引擎）。所有引擎通过统一的元数据服务感知表结构，并直接读写存储层的数据文件。
从上图可以看到，每个引擎都通过两条路径访问数据：控制流（向元数据服务发起请求，获取表 Schema、分区列表、当前快照 ID）和数据流（根据元数据返回的 Manifest 文件列表，直接读取存储层的数据文件）。这种“共享存储、共享元数据、独立计算”的架构，是跨引擎异常产生的根源。
1.3 典型异常场景分类
根据对生产环境的故障复盘，跨引擎查询异常可以归纳为以下四大类，本课程后续章节将逐一深入排查：
| 异常类别 | 典型表现 | 根因方向 |
|---|---|---|
| 数据可见性延迟 | Spark 已提交事务，Trino 查询不到最新数据 | 快照隔离级别、元数据缓存刷新策略、时间旅行语义 |
| Schema 不一致 | 引擎 A 写入新增列后，引擎 B 查询报“字段不存在” | Metastore 同步延迟、列类型映射差异、演进规则兼容性 |
| ACID 事务冲突 | 两个引擎同时写入同一张表，出现提交失败或数据丢失 | 并发冲突检测策略、乐观锁机制、写入顺序 |
| 文件格式/压缩兼容性 | 查询报“Unsupported compression”或读取到乱码 | 各引擎对 Parquet/ORC 的版本支持差异、ZSTD/Snappy 配置 |
1.4 课程结构：五阶段排查方法论
本课程共 30 章，按照“基础认知 → 单点排查 → 跨引擎联调 → 真实案例 → 预防体系”五个阶段组织，每一章都围绕一个具体异常场景展开。以下是课程的核心结构：
- 基础篇（第 1-5 章）：湖仓架构原理、各引擎对 Iceberg/Hudi 的实现差异、元数据服务内部机制、事务与快照原理。
- 存储与格式篇（第 6-10 章）：Parquet/ORC 文件结构、列统计与谓词下推、压缩算法兼容性、小文件问题。
- 元数据与 Schema 篇（第 11-15 章）：Metastore 缓存机制、Schema 演进冲突、分区元数据不一致、Catalog 同步异常。
- 事务与并发篇（第 16-20 章）：ACID 提交流程、冲突检测与重试、快照隔离级别、跨引擎并发写入调优。
- 综合实战篇（第 21-30 章）：端到端排查流程、日志分析技巧、诊断工具链、真实生产故障复盘、预防性监控设计。
1.5 学习目标与前置要求
完成本课程后，你将能够：
- 独立排查“Spark 写入后 Trino 查不到”等数据可见性问题，并能区分是缓存延迟还是事务未提交。
- 定位 Schema 演进导致的跨引擎查询报错，并给出兼容性解决方案。
- 分析多引擎并发写入时的冲突日志，调整隔离级别或重试策略。
- 读懂各引擎的 DEBUG 日志中与元数据、文件扫描相关的关键信息。
- 设计一套跨引擎数据一致性巡检脚本，提前发现潜在异常。
学习本课程前，建议具备以下基础：熟悉 SQL 基本语法、了解 Spark 或 Flink 的简单使用、对 HDFS 或 S3 等文件系统有基本概念。如果你尚未深入使用过 Iceberg 或 Hudi，不必担心，第 2 章会从零讲解湖格式的核心设计。