浅谈银行数据仓库的构建之路

前言

数据仓库，对从事 IT 行业的从业者来说并不是个陌生的名词，这个概念由数据仓库之父 Bill Inmon 在 1991 年出版的“Building the Data Warehouse”中定义的——面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持决策管理。从定义可以了解到，数据仓库具有以下关键特性：

• 面向主题

数据仓库归集全行数据并按特定主题梳理，方便使用者按主题编目快速查找到所需数据并使用；

• 数据集成

数据仓库归集全行数据，打破系统间数据孤岛的局面，从而为后续的决策管理与数据服务提供强大的数据支撑；

• 相对稳定

建设数据应用时，最担忧是源系统的数据模型变更导致“牵一发而动全身”。每次模型变更都伴随着数据应用的影响分析和变更开发，既对开发团队造成极大的工作负担，又影响数据应用的稳定性。数据仓库可通过分层架构“内部消化”源系统模型变更带来的影响，且无需变更数据服务接口，保证数据应用的稳定性；

• 反映历史变化

数据仓库会记录数据的历史轨迹，用于查询任意时点的数据快照从而分析特定时间范围的数据趋势，为决策管理提供数据支持。

理解了数据仓库的关键特性，相当于了解了建设数据仓库的正确方向，但是，并不代表就清楚数据仓库的建设目标和建设路径。特别对于银行机构，对数据的稳定性、准确性与时效性要求都比一般企业要高。那么，银行数据仓库的建设目标与建设路径分别是什么，接下来将分为三个章节去阐述。

银行数据仓库画像

互联网对于传统行业的冲击是全方位的，无论是百货、商场、菜市场等零售行业，还是银行、财务公司等金融行业，都对其经营模式进行“降维打击”，迫使传统行业业务进行线上化转型。尤其是银行，在互联网发展前，基本都是躺着赚钱，是大家眼中的金饭碗，结果在互联网发展后，尤其是互联网金融逐渐的壮大，都被迫喊出“银行是弱势群体”的话语，其程度可想而知。互联网经营模式对比银行传统的经营模式领先是多方面的，以下列表仅从数据的角度进行分析。

上述对比的结果，揭示了互联网经营模式领先的要点之一是数字化的业务运营，所以银行经营模式想要跟上时代的步伐，关键点是数字化转型。

在银行逐渐认识到数据价值后，也开展了自身的数字化转型之路。然而在迈向的过程中，却发现犹如进入迷宫一样，资源是大力投入了，成效却远远未达到预期想象，甚至还影响到原有业务开展。

• 业务数据仍以数据孤岛的方式存在，大量的数据仍未形成合力，难以产生巨大的价值；

• 由于数据孤岛的存在，数据应用只能局限于系统内，可发挥的空间不大；

• 数据孤岛的各自为政，造成各个系统的数据都拥有一套独立的标准，使得系统间的数据联系更加复杂与困难。且标准各异的数据难以测量数据质量，数据治理势必成为下一阶段的工作重心；

• 缺乏统一的数据管理，无法有效发挥数据的使用价值，也无法互相分享数据成果，从而导致另一个问题——烟囱式建设。

解决上述数字化转型遇到的痛点，需要打破数据孤岛、形成数据合力、建设数据质量体系，这时就需要一个数据管理核心，来支撑全行数据应用。这个数据管理核心就是数据仓库。

细化数据仓库目标，描绘出数据仓库的画像。

• 全行数据归集

将全行数据归集到数据仓库中，从而打破数据孤岛，实现数据集中管理及关联分析，产生 1+1>2 的价值；

• 数据质量体系

主要分为两个方面，其一是建设数据统一标准。标准各异的数据会对数据梳理整合造成巨大的阻碍，数据统一标准应从业务属性、技术属性及操作属性三方面进行。其二是做好元数据管理，元数据是系统建设过程产生的描述数据，包含系统设计、数据模型、数据字典、运行日志等，管理好元数据有助于系统维护及可持续发展；

• 数据价值挖掘

