Hadoop 作為MR 的開源實現(xiàn)，一直以動態(tài)運行解析文件格式并獲得比MPP數(shù)據(jù)庫快上幾倍的裝載速度為優(yōu)勢。不過，MPP數(shù)據(jù)庫社區(qū)也一直批評Hadoop由于文件格式并非為特定目的而建，因此序列化和反序列化的成本過高[7]。本文介紹Hadoop目前已有的幾種文件格式，分析其特點、開銷及使用場景。希望加深讀者對Hadoop文件格式及其影響性能的因素的理解。

Hadoop 中的文件格式

1 SequenceFile

SequenceFile是Hadoop API 提供的一種二進制文件，它將數(shù)據(jù)以<key,value>的形式序列化到文件中。這種二進制文件內(nèi)部使用Hadoop 的標(biāo)準(zhǔn)的Writable 接口實現(xiàn)序列化和反序列化。它與Hadoop API中的MapFile 是互相兼容的。Hive 中的SequenceFile 繼承自Hadoop API 的SequenceFile，不過它的key為空，使用value 存放實際的值， 這樣是為了避免MR 在運行map 階段的排序過程。如果你用Java API 編寫SequenceFile，并讓Hive 讀取的話，請確保使用value字段存放數(shù)據(jù)，否則你需要自定義讀取這種SequenceFile 的InputFormat class 和OutputFormat class。

圖1：Sequencefile 文件結(jié)構(gòu)

2 RCFile

RCFile是Hive推出的一種專門面向列的數(shù)據(jù)格式。 它遵循“先按列劃分，再垂直劃分”的設(shè)計理念。當(dāng)查詢過程中，針對它并不關(guān)心的列時，它會在IO上跳過這些列。需要說明的是，RCFile在map階段從遠(yuǎn)端拷貝仍然是拷貝整個數(shù)據(jù)塊，并且拷貝到本地目錄后RCFile并不是真正直接跳過不需要的列，并跳到需要讀取的列， 而是通過掃描每一個row group的頭部定義來實現(xiàn)的，但是在整個HDFS Block 級別的頭部并沒有定義每個列從哪個row group起始到哪個row group結(jié)束。所以在讀取所有列的情況下，RCFile的性能反而沒有SequenceFile高。

圖2：RCFile 文件結(jié)構(gòu)

3 Avro

Avro是一種用于支持?jǐn)?shù)據(jù)密集型的二進制文件格式。它的文件格式更為緊湊，若要讀取大量數(shù)據(jù)時，Avro能夠提供更好的序列化和反序列化性能。并且Avro數(shù)據(jù)文件天生是帶Schema定義的，所以它不需要開發(fā)者在API 級別實現(xiàn)自己的Writable對象。最近多個Hadoop 子項目都支持Avro 數(shù)據(jù)格式，如Pig 、Hive、Flume、Sqoop和Hcatalog。

圖3：Avro MR 文件格式

4. 文本格式

除上面提到的3種二進制格式之外，文本格式的數(shù)據(jù)也是Hadoop中經(jīng)常碰到的。如TextFile 、XML和JSON。 文本格式除了會占用更多磁盤資源外，對它的解析開銷一般會比二進制格式高幾十倍以上，尤其是XML 和JSON，它們的解析開銷比Textfile 還要大，因此強烈不建議在生產(chǎn)系統(tǒng)中使用這些格式進行儲存。 如果需要輸出這些格式，請在客戶端做相應(yīng)的轉(zhuǎn)換操作。 文本格式經(jīng)常會用于日志收集，數(shù)據(jù)庫導(dǎo)入，Hive默認(rèn)配置也是使用文本格式，而且常常容易忘了壓縮，所以請確保使用了正確的格式。另外文本格式的一個缺點是它不具備類型和模式，比如銷售金額、利潤這類數(shù)值數(shù)據(jù)或者日期時間類型的數(shù)據(jù)，如果使用文本格式保存，由于它們本身的字符串類型的長短不一，或者含有負(fù)數(shù)，導(dǎo)致MR沒有辦法排序，所以往往需要將它們預(yù)處理成含有模式的二進制格式，這又導(dǎo)致了不必要的預(yù)處理步驟的開銷和儲存資源的浪費。

5. 外部格式

