Hive格式 Parquet與ORC性能測試報告

1、環境說明
Hadoop集羣：使用測試Hadoop集羣，節點：

hadoop230
hadoop231
hadoop232
hadoop233
這幾臺機器配置同樣，具體參數可參考以下： 
CPU數量：2個 
CPU線程數：32個 
內存：128GB 
磁盤：48TB

使用測試機羣上的同一個隊列，使用整個集羣的資源，全部的查詢都是無併發的。

Hive使用官方的hive 1.2.1版本，使用hiveserver2的方式啓動，使用本機的mysql存儲元數據。
2、測試數據生成
測試數據爲TPC-DS基準測試的數據，官方文檔：http://www.tpc.org/information/current_specifications.asp，這個數據集一共24個表：7個事實表，17個維度表，每個事實表和大部分的維度表組成雪花模型，scale_factor設置爲100，也就是生成100GB的數據。

2.1 下載hive-testbench
git clone https://github.com/hortonworks/hive-testbench

這個項目是用於生成TPC-DS數據集而且將其導入到hive，在使用以前須要保證已經將hive、hadoop等命令加入到PATH中。

2.2 編譯
進入該目錄，執行./tpcds-build.sh，該命令會從TPC-DS下載源代碼，並編譯，初始化metaStore，爲導入數據到hive作準備。

2.3 導入數據
導入ORC數據：./tpcds-setup.sh 100 默認的文件格式就是ORC，因此不須要指定存儲格式。 
導入Parquet數據：FORMAT=parquet ./tpcds-setup.sh 100 指定文件格式爲Parquet 
參數100表示生成100GB的數據，改程序首先會生成text格式的數據到臨時目錄，而後再將這些數據轉換成orc或者parquet格式。

2.4 執行測試
該項目在sample-queries-tpcds/testbench.settings文件中給出了一些hive的配置，在啓動hive以前設置這些參數，在sample-queries-tpcds目錄下給出了65個測試SQL，這部分是能夠在hive上跑的TPC-DS查詢，經過參考以前的測試，選擇了其中的50個查詢用於本次測試。

本次測試主要對比orc文件格式和parquet文件格式之間的查詢性能，並和未壓縮的text格式進行對比。hive經過hiveserver2後臺運行，客戶端經過jdbc的方式分別執行每一條查詢，對比查詢使用的Wall Time（每次查詢結束的時間戳減去查詢以前的時間戳）。

2.5 測試數據模型

測試使用的數據是TPC-DS數據集中以store_sales爲事實表的一個雪花狀模型，不一樣的場景基於這個數據集構造不一樣的表結構。

3、測試程序
輸入參數爲待測試的數據庫列表、待測的SQL和循環輪次N
重複執行N輪查看，每一輪開始以前向hiveserver2爲每個數據庫建立一個connection，而後順序的執行每個待測的SQL，* 執行順序爲對dbA執行query一、對dbB執行query1，對dbC執行query1，對dbA執行query2…因爲每個數據存儲在不一樣的目錄下，能夠避免緩存等其餘因素的影響。
每一輪結束以後從新銷燬以前的connection，從新重複2.
時間統計：統計執行每個sql消耗的時間。
對比的存儲格式：TEXT格式、ORC格式和Parquet格式
全部的查詢都是無併發的，防止查詢之間的影響
4、場景設置

場景一：多個事實表、多個維度表，複雜的join查詢
不須要修改任何數據，直接在TPC-DS數據集上執行查詢。text表不是分區表（100個reducer生成），另外兩種存儲格式的事實表是根據data_id進行分區的分區表，執行了兩次測試：一、執行所有的50個查詢，二、選取符合測試數據模型的查詢，分別爲query27,query7,query28,query67,query82,query42,query43,query46,query73,query96，執行N此查詢，計算平均值。

場景二：維度表和事實表join以後生成的寬表，只在一個表上作查詢。
選取數據模型中的store_sales, household_demographics, customer_address, date_dim, store表生成一個扁平式寬表(store_sales_wide_table)，基於這個表執行查詢，因爲場景一種選擇的query大多數不能徹底match到這個寬表，因此使用了一些新的查詢sql，表的模型、load數據的sql和查詢能夠參考附件。