基于全行数据的关联与分析，挖掘数据间的联系与价值，实现智能营销与风控；

• 商业智能决策

使用可视化的数据分析工具把数据图形化、直观化呈现，帮助业务人员了解数据的变化与趋势，从而快速高效形成决策；

• 数据服务支撑

提供统一、共享的数据接口满足全行应用系统的数据服务需求；

• 数据资产管理

数据仓库既属于数据管理核心，也属于数据资产核心。对内而言，数据仓库将全行数据进行归集并整合，为全行业务应用提供数据服务；对外而言，涉及营销与风控的价值数据，比如客户画像、欺诈名单、老赖名单，对其他银行具有强大的吸引力，可通过有偿查询的方式形成创新业务。

银行数据仓库的画像清晰了，建设目标也明确了，但，该如何构建数据仓库？

浅谈数据仓库建设

宏观理解银行数据仓库的整体架构，有利于下一步理解数据仓库的建设路径。从整体架构，主体模块的功能说明与职责分工如下所示：

• 数据总线

数据仓库作为数据管理核心，必须拥有统一标准的数据输入接口与数据输出通道，才能保证数据输入输出的稳定性。但是数据输入输出会造成数据仓库的资源损耗，尤其是 IO 与网络，所以建设数据总线系统可把数据输入输出功能与数据仓库解耦，让数据仓库专注于数据的整合与计算任务。

• 数据仓库分层

数据仓库分层架构为 ODM 层、SDM 层、FDM 层及 ADM 层。对上述分层方式可能有童鞋会有这样的疑问：为什么没有共性模型层？每个数据层的定义与职责，以及共性模型层的疑问将在下文逐步介绍，有兴趣的童鞋也可以查阅作者的文章《浅谈银行的数据仓库：分层架构篇》；

• 数据服务

分为 SOA 接口与文件接口两种方式，分别提供实时与离线的数据服务。由于应用系统调用数据服务接口同样会造成数据仓库的 IO 与网络资源损耗，所以建设数据服务系统可把调用数据服务功能与数据仓库解耦，同时也避免应用系统直接访问数据仓库所造成的数据安全风险；

• 调度管理

负责数据仓库所有作业（含数据总线的 ETL 作业）的调度配置、依赖配置、日切机制及执行监控；

• 元数据管理

负责对元数据的录入与查询。对数据仓库而言，比较重要的元数据有数据字典、血缘关系、指标口径、数据映射（mapping）及参考数据（码表与系统参数）；

• 质量管理

负责两大功能——数据核检及质量评分。

数据核检分为表内核检与表间核检两种方式。表内核检主要是数据格式核检，依据数据标准对数据的长度、格式、范围、非空等维度进行检查。除了数据格式核检外，还有表内数据勾稽关系核检，保证表内统计结果的一致性。表间核检主要是检查跨系统的数据勾稽关系，比如总账科目与交易明细的总分核对。所有的核检结果均以日志的方式输出，便于数据治理团队推进数据质量提升的工作。

质量评分依赖数据核检结果，对各个源系统的数据质量进行综合评分，主要用于考核源系统的数据质量完善程度，并对开发团队实施奖惩机制，推进数据质量提升的工作。

• 安全管理

负责两大功能——数据生命周期管理及数据安全策略。

数据生命周期管理主要是设定数据的有效期及自动处理策略。当数据达到有效期时，会自动把过期数据进行文本导出、分表、清理等操作，避免数据存储过大造成的一系列系统问题。

数据安全策略主要设定数据的权限，包括查询、下载、分享、补录等权限，避免敏感数据泄露。

数据总线

• 在整体架构的分享中，已说明数据总线会作为数据仓库统一标准的数据输入与数据输出的通道；

• 数据交互建议使用文本方式进行，解除数据仓库与上下游系统端对端的强耦合，使数据交互专注在接口标准和数据结构，同时也避免上下游系统直连带来的奇奇怪怪问题；

• 无论是数据加载还是数据抽取，其执行流程基本是固定的。比如数据加载的执行流程为：

