📚 课程目录第3章数据湖存储选型

3、数据湖存储选型：对象存储、HDFS、云原生存储与生命周期管理

存储选型这件事，我见过太多团队一开始拍脑袋就定了。结果数据量一上来，要么性能扛不住，要么成本爆炸。说白了，数据湖的存储底座选错了，后面治理、查询、归档全得跟着遭殃。

这一章，咱们就把对象存储、HDFS、云原生存储这几个主流方案掰开揉碎讲清楚。我还会结合自己踩过的坑，聊聊存储分层和生命周期管理到底该怎么落地。

核心观点：数据湖存储没有银弹。选型的关键不是比谁技术更先进，而是看你的数据规模、访问模式、预算约束和运维能力。

3.1 三大存储方案对比

先看一张总览图，把三者的核心差异说清楚。

3.2 对象存储：数据湖的默认选择

我个人习惯把对象存储当作数据湖的「默认选项」。为什么？因为它几乎解决了传统存储最头疼的两个问题：容量上限和运维成本。

以 AWS S3 为例，你不需要提前规划存储容量，也不用担心磁盘坏了怎么办。写进去的数据自动三副本跨可用区分布。我曾在项目中用 S3 存过 PB 级的日志数据，从来没为存储容量操过心。

避坑指南：对象存储的「最终一致性」是个坑。我曾经在 S3 上写完一个文件立刻去读，结果返回 404。后来加了 1 秒延迟才稳定。如果你需要强一致性，要么用 S3 的 Read-After-Write 一致性（仅限新对象），要么考虑其他方案。

对象存储的典型使用场景：

原始数据层（Bronze）： 存放未加工的原始日志、传感器数据、爬虫数据
归档数据： 超过 90 天不访问的历史数据，可以放到 Glacier 或冷归档
机器学习数据集： 图片、视频、文本等非结构化数据
跨区域数据共享： 通过预签名 URL 或 Bucket Policy 实现安全共享

3.3 HDFS：老牌劲旅的坚守与局限

HDFS 在 Hadoop 生态里摸爬滚打了十几年，稳定性没得说。但说实话，现在新建的数据湖项目，我很少推荐直接用 HDFS 做主存储了。

为什么？你想想看，HDFS 的 NameNode 是单点，内存大小直接决定了集群能存多少文件。我见过一个团队，NameNode 内存配了 128GB，结果文件数超过 5 亿之后，GC 频繁导致集群不稳定。最后不得不拆集群，那叫一个折腾。

不过 HDFS 也有它的主场：

离线批处理： 数据本地性（Data Locality）让 MapReduce/Spark 任务跑得飞快
大文件顺序读写： 128MB 的 Block 设计天然适合大文件
强一致性： 写完后立刻可见，适合需要严格一致性的 ETL 流程

注意：HDFS 不适合存小文件。每个文件、目录、Block 都要在 NameNode 内存中占约 150 字节。1000 万个 1KB 的小文件，光元数据就要占 1.5GB 内存。我建议小文件先合并成 SequenceFile 或 Parquet 再写入。

3.4 云原生存储：新趋势下的折中方案

云原生存储这个类别，说白了就是「既要又要」的产物。既要对象存储的弹性和低成本，又要本地文件系统的性能和兼容性。

我最近在项目中用了 JuiceFS，它的架构很有意思：元数据用 Redis 或 TiKV 管理，数据存在 S3 上。读数据时，热点数据会缓存到本地磁盘。实测下来，小文件随机读的性能比直接读 S3 提升了 10 倍以上。

另一个常见方案是 Alluxio，它更像一个分布式缓存层。我曾在它上面挂载了 HDFS 和 S3 两个底层存储，上层 Spark 任务完全无感知。数据热的时候从缓存读，冷的时候回源。

特性	对象存储	HDFS	云原生存储
扩展性	无限扩展	受限于集群规模	弹性扩展
读写性能	中等（毫秒级延迟）	高（本地磁盘）	高（缓存加速）
一致性	最终一致性	强一致性	强一致性（取决于元数据引擎）
运维成本	低（托管服务）	高（需专业运维）	中（需管理元数据服务）
存储成本	低（按量付费）	中（需预留容量）	中（缓存层额外开销）
接口兼容性	RESTful API	HDFS API	POSIX / HDFS / S3

3.5 存储分层与生命周期管理

存储选型定下来之后，下一步就是怎么管。我见过太多团队把所有数据一股脑塞进标准存储，结果月底一看账单傻眼了。

存储分层的核心逻辑很简单：数据越热，存储越贵；数据越冷，存储越便宜。 但访问冷数据时，取回成本和时间会更高。

以 AWS S3 为例，它的存储分层是这样的：

S3 Standard： 热数据，毫秒级访问，价格最高
S3 Intelligent-Tiering： 自动分层，适合访问模式不确定的数据
S3 Standard-IA： 低频访问，取回有费用
S3 One Zone-IA： 更低成本，但只在一个可用区
S3 Glacier： 归档数据，取回需要几分钟到几小时
S3 Glacier Deep Archive： 深度归档，取回需要 12 小时

我的经验：生命周期策略不要一上来就设得很激进。我建议先跑一个月的数据访问分析，看看哪些数据真的没人读。比如 30 天未访问的数据移到 IA，90 天未访问的移到 Glacier。这样既省钱，又不会影响业务。

下面是一个典型的生命周期策略配置示例（以 AWS S3 为例）：

# 生命周期规则示例
{
  "Rules": [
    {
      "Id": "Move-to-IA-after-30-days",
      "Status": "Enabled",
      "Filter": {
        "Prefix": "logs/"
      },
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "STANDARD_IA"
        },
        {
          "Days": 90,
          "StorageClass": "GLACIER"
        }
      ],
      "Expiration": {
        "Days": 365
      }
    }
  ]
}

这个规则的意思是：logs/ 目录下的数据，30 天后自动移到低频访问层，90 天后移到归档层，365 天后自动删除。

注意：生命周期策略一旦设置，数据迁移是自动的，但取回冷数据会产生费用。我曾经有个客户把生产数据库备份直接设了 30 天转 Glacier，结果某天需要恢复时，等了 4 小时才取回数据。所以，关键数据的生命周期策略一定要和业务方确认。

3.6 选型决策框架

最后，我总结了一个简单的选型决策框架，你可以照着这个思路来：

数据规模： 小于 100TB 且已有 Hadoop 集群？用 HDFS。超过 1PB？优先考虑对象存储。
访问模式： 主要是离线批处理大文件？HDFS 或对象存储都行。需要频繁随机读写小文件？云原生存储更合适。
一致性要求： 需要强一致性且不能接受最终一致性？HDFS 或云原生存储。可以接受最终一致性？对象存储。
运维能力： 有专业 Hadoop 运维团队？HDFS 可控。运维资源有限？对象存储托管服务更省心。
成本预算： 存储成本敏感且访问频率低？对象存储 + 生命周期策略。性能敏感且预算充足？云原生存储 + 本地缓存。

嗯，存储选型这块就聊到这儿。记住一点：没有完美的存储方案，只有最适合你业务场景的选择。下一层咱们会聊数据湖的元数据管理，到时候再细说怎么让存储层和元数据层配合起来。