数据仓库:

数据仓库,英文名称为Data Warehouse,可简写为DW或DWH。数据仓库,是为企业所有级别的决策制定过程,提供所有类型数据支持的战略集合。它出于分析性报告和决策支持目的而创建。

数据仓库的特点:

1. 面向主题

主题是对业务数据的一种抽象,是从较高层次上对信息系统中的数据进行归纳和整理。面向主题的数据可以划分成两部分:
1)根据原系统业务数据的特点进行主题的抽取
2)确定每个主题所包含的数据内容。

2. 集成性

面向操作型的数据库通常是异构的、并且相互独立,所以无法对信息进行概括和反映信
息的本质。而数据仓库中的数据是经过数据的抽取、清洗、切换、加载得到的,所以为了保证数据不存在二义性,必须对数据进行编码统一和必要的汇总,以保证数据仓库内数据的一致性。数据仓库在经历数据集成阶段后,使数据仓库中的数据都遵守统一的编码规则,并且消除许多冗余数据。

3.稳定性

数据仓库中的数据反映的都是一段历史时期的数据内容,它的主要操作是查询、分析而
不进行一般意义上的更新(数据集成前的操作型数据库主要完成数据的增加、修改、删除、查询),一旦某个数据进入到数据仓库后,一般情况下数据会被长期保留,当超过规定的期限才会被删除。通常数据仓库需要做的工作就是加载、查询和分析,一般不进行任何修改操作,是为了企业高层 人员决策分析之用。

4. 反应历史变化

数据仓库不断从操作型数据库或其他数据源获取变化的数据,从而分析和预测需
要的历史数据,所以一般数据仓库中数据表的键码(维度)都含有时间键,以表明数据的历史时期信息,然后不断增加新的数据内容。通过这些历史信息可以对企业的发展历程和趋势做出分析和预测。数据仓库的建设需要大量的业务数据作为积累,并将这些宝贵的历史信息经过加工、整理,最后提供给决策分析人员,这是数据仓库建设的根本目的。

数据库 vs 数据仓库

属性 数据库 数据仓库
内容 事务 主题、分析
存储 当前最新数据 历史数据
模型建设 三范式 星型范式

ETL过程

数据抽取(Extract)

1. sqoop

是 apache 旗下一款“Hadoop中的各种存储系统(HDFS、HIVE、HBASE) 和关系数据库(mysql、oracle、sqlserver等)服务器之间传送数据”的工具。

2. DataX

日志采集

1. flume

2. logstash

对比
flume logstash
开发语言 java ruby
内存占用 每起一个进程,默认占用1G内存

什么是数据仓库建模?(What)

事实表(Fact Table):

