目录
4.2 用kettle从源数据库中抽取数据(ODM+SDM)
1.概念
需要了解的概念:
OLTP是一个操作系统 OLAP是面向解释分析的系统
面向主题:客户在使用数仓的时候所关心的内容叫做主题,面向客户的需求
银行有哪些主题?客户、财务、贷款
集成的:根据主题,将采集业务数据整合汇总加工,形成业务宽表(业务明细表)
非易失:数据要做到准确、完整、一致、高效
随着时间变化而变化:数据是动态的不是死的
数据库三范式原则:1NF:字段不可分; 2NF:有主键,非主键字段依赖主键; 3NF:非主键字段不能相互依赖;解释:
1NF:原子性 字段不可再分,否则就不是关系数据库;
2NF:唯一性 一个表只说明一个事物;
3NF:每列都与主键有直接关系,不存在传递依赖;
一、星型模型
星型模型:是一种多维的数据关系,它由一个事实表(Fact Table)和一组维表(Dimension Table)组成。每个维表都有一个维作为主键,所有这些维的主键组合成事实表的主键。事实表的非主键属性称为事实(Fact),它们一般都是数值或其他可以进行计算的数据;如下图:
星型模型
星型架构是一种非正规化的结构,多维数据集的每一个维度都直接与事实表相连接,所以数据有一定的冗余
二、雪花型模型
雪花型模型:当有一个或多个维表没有直接连接到事实表上,而是通过其他维表连接到事实表上时,其图解就像多个雪花连接在一起,故称雪花模型。雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化,原有的各维表可能被扩展为小的事实表,形成一些局部的 "层次 " 区域,这些被分解的表都连接到主维度表而不是事实表。
雪花型模型
通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。雪花型结构去除了数据冗余。
三、星型模型VS雪花型模型
星型模型和雪花模型的对比,可以从以下四个角度来对比。
多张事实表共享一张维度表
1、查询性能角度来看
在OLTP-DW环节,由于雪花型要做多个表联接,性能会低于星型架构;但从DW-OLAP环节,由于雪花型架构更有利于度量值的聚合,因此性能要高于星型架构。
2、模型复杂度角度
星型架构更简单方便处理
3、层次结构角度
雪花型架构更加贴近OLTP系统的结构,比较符合业务逻辑,层次比较清晰。
4、存储角度
雪花型架构具有关系数据模型的所有优点,不会产生冗余数据,而相比之下星型架构会产生数据冗余。
四、星座模型
多张事实表共享一张维度表
五、总结
根据项目经验,一般建议使用星型模型。因为在实际项目中,往往最关注的是查询性能问题,至于磁盘空间一般都不是问题。当然,在维度表数据量极大,需要节省存储空间的情况下,或者是业务逻辑比较复杂、必须要体现清晰的层次概念情况下,可以使用雪花型模型。
六 事实表和维度表
ETL是将大量的原始数据经过提取(extract)、转换(transform)、加载(load)到目标存储数据仓库的过程。 ETL 虽然大部分应用在大数据领域,对小数据也可以经过这个过程的处理。在ETL中,数据首先从各种源系统(如数据库、文件、API等)中提取出来,然后在数据仓库或数据湖中进行一系列的转换和清洗操作,以消除数据中的错误、冗余和不一致,并按照业务需求对数据进行整合和格式化。
ETL过程中四个基本的过程:分别是抽取(extract)、清洗(clean)、一致性处理(confirm)和交付(delivery),简称为ECCD。
数据集市:也叫数据市场,是一个从操作的数据和其他的为某个特殊的专业人员团体服务的数据源中收集数据的仓库。
孤立点:指数据库中包含的一些与数据的一般行为或模型不一致的异常数据。
OLTP:OLTP为联机事务处理的缩写,OLAP是联机分析处理的缩写。前者是以数据库为基础的,面对的是操作人员和低层管理人员,对基本数据进行查询和增、删、改等处理。
OLAP:OLAP是在OLTP的基础上发展起来的,以数据仓库为基础的数据分析处理,是共享多维信息的快速分析,是被专门设计用于支持复杂的分析操作,侧重对分析人员和高层管理人员的决策支持。
粒度:指数据仓库的数据单位中保存数据细化或综合程度的级别。粒度影响存放在数据仓库中的数据量的大小,同时影响数据仓库所能回答查询问题的细节程度。
多维数据集:多维数据集是联机分析处理 (OLAP) 中的主要对象,是一项可对数据仓库中的数据进行快速访问的技术。多维数据集是一个数据集合,通常从数据仓库的子集构造,并组织和汇总成一个由一组维度和度量值定义的多维结构。
维度:是多维数据集的结构性特性。它们是事实数据表中用来描述数据的分类的有组织层次结构(级别)。这些分类和级别描述了一些相似的成员集合,用户将基于这些成员集合进行分析。
度量值:在多维数据集中,度量值是一组值,这些值基于多维数据集的事实数据表中的一列,而且通常为数字。此外,度量值是所分析的多维数据集的中心值。即,度量值是最终用户浏览多维数据集时重点查看的数字数据。您所选择的度量值取决于最终用户所请求的信息类型。一些常见的度量值有 sales、cost、expenditures 和 production count 等。
元数据:不同 OLAP 组件中的数据和应用程序的结构模型。元数据描述 OLTP 数据库中的表、数据仓库和数据集市中的多维数据集这类对象,还记录哪些应用程序引用不同的记录块。
级别:级别是维度层次结构的一个元素。级别描述了数据的层次结构,从数据的最高(汇总程度最大)级别直到最低(最详细)级别。
数据挖掘:数据挖掘使您得以定义包含分组和预测规则的模型,以便应用于关系数据库或多维 OLAP 数据集中的数据。之后,这些预测模型便可用于自动执行复杂的数据分析,以找出帮助识别新机会并选择有获胜把握的机会的趋势。
多维 OLAP (MOLAP):MOLAP 存储模式使得分区的聚合和其源数据的复本以多维结构存储在分析服务器计算机上。根据分区聚合的百分比和设计,MOLAP 存储模式为达到最快查询响应时间提供了潜在可能性。总而言之,MOLAP 更加适合于频繁使用的多维数据集中的分区和对快速查询响应的需要。
关系 OLAP (ROLAP):ROLAP 存储模式使得分区的聚合存储在关系数据库的表(在分区数据源中指定)中。但是,可为分区数据使用 ROLAP 存储模式,而不在关系数据库中创建聚合。
混合 OLAP (HOLAP):HOLAP 存储模式结合了 MOLAP 和 ROLAP 二者的特性。
粒度:数据汇总的层次或深度。
聚合|聚集:聚合是预先计算好的数据汇总,由于在问题提出之前已经准备了答案,聚合可以改进查询响应时间。
切块:由多个维的多个成员限定的分区数据,称为一个切块。
切片:由一个维的一个成员限定的分区数据,称为一个切片。
数据钻取:最终用户从常规多维数据集、虚拟多维数据集或链接多维数据集中选择单个单元,并从该单元的源数据中检索结果集以获得更详细的信息,这个操作过程就是数据钻取。
数据挖掘模型:数据挖掘使您得以定义包含分组和预测规则的模型,以便应用于关系数据库或多维 OLAP 数据集中的数据。之后,这些预测模型便可用于自动执行复杂的数据分析,以找出帮助识别新机会并选择有获胜把握的机会的趋势。
数据规范化:指将数据按比例缩放(如更换大单位),使之落入一个特定的区域(如0-1)以提高数据挖掘效率的方法。规范化的常用方法有:最大-最小规范化、零-均值规范化、小数定标规范化。
关联知识:是反映一个事件和其他事件之间依赖或相互关联的知识。如果两项或多项属性之间存在关联,那么其中一项的属性值就可以依据其他属性值进行预测。
数据挖掘:从大量的、不完全的、有噪声的、模糊的、随机的数据中,提取隐含在其中的、人们事先不知道的、但又是潜在有用的信息和知识的过程。
ROLAP:是基于关系数据库存储方式的,在这种结构中,多维数据被映像成二维关系表,通常采用星型或雪花型架构,由一个事实表和多个维度表构成。
MOLAP:是基于类似于“超立方”块的OLAP存储结构,由许多经压缩的、类似于多维数组的对象构成,并带有高度压缩的索引及指针结构,通过直接偏移计算进行存取。
数据归约:缩小数据的取值范围,使其更适合于数据挖掘算法的需要,并且能够得到和原始数据相同的分析结果。
遗传算法:是一种优化搜索算法,它首先产生一个初始可行解群体,然后对这个群体通过模拟生物进化的选择、交叉、变异等遗传操作遗传到下一代群体,并最终达到全局最优。
聚类:是将物理或抽象对象的集合分组成为多个类或簇(cluster)的过程,使得在同一个簇中的对象之间具有较高的相似度,而不同簇中的对象差别较大。
决策树:是用样本的属性作为结点,用属性的取值作为分支的树结构。它是分类规则挖掘的典型方法,可用于对新样本进行分类。
频繁项集:指满足最小支持度的项集,是挖掘关联规则的基本条件之一。
支持度:规则A→B的支持度指的是所有事件中A与B同地发生的的概率,即P(A∪B),是AB同时发生的次数与事件总次数之比。支持度是对关联规则重要性的衡量。
可信度:规则A→B的可信度指的是包含A项集的同时也包含B项集的条件概率
贷款五级形态:贷款五级分类制度是根据内在风险程度将商业贷款划分为正常、关注、次级、可疑、损失五类。贷款五级分类制是银行主要依据借款人的还款能力,即最终偿还贷款本金和利息的实际能力,确定贷款遭受损失的风险程度,其中后三类称为不良贷款。此前的贷款四级分类制度是将贷款划分为正常、逾期、呆滞、损失四类。
信用卡催收:分为银行内催和委外催收两种,内催通常是指逾期三个月以内的客户一般由银行客服提醒(M0期间)或电催部门电联(M1、2期间)或各营业网点办事处上门(M3期间)进行逾期款项催缴;委外催收主要指信用卡中心对于一些难处理,有问题,失去联系或者小金额的客户群在经过内部催收无果后委托给专业从事催收行业的公司(部分是律师事务所)进行催缴。
贷款展期:贷款到期不能归还,经批准办理延长归还时间的手续。贷款到期就要归还,是企业必须遵守的信用原则,也是银行加速信贷资金周转的前提条件。如企业遇有特殊情况,确实无法按期还款时,应提出申请,说明情况,经银行审查同意后,可延长还款时间,但需办理转期手续,否则按逾期贷款处理。
动账交易:动帐指的是开通网银的帐户在网上发生业务.包括支付转帐,内部转帐、转存,网上缴费,买卖基金\股票等等。
计提:计算和提取。按规定的比率与规定的基数相乘计算提取,列入某科目。
2.架构
2.1. 逻辑架构:数据流向,数据分层
在建设一个银行数据仓库项目时,数据流向是将源系统(OLTP)中的数据通过elt工具(如kettle)传输到ODM贴源层和SDM标准层,实现快速接入和临时存放,并添加了时间戳和标签,然后再通过etl工具中的各类组件实现数据类型的统一、编码的统一、数据质量的统一(去除空值和特殊符号)并清洗脏数据(与字段不相符的数据);然后通过数据挖掘技术(FDM层)(如编写存储过程、使用hive脚本、使用odpsSQL语句处理大数据),根据数据字典将业务数据根据主题集成加工成业务宽表(映射关系);随后传入到ADM应用层,应用层是用于提供分析性的数据,支持各种可视化大屏分析、报表、监管报送、为下游系统提供数据支撑服务(OLAP系统),ADM层常用的工具包括数据可视化工具(如可视化技术、FineReport、FineBI、永洪、MSTR、HTML5 CSS JS VUE PHP)
2.1.1应用层:
(1)可视化大屏分析
(2)监管报送
(3)OLAP系统(为下游系统提供数据支撑服务)
2.1.2 源系统|上游系统|OLTP
(1)核心系统
(2)信贷系统
(3)总账
(4)CRM
(5)ECIF
(6)资金系统
(7)中间业务
2.1.3 ODM贴源层
(1)实现快速接入,临时存放
(2)添加时间戳和数据来源标签
- ODM的英文全称是Origin Data Manager,即数据仓库的贴源层,顾名思义,数据层的数据结构跟源系统的数据结构一致。数据总线把每日采集的源系统增量数据文本加载到ODM层中;
- ODM层由于仅保留源系统当日增量数据,且数据结构与源系统一致,故数据加载速度是极快的,无需担心贴源层的数据加载对数据仓库性能造成影响;
- 由于ODM层的数据结构与源系统一致,所以排查数据质量问题时可通过ODM层溯源排查。当然,ODM层仅保留当日增量数据的设计会限制溯源的范围,这是使用关系型数据库搭建数据仓库造成存储成本极高的缘故。当前使用大数据技术框架搭建数据仓库,可使用普通磁盘存储数据,使得存储成本大幅降低,所以也保留ODM层贴源数据的历史轨迹。从很多银行搭建历史数据查询平台来看也能说明这一点;
- 虽然ODM层只是加载源系统的每日增量数据,且数据结构与源系统一致,无任何复杂加工,但很多开发团队会因不重视导致底层数据加载出错,引发连锁的数据问题。解决方案可参考数据总线,关键是做好监控保证数据加载的准确性与稳定性。
2.1.4 SDM标准层
(1)数据类型统一
(2)统一编码
(3)清洗脏数据
(4)数据质量统一
- FDM的英文全称是Finance Data Manager,即数据仓库的金融主题层。当然,金融主题层是针对银行而言,对一般企业,称为主题模型层会更加合适。由于银行业务系统是繁多且复杂的,基于源系统数据模型加工数据应用时,必须要对其熟悉才行,而且源系统数量还不少(至少80个以上),要熟练掌握所有源系统数据模型并灵活运用的学习成本极高。对源系统数据模型按照一定的主题进行梳理与整合后,数据应用开发只需学习主题模型即可,大大降低开发门槛与学习成本;
- 主题划分是一门艺术。划分主题少了,数据过度整合反而使数据模型更加不好理解,且强硬整合不同业务种类的源数据会出现各种奇奇怪怪的数据问题。划分主题多了,数据模型简化达不到效果,使用时跟源系统的数据模型差异不大。所以划分主题建议找业务知识深厚、实施经验丰富的建模专家主导设计,让FDM层建设少踩点坑;
- FDM层位于原始数据(ODM层,SDM层数据结构基本与源系统一致,所以可统称为原始数据)与应用数据之间,起到缓冲地带的作用。一旦源系统数据模型发生变更,数据仓库只需调整SDM层与FDM层的数据映射即可,而FDM层与ADM层的数据映射是基本不变的,保证了ADM层的稳定性。
2.1.5 FDM基础层,模型层
将业务数据根据主题进行集成加工——宽表
2.1.6 ADM分析层
根据甲方需求对宽表数据进行不同维度的汇总
- ADM的英文全称为Application Data Manager,即数据仓库的数据应用层,主要为数据服务而产生的。由于数据服务一般具备特定业务场景,所以ADM层以服务特定业务场景的数据集市形态存在。然而,有两类数据集市对于ADM层来说相对异类,一个是共性宽表,另一个是指标体系,因为这两类数据集市并非针对特定业务场景,而是针对共性业务场景;
- 共性宽表由日常数据分析使用频繁的,共性的元素,按业务主键关联并整合的明细数据。共性宽表主要为了业务人员进行自助数据分析,业务人员可根据共性宽表的维度自由组合筛选及对表内元素编辑计算逻辑从而快速设计报表;
- 指标体系由日常数据分析使用频繁的,共性的统计指标,按相同的统计维度关联并整合的汇总数据。指标体系主要为了让业务人员快速查询统计数据及自由编辑指标计算逻辑来衍生新指标,从而快速了解业务的经营情况。对比共性宽表,指标体系少了灵活性(因指标统计口径是固化在代码中,只能靠技术人员维护),但能极大提升查询效率。
- 共性宽表与指标体系可结合成为业务人员的自助统计工具,既帮助业务人员快速获取想要的数据,又能大大解放开发团队的工作量。
很多童鞋可能对共性宽表与指标体系抱有疑问:为什么不把这两类的数据模型做成数据仓库的共性模型层?这里分享一下作者的观点:
1、共性宽表与指标体系都是针对日常数据分析使用频繁的,共性的内容进行整合,达到数据共享的效果。实际上,数据应用的统计指标都具备特定业务场景特色,而非共性统计指标可以满足,比如有效账户数统计,共性统计指标口径是要求非注销的账户,而 A 部门的口径是要求账户非注销,且账户余额不为 0,这样实际共性统计指标的共享性会大打折扣。
2、共性宽表与指标体系无法覆盖所有的源数据,也就是说数据应用会从金融主题层与共性模型层取数加工,会导致血缘关系的絮乱。
3、一些基础的共性统计指标也可以落地到金融主题层,这样既满足数据共享,也满足清晰的血缘关系。
- 银行既是营销金融产品的机构,也是风险运营的机构,所以营销集市与风险集市对业务支撑作用极大;
- 营销集市核心是建设客户标签体系,由客户标签构成客户画像助力营销;
- 风险集市核心是建设风险评分体系及风险预警体系。风险评分体系贯穿整个信贷业务的生命周期,为快速业务决策提供数据支持。风险预警体系通过统计与展示全行机构的风险运营的数据,让领导层及时识别经营风险及采取相应措施;
- 无论是营销集市的客户画像体系还是风险集市的风险评分体系,都需要形成业务数据闭环来不断迭代与优化。