企业官网建设流程全解析

大数据平台的成本为什么总是一年比一年高？这个问题我们去年被老板拷问了整整一个季度。平台同时跑着HBase、Redis、ES、Flink，外加一个四节点的HDFS给HBase当底层存储，每个组件单看都有存在的理由，合在一起账单就失控了。后来我们用瑶池Lindorm替换了HBase体系、用Tair替换了自建Redis，迁移完成稳定运行近半年，整个大数据架构的运维成本降了差不多60%。这篇文章就把我们拆解成本、选型评估、迁移落地和踩坑的完整过程写清楚，给同样被自建存储系统运维拖垮的团队一个可参考的样本。

1. 先搞清楚钱到底花在哪：一套自建大数据平台的成本拆解

1.1 组件林立带来的隐性成本

很多人一听“降本”，第一反应是去找更便宜的云主机或者砍配置，这个思路不能说错，但会把真正的大头漏掉。我翻出过去一年多的账单和工时记录重新核算了一遍，发现自建集群的成本远不止“云资源账单”这么简单，至少包含四块：资源费用、人力维护、故障损失和扩容等待成本。

资源费用好理解，就是ECS、云盘、带宽这些账单上的数字。人力维护则往往被严重低估，尤其是自建HBase这种全家桶，每天要面对的不只是业务读写，还有NameNode的元数据管理、DataNode的磁盘均衡、RegionServer的region分裂合并、ZooKeeper会话超时抖动。任何一个环节出问题，都要资深工程师去排查，这种成本按“人头”算非常吓人。我们当时HBase集群规模是32台ECS（16C64G规格），挂着约240TB的云盘，底层还压着一个4节点的HDFS。Redis这边同样不省心，为了高可用，主从加哨兵一上就是双倍机器，还要定期处理RDB和AOF持久化文件带来的磁盘占用问题。这些组件不是不能用，而是“养”它们的成本被平摊到了日常工作的每分每秒里，不会单独列在账单上，所以特别容易被忽略。

1.2 我们当时算出来的一份真实账单

为了讲清楚“60%到底怎么降下来的”，我把当时的成本模型列在这里。大家可以用同样的口径去估算自己的集群，这个口径比单纯比“单价”要靠谱得多。

我们当时的业务规模放在行业里只能算中等：HBase侧单表数据量约15TB，实时写入峰值大概每秒8万行；Redis侧有效缓存数据约1.2TB，QPS峰值不到30万。说实话这个量级并不算多“大数据”，但自建模式下的固定开销已经压得平台团队喘不过气。

这里有一个很重要的判断：自建系统的成本不是线性的，它带着很重的“固定成本”。哪怕你业务只有1TB数据，也要至少部署3台起的HBase和3台起的Redis才能提供高可用。集群规模越小，单位成本反而越高。这个特性决定了，中小规模的团队在自建模式下永远处于成本劣势。

1.3 降本方向不是砍功能，而是砍系统

算完账之后，我们内部讨论过好几个方向。有人提议砍掉ES只留HBase，用全文索引顶一顶；有人提议把Redis缓存削掉一半，让业务直接查HBase。这些方案本质都是“砍功能”，会直接影响业务体验，不可取。

我当时的判断是：成本高的根源不是功能太多，而是系统太多。每一套自建组件背后都跟着一套“人肉运维成本”。所以正确方向应该是在不牺牲功能的前提下，减少需要自己运维的系统数量，让专业的产品去做专业的事。这个思路最终决定了选型：HBase体系整体迁移到瑶池Lindorm，Redis体系迁移到Tair，ES和Flink暂时保留。因为这两处是当时成本占比最大、运维负担也最高的部分。

2. 为什么是Lindorm + Tair，而不是其他组合

2.1 Lindorm在存储侧的定位：一个引擎，多种协议

选型时我们先把可选项摆了出来：继续自建HBase、上云HBase托管版、或者用Lindorm这类多模数据库。自建HBase首先被排除，因为我们已经被NameNode、RegionServer、ZooKeeper这三座大山的日常运维磨得没了脾气。云HBase托管版能解决“运维”问题，但它只能解决宽表这一个场景，产品形态偏传统，未来想支撑时序、检索等新需求时，又得再引入新系统。

