Hadoop大数据平台-测试报告及成功案例(3)

left join sym_rb_acct_snappy acct on fmc.client_no = acct.client_no left join sym_rb_tran_hist_snappy trans on acct.internal_key = trans.internal_key;

HBase组件测试

单点查询的执行性能

选取3类不同数据规模的用户分别进行1年、2年、5年以及全量(12年)的查询测试： 用户编号 用户类型 1年查询数据规模 1000939928 1001353940 2193714 100 (个人) 200 (公司) 300 (金融机构) 根据测试结果可以发现，返回2,000+条流水的时间在1秒左右；返回2,000,000+条流水的时间在75秒以内。考虑到某银行大部分普通用户的流水规模在每年几千条，用户基本在1 ~ 2秒左右可以获得请求响应，相比当前Oracle的性能有比较明显的提升。

另外，通过单个用户不同时间周期的流水表查询可以发现：返回的流水表记录的增长会增加查询的延迟，但是并没有呈现线性增长的趋势。例如用户1000939928查询12年的流水时间是2.635秒而不是1.108 * 12 = 13.296秒。

并发查询的执行性能 (500)

通过Impala随机生成两个测试集，分别包含500个唯一的客户编号：

通过并发测试可以发现，HBase在高并发 (500个请求并发) 的情况下仍然可以保持在秒级响应客户请求：对于测试集合1，平均时间少于1.5秒；对于测试集合2，平均时间不到1.3秒。对比是否共享HBase客户端连接可以发现，充分利用共享连接 (比如预分配 50 个客户端连接缓冲于连接池中) 可以大幅提升并发效率：对于测试集合1，平均时间从3.671秒下降到1.434秒，仅为原来响应时间的39.06%；对于测试集合2，平均时间从3.989秒下降到1.289秒，为原来响应时间的32.31%。

2,381 52,748 184,795 10

为了提高HBase的查询效率，还可以进一步在查询应用程序、HBase表设计等多方面进行优化。考虑到时间的约束以及这部分的优化更加侧重于具体的应用，故没有进行进一步深入研究。另外还需要注意的是，HBase的查询需要通过Zookeeper定位数据的索引信息，在高并发情况下需要调整Zookeeper默认的客户端最大连接数：

Hive组件测试

单条SQL的执行性能

从上述测试结果我们可以发现，不同种类的存储格式对Hive运行的效率有很大的影响。使用Parquet可以有效提升Hive的执行效率：group by的执行时间从14.4m下降到7.1m；join的执行时间从13.1m下降到6.8m。在Parquet的基础上是否使用压缩算法，从测试的结果没有发现太大的差异。从集群资源的使用上可以比较清晰地发现：使用Parquet后，在CPU利用率没有明显变化的同时，大大降低了内存与磁盘的开销：对于group by SQL，内存峰值从243.5GB下降到121GB，读磁盘峰值从1.2GB下降到293.9MB；对于join SQL，内存峰值从210.9GB下降到85.3GB，读磁盘峰值从774.8MB下降到200.7MB。

在Hive任务执行过程中，会使用完YARN配置的所有资源，共114 (38 * 3)个vcore以及228GB/456GB的内存 (取决于运行Map还是Reduce)。集群的CPU利用率在55%左右。

并发SQL的执行性能 (3+3)

并发测试采用3+3的模式，即同时运行3个group by和3个join SQL，总共6个SQL并发运行。运行过程中可以通过YARN内嵌的web页面对每个任务的执行状态进行观察，可以发现6个SQL任务之间产生了严重的资源竞争。因此并发后，SQL的执行性能出现了非常明显的下降：group by SQL从单独运行的7分钟下降为36分钟左右 (执行时间为原来的5倍左右)；join SQL从单独运行的6.5分钟下降为34分钟左右。由于YARN采用公平调度策略，6个SQL享受到了基本相同的资源份额，因此每种SQL的执行时间非常相似。

Impala组件测试

11

单条SQL的执行性能

从Impala测试结果我们可以发现，不同种类的存储格式对Impala运行的效率有一定的影响，但是影响并不是太大。使用Parquet后两类SQL的运行效率都会带来一定程度的提升。而在Parquet的基础上是否使用Snappy压缩，对SQL的运行基本没有影响 (与Hive测试结果相同)。

