首先我们来看一下整体结构图:

hdfs.png

日志收集入口

首先,我们需要到各个应用服务器上部署flume进行日志采集,当然也可以通过flume支持的source协议或者自定义source进行日志原始数据收集,统一流入flume汇总收集入口。

这里通常采用日志服务器上部署flume,然后通过hadoop的arvo协议进行传输。如下图所示:

flume收集图.png

日志汇总

将各个节点日志原始信息统一汇总到一个flume节点,然后通过该节点进行数据传输,这样便于统一管理。如果怕单点故障或者压力太大,可以进行主备方式解决单点问题,也可以按照业务划分进行多台服务器汇总。

日志传输

这里数据流传输使用的是kafka。因为flume和storm已经对kafka进行了原生支持,不用进行编程,只需要简单配置就可以实现我们想要的功能。kafka可以实现发布订阅功能,也有简单的存储功能,而且性能相当不错。

kafka支持集群部署,需要连接zookeeper。这里需要注意的是,如果多个组件公用一个zookeeper,需要规划好各自的zookeeper路径,不能使用根目录存储。

数据分析

大数据实时分析框架storm已经很流行了,他可以订阅kafka数据,进行一系列的数据分析,处理,存储。如果我们需要一些实时数据展示,我们可以通过storm将数据格式化后,存储到mysql或者redis上,应用进行读取。如果我们还需要进一步进行统计,如日报表,整体行为分析。我们可以将格式化后的数据统一存入hdfs中,后续进行分析处理。

这里要说明的是hdfs本身就有mapreduce可以进行数据格式化,处理,分析功能。为什么这里要用这套架构传输呢?为什么不用flume直接传输到hdfs分析呢?首先,这套架构可以利用storm进行数据采集,格式化,再存储到hdfs,这样我们存储到hdfs上的都是格式化后的有效数据,一方面可以减少hdfs存储数据量,另一方便hdfs存储的都是有效数据,应用可以直接读取展示。其实这里hdfs所做的工作就是一个存储而不需要进行mapreduce编程。

当然我们也可以flume直接传输到hdfs分析,但是这样我们就需要维护storm和mapreduce两套编程代码,而且会存在大量重复的格式化代码,不便于项目维护。可能有一些工作必须需要mapreduce完成,但是现在hdfs上的数据都是格式化好的,这样也避免了重复的格式化代码,mapreduce只需要关系业务代码就可以了。


以上纯属个人使用上的理解,欢迎大家提出问题,以及反馈。


转载请注明作者,出处。




没有登录不能评论