facebook數(shù)據(jù)倉(cāng)庫(kù)揭秘之rcfile高效存儲(chǔ)結(jié)構(gòu)(完整版)
【正文】 c workload patterns同一份數(shù)據(jù)集會(huì)供給不同應(yīng)用的用戶，通過(guò)各種方式來(lái)分析。Facebook工程師發(fā)表的RCFile: A Fast and Spaceefficient Data Placement Structure in MapReducebased Warehouse Systems一文，介紹了一種高效的數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)——RCFile（Record Columnar File），并將其應(yīng)用于Facebook的數(shù)據(jù)倉(cāng)庫(kù)Hive中。Facebook曾在2010 ICDE（IEEE International Conference on Data Engineering）會(huì)議上介紹了數(shù)據(jù)倉(cāng)庫(kù)Hive。圖1 Hive數(shù)據(jù)倉(cāng)庫(kù)的系統(tǒng)結(jié)構(gòu)基于MapReduce的數(shù)據(jù)倉(cāng)庫(kù)在超大規(guī)模數(shù)據(jù)分析中扮演了重要角色，對(duì)于典型的Web服 務(wù)供應(yīng)商，這些分析有助于它們快速理解動(dòng)態(tài)的用戶行為及變化的用戶需求。Fast query processing為了滿足實(shí)時(shí)性的網(wǎng)站請(qǐng)求和支持高并發(fā)用戶提交查詢的大量讀負(fù)載，查詢響應(yīng)時(shí)間是非常關(guān)鍵的，這要求底層存儲(chǔ)結(jié)構(gòu)能夠隨著查詢數(shù)量的增加而保持高速的查詢處理。上面這三種結(jié)構(gòu)都有其自身特點(diǎn)，不過(guò)簡(jiǎn)單移植這些數(shù)據(jù)庫(kù)導(dǎo)向的 存儲(chǔ)結(jié)構(gòu)到基于MapReduce的數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)并不能很好地滿足所有需求。然而，由于元組重構(gòu)的較高開銷，它并不能提供基于Hadoop系統(tǒng)的快速查詢處理。對(duì)于記錄中來(lái)自不同列的多個(gè)域，PAX將它們放在一個(gè)磁盤頁(yè)中。圖4是一個(gè) HDFS塊內(nèi)RCFile方式存儲(chǔ)的例子。一個(gè)行組包括三個(gè)部分。RCFile使用重量級(jí)的Gzip壓縮算法，是為了獲得較好的壓 縮比，而不使用RLE算法的原因在于此時(shí)列數(shù)據(jù)非排序。此外，RCFile在元數(shù)據(jù)頭部中記錄每個(gè)域?qū)?yīng)的元數(shù)據(jù)。例如，表tbl(c1, c2, c3, c4)有4個(gè)列，做一次查詢“SELECT c1 FROM tbl WHERE c4 = 1”，對(duì)每個(gè)行組，RCFile僅僅讀取c1和c4列的內(nèi)容。然而，對(duì)于一個(gè)行組，如果列c4中沒有值為1的域，那么就無(wú)需解壓列c1。盡管行組變大有助于減少表格的存儲(chǔ)規(guī)模，但是可能會(huì)損害數(shù)據(jù)的讀性能，因?yàn)檫@樣減少了Lazy解壓帶來(lái)的性能提升。有理由相信，作為數(shù)據(jù)存儲(chǔ)標(biāo)準(zhǔn) 的RCFile，將繼續(xù)在MapReduce環(huán)境下的大規(guī)模數(shù)據(jù)分析中扮演重要角色?？紤]到存儲(chǔ)空間和查詢效率兩個(gè)方面，F(xiàn)acebook選擇4MB作為默認(rèn)的行組大小，當(dāng)然也允許用戶自行 選擇參數(shù)進(jìn)行配置。行組大小和下面幾個(gè)因素相關(guān)。元數(shù)據(jù)頭部總會(huì)解壓并在內(nèi)存中維 護(hù)直到RCFile處理下一個(gè)行組。一個(gè)參數(shù)是記錄數(shù)的限
環(huán)評(píng)公示相關(guān)推薦
鄂ICP備17016276號(hào)-1