saiku执行速度慢

使用saiku的过程中发现一个重要问题,速度慢!下面是跟踪和优化过程

一、首先抓包,发现ajax请求:http://l-tdata2.tkt.cn6.qunar.com:8080/saiku/rest/saiku/api/query/execute

里面的参数不少,下面是截屏

二、看日志:发现了mdx语句

WITH
SET [~ROWS_create_date_create_date] AS
    {[create_date].[create_date].[2016-04-12]}
SET [~ROWS_dimPartner_dimPartner] AS
    Hierarchize({{[dimPartner].[dimPartner].[All dimPartners]}, {[dimPartner].[dimPartner].[name].Members}})
SET [~ROWS_in_track_in_track] AS
    {[in_track].[in_track].[All in_tracks]}
SET [~ROWS_product_product] AS
    {[product].[product].[All products]}
SET [~ROWS_self_self] AS
    {[self].[self].[All selfs]}
SET [~ROWS_sight_sight] AS
    {[sight].[sight].[All sights]}
SET [~ROWS_ticket_type_ticket_type] AS
    {[ticket_type].[ticket_type].[All ticket_types]}
SET [~ROWS_order_status_order_status] AS
    {[order_status].[order_status].[All order_statuss]}
SET [~ROWS_refund_status_refund_status] AS
    {[refund_status].[refund_status].[All refund_statuss]}
SELECT
NON EMPTY {[Measures].[money], [Measures].[quantity], [Measures].[qunar_income], [Measures].[order_num]} ON COLUMNS,
NON EMPTY Order(NonEmptyCrossJoin([~ROWS_create_date_create_date], NonEmptyCrossJoin([~ROWS_dimPartner_dimPartner], NonEmptyCrossJoin([~ROWS_in_track_in_track], NonEmptyCrossJoin([~ROWS_product_product], NonEmptyCrossJoin([~ROWS_self_self], NonEmptyCrossJoin([~ROWS_sight_sight], NonEmptyCrossJoin([~ROWS_ticket_type_ticket_type], NonEmptyCrossJoin([~ROWS_order_status_order_status], [~ROWS_refund_status_refund_status])))))))), [Measures].[money], BDESC) ON ROWS
FROM [com_order_detail_cube]
2016-04-15 17:02:55,948 INFO  [org.saiku.datasources.connection.SaikuOlapConnection] Clearing cache
2016-04-15 17:03:26,603 WARN  [mondrian.rolap.RolapSchema] Model is in legacy format
2016-04-15 17:04:09,714 INFO  [org.saiku.datasources.connection.SaikuOlapConnection] Catalogs:1
2016-04-15 17:06:03,660 DEBUG [org.saiku.service.olap.ThinQueryService] Query End
2016-04-15 17:06:03,661 INFO  [org.saiku.service.olap.ThinQueryService] RUN#:84 Size: 14/7      Execute:        190420ms        Format: 0ms     Totals: 0ms      Total: 190420ms

观察日志,发现前端一直执行不返回。分析主要原因是执行mdx需要很长时间,190秒

3、找代码:org.saiku.web.rest.resources.Query2Resource的execute方法

继续追踪代码:org.saiku.service.olap.ThinQueryService的execute方法()。下面是核心重点:

    private CellDataSet execute(ThinQuery tq, ICellSetFormatter formatter) {
        try {

            Long start = (new Date()).getTime();
            log.debug("Query Start");
            CellSet cellSet =  executeInternalQuery(tq); //这是执行mdx语句的地方,需要较长时间
            log.debug("Query End");
            String runId = "RUN#:" + ID_GENERATOR.get();
            Long exec = (new Date()).getTime();

            CellDataSet result = OlapResultSetUtil.cellSet2Matrix(cellSet,formatter);
            Long format = (new Date()).getTime();

            if (ThinQuery.Type.QUERYMODEL.equals(tq.getType()) && formatter instanceof FlattenedCellSetFormatter && tq.hasAggregators()) {
                calculateTotals(tq, result, cellSet, formatter);
            }
            Long totals = (new Date()).getTime();
            log.info(runId + "\tSize: " + result.getWidth() + "/" + result.getHeight() + "\tExecute:\t" + (exec - start)
                    + "ms\tFormat:\t" + (format - exec) + "ms\tTotals:\t" + (totals - format) + "ms\t Total: " + (totals - start) + "ms");

            result.setRuntime(new Double(format - start).intValue());
            return result;
        } catch (Exception | Error e) {
            throw new SaikuServiceException("Can‘t execute query: " + tq.getName(),e);
        }
    }

4、查看数据执行的sql,看看为什么执行的很慢

4.1 选择情况