Lindorm吸引我们的核心点在于“多模合一”：底层是一套统一的分布式存储引擎，却能同时兼容HBase宽表接口、Cassandra接口、SQL接口、OpenTSDB时序接口和Solr检索接口。这意味着它不仅能接管HBase的活，未来如果我们想简化ES，连检索都有机会并进来。我们在评估时做了一个小验证：把一段原本面向HBase的Java客户端代码，只改连接地址和数据源参数，就能读写Lindorm宽表，兼容性做得很干净。

Lindorm的存储计算分离架构对我们来说更是正中下怀。自建HBase最大的尴尬是计算和存储绑在一起，业务高峰期要加RegionServer，低谷期却没法缩。Lindorm的计算层按读写CU弹性伸缩，存储层按实际数据量计费，不再需要为“峰值预留”买单。配合冷热分层能力，90天前的历史数据还能自动进入冷存储，单价与热存储差距明显，这个我在第3章展开讲。

2.2 Tair替代自建Redis的底气在哪

Tair是阿里云的云原生内存数据库，协议层兼容Redis。协议兼容意味着我们的Java客户端改造成本几乎为零。但真正打动我们的，是它把“内存数据库”这个品类的成本结构打散了。

自建Redis只有一种形态：纯内存。不管你的数据是每天访问百万次的热数据，还是一个月才读一次的冷数据，都占着同样昂贵的内存条。Tair则提供内存型、持久内存型、磁盘型三种形态：热数据放内存型，微热数据放持久内存型，冷数据直接放磁盘型。磁盘型的存储成本可以做到内存型方案的四分之一甚至更低，同时依然保持毫秒级访问延迟。

这一点对我们太关键了。我们当时Redis里有大量“历史商品标签”“七天以上未活跃用户的画像快照”这类访问频率很低的数据，但在自建Redis里它们和热数据一样占着昂贵的内存空间。换到Tair之后，这部分数据名正言顺地挪到了磁盘型实例里，内存占用和账单数字同时下降。

2.3 和“继续混合部署”方案的取舍

有同事提过另一个折中方案：HBase迁到云HBase，Redis迁到云Redis，纯托管、不换产品形态。这个方案确实也能省一部分人力成本，但我们算完之后发现，它省的只是“运维成本”，资源成本下降有限，而且未来没有任何扩展空间。相比之下，Lindorm可以把原本需要HBase、OpenTSDB两套引擎才能支撑的场景收敛到一个引擎上；Tair把内存型、持久内存、磁盘型统一到一个产品体系里，后续选型弹性更大。一次迁移如果能同时解决今天的问题和明天的问题，才值得投入这么大的改造精力。

3. 瑶池Lindorm落地细节：从HBase迁出后，存储和计算到底省了什么

3.1 存储计算分离与冷热分层的真实收益

Lindorm上线后，我第一件事是把用户画像表的存储模型重新设计了一遍。在自建HBase里，数据按HDFS三副本策略存，实际15TB的逻辑数据要占45TB的物理空间，云盘费用非常可观。Lindorm底层虽然也是云盘副本机制，但费用由云厂商统一承担，用户只按逻辑存储量计费。我们15TB的数据迁过去之后，存储费用直接按15TB而不是45TB来计算，仅这一项的月度成本就肉眼可见地下降。

冷热分层是另一个大头。Lindorm的表可以设置冷热分层的转换规则，比如“数据写入后超过90天，自动转冷”。我们在订单明细表上配置了自动转冷策略，因为订单数据的特点是“写后基本不再更新，时间越久访问频率越低”。目前集群里超过一半的数据都处于冷存储状态，而冷存储的单价只有热存储的四分之一左右。如果当初不做冷热分层，哪怕Lindorm再怎么便宜，15TB全热存的费用还是会让预算报表很难看。

3.2 兼容HBase接口带来的迁移便利

