揭秘:RCFile高效存儲結構

　　數據格式

　　RCFile在HDFS分布式文件系統之上設計并實(shí)現，如圖4所示，RCFile按照下面的數據格式來(lái)存儲一張表。

　　RCFile基于HDFS架構，表格占用多個(gè)HDFS塊。

　　每個(gè)HDFS塊中，RCFile以行組為基本單位來(lái)組織記錄。也就是說(shuō)，存儲在一個(gè)HDFS塊中的所有記錄被劃分為多個(gè)行組。對于一張表，所有行組大小都相同。一個(gè)HDFS塊會(huì )有一個(gè)或多個(gè)行組。

　　一個(gè)行組包括三個(gè)部分。第一部分是行組頭部的同步標識，主要用于分隔HDFS塊中的兩個(gè)連續行組;第二部分是行組的元數據頭部，用于存儲行組單元的信息，包括行組中的記錄數、每個(gè)列的字節數、列中每個(gè)域的字節數;第三部分是表格數據段，即實(shí)際的列存儲數據。在該部分中，同一列的所有域順序存儲。從圖4可以看出，首先存儲了列A的所有域，然后存儲列B的所有域等。壓縮方式

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

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

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

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

　　數據追加

　　RCFile不支持任意方式的數據寫(xiě)操作，僅提供一種追加接口，這是因為底層的HDFS當前僅僅支持數據追加寫(xiě)文件尾部。數據追加方法描述如下。

　　RCFile為每列創(chuàng )建并維護一個(gè)內存column holder，當記錄追加時(shí)，所有域被分發(fā)，每個(gè)域追加到其對應的column holder。此外，RCFile在元數據頭部中記錄每個(gè)域對應的元數據。

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

　　RCFile首先壓縮元數據頭部并寫(xiě)到磁盤(pán)，然后分別壓縮每個(gè)column holder，并將壓縮后的column holder刷寫(xiě)到底層文件系統中的一個(gè)行組中。

　　數據讀取和Lazy解壓

　　在MapReduce框架中，mapper將順序處理HDFS塊中的每個(gè)行組。當處理一個(gè)行組時(shí)，RCFile無(wú)需全部讀取行組的全部?jì)热莸絻却妗?p>　　相反，它僅僅讀元數據頭部和給定查詢(xún)需要的列。因此，它可以跳過(guò)不必要的列以獲得列存儲的I/O優(yōu)勢。例如，表tbl(c1, c2, c3, c4)有4個(gè)列，做一次查詢(xún)“SELECT c1 FROM tbl WHERE c4 = 1”，對每個(gè)行組，RCFile僅僅讀取c1和c4列的內容。在元數據頭部和需要的列數據加載到內存中后，它們需要解壓。元數據頭部總會(huì )解壓并在內存中維護直到RCFile處理下一個(gè)行組。然而，RCFile不會(huì )解壓所有加載的列，相反，它使用一種Lazy解壓技術(shù)。

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

　　行組大小

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

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

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

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

　　小結

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

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