facebook數(shù)據(jù)倉(cāng)庫(kù)揭秘之rcfile高效存儲(chǔ)結(jié)構(gòu)(參考版)
2025-06-28 19:59本頁(yè)面
【正文】 有理由相信，作為數(shù)據(jù)存儲(chǔ)標(biāo)準(zhǔn) 的RCFile，將繼續(xù)在MapReduce環(huán)境下的大規(guī)模數(shù)據(jù)分析中扮演重要角色。此外，Yahoo公司也在Pig數(shù)據(jù)分析系統(tǒng)中集成了 RCFile，RCFile正在用于另一個(gè)基于Hadoop的數(shù)據(jù)管理系統(tǒng)Howl（）。首先，RCFile具備相當(dāng)于行存儲(chǔ)的數(shù)據(jù)加載 速度和負(fù)載適應(yīng)能力；其次，RCFile的讀優(yōu)化可以在掃描表格時(shí)避免不必要的列讀取，測(cè)試顯示在多數(shù)情況下，它比其他結(jié)構(gòu)擁有更好的性能；再 次，RCFile使用列維度的壓縮，因此能夠有效提升存儲(chǔ)空間利用率?？紤]到存儲(chǔ)空間和查詢效率兩個(gè)方面，F(xiàn)acebook選擇4MB作為默認(rèn)的行組大小，當(dāng)然也允許用戶自行 選擇參數(shù)進(jìn)行配置。盡管行組變大有助于減少表格的存儲(chǔ)規(guī)模，但是可能會(huì)損害數(shù)據(jù)的讀性能，因?yàn)檫@樣減少了Lazy解壓帶來(lái)的性能提升。因此，如果對(duì)縮減存儲(chǔ)空間方面有強(qiáng)烈需求，則不建議選擇使用小行組。根據(jù)對(duì)Facebook日常應(yīng)用的觀察，當(dāng)行組大小達(dá)到一個(gè)閾值后，增加行組大小并不能進(jìn)一步增加Gzip算法下的壓縮比。行組大小和下面幾個(gè)因素相關(guān)。然而，對(duì)于一個(gè)行組，如果列c4中沒(méi)有值為1的域，那么就無(wú)需解壓列c1。如果一個(gè)WHERE條件不能被行組中的所有記錄滿足，那么RCFile將不會(huì)解壓WHERE條件中不滿足的列。Lazy解壓意味著列將不會(huì)在內(nèi)存解壓，直到RCFile決定列中數(shù)據(jù)真正對(duì)查詢執(zhí)行有用。元數(shù)據(jù)頭部總會(huì)解壓并在內(nèi)存中維 護(hù)直到RCFile處理下一個(gè)行組。例如，表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ù)讀取和Lazy解壓在MapReduce框架中，mapper將順序處理HDFS塊中的每個(gè)行組。一個(gè)參數(shù)是記錄數(shù)的限制，另一個(gè)是內(nèi)存緩存的大小限制。此外，RCFile在元數(shù)據(jù)頭部中記錄每個(gè)域?qū)?yīng)的元數(shù)據(jù)。數(shù)據(jù)追加方法描述如下。RCFile將來(lái)的工作之一可能就是根據(jù)每列的數(shù)據(jù)類型和數(shù)據(jù)分布來(lái)自適應(yīng)選擇最好的壓縮算法。因此，相對(duì)較高的 Gzip解壓開銷可以減少。RCFile使用重量級(jí)的Gzip壓縮算法，是為了獲得較好的壓 縮比，而不使用RLE算法的原因在于此時(shí)列數(shù)據(jù)非排序。由于同一列中所有域的長(zhǎng)度值都順序存儲(chǔ)在該部分，RLE算法能夠找到重復(fù)值的長(zhǎng)序列，尤其對(duì)于固定的域長(zhǎng)度。壓縮方式RCFile的每個(gè)行組中，元數(shù)據(jù)頭部和表格數(shù)據(jù)段分別進(jìn)行壓縮。在該部分中，同一列的所有域順序存儲(chǔ)。一個(gè)行組包括三個(gè)部分。對(duì)于一張表，所有行組大小都相同。每個(gè)
環(huán)評(píng)公示相關(guān)推薦
鄂ICP備17016276號(hào)-1