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也有了很大的性能提升，各个产品更多新的特性还是值得关注的。