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

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

RCFile

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

當一個行組內的所有列寫到磁盤時，RCFile就會以列為單位對數據使用類似zlib/lzo的算法進行壓縮。當讀取列數據的時候使用惰性解壓策略（ lazy decompression），也就是說用戶的某個查詢如果只是涉及到一個表中的部分列的時候，RCFile會跳過不需要的列的解壓縮和反序列化的過程。通過在我們的數據倉庫中選取有代表性的例子實驗，RCFile能夠提供5倍的壓縮比。

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

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

與此同時，Hortonworks也在嘗試類似的思路去改進Hive的存儲格式。Hortonworks的工程團隊設計和實現了ORCFile（包括存儲格式和讀寫接口），這幫助我們為Facebook的數據倉庫設計和實現新的存儲格式提供了一個很好的開始。

ORCFile詳解

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

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

自適應的列編碼

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

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

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

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

寫性能

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

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

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

讀性能

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

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

總結

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

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

下一步？

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

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

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