Hive中RCFile數(shù)據(jù)存儲格式的示例分析

這篇文章主要介紹了Hive中RCFile數(shù)據(jù)存儲格式的示例分析，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

Facebook曾在2010 ICDE（IEEE International Conference on Data Engineering）會議上介紹了數(shù)據(jù)倉庫Hive。Hive存儲海量數(shù)據(jù)在Hadoop系統(tǒng)中，提供了一套類數(shù)據(jù)庫的數(shù)據(jù)存儲和處理機制。它采用類 SQL語言對數(shù)據(jù)進行自動化管理和處理，經(jīng)過語句解析和轉(zhuǎn)換，最終生成基于Hadoop的MapReduce任務(wù)，通過執(zhí)行這些任務(wù)完成數(shù)據(jù)處理。圖1顯 示了Hive數(shù)據(jù)倉庫的系統(tǒng)結(jié)構(gòu)。 

圖1 Hive數(shù)據(jù)倉庫的系統(tǒng)結(jié)構(gòu)

基于MapReduce的數(shù)據(jù)倉庫在超大規(guī)模數(shù)據(jù)分析中扮演了重要角色，對于典型的Web服 務(wù)供應(yīng)商，這些分析有助于它們快速理解動態(tài)的用戶行為及變化的用戶需求。數(shù)據(jù)存儲結(jié)構(gòu)是影響數(shù)據(jù)倉庫性能的關(guān)鍵因素之一。Hadoop系統(tǒng)中常用的文件存 儲格式有支持文本的TextFile和支持二進制的SequenceFile等，它們都屬于行存儲方式。Facebook工程師發(fā)表的RCFile: A Fast and Spaceefficient Data Placement Structure in MapReducebased Warehouse Systems一文，介紹了一種高效的數(shù)據(jù)存儲結(jié)構(gòu)——RCFile（Record Columnar File），并將其應(yīng)用于Facebook的數(shù)據(jù)倉庫Hive中。與傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)存儲結(jié)構(gòu)相比，RCFile更有效地滿足了基于MapReduce的 數(shù)據(jù)倉庫的四個關(guān)鍵需求，即Fast data loading、Fast query processing、Highly efficient storage space utilization和Strong adaptivity to highly dynamic workload patterns。

數(shù)據(jù)倉庫的需求

基于Facebook系統(tǒng)特征和用戶數(shù)據(jù)的分析，在MapReduce計算環(huán)境下，數(shù)據(jù)倉庫對于數(shù)據(jù)存儲結(jié)構(gòu)有四個關(guān)鍵需求。

Fast data loading

對于Facebook的產(chǎn)品數(shù)據(jù)倉庫而言，快速加載數(shù)據(jù)（寫數(shù)據(jù)）是非常關(guān)鍵的。每天大約有超過20TB的數(shù)據(jù)上傳到Facebook的數(shù)據(jù)倉庫， 由于數(shù)據(jù)加載期間網(wǎng)絡(luò)和磁盤流量會干擾正常的查詢執(zhí)行，因此縮短數(shù)據(jù)加載時間是非常必要的。

Fast query processing

為了滿足實時性的網(wǎng)站請求和支持高并發(fā)用戶提交查詢的大量讀負載，查詢響應(yīng)時間是非常關(guān)鍵的，這要求底層存儲結(jié)構(gòu)能夠隨著查詢數(shù)量的增加而保持高速 的查詢處理。

Highly efficient storage space utilization

高速增長的用戶活動總是需要可擴展的存儲容量和計算能力，有限的磁盤空間需要合理管理海量數(shù)據(jù)的存儲。實際上，該問題的解決方案就是最大化磁盤空間 利用率。

Strong adaptivity to highly dynamic workload patterns

同一份數(shù)據(jù)集會供給不同應(yīng)用的用戶，通過各種方式來分析。某些數(shù)據(jù)分析是例行過程，按照某種固定模式周期性執(zhí)行；而另一些則是從中間平臺發(fā)起的查 詢。大多數(shù)負載不遵循任何規(guī)則模式，這需要底層系統(tǒng)在存儲空間有限的前提下，對數(shù)據(jù)處理中不可預(yù)知的動態(tài)數(shù)據(jù)具備高度的適應(yīng)性，而不是專注于某種特殊的負 載模式。

MapReduce存儲策略

要想設(shè)計并實現(xiàn)一種基于MapReduce數(shù)據(jù)倉庫的高效數(shù)據(jù)存儲結(jié)構(gòu)，關(guān)鍵挑戰(zhàn)是在MapReduce計算環(huán)境中滿足上述四個需求。在傳統(tǒng)數(shù)據(jù)庫 系統(tǒng)中，三種數(shù)據(jù)存儲結(jié)構(gòu)被廣泛研究，分別是行存儲結(jié)構(gòu)、列存儲結(jié)構(gòu)和PAX混合存儲結(jié)構(gòu)。上面這三種結(jié)構(gòu)都有其自身特點，不過簡單移植這些數(shù)據(jù)庫導(dǎo)向的 存儲結(jié)構(gòu)到基于MapReduce的數(shù)據(jù)倉庫系統(tǒng)并不能很好地滿足所有需求。

