title: HDFS、Ceph、对象存储到底怎么选一次把冷数据存贵了 3 倍的选型复盘tags: HDFS, Ceph, 对象存储, 存储选型, 分布式存储description: 从我们 200TB 日志存对象存储月账单翻车出发拆解 HDFS、Ceph、对象存储三种方案的读写模型、成本结构和适用场景给出按数据温度选型的判断框架。我们团队曾负责一个日志归档平台每天新增 600GB 日志一年就是 200TB 出头。最开始图省事全量扔进云对象存储结果第一个月账单出来存储费 请求费GET/PUT/List加一块比我们预估的贵了 3 倍。那次之后我把三类存储的账从头算了一遍。这篇文章不教你搭集群只讲什么时候该用哪个、别被什么坑。先立一个基调存储选型的核心不是性能谁强而是你的数据温度是什么。热数据频繁随机读、温数据偶尔读、冷数据几乎不读只合规留存对应的最优解是三个完全不同的东西。HDFS为大文件、批处理而生不是给小文件用的HDFS 的设计假设很明确一次写入、多次读取、文件很大默认块 128MB/256MB、吞吐优先。它把文件切成 block默认 3 副本散在不同机架。// 用 Hadoop FileSystem API 写 HDFS注意这是流式追加写不是随机写 Configuration conf new Configuration(); conf.set(fs.defaultFS, hdfs://nn-1:9000); FileSystem fs FileSystem.get(conf); // 1. 打开一个输出流HDFS 会在后台切块、流水复制到 3 个 DataNode try (FSDataOutputStream out fs.create(new Path(/logs/2026/07/31/app.log))) { out.write(bytes); // 2. 只要顺序写吞吐极高单流能跑满磁盘 } // 3. 读也是流式不支持随机 seek 之外的改写append 受限不支持覆盖中间内容 try (FSDataInputStream in fs.open(new Path(/logs/2026/07/31/app.log))) { in.seek(1024); // 只支持定位读不支持改 in.read(buf); }逐行看第 6 行fs.create背后是 NameNode 选块 客户端直连 DataNode 流水线复制所以顺序写吞吐量极高但每个文件都要先去 NameNode 申请元数据。这就是 HDFS 最大的雷——小文件灾难如果你往 HDFS 里塞 1 亿个 1KB 的小文件NameNode 的内存会被 block 元数据每个约 150 字节对象 引用撑爆。我们早期把应用产生的百万级小日志直接写 HDFSNameNode 堆内存 64G 用了不到两周就 Full GC 到卡死。我的判断HDFS 适合大文件 离线分析Spark/Hive的场景。如果你是海量小文件、或者需要低延迟随机读HDFS 是错的。对象存储无限扩展、按量付费但请求费会咬人对象存储S3 / OSS / MinIO的本质是KV 不可变对象用 HTTP 接口读写扁平命名空间靠 key 前缀模拟目录。它几乎无限扩展运维成本极低。// 用 AWS S3 SDK 上传注意分片上传对大文件是必须的 AmazonS3 s3 AmazonS3ClientBuilder.standard() .withRegion(Regions.CN_NORTH_1).build(); // 1. 小文件直接 putObject但超过 100MB 强烈建议用分片上传 UploadPartRequest part new UploadPartRequest() .withBucketName(logs-archive) .withKey(2026/07/31/app.log) .withUploadId(uploadId) .withPartNumber(i) .withPartSize(5 * 1024 * 1024) // 2. 每片 5MB这是 S3 分片最小单位 .withInputStream(partStream); s3.uploadPart(part); // 3. 冷数据记得转存储类别标准 - 低频 - 归档价格能差 5 倍以上 s3.setObjectStorageClass(logs-archive, 2026/07/31/app.log, StorageClass.DeepArchive);第 13 行是我们翻车的关键点对象存储的存储费其实不贵贵的是请求费和流量费。我们那 200TB 日志每天全量扫描一遍做合规校验产生上亿次 GET 请求请求费比存储费还高。后来我们对半年前的数据直接转DeepArchive深度归档读取延迟从毫秒变小时级但存储单价从 0.12 元/GB/月降到 0.02 元/GB/月加上把每日全量扫描改成按需检索账单直接砍到三分之一。另一个坑对象存储是最终一致性大多数厂商的跨区域复制如果你写入后立刻读可能读不到。我们的日志检索服务曾经因为刚写进去查不到被误判为丢数据其实是复制延迟。热路径上别依赖对象存储的强一致。Ceph能打能扛但运维是个无底洞Ceph 用 RADOS 做统一存储底座上层可以跑对象RGW兼容 S3、块RBD、文件CephFS。它的核心是 CRUSH 算法——用确定性哈希算出对象该放哪个 OSD不需要中心元数据节点所以理论上能扩到几千个节点。// 通过 S3 兼容接口访问 Ceph RGW客户端代码和访问公有云对象存储完全一致 Bean public AmazonS3 cephS3() { // 1. Ceph RGW 暴露的是 S3 兼容端点所以直接用 AWS SDK 就行 return AmazonS3ClientBuilder.standard() .withEndpointConfiguration(new EndpointConfiguration( https://ceph-rgw.internal, Regions.CN_NORTH_1.name())) .withPathStyleAccessEnabled(true) // 2. Ceph 用 path-style不是 virtual-hosted .withCredentials(new AWSStaticCredentialsProvider( new BasicAWSCredentials(access-key, secret-key))) .build(); }第 6 行withPathStyleAccessEnabled(true)是接 Ceph 必踩的坑AWS 公有云推荐 virtual-hosted 风格但自建 Ceph RGW 默认只认真实 path-style不设这个所有请求 400。Ceph 的好处是一套存储三种接口但代价是你要自己管 MON/OSD/MDS 的故障、扩容时的数据再平衡、PG 数量规划。我从不建议少于 5 人专职运维的团队自建 Ceph——它出问题时的排查成本远超省下的云账单。我们的踩坑把温数据当冷数据存又当热数据读前面说的 3 倍账单根因是我们对数据温度的误判。我们把最近 7 天要频繁检索排障的日志和一年以上只合规留存的日志无差别地全放标准对象存储还要每天扫一遍。等于用最贵的形态存了最不需要频繁访问的数据又做了最费请求的操作。复盘后我们定了一套分层热7 天内放 Elasticsearch方便检索排障贵但值。温7 天–90 天放标准对象存储按需 GET。冷90 天以上转深度归档 抽稀索引几乎不读只留合规。一张表看清三者的真实边界为了让你少返工我把三类存储在四个关键维度上直接拉平对比而不是泛泛说各有优劣维度HDFSCeph (RADOS)对象存储最佳文件大小大文件100MB任意但小文件 PG 压力大任意海量小文件有元数据开销一致性模型单写强一致强一致副本/纠删码跨区最终一致单区强一致主要成本结构机器 运维人力运维人力极高存储费 请求费 流量费典型适用场景离线分析Spark/Hive内网自建统一存储池备份归档、静态资源、冷数据这张表是我踩完坑之后的浓缩。注意主要成本结构那一行HDFS 和 Ceph 的成本大头是人对象存储的成本大头是账单。如果你的团队养不起专职存储运维对象存储哪怕是自建的 MinIO 轻量版几乎是你唯一轻松的选择。用生命周期规则自动降冷别靠人记对象存储最香的能力是生命周期规则——你可以声明某前缀的文件 30 天后转低频、180 天后转归档、365 天后删除全程不用写一行业务逻辑。我们当初要是早用上这个账单翻车那次根本不会发生。// 用 AWS S3 SDK 给 bucket 配置生命周期自动把冷数据降冷 BucketLifecycleConfiguration config new BucketLifecycleConfiguration() .withRules(new BucketLifecycleConfiguration.Rule() .withId(archive-logs) .withFilter(new LifecycleFilter( new LifecyclePrefixPredicate(logs/))) // 1. 只对 logs/ 前缀生效 .withTransitions(new Transition() .withDays(30).withStorageClass(StorageClass.StandardInfrequentAccess)) .withTransitions(new Transition() .withDays(180).withStorageClass(StorageClass.DeepArchive)) // 2. 180天进深度归档 .withExpirationInDays(365) // 3. 一年合规留存后自动删除 .withStatus(BucketLifecycleConfiguration.ENABLED)); s3.setBucketLifecycleConfiguration(logs-archive, config);逐行看第 5 行withFilter把规则限定在logs/前缀避免误伤其他数据第 8 行把 180 天以上的日志推到DeepArchive单价直接降到标准存储的六分之一第 10 行withExpirationInDays(365)让过期数据自动消失不用我们写定时清理任务。这套规则上线后我们的归档存储费每月省了 70%因为该冷的数据终于自动冷下来了而不是一直躺在最贵的存储类别里。选型判断框架照着对号入座海量小文件 离线分析HDFS但务必先合并小文件或上 HBase/对象存储替代。别让 NameNode 扛元数据。图片/视频/备份/归档要无限扩展对象存储公有云或 MinIO 自建轻量版。记住算请求费。需要在内网自建、又要对象又要块又要文件Ceph但前提是有人能 7×24 运维它。中小团队、不想养存储专家直接公有云对象存储 生命周期规则自动转冷别碰自建集群。我对存储选型的态度很直白先算账再谈架构。很多人一上来就纠结HDFS 还是 Ceph 性能高但真正决定成本的是这份数据多久读一次、怎么读。把温度分清楚方案自然收敛。思考题如果你的对象存储跨区复制是最终一致而你的业务要求刚上传的文件必须立刻能被另一个区域的系统读到你会怎么补强这一致性缺口
HDFS、Ceph、对象存储到底怎么选：一次把冷数据存贵了 3 倍的选型复盘
title: HDFS、Ceph、对象存储到底怎么选一次把冷数据存贵了 3 倍的选型复盘tags: HDFS, Ceph, 对象存储, 存储选型, 分布式存储description: 从我们 200TB 日志存对象存储月账单翻车出发拆解 HDFS、Ceph、对象存储三种方案的读写模型、成本结构和适用场景给出按数据温度选型的判断框架。我们团队曾负责一个日志归档平台每天新增 600GB 日志一年就是 200TB 出头。最开始图省事全量扔进云对象存储结果第一个月账单出来存储费 请求费GET/PUT/List加一块比我们预估的贵了 3 倍。那次之后我把三类存储的账从头算了一遍。这篇文章不教你搭集群只讲什么时候该用哪个、别被什么坑。先立一个基调存储选型的核心不是性能谁强而是你的数据温度是什么。热数据频繁随机读、温数据偶尔读、冷数据几乎不读只合规留存对应的最优解是三个完全不同的东西。HDFS为大文件、批处理而生不是给小文件用的HDFS 的设计假设很明确一次写入、多次读取、文件很大默认块 128MB/256MB、吞吐优先。它把文件切成 block默认 3 副本散在不同机架。// 用 Hadoop FileSystem API 写 HDFS注意这是流式追加写不是随机写 Configuration conf new Configuration(); conf.set(fs.defaultFS, hdfs://nn-1:9000); FileSystem fs FileSystem.get(conf); // 1. 打开一个输出流HDFS 会在后台切块、流水复制到 3 个 DataNode try (FSDataOutputStream out fs.create(new Path(/logs/2026/07/31/app.log))) { out.write(bytes); // 2. 只要顺序写吞吐极高单流能跑满磁盘 } // 3. 读也是流式不支持随机 seek 之外的改写append 受限不支持覆盖中间内容 try (FSDataInputStream in fs.open(new Path(/logs/2026/07/31/app.log))) { in.seek(1024); // 只支持定位读不支持改 in.read(buf); }逐行看第 6 行fs.create背后是 NameNode 选块 客户端直连 DataNode 流水线复制所以顺序写吞吐量极高但每个文件都要先去 NameNode 申请元数据。这就是 HDFS 最大的雷——小文件灾难如果你往 HDFS 里塞 1 亿个 1KB 的小文件NameNode 的内存会被 block 元数据每个约 150 字节对象 引用撑爆。我们早期把应用产生的百万级小日志直接写 HDFSNameNode 堆内存 64G 用了不到两周就 Full GC 到卡死。我的判断HDFS 适合大文件 离线分析Spark/Hive的场景。如果你是海量小文件、或者需要低延迟随机读HDFS 是错的。对象存储无限扩展、按量付费但请求费会咬人对象存储S3 / OSS / MinIO的本质是KV 不可变对象用 HTTP 接口读写扁平命名空间靠 key 前缀模拟目录。它几乎无限扩展运维成本极低。// 用 AWS S3 SDK 上传注意分片上传对大文件是必须的 AmazonS3 s3 AmazonS3ClientBuilder.standard() .withRegion(Regions.CN_NORTH_1).build(); // 1. 小文件直接 putObject但超过 100MB 强烈建议用分片上传 UploadPartRequest part new UploadPartRequest() .withBucketName(logs-archive) .withKey(2026/07/31/app.log) .withUploadId(uploadId) .withPartNumber(i) .withPartSize(5 * 1024 * 1024) // 2. 每片 5MB这是 S3 分片最小单位 .withInputStream(partStream); s3.uploadPart(part); // 3. 冷数据记得转存储类别标准 - 低频 - 归档价格能差 5 倍以上 s3.setObjectStorageClass(logs-archive, 2026/07/31/app.log, StorageClass.DeepArchive);第 13 行是我们翻车的关键点对象存储的存储费其实不贵贵的是请求费和流量费。我们那 200TB 日志每天全量扫描一遍做合规校验产生上亿次 GET 请求请求费比存储费还高。后来我们对半年前的数据直接转DeepArchive深度归档读取延迟从毫秒变小时级但存储单价从 0.12 元/GB/月降到 0.02 元/GB/月加上把每日全量扫描改成按需检索账单直接砍到三分之一。另一个坑对象存储是最终一致性大多数厂商的跨区域复制如果你写入后立刻读可能读不到。我们的日志检索服务曾经因为刚写进去查不到被误判为丢数据其实是复制延迟。热路径上别依赖对象存储的强一致。Ceph能打能扛但运维是个无底洞Ceph 用 RADOS 做统一存储底座上层可以跑对象RGW兼容 S3、块RBD、文件CephFS。它的核心是 CRUSH 算法——用确定性哈希算出对象该放哪个 OSD不需要中心元数据节点所以理论上能扩到几千个节点。// 通过 S3 兼容接口访问 Ceph RGW客户端代码和访问公有云对象存储完全一致 Bean public AmazonS3 cephS3() { // 1. Ceph RGW 暴露的是 S3 兼容端点所以直接用 AWS SDK 就行 return AmazonS3ClientBuilder.standard() .withEndpointConfiguration(new EndpointConfiguration( https://ceph-rgw.internal, Regions.CN_NORTH_1.name())) .withPathStyleAccessEnabled(true) // 2. Ceph 用 path-style不是 virtual-hosted .withCredentials(new AWSStaticCredentialsProvider( new BasicAWSCredentials(access-key, secret-key))) .build(); }第 6 行withPathStyleAccessEnabled(true)是接 Ceph 必踩的坑AWS 公有云推荐 virtual-hosted 风格但自建 Ceph RGW 默认只认真实 path-style不设这个所有请求 400。Ceph 的好处是一套存储三种接口但代价是你要自己管 MON/OSD/MDS 的故障、扩容时的数据再平衡、PG 数量规划。我从不建议少于 5 人专职运维的团队自建 Ceph——它出问题时的排查成本远超省下的云账单。我们的踩坑把温数据当冷数据存又当热数据读前面说的 3 倍账单根因是我们对数据温度的误判。我们把最近 7 天要频繁检索排障的日志和一年以上只合规留存的日志无差别地全放标准对象存储还要每天扫一遍。等于用最贵的形态存了最不需要频繁访问的数据又做了最费请求的操作。复盘后我们定了一套分层热7 天内放 Elasticsearch方便检索排障贵但值。温7 天–90 天放标准对象存储按需 GET。冷90 天以上转深度归档 抽稀索引几乎不读只留合规。一张表看清三者的真实边界为了让你少返工我把三类存储在四个关键维度上直接拉平对比而不是泛泛说各有优劣维度HDFSCeph (RADOS)对象存储最佳文件大小大文件100MB任意但小文件 PG 压力大任意海量小文件有元数据开销一致性模型单写强一致强一致副本/纠删码跨区最终一致单区强一致主要成本结构机器 运维人力运维人力极高存储费 请求费 流量费典型适用场景离线分析Spark/Hive内网自建统一存储池备份归档、静态资源、冷数据这张表是我踩完坑之后的浓缩。注意主要成本结构那一行HDFS 和 Ceph 的成本大头是人对象存储的成本大头是账单。如果你的团队养不起专职存储运维对象存储哪怕是自建的 MinIO 轻量版几乎是你唯一轻松的选择。用生命周期规则自动降冷别靠人记对象存储最香的能力是生命周期规则——你可以声明某前缀的文件 30 天后转低频、180 天后转归档、365 天后删除全程不用写一行业务逻辑。我们当初要是早用上这个账单翻车那次根本不会发生。// 用 AWS S3 SDK 给 bucket 配置生命周期自动把冷数据降冷 BucketLifecycleConfiguration config new BucketLifecycleConfiguration() .withRules(new BucketLifecycleConfiguration.Rule() .withId(archive-logs) .withFilter(new LifecycleFilter( new LifecyclePrefixPredicate(logs/))) // 1. 只对 logs/ 前缀生效 .withTransitions(new Transition() .withDays(30).withStorageClass(StorageClass.StandardInfrequentAccess)) .withTransitions(new Transition() .withDays(180).withStorageClass(StorageClass.DeepArchive)) // 2. 180天进深度归档 .withExpirationInDays(365) // 3. 一年合规留存后自动删除 .withStatus(BucketLifecycleConfiguration.ENABLED)); s3.setBucketLifecycleConfiguration(logs-archive, config);逐行看第 5 行withFilter把规则限定在logs/前缀避免误伤其他数据第 8 行把 180 天以上的日志推到DeepArchive单价直接降到标准存储的六分之一第 10 行withExpirationInDays(365)让过期数据自动消失不用我们写定时清理任务。这套规则上线后我们的归档存储费每月省了 70%因为该冷的数据终于自动冷下来了而不是一直躺在最贵的存储类别里。选型判断框架照着对号入座海量小文件 离线分析HDFS但务必先合并小文件或上 HBase/对象存储替代。别让 NameNode 扛元数据。图片/视频/备份/归档要无限扩展对象存储公有云或 MinIO 自建轻量版。记住算请求费。需要在内网自建、又要对象又要块又要文件Ceph但前提是有人能 7×24 运维它。中小团队、不想养存储专家直接公有云对象存储 生命周期规则自动转冷别碰自建集群。我对存储选型的态度很直白先算账再谈架构。很多人一上来就纠结HDFS 还是 Ceph 性能高但真正决定成本的是这份数据多久读一次、怎么读。把温度分清楚方案自然收敛。思考题如果你的对象存储跨区复制是最终一致而你的业务要求刚上传的文件必须立刻能被另一个区域的系统读到你会怎么补强这一致性缺口
