4、存储层运维（下）：对象存储（S3/MinIO）对接、数据分层（热/温/冷）、存储成本优化、生命周期管理

存储层是 Lakehouse 的底盘。底盘不稳，上层再好的引擎也白搭。

这一讲我们聚焦对象存储的实战对接、数据分层策略、成本控制手段，以及自动化的生命周期管理。说白了，就是怎么让你的数据存得稳、查得快、还省钱。

4.1 对象存储对接：S3 与 MinIO 的实战要点

Lakehouse 的存储底座，现在基本就是对象存储的天下了。公有云用 S3，私有化部署用 MinIO 或 Ceph。我个人的习惯是，不管底层是什么，统一用 S3 兼容接口去对接，这样上层引擎（Spark、Trino、Flink）的配置可以复用。

4.1.1 S3 对接的关键配置

对接 S3 时，很多人只配了 access key 和 secret key 就跑。嗯，这里要注意，生产环境远远不够。

spark.hadoop.fs.s3a.impl=org.apache.hadoop.fs.s3a.S3AFileSystem
spark.hadoop.fs.s3a.access.key=YOUR_ACCESS_KEY
spark.hadoop.fs.s3a.secret.key=YOUR_SECRET_KEY
spark.hadoop.fs.s3a.endpoint=https://s3.amazonaws.com
spark.hadoop.fs.s3a.path.style.access=true
spark.hadoop.fs.s3a.connection.maximum=100
spark.hadoop.fs.s3a.connection.timeout=5000
spark.hadoop.fs.s3a.attempts.maximum=10
spark.hadoop.fs.s3a.threads.max=20

我曾经遇到过一个线上事故：ETL 任务在高峰期频繁报错 Timeout waiting for connection from pool。查了半天，发现是连接池最大连接数设成了默认的 15，根本扛不住并发。调大到 100 后，问题解决。

4.1.2 MinIO 部署与对接

私有化场景下，MinIO 是我的首选。它轻量、兼容 S3 API、性能也不错。部署时我建议用纠删码模式，而不是简单的副本模式。

为什么？你想想看，纠删码可以在相同的存储利用率下提供更高的数据可靠性。比如 16 个盘，设置 EC:8+4，允许同时坏 4 个盘，而存储利用率还有 66%。副本模式要达到同样的可靠性，得 3 副本，利用率只有 33%。

对接 MinIO 的配置和 S3 几乎一样，只需要改 endpoint 地址：

spark.hadoop.fs.s3a.endpoint=http://minio-cluster:9000
spark.hadoop.fs.s3a.path.style.access=true
spark.hadoop.fs.s3a.connection.ssl.enabled=false  # 内部网络可关闭 SSL

4.2 数据分层：热/温/冷 的划分策略

数据不是越热越好，也不是越冷越好。关键是让合适的数据待在合适的存储上。

我一般把数据分为三层：

分层不是一刀切。我习惯用「最后访问时间 + 数据时效性」两个维度来动态判断。举个例子，一张订单表，最近 7 天的订单是热数据，7-30 天的订单是温数据，超过 30 天的订单自动转为冷数据。

你看，光靠分层，成本就能砍一半。这还没算查询性能的提升——热数据在 SSD 上，查询速度能快 3-5 倍。

4.3 存储成本优化：从细节里抠钱

成本优化不是一锤子买卖，而是持续的过程。我总结了几个「抠钱」的点：

4.3.1 文件大小与压缩

小文件是 Lakehouse 的癌症。一个 1KB 的文件和 1GB 的文件，元数据开销几乎一样。但查询 100 万个小文件，光打开文件就要花几分钟。

我建议：

• 写入时控制文件大小在 128MB ~ 512MB 之间
• 使用 Parquet + Zstd 压缩，压缩比高，解压速度快
• 定期运行 OPTIMIZE 或 COMPACT 合并小文件

-- Delta Lake 合并小文件
OPTIMIZE my_table
WHERE date >= '2024-01-01'
ZORDER BY (user_id)

-- Iceberg 合并
CALL catalog.system.rewrite_data_files(
  table => 'my_table',
  options => map('target-file-size-bytes', '268435456')
)

4.3.2 存储类型选择

公有云对象存储通常有多个存储类。以 AWS S3 为例：

我的经验是：不要手动去选存储类，而是用生命周期策略自动转换。人容易忘，机器不会。

4.3.3 删除无用数据

这个听起来简单，但做起来最难。很多团队「不敢删」，结果存储成本越来越高。

我建议建立数据淘汰机制：

• 临时表超过 7 天自动清理
• 测试数据超过 30 天自动清理
• 日志数据超过 90 天自动归档到冷存储
• 超过 1 年的数据，除非有合规要求，否则直接删除

4.4 生命周期管理：自动化才是王道

手动管理存储？不存在的。生产环境的数据量，人根本管不过来。生命周期管理就是让机器替你干活。

4.4.1 对象存储的生命周期策略

S3 和 MinIO 都支持生命周期规则。我一般这样配置：

# S3 生命周期规则示例（JSON）
{
  "Rules": [
    {
      "Id": "hot-to-warm",
      "Status": "Enabled",
      "Filter": {
        "Prefix": "data/orders/"
      },
      "Transitions": [
        {
          "Days": 7,
          "StorageClass": "GLACIER_IR"
        }
      ]
    },
    {
      "Id": "warm-to-cold",
      "Status": "Enabled",
      "Filter": {
        "Prefix": "data/orders/"
      },
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "DEEP_ARCHIVE"
        }
      ]
    },
    {
      "Id": "expire-old-data",
      "Status": "Enabled",
      "Filter": {
        "Prefix": "data/orders/"
      },
      "Expiration": {
        "Days": 365
      }
    }
  ]
}

你看，一条规则搞定热→温→冷→删除的全流程。设置好之后，基本不用管。

4.4.2 表级别的生命周期管理

对象存储的规则是文件级别的。但 Lakehouse 还需要表级别的管理。比如 Iceberg 的 expire_snapshots 和 remove_orphan_files。

我习惯写一个定时任务，每天凌晨跑：

-- Iceberg 清理历史快照（保留最近 7 天）
CALL catalog.system.expire_snapshots(
  table => 'my_table',
  older_than => TIMESTAMP '2024-01-01 00:00:00',
  retain_last => 7
)

-- 清理孤儿文件
CALL catalog.system.remove_orphan_files(
  table => 'my_table',
  older_than => TIMESTAMP '2024-01-01 00:00:00'
)

4.5 知识体系总览

下面这张图，把本章的核心逻辑串起来了。你可以把它当作运维时的「地图」。

这张图从对象存储对接开始，到数据分层，再到成本优化，最后落到生命周期管理。每一步都是环环相扣的。你不需要一次性全部做完，但心里要有这张图，知道下一步该往哪走。