银行数据仓库的架构

1. 数据仓库的定义

官方定义
数据仓库是一个面向主题的、集成的、随时间变化的、但信息本身相对稳定的数据集合，用于对管理决策过程的支持。
这个定义的确官方，但是却指出了数据仓库的四个特点。
特点
面向主题：数据仓库都是基于某个明确主题，仅需要与该主题相关的数据，其他的无关细节数据将被排除掉
集成的：从不同的数据源采集数据到同一个数据源，此过程会有一些ETL操作
随时间变化：关键数据隐式或显式的基于时间变化
信息本身相对稳定：数据装入以后一般只进行查询操作，没有传统数据库的增删改操作
效率足够高：数据仓库的分析数据一般分为日、周、月、季、年等，可以看出，日为周期的数据要求的效率最高，要求24小时甚至12小时内，目前普遍的数据展现方式为T+1，即当日处理昨日的业务数据。
数据质量：基于数据仓库的应用所面对的一般为企业决策层用户，所以对数据仓库提供的各种信息，肯定要准确的数据；但由于数据源有脏数据或者代码不严谨，所以数据仓库流程通常分为多个步骤，包括数据抽取，清洗，转换，装载，查询，展现等等；其中数据清洗则主要对抽取过来各数据源的脏数据和不规范数据进行统一标准化。
扩展性：有的大型数据仓库系统架构设计复杂，是因为考虑到了未来3-5年的扩展性，这样的话，未来不用花太多时间去重建数据仓库系统，就能很稳定运行。主要体现在数据建模的合理性，数据仓库方案中多出一些中间层，使海量数据流有足够的缓冲，不至于因为数据源的变动而导致用户应用功能的频繁变动。

个人理解
数据仓库就是整合多个和多种数据源的历史和现在的数据进行标准化整合，统一口径，细粒度的、多维度的分析，帮助高层管理者或者业务分析人员做出商业战略决策或商业报表。唤醒企业沉睡多年的历史数据。

2. 数据仓库的用途

1.整合公司所有业务数据，建立统一的数据中心
2.产生业务报表，用于作出决策
3.为网站运营提供运营上的数据支持
4.可以作为各个业务的数据源，形成业务数据互相反馈的良性循环
5.分析用户行为数据，通过数据挖掘来降低投入成本，提高投入效果
6.开发数据产品，直接或间接地为公司盈利

3. 数据仓库架构

3.1 数仓分层原则

优秀可靠的数仓体系，往往需要清晰的数据分层结构，即要保证数据层的稳定又要屏蔽对下游的影响，并且要避免链路过长。那么问题来了，一直在讲数仓要分层，那数仓分几层最好？
目前市场上主流的分层方式眼花缭乱，不过看事情不能只看表面，还要看到内在的规律，不能为了分层而分层，没有最好的，只有适合的。
分层是以解决当前业务快速的数据支撑为目的，为未来抽象出共性的框架并能够赋能给其他业务线，同时为业务发展提供稳定、准确的数据支撑，并能够按照已有的模型为新业务发展提供方向，也就是数据驱动和赋能。
一个好的分层架构，要有以下好处：

1. 清晰数据结构；
2. 数据血缘追踪；
3. 减少重复开发；
4. 数据关系条理化；
5. 屏蔽原始数据的影响。
   数仓分层结构一般如下：
   

3.2 数仓分层详细介绍

3.2.1 贴源层：ODS（Operational Data Store）

ODS 层，是最接近数据源中数据的一层，为了考虑后续可能需要追溯数据问题，因此对于这一层就不建议做过多的数据清洗工作，原封不动地接入原始数据即可，至于数据的去噪、去重、异常值处理等过程可以放在后面的DWD 层来做。

3.2.2 数据仓库层：DW（Data Warehouse）

数据仓库层是我们在做数据仓库时要核心设计的一层，在这里，从ODS 层中获得的数据按照主题建立各种数据模型。DW 层又细分为DWD（Data Warehouse Detail）层、DWM（Data WareHouse Middle）层和DWS（Data WareHouse Servce） 层。

3.2.2.1 数据明细层：DWD（Data Warehouse Detail）

