Hadoop之POC測試總結

POC測試總結

一、       測試內容

測試內容	測試目的	其他
功能測試	驗證產品的自動部署安裝、集成統一管理、運維監控功能是否完善、對SQL的支持能力（SQL-標準、事務支持能力、索引、存儲過程、UDF），混合負載管理能力	存儲特性及多重分區能力
組件測試	驗證產品的數據壓縮存儲特性、多種計算接口支持、對異構數據庫支持、數據挖掘能力	壓縮對性能的影響
性能測試	測試產品的單查詢性能和併發查詢能力、驗證產品的索引特性及大批量數據更新能力、刪除能力、數據導出能力	索引特性 大批量數據更新刪除能力
可靠性能	驗證集羣不同組件的高可用、備份、恢復能力
安全測試	驗證產品的安全權限管理
擴展性測試	產品節點置換、擴展能力及對性能的影響

 

本次選取了有代表性的幾個產品進行比對，記錄測試時間和測試結果，並對結果和出現的問題進行一定的分析。因篇幅限制，本文只介紹SQL引擎性能有關的測試，其他內容下次介紹。另外個別產品比如IBM的BigSql測試結果沒有一一列出，只在文中有少量提及。

二、       測試流程

1.      準備工作

環境分配、搭建、檢查

測試案例設計、評審

自動化腳本編寫調試

評審腳本，確定開始時間

修改密碼、啓動機器

2.      執行過程

清庫、建庫、加載種子數據、翻數、運行核數腳本

單查詢

併發查詢

逐條導入

導出測試

組件測試（壓縮、多租戶、接口支持），擴展性測試、可靠性測試、安全測試、TPC-DS測試

三、       測試環境

1.      測試環境及工具

機器節點	操作系統	節點數	磁盤	內存	CPU	RAID策略
DB節點	Red   Hat 6.6	18	SATA盤2T/塊*10塊/節點	256G/節點	24核 2.6GHZ	系統盤：RAID 1 600G*2塊 數據盤：JBOD
ETL節點		3	SAS盤 1.2T/塊*16塊/節點

採用nmon監控工具

 

2.      種子數據及翻數說明

種子數據10張表，一天527G數據，造數要求：

1）  獨立證券數：1萬隻（現有基礎放大4~5倍）

2）  會員數：1000個

3）  交易單元數：10萬個

4）  營業部個數：10萬個

5）  投資者賬戶數：10億個

6）  委託成交獨立賬戶數：委託獨立賬戶1億，成交獨立賬戶7千萬

7）  持股記錄獨立賬戶數：2億個

種子數據表和翻數說明

序號	表名	中文名	數據量	種子文件大小	翻數說明
1	DWCJK	成交庫	11億/天	128G	翻310天
2	DWWTK	委託庫	13億/天	145G	翻310天
3	TSQUOTAT	逐筆行情	2億/天	57G	翻310天
4	WWTNISHC	二級股份持有及變更	4億/天	24G	翻310天
5	DWZQXX	證券信息庫	1萬	3M
6	SWTNIALK	投資者當前概要表	10億	145G
7	WWTNBRCH	營業部資料表	10萬	19M
8	WWTNMMBR	會員資料表	1000	0.5M
9	WWTNSEAT	席位資料表	10萬	15M
10	SWTNBCSA	營業部客戶託管單元當前信息表	7億	29G

翻數規則，略；數據日期從2015-05-01開始

查詢參數：Python腳本隨機生成

1、  日期：查詢時間跨度+隨機日期

2、  證券：數量最多的100只證券中隨機選

3、  查詢時間：

**）單查詢：開始時間：9150000，結束時間：15300000

**）併發查詢：開始時間：9300000+隨機數，結束時間：1500000-隨機數

四、       測試案例

1.      性能測試案例

案例編號	類別	查詢範圍	特徵	返回數量級	備註
tc000	加載及翻數	-	-	-
tc001	簡單查詢	1天	單表（成交庫）查詢、排序	萬級
tc002	簡單查詢	1個月	多個單表（成交、委託、證券信息）分別查詢並彙總，取交集，不排序	個位
tc003	中等查詢	1季度	兩張表（大表：成交庫，小表：當前投資者概要）關聯後，分組統計並排序	十萬級
tc004	中等查詢	1天	大表分組統計，取並集，再和其他小表做關聯，不排序	萬級
tc005	複雜查詢	1個月	多表關聯（含兩個大表：成交庫，二級股份持有及變更），分組統計，關聯數量級大	萬級
tc006	業務查詢1	1個月	考察with語句的解析優化能力	百萬級	寫表
tc007	業務查詢2	半年	考察with語句的解析優化能力，支持dense_rank分析函數	個位
tc008	業務查詢3	1年	考察with語句的解析優化能力，支持case when	萬級
tc009	業務查詢4	1個月	考察with語句的解析優化能力，支持分析函數row_number和條件分支語句	千級
tc010	業務查詢5	15天	考察with語句的解析優化能力，對子查詢結果取並集	萬級
tc011	簡單併發	1個月	執行tc002，併發數20個、50個、100個，參數隨機生成，考察併發能力	個位
tc012	中等併發	1天	執行tc004，併發數20個、50個、100個，參數隨機生成，考察併發能力	萬級
tc013	複雜併發	1個月	執行tc005，併發數20個、50個、100個，參數隨機生成，考察併發能力	萬級
tc014	混合併發	1個月/1天/1個月	50個簡單tc002、30箇中等tc004、20個複雜tc005	個位 萬級 萬級

 

