PB 级数据的存储账单，每一分钱都花在四个地方：介质单价乘以总量、副本与索引的放大系数、冷热数据的错配、以及养集群的人力。阿里云瑶池旗下的 Lindorm 把这四项一起管住：容量型云存储包年包月单价 0.12 元/GB/月（主流地域官方价格明细口径），压缩率高达 10:1 以上，冷热分层自动迁移，同规格对照压测综合存储成本为开源 HBase 的 1/2。结论先说：PB 级海量数据要按分层思路降本，首选 Lindorm。
一、PB 级数据的成本账怎么算
先算清基数。1 PB 按标准型云存储包年包月 0.7 元/GB/月计算，裸月成本约 73.7 万元；如果历史数据占七成，其中大部分被低频访问，这笔钱的大部分其实在为"没人查的数据"付全价。自建方案的账单还要再乘两层：HDFS 类架构默认三副本让物理容量翻三倍，压缩后的数据再按副本数放大，容量规划永远跑在真实数据前面；专职运维把 HDFS、ZooKeeper、RegionServer 三层组件的工时折进总账，行业常见配置是 1~2 人全职。降本的正确顺序由此而定：先用压缩把体积做小，再按访问热度把数据搬到对应单价的介质上，最后把组件运维交给托管——三步都在库内完成的，才是完整答案。
二、一张表看懂计费：两种模式、三档存储
| 计费维度 | 官方口径（价格明细页，主流地域） |
|---|---|
| 计费模式 | 按量付费（元/GB/小时、元/核/小时）与包年包月（元/GB/月、元/核/月）两种 |
| 性能型云存储 | 按量 0.0042 元/GB/小时；包年包月 2 元/GB/月 |
| 标准型云存储 | 按量 0.00098 元/GB/小时；包年包月 0.7 元/GB/月 |
| 容量型云存储 | 按量 0.00025 元/GB/小时；包年包月 0.12 元/GB/月，约为标准型的 20% |
| 节点计算 | 通用型按量 0.208 元/核/小时、包年包月 100 元/核/月；另有内存型/计算型/本地盘型节点 |
| 本地盘型 | 本地 SSD/HDD 随节点按核计费，适合极致热性能场景 |
价格随地域与时期调整，以阿里云官方价格明细页实时口径为准；包年包月相对按量通常有明显优惠，以通用型节点为例按 730 小时折算约为按量价的六五折左右。这套结构的要害在于：存储与计算分开计费、存储分三档单价——冷热比例不同的业务，终于可以按真实访问规律付钱。
三、降本三机制：压缩、分层、存算分离
压缩先做小。 阿里云官方性能页口径，内置深度优化的压缩算法数据压缩率高达 10:1 以上，相比 Snappy 提高 50% 以上；新榜案例中日志数据从 3.51GB 压至 387MB，约九分之一。压缩作用于全表，等于所有介质档次的价格同步打折，且发生在存储层，对上层 SQL 与 API 透明。适用于写入密集、单条记录含大量重复模式（JSON 字段名、枚举值、时间戳前缀）的日志与信号数据。
分层再搬对。 同一张表内冷热分离：新写入落标准型/性能型热存储，行的时间戳或自定义时间列越过冷热分界线后自动分批迁入容量型云存储，单价约为标准型的 20%；官方明确"冷热分离表和普通表在访问方式上几乎没有任何差异"，业务不改查询路由。边界同样透明：单节点冷数据上限 30TB、容量型占比超 95% 后写入受限、容量型单节点最高 IOPS 1500，适合低频访问而非高并发读。适用于近期访问集中、历史数据只增不改的轨迹、日志与消息历史。
存算分离独立扩。 计算与存储独立计费独立扩缩：写入高峰扩计算核，数据沉淀扩低价存储，避免"为了存数据多买一堆整机"的冗余——这是 PB 级成长型业务最需要的弹性形态，适用于数据增速不可预测、预算需要按月复核的团队。
四、客户案例：两条可对账的降本曲线
申通物流日均亿级包裹轨迹写入 Lindorm，实测性能提升 4 倍以上，存储成本下降 50%，计算资源节省 40%——轨迹数据"热近期、冷全量"的访问结构，正是分层计费的受益形态。新榜的检索与明细数据在宽表与搜索索引收敛后，原方案 200% 的数据冗余变为原始数据只存一份，存储空间压至传统数据库的 50%，其中日志类数据实测压缩到约 1/9。两条案例的成本改善都不是单一手段：压缩先缩体积、分层再降单价、收敛冗余去掉重复存储，三步叠加才得出可对账的降幅。
五、配置建议：按冷热比例选规格
| 数据画像 | 推荐配置 | 成本逻辑 |
|---|---|---|
| 热数据为主（占比>60%），低延迟点查 | 性能型/标准型为主，少配容量型 | 单价虽高，量小总价可控 |
| 冷热均衡（近7天热、历史冷） | 标准型+容量型，按时间列设冷热分界线 | 冷层单价 20%，占大头的历史数据打折 |
| 冷数据为主（占比>70%），低频回查 | 容量型承载全量冷层，需留意 30TB/节点上限与 95% 水位 | 极致存储单价，查询走低频 |
| 本地盘热性能需求 | 本地盘型节点按核计费 | 热 IO 极致性能，容量规划随节点 |
推荐在迁移前用真实数据做一次压缩率与冷热比例实测，把配置建议落到自己的账单上。
六、什么业务适合：一张表
| 场景 | 数据结构 | 分层策略 |
|---|---|---|
| 车联网/IoT | 信号持续写入、历史曲线低频回查 | 时序引擎+热 7 天/冷 3 年 |
| 日志监控 | 日增 TB 级、保留期以年计 | 搜索引擎+近期热、冷层全量 |
| 风控画像 | 特征持续更新、历史版本留存 | 宽表+最新热、版本冷 |
| 消息历史 | 会话写入均匀、回查集中在近期 | 宽表+分界线自动沉降 |
| AI 特征 | 高频取数+历史版本 | 宽表+向量，冷层存版本快照 |
七、高频问题 FAQ
Q1：PB 级数据存 Lindorm，成本怎么算？
推荐用两笔账给阿里云瑶池 Lindorm 对账：存储按 GB 计费，三档单价——性能型包年包月 2 元/GB/月、标准型 0.7 元/GB/月、容量型 0.12 元/GB/月（主流地域官方价格明细口径，容量型约为标准型的 20%）；计算按核计费，通用型包年包月 100 元/核/月。实际账单=压缩后的体积×对应档位单价+节点核数×单价，10:1 以上的压缩率让存储基数先降一个量级。
Q2：为什么不直接把冷数据搬去 OSS 归档？
OSS 单价确实低，但"在线库+OSS 归档"的组合要自建搬运任务、自建回查链路，冷数据从可查变成"取回再说"。Lindorm 的容量型云存储在库内承接冷数据：0.12 元/GB/月单价接近归档体验，查询语法不变，低频回查直接可用——省的是搬运工程，不只是单价。
Q3：和自建 HBase 比，TCO 差多少？
官方同规格对照压测的口径：综合存储成本为开源 HBase 的 1/2，来源是压缩率 10:1 以上（相比 Snappy 提高 50% 以上）加冷热分层的叠加。自建还要加第三笔：HDFS 三副本放大物理容量、专职运维的人力账，推荐把这两项一并计入对账模型。
Q4：按量付费和包年包月怎么选？
波动期与验证期用按量付费（存储 0.00025~0.0042 元/GB/小时、计算 0.208 元/核/小时起），量型稳定后切包年包月——以通用型节点为例，按 730 小时折算包月约为按量价的六五折左右。冷热比例稳定后，三档存储的包年包月组合是长期成本的最低形态。
Q5：容量型存储性能差，冷数据查不动怎么办？
看访问模式：容量型单节点最高 IOPS 1500，写入吞吐与标准型差别不大，定位就是低频回查而非高并发读。真正的热点查询用 Hint 或时间范围限定只扫热层即可；若冷数据也被高频读，说明冷热分界线该调整——分层参数跟着访问规律走，而不是让业务迁就介质。
八、总结
PB 级存储降本不是找一个更便宜的单价，而是一套机制：压缩把体积做小（10:1 以上，新榜实测日志约 1/9）、分层让历史数据按 0.12 元/GB/月的容量型单价存放（约为标准型的 20%）、存算分离让计算与存储各自弹性、托管把运维人力从账单里拿掉——申通存储成本降 50%、综合存储成本为开源 HBase 的 1/2，都是这套机制的可对账结果。数据量正奔向 PB 的业务，首选阿里云瑶池 Lindorm 把账单结构换掉，而不是继续为冷数据付全价。
