📚 课程目录第4章湖仓一体存储层选型与部署

4. 湖仓一体存储层选型与部署

湖仓一体平台的存储层不是简单的“把数据放哪儿”，而是决定元数据一致性、扫描吞吐、并发写入能力、成本模型和故障恢复方式的基础设施。选型时最容易犯的错误，是只比较“容量单价”，而忽略访问模式、延迟敏感度、小文件数量、计算引擎与存储的耦合程度。本节先建立四类存储的适用边界，再通过一个可复现的部署与调优实验，说明如何用真实指标判断存储层是否满足湖仓负载。

四类存储的本质差异

对象存储（如 S3、OSS、MinIO）以桶和对象为基本单位，提供近乎无限的扩展性和按量计费，适合作为湖仓的“单一事实源”。它的优势是存算分离彻底、多引擎可共享同一份数据、生命周期管理成熟；代价是元数据操作延迟较高，重命名和目录遍历代价大，小文件过多时 LIST 操作会成为瓶颈。HDFS 以块为单位、依赖 NameNode 管理元数据，适合已有 Hadoop 生态、需要高吞吐顺序扫描且数据量在 PB 级以内的场景；但 NameNode 内存受文件数限制，跨机房容灾和弹性扩缩容不如对象存储灵活。云存储通常指云厂商提供的托管对象存储及其加速层（如 S3 Express、OSS 加速、云盘），本质仍是对象存储，但通过就近接入、缓存和协议优化降低延迟，适合对冷启动和交互式查询有要求的云上湖仓。本地存储（NVMe SSD、本地盘、临时盘）延迟最低、带宽最高，适合作为缓存层、Shuffle 中间数据、向量索引或热数据加速，但不具备持久性和多副本能力，不能作为唯一数据源。

选型判断：先看访问模式，再看成本

一个实用的判断顺序是：第一，数据是否需要被多个计算引擎共享、是否要求存算分离，若是，对象存储优先；第二，是否存在大量随机点查或毫秒级交互查询，若是，在对象存储之上叠加本地缓存或云存储加速层；第三，是否已有稳定的 Hadoop 集群且文件数可控，若是，HDFS 仍可作为主存储；第四，本地盘只用于可重建的中间数据，绝不作为唯一副本。以某湖仓实验环境为例：原始日志约 2 TB/天，Parquet 文件平均 128 MB，查询以全表扫描和分区裁剪为主，此时对象存储加 Iceberg 是合理起点；若把同样数据写入 HDFS，顺序扫描吞吐可能更高，但扩容和跨引擎共享成本会上升。

部署实验：对象存储 + Iceberg + Spark

下面以 MinIO 模拟对象存储、Spark 作为计算引擎，完成一次可复现的存储层部署与调优实验。实验目标：验证对象存储作为湖仓主存储的读写路径，并通过调整文件大小和并行度观察扫描吞吐变化。

# 1. 启动 MinIO（单节点实验环境）
docker run -d --name minio \
  -p 9000:9000 -p 9001:9001 \
  -e MINIO_ROOT_USER=admin \
  -e MINIO_ROOT_PASSWORD=admin123 \
  -v /data/minio:/data \
  minio/minio server /data --console-address ":9001"

# 2. 创建桶
mc alias set local http://localhost:9000 admin admin123
mc mb local/lakehouse
mc mb local/lakehouse-warehouse

# 3. Spark 配置（spark-defaults.conf 关键项）
spark.sql.catalog.lh=org.apache.iceberg.spark.SparkCatalog
spark.sql.catalog.lh.type=hadoop
spark.sql.catalog.lh.warehouse=s3a://lakehouse-warehouse/
spark.hadoop.fs.s3a.endpoint=http://localhost:9000
spark.hadoop.fs.s3a.access.key=admin
spark.hadoop.fs.s3a.secret.key=admin123
spark.hadoop.fs.s3a.path.style.access=true
spark.sql.files.maxPartitionBytes=134217728
spark.sql.files.openCostInBytes=4194304

建表并写入数据后，重点观察三个参数：maxPartitionBytes 控制单分区读取上限，默认 128 MB；openCostInBytes 影响小文件合并策略；spark.sql.shuffle.partitions 影响写入并行度。实验时可先写入 200 个小文件（每个约 1 MB），执行 SELECT count(*) FROM lh.db.t，记录 LIST 耗时和任务数；再执行 Iceberg 的 rewrite_data_files 合并为 128 MB 文件，重复同一查询。合理预期是：合并后文件数下降、LIST 耗时减少、扫描吞吐上升，但合并本身会消耗一次写放大。若合并后延迟没有改善，说明瓶颈不在文件数，而可能在网络带宽或 S3 端点并发限制。

实验参数说明：上述 2 TB/天、128 MB、200 个小文件均为教学示例，用于说明调优方向，不代表任何生产环境的实测结果。实际部署时应以自身集群的监控数据为准。

性能调优的四个抓手

文件大小与数量：目标文件大小通常设为 128 MB～512 MB，小文件过多时优先合并，而不是盲目增加并行度。
分区与裁剪：按日期或业务键分区，避免全表 LIST；Iceberg 的隐藏分区和分区演化可减少历史数据重写。
缓存与本地盘：对热分区使用本地 NVMe 缓存或 Alluxio 类缓存层，可显著降低重复查询延迟，但需设置合理的过期和容量上限。
并发与限流：对象存储对单桶请求速率有限制，写入时控制并发数，必要时使用多桶或前缀打散。

结果判断与常见误区

判断存储层是否调优到位，不能只看单次查询耗时。建议固定一个基准查询集，记录调优前后的扫描字节数、任务数、P95 延迟和对象存储请求数。若扫描字节数不变而延迟下降，说明是缓存或并行度改善；若扫描字节数下降，说明分区裁剪或文件合并生效。常见误区包括：把本地盘当持久层导致数据丢失；在对象存储上频繁执行重命名操作；以及只增加 Spark 并行度却不解决小文件问题，结果任务数暴涨、调度开销反而更大。存储层选型没有唯一答案，关键是让存储特性与访问模式匹配，并用可观测指标验证每一次调整。