为您推荐:
精华内容
最热下载
问答
  • 5星
    159KB weixin_44020886 2021-02-17 08:48:00
  • 5星
    64.58MB qq_45934521 2021-07-06 15:02:14
  • 5星
    487.12MB weixin_44802353 2021-05-23 12:32:22
  • 5星
    906KB qq_54433450 2021-07-24 11:47:14
  • 5星
    1.97MB weixin_44573410 2021-02-10 14:40:20
  • 5星
    2.28MB qq_40957277 2021-06-22 18:53:14
  • 5星
    216KB weixin_51390582 2021-09-19 13:49:34
  • 5星
    29KB m0_52957036 2020-04-29 07:50:59
  • 5星
    36KB Guanam2020 2021-10-14 19:41:09
  • 5星
    3.52MB wenyusuran 2021-03-26 09:54:09
  • 数据仓库建模在数据仓库建设中有很重要的地位,是继业务梳理后的第二大要点,是将概念模型转化为物理模型的一个过程。关于建模一向被吹得神乎其神,相关介绍文章以及招聘需求中对此都要求很高,那么了解主流的建模...

    数据仓库建模在数据仓库建设中有很重要的地位,是继业务梳理后的第二大要点,是将概念模型转化为物理模型的一个过程。关于建模一向被吹得神乎其神,相关介绍文章以及招聘需求中对此都要求很高,那么了解主流的建模方法和各自的优劣势以及应用场景就变得至关重要了。

    选择合适的建模方法要考虑几点要素,分别是:性能、成本、效率和质量,性能是能够快速的查询所需的数据,减少数据IO的吞吐;成本是减少不必要的冗余,实现计算结果的复用,减少大数据系统的计算成本和存储成本;效率则是改善使用数据的效率,计算、查询效率也算在内;质量是改善数据统计口径的不一致性,减少数据计算错误的可能性,提供高质量、一致性的数据访问平台。在实际应用中则会根据这几点要素所占权重的不同来选择合适的建模方法。

    ER模型

    将事务抽象为“实体”、“属性”和“关系”来表示数据的关联和事物的描述,这种对事务的抽象建模通常称为 E-R 实体关系模型。数据仓库之父Bill Inmon提出的建模方法,从全企业的高度设计一个 3NF 模型,用实体关系( Entity Relationship )模型来描述企业业务,满足 3NF。

    数据仓库的 3NF 与 OLTP 系统中的 3NF 的区别在于,它是站在企业角度面向主题的抽象,而不是针对某个具体的业务流程。采用 E-R模型建设数据仓库模型的出发点是整合数据,对各个系统的数据以整个企业角度按主题进行相似的组合和合并,并进行一致性处理,为数据分析决策服务,但是并不能直接用于分析决策。

    作为一种标准的数据建模方案,它的实施周期非常长,一致性和扩展性比较好,能经得起时间的考验。但是随着企业数据的高速增长、复杂化,数仓如果全部使用 E-R 模型进行建模就显得越来越不适合现代化复杂、多变的业务组织,因此一般只有在数仓底层 ODS、DWD 会采用 E-R 关系模型进行设计。

    维度建模

    维度建模是数据仓库领域另一位大师 Ralph Kimball 所倡导,是数据仓库工程领域最流行的数仓建模经典。维度建模以分析决策的需求出发构建模型,构建的数据模型为分析需求服务,因此它重点解决用户如何更快速完成分析需求,同时还有较好的大规模复杂查询的响应性能。维度建模是专门用于分析型数据库、数据仓库、数据集市建模的方法。

    维度建模的主要构成是维度表和事实表。每一张维度表对应现实世界中的一个对象或者一个主题,例如:客户、产品、时间、地区等,通常是包含了多个属性的列,通常数据量不会太大;事实表则是描述业务的多条记录,包含了描述业务的度量值以及和维度表相关联的外键,外键和维度表通常是多对多的关系,数据量大而且经常发生变化。

    维度建模一般包含三个,一般是根据业务需求和业务复杂性加以区分,有区分的方法但没有比较清晰地界限。分别是星型模型、雪花模型和星座模型。

    星型模型

    星型模式(Star Schema)是面向主题的常用模式,主要由一个事实表和多个维度表构成,不存在二级维度表

    星型模式

    雪花模型

    雪花模型(Snowflake Schema)是在星型模型基础上将维表再次扩展,每个维表可以继续向外连接多个子维表。

    雪花模型
    雪花模型相当于将星型模型的大维表拆分成小维表,满足了规范化设计,因为很少会有事实表只关联一层维度的,往往维度还会细分,钻取。然而这种模式在实际应用中很少见,因为跨表查询时效率很慢,所以现在的做法是将部分维度表整合到事实表中,形成宽表,在查询汇总的时候只需要group by就可以了,不需要再进行join操作。

    星座模型

    星座模型(Fact Constellations Schema)也是星型模型的扩展,存在多个事实表且可共用同一个维表。实际上数仓模型建设后期,大部分维度建模都是星座模型。

    星座模型
    前面介绍的两种维度建模方法都是多维表对应单事实表,但在很多时候维度空间内的事实表不止一个,而一个维表可能被多个事实表用到。在业务发展的后期,绝大部分维度建模都采用的都是星座模型。

    Data Vault模型

    Data Vault 是 Dan Linstedt 发起创建的一种模型,它是 E-R 模型的衍生,其设计的出发点也是为了实现数据的整合,但不能直接用于数据分析决策。主要在对自然界中发现的复杂网络建模。

    Data Vault 是面向细节的,可追踪历史的,一组有连接关系的规范化的表的集合。这些表可以支持一个或多个业务功能。从建模风格上看,它采用了一种由第三范式方法(3NF)与维度建模方法混合而成的方式,以二者的独特组合来满足企业需求。

    同时它基于主题概念将企业数据进行结构化组织,并引入了更进一步的范式处理来优化模型,以应对源系统变更的扩展性。 Data Vault 型由以下几部分组成:

    • Hub - 中心表:是企业的核心业务实体,由实体 Key、数仓序列代理键、装载时间、数据来源组成,不包含非键值以外的业务数据属性本身。
    • Link - 链接表:代表 Hub 之间的关系,一个链接表意味着两个或多个中心表之间有关联。这里与 ER 模型最大的区别是将关系作为一个独立的单元抽象,可以提升模型的扩展性。它可以直接描述 1:1、1:2 和 n:n 的关系,而不需要做任何变更。它由 Hub 的代理键、装载时间、数据来源组成。
    • Satellite - 卫星表:数仓中数据的主要载体,包括对链接表、中心表的数据描述、数值度量等信息。Anchor 模型

    Data Vault
    Data Vault 模型比 E-R 模型更容易设计和产出,它的 ETL 加工可实现配置化。我们可以将 Hub 想象成人的骨架,那么 Link 就是连接骨架的韧带,而 SateIIite 就是骨架上面的血肉。

    Anchor模型

    Anchor 是对 Data Vault 模型做了进一步的规范化处理,它的核心思想是所有的扩展只是添加而不是修改,因此将模型规范到6NF,基本变成了 k-v 结构化模型。

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

    由于过度规范化,使用中牵涉到太多的Join操作,这里我们就仅作了解。

    MOLAP

    MOLAP区别于以上几种建模方法,适用于 ADS 层。它是将数据进行预结算,并将结果存到 CUBE 模型中,在查询的时候效率就会快很多。CUBE模型以多维数组的形式,存储在系统中,加快后续的查询,但是需要耗费巨大的时间和空间成本,维度预处理可能会导致数据膨胀。

    CUBE
    常见的MOLAP产品有KylinDruid,其中Kylin使用的会比较多一点,它是将数据仓库中的数据抽取过来进行维度组合,加工成CUBE后存储到Hbase数据库(Hbase具有并发能力,所以查询性能会很高)中,业务端或者前端需要数据的时候Kylin则会从Hbase中将数据取出并返回。

    kylin_diagram
    以上就是几种主流的建模方向,针对每一种建模方法还会有不少的细节问题,留到后面详细讨论。学习一项新技术就是要由上而下,由总体到局部抽丝剥茧,化繁为简。

    展开全文
    m0_61192794 2021-09-26 17:04:12
  • 数据仓库建模方法及企业数据中台建设。

    一、数据仓库建模方法

    每个行业有自己的模型,但是 不同行业的数据模型,在数据建模的方法上,却都有着共通的基本特点。

    什么是数据模型?

    数据模型是抽象描述现实世界的一种工具和方法,是通过抽象的实体及实体之间联系的形式,来表示现实世界中事务的相互关系的一种映射。
    在这里,数据模型表现的抽象的是实体和实体之间的关系,通过对实体和实体之间关系的定义和描述,来表达实际的业务中具体的业务关系。
    数据仓库模型是数据模型中针对特定的数据仓库应用系统的一种特定的数据模型,一般来说,我们数据仓库模型分为几下几个层次。

    通过上面的图形,我们能够很容易的看出在整个数据仓库得建模过程中,我们需要经历一般四个过程:

    • 业务建模,生成业务模型,主要解决业务层面的分解和程序化。
    • 领域建模,生成领域模型,主要是对业务模型进行抽象处理,生成领域概念模型。
    • 逻辑建模,生成逻辑模型,主要是将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化。
    • 物理建模,生成物理模型,主要解决,逻辑模型针对不同关系型数据库的物理化以及性能等一些具体的技术问题。

    因此,在整个数据仓库的模型的设计和架构中,既涉及到业务知识,也涉及到了具体的技术,我们既需要了解丰富的行业经验,同时,也需要一定的信息技术来帮助我们实现我们的数据模型,最重要的是,我们还需要一个非常适用的方法论,来指导我们自己针对我们的业务进行抽象,处理,生成各个阶段的模型。

    为什么需要数据模型?

    在数据仓库的建设中,我们一再强调需要数据模型,那么数据模型究竟为什么这么重要呢?首先我们需要了解整个数据仓库的建设的发展史。
    数据仓库的发展大致经历了这样的三个过程:

    • 简单报表阶段:这个阶段,系统的主要目标是解决一些日常的工作中业务人员需要的报表,以及生成一些简单的能够帮助领导进行决策所需要的汇总数据。这个阶段的大部分表现形式为数据库和前端报表工具。
    • 数据集市阶段:这个阶段,主要是根据某个业务部门的需要,进行一定的数据的采集,整理,按照业务人员的需要,进行多维报表的展现,能够提供对特定业务指导的数据,并且能够提供特定的领导决策数据。
    • 数据仓库阶段:这个阶段,主要是按照一定的数据模型,对整个企业的数据进行采集,整理,并且能够按照各个业务部门的需要,提供跨部门的,完全一致的业务报表数据,能够通过数据仓库生成对对业务具有指导性的数据,同时,为领导决策提供全面的数据支持。

    通过数据仓库建设的发展阶段,我们能够看出,数据仓库的建设和数据集市的建设的重要区别就在于数据模型的支持。因此,数据模型的建设,对于我们数据仓库的建设,有着决定性的意义。
    一般来说,数据模型的建设主要能够帮助我们解决以下的一些问题:

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

    建设数据模型既然是整个数据仓库建设中一个非常重要的关键部分,那么,怎么建设我们的数据仓库模型就是我们需要解决的一个问题。这里我们将要详细介绍如何创建适合自己的数据模型。

    数据仓库数据模型架构

    数据仓库的数据模型的架构和数据仓库的整体架构是紧密关联在一起的,我们首先来了解一下整个数据仓库的数据模型应该包含的几个部分。从下图我们可以很清楚地看到,整个数据模型的架构分成 5 大部分,每个部分其实都有其独特的功能。

    从上图我们可以看出,整个数据仓库的数据模型可以分为大概 5 大部分:

    • 系统记录域(System of Record):这部分是主要的数据仓库业务数据存储区,数据模型在这里保证了数据的一致性。
    • 内部管理域(Housekeeping):这部分主要存储数据仓库用于内部管理的元数据,数据模型在这里能够帮助进行统一的元数据的管理。
    • 汇总域(Summary of Area):这部分数据来自于系统记录域的汇总,数据模型在这里保证了分析域的主题分析的性能,满足了部分的报表查询。
    • 分析域(Analysis Area):这部分数据模型主要用于各个业务部分的具体的主题业务分析。这部分数据模型可以单独存储在相应的数据集市中。
    • 反馈域(Feedback Area):可选项,这部分数据模型主要用于相应前端的反馈数据,数据仓库可以视业务的需要设置这一区域。

    通过对整个数据仓库模型的数据区域的划分,我们可以了解到,一个好的数据模型,不仅仅是对业务进行抽象划分,而且对实现技术也进行具体的指导,它应该涵盖了从业务到实现技术的各个部分。

    数据仓库建模阶段划分

    我们前面介绍了数据仓库模型的几个层次,下面我们讲一下,针对这几个层次的不同阶段的数据建模的工作的主要内容:

    从上图我们可以清楚地看出,数据仓库的数据建模大致分为四个阶段:

    1. 业务建模,这部分建模工作,主要包含以下几个部分:
    • 划分整个单位的业务,一般按照业务部门的划分,进行各个部分之间业务工作的界定,理清各业务部门之间的关系。
    • 深入了解各个业务部门的内具体业务流程并将其程序化。
    • 提出修改和改进业务部门工作流程的方法并程序化。
    • 数据建模的范围界定,整个数据仓库项目的目标和阶段划分。
    1. 领域概念建模,这部分得建模工作,主要包含以下几个部分:
    • 抽取关键业务概念,并将之抽象化。
    • 将业务概念分组,按照业务主线聚合类似的分组概念。
    • 细化分组概念,理清分组概念内的业务流程并抽象化。
    • 理清分组概念之间的关联,形成完整的领域概念模型。
    1. 逻辑建模,这部分的建模工作,主要包含以下几个部分:
    • 业务概念实体化,并考虑其具体的属性。
    • 事件实体化,并考虑其属性内容。
    • 说明实体化,并考虑其属性内容。
    1. 物理建模,这部分得建模工作,主要包含以下几个部分:
    • 针对特定物理化平台,做出相应的技术调整。
    • 针对模型的性能考虑,对特定平台作出相应的调整。
    • 针对管理的需要,结合特定的平台,做出相应的调整。
    • 生成最后的执行脚本,并完善之。

    从我们上面对数据仓库的数据建模阶段的各个阶段的划分,我们能够了解到整个数据仓库建模的主要工作和工作量,希望能够对我们在实际的项目建设能够有所帮助。

    数据仓库建模方法

    大千世界,表面看五彩缤纷,实质上,万物都遵循其自有的法则。数据仓库得建模方法同样也有很多种,每一种建模方法其实代表了哲学上的一个观点,代表了一种归纳,概括世界的一种方法。目前业界较为流行的数据仓库的建模方法非常多,这里主要介绍范式建模法,维度建模法,实体建模法等几种方法,每种方法其实从本质上讲就是从不同的角度看我们业务中的问题,不管从技术层面还是业务层面,其实代表的是哲学上的一种世界观。我们下面给大家详细介绍一下这些建模方法。

    1. 范式建模法(Third Normal Form ,3NF )

    范式建模法其实是我们在构建数据模型常用的一个方法,该方法的主要由 Inmon 所提倡,主要解决关系型数据库得数据存储,利用的一种技术层面上的方法。目前,我们在关系型数据库中的建模方法,大部分采用的是三范式建模法。
    范式是数据库逻辑模型设计的基本理论,一个关系模型可以从第一范式到第五范式进行无损分解,这个过程也可称为规范化。在数据仓库的模型设计中目前一般采用第三范式,它有着严格的数学定义。从其表达的含义来看,一个符合第三范式的关系必须具有以下三个条件:

    • 每个属性值唯一,不具有多义性;
    • 每个非主属性必须完全依赖于整个主键,而非主键的一部分;
    • 每个非主属性不能依赖于其他关系中的属性,因为这样的话,这种属性应该归到其他关系中去。

    由于范式是基于整个关系型数据库的理论基础之上发展而来的,因此,本人在这里不多做介绍,有兴趣的读者可以通过阅读相应的材料来获得这方面的知识。
    根据 Inmon 的观点,数据仓库模型得建设方法和业务系统的企业数据模型类似。在业务系统中,企业数据模型决定了数据的来源,而企业数据模型也分为两个层次,即主题域模型和逻辑模型。同样,主题域模型可以看成是业务模型的概念模型,而逻辑模型则是域模型在关系型数据库上的实例。

    从业务数据模型转向数据仓库模型时,同样也需要有数据仓库的域模型,即概念模型,同时也存在域模型的逻辑模型。这里,业务模型中的数据模型和数据仓库的模型稍微有一些不同。主要区别在于:

    • 数据仓库的域模型应该包含企业数据模型得域模型之间的关系,以及各主题域定义。数据仓库的域模型的概念应该比业务系统的主题域模型范围更加广。
    • 在数据仓库的逻辑模型需要从业务系统的数据模型中的逻辑模型中抽象实体,实体的属性,实体的子类,以及实体的关系等。

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

    1. 维度建模法

    维度建模法, Kimball 最先提出这一概念。其最简单的描述就是,按照事实表,维表来构建数据仓库,数据集市。这种方法的最被人广泛知晓的名字就是星型模式( Star-schema )。

    上图的这个架构中是典型的星型架构。星型模式之所以广泛被使用,在于针对各个维作了大量的预处理,如按照维进行预先的统计、分类、排序等。通过这些预处理,能够极大的提升数据仓库的处理能力。特别是针对 3NF 的建模方法,星型模式在性能上占据明显的优势。
    同时,维度建模法的另外一个优点是,维度建模非常直观,紧紧围绕着业务模型,可以直观的反映出业务模型中的业务问题。不需要经过特别的抽象处理,即可以完成维度建模。这一点也是维度建模的优势。但是,维度建模法的缺点也是非常明显的,由于在构建星型模式之前需要进行大量的数据预处理,因此会导致大量的数据处理工作。而且,当业务发生变化,需要重新进行维度的定义时,往往需要重新进行维度数据的预处理。而在这些与处理过程中,往往会导致大量的数据冗余。
    另外一个维度建模法的缺点就是,如果只是依靠单纯的维度建模,不能保证数据来源的一致性和准确性,而且在数据仓库的底层,不是特别适用于维度建模的方法。
    因此以笔者的观点看,维度建模的领域主要适用与数据集市层,它的最大的作用其实是为了解决数据仓库建模中的性能问题。维度建模很难能够提供一个完整地描述真实业务实体之间的复杂关系的抽象方法。

    1. 实体建模法

    实体建模法并不是数据仓库建模中常见的一个方法,它来源于哲学的一个流派。从哲学的意义上说,客观世界应该是可以细分的,客观世界应该可以分成由一个个实体,以及实体与实体之间的关系组成。那么我们在数据仓库的建模过程中完全可以引入这个抽象的方法,将整个业务也可以划分成一个个的实体,而每个实体之间的关系,以及针对这些关系的说明就是我们数据建模需要做的工作。
    虽然实体法粗看起来好像有一些抽象,其实理解起来很容易。即我们可以将任何一个业务过程划分成 3 个部分,实体,事件和说明,如下图所示:

    上图表述的是一个抽象的含义,如果我们描述一个简单的事实:“小明开车去学校上学”。以这个业务事实为例,我们可以把“小明”,“学校”看成是一个实体,“上学”描述的是一个业务过程,我们在这里可以抽象为一个具体“事件”,而“开车去”则可以看成是事件“上学”的一个说明。
    从上面的举例我们可以了解,我们使用的抽象归纳方法其实很简单,任何业务可以看成 3 个部分:

    • 实体,主要指领域模型中特定的概念主体,指发生业务关系的对象。
    • 事件,主要指概念主体之间完成一次业务流程的过程,特指特定的业务过程。
    • 说明,主要是针对实体和事件的特殊说明。

    由于实体建模法,能够很轻松的实现业务模型的划分,因此,在业务建模阶段和领域概念建模阶段,实体建模法有着广泛的应用。从笔者的经验来看,再没有现成的行业模型的情况下,我们可以采用实体建模的方法,和客户一起理清整个业务的模型,进行领域概念模型的划分,抽象出具体的业务概念,结合客户的使用特点,完全可以创建出一个符合自己需要的数据仓库模型来。
    但是,实体建模法也有着自己先天的缺陷,由于实体说明法只是一种抽象客观世界的方法,因此,注定了该建模方法只能局限在业务建模和领域概念建模阶段。因此,到了逻辑建模阶段和物理建模阶段,则是范式建模和维度建模发挥长处的阶段。
    因此,笔者建议读者在创建自己的数据仓库模型的时候,可以参考使用上述的三种数据仓库得建模方法,在各个不同阶段采用不同的方法,从而能够保证整个数据仓库建模的质量。

    数据仓库建模样例

    上面介绍得是一些抽象得建模方法和理论,可能理解起来相对有些难度,因此,笔者在这里举一个例子,读者可以跟着我们的这个样例,来初步了解整个数据仓库建模的大概过程。

    背景介绍

    熟悉社保行业的读者可以知道,目前我们国家的社保主要分为养老,失业,工伤,生育,医疗保险和劳动力市场这 6 大块主要业务领域。在这 6 大业务领域中,目前的状况养老和事业的系统已经基本完善,已经有一部分数据开始联网检测。而,对于工伤,生育,医疗和劳动力市场这一块业务,有些地方发展的比较成熟,而有些地方还不够成熟。

    1. 业务建模阶段

    基于以上的背景介绍,我们在业务建模阶段,就很容易来划分相应的业务。因此,在业务建模阶段,我们基本上确定我们本次数据仓库建设的目标,建设的方法,以及长远规划等。如下图:

    在这里,我们将整个业务很清楚地划分成了几个大的业务主线,例如:养老,失业,工伤,生育,医疗,劳动力等着几个大的部分,然后我们可以根据这些大的模块,在每个业务主线内,考虑具体的业务主线内需要分析的业务主题。
    因此,业务建模阶段其实是一次和业务人员梳理业务的过程,在这个过程中,不仅能帮助我们技术人员更好的理解业务,另一方面,也能够发现业务流程中的一些不合理的环节,加以改善和改进。
    同时,业务建模阶段的另一个重要工作就是确定我们数据建模的范围,例如:在某些数据准备不够充分的业务模块内,我们可以考虑先不建设相应的数据模型。等到条件充分成熟的情况下,我们可以再来考虑数据建模的问题。

    1. 领域概念建模阶段

    领域概念建模阶段是数据仓库数据建模的一个重要阶段,由于我们在业务建模阶段已经完全理清相应的业务范围和流程,因此,我们在这个领域概念建模阶段的最主要的工作就是进行概念的抽象,整个领域概念建模的工作层次如下图所示:

    从上图我们可以清楚地看到,领域概念建模就是运用了实体建模法,从纷繁的业务表象背后通过实体建模法,抽象出实体,事件,说明等抽象的实体,从而找出业务表象后抽象实体间的相互的关联性,保证了我们数据仓库数据按照数据模型所能达到的一致性和关联性。
    从图上看,我们可以把整个抽象过程分为四个层次,分别为:

    • 抽象方法层,整个数据模型的核心方法,领域概念建模的实体的划分通过这种抽象方法来实现。
    • 领域概念层,这是我们整个数据模型的核心部分,因为不同程度的抽象方法,决定了我们领域概念的不同。例如:在这里,我们可以使用“参与方”这个概念,同时,你也可以把他分成三个概念:“个人”,“公司”,和“经办机构”这三个概念。而我们在构建自己的模型的时候,可以参考业务的状况以及我们自己模型的需要,选择抽象程度高的概念或者是抽象程度低的概念。相对来说,抽象程度高的概念,理解起来较为复杂,需要专业的建模专家才能理解,而抽象程度低的概念,较适合于一般业务人员的理解,使用起来比较方便。笔者在这里建议读者可以选用抽象概念较低的实体,以方便业务人员和技术人员之间的交流和沟通。
    • 具体业务层,主要是解决具体的业务问题,从这张图我们可以看出,具体的业务层,其实只是领域概念模型中实体之间的一些不同组合而已。因此,完整的数据仓库的数据模型应该能够相应灵活多变的前端业务的需求,而其本身的模型架构具有很强的灵活性。这也是数据仓库模型所具备的功能之一。
    • 业务主线层,这个层次主要划分大的业务领域,一般在业务建模阶段即已经完成这方面的划分。

    我们一般通过这种大的业务主线来划分整个业务模型大的框架。
    通过领域概念建模,数据仓库的模型已经被抽象成一个个的实体,模型的框架已经搭建完毕,下面的工作就是给这些框架注入有效的肌体。

    1. 逻辑建模阶段

    通过领域概念建模之后,虽然模型的框架已经完成,但是还有很多细致的工作需要完成。一般在这个阶段,我们还需要做非常多的工作,主要包括:

    • 实例化每一个抽象的实体,例如:在上面的概念模型之后,我们需要对“人”和“公司”等这些抽象实体进行实例化。主要是,我们需要考虑“人”的属性包括那些,在业务模块中,用到的所有跟“人”相关的属性是哪些,我们都需要将这些属性附着在我们数据模型的“人”这个实体上,例如“人”的年龄,性别,受教育程度等等。同理,我们对其他属性同样需要做这个工作。
    • 找出抽象实体间的联系,并将其实例话。这里,我们主要考虑是“事件”这个抽象概念的实例化,例如:对于养老金征缴这个“事件”的属性得考虑,对于失业劳动者培训这个“事件”的属性得考虑等等。
    • 找出抽象事件的关系,并对其进行说明。在这里我们主要是要针对“事件”进行完善的“说明”。例如:对于“事件”中的地域,事件等因素的考量等等。

    总而言之,在逻辑建模阶段,我们主要考虑得是抽象实体的一些细致的属性。通过逻辑建模阶段,我们才能够将整个概念模型完整串联成一个有机的实体,才能够完整的表达出业务之间的关联性。
    在这个阶段,笔者建议大家可以参考 3NF 的建模方法,表达出实体的属性,以及实体与实体之间的联系。例如:在这个阶段,我们可以通过采用 ERWIN 等建模工具等作出符合 3NF 的关系型数据模型来。

    1. 物理建模阶段

    物理建模阶段是整个数据建模的最后一个过程,这个过程其实是将前面的逻辑数据模型落地的一个过程。考虑到数据仓库平台的不同,因此,数据模型得物理建模过程可能会稍微有一些不同,在这个阶段我们主要的工作是:

    • 生成创建表的脚本。不同的数据仓库平台可能生成不同的脚本。
    • 针对不同的数据仓库平台,进行一些相应的优化工作,例如对于 DB2 数据仓库来说,创建一些 MQT 表,来加速报表的生成等等。
    • 针对数据集市的需要,按照维度建模的方法,生成一些事实表,维表等工作。
    • 针对数据仓库的 ETL 车和元数据管理的需要,生成一些数据仓库维护的表,例如:日志表等。

    经过物理建模阶段,整个数据仓库的模型已经全部完成,我们可以按照自己的设计来针对当前的行业创建满足自己需要的数据模型来。

    二、企业数据中台建设

    1、为什么需要数据中台

    1.1 数据中台的由来

    随着互联网的高速发展,背后对数据的需求越来越多,数据的应用场景也越来越多。大规模数据的应用,也逐渐暴露出一些问题。业务发展前期,为了快速实现业务的需求,烟囱式的开发导致企业不同业务线,甚至相同业务线的不同应用之间,数据都是割裂的。两个数据应
    用的相同指标,展示的结果不一致,导致运营对数据的信任度下降。数据割裂的另外一个问题,就是大量的重复计算、开发,导致的研发效率的浪费,计算、存储资源的浪费,大数据的应用成本越来越高。这些问题的根源在于,数据无法共享。
    于是乎在2016 年,阿里巴巴率先提出了“数据中台”的口号。2018、2019数据中台在各行业开始不断崛起。数据中台的核心,是避免数据的重复计算,通过数据服务化,提高数据的共享能力,赋能数据应用以及企业的数智化发展。

    1.2 数据中台是什么

    数据中台是一套“让企业数据用起来”的机制,是一套能持续不断把数据变成资产并服务共享于业务的机制。

    数据中台是指通过数据技术,对全域数据(结构化数据和非结构化数据)进行采集汇聚、存储、计算、加工,同时统一数据标准和口径、规范数据质量和安全权限,最终将资产通过服务共享开放出去,进而为客户提供高效服务,赋能各类型的数据应用。
    数据中台的宗旨,是避免数据的重复计算,消除数据标准和口径不一致的问题 , 通过数据服务化,提高数据的共享能力,赋能数据应用,加速企业的数据价值变现。

    1.3 数据中台与传统数仓的区别
    维度传统数据仓库数据中台
    数据来源业务数据库全域数据包括业务数据、日志数据、埋点数据、爬虫数据、IOT数据等
    数据格式结构化数据结构化、半结构化、非结构化数据
    数据资产缺少数据标准化、规范化数据标准化、规范化,统一技术标准和口径,减少重复造轮子
    数据计算离线离线+实时
    数据应用BI报表为主,主要以数据本身的方式开放灵活服务于前台,主要以数据服务共享的方式开放
    数据价值数据质量较低,取数效率较低、成本较高数据质量较高,取数效率较高、成本较低,离业务更近,数据化驱动智能运营
    1.4 数据中台的价值

    数据中台改变了企业原来利用数据的形式(传统数仓、BI) , 通过业务数据化、数据资产化、资产服务化、服务业务化的四化良性高效闭环,加速了从数据资源到数据资产到价值变现的过程,提高了企业的业务响应力、创新力、价值力。通过降本增效,数据化智能运营,打造出数据驱动的智能化企业,从而更高效的为企业创造更多的价值。

    2、哪些企业适合做数据中台

    不可否认,数据中台的构建需要非常大的投入:

    • 一方面数据中台的建设离不开系统支撑,研发系统需要投入大量的人力,而这些系统是否能够匹配中台建设的需求,还需要持续打磨。
    • 另外一方面,面对大量的数据需求,要花费额外的人力去做数据模型的重构,也需要下定决心。

    所以数据中台的建设,需要结合企业的现状,根据需要进行选择。我认为企业在选择数据中台的时候,应该考虑这样几个因素:

    1. 企业是否有大量的数据应用场景: 数据中台本身并不能直接产生业务价值,数据中台的本质是支撑快速地孵化数据应用。所以当你的企业有较多数据应用的场景时(一般有3个以上就可以考虑)。
    2. 经过了快速的信息化建设,企业存在较多的业务数据的孤岛,需要整合各个业务系统的数据,进行关联的分析,此时,你需要构建一个数据中台。
    3. 当你的团队正在面临效率、质量和成本的苦恼时,面对大量的开发,却不知道如何提高效能,数据经常出问题而束手无策,老板还要求你控制数据的成本,这个时候,数据中台可以帮助你。
    4. 当你所在的企业面临经营困难,需要通过数据实现精益运营,提高企业的运营效率的时候,你需要构建一个数据中台,同时结合可视化的BI数据产品,实现数据从应用到中台的完整构建,这种类型往往出现在传统企业中。
    5. 企业规模也是必须要考虑的一个因素,数据中台因为投入大,收益偏长线,所以更适合业务相对稳定的大公司,并不适合初创型的小公司。

    如果你的公司有以上几个特征,基本不要怀疑,请把数据中台提上日程吧。

    3、数据中台建设方法论与策略

    关于数据中台的建设,目前并没有一个标准的解决方案,也没有一个数据中台能适用于所有的公司,每个公司都应该结合自己的业务规模及数据需求现状来研发适合自己公司的数据中台。阿里是最早提出中台概念的,阿里数据中台的3One建设体系(OneId、OneData、OneService)也成了业界建设数据中台的主要参考方法论,这里我们大概介绍下,并推荐一些建设策略供大家参考。

    3.1 阿里3 One体系

    3.2 相关建设策略

    4、数据中台建设方案

    4.1 整体架构

    4.2 元数据
    4.2.1 元数据包括哪些

    4.2.2 元数据中心整体架构

    目前开源方案有:Netflix Metacat(数据字典采集) 、Apache Atlas(数据血缘采集)。我们设计时可以参考借鉴开源的部分实现思路。

    4.3 数据地图

    数据地图是基于元数据中心构建的一站式企业数据资产目录,可以看作是元数据中心的界面。数据开发、分析师、数据运营、算法工程师都可以在数据地图上进行数据的检索,解决了“不知道有哪些数据?”“到哪里找数据?”“如何准确的理解数据”的难题。
    主要功能有:

    1. 支持根据标签(主题域、分层信息、指标)、表名、字段名等进行检索;
    2. 支持表级和字段级检索;
    3. 数据总览目录支持按技术资产、业务资产、指标资产等目录进行下钻导览;
    4. 表详细信息包括表的基础信息,字段信息、分区信息、产出信息以及数据血缘信息等。

    数据资产目录:

    数据检索:

    表详情:

    4.4 指标管理


    4.5 数据模型规范设计
    4.5.1 数仓模型介绍


    说明:

    1. 数据贴源层ODS:基本保持和业务数据源的表结构、表记录数一致,相当于是原始数据的备份;
    2. 数据公共层CDM:包括明细层DWD和汇总层DWS,以及公共维度DIM DWD的明细事实表和DIM的维表数据由ODS层加工而成。DWS一般是公共指标数据,由DWD明细事实表和维表进行汇总加工而成。数据公共层主要采用维度建模方法作为理论基础,更多地采用维度退化手法,将维度退化到事实表中,减少事实表与维表的关联,提高明细数据表的易用性,比如可以将事实表设计为复合结构的宽表;同时在汇总数据层,加强指标的维度退化,采取更多地宽表化手段构建公共指标数据层,提升公共指标的复用性,减少重复加工。主要功能如下:
    • 组合相关与相似的数据:数据清理整合、规范化,形成明细宽表,同一份数据要归一(DWD);
    • 公共指标统一加工:构建命名规范、口径一致和算法统一的统计指标(DWS);
    • 建立一致性维度:建立一致的数据分析维表,降低数据计算口径,算法不一的风险(DIM);
    1. 数据应用层ADS:存放数据产品应用需要的个性化的统计指标数据,一般不直接作为服务对外提供;
    2. 要避免跨层调用或逆向调用,如ODS层数据只能被DWD层调用。
    4.5.2 表命名规范
    所在层表命名规范例子
    ODSods_业务系统数据库名_业务系统数据库表名_分区规则ods_crm_order_info_dd
    DWD、DWS、ADS层次_主题域_业务过程_内容描述_分区规则dwd_wms_instock_item_info_di
    DIMdim_主题域_维度定义_分区规则dim_wms_area_type_dd

    4.5.3 涉及相关功能

    4.5.4 模型设计步骤


    部分流程说明:

    1. 划分主题域,构建总线矩阵:
      主题域是业务过程的抽象集合。

    构建总线矩阵需要明确每个主题域下有哪些业务过程,业务过程与哪些维度相关,并定义每个主题域下的业务过程和维度。

    1. 模型设计

    A)构建一致性维表:
    在维度建模中,通常将指标的度量称之为“事实”,将产生度量的环境称之为“维度”。将描述同一个业务实体的的多个维度列组合在一起,就是常说的“维度表”。维度表通常就是指业务过程中的一些基础业务实体信息(比如:商品、用户、时间、区域等),实体的属性,比如商品类别、商品品牌就是维度属性。维度表一般由【代理键、自然键、维度属性】三部分构成。

    • 代理键:不具有任何业务含义,仅做维度表数据唯一性区分的属性,通常以主键形式出现,代理键根据场景需要再使用。
    • 自然键:具有业务含义,是业务实体一个实例的唯一性区分(如,商品ID),在维度表中不一定做表的主键。

    B)构建事实表:

    4.6 数据质量
    4.6.1 如何提升数据质量

    最重要的是能做到:早发现、早恢复,做到数据全链路各环节多层级的质量监控保护体系。
    早发现:要能够先于数据使用方发现数据的问题,尽可能在出现问题的源头发现问题,这样就为“早恢复”争取到了大量的时间。
    早恢复:要缩短故障恢复的时间,降低故障对数据产出的影响。
    一般通过以下的方式去执行:

    1. 事前定义监控规则
    2. 事中监控和控制数据生产过程
    3. 事后分析和问题跟踪闭环
    4.6.2 数据质量稽核规则

    稽核规则的完整性:优先保障核心指标、核心表、重要工作流的监控,日常再不断完善。

    4.6.3 建立全链路数据质量监控

    4.6.4 数据质量中心DQC架构

    4.7 成本优化

    4.8 数据服务
    4.8.1 数据服务架构

    4.8.2 查询引擎选择

    4.9 实时数仓

    5、业界数据中台介绍资料

    5.1 华为云dayu介绍

    华为云智能数据运营平台: https://support.huaweicloud.com/wtsnew-dayu/index.html

    5.2 阿里数据中台介绍

    Maxcompute:https://help.aliyun.com/product/27797.html?spm=5176.7944453.751670.btn11.2ebc52dfUOpjI7
    Dataworks:
    https://help.aliyun.com/product/72772.html?spm=5176.10695662.881989.3.4da72bf7ggpQpS

    dataworks 公开课 : https://blog.csdn.net/weixin_34124577/article/details/89590494
    dataworks核心技术讲解:
    https://yq.aliyun.com/download/2377?do=login&accounttraceid=b05fbf4d1f154cb486c74bc64ed87540pewc

    5.3 网易数据中台介绍

    网易数据中台实践: https://pan.baidu.com/s/1rXm0F2TvM4dh2TFNg-b4Xg 提取码: 9t3p

    5.4 转转数据中台介绍

    转转数据中台架构:https://ppt.infoq.cn/slide/show?cid=57&pid=2717

    展开全文
    gongxifacai_believe 2021-01-17 13:21:33
  • 今天的大数据开发分享,我们主要来讲讲数据仓库建模方法与模型。 数仓建模方法 数据仓库中几种经典的数据模型,包括关系建模、维度建模、DataVault模型。在实际工作中,通常会根据业务场景选择一种或几种模型。 1...

    大数据平台当中的数据仓库,往往需要通过建模来更好地对数据进行存储和管理,这其中涉及到性能、成本、效率、质量等多方面的综合考量,对于工程师来说,也需要细细规划。今天的大数据开发分享,我们主要来讲讲数据仓库建模方法与模型。

    数仓建模方法

    数据仓库中几种经典的数据模型,包括关系建模、维度建模、DataVault模型。在实际工作中,通常会根据业务场景选择一种或几种模型。

    1、关系建模

    关系建模,是数据仓库之父Inmon推崇的,被称为“实体-关系”模型,以一种“标准化”的方式存在,强调数据之间非冗余,满足3NF。关系建模是站在企业角度面向主题的抽象,而不是针对某个具体业务流程的实体对象关系抽象。它更多用于数据的整合和一致性质量。

    2、维度建模

    维度建模,Ralph Kimball博士最先提出这一概念。其最简单的描述就是,按照事实表、维表来构建数据仓库、数据集市。这种方法很多人称之为星形模型。之所以称为星形模型是因为它的表示方法是以一颗“星”为中心,周围围绕着其他数据结构,如下图。

    星形模型的中心是一张事实表。事实表是包含大量数据值的一种结构。事实表的周围是维表,用来描述事实表的某个重要方面。维表里的数据量要比事实表里的少。

    星形模型之所以广泛被使用,在于针对各个维作了大量的预处理,比如按照维进行了预先的排序、分类、统计等。通过这些预处理,能够极大地提升数据仓库的处理能力。特别是针对3NF的建模方法,星形模型在性能上占据明显的优势。因此,星形模型仅适用于小范围数据(如一个部门或甚至一个子部门)。

    通常星形模型只包含一张事实表。但是在数据库设计中要创建一种雪花结构的复合结构,需要多张事实表结合。如下图,描绘了一个雪花模型。

    在雪花模型中,不同的事实表通过共享一个或多个公共维表连接起来。有时称这些共享的维表为一致维表。

    维度建模的最大优点在于访问的高效性。如果设计适当,通过星形连接将数据传递给最终用户是非常高效的。为了提高传递信息的效率,必须收集并吸收最终用户的请求。最终用户使用数据的过程是要定义什么样的多维结构的核心。一旦清楚了最终用户的请求,这些请求就可以用来最终确定星形模型,形成最理想的结构。

    3、Data Vault模型

    Data Vault是另一种数据仓库建模方法,是Dan Linstedt在20世纪90年代提出的,主要用于企业级的数据仓库建模。

    Data Vault需要跟踪所有数据的来源,因此其中每个数据行都要包含数据来源和装载时间属性,用以审计和跟踪数据值对应的源系统。

    Data Vault不区分数据在业务层面的正确与错误,它保留操作型系统的所有时间的所有数据,装载数据时不做数据验证、清洗等工作,这点明显有别于其他数据仓库建模方法。

    Data Vault是对ER模型更近一步的规范化,由于对数据的拆解更偏向于基础数据组织,在处理分析类场景时相对复杂,适合数据仓库底层构建,目前实际应用场景较少。

    关于大数据开发,数据仓库建模方法与模型,以上就为大家做了简单的介绍了。数据仓库建模,是数仓设计当中的重要阶段,根据实际的应用需求,选择合适的方法与模型,是工程师必备的能力之一。

    展开全文
    shuimuzh123 2021-01-26 18:09:57
  • 实体:Entity,关系:Relationship,这种对数据的抽象建模通常被称为ER实体关系模型 实体:通常为参与到过程中的主体,客观存在的,比如商品、仓库、货位、汽车,此实体非数据库的实体表 属性:对主体的描述、修饰即...

    一、ER实体模型

    概念

    定义:在信息系统中,将事物抽象为“实体”、“属性”、“关系”来表示数据关联和事物描述;实体:Entity,关系:Relationship,这种对数据的抽象建模通常被称为ER实体关系模型

    实体:通常为参与到过程中的主体,客观存在的,比如商品、仓库、货位、汽车,此实体非数据库的实体表

    属性:对主体的描述、修饰即为属性,比如商品的属性有商品名称、颜色、尺寸、重量、产地等

    关系:现实的物理事件是依附于实体的,比如商品入库事件,依附实体商品、货位,就会有“库存”的属性产生;用户购买商品,依附实体用户、商品,就会有“购买数量”、“金额”的属性产品。

    实体之间建立关系时,存在对照关系:
    1:1 ,即1对1的关系,比如实体人、身份证,一个人有且仅有一个身份证号
    1:n,即1对多的关系,比如实体学生、班级,对于某1个学生,仅属于1个班级,而在1个班级中,可以有多个学生
    n:m,即多对多的关系,比如实体学生、课程,每个学生可以选修多门课程,同样每个课程也可以被多门学生选修

    案例

    场景:课程管理系统
    该系统主要用来管理某校教师、学生、课程,其中包括课程选修、考试、教师授课、学生班级管理功能,现需要完成数据库逻辑模型设计

    • ER
      在这里插入图片描述
    • IDEF1X
      在这里插入图片描述

    应用场景

    ER模型是数据库设计的理论基础,当前几乎所有的OLTP系统设计都采用ER模型建模的方式
    Bill Inom提出的数仓理论,推荐采用ER关系模型进行建模
    BI架构提出分层架构,数仓底层ods、dwd也多采用ER关系模型就行设计

    二、维度建模

    概念

    维度建模将数据仓库中的表划分为事实表、维度表两种类型。维度建模最被人广泛知晓的一种方式就是星型模式。

    维度 : 度量的环境,用来反映业务的一类属性。

    顾名思义,看待事物的角度。比如从颜色、尺寸的角度来比较手机的外观,从cpu、内存等较比比较手机性能。

    维度表一般为单一主键,在ER模型中,实体为客观存在的事物,会带有自己的描述性属性,属性一般为文本性、描述性的,这些描述被称为维度。

    比如商品,单一主键:商品ID,属性包括产地、颜色、材质、尺寸、单价等,但并非属性一定是文本,比如单价、尺寸,均为数值型描述性的,日常主要的维度抽象包括:时间维度表、地理区域维度表等。

    比如:
    在这里插入图片描述

    在这里插入图片描述

    事实表 : 维度模型的基本表,每个数据仓库都包含一个或者多个事实数据表。

    阿里巴巴电商系对于维度建模有一些非常好的扩展补充,例如维度表可以分为快照维表、缓慢变化维表等,事实表可以分为事务事实表、周期快照事实表和累计快照事实表。

    在ER模型中抽象出了有实体、关系、属性三种类别,在现实世界中,每一个操作型事件,基本都是发生在实体之间的,伴随着这种操作事件的发生,会产生可度量的值,而这个过程就产生了一个事实表,存储了每一个可度量的事件。如:一次购买事件,涉及主体包括客户、商品、商家,产生的可度量值=包括商品数量、金额、件数等。

    设计步骤

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

    案例

    某电商平台,经常需要对订单进行分析,以某宝的购物订单为例,以维度建模的方式设计该模型

    涉及到事实表为订单表、订单明细表,维度包括商品维度、用户维度、商家维度、区域维度、时间维度

    商品维度:商品ID、商品名称、商品种类、单价、产地等
    用户维度:用户ID、姓名、性别、年龄、常住地、职业、学历等
    时间维度:日期ID、日期、周几、上/中/下旬、是否周末、是否假期等
    优惠券:券ID、券类别、优惠金额

    订单中包含的度量:商品件数、总金额、总减免
    描述性属性:下单时间、结算时间、订单状态等
    订单明细包含度量:商品ID、件数、单价、减免金额
    描述性熟悉:入购物车时间、状态

    建模
    在这里插入图片描述

    星型模型和雪花模型

    维度建模通常又分为星型模型、雪花模型

    在这里插入图片描述

    所以由上可以看出,星型模型和雪花模型主要区别就是对维度表的拆分,对于雪花模型,维度表的涉及更加规范,一般符合3NF;而星型模型,一般采用降维的操作,利用冗余来避免模型过于复杂,提高易用性和分析效率

    上面的案例,对于商品再拆分出厂家、品类;用户的常住地再拆分出区域维度,改造为雪花模型
    在这里插入图片描述

    雪花和星型对比

    冗余:雪花模型符合业务逻辑设计,采用3NF设计,有效降低数据冗余;星型模型的维度表设计不符合3NF,反规范化,维度表之间不会直接相关,牺牲部分存储空间

    性能:雪花模型由于存在维度间的关联,采用3NF降低冗余,通常在使用过程中,需要连接更多的维度表,导致性能偏低;星型模型反三范式,采用降维的操作将维度整合,以存储空间为代价有效降低维度表连接数,性能较雪花模型高

    ETL:雪花模型符合业务ER模型设计原则,在ETL过程中相对简单,但是由于附属模型的限制,ETL任务并行化较低;星型模型在设计维度表时反范式设计,所以在ETL过程中整合业务数据到维度表有一定难度,但由于避免附属维度,可并行化处理

    三、dataValue模型

    概念

    Data Vault是在ER模型的基础上衍生而来,Data Vault模型是一种中心辐射式模型,模型设计的初衷是有效的组织基础数据层,使之易扩展、灵活的应对业务的变化,同时强调历史性、可追溯性和原子性,不要求对数据进行过度的一致性处理;并非针对分析场景所设计。

    Data Vault模型更容易设计,ETL过程中更易配置化实现。Hub想像成人体的骨架,那么Link就是连接骨架的韧带组织,
    而satelite就是骨架上的血肉。Data Vault是对ER模型更近一步的规范化,由于对数据的拆解和更偏向于基础数据组织,在处理分析类场景时相对复杂,适合数仓低层构建,目前实际应用场景较少

    基本结构

    中心表-HUB

    唯一业务键的列表,唯一标识企业实际业务,企业的业务主体集合

    只包含业务主键信息以及数据装载的描述,不包含非键值以外的业务数据属性本身;比如中心表商品,在DataVault如下,商品属性以及描述信息,都属于卫星表的范畴
    在这里插入图片描述

    链接表-Link

    表示中心表之间的关系,通过链接表串联整个企业的业务关联关系

    链接表用来描述中心表间的关联关系,亦不包含业务键值以及数据装载描述以外的任何非键值数据,比如学生选课链接表,其设计如下,与选课相关的课时数等描述信息,都属于卫星表的范畴。
    在这里插入图片描述

    卫星表- Satellite

    历史的描述性数据,数据仓库中数据的真正载体

    数仓中数据的主要载体,包括对链接表、中心表的数据描述、数值度量等信息,中心表商品、订单明细的卫星表
    分别如下:
    在这里插入图片描述

    案例

    对上面已经讨论到的学生选课ER模型,进行DataVault模型重构,ER原模型如下:
    在这里插入图片描述
    重构原则:
    I. 梳理所有主要实体
    II. 将有入边的实体定义为中心表
    III. 将没有入边切仅有一个出边的表定义为中心表
    IV. 源库中没有入边且有两条或以上出边的表定义为连接表
    V. 将外键关系定义为链接表

    改造完后的大概模型
    在这里插入图片描述

    四、Anchor

    概念

    Anchor是对Data Vault模型做了更近一步的规范会处理,初衷是为了设计高度可扩展的模型,核心思想是所有的扩张只添加而不修改,于是设计出的模型基本变成了k-v结构的模型,模型范式达到了6NF由于过度规范化,使用中牵涉到太多的join操作,目前木有实际案例,仅作了解

    基本结构

    Anchors

    类似Data Valut的Hub,代表业务实体且只有主键

    Attributes

    类似Data Valut的Satellite,但更加规范化,将其全部K-V结构化,一个表只有一个属性描述

    Ties

    类似Data Valut的Link,就是Anchors之间的关系

    Knots

    代表那些可能会在多个Anchors中公用的属性的提炼,比如说性别,状态等这种枚举类型且被公用的属性

    在以上四个基本对象的基础上,又可以细分为历史和非历史的,其中非历史的会以事件戳加多条记录的方式来记录数据的变迁历史。

    五、总结

    以上为四种基本的建模方法,当前主流建模方法为:ER模型、维度模型

    ER模型常用于OLTP数据库建模,应用到构建数仓时更偏重数据整合,站在企业整体考虑,将各个系统的数据按相似性一致性、合并处理,为数据分析、决策服务,但并不便于直接用来支持分析。
    问题:

    • 需要全面梳理企业所有的业务和数据流
    • 实施周期长
    • 对建模人员要求高

    维度建模是面向分析场景而生,针对分析场景构建数仓模型;重点关注快速、灵活的解决分析需求,同时能够提供大规模数据的快速响应性能。针对性强,主要应用于数据仓库构建和OLAP引擎低层数据模型。
    问题

    • 不需要完整的梳理企业业务流程和数据
    • 实施周期根据主题边界而定,容易快速实现demo

    在这里插入图片描述

    展开全文
    qq_27501147 2021-03-14 13:23:53
  • zhangziliang09 2018-02-07 17:53:44
  • WindyQCF 2021-01-05 07:08:00
  • u010002184 2021-01-23 18:42:34
  • m0_45204457 2021-03-17 20:40:04
  • yezonggang 2021-01-28 20:56:49
  • BeiisBei 2021-05-01 14:01:51
  • Shockang 2021-04-18 08:28:59
  • Stray_Lambs 2021-07-05 17:24:20
  • qq_40486089 2021-02-24 15:43:51
  • qq_39880483 2021-07-24 08:34:49
  • henku449141932 2021-02-03 09:04:13
  • Vincent_69 2021-02-17 00:13:04
  • u011250186 2021-09-26 17:14:45
  • weixin_44441757 2021-06-16 09:00:22
  • ytp552200ytp 2021-06-08 17:06:54
  • leaeason 2021-10-13 09:54:54
  • qq_36998916 2021-03-22 16:20:12
  • henku449141932 2021-01-27 11:34:37
  • u014538143 2021-12-17 09:29:59
  • qq_39437513 2021-05-22 00:56:37
  • weixin_45727359 2021-08-08 00:30:51
  • rlnLo2pNEfx9c 2021-08-10 00:07:28

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 32,478
精华内容 12,991
关键字:

数据仓库建模方法