用湖仓一体实现基于业务本质的监管数据治理

近日，北京偶数科技有限公司亮相了由北京区块链技术应用协会（BBAA）主办的“Web 3.0发展趋势高峰论坛暨2022元宇宙、区块链、金融科技蓝皮书发布会”。大会隆重发布《中国金融科技发展报告》、《中国区块链发展报告》、《中国元宇宙发展报告》三部年度蓝皮书。其中偶数科技参与了本年度的《中国金融科技发展报告》编写。

会上，北京偶数科技有限公司产品负责人蒋秀峰就主题《用湖仓一体实现基于业务本质的监管数据治理》进行了分享，以下为发言实录：

嘉宾发言现场

非常高兴有这个机会把偶数科技在数据治理领域的一些实践和探索成果跟大家分享。

今天我分享的题目是《用湖仓一体实现基于业务本质的监管数据治理——如何做好数据资产化工作》。数据治理是我们完成数据资产转化一个非常重要的手段，所以小标题是数据资产化。

如何做好数据资产化相关工作？难道之前数据资产化（如数据治理）的工作我们做的不好吗？过去10到15年我们的金融机构其实做了大量的数据管控和数据治理相关的工作，取得了非常不错的成绩。我们可以回顾一下我们数据管理类系统经过了十几年建设之后的数据应用的现状。

几个数字跟大家分享一下：

第一个，90%

可以说接近90%的金融机构已经完成了数据仓库、大数据平台、或是现在经常提到的数据湖、湖仓一体等这类平台的建设工作。

第二个，100%

已经建设完数据平台的企业几乎100%同时做了数据管控和数据治理相关的工作。

第三个，80%

我们已经完成了这些数据管控和数据治理的前提下，我们看到约80%的数据管控系统应用情况并不乐观，他的效费比相对是比较低的。

第四个，100%

现在几乎所有的数据治理的工作呈现出“运动式”治理的特点，针对不同领域每个阶段进行数据治理工作。

第五个，60%

数据使用过程中接60%的工时和资源消耗在数据准备的过程，并且更多的是通过外包的开发资源，外包的资源实际存在上面 第1、第2和第3的特点，一个外包资源在做数据准备工作的第一年可能质量、效果、效率都不是很能满足要求，第二年各方面做的不错，第三年可能就走了，这意味着一些重复性的工作，挑战性不大。

第六个，80%

以监管为例，我们发现在监管报送的数据质量方面， 80%会出现一些错报、漏报，更多是因为数据治理没有很好的解决底层业务复杂性，稍后我会讲为什么业务复杂性会影响到整个数据质量。

数据资产化工作现状

以上是当前数据应用过程中遇到的问题和特点，由这几个特点可以得出：我们的数据治理工作过去10到15年虽然取得了非常不错的成效，但是仍然有进一步的提升空间，这个提升空间就是我们做好数据治理工作的目标，我们把这个目标再提炼一下，至少从偶数科技实践和观察角度应该包括三个部分：

第一点，要形成一套基于业务视角的统一数据模型，这套数据模型是要解决底层业务逻辑复杂性的。

第二点，这套数据模型能够切实解决数据应用过程中数据看不懂、数据找不到、数据找不全，以及数据应用过程中主要依靠个人经验的问题。

第三点，能够形成一套满足不同用户、不同应用场景的数据架构。

这是我们认为做好数据资产化工作最基础的三点。

为什么要基于业务本质进行数据治理工作？过往在数据治理过程中更多的是偏向于业务的数据质量治理，以及业务数据的可读性，主要集中在元数据缺失治理和准确性治理，这种治理带来的好处是在使用数据的时候可以用表的名称来判断表中业务数据的范围以及业务含义，比如，我们经常看到的《对公客户信息表》可以判断其包含所有对公客户的信息，这种判断大多数情况是有效的。

但是我们也发现，今年一季度银保监会发布了一个EAST处罚信息，1/5以上的金融机构都被处罚，总共罚款8000多万。处罚原因是数据的错报、漏报、瞒报，为什么会发生错报、漏报、瞒报？我们可以通过一个简单的例子分析其原因。