2.      功能測試案例

暫略

五、       產品說明

1.      總體介紹

	Cloudera	Hortonworks		星環	華爲
測試平臺	CDH 5.8	HDP 2.5.3		Transwarp 4.6.4	FI R002C6
Hadoop版本	Hadoop 2.6	Hadoop 2.5		Hadoop 2.5	Hadoop 2.7
測試引擎	Impala 2.6	Hawq 2.0.1	Tez 0.7(Hive 1.2)	Inceptor 4.6.4	Elk 6.0.RC1
SQL支持	SQL-92	SQL-92,99,2003	採用HQL接口，最新支持到2011	SQL-92,SQL-99,SQL-2003	支持SQL-2003標準，其他部分支持
圖形化SQL客戶端	無	無	無	Waterdrop	Data studio（後續才提供）

組件介紹：

Impala：爲提高查詢交互性，依據Google的Dremel爲原型開發，使用類似傳統MPP數據庫數交互式查詢

Hawq：基於Posgres改進，Hadoop原生大規模SQL分析引擎，針對的是分析性應用

Tez：Hortonworks貢獻給Apache用於取代MR，Hive引擎的優化，適合批量數據處理

Inceptor：基於Hadoop和Spark sql技術，用於數據倉庫和交互式查詢，加上自主研發的創新組件，解決數據處理和分析難題

Elk：基於Postgres改進的分佈式交互查詢數據倉庫引擎

LLAP：對Hive on Tez引擎的優化，適合批處理操作

BigSql：IBM公司基於DB2優化器改進的大數據SQL引擎

Spark SQL：適合在數據分析/數據挖掘過程中使用，簡化Spark的編碼

     2.      組件架構

     1、Impala

     a）  採用聯邦架構（無Master節點）

b） 採用獨立的資源管理器

c）  與Hive共享元數據

d） 支持常用的HDFS存儲格式

e）  代碼開源

 

2、Hawq

a）  採用MPP架構（Master/Slave）

b） 從PG 8.1版本移植

c）  對SQL標準支持能力強

d） 採用獨立的資源調度器

e）  彈性執行引擎

f）   支持訪問任何HDFS格式及其他系統的數據，可開發新插件訪問新的數據源

g）  與開源Hadoop無縫集成

h） 代碼開源

 

3、Tez

a）  採用Hive on Tez架構

b） 充分利用YARN框架，簡化數據部署

c）  改進DAG減少IO的讀寫

d） 代碼開源

e）  支持更新、刪除

 

4、LLAP

a）  基於Hive on Tez架構的進一步增強

b） 計算信息常駐內存並共享

c）  支持SQL2011、TDC-DS最新用例

d） 支持ACID MERGE

e）  可視化的開發調測工具

 

5、Inceptor

a）  基於Hive on Spark引擎改進

b） 對SQL標準支持能力強

c）  支持內存列式存儲

d） 併發調度器SLA Scheduler，並行能力強

e）  SQL語法完全支持DB2和Oracke的原語解析，應用遷移方便

f）   支持更新、刪除功能

g）  產品閉源

 

6、Elk

a）  採用MPP架構（Master/Slave）

b） 從PG9.2版本移植

c）  採用獨立的資源調度器

d） 支持多Coordinator

e）  數據預排序功能

f）   支持更新、刪除

g）  產品閉源

 

六、       測試結果

1.      測試時間及執行情況

測試開始時間：2016年11月

測試結束時間：2017年03月

產品名稱	第1輪完成率	第1輪出現的問題	最終完成率	問題說明
Impala	79%	內存溢出	86%	1、  掛盤失敗導致tc013案例失敗 2、  內存溢出導致tc014案例失敗
Hawq	79%	1、  內存溢出 2、  系統連接衝突 3、  磁盤寫錯誤	93%	tc014案例的100個文件有1個未生成
Tez	50%	節點負載過高導致宕機	64%	1、  tc006案例語法不支持，修改後不一致，放棄 2、  負載太高放棄tc003,tc013,tc014
LLAP	86%	tc012中100個併發文件到最後1個hang住了	93%	1、  加載、併發查詢爲加測 2、  tc013未執行成功，最終放棄 3、  參數未使用正式執行參數
Inceptor	79%	放棄tc008,tc013,tc014	100%
Elk	21%	1、  資源利用率過低，修改了參數 2、  內存溢出，tc012,tc013,tc014報錯 3、  負載過高LDAP服務掛掉，從tc003到tc014全部報錯	100%

 

2.      性能測試結果

明細耗時（單位：秒），測試內容和測試案例完全對應

