📚 课程目录第4章环境准备与实验设计

4. 环境准备与实验设计：搭建测试环境、模拟故障场景

Delta Lake 存储层故障的根因定位，不能依赖生产环境中的“碰运气”式排查。一个可控、可重复、可观测的测试环境，是理解故障机理、验证修复方案的前提。本章将围绕“如何搭建一套最小但完整的 Delta Lake 故障复现环境”，以及“如何设计故障注入实验”展开，帮助你建立从现象到根因的闭环实验能力。

4.1 核心原理：故障复现的三层解耦

Delta Lake 存储层故障通常涉及三个独立层次：文件系统层（对象存储或 HDFS）、事务日志层（_delta_log 目录下的 JSON 文件）、表状态层（Spark 内存中的快照）。故障根因定位的难点在于：同一表象（如“读取报错”）可能源自任意一层。因此，实验环境必须支持对三层进行独立干预。

实验设计原则：

隔离性：使用独立存储桶/目录，避免与生产数据交叉。
可控性：能够手动删除、篡改、延迟或重复特定文件。
可观测性：记录每次操作前后的文件列表、日志版本号和校验值。

下图展示了测试环境中三层之间的依赖关系，以及故障注入的切入点：

4.2 方法流程：搭建最小测试环境

推荐使用 Docker + MinIO + Spark 3.x + Delta Lake 2.x 的组合。MinIO 提供 S3 兼容接口，便于模拟对象存储的延迟、限流和文件覆盖行为；Spark 负责执行 Delta 操作。整个环境可在单机 8GB 内存下运行。

4.2.1 环境组件清单

组件	版本建议	作用
Docker / Docker Compose	20.10+	容器编排，隔离依赖
MinIO	RELEASE.2023-03-20	S3 兼容对象存储，模拟 OSS/S3
Apache Spark	3.3.2	计算引擎，运行 Delta Lake
Delta Lake	2.3.0	ACID 表存储层
Jupyter / spark-shell	—	交互式实验入口

4.2.2 启动脚本示例

创建 docker-compose.yml，核心配置如下：

version: "3.8"
services:
  minio:
    image: minio/minio:RELEASE.2023-03-20T00-00-00Z
    ports:
      - "9000:9000"
      - "9001:9001"
    environment:
      MINIO_ROOT_USER: deltaadmin
      MINIO_ROOT_PASSWORD: delta12345
    command: server /data --console-address ":9001"
    volumes:
      - ./minio-data:/data

  spark:
    image: apache/spark:3.3.2
    depends_on:
      - minio
    environment:
      - AWS_ACCESS_KEY_ID=deltaadmin
      - AWS_SECRET_ACCESS_KEY=delta12345
      - AWS_REGION=us-east-1
    volumes:
      - ./scripts:/opt/scripts
      - ./jars:/opt/jars
    entrypoint: ["/opt/scripts/start-spark.sh"]

启动后，在 Spark 中配置 Delta Lake 与 S3 连接：

from pyspark.sql import SparkSession

spark = SparkSession.builder \
    .appName("DeltaFaultLab") \
    .config("spark.sql.extensions", "io.delta.sql.DeltaSparkSessionExtension") \
    .config("spark.sql.catalog.spark_catalog", "org.apache.spark.sql.delta.catalog.DeltaCatalog") \
    .config("spark.hadoop.fs.s3a.endpoint", "http://minio:9000") \
    .config("spark.hadoop.fs.s3a.path.style.access", "true") \
    .config("spark.hadoop.fs.s3a.connection.ssl.enabled", "false") \
    .getOrCreate()

# 创建测试表
spark.sql("CREATE TABLE IF NOT EXISTS delta.`s3a://delta-bucket/user_events` (id INT, event STRING) USING DELTA")

验证环境就绪：执行 spark.sql("SELECT * FROM delta.`s3a://delta-bucket/user_events`").show()，若返回空表且无报错，说明三层链路（Spark → MinIO → Delta 日志）已打通。

4.3 案例/场景：三类典型故障的模拟实验

以下三个实验场景覆盖了 Delta Lake 存储层最常见的故障类型。每个实验均包含故障注入操作和预期现象，便于后续章节对照学习。

