Parquet與ORC：高性能列式存儲格式(收藏)

背景

隨着大數據時代的到來，越來越多的數據流向了Hadoop生態圈，同時對於能夠快速的從TB甚至PB級別的數據中獲取有價值的數據對於一個產品和公司來說更加重要，在Hadoop生態圈的快速發展過程中，涌現了一批開源的數據分析引擎，例如Hive、Spark SQL、Impala、Presto等，同時也產生了多個高性能的列式存儲格式，例如RCFile、ORC、Parquet等，本文主要從實現的角度上對比分析ORC和Parquet兩種典型的列存格式，並對它們做了相應的對比測試。

列式存儲

由於OLAP查詢的特點，列式存儲可以提升其查詢性能，但是它是如何做到的呢？這就要從列式存儲的原理說起，從圖1中可以看到，相對於關系數據庫中通常使用的行式存儲，在使用列式存儲時每一列的所有元素都是順序存儲的。由此特點可以給查詢帶來如下的優化：

• 查詢的時候不需要掃描全部的數據，而只需要讀取每次查詢涉及的列，這樣可以將I/O消耗降低N倍，另外可以保存每一列的統計信息(min、max、sum等)，實現部分的謂詞下推。
• 由於每一列的成員都是同構的，可以針對不同的數據類型使用更高效的數據壓縮算法，進一步減小I/O。
• 由於每一列的成員的同構性，可以使用更加適合CPU pipeline的編碼方式，減小CPU的緩存失效。

 

 

圖1 行式存儲VS列式存儲

 

嵌套數據格式

通常我們使用關系數據庫存儲結構化數據，而關系數據庫支持的數據模型都是扁平式的，而遇到諸如List、Map和自定義Struct的時候就需要用戶自己解析，但是在大數據環境下，數據的來源多種多樣，例如埋點數據，很可能需要把程序中的某些對象內容作為輸出的一部分，而每一個對象都可能是嵌套的，所以如果能夠原生的支持這種數據，查詢的時候就不需要額外的解析便能獲得想要的結果。例如在Twitter，他們一個典型的日志對象（一條記錄）有87個字段，其中嵌套了7層，如下圖。

 

 

圖2 嵌套數據模型

 

隨着嵌套格式的數據的需求日益增加，目前Hadoop生態圈中主流的查詢引擎都支持更豐富的數據類型，例如Hive、SparkSQL、Impala等都原生的支持諸如struct、map、array這樣的復雜數據類型，這樣促使各種存儲格式都需要支持嵌套數據格式。

Parquet存儲格式

Apache Parquet是Hadoop生態圈中一種新型列式存儲格式，它可以兼容Hadoop生態圈中大多數計算框架(Mapreduce、Spark等)，被多種查詢引擎支持（Hive、Impala、Drill等），並且它是語言和平台無關的。Parquet最初是由Twitter和Cloudera合作開發完成並開源，2015年5月從Apache的孵化器里畢業成為Apache頂級項目。

Parquet最初的靈感來自Google於2010年發表的Dremel論文，文中介紹了一種支持嵌套結構的存儲格式，並且使用了列式存儲的方式提升查詢性能，在Dremel論文中還介紹了Google如何使用這種存儲格式實現並行查詢的，如果對此感興趣可以參考論文和開源實現Drill。

數據模型

Parquet支持嵌套的數據模型，類似於Protocol Buffers，每一個數據模型的schema包含多個字段，每一個字段有三個屬性：重復次數、數據類型和字段名，重復次數可以是以下三種：required(只出現1次)，repeated(出現0次或多次)，optional(出現0次或1次)。每一個字段的數據類型可以分成兩種：group(復雜類型)和primitive(基本類型)。例如Dremel中提供的Document的schema示例，它的定義如下：

message Document {
  required int64 DocId;
  optional group Links {
    repeated int64 Backward;
    repeated int64 Forward; 
  }
  repeated group Name {
    repeated group Language {
      required string Code;
      optional string Country; 
     }
    optional string Url; 
  }
}

可以把這個Schema轉換成樹狀結構，根節點可以理解為repeated類型，如圖3。

 

 

圖3 Parquet的schema結構

 

可以看出在Schema中所有的基本類型字段都是葉子節點，在這個Schema中一共存在6個葉子節點，如果把這樣的Schema轉換成扁平式的關系模型，就可以理解為該表包含六個列。Parquet中沒有Map、Array這樣的復雜數據結構，但是可以通過repeated和group組合來實現的。由於一條記錄中某一列可能出現零次或者多次，需要標示出哪些列的值構成一條完整的記錄。這是由Striping/Assembly算法實現的。

