Hadoop生态，数据存储。
数据采集，转换（存储容器格式）
Flume、kafka、sqoop
文件系统
HDFS
数据格式
1、文本数据CSV
2、结构化文本数据XML和JSON，这种文件很难分片，Hadoop没有为这类格式提供内置的InputFormat。
使用类似Avro的容器格式。将数据转换为Avro的内容，从而为数据存储与数据处理提供更紧密、有效的方法。
使用处理XML或JSON文件的专用库。比如，XML，Pig的PiggyBank库中的XMLLoader。JSON，Elephant Bird项目提供的LzoJsonInputFormat。
3、二进制数据（比如图像）
对于Hadoop大多数应用场景来说，二进制文件的存储和处理最好使用SequenceFile之类的容器格式。如果二进制数据的每个分片大于64MB，则可以考虑直接使用该二进制数据自己的格式，无需容器格式。
文件类型
为了配合MapReduce应用，Hadoop开发了一些专用文件格式，基于文件的数据结构（如SequenceFile），序列化格式（如Avro），列式存储格式（如RCFile和Parquet）。
对于Hadoop应用来说，需求特点：（可分片压缩）和（文件格式自描述、与压缩编码无关）
SequenceFile
SequenceFile以二进制键值对的方式存储数据，支持三种记录存储方式：
无压缩，IO效率差，占磁盘。优势不大。
记录级压缩，对每一条记录压缩。
块级压缩，数据达到指定数据块大小再压缩，与记录压缩比，拥有更高的压缩率。（此块与HDFS文件系统数据块无关）通常选块级压缩。
SequenceFile包含头部格式，支持分片，通常作为小文件容器格式使用。hadoop小文件问题：大量的小文件导致NameNode过度使用内存，HDFS中每个文件的元数据都会存在内存里。
来自小文件的大量数据处理需要很多数据处理子任务，导致资源过度消耗。将小文件打包到SequenceFile能更加有效存储和处理。
序列化格式
序列化，将数据结构转化为字节流的过程，一般用于数据存储或网络传输。反序列化，将字节流转化为数据结构的过程。
序列化是分布式处理系统的核心，原因在于能对数据转化，形成一种格式；使用该格式之后，数据可以有效存储，也能通过网络连接进行传输。
它通常关联到分布式处理系统的两个方面：进程间通信（如RPC），以及数据存储。
Hadoop主要采用的序列化格式为Writables。Writables的特点是紧密、快速，但脱离Java语言不容易扩展和使用。
Hadoop生态系统中也有普及的其他序列化框架，Thrift，Protocol Buffers ，Avro。
Thrift
Facebook公司开发的框架，用于实现跨语言提供服务接口。IDL定义服务接口，IDL文件创建桩代码。Thrift的RPC层非常健壮，跨平台通信，实现多语言使用的接口。
但作为序列化框架而言，存在一些缺陷，不支持记录的内部压缩，不可分片，缺少MapReduce的原生支持，
一些外部库（如Elephant Bird项目）能够消除这些缺陷，但Hadoop没有为作为数据存储格式的Thrift提供原生支持。
Protocol Buffers
由Google公司开发，用于在不同语言编写的服务之间完成数据交换。IDL定义服务接口，IDL文件创建桩代码
与Thrift类似，不支持记录的内部压缩，不可分片，缺少MapReduce的原生支持。Elephant Bird项目可以用于编码Protobuf记录，支持MapReduce，压缩，及分片。
Avro
一种和语言无关的数据序列化系统。设计初衷是为了解决Hadoop Writables的主要缺点，即缺少跨语言的可移植性支持。
Avro将模式存于每个文件的头部，每个文件都是自描述的。容易读取，即使用一种语言写入数据，用另一种语言来读取，也没有影响。
可压缩且可分片，为MapReduce提供了更好的原生支持。
支持模式演进（schema evolution）,读取文件的模式不需要与写入文件的模式严格匹配，比SequenceFile更适合Hadoop。
列式存储格式
RCFile
专为高效处理MapReduce应用程序开发。尽管实践中，一般只作为Hive存储格式使用。文件按行进行分片，每个分片按列存储。
ORC
开发初衷弥补RCFile的不足，尤其是查询性能和存储效率方面的缺陷。
支持使用zlib、LZO和Snappy压缩算法提供进一步压缩。谓词下推至存储层，仅返回查询需要的数据。支持Hive类型的模型，decimal与复杂类型。支持分片。
劣势是它专门为Hive设计的，不是通用的存储格式。无法用于非Hive的MapReduce接口（如Pig或Java），也无法用于Impala。
Parquet
和ORC拥有很多相同的设计目标，但是Parquet有意成为Hadoop上的通用存储格式。文件尾部有完整的元数据信息存储，自描述。
完全支持通过Avro和Thrift API写入和读取。
注意：列格式虽高效，在错误处理方面不是很好，文件损毁可能导致行不完整。
压缩
压缩会增加CPU负载，大多数情况下，压缩节省IO比CPU负载增加更重要。
Snappy，Google开发的压缩编解码器，比较平衡压缩速度和大小，压缩文件不可分片，要与容器格式（如SequenceFile和Avro）联合使用。
LZO，压缩速度不错，压缩率略显平庸。文件可分片。(许可协议不允许打包到Hadoop一起分发，需要单独安装)
Gzip，压缩性能非常好，平均能达到Snappy的2.5倍。写入速度不如Snappy，平均为Snappy的一半。读取性能与Snappy差不多。不可分片。
bzip2，压缩性能很优越，处理性能较差一点。额外的压缩要在读取，写入性能上付出代价。可分片。
与容器文件格式（Avro等）一起使用，任何压缩格式都是可分片的。容器文件格式能单独压缩记录构成的数据块，也可进行记录级压缩。
参考
《Hadoop应用架构》 人民邮电出版社