很多人担心从HBase迁到Lindorm是不是要重写应用层。以我们的经验来看，如果你的应用本来就是用HBase的Java客户端，而且没用太多HBase独有高级特性，迁移成本比想象中低得多。常见的HBase API，如Put、Get、Scan、Increment、CheckAndMutate等，Lindorm宽表引擎都有对应实现。我们的画像服务、订单查询服务、风控特征服务，基本只修改了连接配置，个别地方换了新的数据源类，就完成了读写切换。

不过说句大实话：完全“零改造”是不现实的。我们遇到过几个差异点，比如Lindorm对某些Scan的批量大小参数语义不一样，以及Increment在跨行事务上的表现和HBase有差别，这些都需要在联调阶段逐个确认。整体上，应用改动量控制在“天”级，而不是“周”级，已经比我们预想中顺利很多。

3.3 容量治理规范：别把云数据库当成无限大硬盘

Lindorm按量计费让成本变得更透明，但也对使用习惯提出了更高要求。我见过一些团队上了云数据库之后毫无节制地涨数据，最后账单飞涨，反过来怪云数据库太贵。这是典型的“工具选对了，用法不对”。

我们在迁移时同步定了几条规矩：所有新建表必须评估TTL，大数据量导入必须先降温再执行，禁止无条件全表Scan。Lindorm不是不能Scan，而是Scan会消耗大量读CU，在按量计费模式下这笔钱是不可忽视的。我们把原来扫全表的离线任务改成按天分片扫描，同时把部分近实时查询收窄到最近七天的数据范围。这些小习惯叠加起来，大约能省下20%的读CU费用。迁移不仅是换产品，更是一个重新规范使用方式的机会。

4. Tair在缓存层的降本细节：内存不该全用热数据来定价

4.1 持久内存型和磁盘型是怎么把单价打下来的

Tair给我们的第一重惊喜是“按数据冷热付费”的产品分层。自建Redis时代，你只能花大价钱把所有数据都存在内存里。Tair的持久内存型使用持久内存硬件，价格低于传统DRAM；磁盘型则把数据主体放在ESSD云盘上，内存只做最近访问数据的加速层，适合“总量大、但同一时刻真正热的数据少”的场景。

我们当时做了这样的实例规划：

自建Redis时代，这两类数据吃的是同一份内存预算，现在它们按各自的成本单价付费，总费用自然就下来了。特别是磁盘型实例承载了超过80%的数据容量，但账单占比却不到一半，这个结构带来的成本优势是非常直观的。

4.2 代理模式与自动运维：省心也是省成本

Tair默认走Proxy集群模式，客户端不需要感知后端分片。这一点在缓存key拆分、连接数管理上非常省事。我们在自建Redis Cluster上最头疼的就是客户端维护分片路由表的问题，还遇到过节点切换期间客户端报错。换到Tair之后，Proxy层把这些复杂度全部屏蔽了，客户端只管读写。

同时，Tair的主备切换、故障探测、数据备份都是平台自动完成的。这对我们这种平台团队不大、业务线却很多的团队来说，省下的运维时间非常可观。省下时间不是目的，让有限的工程师去做数据治理、实时特征平台这些真正有业务价值的事才是目的。

4.3 基于访问热度重新设计缓存分层

迁移Tair时，我们没有简单地把Redis里的数据原样倒过去，而是先做了一次全量key的访问热度分析。通过统计一周的慢日志和命令频次，把key粗略分成三层：每日访问超过百万次的超热key、每日访问几千次到几万次的温热key、以及完全低频的历史key。

超热key和温热key放进持久内存型实例，容量规划按峰值并预留20%缓冲；低频key全部放进磁盘型实例。这样一分层，内存型实例不用买很大的规格，磁盘型实例按容量购买，整体预算比原来“一刀切全买内存”省了接近一半。这里我给个最直接的配置建议：不要照搬自建Redis的容量规划方式，按访问热度重建容量模型，效果往往比换产品本身更明显。

5. 迁移过程中的实操笔记：双跑、校验与灰度切流

5.1 数据迁移与双写校验方案