4.3.1 场景 A：数据文件缺失（FileNotFound）

故障模拟：向表中写入 100 条数据后，手动删除 MinIO 中某个 parquet 数据文件。

# 1. 写入数据
spark.sql("INSERT INTO delta.`s3a://delta-bucket/user_events` VALUES (1, 'click'), (2, 'view')")

# 2. 查看当前数据文件列表
import os
# 通过 MinIO 客户端或 API 删除最新 parquet 文件
# 示例：mc rm minio/delta-bucket/user_events/part-00000-xxx.snappy.parquet

# 3. 触发读取
spark.sql("SELECT COUNT(*) FROM delta.`s3a://delta-bucket/user_events`").show()

预期现象：抛出 FileNotFoundError 或 java.io.FileNotFoundException，错误信息中会包含缺失文件的完整路径。此时需要区分：是文件真的被删除，还是日志中记录了不存在的文件（即“悬空引用”）。

4.3.2 场景 B：事务日志回滚（Checkpoint 丢失）

故障模拟：删除 _delta_log 目录下最新的 checkpoint 文件，仅保留部分 JSON 日志。

# 1. 写入多批次数据，产生多个 JSON 日志
for i in range(5):
    spark.sql(f"INSERT INTO delta.`s3a://delta-bucket/user_events` VALUES ({i}, 'event_{i}')")

# 2. 手动删除 checkpoint
# mc rm minio/delta-bucket/user_events/_delta_log/_last_checkpoint
# mc rm minio/delta-bucket/user_events/_delta_log/00000000000000000004.checkpoint.parquet

# 3. 重新读取表
spark.sql("SELECT * FROM delta.`s3a://delta-bucket/user_events`").show()

预期现象：Delta Lake 会尝试从最早的 JSON 日志重建状态。若日志不完整，可能报 IllegalStateException 或读取到过期数据。此场景用于训练排查“元数据不一致”问题。

4.3.3 场景 C：并发写冲突（Commit Conflict）

故障模拟：启动两个 Spark 会话，同时对同一张表执行 INSERT 操作。

# 会话 1
spark.sql("INSERT INTO delta.`s3a://delta-bucket/user_events` SELECT id + 100, 'batch1' FROM range(10)")

# 会话 2（同时执行）
spark.sql("INSERT INTO delta.`s3a://delta-bucket/user_events` SELECT id + 200, 'batch2' FROM range(10)")

预期现象：其中一个会话会抛出 ConcurrentAppendException，提示“Transaction committed concurrently”。这是 Delta Lake 乐观并发控制的正常保护机制，但若日志清理策略不当，可能导致死锁或长时间重试。

4.4 误区与复盘：实验设计中的常见陷阱

误区 1：直接在本地文件系统上模拟对象存储。

本地文件系统不具备对象存储的“最终一致性”和“覆盖写”语义。例如，MinIO 中覆盖同名对象不会报错，但本地文件系统可能因权限或锁机制产生不同行为。务必使用 S3 兼容存储。

误区 2：故障注入后不做“基线对比”。

每次实验前应记录表当前版本号、文件数量和日志大小。例如：

# 基线记录
spark.sql("DESCRIBE HISTORY delta.`s3a://delta-bucket/user_events`").show(5)
# 记录 version, timestamp, operation, numFiles

没有基线，就无法判断故障是注入导致还是环境本身不稳定。

误区 3：同时注入多个故障。

例如既删除数据文件又篡改日志，会导致根因无法区分。正确做法是：一次只注入一个故障，验证现象后恢复，再注入下一个。建议使用脚本自动记录每次实验的“故障指纹”。

4.4.1 实验记录模板

建议为每个实验建立如下清单，便于后续章节对照：

实验编号：如 EXP-004-A
故障类型：数据文件缺失 / 日志回滚 / 并发冲突
注入方式：删除文件 / 删除 checkpoint / 双会话写入
表版本号：故障前版本 → 故障后版本
错误信息关键字：如 FileNotFound、ChecksumMismatch
恢复操作：如 FSCK、RESTORE、重试写入