大数据采集、清洗、处理：使用MapReduce进行离线数据分析完整案例

2023-11-07

1 大数据处理的常用方法

大数据处理目前比较流行的是两种方法，一种是离线处理，一种是在线处理，基本处理架构如下：

在互联网应用中，不管是哪一种处理方式，其基本的数据来源都是日志数据，例如对于web应用来说，则可能是用户的访问日志、用户的点击日志等。

如果对于数据的分析结果在时间上有比较严格的要求，则可以采用在线处理的方式来对数据进行分析，如使用Spark、Storm等进行处理。比较贴切的一个例子是天猫双十一的成交额，在其展板上，我们看到交易额是实时动态进行更新的，对于这种情况，则需要采用在线处理。

当然，如果只是希望得到数据的分析结果，对处理的时间要求不严格，就可以采用离线处理的方式，比如我们可以先将日志数据采集到HDFS中，之后再进一步使用MapReduce、Hive等来对数据进行分析，这也是可行的。

本文主要分享对某个电商网站产生的用户访问日志（access.log）进行离线处理与分析的过程，基于MapReduce的处理方式，最后会统计出某一天不同省份访问该网站的uv与pv。

欢迎交流问题，可加我个人QQ 630892562，一起探讨交流问题

或者加我的群号 710219868 邀请码 : 南风（必填）有大神有资源一起交流学习，共同进步

2 生产场景与需求

在我们的场景中，Web应用的部署是如下的架构：

即比较典型的Nginx负载均衡+KeepAlive高可用集群架构，在每台Web服务器上，都会产生用户的访问日志，业务需求方给出的日志格式如下：

1001    211.167.248.22  eecf0780-2578-4d77-a8d6-e2225e8b9169    40604   1       GET /top HTTP/1.0       408     null      null    1523188122767
1003    222.68.207.11   eecf0780-2578-4d77-a8d6-e2225e8b9169    20202   1       GET /tologin HTTP/1.1   504     null      Mozilla/5.0 (Windows; U; Windows NT 5.1)Gecko/20070309 Firefox/2.0.0.3  1523188123267
1001    61.53.137.50    c3966af9-8a43-4bda-b58c-c11525ca367b    0       1       GET /update/pass HTTP/1.0       302       null    null    1523188123768
1000    221.195.40.145  1aa3b538-2f55-4cd7-9f46-6364fdd1e487    0       0       GET /user/add HTTP/1.1  200     null      Mozilla/4.0 (compatible; MSIE 7.0; Windows NT5.2)       1523188124269
1000    121.11.87.171   8b0ea90a-77a5-4034-99ed-403c800263dd    20202   1       GET /top HTTP/1.0       408     null      Mozilla/5.0 (Windows; U; Windows NT 5.1)Gecko/20070803 Firefox/1.5.0.12 1523188120263

其每个字段的说明如下：

appid ip mid userid login_type request status http_referer user_agent time
其中：
appid包括：web:1000,android:1001,ios:1002,ipad:1003
mid:唯一的id此id第一次会种在浏览器的cookie里。如果存在则不再种。作为浏览器唯一标示。移动端或者pad直接取机器码。
login_type：登录状态，0未登录、1：登录用户
request：类似于此种 "GET /userList HTTP/1.1"
status：请求的状态主要有：200 ok、404 not found、408 Request Timeout、500 Internal Server Error、504 Gateway Timeout等
http_referer：请求该url的上一个url地址。
user_agent：浏览器的信息，例如："Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36"
time：时间的long格式：1451451433818。

根据给定的时间范围内的日志数据，现在业务方有如下需求：

统计出每个省每日访问的PV、UV。

3 数据采集：获取原生数据

数据采集工作由运维人员来完成，对于用户访问日志的采集，使用的是Flume，并且会将采集的数据保存到HDFS中，其架构如下：

可以看到，不同的Web Server上都会部署一个Agent用于该Server上日志数据的采集，之后，不同Web Server的Flume Agent采集的日志数据会下沉到另外一个被称为Flume Consolidation Agent（聚合Agent）的Flume Agent上，该Flume Agent的数据落地方式为输出到HDFS。

在我们的HDFS中，可以查看到其采集的日志：

4 数据清洗：将不规整数据转化为规整数据

4.1 数据清洗目的

刚刚采集到HDFS中的原生数据，我们也称为不规整数据，即目前来说，该数据的格式还无法满足我们对数据处理的基本要求，需要对其进行预处理，转化为我们后面工作所需要的较为规整的数据，所以这里的数据清洗，其实指的就是对数据进行基本的预处理，以方便我们后面的统计分析，所以这一步并不是必须的，需要根据不同的业务需求来进行取舍，只是在我们的场景中需要对数据进行一定的处理。

4.2 数据清洗方案

原来的日志数据格式是如下的：

appid ip mid userid login_type request status http_referer user_agent time
其中：
appid包括：web:1000,android:1001,ios:1002,ipad:1003
mid:唯一的id此id第一次会种在浏览器的cookie里。如果存在则不再种。作为浏览器唯一标示。移动端或者pad直接取机器码。
login_type：登录状态，0未登录、1：登录用户
request：类似于此种 "GET /userList HTTP/1.1"
status：请求的状态主要有：200 ok、404 not found、408 Request Timeout、500 Internal Server Error、504 Gateway Timeout等
http_referer：请求该url的上一个url地址。
user_agent：浏览器的信息，例如："Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36"
time：时间的long格式：1451451433818。

但是如果需要按照省份来统计uv、pv，其所包含的信息还不够，我们需要对这些数据做一定的预处理，比如需要，对于其中包含的IP信息，我们需要将其对应的IP信息解析出来；为了方便我们的其它统计，我们也可以将其request信息解析为method、 request_url、 http_version等，

所以按照上面的分析，我们希望预处理之后的日志数据包含如下的数据字段：

appid;  
ip;
//通过ip来衍生出来的字段 province和city
province;
city;

mid;      
userId;    
loginType; 
request; 
//通过request 衍生出来的字段 method request_url http_version
method;
requestUrl;
httpVersion;

status;          
httpReferer; 
userAgent;   
//通过userAgent衍生出来的字段，即用户的浏览器信息
browser;

time;

即在原来的基础上，我们增加了其它新的字段，如province、city等。

我们采用MapReduce来对数据进行预处理，预处理之后的结果，我们也是保存到HDFS中，即采用如下的架构：

本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)