一.数据处理流程
网站流量日志数据分析是一个纯粹的数据分析项目，其整体流程基本上就是 依据数据的处理流转流程进行。通俗可以概括为：数据从哪里来和数据到哪里去，
可以分为以下几个大的步骤：
image
数据采集
数据采集概念，目前行业会有两种解释： 一是数据从无到有产生的过程（服务器打印的 log、自定义采集的日志等）
叫做数据采集； 另一方面也有把通过使用 Flume 等工具把数据采集搬运到指定位置的这个 过程叫做数据采集。
关于具体含义要结合语境具体分析，明白语境中具体含义即可。
数据预处理
数据预处理（data preprocessing）是指在正式处理以前对数据进行的一些
处理。现实世界中数据大体上都是不完整，不一致的脏数据，无法直接进行数据 分析，或者说不利于分析。为了提高数据分析的质量和便捷性产生了数据预处理 技术。
数据预处理有多种方法：数据清理，数据集成，数据变换等。这些数据处理 技术在正式数据分析之前使用，大大提高了后续数据分析的质量与便捷，降低实 际分析所需要的时间。
技术上原则来说，任何可以接受数据经过处理输出数据的语言技术都可以用 来进行数据预处理。比如 java、Python、shell 等。
本项目中通过 MapReduce 程序对采集到的原始日志数据进行预处理，比如 数据清洗，日期格式整理，滤除不合法数据等，并且梳理成点击流模型数据。
使用 MapReduce 的好处在于：一是 java 语言熟悉度高，有很多开源的工具 库便于数据处理，二是 MR 可以进行分布式的计算，并发处理效率高。
数据入库
预处理完的结构化数据通常会导入到 Hive 数据仓库中，建立相应的库和表 与之映射关联。这样后续就可以使用 Hive SQL 针对数据进行分析。 因此这里所说的入库是把数据加进面向分析的数据仓库，而不是数据库。因
项目中数据格式比较清晰简明，可以直接 load 进入数据仓库。 实际中，入库过程有个更加专业的叫法—ETL。ETL 是将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程，目的是将企业中的分散、零乱、 标准不统一的数据整合到一起，为企业的决策提供分析依据。
ETL 的设计分三部分：数据抽取、数据的清洗转换、数据的加载。在设计 ETL 的时候我们 也是从这三部分出发。 数据的抽取是从各个不同的数据源抽取到 ODS(Operational Data Store，操作型数据存储)中——这个过程也可以做一些数据的清洗和转换)，在抽取的过程中 需要挑选不同的抽取方法，尽可能的提高 ETL 的运行效率。ETL 三个部分中，花费时间最长的 是“T”(Transform，清洗、转换)的部分，一般情况下这部分工作量是整个 ETL 的 2/3。数据 的加载一般在数据清洗完了之后直接写入 DW(Data Warehousing，数据仓库)中去。
数据分析
本阶段是项目的核心内容，即根据需求使用 Hive SQL 分析语句，得出指标 各种统计结果。
image
数据可视化
将分析所得数据结果进行数据可视化，一般通过图表进行展示。 数据可视化可以帮你更容易的解释趋势和统计数据。
image
二. 系统的架构
相对于传统的 BI 数据处理，流程几乎差不多，但是因为是处理大数据，所 以流程中各环节所使用的技术则跟传统 BI 完全不同：
- 数据采集：页面埋点 JavaScript
- 采集；开源框架 Apache Flume
- 数据预处理： Hadoop MapReduce 程序
- 数据仓库技术：基于 hadoop 的数据仓库 Hive
- 数据导出：基于 hadoop 的 sqoop 数据导入导出工具
- 数据可视化：定制开发 web 程序(echarts)
- 整个过程的流程调度：hadoop 生态圈中的 azkaban 工具
架构图
image
三. 数据仓库设计
1.事实表
发生在现实世界中的操作型事件，其所产生的可度量数值，存储在事实表中。 从最低的粒度级别来看，事实表行对应一个度量事件，反之亦然。 事实表表示对分析主题的度量。比如一次购买行为我们就可以理解为是一个事实。
image
2.维度表
每个维度表都包含单一的主键列。维度表的主键可以作为与之关联的任何事 实表的外键，当然，维度表行的描述环境应与事实表行完全对应。维度表通常比 较宽，是扁平型非规范表，包含大量的低粒度的文本属性。
维度表示你要对数据进行分析时所用的一个量,比如你要分析产品销售情况, 你可以选择按类别来进行分析,或按区域来分析。这样的按..分析就构成一个维 度。上图中的用户表、商家表、时间表这些都属于维度表，这些表都有一个唯一 的主键，然后在表中存放了详细的数据信息。
总的说来，在数据仓库中不需要严格遵守规范化设计原则。因为数据仓库的 主导功能就是面向分析，以查询为主，不涉及数据更新操作。事实表的设计是以 能够正确记录历史信息为准则，维度表的设计是以能够以合适的角度来聚合主题 内容为准则。
维度建模三种模式
- 星型模式
- 雪花模式（避免使用，关联耦合性太强）
- 星座模式
星形模式(Star Schema)是最常用的维度建模方式。星型模式是以事实表为中心，所有的维度表直接连接在事实表上，像星星一样。
星形模式的维度建模由一个事实表和一组维表成，且具有以下特点：
- 维表只和事实表关联，维表之间没有关联；
- 每个维表主键为单列，且该主键放置在事实表中，作为两边连接的外键；
- 以事实表为核心，维表围绕核心呈星形分布；
image
雪花模式
雪花模式(Snowflake Schema)是对星形模式的扩展。雪花模式的维度表可以拥有其他维度表的，虽然这种模型相比星型更规范一些，但是由于这种模型不太 容易理解，维护成本比较高，而且性能方面需要关联多层维表，性能也比星型模 型要低。所以一般不是很常用。
image
星座模式
星座模式是星型模式延伸而来，星型模式是基于一张事实表的，而星座模式是基于多张事实表的，而且共享维度信息。
前面介绍的两种维度建模方法都是多维表对应单事实表，但在很多时候维度 空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。
image
网友评论