首先任何的筛选都是对立方体内的字段进行全表的扫描,比如我的立方体对应的数据表是:com_order_detail_view,时间对应的字段是create_date,那么选择时间的时候,捕获执行的sql如下:

 select "com_order_detail_view"."create_date" as "c0" from "com_order_detail_view" as "com_order_detail_view" group by "com_order
_detail_view"."create_date" order by "com_order_detail_view"."create_date" ASC NULLS LAST

发现根本没有where条件。好吧,这个可以理解!

4.2 执行情况

筛选的时候,为了提升效率,选择了一个日期,并且只是选择了name字段作为区分。执行时间:190s

抓取的sql如下:

4.2.1

select "dim_partner"."name" as "c0", sum("com_order_detail_view"."money") as "m0", sum("com_order_detail_view"."quantity") as "m1", sum("com_order_detail_view"."qunar_income") as "m2", count(distinct "com_order_detail_view"."display_id") as "m3" from "com_order_detail_view" as "com_order_detail_view", "dim_partner" as "dim_partner" where "com_order_detail_view"."partner" = "dim_partner"."code" group by "dim_partner"."name"

4.2.2

 select sum("com_order_detail_view"."money") as "m0", sum("com_order_detail_view"."quantity") as "m1", sum("com_order_detail_view"."qunar_income") as "m2", count(distinct "com_order_detail_view"."display_id") as "m3" from "com_order_detail_view" as "com_order_detail_view"

没有发现where条件。猜测可能是选择日期没有在过滤条件里面,所以全表扫描,那么将日期放入过滤条件,mdx被修改为:

WITH
SET [~FILTER] AS
    {[create_date].[create_date].[2016-04-01]}
SET [~ROWS_dimPartner_dimPartner] AS
    Hierarchize({{[dimPartner].[dimPartner].[All dimPartners]}, {[dimPartner].[dimPartner].[name].Members}})
SET [~ROWS_in_track_in_track] AS
    {[in_track].[in_track].[All in_tracks]}
SET [~ROWS_product_product] AS
    {[product].[product].[All products]}
SET [~ROWS_self_self] AS
    {[self].[self].[All selfs]}
SET [~ROWS_sight_sight] AS
    {[sight].[sight].[All sights]}
SET [~ROWS_ticket_type_ticket_type] AS
    {[ticket_type].[ticket_type].[All ticket_types]}
SET [~ROWS_order_status_order_status] AS
    {[order_status].[order_status].[All order_statuss]}
SET [~ROWS_refund_status_refund_status] AS
    {[refund_status].[refund_status].[All refund_statuss]}
SELECT
NON EMPTY {[Measures].[money], [Measures].[quantity], [Measures].[qunar_income], [Measures].[order_num]} ON COLUMNS,
NON EMPTY Order(NonEmptyCrossJoin([~ROWS_dimPartner_dimPartner], NonEmptyCrossJoin([~ROWS_in_track_in_track], NonEmptyCrossJoin([~ROWS_product_product], NonEmptyCrossJoin([~ROWS_self_self], NonEmptyCrossJoin([~ROWS_sight_sight], NonEmptyCrossJoin([~ROWS_ticket_type_ticket_type], NonEmptyCrossJoin([~ROWS_order_status_order_status], [~ROWS_refund_status_refund_status]))))))), [Measures].[money], BDESC) ON ROWS
FROM [com_order_detail_cube]
WHERE [~FILTER]
2016-04-15 17:13:02,448 DEBUG [org.saiku.service.olap.ThinQueryService] Query End
2016-04-15 17:13:02,449 INFO  [org.saiku.service.olap.ThinQueryService] RUN#:86 Size: 13/8      Execute:        20679ms Format: 1ms     Totals: 0ms      Total: 20680ms

发现有了效果,执行时间:20s。下面是抓取的sql

4.2.3

select "com_order_detail_view"."create_date" as "c0", "dim_partner"."name" as "c1", sum("com_order_detail_view"."money") as "m0", sum("com_order_detail_view"."quantity") as "m1", sum("com_order_detail_view"."qunar_income") as "m2", count(distinct "com_order_detail_view"."display_id") as "m3" from "com_order_detail_view" as "com_order_detail_view", "dim_partner" as "dim_partner" where "com_order_detail_view"."create_date" = DATE ‘2016-04-01‘ and "com_order_detail_view"."partner" = "dim_partner"."code" group by "com_order_detail_view"."create_date", "dim_partner"."name"

4.2.4

select "com_order_detail_view"."create_date" as "c0", sum("com_order_detail_view"."money") as "m0", sum("com_order_detail_view"."quantity") as "m1", sum("com_order_detail_view"."qunar_income") as "m2", count(distinct "com_order_detail_view"."display_id") as "m3" from "com_order_detail_view" as "com_order_detail_view" where "com_order_detail_view"."create_date" = DATE ‘2016-04-01‘ group by "com_order_detail_view"."create_date"

