1. 程式人生 > >兩種資料格式(Parquet/ORCfile)淺析

兩種資料格式(Parquet/ORCfile)淺析

一、首先來看下ORCfile

Orcfile(Optimized Row Columnar)hive 0.11版裡引入的新的儲存格式,是對之前的RCFile儲存格式的優化,是HortonWorks開源的。看下orcfile的儲存格式:

 

 

可以看到每個Orc檔案由1個或多個stripe組成,每個stripe250MB大小,這個Stripe實際相當於之前的rcfile裡的RowGroup概念,不過大小由4MB->250MB,這樣應該能提升順序讀的吞吐率。每個Stripe裡有三部分組成,分別是Index Data,Row Data,Stripe Footer

每個Stripe都包含

index datarow data以及stripe footerStripe footer包含流位置的目錄,Row data在表掃描的時候會用到。

Index data包含每列的最大和最小值以及每列所在的行。行索引裡面提供了偏移量,它可以跳到正確的壓縮塊位置。

通過行索引,可以在stripe中快速讀取的過程中可以跳過很多行,儘管這個stripe的大小很大。在預設情況下,最大可以跳過10000行。

因為可以通過過濾預測跳過很多行,因而可以在表的 secondary keys 進行排序,從而可以大幅減少執行時間。比如你的表的主分割槽是交易日期,那麼你可以對次分割槽(statezip code

以及last name)進行排序。

每個檔案有一個File Footer,這裡面存的是每個Stripe的行數,每個Column的資料型別資訊等;每個檔案的尾部是一個PostScript,這裡面記錄了整個檔案的壓縮型別以及FileFooter的長度資訊等。在讀取檔案時,會seek到檔案尾部讀PostScript,從裡面解析到File Footer長度,再讀FileFooter,從裡面解析到各個Stripe資訊,再讀各個Stripe,即從後往前讀。

ORCFILE主要特點:

混合儲存結構,先按行儲存,一組行資料叫stripesstripes內部按列式儲存。

支援各種複雜的資料型別,比如: datetime, decimal, 

以及一些複雜型別(struct, list, map, and union)

在檔案中儲存了一些輕量級的索引資料;

基於資料型別的塊模式壓縮:

ainteger型別的列用行程長度編碼(run-length encoding)

bString型別的列用字典編碼(dictionary encoding)

二、再來看看Parquet

我們的開源專案 Parquet 是 Hadoop 上的一種支援列式儲存檔案格式,起初只是 Twitter 和 Coudera 在合作開發,發展到現在已經有包括 Criteo公司 在內的許多其他貢獻者了. Parquet 用 Dremel 的論文中描述的方式,把巢狀結構儲存成扁平格式。

儘管 Parquet 是一個面向列的檔案格式,不要期望每列一個數據檔案。Parquet 在同一個資料檔案中儲存一行中的所有資料,以確保在同一個節點上處理時一行的所有列都可用。Parquet 所做的是設定 HDFS 塊大小和最大資料檔案大小為 1GB,以確保 I/O 和網路傳輸請求適用於大批量資料(What Parquet does is to set an HDFS block size and a maximum data file size of 1GB, to ensure that I/O and network transfer requests apply to large batches of data)

在成G的空間內,一組行的資料會重新排列,以便第一行所有的值被重組為一個連續的塊,然後是第二行的所有值,依此類推。

為了在列式儲存中可以表達巢狀結構,用叫做 definition levelrepetition level兩個值描述。分別表達某個值在整個巢狀格式中,最深巢狀層數,以及在同一個巢狀層級中第幾個值。

Parquet 使用一些自動壓縮技術,例如行程編碼(run-length encoding,RLE) 和字典編碼(dictionary encoding),基於實際資料值的分析。一當資料值被編碼成緊湊的格式,使用壓縮演算法,編碼的資料可能會被進一步壓縮。Impala 建立的 Parquet 資料檔案可以使用 Snappy, GZip, 或不進行壓縮;Parquet 規格還支援 LZO 壓縮,但是目前 Impala 不支援 LZO 壓縮的 Parquet 檔案。

除了應用到整個資料檔案的 Snappy 或 GZip 壓縮之外,RLE 和欄位編碼是 Impala 自動應用到 Parquet 資料值群體的壓縮技術。

綜合來看,ORCfielparquet本質上都是列上儲存,大同小異。parquet主要特點是支援巢狀格式,ORCfile主要特點是strips中有輕量級的index data。所以這兩種資料儲存格式完全是可以相互借鑑融合的。

列示儲存不是hadoop首創,是從傳統資料庫中發展而來。最後來看看wiki中介紹的列示儲存的歷史:

Column stores or transposed files have been implemented from the early days of DBMS development. TAXIR was the first application of a column-oriented database storage system with focus on information-retrieval in biology[11] in 1969. Statistics Canada implemented the RAPID system[12] in 1976 and used it for processing and retrieval of the Canadian Census of Population and Housing as well as several other statistical applications. RAPID was shared with other statistical organizations throughout the world and used widely in the 1980s. It continued to be used by Statistics Canada until the 1990s.

KDB was the first commercially available column-oriented database developed in 1993 followed in 1995 by Sybase IQ. However, that has changed rapidly since about 2004 with many open source and commercial implementations. MonetDB was released under an open-source license on September 30, 2004,[13] followed closely by the now defunct C-Store.[14]Vertica was eventually developed out of C-Store, while the MonetDB-related X100 project evolved into VectorWise.[15][16]