就group by SQL而言，Impala的执行时间最快为21.9分钟慢于Hive的执行时间7分钟。这主要与Impala的实现机制有关，在Impala运行过程中，CPU的利用率普遍在5%以下。通过nmon的观察，在group by聚合计算时，每台计算节点上只会使用一个CPU vcore (Hive会使用机器上配置的最大vcore数，测试时为38)。在当前实现的版本中，Impala在分布式执行group by或者join时，会限制每台机器上只使用单线程进行计算。

对于join SQL，出现明显性能差异的因素是 “compute stats”。该命令为数据表计算统计信息，包括表中每一列有多少行、不重复的有多少行、最大值、平均值等。Impala在执行SQL前，会根据这类统计信息优化SQL的执行计划 (execution plan)。比对parquet+snappy+compute stats与parquet+snappy的执行计划可以发现，前者对交易流水表sym_rb_tran_hist进行表扫描(table scan)，对另外两张表sym_fm_client与sym_rb_acct采用BROADCAST的方式进行全表的网络传输；后者则会将sym_rb_tran_hist进行网络传输。另外，我们还可以通过执行SQL过程中资源的使用情况来进一步验证执行计划优化的效果：使用compute stats后执行计划的网络传输峰值从255MB下降到165.5MB，而内存使用更是从原先的236.8GB下降到2.4GB (根据优化的执行计划, Impala对sym_rb_tran_hist只是进行表扫描操作，即本地磁盘的顺序读)。值得一提的是，Hive在执行该join SQL操作时，由于join的关键字段并不一致，从而会生成两个不同的MapReduce任务进行执行，进一步降低执行的效率。因此即使Hive使用了整个集群的资源，由于SQL执行计划的优化不足，Hive执行的时间也显著慢于Impala。

并发SQL的执行性能 (3+3)

正如之前提到的，在当前实现的版本中，Impala在分布式执行group by或者join时，会限制每台机器上资源的使用。因此即使是在并发的情况下，Impala的执行效率也是非常

12

高效的。同样运行6个SQL，可以从测试结果中发现：虽然并发执行效率上不如单条SQL的执行效率，但是性能下降并不明显 (相比于Hive)：group by SQL从21.9分钟下降到26分钟左右；join SQL从4.1分钟下降到6分钟左右 (甚至还比Hive单独运行join SQL快)。

1.1.2 SAP HANA检测报告

根据研究机构IDC最新发布的调查报告，SAP的数据库业务在过去一年中保持了最快速的增长，收购Sybase两年之后，SAP凭借HANA的强势，已经坐稳数据库市场第四的位置。

IDC的数据显示，SAP数据库业务在2011年中增长了44%，同时数据库市场份额提高了3.9%，数据库收入也从2010年的6.97亿美元增长到了10亿美元。

在IDC最新出炉的RDBMS调查报告中，他们将SAP的增长归结为HANA内存数据库的表现良好，SAP在今年发布了明确的数据库发展路线，已经将Sybase ASE、Sybase IQ、SQL Anywhere和HANA等产品进行了充分的整合，目前SAP在数据库市场中的实力已不容小觑。

IDC预测5年之内，基于内存的技术将取代传统的磁盘。而像大数据这样概念的兴起，也为传统的数据库技术提出了更多的挑战。

1.1.2.1 测试简介

100 TB性能测试旨在证明SAP HANA的高效性和可扩展性；企业运用大型数据库中的数据进行运营分析时，SAP HANA能够帮助企业轻松提升实时商务智能的分析性能。以下将分别介绍测试环境，并提供和分析测试结果

13

测试环境

性能测试环境旨在搭建一个销售与分销（SD）智能商务查询环境，为大量的结构化查询语言（SQL）和业务用户提供支持。

数据库模式 下图1.18-1中的星形模式设计显示SD测试数据环境和每个表的基数。此设计中不使用手动调优结构；没有索引、物化视图、汇总表或其他为实现更快查询性能添加的冗余结构。

SD模式

测试数据 测试数据包括一个大的数据表和几个较小的维度表，如图1中所示。仅在数据表中就有1千亿条记录，代表5年的SD数据。数据使用“Customer_ID”在16个节点进行平均哈希分区，然后在每个节点，将数据按月份分区。这样，每个节点会有60个分区，每个分区约有1.04亿条记录。（另请参见图1.18-2和“加载”部分。）

14

百度搜索“77cn”或“免费范文网”即可找到本站免费阅读全部范文。收藏本站方便下次阅读，免费范文网，提供经典小说综合文库Hadoop大数据平台-测试报告及成功案例(3)在线全文阅读。