BigData 学习记录（四）

标签：后台运行   bzip2   情况   大于   red   默认   也会   text   val   

HDFS的IO操作

1.数据完整性

2.文件格式

1 SequenceFile

SequenceFile是Hadoop API 提供的一种二进制文件，它将数据以<key,value>的形式序列化到文件中。这种二进制文件内部使用hadoop 的标准的Writable 接口实现序列化和反序列化。它与Hadoop API中的MapFile 是互相兼容的。Hive 中的SequenceFile 继承自Hadoop API 的SequenceFile，不过它的key为空，使用value 存放实际的值， 这样是为了避免MR 在运行map 阶段的排序过程。如果你用Java API 编写SequenceFile，并让hive 读取的话，请确保使用value字段存放数据，否则你需要自定义读取这种SequenceFile 的InputFormat class 和OutputFormat class。

2.RCfile

RCFile是Hive推出的一种专门面向列的数据格式。 它遵循“先按列划分，再垂直划分”的设计理念。当查询过程中，针对它并不关心的列时，它会在IO上跳过这些列。需要说明的是，RCFile在map阶段从远端拷贝仍然是拷贝整个数据块，并且拷贝到本地目录后RCFile并不是真正直接跳过不需要的列，并跳到需要读取的列， 而是通过扫描每一个row group的头部定义来实现的，但是在整个HDFS Block 级别的头部并没有定义每个列从哪个row group起始到哪个row group结束。所以在读取所有列的情况下，RCFile的性能反而没有SequenceFile高。

3.Avro

Avro是一种用于支持数据密集型的二进制文件格式。它的文件格式更为紧凑，若要读取大量数据时，Avro能够提供更好的序列化和反序列化性能。并且Avro数据文件天生是带Schema定义的，所以它不需要开发者在API 级别实现自己的Writable对象。最近多个Hadoop 子项目都支持Avro 数据格式，如Pig 、Hive、Flume、Sqoop和Hcatalog。

4.文本格式

5.外部格式

SequenceFile无论在压缩和非压缩的情况下都比原始纯文本TextFile大，其中非压缩模式下大11%， 压缩模式下大6.4%。这跟SequenceFile的文件格式的定义有关： SequenceFile在文件头中定义了其元数据，元数据的大小会根据压缩模式的不同略有不同。一般情况下，压缩都是选取block 级别进行的，每一个block都包含key的长度和value的长度，另外每4K字节会有一个sync-marker的标记。对于TextFile文件格式来说不同列之间只需要用一个行间隔符来切分，所以TextFile文件格式比SequenceFile文件格式要小。但是TextFile 文件格式不定义列的长度，所以它必须逐个字符判断每个字符是不是分隔符和行结束符。因此TextFile 的反序列化开销会比其他二进制的文件格式高几十倍以上。

RCFile文件格式同样也会保存每个列的每个字段的长度。但是它是连续储存在头部元数据块中，它储存实际数据值也是连续的。另外RCFile 会每隔一定块大小重写一次头部的元数据块（称为row group，由hive.io.rcfile.record.buffer.size控制，其默认大小为4M），这种做法对于新出现的列是必须的，但是如果是重复的列则不需要。RCFile 本来应该会比SequenceFile 文件大，但是RCFile 在定义头部时对于字段长度使用了Run Length Encoding进行压缩，所以RCFile 比SequenceFile又小一些。Run length Encoding针对固定长度的数据格式有非常高的压缩效率，比如Integer、Double和Long等占固定长度的数据类型。在此提一个特例——Hive 0.8引入的TimeStamp 时间类型，如果其格式不包括毫秒，可表示为”YYYY-MM-DD HH:MM:SS”，那么就是固定长度占8个字节。如果带毫秒，则表示为”YYYY-MM-DD HH:MM:SS.fffffffff”，后面毫秒的部分则是可变的。

