目录

一：项目来源：

二：数据仓库概念

2.1 业务数据

2.2用户行为数据 

2.3数据仓库结构图

三：项目需求及架构设计

3.1项目需求分析

3.2.1 技术选型

3.2.2 系统数据流程设计

3.2.3 框架版本选型

3.2.4测试集群服务器规划

四：数据生成模块

4.1目标数据

五：数据采集模块

六：电商业务简介

6.1电商业务流程

6.2电商业务表结构

七 业务数据采集模块

7.1 Mysql安装，配置

7.2 业务数据生成:sql脚本

7.3 Sqoop安装

7.4 同步策略

八：数据仓库分层

8.1 数据仓库分层

8.2范式理论和函数依赖

8.3 维度表和事实表（*）

8.4 维度模型分类：

8.5 数据仓库建模（*）

8.5.1 ODS层

8.5.2 DWD层

8.5.3 DWS层与DWT层

8.5.4 ADS层

8.5.5 业务术语

九：Superset

9.1介绍：

9.2 使用

十：即时查询

10.1 Presto介绍

10.2 Presto优化之数据存储

10.3 Presto优化之查询SQL

十一：Azkaban

十二：其他

参考项目：尚硅谷电商数据仓库2.0/3.0

参考书籍：大数据分析--数据仓库项目实战

参考视频：https://www.bilibili.com/video/BV1Hp4y1z7aZ?from=search&seid=8803428276557895543 （哔哩哔哩）

数仓项目总结2参考我的另一篇博客：https://blog.csdn.net/yezonghui/article/details/117391336 （接着这篇博客的总结）

    就是各行业在处理事务过程中产生的数据。比如用户在电商网站中登录，下单，支付等过程中产生的数据。业务数据通常存储在MySql中。

    用户在使用产品过程中，与客户端产品交互过程中产生的数据，比如页面点击，停留，评论，点赞，收藏等。用户行为数据通常存储在日志文件中。

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

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

3）数据仓库维度建模

4）分析用户，流量，会员，商品，销售，地区，活动等电商核心主题，统计的报表指标接近100个。

5）采用即席查询工具，随时进行指标分析。

6）对集群性能进行监控，发生异常需要报警

7）元数据管理

8）质量监控

3.2项目框架

数据采集传输：Flume,Kafka,Sqoop

数据存储：Mysql，Hdfs

数据计算：Hive（引擎：Tez换成Spark）

数据查询：Presto,Druid,Kylin

数据可视化：Superset

任务调度：Azkaban

集群监控：Zabbix

元数据管理：Atlas

服务名称

子服务

服务器

hadoop102

服务器

hadoop103

服务器

hadoop104

HDFS

NameNode

√

DataNode

√

√

√

SecondaryNameNode

√

Yarn

NodeManager

√

√

√

Resourcemanager

√

Zookeeper

Zookeeper Server

√

√

√

Flume(采集日志)

Flume

√

√

Kafka

Kafka

√

√

√

Flume（消费Kafka）

Flume

√

Hive

Hive

√

MySQL

MySQL

√

Sqoop

Sqoop

√

Presto

Coordinator

√

Worker

√

√

Azkaban

AzkabanWebServer

√

AzkabanExecutorServer

√

Druid

Druid

√

√

√

Kylin

√

Hbase

HMaster

√

HRegionServer

√

√

√

Superset

√

Atlas

√

Solr

Jar

√

服务数总计

18

9

9

        我们要收集和分析的数据包括页面数据，事件数据，曝光数据，启动数据和错误数据。

4.2埋点数据日志结构

     我们的日志结构大致可以分为两类：

1）普通页面埋点日志

      每条日志包含了当前页面信息，所有事件，所有曝光信息和错误信息，还包括了一系列公共信息。

2）启动日志 

     包含公共信息，启动信息和错误信息。

          安装以及配置Hadoop，zookeeper,  Kafka, Flume。

着重看一下Flume选型，配置，拦截器。

1.为什么采用flume->kafka->flume这种配置，而不是直接使用flume？

     因为考虑后期采集的数据可能会重复利用，比如做实时计算，统一保存在Kafka中，当其他业务有需求时，

直接从Kafka中取数据就可以了。我们本项目中就是用flume从Kafka中取数据保存到hdfs上。

2.为什么要自定义拦截器？

    ETL拦截器可以实现简单的数据过滤和清洗.

本项目涉及了24张原始业务数据表

    以订单表，用户表，SKU商品表，活动表和优惠券表为中心，延申出优惠券领用表，支付流水表，活动订单表，订单详情表，订单状态表，

商品评论表，编码字典表，退单表，SPU商品表等。

     数据同步策略的类型包括：全量同步，增量同步，新增及变化同步，特殊情况

全量表：存储完整的数据.

                例如每日全量，就是每天存储一份完整数据，作为一个分区。

                适用于表数据量不大，且每天及会有新数据插入，也会有旧数据修改的场景。

增量表：存储新增加的数据。 

                例如每日增量，就是每天存储一份增量数据，作为一个分区

                适用于表数据量大，且每天只会有新数据插入的场景。

新增及变化表：存储新增加的数据和变化的数据。

                 每日新增及变化，就是存储创建时间和操作时间都是今天的数据。

                适用场景：表的数据量大，既会有新增，又会有变化。

