大数据存储平台调优之Hadoop优化

大数据存储平台调优之Hadoop优化

在上节搭建完集群、完成Linux系统配置(优化)后以及建好HDFS上的目录后，我们接下来需要对Hadoop集群做一些优化的工作。我们从两个方面来说：一是HDFS存储方面，一是计算方面

 1、 HDFS方面：

1> 存储格式的选择

对于分析类型的业务来说，最好的存储格式自然是列存储，因为数据量巨大，只扫关心的数据列无疑具有很大优势。目前hadoop生态中有两大列存储格式，一个是由Hortonworks和Microsoft开发的ORCFile，另一个是由Cloudera和Twitter开发的Parquet。Parquet是面向分析型业务的列式存储格式，最早由Twitter和Cloudera合作开发，2015年5月升级为Apache顶级项目

 ORCFile是在RCFile的基础之上改造的。RCFile虽然号称列存储，但是只是“按列存储”而已，将数据先划分成row group，然后row group内部按照列进行存储。这其中没有列存储的一些关键特性，而这些特性在以前的列式数据库中早已用到。好在ORCFile已经弥补了这些特性，包括：

块过滤与块统计：每一列按照固定行数或大小进一步切分，对于切分出来的每一个数据单元，预先计算好这些单元的min/max/sum/count/null值，min/max用于在过滤数据的时候直接跳过数据单元，而所有这些统计值则可以在做聚合操作的时候直接采用，而不必解开这个数据单元做进一步的计算。

更高效的编码方式：RCFile中没有标注每一列的类型，事实上当知道数据类型时，可以采取特定的编码方式，本身就能很大程度上进行数据的压缩。常见的针对列存储的编码方式有RLE（大量重复数据），字典（字符串），位图（数字且基数不大）等等

Parquet的设计原理跟ORC类似，不过它有两个特点：

 通用性：相比ORCFile专门给Hive使用而言，Parquet不仅仅是给Impala使用，还可以给其他查询工具使用，如Hive、Pig，进一步还能对接avro/thrift/pb等序列化格式。

基于Dremel思想的嵌套格式存储：关系数据库设计模式中反对存储复杂格式（违反第一范式），但是现在的大数据计算不仅出现了这种需求（半结构化数据），也能够高效的实现存储和查询效率，在语法上也有相应的支持（各种UDF，Hive的lateral view等）。Google Dremel就在实现层面做出了范例，Parquet则完全仿照了Dremel。

         只读取需要的数据，跳过不符合条件的数据，降低I/O

         压缩，一般采用snappy压缩

         查询性能较xx提升30倍，存储空间节省70%

2> 传输使用AVRO

支持二进制编码、支持JSON编码

         支持压缩

         支持数据排序

         序列化速度快

 3>大量小文件处理

　　因为Namenode把文件系统的元数据放置在内存中，所以文件系统所能容纳的文件数目是由Namenode的内存大小来决定。当文件数到数十亿时，对于当前的硬件水平来说就没法实现了。还有一个问题就是，因为map task的数量是由splits来决定的，所以用MR处理大量的小文件时，就会产生过多的map task，我们知道在Hadoop中map任务或者reduce任务的都是进程方式启动的，启动进程本身需要花费几秒时间,因此针对小文件的改进策略，有几种方法：

·     利用Har等方式归档小文件，这个方法的原理就是把小文件归档起来管理。这种方法的缺点在于:如果想找回原来的小文件内容，那就必须事先保留原始小文件与归档文件的映射关系

·     既然1个Master有影响，那么能不能来个多Master设计，最新的Hadoop也有这方面的实现，但生产环境上使用这种方法的公司并不多，应慎用

 4>fs.trash.interval：

• 说明： 开启HDFS文件删除自动转移到垃圾箱的选项，值为垃圾箱文件清理过期数据文件的时间，默认值是0，单位是分钟。强烈建议开启此选项，以防错误删除重要文件。

dfs.blocksize：

• 默认值：134217728
• 说明： HDFS里一个文件块的大小，Hadoop2.7中默认128M。太大会有较少map参与计算，耗时间较长，太小的话需要较多的map个数资源，而且文件太小会浪费namenode内存。建议根据业务数据文件大小进行设置。

dfs.namenode.handler.count：

• 默认值：10
• 说明：