数据仓库(ODS层)设计

建造数据仓库(ODS层设计)主要包括两个部分的工作——与操作系统接口的设计和数据仓库本身的设计

数据仓库的需求只有在已经装载了部分数据并开始使用时才能弄清楚,数据仓库实在启发方式下建造的,在这个过程中一个阶段的开发完全依赖于上一个阶段获得的结果。

首先,载入一部分数据供BI分析员使用和查看,然后根据最终用户的反馈,修改数据和(或)添加其他数据。然后建立数据仓库的另一部分,如此继续。这种反馈过程贯穿于数据仓库的整个开发生命周期之中。

因此,数据仓库的设计不能完全采用与传统的需求驱动的系统相同的方法进行。但与此同时,对需求进行预测仍然是十分重要的,实际情况通常介于两者之间。

从操作型数据开始

设计时首先考虑如何将数据放置在数据仓库中。

直接将操作系统数据接入,投入需求产出,这显然是不行的,这有很多原因。

数据集成

最重要的一个原因是,这一过程没有考虑到操作系统的数据是未经集成的。
会出现以下这些情况:

  1. 相同的数据以不同的名字出现在各个表中
  2. 不同表中相同的名字存储了不同的数据
  3. 一些数据用相同的名字存在相同的地方却使用了不同的度量单位
  4. 等等

为了从操作型环境中适当地取出数据,必须对数据进行一致性处理。

  1. 编码统一: 数据编码不一致,例如性别,有些是0,1;有些是男,女。因此在数据进入数仓的时候需要编码统一 、
  2. 字段名称统一
  3. 字段度量单位统一

数据载入

加载主要分为两部分,历史数据加载,和日常数据加载
历史数据加载通常并不难,因为只需要加载一次,当然这肯定会占用系统资源,但是只要一次即可。

当操作型环境数据发生变化时,不断地将变化数据装载到仓库中是最为困难的。要有效的地捕捉到那些不断发生的日常变化,并对之进行处理。
为了限制扫描的操作型数据量,通常会采用四种技术。

  1. 扫描那些被打上时间戳的数据,当一个应用对记录的最近一次新增或变化打上时间戳时,数据仓库扫描可以利用时间戳进行有效过滤。
  2. 扫描增量文件,但是这对系统环境等组件,有较高的局限性,很少应用创建增量文件。
  3. 对日志文件进行扫描,例如Mysql的binlog。其原理与扫描增量文件基本相同,其有一个缺点就是,日志通常会包含大量其他数据,对数仓无用,所以需要有一种技术手段提取,例如canal等。
  4. 最后一种技术,是以上三种技术都无法满足的时候的最后的选择。抽取时就建立一份当前快照,下一轮抽取的时候,将两组快照进行对比,以确定发生的业务活动。这种方法很麻烦、复杂,还废资源,通常使用与爬虫爬取数据的数据清洗中。

数据仓库的设计

数据/过程模型与体系结构化环境

过程模型仅仅使用于操作型环境。数据模型既可用于操作型环境,又可用于数据仓库环境。

一个过程模型一般(整个或部分)包括以下内容:

  • 功能分解
  • 第零层上下文图
  • 结构图
  • 状态转换图
  • HIPO图
  • 伪代码

在许多场合和环境下,过程模型都是非常宝贵的,如在建立数据集市时。由于过程模型是需求驱动的,因此不适用于数据仓库。它假设在详细设计开始之前需求是已知的。对于许多过程,是可以这样假设的。但这样的假设在建造数据仓库时并不成立。

数据仓库与数据模型

将企业模型用到数据仓库中要做很多改动。

企业模型属于业务数据模型,属概念层次,是操作系统数据模型和数据仓库数据模型的共同起源。

  1. 要去除纯粹用于操作型环境中的数据。
  2. 在企业数据模型的关键字结构中增加时间元素。(在操作系统中完成)
  3. 在数据仓库中将操作型系统中的数据关系转变为“人工关系”。

