Hadoop 做为MR 的开源实现,一直以动态运行解析文件格式并得到比MPP数据库快上几倍的装载速度为优点。不过,MPP数据库社区也一直批评Hadoop因为文件格式并不是为特定目的而建,所以序列化和反序列化的成本太高。算法
目前 hadoop 中流行的文件格式有以下几种:sql
(1 ) Seque nceFile数据库
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。apache
(2) RCFileapp
RCFile是Hive推出的一种专门面向列的数据格式。 它遵循“先按列划分,再垂直划分”的设计理念。当查询过程当中,针对它并不关心的列时,它会在IO上跳过这些列。须要说明的是,RCFile在map阶段从远端拷贝仍然是拷贝整个数据块,而且拷贝到本地目录后RCFile并非真正直接跳过不须要的列,并跳到须要读取的列, 而是经过扫描每个row group的头部定义来实现的,可是在整个HDFS Block 级别的头部并无定义每一个列从哪一个row group起始到哪一个row group结束。因此在读取全部列的状况下,RCFile的性能反而没有SequenceFile高。oop
HDFS块内行存储的例子布局
HDFS块内列存储的例子性能
HDFS块内RCFile方式存储的例子测试
(3) Av ro优化
Avro是一种用于支持数据密集型的二进制文件格式。它的文件格式更为紧凑,若要读取大量数据时,Avro可以提供更好的序列化和反序列化性能。而且Avro数据文件天生是带Schema定义的,因此它不须要开发者在API 级别实现本身的Writable对象。最近多个Hadoop 子项目都支持Avro 数据格式,如Pig 、Hive、Flume、Sqoop和Hcatalog。
(4) 文本格式
除上面提到的3种二进制格式以外,文本格式的数据也是Hadoop中常常碰到的。如TextFile 、XML和JSON。 文本格式除了会占用更多磁盘资源外,对它的解析开销通常会比二进制格式高几十倍以上,尤为是XML 和JSON,它们的解析开销比Textfile 还要大,所以强烈不建议在生产系统中使用这些格式进行储存。 若是须要输出这些格式,请在客户端作相应的转换操做。 文本格式常常会用于日志收集,数据库导入,Hive默认配置也是使用文本格式,并且经常容易忘了压缩,因此请确保使用了正确的格式。另外文本格式的一个缺点是它不具有类型和模式,好比销售金额、利润这类数值数据或者日期时间类型的数据,若是使用文本格式保存,因为它们自己的字符串类型的长短不一,或者含有负数,致使MR没有办法排序,因此每每须要将它们预处理成含有模式的二进制格式,这又致使了没必要要的预处理步骤的开销和储存资源的浪费。
(5) 外部格式
Hadoop实际上支持任意文件格式,只要可以实现对应的RecordWriter和RecordReader便可。其中数据库格式也是会常常储存在Hadoop中,好比Hbase,Mysql,Cassandra,MongoDB。 这些格式通常是为了不大量的数据移动和快速装载的需求而用的。他们的序列化和反序列化都是由这些数据库格式的客户端完成,而且文件的储存位置和数据布局(Data Layout)不禁Hadoop控制,他们的文件切分也不是按HDFS的块大小(blocksize)进行切割。
Facebook曾在2010 ICDE(IEEE International Conference on Data Engineering)会议上介绍了数据仓库Hive。Hive存储海量数据在Hadoop系统中,提供了一套类数据库的数据存储和处理机制。它采用类SQL语言对数据进行自动化管理和处理,通过语句解析和转换,最终生成基于Hadoop的MapReduce任务,经过执行这些任务完成数据处理。下图显示了Hive数据仓库的系统结构。
Facebook在数据仓库上遇到的存储可扩展性的挑战是独一无二的。他们在基于Hive的数据仓库中存储了超过300PB的数据,而且以每日新增600TB的速度增加。去年这个数据仓库所存储的数据量增加了3倍。考虑到这个增加趋势,存储效率问题是facebook数据仓库基础设施方面目前乃至未来一段时间内最须要关注的。facebook工程师发表的RCFile: A Fast and Spaceefficient Data Placement Structure in MapReducebased Warehouse Systems一文,介绍了一种高效的数据存储结构——RCFile(Record Columnar File),并将其应用于Facebook的数据仓库Hive中。与传统数据库的数据存储结构相比,RCFile更有效地知足了基于MapReduce的数据仓库的四个关键需求,即Fast data loading、Fast query processing、Highly efficient storage space utilization和Strong adaptivity to highly dynamic workload patterns。RCFile 普遍应用于Facebook公司的数据分析系统Hive中。首先,RCFile具有至关于行存储的数据加载速度和负载适应能力;其次,RCFile的读优化能够在扫描表格时避免没必要要的列读取,测试显示在多数状况下,它比其余结构拥有更好的性能;再次,RCFile使用列维度的压缩,所以可以有效提高存储空间利用率。
为了提升存储空间利用率,Facebook各产品线应用产生的数据从2010年起均采用RCFile结构存储,按行存储(SequenceFile/TextFile)结构保存的数据集也转存为RCFile格式。此外,Yahoo公司也在Pig数据分析系统中集成了RCFile,RCFile正在用于另外一个基于Hadoop的数据管理系统Howl(http://wiki.apache.org/pig/Howl)。并且,根据Hive开发社区的交流,RCFile也成功整合加入其余基于MapReduce的数据分析平台。有理由相信,做为数据存储标准的RCFile,将继续在MapReduce环境下的大规模数据分析中扮演重要角色。
facebook 的数据仓库中数据被加载到表里面时首先使用的存储格式是Facebook本身开发的Record-Columnar File Format(RCFile)。RCFile是一种“容许按行查询,提供了列存储的压缩效率”的混合列存储格式。它的核心思想是首先把Hive表水平切分红多个行组(row groups),而后组内按照列垂直切分,这样列与列的数据在磁盘上就是连续的存储块了。
当一个行组内的全部列写到磁盘时,RCFile就会以列为单位对数据使用相似zlib/lzo的算法进行压缩。当读取列数据的时候使用惰性解压策略( lazy decompression),也就是说用户的某个查询若是只是涉及到一个表中的部分列的时候,RCFile会跳过不须要的列的解压缩和反序列化的过程。经过在facebook的数据仓库中选取有表明性的例子实验,RCFile可以提供5倍的压缩比。
随着数据仓库中存储的数据量持续增加,FB组内的工程师开始研究提升压缩效率的技术和方法。研究的焦点集中在列级别的编码方法,例如行程长度编码(run-length encoding)、词典编码(dictionary encoding)、参考帧编码(frame of reference encoding)、可以在通用压缩过程以前更好的在列级别下降逻辑冗余的数值编码方法。 FB 也尝试过新的列类型(例如JSON是在Facebook内部普遍使用的格式,把JSON格式的数据按照结构化的方式存储既能够知足高效查询的需求,同时也下降了JSON元数据存储的冗余)。
FB
的实验代表列级别的编码若是使用得当的话可以显著提升RCFile的压缩比。
与此同时,Hortonworks也在尝试相似的思路去改进Hive的存储格式。Hortonworks的工程团队设计和实现了ORCFile(包括存储格式和读写接口),这帮助Facebook的数据仓库设计和实现新的存储格式提供了一个很好的开始。
关于 ORCFile 的介绍请见这里: http://yanbohappy.sinaapp.com/?p=478
关于性能评测,笔者这里暂时没有条件,贴一张某次 hive 技术峰会演讲嘉宾的截图:
上面说了这么多,想必你已经知道 RCFile 主要用于提高 hive 的查询效率,那如何生成这种格式的文件呢?
(1)hive 中直接 经过textfil e表进行insert转换
例如:
insert overwrite table http_RCTable partition(dt='2013-09-30') select p_id,tm,idate,phone from tmp_testp where dt='2013-09-30';