Analysis of the data warehouse

1. a basic introduction to data warehouse

　　English name for the Data Warehouse , can be abbreviated as DW or DWH. The purpose of the data warehouse is to build integrated data-oriented analysis environment , providing enterprise decision support (Decision Support). It is for analytical reporting and decision support purposes created.

　　The reason the data warehouse itself does not "produce" any data, while the data itself does not require any "consumption", data from an external source, and open to external applications, which is why is it called "warehouse" and not called "factory" .

2. The definition of a data warehouse

　　A data warehouse is subject-oriented (Subject-Oriented), integrated (Integrated), stability and (Non-Volatile) time-varying data sets (Time-Variant), to support management decisions.

2.1, subject-oriented

　　Data warehouse data is organized in a certain subject field.

　　Theme is an abstract concept, refers to the user to use the data warehouse to focus on aspects of decision-making are concerned, a theme commonly associated with a plurality of operational information systems.

2.2, integration

　　According to the requirements of decision analysis, data source will be dispersed throughout the extraction, screening, cleaning, and integration work, and ultimately integrated into the data warehouse.

 

2.3, Stability

　　The relative stability of the data, the data in the data warehouse were only add, there is no update, delete operation process.

　　It reflects the historical changes to the query-based analysis.

2.4, when degeneration

　　The new snapshot data warehouse properties generally with time, with the passage of time and change, constantly generating themes

4. The difference with the data warehouse database

　　The difference between the database and the data warehouse is actually talking about the difference between OLTP and OLAP.

　　OLTP : the On-Line Transaction Processing called online transaction processing , transaction-oriented may also known processing systems, it is in the daily operation of the database online, usually for a small number of records, and modified for specific business. More concerned about problems of user operation response time, data security, integrity and concurrency support the number of users. Traditional database management system as the primary means of data, mainly for operational processing.

 　　OLAP : the On-Line Analytical Processing called online analytical processing , generally analyze historical data for certain topics, to support management decisions.

　　In short, databases are transaction-oriented design, data warehouse is a subject-oriented design .

　　Online transaction database to store general data, there are high transaction requirements; data warehouse storage are generally historical data.

　　Database design is to avoid redundancy, the general rule in line with the paradigm to design, data warehouse design is intentionally introduced in the way the redundancy, the use of anti-paradigm design.

　　The database is to capture data design , data warehouse is to analyze data and design , its two basic elements is the dimension and fact tables. Victoria is the angle of approach, such as time, departments, put a dimension table is to define these things, the fact that the data to be queried table stood, while Victoria's ID.

Features	database	database
data range	Storage history, complete reaction of historical change	The current status data
Data changes	You can add, delete No, no change, historical change response	Support frequently add, delete, change, check operation
Scenarios	Oriented Analysis, strategic decision support	Transaction-oriented business processes
Design Theory	Violation paradigm, appropriate redundancy	Compliance paradigm (first, second, third paradigm), to avoid redundancy
Handling capacity	Infrequent, large-volume, high throughput, delay	Frequent, small batch, high concurrency, low latency

The common means of building data warehouses

•　　 传统数仓建设更多的基于成熟的商业数据集成平台，比如Teradata、Oracle、Informatica等，技术体系比较成熟完善，但相对比较封闭，对实施者技术面要求也相对专业且单一，一般更多应用于银行、保险、电信等“有钱”行业.

• 　　基于大数据的数仓建设一般是基于非商业、开源的技术，常见的是基于hadoop生态构建，涉及技术较广泛、复杂，同时相对于商业产品，稳定性、服务支撑较弱，需要自己维护更多的技术框架。在大数据领域，常用的数据仓库构建手段很多基于hive，sparkSQL，impala等各种技术框架.

6. 数据仓库分层

6.1 数据仓库分层描述

• 数据仓库更多代表的是一种对数据的管理和使用的方式，它是一整套包括了etl、调度、建模在内的完整的理论体系。现在所谓的大数据更多的是一种数据量级的增大和工具的上的更新。 两者并无冲突，相反，而是一种更好的结合。数据仓库在构建过程中通常都需要进行分层处理。业务不同，分层的技术处理手段也不同。

