打开网易新闻 查看精彩图片

一家中型互联网公司每月数据账单从80万涨到140万,CTO开会时把BI团队骂了20分钟。最后发现,70%的钱烧在了没人看的冷数据上。Google基础设施团队负责人Mayank Singhi最近公开了一套内部方法论,直接把某业务线的存储成本砍了47%。

这不是什么"降本增效"的口号,是实打实的工具链改造。Singhi管的是Google最底层的那批系统,他说的话里没有"赋能"和"抓手",只有具体的数字和踩过的坑。

数据成本的"冰山模型":你看到的只是10%

数据成本的"冰山模型":你看到的只是10%

Singhi画过一张图,把数据生命周期切成六段:采集、存储、处理、分析、归档、销毁。大多数公司盯着分析层的BI工具砍价,结果省下来的钱不够存储层涨价的零头。

他举了个例子:某团队把查询引擎从A换成B,计算成本降了15%,欢呼了一周。三个月后账单反弹,因为新引擎的默认配置把中间结果全存成了热存储,存储费涨了22%。

数据成本是个跷跷板,按下去一头,另一头必然翘起来。

Google内部的解法是把成本拆解到"数据温度"维度。热数据(7天内被访问)放在SSD,温数据(7-90天)落盘到标准云存储,冷数据(90天-2年)进归档层,冰数据(2年以上)直接上磁带。每一档的单价差10倍起。

但自动化分层不是开开关关那么简单。Singhi团队踩过一个坑:某条业务线的"冷数据"在季度末突然被财务部门批量调取审计,从归档层拉回热存储的取回费用,比直接存一年还贵。

最后他们加了一条规则:归档前必须预判"被批量调取的概率",用机器学习模型打分。听起来很Google,但Singhi说模型本身只占20%效果,80%是逼着业务方在数据入湖时就填好"预期生命周期"的元数据。

打开网易新闻 查看精彩图片

计算成本的"吸血鬼":那些跑不完的僵尸任务

计算成本的"吸血鬼":那些跑不完的僵尸任务

存储成本看得见,计算成本像水一样流走。Singhi的团队扫描过内部集群,发现31%的计算资源被"僵尸任务"吃掉——作业失败了没人管,重试逻辑写成死循环,或者干脆是两年前的实验代码还在跑。

他们写了一个简单的检测器:连续24小时CPU利用率低于5%且没有产出写入的任务,自动发警告给owner,72小时无响应就强制终止。就这一个规则,清理掉了12%的无效计算。

更隐蔽的是"过度分区"。某日志表按小时分区,三年积累了2.6万个分区,每次查询要扫几百个元数据文件。Singhi的团队把分区粒度改成天,配合自动合并小文件,查询时间从4分钟降到23秒,计算成本降了60%。

分区不是越细越好,元数据本身也会成为瓶颈。

Singhi提到一个反直觉的发现:压缩算法的选择对成本的影响,比硬件升级还大。某业务线把Snappy换成Zstandard(一种无损压缩算法),压缩率从2.1x提升到4.3x,存储直接腰斩。代价是CPU占用涨了8%,但存储省下的钱够买三倍的服务器

被忽视的"数据债务":没人敢删的东西

被忽视的"数据债务":没人敢删的东西

Google内部有个指标叫"数据负债率":存储成本里有多大比例是"没人知道有没有用,但没人敢删"的数据。Singhi说这个数字在大多数团队超过40%。

他们推了一套"数据TTL(生存时间)即服务":数据入湖时必须声明过期时间,系统到期自动清理,想保留要申请延期。听起来简单,阻力极大。某产品线负责人直接冲到Singhi办公室,说"万一删了出事故谁负责"。

打开网易新闻 查看精彩图片

Singhi的回应是:把"保留数据"的成本显性化。以前存储费是基础设施团队统一付,现在按业务线分摊,而且冷数据的取回费用单独记账。那个负责人看了账单后,主动把3年前的测试数据清了。

这套机制里有个设计细节:延期申请不是走工单,而是在数据目录里点一下,系统自动发邮件给相关方,7天无反对就通过。Singhi说"降低阻力比增加审批更重要",人天生厌恶损失,但懒得反对。

成本优化的"最后一公里":谁为优化买单

成本优化的"最后一公里":谁为优化买单

技术方案再漂亮,落不了地等于零。Singhi分享过一个失败案例:某存储优化项目预计省200万美元,方案评审全票通过,实施时发现需要6个团队配合改造数据管道,排期排到18个月后。项目黄了。

后来他们改了机制:成本优化项目必须绑定"实施owner"和"业务收益方",预算从业务方出,省下来的钱按比例返还。一个联邦学习团队为了拿返还,两个月内把特征存储从PB级砍到TB级。

Singhi总结了一套检查清单:优化前确认数据访问模式(读多写少还是读写均衡)、确认SLA容忍度(延迟从100ms到500ms能不能接受)、确认回滚方案(优化失败怎么切回去)。

没有回滚方案的优化,是赌博不是工程。

他最后提到一个还在实验中的方向:用大型语言模型(LLM)自动生成数据生命周期策略。输入是数据schema和业务描述,输出是推荐的分层策略和TTL设置。早期结果显示,对结构化数据的推荐准确率能达到78%,但半结构化数据(比如嵌套JSON)还是一塌糊涂。

Singhi的原话是:"LLM现在能帮我们写80%的草稿,但最后20%的判断还得靠人。数据成本优化没有银弹,只有一个个具体的选择和代价。"

你的团队上个月数据账单里,有多少比例是"不知道有没有用但不敢删"的?