所以可以设计通用程序实现标准化的数据加载与数据抽取，既可大大减轻开发团队的工作量，也可以增强数据总线的稳定性。

数据仓库 ODM 层

• ODM 的英文全称是 Origin Data Manager，即数据仓库的贴源层，顾名思义，数据层的数据结构跟源系统的数据结构一致。数据总线把每日采集的源系统增量数据文本加载到 ODM 层中；

• ODM 层由于仅保留源系统当日增量数据，且数据结构与源系统一致，故数据加载速度是极快的，无需担心贴源层的数据加载对数据仓库性能造成影响；

• 由于 ODM 层的数据结构与源系统一致，所以排查数据质量问题时可通过 ODM 层溯源排查。当然，ODM 层仅保留当日增量数据的设计会限制溯源的范围，这是使用关系型数据库搭建数据仓库造成存储成本极高的缘故。当前使用大数据技术框架搭建数据仓库，可使用普通磁盘存储数据，使得存储成本大幅降低，所以也保留 ODM 层贴源数据的历史轨迹。从很多银行搭建历史数据查询平台来看也能说明这一点；

• 虽然 ODM 层只是加载源系统的每日增量数据，且数据结构与源系统一致，无任何复杂加工，但很多开发团队会因不重视导致底层数据加载出错，引发连锁的数据问题。解决方案可参考数据总线，关键是做好监控保证数据加载的准确性与稳定性。

数据仓库 SDM 层

• SDM 的英文全称是 Standard Data Manager，即数据仓库的标准数据层，顾名思义，该数据层主要用于数据标准落地。除了数据贯标的职责外，还要负责记录数据历史轨迹，合成历史快照；

• 在合成历史快照之前，首先对 ODM 层的增量数据按照数据标准进行清洗与贯标，保证数据标准的一致性；

• 合成历史快照需要对应源系统的供数策略，分别为：

1、源系统全量供数时，数据表只需把全表数据清空并加载即可，但这样只能查询到最新的数据快照。为了记录数据历史轨迹，且节约数据库使用空间，一般只保留特殊时点的历史数据快照，比如每月末、存款起息、信用卡账单日等。

2、源系统增量流水供数时，由于增量数据不会影响到历史数据，故只需把增量数据加载到历史数据快照形成最新数据快照即可。

3、源系统增量历史供数时，由于增量数据可能会影响到历史数据，故需要使用拉链算法既插入新增数据又保留历史数据。

4、使用拉链算法记录数据历史轨迹时，随着时间的增长数据量很可能会指数级增长，比如账户表这类变化极其频繁的源数据。当拉链数据成长到一个数据级时，拉链算法反而会成为累赘，既导致合成历史快照的时间越来越长，又导致数据查询的效率越来越慢。根据八二原则，大部分数据加工仅依赖当前数据，所以，建议把拉链表的历史数据与当前数据分表存储。由于当前数据的量级小，所以无论是使用拉链算法合成历史快照，还是查询数据，上述问题都获得解决。

数据仓库 FDM 层

• FDM 的英文全称是 Finance Data Manager，即数据仓库的金融主题层。当然，金融主题层是针对银行而言，对一般企业，称为主题模型层会更加合适。由于银行业务系统是繁多且复杂的，基于源系统数据模型加工数据应用时，必须要对其熟悉才行，而且源系统数量还不少（至少 80 个以上），要熟练掌握所有源系统数据模型并灵活运用的学习成本极高。对源系统数据模型按照一定的主题进行梳理与整合后，数据应用开发只需学习主题模型即可，大大降低开发门槛与学习成本；

• 主题划分是一门艺术。划分主题少了，数据过度整合反而使数据模型更加不好理解，且强硬整合不同业务种类的源数据会出现各种奇奇怪怪的数据问题。划分主题多了，数据模型简化达不到效果，使用时跟源系统的数据模型差异不大。所以划分主题建议找业务知识深厚、实施经验丰富的建模专家主导设计，让 FDM 层建设少踩点坑；