该层一般保持和ODS 层一样的数据粒度，并且提供一定的数据质量保证。DWD 层要做的就是将数据清理、整合、规范化、脏数据、垃圾数据、规范不一致的、状态定义不一致的命名不规范的数据都会被处理。同时，为了提高数据明细层的易用性，该层会采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联。另外，在该层也会做一部分的数据聚合，将相同主题的数据汇集到一张表中，提高数据的可用性。

3.2.2.2 数据中间层：DWM（Data WareHouse Middle）

该层会在DWD 层的数据基础上，数据做轻度的聚合操作，生成一系列的中间表，提升公共指标的复用性，减少重复加工。直观来讲，就是对通用的核心维度进行聚合操作，算出相应的统计指标。在实际计算中，如果直接从DWD 或者ODS 计算出宽表的统计指标，会存在计算量太大并且维度太少的问题，因此一般的做法是，在DWM 层先计算出多个小的中间表，然后再拼接成一张DWS 的宽表。由于宽和窄的界限不易界定，也可去掉DWM 这一层，只留DWS 层，将所有的数据再放在DWS 亦可。

3.2.2.3 数据服务层（主题层）：DWS（Data WareHouse Service）

DWS 层为公共汇总层，会进行轻度汇总，粒度比明细数据稍粗，基于DWD 层上的基础据，整合汇总成分析某一个主题域的服务数据，一般是宽表。DWS 层应覆盖80% 的应用场景。又称数据集市或宽表。
按照业务划分，如主题域流量、订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP 分析，数据分发等。
一般来讲，该层的数据表会相对比较少，一张表会涵盖比较多的业务内容，由于其字段较多，因此一般也会称该层的表为宽表。

3.2.3 数据应用层：APP（Application）

在这里，主要是提供给数据产品和数据分析使用的数据，一般会存放在ES、PostgreSql、Redis 等系统中供线上系统使用，也可能会存在Hive 或者Druid中供数据分析和数据挖掘使用。比如我们经常说的报表数据，一般就放在这里。

3.2.4 维表层（Dimension）

如果维表过多，也可针对维表设计单独一层，维表层主要包含两部分数据：
高基数维度数据：一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。
低基数维度数据：一般是配置表，比如枚举值对应的中文含义，或者日期维表。数据量可能是个位数或者几千几万。

4. 主题层主题域的划分

4.1国外主流的金融主题划分方案

4.1.1 Teradata FS-LDM 十大金融主题模型

Teradata 公司作为全球最大的专注于大数据分析、数据仓库和整合营销管理解决方案的供应商，并提出一种先进的 FS-LDM 模型（Financial Services Logcial Data Model），把银行约 80% 的业务数据囊括在该模型中。
Teradata FS-LDM 是一个成熟产品，在一个集成的模型内支持保险、银行及证券，包含十大主题：当事人、产品、协议、事件、资产、财务、机构、地域、营销、渠道。具体划分如下图所示：

4.1.2 IBM BDWM 九大金融主题模型

IBM 公司作为数据仓库和数据分析的“元老级”企业，为了对抗 Teradata 公司的 FS-LDM 模型，提出了 BDWM（Banking Date Warehouse Model）九大金融主题模型，主题模型分为参与人、合约、条件、产品、地点、分类、业务方向、事件和资源项目。具体划分如下图所示：

4.2金融主题层划分及建模思路

由上述的 FS-LDM 模型与 BDWM 模型，可以分析出以下共性：

1） 描述银行客户信息的主题；
2） 描述银行机构及员工信息的主题；
3） 描述银行产品信息的主题；
4） 描述银行与客户之间契约信息的主题；
5） 描述银行与客户资产信息的主题；
6） 描述客户使用银行服务时产生的行为信息的主题；
7） 描述银行与客户联系信息的主题。

由于 FS-LDM 模型偏向财务及营销方向，所以多出描述银行营销活动信息及财务风险信息的主题。而 BDWM 模型偏向银行环境及法规方向，所以多出描述银行环境信息及业务信息的主题。

结合上述两大金融模型及本地银行的数据环境，笔者建议以下优化点：

1）取消地域主题。地域主题来源于国外的邮寄销售业务，该业务是国外银行产品重要的引流及销售手段之一。但国内银行甚少开展邮寄销售业务，故地域主题重点描述的邮箱、电话、区域、地址等信息，都可以整合到客户主题内。