由於Parquet支持的數據模型比較松散，可能一條記錄中存在比較深的嵌套關系，如果為每一條記錄都維護一個類似的樹狀結可能會占用較大的存儲空間，因此Dremel論文中提出了一種高效的對於嵌套數據格式的壓縮算法：Striping/Assembly算法。它的原理是每一個記錄中的每一個成員值有三部分組成：Value、Repetition level和Definition level。value記錄了該成員的原始值，可以根據特定類型的壓縮算法進行壓縮，兩個level值用於記錄該值在整個記錄中的位置。對於repeated類型的列，Repetition level值記錄了當前值屬於哪一條記錄以及它處於該記錄的什么位置；對於repeated和optional類型的列，可能一條記錄中某一列是沒有值的，假設我們不記錄這樣的值就會導致本該屬於下一條記錄的值被當做當前記錄的一部分，從而造成數據的錯誤，因此對於這種情況需要一個占位符標示這種情況。

通過Striping/Assembly算法，parquet可以使用較少的存儲空間表示復雜的嵌套格式，並且通常Repetition level和Definition level都是較小的整數值，可以通過RLE算法對其進行壓縮，進一步降低存儲空間。

文件結構

Parquet文件是以二進制方式存儲的，是不可以直接讀取和修改的，Parquet文件是自解析的，文件中包括該文件的數據和元數據。在HDFS文件系統和Parquet文件中存在如下幾個概念：

• HDFS塊(Block)：它是HDFS上的最小的副本單位，HDFS會把一個Block存儲在本地的一個文件並且維護分散在不同的機器上的多個副本，通常情況下一個Block的大小為256M、512M等。
• HDFS文件(File)：一個HDFS的文件，包括數據和元數據，數據分散存儲在多個Block中。
• 行組(Row Group)：按照行將數據物理上划分為多個單元，每一個行組包含一定的行數，在一個HDFS文件中至少存儲一個行組，Parquet讀寫的時候會將整個行組緩存在內存中，所以如果每一個行組的大小是由內存大的小決定的。
• 列塊(Column Chunk)：在一個行組中每一列保存在一個列塊中，行組中的所有列連續的存儲在這個行組文件中。不同的列塊可能使用不同的算法進行壓縮。
• 頁(Page)：每一個列塊划分為多個頁，一個頁是最小的編碼的單位，在同一個列塊的不同頁可能使用不同的編碼方式。

通常情況下，在存儲Parquet數據的時候會按照HDFS的Block大小設置行組的大小，由於一般情況下每一個Mapper任務處理數據的最小單位是一個Block，這樣可以把每一個行組由一個Mapper任務處理，增大任務執行並行度。Parquet文件的格式如下圖所示。

 

 

圖4 Parquet文件結構

 

上圖展示了一個Parquet文件的結構，一個文件中可以存儲多個行組，文件的首位都是該文件的Magic Code，用於校驗它是否是一個Parquet文件，Footer length存儲了文件元數據的大小，通過該值和文件長度可以計算出元數據的偏移量，文件的元數據中包括每一個行組的元數據信息和當前文件的Schema信息。除了文件中每一個行組的元數據，每一頁的開始都會存儲該頁的元數據，在Parquet中，有三種類型的頁：數據頁、字典頁和索引頁。數據頁用於存儲當前行組中該列的值，字典頁存儲該列值的編碼字典，每一個列塊中最多包含一個字典頁，索引頁用來存儲當前行組下該列的索引，目前Parquet中還不支持索引頁，但是在后面的版本中增加。

數據訪問

說到列式存儲的優勢，Project下推是無疑最突出的，它意味着在獲取表中原始數據時只需要掃描查詢中需要的列，由於每一列的所有值都是連續存儲的，避免掃描整個表文件內容。

在Parquet中原生就支持Project下推，執行查詢的時候可以通過Configuration傳遞需要讀取的列的信息，這些列必須是Schema的子集，Parquet每次會掃描一個Row Group的數據，然后一次性得將該Row Group里所有需要的列的Cloumn Chunk都讀取到內存中，每次讀取一個Row Group的數據能夠大大降低隨機讀的次數，除此之外，Parquet在讀取的時候會考慮列是否連續，如果某些需要的列是存儲位置是連續的，那么一次讀操作就可以把多個列的數據讀取到內存。

