Python + 大数据 – 数仓实战之智能电商分析平台

Python + 大数据 – 数仓实战之智能电商分析平台

1. 项目架构

2. 数据仓库维度模型设计-事实表

  事实表的特征：表里没有存放实际的内容，他是一堆主键的集合，这些ID分别能对应到维度表中的一条记录。事实表包含了与各维度表相关联的外键，可与维度表关联。事实表的度量通常是数值类型，且记录数会不断增加，表数据规模迅速增长。

2.1 事务型事实表

  事实表用来存储有事实记录的表，如系统日志、销售记录等；事实表的记录在不断地动态增长，所以它的体积通常远大于其他表；事实表可以分为事务型事实表和周期型事实表。

2.2 周期型事实表

  周期型事实表，一般指随着业务发生不断产生的数据。与事务型不同的是，数据会随着业务周期性的推进而变化。比如订单，其中订单状态会周期性变化。再比如，请假、贷款申请，随着批复状态在周期性变化。

3.数据仓库维度模型设计-维度表

  维度表示你要对数据进行分析时所用的一个量, 比如你要分析产品销售情况, 你可以选择按类别来进行分析,或按区域来分析. 这样的 “按..分析“ 就构成一个维度。
对于物体属性描述的表，例如商品信息表，城市信息表，时间维度表等。

3.1 星型模型

一个事实表，维度表之间没有关联

星型模式的维度建模由一个事实表和一组维表成，且具有以下特点：
a. 维表只和事实表关联，维表之间没有关联；
b. 每个维表主键为单列，且该主键放置在事实表中，
   作为两边连接的外键；
c. 以事实表为核心，维表围绕核心呈星形分布；

3.2 雪花模型

一个事实表，维度表之间有关联联系
 
 雪花模式(Snowflake Schema)是对星型模式的扩展，每个维表可继续向外连接多个子维表。下图为使用雪花模式进行维度建模的关系结构：
  星形模式中的维表相对雪花模式来说要大，而且不满足规范化设计。
雪花模型相当于将星形模式的大维表拆分成小维表，满足了规范化设计。然而这种模式在实际应用中很少见，因为这样做会导致开发难度增大，而数据冗余问题在数据仓库里并不严重。

3.3 星座模型

 多个事实表，维度之间有关联关系
 
 前面介绍的两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。

4.缓慢变化维-拉链表

  缓慢变化维的提出是因为在现实世界中，维度的属性并不是静态的，它会随着时间的流失发生缓慢的变化。这种随时间发生变化的维度我们一般称之为缓慢变化维，并且把处理维度表的历史变化信息的问题称为处理缓慢变化维的问题，有时也简称为处理SCD的问题。

数据仓库的数据模型设计过程中，经常会遇到这样的需求：
 1、表中的部分字段会被update，例如：用户的地址，订单的状态等等;
 2、需要查看某一个时间点或者时间段的历史快照信息，例如：
查看某一个产品在历史某一时间点的状态
查看某一个用户在过去某一段时间内，更新过几次等等
3、变化的比例和频率不是很大，例如：总共有1000万的会员，每天新增和发生变化的有10万左右
4、可以使用拉链表来解决缓慢变化维问题

  拉链表不存储冗余的数据，只有某行的数据发生变化，才需要保存下来，相比每次全量同步会节省存储空间
能够查询到历史快照
  拉链表中没有存储冗余的数据，只要数据没有变化，无需同步

4.1 拉链表开发步骤

1. 在mysql初始化数据
2. 在mysql数据抽取到hive的ods层
3. 将ods的层数写入到dw层,加入两个字段(生效日期，失效日期)
4. 更新mysql部分历史数据,写入新的数据到mysql
5. 将最新的数据写入到ods
6. 更新历史数据+新写入的数据
	1.更新历史数据，用dw层表left join ods 层最新的数据，更新历史失效日期
	2.从ods层读取最新的数据加载到dw层
	

5. 开发流程

6.日志数据处理流程

