Facebook在數(shù)據(jù)倉庫上遇到的存儲可擴展性的挑戰(zhàn)是獨一無二的。我們基于Hive的數(shù)據(jù)倉庫中存儲了超過300PB的數(shù)據(jù)，并且以每日新增600TB的速度增長。去年這個數(shù)據(jù)倉庫所存儲的數(shù)據(jù)量增長了3倍。考慮到這個增長趨勢，存儲效率問題是我們數(shù)據(jù)倉庫基礎設施方面目前乃至將來一段時間內(nèi)最需要關注的。

在提高數(shù)據(jù)倉庫的存儲效率方面我們有許多創(chuàng)新點，例如建立冷數(shù)據(jù)存儲的數(shù)據(jù)中心、對HDFS采用類似RAID的技術在保證數(shù)據(jù)高可用性不變的前提下降低冗余率、在數(shù)據(jù)被寫入到HDFS之前先做壓縮以減少數(shù)據(jù)占用的存儲空間。在Facebook對于大量原始日志的轉換（transformations）操作最廣泛使用的系統(tǒng)是Hive，F(xiàn)acebook的Hive是建立在 Corona Map-Reduce框架之上的用于處理數(shù)據(jù)、建立數(shù)據(jù)倉庫表等工作的查詢引擎。在這篇文章中，我們主要討論Hive表的存儲格式的演化，這個工作主要的目的是使Hive表的存儲格式要盡可能高效壓縮原始數(shù)據(jù)。

RCFile

我們的數(shù)據(jù)倉庫中數(shù)據(jù)被加載到表里面時首先使用的存儲格式是Facebook自己開發(fā)的 Record-Columnar File Format(RCFile)。RCFile是一種“允許按行查詢，提供了列存儲的壓縮效率”的混合列存儲格式。它的核心思想是首先把Hive表水平切分成多個行組（row groups），然后組內(nèi)按照列垂直切分，這樣列與列的數(shù)據(jù)在磁盤上就是連續(xù)的存儲塊了。

當一個行組內(nèi)的所有列寫到磁盤時，RCFile就會以列為單位對數(shù)據(jù)使用類似zlib/lzo的算法進行壓縮。當讀取列數(shù)據(jù)的時候使用惰性解壓策略（ lazy decompression），也就是說用戶的某個查詢?nèi)绻皇巧婕暗揭粋€表中的部分列的時候，RCFile會跳過不需要的列的解壓縮和反序列化的過程。通過在我們的數(shù)據(jù)倉庫中選取有代表性的例子實驗，RCFile能夠提供5倍的壓縮比。

超越RCFile，下一步采用什么樣的方法？

隨著數(shù)據(jù)倉庫中存儲的數(shù)據(jù)量持續(xù)增長，組內(nèi)的工程師開始研究提高壓縮效率的技術和方法。研究的焦點集中在列級別的編碼方法，例如行程長度編碼（run-length encoding）、詞典編碼（dictionary encoding）、參考幀編碼（frame of reference encoding）、能夠在通用壓縮過程之前更好的在列級別降低邏輯冗余的數(shù)值編碼方法。我們也嘗試過新的列類型（例如JSON是在Facebook內(nèi)部廣泛使用的格式，把JSON格式的數(shù)據(jù)按照結構化的方式存儲既可以滿足高效查詢的需求，同時也降低了JSON元數(shù)據(jù)存儲的冗余）。我們的實驗表明列級別的編碼如果使用得當?shù)脑捘軌蝻@著提高RCFile的壓縮比。

與此同時，Hortonworks也在嘗試類似的思路去改進Hive的存儲格式。Hortonworks的工程團隊設計和實現(xiàn)了ORCFile（包括存儲格式和讀寫接口），這幫助我們?yōu)镕acebook的數(shù)據(jù)倉庫設計和實現(xiàn)新的存儲格式提供了一個很好的開始。

ORCFile詳解

Hive的數(shù)據(jù)以ORCFile的格式寫到磁盤時，數(shù)據(jù)被分成一系列的256MB的條帶（stripe），一個條帶類似于在RCFile中的一個行組。在每一個條帶內(nèi)，ORCFile首先對每個列的數(shù)據(jù)進行編碼，然后把整個條帶內(nèi)的所有列使用類似zlib壓縮算法進行壓縮。對于一個字符串格式的列使用詞典編碼，而且是對一個條帶內(nèi)的所有的行數(shù)據(jù)放到一起進行列編碼。在每個條帶內(nèi)會對每10,000行數(shù)據(jù)存儲一個索引，并記錄每一列中的最大值和最小值。這些在過濾式的查詢時能夠跳過一些不在范圍內(nèi)的行。

