大数据SRE的总结（5）－－ 常规运维之 治数据增长

今天来谈hadoop日常运维中的“治数据增长”。

hdfs data growth , too fast. terrible!

背景

现今,规模比较大的互联网公司中，总数据量能达到10pb，甚至几十pb的数据量的公司，我认为中国已经超过了20家以上了。这些公司中，日数据增长达到100tb+的，都有很多家了。

所以我们每天都要观察集群的数据增长，观察是否有哪一天，哪个路径增长过猛了，是否增长了很多垃圾数据，要深挖下去，看看是不是可以删掉无用的数据。

我们还要做“容量预估“,把未来的数据增长规划出来。依靠数据增长斜率，一般计算出未来一个季度后的数据量，把机器采购需求汇报出去。

在上一篇“大数据SRE的总结（4）－－基于FsImage的HDFS数据深度分析”中，我们创建了基于fsimage的hdfs数据分析仓库。并创建了一些分析图表，比如“hdfs增长趋势图”，充分的解决了发现“数据增长异常”的问题。 这一篇，我们会讲，怎么观察“数据增长”，怎么治理“数据过快增长”,以及怎么清理“无用的冷数据”和 怎么管理“数据存活时间”。

hdfs增长趋势图

我们先来算一比细账。

当下，一台不错的datanode机器配置，能挂12-16块盘。每块盘挂上比较大的3tb的硬盘。单台机器的存储量大致在50tb。按每天增长100tb算，就是2台机器。按每天增长500tb，就是10台机器。Terrible !!!

数据的疯狂增长，会暴露出几个问题：

1.加机器对公司的财务预算要求很高

服务器再便宜，也是钱。一周买几十台服务器，这种速度，我相信财务运转再好的it公司也不愿意看到数据增长失控。

2.对集群负载的压力

hadoop 虽然是一个可以水平扩展的技术栈，大多数的分布式系统也都是把“水平scalable”作为主要的功能点设计的。 但是是否真的在工程当中，可以“无限水平扩展呢”？ 首先在hadoop当中，有一些“master节点”，这些master节点要实时的和所有“slave结点”保持心跳通信。

在集群规模比较小的时候，由于“心跳”只是简单的网络通信，且所有的datanode都互相错峰汇报“心跳”。 所以网络元数据交换，并不是hadoop系统水平扩张的瓶颈。但是在hadoop集群的规模达到了大几千，甚至上万台后。网络就是namenode的瓶颈。 这些心跳的rpc请求，会和“用户client”的rpc请求，一起抢占namenode有限的cpu资源。

3.对运维团队的运维压力

每周／月都要安装新机器，加入hadoop集群。做这些事情，是重复／无聊的。即使自动化做的再好，参考(大数据SRE的总结（1）－－部署),也要人来处理某些环节。脏活累活对追求“高技术密集度”的精英工程师团队，是有危害的。

那么我们为什么会有这么多的数据增长问题呢，删掉无用的数据不就行了么？这个事情在公司内部很难做嘛？

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

为什么这个问题 (question)在公司里难做？

针对数据的增长，hadoop admin是应该对此任务负责的。但这个事情在很多公司并没有做好，为什么呢？

Q1. 一些公司在自己的数据量级并不是很大的时候，不愿意重视这个问题。与其请2个人去做这个事情，花掉半年时间。 不如先把钱买机器。这大多发生在 b轮／c轮的公司。 业务增长是主要矛盾。数据每天增长5t，两个程序员半年的成本确实大于买一些机器先解燃眉之急。 等到公司业务越来越大，问题暴露的越来越严重时，才开始意识到严重性，这往往为时有点晚。建立整套的hdfs分析系统和报表系统，也不是一时半会就能搞定的。

Q2. 受限于管理上的问题。公司里各个“业务事业部“和 “基础架构部”是平级的，那作为“基础架构部”的普通员工，哪怕是“基础架构部”的领导，都很难推动其他“业务部门”去clean他们的数据存储。比如：

“业务部门”总认为自己的核心任务是业务开发，对公司产生利益更大。因此在做数据清理的任务排期是，总是靠后，或者设定为低优先级，总有“干不完”的开发任务。所以清理数据在公司内部很难推动。

Q3. hadoop admin 有足够的证据，摆在“业务部门”面前，让他们删除冷数据嘛？

“业务部门”通常会这样搪塞：

我们带着这些问题，来继续往下走。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

Q1似乎是一个很难避免的问题，^_^需要CTO有掌舵的能力，那我希望有志于利用起hadoop技术栈的中小公司cto在看了这篇文章后，都能增加这个意识.

Q2是管理上的问题。所以一般牵扯到制度上的变革，是最好要involve更高层的领导的。多和高层提“成本”，提“省钱”，少提“技术”。我认为高层是会意识到这个问题的价值的^_^。

Q3才是我们这篇文章的重点。即如何摆事实，如何拿出证据证明我们可以针对哪些path做数据优化呢？ 哪些path可以删掉？哪些path应该加data retention 策略？

－－－－－－－－－－－－－－－－－－－－－－－－－－－

行为(Action)

我们需要定期进行一些行为，来保持集群的数据可控。

1.每日行为

每天来到公司，做这样几件事：

2.季度行为

每个季度结束时 ：

－－－－－－－－－－－－－－－－－－－－－－－－－－－

要做到上述行为，我们要对每个team，每个path的“数据增长”都有详尽的数据支持。

