在第二轮迭代完成后,第三轮迭代中,我们就开始做平台的数据分析了,这里我们以工作台数据分析为例,讲解平台如何采用大数据的方式来进行数据分析。

工作台中,需要做数据分析,比如平台合成出来的banner图被用户的点击次数,banner图合成出来后,被用户下载的数据,工作台中的PV/UV情况等。

在此轮设计中,我们直接用的大数据解决方案,并没有在一开始使用关系型数据来做这样的数据分析统计,架构方案如下,我们选用了Druid来做数据存储,以OLAP的方式来做数据分析,Druid.io(以下简称Druid)是面向海量数据的、用于实时查询与分析的OLAP存储系统。Druid的四大关键特性总结如下:

1)、亚秒级的OLAP查询分析,Druid采用了列式存储、倒排索引、位图索引等关键技术,能够在亚秒级别内完成海量数据的过滤、聚合以及多维分析等操作。

2)、实时流数据分析,区别于传统分析型数据库采用的批量导入数据进行分析的方式,Druid提供了实时流数据分析,采用LSM(Long structure merge)-Tree结构使Druid拥有极高的实时写入性能;同时实现了实时数据在亚秒级内的可视化。

3)、丰富的数据分析功能。针对不同用户群体,Druid提供了友好的可视化界面、类SQL查询语言以及REST 查询接口

4)、高可用性与高可拓展性。Druid采用分布式、SN(share-nothing)架构,管理类节点可配置HA,工作节点功能单一,不相互依赖,这些特性都使得Druid集群在管理、容错、灾备、扩容等方面变得十分简单。

关于druid的介绍,可以参考https://www.jianshu.com/p/0a614455a964 这篇文章。

1、 在页面中,我们用采集插件做了数据埋点采集,数据采集通过数据采集服务丢入到kafka中。

2、 我们在druid中设计了两张表,数据的粒度精确到分钟时间段,也就是有分钟表和小时表两张。分钟表数据量可能会比较大,所以我们只会保留1个月内的分钟表数据,小时表的数据会长期保存。

3、 在kafka中,我们创建了两个消费组,一个用于小时消费处理,一个用于分钟消费处理。

4、 在平台设计时,每张banner图都有一个唯一的bannerId和url,在数据聚合处理操作时,bannerId 就成了唯一的标志,按照bannerId进行分钟级的聚合处理和小时级的聚合处理。

5、 小时级的聚合处理也可以考虑使用hive,处理的方案如下,由于分钟表的数据会保存1个月,所以1个月内的查询其实都是直接查询分钟表,1个月以外的数据才会查询小时表。所以尽管此种方案可能会存在数据采集延迟的情况,但是也不会延迟1个月之久,所以可以通过定时任务来处理,定时任务可以在第二天处理前一天的数据。

6、 数据报表在查询时,就可以按照1个月以内查询分钟表,1个月以外的查询小时表。

上面讲的工作台中数据分析的场景,另外我们还有接口合成banner图的数据也是需要分析。在第二轮迭代时,接口请求合成的banner图的结果数据我们同时入了hbase和mysql两张表,上文中已经说过入hbase中的数据是供用户做接口合成结果查询的。入mysql中当时是准备用作数据分析的(因为第二轮时,调用量还不够大,所以那个时候还未采用大数据方案),如下图

在第三轮的接口迭代中,我们将架构进行了优化,以适应每天千万级的接口合成调用,不然mysql数据库会成为最终的瓶颈,如下图

我们将入mysql的那份数据改成写到kafka中,然后kafka的数据可以做实时分析,也可以将kafka的数据进入到hive中做离线分析。

未完待续