精华内容
下载资源
问答
  • 仓库对公司的重要性
    千次阅读
    2022-03-15 15:19:13

    — 总结自一个课程
    一.为什么数据分析重要
    在实际工作中无论是专业的数据分析岗位,还是运营、产品等岗位都开始关注从业者的数据分析能力,运营需要通过数据分析来解决流量、用户增长问题;产品需要利用数据分析解决业务增长需求。无论你处于什么岗位,具备数据分析思维后,可以利用数据挖掘业务价值,也可以更宏观的审视公司业务创造更高的个人价值。
    二.哪些岗位会用到数据分析这项技能
    目前国内的很多公司中,数据分析岗位的职责划分其实还不是很清晰。业务有问题了,找数据分析师;数据有问题,找数据分析师;运营有问题,找数据分析师;产品有问题,还找数据分析师。
    三.数据分析的岗位有哪些种类
    1.岗位种类
    从工作性质上区分:主要分为数据工程师、商业分析师、业务分析师、产品分析师。
    从工作流程和内容上区分:主要是取数员、数据采集工程师、ETL工程师、数据运维工程师、数据算法工程师、业务分析师、可视化工程师。
    2.每种岗位介绍
    (1)数据工程师
    数据工程师包含的岗位很多,主要负责数据仓库、数据中台、数据模型,等等,主要的工作也是根据具体的职责来定的,很多人最后走专业技术线一般都会转到工程师。
    (2)商业分析师
    商业分析师一般来说都是研究行业数据和竞品数据,然后研究企业发展、为公司决策者提供战略决策指导意见的。这个岗位不仅要熟悉业务,还要熟悉行业,对技术的要求不是很高。
    (3)产品分析师
    产品分析师主要负责对产品的数据收集,深度分析和挖掘,为公司运营决策、产品方向、销售策略、媒体投放策略提供数据支持等。
    (4)取数员
    我们俗称的“表哥表姐”就是取数员,属于数据分析最初级的岗位,工作内容就是利用 SQL 等数据采集工具从数据库中进行数据采集。
    (5)数据采集工程师
    数据采集工程师属于取数员的高级岗位,这个岗位除了面对数据库数据之外,通常还需要进行脚本数据、网页数据、产品功能数据等的获取采集工作。
    (6)ETL工程师
    主要面对数据库、数据中心或者数据平台,主要的工作内容就是负责数据从数据库提取出来之后的清洗工作,比如切片、切块、细分等。
    (7)数据运维工程师
    在数据平台上需要数据维护人员,初级岗位是数据运维工程师,主要负责数据平台的管理,任务调度等。
    (8)数据挖掘工程师
    主要工作内容是在数据建模阶段对数据进行算法处理,比如常见的推荐算法、挖掘算法、聚类算法,等等。其中数据算法工程师属于数据挖掘工程师的高级岗位,该岗位主要是对整个数据部门的数据进行管理,脱离了数据挖掘的技术岗位性质,而成为管理岗位的性质。
    (9)业务分析师
    主要是针对具体的业务问题,完成“业务问题定位”-“数据采集”-“数据加工”-“数据处理”-“数据可视化”-“方案落地”的全过程,为业务部门或者公司提供决策依据。
    (10)可视化工程师
    可视化工程师是数据分析当中比较特殊的岗位,其更看重工具的使用,主要职责是利用 FineBI 等工具进行数据的可视化展示,比如报表可视化、大屏可视化、报告可视化等工作。

    更多相关内容
  • 数据仓库介绍

    千次阅读 2022-05-10 14:42:20
    它出于分析报告和决策支持目的而创建。 为需要业务智能的企业,提供指导业务流程改进、监视时间、成本、质量以及控制。 数据仓库的特点 1.数据仓库的数据是面向主题的 与传统数据库面向应用进行数据组织的特点...

                             数据仓库简介

    1. 什么是数据仓库

    数据仓库,英文名称为Data Warehouse,可简写为DW或DWH。数据仓库,是为企业所有级别的决策制定过程,提供所有类型数据支持的战略集合。它出于分析性报告和决策支持目的而创建。 为需要业务智能的企业,提供指导业务流程改进、监视时间、成本、质量以及控制。

    1. 数据仓库的特点

    1.数据仓库的数据是面向主题的

    与传统数据库面向应用进行数据组织的特点相对应,数据仓库中的数据是面向主题进行组织的。什么是主题呢?首先,主题是一个抽象的概念,是较高层次上企业信息系统中的数据综合、归类并进行分析利用的抽象。在逻辑意义上,它是对应企业中某一宏观分析领域所涉及的分析对象。面向主题的数据组织方式,就是在较高层次上对分析对象的数据的一个完整、一致的描述,能完整、统一地刻划各个分析对象所涉及的企业的各项数据,以及数据之间的联系。所谓较高层次是相对面向应用的数据组织方式而言的,是指按照主题进行数据组织的方式具有更高的数据抽象级别。

       2. 数据仓库的数据是集成的

            数据仓库的数据是从原有的分散的数据库数据抽取来的。操作型数据与DSS分析型数据之间差别甚大。第一,数据仓库的每一个主题所对应的源数据在原有的各分散数据库中有许多重复和不一致的地方,且来源于不同的联机系统的数据都和不同的应用逻辑捆绑在一起;第二,数据仓库中的综合数据不能从原有的数据库系统直接得到。因此在数据进入数据仓库之前,必然要经过统一与综合,这一步是数据仓库建设中最关键、最复杂的一步,所要完成的工作有:
        (1)要统一源数据中所有矛盾之处,如字段的同名异义、异名同义、单位不统一、字长不一致,等等。
        (2)进行数据综合和计算。数据仓库中的数据综合工作可以在从原有数据库抽取 数据时生成,但许多是在数据仓库内部生成的,即进入数据仓库以后进行综合生成的。

       3. 数据仓库的数据是不可更新的

             数据仓库的数据主要供企业决策分析之用,所涉及的数据操作主要是数据查询,一般情况下并不进行修改操作。数据仓库的数据反映的是一段相当长的时间内历史数据的内容,是不同时点的数据库快照的集合,以及基于这些快照进行统计、综合和重组的导出数据,而不是联机处理的数据。数据库中进行联机处理的数据经过集成输入到数据仓库中,一旦数据仓库存放的数据已经超过数据仓库的数据存储期限,这些数据将从当前的数据仓库中删去。因为数据仓库只进行数据查询操作,所以数据仓库管理系统相比数据库管理系统而言要简单得多。数据库管理系统中许多技术难点,如完整性保护、并发控制等等,在数据仓库的管理中几乎可以省去。但是由于数据仓库的查询数据量往往很大,所以就对数据查询提出了更高的要求,它要求采用各种复杂的索引技术;同时由于数据仓库面向的是商业企业的高层管理者,他们会对数据查询的界面友好性和数据表示提出更高的要求。

        4. 数据仓库的数据是随时间不断变化的

                   数据仓库中的数据不可更新是针对应用来说的,也就是说,数据仓库的用户进行分析处理时是不进行数据更新操作的。但并不是说,在从数据集成输入数据仓库开始到最终被删除的整个数据生存周期中,所有的数据仓库数据都是永远不变的。
        数据仓库的数据是随时间的变化而不断变化的,这是数据仓库数据的第四个特征。这一特征表现在以下3方面:
        (1)数据仓库随时间变化不断增加新的数据内容。数据仓库系统必须不断捕捉OLTP数据库中变化的数据,追加到数据仓库中去,也就是要不断地生成OLTP数据库的快照,经统一集成后增加到数据仓库中去;但对于确实不再变化的数据库快照,如果捕捉到新的变化数据,则只生成一个新的数据库快照增加进去,而不会对原有的数据库快照进行修改。
        (2)数据仓库随时间变化不断删去旧的数据内容。数据仓库的数据也有存储期限,一旦超过了这一期限,过期数据就要被删除。只是数据仓库内的数据时限要远远长于操作型环境中的数据时限。在操作型环境中一般只保存有60~90天的数据,而在数据仓库中则需要保存较长时限的数据(如5~10年),以适应DSS进行趋势分析的要求。
        (3)数据仓库中包含有大量的综合数据,这些综合数据中很多跟时间有关,如数据经常按照时间段进行综合,或隔一定的时间片进行抽样等等。这些数据要随着时间的变化不断地进行重新综合。因此,数据仓库的数据特征都包含时间项,以标明数据的历史时期。

     

     

    1. 数据仓库发展历程

    数据仓库的发展大致经历了这样的三个过程:

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

    通过数据仓库建设的发展阶段,我们能够看出,数据仓库的建设和数据集市的建设的重要区别就在于数据模型的支持。因此,数据模型的建设,对于我们数据仓库的建设,有着决定性的意义。

     

    1. 数据库与数据仓库的区别

    了解数据库与数据仓库的区别之前,首先掌握三个概念。数据库软件、数据库、数据仓库。

    数据库软件:是一种软件,可以看得见,可以操作。用来实现数据库逻辑功能。属于物理层。

    数据库:是一种逻辑概念,用来存放数据的仓库。通过数据库软件来实现。数据库由很多表组成,表是二维的,一张表里可以有很多字段。字段一字排开,对应的数据就一行一行写入表中。数据库的表,在于能够用二维表现多维关系。目前市面上流行的数据库都是二维数据库。如:Oracle、DB2、MySQL、Sybase、MS SQL Server等。

    数据仓库:是数据库概念的升级。从逻辑上理解,数据库和数据仓库没有区别,都是通过数据库软件实现的存放数据的地方,只不过从数据量来说,数据仓库要比数据库更庞大得多。数据仓库主要用于数据挖掘和数据分析,辅助领导做决策。

    在IT的架构体系中,数据库是必须存在的。必须要有地方存放数据。比如现在的网购,淘宝,京东等等。物品的存货数量,货品的价格,用户的账户余额之类的。这些数据都是存放在后台数据库中。或者最简单理解,我们现在微博,QQ等账户的用户名和密码。在后台数据库必然有一张user表,字段起码有两个,即用户名和密码,然后我们的数据就一行一行的存在表上面。当我们登录的时候,我们填写了用户名和密码,这些数据就会被传回到后台去,去跟表上面的数据匹配,匹配成功了,你就能登录了。匹配不成功就会报错说密码错误或者没有此用户名等。这个就是数据库,数据库在生产环境就是用来干活的。凡是跟业务应用挂钩的,我们都使用数据库。

    数据仓库则是BI下的其中一种技术。由于数据库是跟业务应用挂钩的,所以一个数据库不可能装下一家公司的所有数据。数据库的表设计往往是针对某一个应用进行设计的。比如刚才那个登录的功能,这张user表上就只有这两个字段,没有别的字段了。但是这张表符合应用,没有问题。但是这张表不符合分析。比如我想知道在哪个时间段,用户登录的量最多?哪个用户一年购物最多?诸如此类的指标。那就要重新设计数据库的表结构了。对于数据分析和数据挖掘,我们引入数据仓库概念。数据仓库的表结构是依照分析需求,分析维度,分析指标进行设计的。

    数据库与数据仓库的区别实际讲的是OLTP与OLAP的区别。

    操作型处理,叫联机事务处理OLTP(On-Line Transaction Processing,),也可以称面向交易的处理系统,它是针对具体业务在数据库联机的日常操作,通常对少数记录进行查询、修改。用户较为关心操作的响应时间、数据的安全性、完整性和并发支持的用户数等问题。传统的数据库系统作为数据管理的主要手段,主要用于操作型处理。

    分析型处理,叫联机分析处理OLAP(On-Line Analytical Processing)一般针对某些主题的历史数据进行分析,支持管理决策。

    3497a4082f8f5525056898b45abbce0c.png

    1. 数据仓库架构分层

    数据仓库标准上可以分为四层:ODS(临时存储层)、PDW(数据仓库层)、DM(数据集市层)、APP(应用层)。

    81c9bf292acb4e37877ea71ce14d9d41.png

     

     

      ODS层:

    为临时存储层,是接口数据的临时存储区域,为后一步的数据处理做准备。一般来说ODS层的数据和源系统的数据是同构的,主要目的是简化后续数据加工处理的工作。从数据粒度上来说ODS层的数据粒度是最细的。ODS层的表通常包括两类,一个用于存储当前需要加载的数据,一个用于存储处理完后的历史数据。历史数据一般保存3-6个月后需要清除,以节省空间。但不同的项目要区别对待,如果源系统的数据量不大,可以保留更长的时间,甚至全量保存;

     

     

    PDW层:

    为数据仓库层,PDW层的数据应该是一致的、准确的、干净的数据,即对源系统数据进行了清洗(去除了杂质)后的数据。这一层的数据一般是遵循数据库第三范式的,其数据粒度通常和ODS的粒度相同。在PDW层会保存BI系统中所有的历史数据,例如保存10年的数据。

     

    DM层:

    为数据集市层,这层数据是面向主题来组织数据的,通常是星形或雪花结构的数据。从数据粒度来说,这层的数据是轻度汇总级的数据,已经不存在明细数据了。从数据的时间跨度来说,通常是PDW层的一部分,主要的目的是为了满足用户分析的需求,而从分析的角度来说,用户通常只需要分析近几年(如近三年的数据)的即可。从数据的广度来说,仍然覆盖了所有业务数据。

     

     

    APP层:

    为应用层,这层数据是完全为了满足具体的分析需求而构建的数据,也是星形或雪花结构的数据。从数据粒度来说是高度汇总的数据。从数据的广度来说,则并不一定会覆盖所有业务数据,而是DM层数据的一个真子集,从某种意义上来说是DM层数据的一个重复。从极端情况来说,可以为每一张报表在APP层构建一个模型来支持,达到以空间换时间的目的数据仓库的标准分层只是一个建议性质的标准,实际实施时需要根据实际情况确定数据仓库的分层,不同类型的数据也可能采取不同的分层方法。

     

    为什么要对数据仓库分层:

    1用空间换时间,通过大量的预处理来提升应用系统的用户体验(效率),因此数据仓库会存在大量冗余的数据;

     

    2如果不分层的话,如果源业务系统的业务规则发生变化将会影响整个数据清洗过程,工作量巨大

     

    3通过数据分层管理可以简化数据清洗的过程,因为把原来一步的工作分到了多个步骤去完成,相当于把一个复杂的工作拆成了多个简单的工作,把一个大的黑盒变成了一个白盒,每一层的处理逻辑都相对简单和容易理解,这样我们比较容易保证每一个步骤的正确性,当数据发生错误的时候,往往我们只需要局部调整某个步骤即可。

     

    1. 元数据介绍

    当需要了解某地企业及其提供的服务时,电话黄页的重要性就体现出来了。元数据(Metadata)类似于这样的电话黄页。

    1.元数据的定义

        数据仓库的元数据是关于数据仓库中数据的数据。它的作用类似于数据库管理系统的数据字典,保存了逻辑数据结构、文件、地址和索引等信息。广义上讲,在数据仓库中,元数据描述了数据仓库内数据的结构和建立方法的数据。

          元数据是数据仓库管理系统的重要组成部分,元数据管理器是企业级数据仓库中的关键组件,贯穿数据仓库构建的整个过程,直接影响着数据仓库的构建、使用和维护。

    (1)构建数据仓库的主要步骤之一是ETL。这时元数据将发挥重要的作用,它定义了源数据系统到数据仓库的映射、数据转换的规则、数据仓库的逻辑结构、数据更新的规则、数据导入历史记录以及装载周期等相关内容。数据抽取和转换的专家以及数据仓库管理员正是通过元数据高效地构建数据仓库。

    (2)用户在使用数据仓库时,通过元数据访问数据,明确数据项的含义以及定制报表。

    (3)数据仓库的规模及其复杂性离不开正确的元数据管理,包括增加或移除外部数据源,改变数据清洗方法,控制出错的查询以及安排备份等。

          元数据可分为技术元数据和业务元数据。技术元数据为开发和管理数据仓库的IT 人员使用,它描述了与数据仓库开发、管理和维护相关的数据,包括数据源信息、数据转换描述、数据仓库模型、数据清洗与更新规则、数据映射和访问权限等。而业务元数据为管理层和业务分析人员服务,从业务角度描述数据,包括商务术语、数据仓库中有什么数据、数据的位置和数据的可用性等,帮助业务人员更好地理解数据仓库中哪些数据是可用的以及如何使用。

    由上可见,元数据不仅定义了数据仓库中数据的模式、来源、抽取和转换规则等,而且是整个数据仓库系统运行的基础,元数据把数据仓库系统中各个松散的组件联系起来,组成了一个有机的整体,如图3.5 所示

    1e3bfa74c2927e1a850c169c88bc4d2d.png

     

    2.元数据的存储方式

         元数据有两种常见存储方式:一种是以数据集为基础,每一个数据集有对应的元数据文件,每一个元数据文件包含对应数据集的元数据内容;另一种存储方式是以数据库为基础,即元数据库。其中元数据文件由若干项组成,每一项表示元数据的一个要素,每条记录为数据集的元数据内容。上述存储方式各有优缺点,第一种存储方式的优点是调用数据时相应的元数据也作为一个独立的文件被传输,相对数据库有较强的独立性,在对元数据进行检索时可以利用数据库的功能实现,也可以把元数据文件调到其他数据库系统中操作;不足是如果每一数据集都对应一个元数据文档,在规模巨大的数据库中则会有大量的元数据文件,管理不方便。第二种存储方式下,元数据库中只有一个元数据文件,管理比较方便,添加或删除数据集,只要在该文件中添加或删除相应的记录项即可。在获取某数据集的元数据时,因为实际得到的只是关系表格数据的一条记录,所以要求用户系统可以接受这种特定形式的数据。因此推荐使用元数据库的方式。

          元数据库用于存储元数据,因此元数据库最好选用主流的关系数据库管理系统。元数据库还包含用于操作和查询元数据的机制。建立元数据库的主要好处是提供统一的数据结构和业务规则,易于把企业内部的多个数据集市有机地集成起来。目前,一些企业倾向建立多个数据集市,而不是一个集中的数据仓库,这时可以考虑在建立数据仓库(或数据集市)之前,先建立一个用于描述数据、服务应用集成的元数据库,做好数据仓库实施的初期支持工作,对后续开发和维护有很大的帮助。元数据库保证了数据仓库数据的一致性和准确性,为企业进行数据质量管理提供基础。

     

    3.元数据的作用

          在数据仓库中,元数据的主要作用如下。

    (1)描述哪些数据在数据仓库中,帮助决策分析者对数据仓库的内容定位。

    (2)定义数据进入数据仓库的方式,作为数据汇总、映射和清洗的指南。

    (3)记录业务事件发生而随之进行的数据抽取工作时间安排。

    (4)记录并检测系统数据一致性的要求和执行情况。

    (5)评估数据质量。

              

     

     

    1. 什么是数据模型

      数据模型是抽象描述现实世界的一种工具和方法,是通过抽象的实体及实体之间联系的形式,来表示现实世界中事务的相互关系的一种映射。在这里,数据模型表现的抽象的是实体和实体之间的关系,通过对实体和实体之间关系的定义和描述,来表达实际的业务中具体的业务关系。

    数据仓库模型是数据模型中针对特定的数据仓库应用系统的一种特定的数据模型,一般的来说,我们数据仓库模型分为几下几个层次,如图 2 所示。

    2. 数据仓库模型

    858b39cc0984486ca38959862547fe19.png

     

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

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

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

     

    1. 为什么需要数据仓库模型

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

    数据仓库的发展大致经历了这样的三个过程:

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

    通过数据仓库建设的发展阶段,我们能够看出,数据仓库的建设和数据集市的建设的重要区别就在于数据模型的支持。因此,数据模型的建设,对于我们数据仓库的建设,有着决定性的意义。

    一般来说,数据模型的建设主要能够帮助我们解决以下的一些问题:

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

     

    1. 如何建设数据仓库模型

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

    3.1  数据仓库数据模型架构

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

    3. 数据仓库数据模型架构

    ab8810d80cb4423ba4063c224a8c40a1.png

     

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

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

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

    3.2  数据仓库建模阶段划分

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

    4. 数据仓库建模阶段划分

    5360b8dd8af1465f9250b69cdd90a0dc.png

     

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

    1.   业务建模,这部分建模工作,主要包含以下几个部分:

    • 划分整个单位的业务,一般按照业务部门的划分,进行各个部分之间业务工作的界定,理清各业务部门之间的关系。
    • 深入了解各个业务部门的内具体业务流程并将其程序化。
    • 提出修改和改进业务部门工作流程的方法并程序化。
    • 数据建模的范围界定,整个数据仓库项目的目标和阶段划分。

    2.   领域概念建模,这部分得建模工作,主要包含以下几个部分:

    • 抽取关键业务概念,并将之抽象化。
    • 将业务概念分组,按照业务主线聚合类似的分组概念。
    • 细化分组概念,理清分组概念内的业务流程并抽象化。
    • 理清分组概念之间的关联,形成完整的领域概念模型。

    3.   逻辑建模,这部分的建模工作,主要包含以下几个部分:

    • 业务概念实体化,并考虑其具体的属性
    • 事件实体化,并考虑其属性内容
    • 说明实体化,并考虑其属性内容

    4.   物理建模,这部分得建模工作,主要包含以下几个部分:

    • 针对特定物理化平台,做出相应的技术调整
    • 针对模型的性能考虑,对特定平台作出相应的调整
    • 针对管理的需要,结合特定的平台,做出相应的调整
    • 生成最后的执行脚本,并完善之。

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

    3.4 数据仓库建模方法

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

    1. 范式建模法(Third Normal Form3NF

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

    范式是数据库逻辑模型设计的基本理论,一个关系模型可以从第一范式到第五范式进行无损分解,这个过程也可称为规范化。在数据仓库的模型设计中目前一般采用第三范式,它有着严格的数学定义。从其表达的含义来看,一个符合第三范式的关系必须具有以下三个条件 :

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

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

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

    5. 范式建模法

    7ebb009b0b7d4a618a263bfba4d03ed7.png

     

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

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

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

    2. 维度建模法

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

    6. 维度建模法

    d25da91a4d6e47fda481a4f3fe54164d.png

     

    上图的这个架构中是典型的星型架构。星型模式之所以广泛被使用,在于针对各个维作了大量的预处理,如按照维进行预先的统计、分类、排序等。通过这些预处理,能够极大的提升数据仓库的处理能力。特别是针对 3NF 的建模方法,星型模式在性能上占据明显的优势。

    同时,维度建模法的另外一个优点是,维度建模非常直观,紧紧围绕着业务模型,可以直观的反映出业务模型中的业务问题。不需要经过特别的抽象处理,即可以完成维度建模。这一点也是维度建模的优势。

    但是,维度建模法的缺点也是非常明显的,由于在构建星型模式之前需要进行大量的数据预处理,因此会导致大量的数据处理工作。而且,当业务发生变化,需要重新进行维度的定义时,往往需要重新进行维度数据的预处理。而在这些与处理过程中,往往会导致大量的数据冗余。

    另外一个维度建模法的缺点就是,如果只是依靠单纯的维度建模,不能保证数据来源的一致性和准确性,而且在数据仓库的底层,不是特别适用于维度建模的方法。

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

    3. 实体建模法

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

    虽然实体法粗看起来好像有一些抽象,其实理解起来很容易。即我们可以将任何一个业务过程划分成 3 个部分,实体,事件和说明,如下图所示:

    7. 实体建模法

    0b99c6fbd08c4785afa5401fb635ae28.png

     

    上图表述的是一个抽象的含义,如果我们描述一个简单的事实:“小明开车去学校上学”。以这个业务事实为例,我们可以把“小明”,“学校”看成是一个实体,“上学”描述的是一个业务过程,我们在这里可以抽象为一个具体“事件”,而“开车去”则可以看成是事件“上学”的一个说明。

    从上面的举例我们可以了解,我们使用的抽象归纳方法其实很简单,任何业务可以看成 3 个部分:

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

    由于实体建模法,能够很轻松的实现业务模型的划分,因此,在业务建模阶段和领域概念建模阶段,实体建模法有着广泛的应用。从笔者的经验来看,再没有现成的行业模型的情况下,我们可以采用实体建模的方法,和客户一起理清整个业务的模型,进行领域概念模型的划分,抽象出具体的业务概念,结合客户的使用特点,完全可以创建出一个符合自己需要的数据仓库模型来。

    但是,实体建模法也有着自己先天的缺陷,由于实体说明法只是一种抽象客观世界的方法,因此,注定了该建模方法只能局限在业务建模和领域概念建模阶段。因此,到了逻辑建模阶段和物理建模阶段,则是范式建模和维度建模发挥长处的阶段。

    因此,笔者建议读者在创建自己的数据仓库模型的时候,可以参考使用上述的三种数据仓库得建模方法,在各个不同阶段采用不同的方法,从而能够保证整个数据仓库建模的质量。

     

    数据仓库命名规范

                                                                                                                                                                  

     

    1. 概述

    数据模型是数据管理的分析工具和交流的有力手段;同时,还能够很好地保证数据的一致性,是实现商务智能(Business Intelligence)的重要基础。因此建立、管理一个企业级的数据模型,应该遵循标准的命名和设计规范。

     

     

    1. 数据仓库命名规范
      1. 命名规范
        1. 表属性规范
          1. 表名
            1. ODS层表名

    前缀为ODS_应用系统名(缩写)_数据表名 。数据表名称必须以有特征含义的单词或缩写组成,中间可以用“_”分割,例如:ODS_FUN_CUSTOMERINFO。表名称不能用双引号包含,表名长度不超过30个字符。如果ODS设计采用贴源设计,数据表名应与源系统一致。

    1. 系统和应用名规则如下:
      1. 核心       COR
      2. 对公信贷    CLN
      3. 个贷       PLN
      4. 基金       FUN
      5. 票据       TIC
      6. 理财        FIN
      7. 报表        RPT
      8. ……
      9. 如有新系统,按规则添加[s1] 
            1. DW事实表表名

    前缀为DW_主题名(缩写)_功能描述 。数据表名称必须以有特征含义的单词或缩写组成,中间可以用“_”分割,例如:DW_ORD_DETAIL。表名称不能用双引号包含,表名长度不超过30个字符[s2] 。

    1. 主题名规则如下:
      1. 订单       ORD
      2. 营销活动    MKC
      3. 贷款        LN
      4. 网银       NET
      5. 客户        CUS
      6. ……
      7. 如有新主题,按规则添加
    2. 数据表名规则如下:
      1. 基础表        _BA
      2. 日汇总表       _D
      3. 月汇总表       _M
      4. 历史累计       _H
      5. 全量加载       _A
      6. 增量加载       _I

     

            1. APP应用层表名

    前缀为APP_主题名(缩写)_功能描述 。数据表名称必须以有特征含义的单词或缩写组成,中间可以用“_”分割,例如:  APP_RPT_ DEALER_GOODS。表名称不能用双引号包含,表名长度不超过30个字符。

    1. 主题名规则如下:
      1. 报表       RPT
    2. 数据表名规则如下:

    参考DW层表名称规范

            1. DW/DM维度表表名

    前缀为D_ 。数据表名称必须以有特征含义的单词或缩写组成,中间可以用“_”分割,例如:D_ACCOUNT、D_PUB_DATE。表名称不能用双引号包含,表名长度不超过30个字符。

    1. 数据表名规则如下:
      1. 日期维度      D_PUB_DATE
      2. 城市           D_CITY

     

            1. 元数据表名

    前缀为M_应用名(缩写)_功能描述 。数据表名称必须以有特征含义的单词或缩写组成,中间可以用“_”分割,例如:M_ETL_TASK。表名称不能用双引号包含,表名长度不超过30个字符。

    1. 应用名规则如下:
      1. ETL        ETL
      2. 报表        RPT
      3. OLAP分析    OLP
      4. 源系统      SRC
      5. 数据库      DB
      6. 软硬件      SHW
      7. ……
      8. 如有新应用,按规则添加

     

          1. 表分区名

    前缀为p 。分区名必须有特定含义的单词或字串。

    例如 :tbl_pstn_detail 的分区p2004100101表示该分区存储 2004100101时段的数据。

          1. 字段名

    字段名称必须用字母开头,采用有特征含义的单词或缩写,不能用双引号包含。

     

          1. 字段排列

    每个表中的字段排列也应该遵从相应的规则进行摆放:

    • 同类属性尽量靠拢摆放

    例如:“协议”实体中有一组“日期”属性,包括“开户日期”、“销户日期”、“签署日期”、“起息日期”、“到期日期”等,可以排列在一起、

    • 相关属性尽量靠拢摆放

    例如:“币种”、“金额”常常一起使用,应排列在一起;

    • 重要的和常用的属性靠前
    • 和源系统非常接近的表(特别是一对一的情况),和源系统的属性顺序一致

     

          1. 主键名

    前缀为PK_。主键名称应是 前缀+表名+构成的字段名。如果复合主键的构成字段较多,则只包含第一个字段。表名可以去掉前缀。

          1. 外键名

    前缀为FK_。外键名称应是 前缀+ 外键表名 + 主键表名 + 外键表构成的字段名。表名可以去掉前缀。

        1. 索引
          1. 普通索引

    前缀为IDX_。索引名称应是 前缀+表名+构成的字段名。如果复合索引的构成字段较多,则只包含第一个字段,并添加序号。表名可以[s3] 去掉前缀。

          1. 主键索引

    前缀为IDX_PK_。索引名称应是 前缀+表名+构成的主键字段名,在创建表时候用using index指定主键索引属性。

          1. 唯一索引

    前缀为IDX_UK_。索引名称应是 前缀+表名+构成的字段名。

          1. 外键索引

    前缀为IDX_FK_。索引名称应是 前缀+表名+构成的外键字段名。

          1. 函数索引

    前缀为IDX_func_。索引名称应是 前缀+表名+构成的特征表达字符。

          1. 簇索引

    前缀为IDX_clu_。索引名称应是 前缀+表名+构成的簇字段。

        1. 视图

    前缀为V_。按业务操作命名视图。

        1. 物化视图

    前缀为MV_。按业务操作命名实体化视图。

        1. 存储过程

    前缀为SP_ 。按业务操作命名存储过程。

        1. 触发器

    前缀为Trig_ 。触发器名应是 前缀 + 表[s4] 名 + 触发器名。

        1. 函数

    前缀为Func_ 。按业务操作命名函数。

        1. 数据包

    前缀为Pkg_ 。按业务操作集合命名数据包。

        1. 序列

    前缀为Seq_ 。按业务属性命名。

        1. 普通变量

    前缀为Var_ 。 存放字符、数字、日期型变量[s5] 。

        1. 游标变量

    前缀为Cur_ 。存放游标记录集。

        1. 记录型变量

    前缀为Rec_ 。 存放记录型数据。

        1. 表类型变量

    前缀为Tab_ 。 存放表类型数据。

        1. 数据库链接

    前缀为dbl_ 。 表示分布式数据库外部链接关系。

      1. 命名
        1. 语言

    命名应该使用英文单词,避免使用拼音,特别不应该使用拼音简写。命名不允许使用中文或者特殊字符。

    英文单词使用用对象本身意义相对或相近的单词。选择最简单或最通用的单词。不能使用毫不相干的单词来命名。

    当一个单词不能表达对象含义时,用词组组合,如果组合太长时,采用用简或缩写,缩写要基本能表达原单词的意义。

    当出现对象名重名时,是不同类型对象时,加类型前缀或后缀以示区别。

        1. 大小写

    名称一律小写,以方便不同数据库移植,以及避免程序调用问题。

        1. 单词分隔

    命名的各单词之间可以使用下划线进行分隔。

        1. 保留字

    命名不允许使用SQL保留字。

        1. 命名长度

    表名、字段名、视图名长度应限制在20个字符内(含前缀)。

        1. 字段名称

    同一个字段名在一个数据库中只能代表一个意思。比如telephone在一个表中代表“电话号码”的意思,在另外一个表中就不能代表“手机号码”的意思。

    不同的表用于相同内容的字段应该采用同样的名称,字段类型定义。

     例如:

    行为名称

    行为英文名称

    英文缩写

    计数

    Count

    cnt

    金额

    Amount

    amt

    微信

    Weixin

    Wx

    成功

    success

    succ

    支付

    Pay

    pay

    地址

    Address

    addr

    订单

    Order

    ord

    渠道

    Channel

    chl

    完成

    Finish

    Fin

     

      1. 数据类型
        1. 字符型

    固定长度的字串类型采用char,长度不固定的字串类型采用varchar。避免在长度不固定的情况下采用char类型。如果在数据迁移等出现以上情况,则必须使用trim()函数截去字串后的空格。

        1. 数字型

    数字型字段尽量采用number类型,要注意精度[s6] 。

        1. 日期和时间
          1. 系统时间

    由数据库产生的系统时间首选数据库的日期型,如DATE类型。

          1. 外部时间

    由数据导入或外部应用程序产生的日期时间类型采用varchar类型,数据格式采用:YYYYMMDDHH24MISS。

        1. 大字段

    如无特别需要,避免使用大字段(blob,clob,long,text,image等)。

        1. 唯一键

    对于数字型唯一键值,尽可能用自增产生。


     [s1]对于我们公司,可能的应用包括:商户、订单、商品、财务、返款、促销、客户、供应链等

     [s2]由于表名有长度限制,建议数据库实例名称不包括在表前缀中,而在SQL代码中加上实例前缀,避免表名长度不够用

     [s3]普通索引前缀建议简化为IX_,唯一索引前缀建议简化为UX_,主键索引前缀建议用PK_,外建索引前缀建议用FK_

     [s4]建议触发器前缀为tr_或tg_,函数前缀为fu_或fn_,尽量简化

     [s5]变量前缀建议:字符vs_,数字vi_,日期vd_,尽量简化

     [s6]数字型字段,建议根据字段可能的取值范围定义相应长度的数字类型,长度小,数据加载、计算效率越好。金额型字段,建议采用decimal类型,保证精确性

    数据仓库星型模型vs雪花模型

    一、概述

    在多维分析的商业智能解决方案中,根据事实表和维度表的关系,又可将常见的模型分为星型模型和雪花型模型。在设计逻辑型数据的模型的时候,就应考虑数据是按照星型模型还是雪花型模型进行组织。

    当所有维表都直接连接到“ 事实表”上时,整个图解就像星星一样,故将该模型称为星型模型,如图 1 。

    星型架构是一种非正规化的结构,多维数据集的每一个维度都直接与事实表相连接,不存在渐变维度,所以数据有一定的冗余,如在地域维度表中,存在国家 A 省 B 的城市 C 以及国家 A 省 B 的城市 D 两条记录,那么国家 A 和省 B 的信息分别存储了两次,即存在冗余。

    1. 销售数据仓库中的星型模型

    c5fde1ebbf5842e5bb71457cb94442ac.jpeg

    当有一个或多个维表没有直接连接到事实表上,而是通过其他维表连接到事实表上时,其图解就像多个雪花连接在一起,故称雪花模型。雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化,原有的各维表可能被扩展为小的事实表,形成一些局部的 " 层次 " 区域,这些被分解的表都连接到主维度表而不是事实表。如图 2,将地域维表又分解为国家,省份,城市等维表。它的优点是 : 通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。雪花型结构去除了数据冗余。

    2. 销售数据仓库中的雪花型模型

    a798a26650c54158bc7928262be2173e.jpeg

    星型模型因为数据的冗余所以很多统计查询不需要做外部的连接,因此一般情况下效率比雪花型模型要高。星型结构不用考虑很多正规化的因素,设计与实现都比较简单。雪花型模型由于去除了冗余,有些统计就需要通过表的联接才能产生,所以效率不一定有星型模型高。正规化也是一种比较复杂的过程,相应的数据库结构设计、数据的 ETL、以及后期的维护都要复杂一些。因此在冗余可以接受的前提下,实际运用中星型模型使用更多,也更有效率。

    二、使用选择

    星形模型(Star Schema)和雪花模型(Snowflake Schema)是数据仓库中常用到的两种方式,而它们之间的对比要从四个角度来进行讨论。

      1.数据优化

    雪花模型使用的是规范化数据,也就是说数据在数据库内部是组织好的,以便消除冗余,因此它能够有效地减少数据量。通过引用完整性,其业务层级和维度都将存储在数据模型之中。

    e7425e6397ae469bbf004fade6900e1d.jpeg
    ▲图1 雪花模型

    相比较而言,星形模型实用的是反规范化数据。在星形模型中,维度直接指的是事实表,业务层级不会通过维度之间的参照完整性来部署。

    468a842c546d4ac493e91f88d51c83ef.jpeg

    ▲图2 星形模型

      2.业务模型

    主键是一个单独的唯一键(数据属性),为特殊数据所选择。在上面的例子中,Advertiser_ID就将是一个主键。外键(参考属性)仅仅是一个表中的字段,用来匹配其他维度表中的主键。在我们所引用的例子中,Advertiser_ID将是Account_dimension的一个外键。

    在雪花模型中,数据模型的业务层级是由一个不同维度表主键-外键的关系来代表的。而在星形模型中,所有必要的维度表在事实表中都只拥有外键。

      3.性能

    第三个区别在于性能的不同。雪花模型在维度表、事实表之间的连接很多,因此性能方面会比较低。举个例子,如果你想要知道Advertiser 的详细信息,雪花模型就会请求许多信息,比如Advertiser Name、ID以及那些广告主和客户表的地址需要连接起来,然后再与事实表连接。

    而星形模型的连接就少的多,在这个模型中,如果你需要上述信息,你只要将Advertiser的维度表和事实表连接即可。

      4.ETL

    雪花模型加载数据集市,因此ETL操作在设计上更加复杂,而且由于附属模型的限制,不能并行化。

    星形模型加载维度表,不需要再维度之间添加附属模型,因此ETL就相对简单,而且可以实现高度的并行化。

      总结

    雪花模型使得维度分析更加容易,比如“针对特定的广告主,有哪些客户或者公司是在线的?”星形模型用来做指标分析更适合,比如“给定的一个客户他们的收入是多少?”

     

     

     

     

     

    展开全文
  • 大数据--数据仓库

    千次阅读 2022-04-24 15:39:49
    数据仓库概念数据仓库特点数据仓库分层数据仓库建模模型选择数仓建模流程数仓建模过程模型设计的思路模型落地实现事实表设计事实表设计原则事实表设计方法三种事实表多维体系结构维度设计六范式与反范式元数据数据...

    概念

    1. 数据库(Database):按照一定格式和数据结构在计算机保存数据的软件,属于物理层。
      最早期是广义上的数据库,这个阶段的数据库结构主要以层次或网状的为主,这是数据库的数据和程序间具备非常强的依赖性,应用有一定局限性。
      我们现在所说的数据库一般指的是关系型数据库。关系数据库是指采用了关系模型来组织数据的数据库,其以行和列的形式存储数据,具有结构化程度高,独立性强,冗余度低等优点。
      关系型数据库主要用于联机事务处理OLTP(On-Line Transaction Processing),主要用于进行基本的、日常的事务处理,例如银行交易等场景。
    2. 数据集市:一种微型的数据仓库,它通常是有更少的数据,更少的主题区域,以及更少的历史数据,如果数据仓库是企业级的,那数据集市就是部门级的,一般数据集市只能为某个局部范围内的管理人员服务。
    3. 数据仓库(Data Warehouse)(DW/DWH)1:为企业所有级别的决策制定过程,提供所有类型数据支持的战略集合。它是单个数据存储,出于分析性报告和决策支持目的而创建。为需要业务智能的企业,提供指导业务流程改进、监视时间、成本、质量以及控制。
      对企业的所有数据进行汇总,为企业各个部门提供统一的, 规范的数据出口。
      数据仓库是面向主题集成的。数据仓库主要用于支撑企业决策分析,所涉及的数据操作主要是数据查询。
    • 数据仓库与数据库对比
    维度数据仓库数据库
    应用场景OLAPOLTP
    数据来源多数据源单数据源
    数据标准化非标准化Schema高度标准化的静态Schema
    数据读取优势针对读操作进行优化针对写操作进行优化
    1. 数据湖:一个集中存储各类结构化和非结构化数据的大型数据仓库,它可以存储来自多个数据源、多种数据类型的原始数据,数据无需经过结构化处理,就可以进行存取、处理、分析和传输。数据湖能帮助企业快速完成异构数据源的联邦分析、挖掘和探索数据价值。
      数据湖 = 数据存储架构 + 数据处理工具
      数据存储架构:要有足够的扩展性和可靠性,可以存储海量的任意类型的数据,包括结构化、半结构化和非结构化数据。
      数据处理工具,则分为两大类:
      1)聚焦如何把数据“搬到”湖里。包括定义数据源、制定数据同步策略、移动数据、编制数据目录等。
      2)关注如何对湖中的数据进行分析、挖掘、利用。数据湖需要具备完善的数据管理能力、多样化的数据分析能力、全面的数据生命周期管理能力、安全的数据获取和数据发布能力。如果没有这些数据治理工具,元数据缺失,湖里的数据质量就没法保障,最终会由数据湖变质为数据沼泽。
      数据仓库和数据湖的不同类比于仓库和湖泊:仓库存储着来自特定来源的货物;而湖泊的水来自河流、溪流和其他来源,并且是原始数据。
    • 数据湖与数据仓库对比
    维度数据湖数据仓库
    应用场景可以探索性分析所有类型的数据,包括机器学习、数据发现、特征分析、预测等通过历史的结构化数据进行数据分析
    使用成本起步成本低,后期成本较高起步成本高,后期成本较低
    数据质量包含大量原始数据,使用前需要清洗和标准化处理质量高,可作为事实依据
    适用对象数据科学家、数据开发人员为主业务分析师为主

    数据仓库特点

    1. 数据仓库是面向主题的
      数据仓库中的数据是按照一定的主题域进行组织的,每一个主题对应一个宏观的分析领域。数据仓库排除对于决策无用的数据,提供特定主题的简明视图。

    2. 数据仓库是集成的
      数据仓库中的数据不是一开始就是在里面的,而是从各个分散的数据库中抽取出来的。但是有一个问题,就是这些来自不同数据库的数据会有重复和不一样的地方,如字段的同名异议、异名同义、单位不统一,字长不统一等。所以在集成的过程中,还要对数据进行清洗、规划、去敏等操作。数据仓库是对企业内不同业务部门处理过的数据的完整集合。

    3. 数据仓库的数据是稳定的
      数据仓库中的数据主要是为了给企业做决策时分析使用,涉及的主要是对数据的查询,一般情况下不会对数据进行修改,如果数据仓库中的历史数据超过存储期限,则会直接删除。
      因为数据仓库涉及的操作主要是查询,所以它的系统要比数据库简单很多,但是数据仓库涉及到查询的数据量一般都很大,所以在数据查询就有更高的要求。数仓里不存在数据的更新和删除(不是指数据到期的删除)操作。

    4. 数据仓库中的数据是随时间变化而变化的
      数据仓库中的数据不可更新是针对应用来说的,也就是说,数据仓库的用户进行分析处理是不进行数据更新操作的。但并不是说,在从数据集成输入数据仓库开始到最后被删除的整个生存周期中,所有的数据仓库数据都是永远不变的。
      1)数据仓库随着时间变化不断增加新的数据内容。数据仓库系统必须不断捕捉OLTP数据库中变化的数据,追加到数据仓库当中去,也就是要不断的生成OLTP数据库的快照,经统一集成增加到数据仓库中去;但对于确实不在变化的数据库快照,如果捕捉到新的变化数据,则只生成一个新的数据库快照增加进去,而不会对原有的数据库快照进行修改。
      2)数据库随着时间变化不断删去旧的数据内容 。数据仓库内的数据也有存储期限,一旦过了这一期限,过期数据就要被删除。
      3)数据仓库中包含有大量的综合数据,这些综合数据中很多跟时间有关,如数据经常按照时间段进行综合,或隔一定的时间片进行抽样等等。这些数据要随着时间的变化不断地进行从新综合。因此数据仓库的数据特征都包含时间项,以标明数据的历史时期。
      数仓里会完整的记录某个对象在一段时期内的变化情况。

    数据仓库分层

    • 分层原因
      1)把复杂问题简单化
      2)减少重复开发
      3)隔离原始数据

    • 数据仓库基础分层主要是分为四层
      在这里插入图片描述

    如上图所示,一个公司可能有多个业务系统,而数据仓库就是将所有的业务系统按照某种组织架构整合起来,形成一个仓储平台,也就是数仓。

    1. 四层分层
    • 第一层:ODS——原始数据层:存放原始数据
      ODS层即操作数据存储,是最接近数据源中数据的一层,数据源中的数据,经过抽取、洗净、传输,也就说传说中的ETL之后,装入本层;一般来说ODS层的数据和源系统的数据是同构的,主要目的是简化后续数据加工处理的工作。从数据粒度上来说ODS层的 数据粒度是 最细 的。ODS层的表通常包括两类,一个用于存储当前需要加载的数据,一个用于存储处理完后的历史数据。历史数据一般保存3-6个月后需要清除,以节省空间。但不同的项目要区别对待,如果源系统的数据量不大,可以保留更长的时间,甚至全量保存;数据在装入本层前需要做以下工作:去噪、去重、提脏、业务提取、单位统一、砍字段、业务判别。

    • 第二层:DWD——数据明细层:对ODS层数据进行清洗、维度退化、脱敏等。
      该层一般保持和ODS层一样的数据粒度,并且提供一定的数据质量保证,在ODS的基础上对数据进行加工处理,提供更干净的数据。同时,为了提高数据明细层的易用性,该层会采用一些维度退化手法,当一个维度没有数据仓库需要的任何数据时,就可以退化维度,将维度退化至事实表中,减少事实表和维表的关联。例如:订单id,这种量级很大的维度,没必要用一张维度表来进行存储,而我们一般在进行数据分析时订单id又非常重要,所以我们将订单id冗余在事实表中,这种维度就是退化维度。

    • 第三层:DWS——数据汇总层: 对DWD层数据进行一个轻度的汇总。
      DWS层为公共汇总层,会进行轻度汇总,粒度比明细数据稍粗,会针对度量值进行汇总,目的是避免重复计算。该层数据表会相对比较少,大多都是宽表(一张表会涵盖比较多的业务内容,表中的字段较多)。按照主题划分,如订单、用户等,生成字段比较多的宽表,用于提供后续的业务查询,OLAP分析,数据分发等。

    • 第四层:DM——数据集市层:为各种统计报表提供数据。
      存放的是轻度聚合的数据,也可以称为数据应用层,基于DWD、DWS上的基础数据,整合汇总成分析某一个主题域的报表数据。主要是提供给数据产品和数据分析使用的数据,通常根据业务需求,划分成流量、订单、用户等,生成字段比较多的宽表,用于提供后续的业务查询,OLAP分析,数据分发等。从数据粒度来说,这层的数据是汇总级的数据,也包括部分明细数据。从数据的时间跨度来说,通常是DW层的一部分,主要的目的是为了满足用户分析的需求,而从分析的角度来说,用户通常只需要分析近几年的即可。从数据的广度来说,仍然覆盖了所有业务数据。

    1. 三层分层
    • 第一层:ODS——原始数据层:存放原始数据

    • 第二层:DW——数据仓库层:数据清洗,初步汇总
      本层将从 ODS 层中获得的数据按照主题建立各种数据模型,每一个主题对应一个宏观的分析领域,数据仓库层排除对决策无用的数据,提供特定主题的简明视图。在DW层会保存BI系统中所有的历史数据,例如保存10年的数据。

    • 第三层:DM——数据集市层:为各种统计报表提供数据。

    1. 五层分层
    • 第一层:ODS——原始数据层:存放原始数据

    • 第二层:DWD——数据明细层:对ODS层数据进行清洗、维度退化、脱敏等。

    • 第三层:DWS——数据汇总层: 对DWD层数据进行一个轻度的汇总。

    • 第四层:ADS——数据应用层:为各种统计报表提供数据
      该层是基于DW层的数据,整合汇总成主题域的服务数据,用于提供后续的业务查询等。

    • 第五层:DIM——维表层:基于维度建模理念思想,建立整个企业的一致性维度。

    维表层主要包含两部分数据:1)高基数维度数据:一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。2)低基数维度数据:一般是配置表,比如枚举值对应的中文含义,或者日期维表。数据量可能是个位数或者几千几万。

    数据仓库建模

    • 原因:在大数据时代,数据爆发式增长,如何将这些数据进行有序、有结构的分类组织和存储是大多数公司面临的一个挑战。数据模型就是数据组织和存储方法,它强调从业务、数据存取和使用角度合理存储数据。数据仓库建模的目标是通过建模的方法更好的组织、存储数据,以便在性能、成本、效率和数据质量之间找到最佳平衡点。四个优点:1)性能:快速的查询我们所需要的数据,减少数据的I/O吞吐。2)成本:极大的减少不必要的数据冗余,实现计算结果复用,降低数据的存储和计算成本。3)效率:极大的改善用户使用数据的体验,提高使用数据的效率。4)质量:改善数据统计口径 2的不一致性,减少数据计算错误的可能性。

    • 数据处理:1)操作型处理,叫联机事务处理 OLTP3(On-Line Transaction Processing),也可以称面向交易的处理系统,它是针对具体业务在数据库联机的日常操作,通常对少数记录进行查询、修改。用户较为关心操作的响应时间、数据的安全性、完整性和并发支持的用户数等问题。传统的数据库系统作为数据管理的主要手段,主要用于操作型处理。2)分析型处理,叫联机分析处理 OLAP4(On-Line Analytical Processing)一般针对某些主题的历史数据进行分析,支持管理决策。

    • 常见的四种数据仓库建模模型

    1. ER模型(范式模型)
      实体关系(Entity Relationship,ER)模型。从全企业的高度设计一个3NF模型,用实体关系模型来描述企业业务,在范式理论上符合3NF。
      关系模型主要应用于OLTP系统中,为了保证数据的一致性以及避免冗余,所以大部分业务系统的表都是遵循第三范式的。
      特点:设计思路自上而下,适合上游基础数据存储,同一份数据只存储一份,没有数据冗余,方便解耦,易维护,缺点是开发周期一般比较长,维护成本高。
      范式理论:为设计一张数据表的表结构,符合的标准级别,也就是规范和要求。
      优点:关系型数据库设计时,遵照一定的规范要求,目的在于降低数据的冗余性。
      缺点:范式的缺点是获取数据时,需要通过Join拼接出最后的数据。
      分类:目前业界范式有第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)、第五范式(5NF)(这里只概述1NF、2NF和3NF)。

    2. 维度模型
      在这里插入图片描述
      维度模型如图所示,主要应用于OLAP系统中,通常以某一个事实表为中心进行表的组织,主要面向业务,特征是可能存在数据的冗余,但是能方便的得到数据。
      维度建模是从分析决策的需求出发构建模型,为分析需求服务,因此它重点关注用户如何更快速的完成需求分析,同事具有较好的大规模复杂查询的相应能力。其典型的代表是星型模型,以及在一些特殊场景下使用的雪花模型。

    • 维度建模设计分为以下步骤:1)选择需要进行分析决策的业务过程2)定义粒度3)识别维度4)确认事实

    1)星型模型:维度模型中最简单的形式,也是数据仓库以及数据集市开发中使用最广泛的形式。星型模式由事实表和维度表组成,一个星型模式中可以有一个或多个事实表,每个事实表引用任意数量的维度表。
    星型模型与雪花模型的区别主要在于维度的层级,标准的星型模型维度只有一层,而雪花模型可能会涉及多层。
    在这里插入图片描述

    2)雪花模型:一种多维模型中表的逻辑布局,与星型模式相同,雪花模式也是由事实表和维度表所组成。所谓的“雪花化”就是将星型模型中的维度表进行规范化处理。当所有的维度表完成规范化后,就形成了以事实表为中心的雪花型结构,即雪花模式。
    在这里插入图片描述
    3)星座模型:数据仓库由多个主题构成,包含多个事实表,而维表是公共的,可以共享(例如两张事实表共用一些维度表时,就叫做星型模型),星型模式的汇集。在这里插入图片描述

    1. Data Vault模型
      DataVault由Hub(关键核心业务实体)、Link(关系)、Satellite(实体属性) 三部分组成 ,是Dan Linstedt发起创建的一种模型方法论,它是在ER关系模型上的衍生,同时设计的出发点也是为了实现数据的整合,并非为数据决策分析直接使用。

    2. Anchor模型
      Anchor模型是对Data Vault模型做了进一步规范化处理,它是一个高度可扩展的模型,所有的扩展只是添加而不是修改,因此它将模型规范到6NF,基本变成了K-V结构模型。企业很少使用。

    模型选择

    在数据仓库建模时,会涉及到模式的选择,我们要根据不同模式的特点选择适合具体业务的模式。星型还是雪花,取决于性能优先,还是灵活更优先。在实际开发中,不会绝对选择一种,根据情况灵活组合,甚至并存(一层维度和多层维度都保存)。在传统企业数仓中,业务相对稳定,以范式建模为主。如电信、金融行业等。在互联网公司,业务变化快,需求来来回回的改,计算和存储也不是问题,我们更关心快速便捷的满足业务需求,所以以维度建模为主。

    数仓建模流程

    数仓建模 = 业务模型->概念模型->逻辑模型->物理模型

    1)业务建模:需求沟通
    划分整个单位的业务,一般按照业务部门的划分,进行各个部分之间业务工作的界定,理清各业务部门之间的关系。深入了解各个业务部门的内具体业务流程并将其程序化。提出修改和改进业务部门工作流程的方法并程序化。数据建模的范围界定,整个数据仓库项目的目标和阶段划分。业务建模阶段其实是一次和业务人员梳理业务的过程,在这个过程中,不仅能帮助我们技术人员更好的理解业务,另一方面,也能够发现业务流程中的一些不合理的环节,加以改善和改进。

    2)领域(概念)建模:画图搭建模型

    抽取关键业务概念,并将之抽象化。将业务概念分组,按照业务主线聚合类似的分组概念。细化分组概念,理清分组概念内的业务流程并抽象化。理清分组概念之间的关联,形成完整的领域概念模型。
    领域概念建模就是运用了实体建模法,从纷繁的业务表象背后通过实体建模法,抽象出实体,事件,说明等抽象的实体,从而找出业务表象后抽象实体间的相互的关联性,保证了我们数据仓库数据按照数据模型所能达到的一致性和关联性。

    概念模型具体要求如下:
    在这里插入图片描述

    3)逻辑建模:表设计

    业务概念实体化,并考虑其具体的属性。事件实体化,也就是所谓的事实,并考虑其属性内容。说明实体化,也就是所谓的维度,并考虑其属性内容。

    逻辑模型具体要求如下:
    在这里插入图片描述

    4)物理建模:建表

    针对特定物理化平台,做出相应的技术调整。针对模型的性能考虑,对特定平台作出相应的调整。针对管理的需要,结合特定的平台,做出相应的调整。生成最后的执行脚本,并完善。

    物理模型具体要求如下:
    在这里插入图片描述

    综合现实的大数据平台、采集工具、etl工具、数仓组件、性能要求、管理要求等多方面因素,设计出具体的项目代码,完成数仓的搭建。

    总结来说,上面的模型设计流程大部分应用于DWD层,也就是事实维度层。通过建模,捋清逻辑,把业务落实到一张张表,并梳理表于表之间的关系。

    数仓建模过程

    构建一张订单表,从多个维度进行统计组合,形成多维度数据集,来从多个角度观察业务过程的好坏

    1)选择业务过程

    确认哪些业务处理流程是数据仓库应该覆盖的,是维度方法的基础。因此,建模的第一个步骤是描述需要建模的业务流程。例如,需要了解和分析一个零售店的销售情况,那么与该零售店销售相关的所有业务流程都是需要关注的。为了描述业务流程,可以简单地使用纯文本将相关内容记录下来,或者使用“业务流程建模标注”(BPMN)方法,也可以使用统一建模语言(UML)或其他类似的方法。
    业务过程就是需要那种业务场景下产生的订单表(划分到那个业务线和数据域);业务过程就是用户下单的订单记录表

    2)选择数据域

    • 申明粒度

    粒度就是确认一条记录代表的含义或者是细化到何种程度(一条记录代表一个订单还是多个订单,如拼团的时候团长的单)
    在选择维度和事实前必须声明粒度,因为每个候选维度或事实必须与定义的粒度保持一致。在一个事实所对应的所有维度设计中强制实行粒度一致性是保证数据仓库应用性能和易用性的关键。
    从给定的业务流程获取数据时,原始粒度是最低级别的粒度。建议从原始粒度数据开始设计,因为原始记录能够满足无法预期的用户查询。汇总后的数据粒度对优化查询性能很重要,但这样的粒度往往不能满足对细节数据的查询需求。
    不同的事实可以有不同的粒度,但同一事实中不要混用多种不同的粒度。维度模型建立完成之后,还有可能因为获取了新的信息,而回到这步修改粒度级别。

    • 确认维度

    维度的粒度必须和第二步所声明的粒度一致。
    维度表是事实表的基础,也说明了事实表的数据是从哪里采集来的。
    典型的维度都是名词,如日期、商店、库存等。维度表存储了某一维度的所有相关数据,例如,日期维度应该包括年、季度、月、周、日等数据。

    • 确认事实

    这一步识别数字化的度量,构成事实表的记录。它是和系统的业务用户密切相关的,因为用户正是通过对事实表的访问获取数据仓库存储的数据。大部分事实表的度量都是数字类型的,可累加,可计算,如成本、数量、金额等。

    模型设计的思路

    构造数据仓库两种方式

    1. 自上而下

    Bill Inmon先生推崇“自上而下”的方式,即一个企业建立唯一的数据中心,就像一个数据的仓库,其中数据是经过整合、经过清洗、去掉脏数据的、标准的,能够提供统一的视图。要建立这样的数据仓库,并不从它需要支持哪些应用入手,而是要从整个企业的环境入手,分析其中的概念,应该有什么样的数据,达成整体概念。

    1. 自下而上

    Ralph Kimball先生推崇“自下而上”的方式,他认为建设数据仓库应该按照实际的应用需求,加载需要的数据,不需要的数据不要加载到数据仓库中。这种方式建设周期较短,客户能够很快看到结果。(针对客户的需求,需求要什么就做什么)

    模型落地实现

    1. 按照命名规范创建表

    2. 开发生成维表和事实表的代码

    3. 进行代码逻辑测试,验证数据加工逻辑的正确性

    4. 代码发布,加入调度并配置相应的质量监控和报警机制

    事实表设计

    事实表作为数据仓库维度建模的核心,紧紧围绕着业务过程来设计,通过获取描述业务过程的度量来表达业务过程,包含了引用的维度和与业务过程有关的度量。

    事实表有三种类型 : 事务事实表、周期快照事实表和累积快照事实表。

    事实表设计原则

    1. 尽可能包含所有与业务过程相关的事实

    2. 只选择与业务过程相关(如订单下单业务中不存在支付金额)的事实

    3. 分解不可加性事实为可加的事实:比如订单的优惠率,应分解为订单原价金额与订单优化金额两个事实存储在事实表中。

    4. 在选择维度和事实之前必须先声明粒度

    粒度用于确定事实表中一行所表示业务的细节层次,决定了维度的扩展性。每个维度和事实必须与所定义的粒度保持一致。事实表设计过程中,粒度定义得越细越好,建议从最低级别的原子粒度开始。原子粒度提供了最大限度的灵活性,可以支持无法预期的各种细节层次的用户需求。

    1. 在同一个事实表中不能有多种不同粒度的事实

    2. 事实的单位要保持一致

    3. 对事实的null值要处理

    4. 使用退化维度提高事实表的易用性

    事实表设计方法

    Kimball的维度模型设计方法有以下四个步骤:选择业务过程、声明粒度、确定维度、确定事实。

    1. 选择业务过程及确定事实表类型

    2. 声明粒度

    1)粒度的作用

    粒度的声明,意味着精确定义事实表的每一行所表示的业务含义。

    2)粒度的选择

    应尽量选择最细级别的原子粒度,以确保事实表的应用具有最大的灵活性。

    1. 确定维度

    完成粒度声明后,就意味着确定了主键,对应的维度组合以及相关的维度字段就可以确定了。

    维度选择的原则:应该选择能够描述清楚业务过程所处的环境的维度信息。

    1. 确定事实

    确定原则:选择与业务过程有关的所有事实,且事实的粒度要与所声明的事实表的粒度一致。

    注意:将不可加性事实分解为可加的组件(分解的原则:可以通过分解后的可加的属性值,计算得到不可加性事实)。

    1. 冗余维度

    冗余常用维度字段(比如商品类目),方便下游用户使用(过滤查询、控制聚合)

    三种事实表

    1. 事务事实表

    也可称为原子事实表,描述业务过程,跟踪控件或时间上某点的度量时间,保存的是最原子的数据。

    1. 周期快照事实表

    以一个周期为时间间隔,来记录事实,一般周期可以是每天、每周、每月、每年等。

    只看某个业务过程,比如订单收货,数据按订单收货时间来切分,周期可以为每天、每月等。

    1. 累积快照事实表

    用来描述过程开始和结束之间的关键步骤事件,覆盖过程的整个生命周期,通常具有多个日期字段来记录关键时间点;当过程随着生命周期不断变化时,记录也会随着过程的变化而被修改。

    1. 事务表对比
    务事实表周期快照事实表累积快照事实表
    时期/时间离散事务时间点以有规律的、可预测的用于时间跨度不确定的不断变化的工作流
    日期维度事务日期快照日期相关业务过程涉及的多个日期
    粒度每行代表实体的一个事务每行代表某时间周期的一个实体每行代表一个实体的生命周期
    事实事务事实累积事实相关业务过程事实和时间间隔事实
    事实表加载插入插入插入与更新
    事实表更新不更新不更新业务过程变更时更新

    多维体系结构

    在Kimball的维度建模的数据仓库中,关于多维体系结构(MD)有三个关键性概念:总线架构(Bus Architecture),一致性维度(Conformed Dimension)和一致性事实(Conformed Fact)。

    1. 总线架构

    在多维体系结构(MD)(也就是总线架构)的数据仓库架构中,主导思想是分步建立数据仓库,由数据集市组合成企业的数据仓库。但是,在建立第一个数据集市前,架构师首先要做的就是设计出在整个企业内具有统一解释的标准化的维度和事实,即一致性维度和一致性事实。而开发团队必须严格的按照这个体系结构来进行数据集市的迭***。

    一致性维度就好比企业范围内的一组总线,不同数据集市的事实的就好比插在这组总线上的元件。这也是称之为总线架构的原因。
    实际设计过程中,我们通常把总线架构列表成矩阵的形式,其中列为一致性维度,行为不同的业务处理过程,即事实,在交叉点上打上标记表示该业务处理过程与该维度相关。这个矩阵也称为总线矩阵(Bus Matrix)。

    总线架构和一致性维度、一致性事实共同组成了Kimball的多维体系结构的基础,也建立了一套可以逐步建立数据仓库的方法论。由于总线架构是多维体系结构的核心,所以我们有时就把多维体系结构直接称为总线架构。

    1. 价值链的意义

    每家机构都有一个关键业务过程组成的潜在价值链,这个价值链确定机构主体活动的自然逻辑流程。数据仓库建设就是围绕着价值链建立一致化的维度和事实。
    在这里插入图片描述

    1. 数据总矩阵

    矩阵的每一行对应都对应机构中的一个业务过程,每一列都和一个业务维度相对应,用叉号填充显示的是和每一行相关的列。业务过程应该先从单个数据源系统开始,然后再进行多数据源的合并。

    企业数据仓库总线矩阵是DW/BI系统的一个总体数据架构,提供了一种可用于分解企业数据仓库规划任务的合理方法,开发团队可以独立的,异步的完成矩阵的各个业务过程,迭代地去建立一个集成的企业数据仓库。
    在这里插入图片描述

    1. 一致性维度

    在多维体系结构中,没有物理上的数据仓库,由物理上的数据集市组合成逻辑上的数据仓库。而且数据集市的建立是可以逐步完成的,最终组合在一起,成为一个数据仓库。如果分步建立数据集市的过程出现了问题,数据集市就会变成孤立的集市,不能组合成数据仓库,而一致性维度的提出正式为了解决这个问题。

    一致性维度的范围是总线架构中的维度,即可能会在多个数据集市中都存在的维度,这个范围的选取需要架构师来决定。一致性维度的内容和普通维度并没有本质上区别,都是经过数据清洗和整合后的结果。一致性维度建立的地点是多维体系结构的后台(Back Room),即数据准备区。

    在多维体系结构的数据仓库项目组内需要有专门的维度设计师,他的职责就是建立维度和维护维度的一致性。在后台建立好的维度同步复制到各个数据集市。这样所有数据集市的这部分维度都是完全相同的。建立新的数据集市时,需要在后台进行一致性维度处理,根据情况来决定是否新增和修改一致性维度,然后同步复制到各个数据集市。这是不同数据集市维度保持一致的要点。

    在同一个集市内,一致性维度的意思是两个维度如果有关系,要么就是完全一样的,要么就是一个维度在数学意义上是另一个维度的子集。

    例如,如果建立月维度话,月维度的各种描述必须与日期维度中的完全一致,最常用的做法就是在日期维度上建立视图生成月维度。这样月维度就可以是日期维度的子集,在后续钻取等操作时可以保持一致。如果维度表中的数据量较大,出于效率的考虑,应该建立物化视图或者实际的物理表。这样,维度保持一致后,事实就可以保存在各个数据集市中。虽然在物理上是独立的,但在逻辑上由一致性维度使所有的数据集市是联系在一起,随时可以进行交叉探察等操作,也就组成了数据仓库。

    1. 一致性事实

    在建立多个数据集市时,完成一致性维度的工作就已经完成了一致性的80%-90%的工作量。余下的工作就是建立一致性事实。一致性事实和一致性维度有些不同,一致性维度是由专人维护在后台(Back Room),发生修改时同步复制到每个数据集市,而事实表一般不会在多个数据集市间复制。需要查询多个数据集市中的事实时,一般通过交叉探查(drill across)来实现。

    为了能在多个数据集市间进行交叉探查,一致性事实主要需要保证两点:第一个是KPI的定义及计算方法要一致,第二个是事实的单位要一致性。如果业务要求或事实上就不能保持一致的话,建议不同单位的事实分开建立字段保存。

    这样,一致性维度将多个数据集市结合在一起,一致性事实保证不同数据集市间的事实数据可以交叉探查,一个分布式的数据仓库就建成了。

    1. 小结
    • 总线矩阵:业务过程和维度的交点。

    • 一致性维度:同一集市的维度表,内容相同或包含。一致性维度要么是统一的,要么是维度表的一个子集。

    • 一致性事实:不同集市的同一事实,需保证口径一致,单位统一。指每个度量在整个数据仓库中都是唯一的统计口径,为了避免歧义,一个度量只有唯一的业务术语。

    维度设计

    1. 维度基本概念

    维度是维度建模的基础和灵魂。在维度建模中,将度量称为“事实”,将环境描述为“维度”,维度是用于分析事实所需要的的多样环境。

    例如,在分析交易过程时,可以通过买家、卖家、商品和时间等维度描述交易发生的环境。

    维度所包含的表示维度的列,称为维度属性。维度属性是查询约束条件、分组和报表标签生成的基本来源,是数据易用性的关键。

    维度属性的作用一般是查询约束、分类汇总以及排序等。

    1. 如何获取维度或维度属性

    维度或维度属性的获取,可以从以下两方面获取:

    1)从报表中获取;

    2)可以在和业务人员的交谈中发现维度或维度属性。

    1. 维度设计原则

    维度属性的作用一般是查询约束、分类汇总以及排序等,在确定维度属性时,应当提前考虑以下内容:

    1)维度属性尽量丰富,为数据使用打下基础

    2)给出详实的、富有意义的文字描述

    3)区分数值型属性和事实

    4)沉淀出通用的维度属性,为建立一致性维度做好铺垫

    1. 维度的基本设计方法
    • 第一步:选择维度或新建维度

    • 第二步:确定主维表

    此处的主维表一般是ODS表,直接与业务系系统同步。以淘宝商品维度为例,sauctionauctions是与前台商品中心系统同步的商品表,此表即是主维表。

    • 第三步:确定相关维表

    第四步:确定维度属性

    本步骤主要包括两个阶段,其中第一个阶段是从主维表中选择维度属性或生成新的维度属性;第二个阶段是从相关维表中选择维度属性或生成新的维度属性。

    六范式与反范式

    • 六范式
    1. 一范式(1NF):域应该是原子性的,即数据库表的每一列都是不可分割的原子数据项。
      域:域就是列的取值范围,比如性别的域就是(男,女)
    • 不符合一范式的表格设计如下:
    ID商品商家ID用户ID
    0015 台电脑XXX旗舰店00001

    很明显上表所示的表格设计是不符合第一范式的,商品列中的数据不是原子数据项,是可以进行分割的,因此对表格进行修改,让表格符合第一范式的要求,修改结果如下表所示:

    ID商品商家ID用户ID
    001电脑 5XXX旗舰店00001

    实际上,1NF 是所有关系型数据库的最基本要求,你在关系型数据库管理系统(RDBMS),例如 SQL Server,Oracle,MySQL 中创建数据表的时候,如果数据表的设计不符合这个最基本的要求,那么操作一定是不能成功的。也就是说,只要在 RDBMS 中已经存在的数据表,一定是符合 1NF 的。

    1. 二范式
      二范式(2NF):在 1NF 的基础上,实体的属性完全函数依赖于主关键字(混合主键), 不能存在部分函数依赖于主关键字(混合主键)。如果存在某些属性只依赖混合主键中的部分属性,那么不符合二范式。
    • 不符合二范式的表格设计如下:
    学生 ID姓名所属系系主任所修课程分数
    20170901176王小强计算机系马小腾00000195
    20170901176王小强计算机系马小腾00000299

    上述表格中是混合主键(学生 ID + 所修课程),但是所属系和系主任这两个属性只依赖于混合主键中的学生 ID 这一个属性,因此,不符合第二范式。

    如果有一天学生的所属系要调整,那么所属系和系主任这两列都需要修改,如果这个学生修了多门课程,那么表中的多行数据都要修改,这是非常麻烦的,不符合第二范式。

    为了消除这种部分依赖,只有一个办法,就是将大数据表拆分成两个或者更多个更小的数据表。

    • 符合二范式的表格设计如下:
    学生 ID所修课程分数
    2017090117600000195
    2017090117600000299
    学生 ID所属系系主任
    20170901176计算机系马小腾
    20170901176计算机系马小腾
    学生 ID姓名
    20170901176王小强

    通过上述的修改,当一个学生的所属系需要调整时,不管学生修了多少门课程,都只需要改变上表中的一行数据即可。

    1. 三范式:3NF 在 2NF 的基础之上,消除了非主属性对于主键(复合主键)的传递依赖。
    • 不符合三范式的表格设计如下:
    订单ID商品ID商品颜色商品尺寸商家ID用户ID
    0010001深空灰300 270 40XXX旗舰店00001

    很明显,上表中,商品颜色依赖于商品 ID,商品 ID 依赖于订单 ID,那么非主属性商品颜色就传递依赖于订单 ID,因此不符合三范式,解决方案是将大数据表拆分成两个或者更多个更小的数据表。

    • 符合三范式的表格设计如下:
    订单ID商品ID商家ID用户ID
    0010001XXX旗舰店00001
    1. BC范式(BGFN):关系模式R<U,F>中,若每一个决定因素都包含码,则R<U,F>属于BCFN。
    • 理解:根据定义我们可以得到结论,一个满足BC范式的关系模式有:所有非主属性对每一个码都是完全函数依赖;所有主属性对每一个不包含它的码也是完全函数依赖;没有任何属性完全函数依赖于非码的任何一组属性。
    • 例如有关系模式C(Cno, Cname, Pcno),Cno,Cname,Pcno依次表示课程号、课程名、先修课。可知关系C只有一个码Cno,且没有任何属性对Cno部分函数依赖或传递函数依赖,所以关系C属于第三范式,同时Cno是C中的唯一决定因素,所以C也属于BC范式。
    1. 第四范式(4NF): 限制关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖。
    • 理解: 显然一个关系模式是4NF,则必为BCNF。也就是说,当一个表中的非主属性互相独立时(3NF),这些非主属性不应该有多值,若有多值就违反了4NF。
    1. 第五范式(5NF): 越往下,冗余度越低。必须满足第四范式;表必须可以分解为较小的表,除非那些表在逻辑上拥有与原始表相同的主键。第五范式是在第四范式的基础上做的进一步规范化。第四范式处理的是相互独立的多值情况,而第五范式则处理相互依赖的多值情况。
    • 反范式:反范式化设计数据库,是为了提高查询效率,采用空间换时间的实现思路。
      应用场景:当冗余的信息有价值或者能大幅度提高查询效率的时候,我们才会采取反范式的优化。
      一些情况下,比如存在频繁查询时,可以容忍适当的冗余设计,目的是减少多表关联查询,提高效率。
      缺点:存储空间变大了;一个表中字段做了修改,另一个表中冗余字段也需要做同步修改,否则数据不一致;若采用存储过程来支持数据的更新、删除等额外操作,如果更新频繁会非常消耗系统资源。

    • 范式化设计与反范式设计的优缺点

    1. 范式化设计(时间换空间)
      优点:范式化的表减少了数据冗余,数据表更新操作快、占用存储空间小。
      缺点:查询时需要对多个表进行关联,查询性能降低;索引优化会更难进行。
    2. 反范式化设计(空间换时间):通过增加数据表中的冗余字段来提高数据库的读(查询)性能,但冗余数据会牺牲数据一致性。
      优点:可以减少表关联;可能更好的进行索引优化。
      缺点:存在大量冗余数据;数据维护成本更高(删除异常,插入异常,更新异常)。

    元数据

    元数据(Metadata)最基本的定义就是关于数据的数据。

    元数据打通了源数据、数据仓库、数据应用,记录了数据从产生到消费的全过程。元数据主要记录数据仓库中模型的定义、各层级间的映射关系、监控数据仓库的数据状态及 ETL 的任务运行状态。在数据仓库系统中,元数据可以帮助数据仓库管理员和开发人员非常方便地找到他们所心的数据,用于指导其进行数据管理和开发工作,提高工作效率。

    正是有了元数据,才使得数据仓库的最终用户可以随心所欲地使用数据仓库,利用数据仓库进行各种管理决策模式的探讨。元数据是数据仓库的应用灵魂,可以说没有元数据就没有数据仓库。

    1. 元数据的类型

    1) 技术元数据( Technical Metadata ) :存储关于数据仓库系统技术细节的数据,是用于开发、管理和维护数据仓库使用的数据。

    • 数据仓库结构的描述,包括仓库模式、视图、维、层次结构和导出数据的定义,以及数据集市的位置和内容;业务系统、数据仓库和数据集市的体系结构和模式;汇总用的算法,包括度量和维定义算法,数据粒度、主题领域、聚合、汇总和预定义的查询与报告;由操作环境到数据仓库环境的映射,包括源数据和它们的内容、数据分割、数据提取、清理、转换规则和数据刷新规则及安全(用户授权和存取控制)。

    2)业务元数据( Business Metadata ):从业务角度描述了数据仓库中的数据,它提供了介于使用者和实际系统之间的语义层,使得不懂计算机技术的业务人员也能够 读懂 数据仓库中的数据。

    • 使用者的业务术语所表达的数据模型、对象名和属性名;访问数据的原则和数据的来源;系统所提供的分析方法及公式和报表的信息。在信息打包过程中,需要用包图表示维度和类别还有它们之间的传递和映射关系,实际上这个操作就是在原业务系统的基础上创建了元数据。其中的维度、类别还有 层次关系是属于典型的技术型元数据,而业务系统中与之对应的术语则属于业务元数据。比如日期、区域、产品、客户年龄和客户状况等维 度,实际销售、计划销售、预测销售、计划偏差和预测偏差等指标皆属于元数据。这些数据在以后的分析中起到了极为重要的作用。
    1. 元数据的作用

    元数据是数据管理、数据内容、数据应用的基础,在数据管理方面为集团数据提供在计算、存储、成本、质量、安全、 模型等治理领域上的数据支持。元数据可看作是数据仓库的信息地图。随着时间的流逝来跟踪数据结构的变化,是元数据另一个常见的使用功能。元数据描述了数据的结构、内容、链和索引等项内容。元数据在数据源抽取、数据仓库开发、商务分析、数据仓库服务和数据求精与重构工程等过程都有重要的作用,在下图中可以看到元数据在整个数据仓库开发和应用过程中的巨大影响。
    在这里插入图片描述

    数据治理

    1、数据治理:将数据作为组织资产而展开的一系列的具体化工作,是对数据的全生命周期管理。

    • 数据治理体系是指从组织架构、管理制度、操作规范、IT应用技术、绩效考核支持等多个维度对组织的数据模型、数据架构、数据质量、数据安全、数据生命周期等各方面进行全面的梳理、建设以及持续改进的体系。

    2、数据治理目标:提高数据的质量准确性和完整性,保证数据的安全性(保密性、完整性及可用性),实现数据资源在各组织机构部门的共享;推进信息资源的整合、对接和共享,从而提升集团公司或政务单位信息化水平,充分发挥信息化作用。

    3、数据治理体系:包含两个方面:一是数据质量核心领域,二是数据质量保障机制。

    • 两者内容及相互关系如下图:

    在这里插入图片描述

    1. 数据治理核心领域

    为了有效管理信息资源,必须构集团级数据治理体系。数据治理体系包含数据治理组织、数据构架管理、主数据管理、数据质量管理、数据服务管理及数据安全管理内容,这些内容既有机结合,又相互支撑。

    1. 数据治理方法

    1)数据资源梳理

    数据治理的第一个步骤是从业务的视角厘清组织的数据资源环境和数据资源清单,包含组织机构、业务事项、信息系统,以及以数据库、网页、文件和 API 接口形式存在的数据项资源,本步骤的输出物为分门别类的数据资源清单。

    2)数据采集清洗

    通过可视化的ETL工具(例如阿里的 DataX,Pentaho Data Integration)将数据从来源端经过抽取 (extract)、转换 (transform)、加载 (load) 至目的端的过程,目的是将散落和零乱的数据集中存储起来。

    3)基础库主题库建设

    一般情况下,可以将数据分为基础数据、业务主题数据和分析数据。基础数据一般指的是核心实体数据,或称主数据,例如智慧城市中的人口、法人、地理信息、信用、电子证照等数据。主题数据一般指的是某个业务主题数据,例如市场监督管理局的食品监管、质量监督检查、企业综合监管等数据。而分析数据指的是基于业务主题数据综合分析而得的分析结果数据,例如市场监督管理局的企业综合评价、产业区域分布、高危企业分布等。那么基础库和主题库的建设就是在对业务理解的基础上,基于易存储、易管理、易使用的原则抽像数据存储结构,说白了,就是基于一定的原则设计数据库表结构,然后再根据数据资源清单设计数据采集清洗流程,将整洁干净的数据存储到数据库或数据仓库中。

    4)元数据管理

    元数据管理是对基础库和主题库中的数据项属性的管理,同时,将数据项的业务含义与数据项进行了关联,便于业务人员也能够理解数据库中的数据字段含义,并且,元数据是后面提到的自动化数据共享、数据交换和商业智能(BI)的基础。需要注意的是,元数据管理一般是对基础库和主题库中(即核心数据资产)的数据项属性的管理,而数据资源清单是对各类数据来源的数据项的管理。

    5)血缘追踪

    数据被业务场景使用时,发现数据错误,数据治理团队需要快速定位数据来源,修复数据错误。那么数据治理团队需要知道业务团队的数据来自于哪个核心库,核心库的数据又来自于哪个数据源头。我们的实践是在元数据和数据资源清单之间建立关联关系,且业务团队使用的数据项由元数据组合配置而来,这样,就建立了数据使用场景与数据源头之间的血缘关系。数据资源目录:数据资源目录一般应用于数据共享的场景,例如政府部门之间的数据共享,数据资源目录是基于业务场景和行业规范而创建,同时依托于元数据和基础库主题而实现自动化的数据申请和使用。

    6)质量管理

    数据价值的成功发掘必须依托于高质量的数据,唯有准确、完整、一致的数据才有使用价值。因此,需要从多维度来分析数据的质量,例如:偏移量、非空检查、值域检查、规范性检查、重复性检查、关联关系检查、离群值检查、波动检查等等。需要注意的是,优秀的数据质量模型的设计必须依赖于对业务的深刻理解,在技术上也推荐使用大数据相关技术来保障检测性能和降低对业务系统的性能影响,例如 Hadoop,MapReduce,HBase 等。

    7)商业智能(BI)

    数据治理的目的是使用,对于一个大型的数据仓库来说,数据使用的场景和需求是多变的,那么可以使用 BI 类的产品快速获取需要的数据,并分析形成报表,比较知名的产品有 Microsoft Power BI,QlikView,Tableau,Smartbi等。

    8)数据共享交换

    数据共享包括组织内部和组织之间的数据共享,共享方式也分为库表、文件和 API 接口三种共享方式,库表共享比较直接粗暴,文件共享方式通过 ETL 工具做一个反向的数据交换也就可以实现。我们比较推荐的是 API 接口共享方式,在这种方式下,能够让中心数据仓库保留数据所有权,把数据使用权通过 API 接口的形式进行了转移。API 接口共享可以使用 API 网关实现,常见的功能是自动化的接口生成、申请审核、限流、限并发、多用户隔离、调用统计、调用审计、黑白名单、调用监控、质量监控等等。

    1. 数据质量衡量标准

    1)数据准确性(Accuracy):数据采集值或者观测值和真实值之间的接近程度,也叫做误差值,误差越大,准确度越低。

    • 数据中记录的信息和数据是否准确,数据记录的信息是否存在异常或错误。准确性关注的是数据记录中存在的错误,如字符型数据的乱码现象就存在着准确性的问题,还有就是异常的数值:异常大或者异常小的数值、不符合有效性要求的数值等。

    2)数据的精确性(Precision):指对同一对象的观测数据在重复测量时所得到不同数据间的接近程度。精确性,也可以叫精准性。精确性与我们数据采集的精度有关系。精度高,要求数据采集的粒度越细,误差的容忍程度越低。

    3)数据的正确性(Rightness):数据的正确性取决于数据采集过程的可控程度,可控程度高,可追溯情况好,数据的真实性容易得到保障,而可控程度低或者无法追溯,数据造假后无法追溯,则真实性难以保证。为了提高数据的真实性,采用无人进行过程干涉的智能终端直接采集数据,能够更好地保证所采集数据的真实性,减少人为干预,减少数据造假,从而让数据更加正确地反应客观事物。

    4)数据的及时性(In-time):指数据能否在需要的时候得到保证。

    5)数据的即时性:指数据采集时间节点和数据传输的时间节点,一个数据在数据源头采集后立即存储,并立即加工呈现,就是即时数据,而经过一段时间之后再传输到信息系统中,则数据即时性就稍差。

    6)数据的完整性:从数据采集到的程度来衡量的,是应采集和实际采集到数据之间的比例。衡量的是应采集和实际采集的差异。

    7)数据的全面性:指数据采集点的遗漏情况。

    8)数据的关联性:指各个数据集之间的关联关系。

    1. 数据质量的保证方法
      1)从技术层面来说,需要构建一套高效、健壮的ETL程序,以此保证数据清洗、转换后数据的正确性和一致性。

    2)从流程上来说,整个ETL是多个任务,按步骤顺序执行的一个过程,后置任务依赖前置任务,定期执行,整个流程需要自动化,并且哪个环节出现了问题,给予预警,通知相关维护人员及时处理。

    3)从管理层面上来说,数据仓库是构建在公司各个业务系统之上,它是一面镜子,很多时候它能反映出业务系统的问题,所以需要管理层的支持和约束,比如通过第一条说的事后自动检验机制反映出业务系统的维护错误,需要相应的业务系统维护人员及时处理。

    1. 数据治理流程
      基本流程如下:发现数据质量问题 > 定义数据质量规则 > 质量控制 > 质量评估 > 质量优化。
      在这里插入图片描述

    OLTP与OLAP区别

    OLTPOLAP
    用户操作人员,低层管理人员决策人员,高级管理人员
    功能日常操作处理分析决策
    DB设计面向应用面向主题
    数据当前的,最新的,细节的,二维的,分立的历史的,聚集的,多维的,集成的,统一的
    存取读写数十条记录读上百万条记录
    工作单位简单的事务复杂的查询
    用户数上千个上百万个
    DB大小100MB-GB100GB-TB
    时间要求具有实时性对时间的要求不严格
    并发要求高并发低并发
    技术实现方案事务;索引;存储计算耦合大量SCAN;列式存储;存算可以分离
    数据模型/规约关系模型,3NF范式维度模型,关系模型,对范式要求低
    主要应用数据库数据仓库
    技术典范MySQL,OracleSQL-On-Hadoop

    1. 来源:牛客网
      链接:https://www.nowcoder.com/discuss/934440 ↩︎

    2. 统计口径 分为 财务口径和业务口径 ↩︎

    3. OLTP(On-Line Transaction Processing)联机事务处理过程:基本特征是前台接收的用户数据可以立即传送到计算中心进行处理,并在很短的时间内给出处理结果,是对用户操作快速响应的方式之一。数据库:传统的关系型数据库、NoSQL、NewSQL。 ↩︎

    4. OLAP(Online Analytical Processing)联机分析处理:使分析人员能够迅速、一致、交互地从各个方面观察信息,以达到深入理解数据的目的。主流开源的OLAP引擎:Hive、Sparksql、Presto、Kylin、Impala、Druid、Clickhouse 等。 ↩︎

    展开全文
  • 数据仓库原理

    千次阅读 2022-03-29 16:30:43
    数据仓库原理 ODS>DWD>DWS>ADS

    1.简介

    1.1诞生背景

    1. 历史数据积存:历史数据使用频率 低,堆积在业务科中,导致性能下降;
    2. 企业数据分析需要:各个部门自己建立独立的数据抽取系统,导致数据不一致;

    1.2基本概述(Data Warehouse,DW)

    1. 由数据仓库之父比尔恩门提出;
    2. 数据仓库是一个面向主题的集成的非易失的随着时间变化的数据集合;
    3. 主要用于组织积累的历史数据,并使用分析方法(OLAP、数据分析)进行分析整理,进而辅助决策,为管理者、企业系统提供数据支持,构建商业智能;

    1.2.1数据仓库的特点

    • 面向主题:为数据分析提供服务,根据主题将原始数据聚合在一起;
    • 集成:原始数据来源于不同数据源,要整合成最终数据,需要经过抽取、清洗、转化;
    • 非易失:保持的数据是一系列的历史快照,不允许被修改,只允许通过工具进行查询、分析;
    • 时变性:数仓会定期接、集成新的数据,从而反映出数据的最新变化;

    1.2.2数据库VS数据仓库

    类型数据库数据仓库
    概述数据库面向事业设计,属于OLTP(在线事务处理)系统,主要操作是随机读写;在设计时尽量避免冗余,常采用符合范式规则来设计;数据库面向主题设计,属于OLAP(在线分析处理)系统,主要操作是批量读写;关注数据整合,以及分析、处理性能;会有意引入冗余,采用符合范式规则来设计;
    面向事务分析
    数据类型细节、业务
    数据特点当前的、最新的综合、清洗过的数据
    目的日常操作历史的、跨时间维护
    设计模型基于ER模型,面向应用长期信息需求、决策支持
    操作读/写星形/雪花模型,面向主题
    数据模型GB到TB>=TB

    1.3数据仓库建设方案

    传统数据仓库大数据数据仓库

    概述

    由关系型数据组成MPP(大规模并行处理)集群利用大数据天然的扩展性,完成海量数据的存放
    将SQL转化为大数据计算引擎任务,完成数据分析

    问题

    扩展性有限、热点问题SQL支持率、事务支持

    1.4MPP&分布式架构

    1.4.1MPP架构

    1. 传统数仓中常见的技术架构,将单机数据库节点组成集群,提升整体处理性能 ;
    2. 节点间为非共享架构(share Noting),每个节点都有独立的磁盘存储系统和内存系统;
    3. 每台数据节点通过专用网络或者商业网络互相连接,彼此协同计算,作为整体提供服务 ;
    4. 设计上有限考虑C一致性,其次考虑A(可用性),尽量做好P(分区容错性)。

    1.4.2MPP架构优点

    1. 运算方式精细,延迟低、吞吐低;
    2. 适合中等规模的结构化数据处理。

    1.4.3MPP架构缺点

    1. 架构缺点:存储位置不透明,通过Hash确认数据所在的物理节点,查询任务在所有节点均会执行;
    2. 并行计算时,单节点瓶颈会成为整个系统短板,容错性差;
    3. 分布式事务的实现会导致扩展性降低。

    1.4.4分布式架构

    1. 大数据中常见的技术架构、也成为hadoop架构/批处理架构;
    2. 各节点实现场地自治(可以单独运行局部应用),数据在集群中全局透明共享;
    3. 每台节点通过局域性或广域网相连,节点间的通信开销较大,在运算时致力减少数据移动;
    4. 优先考虑的是P(分区容错性),然后是A(可用性),最后再考虑C(一致性)

    1.4.5MPP+分布式架构

    1. 数据存储采用分布式架构中的公共存储,提高容错性;
    2. 上层架构采用MPP,减少运算延迟。

    1.4.6常见产品

    传统数据仓库

    • Oracle RAC
    • DB2
    • Teradata
    • greenplunm

    大数据数据仓库

    • Hive
    • Spark sql
    • HBase
    • impala
    • HAWQ
    • TIDB

    2.架构

    2.1架构图

    2.2ETL流程

    2.2.1ETL--Extract-Transform-Load

    1. 将数据从来源端经过抽取(extract)、交互转化(transform)、加载(load)至目的端的过程;
    2. 构建数据仓库的重要一环,用户从数据源抽取所需的数据没经过数据清洗,最终按照月线定义好的数据仓库模型,将数据加载到数据仓库中去;
    3. ETL规则的设计和实施约占正回购数据仓库搭建工作量的60%-80%。

    2.2.1.1数据抽取(Extraction)

    • 抽取的数据源可以分为结构化数据、非结构化数据、半结构化数据;
    • 结构化数据一般采用JDBC、数据库日志方式,非/半结构化数据会监听文件变动;

    2.2.1.2抽取方式

    • 数据抽取方式由全量同步、增量同步两种方式;
    • 全量同步会将全部数据进行抽取,一般用于初始化数据转载;
    • 增量同步方式会检测数据的变动,抽取发生变动的数据,一般用于数据更新;

    2.2.2数据转换(Transformation)

    数据转化要经历数据清洗和转化两个过程:

    • 数据清洗主要是对出现的重复、二义性、不完整、违反业务或逻辑规则等问题的数据进行统一的处理;
    • 数据转化主要是对数据进行标准化处理,进行字段、数据类型、数据定义的转换;

    结构化数据再转化过程中的逻辑较为简单,非/半结构化数据的转化

    数据加载(Loading)

    将最后处理完的数据导入对应的目标源里

    2.2.3ETL过程

    结构化数据ETL工具

    • Sqoop
    • Kettle
    • Datastage
    • Informatica
    • Kafka

    非/半结构化数据ETL工具

    • Flume
    • Logstash

    2.3数据积存

    2.3.1操作数据层(ODS)

    1. 数据与原业务数据保存一致,可以增加字段来进行数据管理(update_time、from、update_type);
    2. 存储的历史数据是只读的,提供业务系统查询使用;
    3. 业务系统对历史数据完成修改后,将update_type字段更新为UPDATE,追加回ODS中;

    在离线数仓中,业务数据定期通过ETL流程到ODS中,导入方式有全量、增量两种:

    • 全量导入:数据第一次导入时,选择此种方式;
    • 增量导入:数据非第一次导入,每次只需要导入新增、更改的数据,建议使用外连接&全覆盖方式

    2.4数据分析

    2.4.1数据明细层(DWD)

    1. 数据明细层对ODS的数据进行清洗、标准化、维度退化(把时间、分类、地域这类维度加入表内)
    2. 数据仍然满足3NF模型,为数据预算做准备

    2.4.2数据汇总层(DWS)

    1. 数据汇总层的数据对数据明细层的数据,按照分析主题进行计算汇总,存放便于分析的宽表;
    2. 存储模型并非3NF,而是注重数据聚合,复杂查询、处理性能更优的数仓模型,如维度模型;

    2.4.3数据应用层(ADS)

    1. 数据应用层也被称为数据集市;
    2. 存储数据分析结果,为不同业务场景提供接口,减轻数据仓库的负担;
    3. 数据仓库擅长数据分析,直接开放业务查询接口,会加重其负担;
    4. 数据应用层(kylin报表决策、HBase并发查询、ElasticSearch搜索检索)

    3.建模

    3.1基本概念

    3.1.1OLTP系统建模方法

    1. OLTP(在线事业处理)系统中,主要操作时随机读写;
    2. 为了保证数据一致性、减少冗余,常使用关系模型(ER模型);
    3. 在关系模型中,使用三范式规则来减少冗余;

    3.1.2OLAP(在线联机分析)

    1. OLAP系统,主要操作时复杂分析查询;关注数据整合,以及分析、处理性能;
    2. OLAP根据数据存储的方式不同,有分为ROLAP、MOLAP、HOLAP;

    OLAP系统分类

    1. ROLAP(Relation OLAP):使用关系模型构建,存储系统一般为RDBMS
    2. MOLAP(Multidimensional OLAP,多维型OLAP):预先聚合计算,使用多为数组的形式保存数据结果,加快查询分析时间;
    3. HOLAP(hybird PLAP,混合架构的OLAP):ROLAP和MOLAP两者的集成;如低层时关系型的,高层时多维矩阵型的;查询效率高于ROLAP,低于MOLAP;

    3.2ROLAP系统建模方法

    典型的数据仓库建模方法有ER模型、维度模型、Data Value、Anchor

    ER模型(成熟)

    1. 出发点时整合数据,为数据分析决策服务
    2. 需要全面了解业务和数据
    3. 实施周期长
    4. 对建模人员能力要求高

    维度建模(互联网)

    1. 为分析需求服务,更快完成需求分析
    2. 具有较好大规模复杂查询相应性能
    3. 最流行的数仓建模经典

    Data Value

    1. ER模型的衍生
    2. 强调数据的历史性、可追溯、原子性
    3. 弱化一致性处理和整合
    4. 引入范式,应对源系统的扩展性

    Anchor

    1. data value模型的衍生
    2. 初衷为设计一个高度可扩展模型
    3. 会带来较多的join操作

    3.2.1维度模型

    • 维度模型中,表被分为维度表、事实表,维度是对事实的一种组织;
    • 维度一般包含分类、时间、地域等
    • 唯独模型分为星型模型、雪花模型、星座模型
    • 唯独模型建立后,方便对数据进行多维分析 

    星型模型

    • 标准的星型模型,维度只有一层,分析性能最优

    雪花模型

    • 雪花模型具有多层维度,比较接近三范式设计,较为灵活

    星座模型

    • 星座模型基于多个事实表,事实表之间会共享一些维度表;
    • 式大型数据仓库中的常态,式业务增长的结果,与模型设计无关;

    什么是宽表模型

    • 宽表模型式维度模型的衍生,适合join性能不佳的数据仓库产品;
    • 宽表模型将维度冗余到事实表中,形成宽表,以此减少join操作;

    3.3MOLAP

    3.3.1MOLAP系统建模方法

    1. MOLAP将数据进行预结算,并将聚合结果存储到CUBE模型中;
    2. CUBE模型以多维数组的形式,物化到存储系统中,加快了后续的查询;
    3. 生产CUBE需要大量的时间、空间,维度预处理可能会导致数据膨胀;

     常见的MOLAP产品

    • Kylin(开源产品代表)
    • Druid

    3.4多维分析

    3.4.1OLAP多维分析

    • OLAP主要操作时复杂查询,可以夺标关联,使用count、sum、avg等聚合函数
    • OLAP对复杂查询操作做了直观的定义,包括钻取、切片、切块、旋转

    3.4.2钻取

    • 对维度不同层次的分析,通过改变维度的层次来变换分析的粒度
    • 钻取包括上卷(ROLL-UP)、下钻(DRILL-DOWN)
    • 上卷(ROLL-UP),也称为向上钻取,指从低层次到高层次的切换
    • 下钻(DRILL-DOWN),指从高层次到低层次的切换

    3.4.3切片(slice)、切块(dice)

    • 选择某个维度进行分割称为切片;
    • 按照多维度进行的切片称为切块;

    3.4.4旋转(Pivot)

    对维度方向的互换,类似与交换坐标轴上卷(Roll-up)

     4.最佳实践

    4.1表的分类

    4.1.1维度建模中的表类型

    • 事实表
    • 维度表
    • 事务事实表
    • 周期快照事实表
    • 累积快照事实表

    事实表

    • 一般是指现实存在的业务对象,比如用户,商品,商家,销售员等

    维度表

    • 一般是指对应一些业务状态,代码的解释表。也可以称之为码表
    • 通常使用维度对事实表的书籍进行统计、聚合运算

    4.1.2事实表的3个分类

    事务事实表

    • 随着业务不断产生的书籍,一旦产生就不会再变化,如交易流水、操作日志、出库入库记录

    周期快照事实表

    • 随着业务周期性的推进而变化,完成间隔周期内的度量统计,如年、季度累计
    • 使用周期+状态度量的组合,如年累计订单数,年时周期,订单总数是量度

    累计快照事实表

    • 记录不确定周期的度量统计,完全覆盖一个事实的生命周期,如订单的状态表;
    • 通常由多个时间字段,用于记录生命周期中的关键时间点;
    • 只有一条记录,针对次记录不断更新;

    实现方式一

    • 使用日期分期表,全量书籍记录,每天的分区存储昨天全量数据与当天增量数据合并的结果;
    • 数据量大会导致全量表膨胀,存储大量永远不更新的冷数据,对性能影响较大;
    • 适用于数据量较少的情况;

    实现方式二

    • 使用日期分区表,推测数据最长生命周期,存储周期内数据;周期外的冷数据存储到归档表;
    • 需要保留多天的分区数据,存储消耗依然很大;

    实现方案三

    • 使用日期分区表,以业务实体的结束时间分区,每天的分区存放当天结束的数据;设计一个时间非常大的分区,如9999-12-31,存放截止当前未结束的数据;
    • 已结束的数据存放到相应分区,存放未结束数据的分区,数据量也不会很大,ETL性能好;
    • 无存储浪费,数据全局唯一;
    • 业务系统可能无法标识业务实体的结束时间,可以使用其他相关业务系统的结束标志作为次业务系统的结束,也可以使用最长生命周期时间活前端系统的数据归档时间;

    4.1.3拉链表

    • 拉链表记录每条信息的周末周期,用于保留数据的虽有历史(变更)状态;
    • 拉链表将表数据的随机修改方式,变为顺序追加;

    4.2ETL策略

    全量同步

    • 数据初始化装载一定使用全量同步的方式;
    • 因为业务、技术原因,使用全量同步的方式做周期数据更新,直接覆盖原有数据即可;

    增量同步

    • 传统数据整合方案中,大多采用merge方式(update+insert)
    • 主流大数据平台不支持update操作,可采用全外链接+数据全量覆盖方式
    • 如果担心数据更新出错,可以采用分区方式,每天保存最新的全量版本,保留较短周期;

    4.3任务调度

    4.3.1为什么需要任务调度

    • 解决任务单元之间的依赖关系
    • 自动化完成任务的定时计划

    4.3.2常见类型

    • Shell
    • Java程序
    • Mapreduce程序
    • SQL脚本

    4.3.3常见调度工具

    • Azkaban
    • Oozie

     

    5.项目实战

    5.1项目背景

    • 某电商企业,因数据积存、分析需要,筹划搭建数据仓库,提供数据分析的访问接口;
    • 项目一期需要完成数据仓库建设,并完成用户复购率的分析计算,支持业务查询需求;

    复购率计算

    • 复购率是指在一段时间间隔内,多次重复购买产品的用户,占全部人数的比率;
    • 统计各个品类下,品牌月单次复购率和多次复购率;

    5.2数据描述

     

     

     

    5.3架构设计

    5.3.1数据仓库架构图

    5.4环境搭建

    5.4.1环境说明

    操作系统依旧组件版本

    • CentOS 7.2
    • Hadoop 2.7.7
    • Hive1.2.1
    • Tez 0.9.1
    • MySQL 5.7.28
    • Sqoop 1.4.6
    • Azkaban 2.5.0
    • Presto 0.196

    5.4.2集群规划

    使用3台虚拟机进行搭建

    HadoopHive&TezMySQLSqoopAzkabanPresto

    node01

    node02

    node03

     5.4.3搭建流程

    1. 安装并准备3台CentOS7.2虚拟机,主机名为node01、node02、node03
    2. 上传自动化安装脚本automaticDeploy.zip到虚拟机node01中
    3. 解压automaticDeploy.zip到/home/Hadoop/目录下
    4. 更改frames.txt文件,配置组件的安装节点信息

    Downloads – Oracle VM VirtualBoxhttps://www.virtualbox.org/wiki/Downloads

    5.5项目开发

    整体开发流程

    1. 业务数据生成
    2. ETL数据导入
    3. 创建ODS层,并完成HDFS接入
    4. 创建DWD层,并完成ODS层数据接入
    5. 创建DWS层,导入DWD层数据
    6. 创建ADS层,完成复购率计算
    7. 编写脚本,将ADS层的数据导出到MySQL中,供业务查询
    8. 使用Azkaban调度器,实现脚本自动化运行

     

    展开全文
  • 数据仓库及数据挖掘

    千次阅读 2022-03-25 00:05:51
    一、数据仓库概述 二、数据仓库的建设 三、数据仓库的分类 四、数据仓库的设计方法 五、数据挖掘 1、概述 2、常用技术与方法 3、应用
  • 数据仓库 & OLAP

    千次阅读 2022-03-28 21:02:57
    一、数据库 vs. 数据仓库 1. 构建目的不同:数据库主要用于实现企业的日常业务管理,提高业务运营的效率 ...除了要通过创建事务和处理的正确外,还需复杂的并发控制机制保证事务运行的隔离。(更新操
  • 数据仓库常见建模方法与建模实例演示

    万次阅读 多人点赞 2020-04-14 15:52:09
    1.数据仓库建模的目的? 为什么要进行数据仓库建模?大数据的数仓建模是通过建模的方法更好的组织、存储数据,以便在 性能、成本、效率和数据质量之间找到最佳平衡点。一般主要从下面四点考虑 访问性能:能够快速...
  • 数据仓库的概念有了基本的认识后,有必要单独说明一下ETL这个最重要的过程,然后向读者介绍四种常见的数据仓库架构。本篇最后描述实时数据仓库的产生背景、特定需求和使用场景,并列举一些常见的实时数据仓库...
  • 仓库管理过程的准确和高效至关重要。影响着公司的经济发展和管理。利用人工管理强大而数据烦琐的数据库显的效率过于低。利用计算机高效、准确的特点能够很好的满足公司的管理需要。提高公司各个员工的工作效率和...
  • 搭建数据仓库的意义及优点

    万次阅读 2019-06-26 23:36:38
    ​ 数据仓库更多代表的是一种数据的管理和使用的方式,它是一整套包括了etl、调度、建模在内的完整的理论体系。数据仓库在构建过程中通常都需要进行分层处理。业务不同,分层的技术处理手段也不同。 ​ 数据仓库...
  • Hadoop之数据仓库概述

    千次阅读 多人点赞 2021-07-10 08:28:08
    数据仓库的概念可以追溯到20世纪80年代,当时IBM的研究人员开发出了“商业数据仓库”。本质上,数据仓库试图提供一种从操作型系统到决策支持环境的数据流架构模型。数据仓库概念的提出,是为了解决和这个数据流
  • 企业级数据仓库(EDW,1991)1991年,BillInmon出版了其有关数据仓库的第一本书,这本书不仅仅说明为什么要建数据仓库、数据仓库能给你带来什么,更重要的是,Inmon第一次提供了如何建设数据仓库的指导意见,...
  • 如何搭建数据仓库

    千次阅读 2020-12-10 10:31:30
    其实数据仓库可以看成是BI的基础版本、数据库的升级版本,我们可以把公司里的数据都想象成一个个文件夹,数据库就是这一个个文件柜,这个文件柜存放着非常多的数据,无论这个数据是什么、或者是如何组织的。...
  • 据挖掘技术是基于已有的数据之上,以帮助企业或个人了解现有的数据或信息,并...这个基础数据就储存于数据仓库中,基于数据仓库进行数据挖掘,还能够辅助管理层未来行业发展前景做出更科学、更合理地数据分析与预测。
  • 数据库设计的重要性

    千次阅读 2019-10-04 00:45:00
    一、设计数据库的必要 1. 为什么要设计数据库 当数据库比较复杂(如数据量大,表较多,业务关系复杂)时,我们需要先设计数据库, 因为: 良好的数据库设计: 节省数据的存储空间 能够保证...
  • 一致维度与数据仓库

    千次阅读 2018-10-11 15:20:22
    一致维度与数据仓库    1、一致维度概念   维度建模的数据仓库中,有一个概念叫Conformed Dimension,中文一般翻译为“一致维度”。一致维度是Kimball的多维体系结构(MD)中的三个关键概念之一,...
  • 大数据:数据仓库设计

    千次阅读 2021-05-09 22:02:16
    数据仓库设计
  • 拥有本篇文章,意味着你拥有一本完善的书籍,本篇文章整理了数据仓库领域,几乎所有的知识点。
  • 数据仓库实战教程

    万次阅读 多人点赞 2020-12-28 09:19:07
    大型支付公司实时数仓建设案例 总结 数据仓库实战教程 读者交流群已经开通了,有需要的可以私信进入读者交流群 数据仓库已经是企业的数据竞争的核心了,学好数据仓库对提高自己和找到一份好的工作都至关重要,但是...
  • 数据仓库基本知识

    万次阅读 多人点赞 2017-10-31 17:35:04
    数据仓库是什么 根据统计,每个企业的数据量每2~3年时间就会成倍增长,这些数据蕴含着巨大的商业价值,而企业所关注的通常只占在总数据量的2%~4%左右。 因此,企业仍然没有最大化地利用已存在的数据资源,以...
  • 数据仓库和数据库解决的问题有什么不一样? 数据仓库架构的发展历史 从Hadoop框架的角度来理解数据仓库 从Hive来更深入理解: 数据仓库和数据库解决的问题有什么不一样?
  • 数据仓库(一):认识数据仓库

    千次阅读 2020-12-28 23:15:32
    数据仓库有一种敬畏之心,后来经过慢慢的学习和使用,发现其实它在应用开发中的使用方法跟传统关系数据库没什么区别,无非就是普通的SQL查询以及JDBC连接。所以数仓的使用不是本文的重点,我们...
  • 仓库温度的控制要求

    千次阅读 2020-12-24 14:58:23
    仓库的温度和湿度储存物品质量具有很大的影响,因此,采取措施,创造适合物品安全储存保管的温湿度条件,就成为仓储管理中的一项重要的日常工作、仓库温度的控制要求?这儿中国物通网小编为大家讲一讲!仓库温度的...
  • 京东零售数据仓库演进之路

    千次阅读 2022-06-17 00:51:49
    摘要:京东零售十年交易额快速增长的背后,不仅是京东零售高速发展的十年,也是数据仓库技术架构演进创新的十年,EB级数据如何进行资产化沉淀和治理?如何支撑业务高速发展、精细化运营、规模化创新的不同阶段?在...
  • Maven中央仓库

    千次阅读 2021-08-25 10:52:39
    Maven中央仓库 学习链接:maven 仓库配置 pom中repositories属性 安装好Maven之后,我们可以建立一个简单的项目,配置一些简单的依赖,然后运行mvn clean install,项目就构建好了。我们没有手工的去下载任何jar文件...
  • 干货 | 万字详解整个数据仓库设计体系

    千次阅读 多人点赞 2021-03-19 14:20:08
    它出于分析报告和决策支持目的而创建。 数据仓库本身并不“生产”任何数据,同时自身也不需要“消费”任何的数据,数据来源于外部,并且开放给外部应用,这也是为什么叫“仓库”,而不叫“工厂”的原因。 基本...
  • 问题导读:1、数据仓库的总体架构是怎样的? 2、如何进行数据采集? 3、数据是如何进行加工和处理的?1.1 数据仓库总体架构专家系统接收增购项目车辆TCMS或其他子系统通过车地通信传输的实时或离线数据,经过一系列...
  • 数据仓库之DIM层

    千次阅读 2022-01-30 13:26:33
    而度量是属性的标量刻画。并且度量具有统计意义,而属性并不具有统计意义,比如25岁的我在超市买了1瓶300ML农夫山泉,花了2元。这里的1瓶和2块就是我买水的这个业务过程的度量。超市是(地理维度)属性,25岁是...
  • 数据仓库知识点汇总

    千次阅读 多人点赞 2019-10-09 15:04:01
    数据仓库形象解释 业务场景如下图 举例说明: 在很久很久以前,世界上生活着许多种族,有人类,有矮人,有精灵......他们有着不同的信仰,不同的文化,彼此相安无事。可是,有一个猥琐男却偏偏想要统治整个世界...
  • 初识数据仓库

    万次阅读 2020-04-12 15:50:38
    首先的疑问是什么是数据仓库? 作为理工科出身多多少少都会了解数据库的...假设有一天,你收到你boss的任务,要求你在半天的时间内分析一个公司几个项目的业绩分析报表要求,你觉得很简单,因为操作已经在你脑子里...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 155,830
精华内容 62,332
热门标签
关键字:

仓库对公司的重要性

友情链接: 4fsk.rar