2）财务主题重点在总账数据。总账是银行的记账核心，总账数据一般存放在银行的核心系统或总账财务系统中。通过分析总账数据，可以分析出银行的经营状况、统计出银行的业务结构。同时通过汇总业务系统的账务数据，还可以进行以银行科目为维度的总分校验，保证余额信息的准确性。故财务主题的重点应为总账数据。

3）增加公共主题描述业务系统的码值与参数数据模型。业务系统的逻辑处理过程中，会产生大量的码值与参数，比如机构编码、状态编码、业务控制参数、节点配置参数等。这类数据对于识别数据的业务状态，及代码的中文含义，起到至关重要的作用，但这类数据跟已有的金融主题的关联性不强，故需单独增加公共主题进行建模管理。

最终，笔者认为 FDM 层的金融主题划分应划分为客户、产品、协议、事件、渠道、营销、内部机构、资产、财务、公共，具体如下图所示：

4.2.1 客户主题

银行的客户信息会在多个业务系统中进行登记，比如网上银行、手机银行等渠道系统，理财系统、信贷系统、核心系统等，且多个业务系统中保存的客户信息还大概率的不一致。这时，在使用客户信息时就会出现疑惑：以哪个系统的客户信息为准？多个业务系统的个性化客户信息如何整合？所以，建设统一客户视图管理是银行数据工作的重点。

建设统一客户视图管理一般实践方式为建设 ECIF（客户信息管理）系统，由 ECIF 系统整合各个业务系统的客户信息形成统一视图，为全行提供客户信息查询服务。假如行内未建设 ECIF 系统，亦应在数仓上建设统一客户视图的客户信息主题，替代 ECIF 系统为全行提供客户信息查询服务。落地统一客户视图关键是与全行业务部门约定好客户信息整合的优先级及更新规则，因为客户信息整合很可能会影响到客户经理的绩效，从而影响业务部门的绩效。确定业务规则并获得全行支持后，通过 ETL 手段每日提取业务系统的增量客户信息整合处理即可。
银行客户主要分为个人客户、对公客户及同业客户。客户主题的建模应对这三类客户进行单独建模，原因如下：

1）数据分析时很少对所有客户进行统一分析，更多的情景是分析每类客户的情况；
2）单独建模可以避免单表的数据量过大，加快统一视图的数据整合效率；
3）相似数据进行“求同存异”的整合时，必定存在大量字段空值的情况，既影响数据的存储也影响表的查询速度。
故，客户主题的建模思路如下所示

4.2.2 产品主题

金融产品是银行经营的核心，也是银行与客户建立关系的纽带。金融产品主要分为以下类别：

1）负债类产品。负债类产品一般为存款类产品和理财类产品，主要用于银行吸纳客户的合法资金，再运用该资金进行信贷或资管类产品投资。客户“借钱”给银行后，银行会按照约定的利率或者收益率，计提利息或收益并返回给客户，所以负债类产品的利率或收益率是银行向客户“借钱”的成本。
2）资产类产品。资产类产品主要是信贷融资类产品，主要用于银行“借钱”给客户，并向客户按约定的利率或费率收取客户的利息或费用，从而产生利润。信贷融资类产品又分为：
a）零售信贷，比如购房贷款、汽车贷款、教育贷款等；
b）对公信贷，比如经营贷款、购货贷款、小微企业贷款等；
c）政策信贷，比如涉农专项贷款、绿色贷款、联合平台贷款等；
d） 票据融资，比如承兑汇票贴现、转贴现等；
e） 国际贸易融资，比如信用证、福费廷等。

当客户购买银行的资产类产品后，需要按约定支付银行利息或者费用，作为客户向银行“借钱”的资金成本。故银行资产类产品的收益率与负债类产品的息率之间的利差，就是银行传统业务的利润手段。

3）资管类产品。这里专指银行自营的资管类产品，比如债券、基金、信托等。银行通过募集客户资金或运营客户委托的资金进行投资，在为客户赚取收益的同时，收取资管管理费和分润投资产生的超额收益进行收益。

