《大型综合项目-基于大数据平台的数据仓库》学习笔记之（04）：数仓概念篇2

本项目教程笔记源自多易教育《Titan综合数据仓库与数据运营系统》，在CSDN学院有相关视频教程购买链接，大数据企业级项目实战–Titan大型数据运营系统
本项目课程是一门极具综合性和完整性的大型大数据项目实战课程，课程项目的业务背景源自各类互联网公司对海量用户浏览行为数据和业务数据分析的需求及企业数据管理、数据运营需求。
学完本课程，你将很容易就拿到大数据数仓建设或用户画像建设等岗位的OFFER

本课程项目涵盖数据采集与预处理、数据仓库体系建设、用户画像系统建设、数据治理（元数据管理、数据质量管理）、任务调度系统、数据服务层建设、OLAP即席分析系统建设等大量模块，力求原汁原味重现一个完备的企业级大型数据运营系统。

跟随项目课程，历经接近100+小时的时间，从需求分析开始，到数据埋点采集，到预处理程序代码编写，到数仓体系搭建…逐渐展开整个项目的宏大视图，构建起整个项目的摩天大厦。

---

一、事实和维度

1、基本概念

       事实： 现实发生的某件事
       维度： 衡量事实的一个角度

       事实表： 记录事实的表；比如，订单表，注册表，购物车，退货表，浏览日志表
       维度表： 对维度的详细描述信息；比如，地域维表，产品维表，品类维表，栏目维表，时间维表；

2、事实表及维度举例

       访客浏览记录表
       uid,session,page,lanmu,pinlei,pid,datetime,areacode
       u1,s1,/abc/dd,lm1,cat1,p01,2019-10-21 16:18:21,11010
       u1,s1,/bbb/cd,lm2,cat3,p08,2019-10-21 16:18:30,11010
       u2,s2,/aty/rt,lm3,cat5,p05,2019-10-21 16:17:21,01010
       u2,s2,/bbb/cd,lm2,cat3,p08,2019-10-21 16:19:30,01010
       上面的表就是一个 事实表

       对事实表，假如要计算pv数（指标）
       我们按如下口径来统计：
              总pv数
              每个栏目的pv数
              每个省份的pv数
              每个商品品类的pv数
              每个省份中的每个栏目的pv数
       从这些需求中可以看出，同一个指标，可以通过多种角度（口径）去统计！
       这些角度，或口径，就叫“维度！”

       维度组合中的维度越多，统计出来的事实指标粒度越细

3、维表举例

       栏目维度表：
       栏目id，栏目名称
       lm1,生鲜水产
       lm2,冲调饮品
       lm3,智能设备

       地域码维表：
       地域码 省 市
       11010 湖北省,武汉市
       01010 山西省,临汾市

       时间维表：
       日期 季度 周数 周几 销售季 活动期间
       2019-10-21 4 38 monday
       2019-10-21 4 38 monday

       维表的作用： 可以对统计维度进行人性化的诠释！可以丰富维度内容！

4、维度建模经典模型

星型模型

雪花模型

星座模型

二、数仓分层管理

       数仓分层： 就是将数仓中大量的表进行分层管理！

1、数仓分层概述

       数据仓库中的数据表，往往是分层管理、分层计算的：
               ADS层： 应用服务层
               DWS层：数仓汇总层
               DWD层：数仓明细层
               ODS层：操作数据（最原始的数据）层 – 贴源层

ODS层：对应着外部数据源ETL到数仓体系之后的表！
DWD层：数仓明细层；一般是对ODS层的表按主题进行加工和划分；本层中表记录的还是明细数据；
DWS层：数仓汇总层；
ADS层： 应用层，主要是一些结果报表！

2、分层思想示意图

分层的意义：数据管理更明晰！运算复用度更高！需求开发更快捷！便于解耦底层业务（数据）变化！

图示：什么叫运算复用！