总结:使用saiku的时候,将时间条件放在《行》或者《列》里面,基本不起作用。最好放入在《过滤》里面

时间: 2024-10-13 02:32:17

saiku执行速度慢的相关文章

saiku执行速度优化二

上一篇文章介绍了添加filter可以加快查询速度.下面继续分析: 下面这个MDX语句: WITH SET [~FILTER] AS {[create_date].[create_date].[2013-01-01]} SET [~ROWS_dimPartner_dimPartner] AS {[dimPartner].[dimPartner].[name].Members} SET [~ROWS_sight_sight] AS Hierarchize({{[sight].[sight].[cou

【知识点整理】Oracle中NOLOGGING、APPEND、ARCHIVE和PARALLEL下,REDO、UNDO和执行速度的比较

[知识点整理]Oracle中NOLOGGING.APPEND.ARCHIVE和PARALLEL下,REDO.UNDO和执行速度的比较 1  BLOG文档结构图 2  前言部分 2.1  导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识,~O(∩_∩)O~: ① 系统和会话级别的REDO和UNDO量的查询 ② NOLOGGING.APPEND.ARCHIVE和PARALLEL下,REDO.UNDO和执行速度的比较(重点)   Tips: ① 本文

php array_shift与array_pop执行速度差距为啥这么大

闲话不说,上问题: 一个很大的php数组(1w+),使用array_shfit跟array_pop取数组元素时,性能差距特别大,array_shift慢的无法忍受,而array_pop就很快了. 先不说答案,看段代码: $arr = array(     0=>123,     3=>132,     2=>987, ); array_shift($arr); //array_pop($arr); var_dump($arr); 输出会有什么不同呢, array_shift后,输出为:

JavaScript代码优化(下载时间和执行速度优化)

JavaScript代码的速度被分成两部分:下载时间和执行速度. 下载时间 Web浏览器下载的是js源码,因此所有长变量名和注释都回包含在内.这个因素会增加下载时间.1160是一个TCP-IP包中的字节数.最好能将每个javascript文件都保持在1160字节以下以获得最优的下载时间.    由于这个原因,要删除注释.删除制表符和空格.删除所有的换行.将长变量名缩短. 遵循这4条比较困难.因此用外部程序(ECMAScript Cruncher)来帮助我们. 要运行ESC,必使用Windows系

优化SQL的执行速度

在项目开发中,页面的反应速度是非常重要的,改善页面反应速度的方法有很多. 但一般的问题多数是出现在数据库访问的SQL上面. 比如:重复多次访问数据库,SQL速度很低等. 重复多次访问数据库需要修改逻辑来减少数据库的访问.而SQL的执行速度可以通过仔细调试解决. 下面是一些SQL的性能调试方法.整理于网络内容. 1. IN和EXISTS --1.慢   SELECT  name   FROM    Personnel   WHERE   birthday IN (SELECT  birthday 

string和stringbuffer的执行速度

如果说直接比较两者的执行速度,是不客观的,它需要在特定的情况下才能做出优劣选择: 一. 1 String str1="abc"; 2 String str2="de"; 3 String str=str1+str2 StringBuilder stringBuilder=new StringBuilder().append("abc").append("de"); 此种情况,stringbuffer更快 二. String s

查看Sql语句执行速度

原文链接:http://www.cnblogs.com/New-world/archive/2012/11/28/2793560.htmlMS_SQL模糊查询like和charindex的对比 like查询效率低下,网上搜了一下替代like查询的方法,都是说用charindex方法,自己对比了一下查询速度 test1表中有一千两百多万条数据,我只给ID加了索引 先看一下 '%我%'这种模糊查询: declare @q datetime set @q = getdate() select ID,U

关于加快INSERT语句执行速度和HINT /*+ append */及/*+ append nologging */的使用

(非归档模式下)创建表T01: SQL> create table t01 as select * from dba_objects where 1=2; Table created. (非归档模式下)查看当前redo大小: SQL> select value 2 from v$mystat,v$statname 3 where v$mystat.statistic#=v$statname.statistic# 4 and v$statname.name='redo size' 5 / VAL

写好循环也不容易--8种遍历方法执行速度深度°对比

关于数组或对象遍历,相信很多人都没有深入观察过执行效率.这是一个曾在群里吵翻天的话题,读懂后你将成为遍历效率话题的大师. 导读 遍历数组或对象是一名程序员的基本素养之一. 然而遍历却不是一件简单的事, 优秀的程序员知道怎么去选择合适的遍历方法, 优化遍历效率. 本篇将带你走进JavaScript遍历的世界, 享受分析JS循环的快感. 本篇所有代码都可以直接运行, 希望您通读本篇后, 不止是浏览, 最好是亲手去实践下. 概述 js有如下两种数据需要经常遍历 数组(Array) 对象(Object)