【正文】 patterns同一份數(shù)據(jù)集會供給不同應用的用戶，通過各種方式來分析。盡管預先分組后，多個列在一起能夠減少開銷，但是對于高度動態(tài)的負載模式，它并不具備很好的適應性。RCFile基于HDFS架構，表格占用多個HDFS塊。盡管RCFile對表格數(shù)據(jù)的所有列使用同樣的壓縮算法，不過如果使用不同的算法來壓縮不同列或許效果會更好。然而，RCFile不會解壓所有加載的列，相反，它使用一種Lazy解壓技術。小結本文簡單介紹了RCFile存儲結構，其廣泛應用于Facebook公司的數(shù)據(jù)分析系統(tǒng)Hive中。需要注意的是，當行組的大小超過4MB，數(shù)據(jù)的壓縮比將趨于一致。因此，它可以跳過不必要的列以獲得列存儲的I/O優(yōu)勢。表格數(shù)據(jù)段不會作為整個單元來壓縮；相反每個列被獨立壓縮，使用Gzip壓縮算法。它結合了行存儲和列存儲的優(yōu)點：首先，RCFile保證同一行 的數(shù)據(jù)位于同一節(jié)點，因此元組重構的開銷很低；其次，像列存儲一樣，RCFile能夠利用列維度的數(shù)據(jù)壓縮，并且能跳過不必要的列讀取。查詢時列存儲能夠避 免讀不必要的列，并且壓縮一個列中的相似數(shù)據(jù)能夠達到較高的壓縮比。每天大約有超過20TB的數(shù)據(jù)上傳到Facebook的數(shù)據(jù)倉庫，由于數(shù)據(jù)加載期間網(wǎng)絡和磁盤流量會干擾正常的查詢執(zhí)行，因此縮短數(shù)據(jù)加載時間是非常必要的。Hive存儲海量數(shù)據(jù)在Hadoop系統(tǒng)中，提供了一套類數(shù)據(jù)庫的數(shù)據(jù)存儲和處理機制。某些數(shù)據(jù)分析是例行過程，按照某種固定模式周期性執(zhí)行；而另一些則是從中間平臺發(fā)起的查 詢。除非所有列組根據(jù)可能的 查詢預先創(chuàng)建，否則對于一個查詢需要一個不可預知的列組合，一個記錄的重構或許需要2個或多個列組。每個HDFS塊中，RCFile以行組為基本單位來組織記錄。RCFile將來的工作之一可能就是根據(jù)每列的數(shù)據(jù)類型和數(shù)據(jù)分布來自適應選擇最好的壓縮算法。Lazy解壓意味著列將不會在內存解壓，直到RCFile決定列中數(shù)據(jù)真正對查詢執(zhí)行有用。首先，RCFile具備相當于行存儲的數(shù)據(jù)加載 速度和負載適應能力；其次，RCFile的讀優(yōu)化可以在掃描表格時避免不必要的列讀取，測試顯示在多數(shù)情況下，它比其他結構擁有更好的性能；再 次，RCFile使用列維度的壓縮，因此能夠有效提升存儲空間利用率。因此，如果對縮減存儲空間方面有強烈需求，則不建議選擇使用小行組。相反，它僅僅讀元數(shù)據(jù)頭部和給定查詢需要的列。由于同一列中所有域的長度值都順序存儲在該部分，RLE算法能夠找到重復值的長序列，尤其對于固定的域長度。RCFile的設計與實現(xiàn)RCFile（Record Columnar File）存儲結構遵循的是“先水平劃分，再垂直劃分”的設計理