Hadoop生态笔记(1)

Posted by hydra on 2020-04-07

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应用架构》 人民邮电出版社