壓縮方式 - 揭秘:RCFile高效存儲(chǔ)結(jié)構(gòu)

　　RCFile的每個(gè)行組中，元數(shù)據(jù)頭部和表格數(shù)據(jù)段分別進(jìn)行壓縮。

　　對(duì)于所有元數(shù)據(jù)頭部，RCFile使用RLE(Run Length Encoding)算法來壓縮數(shù)據(jù)。由于同一列中所有域的長(zhǎng)度值都順序存儲(chǔ)在該部分，RLE算法能夠找到重復(fù)值的長(zhǎng)序列，尤其對(duì)于固定的域長(zhǎng)度。

　　表格數(shù)據(jù)段不會(huì)作為整個(gè)單元來壓縮;相反每個(gè)列被獨(dú)立壓縮，使用Gzip壓縮算法。RCFile使用重量級(jí)的Gzip壓縮算法，是為了獲得較好的壓縮比，而不使用RLE算法的原因在于此時(shí)列數(shù)據(jù)非排序。此外，由于Lazy壓縮策略，當(dāng)處理一個(gè)行組時(shí)，RCFile不需要解壓所有列。因此，相對(duì)較高的Gzip解壓開銷可以減少。

　　盡管RCFile對(duì)表格數(shù)據(jù)的所有列使用同樣的壓縮算法，不過如果使用不同的算法來壓縮不同列或許效果會(huì)更好。RCFile將來的工作之一可能就是根據(jù)每列的數(shù)據(jù)類型和數(shù)據(jù)分布來自適應(yīng)選擇最好的壓縮算法。

　　數(shù)據(jù)追加

　　RCFile不支持任意方式的數(shù)據(jù)寫操作，僅提供一種追加接口，這是因?yàn)榈讓拥腍DFS當(dāng)前僅僅支持?jǐn)?shù)據(jù)追加寫文件尾部。數(shù)據(jù)追加方法描述如下。

　　RCFile為每列創(chuàng)建并維護(hù)一個(gè)內(nèi)存column holder，當(dāng)記錄追加時(shí)，所有域被分發(fā)，每個(gè)域追加到其對(duì)應(yīng)的column holder。此外，RCFile在元數(shù)據(jù)頭部中記錄每個(gè)域?qū)?yīng)的元數(shù)據(jù)。

　　RCFile提供兩個(gè)參數(shù)來控制在刷寫到磁盤之前，內(nèi)存中緩存多少個(gè)記錄。一個(gè)參數(shù)是記錄數(shù)的限制，另一個(gè)是內(nèi)存緩存的大小限制。

　　RCFile首先壓縮元數(shù)據(jù)頭部并寫到磁盤，然后分別壓縮每個(gè)column holder，并將壓縮后的column holder刷寫到底層文件系統(tǒng)中的一個(gè)行組中。

　　數(shù)據(jù)讀取和Lazy解壓

　　在MapReduce框架中，mapper將順序處理HDFS塊中的每個(gè)行組。當(dāng)處理一個(gè)行組時(shí)，RCFile無需全部讀取行組的全部?jī)?nèi)容到內(nèi)存。

　　相反，它僅僅讀元數(shù)據(jù)頭部和給定查詢需要的列。因此，它可以跳過不必要的列以獲得列存儲(chǔ)的I/O優(yōu)勢(shì)。例如，表tbl(c1, c2, c3, c4)有4個(gè)列，做一次查詢“SELECT c1 FROM tbl WHERE c4 = 1”，對(duì)每個(gè)行組，RCFile僅僅讀取c1和c4列的內(nèi)容。在元數(shù)據(jù)頭部和需要的列數(shù)據(jù)加載到內(nèi)存中后，它們需要解壓。元數(shù)據(jù)頭部總會(huì)解壓并在內(nèi)存中維護(hù)直到RCFile處理下一個(gè)行組。然而，RCFile不會(huì)解壓所有加載的列，相反，它使用一種Lazy解壓技術(shù)。