我们来想想，在理想情况下，有了哪些数据，我们就能搞定？

针对“每日行为”,我们需要:

1. 每天增长最大的文件是哪些？

2. 针对确定的“异常日增长路径”，能查到这个路径的历史数据增长，要知道“平均增长值”，才能看出“某日增长量为异常”，然后要能查到其下哪个子路径贡献了最大的增长。进一步深入查找问题。

针对“季度行为”，我们需要：

所有“数据团队”对 集群存储的使用情况。要按hdfs的使用量做kpi考核。每一个“数据团队”，都有哪些“重要路径”，我们还需要知道这些路径的“增长状况怎么样”。

2. 针对一个team新增的“异常增长路径”。我们要能查到这个路径的历史数据增长，要知道“平均增长值”，才能看出“某日增长量为异常”，然后要能查到其下哪个子路径贡献了最大的增长。进一步深入查找问题。

3. 针对“某些”很大的，size很久没有变化过的folder，我们要知道这个folder最后的访问时间是什么时候，我们要知道这个folder下，超过半年没访问过的文件占比有多少。超过1年没访问过的文件有多少。这样我们才能和所属team联系，优先决定是否能删除他？

在上一篇的 大数据SRE的总结（4）－－基于FsImage的HDFS数据深度分析 ，我们建立了hdfs数据仓库。这相当于我们存下了hdfs每一天的快照。那么首先，每一条path的元数据历史问题解决了。 再说team level，每一个team的数据，都是由一些文件夹下的数据组成的。

比如“推荐系统团队”，在/hive/warehouse/reco.db下，所有的推荐相关的表数据都存在于这个下面. 另外/user/reco下也存放了很多这个组的数据，那么这几个路径，都属于“推荐数据组”的“顶级路径”。 所有“顶级路径”的“增长聚合”，就是整个组的“数据增长”。

数据组的顶级路径

每个folder，聚合其下每一个文件的last_access_time,作为最终这个folder的last_access_time.

这个功能对hive表非常好用。 有些hive表很久都没有人访问过。后面我也会单独讲如何清理hive表。

－－－－－－－－－－－－－－－－－－－－－－－－－－－

例子：

我用我司的自动化运维系统中的一些报表来做解决问题的展示。

这些报表，都是我们根据解决问题的方法论，创建出来的。我们希望贯彻“让一切人的决策基于数据”这一宗旨。让我们判断问题，找到问题，甚至说服“数据团队”，都用data driven.

每日行为例子

1.查看集群每日增长，发现没什么大问题

2.查看增长贡献，发现几个/user下的用户增长过猛

3.查看这个路径，与本路径历史增长做比较，发现确实昨日是个不正常的增长。

4. 分析具体是什么子文件导致了这个目录的异常增长。

原来是这个用户删除了一些其他路径的大文件，划归到user目录自己的~/.Trash下了，那这次就不用太担心大数据数量级，因为过一天后hdfs就会自动清理掉~/.Trash下的垃圾文件了。

季度行为例子

1.分析“数据团队”季度增长量

可以看到：

TeamA的数据总量很大，环比增长也很大，是首要的分析目标。

TeamB 和 TeamC 相比，虽然TeamB绝对值增量比TeamC大不少，但还是一个数量级，但TeamC环比增速太高，很可能业务上发生了很大的变化，所以 TeamC是第二目标。

在运维人员有限的工作时间内，一定要把“精力”花在刀刃上。对一个Team的数据进行深度分析，往往要用去个把小时，一定要在单位时间上产出最大化。

2.深度分析Team数据。

深度分析，也是遵循“单位时间产出最大化，抓最主要矛盾”这一思想。

比如还是拿我司的“推荐“团队做例子：

这些所有的顶级路径，都代表了某种业务的“细分”顶级路径。

在每个细分“顶级路径”下，我们要观察：

还是拿recoteam 数据来举例子：

根据数据统计，我们分出第一轮目标 和 第二轮目标。

第一个路径：hdfs://beaconstore/user/hadoop/reco/report

他的特点是，每日增速固定。 但最近访问时间“很新”。且“平均文件大小”偏小。

所以策略可能是 ： 1.“每日数据量优化” 2.“减少天分区数”

3.未来对“文件平均大小”做优化。因为文件数量很多，可以节省出很多内存。

第二个路径：hdfs://beaconstore/user/hadoop/reco/report

他的特点是，已经许久不新增数据。 但最近访问时间“很新”。

所以策略可能是 ： 1.找到哪些子数据经常访问 2.删掉不访问的子数据 3. 是否有生命周期？有的话记得在未来删除

第三个路径：hdfs://beaconstore/user/hadoop/reco/online_log

他的特点是，很久很久不新增数据。 且最近访问时间“很老”。

策略是 ： 1.建议删除

可以看出，不通的hdfs路径，其存在的问题不尽相同。真的是要具体问题具体分析。

如果，通过分析“第一目标清单”，已经能够达到控制集群存储的目的，大幅降低数据存储。那么可以适当的忽略“第二目标清单”，记住那个目标“单位时间产出比”。 这个时候可以把时间省下来做更多有意义的事情。

3.最后我们会出具一个report。给相关的组发送email，指明应该做哪些优化。

总结

总之，为了防患“无止境的数据增长”，观数据增长这件事，最好每天来公司都做一下。每天5分钟，健康好好。每个季度也要好好的review每个数据team的增长。

这里总结了一些通用的原则：

（编辑：广州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!