大家做大数据架构的这几年应该都有一个共同感受老板嘴上不说但每笔预算都恨不得掰成两半花。尤其是自建 HBase 加自建 Redis 这套经典组合稳定是稳定但账单越来越难看。物理机要钱运维要人扩容要周期一出故障半夜爬起来处理更是常态。我们团队在去年做了一次彻底的大数据架构降本改造核心动作是把自建 HBase 和自建 Redis 整体迁移到了云上的瑶池 Lindorm 加 Tair 这套组合。今天直接说结果综合运维成本降了 60%存储成本下降了一个量级性能不但没缩水高峰期写入延迟反而比以前更稳。这篇文章不聊虚的从成本构成、技术选型、迁移踩坑到冷热分层设计全部摊开讲。1. 为什么要动这套架构成本账和运维账都算不过来了很多团队不敢动核心大数据架构怕迁移出事故但真把旧架构的账算清楚其实更吓人。我们当时的情况是自建 HBase 用了 24 台物理机自建 Redis 集群占了 16 台虚拟机每个月光机器折旧和电费机房成本就是一笔不小的开销。更别提还有 2 名专职运维的大半精力都耗在集群身上每周至少有两三次半夜处理告警。不过我先把话说在前头HBase 和 Redis 本身不是不好而是自建这条路在当前阶段让大多数团队越走越吃力。HBase 的 Region 分裂、热点处理、compaction 调优每一项都是经验活团队没有一年半载的积累根本玩不转Redis 的主从切换、持久化策略、内存碎片整理也是一堆需要操心的细节。如果你们团队规模不大、又不想在基础设施上投入太多人力云原生数据库替代自建就是必然要走的路线。1.1 为什么选 Lindorm 和 Tair 这对组合选型的时候我们不是没有犹豫过。市面上的选择很多但 Lindorm 吸引我的地方在于它是多模数据库HBase 宽表模型、时序模型、搜索模型都支持而我们现有的业务表大多是宽表结构迁移成本相对可控。另一个关键点是它存储计算分离存储按量计费不需要像自建那样预留物理容量这对成本敏感的场景非常友好。Lindorm 还自带 ZSTD 压缩我们实测压缩比比 HBase 默认的 Snappy 高 1.5 倍左右。这意味着同样的数据量在 Lindorm 上占用的存储空间更小存储成本自然就降下来了。加上它支持自动分区管理不用像 HBase 那样手工预分区rowkey 设计得烂也不会出现明显热点运维负担轻了很多。Tair 则是云原生内存数据库兼容 Redis 协议但它省掉了主从、哨兵、持久化这些自建 Redis 必须自己管的东西。我们原来 Redis 集群偶尔会主从切换慢导致缓存击穿业务方经常来投诉Tair 的高可用切换做得很隐蔽自动故障检测和持久化策略直接控制台配置半夜被叫起来的次数基本归零。提示Tair 虽然兼容 Redis 协议但部分命令行为有差异比如某些 Lua 脚本、阻塞命令在迁移前一定要扫一遍业务代码别直接改了连接地址就上这里很容易踩坑。1.2 60% 降幅的成本构成拆解很多朋友好奇 60% 这个数字怎么算出来的。我直接放一张内部脱敏过的成本拆解表比用嘴说清楚得多成本项自建 HBase 自建 Redis云上 Lindorm Tair降幅说明服务器资源24 台物理机加 16 台虚拟机Lindorm 按量存储加 Tair 主从版资源不再按峰值预留按需扩缩容存储容量预留 70TB 物理容量实际有效数据约 40TB按实际存储计费开启 ZSTD 后容量大幅压缩存储成本直接下降一个量级运维人力2 名专职运维每周至少两次半夜处理几乎零运维控制台操作即可人力成本大幅释放软件许可与工具商业运维和监控工具授权费用无少了一笔隐性成本需要注意这 60% 算的不是单纯服务器采购成本而是把硬件、运维人力、软件许可、机房租用、电费全部算进去的总拥有成本TCO。对老板来说这叫预算腾挪对技术人员来说这个降本并没有牺牲性能和稳定性反而把运维压力卸下来了。所以我说这套方案的本质是把账算清楚了。2. 成本降了 60%性能和稳定性靠什么撑住听到降本方案很多人第一反应是“便宜没好货”。但对我们这套场景来说结论恰好相反性能不降反升。原因可以拆成三块写入链路更顺、热数据访问更快、冷数据存储更省。下面逐一展开。2.1 写入链路从脑梗到顺滑的关键改造大数据场景最容易出问题的环节是写入尤其是在高峰期秒级写入量很大的时候。原来 HBase 在写入量大的时段经常出现 region server 负载不均部分节点写满、部分节点闲置然后写入延迟抖动严重时直接报错。每次大促前我们都要靠临时扩容硬顶扩完再缩非常折腾。Lindorm 写入侧最大的体验是省心。它的自动分区管理不再需要手工预分区行键分布再烂也不会轻易产生热点写入吞吐有弹性底层存储和计算分离之后流量上来能自动扛住不用提前加节点。我们线上高峰期每秒写入量大概 80 万条包含日志和埋点数据链路是 Flink 消费 Kafka 后批量写入 Lindorm写入延迟 P99 稳定在 30ms 以内。这里有一个实操细节值得分享对 Lindorm 的写入不要逐条写而是通过 Flink 攒批默认攒够 2000 条或者 2 秒再 flush 一次。批次大小是个权衡点批太小吞吐上不去批太大单次延迟会拉高内存占用也随之上升。我们前后调了几轮最后定在 2000 条加 2 秒这个档位既保证了吞吐又把写入 P99 压在了 30ms 以内。Tair 在写入侧的角色是承接高频计数器和排行榜比如实时在线人数、点击量排行这些。以前这些数据直接怼 Redis主从同步有延迟时数据偶尔对不上换到 Tair 后数据一致性表现更稳基本没有出现过主从延迟引发的数据错乱。2.2 查询链路热数据走 Tair冷数据走 Lindorm大数据访问有明显的冷热之分这也是成本优化空间最大的地方。我们的分层策略是热数据最近 7 天放 Tair毫秒级响应。温数据最近 30 天放 Lindorm通过二级索引查询。冷数据30 天以上放 Lindorm 冷存储低频访问成本更低。这个分层设计让每类数据都待在“最合适、最便宜”的地方。比如用户实时画像、实时榜单这类 QPS 上万的接口直接从 Tair 拿数据响应时间基本在 2ms 左右而历史订单查询、报表分析这类 QPS 很低的场景走 Lindorm 就够了没有必要动用昂贵的内存资源。有团队可能会问为什么不把全部数据放 Tair答案很简单内存太贵了。把 40TB 数据全部放进内存任何公司都扛不住这个成本。所以冷热分层不是可选项而是成本控制下的必选动作。Lindorm 是宽表模型单表查询很快但要根据非主键字段查就得靠二级索引。我们建索引的原则是“用到才建能不加就不加”因为每多一个索引写入时都有额外的索引维护开销。线上三个高频查询场景建了索引按用户 ID 查最近订单列表、按设备 ID 查设备状态记录、按商户 ID 查交易汇总。表格设计上主键保留业务主键比如“用户ID_时间戳”二级索引用冗余字段的方式建查询时直接命中索引。2.3 冷数据处理成本降幅最大的一个动作数据超过 30 天之后访问频率明显下降继续放在标准存储上就是浪费钱。Lindorm 支持冷热数据分层我们配置了生命周期策略30 天后自动把数据转为冷存储查询频率极低的数据还可以进一步归档。这个功能带来的收益非常直接标准存储和冷存储的单价差距相当大冷数据占比越高省得越多。我们的数据大约 60% 是 30 天以上的冷数据如果全部按标准存储计费成本会非常难看。开启冷存储之后单 GB 成本下降了一个量级整体存储成本直接降下来一大截。Lindorm 配套的 LTSLindorm Tunnel Service也值得一说。它是一个数据同步通道可以把 Lindorm 里的数据无缝同步到 MaxCompute 等外部系统做离线分析或者数据归档时不用自己再写一套同步工具开发量省了稳定性还更好。3. 迁移实战从自建 HBase 加 Redis 切到 Lindorm 加 Tair光讲原理不实操等于纸上谈兵。这一章把迁移过程中的具体步骤、踩坑点和验证方法都梳理出来给正在纠结要不要迁移的团队做个参考。3.1 迁移前的数据盘点与容量规划迁移前最重要的事情不是写代码而是把家底盘清楚。我们当时做了几件事统计每个表的体量、行数、平均行长评估目标存储用量分析读写比例、QPS 峰值、写入吞吐峰值确认规格选型梳理业务对数据一致性的要求决定哪些数据可以异步迁移哪些必须同步双写。以我们为例HBase 里有大概 40 个业务表其中 15 个是核心高频表其余偏离线分析。我们给这 15 个核心表做了完整的 schema 映射包括列族、列名、数据类型、TTL 等。列族过多或者列名不规范的表顺便做了一次治理。这种“顺手”的活在迁移期做最划算平时根本没人敢动线上表。容量规划这里要特别提醒Lindorm 的存储独立计费规划时不能只按原数据量估算因为压缩比、副本数、索引开销都会影响最终存储量。建议按原数据量的 1.5 到 2 倍去做预算心里才有底。Tair 的容量规划相对简单统计热数据总量加上 30% 的 buffer 就差不多。如果发现内存成本偏高优先优化热数据的保留时间而不是无脑加内存。3.2 双写方案设计与数据迁移执行数据迁移最怕两件事丢数据、新旧数据不一致。我们采用的是“双写加校验加切换”这个比较稳妥的方案具体流程分五步在代码里加一个双写开关业务写入时同时写 HBase 和 Lindorm通过开关控制灰度比例。历史数据全量迁移用同步脚本按表粒度分批跑。迁移完成后做增量校验和全量校验确保两端数据一致。在业务低峰期打开读流量切换开关新读写全部走 Lindorm。观察一段时间确认稳定后关闭 HBase 侧的写流量下线旧集群。这个方案最大的坑是双写期间的性能损耗。每次写入要写两套系统延迟和资源占用都会上升。我们当时专门做了压测确认双写对核心链路的延迟影响不超过 10%才放心推进。校验环节同样重要。我们写了一个比对工具按主键维度对 HBase 和 Lindorm 的数据做抽样比对比对字段值、时间戳、版本号。抽样比例最开始是 1%等信心建立后逐步提升到 5%。校验通过才切流量整个过程虽然有灰度但每一步都走得很稳。注意双写期间一定要监控写入延迟和失败率两个指标任何一个异常都要立刻关掉双写开关保证业务可用性优先绝对不能为了迁移而牺牲线上稳定性。3.3 回滚预案与业务验证再完善的方案也有可能翻车所以回滚预案必须提前准备好。我们的策略是保留旧集群一个月确保 Lindorm 侧稳定运行之后才真正下线 HBase 和自建 Redis。回滚的判断条件也很明确如果切换后 Lindorm 的写入 P99 超过 100ms或者核心接口的查询延迟上升超过 50%或者出现数据不一致无法快速修复的情况就立即回滚。实践下来这个预案虽然没有真正用到但给了业务方很大的安全感也让迁移审批流程顺利了很多。业务验证方面我们对核心链路做了全链路压测模拟双十一峰值流量。压测目的是确认 Lindorm 和 Tair 在峰值下表现稳定不是简单“能扛住就行”。压测指标包括吞吐量、P99 延迟、错误率、资源水位全部记录下来跟旧架构做对比。最后的结果是吞吐能力相当延迟略有下降资源水位还更低了。4. 跑稳之后回头看成本治理不是一次性的项目迁移完成后团队最直观的感受是“终于不用天天救火了”。但我想说的是降本这件事不是一次性的项目而是一个持续治理的过程。架构切完之后我们并没有停下来而是建立了一套常态化的成本治理机制。4.1 日常监控和成本看板怎么搭原来我们只有机器监控没有成本监控导致很多时候成本超了都不知道花在哪。切到 Lindorm 和 Tair 之后我们利用云上控制台的监控能力搭了一套成本看板把每个业务的存储用量、请求量、成本消耗全部关联起来。看板的核心指标有四个存储用量增长趋势、请求量 QPS 趋势、按业务线拆分的成本占比、冷热数据比例变化。每个指标都设置了告警阈值比如存储用量月环比增长超过 20% 就要告警。这样一旦哪个业务线数据增长异常我们能在第一时间介入不至于月底看到账单才后悔。成本看板还要结合业务价值去看。比如某个报表任务每天凌晨跑一次全量扫描查询量不大但扫描的数据量很大存储成本一直在涨。后来我们把这类任务的查询模式改成分区裁剪只扫描当天新增分区存储和计算成本都降了不少。这种优化不需要改架构靠的是对业务查询模式的持续分析。4.2 生命周期策略和定期治理节奏对于大数据系统最怕的就是数据只进不出。我们制定了明确的数据生命周期管理规范业务数据按天分区热数据保留 7 天温数据保留 30 天超过 30 天自动转冷存储超过 180 天的数据根据业务需求评估是否归档或清理。这个策略全部通过 Lindorm 的生命周期管理功能自动完成不需要人工干预。最开始设置这个规范的时候业务方是有顾虑的怕冷数据查询变慢、怕数据被清理后出问题。我们做了一次数据访问分析证明 30 天前的数据查询频率不到总量的 5%而且冷存储查询延迟虽然比标准存储高一些但对这些低 QPS 场景完全够用。成本治理的节奏也很重要。我们每个月复盘一次成本数据看哪些业务线的成本增长异常哪些表可以合并或下线哪些生命周期策略可以收紧。这种月度治理的习惯保持了半年成本控制效果比想象中好很多。5. 如果再做一次我会提醒自己的几件事迁移这个项目从立项到完成用了差不多三个月踩了不少坑也总结了一些可能对大家有用的经验。最后分享几条实在的希望能帮准备做类似改造的团队少走弯路。5.1 选型别只看单价要看 TCO 和团队承载力很多团队做技术选型容易陷入“比价格”的误区觉得哪家数据库单价低就选哪家。但实际上TCO 才是真正值得关注的指标。TCO 包括软件费用、硬件费用、运维人力、学习成本、迁移成本、隐性故障成本等。自建 HBase 看起来没有软件费但硬件和人力成本高得吓人云数据库看起来有服务费但省下来的运维人力可能是更大的一笔收益。还要看团队承载力。如果团队连一个专职运维都没有自建数据库就是在给自己埋雷。云上托管数据库的价值不在于“便宜”而在于把复杂问题丢给专业团队我们只需要关注业务。我个人的体会是适合的架构永远是“跟团队规模和业务阶段匹配”的架构而不是“听起来最牛”的架构。对大多数中小企业来说自建核心数据库的隐性成本远远高于账面上的那点费用节省。5.2 数据库迁移永远先考虑数据一致性做数据库迁移最忌讳上来就写迁移代码然后直接切流量。数据一致性是所有环节里最不能妥协的。我的建议是任何迁移方案都要包含完整的数据校验步骤并且校验不能只是“抽样看看”要能做全量比对就做全量比对至少也要做到关键字段的 diff。我们团队在迁移过程中吃过一次亏某个配置表的数据量很小就想着不用校验了结果切流量后发现新系统里少了一批历史配置数据导致一部分用户看到的功能状态不对。虽然最后通过补录解决了但这个教训让我深刻理解了“再小的表也要校验”这句话。5.3 降本增效的核心是让数据去最合适的地方最后想说的是降本不是一味砍成本而是让每一份数据、每一个请求都去它最该去的地方。热数据放内存温数据放普通存储冷数据放冷存储这才是成本最优解。Lindorm 加 Tair 这套组合之所以效果好本质上是把“冷热分离”“存储计算分离”“按量付费”这些理念真正落地了。如果你所在的团队也正被大数据架构的成本压得喘不过气我的建议是先别急着上方案花两周时间把现有系统的 TCO 算清楚再对照这篇文章的拆解逻辑看看哪些地方还有优化空间。成本降低 60% 听起来夸张但只要账算明白了方案选对了执行走稳了这个目标并不遥远。