指存储有事实记录的表,如系统日志、销售记录等;事实表的记录在不断地动态增长,所以它的体积通常远大于其他表。事实表作为数据仓库建模的核心,需要根据业务过程来设计,包含了引用的维度和业务过程有关的度量。
作为度量业务过程的事实,一般为整型或浮点型的十进制数值,有可加性,半可加性和不可加性三种类型

  • 可加:最灵活最有用的事实是完全可加,可加性度量可以按照与事实表关联的任意维度汇总。比如订单总金额。
  • 半可加:半可加度量可以对某些维度汇总,但不能对所有维度汇总。差额是常见的半可加事实,除了时间维度外,他们可以跨所有维度进行操作。(比如每天的余额加起来毫无意义)。
  • 不可加:一些度量是完全不可加的,例如:比率。对非可加事实,一种好的方法是,分解为可加的组件来实现聚集

    维度表(Dimension Table):

    维度表(Dimension Table)或维表,有时也称查找表(Lookup Table),是与事实表相对应的一种表;它保存了维度的属性值,可以跟事实表做关联;相当于将事实表上经常重复出现的属性抽取、规范出来用一张表进行管理。常见的维度表有:日期表(存储与日期对应的周、月、季度等的属性)、地点表(包含国家、省/州、城市等属性)等。维度是维度建模的基础和灵魂。

    事实表和维度表的关系

    1. 星型模型:
    星形模型中有一张事实表,以及零个或多个维度表,事实表与维度表通过主键外键相关联,维度表之间没有关联,当所有维表都直接连接到“ 事实表”上时,整个图解就像星星一样,故将该模型称为星型模型。星形模型是最简单,也是最常用的模型。由于星形模型只有一张大表,因此它相比于其他模型更适合于大数据处理。其他模型可以通过一定的转换,变为星形模型。
    星型架构是一种非正规化的结构,多维数据集的每一个维度都直接与事实表相连接,不存在渐变维度,所以数据有一定的冗余,如在地域维度表中,存在国家 A 省 B 的城市 C 以及国家 A 省 B 的城市 D 两条记录,那么国家 A 和省 B 的信息分别存储了两次,即存在冗余。
    2. 雪花模型:
    当有一个或多个维表没有直接连接到事实表上,而是通过其他维表连接到事实表上时,其图解就像多个雪花连接在一起,故称雪花模型。雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化,原有的各维表可能被扩展为小的维度表,形成一些局部的 “ 层次 “ 区域,这些被分解的表都连接到主维度表而不是事实表。如图,将地域维表又分解为国家,省份,城市等维表。它的优点是 : 通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。雪花型结构去除了数据冗余。
    星座模型是由星型模型延伸而来,星型模型是基于一张事实表而星座模式是基于多张事实表,并且共享维度表信息,这种模型往往应用于数据关系比星型模型和雪花模型更复杂的场合。星座模型需要多个事实表共享维度表,因而可以视为星形模型的集合,故亦被称为星系模型
    3. 星座模型
    星座模型是由星型模型延伸而来,星型模型是基于一张事实表而星座模式是基于多张事实表,并且共享维度表信息,这种模型往往应用于数据关系比星型模型和雪花模型更复杂的场合。星座模型需要多个事实表共享维度表,因而可以视为星形模型的集合,故亦被称为星系模型
    4.总结
    通过对比,我们可以发现数据仓库大多数时候是比较适合使用星型模型构建底层数据Hive表,通过大量的冗余来减少表查询的次数从而提升查询效率,星型模型对OLAP的分析引擎支持比较友好,这一点在Kylin中比较能体现。而雪花模型在关系型数据库中如MySQL,Oracle中非常常见,尤其像电商的数据库表。在数据仓库中雪花模型和星座模型的应用场景比较少,但也不是没有,所以在具体设计的时候,可以考虑是不是能结合两者的优点参与设计,以此达到设计的最优化目的。

如何进行数据仓库建模?(How)

0. 建模原则

  • 高内聚和低耦合
  • 核心模型与扩展模型分离
  • 公共处理逻辑下沉及单一
  • 成本与性能平衡
  • 数据可回滚
  • 一致性
  • 命名清晰、可理解

    1. 分层规范

    数据仓库一般分为三层,自上而下分别为

  • 数据贴源层(ODS,Operation Data Store)、

  • 数据公共层(CDM,Common Data Model):由ODS层数据加工而成。主要完成数据加工与整合,建立一致性的维度,构建可复用的面向分析和统计的明细事实表,以及汇总公共粒度的指标
    • 公共维度层(DIM):
    • 明细粒度事实层(DWD):对数据进行规范化编码转换,清洗,统一格式,脱敏等,不做横向整合
    • 公共汇总粒度事实层(DWS):
    • 主题宽表层(DW):对DWD各种信息进行整合,输出主题宽表(面向业务过 程,不同业务过程的信息不冗余建设,采用外键形式)
  • 数据应用层(ADS,Application Data Service)、

ODS->(DW->DM)->DA/ADS层是如何划分的,分层的原因

