接手这个项目的时候团队正被一套自建的大数据底座压得喘不过气。HBase 集群 20 多台机器Redis 集群又是 10 多台每天盯着磁盘水位、Region 分区、慢查询和主从延迟运维同学连轴转。我们把所有成本摊开算了一笔账最后做了一个让很多人意外的决定整体迁到瑶池 Lindorm Tair。半年后复盘运维成本确实降了 60%而且不是靠砍机器砍出来的是架构和运维方式本身就变了。这篇就把完整的选型思考、迁移过程和成本拆解写出来给同样在自建大数据架构里挣扎的团队一个参考。这个方案适合谁手上有 HBase、OpenTSDB、Solr 这类存储需求的团队或者还在用自建 Redis 扛缓存但经常被集群运维折磨的团队。不管你是做用户画像、订单查询、IoT 时序数据还是实时推荐链路这套组合的思路都可以直接拿过去用。下面我会尽可能把为什么省钱的逻辑讲透不是简单地说“云上真好”而是把账一笔一笔算清楚。1. 降本先从账算起自建系统到底贵在哪1.1 我们原来那套架构的真实账单项目一开始其实谁都没觉得自建有什么问题。HBase 集群跑了好几年Redis 也从单机一路扩到了集群表面上机器数量是多了点但毕竟“机器是自己的想怎么折腾都行”。可真到了年底做成本盘点的时候账目一摊开才发现完全不是这么回事。先说硬件。HBase 集群 22 台 ECS每台 32C128G 配 4 块 SSD 数据盘Redis 集群 12 台 16C64G 的机器再加上 3 台 Kafka 和若干协调节点月均机器成本大概在 9 万出头。这里还没算块存储费用、快照费用和跨可用区流量费用。我们原本以为机器成本占比最大但算完之后发现真正的大头其实是人。这套系统要维持“能正常对外提供服务”至少需要两个人轮班盯。HBase 的 Region 分裂要管、WAL 堆积要管、热点 Region 要处理、Redis 的主从切换要盯、内存碎片要定期整理、慢查询要捞出来分析。你以为这些是偶尔发生的事实际上每周都有。运维工时折算下来每个月花在这套自建系统上的研发人力成本比机器租金高得多。换句话说硬件成本是看得到的人力成本是一点点磨掉的。1.2 60% 这个数字到底怎么算出来的很多人看到“降低 60%”第一反应是怀疑因为如果只算机器租金降到 60% 几乎不可能。Lindorm 和 Tair 都是托管产品机器成本未必比自建便宜多少有些规格甚至还要贵一点。所以这里必须讲清楚我们核算的是综合运维成本也就是 TCO。综合成本包含四块机器资源成本、人力运维成本、故障损失成本、以及版本升级和扩容带来的隐性改造成本。自建方案里后面三项非常容易被低估。比如一次 Region 热点导致的毛刺可能让线上推荐接口超时率上升到 5%业务方排查一整天最后发现是底层存储的问题。这种隐形成本不摊到存储系统头上你永远觉得它很便宜。我们用 6 个月为周期做对比自建 HBase Redis 全周期成本约 54 万元迁移到 Lindorm Tair 后机器资源月租降到 5.5 万运维人力降到 0.5 个人力故障损失费用几乎归零。算下来周期综合成本约 21 万左右大约降了 61%。这就是 60% 这个数字的出处不是拍脑袋是财务和研发一起对过账的。1.3 为什么选瑶池 Lindorm Tair 而不是别的组合选型的时候其实对比过好几条路。一个是继续用自建 HBase但把机器规格降下来把冷数据转 OSS另一个是 HBase 迁到 LindormRedis 继续自己维护还有一个是彻底用 Lindorm Tair 统一替换。最终选第三条路不是因为它最便宜而是因为它让团队结构具备“减负”的可能。Lindorm 兼容 HBase API这意味着我们已有的读写代码基本不用改。同时它内部做了大量针对云场景的优化比如冷热分离、存储计算分离、自动分区等。而 Tair 兼容 Redis 协议业务侧从 Jedis 切到 Tair 客户端几乎零成本。最关键是两者都是全托管产品日常的扩容、升级、故障切换都不需要人盯着。只要业务代码不动运维工作量自然就降下来了。2. 架构改造的两条主线存储底座与缓存链路2.1 改造前的系统拓扑到底长什么样改造前我们的核心链路大致是这样的业务实时写入消息队列消费端做完清洗后写入 HBase查询链路里热点数据先查 Redis查不到再穿透到 HBase。HBase 同时承担着用户行为明细、订单状态索引、标签服务底层存储Redis 则扛着实时榜单、用户会话、频控计数和部分特征缓存。这个架构本身没有大问题但运维压力一点不比业务代码少。HBase 的 RowKey 设计虽然早年花过心思可随着流量上涨Region 热点还是频繁出现Redis 的内存增长更是让人头疼明明设置了过期时间可内存就是不降。我们不停在加机器、调参数、重启节点之间循环团队戏称自己是“专业数据库保姆”。这套结构最大的问题在于所有底层能力都需要自己维护而我们的核心业务根本不在数据库运维上。与其在存储上不断“填坑”不如把运维复杂度转移到云平台侧让团队重新把精力放回业务架构。2.2 新版架构中 Lindorm 和 Tair 各自承担的角色改造后的架构Lindorm 扮演的是统一数据底座。HBase 原有场景全部迁移到 Lindorm 的宽表模型同时把部分 OpenTSDB 时序场景也一并收编。Lindorm 的原生多模型能力让我们可以在一套存储上同时处理宽表数据和时序数据省掉了一套独立的时序存储集群。Tair 承担的是缓存和加速层。它替掉了原来的自建 Redis 集群业务接口访问路径没变仍然是先查 Tair 再回源 Lindorm。Tair 在兼容 Redis 协议的基础上把持久化、主从切换、内存碎片整理这些事情都托管了。对业务代码来说可能只改了一个客户端配置项但背后省下来的是处理主从切换、内存告警、慢查询的大把时间。Lindorm 和 Tair 之间的数据流转也做了优化。原来查 HBase 是纯走内网现在从 Tair 穿透到 Lindorm 的链路延迟更低因为两者在同一个云网络环境内且底层基础设施做了协同优化。这个感知不强但在高并发下对比数据非常明显。2.3 降本不降性能切换后的真实指标变化担心“运维省了但性能降了”是很正常的顾虑。我们在选型时也有这个担心所以第一批切换的是非核心业务跑了整整两周对比数据。结果发现Lindorm 在读写延迟上相比自建 HBase 不降反升平均读延迟稳定在 2ms 到 5ms写延迟在 3ms 左右P99 从原来的 80ms 降到了 30ms。Tair 的表现同样没有让人失望。在同等 QPS 下Tair 的 P99 延迟比自建 Redis 集群低约 40%而且整个压测过程中没有出现内存碎片暴涨或者主从切换抖动。这个结果其实有迹可循自建 Redis 集群用的是通用 ECS网络和磁盘能力都会相互争抢而 Tair 底层的资源隔离做得更彻底减少了邻居噪声影响。性能没降运维反而降了这种“双赢”在技术选型里不算常见。我们当时就判断这条路走对了。3. 迁移实操从 HBase 和 Redis 平滑切换过来3.1 迁移前必须做好的三件事首先把存量数据全量做一次导出但不要直接全量灌到 Lindorm。先抽几个大表跑一遍 RowKey 分布确认没有明显热点。这个环节非常重要因为 Lindorm 虽然有自动分区能力但 RowKey 设计差的话再强的自动能力也会被浪费。其次梳理清楚业务对存储的访问模式哪些是点查、哪些是范围扫描、哪些是批量写入。不同模式在 Lindorm 上的建表参数完全不一样。我们踩过一个坑有两张表习惯性扫描整表做离线分析迁到 Lindorm 之后扫描超时频繁后来改成用二级索引加条件过滤才解决。第三确认双跑方案。我们采用的方式是业务双写读流量灰度切。也就是说写入时同时写 HBase 和 Lindorm读流量先放 5% 到 Lindorm逐步增加到 100%。这里建议开发一个数据校验任务定时对 HBase 和 Lindorm 里的抽样 key 做一致性比对避免出现数据不齐还浑然不知的情况。3.2 Lindorm 建表与核心参数配置建议Lindorm 兼容 HBase 的 API建表语句和 Habse 基本一致但有些参数建议按云上方式设置。以我们最核心的用户行为明细表为例建表时指定了冷热分离策略热数据保留 7 天超过 7 天的自动转入冷存储。这个配置对成本控制影响极大因为冷存储的价格大约只有热存储的三分之一。分区方面Lindorm 支持按 split keys 预分区也支持后续自动分裂。我们建议核心大表还是手动预分区同时开启自动分裂兜底。预分区数量不要贪多一般按照当前数据量估算确保每个 Region 的数据量在 10GB 左右这样既不会因为 Region 太少导致热点也不会因为 Region 太多增加元数据管理压力。另一个值得说的是 TTL 和压缩。原本 HBase 里我们舍不得开 TTL 的表迁到 Lindorm 后都重新梳理了保留周期。因为 Lindorm 的存储成本低但也不是无限低合理设置 TTL 能进一步压成本。比如订单索引表保留 180 天就够历史数据该过期就过期没必要永久留着。3.3 Tair 接入与缓存链路改造细节Tair 接入过程比 Lindorm 更顺滑因为所有命令都是 Redis 协议的。我们原来用的是 Jedis 连接池切换 Tair 的时候只需要改连接信息和部分参数调整。建议配置方面重点关注两个一个是合理的连接池大小另一个是超时时间。连接池大小别随手写 200 或者 500而是根据实际 QPS 和平均执行时间估算。我们用单次操作平均 0.5ms、单连接可支撑约 2000 QPS 来算客户端实例只需要 20 到 50 个连接就能扛住几万 QPS。连接数开太大反而增加服务端压力甚至引发不必要的 CPU 消耗。超时时间建议区分“连接超时”和“读超时”。连接超时可以设置 500ms读超时根据业务容忍度设置 300ms 到 1s。不要一个值套所有接口一些核心接口的超时设置过大会导致线程池堆积这在排查线上问题时经常被忽略。3.4 切换过程中业务侧要做哪些适配HBase 切 Lindorm 的代码改动量比我们想象中还要小。因为我们用的就是标准 HBase API换掉连接配置之后绝大部分逻辑能直接跑。有几个需要额外处理的点一是 Lindorm 的 SQL 引擎和 HBase 原生 API 是两套体系如果用 Phoenix 的语法要确认版本兼容性二是原来通过协处理器在服务端做的事情需要重构到客户端完成。Tair 方面就更简单了客户端直接把 host 和 password 换成 Tair 的即可。但是如果业务里用了 Redis 的事务、Lua 脚本以及某些版本特有的命令需要先确认 Tair 的兼容范围。我们有一块业务原本依赖 Redis 的 KEYS 命令做模糊匹配切到 Tair 后发现这个命令被限制了后来改成用 scan 命令分页遍历解决。4. 60% 成本压缩的深度拆解4.1 人力运维成本从 2 个人全职变成 0.5 个人兼职这是整个降本方案里最值得说的一项。原来 HBase 和 Redis 的运维工作占用了两个研发人员几乎所有精力他们每天做的是看监控、处理报警、调参数、写工具脚本。这还只是“维护”不是“建设”。真正到做业务需求的时间可能只有一半不到。迁到 Lindorm Tair 之后存储侧基本没有需要人为介入的运维操作。扩容的话控制台点两下就能完成底层数据迁移由系统自动处理。主从切换、故障自愈这些能力过去需要我们自己写脚本和值班机制来保证现在都变成平台内置能力。我们从两个全职运维变成一个兼职值班另外一个人力释放出来转做数据架构和业务支持。这里有一个容易被忽略的点人力释放带来的收益不是立刻体现在账面上的而是体现在团队下一个项目交付速度和质量的提升上。我们后来用释放的人力做了实时特征平台支撑了多条推荐链路的优化这部分的业务收益比省下来的运维人力成本大得多。4.2 机器资源成本与存储分层带来的直接收益机器成本方面Lindorm 采用了存算分离架构计算和存储可以独立扩缩容。过去自建 HBase 扩容时存储和计算必须一起加比如某张表需要增加存储空间但 CPU 和内存还很充裕也得整体加一台 32C128G 的机器。Lindorm 按量分层计费存储装不下就只扩存储计算不够才扩计算这种方式让每一分钱都花在刀刃上。Tair 的成本逻辑类似。自建时为了保证高可用至少得三副本内存成本翻三倍。Tair 默认就做了高可用底层副本机制不用业务关心。我们根据业务情况选择了合适的容量规格并且搭配了 Tair 的持久化策略省掉了一部分额外副本的开销。再说冷热分离。Lindorm 把 30 天之前的历史数据自动沉降到冷存储这部分数据访问频率低但占用量极大。我们的数据体量里冷数据大概占了 70% 以上这意味着存储成本直接降到原来的三分之一。这个机制对成本降低的贡献比想象中要大得多。4.3 故障损失成本自建系统被低估的“隐形黑洞”自建系统最怕的是故障而故障成本往往不会出现在账面上出一次问题就需要团队连轴转修复。HBase 时代我们经历过一次 Region Server 宕机导致的全链路缓存雪崩那次事故让线上接口超时持续了 40 分钟业务损失和团队加班成本算下来非常可观。Lindorm 和 Tair 全都是多可用区部署的托管服务底层故障切换对业务透明。我们切换到现在半年时间没有因为存储侧故障引发过一次线上事故。这个“零故障成本”在成本对比表里看起来是 0但实际上比任何单项省钱都更值钱。4.4 一张表算清老架构与新架构的季度成本为了让大家有一个直观感受我把我们一个季度的成本对比整理成了一张表成本项自建 HBase RedisLindorm Tair说明计算资源10.8 万7.2 万自建机器规格含资源冗余Lindorm 按需付费存储资源6.5 万3.6 万Lindorm 冷热分离冷存储价格优势明显运维人力6.0 万1.5 万从 2 人全职降到 0.5 人兼职故障处理2.0 万0.1 万按历史事故均摊估算版本升级与迁移改造1.5 万0.2 万云托管自动升级无迁移成本总计26.8 万12.6 万降幅约 53%从表里能看到单看计算资源降幅没有想象中大真正拉开差距的是存储的人力和故障成本。如果你们的业务对数据一致性要求很高、故障容忍度低那么 Lindorm 和 Tair 这种托管方案在成本对比中的优势会更大。5. 真实踩坑记录与排查心得5.1 扫描超时问题不是 Lindorm 不行是用法没对迁移初期我们把原来 HBase 上做批量导出分析的作业直接迁到 Lindorm 上跑结果大面积出现超时。排查后发现Lindorm 对整表扫描的支持不如自建 HBase 那么“自由”它对单次扫描的行数和数据量有保护机制。解决办法有两个方向要么用 Lindorm SQL 服务通过 SQL 做 pushdown 计算要么在客户端做分段扫描按照 startKey 和 endKey 把全表切成若干个小段并发处理。我们最终选择了后者同时把原来每批次扫描 100 万行降到 20 万行整个作业跑完的时间反而更短了。这个案例充分说明任何存储系统换上来都不是“无脑平移”适配本身也是降本的一部分。5.2 冷热分离设置太晚导致热存储成本偏高冷热分离是个好东西但我们一开始没有在创建表时就把分层策略配置好导致前期写入的数据全留在热存储里。后来发现冷数据占比已经很高热存储成本开始明显上涨。解决办法是重建表并把 TTL 和冷热分离策略一起配置再把数据刷过去。这个过程不算复杂但如果一开始就规划好能省掉一次不必要的数据迁移。所以强烈建议Lindorm 建表时就把冷热分离 TTL 这些事情想清楚别等数据堆积了再改。5.3 Tair 的过期 Key 监控和容量预估Tair 的内存淘汰策略和自建 Redis 有些细微差别特别是在大规模 Key 过期时监控上可能出现内存暂时不降的现象。刚开始我们以为数据没删掉后来确认是底层在分批清理过期 Key。容量预估方面Tair 不像自建 Redis 那样容易“随手加内存”。自建时我们经常因为内存不够直接扩规格而 Tair 扩容量虽然也很方便但会产生额外费用。因此一定要提前对 Key 数量和单个 Key 大小做估算然后用 maxmemory 相关的监控指标持续观测。这里建议业务侧建立 Key 容量周报制度每周过一遍内存增长的来源。5.4 数据双跑期间的一致性问题排查双跑阶段最头疼的是数据一致性问题。有一次我们比对发现Lindorm 的写入数据比 HBase 少了几条排查了很久最后定位到是双写逻辑里部分异常分支只写了 HBase 没写 Lindorm。这里给后来者一个建议双写逻辑不要散落在业务代码里最好封装成一个明确的写入服务或者通过消息队列异步同步两份存储。这样出了问题只需要排查一个通道而不是在几十个业务点里逐个找。我们对这类一致性校验设置了小时级任务同时做总量比对和抽样 key 比对效果不错。6. 新架构的运维日常和后续规划6.1 现在的运维节奏是怎样的现在的日常运维工作和以前相比几乎算是“静音模式”。Lindorm 侧主要看容量阈值、慢查询、以及冷热分离的执行情况Tair 侧看内存使用率、命中率和过期 Key 监控。这些指标通过云监控配置好告警之后基本能做到无人值守。团队里值班同学每天的例行工作是早上花 10 分钟看一眼告警处理业务侧的缓存穿透或者数据倾斜之类的问题。存储侧自己出故障的情况半年以来几乎没有。我们把原来做底层运维的时间用来做 Lindorm 上的表模型优化和 Tair 的缓存治理比如识别无效缓存、压缩大 Value、调整过期策略。6.2 哪些方向还能进一步压成本第一Lindorm 的冷数据可以再往下沉把访问频率极低的归档数据转到对象存储只保留查询入口。这个方案目前我们正在试点预计还能再省 20% 左右的存储费用。第二Tair 侧的 Key 过期策略改成更细粒度的空闲时间淘汰让不活跃的缓存更快释放内存降低容量费用。第三把离线数仓里对 Lindorm 的直连查询逐步收敛到统一数据服务层减少不必要的扫描类流量从而降低计算资源消耗。这三个方向不需要改业务逻辑更多的是管理和治理侧的动作。以我们自己一个季度的效果来估算整体成本还能继续下降一到两成。6.3 是否所有团队都适合切到托管方案虽然这个方案帮我们省了很多成本但不是所有场景都建议照搬。如果你们有极强的定制化需求比如对 HBase 内核做了深度修改或者 Redis 里跑着大量定制模块那强行迁移反而可能增加改造成本。反过来如果你们的自建集群只是在“能用”状态团队核心业务又不在存储内核上那 Lindorm Tair 这套组合确实值得认真评估。它的核心价值不是把机器变便宜而是把原本耗在存储运维上的精力释放出来让团队去做更值钱的事。最后分享一个心得降成本真正能成靠的不是跟云厂商砍价而是让每一层系统都回到它最擅长的位置。自建 HBase 也许适合愿意深挖内核的团队但对于大多数业务团队来讲把存储和缓存的运维交给专业的托管服务才是更现实的选择。迁移过程虽然也踩了不少坑但半年后再回头看这个决定不仅帮我们省下了真金白银也让整个团队的工作状态轻松了一大截。