POC测试总结

一、       测试内容

测试内容

测试目的

其他

功能测试

验证产品的自动部署安装、集成统一管理、运维监控功能是否完善、对SQL的支持能力（SQL-标准、事务支持能力、索引、存储过程、UDF），混合负载管理能力

存储特性及多重分区能力

组件测试

验证产品的数据压缩存储特性、多种计算接口支持、对异构数据库支持、数据挖掘能力

压缩对性能的影响

性能测试

测试产品的单查询性能和并发查询能力、验证产品的索引特性及大批量数据更新能力、删除能力、数据导出能力

索引特性

大批量数据更新删除能力

可靠性能

验证集群不同组件的高可用、备份、恢复能力

安全测试

验证产品的安全权限管理

扩展性测试

产品节点置换、扩展能力及对性能的影响


本次选取了有代表性的几个产品进行比对，记录测试时间和测试结果，并对结果和出现的问题进行一定的分析。因篇幅限制，本文只介绍性能有关的测试，其他内容下次单独介绍。另外个别产品比如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.      性能测试案例

案例编号

类别

查询范围

特征

返回数量级

备注

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（后续才提供）

 

     2.      组件架构

     1、Impala

Hadoop之POC测试总结_第1张图片

     a）  采用联邦架构（无Master节点）

b） 采用独立的资源管理器

c）  与Hive共享元数据

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

e）  代码开源

 

2、Hawq

Hadoop之POC测试总结_第2张图片

a）  采用MPP架构（Master/Slave）

b） 从PG 8.1版本移植

c）  对SQL标准支持能力强

d） 采用独立的资源调度器

e）  弹性执行引擎

f）   支持访问任何HDFS格式及其他系统的数据，可开发新插件访问新的数据源

g）  与开源Hadoop无缝集成

h） 代码开源

 

3、Tez

Hadoop之POC测试总结_第3张图片

a）  采用Hive on Tez架构

b） 充分利用YARN框架，简化数据部署

c）  改进DAG减少IO的读写

d） 代码开源

e）  支持更新、删除

 

4、LLAP

Hadoop之POC测试总结_第4张图片

a）  基于Hive on Tez架构的进一步增强

b） 计算信息常驻内存并共享

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

d） 支持ACID MERGE

e）  可视化的开发调测工具

 

5、Inceptor

Hadoop之POC测试总结_第5张图片

a）  基于Hive on Spark引擎改进

b） 对SQL标准支持能力强

c）  支持内存列式存储

d） 并发调度器SLA Scheduler，并行能力强

e）  SQL语法完全支持DB2和Oracke的原语解析，应用迁移方便

f）   支持更新、删除功能

g）  产品闭源

 

6、Elk

Hadoop之POC测试总结_第6张图片


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、  加载性能对比

Hadoop之POC测试总结_第7张图片

结论：

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、翻数性能对比

Hadoop之POC测试总结_第8张图片

结论：

a）  Bigsql速度最快（4885W条/秒），Hawq处于同一量级（每秒2887W条）

b） 翻数能力与磁盘写能力有一定关系，对内存使用相差不大，各个产品性能无明显差别

分析：

a）  IBM-Bigsql每天一个分区表（外部表）并行翻数，最后建立一个总的外部表指向之前建立的文件夹，比较有特点

b） Hawq每个节点采用12个数据库实例（默认6个），提高并行能力

c）  Elk每个节点采用9个数据库实例（默认4个）

d） Tez人为原因采用串行翻数，边扫描边计算，CPU使用率不高，整体效率较低

 

4.      单查询结果分析

1、单查询1性能对比

Hadoop之POC测试总结_第9张图片

结论：

a）  Impala速度最快，Elk和Inceptor处于同一数量级

b） 单表查询，建表时分区字段的选择对性能影响较大

分析：

a）  Impala按买卖类别和成交日期进行分区，与查询条件吻合，其他产品均只按成交日期分区

b） Elk建表时指定证券代号和成交股数做预排序，插入数据时预先排序，降低计算复杂度

 

2、单查询2性能对比

Hadoop之POC测试总结_第10张图片

结论：

a）  Elk速度最快，Inceptor处于同一数量级

b） 单表查询，提高数据块的扫描效率会对性能有一定的提升

分析：

a）  Elk插入数据时有做预排序，缩短查找范围，减少扫描磁盘的开销

b） Inceptor打开了最大最小值过滤器，减少扫描磁盘的开销

c）  Tez人为原因没有按证券代号进行分布，没有开启预排序功能，统计信息时没有全字段收集

 

3、单查询3性能对比

Hadoop之POC测试总结_第11张图片