除了壓縮改進，新的存儲格式的一個顯著優(yōu)點就是列和行會以偏移（offset）的形式被記錄，這樣就不需要用分隔符去標記行尾。然而在RCFile中是通過預留某些ASCII值作為分隔符，那么這些分隔符就不允許出現(xiàn)在數(shù)據(jù)流中。同時查詢引擎能夠利用條帶和每一列在文件級別的元數(shù)據(jù)去優(yōu)化查詢效率。

自適應的列編碼

當我們開始在數(shù)據(jù)倉庫中測試ORCFile的時候，我們發(fā)現(xiàn)有些Hive表壓縮表現(xiàn)良好，有的反而會引起數(shù)據(jù)膨脹，導致我們數(shù)據(jù)倉庫中一個有代表性的表集合上的測試中壓縮效率提升非常不明顯。因為如果某一列數(shù)據(jù)的熵很大的時候，詞典編碼會引起數(shù)據(jù)膨脹，所以如果默認對所有的字符串類型的列都進行詞典編碼是不合適的。對于某一列是否需要詞典編碼我們考慮兩種方法：通過用戶指定的列元數(shù)據(jù)靜態(tài)指定；在運行時通過考察列值的情況動態(tài)選擇編碼方法。我們選擇后者是因為它能夠很好的兼容我們數(shù)據(jù)倉庫已有的數(shù)量眾多的表。

我們進行了很多測試目的是找到最大化壓縮比同時又不影響ORCFile寫性能的方法。由于字符串類型在我們最大的那些表中占據(jù)主導，同時數(shù)據(jù)倉庫中大約80%的列是由字符串類型組成的，所以優(yōu)化字符串類型的壓縮比最重要。對于每個條帶內(nèi)每一列的不同數(shù)值的數(shù)目設置一個閾值，同時我們修改了ORCFile的寫接口，對于每個條帶內(nèi)的數(shù)據(jù)如果使用詞典編碼能夠帶來壓縮效率提升我們就對數(shù)據(jù)進行詞典編碼。同時我們對列值進行采樣，考察組成列值的字符集合。因為如果這個字符集合比較小的話像zlib這樣的通用壓縮算法可以有比較好的壓縮比，這種情況下詞典編碼就不是很必要了，有的時候甚至會起副作用。

對于很大的整形數(shù)據(jù)，我們可以考慮使用行程長度編碼或者詞典編碼。大多數(shù)情況下行程長度編碼只比通用壓縮算法稍微好一點，然而當列數(shù)據(jù)是由少數(shù)幾個不同數(shù)值組成的時候詞典編碼會表現(xiàn)比較出色。基于這個結果，對于很大的整形數(shù)據(jù)我們也是采用詞典編碼而不是行程長度編碼。對于字符串類型和數(shù)值類型的數(shù)據(jù)采用這個思路編碼能夠給ORCFile帶來很高的壓縮效率。

我們也實驗了很多其他的提高壓縮比的方法。其中值得一提的思路就是自適應行程長度編碼，也就是一種啟發(fā)式的策略，只有當使用行程長度編碼能夠提高壓縮比的時候才會使用。在ORCFile的開源版本中這個策略應用到為整形數(shù)據(jù)在多種方法中自適應地選擇編碼算法的過程中。這個方法雖然提高了壓縮比，但是寫性能下降了。我們也研究了條帶大小對壓縮比的影響。出乎我們的意料，增加條帶的大小并不能顯著提高壓縮比。因為隨著條帶大小的增加，詞典元素的數(shù)量會增加，這會導致編碼后的列值所占用的字節(jié)數(shù)量增大。所以想要存儲較少的詞典帶來的優(yōu)勢不符合預期，以256MB作為一個條帶大小的這個經(jīng)驗值還是挺靠譜的。

寫性能

考慮到在我們的規(guī)模下數(shù)據(jù)的寫入速度會影響查詢性能，我們對開源的ORCFile的寫入接口進行了很多改進用于提高寫入性能。其中關鍵的一點是消除冗余或者不必要的操作，同時要優(yōu)化內(nèi)存使用情況。

我們對ORCFile寫接口的改進中最關鍵的就是創(chuàng)建有序詞典的過程。在開源ORCFile的版本中為了保證詞典的有序，寫接口是用紅黑樹（red-black tree）來存儲的詞典。然后在自適應的詞典編碼中，即使某一列不適合使用詞典編碼存儲，它也要花費O(log(n))的時間復雜度向紅黑樹插入一個新的key。如果使用一個存儲高效的哈希映射來存放詞典，只有在需要的時候排序，詞典的內(nèi)存占用量降低了30%，而且更重要的是寫性能提高了1.4倍。為了更快、更高效利用內(nèi)存地調(diào)整詞典大小，初始詞典是由一個字節(jié)數(shù)組為元素的數(shù)組存儲的。然而這會使得訪問詞典元素這個操作非常頻繁，我們選擇使用Airlift庫的Slice類用來代替詞典實現(xiàn)高效內(nèi)存拷貝，能把寫性能再提高20%-30%。

