做数据平台的人应该都体会过这种感觉业务量涨上去了数据账单和设备维护的负担也跟着上去了。我一直有个观点大数据架构的“降本”不是简单地砍机器、缩容量而是要从架构形态上做减法。我们团队最近一年做了一次比较大的技术改造把原来以 HBase Redis 为核心的大数据底座整体切换到了瑶池数据库体系下的 Lindorm 和 Tair最终运维成本下降了 60%。这篇文章就是把这次改造的思路、选型过程、迁移细节和踩过的坑完整复盘一遍给正在做大数据架构降本的同学一个参考。先交代一下背景。我们当时的业务是典型的物联网设备数据采集与用户行为分析每天新增数据量在 TB 级别数据保留周期最长到 12 个月。系统里既有大量的时序型设备上报数据也有用户维度的实时 KV 查询和榜单缓存。这套架构跑了三年功能上没问题但成本就像温水煮青蛙月度账单越来越高运维团队的大部分时间都消耗在集群扩容、节点故障处理、内核版本升级这些事情上。盘点之后我们发现真正需要动刀的是存储层和缓存层这两块。1. 传统大数据架构的账单到底花在了哪里在做降本方案之前我们花了大概两周时间把现有架构的成本构成彻底盘了一遍。不盘不知道一盘才发现很多成本根本不是业务增长带来的而是架构本身的“结构性浪费”。1.1 存储一层HBase 集群的隐性浪费我们原来的宽表存储用的是自建的 HBase跑在十几台高性能云主机上每台机器配置是 32 核 128GB 内存挂载 SSD 云盘。为什么规格选这么高因为 HBase 的 RegionServer 既吃 CPU 又吃内存而且读写路径上的数据都希望尽量驻留在 BlockCache 里内存小了性能立刻拉胯。但问题在于我们的数据是有明显的冷热分布的近 7 天的热数据访问频率极高而 3 个月之前的冷数据几乎不会被业务直接查询只能用来跑离线分析或者给审计用。这些冷数据同样占据着内存和 SSD 空间我算了一笔账12 个月的保留周期里约 70% 的存储成本其实花在了“存着但基本不读”的数据上。再往下拆HBase 自身还带了几个“标配开销”。首先是三副本机制这个本身是必要的但配合自建集群的运维模式每台机器都要预留足够的内存和磁盘 buffer实际存储效率并不高。其次是 HMaster、ZooKeeper 这些组件虽然只占少数几台机器但也需要高规格配置和独立的高可用保障。还有一个容易被忽略的部分是集群的“碎片空间”频繁的 compaction 和 split 操作会让磁盘 IO 忽高忽低为了扛住这些抖动我们不得不把机器规格再往上抬一档。这些都是隐性成本账单上不会单独列出来但每个月的费用里都有它们的身影。1.2 缓存一层Redis 集群的高可用成本缓存层用的是自建 Redis部署模式是 3 主 3 从 3 个 Sentinel 节点。为什么要这么多节点因为业务对可用性要求高主节点挂掉必须秒级切换所以从节点和哨兵节点一个都不能少。但这样带来的问题是真正提供读写能力的只有 3 个主节点另外 3 个从节点纯粹是“备份资源”平时不承载流量却要消耗和主节点一样的内存成本。还有一个更扎心的现实我们的缓存数据增长太快了。业务方总是希望把更多的数据放到 Redis 里以换取查询性能导致 Redis 的内存使用率常年维持在 85% 以上。内存一接近水位主从同步延迟就上来了频繁触发淘汰策略大 key 删除造成的阻塞也偶尔出现。为了治这些问题我们不得不定期做内存清理和集群扩容每次扩容都是一次小心翼翼的线上操作凌晨变更、专人盯盘是常态。这些时间成本叠加起来其实已经远超 Redis 实例本身的费用。1.3 人力成本运维不只有账单最后算人力成本的时候我们才意识到问题比想象中严重。当时团队里有专门负责 HBase 和 Redis 运维的同学日常要做的事情包括集群监控、故障处理、版本升级、参数调优、扩容缩容、备份恢复演练。每个月至少有三分之一的时间都耗在这些“救火”任务上。更头疼的是自建组件的内核版本相对保守遇到一些 bug 或者性能瓶颈要么自己啃源码要么等社区修复时间完全不可控。我们当时算过一个粗略的账如果把运维这些事情折算成人力成本加上云资源账单每个月花在这套存储和缓存架构上的总成本大概是 X 万元。其中资源账单大概占六成人力成本占四成。而且随着数据量增长这两部分成本还在稳步上升。这时候我们发现单纯靠“多买几台机器”已经解决不了问题了必须换一种架构思路。2. Lindorm Tair 的选型逻辑与成本测算选型的过程其实没有太多犹豫。我们当时的核心诉求有几个第一存储层要能兼容 HBase 的访问协议不然应用改造量太大第二缓存层要兼容 Redis 协议最好能无缝替换第三必须有冷热分层能力把存储成本结构性降下来第四最好是云托管形态把运维负担交出去。基于这几点我们最终锁定了 Lindorm 和 Tair 这两个产品。2.1 为什么是 Lindorm而不是继续调优 HBase简单来说Lindorm 是一款云原生多模数据库底层是统一的分布式存储引擎在上面提供宽表、时序、搜索、向量等多种模型。对我们来说最直接的吸引力在于它兼容 HBase 的 API这意味着绝大部分 Java 代码可以沿用不需要把读写逻辑重写一遍。同时Lindorm 天然具备冷热分离能力数据可以根据时间戳或者自定义策略自动沉降到冷存储而冷存储用的是更廉价的存储介质成本能降一大截。另外一个关键点是吞吐和延迟的平衡。自建 HBase 在读写压力上来之后经常要面对 Region 分裂、热点、compaction 抖动这些问题而 Lindorm 因为是托管的分布式架构这些底层运维动作基本由平台处理了我们能明显感觉到读写延迟更平稳。而且 Lindorm 的扩容是线性扩展不像 HBase 那样要规划好 Region 数量和机器规格业务侧的压力小很多。如果你以为 Lindorm 只是“HBase 的云托管版”那就低估它了。我们在实际使用中还用了它的时序模型来处理部分设备上报数据比原来在 HBase 里自己设计 rowkey 和列族要自然得多。这一点等会儿在实操部分细说。2.2 为什么是 Tair而不是继续维护 RedisTair 是云原生内存数据库兼容 Redis 协议但它有几个形态是针对我们这种场景量身定做的。我们用的是持久内存型和磁盘型两种形态的组合热数据放在持久内存型实例里访问性能和 Redis 相当冷缓存数据放到磁盘型实例成本比纯内存低非常多但依然具备毫秒级延迟。这里要展开说一个对比。自建 Redis 看起来便宜但算上主从、哨兵、持久化、备份这些配套之后实际成本并不低。而且 Redis 的数据是“纯内存”的我们之前很多冷数据是因为怕丢、怕重建缓存才一直留在内存里现在借助 Tair 的分层存储能力可以把这些数据放到磁盘型实例上内存只留热数据成本结构彻底变了。另外Tair 作为托管服务主从高可用、故障切换、数据持久化这些能力是平台内置的我们不需要再维护一套 Sentinel 集群也不用手动处理主从切换。对于我们这种人力紧张的小团队来说这一点省下的精力非常可观。2.3 账怎么算60% 的降幅从哪来很多人听到“运维成本降 60%”第一反应是“你是不是把机器砍得太狠了”。其实不是我们这次降本的本质是两件事第一用冷热分离把存储成本降下来第二用托管服务把人力成本降下来。我放一张当时测算的对比模型口径是月成本。成本项原方案自建 HBase 自建 Redis新方案Lindorm Tair变化幅度计算资源较高主从 哨兵节点冗余多按需配置无冗余组件下降约 45%存储资源热冷数据同池SSD 成本高冷热分层冷数据落低成本介质下降约 70%高可用/备份自建主从、快照脚本维护平台内置下降约 50%运维人力约 1.5 人/月投入约 0.5 人/月投入下降约 67%综合成本基准 100%约 40%下降 60%当然不同业务的成本结构不同这个数字不能直接搬到你自己的场景里。但我可以负责任地说凡是自建 HBase Redis 且数据有明显冷热特征的业务做一次类似的架构迁移成本下降 50% 以上是大概率事件。关键在于你要先盘清楚自己的成本构成再决定从哪里动刀。3. 实操迁移过程与关键环节选型定了之后最考验人的是迁移过程。我们当时的迁移原则是“先全量、再增量、后切换”每一步都有回退方案整个过程持续了大约六周。这里我把每一步的关键环节和操作细节拆开讲。3.1 时序/宽表数据迁移HBase - Lindorm第一步是数据迁移。对于宽表数据Lindorm 提供了原生的迁移工具我们的流程大致是三段式先做一次全量快照导入然后开启增量同步最后在业务低峰期做切换。全量迁移的准备工作很关键。我们先把原有 HBase 表的主键设计、列族配置、版本保留数这些信息梳理了一遍在 Lindorm 上提前建好目标表。这里特别提醒一下虽然 Lindorm 兼容 HBase API但建表语句里的参数和 HBase 不完全一样比如预分区、压缩算法、TTL 这些都要按 Lindorm 的规则重新配置。我们用了一段脚本扫描并转换原表的元数据避免手动建表出错。增量同步这一块我们的做法是利用 HBase 的 WAL 日志或者操作审计能力把迁移期间的写入变更记录下来再回放到 Lindorm。如果你用的是支持 CDC 的版本可以直接接入同步链路。实际操作中要注意顺序问题先启动增量同步再做全量导入最后切流量的时候才能保证数据不丢、不重。切换前必须做数据校验。我们写了一套比对脚本按主键段并行扫描两张表对比指定时间范围内的记录数和校验和。有些同学嫌麻烦想跳过这一步我个人强烈不建议。数据量大的时候迁移工具偶尔会出现漏数据或者类型转换异常的情况校验这一步能帮你提前发现 90% 的问题。3.2 缓存层迁移Redis - Tair缓存层的迁移相对简单但有三个点必须处理好。第一是数据形态检查。我们原来的 Redis 里有大量的 String、Hash、ZSet 数据还有一些设置了 TTL 的 key。Tair 对这些数据结构的兼容性很好但有个别命令的行为和原生 Redis 有差异比如某些 Lua 脚本里的命令或者 Cluster 模式下的 multi-key 操作。我们在迁移前专门跑了一遍命令兼容性扫描把不兼容的命令清单梳理出来让业务侧提前适配。第二是大 key 处理。自建 Redis 多年使用下来难免会积累一些大 key比如某些用户维度的 Hash 集合特别大。这些大 key 在迁移时会有两个问题一是全量迁移的 RDB 文件体积被撑大二是迁移完成后访问大 key 依然可能阻塞 Tair 实例。我们借着这次迁移做了一次彻底的大 key 清洗把超过阈值的大 Hash 拆分成多个小 key从根上解决了这个隐患。第三是切换策略。我们采用的是“双读双写”策略先让应用同时写 Redis 和 Tair读请求切到 Tair 之前先比对一次双端数据的一致性观察运行稳定后再把读流量灰度切过去。整个切换过程可以做到对业务几乎无感知。3.3 应用侧改造与上线应用侧的代码改造量比我们预想的要小。因为 Lindorm 兼容 HBase API原有的大部分读写逻辑只需要替换连接配置和客户端依赖再加上少量适配代码。Tair 这边也一样Redis 客户端基本可以直接连只需调整连接池参数和超时设置。不过有几处细节值得注意。比如原来的 HBase 客户端里经常会写一些自定义 FilterLindorm 对这些 Filter 的兼容程度并不完全是 100%我们在测试阶段遇到过一个自定义过滤条件在 Lindorm 上返回结果不一致的问题最后改成了服务端过滤 客户端二次过滤的方案。另外Lindorm 的 scan 操作要尤其注意 limit 限制如果不设置明确的扫描范围很容易出现超时或者资源占用过高的问题这一点和 HBase 的使用习惯不完全一样。上线步骤我们拆得很细先切读流量观察核心指标再切写流量观察数据延迟最后再把旧集群的写入停掉。整个流程中我们保留了旧集群的只读状态持续观察了两周确认无恙后才正式下线。4. 迁移过程中踩过的坑与排查方法这次迁移整体是顺利的但中间也踩了不少坑。我把印象比较深的几个问题和排查思路整理出来希望能帮后面做类似改造的同学少走弯路。4.1 接口兼容性不能只看“兼容”两个字Lindorm 虽然兼容 HBase API但这种“兼容”不等于逐字节的行为一致。我们遇到的一个典型问题是在 scan 大表时原有的 HBase 客户端代码里写了 setBatch 和 setCaching 参数在 Lindorm 上表现出的 RPC 次数和网络开销明显不同导致一段离线导出任务跑得比原来慢很多。排查之后发现是因为 Lindorm 对 scan 的并发控制和预取机制和 HBase 不一样。解决办法是调整客户端的参数。我们最终把 scan 的 caching 值调大同时限制了每次 scan 的 region 范围让离线任务以更自然的节奏去拉数据。类似这种细节文档里不会写得特别细最好的方式是在迁移测试阶段把核心读写链路都跑一遍用真实的查询模式去验证而不是只跑几个简单的 get 操作。4.2 冷热分离的 TTL 策略要反复验证冷热分离是 Lindorm 省成本的大杀器但也容易出问题。我们最初设计冷热规则时想着“数据超过 30 天自动转冷”结果上线后发现有一部分数据在冷存储里无法被实时查询导致个别报表页面出现短暂超时。原因是我们对“转冷”的语义理解不到位。Lindorm 的冷热分离是基于数据写入时间或者自定义时间戳来判定的数据转冷之后查询冷数据需要走冷数据读取链路延迟会比热数据略高。所以冷热分层的阈值不能只看“数据多久没读”还要结合业务对查询延迟的容忍度。我们最终把转冷阈值从 30 天调整到了 60 天并把对延迟敏感的那部分数据的 TTL 规则单独配置。这里提醒一句设置 TTL 一定要小心。我们测试时因为误把 TTL 和冷转热的策略混淆导致一批数据被提前清理了好在有备份才恢复。建议在测试环境里先验证完整的数据生命周期写入 - 热数据查询 - 转冷 - 冷数据查询 - TTL 清理每一步都确认符合预期再上生产。4.3 Tair 的“冷数据”不是永远免费的使用 Tair 磁盘型实例时容易产生一个错觉以为数据进了磁盘型就等于“随便存”。实际上磁盘型实例仍然有容量上限和性能上限而且磁盘型实例的访问毛刺会比纯内存实例略高。我们的一个业务把大量冷榜单数据放进磁盘型 Tair 后遇到了一次大促流量波峰磁盘读延迟出现明显上升最终通过给关键 key 增加本地缓存 限制并发读的方式解决了问题。另外需要注意持久化内存型 Tair 的单 key 大小限制。我们当时有一个存储用户画像大 JSON 的场景value 大小到了几 MB写入持久内存型实例时报错后来拆成了多个 Hash 字段存储才解决。迁移 Tair 之前最好把自己的数据结构清一遍value 过大的提前拆分。4.4 排查工具与指令速查场景原 HBase/Redis 常用方式Lindorm/Tair 建议方式查看大表 region 分布hbase shell: status detailedLindorm 控制台或 SQL 诊断分析 scan 慢查询HBase Master 页面 / log开启慢查询日志结合 tracing内存型缓存 key 扫描redis-cli --bigkeysTair 控制台内置的 Key 分析主从切换验证手动 kill 主节点观察可直接通过控制台进行主备切换演练冷热数据分布查看无直观手段Lindorm 热冷数据统计报表这些工具和指令能帮你把日常排查效率提起来。我个人尤其推荐多看看云产品控制台里自带的诊断能力很多时候比你自己写脚本去抓日志要更快、更准确。5. 降本效果复盘与后续还能怎么省改造完成到现在已经跑了半年多再回头去看当时的目标我们可以说基本都实现了。但这篇文章的最后一个部分我想聊的不只是“省了多少钱”而是整个团队的运作方式发生了怎样的变化以及下一阶段还有哪些空间可以继续优化。5.1 上线半年后的资源与稳定性对比从资源账单来看存储和缓存相关的月度成本稳定下降了约 60%这个数字和最初测算基本一致。存储侧的大头是 Lindorm 的冷存储费用比原来的 SSD 云盘低了好几个量级缓存侧则是 Tair 磁盘型实例拉低了整体成本同时热数据依然保持在高性能实例上。稳定性方面我们最直观的感受是“半夜被叫醒的情况几乎没有了”。以前自建 Redis 偶尔会出现主从切换每次切换都要起来确认数据一致性现在这套托管架构的故障自愈能力明显更强即使真有节点异常平台会自动处理我们只需要事后看一下事件记录。过去半年核心链路的可用性从 99.95% 提升到了 99.99%这是一个额外收获。5.2 运维模式的变化从“救火”到“巡山”团队层面的变化同样明显。以前团队里负责 HBase 和 Redis 的同学每天第一件事是看监控告警然后处理各种“漂红”的指标整个人被耗在操作层面。现在这部分职责大幅度简化我们更多的时间花在容量规划、数据模型优化和成本分析上。运维方式也从“出了故障再处理”变成了“定期巡检 主动优化”。我还发现一个有意思的变化因为 Lindorm 和 Tair 的使用门槛比自建 HBase/Redis 低业务团队也开始能看懂一些底层数据情况了他们会自己去看热冷数据分布和容量使用率甚至主动提出“这个表能不能早点转冷”。这种共建的氛围比纯粹的技术降本更有长期价值。5.3 后续还能怎么降弹性与 Serverless 化降本到这里并没有到终点。我们正在评估两件事一是把部分非核心业务切换到 Serverless 形态让计算资源随流量自动伸缩彻底消灭“闲置资源”的概念二是把数据生命周期管理再做细一点按不同业务的重要程度设置不同的保留策略和转冷策略而不是“一刀切”用同一个规则。根据我个人经验降本这件事最怕团队陷入“为了降本而降本”的短期思维。真正成功的降本一定是以架构合理性为前提的这次我们之所以能降 60%不是因为拼命压缩容量而是因为把冷热分离、按需计算、托管运维这些机制用到了合适的位置上。如果你的业务也面临类似的成本压力建议你先花时间盘清楚成本构成再决定哪些组件值得保留、哪些应该被替代而不是一上来就喊着“上云”“换数据库”。最后分享一个小技巧在做类似迁移时一定要在项目初期就建立成本基线。把迁移前的账单、资源用量、人力投入全都记录下来迁移完成后逐项对比。有了这些数据你不仅能验证降本效果也能在向团队或管理层汇报时拿出一份一眼就能看懂的“成绩单”。这次我们能快速确认降本 60%靠的就是这笔账从头到尾都记得清清楚楚。