Hadoop實際上支持任意文件格式，只要能夠?qū)崿F(xiàn)對應(yīng)的RecordWriter和RecordReader即可。其中數(shù)據(jù)庫格式也是會經(jīng)常儲存在Hadoop中，比如Hbase，Mysql，Cassandra，MongoDB。 這些格式一般是為了避免大量的數(shù)據(jù)移動和快速裝載的需求而用的。他們的序列化和反序列化都是由這些數(shù)據(jù)庫格式的客戶端完成，并且文件的儲存位置和數(shù)據(jù)布局(Data Layout)不由Hadoop控制，他們的文件切分也不是按HDFS的塊大小（blocksize）進行切割。

文件存儲大小比較與分析

我們選取一個TPC-H標(biāo)準(zhǔn)測試來說明不同的文件格式在存儲上的開銷。因為此數(shù)據(jù)是公開的，所以讀者如果對此結(jié)果感興趣，也可以對照后面的實驗自行做一遍。Orders 表文本格式的原始大小為1.62G。 我們將其裝載進Hadoop 并使用Hive 將其轉(zhuǎn)化成以上幾種格式，在同一種LZO 壓縮模式下測試形成的文件的大小。

表1：不同格式文件大小對比

從上述實驗結(jié)果可以看到，SequenceFile無論在壓縮和非壓縮的情況下都比原始純文本TextFile大，其中非壓縮模式下大11%， 壓縮模式下大6.4%。這跟SequenceFile的文件格式的定義有關(guān)： SequenceFile在文件頭中定義了其元數(shù)據(jù)，元數(shù)據(jù)的大小會根據(jù)壓縮模式的不同略有不同。一般情況下，壓縮都是選取block 級別進行的，每一個block都包含key的長度和value的長度，另外每4K字節(jié)會有一個sync-marker的標(biāo)記。對于TextFile文件格式來說不同列之間只需要用一個行間隔符來切分，所以TextFile文件格式比SequenceFile文件格式要小。但是TextFile 文件格式不定義列的長度，所以它必須逐個字符判斷每個字符是不是分隔符和行結(jié)束符。因此TextFile 的反序列化開銷會比其他二進制的文件格式高幾十倍以上。

RCFile文件格式同樣也會保存每個列的每個字段的長度。但是它是連續(xù)儲存在頭部元數(shù)據(jù)塊中，它儲存實際數(shù)據(jù)值也是連續(xù)的。另外RCFile 會每隔一定塊大小重寫一次頭部的元數(shù)據(jù)塊（稱為row group，由hive.io.rcfile.record.buffer.size控制，其默認(rèn)大小為4M），這種做法對于新出現(xiàn)的列是必須的，但是如果是重復(fù)的列則不需要。RCFile 本來應(yīng)該會比SequenceFile 文件大，但是RCFile 在定義頭部時對于字段長度使用了Run Length Encoding進行壓縮，所以RCFile 比SequenceFile又小一些。Run length Encoding針對固定長度的數(shù)據(jù)格式有非常高的壓縮效率，比如Integer、Double和Long等占固定長度的數(shù)據(jù)類型。在此提一個特例——Hive 0.8引入的TimeStamp 時間類型，如果其格式不包括毫秒，可表示為”YYYY-MM-DD HH:MM:SS”，那么就是固定長度占8個字節(jié)。如果帶毫秒，則表示為”YYYY-MM-DD HH:MM:SS.fffffffff”，后面毫秒的部分則是可變的。

Avro文件格式也按group進行劃分。但是它會在頭部定義整個數(shù)據(jù)的模式（Schema）， 而不像RCFile那樣每隔一個row group就定義列的類型，并且重復(fù)多次。另外，Avro在使用部分類型的時候會使用更小的數(shù)據(jù)類型，比如Short或者Byte類型，所以Avro的數(shù)據(jù)塊比RCFile 的文件格式塊更小。

序列化與反序列化開銷分析

我們可以使用Java的profile工具來查看Hadoop 運行時任務(wù)的CPU和內(nèi)存開銷。以下是在Hive 命令行中的設(shè)置：

hive>set mapred.task.profile=true;
hive>set mapred.task.profile.params =-agentlib:hprof=cpu=samples,heap=sites, depth=6,force=n,thread=y,verbose=n,file=%s

當(dāng)map task 運行結(jié)束后，它產(chǎn)生的日志會寫在$logs/userlogs/job- 文件夾下。當(dāng)然，你也可以直接在JobTracker的Web界面的logs或jobtracker.jsp 頁面找到日志。

我們運行一個簡單的SQL語句來觀察RCFile 格式在序列化和反序列化上的開銷：

