深入分析Parquet列式存儲格式

Parquet是面向分析型業務的列式存儲格式，由Twitter和Cloudera合作開發，2015年5月從Apache的孵化器裏畢業成爲Apache頂級項目，最新的版本是1.8.0。

列式存儲

列式存儲和行式存儲相比有哪些優勢呢？

1. 可以跳過不符合條件的數據，只讀取需要的數據，降低IO數據量。
2. 壓縮編碼可以降低磁盤存儲空間。由於同一列的數據類型是一樣的，可以使用更高效的壓縮編碼（例如Run Length Encoding和Delta Encoding）進一步節約存儲空間。
3. 只讀取需要的列，支持向量運算，能夠獲取更好的掃描性能。

當時Twitter的日增數據量達到壓縮之後的100TB+，存儲在HDFS上，工程師會使用多種計算框架（例如MapReduce, Hive, Pig等）對這些數據做分析和挖掘；日誌結構是複雜的嵌套數據類型，例如一個典型的日誌的schema有87列，嵌套了7層。所以需要設計一種列式存儲格式，既能支持關係型數據（簡單數據類型），又能支持複雜的嵌套類型的數據，同時能夠適配多種數據處理框架。

關係型數據的列式存儲，可以將每一列的值直接排列下來，不用引入其他的概念，也不會丟失數據。關係型數據的列式存儲比較好理解，而嵌套類型數據的列存儲則會遇到一些麻煩。如圖1所示，我們把嵌套數據類型的一行叫做一個記錄（record)，嵌套數據類型的特點是一個record中的column除了可以是Int, Long, String這樣的原語（primitive）類型以外，還可以是List, Map, Set這樣的複雜類型。在行式存儲中一行的多列是連續的寫在一起的，在列式存儲中數據按列分開存儲，例如可以只讀取A.B.C這一列的數據而不去讀A.E和A.B.D，那麼如何根據讀取出來的各個列的數據重構出一行記錄呢？

圖1 行式存儲和列式存儲

Parquet適配多種計算框架

Google的Dremel系統解決了這個問題，核心思想是使用“record shredding and assembly algorithm”來表示複雜的嵌套數據類型，同時輔以按列的高效壓縮和編碼技術，實現降低存儲空間，提高IO效率，降低上層應用延遲。Parquet就是基於Dremel的數據模型和算法實現的。

Parquet是語言無關的，而且不與任何一種數據處理框架綁定在一起，適配多種語言和組件，能夠與Parquet配合的組件有：

查詢引擎: Hive, Impala, Pig, Presto, Drill, Tajo, HAWQ, IBM Big SQL

計算框架: MapReduce, Spark, Cascading, Crunch, Scalding, Kite

數據模型: Avro, Thrift, Protocol Buffers, POJOs

那麼Parquet是如何與這些組件協作的呢？這個可以通過圖2來說明。數據從內存到Parquet文件或者反過來的過程主要由以下三個部分組成：

1, 存儲格式(storage format)

parquet-format項目定義了Parquet內部的數據類型、存儲格式等。

2, 對象模型轉換器(object model converters)

這部分功能由parquet-mr項目來實現，主要完成外部對象模型與Parquet內部數據類型的映射。

3, 對象模型(object models)

對象模型可以簡單理解爲內存中的數據表示，Avro, Thrift, Protocol Buffers, Hive SerDe, Pig Tuple, Spark SQL InternalRow等這些都是對象模型。Parquet也提供了一個example object model 幫助大家理解。

例如parquet-mr項目裏的parquet-pig項目就是負責把內存中的Pig Tuple序列化並按列存儲成Parquet格式，以及反過來把Parquet文件的數據反序列化成Pig Tuple。

這裏需要注意的是Avro, Thrift, Protocol Buffers都有他們自己的存儲格式，但是Parquet並沒有使用他們，而是使用了自己在parquet-format項目裏定義的存儲格式。所以如果你的應用使用了Avro等對象模型，這些數據序列化到磁盤還是使用的parquet-mr定義的轉換器把他們轉換成Parquet自己的存儲格式。

圖2 Parquet項目的結構

Parquet數據模型

理解Parquet首先要理解這個列存儲格式的數據模型。我們以一個下面這樣的schema和數據爲例來說明這個問題。