測試內容	Hawq	Impala	Tez	Inceptor	Elk	返回行數
加載種子數據500G	516	611	1195	1620	519	47.9億
種子數據翻310倍	32273	44307	161555	55510	40153
簡單查詢1	31	7	33	13	9	45880
簡單查詢2	34	109	488	3	2	3
中等查詢1	855	1245	3772	1494	660	389536
中等查詢2	57	73	174	81	81	20000
複雜查詢	543	2456	3604	41	85	10000
業務查詢1	665	956	-	1643	913	4946805
業務查詢2	16	626	8296	179	64	1
業務查詢3	1443	36136	-	11918	10435	24166
業務查詢4	2153	17362	8659	1194	927	1137
業務查詢5	111	917	4178	413	1391	72256
簡單查詢2併發20	31	1104	7491	23	345
簡單查詢2併發50	63	2405	19060	52	766
簡單查詢2併發100	134	5059	39460	194	1112
中等查詢2併發20	2693	1360	6962	4684	6577
中等查詢2併發50	6458	2266	13783	11402	13733
中等查詢2併發100	12838	3978	26909	22448	34459
複雜查詢併發20	6712	7312	-	1089	3461
複雜查詢併發50	16062	18745	-	2518	6179
複雜查詢併發100	31318	27816	-	2786	6751
混合查詢併發100	13267	13904	-	8626	12882

 

各產品建表時分區、分佈情況（表一：）

中文表名	英文表名	分類	產品名
			Hawq	Tez	LLAP
成交庫	dwcjk	分區	成交日期	成交日期，買賣類別	成交日期，買賣類別
		分佈	成交序號	Random	Random
委託庫	dwwtk	分區	委託日期	買賣類別，委託日期	買賣類別，委託日期
		分佈	成交序號	Random	Random
逐筆行情	tsquotat	分區	交易日期	交易日期	交易日期
		分佈	Random	Random	Random
二級股份持有及變更	wwtnishc	分區	記錄起始日期	N/A	記錄起始日期
		分佈	投資者代碼	Random	Random
投資者當前概要表	swtnialk	分區	N/A	N/A
		分佈	投資者代碼	Random	Random
營業部客戶託管單元資料表	swtnbcsa	分區	N/A	N/A
		分佈	Random	Random	Random
其他	others	分區	N/A	N/A
		分佈	Random	Random	Random

表二：

中文表名	英文表名	分類	產品名
			Impala	Inceptor	Elk
成交庫	dwcjk	分區	成交日期，買賣類別	成交日期	成交日期
		分佈	Random	Random	成交序號
委託庫	dwwtk	分區	買賣類別，委託日期	委託日期	委託日期
		分佈	Random	Random	合同序號
逐筆行情	tsquotat	分區	交易日期	交易日期	交易日期
		分佈	Random	Random	證券代號，交易時間
二級股份持有及變更	wwtnishc	分區	記錄起始日期 記錄結束日期	N/A	記錄起始日期
		分佈	Random	Random	投資者代碼
投資者當前概要表	swtnialk	分區	投資者類別	Random	Random
		分佈	Random	投資者代碼	投資者代碼
營業部客戶託管單元資料表	swtnbcsa	分區	N/A	N/A	N/A
		分佈	Random	Random	投資者代碼
其他	others	分區	N/A	N/A	N/A
		分佈	Random	Random	所有節點全量分佈

 

3.      加載與翻數分析

1、  加載性能對比

結論：

a）Hawq加載速度最快，每小時3.6T（1G/秒），處於同一數量級的有Elk和Impala

b）採用專用工具可減少代碼開發複雜度，降低出錯率

分析：

a）  LLAP採用Isilon的存儲，專用加載工具，數據直接存放HDFS

b） Hawq採用gpfdist工具，Elk採用類似的加載工具gds進行加載

c）  Impala每小時3.04T，採用HDFS上傳文件，Tez採用相同的方式加載

d） Inceptor每小時1.15T，人爲原因，只使用了1臺ETL節點串行加載，沒有打滿3臺ETL機器

 

2、翻數性能對比

結論：

a）  Bigsql速度最快（4885W條/秒），Hawq處於同一量級（每秒2887W條）

b） 翻數能力與磁盤寫能力有一定關係，對內存使用相差不大，各個產品性能無明顯差別

分析：

a）  IBM-Bigsql每天一個分區表（外部表）並行翻數，最後建立一個總的外部表指向之前建立的文件夾，比較有特點

b） Hawq每個節點採用12個數據庫實例（默認6個），提高並行能力

c）  Elk每個節點採用9個數據庫實例（默認4個）

d） Tez人爲原因採用串行翻數，邊掃描邊計算，CPU使用率不高，整體效率較低

 

4.      單查詢結果分析

1、單查詢1性能對比

結論：

a）  Impala速度最快，Elk和Inceptor處於同一數量級

b） 單表查詢，建表時分區字段的選擇對性能影響較大

分析：

a）  Impala按買賣類別和成交日期進行分區，與查詢條件吻合，其他產品均只按成交日期分區

b） Elk建表時指定證券代號和成交股數做預排序，插入數據時預先排序，降低計算複雜度

 

2、單查詢2性能對比

結論：

a）  Elk速度最快，Inceptor處於同一數量級

b） 單表查詢，提高數據塊的掃描效率會對性能有一定的提升

分析：

a）  Elk插入數據時有做預排序，縮短查找範圍，減少掃描磁盤的開銷

