企业官网建设流程全解析

大家做大数据架构的，这几年应该都有一个共同感受：老板嘴上不说，但每笔预算都恨不得掰成两半花。尤其是自建 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% 这个数字怎么算出来的。我直接放一张内部脱敏过的成本拆解表，比用嘴说清楚得多：

需要注意，这 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 配套的 LTS（Lindorm 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 双写方案设计与数据迁移执行

数据迁移最怕两件事：丢数据、新旧数据不一致。我们采用的是“双写加校验加切换”这个比较稳妥的方案，具体流程分五步：

1. 在代码里加一个双写开关，业务写入时同时写 HBase 和 Lindorm，通过开关控制灰度比例。
2. 历史数据全量迁移，用同步脚本按表粒度分批跑。
3. 迁移完成后做增量校验和全量校验，确保两端数据一致。
4. 在业务低峰期打开读流量切换开关，新读写全部走 Lindorm。
5. 观察一段时间确认稳定后，关闭 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% 听起来夸张，但只要账算明白了，方案选对了，执行走稳了，这个目标并不遥远。