分层的意义举例说明：
       – ods层 ： 贴源层，跟浏览日志结构保持一致

       – dwd层明细表 ： 对ods的某些字段进行了更进一步的细化，或者关联了一些额外信息
       user,session,page,lanmu,pinlei,pid,datetime,areacode
       u1,s1,/abc/dd,lm1,cat1,p01,2019-10-21 16:18:21,11010
       u1,s1,/bbb/cd,lm2,cat3,p08,2019-10-21 16:18:30,11010
       u2,s2,/aty/rt,lm3,cat5,p05,2019-10-21 16:17:21,01010
       u2,s2,/bbb/cd,lm2,cat3,p08,2019-10-21 16:19:30,01010
       u1,s3,/bbb/cd,lm2,cat3,p08,2019-10-21 16:18:30,11010

       --dws层: 会话聚合 dws_acc_agg_s
       用户 会话 pvs
       u1 s1 2
       u1 s3 1
       u2 s2 2
       --dws层: 用户聚合 dws_acc_agg_u
       用户 会话数 pvs
       u1 2 3
       u2 1 2

       有了上述模型，则：
       需求1： 日活总数
       需求2： 日访问总次数
       需求3： 日pv总数
       需求4： 日访问次数>2次的人
       需求5： 日访问pv数最高的前100人
       需求6： 日访问次数最高的前100人
       这些需求，都可以直接从dws_acc_agg_u得出

3、分层的原因

       1)、空间换时间（让大量运算任务可复用）

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

       2)、把复杂问题简单化

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

       3)、便于解耦 “底层业务（数据）的变化”对上层的影响

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

三、数仓建模理论

1、什么是数据模型

       数据模型是数据特征的抽象。数据是描述事物的符号记录，模型是现实世界的抽象。数据模型从抽象层次上描述了系统静态特征、动态行为和约束条件为数据库系统信息表示与操作提供了一个抽象的框架。简单讲数据模型就是数据组织和存放的方法，它强调从业务、数据存取和使用角度合理存储数据。
       数据模型所描述的内容有三部分：数据结构、数据操作、数据约束。
               数据结构：主要描述数据的类型、内容、性质以及数据间的联系等，是目标类型的集合。
               数据操作：主要描述在相 应的数据结构上的操作类型和操作方式。
               数据约束：主要描述数据结构内数据间的语法词义联系、他们之间的制约和依存关系，以及数据动态变化的规则，以保证数据的正确、有效和相容。它是完整性规则的集合，用以限定符合数据模型的数据库状态，以及状态的变化。约束条件可以按不同的原则划分为数据值的约束和数据间联系的约束；静态约束和动态约束；实体约束和实体间的参照约束等。

2、为什么要数据模型

       从性能、成本、效率、质量的角度看：
              性能：良好的数据模型能帮助我们快速查询所需要的数据，减少数据的I/O吞吐。
              成本：良好的数据模型能极大减少不必要的数据冗余，也能实现计算结果复用，极大地降低大数据系统中的存储和计算成本。
              效率：良好的数据模型能极大地改善用户使用数据的体验，提高使用数据的效率。
              质量：良好的数据模型能改善数据统计口径的不一致，减少数据计算错误的可能性。
              因此，毋庸置疑，大数据系统需要数据模型方法来帮助更好地组织和存储数据，以便在性能、成本、效率和质量之间取得最佳平衡。

       从业务和数仓建设的角度看：
              在数据仓库的建设中，我们一再强调需要数据模型，那么数据模型究竟为什么这么重要呢？首先我们需要了解整个数据仓库的建设的发展史。数据仓库的发展大致经历了这样的三个过程：
              简单的报表阶段：这个阶段，系统的主要目标是解决一些日常工作中业务人员需要的报表，以及生成一些简单的能够帮助领导进行决策所需要的汇总数据。这个阶段的大部分表现形式为数据库和前端报表工具。
              数据集市阶段：这个阶段主要是根据某个业务部门的需要，进行一定的数据的采集，整理，按照业务人员的需求，进行多维报表的展现，能够提供对特定业务指导的数据，并且能够提供特定的领导决策数据。
              数据仓库阶段：这个阶段主要是按照一定的数据模型，对整个企业的数据进行采集整理，并且能够按照各个业务部门的需要，提供跨部门的，完全一致的业务报表数据，能够通过数据仓库生成对业务具有指导性的数据，同时为领导决策提供全面的数据支持。

       通过对数据仓库建设的发展阶段，我们能够看出，数据仓库的建设和数据集市的建设的重要区别就在于数据模型的支持。因此，数据模型的建设，对于我们数据仓库的建设，有着决定性的意义。 一般来说，数据模型的建设主要能够帮助我们解决以下的一些问题：
              进行全面的业务梳理，改进业务流程。在业务模型建设的阶段，能够帮助我们的企业或者管理机构对本单位的业务进行全面的梳理。通过业务模型的建设，我们应该能够全面了解该单位的业务架构图和整个业务的运行情况，能够将业务按照特定的规律进行分门别类和程序化，同时，帮助我们进一步的改进业务的流程，提高业务效率，指导我们业务部门的生产。
              建设全方位的数据视角，消灭信息孤岛和数据差异。通过数据仓库的模型建设，能够为企业提供一个整体的数据视角，不再是各个部门只是关注自己的数据，而且通过模型的建设，勾勒出部门之间的联系，帮助消灭各部门之间的信息孤岛的问题，更为重要的是，通过数据模型的建设，能够保证这个企业的数据一致性，各个部门之间数据的差异将会得到有效解决。
              解决业务的变动和数据仓库的灵活性。通过数据模型的建设，能够很好的分离出底层技术的实现和上层业务的展现。当上层业务发生变化时，通过数据模型，底层的技术实现可以非常轻松的完成业务的变动，从而达到整个数据仓库的灵活性。
              帮助数据仓库系统本身的建设。通过数据仓库的模型建设，开发人员和业务人员能够很容易的达成系统建设范围的界定，以及长期目标的规划，从而能够使整个项目组明确当前的任务，加快这个系统建设的速度。