• FDM 层位于原始数据（ODM 层，SDM 层数据结构基本与源系统一致，所以可统称为原始数据）与应用数据之间，起到缓冲地带的作用。一旦源系统数据模型发生变更，数据仓库只需调整 SDM 层与 FDM 层的数据映射即可，而 FDM 层与 ADM 层的数据映射是基本不变的，保证了 ADM 层的稳定性。

数据仓库 ADM 层

• ADM 的英文全称为 Application Data Manager，即数据仓库的数据应用层，主要为数据服务而产生的。由于数据服务一般具备特定业务场景，所以 ADM 层以服务特定业务场景的数据集市形态存在。然而，有两类数据集市对于 ADM 层来说相对异类，一个是共性宽表，另一个是指标体系，因为这两类数据集市并非针对特定业务场景，而是针对共性业务场景；

• 共性宽表由日常数据分析使用频繁的，共性的元素，按业务主键关联并整合的明细数据。共性宽表主要为了业务人员进行自助数据分析，业务人员可根据共性宽表的维度自由组合筛选及对表内元素编辑计算逻辑从而快速设计报表；

• 指标体系由日常数据分析使用频繁的，共性的统计指标，按相同的统计维度关联并整合的汇总数据。指标体系主要为了让业务人员快速查询统计数据及自由编辑指标计算逻辑来衍生新指标，从而快速了解业务的经营情况。对比共性宽表，指标体系少了灵活性（因指标统计口径是固化在代码中，只能靠技术人员维护），但能极大提升查询效率。

• 共性宽表与指标体系可结合成为业务人员的自助统计工具，既帮助业务人员快速获取想要的数据，又能大大解放开发团队的工作量。

• 很多童鞋可能对共性宽表与指标体系抱有疑问：为什么不把这两类的数据模型做成数据仓库的共性模型层？这里分享一下作者的观点：

1、共性宽表与指标体系都是针对日常数据分析使用频繁的，共性的内容进行整合，达到数据共享的效果。实际上，数据应用的统计指标都具备特定业务场景特色，而非共性统计指标可以满足，比如有效账户数统计，共性统计指标口径是要求非注销的账户，而 A 部门的口径是要求账户非注销，且账户余额不为 0，这样实际共性统计指标的共享性会大打折扣。

2、共性宽表与指标体系无法覆盖所有的源数据，也就是说数据应用会从金融主题层与共性模型层取数加工，会导致血缘关系的絮乱。

3、一些基础的共性统计指标也可以落地到金融主题层，这样既满足数据共享，也满足清晰的血缘关系。

• 银行既是营销金融产品的机构，也是风险运营的机构，所以营销集市与风险集市对业务支撑作用极大；

• 营销集市核心是建设客户标签体系，由客户标签构成客户画像助力营销；

• 风险集市核心是建设风险评分体系及风险预警体系。风险评分体系贯穿整个信贷业务的生命周期，为快速业务决策提供数据支持。风险预警体系通过统计与展示全行机构的风险运营的数据，让领导层及时识别经营风险及采取相应措施；

• 无论是营销集市的客户画像体系还是风险集市的风险评分体系，都需要形成业务数据闭环来不断迭代与优化。

数据服务

• 数据服务应建设独立系统进行运营。理想状态下，所有的数据服务都展现在系统界面上，如超市一样，应用系统在系统界面自助注册所需的数据服务即可使用。

• 数据服务主要分文件接口与 SOA 接口。文件接口针对数据量大、固定时间间隔、允许离线更新的数据交互；SOA 接口针对数据量小、频繁且不定时、必须实时读取的数据交互。

• 由于 SOA 接口需要实时查询数据，建议单独部署关系型数据库作为 SOA 接口的数据存储，既提升查询效率，又避免应用系统直接访问数据仓库。

本章节主要阐述了数据仓库的整体架构与建设路径的关键点，从技术层面上已经基本了解数据仓库如何实施。然而，建设数据仓库，不仅是系统的建设，还是项目的运营。不懂得项目运营，系统建设必定困难重重。

数据仓库项目管理

数据仓库属于不断迭代更新系统，数据服务能力应随着迭代过程变得越来越强。但，为什么很多企业的数据仓库喜欢每隔几年就推到重建呢？本章节从项目管理的角度阐述数据仓库的建设，不过限于篇幅，仅分享项目管理的主要痛点，未来有机会会编写项目管理的实施流程与规范的文章跟大家作分享。

从作者的经验来说，数据仓库项目痛点主要有四个：

• 缺乏规范管理：项目管理的重点之一是规范化。对内而言，规范化有助于提升开发团队的工作效率，系统建设过程中技术文档的沉淀也有助于系统的可持续发展；对外而言，规范化有助于系统间的交互，并且有效地降低沟通成本。缺乏规范管理，容易导致数据仓库模型愈加混乱，最终数据仓库变成数据沼泽，被迫要推倒重做；

• 缺乏稳定团队：数据仓库对全行的数据进行归集并梳理整合成主题模型，最终加工成数据集市为各类应用系统提供数据服务，所以数据仓库是一个数据关系十分复杂的系统，哪怕已经模型简化。这样的系统依赖开发团队不断地沉淀与迭代才能挖掘与发挥更大的性能。不稳定的开发团队会导致技术沉淀出现断层，随着系统的复杂程度上升会让新成员越来越难理解数据关系的逻辑及背景；

• 缺乏高管支持：数据仓库项目建设是一个缓慢的过程且价值体现不明显，这类项目在高管的眼中就是源源不断投入资源的无底洞。假如高管并不了解数据仓库的本质与价值，很可能会慢慢把资源投入到其他容易产生价值的项目去。一旦数据仓库缺乏资源的支撑，慢慢速度就跟不上数据服务的迫切需求，最终变得边缘化；

• 缺乏有效打法：数据仓库的迭代优化主要体现在主题模型与数据集市，假如开发团队不懂或者不敢操作，老旧的数据模型会成为数据服务能力的严重阻碍。

项目管理都是有方法可依的，所以上述的痛点也是有方法去解决。

• 获取高管的支持承诺

1、在项目建设前，必须跟高管分析数据仓库建设的利与弊，明确告知建设路径是一个缓慢的过程，让高管形成心理预期与具备一定的认知。同时要宣扬同业数据仓库建设的成功案例，特别是每个里程碑的成效，让高管明确了解项目带来的好处，自然就容易获得支持了。

2、在项目建设过程中，要懂得向高管“邀功”，这样才能获得更多的信任与支持。

• 进行规范化管理

1、建立需求实施流程，管理需求生命周期，让整个需求实施过程都是有迹可循。

2、做好元数据管理，哪怕缺乏元数据管理系统，也要用文档沉淀下重要的元数据，比如架构文档、模型文档、数据映射文档、指标口径文档。

3、 维护好技术文档，宁可牺牲一定的开发时间，也必须维护好项目过程的资料。这样系统出现异常或者需要交接项目时，就能发挥重大的作用。

• 打造阶梯型开发团队

1、开发团队哪怕规模小，也要做到麻雀虽小五脏俱全，至少要具备项目经理、架构师/模型师、需求分析师、研发骨干、研发工程师、测试工程师的角色。

2、重要角色必须要有 AB 角，避免重要角色突然流失造成的项目风险与技术断层。

3、最好能主动培养人才而非一味依赖通过社招来招募人才。虽然主动培养人才花费成本比较高，而且存在流失的风险，但一旦能留下来，基本都是骨干角色而且对团队有极高的归属感，更不用说社招来的人才一样存在流失的风险呢。

• 多、好、新的打法

1、允许试错并鼓励尝试，在合适范围内对模型进行增删改，甚至推到重构，培养能建模的能力。

2、在建模能力培养过程中，所涉及的模型肯定会出现效果特别好的机会。以此机会作为标杆，复盘设计思路并形成方法论沉淀。

3、待到模型建设基本成熟后，再从宏观的角度观察模型，结合业务场景持续思考可优化地方并落地。这样就会回到“多”阶段，不断试错从而产生新的建模能力及方法论。