Day4那晚之后,能跑起来了,但是结果卡在67%就fail了,timeout,本以为又是没空间的问题,期间不断麻烦师兄而师兄基本也被用坏了(一会儿系统盘满了,一会儿重启MySQL,一会SSH -X又不好使了,因为师兄自己开了代理所以影响了我),不仅清理了master的空间,还让我把数据放到另一个内存3T容量几十T的大MySQL上跑,于是创建我的用户、授权(远程访问)、建库建表导数据再来一遍,却发现在MySQL上直接跑SQL都很慢很慢,原因要么是由于数据量大天生就慢,要么就是生成了和数据量成正比的中间文件吃掉了空间,于是我baidu了两点,一个是Linux系统盘满了,一个是SQL运行产生中间文件,前者原因太多了,感觉对驴唇不对马嘴,后者似乎看了一些感觉上也不是这个问题。
但是有一个现象我一直是知道的,但是没重点查过,那就是这条SQL第一次或者很偶尔是能跑出来的并且时间运行得也很正常,这个现象我在前面的文章应该描述过,所以我曾经以为结果已经跑通了,可是根据描述后来越来越慢,在集群上Mapreduce的时候就卡在map67%或者11%了,然后再用MySQL直接查询也查不出结果来最后只能中止掉,以前放在master的小MySQL上说可能是容量问题就算了,已经换到大内存大容量的MySQL还这样,那就不是空间小导致的慢了,所以只剩下一个可能!就是SQL语句的问题!(我一直想过SQL有优化的余地,但是SQL优化有点太专业了,一时也找不到感觉啊)所以本着从现象入手的原则,我就baidu一下“SQL时好时坏”,居然同问的还不少,其中http://bbs.csdn.net/topics/360176808 这个帖子底下给了很多方向,打算从头试一试,第一个是存储过程,我觉得存储过程就是存储“过程”,可能SQL太长了,就存在MySQL里,用户提供参数就可以了,可以减少网络消耗,我的SQL又不长,用不着,那么下一个。下一个,读到“如果是我,我就让sql语句执行尽可能简单的功能,把判断啥的放在程序里去执行,要不然总是这样,数据库受不了啊”这句,我决定拆SQL,我的SQL有一个join,join的是一个子查询,我把子查询拿出来单跑了一下,很慢,中止掉,只有一种可能!就是数据量太大就慢,我一直想试试select出所有数据的,但是数据太多之前在master上已经吃掉很多空间了,就没敢试,这次顾忌倒是不大,就试了一下,果然同样很慢,但是呢,select+limit 10 这种就很快,那就说明尽管数据集本身很大但是查出结果是小范围的数据也快,于是在那条子查询的后面加上了where条件(放在group by之前哦~)限制一个小范围,果然很快就出结果了,其实我要的就是大数据集上的小范围内的结果,但是这个范围我只加在了外部SQL上,没给内部嵌套的子查询也加上,所以是子查询由于没加范围限制而scan了整个数据集!改完之后重新做了下实验,分布式比查询一整条SQL快了一倍!效果可以说是非常明显了。
这就是最根本的问题啦,一切~就都顺畅了~
再跑起来的时候我竟然有自信它绝对不可能卡在那(毕竟之前总卡,我都习惯了,还是会担心~),流畅~于是一鼓作气把echarts也连起来了试了一下,就这么简单期间还丢三落四地忘记添加某些返回值导致图形没出来呢…
所以现在整个系统的框架已经很明朗了~和我之前设想的一样,每个算法单独有一个jar,springboot那我可以直接调用jar,这样扩展性可以说是非常好了~唯一要保证的就是主类在springboot项目里的包名加类名必须和算法工程里的包名加类名完全一致,否则会ClassNotFound,而算法改逻辑在算法工程里改就行,springboot里不需要。但是,job毕竟是在springboot里启动的,所以像是检测output path if exists这个问题(如果exists则delete掉)要写在springboot的main里,而且标准输出放在springboot里也是能在后台看见的,所以像统计Job运行时间也放在springboot的main里。
我的系统整个框架就明朗了~扩展性非常好~算法可以单独拿出来研发,你说好不好!
第一个算法目前还有两个UI问题,一是定义接口,二是时间序列中时间的格式。像是系统最后的运行环境之类的,也许可以想想其它更通用的解决方案~
目前的最高优先级:实现第二个分布式算法。