3、数据仓库建模阶段划分

从上图我们可以清楚地看出，数据仓库的数据建模大致分为四个阶段：
       1. 业务建模，这部分建模工作，主要包含以下几个部分：
              划分整个单位的业务，一般按照业务部门的划分，进行各个部分之间业务工作的界定，理清各业务部门之间的关系。
              深入了解各个业务部门内的具体业务流程并将其程序化。
              提出修改和改进业务部门工作流程的方法并程序化。
              数据建模的范围界定，整个数据仓库项目的目标和阶段划分。
       2. 领域概念建模，这部分的建模工作，主要包含以下几个部分：
              抽取关键业务概念，并将之抽象化。
              将业务概念分组，按照业务主线聚合类似的分组概念。
              细化分组概念，理清分组概念内的业务流程并抽象化。
              理清分组概念之间的关联，形成完整的领域概念模型。
       3. 逻辑建模，这部分的建模工作，主要包含以下几个部分：
              业务概念实体化，并考虑其具体的属性
              事件实体化，并考虑其属性内容
              说明实体化，并考虑其属性内容
       4. 物理建模，这部分得建模工作，主要包含以下几个部分：
              针对特定物理化平台，做出相应的技术调整
              针对模型的性能考虑，对特定平台作出相应的调整
              针对管理的需要，结合特定的平台，做出相应的调整
              生成最后的执行脚本，并完善之。
       从我们上面对数据仓库的数据建模阶段的各个阶段的划分，我们能够了解到整个数据仓库建模的主要工作和工作量，希望能够对我们在实际的项目建设有所帮助

4、数据仓库建模方法论

       1)、范式建模法

              范式建模法其实是我们在构建数据模型常用的一个方法，该方法的主要由 Inmon 所提倡，主要解决关系型数据库得数据存储，利用的一种技术层面上的方法。目前，我们在关系型数据库中的建模方法，大部分采用的是三范式建模法。

范式是数据库逻辑模型设计的基本理论，一个关系模型可以从第一范式到第五范式进行无损分解，这个过程也可称为规范化。在数据仓库的模型设计中目前一般采用第三范式，它有着严格的数学定义。从其表达的含义来看，一个符合第三范式的关系必须具有以下三个条件 :
1、每个属性值唯一，不具有多义性 ;
2、每个非主属性必须完全依赖于整个主键，而非主键的一部分 ;
3、每个非主属性不能依赖于其他关系中的属性，因为这样的话，这种属性应该归到其他关系中去。

              由于范式是基于整个关系型数据库的理论基础之上发展而来的，因此，本人在这里不多做介绍，有兴趣的读者可以通过阅读相应的材料来获得这方面的知识。

       根据 Inmon 的观点，数据仓库模型的建设方法和业务系统的企业数据模型类似。在业务系统中，企业数据模型决定了数据的来源，而企业数据模型也分为两个层次，即主题域模型和逻辑模型。同样，主题域模型可以看成是业务模型的概念模型，而逻辑模型则是域模型在关系型数据库上的实例。