b） Inceptor打開了最大最小值過濾器，減少掃描磁盤的開銷

c）  Tez人爲原因沒有按證券代號進行分佈，沒有開啓預排序功能，統計信息時沒有全字段收集

 

3、單查詢3性能對比

結論：

a）  BigSql執行最快，Elk和Hawq處於同一數量級

b） 計算時均不直接排序（或產品具有預先排序），會對性能有一定的提升

分析：

a）  BigSql利用pGRPBY特性，不做Sort運算（前提是組合條件不能過多，否則佔內存），做小範圍的GROUP BY

b） Elk插入數據時有做預排序，資源重分佈時，可以減少（排序需要的）網絡開銷

c）  Hawq當維表比數據表大時，選擇數據表做重分佈，避免過濾後的數據全廣播

 

4、單查詢4性能分析

結論：

a）  Hawq執行最快，Impala、Inceptor、Elk處於同一數量級

分析：

a）  維表比彙總後的數據表還大，各個產品對資源的調度策略稍有差異

b） Hawq選擇執行路由，彙總後的數據做重分佈，認爲全廣播開銷太大

c）  Impala調度器選擇維表（證券信息庫和營業部資料表）做全廣播

d） Elk調度器選擇對彙總後的數據做全廣播

 

5、單查詢5性能分析

結論：

a）  Inceptor執行最快，Elk處於同一數量級

b） 各產品自身特性對性能有一定的提升

分析：

a）  Inceptor具有等價範圍擴展功能，會根據成交日期減少二級股份持有及變更表的掃描範圍

b） Elk證券代號和成交股數預排序字段的利用，資源重分佈時，可以減少（二次排序的）網絡傳輸開銷

c）  Tez不支持JOIN…BETWEEN，改寫Sql後造成了兩張表做笛卡爾積操作，後做filter時相當耗時

 

6、業務查詢1性能分析

結論：

a）  Hawq執行最快，Impala和Elk處於同一數量級

b） Hawq對複雜語句的解析比較智能

分析：

a）  Hawq適合有with語句的場景，按成交序號做分佈且默認打開multiphase_agg參數

b） Elk查詢字段和建表時的預處理字段不一致，做聚合操作時排序效果不明顯

c）  Impala的分區鍵（買表類別）沒有利用上；並且本該最後掃描的成交庫表卻在一開始就進行了掃描，提前佔用了1.09G的內存，在對執行計劃樹的優化上一般

 

7、業務查詢2性能優化

結論：

a）  Hawq執行最快，Elk處於同一數量級

b） Hawq對複雜語句的解析比較智能

分析：

a）  Hawq適合有with語句的場景，按成交序號做分佈且默認打開multiphase_agg參數

b） Elk不適合做不帶limit限制的排序操作，並且條件字段和建表時的預排序字段不完全一致

 

8、業務查詢3性能優化

結論：

a）  Hawq執行最快

b） 如果業務數據分佈不均勻，可以考慮按隨機方式進行分佈數據

分析：

a）  代號’000001’的股票，數據量很大（造數的關係是其他股票的20倍），查詢全年的數據，容易發生數據傾斜

b） Hawq表現特徵：一個是適合with語句的場景，一個是設置成交序號作爲分佈鍵，數據分佈比較均勻，計算時基本不會發生傾斜

 

9、業務查詢4性能分析

結論：

a）  Elk執行最快，Inceptor處於同一數量級

b） 數據分佈鍵和查詢關聯條件一致時，會有一定的性能的提升

分析：

a）  Elk逐筆行情表按證券代號和交易主機時間做數據分佈，數據關聯時數據本地化程度較高，較少了重部分的數據量，降低網絡開銷，Hawq和Inceptor均是按隨機分佈

b） Inceptor具有等價範圍擴展功能，掃描數據時會根據記錄起始/結束日期縮短查找範圍，減少讀入內存的數據量

 

10、業務查詢5性能分析

結論：

a）  Hawq執行最快，Inceptor處於同一數量級

b） Hawq對複雜語句的解析比較智能

分析：

a）  Hawq的表現特徵：一是對with語句的支持能力比較好，另一個是按成交序號做數據分佈，數據量大時不容易發生數據傾斜

b） Tez不適合做不限制數量的排序操作

 

11、單查詢總結

a）Hadoop平臺下的數據分區、分佈對查詢性能有比較大的影響，差異較大

b）Hawq不需要Session級的調優，基本靠優化器自身，對複雜語句支持能力比較好，引擎相對智能

c）Inceptor具有等價擴展功能，適合關聯條件和查詢條件一致的場景，對簡單語句支持能力比較好

d）Impala單查詢整體表現一般，對於總量在50T以內的查個查詢性能不對，超過100T時性能一般，人爲因素也對最終結果有一定的影響

e）Tez單個查詢表現不成熟，50T以內的處理分析比較適合，人爲因素也對最終結果有一定的影響

f）LLAP相對Tez有一定提升（2.1版本對1.2版本不管是語法解析還是執行計劃的優化都有提高）

g）BigSql單查詢整體表現比較穩定，個別查詢比較快

 

5.      併發查詢結果分析