特殊表：只需要存储一次。‘

               例如客观世界的维度（性别，地区，民族），日期维度（可以一次性导入或者导入一年的数据）。

为什么要分层？

       1）把复杂问题简单化

       2）减少重复开发

       3）隔离原始数据

如何分层？

     这块有时间可以了解一下，增强基本功。

维度表：一般是对事实的描述信息。每一张维度表对应现实世界中的一个对象或者概念。

事实表：事实表中的每行数据代表一个业务事件(下单，支付，退款，评价等)

事实表分类：

1)事务型事实表:

    以每个事物或者事件为单位，例如一个销售订单记录，一笔支付记录，作为事实表里面的一行数据。

     一旦事物被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。

2）周期型快照事实表

     周期型快照事实表中不会保留所有数据，只保留固定时间间隔的数据，例如每天或者每月的销售额，或者每月的账户余额。

3）累计型快照事实表

     累计型快照事实表用于跟踪业务事实的变化。例如数据仓库中可能需要累积或者存储订单从下订单开始，到订单商品

被打包，运输，和签收的各个业务阶段的时间点数据来跟踪订单声明周期的进展情况。当这个业务过程进行时，事实表的记录也要不断更新。

在维度建模的基础上又分为三种模型：星型模型，雪花模型，星座模型。

   对应的数据有：1）HDFS用户行为数据；2）HDFS 业务数据

   3）针对HDFS上的用户行为数据和业务数据，我们进行规划处理

     DWD层需要构建维度模型，一般采用星型模型，呈现的状态一般为星座模型

     维度建模步骤：选择业务过程 （挑选我们感兴趣的业务线，比如下单业务，支付业务，退款业务）

                             -->声明粒度 （数据仓库的数据中保存数据的细化程度和综合程度的级别，应该尽可能选择最小粒度）

                             -->确认维度 （维度的作用时描述业务是事实，主要表示的是”谁，何处，何时“等信息）

                             -->确认事实 （此处的”事实“一词，指的是业务过程中的度量值（次数，个数，件数，金额，可以进行累加））

注意：DWD层是以业务过程为驱动的。DWS,DWT,ADS层都是以需求为驱动，和维度建模没有关系

DWS层和DWT层统称为宽表层，这两层的设计思想大致相同。

总结如下：1）需要建哪些宽表：以维度为基准。

                  2）宽表里面的字段：是站在不同维度的角度去看事实表，重点关注事实表聚合后的度量值。

                  3）DWS和DWT层的区别：DWS层存放的所有主题对象当天的汇总行为，例如每个地区当天的下单次数，下单金额。

                                                              DWT层存放的是所有主题对象的累计行为，例如每个地区最近7天的下单次数，下单金额等。

        对电商系统各大主题指标分别进行分析。

    用户，新增用户，活跃用户，周（月）活跃用户，月活跃率，沉默用户，版本分布，本周回流用户，连续n周活跃用户，

忠诚用户，留存用户，用户新鲜度，单词使用时长，日使用时长，启动次数计算标准

Apache Superset 是一个开源的，现代的，轻量级的BI分析工具，能够对接多种数据源，拥有丰富的图标展示形式，支持自定义表盘。可以作为数据仓库的可视化工具。

其实主要就是按照文档进行一步步安装，配置，使用即可。

     1）Presto是一个开源的分布式SQL查询引擎，数据量支持GB到PB字节，主要用于处理秒级查询的场景。

【注意】：Presto可以解析SQL，但它不是一个标准的数据库，不是Mysql的替代品，也不能来处理在线事务（OLTP）。

    2）Presto架构

    3）Presto优点：

     基于内存运算，减少了硬盘IO，计算更快。

     能够连接多个数据源。

1）合理设置分区

2）使用列式存储 ：Presto对orc文件读取做了特定优化，因此对orc支持更好。

3）使用压缩：数据压缩可以减少节点间数据传输对IO带宽压力，建议使用snappy压缩。

1）select 只选择使用的字段，避免采用*

2）过滤条件在需要的情况下，必须加上分区字段

3）group by按照后面每个字段distinct数据多少进行降序排列

   eg: group by uid, gender 优于 group by gender , uid

4)使用order by的时候使用limit.可以减少排序计算和内存压力。

eg:不加limit,最后全局的数据量都到一块了，加了limit 10,就只有每个小块的前10条数据进入最后大块，然后进行排序。

5）Presto中join的默认算法是broadcast join，最好将大表放在左边。

（这与map  join不同）

1）azkban介绍：

    Azakban是一个批量工作流任务调度器，主要用于在一个工作流内以一个特定的顺序运行一组工作和流程，它的配置是通过简单的key:value对的方式，通过配置中的Dependencies来设置依赖关系。

    Azkaban使用job配置文件建立任务之间的依赖关系，并且提供一个易于使用的web用户界面维护和跟踪工作流。

为什么需要调度系统：

2）azkaban的架构

azkaban由三个组件组成：

Azkaban Web Server : 是工作流系统的主要管理者，负责用户登录认证，project管理，定时执行工作流，跟踪工作流执行进度等

AzkabanExecutorServer : 负责具体的工作流的提交，执行，它们通过mysql数据库来协调任务的执行。

关系型数据库Mysql: 存储大部分执行流状态，AzkabanWebserver和AzkabanExecutorServer都需要访问数据库。

kylin

zqbbix

参考：

尚硅谷大数据课程相关资料