文档介绍：该【大数据平台 】是由【mazhuangzi1】上传分享，文档一共【38】页，该文档可以免费在线阅读，需要了解更多关于【大数据平台 】的内容，可以使用淘豆网的站内搜索功能，选择自己适合的文档，以下文字是截取该文章内的部分文字，如需要获得完整电子版，请下载此文档到您的设备，方便您编辑和打印。目录
1仓库底层模型重构 1
1
6
27
28
30
31
31
新核心模型设计 32
34
35
35
35
35
方案概述 35
分层设计方案 36
数据保留规则 36
1仓库底层模型重构
针对新核心系统的数据表,重新进行整合层的主题域划分及模型设计,逐渐废除现有的新核心向老核心映射后的模型实体。
新设计的模型实体,可优先入模新核心的源系统,不要求外围系统的也按此模型入模(重保高时效应用依赖的外围表除外)。
但新设计的数据模型需考虑卡中心各外围系统,保持模型的稳定性,以及需考虑各源系统的数据到达时间,合理进行模型整合及拆分,保障下游应用的时效。后续外围系统的模型新增及调整,均可以此模型作为参照。
整合成新的仓库模型,在设计上需与传统数仓模型有一定区分,能满足大数据平台的特性,从存储、使用、性能、稳定等角度综合考虑。
由于后续仓库拟不存储敏感信息,需酌情在底层新增敏感信息的弱化信息处理(如手机号是否有效,长度等)。
重构共性加工层的模型,梳理出来的重要指标维度,需在共性加工层进行实现。将各集市及下游的共性指标维度(尤其是基础性指标)进行下沉,以及考虑到处理时效等,减少加工链路。
新核心新的业务特性,或者下游应用使用的一些重点主题,需合理考虑模型或指标维度的新增。
重构后的数据模型,必须能涵盖现有生产的所有下游应用,保障业务的延续性。底层数据模型的重构,需充分考虑生产上新老两套模型的并行方案,以支持后续两套模型的平稳过渡。
重构后的数据模型,包括整合层及共性层,整体批次时效不得晚于现有生产时效。数据仓库建模
一、数仓建模的目标
访问性能:能够快速查询所需的数据,减少数据I/O。
数据成本:减少不必要的数据冗余,实现计算结果数据复用,降低大数据系统中的存储成
本和计算成本。
使用效率:改善用户应用体验,提高使用数据的效率。
数据质量:改善数据统计口径的不一致性,减少数据计算错误的可能性,提供高质量的、一致的数据访问平台。
所以,大数据的数仓建模需要通过建模的方法更好的组织、存储数据,以便在性能、成本、效率和数据质量之间找到最佳平衡点。
二、四种建模方法
1、ER实体模型
在信息系统中,将事务抽象为''实体”(Entity)、“属性”(Property)、“关系”(Relationship)来表示数据关联和事物描述,这种对数据的抽象建模通常被称为ER实体关系模型。
实体:通常为参与到过程中的主体,客观存在的,比如商品、仓库、货位、汽车,此实体非数据库表的实体表。
属性:对主体的描述、修饰即为属性,比如商品的属性有商品名称、颜色、尺寸、重量、产地等。
关系:现实的物理事件是依附于实体的,比如商品入库事件,依附实体商品、货位,就会有“库存”的属性产生;用户购买商品,依附实体用户、商品,就会有“购买数量”、“金额”的属性产品。
实体之间建立关系时,存在对照关系:
1:1:即1对1的关系
l:n:即1对多的关系
n:m:即多对多的关系
在日常建模中,“实体”用矩形表示,“关系”用菱形,“属性”用椭圆形。ER实体关系模型也称为E-R关系图。
应用场景:
1、 ER模型是数据库设计的理论基础,当前几乎所有的OLTP系统设计都采用ER模型建模的方式。
2、 BillInom提出的数仓理论,推荐采用ER关系模型进行建模。
3、 BI架构提出分层架构,数仓底层ods、dwd也多采用ER关系模型进行设计。
2、维度建模
维度建模源自数据集市,主要面向分析场景。RalphKimball推崇数据集市的集合为数据仓库,同时也提出了对数据集市的维度建模,将数据仓库中的表划分为事实表、维度表两种类型。
事实表:
在ER模型中抽象出了有实体、关系、属性三种类别,在现实世界中,每一个操作型事件,基本都是发生在实体之间的,伴随着这种操作事件的发生,会产生可度量的值,而这个过程就产生了一个事实表,存储了每一个可度量的事件。
维度表:
维度,顾名思义,看待事物的角度。比如从颜色、尺寸的角度来比较手机的外观,如pu、内存等角度比较手机性能。
维度表一般为单一主键,在ER模型中,实体为客观存在的事务,会带有自己的描述性属性,属性一般为文本性、描述性的,这些描述被称为维度。
比如商品,单一主键:商品ID,属性包括产地、颜色、材质、尺寸、单价等,但并非属性一定是文本,比如单价、尺寸,均为数值型描述性的,日常主要的维度抽象包括:时间维度表地理区域维度表等。
维度建模通常又分为星型模型和雪花模型
星型模型:
雪花模型:
堆廈表乩2
维度萄
维虞表2
JJ
■k^
醛度表3
錐虔再4
星型模型和雪花模型的主要区别在于对维度表的拆分,对于雪花模型,维度表的设计更加规范,一般符合3NF;而星型模型,一般采用降维的操作,利用冗余来避免模型过于复杂,提高易用性和分析效率。
雪花、星型模型对比:
1、 冗余:雪花模型符合业务逻辑设计,采用3NF设计,有效降低数据冗余;星型模型的维度表设计不符合3NF,反规范化,维度表之间不会直接相关,牺牲部分存储空间。
2、 性能:雪花模型由于存在维度间的关联,采用3NF降低冗余,通常在使用过程中,需要连接更多的维度表,导致性能偏低;星型模型反三范式,采用降维的操作将维度整合,以存储空间为代价有效降低维度表连接数,性能较雪花模型高。
3、 ETL:雪花模型符合业务ER模型设计原则,在ETL过程中相对简单,但是由于附属模型的限制,ETL任务并行化较低;星型模型在设计维度表时反范式设计,所以在ETL过程中整合业务数据到维度表有一定难度,但由于避免附属维度,可并行化处理。
大数据和传统关系型数据库的计算框架不一样,例如对比mapreduce和oracle,在mapreduce里面,每多一个表的关联,就多一个job。mapreduce的每个任务进来,要申请资源,分配容器,各节点通信等。有可能YARN调度时长大于任务运行时间,例如调度需要5秒才能申请到资源,而表之间的join只需要2秒。hive优化里面,要尽可能减少job任务数,也就是减少表之间的关联,可以用适当的冗余来避免低效的查询方式,这是和oracle等其他关系型数据库不同的地方。
(点此了解:MapReduce作业运行机制)
3、 DataVault模型
DataVault是在ER模型的基础上衍生而来,模型设计的初衷是有效的组织基础数据层,使之易扩展,灵活应对业务变化,同时强调历史性、可追溯性和原子性,不要求对数据进行过度的一致性处理,并非针对分析场景所设计。
DataVault模型是一种中心辐射式模型,其设计重点围绕着业务键的集成模式。这些业务键是存储在多个系统中的、针对各种信息的键,用于定位和唯一标识记录或数据。
DataVault模型包含三种基本结构:
1) 中心表-Hub:唯一业务键的列表,唯一标识企业实际业务,企业的业务主体集合。
2) 链接表-Link:表示中心表之间的关系,通过链接表串联整个企业的业务关联关系。
3) 卫星表-Satellite:历史的描述性数据,数据仓库中数据的真正载体。
DataVault是对ER模型更进一步的规范化,由于对数据的拆解更偏向于基础数据组织,在处理分析类场景时相对复杂,适合数仓底层构建,目前实际应用场景较少。
4、 Anchor
Anchor是对DataVault模型做了更进一步的规范化处理,初衷是为了设计高度可扩展的模型,核心思想是所有的扩张只添加而不修改,于是设计出的模型基本变成了K-V结构的模型,模型范式达到了6NF。
由于过度规范化,使用中牵涉到太多的join操作,目前没有实际案例,仅作了解。四种基本建模方法对比:
当前主流建模方法为:ER模型、维度建模。
1) ER模型
ER模型应用到构建数仓时更偏重数据整合,站在企业整体考虑,将各个系统的数据按相似性一致性进行合并处理,为数据分析、决策服务,但并不便于直接用来支持分析。
问题:
a) 需要全面梳理企业所有的业务和数据流;
b) 实施周期长;
c) 对建模人员要求高。
2) 维度模型维度建模是面向分析场景而生,针对分析场景构建数仓模型,重点关注快速、灵活的解决分析需求,同时能够提供大规模数据的快速响应性能。针对性强,主要应用于数据仓库构建和
OLAP引擎底层数据模型。
模型选择和设计的原则:
a) 数仓模型的选择是灵活的,不局限于某一种模型方法;
b) 数仓模型的设计也是灵活的,以实际需求场景为导向;
c) 模型设计要兼顾灵活性,可扩展,而对终端用户透明性;
d) 模型设计要考虑技术可靠性和实现成本。
总结
数据仓库建模中维度建模和3NF建模并不是OR的关系,它们更像是上下层的关系。
3NF基础模型更注重源数据怎么放,它是一个重在数据存放的数据仓库模型,基本特性为主题,标准化,集成、相对稳定、反应数据的历史变化。
维度模型更注重数据怎么用,它是一个面向数据分析型的数据仓库,基于事实表关联维度表进行多维分析。
传统数据仓库建设层级基本是
贴源层-〉3NF基础模型-〉维度模型层
总体概述
总体架构
在大数据背景下数据仓库模型包括基础层、共享层、应用层,其中基础层又包括ODS层和整合层,而ODS层又可以进一步根据需要分为增量贴源层和ODS历史层。
\
应用超
\
阍解市
共亭层
±t
i
整合层
ODS历史屋
数据仓库模型架枸
基础层
基础层通常包括贴源层、ODS历史层、整合层。
贴源层
通过Hive外部表搭建,存储每日增全量数据无需保留历史。
ODS历史层
ODS历时层保留初始全量数据以及每日增量数据,通过数据日期搭建分区表。ODS历史层是大数据平台下数据仓库模型架构中的一个新增层,也是数据仓库中非常关键的一层,它简单粗放的保留了原始数据历史轨迹,为平台下游应用的多维度,多视角分析挖掘提供数据保证。ODS历史层设计特点是冗余的,贴源的,可追溯的。在传统的数据仓库模型架构中由于存储的限制,ODS历史层没有落地。
整合层
整合层是整个数据仓库的核心层。数据经过ODS历时层之后再这里进行加工整合。我们通常所说的ER、DM、DV等建模方法在这里落地。整合层的设计因客户具体的数据情况而异。
基础层设计以数据为驱动。
共享层
共享层根据应用需求存储共性加工数据,避免数据集市的烟囱式开发。共享层采用维度模型设计思想。共享层设计以应用为驱动。
应用层
应用层通常按主题划分为财务,风险、客户、绩效等主题指标。应用层设计以业务需求为驱动。
设计范围
数据仓库建设由下而上,从基础层开始,我们首先需要梳理平台涉及到的数据范围。
设计目标
数据仓库基础层建设包括贴源层、ODS历史层、整合层的建设。其中贴源层、ODS历史
层建设逻辑比较简单,在此不再多讲。下面着重描述整合层的建设。整合层的定位,整合层的设计目标主要包括:
中性的,共享的:整合层的设计不针对某个特别的应用而设计,能涵盖银行业的业务范围,且满足金融机构不断产生的业务发展需求。
灵活的,可扩展的:能存放最详尽的历史数据,业务发生变化时易于扩展,适应复杂的实际业务情况。
稳定的,经得起考验的:数据模型能够在很长时间内保持稳定性,回答不断产生、不断变化且无法预先定义的业务问题。当未来新增源系统入仓或是大量新增源系统表,主题模型依然保持稳定,不会对模型进行大幅度的重构操作。
规范的,易懂的:使用业务语言进行模型设计,易于让业务人员理解和使用,有助于IT和业务部门人员的沟通。
总体设计原则
中信银行信用卡中心主题模型层逻辑数据模型设计将本着以博易公司FS-LDM产品整合层模型为核心骨架,结合博易公司FS-LDM在其他银行同业客户化的实施经验,后期参考中信银行信用卡中心大数据架构提升项目高阶模型现状和数据标准现状,同时充分考虑源系统的各种数据信息项以及信息调研的结果,搭建中信银行信用卡中心主题模型层高阶模型。
主题设计原则
博易公司FS-LDM包含10大主题。
FS-LDM主题
当事人主题
产品主题
协议主题
内部机构主题
事件主题
地理区域主题
营销主题
渠道主题
财务主题
当事人资产主题
在进行具体的数据调研后,会根据具体的业务调研分析进行一一对应且保证业务含义相同。同时也会梳理每个主题涉及到数据标准情况并进行一一对应。
在高阶逻辑数据模型设计阶段可能不对现有主题进行裁减,在详细设计阶段将结合信息调研分析结果,决定逻辑数据模型主题是否物理化。
核心实体设计原则
以FS-LDM中的现有实体为基础,结合FS-LDM在其他银行同业客户化的实施经验,参考中信银行信用卡中心数据仓库高阶模型现有成果和数据标准成果,形成中信银行信用卡中心高阶设计模型中的实体。结合源系统信息调研分析的结果和最终应用的需求,再对高阶模型进行完善。
整合层主题说明
当事人(PARTY)
当事人PARTY:—个人或者一组人,指金融机构所服务的任意对象和感兴趣进行分析的各种对象。如:个人或公司客户、潜在客户、代理机构、雇员、分行、部门等。一个当事人(Party)可以同时是这当中的许多角色。它们之间存在许多关系,如银行机构与客户(管理机构、开户机构等),内部机构之间(上下级等),企业之间(集团客户、担保人等),企业与个人(雇佣、担保等),个人之间(父子、夫妻、联络人等),这些在模型中都可以体现。
数据准入原则