在數據訪問的過程中，Parquet還可以利用每一個row group生成的統計信息進行謂詞下推，這部分信息包括該Column Chunk的最大值、最小值和空值個數。通過這些統計值和該列的過濾條件可以判斷該Row Group是否需要掃描。另外Parquet未來還會增加諸如Bloom Filter和Index等優化數據，更加有效的完成謂詞下推。

ORC文件格式

ORC文件格式是一種Hadoop生態圈中的列式存儲格式，它的產生早在2013年初，最初產生自Apache Hive，用於降低Hadoop數據存儲空間和加速Hive查詢速度。和Parquet類似，它並不是一個單純的列式存儲格式，仍然是首先根據行組分割整個表，在每一個行組內進行按列存儲。ORC文件是自描述的，它的元數據使用Protocol Buffers序列化，並且文件中的數據盡可能的壓縮以降低存儲空間的消耗，目前也被Spark SQL、Presto等查詢引擎支持，但是Impala對於ORC目前沒有支持，仍然使用Parquet作為主要的列式存儲格式。2015年ORC項目被Apache項目基金會提升為Apache頂級項目。

數據模型

和Parquet不同，ORC原生是不支持嵌套數據格式的，而是通過對復雜數據類型特殊處理的方式實現嵌套格式的支持，例如對於如下的hive表：

CREATE TABLE `orcStructTable`(
  `name` string,
  `course` struct<course:string,score:int>,
  `score` map<string,int>,
  `work_locations` array<string>)

ORC格式會將其轉換成如下的樹狀結構：

 

 

圖5 ORC的schema結構

 

在ORC的結構中這個schema包含10個column，其中包含了復雜類型列和原始類型的列，前者包括LIST、STRUCT、MAP和UNION類型，后者包括BOOLEAN、整數、浮點數、字符串類型等，其中STRUCT的孩子節點包括它的成員變量，可能有多個孩子節點，MAP有兩個孩子節點，分別為key和value，LIST包含一個孩子節點，類型為該LIST的成員類型，UNION一般不怎么用得到。每一個Schema樹的根節點為一個Struct類型，所有的column按照樹的中序遍歷順序編號。

ORC只需要存儲schema樹中葉子節點的值，而中間的非葉子節點只是做一層代理，它們只需要負責孩子節點值得讀取，只有真正的葉子節點才會讀取數據，然后交由父節點封裝成對應的數據結構返回。

文件結構

和Parquet類似，ORC文件也是以二進制方式存儲的，所以是不可以直接讀取，ORC文件也是自解析的，它包含許多的元數據，這些元數據都是同構ProtoBuffer進行序列化的。ORC的文件結構入圖6，其中涉及到如下的概念：

• ORC文件：保存在文件系統上的普通二進制文件，一個ORC文件中可以包含多個stripe，每一個stripe包含多條記錄，這些記錄按照列進行獨立存儲，對應到Parquet中的row group的概念。
• 文件級元數據：包括文件的描述信息PostScript、文件meta信息（包括整個文件的統計信息）、所有stripe的信息和文件schema信息。
• stripe：一組行形成一個stripe，每次讀取文件是以行組為單位的，一般為HDFS的塊大小，保存了每一列的索引和數據。
• stripe元數據：保存stripe的位置、每一個列的在該stripe的統計信息以及所有的stream類型和位置。
• row group：索引的最小單位，一個stripe中包含多個row group，默認為10000個值組成。
• stream：一個stream表示文件中一段有效的數據，包括索引和數據兩類。索引stream保存每一個row group的位置和統計信息，數據stream包括多種類型的數據，具體需要哪幾種是由該列類型和編碼方式決定。

 

 

圖6 ORC文件結構

 

在ORC文件中保存了三個層級的統計信息，分別為文件級別、stripe級別和row group級別的，他們都可以用來根據Search ARGuments（謂詞下推條件）判斷是否可以跳過某些數據，在統計信息中都包含成員數和是否有null值，並且對於不同類型的數據設置一些特定的統計信息。

數據訪問

讀取ORC文件是從尾部開始的，第一次讀取16KB的大小，盡可能的將Postscript和Footer數據都讀入內存。文件的最后一個字節保存着PostScript的長度，它的長度不會超過256字節，PostScript中保存着整個文件的元數據信息，它包括文件的壓縮格式、文件內部每一個壓縮塊的最大長度(每次分配內存的大小)、Footer長度，以及一些版本信息。在Postscript和Footer之間存儲着整個文件的統計信息(上圖中未畫出)，這部分的統計信息包括每一個stripe中每一列的信息，主要統計成員數、最大值、最小值、是否有空值等。

