百度手机助手存储资源优化实践

发表于 2年以前 | 总阅读数：425 次

导读：本文主要总结一下笔者之前做的关于业务存储资源优化的整个过程，正所谓前事不忘，后事之师，希望以文中的例子为引，能够总结出一些如何避免坑以及如何填坑的方法论。

全文19135字，预计阅读时间26分钟

一、业务介绍

为了更好的理解下面介绍的点，先对业务的一些概念进行简单介绍。- 「百度手机助手」：百度手机助手是在Android系统上的手机应用分发平台，管理开发者上传的Android应用，经过转存等处理后将应用分发到C端。

「增量更新（省流量更新）」：如上面的业务框图所示，开发者将应用传到开发者平台（app.baidu.com), 为了保障下载的稳定性以及速度，助手会将开发者的应用会转存到百度内部的存储服务上，叫做BOS(Baidu Object Storage)。为了节约用户下载的流量，助手启动了增量更新的能力。增量更新是指新版相对旧版生成差异包（下文叫patch包），在更新软件时，将旧版本的包与差异包合并成为最新版本的过程。相对全量更新更省流量，降低了用户更新软件的流量成本。

在优化的时间点，整个助手的存储占用已经达到了几P的量，每年的预算费用近千万。从业务上进行数据分析，通过分析对应业务场景的mysql库，库中会记录对应应用的大小。分析后的大致数据如下：

这里面会发现应用patch包的占用非常大，同时发现存储总量-已知存储后，仍有P级别的存储是未知的。这里应用patch包的存储占用是否符合预期需要看一下。所以，为什么优化就有了几个合理的理由：

下面就展开整个清理的过程。

优化的第一步就是分析要怎么优化，把闲置的存储找出来，然后优化它。用普通话来说就是猜。此处的闲置，可以定义为消耗的存储带来的价值不符合预期。存储的价值是什么？分几部分来说。

「应用存储」 统一转存到百度，首先安全，如果使用第三方的服务，存在被偷梁换柱的风险；其次稳定，可以自己对存储以及下载进行优化；最后可以基于内部存储做一下定制化的能力，比如动态追加数据等。应用存储在百度的价值无可替代，简单来说是钱花得值。
「应用patch包」 对这部分的价值定义，在用户节省下载流量的场景下有价值，否则没有价值。即如果我们生成了patch包，占用了存储，但用户却没有升级该版本，那么就是没有价值。
「不知道去哪了的存储」 当然要挖出来，看看是哪家妖怪。

有了初步的方向后，要进行更准确的确认，判断收益空间。从下面两个角度进行验证。

「存储占比」 整个存储的object在优化之前差不多亿+条，没有短时间内快速获取全部object的方式，采用了抽样的方法，拉取了线上30W条数据进行初步分析,下面是存储空间占用的分布

▲存储空间分布

▲更新流量分布

有了上面的数据，可以从基本面看出，省流量更新的存储消耗更大，但是实际的流量价值却很低，基于此可以确定要对省流量更新的patch包下手了。

就像把大象装进冰箱一样，开门-放大象进去-关门。优化也不是上来就动手把存储清除，整个过程参考大象装冰箱的思路，分为三步:

正所谓 “知己知彼百战百胜”，做一件事情降低风险的第一要领，应该是把事情摸清楚。对于存在几年的老业务，如何去摸底，总结下来有几点经验。

「内部文档」无论是技术文档还是需求文档，尽量都去看一遍，同时带着问题看，把自己代入到写文档的视角里，多思考下为什么文档是这样的，这样可以尽可能多的挖掘出一些疑问点。
「代码」 核心的代码逻辑一定要过一遍，时间越长的代码，补丁可能越多，一些边界的场景都隐藏在代码的小角落。
「人」 找到相关的同学或者不相关的同学（第三者视角），带着基于文档和代码的疑问进行沟通、询问、刨根问底，补全思维偏差。
「产品」 基于产品功能进行回归，将文档和代码进行串联，形成清晰的代码地图。

最后，基于全面的信息梳理，完成基于数据流的业务流程图。整个过程有点像是《长夜难明》的探案过程，抓住每一个线索，完成最后的拼图。

从图中，可以看到主要的存储分为三部分，「开发者应用，客户安装应用，省流量patch包」。其中patch包的生成步骤为：

核心的数据处理流程如下：

由于是进行存储优化，那就主要关注梳理出的数据流程各个环节是否可以优化以及是否要进行优化。首先，磨刀不误砍柴工，从BOS处通过api导出全量列表，由于历史积累，共亿+条object数据。然后基于原来的增量更新策略制定出了对应的优化策略。

在梳理方案的过程中，深感项目的评估以及持续跟进的重要性。下面举几个例子简单说明下。

最初处理的时候，为了快速解决用户的增量更新的目标，设计时对全部应用一股脑的生成增量patch包，但是并没有考虑到用户是否会进行更新的场景，也就是实际的ROI。实际上只覆盖top300更新的应用，就已经能够占比93%的更新请求，但是能够减少95%的存储占用，是非常明显的对比。
在初版的策略里并没有考虑业务特性，原始的策略是取top10版本号的包和用户手机安装的包来进行生成patch，但忽略了同一版本号下会同时存在多个包（客户为了推广，同一版本的包会生成N个渠道包上传管理），也就是1对N的场景。
原来设计的初衷可能是仅生成最高10个版本的patch就好了，实际上会放大到生成几百个包，也是非常大的存储消耗。还有原来的top10的考虑是为了由于Android SDK的一些限制，某些低端机型可能无法安装高版本应用，但随着千元机的普及，这个策略也可以成为历史了。

在处理的过程发现上文提到的未知的P级别空间，发现是原来物理机迁移，自运维的数据库未迁移，导致之前的增量包虽然占用了BOS存储，但是没有在db中发现，评估对业务没有实际用途了，最后一股脑清理掉了（非常爽）。