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

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

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

Kylin从1.5早期的版本中就开始实验一种Streaming Cubing的方式,当时的实现方式无愧于实验feature的称号,我们也简单测试过,日常运维各种问题,mini-batch进程crash、数据丢失、一但crash基本上就得重头来过,数据不可能恢复,所以那时的streaming cubing还不是一个线上可用的状态。

虽然看起来可以提高cube的构建效率,大幅度提升数据的实时性,但是由于设计的不合理那时候还不能在生产中使用

最近在1.6中终于有一个看上去很美的streaming cubing实现了。新版用一个MR任务去跑每一个kafka分区,把kafka中的数据写入HDFS,之后就可以和从hive中build一样使用通用kylin cube building过程了

这样做有以下几个好处

允许多个segment(一个segment就是hbase中存储cube数据的一个片段)并发build

允许segment之间出现时间窗口重叠(很重要)

其他不那么新的新特性

支持精确的distinct计数(所有数据类型)---1.5.3

支持针对不同的Project设置不同的MR job运行队列---1.5.3

Top N指标支持多列group by ---1.5.3

主动监测OOM,将堆栈中的cuboid缓存到本地磁盘---1.5

查询明细数据(RAW MEASURE)---1.5.2

支持Hive视图作为lookup 表---1.5.2

综上,如果大家想要在生产环境中使用kylin的话,推荐大家尝试1.5以上的版本。

Why Kylin?

刚才聊的都是kylin的功能特性和设计,接下来看看我们为什么要选择kylin,或者说kylin适合什么样的场景?

1、平台体系完善,成熟度高,部署简单,易用

2、在高并发访问下保持不错的性能,随着数据量和维度组合的增长,性能衰减也不会特别明显

3、Cube模型的合理设计,可以减少人工配置 ETLjob的数量

4、可以在数据准确度、存储空间、性能之间灵活调整,找到最适合需求场景的平衡点

5、标准SQL语法+JDBC/ODBC驱动可以很方便的和现有系统做集成

7、社区活跃,有Kyligence这样的商业公司在背后推动

8、支持准实时的数据更新,未来有准实时OLAP需求也可以复用kylin

9、底层基于已经相对成熟的Hive、HBase,整体技术栈并不复杂,日常运维成本低

hobo文库本下面是Kylin的架构图应用场景特征

我们总结了一下日常接入kylin的需求需要满足的基本特征,这些描述都是基于我们自身的技术体系和需求的特点而决定的,仅供大家参考,并不是一定要这样

I. 数据量大,同时对查询性能有需求

数据量不大直接用mysql好了,对查询性能没有要求的可以用其他的诸如impala或者spark都可以

II. 数据实时性要求不高(目前最高到小时级更新)

只针对于非实时的cubing,Streaming cubing目前还在研究中,方案成熟后可以很大程度上提高实时性

III. 维度组合和查询条件组合在可预见的范围内

由于Cube模型需要预先构建,因此维度的组合和条件必须是可预见的,如果用户传入的维度building时没有包含,自然是查询报错了。对于查询自由度过高的场景还是推荐用hive、spark或者impala

IV. 数据总量大,但条件扫描范围不会太大的。

不适合需要大范围模糊搜索排序的场景(类似search),这类场景自然是ES这类搜索引擎的强项,kylin并不擅长。

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

发表评论

0条评论,0人参与

请输入评论内容...

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

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

暂无评论

暂无评论

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

粤公网安备 44030502002758号