假如要统计全机构风险数据资产，针对委托贷款风险数据资产是否应该纳入进来，这是非常细节的问题。委托贷款可以在现金管理项下，也可以在非现金管理项下。（1）从业务口径角度，我们可能对“委托贷款风险数据资产”的定义有理解偏差，进而直接影响到监管报送的数据质量；（2）即便没有理解偏差，我们在实际进行“委托贷款风险数据资产”数据提取整合过程中，该数据分散在不同的业务系统（如信贷、国际结等系统）仍然会对数据提取造成障碍，最终造成错报和漏报。

因此，偶数科技通过实践和分析发现，错报、漏报背后的根本原因是金融机构在数据处理过程中没有基于业务本质对底层逻辑化繁为简。

除了基于业务本质的数据治理，还有一个关键词是监管数据治理。前面我们分享提到，金融行业数据管理及应用领域普遍外包的现象，少有企业有意愿、有能力投入大量的资源进行相关工作。但监管机构例外，监管机构面向的是几千家不同的金融机构，无论从业务能力、技术能力以及职能目标，都需要建立一个基于风控视角的数据模型，这个数据模型现在以EAST最为典型（审计署也有一套统计数据模型起到了同样的作用）。

实践层面来看，EAST从1.0、2.0到5.0，一直是基于业务本质的设计思路，我们是可以借鉴监管研究成果进行基于业务本质的数据治理工作的。

我们前面说到的相关数据治理成果，形成风控视角的统一数据模型，其应用场景也是丰富的、有价值的。应用场景最有价值之处在于如何构建数据湖或者湖仓一体平台。通过这张图，我们看到的是技术发展的脉络，通过技术发展这个脉络，我们总结出数据管理平台的现状和不足。

监管数据治理成果的应用（湖仓一体）

第一个阶段是早期传统OLTP数据库的出现。

从第二阶段，大规模并行处理技术MPP出现的同时，数据管理平台对应的是我们数据仓库建设的阶段，大概是在2004年、2005。有些起步较早的国际厂商（如IBM和TD）既有底层的数据库平台，也有上层的数据仓库建设方法和统一的数据模型，这套数据模型在市面上得到了金融客户的认可。现在数据湖厂商的一个特点是只关注底层技术平台，上层的平台建设方法呈现出百家争鸣的特点，并没有形成一套行业标准和被认可的数据模型，偶数也在思考和探索湖仓一体的数据模型到底应该如何建设。

实际上，基于监管数据治理后形成的面向风险管控的统一数据模型是非常重要的，能够指导我们建设湖仓一体平台。高性能的底层基础平台加上上层的整合的数据模型，能够更便捷的支撑我们的数据应用，成为数据应用的加速器。

当然数据治理不仅是刚才说到的基于业务本质做数据整合，还包括数据资产本身的盘点、传统数据管控三大项、基于数据向上做的元数据治理、业务数据治理、数据画像工作和数据资产运营。传统的数据管控或数据治理是为治而治，并没有建立管控与应用之间的抓手，抓手的问题其实要通过数据应用相关策略和手段进行。

以上是偶数科技数据治理的研究，目前偶数已经有一些实践和探索成果，并且我们研发了一套统一的监管数据模型，我们把这套统一的监管数据模型叫做偶数模式。偶数模式与进阶模式不同，在进阶模式，虽然很多银行都有统一的监管数据平台或监管报送系统，但是其底层架构仍然是数据分体的，这也是为什么金融机构即便正确理解了某一业务口径（如委托贷款风险数据资产），实操层面仍然不可避免受到技术架构掣肘，造成疏漏。

偶数科技监管数据治理研究成果

偶数不但已经探索研发的监管数据模型以外，还有一套完整的实施方法和流程，这套实施方法流程区别于传统方法的，是引入了数据资产这个概念，结合前面提到的数据资产的运营手段，偶数实施方法论完成底层业务复杂逻辑所要求的模型整合。

此外，我们还有之配套的工具类产品，包括基于数据开发和数据管理的组件Lava，向上数据应用、数据分析的组件 Kepler和LittleBoy建模平台。因此，偶数从工具层面、实施方法层面、模型层面都能更好的支撑金融机构完成基于业务本质的监管数据治理，应用到统一的报送平台。当然，这套方法也可以扩展出如刚才提到的面向审计的统一数据治理和数据模型、面向营销的统一数据治理和数据模型。

我的分享就到这里。谢谢大家！