侵权投诉
订阅
纠错
加入自媒体

大数据多维分析引擎在魅族的实践

2017-01-24 15:00
魏丁小陆
关注

上图中的性能指标都是优化后的,前期刚上线的时候也是经历了多伦的痛苦优化。

先看看上面那个例子优化前的状态

优化前:

Cube原始记录 6亿---一个月数据

build后的Cube Size 1.9T

单次查询扫描一周数据,HBase频繁超时,Region Server经常被拖死,平均响应时间近30s

维度基本上全选,mandory、维度继承从来不用,结果如上。。Cube存储空间相比原始数据膨胀了700倍,Hbase region server一天挂N次,运维小哥苦不堪言。

优化后:

活用Aggregation Groups

将使用场景进行分组,对应不同的group

大基数维度创建单独的group,尽量确认需求,收缩条件组合范围,include中只包含相关的维度

低基数的维度可以单独建立一个group,加上必选条件维度,把低基数的维度都设置成Mandatory,这样维度组合出现时kylin会灵活进行内存内二次聚合,但因为这些维度基数都不大,对性能不会影响太多

二选一或多选一的条件维度不要包含在统一个group(比如崩溃时间和上传时间)

同时有好几个大基数group的话可以考虑每个group单独建一个cube(避免cube膨胀,row key结构也更合理)

kylin.query.mem.budget

Rowkey

有日期分区字段的,可以将日期转成只包含变化范围的数字:

比如原始格式是字符串的2016-07-15 12:31:25,只保留一个月的数据,同时查询是按天维度group by 不关心小时分钟可以把日期转成yyMMdd ,160715,这样可以极大的降低维度基数

基数小的维度在前面

低基数的维度尽量用dict编码(100w以内)

合理使用层级维度/派生维度

Kev1nZ:优化后效果

Cube build后大小降低到500G上下

50%的查询性能在2s以内

Cube build时间缩短30%

本来希望整理一些streaming cubing的实践和优化相关的内容,但是由于社区里的很多实践最近变化比较大,还不太稳定,以后等稳定过之后再有机会可以一并交流。

好了,我今天分享的内容就到这里,谢谢大家!

<上一页  1  2  3  4  5  
声明: 本文由入驻维科号的作者撰写,观点仅代表作者本人,不代表OFweek立场。如有侵权或其他问题,请联系举报。

发表评论

0条评论,0人参与

请输入评论内容...

请输入评论/评论长度6~500个字

您提交的评论过于频繁,请输入验证码继续

暂无评论

暂无评论

文章纠错
x
*文字标题:
*纠错内容:
联系邮箱:
*验 证 码:

粤公网安备 44030502002758号