接下來讀取文件的Footer信息，它包含了每一個stripe的長度和偏移量，該文件的schema信息(將schema樹按照schema中的編號保存在數組中)、整個文件的統計信息以及每一個row group的行數。

處理stripe時首先從Footer中獲取每一個stripe的其實位置和長度、每一個stripe的Footer數據(元數據，記錄了index和data的的長度)，整個striper被分為index和data兩部分，stripe內部是按照row group進行分塊的(每一個row group中多少條記錄在文件的Footer中存儲)，row group內部按列存儲。每一個row group由多個stream保存數據和索引信息。每一個stream的數據會根據該列的類型使用特定的壓縮算法保存。在ORC中存在如下幾種stream類型：

• PRESENT：每一個成員值在這個stream中保持一位(bit)用於標示該值是否為NULL，通過它可以只記錄部位NULL的值
• DATA：該列的中屬於當前stripe的成員值。
• LENGTH：每一個成員的長度，這個是針對string類型的列才有的。
• DICTIONARY_DATA：對string類型數據編碼之后字典的內容。
• SECONDARY：存儲Decimal、timestamp類型的小數或者納秒數等。
• ROW_INDEX：保存stripe中每一個row group的統計信息和每一個row group起始位置信息。

在初始化階段獲取全部的元數據之后，可以通過includes數組指定需要讀取的列編號，它是一個boolean數組，如果不指定則讀取全部的列，還可以通過傳遞SearchArgument參數指定過濾條件，根據元數據首先讀取每一個stripe中的index信息，然后根據index中統計信息以及SearchArgument參數確定需要讀取的row group編號，再根據includes數據決定需要從這些row group中讀取的列，通過這兩層的過濾需要讀取的數據只是整個stripe多個小段的區間，然后ORC會盡可能合並多個離散的區間盡可能的減少I/O次數。然后再根據index中保存的下一個row group的位置信息調至該stripe中第一個需要讀取的row group中。

由於ORC中使用了更加精確的索引信息，使得在讀取數據時可以指定從任意一行開始讀取，更細粒度的統計信息使得讀取ORC文件跳過整個row group，ORC默認會對任何一塊數據和索引信息使用ZLIB壓縮，因此ORC文件占用的存儲空間也更小，這點在后面的測試對比中也有所印證。

在新版本的ORC中也加入了對Bloom Filter的支持，它可以進一步提升謂詞下推的效率，在Hive 1.2.0版本以后也加入了對此的支持。

性能測試

為了對比測試兩種存儲格式，我選擇使用TPC-DS數據集並且對它進行改造以生成寬表、嵌套和多層嵌套的數據。使用最常用的Hive作為SQL引擎進行測試。

測試環境

• Hadoop集群：物理測試集群，四台DataNode/NodeManager機器，每個機器32core+128GB，測試時使用整個集群的資源。
• Hive：Hive 1.2.1版本，使用hiveserver2啟動，本機MySql作為元數據庫，jdbc方式提交查詢SQL
• 數據集：100GB TPC-DS數據集，選取其中的Store_Sales為事實表的模型作為測試數據
• 查詢SQL：選擇TPC-DS中涉及到上述模型的10條SQL並對其進行改造。

測試場景和結果

整個測試設置了四種場景，每一種場景下對比測試數據占用的存儲空間的大小和相同查詢執行消耗的時間對比，除了場景一基於原始的TPC-DS數據集外，其余的數據都需要進行數據導入，同時對比這幾個場景的數據導入時間。

場景一：一個事實表、多個維度表，復雜的join查詢。

基於原始的TPC-DS數據集。

Store_Sales表記錄數：287,997,024，表大小為：

• 原始Text格式，未壓縮 : 38.1 G
• ORC格式，默認壓縮（ZLIB）,一共1800+個分區 : 11.5 G
• Parquet格式，默認壓縮（Snappy），一共1800+個分區 ： 14.8 G

查詢測試結果：

 

 

場景二：維度表和事實表join之后生成的寬表，只在一個表上做查詢。

