大数据基础技术领域中Hadoop的地位已获得广泛认同，但目前国内外市场上的Hadoop版本也是林林总总，到底该参照什么标准来考评Hadoop，尤其是给企业应用的Hadoop发行版平台呢？

    大家可能都听说过TPC–TransactionProcessing Performance Council，它是一个非赢利的标准化组织。它定义了多组标准测试集用于客观地／可重现地评测数据库的性能。TPC中有个Decision Support（DS）子集，即TPC-DS，是用于评测决策支持系统（或数据仓库）的标准SQL测试集。这个测试集包含对大数据集的统计／报表生成／联机查询／数据挖掘等复杂应用，测试用的数据和值是有倾斜的，与真实数据一致。可以说TPC-DS是与真实场景非常接近的一个测试集，也是难度较大的一个测试集。

    TPC-DS的这个特点跟大数据的分析挖掘应用非常类似。Hadoop等大数据分析技术也是对海量数据进行大规模的数据分析和深度挖掘，也包含交互式联机查询和统计报表类应用，同时大数据的数据质量也较低，数据分布是真实而不均匀的。因此TPC-DS成为客观衡量多个不同Hadoop版本以及SQLonHadoop技术的最佳测试集。随着国内外各代表性的Hadoop发行版厂商以TPC-DS为标准测评产品，TPC-DS也就逐渐成为了业界公认的Hadoop系统测试准则。这个基准测试有以下几个主要特点：

    ●一共99个测试案例，遵循SQL‘99和SQL2003的语法标准，SQL案例比较复杂

    ●分析的数据量大，并且测试案例是在回答真实的商业问题

    ●测试案例中包含各种业务模型（如分析报告型，迭代式的联机分析型，数据挖掘型等）

    ●几乎所有的测试案例都有很高的IO负载和CPU计算需求

    这个基准测试的完整信息请参考http://www.tpc.org/tpcds/。

    为了使大家进一步了解星环Hadoop发行版的性能，我们选取了国外具代表性的厂商Cloudera及其产品（ClouderaImpala）做对比测试。

    测试硬件环境

    我们搭建了两个集群分别用于TranswarpInceptor与ClouderaImpala的测试。每个集群采用4台普通两路x86服务器搭建，每台服务器硬件配置如下：

    我们使用的操作系统是64位的CentOS6.4，LinuxKernel版本号为2.6.32。TranswarpInceptor集群部署了Transwarp Data Hub (TDH) v3.4，包括基准的Hadoop 2.2以及Inceptor。系统配置方面，每台服务器的6块硬盘中有1块用于操作系统，其他5块硬盘用作HDFS。Hadoop的各种服务的配置如下：

    相对应地，我们在Cloudera的集群中安装了CDH5.1.3（包含Hadoop2.3）以及Impala1.4。

    测试软件设定

    TPC-DS配置

    考虑到磁盘的容量和HDFS的存储复制模式，我们选择的是500GB的数据总量。SQL测试案例的选择上，在ClouderaImpala中使用的是由Cloudera改动过的TPC-DS测试子集，在TranswarpInceptor我们选用的是TPC-DS为MySQL生成的测试集合，保留了原有的各种复杂SQL，因此能够客观反映出Inceptor在SQL支持上的情况。

    ClouderaImpala测试集合可参考https://github.com/cloudera/impala-tpcds-kit。

    Hadoop版本

    TranswarpDataHub(TDH) v3.4使用的是Hadoop2.2 版本，而ClouderaCDH 5.1.3使用的是Hadoop 2.3。HDFS 2.3增加了一些新的功能如DataNode Cache，因此能够更有效地减少磁盘读写。TDH下个版本会升级到Hadoop 2.3，届时我们会再次测试以权衡出HDFS的版本升级带来的性能提升情况。

    TranswarpTDH和ClouderaCDH都是用YARN作为资源调度组件，版本号分别为2.2和2.3，但是考虑到YARN这两个版本间没有大的性能相关功能，可以认为资源调度方面没有差异。

    其他组件没有太多的差异性，因此可以不考虑他们对最终的测试结果产生的影响。

    数据存储格式

    TranswarpInceptor可以支持基于内存和SSD的数据表作为数据输入，也支持ORC和Text文件格式。考虑到ClouderaImpala只支持磁盘表，为了公正测试，我们使用Inceptor的磁盘表ORC格式和Impala的Parquet格式做数据对比。另外，我们没有Cloudera Impala的详细资料，因此没有任何额外的参数设置和调优工作，只是使用默认的参数完成Impala的测试。

    测试方法

    为了保证数据的合理性，我们所有的性能测试数据都是每个测试案例完成三次运行后取的平均值。同时为了避免系统内部缓存对结果的影响，我们的测试不是连续将同一个测试SQL执行3次，而是连续执行完整个测试集合后再执行下一轮的测试集合。

    建表与数据分区

    TranswarpInceptor支持两种分区方式：基于单一值的分区方式（uniquevaluepartition）和区间分区方式(range partition)。考虑到TPC-DS基准测试的时间跨度包含十几年的数据，我们选择按照日期相关的列做区间分区(range partition)。大的事实表都采用这种分区策略，包括：store_sales, store_returns, catalog_sales, catalog_returns, web_sales, web_returns, inventory。另外所有的维度表不做任何的分区设定。原始TEXT格式的数据总量为～490GB，转成ORC格式后压缩成～150GB。

    ClouderaImpala使用修改版的测试案例，SQL集合中只包含一张事实表（store_sales）和9个维度表，生成的TEXT格式数据大小约130GB，实际导入的压缩的parquet文件总数据量只有50GB。

    测试结果

    测试案例支持广度

    TranswarpInceptor可以支持99个测试案例中的72个测试SQL，并且没有SQL会出现运行错误。在Inceptor4.0版本中，我们会加入更多的SQL支持，如Intersect/ExceptOperator，多层级的correlated subquery等，SQL的支持度将会进一步提高。

    下表是TPC-DS官方标准测试集合要求的主要SQL语法功能，以及TranswarpInceptor和ClouderaImpala的支持情况：

    由于ClouderaImpala的SQL语法支持非常有限，在Cloudera发布的测试集合中的20个SQL，只有6个是官方正式发布的版本。另外所有SQL中都只有一个事实表，没有出现多个事实表的案例。在TPC-DS的标准测试集合中，一共有39个测试案例是多个事实表之间的连接，而这些案例全部不在ClouderaImpala的测试集合中。此外所有的SQL中事实表都被加上了一个partitionkey的过滤条件，因此Cloudera的测试有些不够严谨。

    与之相对应的，TranswarpInceptor原生支持窗口统计函数和多维度GROUPBY统计，另外有Costbased optimizer来实时的生成过滤条件，选择更佳的表连接顺序，挑选更合适的表连接算法等，所以能够有效的支持这些标准的SQL测试案例。

    稳定性比较

    上图是整个测试过程中出现的OutOfMemory次数的比较。ClouderaImpala是基于内存的计算模式，内部采用thrift作用通信协议，所以只要网络或者内存有波动就比较容易出现错误，由于没有相应的容错设计，整个测试的稳定性表现比较差。在测试过程中，部分SQL（如query3，19，42等）一共有10次跑出Out Of Memory的错误，我们每次遇到这种问题后都会重启Impala来完成测试，否则会重复的遇到这个问题。因此，Cloudera Impala的测试过程中有大量的手工动作。

    相比较而言，TranswarpInceptor也是基于内存的计算，但是支持数据可动态地从内存换入换出到磁盘，能够有效的容错等内存使用量超大的计算场景，尤其是在有大量数据倾斜状况(dataskew)的场景。另外大量的数据shuffle都是通过HDFS完成的，因此可以确保正确性和容错能力。由于出色的健壮性和容错性，TranswarpInceptor整个测试计划全部是自动完成的。

    性能比较

    下图是所有的测试集合的性能对比图。图中纵坐标小于1表述测试案例中ClouderaImpala

    性能超过TranswarpInceptor，而大于1则表示TranswarpInceptor有更好的性能表现。对于ClouderaImpala不能支持的SQL，我们就标记这个性能比为100。

    从图中可见，在ClouderaImpala支持的20个SQL中，有11个SQL的表现超过TranswarpInceptor，2个表现相当，另外7个TranswarpInceptor比Cloudera Impala表现的更好。

    由于ClouderaImpala的测试案例中手工的给事实表添加了partitionkey的过滤条件，因此能够有效过滤大量数据，实际参与计算的数据量比TranswarpInceptor要少，所以在这些相关的案例中Cloudera Impala得以表现良好。另外一些SQL逻辑非常简单的案例中Cloudera Impala的表现也比较好，这个则要归功于Cloudera Impala使用C++代码开发，相对来说执行效率超过Transwarp Inceptor的Java语言。除此之外的其他案例中，如逻辑复杂的SQL、或大量数据参与实际计算、或窗口统计等情况中，Transwarp Inceptor无论从稳定性还是性能上表现都更为超越。

    另外，在和开源的Hive执行效率相比中，Inceptor3.4能够带来10x~100x的性能提升。下图是TPC-DS的部分query在Inceptor和CDHHive的性能提升倍数，其中最大的提升倍数竟可达到123倍。需要说明的是，这里用的Query跟Impala运行的相同。

    更多详细的性能比较以及TPC-DS的测试配置和细节可以参考星环发布的性能白皮书。

    测试小结

    通过TranswarpInceptor和ClouderaImpala在TPC-DS案例上的对比，我们不难得到如下结论：

    TranswarpInceptor在SQL支持度上远胜于ClouderaImpala，应用迁移成本更低。

    TranswarpInceptor在稳定性和容错性上表现优于ClouderaImpala，系统运维成本更低。

    TranswarpInceptor在性能表现上和ClouderaImpala基本相当，都有各自擅长的应用场景。

    TranswarpInceptor和ClouderaImpala的可扩展性方面的比较由于硬件资源的限制而没有测试，后期我们会加上相应的测试结果。

    结语

    虽然标准的Hadoop能够解决用户在数据处理上能与不能的问题，但却不能有效满足用户更深层次的需求，尤其两个方面：一是传统Hadoop使用MapReduce框架作为计算引擎，所有的数据计算以磁盘为中心，因此计算时间长，任务调度延时大，不适合交互式或者迭代式计算场景；二是HiveQL作为Hadoop的查询语言，其支持的语法比传统的SQL要小很多，因此不能满足实际用户的应用要求。

    星环科技的TranswarpInceptor交互式分析引擎构建于Hadoop之上，但使用Spark作为其默认计算引擎。Spark采用基于内存的计算模型和更细粒度的并发调度等技术，有效解决了MapReduce的高延时问题。在Spark基础上，TranswarpInceptor还扩展了多种执行引擎的优化技术，推出了基于内存与SSD的混合存储结构，有效将SQL任务执行的时间在开源Spark的技术上再降低了数倍，因而能够有效地应用于交互式和迭代式计算场景。

    TranswarpInceptor采用自主研发的SQL编译引擎，完善地支持SQL92、SQL‘99等标准，并且部分支持SQL2003以及PL/SQL，因此能够有效满足大部分客户的应用需求，避免大量的应用重写工作。

    随着在大数据领域国内外开始处于同一起跑线，我们相信像星环科技这样国内具有代表性的Hadoop发行版厂商将在中国的广阔市场空间中获得长足发展，并且由于中国市场激烈的竞争与磨练，逐步打磨出超越国外先进厂商的技术与实力。