清晰数据结构:每一个数据分层都有它的作用域和职责,在使用表的时候能更方便地定位和理解;
减少重复开发:规范数据分层,开发一些通用的中间层数据,能够减少极大的重复计算;
统一数据口径:通过数据分层,提供统一的数据出口,统一对外输出的数据口径;
复杂问题简单化:将一个复杂的任务分解成多个步骤来完成,每一层解决特定的问题。
image.png
每层划分的依据如下:

  • ods层(original data):存放原始数据信息,原则上不进行任何的数据清晰,和数据源保持一致;
  • dw层:数据公共层,是数仓建设的重点,一般是日志子表和一些宽表,主要完成数据的清洗、转换等;
    • dwd(data warehouse detail):数据明细层
    • dws(data warehouse summay):数据汇总层
  • dm层(data market):数据集市层,是最直接体系数据资产的层,一般是汇总数据,现在已经逐步弱化,面向挖掘、数据分析等;
  • da层(data application):数据应用层,高度汇总数据,主要用于报表展示。

    2. 架构-Inmon

    辐射状企业信息工厂(Corporate Information Factory,CIF)方法由Bill Inmon及业界人士倡导的。在这个环境下,数据从操作性数据源中获取,在ETL系统中处理,将这一过程称为数据获取,从这一过程中获得的原子数据保存在满足第三范式的数据库中,这种规范化的原子数据的仓库被称为CIF架构下的企业级数据仓库(EDW)
    与Kimball方法相似,CIF提倡企业数据协调与集成,但CIF认为要利用规范化的EDW承担这一角色,而Kimball架构强调具有一致性维度的企业总线的重要作用。
    Inmon企业级数据仓库的分析数据库通常以部门为中心(而不是围绕业务过程来组织),而且包含汇总数据,并不是原子级别数据,如果ETL过程中数据所应用的业务规则超越了基本概要,如部门改名了或者其他的类似计算,要将分析数据库与EDW原子数据联系起来将变得很困难

    3. 架构-Kimball

    Kimball架构利用了CIF中处于中心地位的EDW,但是此次的EDW完全与分析与报表用户隔离,仅作为数据来源,其中数据是维度的,原子的,以过程为中心的,与企业级数据仓库总线结构保持一致。

    4. Inmon架构 vs Kimball架构

    | | Inmon架构 | Kimbal架构 | | —- | —- | —- | | 流程 | 自顶向下,从数据抽取->数据仓库->数据集市,以数据源为导向,是一种瀑布流开发方法,模型偏向于3NF | 架构是自下向上,即从数据集市(主题划分)->数据仓库->数据抽取,是以需求为导向的,一般使用星型模型 | | 事实表和纬度表 | 不强调事实表和维度表的概念,是因为数据源变化可能比较大,更加强调的是数据清洗的工作 | 强调模型由事实表和维度表组成,注重事实表和维度表的设计 | | 数据集市 | 数据集市有自己的物理存储,是真实存在的。 | 数据集市是一个逻辑概念,是指多为数据仓库的主题域划分,并没有自己的物理存储,也可以说是虚拟的数据集市。是数据仓库的一个访问层,是按主题域组织的数据集合,用于支持部门级的决策。 | | 中心 | 以部门为中心 | 是以业务过程为中心 | | EDW访问 | 用户可以直接访问企业数据仓库(EDW) | 用户不可以直接访问企业数据仓库(EDW),只能访问展现区数据 |

5. 建模流程

业务模型—>领域模型—>逻辑模型—>物理模型

5.1 业务模型

生成业务模型,主要解决业务层面的分解和程序化

5.2 领域模型

生成领域模型,主要是对业务模型进行抽象处理,生成领域概念模型。

5.3 逻辑模型

生成逻辑模型,主要是将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化。

5.4 物理模型

生成物理模型,主要解决,逻辑模型针对不同关系型数据库的物理化以及性能等一些具体的技术问题。

未分类知识点

1. Data Vault模型

Data Vault Dan Linstedt 发起创建的一种模型,它是模型的衍生,其设计的出发点也是为了实现数据的整合,但不能直接用于数据分析决策。它强调建立一个可审计的基础数据层,也就是强调数据的历史性、可追溯性和原子性,而不要求对数据进行过度的一致性处理和整合;
同时它基于主题概念将企业数据进行结构化组织,并引入了更进一步的范式处理来优化模型,以应对源系统变更的扩展性。Data Vault 型由以下几部分组成。

  • Hub :是企业的核心业务实体,由 实体 key 、数据仓库序列代理键、装载时间、数据来源组成。
  • Link :代表 Hub 之间的关系。这里与 模型最大的区别是将关系作为一个独立的单元抽象,可以提升模型的扩展性。它可以直接描述 1:1 1:n n:n 的关系,而不需要做任何变更。它由 Hub 的代理键、装载时间、数据来源组成。
  • Satellite :是 Hub 的详细描述内容, 一个 Hub 可以有多个 Satellite它由 Hub 的代理键、装载时间、来源类型、详细的 Hub 描述信息组成。


    Data Vault 模型比 ER 模型更容易设计和产出,它的 ETL 加工可实现配置化。

    2. Anchor模型

    进一步规范化处理,其核心思想是所有的扩展只添加而不是修改,因此将模型规范到6NF,基本编程了K-V结构化模型。
      那么总的来说,分为三个阶段:

  1. 将数据以源表结构相同的方式同步到Oracle,数据工程师基于ODS数据进行统计。
  2. 通过一些模型技术改变烟囱式的开发模型,消除一些冗余,提升数据的一致性。(经验)在不太成熟、快速变化的业务面前,构建ER模型的风险非常大,不太适合去构建ER模型。
  3. 选择了以Kimball的维度建模为核心理念的模型方法论,同时对其进行了一定的升级和扩展,构建了公共层模型数据架构体系。