《Hadoop权威指南：大数据的存储与分析》—5.4.3 其他文件格式和面向列的格式

5.4.3  其他文件格式和面向列的格式

顺序文件和map文件是Hadoop中最早的、但并不是仅有的二进制文件格式，事实上，对于新项目而言，有更好的二进制文件格式可供选择。

Avro数据文件(详见12.3节)在某些方面类似顺序文件，是面向大规模数据处理而设计的(紧凑且可切分)。但是Avro数据文件又是可移植的，它们可以跨越不同的编程语言使用。Avro数据文件中存储的对象使用模式来描述，而不是像Writable对象的实现那样使用Java代码(例如顺序文件就是这样的情况，这样的弊端是过于以Java为中心)。Avro数据文件被Hadoop生态系统的各组件广为支持，因此它们被默认为是对二进制格式的一种比较好的选择。

顺序文件、map文件和Avro数据文件都是面向行的格式，意味着每一行的值在文件中是连续存储的。在面向列的格式中，文件中的行(或等价的，Hive中的一张表)被分割成行的分片，然后每个分片以面向列的形式存储：首先存储每行第1列的值，然后是每行第2列的值，如此以往。该过程如图5-4所示。

图5-4. 面向行的和面向列的存储

面向列的存储布局可以使一个查询跳过那些不必访问的列。让我们考虑一个只需要处理图5-4中表的第2列的查询。在像顺序文件这样面向行的存储中，即使是只需要读取第二列，整个数据行(存储在顺序文件的一条记录中)将被加载进内存。虽说“延迟反序列化”(lazy deserialization)策略通过只反序列化那些被访问的列字段能节省一些处理开销，但这仍然不能避免从磁盘上读入一个数据行所有字节而付出的开销。

如果使用面向列的存储，只需要把文件中第2列所对应的那部分(图中高亮部分)读入内存。一般来说，面向列的存储格式对于那些只访问表中一小部分列的查询比较有效。相反，面向行的存储格式适合同时处理一行中很多列的情况。

由于必须在内存中缓存行的分片、而不是单独的一行，因此面向列的存储格式需要更多的内存用于读写。并且，当出现写操作时(通过flush或sync操作)，这种缓存通常不太可能***，因此，面向列的格式不适合流的写操作，这是因为，如果writer处理失败的话，当前的文件无法恢复。另一方面，对于面向行的存储格式，如顺序文件和Avro数据文件，可以一直读取到writer失败后的最后的同步点。由于这个原因，Flume(详见第14章)使用了面向行的存储格式。

Hadoop中的第一个面向列的文件格式是 Hive的RCFile(Record Columnar File)，它已经被Hive的ORCFile(Optimized Record Columnar File)及Parquet取代(详见第13章)。Parquet是一个基于Google Dremel的通用的面向列的文件格式，被Hadoop组件广为支持。Avro也有一个面向列的文件格式，称为Trevni。