場景三：複雜的數據結構組成的寬表，struct、list、map等（1層）
在場景二的基礎上，將維度表（除了store_sales表）轉換成一個struct或者map對象，源store_sales表中的字段保持不變。生成有一層嵌套的新表（store_sales_wide_table_one_nested），使用的查詢邏輯和場景二中相同，修改sql以知足新的表結構。表的模型、load數據的sql和查詢能夠參考附件。

場景四：複雜的數據結構，多層嵌套。（3層）
在場景三的基礎上，將部分維度表的struct內的字段再轉換成struct或者map對象，只存在struct中嵌套map的狀況，最深的嵌套爲三層。生成一個多層嵌套的新表（store_sales_wide_table_more_nested），使用的查詢邏輯和場景三中相同，修改sql以知足新的表結構。表的模型、load數據的sql和查詢能夠參考附件。

5、測試結果
      每一種場景下對比測試主要關注兩個方面：一、測試數據的大小，以對比不一樣的文件格式在存儲上的優劣，二、相同場景中的不一樣文件格式查詢時間對比。另外，在場景2、場景3、場景四中向新表中導數據的速度爲ORC > parquet > text

場景一
該場景中設計到TPC-DS中所有的表，以store_sales表爲例，該表的記錄數：287,997,024，文件大小爲：

原始Text格式，未壓縮 : 38.1 G
ORC格式，默認壓縮（ZLIB）,一共1800+個分區 : 11.5 G
PARQUET格式，默認壓縮（Snappy?），一共1800+個分區 ： 14.8 G
測試1(執行所有50個查詢)結果：

說明：原始Text格式相差並不大，甚至有的更優？！可能緣由是在多個表join的狀況下，每個查詢須要多達10+個MR任務處理，而這些查詢文件存儲格式之間的查詢主要存在於前幾個讀取原始表記錄的job，然後面的任務相差並不大，進而致使查詢時間的差別減少，從後面單個寬表的測試結果能夠看到，Text和其它兩種列式存儲格式的性能上的差別仍是挺大的。

測試2(執行其中10條查詢)結果：

說明：和測試1相似，相差不大，對於query82，ORC格式差不少？！

場景二
該場景中只涉及到了一個寬表，而且沒有任何分區字段，store_sales_wide_table表記錄數：263,704,266，表大小爲：

原始Text格式，未壓縮 ： 149.0 G
ORC格式，默認壓縮 ： 10.6 G 比store_sales表還小？
PARQUET格式，默認壓縮 ： 12.5 G 比store_sales表還小？
查詢測試結果：

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

原始Text格式，未壓縮 ： 245.3 G
ORC格式，默認壓縮 ： 10.9 G 比store_sales表還小？
PARQUET格式，默認壓縮 ： 29.8 G
查詢測試結果：

場景四
該場景中只涉及一個多層嵌套的寬表，沒有任何分區字段，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要小？
查詢測試結果：

6、總結
      本文使用HIVE對三種不一樣的文件存儲格式——Text、ORC和Parquet進行了對比測試，從測試結果來看，星狀模型對於數據分析場景並非很合適，多個表的join會大大拖慢查詢速度，而且不能很好的利用列式存儲帶來的性能提高，在使用寬表的狀況下，ORC文件格式在存儲空間上要遠優於Text格式，較之於PARQUET格式有一倍的存儲空間提高，在導數據（insert into table select 這樣的方式）方面ORC格式也要優於PARQUET，在最終的查詢性能上能夠看到，不管是無嵌套的扁平式寬表，或是一層嵌套表，仍是多層嵌套的寬表，二者的查詢性能相差很少，較之於Text格式有2到3倍左右的提高，在query_join2這個查詢中，使用寬表和另一個維度表執行join查詢的時候，ORC要優於PARQUET格式。

      另外，經過對比場景二和場景三的測試結果，能夠發現扁平式的表結構要比嵌套式結構的查詢性能有所提高，因此若是選擇使用大寬表，則設計寬表的時候儘量的將表設計的扁平化，減小嵌套數據。

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