一、数据流转的过程

用户产生数据---通过业务服务器产生业务数据----数据存储(业务数据与行为数据)----数据统计分析(数据仓库)---数据可视化

二、数据统计分析架构

2.1技术路线选择

数据仓库核心功能：统计分析

问题：用什么技术实现统计分析？Spark、MR、Flink...

Spark学习周期长，开发效率低，运行效率高（相较于MR）——采用SQL方式

如果项目想用SQL方式，有两条技术路线：

• Spark on Hive ：Spark解析SQL

• Hive on Spark ： Hive解析SQL(基于Hadoop)

二者有什么区别？——谁来解析SQL文谁放前面

实际开发过程中两种方式都会选择，但 Hive解析SQL基于Hadoop，Hadoop在国内用的更多，所以虽然两种方式都会采取，但主要使用Hive on Spark

2.2数据仓库 - 数据源

2.2.1用Spark写一个WordCount的基本步骤是什么？

1. 对接数据源

2. 加工数据(想办法把从数据源得到的数据转换为需要的格式过滤无效数据等等)

3. 统计数据（求和、取最大值等都是统计操作，统计是统计，分析是分析）

4. 分析数据（可以根据统计结果分析数据）
   

这也是数据仓库应该遵循的做统计分析的步骤。

2.2.2数据仓库是否可以以数据库为数据源？

现在出现了新问题：我们之前说我们的数据源来自于数据库，那么数据仓库中的数据源能直接是数据库吗？

答案是可以，但最好不要，默认是不行的，原因如下：

1. 之前说过数据仓库是为了统计分析，而数据存储部分是为了存储数据，保证业务系统的运行。数据存储部分存储数据是行式存储，而数据仓库是列式存储，业务数据库无法直接对接数据仓库。中间增加转换行列数据系统性能上会受到影响。

2. 业务数据库中存储的数据不是海量数据，但是数据仓库要求的数据是海量数据。数据量不够，数据量少做出的决策就不具备很大参考性。

3. 数据库不是为了数据仓库服务的，数据仓库在对接数据库数据时，会对数据库的性能造成影响。因为本身数据库是为了业务服务器存储数据用的，而业务服务器对用户提供服务，如果数据仓库介入，二者同时访问服务，势必会对业务端造成影响。

因此，在数据仓库中有个独立的数据源，只为数据仓库服务是最好的。——数据仓库应该设计一个自己的数据源

设计数据仓库自己的数据源\color{red}{代替和补充数据库}，数据存储应该和数据库保持同步，并且汇总。

2.3 数据采集和数据仓库

先前确定过，我们底层是用SQL的方式来做开发。那么数据的处理步骤中应该采用什么方式？放在文件、内存还是...?

SQL一般都是针对结构化数据，因此我们需要将数据转换为结构化数据——表

我们在数据仓库统计分析数据的所有流程中都有表的出现。

2.3.1建表有什么好处？

什么时候会用到rdd.cache(缓存)？ ——当某个东西需要重复使用，避免重复读取影响性能。

所以每个过程中都可能建立的表实际上是为了实现计算资源的复用，复用提高效率。这是我们的设计理念。

2.3.2采集项目和数据仓库项目的耦合性

但是又有一个问题：数据仓库的数据源数据需要从数据库中同步过来

数据库中每时每刻都会有数据的变化，所以我们同步不止会同步一次。——数据仓库的数据源数据需要从数据库中周期性(天)同步过来

一般情况下，将这个同步过程称之为采集。

那么，如果我要采集的目的是把数据放到数据源中，我们的数据源中有表。我们采集数据时不知道数据源中有什么表，怎么办？

---

数据采集的时候，如果想要将数据同步到数据仓库的数据源，那么就必须知道数据源中的表结构。

如果这样，数据仓库的数据源与数据就不会是独立的，采集项目和数据仓库项目就存在耦合性(关联性)。