1、  簡單併發性能分析

結論：

a）  Inceptor和Hawq總體執行時間最短，兩個產品處於同一數量級

b） 20個併發以內的查詢，Hawq和Elk併發性較好，20個併發以上趨於串行輪候執行

c）  20個併發以內的查詢，Inceptor和Impala有一定的併發能力，50個併發以上有性能惡化現象

d） Impala對內存的佔用比較大，Inceptor和Hawq耗時最短，且資源消耗不高，性能較好

 

2、  中等併發性能分析

結論：

a）  Impala總體用時最短，Bigsql與其處於同一數量級

b） Impala總體趨於串行輪候，其他四個產品出現資源競爭現象

c）  Impala對內存的佔用比較大，Hawq和Impala對CPU的佔用一般，磁盤讀寫速度很快

 

3、  複雜併發性能分析

結論：

a）  所有產品均趨於串行輪候執行

b） 50個併發最大的中間結果集爲60億，100併發最大的中間結果集爲8億，（50個併發中有’000001’股票），因爲50和100兩組併發耗時比較接近

c）  Impala對內存的佔用比較大，Inceptor總耗時最小，對CPU的佔用最大

 

  4、  混合併發性能分析

a）  Inceptor混合併發用時最短，比第二名塊1.18個小時，資源佔用方面CPU佔用最大

b） Hawq和Elk處於同一級別，整體用時不大

c）  Impala中100個文件有21個因爲內存溢出沒有正確導出，用例完成率79%，且內存佔用率仍然很高

4、  分析說明

     5、  併發查詢總結

a）  Inceptor在50個簡單併發查詢以內比較穩定，50個以上性能有惡化現象；支援佔用方面，簡單併發用時較短，且對CPU和內存佔用並不多，複雜併發用時短，但對CPU佔用相對較高

b） Hawq在50個複雜併發以內，相對比較穩定

c）  Impala在50個簡單併發以內，併發較穩定，50個以上性能有惡化現象；資源佔用方面對內存的影響一直比其他產品要大

d） LLAP比Tez有一定的提升，20個簡單併發以內可用

e）  Bigsql20個簡單併發以內可用，表現比較穩定，整個過程沒有出現異常

f）   Elk20個簡單併發以內可用，相對比較穩定，20個以上性能有惡化現象

g）  各產品成熟度均表現一般，結構化數據的併發查詢還需要MPP作爲補充工具

 

6.      其他性能結果

1、逐條插入

單進程逐條插入在10條/秒上下，10個併發進程逐條插入在100條/秒左右，效率低下，實際不會採用這種方式

 

2、導出性能

產品	導出單文件（58G，2.3億）		30個併發查詢並導出（6.7T，753億）
	時間（秒）	速度（條/秒）	時間（小時）	速度（條/秒
Impala	1874	12萬	5.8	360萬
Hawq	114	199萬	5.8	360萬
Tez	333	68萬	41	51萬
LLAP	421	54萬	7.9	262萬
Elk	111	205萬	4.7	445萬
Inceptor	-	-	-	-

導出單文件：

a）  Hawq採用gpfdist外部表方式（約1.79T/H），Elk採用類似的gds（約1.84T/H）處於同一數量級

b） Impala採用Impala shell命令文件追加的方式導出，約0.11T/H，Tez約0.61T/H

c）  LLAP採用Beeline查詢方式導出，基本處於同一數量級

d）Impala人爲原因程序按單進程串行處理速度較慢，如果按多進程處理速度應該有提升

30個併發查詢並導出：

a）Elk性能最好，每小時約1.43T/H，處於同一數量級的有Hawq

b）Hawq和Impala每小時約爲1.16T/H

 

3、導出數據到DB2

產品	全表數據到DB2（中間不落地）		指定查詢條件到DB2（中間不落地）		指定查詢條件到DB2（中間產生落地文件）
	時間（分鐘）	速度（條/秒）	時間（分鐘）	速度（條/秒）	時間（分鐘）	速度（條/秒）
Impala	2.6	6369	2.4	6897	-	-
Hawq	3.8	4425	3.5	4808	-	-
Tez	72	213	170	98	178	94
Elk	2.07	8065	2.09	8000	1.58	10526
Inceptor	-	-	-	-	-	-

結論：

各產品均採用JDBC連接方式，不適合大批量數據導出，只適合小批量的數據導出

分析：

a）  三種場景導出到DB2的數據量均爲100萬條

b） Hawq採用pxf外部表方式；Impala採用Sqoop1方式；Tez採用Nifi方式，瓶頸在於查詢，不適合order by全排序；Elk採用Loader工具導出

 

7.      測試出現的問題

1、  Hawq

a）gppoc沒有權限訪問數據庫對象

解決：因爲設置了gpadmin和gppoc兩個用戶組，分別使用各自的資源隊列，切換到gppoc用戶後腳本缺少環境變量，Shell腳本中增加了PGHOST=127.0.0.1即可

b）tc008報內存不夠

解決：設置的pg_default的mem值超過了當時可以訪問的內存值，重新調低該參數值

# select * from pg_settings where name like ‘%protect%;

# select * from pg_resqueue;

