目录
1.概念
一、星型模型
二、雪花型模型
三、星型模型VS雪花型模型
四、星座模型
五、总结
六 究竟表和维度表
2.架构
2.1. 逻辑架构：数据流向，数据分层
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）添加时间戳和数据泉源标签
2.1.4 SDM标准层
（1）数据类型统一
（2）统一编码
（3）洗濯脏数据
（4）数据质量统一
2.1.5 FDM底子层，模型层
2.1.6 ADM分析层
2.2 物理架构（硬件）
2.2.1软硬件架构
2.2.2 硬件环境设计
2.3 技能架构（技能栈）
2.3.1 数据收罗技能
（1）ETL工具有哪些？
2.3.2 数据存储技能
（1）关系型数据库
（2）非关系型数据库
（3）分布式数据库
（4）关系型数据库和分布式数据库的横向对比
2.3.3 数据挖掘技能
（1）存储过程
（2）hive脚本
（3）SQL
（4）odpsSQL
2.3.4 可视化技能
（1）FineReport
（2）FineBI
（3）永洪
（4）MSTR
（5）HTML5 CSS JS VUE PHP
2.3.5 web中心件
（1）tomcat
（2）weblogic
（3）jboss
2.3.6 调度技能
3.熟悉银行业务底子
3.1 银行存款业务
3.1.1 个人储备存款业务
1.概念
2. 分类
3.活期储备
4.定期储备
3.1.2 外币储备存款业务
3.1.3 挂失业务
3.1.4 止付、冻结业务
3.1.5 个人存款证明
3.1.6 对公存款
1.概念
2.分类
3. 活期存款
4.定期存款
5.协议存款
5.关照存款
3.1.7 存款结计利钱
1.利率
概念
利率类型
我国现在的存款利率政策
利率换算公式
2.计息起点
3.存款存期盘算规则
4.计结息规则
5.积数计息法
6.逐笔计息法
3.2 银行贷款业务
3.3 银行理财业务
4.搭建数仓
4.1 kettle
4.1.1 第一个转换案例
1.新建转换，新建db毗连编辑
2.创建表输入（从源系统数据库抽取数据）
3.创建表输出（将数据传输到ODM数据库）
4.按住shift毗连两个对象
5.双击编辑表输入
6.双击编辑表输出
7.匹配字段
8.启动
9.查看数据库
4.1.2 焦点对象中的组件
1.concat fields 拼接字段
2.值映射(改变源值）语言转换
3.剪切字符串
4.字符串更换
5.EXCEL 列转行 排序记录
6.去重的两种方式
7.列拆分多行
8.增长序列
9.字符串操作
10.字段选择(转换数据类型)
11.盘算器
12.更换空值
13.数据分流
14.过滤记录
15.停止（一般配合过滤记录使用）
16.数据库查询
17.流查询
18.记录集毗连
19.分组聚合（根据分组字段求平均值）
20.设置和获取环境变量
21.获取系统信息
22.插入更新
23.数据同步
4.2 用kettle从源数据库中抽取数据（ODM+SDM）
4.2.1 贷款表
4.3 开发个人活期账户信息宽表（FDM）
4.3.1 需求调研（关心哪些数据项）
4.3.2 设计模型 建表
4.3.3 开发
1.开发映射文档
2.存储过程
3.异常处理
4.3.4 测试
1.概念
必要了解的概念：
OLTP是一个操作系统 OLAP是面向解释分析的系统
<hr>
面向主题：客户在使用数仓的时候所关心的内容叫做主题，面向客户的需求
银行有哪些主题？客户、财政、贷款
集成的：根据主题，将收罗业务数据整合汇总加工，形成业务宽表（业务明细表）
非易失：数据要做到正确、完整、一致、高效
随着时间变化而变化：数据是动态的不是死的
<hr> 数据库三范式原则：1NF:字段不可分; 2NF:有主键，非主键字段依赖主键; 3NF:非主键字段不能相互依赖;解释:
1NF:原子性 字段不可再分,否则就不是关系数据库;
2NF:唯一性 一个表只说明一个事物;
3NF:每列都与主键有直接关系，不存在通报依赖;
<hr> 一、星型模型
星型模型：是一种多维的数据关系，它由一个究竟表（Fact Table）和一组维表（Dimension Table）组成。每个维表都有一个维作为主键，所有这些维的主键组合成究竟表的主键。究竟表的非主键属性称为究竟（Fact），它们一般都是数值或其他可以进行盘算的数据；如下图：
星型模型
星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与究竟表相毗连，所以数据有一定的冗余
二、雪花型模型
雪花型模型：当有一个或多个维表没有直接毗连到究竟表上，而是通过其他维表毗连到究竟表上时，其图解就像多个雪花毗连在一起，故称雪花模型。雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的究竟表，形成一些局部的 "层次 " 区域，这些被分解的表都毗连到主维度表而不是究竟表。
雪花型模型
通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。雪花型结构去除了数据冗余。
三、星型模型VS雪花型模型
星型模型和雪花模型的对比，可以从以下四个角度来对比。
多张究竟表共享一张维度表
1、查询性能角度来看
在OLTP-DW环节，由于雪花型要做多个表联接，性能会低于星型架构；但从DW-OLAP环节，由于雪花型架构更有利于度量值的聚合，因此性能要高于星型架构。
2、模型复杂度角度
星型架构更简单方便处理
3、层次结构角度
雪花型架构更加贴近OLTP系统的结构，比较符合业务逻辑，层次比较清晰。
4、存储角度
雪花型架构具有关系数据模型的所有长处，不会产生冗余数据，而相比之下星型架构会产生数据冗余。
四、星座模型
多张究竟表共享一张维度表
五、总结
根据项目履历，一般建议使用星型模型。因为在实际项目中，每每最关注的是查询性能问题，至于磁盘空间一般都不是问题。当然，在维度表数据量极大，必要节省存储空间的情况下，大概是业务逻辑比较复杂、必须要体现清晰的层次概念情况下，可以使用雪花型模型。
六 究竟表和维度表
<hr> ETL是将大量的原始数据经过提取（extract）、转换（transform）、加载（load）到目标存储数据堆栈的过程。 ETL 虽然大部门应用在大数据领域，对小数据也可以经过这个过程的处理。在ETL中，数据首先从各种源系统（如数据库、文件、API等）中提取出来，然后在数据堆栈或数据湖中进行一系列的转换和洗濯操作，以消除数据中的错误、冗余和不一致，并按照业务需求对数据进行整合和格式化。
<hr> ETL过程中四个根本的过程：分别是抽取（extract）、洗濯（clean）、一致性处理（confirm）和交付（delivery），简称为ECCD。
<hr> 数据集市：也叫数据市场，是一个从操作的数据和其他的为某个特殊的专业人员团体服务的数据源中网络数据的堆栈。
<hr> 孤立点：指数据库中包含的一些与数据的一般行为或模型不一致的异常数据。
<hr> OLTP：OLTP为联机变乱处理的缩写，OLAP是联机分析处理的缩写。前者是以数据库为底子的，面临的是操作人员和低层管理人员，对根本数据进行查询和增、删、改等处理。
<hr> OLAP：OLAP是在OLTP的底子上发展起来的，以数据堆栈为底子的数据分析处理，是共享多维信息的快速分析，是被专门设计用于支持复杂的分析操作，侧重对分析人员和高层管理人员的决议支持。
<hr> 粒度：指数据堆栈的数据单元中生存数据细化或综合程度的级别。粒度影响存放在数据堆栈中的数据量的大小，同时影响数据堆栈所能回答查扣问题的细节程度。
<hr> 多维数据集：多维数据集是联机分析处理 (OLAP) 中的主要对象，是一项可对数据堆栈中的数据进行快速访问的技能。多维数据集是一个数据集合，通常从数据堆栈的子集构造，并组织和汇总成一个由一组维度和度量值定义的多维结构。
<hr> 维度：是多维数据集的结构性特性。它们是究竟数据表中用来形貌数据的分类的有组织层次结构(级别)。这些分类和级别形貌了一些相似的成员集合，用户将基于这些成员集合进行分析。
<hr> 度量值：在多维数据集中，度量值是一组值，这些值基于多维数据集的究竟数据表中的一列，而且通常为数字。此外，度量值是所分析的多维数据集的中心值。即，度量值是最终用户浏览多维数据集时重点查看的数字数据。您所选择的度量值取决于最终用户所哀求的信息类型。一些常见的度量值有 sales、cost、expenditures 和 production count 等。
<hr> 元数据：不同 OLAP 组件中的数据和应用步伐的结构模型。元数据形貌 OLTP 数据库中的表、数据堆栈和数据集市中的多维数据集这类对象，还记录哪些应用步伐引用不同的记录块。
<hr> 级别：级别是维度层次结构的一个元素。级别形貌了数据的层次结构，从数据的最高(汇总程度最大)级别直到最低(最具体)级别。
<hr> 数据挖掘：数据挖掘使您得以定义包含分组和预测规则的模型，以便应用于关系数据库或多维 OLAP 数据集中的数据。之后，这些预测模型便可用于自动执行复杂的数据分析，以找出帮助识别新时机并选择有获胜把握的时机的趋势。
<hr> 多维 OLAP (MOLAP)：MOLAP 存储模式使得分区的聚合和其源数据的复本以多维结构存储在分析服务器盘算机上。根据分区聚合的百分比和设计，MOLAP 存储模式为达到最快查询响应时间提供了潜在可能性。总而言之，MOLAP 更加得当于频仍使用的多维数据集中的分区和对快速查询响应的必要。
<hr> 关系 OLAP (ROLAP)：ROLAP 存储模式使得分区的聚合存储在关系数据库的表(在分区数据源中指定)中。但是，可为分区数据使用 ROLAP 存储模式，而不在关系数据库中创建聚合。
<hr> 混合 OLAP (HOLAP)：HOLAP 存储模式联合了 MOLAP 和 ROLAP 二者的特性。
<hr> 粒度：数据汇总的层次或深度。
<hr> 聚合|聚集：聚合是预先盘算好的数据汇总，由于在问题提出之前已经预备了答案，聚合可以改进查询响应时间。
<hr> 切块：由多个维的多个成员限定的分区数据，称为一个切块。
<hr> 切片：由一个维的一个成员限定的分区数据，称为一个切片。
<hr> 数据钻取：最终用户从通例多维数据集、虚拟多维数据集或链接多维数据集中选择单个单元，并从该单元的源数据中检索结果集以获得更具体的信息，这个操作过程就是数据钻取。
<hr> 数据挖掘模型：数据挖掘使您得以定义包含分组和预测规则的模型，以便应用于关系数据库或多维 OLAP 数据集中的数据。之后，这些预测模型便可用于自动执行复杂的数据分析，以找出帮助识别新时机并选择有获胜把握的时机的趋势。
<hr> 数据规范化：指将数据按比例缩放(如更换大单元)，使之落入一个特定的区域（如0－1）以提高数据挖掘服从的方法。规范化的常用方法有：最大－最小规范化、零－均值规范化、小数定标规范化。
<hr> 关联知识：是反映一个变乱和其他变乱之间依赖或相互关联的知识。如果两项或多项属性之间存在关联，那么其中一项的属性值就可以依据其他属性值进行预测。
<hr> 数据挖掘：从大量的、不完全的、有噪声的、模糊的、随机的数据中，提取隐含在其中的、人们事先不知道的、但又是潜在有用的信息和知识的过程。
<hr> ROLAP：是基于关系数据库存储方式的，在这种结构中，多维数据被映像成二维关系表，通常采用星型或雪花型架构，由一个究竟表和多个维度表构成。
<hr> MOLAP：是基于类似于“超立方”块的OLAP存储结构，由很多经压缩的、类似于多维数组的对象构成，并带有高度压缩的索引及指针结构，通过直接偏移盘算进行存取。
<hr> 数据归约：缩小数据的取值范围，使其更得当于数据挖掘算法的必要，而且能够得到和原始数据相同的分析结果。
<hr> 遗传算法：是一种优化搜刮算法，它首先产生一个初始可行解群体，然后对这个群体通过模拟生物进化的选择、交叉、变异等遗传操作遗传到下一代群体，并最终达到全局最优。
<hr> 聚类：是将物理或抽象对象的集合分组成为多个类或簇(cluster)的过程，使得在同一个簇中的对象之间具有较高的相似度，而不同簇中的对象差异较大。
<hr> 决议树：是用样本的属性作为结点，用属性的取值作为分支的树结构。它是分类规则挖掘的典型方法，可用于对新样本进行分类。
<hr> 频仍项集：指满意最小支持度的项集，是挖掘关联规则的根本条件之一。
<hr> 支持度：规则A→B的支持度指的是所有变乱中A与B同地发生的的概率，即P(A∪B)，是AB同时发生的次数与变乱总次数之比。支持度是对关联规则重要性的衡量。
<hr> 可信度：规则A→B的可信度指的是包含A项集的同时也包含B项集的条件概率
<hr> 贷款五级形态：贷款五级分类制度是根据内在风险程度将商业贷款分别为正常、关注、次级、可疑、损失五类。贷款五级分类制是银行主要依据乞贷人的还款能力，即最终偿还贷款本金和利钱的实际能力，确定贷款遭受损失的风险程度，其中后三类称为不良贷款。此前的贷款四级分类制度是将贷款分别为正常、逾期、呆滞、损失四类。
<hr> 信用卡催收：分为银行内催和委外催收两种，内催通常是指逾期三个月以内的客户一般由银行客服提示（M0期间）或电催部门电联（M1、2期间）或各营业网点办事处上门（M3期间）进行逾期款项催缴；委外催收主要指信用卡中心对于一些难处理，有问题，失去联系大概小金额的客户群在经过内部催收无果后委托给专业从事催收行业的公司（部门是状师变乱所）进行催缴。
<hr> 贷款展期：贷款到期不能归还，经批准办理延长归还时间的手续。贷款到期就要归还，是企业必须遵守的信用原则，也是银行加速信贷资金周转的前提条件。如企业遇有特殊情况，确实无法按期还款时，应提出申请，说明情况，经银行检察同意后，可延长还款时间，但需办理转期手续，否则按逾期贷款处理。
<hr> 动账交易：动帐指的是开通网银的帐户在网上发生业务.包罗支付转帐,内部转帐、转存,网上缴费,交易基金\股票等等。
<hr> 计提：盘算和提取。按规定的比率与规定的基数相乘盘算提取，列入某科目。
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、一些底子的共性统计指标也可以落地到金融主题层，如许既满意数据共享，也满意清晰的血缘关系。
- 银行既是营销金融产品的机构，也是风险运营的机构，所以营销集市与风险集市对业务支持作用极大；
- 营销集市焦点是建设客户标签体系，由客户标签构成客户画像助力营销；
- 风险集市焦点是建设风险评分体系及风险预警体系。风险评分体系贯穿整个信贷业务的生命周期，为快速业务决议提供数据支持。风险预警体系通过统计与展示全行机构的风险运营的数据，让领导层及时识别谋划风险及采取相应措施；
- 无论是营销集市的客户画像体系还是风险集市的风险评分体系，都必要形成业务
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