• 分层是数据仓库解决方案中，数据架构设计的一种数据逻辑结构 ，通过分层理念建立的数据仓库，它的可扩展性非常好，这样设计出来的模型架构，可以任意地增减、替换数据仓库中的各个组成部分。

从整体的逻辑划分来讲，数据仓库模型实际上就是这三层架构。
接入层：底层的数据源或者是操作数据层，一般在公司的话，统一都是称为ODS层
中间层：是做数据仓库同学需要花费更多精力的一层，这一层包括的内容是最多的、最复杂的。
应用层：对不同的应用提供对应的数据。该层主要是提供数据产品和数据分析使用的数据，比如我们经常说的报表数据

• 针对于这三层架构，这里给出比较典型的一个做数据仓库在实施的时候，具体的层次划分。

• ODS：

  • Operation Data Store 原始数据层

• DWD
  

  • data warehouse detail 数据明细层

  • 它主要是针对于接入层的数据进行数据的清洗和转换。还有就是一些维度的补充。

• DWS
  

  • data warehouse summary 数据汇总层

  • 它是在DWD明细层之上，也有公司叫DW层

  • 它是按照一定的粒度进行了汇总聚合操作。它是单业务场景。

• DWM
  

  • data warehouse market 数据集市层

  • 它是在DWS数据汇总层之上，集市层它是多业务场景的。

• APP
  

  • Application 应用层

  • 这个是数据仓库的最后一层数据，为应用层数据，直接可以给业务人员使用

TMP临时表：在做一些中间层表计算的时候，大量使用tmp临时表。
DIM维度层：基于ODS层和DWD层抽象出一些公共的维度，典型的公共维度主要包括城市信息、渠道信息、个人基础属性信息。

6.2 为什么要进行数据仓库分层

• 分层的主要原因是在管理数据的时候，能对数据有一个更加清晰的掌控，主要有下面几个原因：

  • 空间换时间

    • 通过建设多层次的数据模型供用户使用，避免用户直接使用底层操作型数据，可以更高效的访问数据。

  • 把复杂问题简单化

    • 讲一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。

  • 便于处理业务的变化

    • 随着业务的变化，只需要调整底层的数据，对应用层对业务的调整零感知。

7. 数据仓库建模

​ 　　目前业界较为流行的数据仓库的建模方法非常多，这里主要介绍范式建模法，维度建模法，实体建模法等几种方法，每种方法其实从本质上讲就是从不同的角度看我们业务中的问题，不管从技术层面还是业务层面，其实代表的是哲学上的一种世界观。

7.1 范式建模法（Third Normal Form 3NF）

范式建模法是基于整个关系型数据库的理论基础之上发展而来的，其实是我们在构建数据模型常用的一个方法，主要解决关系型数据库得数据存储，利用的一种技术层面上的方法。
目前，我们在关系型数据库中的建模方法，大部分采用的是三范式建模法。
从其表达的含义来看，一个符合第三范式的关系必须具有以下三个条件 :
（1）每个属性值唯一，不具有多义性 ;
（2）每个非主属性必须完全依赖于整个主键，而非主键的一部分 ;
（3）每个非主属性不能依赖于其他关系中的属性，因为这样的话，这种属性应该归到其他关系中去。

7.2 维度建模法

维度建模(dimensional modeling)是专门用于分析型数据库、数据仓库、数据集市建模的方法。维度建模法简单描述就是按照事实表、维度表来构建数仓、集市。
维度建模从分析决策的需求出发构建模型，为分析需求服务，因此它重点关注用户如何更快速地完成需求分析，同时具有较好的大规模复杂查询的相应性能。

• 维度表

维度表示你要对数据进行分析时所用的一个量,比如你要分析产品销售情况, 
你可以选择按类别来进行分析,或按区域来分析。
通常来说维度表信息比较固定，且数据量小

• 事实表

