精华内容
下载资源
问答
  • 即席查询调研报告
    2021-09-23 19:43:35

    即席查询调研报告

    什么是即席查询

    即席查询(Ad Hoc)是用户根据自己的需求,灵活的选择查询条件,系统能够根据用户的选择生成相应的统计报表。即席查询与普通应用查询最大的不同是普通的应用查询是定制开发的,而即席查询是指那些用户在使用系统时,根据自己当时的需求自定义的查询。

    测试组件介绍

    Apache Doris

    是一个现代化的MPP分析型数据库产品。仅需亚秒级响应时间即可获得查询结果,有效地支持实时数据分析。支持数据实时导入和实时查询,并且可以支持10PB以上的超大数据集。提供 OLAP 数据分析。(同时支持聚合和明细查询分析)

    starRocks

    fork于 Apache Doris,在此基础上做了一些增强

    特性
    1、联邦查询
    StarRocks支持使用外表的方式进行联邦查询,当前可以支持Hive,MySQL,Elasticserach三种类型的外表,用户无需通过数据导入,可以直接进行数据查询加速。
    2、全面向量化引擎
    CPU需要支持AVX2指令集, cat /proc/cpuinfo |grep avx2有结果输出表明CPU支持,如果没有支持,建议更换机器,StarRocks使用向量化技术需要一定的指令集支持才能发挥效果。
    3、智能查询优化
    StarRocks通过CBO优化器(Cost Based Optimizer)可以对复杂查询自动优化。无需人工干预,就可以通过统计信息合理估算执行成本,生成更优的执行计划,大大提高了Adhoc和ETL场景的数据分析效率。
    4、智能物化视图
    StarRocks支持智能的物化视图。用户可以通过创建物化视图,预先计算生成预聚合表用于加速聚合类查询请求。
    StarRocks的物化视图能够在数据导入时自动完成汇聚,与原始表数据保持一致。并且在查询的时候,用户无需指定物化视图,StarRocks能够自动选择最优的物化视图来满足查询请求。
    5、标准SQL
    StarRocks支持标准的SQL语法,包括聚合,JOIN,排序,窗口函数,自定义函数等功能。StarRocks可以完整支持TPC-H的22个SQL和TPC-DS的99个SQL。此外,StarRocks还兼容MySQL协议语法,可使用现有 的各种客户端工具、BI软件访问StarRocks,
    对StarRocks中的数据进行拖拽式分析。
    6、流批一体
    StarRocks支持实时和批量两种数据导入方式,支持的数据源有Kafka, HDFS, 本地文件,支持的数据格式有ORC, Parquet和CSV等,StarRocks可以实时消费Kafka数据来完成数据导入,保证数据不丢不重(exactly once)。StarRocks也可以从本地或者远程(HDFS)批量导入数据。

    Presto

    Presto是一个分布式SQL查询引擎, 它被设计为用来专门进行高速、实时的数据分析。它支持标准的ANSI SQL,包括复杂查询、聚合(aggregation)、连接(join)和窗口函数(window functions),动态编译/利用cpu的指令集并行化执行。它的产生是为了解决hive的MR太慢的问题,Presto 本身并不存储数据,但是可以接入多种数据源,并且支持跨数据源的级联查询。Presto是一个OLAP的工具,擅长对海量数据进行复杂的分析。

    ClickHouse

    Clickhouse由俄罗斯yandex公司开发。是一款用于大数据实时分析的列式数据库管理系统。通过向量化的执行以及对cpu底层指令集的使用,可以对海量数据进行并行处理,从而加快数据的处理速度。

    除此之外,adhoc还有Impala,但经社区反馈其多表查询性能和presto差不多,但是单表查询方面却不如presto好。而且Impala有很多不支持的地方,例如:不支持Date数据类型,不支持ORC文件格式等等,需要采用parquet格式进行查询,而且Impala在查询时占用的内存很大。因此直接pass掉

    测试方法

    TPC-H基准压测
    TPC-H 基准测试是由TPC-D发展而来的,是面向商品零售业的决策支持系统测试基准,它定义了8张表,22个查询,遵循SQL92;基准的数据库模式遵循第三范式;新兴的数据仓库开始采用新的模型,如星型模型、雪花模型。

    表的信息:2个事实表:lineorder,orders 6个维度表:customer,part,parsupp,supplier,region,nation
    数据查询:22条标准SQL查询测试语句:统计查询、多表关联、sum、复杂条件、group by、order by等组合方式

    TPC-H基准sql

    SSB基准压测
    SSB(Star Schema Benchmark)是在TPC-H基础之上,麻省州立大学波士顿校区的研究人员定义的基于现实商业应用的数据模型,是学术界和工业界广泛使用的一个星型模型测试集(来源论文),比较公正和中立。

    表的信息:1张大宽表:lineorder_flat;1张事实表:lineorder4张维度表:customer,part,dates,supplier
    数据查询:2类查询场景(单表和多表join)每类场景下有13条标准SQL查询测试语句:统计查询、多表关联、sum、复杂条件、group by、order by等组合方式

    本次主要通过ssb基准进行测试,通过这个测试集合可以方便的对比各种OLAP产品的基础性能指标。Clickhouse 通过改写SSB,将星型模型打平转化成宽表,改造成了一个单表测试benchmark。本报告记进行了StarRocks、ApacheDoris和Clickhouse在SSB单表测试,以及StarRocks和ApacheDoris的多表测试,由于Clickhouse对多表Join支持有限,这也不是clickhouse的强项,所以在多表测试中并未将Clickhouse加入测试。

    测试环境

    硬件环境

    机器1台腾讯云主机
    CPU16核(超线程)
    内存64G

    软件环境

    容器化环境部署,StarRocks,Apache Doris和Clickhouse容器分别部署在相同的机器上进行测试,都为standalone模式。

    StarRocksApache Doris的基础镜像为centos:7.9,Clickhouse基础镜像为Ubuntu 20,考虑到容器本身对资源的消耗很小,可以忽略不计。

    软件版本:StarRocks community 1.18.2 ,Aapche Doris 0.14.0,Clickhouse 21.8.6.15

    测试数据

    测试数据生成

    StarRocks和Apache Doris测试数据生成

    编译 :

    wget https://starrocks-public.oss-cn-beijing.aliyuncs.com/ssb-poc-0.9.2.zip
    unzip ssb-poc-0.9.2.zip
    cd ssb-poc
    make && make install

    生成数据:

    cd output

    bin/gen-ssb.sh 10 data_dir

    注意: 如果使用因子100,生成6亿条记录的初始文件,约59G;使用因子1000,生成60亿条记录的初始文件,约600G;本次使用因子10,生成6千万条记录的初始文件,约6G。

    创建表结构:

    修改配置文件conf/starrocks.conf,指定脚本操作的集群地址

     # for mysql cmd
     mysql_host: 192.168.1.1 #fe地址
     mysql_port: 9030
     mysql_user: root
     mysql_password:
     database: ssb
     
    # cluster ports
      http_port: 8030
      be_heartbeat_port: 9050
      broker_port: 8000
    
    # parallel_fragment_exec_instance_num
    parallel_num: 1
    
     ...
    

    使用Stream load导入单表数据

    bin/stream_load.sh data_dir

    插入数据到宽表lineorder_flat

    bin/flat_insert.sh

    或者创建分区宽表lineorder_flat

    CREATE TABLE `lineorder_flat` (
      `lo_orderdate` date NOT NULL COMMENT "",
      `lo_orderkey` int(11) NOT NULL COMMENT "",
      `lo_linenumber` tinyint(4) NOT NULL COMMENT "",
      `lo_custkey` int(11) NOT NULL COMMENT "",
      `lo_partkey` int(11) NOT NULL COMMENT "",
      `lo_suppkey` int(11) NOT NULL COMMENT "",
      `lo_orderpriority` varchar(100) NOT NULL COMMENT "",
      `lo_shippriority` tinyint(4) NOT NULL COMMENT "",
      `lo_quantity` tinyint(4) NOT NULL COMMENT "",
      `lo_extendedprice` int(11) NOT NULL COMMENT "",
      `lo_ordtotalprice` int(11) NOT NULL COMMENT "",
      `lo_discount` tinyint(4) NOT NULL COMMENT "",
      `lo_revenue` int(11) NOT NULL COMMENT "",
      `lo_supplycost` int(11) NOT NULL COMMENT "",
      `lo_tax` tinyint(4) NOT NULL COMMENT "",
      `lo_commitdate` date NOT NULL COMMENT "",
      `lo_shipmode` varchar(100) NOT NULL COMMENT "",
      `c_name` varchar(100) NOT NULL COMMENT "",
      `c_address` varchar(100) NOT NULL COMMENT "",
      `c_city` varchar(100) NOT NULL COMMENT "",
      `c_nation` varchar(100) NOT NULL COMMENT "",
      `c_region` varchar(100) NOT NULL COMMENT "",
      `c_phone` varchar(100) NOT NULL COMMENT "",
      `c_mktsegment` varchar(100) NOT NULL COMMENT "",
      `s_region` varchar(100) NOT NULL COMMENT "",
      `s_nation` varchar(100) NOT NULL COMMENT "",
      `s_city` varchar(100) NOT NULL COMMENT "",
      `s_name` varchar(100) NOT NULL COMMENT "",
      `s_address` varchar(100) NOT NULL COMMENT "",
      `s_phone` varchar(100) NOT NULL COMMENT "",
      `p_name` varchar(100) NOT NULL COMMENT "",
      `p_mfgr` varchar(100) NOT NULL COMMENT "",
      `p_category` varchar(100) NOT NULL COMMENT "",
      `p_brand` varchar(100) NOT NULL COMMENT "",
      `p_color` varchar(100) NOT NULL COMMENT "",
      `p_type` varchar(100) NOT NULL COMMENT "",
      `p_size` tinyint(4) NOT NULL COMMENT "",
      `p_container` varchar(100) NOT NULL COMMENT ""
    ) ENGINE=OLAP
    DUPLICATE KEY(`lo_orderdate`, `lo_orderkey`)
    COMMENT "OLAP"
    PARTITION BY RANGE(`lo_orderdate`)
    (PARTITION p1 VALUES [('0000-01-01'), ('1993-01-01')),
    PARTITION p2 VALUES [('1993-01-01'), ('1994-01-01')),
    PARTITION p3 VALUES [('1994-01-01'), ('1995-01-01')),
    PARTITION p4 VALUES [('1995-01-01'), ('1996-01-01')),
    PARTITION p5 VALUES [('1996-01-01'), ('1997-01-01')),
    PARTITION p6 VALUES [('1997-01-01'), ('1998-01-01')),
    PARTITION p7 VALUES [('1998-01-01'), ('1999-01-01')))
    DISTRIBUTED BY HASH(`lo_orderkey`) BUCKETS 48
    PROPERTIES (
    "replication_num" = "1",
    "in_memory" = "false",
    "storage_format" = "DEFAULT"
    );
    

    clickhouse测试数据生成

    编译 :

    git clone https://github.com/vadimtk/ssb-dbgen.git
    cd ssb-dbgen
    make

    其他参考链接,使用因子10,生成6千万条测试数据。

    测试数据详情

    表名行数解释
    lineorder6千万SSB商品订单表
    customer30万SSB客户表
    part80万SSB 零部件表
    supplier2万SSB 供应商表
    dates2556日期表
    lineorder_flat6千万SSB打平后的宽表

    测试sql

    单表测试SQL

    --Q1.1 
    SELECT sum(lo_extendedprice * lo_discount) AS `revenue` 
    FROM lineorder_flat 
    WHERE lo_orderdate >= '1993-01-01' and lo_orderdate <= '1993-12-31' AND lo_discount BETWEEN 1 AND 3 AND lo_quantity < 25; 
     
    --Q1.2 
    SELECT sum(lo_extendedprice * lo_discount) AS revenue FROM lineorder_flat  
    WHERE lo_orderdate >= '1994-01-01' and lo_orderdate <= '1994-01-31' AND lo_discount BETWEEN 4 AND 6 AND lo_quantity BETWEEN 26 AND 35; 
     
    --Q1.3 
    SELECT sum(lo_extendedprice * lo_discount) AS revenue 
    FROM lineorder_flat 
    WHERE weekofyear(lo_orderdate) = 6 AND lo_orderdate >= '1994-01-01' and lo_orderdate <= '1994-12-31' 
     AND lo_discount BETWEEN 5 AND 7 AND lo_quantity BETWEEN 26 AND 35; 
     
     
    --Q2.1 
    SELECT sum(lo_revenue), year(lo_orderdate) AS year,  p_brand 
    FROM lineorder_flat 
    WHERE p_category = 'MFGR#12' AND s_region = 'AMERICA' 
    GROUP BY year,  p_brand 
    ORDER BY year, p_brand; 
     
    --Q2.2 
    SELECT 
    sum(lo_revenue), year(lo_orderdate) AS year, p_brand 
    FROM lineorder_flat 
    WHERE p_brand >= 'MFGR#2221' AND p_brand <= 'MFGR#2228' AND s_region = 'ASIA' 
    GROUP BY year,  p_brand 
    ORDER BY year, p_brand; 
      
    --Q2.3 
    SELECT sum(lo_revenue),  year(lo_orderdate) AS year, p_brand 
    FROM lineorder_flat 
    WHERE p_brand = 'MFGR#2239' AND s_region = 'EUROPE' 
    GROUP BY  year,  p_brand 
    ORDER BY year, p_brand; 
     
     
    --Q3.1 
    SELECT c_nation, s_nation,  year(lo_orderdate) AS year, sum(lo_revenue) AS revenue FROM lineorder_flat 
    WHERE c_region = 'ASIA' AND s_region = 'ASIA' AND lo_orderdate  >= '1992-01-01' AND lo_orderdate   <= '1997-12-31' 
    GROUP BY c_nation, s_nation, year 
    ORDER BY  year ASC, revenue DESC; 
     
    --Q3.2 
    SELECT  c_city, s_city, year(lo_orderdate) AS year, sum(lo_revenue) AS revenue
    FROM lineorder_flat 
    WHERE c_nation = 'UNITED STATES' AND s_nation = 'UNITED STATES' AND lo_orderdate  >= '1992-01-01' AND lo_orderdate <= '1997-12-31' 
    GROUP BY c_city, s_city, year 
    ORDER BY year ASC, revenue DESC; 
     
    --Q3.3 
    SELECT c_city, s_city, year(lo_orderdate) AS year, sum(lo_revenue) AS revenue 
    FROM lineorder_flat 
    WHERE c_city in ( 'UNITED KI1' ,'UNITED KI5') AND s_city in ( 'UNITED KI1' ,'UNITED KI5') AND lo_orderdate  >= '1992-01-01' AND lo_orderdate <= '1997-12-31' 
    GROUP BY c_city, s_city, year 
    ORDER BY year ASC, revenue DESC; 
     
    --Q3.4 
    SELECT c_city, s_city, year(lo_orderdate) AS year, sum(lo_revenue) AS revenue 
    FROM lineorder_flat 
    WHERE c_city in ('UNITED KI1', 'UNITED KI5') AND s_city in ( 'UNITED KI1',  'UNITED KI5') AND  lo_orderdate  >= '1997-12-01' AND lo_orderdate <= '1997-12-31' 
    GROUP BY c_city,  s_city, year 
    ORDER BY year ASC, revenue DESC; 
     
     
    --Q4.1 
    set vectorized_engine_enable = FALSE; 
    SELECT year(lo_orderdate) AS year, c_nation,  sum(lo_revenue - lo_supplycost) AS profit FROM lineorder_flat 
    WHERE c_region = 'AMERICA' AND s_region = 'AMERICA' AND p_mfgr in ( 'MFGR#1' , 'MFGR#2') 
    GROUP BY year, c_nation 
    ORDER BY year ASC, c_nation ASC; 
     
    --Q4.2 
    SELECT year(lo_orderdate) AS year, 
        s_nation, p_category, sum(lo_revenue - lo_supplycost) AS profit 
    FROM lineorder_flat 
    WHERE c_region = 'AMERICA' AND s_region = 'AMERICA' AND lo_orderdate >= '1997-01-01' and lo_orderdate <= '1998-12-31' AND  p_mfgr in ( 'MFGR#1' , 'MFGR#2') 
    GROUP BY year, s_nation,  p_category 
    ORDER BY  year ASC, s_nation ASC, p_category ASC; 
     
    --Q4.3 
    SELECT year(lo_orderdate) AS year, s_city, p_brand, 
        sum(lo_revenue - lo_supplycost) AS profit 
    FROM lineorder_flat 
    WHERE s_nation = 'UNITED STATES' AND lo_orderdate >= '1997-01-01' and lo_orderdate <= '1998-12-31' AND p_category = 'MFGR#14' 
    GROUP BY  year,  s_city, p_brand 
    ORDER BY year ASC,  s_city ASC,  p_brand ASC; 
    

    多表测试SQL

    --Q1.1 
    select sum(lo_revenue) as revenue
    from lineorder join dates on lo_orderdate = d_datekey
    where d_year = 1993 and lo_discount between 1 and 3 and lo_quantity < 25;
    
    --Q1.2
    select sum(lo_revenue) as revenue
    from lineorder
    join dates on lo_orderdate = d_datekey
    where d_yearmonthnum = 199401
    and lo_discount between 4 and 6
    and lo_quantity between 26 and 35;
    
    --Q1.3
    select sum(lo_revenue) as revenue
    from lineorder
    join dates on lo_orderdate = d_datekey
    where d_weeknuminyear = 6 and d_year = 1994
    and lo_discount between 5 and 7
    and lo_quantity between 26 and 35;
    
    
    --Q2.1
    select sum(lo_revenue) as lo_revenue, d_year, p_brand
    from lineorder
    inner join dates on lo_orderdate = d_datekey
    join part on lo_partkey = p_partkey
    join supplier on lo_suppkey = s_suppkey
    where p_category = 'MFGR#12' and s_region = 'AMERICA'
    group by d_year, p_brand
    order by d_year, p_brand;
    
    --Q2.2
    select sum(lo_revenue) as lo_revenue, d_year, p_brand
    from lineorder
    join dates on lo_orderdate = d_datekey
    join part on lo_partkey = p_partkey
    join supplier on lo_suppkey = s_suppkey
    where p_brand between 'MFGR#2221' and 'MFGR#2228' and s_region = 'ASIA'
    group by d_year, p_brand
    order by d_year, p_brand;
    
    --Q2.3
    select sum(lo_revenue) as lo_revenue, d_year, p_brand
    from lineorder
    join dates on lo_orderdate = d_datekey
    join part on lo_partkey = p_partkey
    join supplier on lo_suppkey = s_suppkey
    where p_brand = 'MFGR#2239' and s_region = 'EUROPE'
    group by d_year, p_brand
    order by d_year, p_brand;
    
    
    --Q3.1
    select c_nation, s_nation, d_year, sum(lo_revenue) as lo_revenue
    from lineorder
    join dates on lo_orderdate = d_datekey
    join customer on lo_custkey = c_custkey
    join supplier on lo_suppkey = s_suppkey
    where c_region = 'ASIA' and s_region = 'ASIA'and d_year >= 1992 and d_year <= 1997
    group by c_nation, s_nation, d_year
    order by d_year asc, lo_revenue desc;
    
    --Q3.2
    select c_city, s_city, d_year, sum(lo_revenue) as lo_revenue
    from lineorder
    join dates on lo_orderdate = d_datekey
    join customer on lo_custkey = c_custkey
    join supplier on lo_suppkey = s_suppkey
    where c_nation = 'UNITED STATES' and s_nation = 'UNITED STATES'
    and d_year >= 1992 and d_year <= 1997
    group by c_city, s_city, d_year
    order by d_year asc, lo_revenue desc;
    
    --Q3.3
    select c_city, s_city, d_year, sum(lo_revenue) as lo_revenue
    from lineorder
    join dates on lo_orderdate = d_datekey
    join customer on lo_custkey = c_custkey
    join supplier on lo_suppkey = s_suppkey
    where (c_city='UNITED KI1' or c_city='UNITED KI5')
    and (s_city='UNITED KI1' or s_city='UNITED KI5')
    and d_year >= 1992 and d_year <= 1997
    group by c_city, s_city, d_year
    order by d_year asc, lo_revenue desc;
    
    --Q3.4
    select c_city, s_city, d_year, sum(lo_revenue) as lo_revenue
    from lineorder
    join dates on lo_orderdate = d_datekey
    join customer on lo_custkey = c_custkey
    join supplier on lo_suppkey = s_suppkey
    where (c_city='UNITED KI1' or c_city='UNITED KI5') and (s_city='UNITED KI1' or s_city='UNITED KI5') and d_yearmonth
     = 'Dec1997'
    group by c_city, s_city, d_year
    order by d_year asc, lo_revenue desc;
    
    
    --Q4.1
    select d_year, c_nation, sum(lo_revenue) - sum(lo_supplycost) as profit
    from lineorder
    join dates on lo_orderdate = d_datekey
    join customer on lo_custkey = c_custkey
    join supplier on lo_suppkey = s_suppkey
    join part on lo_partkey = p_partkey
    where c_region = 'AMERICA' and s_region = 'AMERICA' and (p_mfgr = 'MFGR#1' or p_mfgr = 'MFGR#2')
    group by d_year, c_nation
    order by d_year, c_nation;
    
    --Q4.2
    select d_year, s_nation, p_category, sum(lo_revenue) - sum(lo_supplycost) as profit
    from lineorder
    join dates on lo_orderdate = d_datekey
    join customer on lo_custkey = c_custkey
    join supplier on lo_suppkey = s_suppkey
    join part on lo_partkey = p_partkey
    where c_region = 'AMERICA'and s_region = 'AMERICA'
    and (d_year = 1997 or d_year = 1998)
    and (p_mfgr = 'MFGR#1' or p_mfgr = 'MFGR#2')
    group by d_year, s_nation, p_category
    order by d_year, s_nation, p_category;
    
    --Q4.3
    select d_year, s_city, p_brand, sum(lo_revenue) - sum(lo_supplycost) as profit
    from lineorder
    join dates on lo_orderdate = d_datekey
    join customer on lo_custkey = c_custkey
    join supplier on lo_suppkey = s_suppkey
    join part on lo_partkey = p_partkey
    where c_region = 'AMERICA'and s_nation = 'UNITED STATES'
    and (d_year = 1997 or d_year = 1998)
    and p_category = 'MFGR#14'
    group by d_year, s_city, p_brand
    order by d_year, s_city, p_brand;
    

    运行测试用例

    本测试采用单核测试

    clickhouse

    在客户端执行命令

    set max_threads=1;

    clickhouse 使用上面单表测试SQL进行单表性能测试

    starrocks和Apache doris

    在客户端执行命令

    set global parallel_fragment_exec_instance_num = 1;

    starrocks和Apache doris分别单表和多表测试,执行上面的SQL

    或者执行上面生成测试数据生成的脚本分别进行单表和多表测试

    执行SQL:

    bin/benchmark.sh -p -d ssb
    bin/benchmark.sh -p -d ssb-flat

    测试结果

    单表测试结果

    SQLStarRocks 用时(ms)fisrtStarRocks 用时(ms)Apache Doris 用时(ms)firstApache Doris 用时(ms)Clickhouse用时(ms)firstClickhouse用时(ms)
    Q1.16882155398416479213
    Q1.2129902062036224
    Q1.3989518720077
    Q2.117155297869767828561199
    Q2.240543761516329965984
    Q2.3183160796724935952
    Q3.199310568170803417101342
    Q3.221321811271001971655
    Q3.3175118575565417429
    Q3.41191632172682519
    Q4.1113411009730898121581656
    Q4.238335929052694346323
    Q4.32842638021019330298

    在这里插入图片描述

    多表测试结果

    SQLStarRocks 用时(ms)firstStarRocks 用时(ms)Apache Doris 用时(ms)fisrtApache Doris 用时(ms)
    Q1.12349465066247
    Q1.2377542165114
    Q1.34745141174
    Q2.1114861263450505
    Q2.2204177513501
    Q2.310392428422
    Q3.15692452714954
    Q3.2995160697451
    Q3.312986487413
    Q3.44646397404
    Q4.11335261837825
    Q4.212296741744
    Q4.38979504515

    在这里插入图片描述

    结果分析

    从Linux 系统缓存命中率方面分析

    从测试结果可以看出同一个查询引擎,第一次运行的结果都会比再次运行的时间要长。因此禁用系统交换分区提高缓存命中率可以有效地提高分析引擎的查询效率。

    从不同查询引擎方面分析

    • 从单表测试结果分析,StarRocks 的性能以微弱的优势领先于 Clickhouse,但都明显高于Apache Doris。

    • 从多表测试结果分析,StarRocks 的性能明显高于Apache Doris。

    • 另外从社区反馈分析,Clickhouse的性能在单表性能方面明显高于presto,参考链接; Presto和DorisDB在同等环境下性能对比,ORC格式下StarRocks 查询Hive外表的性能大约是Presto的3.35倍,参考链接

    结论

    采用满分为5来比较各方面性能

    StarRocksApache DorisClickhousepresto
    单表查询性能5454
    多表查询性能5413
    外表支持3(有限支持)2(有限支持)0(不支持)5(丰富)
    社区活跃度1 (1.2k)2 (3.3k)5 (19.5k)4 (12.4k)

    时间:2021-09-23

    基于以上结论,得出以下各自使用场景

    clickhouse场景

    • 海量数据,但又不希望单节点的存储空间消耗太高。
    • 宽表,为了业务方便,可能会把很多相关数据列都整合到一个表里。

    StarRocks场景

    • 同时存在大量单表查询和多表聚合的需求
    • 存在实时增量的场景(例如:kafka实时接入)

    presto场景

    • 同时存在大量单表查询和多表聚合的需求,同时对性能要求不是太高
    • 存在多种数据源级联查询的场景
    • 可以与hive/hdfs深入绑定,利用hdfs本地化计算的优势

    由于StarRocks 是Apache Doris的加强版,因此推荐直接使用 StarRocks

    附件

    StarRocks docker-compose参考链接

    Apache doris docker-compose参考链接

    clickhouse部署参考链接

    presto部署参考链接

    更多相关内容
  • 数仓即席查询–Druid

    2021-01-07 15:05:15
    它在处理PB级数据,毫秒级查询,数据实时处理方面,比传统的OLAP系统有了显著的性能改进 官网:http://druid.io/ ps:阿里巴巴也有一个项目叫Druid,但是它是一个数据库连接池项目 Druid特点 1.列式存储格式 Druid使用面向...
  • 大数据即席查询技术.pptx
  • 数仓即席查询—Presto

    2021-01-07 13:57:54
    presto是一个开源的分布式SQL查询引擎,数据量支持GB到PB级,主要用来处理秒级查询场景 ps:虽然presto可以解析SQL,但它不是一个标准的数据库,不是MySQL,oracle的代替品,也不能用来处理在线事务(OLTP);官网:...
  • IQL即席查询服务

    2018-12-17 17:25:30
    基于SparkSQL实现了一套即席查询服务,具有如下特性: 优雅的交互方式,支持多种datasource/sink,多数据源混算 spark常驻服务,基于zookeeper的引擎自动发现 负载均衡,多个引擎随机执行 多session模式实现并行...
  • 即席查询引擎怎么选

    2021-09-22 09:09:44
    一、怎么理解即席查询 即席查询(Ad Hoc)是用户根据自己的需求,灵活的选择查询条件,系统能够根据用户的选择生成相应的统计报表。即席查询与普通应用查询最大的不同是普通的应用查询是定制开发的,而即席查询是由...

    一、怎么理解即席查询

     即席查询(Ad Hoc)是用户根据自己的需求,灵活的选择查询条件,系统能够根据用户的选择生成相应的统计报表。即席查询与普通应用查询最大的不同是普通的应用查询是定制开发的,而即席查询是由用户自定义查询条件的。

    1.1 即席查询与批处理后查询的区别 

     1.1.1 批处理后的查询

    在数据仓库系统中,根据应用程序的需求,需要对源数据进行加工,这些加工过程往往是固定的处理原则,这种情况下,可以把数据的增删改查SQL语句写成一个批处理脚本,由调度程序定时执行。

    特点:由于批处理脚本中的SQL语句是固定的,所以可以提前完成SQL语句的调优工作,使得批处理脚本的运行效率达到最佳。

    1.1.2 即席查询

    通常的方式是,将数据仓库中的维度表和事实表映射到语义层,用户可以通过语义层选择表,建立表间的关联,最终生成SQL语句。即席查询是用户在使用时临时生产的,系统无法预先优化这些查询,所以即席查询也是评估数据仓库的一个重要指标。

    在一个数据仓库系统中,即席查询使用的越多,对数据仓库的要求就越高,对数据模型的对称性的要求也越高。

    现在市场上运用更多的是:Kylin、Druid、Presto、Impala等等这些框架去诠释大数据即席查询的功能。此篇就来介绍四种框架的优缺点,用途与场景选择。

    二、Kylin

     2.1 Kylin特点

     Kylin的主要特点包括支持SQL接口、支持超大规模数据集、亚秒级响应、可伸缩性、高吞吐率、BI工具集成等。

    1. 标准SQL接口:Kylin是以标准的SQL作为对外服务的接口。

    2. 支持超大数据集:Kylin对于大数据的支撑能力可能是目前所有技术中最为领先的。早在2015年eBay的生产环境中就能支持百亿记录的秒级查询,之后在移动的应用场景中又有了千亿记录秒级查询的案例。

    3. 亚秒级响应:Kylin拥有优异的查询相应速度,这点得益于预计算,很多复杂的计算,比如连接、聚合,在离线的预计算过程中就已经完成,这大大降低了查询时刻所需的计算量,提高了响应速度。

    4. 可伸缩性和高吞吐率:单节点Kylin可实现每秒70个查询,还可以搭建Kylin的集群。

    5. BI工具集成

    • ODBC:与Tableau、Excel、PowerBI等工具集成

    • JDBC:与Saiku、BIRT等Java工具集成

    • RestAPI:与JavaScript、Web网页集成

    • Kylin开发团队还贡献了Zepplin的插件,也可以使用Zepplin来访问Kylin服务。

    2.2 Kylin工作原理

    Apache Kylin的工作原理本质上是MOLAP(Multidimension On-Line Analysis Processing)Cube,也就是多维立方体分析。在这里需要分清楚两个概念:

    2.2.1 维度和度量

    维度:即观察数据的角度。比如员工数据,可以从性别角度来分析,也可以更加细化,从入职时间或者地区的维度来观察。维度是一组离散的值,比如说性别中的男和女,或者时间维度上的每一个独立的日期。因此在统计时可以将维度值相同的记录聚合在一起,然后应用聚合函数做累加、平均、最大和最小值等聚合计算。

    度量:即被聚合(观察)的统计值,也就是聚合运算的结果。比如说员工数据中不同性别员工的人数,又或者说在同一年入职的员工有多少。

    2.2.2 Cube和Cuboid

    有了维度跟度量,一个数据表或者数据模型上的所有字段就可以分类了,它们要么是维度,要么是度量(可以被聚合)。于是就有了根据维度和度量做预计算的Cube理论。给定一个数据模型,我们可以对其上的所有维度进行聚合,对于N个维度来说,组合的所有可能性共有2n种。对于每一种维度的组合,将度量值做聚合计算,然后将结果保存为一个物化视图,称为Cuboid。所有维度组合的Cuboid作为一个整体,称为Cube 下面举一个简单的例子说明,假设有一个电商的销售数据集,其中维度包括

    时间[time]、商品[item]、地区[location]和供应商[supplier]

    度量为销售额。那么所有维度的组合就有16种,如下图所示:

    一维度(1D)的组合有4种:[time]、[item]、[location]和[supplier]4种;

    二维度(2D)的组合有6种:[time, item]、[time, location]、[time, supplier]、[item, location]、[item, supplier]、[location, supplier]

    三维度(3D)的组合也有4种

    最后还有零维度(0D)和四维度(4D)各有一种,总共16种

    2.3 核心算法

    Kylin的工作原理就是对数据模型做Cube预计算,并利用计算的结果加速查询:

    1. 指定数据模型,定义维度和度量;

    2. 预计算Cube,计算所有Cuboid并保存为物化视图;预计算过程是Kylin从Hive中读取原始数据,按照我们选定的维度进行计算,并将结果集保存到Hbase中,默认的计算引擎为MapReduce,可以选择Spark作为计算引擎。一次build的结果,我们称为一个Segment。构建过程中会涉及多个Cuboid的创建,具体创建过程由kylin.cube.algorithm参数决定,参数值可选 auto,layer 和 inmem, 默认值为 auto,即 Kylin 会通过采集数据动态地选择一个算法 (layer or inmem),如果用户很了解 Kylin 和自身的数据、集群,可以直接设置喜欢的算法。

    3. 执行查询,读取Cuboid,运行,产生查询结果

    2.3.1 逐层构建算法(layer)

    一个N维的Cube,是由1个N维子立方体、N个(N-1)维子立方体、N*(N-1)/2个(N-2)维子立方体、......、N个1维子立方体和1个0维子立方体构成,总共有2^N个子立方体组成,在逐层算法中,按维度数逐层减少来计算,每个层级的计算(除了第一层,它是从原始数据聚合而来),是基于它上一层级的结果来计算的。比如,[Group by A, B]的结果,可以基于[Group by A, B, C]的结果,通过去掉C后聚合得来的;这样可以减少重复计算;当 0维度Cuboid计算出来的时候,整个Cube的计算也就完成了。每一轮的计算都是一个MapReduce任务,且串行执行;一个N维的Cube,至少需要N次MapReduce Job。算法优点:

    1. 此算法充分利用了MapReduce的能力,处理了中间复杂的排序和洗牌工作,故而算法代码清晰简单,易于维护;

    2. 受益于Hadoop的日趋成熟,此算法对集群要求低,运行稳定;在内部维护Kylin的过程中,很少遇到在这几步出错的情况;即便是在Hadoop集群比较繁忙的时候,任务也能完成。算法缺点:

    3. 当Cube有比较多维度的时候,所需要的MapReduce任务也相应增加;由于Hadoop的任务调度需要耗费额外资源,特别是集群较庞大的时候,反复递交任务造成的额外开销会相当可观;

    4. 由于Mapper不做预聚合,此算法会对Hadoop MapReduce输出较多数据; 虽然已经使用了Combiner来减少从Mapper端到Reducer端的数据传输,所有数据依然需要通过Hadoop MapReduce来排序和组合才能被聚合,无形之中增加了集群的压力;

    5. 对HDFS的读写操作较多:由于每一层计算的输出会用做下一层计算的输入,这些Key-Value需要写到HDFS上;当所有计算都完成后,Kylin还需要额外的一轮任务将这些文件转成HBase的HFile格式,以导入到HBase中去;

    总体而言,该算法的效率较低,尤其是当Cube维度数较大的时候。

    2.3.2 快速构建算法(inmem)

    也被称作“逐段”(By Segment) 或“逐块”(By Split) 算法,从1.5.x开始引入该算法,利用Mapper端计算先完成大部分聚合,再将聚合后的结果交给Reducer,从而降低对网络瓶颈的压力。该算法的主要思想是,对Mapper所分配的数据块,将它计算成一个完整的小Cube 段(包含所有Cuboid);每个Mapper将计算完的Cube段输出给Reducer做合并,生成大Cube 与之前算法相比,快速算法主要有两点不同:

    1. Mapper会利用内存做预聚合,算出所有组合;Mapper输出的每个Key都是不同的,这样会减少输出到Hadoop MapReduce的数据量,Combiner也不再需要;

    2. 一轮MapReduce便会完成所有层次的计算,减少Hadoop任务的调配。

     2.4 Kylin总结

    Kylin的优点

    • 写SQL查询,结果预聚合.

    • 有可视化页面

    什么场景用Kylin

    • 查询数据后想要立马可视化的

    Kylin的缺点

    • 集群依赖较多,如HBase和Hive等,属于重量级方案,因此运维成本也较高。

    • 查询的维度组合数量需要提前确定好,不适合即席查询分析

    • 预计算量大,资源消耗多

    什么时候不可以用Kylin

    • 查询维度过多

    三、Impala

    3.1 什么是Impala

    Cloudera公司推出,提供对HDFS、Hbase数据的高性能、低延迟的交互式SQL查询功能。基于Hive,使用内存计算,兼顾数据仓库、具有实时、批处理、多并发等优点。是CDH平台首选的PB级大数据实时查询分析引擎。

    3.2 Impala为什么快

     查询引擎都会分为Frontend和Backend两部分,Frontend主要用于进行SQL的语法分析、词法分析、逻辑优化等,Backend则偏向底层做物理优化。

    3.2.1 Frontend

    Frontend主要负责解析编译SQL生成后端可以执行的查询计划。SQL的查询编译器是个标准的流程:SQL解析,语法分析,查询计划/优化。impala的查询分析器,会把标准的SQL解析成一个解析树,里面包含所有的查询信息,比如表、字段、表达式等等。一个可执行的执行计划通常包含两部分:单点的查询计划Single Node Planning 和 分布式并发查询计划 parallelization \ fragmentation。

    在第一个阶段,语法解析树会被翻译成一个单点的不可以直接执行的树形结构,一般会包含:HDFS\HBase scan, hash join, cross join, union, hash agg, sort, top-n, analytic eval等。这一步主要负责基于最下层的查询节点、谓词下推、限制查询数量、join优化等优化查询性能。主要是依赖于表或者分区的统计信息进行代价评估。

    第二个阶段就是基于第一个阶段优化后的单点执行计划,生成分布式的执行计划,并尽量满足最小化数据移动以及最大化数据本地性。分布式执行主要通过在节点间增加数据交换节点或者直接移动少量的数据在本地进行聚合。目前支持的join策略有broadcast和partition两种。前者是把join的整个表广播到各个节点;后者是基于hash重新分区,使得两部分数据到同一个节点。Impala通过衡量哪一种网络传输压力小,耗费的资源少,就选哪种.

    所有的聚合操作都是在本地进行预聚合,然后再通过网络传输做最终的聚合。对于分组聚合,会先基于分区表达式进行的预聚合,然后通过并行的网络传输在各个节点进行每一部分的聚合。对于非分组的聚合最后一步是在单独的节点上进行。排序和TOPN的模式差不多:都是现在单独的节点进行排序/topN,然后汇总到一个节点做最后的汇总。最后根据是否需要数据交换为边界,切分整个执行计划树,相同节点的执行计划组成一个fragment。

    3.2.2 Backend

    impala的backend接收到fragment后在本地执行,它的设计采取了很多硬件上的特点,backend底层是用C++编写,使用了很多运行时代码生成的技术,对比java来说减轻内存的压力。

    impala的查询设计思路也是按照volcano风格设计,处理的时候是getNext一批一批处理的。大部分的命令都是管道形式处理的,因此会消耗大量的数据存储中间数据。当执行的时候如果内存超出使用的范围,也可以把结果缓存到磁盘,经常有溢出可能的有如hash join, agg, sorting等操作。

    运行时代码生成:impala内部使用了LLVM的机制,性能提升5倍。LLVM是一套与编译器相关的的库,与传统的编译器不同,它更注重模块化与重用性。允许impala应用在运行时进行即时编译以及代码生成。运行时代码生成通常用于内部处理,比如用于解析文件格式的代码,对于扫描一些大表,这点尤为重要

    总结几点就是:

    1. 真正的MPP(大规模并行处理)查询引擎。

    2. 使用C++开发而不是Java,降低运行负荷。

    3. 运行时代码生成(LLVM IR),提高效率。

    4. 全新的执行引擎(不是Mapreduce)。

    5. 在执行SQL语句的时候,Impala不会把中间数据写入到磁盘,而是在内存中完成了所有的处理。

    6. 使用Impala的时候,查询任务会马上执行而不是生产Mapreduce任务,这会节约大量的初始化时间。

    7. Impala查询计划解析器使用更智能的算法在多节点上分布式执行各个查询步骤,同时避免了sorting和shuffle这两个非常耗时的阶段,这两个阶段往往是不需要的。

    8. Impala拥有HDFS上面各个data block的信息,当它处理查询的时候能够在各个datanode上面更均衡的分发查询。

    3.3 Impala总结

    Impala优点

    1. 基于内存运算,不需要把中间结果写入磁盘,省掉了大量的I/O开销。

    2. 无需转换为Mapreduce,直接访问存储在HDFS,HBase中的数据进行作业调度,速度快。

    3. 使用了支持Data locality的I/O调度机制,尽可能地将数据和计算分配在同一台机器上进行,减少了网络开销。

    4. 支持各种文件格式,如TEXTFILE 、SEQUENCEFILE 、RCFile、Parquet。

    5. 可以访问hive的metastore,对hive数据直接做数据分析。

    Impala缺点

    1. 对内存的依赖大,且完全依赖于hive。

    2. 实践中,分区超过1万,性能严重下降。

    3. 只能读取文本文件,而不能直接读取自定义二进制文件。每当新的记录/文件被添加到HDFS中的数据目录时,该表需要被刷新

    四、Presto

     4.1 什么是Presto

    Presto是一个facebook开源的分布式SQL查询引擎,适用于交互式分析查询,数据量支持GB到PB字节。presto的架构由关系型数据库的架构演化而来。presto之所以能在各个内存计算型数据库中脱颖而出,在于以下几点:

    • 清晰的架构,是一个能够独立运行的系统,不依赖于任何其他外部系统。例如调度,presto自身提供了对集群的监控,可以根据监控信息完成调度。

    • 简单的数据结构,列式存储,逻辑行,大部分数据都可以轻易的转化成presto所需要的这种数据结构。

    • 丰富的插件接口,完美对接外部存储系统,或者添加自定义的函数。

    4.2 Presto的执行过程

    Presto包含三类角色,coordinator,discovery,worker。coordinator负责query的解析和调度。discovery负责集群的心跳和角色管理。worker负责执行计算。

    1. presto-cli提交的查询,实际上是一个http POST请求。查询请求发送到coordinator后,经过词法解析和语法解析,生成抽象语法树,描述查询的执行。
    2. 执行计划编译器,会根据抽象语法树,层层展开,把语法树所表示的结构,转化成由单个操作所组成的树状的执行结构,称为逻辑执行计划。
    3. 原始的逻辑执行计划,直接表示用户所期望的操作,未必是性能最优的,在经过一系列性能优化和转写,以及分布式处理后,形成最终的逻辑执行计划。这时的逻辑执行计划,已经包含了map-reduce操作,以及跨机器传输中间计算结果操作。
    4. scheduler从数据的meta上获取数据的分布,构造split,配合逻辑执行计划,把对应的执行计划调度到对应的worker上。
    5. 在worker上,逻辑执行计划生成物理执行计划,根据逻辑执行计划,会生成执行的字节码,以及operator列表。operator交由执行驱动来完成计算。

    4.3 Presto总结

    优点

    1. Presto与Hive对比,都能够处理PB级别的海量数据分析,但Presto是基于内存运算,减少没必要的硬盘IO,所以更快。

    2. 能够连接多个数据源,跨数据源连表查,如从Hive查询大量网站访问记录,然后从Mysql中匹配出设备信息。

    3. 部署也比Hive简单,因为Hive是基于HDFS的,需要先部署HDFS。

    缺点

    1. 虽然能够处理PB级别的海量数据分析,但不是代表Presto把PB级别都放在内存中计算的。而是根据场景,如count,avg等聚合运算,是边读数据边计算,再清内存,再读数据再计算,这种耗的内存并不高。但是连表查,就可能产生大量的临时数据,因此速度会变慢,反而Hive此时会更擅长。

    2. 为了达到实时查询,可能会想到用它直连MySql来操作查询,这效率并不会提升,瓶颈依然在MySql,此时还引入网络瓶颈,所以会比原本直接操作数据库要慢。

    五、Druid

     5.1 Druid是什么

    Druid是一个专为大型数据集上的高性能切片和OLAP分析而设计的数据存储,druid提供低延时的数据插入,实时的数据查询。Druid最常用作为GUI分析应用程序提供动力的数据存储,或者用作需要快速聚合的高度并发API的后端。

    5.2 Druid的主要特点

    1. 列式存储格式 Druid使用面向列的存储,这意味着它只需要加载特定查询所需的精确列。这为仅查看几列的查询提供了巨大的速度提升。此外,每列都针对其特定数据类型进行了优化,支持快速扫描和聚合。

    2. 高可用性与高可拓展性 Druid采用分布式、SN(share-nothing)架构,管理类节点可配置HA,工作节点功能单一,不相互依赖,这些特性都使得Druid集群在管理、容错、灾备、扩容等方面变得十分简单。Druid通常部署在数十到数百台服务器的集群中,并且可以提供数百万条记录/秒的摄取率,保留数万亿条记录,以及亚秒级到几秒钟的查询延迟。

    3. 实时或批量摄取 实时流数据分析。区别于传统分析型数据库采用的批量导入数据进行分析的方式,Druid提供了实时流数据分析,采用LSM(Long structure-merge)-Tree结构使Druid拥有极高的实时写入性能;同时实现了实时数据在亚秒级内的可视化。

    4. 容错,恢复极好的架构,不会丢失数据 一旦Druid摄取了您的数据,副本就会安全地存储在深层存储(通常是云存储,HDFS或共享文件系统)中。即使每个Druid服务器都出现故障,您的数据也可以从深层存储中恢复。对于仅影响少数Druid服务器的更有限的故障,复制可确保在系统恢复时仍可进行查询。

    5. 亚秒级的OLAP查询分析 Druid采用了列式存储、倒排索引、位图索引等关键技术,能够在亚秒级别内完成海量数据的过滤、聚合以及多维分析等操作。

    6. Druid的核心是时间序列,把数据按照时间序列分批存储,十分适合用于对按时间进行统计分析的场景

    7. Druid支持水平扩展,查询节点越多、所支持的查询数据量越大、响应越快

    8. Druid支持低延时的数据插入,数据实时可查,不支持行级别的数据更新

     5.3 为什么快

    我们知道Druid能够同时提供对大数据集的实时摄入和高效复杂查询的性能,主要原因就是它独到的架构设计和基于Datasource与Segment的数据存储结构。

    • Druid在数据插入时按照时间序列将数据分为若干segment,支持低延时地按照时间序列上卷,所以按时间做聚合效率很高

    • Druid数据按列存储,每个维度列都建立索引,所以按列过滤取值效率很高

    • Druid用以查询的Broker和Historical支持多级缓存,每个segment启动一个线程并发执行查询,查询支持多Historical内部的线程级并发及Historical之间的进程间并发,Broker将各Historical的查询结果做合并

    5.4 Druid总结

    应用场景:

    • 需要交互式聚合和快速探究大量数据时;

    • 需要实时查询分析时;

    • 具有大量数据时,如每天数亿事件的新增、每天数10T数据的增加;

    • 对数据尤其是大数据进行实时分析时;

    • 需要一个高可用、高容错、高性能数据库时。

    六、即席查询总结

    1. Kylin:核心是Cube,Cube是一种预计算技术,基本思路是预先对数据作多维索引,查询时只扫描索引而不访问原始数据从而提速。

    2. Impala:基于内存计算,速度快,支持的数据源没有Presto多。

    3. Presto:它没有使用Mapreduce,大部分场景下比HIVE快一个数量级,其中的关键是所有的处理都在内存中完成。

    4. Druid:是一个实时处理时序数据的OLAP数据库,因为它的索引首先按照时间分片,查询的时候也是按照时间线去路由索引。

    参考:微信公众号(大数据左右手),文章名称:查询引擎怎么选?7000字解析所有开源引擎的秘密

    展开全文
  • Spinach:基于Spark SQL实现即席查询.pdf
  • 即席查询—Presto

    2021-05-19 13:44:23
    文章目录即席查询—Presto1 提高查询速度?2 定义3 架构4 优、缺5 命令行客户端6 可视化客户端7 优化7.1 数据存储7.2 SQL8 避坑 即席查询—Presto 1 提高查询速度? 1、基于内存:充分利用内存引入Presto 2、预计算...

    即席查询—Presto

    1 提高查询速度?

    1、基于内存:充分利用内存引入Presto

    2、预计算:查之前将可能查询的结果都计算出(提前计算出)kylin

    2 定义

    Presto是一个开源的分布式的SQL查询引擎,数据量支持GB到PB字节,主要用来处理秒级查询的场景。但是它并不是一个标准的数据库,只是用来解析SQL。

    3 架构

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Ok8abKt4-1621403043329)(../../AppData/Roaming/Typora/typora-user-images/image-20210519101232540.png)]

    各功能解释如下

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NKIQmmZU-1621403043332)(../../AppData/Roaming/Typora/typora-user-images/image-20210519101201000.png)]

    4 优、缺

    1、基于内存计算,减少磁盘IO

    2、支持多种数据源,可以进行跨数据源的连表查询,比如读取hive某表信息和mysql中进行表的关联匹配(主要的原因是因为presto有其统一的数据结构schema+table)

    缺点无非是效率和数量的不平衡,虽说presto可以处理PB级别的数据,但它并不是将这个数据放在内存中进行计算,而是根据场景进行调整,比如一些聚合(count、avg、sum、max等)的操作就会边读、边算、边清内存,然后再读再算,所以这种消耗内存不高,但是连表查会产生大量临时数据(主要就是多表联合得先生成一个最终需要查询的临时表,再进行查询操作),因而速度会慢;解决方案:可以先在hive里面提前进行多表关联成大宽表的操作,然后presto就可直接查询

    5 命令行客户端

    ./prestocli --server master:8881 --catalog hive --schema default

    它和hive查询不太一样,它不是全部出来,只会出现一部分,可以使用回车出现一行,空格进行换页,到最后结尾end的时候按q退出

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SJZ2Pk1c-1621403043333)(../../AppData/Roaming/Typora/typora-user-images/image-20210519113235897.png)]

    其实它中间查询是由一个通道,查多少拿多少,没有全部显示直接退出可能会报断开的管道错;如果不添加LZO的依赖,presto查询会出问题

    6 可视化客户端

    nohup bin/yanagishima-start.sh >y.log 2>&1 &
    在这里插入图片描述

    7 优化

    7.1 数据存储

    1、分区处理:合理化的设置分区,同hive类似;合理的分区可以减少它的数据读取量,提升查询的性能

    2、存储格式:对ORC文件进行特定的优化,相对于Parquet,对ORC更友好

    3、压缩格式:选择snappy优先,要求速度快

    7.2 SQL

    1、选择字段:选择需要的字段进行读取、减少数据量,少用*

    2、分区字段:能以分区作为过滤条件,尽量使用分区

    3、Group By:将group by语句中的字段按照每个字段的distinct数据多少进行降序排列

    4、Order By:如果需要使用order by进行全局排序查询TopN或者BottomN(倒数),使用limit可减少排序计算和内存的压力

    5、Join:①broadcast join大表join小表,presto中join的默认算法是broadcast join,采用的大表切分、小表广播,大表会被切分成每份送往worker,小表直接广播复制到worker中进行join;②hash join大表join大表,会根据要join的字段将两张表进行hash,hash相同的进入同一worker进行join

    8 避坑

    1、引用关键字:避免对关键字的冲突引用,MySQL对字段加反引号`,但在presto对字段是假双引号"",如果字段不是关键字可以不加

    2、时间函数:对于时间戳类型(timestamp)需要比较的时候,需要添加timestamp关键字

    /*MySQL的写法*/
    SELECT t FROM a WHERE t > '2017-01-01 00:00:00'; 
    
    /*Presto中的写法*/
    SELECT t FROM a WHERE t > timestamp '2017-01-01 00:00:00';
    

    3、不支持insert overwrite:persto中不支持insert overwrite语法,毕竟它是专门用来查询的,如果实在想插入数据,那只能先delete,然后insert into

    4、parquet存储格式:persto只支持parquet列式存储格式的查询,不支持插入

    展开全文
  • 即席查询Presto

    2022-02-22 14:47:24
    文章目录1.Presto简介1.1Presto概念1.2Presto架构1.3Presto优缺点2.Presto安装...查询SQL4.1只选择使用的字段4.2过滤条件必须加上分区字段4.3Group By语句优化4.4Order by使用Limit4.5使用Join语句时将大表放在左边5....

    1.Presto简介

    1.1Presto概念

    ​ Presto是一个开源的分布式SQL查询引擎,数据量支持GB到PB字节,主要用来处理秒级查询的场景

    注:虽然Presto可以解析SQL,但它不是一个标准的数据库。不是MySQL、Oracle的代替品,也不能用来处理在线事务(OLTP)

    1.2Presto架构

    Presto由一个Coordinator和多个Worker组成
    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Mwybw0ro-1645512439049)(C:\Users\Admin\AppData\Roaming\Typora\typora-user-images\image-20220217204211235.png)]

    1.3Presto优缺点

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zN1RtxUy-1645512439051)(C:\Users\Admin\AppData\Roaming\Typora\typora-user-images\image-20220217204517066.png)]

    优点:
    (1)Presto基于内存运算,减少硬盘IO,计算更快
    (2)能够连接多个数据源,跨数据源连表查看,如从Hive查询大量网站访问记录,然后从Mysql中匹配出设备信息
    
    缺点:
    Pressto能够处理PB级别的海量数据分析,但Presto并不是把PB级数据都存放在内存中计算的,而是根据场景。
    	Count,AVG等聚合运算,是边读数据边计算,再清内存,再读数据,再计算,这种耗的内存并不高。
    	连表查询,可能产生大量的临时数据,速度会变慢
    

    2.Presto安装

    2.1Presto Server安装

    1)官网地址

    https://prestodb.github.io/

    2)下载地址

    https://repo1.maven.org/maven2/com/facebook/presto/presto-server/0.208/presto-server-0.208.tar.gz

    3)解压到/opt/module

    tar -zxvf presto-server-0.208.tar.gz -C /opt/module/
    

    4)将文件更名为presto 并在presto目录下创建data,etc等文件夹

    mv presto-server-0.208/ presto
    ...
    cd presto
    mkdir data
    mkdir etc
    

    5)进入etc配置jvm.config

    vim jvm.config
    
    -server
    -Xmx16G
    -XX:+UseG1GC
    -XX:G1HeapRegionSize=32M
    -XX:+UseGCOverheadLimit
    -XX:+ExplicitGCInvokesConcurrent
    -XX:+HeapDumpOnOutOfMemoryError
    -XX:+ExitOnOutOfMemoryError
    

    6)配置catalog数据源

    在etc下创建catalog,进入catalog,此处我们可配置一个Hive的catalog

    vim hive.properties
    
    connector.name=hive-hadoop2
    hive.metastore.uri=thrift://hadoop102:9083
    

    7)将presto分发给hadoop103、hadoop104

    xsync /opt/module/presto
    

    8)修改hadoop102、hadoop103、hadoop104三台主机的/opt/module/presto/etc/node.properties

    使得三个的node.id各不相同

    9)Presto由一个coordinator节点和多个worker节点组成

    在hadoop102上配置coordinator

    etc目录下 vim config.properties
    
    coordinator=true
    node-scheduler.include-coordinator=false
    http-server.http.port=8881
    query.max-memory=50GB
    discovery-server.enabled=true
    discovery.uri=http://hadoop102:8881
    

    在hadoop103、hadoop104上配置worker

    etc目录下 vim config.properties
    
    coordinator=false
    http-server.http.port=8881
    query.max-memory=50GB
    discovery.uri=http://hadoop102:8881
    

    10)在hadoop102的/opt/module/hive目录下,启动Hive Metastore,用yingzi角色

    nohup bin/hive --service metastore >/dev/null 2>&1 &
    

    11)分别在hadoop102、hadoop103、hadoop104上启动Presto Server

    (1)前台启动Presto,控制台显示日志
    bin/launcher run
    
    (2)后台启动Presto
    bin/launcher start
    

    2.2Presto命令行Client安装

    1)下载Presto客户端

    https://repo1.maven.org/maven2/com/facebook/presto/presto-cli/0.208/presto-cli-0.208-executable.jar

    2)修改名称为prestocli,将文件移到presto目录下,并为其增加执行权限

    3)启动prestocli

    ./prestocli --server hadoop102:8881 --catalog hive --schema default
    

    4)Presto命令行操作

    Presto的命令行操作,相当于Hive命令行操作。每个表必须要加上schema

    select * from schema.table limit 100
    

    2.3Presto可视化Client安装

    1)上传unzip yanagishima-18.0.zip至/opt/module

    unzip unzip yanagishima-18.0.zip
    

    2)解压后进入conf文件夹,vim yanagishima.properties

    jetty.port=7080
    presto.datasources=yingzi-presto
    presto.coordinator.server.yingzi-presto=http://hadoop102:8881
    catalog.yingzi-presto=hive
    schema.yingzi-presto=default
    sql.query.engines=presto
    

    3)在/opt/module/yanagishima-18.0路径下启动yanagishima

    nohup bin/yanagishima-start.sh >y.log 2>&1 &
    

    4)启动web页面

    http://hadoop102:7080

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-eQwQJC8P-1645512439053)(C:\Users\Admin\AppData\Roaming\Typora\typora-user-images\image-20220218143533507.png)]

    3.Presto优化之数据存储

    3.1合理设置分区

    ​ 与Hive类似,Presto会根据元数据信息读取分区数据,合理的分区能减少Presto数据读取量,提升查询性能

    3.2使用列式存数

    ​ Presto对ORC文件读取做了特定优化,因此在Hive中创建Presto使用的表时,尽量使用ORC格式存储

    3.3使用压缩

    ​ 数据压缩可以减少节点见数据传输对IO带宽压力,对于即席查询需要快速解压,可采用Snappy压缩

    4.Persto优化之查询SQL

    4.1只选择使用的字段

    ​ 由于采用列式存储,选择需要的字段可加快字段的读取、减少数据量。避免采用*读取所有字段。

    4.2过滤条件必须加上分区字段

    ​ 对于有分区的表,where语句中优先使用分区字段进行过滤。

    4.3Group By语句优化

    ​ 合理安排Group by 语句中字段顺序对性能有一定提升。

    4.4Order by使用Limit

    ​ Order by需要扫码数据到单个worker节点进行排序,导致单个worker需要大量内存。如果是查询Top N或者Bottom N,使用Limit可减少排序计算和内存压力

    4.5使用Join语句时将大表放在左边

    ​ Presto中join的默认算法是broadcast join,即将join左边的表分割到多个worker,然后将join右边的表数据整个复制一份发生到每个worker进行计算。如果右边的表数据量太大,则可能会报内存溢出错误。

    5.注意事项

    5.1字段名引用

    ​ 避免和关键字冲突:MySQL对字段加反引号、Presto对字段加双引号分割。

    ​ 当然,如果字段名称不是关键字,可以不加这个双引号

    5.2时间函数

    ​ 对于Timestamp,需要进行比较的时候,需要添加Timestamp关键字,而MySQL中对Timestamp可以直接进行比较。

    /*MySQL的写法*/
    SELECT t FROM a WHERE t > '2017-01-01 00:00:00'; 
    
    /*Presto中的写法*/
    SELECT t FROM a WHERE t > timestamp '2017-01-01 00:00:00';
    

    5.3不支持INSERT OVERWRITE语法

    ​ Presto中不支持insert overwrite语法,只能先delete,然后insert into

    5.4PARQUET格式

    ​ Presto目前支持Parquet格式,支持查询,但不支持insert

    展开全文
  • 摘要:本文整理自360 政企安全集团的大数据工程师苏军以及刘佳在 Flink Forward Asia 2020 分享的议题《基于 Flink 的 PB 级数据即席查询实践》,文章内容为...
  • Baidu基于Spark SQL构建即席查询平台
  • 即席查询(Ad Hoc)入门(Kylin)

    千次阅读 2021-08-02 19:23:39
    目录1、什么是即席查询2、前置概念3、Kylin3.1 Kylin简介2.2 Kylin架构 1、什么是即席查询 即席查询(Ad Hoc)是用户根据自己的需求,灵活的选择查询条件,系统能够根据用户的选择生成相应的统计报表。 即席查询与...
  • Apache Kylin 是一个开源的分布式分析引擎,提供 Hadoop/Spark 之上的 SQL 查询接口 及多维分析(OLAP)能力以支持超大规模数据,最初由 eBay Inc 开发并贡献至开源社区。 它能在亚秒内查询巨大的 Hive 表。 Kylin ...
  • 即席查询Presto.md

    2021-10-24 10:23:50
    程序员,在校生,程序员行业爱好者
  • 在文章OLTP和OLAP,数据库和数据仓库中我们了解了OLAP和OLTP以及数据库数据仓库的区别,本文主要最大数据下的即席查询引擎presto进行介绍。 在OLAP中,查询通常分为固化查询和即席查询即席查询:通过手写sql完成...
  • 即席查询之presto

    2020-10-25 20:26:22
    即席查询之presto即席查询之presto简介架构优缺点性能presto安装使用docker安装(2个G谨慎安装)安装docker使用docker安装presto使用安装包安装安装presto Server安装presto client可视化安装presto优化数据存储查询...
  • 离线电商数仓3.0的即席查询笔记

    千次阅读 2022-03-27 20:46:01
    离线电商数仓3.0的即席查询笔记 kylin的简介与架构 Apache Kylin 是一个开源的分布式分析引擎,提供 Hadoop/Spark 之上的 SQL 查询接口及多维分析(OLAP)能力以支持超大规模数据,最初由 eBay Inc 开发并贡献至开源...
  • 什么是即席查询即席查询实现

    万次阅读 2019-03-29 18:54:37
    即席查询概念: 百度对即席查询的解释: 即席查询(Ad Hoc)是用户根据自己的需求,灵活的选择查询条件,系统能够根据用户的选择生成相应的统计报表。即席查询与普通应用查询最大的不同是普通的应用查询是定制开发的...
  • 使用clickhouse即席查询

    2021-08-11 17:21:19
    controller:面向外部请求,提供数据查询,返回对应格式的数据 service:组合和数据层,提供数据服务(接口+实现类) mapper:单表操作(接口 + xml操作(sql) ) 1. ...
  • 即席查询架构对比

    千次阅读 2019-11-20 16:15:46
    1.Druid:是一个实时处理时序数据的OLAP数据库,因为它的索引首先按照时间分片,查询的时候也是按照时间线去路由索引。 2.Kylin:核心是CUbe,Cube是一种预计算技术,基本思路是预先对数据作多维索引,查询时只扫描...
  • 大数据即席查询与分析

    万次阅读 2018-04-22 15:32:51
    即席查询与普通应用查询最大的不同是普通的应用查询是定制开发的,而即席查询是由用户自定义查询条件的。 在数据仓库领域有一个概念叫Ad hoc queries。通常的方式是,将数据仓库中的维度表和事实表映射到语义层,...
  • Spark-sql即席查询 Spark SQL Shark和Spark SQL Shark的出现,使得SQL-on-Hadoop的性能比Hive有了10-100倍的提高,但Shark的设计导致了两个问题: 一是执行计划优化完全依赖于Hive,不方便添加新的优化策略 二...
  • 然而即便使用即席查询也不代表着一劳永逸,在应用即席查询的业务场景中,往往会出现各种各样的问题导致性能缓慢。秉着「让数据能力平民化」的使命,关于即席查询能力的场景化难题,易观数科也有着自己的思考。 即席...
  • 即席查询之Presto

    2020-10-20 16:18:52
    分布式sql查询引擎 GB–PB 处理秒级查询的场景 注意:不是一个标准 的数据库,不是mysql的替代品,也不能处理在线事务(OLTP) 属于OLAP分析引擎: 1)客户端提交查询,从Presto命令行CLI提交到Coordinator 2)...
  • 即席查询目的很明确,就是要快,所提即所得,即提出来这个需求立马要看到结果,数仓传统的hive做即席查询那肯定是不行的,MR跑完数据估计天都黑了,所以也迫使新的框架要研发出来,这里例举出市面上常用的几款即席查询的...
  • Hive-之即席查询引擎选型 1 背景 为什么需要使用到即席查询的数据表,这个取决于数仓的上层应用于数仓的规模,通常如果需要给Hive的上层服务提供快速响应,那么即席查询是必不可少的数仓组件,常见的即席查询组件有...
  • Ad hoc queries(即席查询)

    2021-03-16 11:33:43
    即席查询与普通应用查询最大的不同是普通的应用查询是定制开发的,而即席查询是由用户自定义查询条件的。 浅析即席查询 在数据仓库领域有一个概念叫Ad hoc queries,中文一般翻译为“即席查询”。即席查询是指那些...
  • 推荐使用DBeaver 驱动设置: 之后就连接到hive,输入指令可查看Schemas 输入sql即可进行查询: 1.4 Presto的优势应用 Presto能够完成不能框架下的数据查询,例如进行mysql和hive的查询: 即席查询 Kylin Apache Kylin是一...
  • 数仓 即席查询 之 Persto

    千次阅读 2022-01-27 21:33:05
    文章目录Presto简介Presto概念Presto架构Presto优缺点Presto、Impala性能比较Presto安装Presto Server安装Presto命令行Client安装部署LZO说明Presto可视化Client安装Presto优化之查询SQL只选择使用的字段过滤条件...
  • Apache Kylin是一个开源的分布式分析引擎,提供Hadoop/Spark之上的SQL查询接口及多维分析(OLAP)能力以支持超大规模数据,最初由eBay Inc开发并贡献至开源社区。它能在亚秒内查询巨大的Hive表。 1.1.2 Kylin相关...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 7,533
精华内容 3,013
关键字:

即席查询

友情链接: 光伏气动载荷.zip