从HBase向Lindorm迁移，我们采用的是“存量导入+增量双写”的方式。存量数据通过离线任务先导过去，导完跑一遍行数校验和checksum校验；增量部分在切换前开启双写，业务同时写HBase和Lindorm，等两边的数据追平后再切读。

有一段关键逻辑值得单独贴出来：

// 双写与异步校验的简化示意 public void writeBoth(String rowKey, byte[] family, byte[] qualifier, byte[] value) { hbaseTable.put(new Put(Bytes.toBytes(rowKey)).addColumn(family, qualifier, value)); lindormTable.put(new Put(Bytes.toBytes(rowKey)).addColumn(family, qualifier, value)); pendingCompareQueue.add(rowKey); } // 独立的校验任务从队列里取key，定期对比两边的读取结果

这里最容易踩的坑是：双写不是简单地在代码里写两个数据源，还要保证写失败的补偿和日志。我们在双写阶段专门加了一个异步补偿任务，定期比对两边的增量数据，发现差异就从HBase侧补录到Lindorm。如果只闷头双写不校验，切换时很可能发现两边数据已经不一致了，再回头定位就非常痛苦。

5.2 Tair迁移的平滑切换流程

Tair迁移相对简单，因为Redis本身常被当作可以允许短暂丢失的缓存来用。我们采用“先建新实例、再预热、最后切流量”三步走：先通过工具把自建Redis里的数据导出到Tair，然后让业务短暂地双读，验证Tair返回的数据和自建Redis一致，最后按业务线灰度切流。

整个过程中，自建Redis主集群的读流量是逐步下降的。切换期间观察Tair侧的错误率和延迟曲线，确认没有异常后再完全摘掉旧集群。这里要提醒一句：导出工具默认的并发度往往偏低，如果是上百GB的缓存数据，记得把并发参数调大，否则预热阶段就可能耗掉大半天。

5.3 我们在迁移中踩过的三个坑

第一个坑是批量导入Lindorm时没有做预分区，导致导入开始阶段大量请求集中打在一个Region上，导入速度一度非常慢。解决办法是按主键分布预创建足够数量的分片，让导入请求均匀打散。

第二个坑是Tair磁盘型实例的内存淘汰策略。磁盘型实例的内存是热数据加速层，如果淘汰策略配置不合理，热数据可能被冷数据挤掉，导致延迟瞬抬。我们把相关参数调成优先保热数据后，业务高峰期的延迟曲线才平稳下来。

第三个坑是迁移期间的双跑任务占用了大量本地带宽。HBase和Lindorm同时写入时，单机网络和磁盘IO比平时高出一截。好在我们的迁移窗口选在了业务低峰期，同时给双写任务加了熔断开关，整体平稳度过。如果你也要做大规模双跑，提前评估带宽和磁盘IO非常有必要。

5.4 切换后的成本复盘与运营节奏

迁移完成三个月后，我做了一次全面的成本复盘。Lindorm侧每月账单稳定在之前自建HBase加HDFS体系的45%左右，Tair侧每月账单约为自建Redis方案的三分之一。再加上运维人力投入从原来的接近1.7人降到了0.5人以下，综合算下来一年节省的费用在90万元以上，降幅刚好落在60%这个区间。

比数字更重要的，是团队状态的变化。从繁琐的集群运维中解放出来之后，我们开始有精力做数据治理、实时特征平台和链路稳定性优化，这些才是平台团队存在的真正意义。降本不是目的，把省下来的钱和人力投入到更有价值的事情上，才是这一整轮改造最有回报的部分。

最后分享一点个人体会：做降本方案选型时，不要只盯着“每GB单价”“每QPS成本”这种孤立数字，一定要把运维人力、故障损失和扩容等待成本全部折算进去。我们这套方案能顺利落地，很大程度靠的是“先把账算明白，再动手做技术选型”。如果你所在团队也正在被自建HBase和Redis的运维成本困扰，不妨先按我上面的成本模型做一次盘算，再决定是否走Lindorm加Tair的路线。欢迎有类似迁移经验的团队一起交流，毕竟降本这条路，没有哪家是一次走通的。