Parquet性能測試之項目實踐中應用測試
一、SparkSql中兩種格式存儲的讀寫性能（以資源產品拓撲信息寬表為例）
1、假設：由於對於parquet存儲格式來說，針對列式的查詢讀取操作以及列式的計算性能更高於普通的存儲格式，所以在讀取相同的sql過程中，表的存儲格式為parquet，讀取的性能更高，所花費的時間更少。
2、測試步驟：
①將sparksql用的相關hive表，建立相同的parquet存儲格式的表；
②分別執行生成的jar包，進行數據的整合；
3、測試結果：（可能是由於資源占用問題第三次測試中parquet存儲格式花費時間較長，但是仍然低於hdfs格式存儲的讀取效率）
次數|時間 Parquet格式表 普通格式表
第1次 9分0秒 14分51秒
第2次 9分38秒 14分18秒
第3次 13分9秒 16分14秒
平均時間 10分36秒 15分08秒
4、測試分析
此次測試，使用相同的sparksql進行讀取轉化，只是所使用的hive 的存儲方式不同，由以上的執行時間來看，很明顯在讀寫生成資源產品拓撲信息寬表過程中，建表為parquet存儲所花費的時間更少，假設成立。
二、存儲的格式不同，列式計算中parquet格式存儲比普通文件存儲進行列式運算的效率更高
2、測試步驟：
①對sparksql中需要處理的表存儲為parquet格式和普通格式；
②執行列式運算的sparksql；
③對比執行時間，得出結論。
3、測試結果：
生成文件來源|執行所花費的時間 Parquet格式存儲運算耗時 普通格式存儲耗時 Sql難度分析
七天質量跟蹤（Build_mov_fix_7day_fix）用表ksdd_oss.build_mov_fix 2分18秒 7分50秒 Sparksql要對500萬左右的數據進行多次分組求最大值
客戶健康檔案--開通裝移修監控期數據（Build_mov_fix_7day_health）用表ksdd_oss.cust_health_detail和ksdd_oss.cust_health_detail_num 12分49秒 4分2秒 Sparksql對健康檔案詳單和統計表7天的數據進行計算關聯，兩張表的數據在40億以上
4、測試分析
此次測試，通過復雜的大數據量的數據進行運算，寫出結果。通過執行的時間，我們可以從裏面看出執行效率如何。從前兩次測試結果來看parquet格式存儲的優勢明顯高於普通的文件存儲。而從第三個來看關聯查詢運算，數據量也比較大，測試結果並非我們所假設的那樣。什麽原因造成的上述結果，經過查詢資料，我們得知在列數查詢較少的情況下，我們使用parquet格式存儲進行查詢的效率很高，包括直接impala查詢大表所消耗的時間也是相比來說非常短。造成上述原因的主要原因應該是所需要進行聚合函數的字段過多，導致parquet格式存儲的查詢效率極具降低。因此，我們在進行sparksql執行時要考慮到所使用的表字段的個數，若是字段過多，建議使用一般的存儲格式，不宜使用parquet來存儲。通過分析，我們對假設要分情況來討論，通過具體的字段數來決定使用哪種方式來進行數據格式的存儲。
三、存儲格式不同，Parquet格式存儲所占用的內存更小
1、假設：由於parquet存儲格式每一列的成員都是同構的，針對不同的數據類型使用更高效的數據壓縮算法，進一步減少I/O；並且由於每一列的成員的同構性，可以使用更加適合CPU pipeline的編碼方式，減少CPU的緩存失效，所以我們假設存儲格式不同，Parquet格式存儲所占用的內存更小。
2、測試步驟：
①生成相同數據量；
②將生成的數據按照普通文件格式存儲和parquet格式存儲；
③查看生成文件所占用的空間大小，進而得出結論。
3、測試結果：
生成文件的來源|所占用內存大小 Parquet存儲文件大小 普通文件大小 相對節約比例 節約空間大小
資源產品拓撲信息寬表中間文件（zyproinfotwo） 3.6G 12.6G 71.4% 9G
資源寬表回寫oracle的數據(zydata_to_oracle) 726M 2.3G（2355.2M） 69.2% 1629.2M
拓撲導入bras數據（topo_add_stb） 294.3M 1.2G（1228.8M） 76% 934.5M
4、測試分析
此次測試，我們可以通過測試的數據看出使用Parquet格式來存儲數據，占用的空間更小，節約的空間在70%以上，在我們的應用之中針對大數據量的基礎表的存儲，我們可以生成parquet格式進行存儲，在代碼之中我們可以通過讀取所需的文件解析註冊成臨時表再進行操作提取所需要的字段。由此看見假設成立，存儲格式不同，Parquet格式存儲所占用的內存更小。
Parquet性能測試之項目實踐中應用測試