facebook數(shù)據(jù)倉庫揭秘之rcfile高效存儲(chǔ)結(jié)構(gòu)-文庫吧資料
2025-07-01 19:59本頁面
【正文】 HDFS塊中，RCFile以行組為基本單位來組織記錄。圖4 HDFS塊內(nèi)RCFile方式存儲(chǔ)的例子數(shù)據(jù)格式RCFile在HDFS分布式文件系統(tǒng)之上設(shè)計(jì)并實(shí)現(xiàn)，如圖4所示，RCFile按照下面的數(shù)據(jù)格式來存儲(chǔ)一張表。圖4是一個(gè) HDFS塊內(nèi)RCFile方式存儲(chǔ)的例子。RCFile的設(shè)計(jì)與實(shí)現(xiàn)RCFile（Record Columnar File）存儲(chǔ)結(jié)構(gòu)遵循的是“先水平劃分，再垂直劃分”的設(shè)計(jì)理念，這個(gè)想法來源于PAX。本文介紹的是RCF i l e 數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)在Hadoop系統(tǒng)上的實(shí)現(xiàn)。類似于行存儲(chǔ)，PAX對(duì)多種動(dòng)態(tài)查詢有很強(qiáng)的適應(yīng)能力。對(duì)于記錄中來自不同列的多個(gè)域，PAX將它們放在一個(gè)磁盤頁中。除非所有列組根據(jù)可能的 查詢預(yù)先創(chuàng)建，否則對(duì)于一個(gè)查詢需要一個(gè)不可預(yù)知的列組合，一個(gè)記錄的重構(gòu)或許需要2個(gè)或多個(gè)列組。因此，記錄的重構(gòu)將導(dǎo)致通過 集群節(jié)點(diǎn)網(wǎng)絡(luò)的大量數(shù)據(jù)傳輸。然而，由于元組重構(gòu)的較高開銷，它并不能提供基于Hadoop系統(tǒng)的快速查詢處理。在這個(gè)例子中，列A和列B存儲(chǔ)在同一列組，而列C和列D分別存儲(chǔ)在單獨(dú)的列組。不過，行存儲(chǔ)的缺點(diǎn)也是顯而易見的，例如它不能支持快速查詢處理，因?yàn)楫?dāng)查詢僅僅針對(duì)多列表中的少數(shù)幾列時(shí)，它不能跳過不必要 的列讀??；此外，由于混合著不同數(shù)據(jù)值的列，行存儲(chǔ)不易獲得一個(gè)極高的壓縮比，即空間利用率不易大幅提高。上面這三種結(jié)構(gòu)都有其自身特點(diǎn)，不過簡(jiǎn)單移植這些數(shù)據(jù)庫導(dǎo)向的 存儲(chǔ)結(jié)構(gòu)到基于MapReduce的數(shù)據(jù)倉庫系統(tǒng)并不能很好地滿足所有需求。MapReduce存儲(chǔ)策略要想設(shè)計(jì)并實(shí)現(xiàn)一種基于MapReduce數(shù)據(jù)倉庫的高效數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)，關(guān)鍵挑戰(zhàn)是在MapReduce計(jì)算環(huán)境中滿足上述四個(gè)需求。某些數(shù)據(jù)分析是例行過程，按照某種固定模式周期性執(zhí)行；而另一些則是從中間平臺(tái)發(fā)起的查 詢。實(shí)際上，該問題的解決方案就是最大化磁盤空間利用率。Fast query processing為了滿足實(shí)時(shí)性的網(wǎng)站請(qǐng)求和支持高并發(fā)用戶提交查詢的大量讀負(fù)載，查詢響應(yīng)時(shí)間是非常關(guān)鍵的，這要求底層存儲(chǔ)結(jié)構(gòu)能夠隨著查詢數(shù)量的增加而保持高速的查詢處理。Fast data loading對(duì)于Facebook的產(chǎn)品數(shù)據(jù)倉庫而言，快速加載數(shù)據(jù)（寫數(shù)據(jù)）是非常關(guān)鍵的。與傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)相比，RCFile更有效地滿足了基于MapReduce的 數(shù)據(jù)倉庫的四個(gè)關(guān)鍵需求，即Fast data loading、Fast query processing、Highly efficient storage space utilization和Strong adaptivity to highly dy
環(huán)評(píng)公示相關(guān)推薦
鄂ICP備17016276號(hào)-1