hadoop 有没有类似oracle 字符集编码

1、hadoop内部默认的文本读取编码设置为utf-8，你的源文件为gbk，在读取时遇到中文时是肯定要出现乱码。

解决方法有二：

（1）将你的GBK编码的文件在生成时，统一成utf-8,这是最好的方式，方便国际化。

（2）重写一个你的hadoop读文件的FileInputFormat对象，在其中进行传相应的编码值与编码转换的工作，这个是比较麻烦，实际当中用得很少。

再思考下。

Hadoop中的文件格式大致上分为面向行和面向列两类：

面向行：TextFile、SequenceFile、MapFile、Avro Datafile

二进制格式文件大小比文本文件大。

生产环境常用，作为原始表的存储格式，会占用更多磁盘资源，对它的 解析开销一般会比二进制格式高 几十倍以上。

Hadoop API 提供的一种二进制文件，它将数据以<key,value>的形式序列化到文件中。这种二进制文件内部使用Hadoop 的标准的Writable 接口实现序列化和反序列化。它与Hadoop API中的MapFile 是互相兼容的。

MapFile即为排序后的SequeneceFile，它会额外生成一个索引文件提供按键的查找。文件不支持复写 *** 作，不能向已存在的SequenceFile(MapFile)追加存储记录，在执行文件写 *** 作的时候，该文件是不可读取的。

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

面向列：Parquet 、RCFile、ORCFile

RCFile是Hive推出的一种专门面向列的数据格式。 它遵循“先按列划分，再垂直划分”的设计理念。当查询过程中，针对它并不关心的列时，它会在IO上跳过这些列。

ORCFile （Optimized Record Columnar File)提供了一种比RCFile更加高效的文件格式。其内部将数据划分为默认大小为250M的Stripe。每个Stripe包括索引、数据和Footer。索引存储每一列的最大最小值，以及列中每一行的位置。

Parquet 是一种支持嵌套结构的列式存储格式。Parquet 的存储模型主要由行组（Row Group）、列块（Column Chuck）、页（Page）组成。

1、行组，Row Group：Parquet 在水平方向上将数据划分为行组，默认行组大小与 HDFS Block 块大小对齐，Parquet 保证一个行组会被一个 Mapper 处理。

2、列块，Column Chunk：行组中每一列保存在一个列块中，一个列块具有相同的数据类型，不同的列块可以使用不同的压缩。

3、页，Page：Parquet 是页存储方式，每一个列块包含多个页，一个页是最小的编码的单位，同一列块的不同页可以使用不同的编码方式。

一般原始表数据使用文本格式存储，其他的都是列式存储。

目前在Hadoop中常用的几种压缩格式：lzo，gzip，snappy，bzip2,主要特性对比如下：

其性能对比如下：

2.1 lzo

hadoop中最流行的压缩格式，压缩/解压速度也比较快，合理的压缩率，支持split。适用于较大文本的处理。

对于lzo压缩，常用的有LzoCodec和lzopCodec，可以对sequenceFile和TextFile进行压缩。对TextFile压缩后，mapred对压缩后的文件默认是不能够进行split *** 作，需要对该lzo压缩文件进行index *** 作，生成lzo.index文件，map *** 作才可以进行split。如果设置LzoCodec，那么就生成.lzo后缀的文件，可以用LzoIndexer 进行支持split的index计算，如果设置LzopCodec，那么生成.lzo_deflate后缀的文件，不支持建立index。

---