hadoop近期学习与工作的心得与体会
hadoop近期学习与工作的心得与体会
hadoop的学习与工作按计划有序进行，根据计划第二阶段的学习可以告一段落，现在对这一阶段的学习与工作做个总结。
首先，我讲一下我理解的hadoop是什么。我理解的hadoop是一个生态圈，这个生态圈有核心，有周边。核心就是hadoop的mapreduce计算框架与hdfs分布式文件系统。周边呢，有列式数据库hbase，数据仓库系统hive，与脚本语言pig以及机器学习工具mahout。此外还有重要的数据加载工作flume以及chukuwa，还有其它的组件目前还尚未了解。
那么为什么使用hadoop呢？
我从hadoop的两个核心组件mapreduce计算框架与hdfs文件系统来理解。
hadoop的只有一个小小的抱负，那就是计算搜索引擎中的“页面价值”（page rank），它将网页的海量页面抽象成平面向量，以页面被其它页面的引用作为向量值，假设页面数据为n，那就形成n*n的对称矩陈，可以想象页面n的值非常的大，单机运算很难求出结果，因此就需要一种分布式的计算方法来达到这一运算需求，于是就有了mapreduce。另外一个问题就是海量数据如何存放的问题以及这些海量数据的可靠性的问题，对这些问题的回答，有一些回答其中就有raid技术、网格计算以及传统rdbms等。
对于raid技术，其实是这种海量存储的一种可选方案，但是raid技术有问题，第一个问题就是raid技术并不能提高数据的吞吐能力，而海量数据明显有这方面的需要，第二个问题就是raid技术对硬件有要求，往往需要较高的性能以及同厂商同型号甚至同批次，第三个问题是一旦raid中有磁盘故障，访问速度立即大辐下降。此外raid技术实际并不完全可靠，raid中磁盘全部故障的情况并不少见。
以及网格计算为代表的规模处理框架可能也是一种方案，但无论是网络计算还是高性能计算都是使用SAN（存储区域）技术进行运行的，也就是使用共享存储的方式进行，那么这种方式存在的问题显而易见，第一个问题就是数据必须本地化才能够执行，那么节点的网络带宽就是该系统的瓶颈，只能访问百G规模的数据，而这个规模才是mapreduce开始发力的规模。
那么传统rdbms系统的表现如何呢？
在说明这个问题之前我们先谈一下硬盘，时至今日，我们在存储大规模数据时，仍然使用硬盘。硬盘的有两个问题至今未有实质性的解决。
第一，硬盘容量与访问速度的不平衡发展，我们用一个列表来做对比。
| 年分 |
容量 |
传统速率 |
用时 |
| 1990年 |
1370MB |
4.4MB/s |
5分钟 |
| 2010年 |
1TB |
100MB/s |
2.5小时 |
第二，硬盘寻址速度与传输速度的不平衡发展。也就是磁盘寻址时间的提升远远不及传输速率的提升，其原因是寻址是物理操作，而传输则取决于硬盘的带宽。
那么再说一下rdmbs系统，rdmbs系统的数据一般行式存储，以oracle为例，分段区块存储，一行数据往往比较小，为了精确定位到某一条具体的数据，oracle把块设置的比较小，通常为一个或多个操作系统块。那么方式寻址就是决定其性能的主要因素，而不是访问的数据，因为比较小。如果是少量数据查询或更新，那么就有比较有优势，因为她采用B树索引精确定位。但是如果是大量的数据查询或者更新，这种方式就比较落后，因为她需要不停地使用“排序/合并”(sort/merge)来重建数据库。
那么， hadoop是如何解决这些问题的呢？在存储上，hadoop采用了类似raid的技术，那就是冗余技术，不同的是，hadoop hdfs采用了更高效合理的做法，以两份冗余为例，hdfs上会有三份数据，hadoop把第一份数据保存在本地上，就是执行保存操作的那个hdfs客户端上，一份保存在与第一份数据在同一机架的不同结点上，第三份则是保存在不同机架的随机结点上，另外对大文件以一定的算法进行分割后再进行保存，这就大大的降低了数据丢失的可能性了。 该存储方式也解决了分布式运算中存在的数据本地化的问题，当任务降临时，hadoop会优先把任务本地化，假设集群中的所有结点都有这个任务源文件的分片，那么就可以在本地执行任务，而不用进行数据的传输了，从而节省了带宽，这种运算方式对比网格计算就能看到它的优势所在了。
在应对磁盘在容量与传输速度以及寻址与传输发展不平衡的问题上，hadoop采用了大块的存储方式，早期hdfs的版本为64MB，而在hadoop2，即yarn的版本上，我观察到其默认的块大小已经为128MB了。 hadoop这种设计方式是为大数据的高吞吐而设计的，这种设计的依据是大数据往往以整个数据集作为分析的目标，此时磁盘寻址已经不是主要问题，带宽则是限制其性能的主要因素了。
hadoop的这种设计有效规避了rdbms由磁盘寻址带来的性能问题。但hadoop的这种技术偏好是极其明显的，一是高吞吐带来的高延时，二是只适合于类似于系统日志的一次写入多次读取的场景，而对于随机读写的场合，则力所不及。
那么，hadoop用于何种场合呢？
hadoop最初仅仅有一个小小的抱负，那就是从海量的网页中取出最有价值的部分网页提供给用户，而今却是广泛应用于各行各业了。大致有以下几种企业会用：
搜索引擎企业，yahoo、百度等。
互联网企业，如阿里、京东、腾讯等。
电信运营商，移动、电信等。
金融，四大行、以及部分保险公司。
快递，近些年，快递行业的数据量也是海量增长。
电力水力，智能电力、智能电网等。
此外，hadoop有明显的技术偏好，适用离线日志分析、大数据批量处理的场景，那就意味着不能对响应速度有要求。如果需要实时分析、实时处理的场景，恐怕需要其它框架。
最后，结合实际的工作，说一下咱们这边hadoop的使用情况。
许纪给出源数据文件和转换程序，我们通过转换程序生成csv数据文件，保存在windows的服务器上。 hadoop集群上有三个节点，我在三个节点上安装了samba服务，建立了hadoop集群各节点与windows服务器的磁盘文件映射，这个工作是为了节省一部分磁盘空间。在hadoop集群各节点上又安装了lzo压缩程序。有了samba服务之后，hadoop节点可以访问windows的文件了，我们把csv数据文件所在的目录挂载到hadoop节点上，并使用lzo算法按年把csv压缩成一个lzo文件。然后在hdfs上按年建立一个文件夹，将生成的当年的lzo文件存放在该文件夹下， 并建立该lzo文件的索引。 hadoop集群中也加入了lzo压缩的配置，因此能够读取该lzo文件，并进行更新作业。更新作业的源程序里也指定输入格式为lzo文件，以输出为lzo文件。到这里更新操作已经完成，生成了lzo文件作为输出。在hive建表时，也指定以lzo文件作为数据来源。这样的话，我们生成的lzo文件就可以顺利地加载到hive中去。数据到hive之后，我们就可以使用hive的导出命令将id批量的导出到该节点的文件系统中，所在文件夹由samba服务的存在可以由windows服务器访问，就可以复制到磁盘或U盘中了。
该过程如下图所示：
图1
最后，谈一下这一阶段存在的问题以及困难，以及下一阶段学习与工作的计划安排。
虽然解决了部分工作，但对hadoop存在的问题和困惑还是不少的，虽然查阅了不少资料，并且也在网上请教了一些人，一些问题和困惑至今未得到解答。
首先的问题是，在做更新时，如果使用了reduce操作，在reduce操作达到33%左右时，卡住不动了，查看一下集群中的Contrainer，发现三个结点居然只有一个Yarn-master和一个yarn-child，而在map阶段通常集群中会有12个contrainer，其中有一个yarn-master，11个yarn-child。
其次，在使用MultiOutputs时，常常会交替出现如下三个错误：
1、GC overheadlimit exceeded
2、java heap spacehadoop
3、Error unableto create new native thread
查看一下内存使用情况，却没有出现内存占用特别高的情况，【网上有关于jvm最多创建多少个线程的说法】。
还有一个问题，就是中文支持的问题，目前我们的工作中只有英文，实际的分析操作有可能是中文的，如果对中文分析的话，现在的程序会报错，网上有些解决方法，但是目前没有试验成功。
最后一个问题是，当初在选型时，是以hbase作标准的，也就是说以hbase的版本选择hadoop版本，最初使用的hbase版本为hbase-1.2.1，对hadoop支持最好的是hadoop-2.5.1，所以无论在测试还是实际使用，都沿用这个版本，导致如今使用的版本过高，一些组件如sqoop-1.4.6或sqoop-1.4.5与之不兼容，目前我正考虑降低版本使用如hadoop-2.2.0。
学习与工作中也存在困难，第一个困难莫过于自己摸索，遇到如上的问题解答不了。
第二个困难是，目前的集群环境仍然在虚拟机中进行，当虚拟机过大时，会生成几百GB的大文件，如果突然断电，这些文件又没有正常关闭，那么这个虚拟机就会启动不开，并且这个大文件将无法删除，一直驻留在windows服务器上，除非重新安装系统，格式化文件。
最后，谈一下一阶段的学习与工作安排。
下一阶段主要的任务是mapreduce的编程，有人提议要研究100个场景才算熟练的编程，我认为寻找典型的场景比数目更重要吧，比如多个map或多个reduce的编程、多个job的编程、以及使用特别组件如MultiOutputs的编程等。
另外寻找实际的项目资料，看看人家是如何架构这些分析系统或者数据仓库的，各个组件间是如何联系使用的，为将来的架构工作做准备。