行存儲

如圖2所示，基于Hadoop系統(tǒng)行存儲結(jié)構(gòu)的優(yōu)點在于快速數(shù)據(jù)加載和動態(tài)負載的高適應(yīng)能力，這是因為行存儲保證了相同記錄的所有域都在同一個集群 節(jié)點，即同一個HDFS塊。不過，行存儲的缺點也是顯而易見的，例如它不能支持快速查詢處理，因為當(dāng)查詢僅僅針對多列表中的少數(shù)幾列時，它不能跳過不必要 的列讀??；此外，由于混合著不同數(shù)據(jù)值的列，行存儲不易獲得一個極高的壓縮比，即空間利用率不易大幅提高。盡管通過熵編碼和利用列相關(guān)性能夠獲得一個較好 的壓縮比，但是復(fù)雜數(shù)據(jù)存儲實現(xiàn)會導(dǎo)致解壓開銷增大。 

圖3 HDFS塊內(nèi)列存儲的例子

PAX混合存儲

PAX存儲模型（用于Data Morphing存儲技術(shù)）使用混合存儲方式，目的在于提升CPU Cache性能。對于記錄中來自不同列的多個域，PAX將它們放在一個磁盤頁中。在每個磁盤頁中，PAX使用一個迷你頁來存儲屬于每個列的所有域，并使用 一個頁頭來存儲迷你頁的指針。類似于行存儲，PAX對多種動態(tài)查詢有很強的適應(yīng)能力。然而，它并不能滿足大型分布式系統(tǒng)對于高存儲空間利用率和快速查詢處 理的需求，原因在于：首先，PAX沒有數(shù)據(jù)壓縮的相關(guān)工作，這部分與Cache優(yōu)化關(guān)系不大，但對于大規(guī)模數(shù)據(jù)處理系統(tǒng)是非常關(guān)鍵的，它提供了列維度數(shù)據(jù) 壓縮的可能性；其次，PAX不能提升I/O性能，因為它不能改變實際的頁內(nèi)容，該限制使得大規(guī)模數(shù)據(jù)掃描時不易實現(xiàn)快速查詢處理；再次，PAX用固定的頁 作為數(shù)據(jù)組織的基本單位，按照這個大小，在海量數(shù)據(jù)處理系統(tǒng)中，PAX將不會有效存儲不同大小類型的數(shù)據(jù)域。本文介紹的是RCF i l e 數(shù)據(jù)存儲結(jié)構(gòu)在Hadoop系統(tǒng)上的實現(xiàn)。該結(jié)構(gòu)強調(diào)：第一，RCFile存儲的表是水平劃分的，分為多個行組， 每個行組再被垂直劃分， 以便每列單獨存儲；第二，RCFile在每個行組中利用一個列維度的數(shù)據(jù)壓縮，并提供一種Lazy解壓（decompression）技術(shù)來在查詢執(zhí)行時 避免不必要的列解壓；第三，RCFile支持彈性的行組大小，行組大小需要權(quán)衡數(shù)據(jù)壓縮性能和查詢性能兩方面。

RCFile的設(shè)計與實現(xiàn)

RCFile（Record Columnar File）存儲結(jié)構(gòu)遵循的是“先水平劃分，再垂直劃分”的設(shè)計理念，這個想法來源于PAX。它結(jié)合了行存儲和列存儲的優(yōu)點：首先，RCFile保證同一行 的數(shù)據(jù)位于同一節(jié)點，因此元組重構(gòu)的開銷很低；其次，像列存儲一樣，RCFile能夠利用列維度的數(shù)據(jù)壓縮，并且能跳過不必要的列讀取。圖4是一個 HDFS塊內(nèi)RCFile方式存儲的例子。 

圖4 HDFS塊內(nèi)RCFile方式存儲的例子

數(shù)據(jù)格式

RCFile在HDFS分布式文件系統(tǒng)之上設(shè)計并實現(xiàn)，如圖4所示，RCFile按照下面的數(shù)據(jù)格式來存儲一張表。

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

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

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

壓縮方式

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

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

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

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

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

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

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

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

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

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

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

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

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

行組大小

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

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

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

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

感謝你能夠認真閱讀完這篇文章，希望小編分享的“Hive中RCFile數(shù)據(jù)存儲格式的示例分析”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關(guān)注億速云行業(yè)資訊頻道，更多相關(guān)知識等著你來學(xué)習(xí)!