结论：

a）  BigSql执行最快，Elk和Hawq处于同一数量级

b） 计算时均不直接排序（或产品具有预先排序），会对性能有一定的提升

分析：

a）  BigSql利用pGRPBY特性，不做Sort运算（前提是组合条件不能过多，否则占内存），做小范围的GROUP BY

b） Elk插入数据时有做预排序，资源重分布时，可以减少（排序需要的）网络开销

c）  Hawq当维表比数据表大时，选择数据表做重分布，避免过滤后的数据全广播

 

4、单查询4性能分析

Hadoop之POC测试总结_第12张图片

结论：

a）  Hawq执行最快，Impala、Inceptor、Elk处于同一数量级

分析：

a）  维表比汇总后的数据表还大，各个产品对资源的调度策略稍有差异

b） Hawq选择执行路由，汇总后的数据做重分布，认为全广播开销太大

c）  Impala调度器选择维表（证券信息库和营业部资料表）做全广播

d） Elk调度器选择对汇总后的数据做全广播

 

5、单查询5性能分析

Hadoop之POC测试总结_第13张图片

结论：

a）  Inceptor执行最快，Elk处于同一数量级

b） 各产品自身特性对性能有一定的提升

分析：

a）  Inceptor具有等价范围扩展功能，会根据成交日期减少二级股份持有及变更表的扫描范围

b） Elk证券代号和成交股数预排序字段的利用，资源重分布时，可以减少（二次排序的）网络传输开销

c）  Tez不支持JOIN…BETWEEN，改写Sql后造成了两张表做笛卡尔积操作，后做filter时相当耗时

 

6、业务查询1性能分析

Hadoop之POC测试总结_第14张图片

结论：

a）  Hawq执行最快，Impala和Elk处于同一数量级

b） Hawq对复杂语句的解析比较智能

分析：

a）  Hawq适合有with语句的场景，按成交序号做分布且默认打开multiphase_agg参数

b） Elk查询字段和建表时的预处理字段不一致，做聚合操作时排序效果不明显

c）  Impala的分区键（买表类别）没有利用上；并且本该最后扫描的成交库表却在一开始就进行了扫描，提前占用了1.09G的内存，在对执行计划树的优化上一般

 

7、业务查询2性能优化

Hadoop之POC测试总结_第15张图片

结论：

a）  Hawq执行最快，Elk处于同一数量级

b） Hawq对复杂语句的解析比较智能

分析：

a）  Hawq适合有with语句的场景，按成交序号做分布且默认打开multiphase_agg参数

b） Elk不适合做不带limit限制的排序操作，并且条件字段和建表时的预排序字段不完全一致

 

8、业务查询3性能优化

Hadoop之POC测试总结_第16张图片

结论：

a）  Hawq执行最快

b） 如果业务数据分布不均匀，可以考虑按随机方式进行分布数据

分析：

a）  代号’000001’的股票，数据量很大（造数的关系是其他股票的20倍），查询全年的数据，容易发生数据倾斜

b） Hawq表现特征：一个是适合with语句的场景，一个是设置成交序号作为分布键，数据分布比较均匀，计算时基本不会发生倾斜

 

9、业务查询4性能分析

Hadoop之POC测试总结_第17张图片

结论：

a）  Elk执行最快，Inceptor处于同一数量级

b） 数据分布键和查询关联条件一致时，会有一定的性能的提升

分析：

a）  Elk逐笔行情表按证券代号和交易主机时间做数据分布，数据关联时数据本地化程度较高，较少了重部分的数据量，降低网络开销，Hawq和Inceptor均是按随机分布

b） Inceptor具有等价范围扩展功能，扫描数据时会根据记录起始/结束日期缩短查找范围，减少读入内存的数据量

 

10、业务查询5性能分析

Hadoop之POC测试总结_第18张图片

结论：

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、  分析说明

说明1：

a）  Inceptor混合并发用时最短，比第二名块1.18个小时，资源占用方面CPU占用最大

b） Hawq和Elk处于同一级别，整体用时不大

c）  Impala中100个文件有21个因为内存溢出没有正确导出，用例完成率79%，且内存占用率仍然很高

 

说明2：

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.      产品调优


2.      注意事项

 

3.      最后说明

1、  因为产品众多（前后8个Sql引擎），对各个产品的理解有限，且受限于篇幅，本文仅作为测试工作一个阶段性总结。

2、  各个产品在最近今年变化都比较大，比如2018年8月份HAWQ 成 Apache 顶级项目，11月份TDH 升级到6.0后，Inceptor也有了很大的性能提升，各个产品更多新的特性还是值得关注的