表示对分析主题的度量。
事实表包含了与各维度表相关联的外键，并通过join方式与维度表关联。事实表的度量通常是数值类型，且记录数会不断增加，表规模迅速增长。
​
消费事实表：Prod_id(引用商品维度表), TimeKey(引用时间维度表), Place_id(引用地点维度表), Unit(销售量)。

总的说来，在数据仓库中不需要严格遵守规范化设计原则。因为数据仓库的主导功能就是面向分析，以查询为主，不涉及数据更新操作。事实表的设计是以能够正确记录历史信息为准则，
维度表的设计是以能够以合适的角度来聚合主题内容为准则

7.2.1 维度建模三种模式

　　基于事实表和维表就可以构建出多种多维模型，包括星形模型、雪花模型和星座模型。

　　维度建模法最被人广泛知晓的名字就是星型模式。

• 星型模式

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

  

  

 

• 雪花模式

雪花模式是对星形模式的扩展。雪花模式的维度表可以拥有其他维度表的，虽然这种模型相比星型更规范一些，但是由于这种模型不太容易理解，维护成本比较高，而且性能方面需要关联多层维表，
性能也比星型模型要低。所以一般不是很常用。

• 星座模式
  

星座模式是星型模式延伸而来，星型模式是基于一张事实表的，而星座模式是基于多张事实表的，而且共享维度信息。
​
前面介绍的两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。

7.3 实体建模法

实体建模法并不是数据仓库建模中常见的一个方法，它来源于哲学的一个流派。
​
从哲学的意义上说，客观世界应该是可以细分的，客观世界应该可以分成由一个个实体，以及实体与实体之间的关系组成。
​
那么我们在数据仓库的建模过程中完全可以引入这个抽象的方法，将整个业务也可以划分成一个个的实体，而每个实体之间的关系，以及针对这些关系的说明就是我们数据建模需要做的工作。

参考文档：http://www.uml.org.cn/sjjmck/201810163.asp

8、数据仓库架构

• 数据采集

数据采集层的任务就是把数据从各种数据源中采集和存储到数据存储上，期间有可能会做一些ETL操作。
​
数据源种类可以有多种：
日志：所占份额最大，存储在备份服务器上
业务数据库：如Mysql、Oracle
来自HTTP/FTP的数据：合作伙伴提供的接口
其他数据源：如Excel等需要手工录入的数据

• 数据存储与分析

HDFS是大数据环境下数据仓库/数据平台最完美的数据存储解决方案。
​
离线数据分析与计算，也就是对实时性要求不高的部分，Hive是不错的选择。
使用Hadoop框架自然而然也提供了MapReduce接口，如果真的很乐意开发Java，或者对SQL不熟，那么也可以使用MapReduce来做分析与计算。
Spark性能比MapReduce好很多，同时使用SparkSQL操作Hive。

• 数据共享

前面使用Hive、MR、Spark、SparkSQL分析和计算的结果，还是在HDFS上，但大多业务和应用不可能直接从HDFS上获取数据，那么就需要一个数据共享的地方，使得各业务和产品能方便的获取数据。
​
这里的数据共享，其实指的是前面数据分析与计算后的结果存放的地方，其实就是关系型数据库和NOSQL数据库。

• 数据应用

报表：报表所使用的数据，一般也是已经统计汇总好的，存放于数据共享层。
接口：接口的数据都是直接查询数据共享层即可得到。
即席查询：即席查询通常是现有的报表和数据共享层的数据并不能满足需求，需要从数据存储层直接查询。一般都是通过直接操作SQL得到。

9、补充

• 增加以下内容

  • 数据采集

    • 采用Flume收集日志，采用Sqoop将RDBMS以及NoSQL中的数据同步到HDFS上

  • 消息系统

    • 可以加入Kafka分布式消息系统保证数据丢失

  • 机器学习

    • 使用了SparkMLlib提供的机器学习算法

  • 数据可视化

    • 提供可视化前端页面，方便运营等非开发人员直接查询

  • 任务调度和监控

    • 任务的统一调度和监控