按列打開詞典編碼很耗費計算資源。因為每一列的字符在不同的條帶里會有重復，我們已經(jīng)發(fā)現(xiàn)對于所有條帶統(tǒng)一進行詞典編碼沒有優(yōu)勢。所以我們改進寫接口，基于條帶的子集合判斷列編碼算法，同時接下來的條帶中對應的列會重復上面條帶的算法。也就是說如果寫接口判斷對于這一列的值使用詞典編碼沒有優(yōu)勢，那么在接下來的條帶中會智能地不使用詞典編碼。由于Facebook自有的ORCFile格式帶來的壓縮效率的提升，我們可以降低已經(jīng)使用的zlib的壓縮級別，同時寫性能得到20%的提升。

讀性能

談到讀性能，大家很快就會想到的問題就是惰性列解壓縮（laze column decompression）。例如一個要讀取很多列但是只在某一列有過濾條件的查詢。如果沒有我們實現(xiàn)的惰性解壓縮，所有列都會被讀取并解壓縮。理想情況是只有設置有過濾條件的列被解壓縮和解碼，這樣這個查詢才不會浪費大量的時間在解壓縮和解碼那些無關數(shù)據(jù)上。

為了這個目的，我們利用ORCFile存儲格式中的索引跨步（index strides）給Facebook的ORCFile的讀接口實現(xiàn)了惰性解壓縮和惰性解碼功能。在前面講的例子中，對于有過濾條件的那一列涉及到的所有數(shù)據(jù)將要被解壓縮和解碼。對于其他列的數(shù)據(jù)，我們改變讀接口去讀取條帶內(nèi)相應的索引跨步（對條帶的元數(shù)據(jù)操作），只需要解壓縮和解碼相應索引跨步前面的行數(shù)據(jù)。經(jīng)過我們的測試，這個改進使得在我們Facebook的ORCFile的版本上運行的簡單過濾型（select）查詢比開源版本性能提高了3倍。因為沒有了額外數(shù)據(jù)的惰性解碼，F(xiàn)acebook的ORCFile在這種簡單過濾型查詢的性能也比RCFile高。

總結

通過應用這些改進，在數(shù)據(jù)倉庫數(shù)據(jù)中我們使用ORCFile相比RCFile在壓縮比上帶來了5到8倍的提升。從數(shù)據(jù)倉庫中選擇了一系列典型的查詢和數(shù)據(jù)的測試中，我們發(fā)現(xiàn)Facebook的ORCFile的寫性能會比開源版本高3倍。

我們已經(jīng)把這種新的存儲格式應用到許多數(shù)十PB級別的表數(shù)據(jù)中，通過把數(shù)據(jù)從RCFile改成ORCFile存儲格式，已經(jīng)再生出數(shù)十PB級別的存儲容量。我們正在把這種新的存儲格式向數(shù)據(jù)倉庫中的其他表推廣，這個改進可以達到存儲效率和讀寫性能的雙重提升。我們Facebook內(nèi)部的ORCFile的代碼是開源的，同時我們也在與開源社區(qū)密切配合把這些改進并入Apache Hive的代碼中。

下一步？

在進一步改進ORCFile的壓縮比和讀寫效率方面我們有很多想法。包括支持新的壓縮編碼例如LZ4HC、不同的列當編碼不同時使用不同的壓縮算法和壓縮等級、存儲更多的統(tǒng)計信息并暴露給查詢引擎使用、把開源社區(qū)像謂詞下壓（predicate pushdown）等工作引入Facebook內(nèi)部。另外還有一些其他的改進思路，例如降低源表和派生表的邏輯冗余、對于冷數(shù)據(jù)集的采樣、增加目前暫時以字符串格式存儲的卻有通用需求的Hive原生數(shù)據(jù)類型。

Facebook分析基礎設施組的許多同事參與了ORCFile相關的工作，包括了本文的作者 Pamela Vagata，Kevin Wilfong and Sambavi Muthukrishnan。同時感謝Hortonworks的同事對我們的工作的配合和幫助。

（原文鏈接： Scaling the Facebook data warehouse to 300 PB ，本文是原文的翻譯，翻譯：梁堰波）