zoukankan      html  css  js  c++  java

  • Presto压测报告

    一、通过Presto insert到其他数据源的性能

    1、压测结果

    （K是一千，M是一百万）

    源库

    源表

    行数

    worker数
    （每worker 100G内存）

    tpch -> hive

    tpch -> es6

    tpch -> mysql

    耗时（分:秒）

    速率（rows/s）

    耗时（分:秒）

    速率（rows/s）

    耗时（分:秒）

    速率（rows/s）

    tiny
    (基准)

    lineitem

    60K

    4

    		    

    1:57

    513

    		    

    orders

    15K

    4

    		    

    2:51

    87

    		    

    part

    2K

    4

    		    

    2:34

    12

    		    

    supplier

    0.1K

    4

    		    

    0:03

    38

    		    

    customer

    1.5K

    4

    		    

    3:46

    6

    		    

    partsupp

    8K

    4

    		    

    5:29

    24

    		    

    sf100
    (基准的10000倍)

    lineitem

    600M

    1

    53:57

    185K

    		        

    4

    13:28

    743K

    871:13

    11.5K

    400:10

    25K

    orders

    150M

    4

    2:55

    855K

    335:50

    7.44K

    96:20

    26K

    part

    20M

    4

    0:41

    485K

    52:12

    6.38K

    11:18

    29.5K

    supplier

    1M

    4

    0:05

    1050K

    0:27

    36.8K

    0:38

    26.3K

    customer

    15M

    1

    3:21

    74.4K

    		        

    4

    0:25

    610K

    25:27

    9.82K

    9:49

    25.5K

    partsupp

    80M

    4

    1:17

    1050K

    211:57

    6.29K

    43:36

    30.6K

    sf300
    (基准的30000倍)

    lineitem

    1800M

    4

    40:11

    747K

    		        

    orders

    450M

    4

    8:03

    932K

    		        

    part

    60M

    4

    1:56

    519K

    		        

    supplier

    3M

    4

    0:06

    483K

    		        

    customer

    45M

    4

    1:11

    634K

    		        

    partsupp

    240M

    4

    3:28

    1150K

    		        

    转换成图表如下所示（纵轴单位1000行/秒，横轴单位1百万行）：

    相同数据量不同数据源的insert速率

    2、解读

    随着worker数的增加，性能线性增长；

    随着数据量的增加，耗时线性增长；

    tpch -> hive 速度还是非常快的

    tpch -> es6 慢很多，默认配置，未进行参数优化，查了下资料也无可优化写入的参数，由于速度非常慢，不建议大数据量插入。

    tpch -> mysql 也不快，而且在insert时先将数据插入临时表，然后再从临时表导入到目标表，这样会消耗两倍的磁盘空间和时间，可使用create table as提高性能

    3、建议

    不建议使用Presto大批量insert数据到ElasticSearch或MySQL，在需要插数据到MySQL时要使用create table as

    二、TPCH OLAP性能

    1、TPCH介绍

    TPC（事务处理性能委员会），由数十家会员公司创建的非盈利组织，功能是制定商务应用基准程序（Benchmark）的标准规范、性能和价格度量，并管理测试结果的发布，其发布的TPCH标准的主要目的是评价特定查询的决策支持能力，强调数据库在数据挖掘、分析处理方面的能力，包含22段复杂sql，详情可见https://yq.aliyun.com/articles/149715?t=t1

    由于数据量的大小对查询速度有直接的影响，TPC- H 标准对数据库系统中的数据量有严格、明确的规定。用SF 描述数据量，1SF 对应1 GB 单位，SF 由低到高依次是1、10、30、100、300、1 000、3 000、10 000。需要强调，SF 规定的数据量只是8个基本表的数据量，不包括索引和临时表。

    2、Hive和TPCH

    （1）压测结果

    无预热，以运行2次的平均时间作为最终运行时间，worker数4，每worker 100G内存

    join_distribution_type为PARTITIONED，join_reordering_strategy为ELIMINATE_CROSS_JOINS

    查询语句

    sf100(基准的10000倍)

    sf300(基准的30000倍)

    sf1000(基准的100000倍)

    HIVE on Presto

    Hive on MR

    TPCH on Presto

    HIVE on Presto

    Hive on MR

    TPCH on Presto

    TPCH on Presto

    q01

    8.599 s ± 470.226 ms

    6.5 m

    8.779 s ± 337.290 ms

    14.363 s ± 173.241 ms

    12.5 m

    26.196 s ± 807.516 ms

    1.422 m ± 3.524 s

    q02

    10.659 s ± 2.570 s

    >60 m 还未执行完

    14.194 s ± 661.145 ms

    25.267 s ± 2.235 s

    >60 m 还未执行完

    39.602 s ± 434.164 ms

    2.112 m ± 3.742 s

    q03

    10.490 s ± 1.621 s

    8 m

    27.493 s ± 148.492 ms

    28.781 s ± 2.642 s

    11 m

    1.411 m ± 1.800 s

    4.813 m ± 2.956 s

    q04

    4.152 s ± 57.276 ms

    6.5 m

    29.934 s ± 1.659 s

    10.121 s ± 827.315 ms

    6 m

    1.413 m ± 1.551 s

    4.997 m ± 5.850 s

    q05

    19.645 s ± 2.247 s

    13 m

    32.882 s ± 510.531 ms

    59.886 s ± 4.129 s

    17.5 m

    1.591 m ± 1.481 s

    5.508 m ± 4.229 s

    q06

    3.552 s ± 563.564 ms

    2 m

    4.158 s ± 1.613 s

    4.705 s ± 53.033 ms

    1.5 m

    13.544 s ± 1.587 s

    40.434 s ± 193.747 ms

    q07

    30.973 s ± 1.561 s

    22 m

    47.387 s ± 921.360 ms

    1.545 m ± 1.936 s

    30 m

    2.227 m ± 4.816 s

    7.741 m ± 29.050 s

    q08

    21.706 s ± 929.845 ms

    >90 m 还未执行完

    38.677 s ± 147.785 ms

    1.125 m ± 826.608 ms

    >90 m 还未执行完

    1.993 m ± 1.324 s

    4 worker，超过400G内存限制，资源不足

    q09

    30.347 s ± 1.276 s

    >60 m 还未执行完

    59.550 s ± 996.313 ms

    1.599 m ± 5.453 s

    >60 m 还未执行完

    2.998 m ± 3.964 s

    4 worker，超过400G内存限制，资源不足

    q10

    9.092 s ± 2.391 s

    13 m

    30.500 s ± 357.089 ms

    26.605 s ± 8.540 s

    12 m

    1.486 m ± 404.465 ms

    4.862 m ± 328.805 ms

    q11

    7.166 s ± 322.441 ms

    7 m

    7.797 s ± 212.132 ms

    21.236 s ± 3.460 s

    10 m

    19.765 s ± 1.293 s

    58.372 s ± 8.522 s

    q12

    4.087 s ± 171.827 ms

    7 m

    27.380 s ± 189.505 ms

    16.256 s ± 2.787 s

    9 m

    1.407 m ± 845.700 ms

    4.522 m ± 512.652 ms

    q13

    9.660 s ± 622.961 ms

    5 m

    27.948 s ± 342.240 ms

    22.866 s ± 1.432 s

    10 m

    1.414 m ± 161.220 ms

    4.759 m ± 680.237 ms

    q14

    4.084 s ± 324.562 ms

    4 m

    30.155 s ± 226.274 ms

    9.168 s ± 263.044 ms

    10 m

    1.514 m ± 303.349 ms

    5.025 m ± 439.113 ms

    q15

    4.145 s ± 102.530 ms

    6 m

    7.805 s ± 398.101 ms

    10.273 s ± 128.693 ms

    21 m

    19.677 s ± 9.899 ms

    1.084 m ± 1.469 s

    q16

    4.024 s ± 1.172 s

    8.5 m

    28.806 s ± 488.611 ms

    7.348 s ± 2.382 s

    24.5 m

    1.382 m ± 825.194 ms

    4.616 m ± 557.200 ms

    q17

    25.625 s ± 1.013 s

    9 m

    36.223 s ± 511.238 ms

    1.252 m ± 613.062 ms

    33 m

    1.898 m ± 450.427 ms

    6.265 m ± 127.279 ms

    q18

    24.291 s ± 917.825 ms

    20.5 m

    42.352 s ± 132.229 ms

    1.375 m ± 5.720 s

    50 m

    2.239 m ± 1.923 s

    7.535 m ± 2.703 s

    q19

    4.456 s ± 737.512 ms

    13 m

    32.079 s ± 828.022 ms

    13.788 s ± 1.279 s

    80 m

    1.588 m ± 485.782 ms

    5.250 m ± 1.347 s

    q20

    7.854 s ± 2.233 s

    4.5 m

    33.239 s ± 598.212 ms

    21.219 s ± 3.412 s

    34.5 m

    1.657 m ± 183.141 ms

    5.460 m ± 1.004 s

    q21

    58.191 s ± 5.942 s

    18.5 m

    1.072 m ± 1.531 s

    2.648 m ± 2.150 s

    83 m

    3.305 m ± 7.362 s

    4 worker，超过400G内存限制，资源不足

    q22

    3.363 s ± 1.896 s

    1.5 m

    25.634 s ± 730.441 ms

    6.997 s ± 1.295 s

    2 m

    1.245 m ± 3.536 ms

    4.184 m ± 801.859 ms

    转换成图表后如下所示（纵轴单位是秒）：

    同一数据量下的比较

    不同数据量TPCH on Presto的表现：

    （2）解读

    随着worker数的增加，性能线性增长；

    随着数据量的增加，耗时低于线性增长，对于批量处理的优化还是比较高的；

    当Hive由MR引擎更换到Presto引擎后，性能提升是显著的，可以将原来小时级的任务加速到秒级；

    由于插入数据是比较耗时的，所以又测了TPCH数据源的性能，这个数据源支持最高达300万倍基准数据的庞大数据量测试，通过比较发现，

           HIVE on Presto比同数据量的TPCH on Presto执行要快，可能是因为Hive数据存的是分布式文件系统Hdfs，且文件格式是列式存储ORC，读取效率高

    因此可通过TPCH on Presto大致估算HIVE on Presto执行所需的最大时长，发现4节点400G的Presto是完全可以支撑3万倍基准数据的OLAP查询的，可以支撑大部分的10万倍基准数据的复杂查询，有3个10万倍基准数据的复杂查询由于内存资源不足无法支撑

    （3）建议

    在内存资源足够的情况下，建议使用Presto作为Hive的执行引擎

    3、ElasticSearch

    （1）压测结果

    由于ES on Presto并不完全支持sql语法，如对一个字符串类型的列进行过滤时，使用Presto where过滤只能得到空值，需要用Presto ES connector的push-down特性才可以得到正确结果，而TPCH的sql非常复杂，且实际使用ES的场景中很少需要用到这么复杂的查询，因此只针对少量常用语法进行比较

    索引数据量

    操作

    ES on Presto

    ES on DSL

    tiny_customer
    1.5K

    数据量

    select count(1) from es6.default.tinyconsumer;

    1s

    GET /tiny_customer/_search
    {
      "query":{
        "match_all": {}
      },
      "size":0
    }
    找hits键值中的total键值

    1s

    使用_dsl强下推
    select count(1) from tiny_customer where _dsl='{"query":{"match_all":{}}}';

    1s

    简单过滤字段

    注意对于文本数据，必须使用push-down特性，不然查不到数据
    select * from customer where _mktsegment=match_phrase('HOUSEHOLD');

    1s

    GET /tiny_customer/_search
    {
      "query":{
        "match_phrase": {
          "mktsegment": "HOUSEHOLD"
        }
      }
    }

    2s

    select count(1) from customer where _mktsegment=match_phrase('HOUSEHOLD');

    1s

    去重数据量

    select count(distinct nationkey) from tiny_customer;

    1s

    GET /tiny_customer/_search
    {
      "query":{
        "match_all": {}
      },
      "size":0,
       "aggs": {
        "uid_aggs": {
          "cardinality": {
            "field": "nationkey"
          }
        }
      }
    }

    1s

    customer
    15M

    数据量

    select count(1) from es6.default.consumer;

    610s

    GET /customer/_search
    {
      "query":{
        "match_all": {}
      },
      "size":0
    }
    找hits键值中的total键值

    1s

    使用_dsl强下推
    select count(1) from customer where _dsl='{"query":{"match_all":{}}}';

    600s

    简单过滤字段

    注意对于文本数据，必须使用push-down特性，不然查不到数据
    select * from customer where _mktsegment=match_phrase('HOUSEHOLD');

    2s

    GET /customer/_search
    {
      "query":{
        "match_phrase": {
          "mktsegment": "HOUSEHOLD"
        }
      }
    }

    2s

    select count(1) from customer where _mktsegment=match_phrase('HOUSEHOLD');

    140s

    去重数据量

    select count(distinct nationkey) from customer;

    630s

    GET /customer/_search
    {
      "query":{
        "match_all": {}
      },
      "size":0,
       "aggs": {
        "uid_aggs": {
          "cardinality": {
            "field": "nationkey"
          }
        }
      }
    }

    1s

    （2）解读

    若查的数据量不大，Presto性能还是可以的，且更方便易用，但对于大数据量，发现只是查数据子集时两者性能差别不大，但遇到需要查数据量等扫描全索引的情况，这个时候ES on Presto就远不如ES on ES快，因为ES本身有丰富的统计信息，且对查询做了很多优化，而Presto需要把所有数据查出来再进行统计，即使使用_dsl强下推也无法显著提高性能，看来Presto并未针对ES特性做足够的优化

    （3）建议

    索引数据量不大的场景，或对性能不敏感且对易用性敏感的场景，可以使用Presto查ES中的数据。但在查询时注意不能完全套用普通sql语法，要对语法做充分测试

    三、性能优化

    1、数据源优化

    Presto使用的是MPP架构，使用纯内存计算，计算的效率是很高的，但在计算前要先把数据从数据源中读出来，这个阶段的性能就非常取决于数据源。

    当在Presto上对数据库跨库查询，例如Mysql数据库。这个时候Presto的做法是从MySQL数据库端拉取最基本的数据，然后再去做进一步的处理，例如统计等聚合操作。

    举个栗子：

    SELECT count(id) FROM table_1 WHERE condition=1;

    上面的SQL语句会分为3个步骤进行：

    • Presto发起到Mysql数据库进行查询

                  SELECT id FROM table_1 WHERE condition=1;

    • 对结果进行count计算
    • 返回结果

    所以说，对于Presto来说，其跨库查询的瓶颈是在数据拉取这个步骤。当一个查询中有多个数据源时，瓶颈取决于最慢的数据源的读取效率，当查询性能无法满足要求时，可考虑使用Presto sql把Mysql中相关的数据表定期转移到HDFS中，并转存为高效的列式存储格式ORC，且在归档的时候我们要选择一个归档字段，如果是按日归档，我们可以用日期作为这个字段的值，采用yyyy-MM-dd的形式，例如2019-01-23。

    2、集群优化

    （1）加节点数比加内存性能提升更明显，因为加节点不光会加内存，还会加cpu，提高处理能力

    （2）当内存不足，经常发生GC会极大降低性能甚至导致查询失败

    （3）单个节点的内存设置不可过小

    因为有的聚合运算的reduce步骤只能放在同一台机器执行，这个时候若内存数过小，会发生大量GC降低性能，甚至OOM无法执行。这是tpch q08，一个8表的join、group by操作，在一个130G的集群上执行，每个节点24G内存，但经过短时间的100多G内存的占用后持续了较长时间的24G内存占用，就是这个原因。一共需要执行12分钟，只有3分钟是占用了100多G内存

    四、业界压测参考

    以上内容只做了关于Presto的纵向性能测试，业界有做了关于市面上流行的开源引擎的比较，有兴趣的可以看看

    开源OLAP引擎测评报告(SparkSql、Presto、Impala、HAWQ、ClickHouse、GreenPlum)

     http://www.clickhouse.com.cn/topic/5c453371389ad55f127768ea
  • 相关阅读:
    OSI安全体系结构
    PHP 二维数组根据相同的值进行合并
    Java实现 LeetCode 17 电话号码的字母组合
    Java实现 LeetCode 16 最接近的三数之和
    Java实现 LeetCode 16 最接近的三数之和
    Java实现 LeetCode 16 最接近的三数之和
    Java实现 LeetCode 15 三数之和
    Java实现 LeetCode 15 三数之和
    Java实现 LeetCode 15 三数之和
    Java实现 LeetCode 14 最长公共前缀
  • 原文地址：https://www.cnblogs.com/codetouse/p/12745913.html
Copyright © 2011-2022 走看看