hive> select O_CUSTKEY,O_ORDERSTATUS from orders_rc2 where O_ORDERSTATUS='P';

其中的O_CUSTKEY列為integer類型，O_ORDERSTATUS為String類型。在日志輸出的最后會包含內(nèi)存和CPU 的消耗。

下表是一次CPU 的開銷：

表2：一次CPU的開銷

其中第五列可以對照上面的Track信息查看到底調(diào)用了哪些函數(shù)。比如CPU消耗排名20的函數(shù)對應(yīng)Track：

TRACE 315554: (thread=200001)
    org.apache.hadoop.hive.ql.io.RCFile$Reader.getCurrentRow(RCFile.java:1434)
    org.apache.hadoop.hive.ql.io.RCFileRecordReader.next(RCFileRecordReader.java:88)
    org.apache.hadoop.hive.ql.io.RCFileRecordReader.next(RCFileRecordReader.java:39)
org.apache.hadoop.hive.ql.io.CombineHiveRecordReader.doNext(CombineHiveRecordReader.java:98)
org.apache.hadoop.hive.ql.io.CombineHiveRecordReader.doNext(CombineHiveRecordReader.java:42)    
org.apache.hadoop.hive.ql.io.HiveContextAwareRecordReader.next(HiveContextAwareRecordReader.java:67)

其中，比較明顯的是RCFile，它為了構(gòu)造行而消耗了不必要的數(shù)組移動開銷。其主要是因為RCFile 為了還原行，需要構(gòu)造RowContainer，順序讀取一行構(gòu)造RowContainer，然后給其中對應(yīng)的列進行賦值，因為RCFile早期為了兼容SequenceFile所以可以合并兩個block，又由于RCFile不知道列在哪個row group結(jié)束，所以必須維持?jǐn)?shù)組的當(dāng)前位置，類似如下格式定義：

   Array<RowContainer extends List<Object>>

而此數(shù)據(jù)格式可以改為面向列的序列化和反序列化方式。如：

Map<array<col1Type>,array<col2Type>,array<col3Type>....>

這種方式的反序列化會避免不必要的數(shù)組移動，當(dāng)然前提是我們必須知道列在哪個row group開始到哪個row group結(jié)束。這種方式會提高整體反序列化過程的效率。

關(guān)于Hadoop文件格式的思考

1 高效壓縮

Hadoop目前尚未出現(xiàn)針對數(shù)據(jù)特性的高效編碼（Encoding）和解碼(Decoding)數(shù)據(jù)格式。尤其是支持Run Length Encoding、Bitmap 這些極為高效算法的數(shù)據(jù)格式。HIVE-2065 討論過使用更加高效的壓縮形式，但是對于如何選取列的順序沒有結(jié)論。關(guān)于列順序選擇可以看Daniel Lemire的一篇論文 《Reordering Columns for Smaller Indexes》[1]。作者同時也是Hive 0.8中引入的bitmap 壓縮算法基礎(chǔ)庫的作者。該論文的結(jié)論是：當(dāng)某個表需要選取多個列進行壓縮時，需要根據(jù)列的選擇性(selectivity)進行升序排列，即唯一值越少的列排得越靠前。 事實上這個結(jié)論也是Vertica多年來使用的數(shù)據(jù)格式。其他跟壓縮有關(guān)的還有HIVE-2604和HIVE-2600。

2 基于列和塊的序列化和反序列化

不論排序后的結(jié)果是不是真的需要，目前Hadoop的整體框架都需要不斷根據(jù)數(shù)據(jù)key進行排序。除了上面提到的基于列的排序，序列化和反序列化之外，Hadoop的文件格式應(yīng)該支持某種基于塊（Block） 級別的排序和序列化及反序列化方式，只有當(dāng)數(shù)據(jù)滿足需要時才進行這些操作。來自Google Tenzing論文中曾將它作為MR 的優(yōu)化手段提到過。

“Block Shuffle：正常來說，MR 在Shuffle 的時候使用基于行的編碼和解碼。為了逐個處理每一行,數(shù)據(jù)必須先排序。然而，當(dāng)排序不是必要的時候這種方式并不高效,我們在基于行的shuffle基礎(chǔ)上實現(xiàn)了一種基于block的shuffle方式，每一次處理大概1M的壓縮block，通過把整個block當(dāng)成一行，我們能夠避免MR框架上的基于行的序列化和反序列化消耗，這種方式比基于行的shuffle 快上3倍以上。”