4）中间收入类产品。中间收入类产品属于银行非资金运营业务，通过收取客户的服务费进行收益。中间收入类产品主要分为代理业务，比如第三方存管、代理资管类产品、保险产品、债券产品等；和部分重要空白凭证开立，比如汇票开立、信用证开立、保函开立等。

5）银行卡产品。银行卡产品主要分为借记卡、准贷记卡和贷记卡。

借记卡是指发卡银行向持卡人签发的，没有信用额度，持卡人先存款、后使用的银行卡。

准贷记卡是指持卡人须先按发卡银行要求交存一定金额的备用金，当备用金帐户余额不足支付时，可在发卡银行规定的信用额度内透支的信用卡，但透支的部分自透支当天起计收利息，不享受免息期。

贷记卡即信用卡，是由商业银行或信用卡公司对信用合格的消费者发行的信用证明，持卡人可在发卡组织规定的信用额度内透支资金，且透支资金享有免息期。站在客户的角度，信用卡是一款可透支的支付工具；站在银行的角度，信用卡更像是一个客户运营的平台。虽然信用卡具备免息期，但是客户在使用信用卡进行提前消费的分期业务或者取现时，就是银行通过信用卡这个平台产生收益的时候。

产品主题应按同类产品进行单独建模，建模思路如下：

4.2.3 协议主题

协议主题是银行与客户之间针对某种特定产品或服务而签立的契约关系。当银行与客户之间针对某种产品或服务的条款和条件达成协议时，一个协议就会被开立，因此协议是客户和银行往来的重要载体。由于协议的类型繁多，如存款账户、贷款账户，如手机银行签约合同、贷款合同，如存折、银承汇票，都属于银行与客户间的协议，所以协议主题也是银行主题模型中最重要和复杂的一个主题。
协议信息主要分为三类：
a）银行账户，比如存款账户、贷款账户、理财账户等 ;
b）签约信息，比如网银签约、手机银行签约、贷款合同、担保合同等 ;
c）凭证，比如银行承兑汇票、支票、存折、存单等。
协议主题应按同类协议进行单独建模，建模思路如下所示：

4.2.4 事件主题

客户享受银行金融服务的过程中，会与银行产生大量的互动行为，这类互动行为就是客户与银行间的事件。事件按是否涉及钱财分为金融事件与非金融事件。
1）金融事件主要为客户与银行间发生的涉及资金的行为，包括存款、消费、取现、转账、批量代发，水电费用代缴等；
2）非金融事件主要为客户与银行间发生的无资金涉及的行为，包括账户余额查询、签约状态变更、操作日志等。
除了客户与银行间的事件，还有银行与银行间的资金清算事件，这一类事件就是支付结算流水。
故，事件主题具体建模思路如下所示：

4.2.5 渠道主题

当客户想要跟银行接触、购买产品、使用服务，互动交流时，必须通过一个触点来进行这个触点就是平常所说的渠道。渠道除了是银行业务入口，也是银行客户的流量入口，所以经营好银行渠道是业务增长其中一个关键点。
银行渠道主要分为三类：
1）电子渠道，比如网银、手机银行、微信公众号。
2）设备渠道，比如 ATM、POS、自动终端。
3）人工渠道，比如网点、柜台、分理处。
要注意的是，渠道既然是一个对外放开的接口，肯定也会有相应的限制规则作为门槛，避免渠道被乱用、滥用。
故，渠道主题具体建模思路如下：

4.2.6 营销主题

为了促进金融产品的销售，银行的市场部门会制定营销活动推送给客户，并根据营销活动实际产生的效果，不断调整活动细节直到达到营销目标的循环往复的过程。为了实现营销活动自动化配置及推送，银行会建设营销管理系统或 CRM（客户关系管理）系统来策划与管理营销活动，所以营销主题的数据来源就是营销管理系统或 CRM 系统。
营销主题的数据主要分为三类：
1）商机发现，主要为客户调研数据、同业调研数据和潜在客户数据。
2）营销活动，主要为活动信息及规则。
3）权益体系，主要为对应营销活动的权益信息及规则。
故，营销主题具体建模思路如下：

4.2.7 银行主题