但采集项目和数据仓库项目其实具有独立性，可以分开开发，所以在架构设计中，我们需要做一个任务——解耦合

2.3.3 解耦合：增加中间件

\color{red}{解耦合的中心思想 —— 增加中间件}

我们采集到的东西是数据和文件，而数据仓库需要的是表，这种时候就跟技术相关了，要考虑技术实现，我们数据仓库用的是Hive。

数据库把数据放进中间件中，数据仓库从中间件取数据。能实现把文件数据转换为数据仓库需要的表结构，并且方便二者存取，这就是我们选择中间件的条件。

---

Hive虽然需要表，但底层的本质是HDFS文件,只是为了操作方便把它管理成一张表，本质上还是文件

 data  &   file
 |  |
 |  |
 V  V
 ？？？ -->HDFS(file)
          ^  ^
          |  |
          |  |
 hive(table)  ==> HDFS(file)

file放进HDFS(file)并不难，因为HDFS(file)本身就是用来存文件的

把data文件放入HDFS(file)也不难，只需上传。

我们只需把数据库中的文件、数据上传和同步到HDFS中。

我们数据仓库再想办法把HDFS中的文件放到表里，利用loaddata即可把文件从HDFS拿到表里。

所以，最终我们将HDFS作为我们的中间件。

2.3.4 数据采集

我们要将数据存储内的东西放进HDFS中，怎么放？ ——这就是数据采集

Flume——把海量日志上传到HDFS

DataX、Maxwell——将数据文件上传到HDFS

至此，架构已经讲完。

数据存储不是我们的业务范围，我们需要做的是知道怎么把数据从数据存储中拿过来并进行处理。

因此，我们需要学习的内容有两部分，数据采集和数据仓库，下图中就是我们未来主要需要学习的内容。

最后的最后，由于数据可视化流程不便于直接对接大数据平台，因此我们还需要把统计分析后的数据同步到MySQL中供数据可视化使用。

三、项目需求及架构设计

3.1项目需求分析

3.1.1采集平台

1. 用户行为数据采集平台搭建

2. 业务数据采集平台搭建

3.1.2离线需求与实时需求

需要有对应的指标体系

指标：需要的数值就是指标

思考

(1)项目技术如何选型？

(2)框架发行版本如何选型（Apache、CDH、HDP）

(3)如何确认集群规模？（假设每台服务器16T硬盘）

3.2项目框架

3.2.1技术选型

3.2.2系统数据流程设计

1.离线系统数据流程图

Flume专门就是将本地文件传输给HDFS的，为何中间要加消息缓存kafka集群？

• 加此集群并非只为了削峰，它还能传输数据，均衡速率，在生产和消费不平衡时可以通过偏移量改变速率，可以对实时速率进行更友好的处理，即为了实时数仓做准备。

数据同步的方式

全量数据同步(DataX)：表的全部数据

增量数据同步(Maxwell)：表的新增及变化的数据

采集数据的目的——为了后期的统计分析做准备

需求2的第二条解决方法相当于空间换时间，专门新建一张表用于存放最近一周的注册用户数量，这样查询的时候就快多了。

2.实时数据流程图（延续离线流程图）

3.2.3 框架版本选型

Apache很可能出现各个版本不兼容的问题，需要技术雄厚，CDP帮你把版本集成了起来，但是需要收费。

3.2.4服务器选型

3.2.5集群规模

四、用户行为日志

4.1数据同步格式

4.1.2用户行为日志数据

\color{red}{格式：JSON}

日志分为两大类：

1. 页面浏览日志

2. App启动日志

1.页面浏览日志

common：环境信息

actions：动作信息，是一个数组，里面的对象是一个个动作

displays：曝光信息，也是一个数组，里面的对象是一个个曝光对象

page：页面信息

err：错误信息

ts：进入当前页面时间戳（默认看长度区分单位，13位单位毫秒，10位单位秒）

2.App启动日志

common：环境信息（共通的）

start:启动信息

err：错误信息

ts：启动App的时间戳