vsegresourcequota：資源隊列裏面虛擬Segment的限額。開始設置的是18，18G*204個Vseg=3672G，實際硬件256G*17Nodes=4352G，總的資源佔比84%，後修改爲16G，每個計算單元按16G計算，總的資源佔比爲75%，控制在80%以內。

c）  程序異常退出

解決：因爲採用tmux登錄，且程序沒有放在後臺，人爲原因（Ctrl+C）退出了程序

d） 最大連接數max_connections不足，程序執行異常

解決：重新設置系統參數

/data/hawq/master/postgresql.conf

max_connections = 1280 （默認值250）

max_prepared_transactions = 1280 （默認值1000）

master和slave通信時，內部心跳會用到connection，一般把max_connection設置的比較大，開始設置爲1400和1200導致資源搶佔，連接被拒絕，所以將參數調小了一點，控制在合理範圍

當設置max_connection時，必須同時設置max_prepared_transactions，並且max_connection必須小於等於max_prepared_transactions，建議生產環境兩個參數值保持一致即可

max_prepared_transactions是本地化參數，所有節點必須配置成相同的值

另一個參數seg_max_connection（默認值1280），建議設置爲max_connection的5~10倍，且必須要比max_prepared_transactions大

e）  中等併發查詢報空指針異常connection pointer is NULL

解決：執行前刪除數據沒有使用HDFS標準命令，而是直接rm掉數據，之後沒有啓動HDFS當時系統未報錯，後面重新啓動了HDFS，組件進行數據校驗，出錯並開啓了安全模式SAFE_MODE=TRUE（默認關閉，可讀可寫，一旦打開只可讀不可寫）。直接關閉了該參數，繼續向下執行未發現異常。

 

2、Impala

a）拒絕連接206a2 fialed:RPC client failed to connect: Couldn’t open transport for cdh2:22000(connect() failed: Connection refused)

解決：執行程序前刪除了分析表語句，沒有收集統計信息導致分配資源不夠

b）nmon日誌出錯RX packets:0 TX packets:0

解決：沒有采用延時導致kill nmon的程序提前了11秒並打印了信息，在kill之前統一延時3~5秒即可

c）nohup.out日誌中出現刪除數據庫失敗的提示

run/nohup.out:ERROR

run/nohup.out:ImpalaRuntimeException:Error making ‘dropDatabase’ RPC to Hive Metastore

解決：調起程序前，已經手動刪除過數據庫，腳本有再次刪庫提示失敗

d） 管理頁面顯示有1臺機器異常

解決：系統安裝後，系統盤沒有隱藏（其他節點均有隱藏），導致掛盤時掛錯了，把系統盤當成了disk01使用，並刪除了系統文件。

e）  tc013（50個複雜併發查詢）程序報impala_client.RPCException: ERROR: Invalid or unknown query hadle

解決：暫無解決方案，生產環境執行需修改SQL，優化執行路由

f）HDFS報健康狀態錯誤

解決：一個是內存交換異常不影響使用，一個是因爲較長時間沒有進行健康檢查提示異常

 

3、Tez

a）tc006的sql語句Tez語法不支持join on…(…or…)

解決：修改sql後試跑多次均與標杆數據對比不上，（可能與參數文件有關），後放棄

b）tc005和tc007的sql語句Tez語法不支持join的between不等值連接

解決：改寫sql

c）從tc008開始報：BolckMissingException: Could not obtain block

解決：在Ambari監控頁面，看到17個計算節點有5個down掉了，接收不到心跳信息，且出故障的節點無法ping通。通過查看nmon日誌，發現down掉的5臺機器cpu均接近100%，I/O相當高，負載很高，初步懷疑是機器負載過高導致。未解決，程序繼續向下執行。

d） 從tc008開始執行，4個小時後hdp10節點down掉了

解決：進一步檢查環境發現之前5個down掉的機器redhat_transparent_hugepage未禁用，因爲在linux下使用必須禁用透明大頁面，否則會導致Hadoo使用時報錯。比較奇怪的是正式起跑前已經對18臺機器進行了設置：

# echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag

# echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled

e）tc008跑了7個半小時，發現hdp09和hdp10節點都down掉了

Hortonworks原廠認爲是linxu系統的bug：futex_wait_call造成的，或者XFS Bug協同引起的。多個進程在等待和喚醒交替時可能出現，尤其是Haswell處理器（CPU：E5-2690 v3）配上redhat6.6，只能通過打補丁解決

紅帽專家定位分析：通過/var/crash目錄下的vmcore發現cpu load比較高（5分鐘內達到264.52的負載），從日誌看node 0 normal基本用完，內存不足。寫文件時需要在node 0分配memory，這是node0 memory已經用完，觸發了shrink_zone來在node0進行內存回收，回收是發生了異常導致oops。

解決：沒有解決

f）tc013和tc014執行時間過長，放棄

 

4、Inceptor

a）採用4.6.2版本，混合併發100個無法完成

解決：併發的參數忘記設置，導致併發執行時間過長

b）tc008測試案例無法執行

解決：數據傾斜對數據影響比較嚴重，報錯或被hang住。換用4.6.4版本後，增加了以下參數未出現上述問題

set inceptor.optimizer.on = true