银行主题主要是描述银行内部的信息，内部信息主要分为三类：
1）内部组织架构，比如总行、分行、支行、营业厅等机构信息。除了机构信息之外，还关注组织架构的层级关系。
2）内部人员，比如员工基本信息、薪酬信息、关系人信息、奖惩记录等。
3）内部账户，这里专指银行机构内部清算、银行对他行清算、银行对商户清算的虚拟账户。
所以银行主题具体建模思路如下：

4.2.8 资产主题

无论是银行还是银行客户，系统内都存储着大量的资产数据（负债属于从别的对象“借”过来的资产，所以可以理解为“负”的资产）。
对于银行来说，资产主要分为四部分：
1）同业拆借。同业拆借是金融机构之间进行短期、临时性头寸调剂的行为。银行向同业贷出款项，称为资金拆出，属于资产；银行向同业借入款项，称为资金拆入，属于负债。
2）央行准备金。为了确保商业银行在遇到突然大量提取存款时，能有相当充足的清偿能力，央行要求商业银行的库存现金按一定比例存放在央行的存款，称为央行准备金，属于资产。
3）固定资产。这里指银行所拥有的固定物资，比如银行名下的房产、办公楼、固定设备、汽车等。
4）无形资产。比如银行的品牌、专利权、著作权、信誉等。
对于银行客户来说，资产主要分为四类部分：
1）固定资产。这里指客户所拥有的固定物资，比如个人 / 公司名下的房产、汽车、货物、地皮等。
2）本行金融资产。在本行购买的存款产品、贷款产品、理财产品、资管产品。还有贷款时的担保物与抵质押物也属于客户的资产。
3）他行金融资产。在他行购买的存款产品、贷款产品、理财产品、资管产品、在本行购买的代理第三方的金融产品。
4）无形资产。比如客户的品牌、专利权、著作权、信誉等。
通过资产数据，可以分析银行 / 银行客户的经济实力，从而对银行 / 银行客户进行营销评级或风险评级。由于银行资产数据结构与客户资产数据结构差异较大，且不同资产的数据结构同样差异较大，故资产主题需对每一类的资产进行单独建模，建模思路如下：

4.2.9 财务主题

财务主题主要分为总账数据与风险管理数据两部分：
1）总账数据。总账全称为会计总分类账薄（General Ledger），是根据总分类科目开设账户，用来登记全部经济业务，进行总分类核算，提供总括核算资料的分类账薄。故总账数据登记的是银行按会计科目记录的经济业务的数据。通过分析总账数据，即可得出银行的经营情况及业务结构。
除此之外，通过把总行数据与账务明细数据按科目进行余额核对（也称总分校验），可以检查出会计登记数据与实际业务发生数据是否一致，是银行经营数据校验的关键一环。
2）风险管理数据。存放银行的风险敞口与贷款减值准备的分账信息。

故，财务主题具体建模思路如下：

4.2.10 公共主题

业务系统的运营过程中，会产生大量的码值与参数，比如机构编码、状态编码、业务控制参数、节点配置参数等。虽然码值与参数非业务数据，却是使用业务数据的重要一环，因为该类数据是为了识别业务数据的状态与码值的中文含义。
故，建设公共主题是为了把整个数据布局补上最后一块重要的拼图，具体建模思路如下：

总结：
FDM 层对源数据的化繁为简后，整个银行数据的脉络就清晰展现在面前，为 ADM 层和数据分析提供数据基础。然而，是否建设好 FDM 层模型就可以一劳永逸呢？很明显答案是否的。原因有以下两点：
1）银行业务在不停地发生变化，而 FDM 层是按照业务脉络进行建模的，所以 FDM 层模型必须跟随着业务的变化而变化，才能符合及容纳当前实际的业务情况。
2）银行的数据量日渐增大，由于数据库技术的限制，原有模型的管理效率会越来越低。为了解决效率问题，可以通过更新数据库技术来解决，但更新技术意味着整个数仓要进行重构，成本非常大。故除非绕不开技术的瓶颈，否则通过拆解模型来解决。
拆解模型指把原来粗粒度的模型拆分成细粒度的模型，比如支付结算模型，可拆解为大额支付模型、小额支付模型、超级网银支付模型、票据清算模型等。模型的拆解，虽然会增加数据统计或分析的复杂度，但可低成本地解决效率问题，且不至于对数仓伤筋动骨。