Avro文件格式也按group进行划分。但是它会在头部定义整个数据的模式（Schema）， 而不像RCFile那样每隔一个row group就定义列的类型，并且重复多次。另外，Avro在使用部分类型的时候会使用更小的数据类型，比如Short或者Byte类型，所以Avro的数据块比RCFile 的文件格式块更小。

3.压缩

1 gzip压缩

优点：压缩率比较高，而且压缩/解压速度也比较快；hadoop本身支持，在应用中处理gzip格式的文件就和直接处理文本一样；有hadoop native库；大部分Linux系统都自带gzip命令，使用方便。

缺点：不支持split。

应用场景：当每个文件压缩之后在130M以内的（1个块大小内），都可以考虑用gzip压缩格式。譬如说一天或者一个小时的日志压缩成一个gzip 文件，运行mapreduce程序的时候通过多个gzip文件达到并发。hive程序，streaming程序，和Java写的mapreduce程序完 全和文本处理一样，压缩之后原来的程序不需要做任何修改。

2 lzo压缩

优点：压缩/解压速度也比较快，合理的压缩率；支持split，是hadoop中最流行的压缩格式；支持hadoop native库；可以在linux系统下安装lzop命令，使用方便。

缺点：压缩率比gzip要低一些；hadoop本身不支持，需要安装；在应用中对lzo格式的文件需要做一些特殊处理（为了支持split需要建索引，还需要指定inputformat为lzo格式）。

应用场景：一个很大的文本文件，压缩之后还大于200M以上的可以考虑，而且单个文件越大，lzo优点越越明显。

3 snappy压缩

优点：高速压缩速度和合理的压缩率；支持hadoop native库。

缺点：不支持split；压缩率比gzip要低；hadoop本身不支持，需要安装；linux系统下没有对应的命令。

应用场景：当mapreduce作业的map输出的数据比较大的时候，作为map到reduce的中间数据的压缩格式；或者作为一个mapreduce作业的输出和另外一个mapreduce作业的输入。

4 bzip2压缩

优点：支持split；具有很高的压缩率，比gzip压缩率都高；hadoop本身支持，但不支持native；在linux系统下自带bzip2命令，使用方便。

缺点：压缩/解压速度慢；不支持native。

应用场景：适合对速度要求不高，但需要较高的压缩率的时候，可以作为mapreduce作业的输出格式；或者输出之后的数据比较大，处理之后的数据 需要压缩存档减少磁盘空间并且以后数据用得比较少的情况；或者对单个很大的文本文件想压缩减少存储空间，同时又需要支持split，而且兼容之前的应用程 序（即应用程序不需要修改）的情况。

4.序列化和数据类型

本质上讲,就是数据保存到虚拟机之外,然后又被读到虚拟机内.如果仅仅是保存,不关心能读进jvm的话,就不关心序列化问题了.正是因为需要被读进jvm,所以必须识别写出、读入的数据格式、字符顺序等问题。因此序列化也就是比较重视的事情了。拿密码来打比方：序列化就像加密，反序列化就像解密。只加密不解密那肯定是不行的。hdfs作为分布式存储系统必然涉及到序列化问题。http://www.thebigdata.cn/Hadoop/14291.html

Writable类对Java基本数据类型提供封装，short和char除外（两者可以存储在IntWritable中）。所有的封装包含get()和set()两个方法用于读取或设置封装的值。

Text是针对utf-8序列的Writable类。一般可以认为它等价于java.lang.String的Writable。
NullWritable是一个非常特殊的Writable类型，序列化不包含任何字符，仅仅相当于个占位符。你在使用mapreduce时，key或者value在无需使用时，可以定义为NullWritable。
ObjectWritable和GenericWritable。
在org.apache.hadoop.io包中，有4个集合类：ArrayWritable，TwoDArrayWritable，MapWritable和SortedMapWritable。

BigData 学习记录（四）

标签：后台运行   bzip2   情况   大于   red   默认   也会   text   val   

原文地址：http://www.cnblogs.com/L907933970/p/7215913.html