当前位置:技术分享 > 技术参考 > 正文

驱动海量大数据实时多维分析,优酷为什么会选择Druid?2016-08-09 13:55:00 | 编辑:hely | 查看: | 评论:0

今天分享的话题是Druid驱动大数据实时OLAP。首先我来谈一下实时OLAP的需求背景,我们广告系统有DSP睿视系统和AD exchange等,实时竞价是DSP的核心,广告主或者优化师需要动态调整出价优化使收益最大化。

需求背景

我今天分享的话题是Druid驱动大数据实时OLAP。

首先我来谈一下实时OLAP的需求背景,我们广告系统有DSP睿视系统和AD exchange等,实时竞价是DSP的核心,广告主或者优化师需要动态调整出价优化使收益最大化。广告主调整出价策略或者投放策略进行优化,想要尽快得到实时的反馈,比如修改了地域定投,实时分地域查看竞得率和转化率,甚至是分钟粒度的。

在我们的DSP系统中我们提供12种维度(不算多)的多维分析,用户可以任意组合下钻查询。最初的时候我并不是采用Druid,而是采用Storm+Kafka+Redis实时数据处理,以及hive+mysql的离线处理的Lambda架构见下图。

 

 

实时数据经过Storm ETL,主要是将不同维度组合作为key,计算metrics以后为value存在redis中。离线数据定时将昨天的数据在Hive中 经过一系列ETL,按照维度组合计算metrics以后将结果存储在mysql中。采用redis作为实时数据的存储有两个核心问题需要解决:

1、redis不支持range scan,我们需要在app层拼好所有的key,然后调用mget获取,如果执行group by查询的话例如select area,pv from t where cast='a' group by area的话,需在客户端好所有的cast_area的key。那么问题来了,我并不知道投放a在哪些城市 产生过曝光,如果有地域定向还好,如果没有的话需要拼接所有城市的key取redis中进行mget。哪这样只是城市维度还好,全国也只有几百个城市,但如果换做其他基数很大的维度,哪性能开销就比较大了。

2、如果做到真正的多维分析,需要穷举1维,2维知道N维维度的所有组合,例如有A B C和D,那么一维的组合有A B C D,二维的有 AB BC CD DA等组合,依次类推直到组合到N维。同时每种维度又有自己的基数,例如ABCD各自的基数都是100,最差的情况, 今ABCD这种组合就会有1亿个key,但现实数据一般都是稀疏,不会出现这种的情况。总之穷举维度组合作为key的方式存储空间 会非常大,特别是添加维度以后,有可能是指数级的增长,非常不可控。

为了规避这个问题,我们对功能进行了降级,我们提供某些维度组合的查询,这样就做到了简单可控。但需要历史和实时结合查询的场景,问题就又来了,我需要将mysql的数据和redis的数据整合起来。只能在app端进行数据合并。就这样这个系统愉快地高效运转了一段时间。

4月份的时候我参加Qcon和Druid中国用户组的Meetup,听Druid项目发起人Fangjin Yang将Druid的昨天今天和明天,6年前他们在 metamarkets创业公司,主要为广告公司提供多维数据分析,尝试过很多方案,例如传统的关系型数据mysql/postgresql,kv存储的 Hbase,Hbase受限于rowkey设计,都不能很好地解决多维分析,随后创建Druid。我相信很多公司都有类似的经历。说了这么多终于引入正题。

上一篇:七夕节放送:如何利用数据分析找到女朋友? 盘点最受欢迎的十个开源大数据技术下一篇: