银行数仓主题划份

银⾏数仓主题划份
描述银⾏数据仓库（下⽂简称“数仓”）分层架构⾄少包含ODM 贴源层、SDM 标准层、FDM 主题层和ADM 应⽤层。

其中FDM 层的核⼼诉求是把复杂的源数据化繁为简，按照业务逻辑划分出⾦融主题，把源数据进⾏拆分与整合到⾦融主题的模型中。

关键是，⾦融主题应该划分成什么？每个⾦融主题的模型建设思路是怎样的？⾦融主题的数据模型该怎样维护？
在解答上述问题之前，⾸先要了解国外主流的⾦融主题划分⽅案是如何的，如何从国外的主流⽅案中取经。

国外主流的⾦融主题划分⽅案
Teradata 公司的 FS-LDM ⼗⼤⾦融主题模型
Teradata 公司作为全球最⼤的专注于⼤数据分析、数据仓库和整合营销管理解决⽅案的供应商，并提出⼀种先进的 FS-LDM 模型（Financial Services Logcial Data Model），把银⾏约 80% 的业务数据囊括在该模型中。

Teradata FS-LDM 是⼀个成熟产品，在⼀个集成的模型内⽀持保险、银⾏及证券，包含⼗⼤主题：当事⼈、产品、协议、事件、资产、财务、机构、地域、营销、渠道。

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

具体划分如下图所⽰：⾦融主题层划分及建模思路
由上述的 FS-LDM 模型与 BDWM 模型，可以分析出以下共性：
1）描述银⾏客户信息的主题；
2）描述银⾏机构及员⼯信息的主题；
3）描述银⾏产品信息的主题；
4）描述银⾏与客户之间契约信息的主题；
5）描述银⾏与客户资产信息的主题；
6）描述客户使⽤银⾏服务时产⽣的⾏为信息的主题；
7）描述银⾏与客户联系信息的主题。

由于 FS-LDM 模型偏向财务及营销⽅向，所以多出描述银⾏营销活动信息及财务风险信息的主题。

⽽ BDWM 模型偏向银⾏环境及法规⽅向，所以多出描述银⾏环境信息及业务信息的主题。

结合上述两⼤⾦融模型及本地银⾏的数据环境，笔者建议以下优化点：
1）取消地域主题。

地域主题来源于国外的邮寄销售业务，该业务是国外银⾏产品重要的引流及销售⼿段之⼀。

但国内银⾏甚少开展邮寄销售业务，故地域主题重点描述的邮箱、电话、区域、地址等信息，都可以整合到客户主题内。

2）财务主题重点在总账数据。

总账是银⾏的记账核⼼，总账数据⼀般存放在银⾏的核⼼系统或总账财务系统中。

通过分析总账数据，可以分析出银⾏的经营状况、统计出银⾏的业务结构。

同时通过汇总业务系统的账务数据，还可以进⾏以银⾏科⽬为维度的总分校验，保证余额信息的准确性。

故财务主题的重点应为总账数据。

3）增加公共主题描述业务系统的码值与参数数据模型。

业务系统的逻辑处理过程中，会产⽣⼤量的码值与参数，⽐如机构编码、状态编码、业务控制参数、节点配置参数等。

这类数据对于识别数据的业务状态，及代码的中⽂含义，起到⾄关重要的作⽤，但这类数据跟已有的⾦融主题的关联性不强，故需单独增加公共主题进⾏建模管理。

最终，笔者认为 FDM 层的⾦融主题划分应划分为客户、产品、协议、事件、渠道、营销、银⾏、资产、财务、公共，具体如下图所⽰：
客户主题
银⾏的客户信息会在多个业务系统中进⾏登记，⽐如⽹上银⾏、⼿机银⾏等渠道系统，理财系统、信贷系统、核⼼系统等，且多个业务系统中保存的客户信息还⼤概率的不⼀致。

这时，在使⽤客户信息时就会出现疑惑：以哪个系统的客户信息为准？多个业务系统的个性化客户信息如何整合？所以，建设统⼀客户视图管理是银⾏数据⼯作的重点。

建设统⼀客户视图管理⼀般实践⽅式为建设 ECIF（客户信息管理）系统，由 ECIF 系统整合各个业务系统的客户信息形成统⼀视图，为全⾏提供客户信息查询服务。

假如⾏内未建设 ECIF 系统，亦应在数仓上建设统⼀客户视图的客户信息主题，替代 ECIF 系统为全⾏提供客户信息查询服务。

落地统⼀客户视图关键是与全⾏业务部门约定好客户信息整合的优先级及更新规则，因为客户信息整合很可能会影响到客户经理的绩效，从⽽影响业务部门的绩效。

确定业务规则并获得全⾏⽀持后，通过 ETL ⼿段每⽇提取业务系统的增量客户信息整合处理即可。

银⾏客户主要分为个⼈客户、对公客户及同业客户。

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

故，客户主题的建模思路如下所⽰：
产品主题
⾦融产品是银⾏经营的核⼼，也是银⾏与客户建⽴关系的纽带。

⾦融产品主要分为以下类别：
1）负债类产品。

负债类产品⼀般为存款类产品和理财类产品，主要⽤于银⾏吸纳客户的合法资⾦，再运⽤该资⾦进⾏信贷或资管类产品投资。

客户“借钱”给银⾏后，银⾏会按照约定的利率或者收益率，计提利息或收益并返回给客户，所以负债类产品的利率或收益率是银⾏向客户“借钱”的成本。

2）资产类产品。

资产类产品主要是信贷融资类产品，主要⽤于银⾏“借钱”给客户，并向客户按约定的利率或费率收取客户的利息或费⽤，从⽽产⽣利润。

信贷融资类产品⼜分为：
a）零售信贷，⽐如购房贷款、汽车贷款、教育贷款等；
b）对公信贷，⽐如经营贷款、购货贷款、⼩微企业贷款等；
c）政策信贷，⽐如涉农专项贷款、绿⾊贷款、联合平台贷款等；
d）票据融资，⽐如承兑汇票贴现、转贴现等；
e）国际贸易融资，⽐如信⽤证、福费廷等。

当客户购买银⾏的资产类产品后，需要按约定⽀付银⾏利息或者费⽤，作为客户向银⾏“借钱”的资⾦成本。

故银⾏资产类产品的收益率与负债类产品的息率之间的利差，就是银⾏传统业务的利润⼿段。

3）资管类产品。

这⾥专指银⾏⾃营的资管类产品，⽐如债券、基⾦、信托等。

银⾏通过募集客户资⾦或运营客户委托的资⾦进⾏投资，在为客户赚取收益的同时，收取资管管理费和分润投资产⽣的超额收益进⾏收益。

4）中间收⼊类产品。

中间收⼊类产品属于银⾏⾮资⾦运营业务，通过收取客户的服务费进⾏收益。

中间收⼊类产品主要分为代理业务，⽐如第三⽅存管、代理资管类产品、保险产品、债券产品等；和部分重要空⽩凭证开⽴，⽐如汇票开⽴、信⽤证开⽴、保函开⽴等。

5）银⾏卡产品。

银⾏卡产品主要分为借记卡、准贷记卡和贷记卡。

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

准贷记卡是指持卡⼈须先按发卡银⾏要求交存⼀定⾦额的备⽤⾦，当备⽤⾦帐户余额不⾜⽀付时，可在发卡银⾏规定的信⽤额度内透⽀的信⽤卡，但透⽀的部分⾃透⽀当天起计收利息，不享受免息期。

贷记卡即信⽤卡，是由商业银⾏或信⽤卡公司对信⽤合格的消费者发⾏的信⽤证明，持卡⼈可在发卡组织规定的信⽤额度内透⽀资⾦，且透⽀资⾦享有免息期。

站在客户的⾓度，信⽤卡是⼀款可透⽀的⽀付⼯具；站在银⾏的⾓度，信⽤卡更像是⼀个客户运营的平台。

虽然信⽤卡具备免息期，但是客户在使⽤信⽤卡进⾏提前消费的分期业务或者取现时，就是银⾏通过信⽤卡这个平台产⽣收益的时候。

产品主题应按同类产品进⾏单独建模，建模思路如下：
协议主题
协议主题是银⾏与客户之间针对某种特定产品或服务⽽签⽴的契约关系。

当银⾏与客户之间针对某种产品或服务的条款和条件达成协议时，⼀个协议就会被开⽴，因此协议是客户和银⾏往来的重要载体。

由于协议的类型繁多，如存款账户、贷款账户，如⼿机银⾏签约合同、贷款合同，如存折、银承汇票，都属于银⾏与客户间的协议，所以协议主题也是银⾏主题模型中最重要和复杂的⼀个主题。

协议信息主要分为三类：
a）银⾏账户，⽐如存款账户、贷款账户、理财账户等 ;
b）签约信息，⽐如⽹银签约、⼿机银⾏签约、贷款合同、担保合同等 ;
c）凭证，⽐如银⾏承兑汇票、⽀票、存折、存单等。

协议主题应按同类协议进⾏单独建模，建模思路如下所⽰：
事件主题
客户享受银⾏⾦融服务的过程中，会与银⾏产⽣⼤量的互动⾏为，这类互动⾏为就是客户与银⾏间的事件。

事件按是否涉及钱财分为⾦融事
件与⾮⾦融事件。

1）⾦融事件主要为客户与银⾏间发⽣的涉及资⾦的⾏为，包括存款、消费、取现、转账、批量代发，⽔电费⽤代缴等；
2）⾮⾦融事件主要为客户与银⾏间发⽣的⽆资⾦涉及的⾏为，包括账户余额查询、签约状态变更、操作⽇志等。

除了客户与银⾏间的事件，还有银⾏与银⾏间的资⾦清算事件，这⼀类事件就是⽀付结算流⽔。

故，事件主题具体建模思路如下所⽰：
渠道主题
当客户想要跟银⾏接触、购买产品、使⽤服务，互动交流时，必须通过⼀个触点来进⾏，这个触点就是平常所说的渠道。

渠道除了是银⾏业务⼊⼝，也是银⾏客户的流量⼊⼝，所以经营好银⾏渠道是业务增长其中⼀个关键点。

银⾏渠道主要分为三类：
1）电⼦渠道，⽐如⽹银、⼿机银⾏、微信公众号。

2）设备渠道，⽐如 ATM、POS、⾃动终端。

3）⼈⼯渠道，⽐如⽹点、柜台、分理处。

要注意的是，渠道既然是⼀个对外放开的接⼝，肯定也会有相应的限制规则作为门槛，避免渠道被乱⽤、滥⽤。

故，渠道主题具体建模思路如下：
营销主题
为了促进⾦融产品的销售，银⾏的市场部门会制定营销活动推送给客户，并根据营销活动实际产⽣的效果，不断调整活动细节直到达到营销⽬标的循环往复的过程。

为了实现营销活动⾃动化配置及推送，银⾏会建设营销管理系统或 CRM（客户关系管理）系统来策划与管理营销活动，所以营销主题的数据来源就是营销管理系统或 CRM 系统。

营销主题的数据主要分为三类：
1）商机发现，主要为客户调研数据、同业调研数据和潜在客户数据。

2）营销活动，主要为活动信息及规则。

3）权益体系，主要为对应营销活动的权益信息及规则。

故，营销主题具体建模思路如下：
银⾏主题
银⾏主题主要是描述银⾏内部的信息，内部信息主要分为三类：
1）内部组织架构，⽐如总⾏、分⾏、⽀⾏、营业厅等机构信息。

除了机构信息之外，还关注组织架构的层级关系。

2）内部⼈员，⽐如员⼯基本信息、薪酬信息、关系⼈信息、奖惩记录等。

3）内部账户，这⾥专指银⾏机构内部清算、银⾏对他⾏清算、银⾏对商户清算的虚拟账户。

所以银⾏主题具体建模思路如下：
资产主题
⽆论是银⾏还是银⾏客户，系统内都存储着⼤量的资产数据（负债属于从别的对象“借”过来的资产，所以可以理解为“负”的资产）。

对于银⾏来说，资产主要分为四部分：
1）同业拆借。

同业拆借是⾦融机构之间进⾏短期、临时性头⼨调剂的⾏为。

银⾏向同业贷出款项，称为资⾦拆出，属于资产；银⾏向同业借⼊款项，称为资⾦拆⼊，属于负债。

2）央⾏准备⾦。

为了确保商业银⾏在遇到突然⼤量提取存款时，能有相当充⾜的清偿能⼒，央⾏要求商业银⾏的库存现⾦按⼀定⽐例存放在央⾏的存款，称为央⾏准备⾦，属于资产。

3）固定资产。

这⾥指银⾏所拥有的固定物资，⽐如银⾏名下的房产、办公楼、固定设备、汽车等。

4）⽆形资产。

⽐如银⾏的品牌、专利权、著作权、信誉等。

对于银⾏客户来说，资产主要分为四类部分：
1）固定资产。

这⾥指客户所拥有的固定物资，⽐如个⼈ / 公司名下的房产、汽车、货物、地⽪等。

2）本⾏⾦融资产。

在本⾏购买的存款产品、贷款产品、理财产品、资管产品。

还有贷款时的担保物与抵质押物也属于客户的资产。

3）他⾏⾦融资产。

在他⾏购买的存款产品、贷款产品、理财产品、资管产品、在本⾏购买的代理第三⽅的⾦融产品。

4）⽆形资产。

⽐如客户的品牌、专利权、著作权、信誉等。

通过资产数据，可以分析银⾏ / 银⾏客户的经济实⼒，从⽽对银⾏ / 银⾏客户进⾏营销评级或风险评级。

由于银⾏资产数据结构与客户资产数据结构差异较⼤，且不同资产的数据结构同样差异较⼤，故资产主题需对每⼀类的资产进⾏单独建模，建模思路如下：
财务主题
财务主题主要分为总账数据与风险管理数据两部分：
1）总账数据。

总账全称为会计总分类账薄（General Ledger），是根据总分类科⽬开设账户，⽤来登记全部经济业务，进⾏总分类核算，提供总括核算资料的分类账薄。

故总账数据登记的是银⾏按会计科⽬记录的经济业务的数据。

通过分析总账数据，即可得出银⾏的经营情况及业务结构。

除此之外，通过把总⾏数据与账务明细数据按科⽬进⾏余额核对（也称总分校验），可以检查出会计登记数据与实际业务发⽣数据是否⼀致，是银⾏经营数据校验的关键⼀环。

2）风险管理数据。

存放银⾏的风险敞⼝与贷款减值准备的分账信息。

故，财务主题具体建模思路如下：
公共主题
业务系统的运营过程中，会产⽣⼤量的码值与参数，⽐如机构编码、状态编码、业务控制参数、节点配置参数等。

虽然码值与参数⾮业务数据，却是使⽤业务数据的重要⼀环，因为该类数据是为了识别业务数据的状态与码值的中⽂含义。

故，建设公共主题是为了把整个数据布局补上最后⼀块重要的拼图，具体建模思路如下：
总结
FDM 层对源数据的化繁为简后，整个银⾏数据的脉络就清晰展现在⾯前，为 ADM 层和数据分析提供数据基础。

然⽽，是否建设好 FDM 层模型就可以⼀劳永逸呢？很明显答案是否的。

原因有以下两点：
1）银⾏业务在不停地发⽣变化，⽽ FDM 层是按照业务脉络进⾏建模的，所以 FDM 层模型必须跟随着业务的变化⽽变化，才能符合及容纳当前实际的业务情况。

2）银⾏的数据量⽇渐增⼤，由于数据库技术的限制，原有模型的管理效率会越来越低。

为了解决效率问题，可以通过更新数据库技术来解决，但更新技术意味着整个数仓要进⾏重构，成本⾮常⼤。

故除⾮绕不开技术的瓶颈，否则通过拆解模型来解决。

拆解模型指把原来粗粒度的模型拆分成细粒度的模型，⽐如⽀付结算模型，可拆解为⼤额⽀付模型、⼩额⽀付模型、超级⽹银⽀付模型、票据清算模型等。

模型的拆解，虽然会增加数据统计或分析的复杂度，但可低成本地解决效率问题，且不⾄于对数仓伤筋动⾻。

FDM 层对源数据化繁为简后，已经具备数据分析的数据基础。

那是否代表业务⼈员就可以直接使⽤ FDM 层的数据进⾏数据分析呢？假如业务⼈员具备丰富的业务知识与数据库技术，是可⾏的，但实际上⼤部分的业务⼈员的知识储备并没有那么丰富，然⽽他们希望能够⾃⾏进⾏数据探索，解决⾃⾝的⼩需求。

如何才能降低数据分析的门槛，让⼤部分普通的业务⼈员也能享受这个科技红利呢？这个问题留到下⼀篇⽂章再进⾏讨论。