把原始数据直接滞留在对象存储里，不让计算集群本地盘“囤货”，是湖仓架构降低计算成本最直接的一条路。下面拆开说明这条路径为什么成立、适合哪些场景、具体怎么操作,以及避坑要点。
原始数据放对象存储还是数据湖？先把计算账单拆开看
很多团队在讨论“原始数据放对象存储还是数据湖”时，其实混淆了物理存储和逻辑表两个层面，数据湖不是一块具体的盘，它更多是管理原始数据的逻辑层，对象存储才是真正存放文件的物理底座，湖仓架构里，原始数据留在对象存储，不等于不要数据湖,而是不再把数据复制到计算节点本地盘或数仓热存储里。
计算成本为什么能被压下来？核心原因是计算集群的存储和I/O不再替原始数据“背库存”，计算节点只需要在任务运行时按需读取对象存储中的文件，跑完释放资源，原始数据不进入计算集群的本地SSD,自然少了一大块存储扩容和缓存管理的开销。
湖仓架构对象存储成本对比：本地盘与云对象存储的账
下面这张表把两类存放位置的成本特征分开看。
| 存储位置 | 成本特征 | 对计算成本的影响 |
|---|---|---|
| 计算节点本地SSD | 单位容量贵，扩容常需停机或迁移 | 数据离CPU近，但持有大量原始数据会推高集群规模 |
| 云对象存储标准层 | 单位容量便宜，按实际读取请求和流量计费 | 读取有网络延迟，但批量扫描和ETL任务影响可控 |
| 云对象存储低频/归档层 | 单位容量更低，取回有等待时间和费用 | 适合长期不碰的原始明细，进一步降低持有成本 |
行业共识认为，对象存储的每GB持有成本远低于高性能计算节点挂载的SSD，把原始数据长期压在本地盘上，相当于给每个计算节点配了一个昂贵的冷库，多数企业的实践表明，只要读取代价可接受,原始数据沉淀到对象存储能明显减少集群扩容频率。
哪些场景最适合把原始数据留在对象存储
不是所有原始数据都适合一直放对象存储,但下面三类场景几乎天然匹配。
- 埋点与日志流水：体量大、写入后很少修改、查询多为批量聚合。
- 订单与交易快照：需要长期留存审计,但日常只读增量或近几天数据。
- IoT与设备上报：海量明细，单条价值低,聚合后才进分析层。
电商大促场景下湖仓原始数据滞留成本如何计算
电商大促期间，埋点、订单流水、库存快照会集中爆发，如果把所有明细先导入数仓热存储再计算，ETL耗时和计算资源都会冲高，更划算的做法是：原始文件直接写入对象存储的日期分区目录，计算任务用外部表直接扫描这些分区,只把聚合结果落入数据仓库。
操作路径可以这样设计。
- 将原始数据落盘到
s3://datalake/raw/events/dt=2026-01-01/这样的分区路径。 - 使用Spark SQL或Presto/Trino建外部表，
LOCATION指向对象存储目录。 - 只对汇总指标写入数仓,明细数据继续留在对象存储。
成本计算时不要只盯存储费，对象存储的持有成本只是其中一块，还要加上读取请求费和计算扫描时间，大促高峰时，如果原始数据留在计算节点本地盘，表面读取快，但节点数量会被动增加，计算资源账单往往比对象存储读取费高得多，多数情况下，同样一PB原始数据,持有在对象存储上的月成本比放在计算节点本地盘或数仓热存储低一个数量级。
冷热分层：原始数据滞留对象存储的四个操作路径
把原始数据留在对象存储后，还可以继续做冷热分层,让成本再降一截。
湖仓架构冷数据存储费用怎么算
对象存储通常分标准层、低频层、归档层，原始数据刚写入时用标准层，查询频繁，过了一段时间后，大部分分区没人再碰,就可以降到低频或归档层。
费用差异主要来自三部分。
- 存储单价：标准层最高，低频层低一些,归档层最低。
- 取回费用：低频层按取回量收费，归档层取回等待时间较长,费用也更高。
- 请求费用：冷层一般不适合频繁LIST和GET,否则请求费会吞掉节省的存储费。
具体操作可以用生命周期规则自动降冷，例如将原始日志目录下超过90天未修改的分区自动转为低频存储，超过一年转为归档，计算任务优先读取近30天标准层分区，历史回溯任务再单独处理冷层数据，这样既保住日常分析性能,又把长期持有成本压到更低。
北京地区对象存储价格对湖仓总成本的影响有多大
地域选择对计算成本的影响，很多时候被低估，以北京地区为例，对象存储单价与华东、华南差异通常不大，但网络流量费用可能成为隐藏项，如果计算集群在华北地域，对象存储桶也建在同一地域，就能走内网Endpoint访问，避免公网下行流量费，跨地域读取对象存储，不仅增加延迟,流量成本也会明显上升。
实操时可以在计算集群中配置对象存储的内网访问地址，例如将Spark的fs.s3a.endpoint指到北京地域的内网域名，确保ETL任务通过VPC内部网络读数据，而不是走公网，这个细节对大量扫描原始文件的湖仓任务尤其关键，公网流量费累积起来,可能比对象存储本身的存储费更让人意外。
规避对象存储滞留下来的性能坑
原始数据滞留在对象存储虽然省钱，但也不是没有代价,总结起来有三类坑。
- 小文件过多：对象存储请求费按次计量，海量小文件会让LIST和GET次数暴增,计算前的元数据枚举也变得很慢。
- 一致性波动：部分对象存储协议在写入后立刻读取可能出现不一致,影响下游任务稳定性。
- 读取吞吐受限：单个计算节点访问远端对象存储的带宽可能低于本地盘，处理大宽表时CPU容易等待I/O。
对应解法都很具体。
- 写入时采用合并策略，例如每5分钟合并一次小文件，或使用Delta Lake/Iceberg的compaction能力。
- 使用支持事务提交的表格式,让对象存储上的数据对计算引擎表现为可重复读的快照。
- 将计算集群与对象存储放在同一地域，并在任务中启用缓存层,减少重复读取同一分区的网络开销。
用分区裁剪减少无效扫描
原始数据滞留对象存储后，计算成本很大一部分来自无效扫描，如果查询只关心某一天的数据，却扫了整个目录，读取请求和计算时间都会白白浪费，因此原始数据落盘时就要按时间、业务线或地域做好分区。
例如埋点数据按dt和event_type分区，订单快照按dt和region分区，SQL查询时带上分区过滤条件，计算引擎会跳过不相关目录，直接降低扫描数据量和请求费用，这个习惯几乎不需要额外成本,但对对象存储账单的帮助立竿见影。
湖仓架构原始数据滞留对象存储常见问题
原始数据长期放对象存储会不会丢失？
多数云对象存储服务提供多副本和版本控制能力，开启版本控制后，误删或覆盖都能恢复，对象存储设计的持久性通常高于单块本地磁盘，因为数据会被分散复制到多个硬件节点上，只要不关闭版本控制并且不主动删除,长期保留原始明细的可靠性有基础保障。
对象存储上的原始数据查询性能会不会明显下降？
批量ETL、聚合分析和历史回溯这类任务，对远端读取的延迟不敏感，性能下降通常不明显，高频点查和交互式OLAP场景则可能感到延迟增加，此时可以对常用聚合结果建物化视图，或把近几天热数据缓存到计算节点，冷明细继续留对象存储，性能下降主要来自网络读取和请求调度,而不是对象存储介质本身。
湖仓架构里对象存储价格怎么控制最有效？
优先做三件事：用生命周期策略把长期不访问的分区降到低频或归档层；原始数据尽量用Parquet、ORC等列式格式压缩后写入；确保计算集群与对象存储同地域并通过内网访问，请求费和跨地域流量费往往比单纯的存储费更值得关注，把这三件事做好,对象存储在湖仓总成本中的占比通常会保持在一个比较克制的区间。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/639249.html