从业务数据模型转向数据仓库模型时，同样也需要有数据仓库的域模型，即概念模型，同时也存在域模型的逻辑模型。这里，业务模型中的数据模型和数据仓库的模型稍微有一些不同。主要区别在于：
1、数据仓库的域模型应该包含企业数据模型的域模型之间的关系，以及各主题域定义。数据仓库的域模型的概念应该比业务系统的主题域模型范围更加广。
2、在数据仓库的逻辑模型需要从业务系统的数据模型中的逻辑模型中抽象实体，实体的属性，实体的子类，以及实体的关系等。

       以笔者的观点来看，Inmon 的范式建模法的最大优点就是从关系型数据库的角度出发，结合了业务系统的数据模型，能够比较方便的实现数据仓库的建模。但其缺点也是明显的，由于建模方法限定在关系型数据库之上，在某些时候反而限制了整个数据仓库模型的灵活性，性能等，特别是考虑到数据仓库的底层数据向数据集市的数据进行汇总时，需要进行一定的变通才能满足相应的需求。因此，笔者建议读者们在实际的使用中，参考使用这一建模方式。

       2)、维度建模法

               维度建模法简单描述就是按照事实表、维度表来构建数仓、集市。维度建模从分析决策的需求出发构建模型，为分析需求服务，因此它重点关注用户如何更快速地完成需求分析，同时具有较好的大规模复杂查询的相应性能。其典型的代表是星型模型，以及在一些特殊场景下使用的雪花模型。

维度建模的优缺点：
优点，以星型模型为例子，其针对各个维度做了大量的预处理，如按照维度进行预先的统计、分类、排序等，从而极大的提升数据仓库的处理能力；另一个优点是维度建模非常直观，紧紧围绕着业务模型，可以直观的反映出业务模型中的业务问题。不需要经过特别的抽象处理，即可以完成维度建模。
缺点，由于在构建星型模式之前需要进行大量的数据预处理，因此会导致大量的数据处理工作。而且，当业务发生变化，需要重新进行维度的定义时，往往需要重新进行维度数据的预处理。而在这些预处理过程中，往往会导致大量的数据冗余；另外一个维度建模法的缺点就是，如果只是依靠单纯的维度建模，不能保证数据来源的一致性和准确性，而且在数据仓库的底层，不是特别适用于维度建模的方法。

               所以维度建模的领域主要适用于数据集市层，它的最大的作用其实是为了解决数据仓库建模中的性能问题。维度建模很难能够提供一个完整地描述真实业务实体之间的复杂关系的抽象方法

维度建模大致分为一下几个步骤：
1.选择需要进行分析决策的业务过程。业务过程可以是单个业务时间，比如交易的支付、退款等；也可以是某个事件的状态，比如当前的账户余额等；还可以是一系列相关业务时间组成的业务流程，具体需要看我们分析的是某些时间发生情况，还是当前状态或是时间流转效率
2.选择粒度。在事件分析中，我们需要预判所有分析需求细分的程度，从而决定选择的粒度，粒度是维度的一个组合。
3.识别维表。选择好粒度之后，就需要基于粒度设计维表，包括维度属性，用于分析时进行分组和筛选。
4.选择事实。确定分析需要衡量的指标。

       3)、Data Vault建模

