是否需要追逐潮流！基于Hadoop的感想

   近几年大数据的概念被炒的红红火火，各种云应运而生，也有不少企业开始搭载自己的云，但是真的什么企业都需要吗？下面我要说的也仅仅是基于我目前工作的一些感想，欢迎拍砖！

   公司的主要数据是利用HBase收集的报文，整个到目前运行了一年零一两个月的时间。目前数据量是266GB（其中包含一份完全副本，实际业务数据133GB），在7月出进行数据统计时，该平台数据量为250GB（其中包含一份完全副本，实际业务数据125GB），并且通过计算可以得知，在过去14个月内，平均每月获得的数据量为9.5GB，并且7月份一个月的时间内HBase收集的报文为8GB左右。

   通过上面的描述可以看出这个业务的数据量并不大，可能很多公司tomcat一天的日志量都比这一年的总数据量要大的多。并且在前段时间对HBase内表的数据进行了一次统计，大约有700W的数据，搜索一共耗时20分钟左右。说实话，这个速度并不算快，由于节点数量的不足并不能充分发挥HBase在分布式上的有点，但是这个时间对比Oracle真的能有提升吗？

   在有了如上疑问后跟领导进行了沟通，领导要表达的是：不管是不是合适，我们要先抢占技术的高峰，就算目前数据量不大以后也会变大。根据领导的回答我也算明白了，当初在构建这个平台的时候基本没有考虑到这个平台是否符合业务逻辑的需求（PS:虽然我在这个公司也不想涉及到业务逻辑方面的内容），只是因为这个东西很新，很火。

   在和领导沟通后，我简单的了解了一下表内的内容：时间、报文类型（公司设定的发送报文、接受报文、企业报文用不同的编号来表示）、报文XML文件。说真的，存储的方式对于分析来说作用很小，因为XML文件没有解析，所以有了第二次沟通。

   在第二次沟通前我了解了一下关于XML解析方面的内容，可以通过Java程序解析后再报错，同时Hadoop在某一个版本是确实存在着XML解析的类，不过后来被取消了。沟通的结果就是领导让我去想办法弄XML的解析，说真的这东西我真力不从心。后来的几次沟通也是这样（内容多种多样，包含HBase的API接口压力测试，云平台改进想法文档等等），最后都是无功而返。

   通过多次的沟通，我始终觉得领导从来没有在这个系统是不适合Hadoop上进行过思考，每次一说到这个，就开始跟我说百度、谷歌每天要对几个PB的文件进行分析，而我们对百十来个GB的数据束手无策。但是真的是束手无策吗？每次沟通我都会说一些想法，最后也都被很容易得PASS了，原因大部分都是因为他试验过效率不行等原因。

   一个月就算多说10个G的数据量，平均到每天也就不足350MB。真的都放到Oracle甚至MySQL里面每天跑个列表出来应该并不困难。而坚定的认为Hadoop在架构上比那两个更先进，所以效果就更好。这里我打个比方吧！

   一个人走路的速度比骑车的速度慢，骑车的速度又比汽车的速度慢！同样是5公里，走路可能需要半个小时，骑车需要15分钟，汽车需要10分钟。但是如果你想从一个楼到对面的楼里面去那？你会选择开走路、汽车还是骑车那一种？如果你要是去1公里外的报亭买报纸你会选择开走路、汽车还是骑车那一种？如果你去50公里外的地方郊游你会选择开走路、汽车还是骑车那一种？

   现在的情况是：

   小部分企业给人的感觉就是开着汽车去隔壁串门！

   大部分企业跟人的感觉是开着汽车去一公里外的地方买报纸！

   极小一部分的企业是开着汽车去郊游！