项目效果展示
本身我们这个数据仓库项目其实是一个纯后台项目，不过为了让大家能够更加直观的感受项目的效果，我们可以基于数据仓库中的数据统计一些指标进行展现。
我们这个项目要讲的重点不是这个大屏，这个大屏只是一个效果，为了让大家感受更加直观一些而已，我们主要讲的是这些指标对应的底层数据是如何在数据仓库中一层一层构建的。
项目的由来
接下来我们来看一下这个项目的由来，我们为什么要做这个数据仓库项目呢？或者说做这个数据仓库项目有什么意义吗？
通过构建企业级数据仓库，对企业中的所有数据进行整合，为企业各个部门提供统一的，规范的数据出口这样大家在使用数据的时候不需要每次都到各种地方去找数据，所有人在使用的时候都是基于相同的基础数据，这样计算出来的指标肯定是相同的。
一个完善合理的数据仓库对于企业整体的数据管理是意义重大的，而数据仓库也是整个大数据系统中的重要一环，更高层次的数据分析、数据挖掘等工作都会基于数据仓库进行
如果你的底层数据都没有规划好，那么上层的数据分析以及数据挖掘都是会受影响的。就像是我们盖房子，如果地基没有打牢，盖出来的房子肯定也是摇摇欲坠。所以说数据仓库对于一个中大型企业而言是至关重要的。
那话又说回来了，如果你们公司刚起步，产品也是刚上线，这个时候你花大量的时间去搞数据仓库也是没有意义的，这个时候讲究的是快速迭代。只有说数据规模上来之后，数据仓库才是有意义的，并且也是必不可少的。
什么是数据仓库
我们前面学习过Hive，说Hive其实就是一个数据仓库，可以这样理解，就是把Hive认为是一种技术，通过Hive这种技术可以实现数据仓库的建设。
我们这个项目中的数据仓库就是使用Hive构建的。
来看一下针对数据仓库的官方解释：
数据仓库(Data Warehouse)是一个面向主题的、集成的、稳定的且随时间变化的数据集合，用于支持管理人员的决策
面向主题
主题就是类型的意思。
传统数据库主要是为应用程序进行数据处理，未必会按照同一主题存储数据；数据仓库侧重于数据分析工作，是按照主题存储的。
这一点，类似于传统农贸市场与超市的区别
市场里面，针对一个商贩，他卖的萝卜、白菜这些蔬菜以及水果会在一个摊位上；、
而超市里，蔬菜和水果是分开的，并且在蔬菜里面也会进行分类，不同类型的蔬菜放到不同的地方。
也就是说，农贸市场里的菜(数据)是按照商贩(应用程序)去归类(存储)的，而超市里面则是按照蔬菜、水果的类型(同主题)归类的。
集成
传统数据库通常与某些特定的应用相关，数据库之间相互独立。而数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。
稳定
稳定说的是相对稳定
传统数据库中的数据通常实时更新，数据根据需要及时发生变化。数据仓库的数据主要供企业决策分析使用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。
变化
这里的变化说的是反映历史变化
传统数据库主要关心当前某一个时间段内的数据，而数据仓库中的数据通常包含历史信息，它里面记录了企业从过去某一时间点(如开始应用数据仓库的时间)到目前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出分析和预测。
企业数据仓库的建设，是以现有企业业务系统和大量业务数据的积累为基础。数据仓库不是静态的概念，只有把信息及时交给需要这些信息的使用者，供他们做出改善其业务经营的决策，信息才能发挥作用，信息才有意义。而把信息加以整理归纳和重组，并及时提供给相应的管理决策人员，是数据仓库的根本任务。
数据仓库基础知识
在学习数据仓库之前我们先来看一些数据仓库的基础知识
- 事实表、维度表
- 数据库三范式
- 维度建模模型：雪花模型、星型模型
事实表、维度表
什么是事实表呢？
事实表是指保存了大量业务数据的表，或者说保存了一些真实的行为数据的表
例如：销售商品所产生的订单数据
什么是维度表呢？
首先说一下什么是维度
维度其实指的就是一个对象的属性或者特征，例如：时间维度，地理区域维度，年龄维度
这是维度的概念。
维度表里面存放的其实就是刚才我们所说的那些维度相关的信息。
数据仓库建模方式
数据仓库建模可以使用多种方式
- ER实体模型，这种模型其实就是满足数据库第三范式的模型，这就是刚才我们为什么要分析数据库中的三范式了。
ER模型是数据库设计的理论基础，当前几乎所有的OLTP系统设计都采用ER模型建模的方式
Bill Inom提出的数仓理论，推荐采用ER关系模型进行建模，不过这种方式在实际工作中不推荐使用。 - 维度建模模型
Ralph Kimball提出的数仓理论中，提出了维度建模，将数据仓库中的表划分为事实表和维度表。
基于事实表和维度表进行维度建模。
维度建模通常又分为星型模型和雪花模型，一会我们详细分析这两种维度建模模型。
维度建模是我们在构建数据仓库中常用的方式。 - Data Vault模型
Data Vault是在ER模型的基础上衍生而来，模型设计的初衷是有效的组织基础数据层，使之易扩展、灵活的应对业务的变化，同时强调历史性、可追溯性和原子性，不要求对数据进行过度的一致性处理；并非针对分析场景所设计。 - Anchor模型
Anchor是对Data Vault模型做了更近一步的规范化处理，初衷是为了设计高度可扩展的模型，核心思想是所有的扩张只添加而不修改，于是设计出的模型基本变成了k-v结构的模型。
Data Vault模型和Anchor模型，这两种模型大家知道就行了，很少使用，如果大家感兴趣的话可以到网上查阅相关资料了解一下。
维度建模模型
下面详细分析一下维度建模模型
星型模型和雪花模型
星型模型和雪花模型主要区别就是对维度表的拆分，
对于雪花模型，维度表的设计更加规范，一般符合3NF；
而星型模型，一般采用降维的操作，利用冗余来避免模型过于复杂，提高易用性和分析效率
这里面的中间的订单表是事实表，外面的四个是维度表。
这几个维度表，其实严格意义上来说，只能满足第二范式，是不满足第三范式的。
但是这样的好处是查询效率比较高，在查询的时候不需要关联很多张表。
缺点就是数据有冗余。
使用这个五角星代表星型模型还是比较形象的，因为针对事实表周边的这些维度表，外层就没有其它的表了。
这个里面订单表是一个事实表，其余的都是维度表。
针对商品维度表外层又拆分出来了一个商品类目的维度表，这样拆分之后其实就满足第三范式了，但是这样就变的复杂了，后期在获取商品维度数据的时候，还需要关联这个商品类目维度表。
这里使用这个雪花代表雪花模型也是比较形象的，事实表周边会有一层维度表，这些维度表外层还可能会有多层维度表
星型模型 VS 雪花模型
- 冗余：雪花模型符合业务逻辑设计，采用3NF设计，有效降低数据冗余；星型模型的维度表设计不符合3NF，反规范化，维度表之间不会直接相关，牺牲部分存储空间
- 性能：雪花模型由于存在维度间的关联，采用3NF降低冗余，通常在使用过程中，需要连接更多的维度表，导致性能偏低；星型模型违反三范式，采用降维的操作将维度整合，以存储空间为代价有效降低维度表连接数，性能比雪花模型高
在实际工作中我们多采用星型模型，因为数据仓库主要是侧重于做数据分析，对数据的查询性能要求比较高，所以星型模型是比较好的选择，在实际工工作中我们会尽可能的多构建一些宽表，提前把多种有关联的维度整合到一张表中，后期使用时就不需要多表关联了，比较方便，并且性能也高。
数据仓库分层
为什么要分层
数据仓库在构建过程中通常都需要进行分层处理。业务不同，分层的技术处理手段也不同。对数据进行分层的一个主要原因就是希望在管理数据的时候，能对数据有一个更加清晰的掌控
详细来讲，主要有下面几个原因：
- 清晰的数据结构：每一个分层的数据都有它的作用域，这样我们在使用表的时候能更方便地定位和理解。
- 数据血缘追踪：简单来讲可以这样理解，我们最终给业务方呈现的是一个能直接使用的业务表，但是它的来源有很多，如果有一张来源表出问题了，我们希望能够快速准确地定位到问题，并清楚它的危害范围，分层之后就很好定位问题，以及可以清晰的知道它的危害范围。
- 减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少重复计算。
- 把复杂问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性， 当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。
- 屏蔽业务的影响，不必改一次业务就重新接入数据。
数据仓库分层设计
数据仓库一般会分为4层
- ODS层：原始数据层，数据源中的数据，采集过来之后，原样保存。
- DWD层：明细数据层：这一层是对ODS层的数据进行清洗，解决一些数据质量问题和数据的完整度问题。
- DWS层：这一层是对DWD层的数据进行轻度聚合汇总，生成一系列的中间表，提升公共指标的复用性，减少重复加工，并且构建出来一些宽表，用于提供后续的业务查询。
- APP层：根据业务需要，由前面三层的数据统计而出的结果，可以直接提供查询展现，一般会把APP层的数据导出到MySQL中供线上系统使用，提供报表展示、数据监控及其它功能。也有公司把这层称为DM层。虽然名字不一样，但是性质是一样的。
注意：针对DWD层在对数据进行清洗的时候，一般需要遵循以下原则
- 数据唯一性校验(通过数据采集工具采集的数据会存在重复的可能性)
- 数据完整性校验(采集的数据中可能会出现缺失字段的情况，针对缺失字段的数据建议直接丢掉，如果可以确定是哪一列缺失也可以进行补全，可以用同一列上的前一个数据来填补或者同一列上的后一个数据来填补)
- 数据合法性校验-1(针对数字列中出现了null、或者-之类的异常值，全部替换为一个特殊值，例如0或者-1，这个需要根据具体的业务场景而定)
- 数据合法性校验-2(针对部分字段需要校验数据的合法性，例如：用户的年龄，不能是负数)
数据仓库命名规范
我们在使用Hive实现数据仓库的时候该如何体现这些层次？
- 针对数据仓库的每一层都在Hive中创建一个数据库，数据库的命名包含每一层的标识符
例如：针对ODS层可以在Hive中创建数据库 ods_mall，把同一层的表都放到一个数据库里面，方便管理 - 针对每一层中的表名，在创建的时候可以使用每一层的标识符开头
例如：针对ODS层，创建的表名为：ods_user，这样方便后期使用，只要看到表名就可以知道这个表示哪一层的了。
针对一些临时表，我们可以在对应的分层中创建表名的时候，以_tmp结尾。
针对一些备份的表，可以在表名后面添加_bak。
典型的数据仓库系统架构
下图是一个典型的企业数据仓库系统，通常包含数据源、数据存储与管理、数据的访问三个部分
数据源部分负责采集各种日志数据、业务数据，以及一些文档资料，将我们需要的这些数据加载到Hive中，构建数据仓库
数据仓库构建好了以后可以为很多服务提供数据支撑
例如：做数据报表，做OLAP数据分析，以及在做用户画像和数据挖掘的时候都是需要使用到数据仓库中的数据的
在实际工作中，数据仓库分为离线数据仓库和实时数据仓库
我们这个项目主要分析离线数据仓库，因为到现阶段为止我们主要学习了离线计算相关的技术框架
项目需求分析
通过刚才对一个典型的企业数据仓库系统架构进行分析，我们发现，想要开发一个完整的数据仓库系统，
至少需要以下这几个功能模块
- 数据采集平台，这个模块主要负责采集各种数据源的数据
- 数据仓库，这个模块负责数据存储和管理
- 数据报表，这个模块其实就是数据可视化展示了
通过这三个模块可以实现数据采集，构建数据仓库，最后基于数据仓库中的数据实现上层应用，体现数据仓库的价值。
技术选型
首先是数据采集
我们前面学习了Flume这个数据采集工具
其实还有一些类似的数据采集工具，Logstash、FileBeat，这两个也可以实现数据采集
那这三个日志采集工具我们需要如何选择呢？
首先从性能消耗上面来说，Flume和Logstash的性能消耗差不多，都是基于JVM执行的，都是重量级的组件，支持多种数据源和目的地。FileBeat是一个只支持文件数据采集的工具，是一个轻量级组件，性能消耗比价低，它不是基于JVM执行的，使用go语言开发。
我们在采集数据的时候可以分为两种情况
第一种是把采集工具部署到产生数据的服务器上面
web项目产生的日志数据直接保存在服务器上面，并且这个服务器的性能比较高，可以允许我在上面部署Flume数据采集工具，这样也不会对上面的web项目的稳定性产生什么影响。
第二种是把采集工具部署在一个独立的服务器上面
web项目产生的日志数据直接保存在服务器上面，但是这个服务器的性能一般，并且对web项目的稳定性要求非常高，如果让你在上面部署一个其它服务，这样这个服务器的稳定性就没办法保证了，进而也就无法保证web项目的稳定性了，所以这个时候可以选择在产生日志的时候使用埋点上报的方式，通过http接口把日志数据传输到日志接收服务器中
分析
那针对第一种情况肯定是要选择一个性能消耗比较低的数据采集工具，优先选择FileBeat
针对第二种情况的话就不需要考虑性能消耗了，因为采集工具是在独立的机器上，不会影响web项目，这个时候我们需要考虑的就是采集工具的功能是否完整，因为在采集数据的时候可能需要对数据进行一些简单的处理，以及后期可能会输出到不同的存储介质中。
Flume和Logstash都是支持多种输入、多种输出、以及都可以在采集数据的时候对数据做一些处理，那这个时候该如何选择呢？
注意了，这个时候我们就要考虑如果后期采集工具出现了问题，或者我们需要自定义一些功能，维护成本高不高，Flume是使用java开发的，而Logstash是使用ruby开发的，由于我们都是java出身，所以考虑到后期的维护成本，Flume是最优的选择。
在采集数据的时候，除了日志数据，有时候还需要采集一些业务系统的数据，这些数据一般保存在关系型数据库中，例如：MySQL
我们也需要把这些数据采集过来，如果MySQL开启了binlog，那我们可以使用Flume采集
采集MySQL中的数据
什么是MySQL的binlog呢？
可以这样理解，MySQL对数据库的任何修改都会记录在binlog中，所以如果开启了binlog，那我们就可以使用Flume采集这个日志数据，就可以获取到MySQL中数据的变化了。
但是目前我们的MySQL没有开启binlog，并且也没有打算开启binlog，那怎么办？
因为我们这个需求不需要实时采集MySQL中的数据，所以不开启binlog也是没有问题的，Flume默认不支持直接采集MySQL中的数据，如果想要实现的话需要自定义Source，这样就比较麻烦了
其实采集MySQL中的数据有一个比较常用的方式是通过Sqoop实现。
Sqoop中有两大功能，数据导入和数据导出
数据导入是指把关系型数据库中的数据导入HDFS中
数据导出是指把HDFS中的数据导出到关系型数据库中
我们后期在做一些报表的时候其实也是需要把数据仓库中的数据导出到MySQL中的，所以在这选择Sqoop也是非常实用的。
所以针对数据采集这块，我们主要选择了Flume和Sqoop
数据存储
数据采集过来以后，由于我们后面要构建数据仓库，数据仓库是使用Hive实现，Hive的数据是存储在HDFS中的，所以我们把采集到的数据也直接存储到HDFS里面
还有一点是后期在做一些数据报表的时候，是需要把数据仓库中的数据导出到MySQL中的，所以数据存储也需要使用到MySQL。
数据计算
在构建数据仓库的时候，我们前面说了，是使用Hive构建数据仓库，一般的数据处理通过SQL是可以搞定的，如果遇到了比较复杂的处理逻辑，可能还需要和外部的数据进行交互的，这个时候使用SQL就比较麻烦了，内置的函数有时候搞不定，还需要开发自定义函数针对复杂的数据清洗任务我们也可以考虑使用Spark进行处理。
数据可视化
在数据可视化层面，我们可以使用Hue进行数据查询
如果想实现写SQL直接出图表的话可以使用Zeppelin
如果想定制开发图表的话可以使用Echarts之类的图表库，这个时候是需要我们自己开发数据接口实现的。
整体架构设计
我们采集的数据主要分为服务端数据和客户端数据
什么是服务端数据，就是网站上的商品详情数据以及你下的订单信息之类的数据，这些数据都是在服务端存储着的，一般是存储在类似于MySQL之类的关系型数据库中，这些数据对事务性要求比较严格，所以会存放在关系型数据库中
什么是客户端数据呢，就是用户在网站或者app上的一些滑动、点击、浏览、停留时间之类的用户行为数据，这些数据会通过埋点直接上报，这些其实就是一些日志类型的数据了，这种类型的数据没有事务性要求，并且对数据的完整性要求也不是太高，就算丢一些数据，对整体结果影响也不大。
针对服务端数据，在采集的时候，主要是通过Sqoop进行采集，按天采集，每天凌晨的时候把昨天的数据采集过来，存储到HDFS上面。
针对客户端数据，会通过埋点上报到日志接收服务器中，其实这里面就是一个Http服务，埋点上报就是调用了这个Http服务，把日志数据传输过来，日志接收服务收到数据之后，会把数据落盘，存储到本地，记录为日志文件，然后通过Flume进行采集，将数据采集到HDFS上面，按天分目录存储。
服务端数据和客户端数据都进入到HDFS之后，就需要对数据进行ETL，构建数据仓库了。
数据仓库构建好了以后可以选择把一些需要报表展现的数据导出到MySQL中，最终在页面进行展现。
服务器资源规划
整体架构分析好了，下面我们来分析一下，想要实现这个架构，服务器资源应该如何划分
针对我们的测试环境：
针对生产环境，至少需要这些机器：
说明
- 由于NameNode开启了HA，所以SecondaryNameNode进程就不需要了
- NameNode需要使用单独的机器，并且此机器的内存配置要比较高，建议128G
- DataNode和NodeManager需要部署在相同的集群上，这样可以实现数据本地化计算
- Hadoop Client 需要部署在需要和Hadoop交互的机器上
- 数据接口服务器需要使用至少两台，为了实现负载均衡及故障转移，保证数据接收服务的稳定性
- Flume部署在日志服务器上面，便于采集本机保存的用户行为日志信息；还需要有单独的Flume机器，便于处理其它的日志采集需求
- Hive需要部署在所有业务机器上
- MySQL建议单独部署，至少两台，一主一备
- Sqoop需要部署在所有业务机器上
- Zeppelin可以单独部署在一台普通配置的机器上即可
- Azkaban建议至少使用三台，一主两从，这样可以保证一个从节点挂掉之后不影响定时任务的调度
针对Hadoop集群的搭建在线上环境需要使用CDH或者HDP
具体Hadoop集群需要使用多少台集群需要根据当前的数据规模来预估
假设集群中的机器配置为8T，64 Core，128G
- 如果每天会产生1T的日志数据，需要保存半年的历史数据： 1T*180天=180T
- 集群中的数据默认是3副本： 180T*3=540T
- 预留20%左右的空间： 540T/0.8=675T
这样计算的话就需要675T/8T=85台服务器
如果我们在数据仓库中对数据进行分层存储，这样数据会出现冗余，存储空间会再扩容1~2倍
注意：没有必要一开始就上线全部的机器，我们可以前期上线30台，后面随着业务数据量的增长再去动态扩容机器即可。
标签：需要,项目,模型,数据仓库,介绍,采集,维度,数据 From： https://www.cnblogs.com/strongmore/p/17367364.html