整個測試設置了四種場景，每一種場景下對比測試數據占用的存儲空間的大小和相同查詢執行消耗的時間對比，除了場景一基於原始的TPC-DS數據集外，其余的數據都需要進行數據導入，同時對比這幾個場景的數據導入時間。選取數據模型中的store_sales, household_demographics, customer_address, date_dim, store表生成一個扁平式寬表(store_sales_wide_table)，基於這個表執行查詢，由於場景一種選擇的query大多數不能完全match到這個寬表，所以對場景1中的SQL進行部分改造。

store_sales_wide_table表記錄數：263,704,266，表大小為：

• 原始Text格式，未壓縮 ： 149.0 G
• ORC格式，默認壓縮 ： 10.6 G
• PARQUET格式，默認壓縮 ： 12.5 G

查詢測試結果：

 

 

場景三：復雜的數據結構組成的寬表，struct、list、map等（1層）

整個測試設置了四種場景，每一種場景下對比測試數據占用的存儲空間的大小和相同查詢執行消耗的時間對比，除了場景一基於原始的TPC-DS數據集外，其余的數據都需要進行數據導入，同時對比這幾個場景的數據導入時間。在場景二的基礎上，將維度表（除了store_sales表）轉換成一個struct或者map對象，源store_sales表中的字段保持不變。生成有一層嵌套的新表（store_sales_wide_table_one_nested），使用的查詢邏輯相同。

store_sales_wide_table_one_nested表記錄數：263,704,266，表大小為：

• 原始Text格式，未壓縮 ： 245.3 G
• ORC格式，默認壓縮 ： 10.9 G 比store_sales表還小？
• PARQUET格式，默認壓縮 ： 29.8 G

查詢測試結果：

 

 

場景四：復雜的數據結構，多層嵌套。（3層）

整個測試設置了四種場景，每一種場景下對比測試數據占用的存儲空間的大小和相同查詢執行消耗的時間對比，除了場景一基於原始的TPC-DS數據集外，其余的數據都需要進行數據導入，同時對比這幾個場景的數據導入時間。在場景三的基礎上，將部分維度表的struct內的字段再轉換成struct或者map對象，只存在struct中嵌套map的情況，最深的嵌套為三層。生成一個多層嵌套的新表（store_sales_wide_table_more_nested），使用的查詢邏輯相同。

該場景中只涉及一個多層嵌套的寬表，沒有任何分區字段，store_sales_wide_table_more_nested表記錄數：263,704,266，表大小為：

• 原始Text格式，未壓縮 ： 222.7 G
• ORC格式，默認壓縮 ： 10.9 G 比store_sales表還小？
• PARQUET格式，默認壓縮 ： 23.1 G 比一層嵌套表store_sales_wide_table_one_nested要小？

查詢測試結果：

 

 

結果分析

從上述測試結果來看，星狀模型對於數據分析場景並不是很合適，多個表的join會大大拖慢查詢速度，並且不能很好的利用列式存儲帶來的性能提升，在使用寬表的情況下，列式存儲的性能提升明顯，ORC文件格式在存儲空間上要遠優於Text格式，較之於PARQUET格式有一倍的存儲空間提升，在導數據（insert into table select 這樣的方式）方面ORC格式也要優於PARQUET，在最終的查詢性能上可以看到，無論是無嵌套的扁平式寬表，或是一層嵌套表，還是多層嵌套的寬表，兩者的查詢性能相差不多，較之於Text格式有2到3倍左右的提升。

另外，通過對比場景二和場景三的測試結果，可以發現扁平式的表結構要比嵌套式結構的查詢性能有所提升，所以如果選擇使用大寬表，則設計寬表的時候盡可能的將表設計的扁平化，減少嵌套數據。

通過這三種文件存儲格式的測試對比，ORC文件存儲格式無論是在空間存儲、導數據速度還是查詢速度上表現的都較好一些，並且ORC可以一定程度上支持ACID操作，社區的發展目前也是Hive中比較提倡使用的一種列式存儲格式，另外，本次測試主要針對的是Hive引擎，所以不排除存在Hive與ORC的敏感度比PARQUET要高的可能性。

總結

本文主要從數據模型、文件格式和數據訪問流程等幾個方面詳細介紹了Hadoop生態圈中的兩種列式存儲格式——Parquet和ORC，並通過大數據量的測試對兩者的存儲和查詢性能進行了對比。對於大數據場景下的數據分析需求，使用這兩種存儲格式總會帶來存儲和性能上的提升，但是在實際使用時還需要針對實際的數據進行選擇。另外由於不同開源產品可能對不同的存儲格式有特定的優化，所以選擇時還需要考慮查詢引擎的因素。