• [原创]kudu vs parquet, impala vs spark Benchmark


    测试环境

    • 节点:

                   2 台主节点,6台计算节点

    • 机器配置:

                   16个物理核

                   128G内存

                   12*3T磁盘

    • 操作系统:

                   redhat 7.2

    • 版本:

                   CDH 5.7.1-1.cdh5.7.1.p0.11

                   impala_kudu 2.7.0-1.cdh5.9.0.p0.23

                   kudu 0.9.1-1.kudu0.9.1.p0.32

                   spark 2.0.0

    • 对照组:

                   Spark on Parquet

                   Impala on Parquet

                   Impala on Kudu

    测试数据、语句、场景

        TPC-DS,是用于评测决策支持系统(或数据仓库)的标准SQL测试集。这个测试集包含对大数据集的统计/报表生成/联机查询/数据挖掘等复杂应用,测试用的数据和值是有倾斜的,与真实数据一致。可以说TPC-DS是与真实场景非常接近的一个测试集,也是难度较大的一个测试集。

        TPC-DS支持指定不同的数据大小。本次测试选择的数据大小分别为10GB、100GB、1TB、10TB。数据大小与表rows的关系如下图所示:

     

        TPC-DS一共99个测试案例,遵循SQL'99和SQL 2003的语法标准,SQL案例比较复杂.分析的数据量大,并且测试案例是在回答真实的商业问题.测试案例中包含各种业务模型(如分析报告型,迭代式的联机分析型,数据挖掘型等).本次测试使用了大部分的query,某些query由于语法错误、语法不兼容,或者在Hive、Spark、Impala下面都无法跑过,因此这些query不纳入性能测试的范围。

    参数配置

        本次测验基本上使用了CDH的默认配置。一些重要配置有:

    • Hadoop:  使用非安全模式,不带kerberos认证。
    • Impala:  使用自带的Resource Management,而非YARN;Catalog Server设置内存为32gb;impalad内存设置为64gb。
    • Kudu:   使用data disks的第一块磁盘作为WAL磁盘(也就是使用SATA盘);Kudu Tablet Server内存设置为32gb。
    • Spark:  配置如下
    spark.serializer                 org.apache.spark.serializer.KryoSerializer
    spark.driver.memory              10g
    spark.executor.memory           10g
    spark.executor.instances        36
    spark.executor.cores            5
    spark.yarn.executor.memoryOverhead  2g 
    spark.sql.autoBroadcastJoinThreshold    209715200
    

      

    测试步骤

    1. 通过tpcds-gen在hdfs上生成parquet数据
    2. 利用impala将tpcds数据从hdfs上导入到kudu
    3. 测试impala on kudu的性能
    4. 测试impala on parquet性能
    5. 测试spark on parquet的性能

    测试结果

    Kudu数据导入速度

        如图所示,kudu在导入小表时速度非常快,当导入大表时,速度反而变慢,性能严重下降。为了避免表字段类型、字段数目、大小造成的速度差异。我们根据同一张表store_sales进行比较,其结果为

     

                                                (单位rows/秒, 越大越好)

        由于kudu一开始先将数据插入到memRowSet,因此在数据集较小时插入速度非常快。当插入的数据达到10亿条级别以上时,性能开始出现严重的downgrade。根据Todd在slack上的解释是,impala插入数据时采用了随机的顺序,如果先将数据排序,再用impala导入可改善插入性能。目前社区正在改善此问题。

    Kudu 查询性能

        首先我们比较一下100GB下impala on kudu 和impala on parquet的性能

                                               (单位second, 越小越好)

        如图所示,在小数据集的查询性能上,kudu普遍比parquet慢了2倍~10倍。

        如果我们再比较一下1TB下的性能,可以发现

     

        Kudu比parquet慢了10倍~100倍。这其中很可能是由于impala对kudu缺少优化导致的。因此我们再来比较基本查询kudu的性能

     

        如图所示,单从简单查询来看,kudu的性能和imapla差距不是特别大,其中出现的波动是由于缓存导致的。和impala的差异主要来自于impala的优化。

    Spark 2.0 / Impala查询性能

    查询速度

     

                                                (单位second, 越小越好)

        从数据大小分析, 1TB和10TB下的差异不大。

        从语句进行分析,Impala对于query75、query94下的性能较差,很可能是语句优化,join顺序导致的异常。Spark对于query17、query50性能较差。

        综合分析,可以发现impala的速度普遍比Spark快一倍以上。Impala经过compute stats之后,消除了query75、query94这两个语句的异常,在其它语句上的速度提升达到了一倍以上,在某些语句上compute stats后速度反而下降,如query58,然而这种情况很少见。

    资源使用情况

     

        Impala的资源使用整体少于Spark,磁盘的数据读取少于Spark,这对于速度的提高至关重要,这与其语句的优化有关。Impala的CPU一直维持在较低的水平,说明其C++的实现比JAVA高效。

        Spark的CPU占用较高,但是维持在50%的水平,可见CPU并没有成为其瓶颈。Spark的磁盘写入(绿色)非常多,这也许是其速度的主要瓶颈。从网络IO上来看Spark也多余Impala,这一点可能与语句的优化、join、shuffle的实现方式有关。

    --------

    By 浴雨青山

    商业转载请联系作者获得授权,非商业转载请注明出处

  • 相关阅读:
    Java内存回收
    Android四大基本组件介绍与生命周期
    JAVA中获取当前系统时间
    jquery如何判断元素是否被点击_百度知道
    css控制div显示/隐藏方法及2种方法比较原码
    点击图标不断震动效果
    jquery 如何动态添加、删除class样式方法介绍_jquery_脚本之家
    HTML5绘制矩形和圆形并且还有获取在这个图层内的坐标的思路和代码
    Attribute name invalid for tag form according to TLD异常解决办法_gaigai_百度空间
    html5绘图
  • 原文地址:https://www.cnblogs.com/wasu/p/5828586.html
Copyright © 2020-2023  润新知