message AddressBook {
 required string owner;
 repeated string ownerPhoneNumbers;
 repeated group contacts {
   required string name;
   optional string phoneNumber;
 }
}

這個schema中每條記錄表示一個人的AddressBook。有且只有一個owner，owner可以有0個或者多個ownerPhoneNumbers，owner可以有0個或者多個contacts。每個contact有且只有一個name，這個contact的phoneNumber可有可無。這個schema可以用圖3的樹結構來表示。

每個schema的結構是這樣的：根叫做message，message包含多個fields。每個field包含三個屬性：repetition, type, name。repetition可以是以下三種：required（出現1次），optional（出現0次或者1次），repeated（出現0次或者多次）。type可以是一個group或者一個primitive類型。

Parquet格式的數據類型沒有複雜的Map, List, Set等，而是使用repeated fields 和 groups來表示。例如List和Set可以被表示成一個repeated field，Map可以表示成一個包含有key-value 對的repeated field，而且key是required的。

圖3 AddressBook的樹結構表示

Parquet文件的存儲格式

那麼如何把內存中每個AddressBook對象按照列式存儲格式存儲下來呢？

在Parquet格式的存儲中，一個schema的樹結構有幾個葉子節點，實際的存儲中就會有多少column。例如上面這個schema的數據存儲實際上有四個column，如圖4所示。

圖4 AddressBook實際存儲的列

Parquet文件在磁盤上的分佈情況如圖5所示。所有的數據被水平切分成Row group，一個Row group包含這個Row group對應的區間內的所有列的column chunk。一個column chunk負責存儲某一列的數據，這些數據是這一列的Repetition levels, Definition levels和values（詳見後文）。一個column chunk是由Page組成的，Page是壓縮和編碼的單元，對數據模型來說是透明的。一個Parquet文件最後是Footer，存儲了文件的元數據信息和統計信息。Row group是數據讀寫時候的緩存單元，所以推薦設置較大的Row group從而帶來較大的並行度，當然也需要較大的內存空間作爲代價。一般情況下推薦配置一個Row group大小1G，一個HDFS塊大小1G，一個HDFS文件只含有一個塊。

圖5 Parquet文件格式在磁盤的分佈

拿我們的這個schema爲例，在任何一個Row group內，會順序存儲四個column chunk。這四個column都是string類型。這個時候Parquet就需要把內存中的AddressBook對象映射到四個string類型的column中。如果讀取磁盤上的4個column要能夠恢復出AddressBook對象。這就用到了我們前面提到的 “record shredding and assembly algorithm”。

Striping/Assembly算法

對於嵌套數據類型，我們除了存儲數據的value之外還需要兩個變量Repetition Level(R), Definition Level(D) 才能存儲其完整的信息用於序列化和反序列化嵌套數據類型。Repetition Level和 Definition Level可以說是爲了支持嵌套類型而設計的，但是它同樣適用於簡單數據類型。在Parquet中我們只需定義和存儲schema的葉子節點所在列的Repetition Level和Definition Level。

Definition Level

嵌套數據類型的特點是有些field可以是空的，也就是沒有定義。如果一個field是定義的，那麼它的所有的父節點都是被定義的。從根節點開始遍歷，當某一個field的路徑上的節點開始是空的時候我們記錄下當前的深度作爲這個field的Definition Level。如果一個field的Definition Level等於這個field的最大Definition Level就說明這個field是有數據的。對於required類型的field必須是有定義的，所以這個Definition Level是不需要的。在關係型數據中，optional類型的field被編碼成0表示空和1表示非空（或者反之）。

Repetition Level

記錄該field的值是在哪一個深度上重複的。只有repeated類型的field需要Repetition Level，optional 和 required類型的不需要。Repetition Level = 0 表示開始一個新的record。在關係型數據中，repetion level總是0。

下面用AddressBook的例子來說明Striping和assembly的過程。

對於每個column的最大的Repetion Level和 Definition Level如圖6所示。

圖6 AddressBook的Max Definition Level和Max Repetition Level

下面這樣兩條record：

AddressBook {
 owner: "Julien Le Dem",
 ownerPhoneNumbers: "555 123 4567",
 ownerPhoneNumbers: "555 666 1337",
 contacts: {
   name: "Dmitriy Ryaboy",
   phoneNumber: "555 987 6543",
 },
 contacts: {
   name: "Chris Aniszczyk"
 }
}
AddressBook {
 owner: "A. Nonymous"
}