set ngmr.reader.minmaxfilter=true

set mapred.reduce.tasks = 350

 

5、Elk

a）翻數時發現資源利用率比較低

解決：對資源隊列參數進行修改，max_active_statements：針對資源池允許某個控制節點（CN）上執行的併發數，默認值是10

gs_guc reload -Z coordinator -N all -I all -c “max_active_statements = 20”

設置完成後效率有比較明顯的提升

b）tc012_3到tc014_3報out of memory

分析：tc012案例work_mem=8G，到tc012_3時，單個query達到了上線，內存總和超過了系統內存總和。操作系統kill掉了腳本進程，另外安裝產品時默認設置一個節點9個數據庫實例，每個實例內存上線max_process_memeory爲30G，也會導致內存溢出。

解決：將work_mem改小，設置爲6G，max_process_memeory從30G調整爲25G

c）NameNode節點的LDAP認證服務掛掉了導致報錯

分析：測試時參照生產環境進行，保留了LDAP認證服務，但爲了追求性能沒有對LDAP做主備，最終原因應該是nodename節點負載過高導致服務終止

解決：重啓LDAP服務，重新開始執行

d）對數sql執行時報內存不足錯誤（memory is temporarily unavailable）

分析：爲加快第1條sql查詢速度，設置最大內存閾值work_mem=6G，內存分配到了算子級別count(distinct)共分配4*6G=24G的內存，其他處理還需要一定的內存。數據庫實例設置內存上線max_process_memory等於25G，當內存閾值達到25G就會報內存不足錯誤

解決：設置work_mem=4G，不單獨額外增加內存設置，重新執行（耗時較久約13.6個小時）

七、       其他

1.      產品調優

 

1、Hawq

a）加載：使用gpfdist外部表並行加載數據，HDFS數據通過外部表加載並使用textfile+128M存儲

b）翻數：數據存儲方面採用列存，parquet格式及Snappy壓縮，設置內存中數據頁和flush磁盤閾值（rowgroupsize=8388608，pagesize=1048576）

c）數據分佈：大表Hash（dwcjk（cjxh），dwwtk（jlhm），wwtnishc（inv_cd）），小表隨機分佈；成交、委託表按天分區

d）統計信息收集：全量信息收集

e）參數設置：資源池設置針對加載、查詢設置不同的資源隊列；部分場景關掉GPORCA優化器採用原始優化器（估計新優化器GPORCA還不是那麼成熟）

f）選擇Random還是Hash數據分佈？使用Hash分佈優勢是按桶分佈數據，操作時可能會減少一個motion的動作，兩階段解耦變成一階段解耦。優勢是當兩個表做JOIN時，關聯條件是分佈鍵的情況下，sql執行還是挺快的。

但是Hash分佈有兩個缺點：

**）增加和刪除節點，需要調整數據分佈，並重新分佈數據

**）節點調整，BlucketNumber是固定的，桶數不能調整，只能重新建表。

對於隨機分佈，集羣擴容後，Hawq的彈性查詢特性，使得在操作隨機分佈表時能夠自動使用更多的資源，而不需要重新分佈數據。重新分佈大表數據的資源和時間消耗都非常大。而且隨機分佈表具有更好的數據本地化，尤其是在底層HDFS因爲某個數據節點失效而執行rebalance操作重新分佈數據的時候，在一個大規模的Hadoop集羣，增刪數據節點後rebalance的情況還是比較常見的。結論：推薦使用random分佈表。

g）在選擇分佈策略時，需要考慮具體數據和查詢的情況，這將包括：

**）平均分佈數據。爲了能夠達到最好的性能，所有segment應該包括相似數量的數據，如果數據不平衡或者發生傾斜，擁有更多數據的segment工作負載會比其他segment高很多

**）本地和分佈式操作。本地操作無疑比分佈式操作更快，如果查詢條件中有連接、排序或聚合操作如果能夠在一個segment上完成，那麼本地處理查詢時最快的。當多個表共享一個公共的Hash分佈鍵時，該列的連接或排序操作是在本地進行的，對於隨機分佈策略，是否本地連接是不可控的。

**）平均處理查詢。爲了獲得更好的性能，所有segment應該處理等量的查詢工作。如果表的數據分佈策略和查詢條件謂詞匹配不好，查詢負載可能成爲瓶頸。例如，成交表dwcjk在以zqdh列作爲分佈鍵分佈數據時，如果查詢條件中一個謂詞引用了單一的分佈鍵，則查詢可能只在一個segment上進行處理。如果查詢謂詞以其他條件查詢數據，則所有的segment公共處理查詢。本次poc採用cjxh作爲分佈鍵，是因爲’000001’中國平安股票數據造的不合理（是其他股票的20倍），如果按zqdh做分佈鍵，17個計算節點中一個1個將會一直跑下去，其他16個節點在邊上看熱鬧。所以說分佈鍵的選擇是要看具體業務狀況的。

a）  Hawq運行時動態並行查詢的性能主要依賴以下因素：

**）隨機分佈表的大小