数据仓库人工关系:是指数据仓库中不同数据角色之间的相互作用和关系。在数据仓库中,数据被划分为不同的层次,如源数据、ETL数据、分段数据和汇总数据等。这些数据角色在企业数据流动过程中发挥着不同的作用,而数据仓库人工关系则描述了这些数据角色之间的联系和交互方式。
数据仓库人工关系包括数据抽取、转换和加载(ETL)、数据分析和报表生成、数据质量和准确性验证、数据安全和隐私保护等环节。这些环节之间的关系和协作方式,构成了数据仓库的人工关系。

将企业数据模型转变为数据仓库模型的最后一项设计工作是进行稳定性分析。稳定性分析是根据各个数据属性是否经常变化的特性将这些数据分组。例如:一张大的通用目的表建立三张表,很少变化的数据分到一组,不时变化的分到一组,而经常变化的又分为一组。
稳定性分析(通常是物理数据库设计之前数据建模的最后一步)的最后结果就是建立了具有相似特性的数据分组。

数据仓库的数据模型

数据建模分为三个层次

  • 高层建模(称为实体关系图,或ERD)
  • 中间层建模(称为数据项集,或DIS)
  • 底层建模(称为物理模型)
高层数据模型

在这里插入图片描述
在ERD层的实体处于最高抽象层。由集成范围决定哪些实体属于模型范围。集成范围定义了数据模型的边界,需要在建模前确定,哪些数据将会被放入建模,不然数据建模无穷无尽。

中间层数据模型

高层数据模型建好之后,要建立下一层即中间层模型。对高层模型中标识出的每一个主要主题域或实体,都要建立一个中间层模型,即对每一个主题域的扩展。中间层不一定能一次全部建好,某个主题域的中间层数据模型扩展后,会对模型的一部分进行充实,其他部分保持不变,会随着主题域迭代。

如下图所示,在中间层数据模型上,有四个基本的构造
在这里插入图片描述

  • 主要数据分组:每个主要主题域有且只有一个主要数据分组其中包含了对每个主要主题域只存在一次的属性(主键)。同所有的数据分组一样,主要数据分组包含每个主要主题域的属性和关键字。
  • 二级数据分组:二级数据分组包含每个主要主题域可以存在多次的数据属性。从主要数据分组向下的直线段指示出了二级数据分组。有多少个可以出现多次的不同数据分组,就可以含有多少个二级数据分组。
  • 连接器:即数据关联主键。表示两个主要主题域间的数据关系。连接器将一个分组的数据与另一个分组的数据联系起来。
  • 数据的“类型”:数据的类型由指向数据分组右边的线段指示。左边的数据分组是超类型,右边的数据分组是数据的子类型。

这四个数据模型构造用来标识数据模型中的数据属性和这些属性间的关系。
在这里插入图片描述
这个例子是一个金融机构中账户的中间层建模,所有不同的都在该DIS中表示出来了。

还有另外中一种特别类型,如下图,从一个数据分组引出的线的两种“类型”,右边的两条线说明存在标准的两种“类型”,属于同级别。一条线的标准是根据业务类型——存款或提款。另一条线则指明另一种标准——ATM或柜员业务。总之,两种类型的业务活动都包括下面的交易:

  • ATM存款
  • ATM提款
  • 柜员存款
  • 柜员提款

这个图表的另一个特点是所有的公共数据在左边,所有的独有数据在右边。例如,日期、时间属性是所有交易都有的,但是现金库余额属性只与出纳业务有关。
在这里插入图片描述

底层数据模型

物理模型是从中间层数据模型创建而来,建立物理模型通过扩展中间层模型,使模型中包含有主键和物理属性。还要做性能的优化,确定数据的粒度与分区,增加时间元素,以便每个数据单元都相关。

分区设计主要考虑数据的使用,降低IO。数据使用时,如果将数据放在同一分区中,即数据存储时将会存放在同一物理块中,那么数据读取只需要一次IO操作,即可拥有更高的运行效率,一般都以日期、渠道等为分区。

总结

分为两步

  • 将数据载入,有两块操作:
    第一,数据集成,同一口径:命名,单位,码值等
    第二,合理捕获增量变化数据,存入数仓
  • 设计ODS层,存放导出数据
    第一步,设计抽象模型(高层建模)
    第二部,在高层建模基础上丰满业务模型(中间层建模)
    第三步,扩展中间层建模生成物理模型(底层建模)
  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值