以contacts.phoneNumber這一列爲例，"555 987 6543"這個contacts.phoneNumber的Definition Level是最大Definition Level=2。而如果一個contact沒有phoneNumber，那麼它的Definition Level就是1。如果連contact都沒有，那麼它的Definition Level就是0。

下面我們拿掉其他三個column只看contacts.phoneNumber這個column，把上面的兩條record簡化成下面的樣子：

AddressBook {
 contacts: {
   phoneNumber: "555 987 6543"
 }
 contacts: {
 }
}
AddressBook {
}

這兩條記錄的序列化過程如圖7所示：

圖7 一條記錄的序列化過程

如果我們要把這個column寫到磁盤上，磁盤上會寫入這樣的數據（圖8）：

圖8 一條記錄的磁盤存儲

注意：NULL實際上不會被存儲，如果一個column value的Definition Level小於該column最大Definition Level的話，那麼就表示這是一個空值。

下面是從磁盤上讀取數據並反序列化成AddressBook對象的過程：

1，讀取第一個三元組R=0, D=2, Value=”555 987 6543”

R=0 表示是一個新的record，要根據schema創建一個新的nested record直到Definition Level=2。

D=2 說明Definition Level=Max Definition Level，那麼這個Value就是contacts.phoneNumber這一列的值，賦值操作contacts.phoneNumber=”555 987 6543”。

2，讀取第二個三元組 R=1, D=1

R=1 表示不是一個新的record，是上一個record中一個新的contacts。

D=1 表示contacts定義了，但是contacts的下一個級別也就是phoneNumber沒有被定義，所以創建一個空的contacts。

3，讀取第三個三元組 R=0, D=0

R=0 表示一個新的record，根據schema創建一個新的nested record直到Definition Level=0，也就是創建一個AddressBook根節點。

可以看出在Parquet列式存儲中，對於一個schema的所有葉子節點會被當成column存儲，而且葉子節點一定是primitive類型的數據。對於這樣一個primitive類型的數據會衍生出三個sub columns (R, D, Value)，也就是從邏輯上看除了數據本身以外會存儲大量的Definition Level和Repetition Level。那麼這些Definition Level和Repetition Level是否會帶來額外的存儲開銷呢？實際上這部分額外的存儲開銷是可以忽略的。因爲對於一個schema來說level都是有上限的，而且非repeated類型的field不需要Repetition Level，required類型的field不需要Definition Level，也可以縮短這個上限。例如對於Twitter的7層嵌套的schema來說，只需要3個bits就可以表示這兩個Level了。

對於存儲關係型的record，record中的元素都是非空的（NOT NULL in SQL）。Repetion Level和Definition Level都是0，所以這兩個sub column就完全不需要存儲了。所以在存儲非嵌套類型的時候，Parquet格式也是一樣高效的。

上面演示了一個column的寫入和重構，那麼在不同column之間是怎麼跳轉的呢，這裏用到了有限狀態機的知識，詳細介紹可以參考Dremel。

數據壓縮算法

列式存儲給數據壓縮也提供了更大的發揮空間，除了我們常見的snappy, gzip等壓縮方法以外，由於列式存儲同一列的數據類型是一致的，所以可以使用更多的壓縮算法。

壓縮算法	使用場景
Run Length Encoding	重複數據
Delta Encoding	有序數據集，例如timestamp，自動生成的ID，以及監控的各種metrics
Dictionary Encoding	小規模的數據集合，例如IP地址
Prefix Encoding	Delta Encoding for strings

性能

Parquet列式存儲帶來的性能上的提高在業內已經得到了充分的認可，特別是當你們的表非常寬（column非常多）的時候，Parquet無論在資源利用率還是性能上都優勢明顯。具體的性能指標詳見參考文檔。

Spark已經將Parquet設爲默認的文件存儲格式，Cloudera投入了很多工程師到Impala+Parquet相關開發中，Hive/Pig都原生支持Parquet。Parquet現在爲Twitter至少節省了1/3的存儲空間，同時節省了大量的表掃描和反序列化的時間。這兩方面直接反應就是節約成本和提高性能。

如果說HDFS是大數據時代文件系統的事實標準的話，Parquet就是大數據時代存儲格式的事實標準。