**）Hash分佈表的CREATE TABLE DDL中指定的bucketnum存儲參數，儘量不要單獨設置，如果要設置，應該設置成segment節點數量的倍數。默認的桶的個數，和集羣有關，比如有16個計算節點，就配置16*6=96個桶（節點的倍數）。

**）數據本地化情況

**）參數設置

default_hash_table_bucket_number參數（默認爲6）

hawq_rm_nvseg_perquery_limit參數（默認爲512）

i）如果網絡比較差的情況，可以調高net_disk_ratio，該參數值默認是1.01（1個Virtual Segment的Penalty=net_disk_ratio*block size），讓更多節點參與運算。網絡越差，Penalty值就更大，也就是更多要求數據在本地化計算

j）min_datasize_to_combine_segment建議設置成和HDFS塊大小一致，如果HDFS的塊是128M，就設置爲128M，如果HDFS是256M，就設置爲256M，保證每次都能夠讀取完整的一塊數據

k）Hawq做擴容和收縮也比較簡單，在擴容或收縮之後可以採用如下方式進行優化：

**）新增加節點的時候需要對HDFS做rebalance

**）集羣擴展後，最好清理一下cache，這些都比較舊了

**）擴展了集羣，default_hash_table_tucket_number也應該同步變大

**）節點擴容後，假設Virtual segment從96變成了192個，就需要對Hash表進行重部分，Redistributed一個較大的Hash表比較耗時，再次推薦Random表

 

1、  Impala

a）  加載：在ETL服務器安裝HDFS客戶端，通過該客戶端上傳數據到外部表，外部表使用textfile+128M存儲；

b） 翻數：爲避免動態分區，對成交、委託表按照MMLB字段進行預先分區，swtnialk使用inv_kind預先分區，然後針對各個分區併發翻數

c）  存儲：使用parquet格式+snappy壓縮+512M數據塊存儲

d） 數據分佈：所有數據隨機分佈；按dwcjk(mmlb)，dwwtk(mmlb)，tsquotat(TRD_DT)，wwtnishc(REC_FDT,REC_EDT)，swtnialk(INV_KIND)進行分區

e）  統計信息收集：針對每個分區進行增量統計信息收集

f）   參數設置：設置客戶端順序連接數據節點提交請求，也就是需要人工指定連接到哪個數據節點，Impala不會自動判斷哪個階段負載比較低，需要利用循環連接方式，保證負載均衡；小表關聯時強制廣播

g）  使用insert…select在表表之間拷貝數據，避免對海量數據或影響性能的關鍵表使用insert…values插入數據（這樣會產生單個小文件）

h） 使用合適的分區粒度。

**）如果包含上千個分區的Parquet表，每個分區的數據都小於1G，那麼可以考慮更多的粒度作爲分區來提交（比如分區鍵值從年月日，變成年月），保證一個表的分區數不超過30000個，同時也避免過小的分區

**）降低分區字段的長度，目前分區字段可以利用數值類型和字符串類型，推薦使用合適的整數（一般使用0~256可以保存一個分區成員的映射，否則分區會很多）而非原始的字符串，可以在外面建議字符串到整數的映射以保存原始信息，這個約束的主要原因是每個分區會佔用一個目錄，每一個目錄又會在NameNode中佔有一定的內存，所以不光是Impala，對於Hadoop來說，應儘量減少文件目錄數量

i）使用STRAIGHT_JOIN關鍵字後，必須保證表的先後順序，可以參考如下規則進行調整：

**）指定最大的表作爲第一張表，查詢初始階段，只是把數據從Impala節點的磁盤讀取放入內存，開始時對內存的消耗並不嚴重

**）指定最小的表左右下一張表，後續的第二、三張表都需要經過網絡傳輸，爲減小後續連接查詢階段結果集的開銷，最好就是先和一張最小的表關聯，裁剪掉一部分數據

**）每次均指定剩下最小的表做關聯，比如有四張表分別爲：BIG、MEDIUM、SMALL、TINY，那麼連接順序應該是：BIG、TINY、SMALL、MEDIUM

**）COMPUTE STATS會對JOIN的順序進行自動優化，只是當前優化工作不一定是最優的，可以使用STRAIGHT_JOIN保持在計算時的JOIN順序，比如select STRAIGHT_JOIN a.* from tb1 a, tb2 b where a.id=b.id

j）選擇合適的Parquet Block大小

k）SQL Hint指定JOIN方式，比如

**) [cdh2:21000] > explain select * from tb1 a join [SHUFFER] tb2 b on a.id=b.id

**) [cdh2:21000] > explain seelct * from tb1 a join [BROADCAST] tb2 b on a.id=b.id

l）   其他：使用Parquet、不使用/使用壓縮、收集統計信息COMPUTE STATS、使用EXPLAIN和Profile功能分析性能

 

2、  Tez、Inceptor、Elk

略 

2.      注意事項

 

3.      最後說明

1、  因爲產品衆多（前後8個Sql引擎），對各個產品的理解可以說是雲山霧照，走馬觀花，本文僅作爲測試工作一個階段性總結。

2、  各個產品在這幾年變化都比較大，比如2018年8月份HAWQ 成 Apache 頂級項目，11月份TDH 升級到6.0後，Inceptor也有了很大的性能提升，各個產品更多新的特性還是值得關注的。