　　Lazy解壓意味著列將不會(huì)在內(nèi)存解壓，直到RCFile決定列中數(shù)據(jù)真正對(duì)查詢執(zhí)行有用。由于查詢使用各種WHERE條件，Lazy解壓非常有用。如果一個(gè)WHERE條件不能被行組中的所有記錄滿足，那么RCFile將不會(huì)解壓WHERE條件中不滿足的列。例如，在上述查詢中，所有行組中的列c4都解壓了。然而，對(duì)于一個(gè)行組，如果列c4中沒有值為1的域，那么就無需解壓列c1。

　　行組大小

　　I/O性能是RCFile關(guān)注的重點(diǎn)，因此RCFile需要行組夠大并且大小可變。行組大小和下面幾個(gè)因素相關(guān)。

　　行組大的話，數(shù)據(jù)壓縮效率會(huì)比行組小時(shí)更有效。根據(jù)對(duì)Facebook日常應(yīng)用的觀察，當(dāng)行組大小達(dá)到一個(gè)閾值后，增加行組大小并不能進(jìn)一步增加Gzip算法下的壓縮比。

　　行組變大能夠提升數(shù)據(jù)壓縮效率并減少存儲(chǔ)量。因此，如果對(duì)縮減存儲(chǔ)空間方面有強(qiáng)烈需求，則不建議選擇使用小行組。需要注意的是，當(dāng)行組的大小超過4MB，數(shù)據(jù)的壓縮比將趨于一致。

　　盡管行組變大有助于減少表格的存儲(chǔ)規(guī)模，但是可能會(huì)損害數(shù)據(jù)的讀性能，因?yàn)檫@樣減少了Lazy解壓帶來的性能提升。而且行組變大會(huì)占用更多的內(nèi)存，這會(huì)影響并發(fā)執(zhí)行的其他MapReduce作業(yè)?？紤]到存儲(chǔ)空間和查詢效率兩個(gè)方面，F(xiàn)acebook選擇4MB作為默認(rèn)的行組大小，當(dāng)然也允許用戶自行選擇參數(shù)進(jìn)行配置。

　　小結(jié)

　　本文簡(jiǎn)單介紹了RCFile存儲(chǔ)結(jié)構(gòu)，其廣泛應(yīng)用于Facebook公司的數(shù)據(jù)分析系統(tǒng)Hive中。首先，RCFile具備相當(dāng)于行存儲(chǔ)的數(shù)據(jù)加載速度和負(fù)載適應(yīng)能力;其次，RCFile的讀優(yōu)化可以在掃描表格時(shí)避免不必要的列讀取，測(cè)試顯示在多數(shù)情況下，它比其他結(jié)構(gòu)擁有更好的性能;再次，RCFile使用列維度的壓縮，因此能夠有效提升存儲(chǔ)空間利用率。

　　為了提高存儲(chǔ)空間利用率，F(xiàn)acebook各產(chǎn)品線應(yīng)用產(chǎn)生的數(shù)據(jù)從2010年起均采用RCFile結(jié)構(gòu)存儲(chǔ)，按行存儲(chǔ)(SequenceFile/TextFile)結(jié)構(gòu)保存的數(shù)據(jù)集也轉(zhuǎn)存為RCFile格式。此外，Yahoo公司也在Pig數(shù)據(jù)分析系統(tǒng)中集成了RCFile，RCFile正在用于另一個(gè)基于Hadoop的數(shù)據(jù)管理系統(tǒng)Howl(http://wiki.apache.org/pig/Howl)。而且，根據(jù)Hive開發(fā)社區(qū)的交流，RCFile也成功整合加入其他基于MapReduce的數(shù)據(jù)分析平臺(tái)。有理由相信，作為數(shù)據(jù)存儲(chǔ)標(biāo)準(zhǔn)的RCFile，將繼續(xù)在MapReduce環(huán)境下的大規(guī)模數(shù)據(jù)分析中扮演重要角色。