hadoop集群：使用測試hadoop集群，節點：
hadoop230
hadoop231
hadoop232
hadoop233
hive使用官方的hive 1.2.1版本，使用hiveserver2的方式啟動，使用本機的mysql儲存元資料。
測試資料為tpc-ds基準測試的資料，官方文件：這個資料集一共24個表：7個事實表，17個維度表，每乙個事實表和大部分的維度表組成雪花模型，scale_factor設定為100，也就是生成100gb的資料。
git clone
這個專案是用於生成tpc-ds資料集並且將其匯入到hive，在使用之前需要保證已經將hive、hadoop等命令加入到path中。
匯入orc資料：./tpcds-setup.sh 100 預設的檔案格式就是orc，所以不需要指定儲存格式。
匯入parquet資料：format=parquet ./tpcds-setup.sh 100 指定檔案格式為parquet
引數100表示生成100gb的資料，改程式首先會生成text格式的資料到臨時目錄，然後再將這些資料轉換成orc或者parquet格式。
該專案在sample-queries-tpcds/testbench.settings檔案中給出了一些hive的配置，在啟動hive之前設定這些引數，在sample-queries-tpcds目錄下給出了65個測試sql，這部分是可以在hive上跑的tpc-ds查詢，通過參考之前的測試，選擇了其中的50個查詢用於本次測試。
本次測試主要對比orc檔案格式和parquet檔案格式之間的查詢效能，並和未壓縮的text格式進行對比。hive通過hiveserver2後台執行，客戶端通過jdbc的方式分別執行每一條查詢，對比查詢使用的wall time（每次查詢結束的時間戳減去查詢之前的時間戳）。
測試使用的資料是tpc-ds資料集中以store_sales為事實表的乙個雪花狀模型，不同的場景基於這個資料集構造不同的表結構。
不需要修改任何資料，直接在tpc-ds資料集上執行查詢。text表不是分割槽表（100個reducer生成），另外兩種儲存格式的事實表是根據data_id進行分割槽的分割槽表，執行了兩次測試：1、執行全部的50個查詢，2、選取符合測試資料模型的查詢，分別為query27,query7,query28,query67,query82,query42,query43,query46,query73,query96，執行n此查詢，計算平均值。
選取資料模型中的store_sales, household_demographics, customer_address, date_dim, store表生成乙個扁平式寬表(store_sales_wide_table)，基於這個表執行查詢，由於場景一種選擇的query大多數不能完全match到這個寬表，所以使用了一些新的查詢sql，表的模型、load資料的sql和查詢可以參考附件。
在場景二的基礎上，將維度表（除了store_sales表）轉換成乙個struct或者map物件，源store_sales表中的字段保持不變。生成有一層巢狀的新錶（store_sales_wide_table_one_nested），使用的查詢邏輯和場景二中相同，修改sql以滿足新的表結構。表的模型、load資料的sql和查詢可以參考附件。
在場景三的基礎上，將部分維度表的struct內的字段再轉換成struct或者map物件，只存在struct中巢狀map的情況，最深的巢狀為三層。生成乙個多層巢狀的新錶（store_sales_wide_table_more_nested），使用的查詢邏輯和場景三中相同，修改sql以滿足新的表結構。表的模型、load資料的sql和查詢可以參考附件。
每一種場景下對比測試主要關注兩個方面：1、測試資料的大小，以對比不同的檔案格式在儲存上的優劣，2、相同場景中的不同檔案格式查詢時間對比。另外，在場景
二、場景
三、場景四中向新錶中導資料的速度為orc > parquet > text
該場景中設計到tpc-ds中全部的表，以store_sales表為例，該錶的記錄數：287,997,024，檔案大小為：
測試1(執行全部50個查詢)結果：
說明：原始text格式相差並不大，甚至有的更優？！可能原因是在多個表join的情況下，每乙個查詢需要多達10+個mr任務處理，而這些查詢檔案儲存格式之間的查詢主要存在於前幾個讀取原始表記錄的job，而後面的任務相差並不大，進而導致查詢時間的差異減小，從後面單個寬表的測試結果可以看到，text和其它兩種列式儲存格式的效能上的差異還是挺大的。
測試2(執行其中10條查詢)結果：
說明：和測試1類似，相差不大，對於query82，orc格式差很多？！
該場景中只涉及到了乙個寬表，並且沒有任何分割槽字段，store_sales_wide_table表記錄數：263,704,266，表大小為：
查詢測試結果：
該場景中只涉及乙個巢狀的寬表，沒有任何分割槽字段，store_sales_wide_table_one_nested表記錄數：263,704,266，表大小為：
查詢測試結果：
該場景中只涉及乙個多層巢狀的寬表，沒有任何分割槽字段，store_sales_wide_table_more_nested表記錄數：263,704,266，表大小為：
查詢測試結果：
本文使用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要高的可能性。
parquet效能測試
之前一直考慮更換impala的檔案儲存格式為parquet，但是沒有立即使用，最近又做了一些測試，看看parquet是否真的有用。在測試的時候順便測了一下compute語句的效果，一起作為參考。下面抽出乙個小業務的部分測試結果來展示。庫名和表名當然不是真的。表名行數 字段數物理儲存大小 ain342...
開源列式儲存引擎Parquet和ORC
自董的部落格 相比傳統的行式儲存引擎，列式儲存引擎具有更高的壓縮比，更少的io操作而備受青睞 注 列式儲存不是萬能高效的，很多場景下行式儲存仍更加高效 尤其是在資料列 column 數很多，但每次操作僅針對若干列的情景，列式儲存引擎的價效比更高。在網際網路大資料應用場景下，大部分情況下，資料量很大且...
Impala實踐之十一 parquet效能測試
之前一直考慮更換impala的檔案儲存格式為parquet，但是沒有立即使用，最近又做了一些測試，看看parquet是否真的有用。在測試的時候順便測了一下compute語句的效果，一起作為參考。下面抽出乙個小業務的部分測試結果來展示。庫名和表名當然不是真的。表名行數 字段數物理儲存大小 ain342...