Data Vault 是ER模型的衍生，其设计的出发点也是为了实现数据的整合，但不能直接用于数据分析决策，它强调建立一个可审计的基础数据层，也就是强调数据的历史性、可追溯性和原子性，而不要求对数据进行过度的一致性处理和整合；同时它基于主题概念将企业数据进行结果化组织，并引入了更进一步的范式处理来优化模型以应对源系统变更的扩展性。Data Vault模型由以下几部分组成。
1、Hub：是企业的核心业务实体，由实体key、数据仓库序列代理键、装载时间、数据来源组成。
2、Link：代表Hub之间的关系。这里与ER模型最大的区别是将关系作为一个独立的单元抽象，可以提升模型的扩展性。它可以直接描述1:1、1:n、n:n的关系，而不需要做任何变更。它由Hub的代理键、装载时间、数据来源组成。
3、Satellite：是Hub的详细描述内容，一个Hub可以有多个Satellite。它由Hub代理键、装载时间、数据来源、详细的Hub描述信息组成。

              Data Vault 模型比ER模型更容易设计和产出，它的ETL加工可实现配置化。Hub可以想像成人的骨架，那么Link就是链接骨架的韧带，Satellite是骨架上的血和肉

       4)、Anchor 建模

              Anchor 对Data Vault模型做了进一步规范化处理，初衷是设计一个高度可扩展的模型，其核心思想是所有的扩展只是添加而不是修改，一次将模型规范到6NF，基本变成了K-V结构化模型。Anchor模型的组成。

Anchors：类似于Data Vault的Hub，代表业务实体，且只有主键。
Attributes：功能类似于Data Vault的Satellite，但是它更加规范化，将其全部K-V结构化，一个表只有一个Anchors的属性描述。
Ties：将是Anchors之间的关系，单独用表来描述，类似于Data Vault的Link，可以提升整体模型关系的扩展能力。
Knots：代表哪些可能会在多个Anchors中公用的属性的提炼，比如性别、状态等这种枚举类型且被公用的属性。

              在上述四个基本对象的基础上，又可以细化分为历史的和非历史的，其中历史的会以时间戳加多条记录的方式记录数据的变迁历史。Anchor模型的创建者以此方式来获取极大的可扩展性，但是也会增加非常多的查询join操作，创建者的观点是，数据仓库中的分析查询只是基于一小部分字段进行的，类似于列存储结构，可以大大减少数据扫描，从而对查询性能影响较小。一些有数据表裁剪特性的数据库如MariaDB 的出现，会大量减少join操作。但实际情况是不是如此还有带商榷。

5、数据仓库建设流程

       1)、数据调研

               略

       2)、业务调研

              数据仓库是要涵盖所有业务领域，还是各个业务领域独自建设，业务领域内的业务线也同样面临着这个问题。所以要构建大数据数据仓库，就需要了解各个业务领域、业务线的业务有什么共同点和不同点，以及各个业务线可以细分为哪几个业务模块，每个业务模块具体的业务流程又是怎样的。业务调研是否充分，将会直接决定数据仓库建设是否成功。

       3)、需求调研

              了解业务系统的业务后不等于说就可以实施数仓建设了，还需要收集数据使用者的需求，及找分析师、运营人员、产品人员等了解他们对数据的诉求。通常需求调研分下面两种途径：
              1.根据与分析师、运营人员、产品人员的沟通获取需求。
              2.对现有报表、数据进行研究分析获取数据建设需求。

例：保险数仓需求指标：

       4)、调研方法论

---

本项目教程笔记源自多易教育《Titan综合数据仓库与数据运营系统》，在CSDN学院有相关视频教程购买链接，大数据企业级项目实战–Titan大型数据运营系统
本项目课程是一门极具综合性和完整性的大型大数据项目实战课程，课程项目的业务背景源自各类互联网公司对海量用户浏览行为数据和业务数据分析的需求及企业数据管理、数据运营需求。
学完本课程，你将很容易就拿到大数据数仓建设或用户画像建设等岗位的OFFER

本课程项目涵盖数据采集与预处理、数据仓库体系建设、用户画像系统建设、数据治理（元数据管理、数据质量管理）、任务调度系统、数据服务层建设、OLAP即席分析系统建设等大量模块，力求原汁原味重现一个完备的企业级大型数据运营系统。

跟随项目课程，历经接近100+小时的时间，从需求分析开始，到数据埋点采集，到预处理程序代码编写，到数仓体系搭建…逐渐展开整个项目的宏大视图，构建起整个项目的摩天大厦。