![(https://gitee.com/hu_hao11/blogImage/raw/master/img/20220830165323.png)

  网站流量日志数据分析整体流程基本上就是依据数据的处理流转流程进行。通俗可以概括为：数据从哪里来和数据到哪里去，可以分为以下几个大的步骤：

6.1 Nginx启动

/usr/local/nginx/sbin/nginx
 
/usr/local/nginx/sbin/nginx -s stop #停止服务器。

通过浏览器访问: http://192.168.88.100/

tail -f 日志文件名  : 实时查看文件

6.2 日志字段解释

1、访客ip地址：   58.215.204.118
2、访客用户信息：  - -
3、请求时间：[18/Sep/2018:06:51:35 +0000]
4、请求方式：GET
5、请求的url：/wp-includes/js/jquery/jquery.js?ver=1.10.2
6、请求所用协议：HTTP/1.1
7、响应码：304
8、返回的数据流量：0
9、访客的来源url：http://blog.fens.me/nodejs-socketio-chat/
10、访客所用浏览器：Mozilla/5.0 (Windows NT 5.1; rv:23.0) Gecko/20100101 Firefox/23.0

7 . Flume

  Flume是Cloudera提供的一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的软件。
  Flume的核心是把数据从数据源(source)收集过来，再将收集到的数据送到指定的目的地(sink)。为了保证输送的过程一定成功，在送到目的地(sink)之前，会先缓存数据(channel),待数据真正到达目的地(sink)后，flume在删除自己缓存的数据。
当前Flume有两个版本。Flume 0.9X版本的统称Flume OG（original generation），Flume1.X版本的统称Flume NG（next generation）。由于Flume NG经过核心组件、核心配置以及代码架构重构，与Flume OG有很大不同，使用时请注意区分。改动的另一原因是将Flume纳入 apache 旗下，Cloudera Flume 改名为 Apache Flume。

7.1 Flume 运行机制

  Flume系统中核心的角色是agent，agent本身是一个Java进程，一般运行在日志收集节点。
  每一个agent相当于一个数据传递员，内部有三个组件：
  Source：采集源，用于跟数据源对接，以获取数据；
  Sink：下沉地，采集数据的传送目的，用于往下一级agent传递数据或者往
	   最终存储系统传递数据；
  Channel：agent内部的数据传输通道，用于从source将数据传递到sink；

7.2 将日志采集到HDFS脚本

# Name the components on this agent
a1.sources = r1
a1.sinks = k1
a1.channels = c1

a1.sources.r1.type = TAILDIR
a1.sources.r1.positionFile = /var/log/flume/taildir_position.json
a1.sources.r1.filegroups = f1
a1.sources.r1.filegroups.f1 = /usr/local/nginx/logs/access*.log


# Describe the sink
a1.sinks.k1.type = hdfs
a1.sinks.k1.hdfs.path = /flume/web_log/2021-02-03
a1.sinks.k1.hdfs.filePrefix = events-

a1.sinks.k1.hdfs.round = true
a1.sinks.k1.hdfs.roundValue = 10
a1.sinks.k1.hdfs.roundUnit = minute

a1.sinks.k1.hdfs.rollInterval = 0
a1.sinks.k1.hdfs.rollSize = 4194304
a1.sinks.k1.hdfs.rollCount = 1000000
a1.sinks.k1.hdfs.idleTimeout= 10
a1.sinks.k1.hdfs.batchSize = 100
a1.sinks.k1.hdfs.useLocalTimeStamp = true
#生成的文件类型，默认是Sequencefile，可用DataStream，则为普通文本
a1.sinks.k1.hdfs.fileType = DataStream

# Use a channel which buffers events in memory
a1.channels.c1.type = memory
a1.channels.c1.capacity = 1000
a1.channels.c1.transactionCapacity = 100

# Bind the source and sink to the channel
a1.sources.r1.channels = c1
a1.sinks.k1.channel = c1

7.3 启动Flume采集

/export/server/flume-1.8.0/bin/flume-ng agent -c /export/server/flume-1.8.0/conf  -f /export/server/flume-1.8.0/conf/web_log.conf -n a1  -Dflume.root.logger=INFO,console

7.4 数据预处理-清洗

Flume采集获取的日志数据是不能直接用于分析的，需要做下预处理：
预处理需求:
    1:剔除字段长度不够的日志数据
    2:剔除对分析没有意义的字段
    3:转换日期格式
    4:对原日志数据进行切割，分隔符指定为 ‘\001’
    5:对数据的有效行进行标记
    
数据清洗：
hadoop jar /export/data/mapreduce/web_log.jar cn.itcast.bigdata.weblog.pre.WeblogPreProcess 

7.5 点击流模型数据

	点击流（Click Stream）是指用户在网站上持续访问的轨迹。注重用户浏览网站的整个流程。用户对网站的每次访问包含了一系列的点击动作行为，这些点击行为数据就构成了点击流数据（Click Stream Data），它代表了用户浏览网站的整个流程。

在点击流模型中，存在着两种模型数据：PageViews、Visits。

7.5.1 点击流模型pageviews

  Pageviews模型数据专注于用户每次会话（session）的识别，以及每次session内访问了几步和每一步的停留时间。
  在网站分析中，通常把前后两条访问记录时间差在30分钟以内算成一次会话。如果超过30分钟，则把下次访问算成新的会话开始。
大致步骤如下：
	在所有访问日志中找出该用户的所有访问记录
	把该用户所有访问记录按照时间正序排序
	计算前后两条记录时间差是否为30分钟
	如果小于30分钟，则是同一会话session的延续
	如果大于30分钟，则是下一会话session的开始
	用前后两条记录时间差算出上一步停留时间
	最后一步和只有一步的  业务默认指定页面停留时间60s。
	
	
	--得到pageviews模型
hadoop jar /export/data/mapreduce/web_log.jar  cn.itcast.bigdata.weblog.clickstream.ClickStreamPageView

7.5.2点击流模型Visits

	Visits模型专注于每次会话session内起始、结束的访问情况信息。比如用户在某一个会话session内，进入会话的起始页面和起始时间，会话结束是从哪个页面离开的，离开时间，本次session总共访问了几个页面等信息。
大致步骤如下：
	在pageviews模型上进行梳理
	在每一次回收session内所有访问记录按照时间正序排序
	第一天的时间页面就是起始时间页面
	业务指定最后一条记录的时间页面作为离开时间和离开页面。


得到visits模型
hadoop jar /export/data/mapreduce/web_log.jar cn.itcast.bigdata.weblog.clickstream.ClickStreamVisit   

今天的文章Python + 大数据 – 数仓实战之智能电商分析平台分享到此就结束了，感谢您的阅读。