3 數(shù)據(jù)過濾（Skip List）

除常見的分區(qū)和索引之外，使用排序之后的塊（Block）間隔也是常見列數(shù)據(jù)庫中使用的過濾數(shù)據(jù)的方法。Google Tenzing同樣描述了一種叫做ColumnIO 的數(shù)據(jù)格式，ColumnIO在頭部定義該Block的最大值和最小值，在進行數(shù)據(jù)判斷的時候，如果當(dāng)前Block的頭部信息里面描述的范圍中不包含當(dāng)前需要處理的內(nèi)容，則會直接跳過該塊。Hive社區(qū)里曾討論過如何跳過不需要的塊 ，可是因為沒有排序所以一直沒有較好的實現(xiàn)方式。包括RCFile格式，Hive的index 機制里面目前還沒有一個高效的根據(jù)頭部元數(shù)據(jù)就可以跳過塊的實現(xiàn)方式。

4 延遲物化

真正好的列數(shù)據(jù)庫，都應(yīng)該可以支持直接在壓縮數(shù)據(jù)之上不需要通過解壓和排序就能夠直接操作塊。通過這種方式可以極大的降低MR 框架或者行式數(shù)據(jù)庫中先解壓，再反序列化，然后再排序所帶來的開銷。Google Tenzing里面描述的Block Shuffle 也屬于延遲物化的一種。更好的延遲物化可以直接在壓縮數(shù)據(jù)上進行操作，并且可以做內(nèi)部循環(huán)， 此方面在論文《Integrating Compression and Execution in Column-Oriented Database System》[5]的5.2 章節(jié)有描述。 不過考慮到它跟UDF 集成也有關(guān)系，所以，它會不會將文件接口變得過于復(fù)雜也是一件有爭議的事情。

5 與Hadoop框架集成

無論文本亦或是二進制格式，都只是最終的儲存格式。Hadoop運行時產(chǎn)生的中間數(shù)據(jù)卻沒有辦法控制。包括一個MR Job在map和reduce之間產(chǎn)生的數(shù)據(jù)或者DAG Job上游reduce 和下游map之間的數(shù)據(jù)，尤其是中間格式并不是列格式，這會產(chǎn)生不必要的IO和CPU 開銷。比如map 階段產(chǎn)生的spill，reduce 階段需要先copy 再sort-merge。如果這種中間格式也是面向列的，然后將一個大塊切成若干小塊，并在頭部加上每個小塊的最大最小值索引，就可以避免大量sort-mege操作中解壓—反序列化—排序—合并（Merge）的開銷，從而縮短任務(wù)的運行時間。

其他文件格式

Hadoop社區(qū)也曾有對其他文件格式的研究。比如，IBM 研究過面向列的數(shù)據(jù)格式并發(fā)表論文《Column-Oriented Storage Techniques for MapReduce》[4]，其中特別提到IBM 的CIF（Column InputFormat)文件格式在序列化和反序列化的IO消耗上比RCFile 的消耗要小20倍。里面提到的將列分散在不同的HDFS Block 塊上的實現(xiàn)方式RCFile 也有考慮過，但是最后因為重組行的消耗可能會因分散在遠(yuǎn)程機器上產(chǎn)生的延遲而最終放棄了這種實現(xiàn)。此外，最近Avro也在實現(xiàn)一種面向列的數(shù)據(jù)格式，不過目前Hive 與Avro 集成尚未全部完成。有興趣的讀者可以關(guān)注avro-806 和hive-895。

總結(jié)

Hadoop 可以與各種系統(tǒng)兼容的前提是Hadoop MR 框架本身能夠支持多種數(shù)據(jù)格式的讀寫。但如果要提升其性能，Hadoop 需要一種高效的面向列的基于整個MR 框架集成的數(shù)據(jù)格式。尤其是高效壓縮，塊重組（block shuffle），數(shù)據(jù)過濾（skip list）等高級功能，它們是列數(shù)據(jù)庫相比MR 框架在文件格式上有優(yōu)勢的地方。相信隨著社區(qū)的發(fā)展以及Hadoop 的逐步成熟，未來會有更高效且統(tǒng)一的數(shù)據(jù)格式出現(xiàn)。

【編輯推薦】

1. Chkdsk大躍進：Win8磁盤檢測時間大大縮短
2. Linux下使用mke2fsk格式化分區(qū)的方法
3. Ubuntu 11.10 利用終端環(huán)境備份還原