百信银行数据治理实践

01、数据治理概览

1. 国家及监管动态分享

从国家及监管动态上来看，目前，数据治理已经不止停留在监管层面，更上升到国家的高度，这个趋势体现在最近发布了一系列相关的法律法规，包括数据安全法、个人信息技术保护法、个人信息保护法、网络安全法等。2018 年，银行业整合了近十年的历史经验，发布了《银行业金融机构数据指引》，该指引从审计、监管等方面规范了银行业的行为准则；2020 年 1 月，监管部门首次针对数据治理问题，对某农村商业银行开出罚单，表明数据治理真正纳入监管范围。继而，银保监会发布的各项制度愈发细化，陆续发布了针对数据质量、数据标准、信息管理等方面的制度。2020 年 5 月，银保监会首次针对 EAST 报送开出罚单，并发布了关于《配合做好监管标准化数据（EAST）质量稽核调查相关工作的通知》。
2. 监管要求概览

相对于互联网和传统行业而言，银行业在数据治理方面起步早，在 21世纪初已经开始布局数据治理的相关工作，目前处于较前沿的位置。2018 年发布的《银行业金融机构数据指引的通知》从治理架构和治理机制方面对银行业近十年的经验进行总结，明确提出要建立组织架构健全、职责边界清晰的数据治理架构、制定全面科学有效的管理制度、确立数据质量管理目标并建立质量控制机制、建立数据质量监控体系和数据质量考核评价体系、建立数据治理问责机制、建立数据治理自我评估机制、建立数据质量整改制度等。该指引共 7 章 55 条，第一章为总则，第二章到第六章分别从数据治理架构、数据管理、数据质量控制、数据价值实现和监督管理方面解读了银行业的数据治理机制，第七章为附则。该指引重点针对银行业金融机构如何制定数据治理体系以及数据治理应当发挥的作用。

3. 数据治理体系

首先，数据治理体系的基本原则是全覆盖，包括指标数据、数仓、业务系统、标签、特征等；
事项上，须涵盖数据安全、数据生命周期、元数据、数据标准等；
架构上，明确要求须包括组织架构、制度政策、管理流程等；

另外，该指引还对数据治理的技术支撑、数据治理体系的建设和元数据的管理也作了明确要求。

02、数据治理痛点
1. 推动难

首先，数据治理面临推动难的问题。

一是数据治理的范围大，在做数据处理的过程中涉及的范围较广，例如，银行涉及的数据主要包括业务主体基础数据（即业务系统中的数据）、指标数据（包含数仓数据、数据报表数据、指标维度数据等）、风控特征数据和营销标签数据四类；

二是治理领域较广，需要针对数据的标准、质量、数据安全、主数据、数据生命周期、数据资产等领域进行治理；

三是涉及部门多，整体而言，数据治理是一个全行级、自上而下的工作，需要管理部门、业务部门、科技部门协同配合。

2. 落地难

数据治理还面临落地难的问题。数据治理在落地的过程中，会面临诸多挑战。

其一是数据标准落地难，以业务主体基础数据，即业务系统的数据为例，新业务系统的上线及数据表的频繁变动都可能是引发该问题的原因。如果想对这些标准进行全方位管理，需要耗费巨大的人力和物力，尤其在三方系统上线时，其改造成本也非常大，包括核心、账管等核心系统的变更及修改时，也需要对数据进行拦截、将数据标准落地，其难度也非常之大。据了解，建行、工行在该方面成效较好，但其投入的人力、物力是一些小银行、小企业很难做到的。所以，大家往往会陷入疲于奔命的状态。
其二是数据质量整改难，以业务系统数据为例，由于数仓数据、数据指标相对简单很多，对数仓数据进行一次重构可能就能解决相应问题；但对业务系统的数据（即源头的数据)进行治理是非常之难的，应该以何种力度来推动数据治理的进程是一个值得思考的问题。举个例子，业务可能会对数据质量提出问题，但是科技部门和业务部门的资源是否能够支持整改，是否能明确数据质量的价值。
其三是数据安全管控难，在进行数据安全管控的过程中，经常会遇到一些强势业务部门的挑战。例如数据出航，业务为了数据合作临时需要出具部分个人信息，但事先并未得到用户的授权。此时，作为数据安全的管理部门，即数据治理组织，如何平衡业务合作与数据安全之间的关系，是否能坚守住数据安全这个原则是十分重要的。
3. 数据治理的“两张皮”

很多公司在数据治理方面经常陷入“两张皮”的情况。其一是“组织、流程、制度”皮，组织的流程制度很多，也非常全面合理，考核体系、评价体系也建立得十分完善。但到了真正落地的时候却推不动；其二是“推动、落地、工具”皮，这些制度可能不具备落地性，甚至会因为资源问题发生工具不健全的情况。这个问题在传统行业和互联网公司会更严重。

03数据治理组织架构
1. 数据治理组织架构建设

在数据治理的组织架构，主要是如何通过数据治理的组织架构来争取管理的力度，这个是数据治理的核心。整个数据治理是一个自上而下的建设方案。首先，在百信银行，数据治理的责任是落在董事会的，即由董事会牵头完成整个数据治理工作、成立了数据安全管理委员会（其他银行可能成立的是专门的数据管理部门）。高级管理层在其中要发挥决策的作用。继而，由大数据部来牵头全行的数据管理工作，包含业务部门、科技部门及一些专项工作小组，例如数据安全小组、数据标准小组、数据质量小组等。
2. 组织推动

数据治理是自上而下的工作，如果争取不到高层的资源，就算工具和体系搭建得再好，只要业务部门或者科技部门不配合，又缺乏管理力度，其落地性可能只是空谈。以数据安全、数据质量、数据标准分别举例，数据安全方面，数据出航是一个非常敏感的话题，当科技部门受到了业务部门的挑战，应该如何尽职守住底线。一般而言，科技部门是服务于业务部门的，话语权较小，基本上是很难做到坚守底线。此时，如果建立了完整的体系架构，就可以借助组织的力量来实现。在百信银行的组织中会包含风险管理部、信贷管理部等，在遇到这类问题时，这些部门就会发挥其相关职能，如果依然受到了业务部门的挑战，就需要往上汇报，发挥高层管理自上而下的管控力度。其实从整个数据安全来看，技术体系已经很成熟了，但是主要的问题是怎么去守住红线。在一些互联网公司里，即使技术部门都做的很好，但当业务部门一定要出数据的时候，技术部门是没有太多话语权的。数据质量方面，我们最近在做EAST的数据质量问题整改，如果想达到效果，在业务系统方面是必须有非常强的推动力的，因为每一个数据治理、每一个存量数据治理的整改都是极耗资源的，以还款方式这个字段为例，在实际操作的过程中，颗粒度是很粗的，其牵扯的系统较多，在数仓层面无法解决细化颗粒度的问题，只能推动业务系统去改造。如何争取到力度，获取到资源让大家去改造，让各个业务部门以及科技部门配合，还是需要依靠于组织的力量。第三方面是数据标准，将数据标准的强制管控，无论是数据仓库还是业务系统的数据标准，如果想达到前置管控的状态，也就是对增量数据的前置管控，其本质上是开发的效率和管控的折中，这个过程一定会牺牲开发效率的，这时候就要根据监管条例以及行内的发展向组织去争取力度，把工具真正的应用落实。

3. 总结

在数据治理的过程当中，从上而下推动是十分重要的，数据治理的核心点就在于如何向上获取管理力度。如果一直是从下而上推动的话，数据治理就会被套着一层枷锁，是很难落地的，除了一些管理力度比较弱的情况，例如以价值为驱动的数据治理落地，一般可能会关注指标数据治理。这也是为什么现在的公司做数据治理都是以指标数据治理为出发的。

04数据治理落地
1. 数据标准落地——分类和痛点

数据治理的落地和数据治理的落地，一方面是基础数据的数据治理（即业务系统的数据治理），在落地层面存在以下三个问题： 如何制定适合企业发展的数据标准？ 数据标准工作量检查大，如何确保落地？ 动辄就是几十万的数据标准，有没有必要按照全部的数据标准去执行？ 另一方面是指标数据的数据治理在落地层面的三个痛点： 指标是否有必要全部管控？ 是否有必要对数仓进行管理？ 如何保障指标的质量？
2. 数据标准落地——业务主题基础数据的标准制定

首先，指标数据的落地，百信银行制定了一套业务主题基础数据标准，核心思路是通过制定和达成这些标准，打通整个的关联关系。如何制定这个标准？主要依据的是国家规范以及行业的规范，例如综合EAST、反洗钱、金融数据安全分级、个人信息技术保护的相关规范去制定这个标准。
3. 数据标准落地——业务主题基础数据的资产盘点

还有一个问题是如何制定适合本行的数据标准，对百信银行来说，正在使用的例如性别、还款方式这一套标准就与监管的要求不相符。所以需要基于自然语言处理技术，遍历全行的数据标准，通过聚类等方式自动生成一些标准。在数据标准的制定过程中要综合行业和国家的规范以及行内相关标准的实际情况（例如枚举值是怎么样的)。以机器学习的方式大大地减轻了整个数据标准制定的工作量，以自动化工具为辅，人工为主，大幅提升整个的数据资产的判断能力。数据标准方面也会有一些信息相关的标签，例如安全等级、个人金融信息等级、字段的编码、字段的备注，都会落到数据标准上。接下来，我们要建立数据标准和数据表中字段的映射关系，打通整个数据资产。百信银行根据上述方式制定出数据标准，根据自然语言处理技术发现涉及这个标准项的字段，并且将标准项与该字段的关系打通，维护到元数据的管理平台，其核心是以自动化工具为主，人工为辅，人工智基本上是进行了简单的审核工作，这就完成了整个数据资产的盘点。然后就可以依据这个数据标准采取一些管理动作。且在数据标准上也打了数据质量的标签，例如某个字段为空、手机号必须是11位等，因此也包括数据质量的管理工作。然后包括安全的这些信息也都打在上面，就可以采取一些管理动作了。
4. 数据标准落地——业务主题基础数据的前置管控

在制定了数据标准后，接下来是对于业务系统的数据标准落地的工作，就要在前置的管控环节对数据标准进行检查。我们嵌入到了整个 DateBox 体系中，在上线的时候会使用一些工具进行检查。

核心的逻辑是通过 AI 相关技术，包括自然语言处理技术，发现哪些字段涉及到了数据标准，例如一个 Cust ID，我们也能识别出它是 Consumer ID，即客户号，这时我们会对这个字段的编码和类型进行校验，如果发现不符，我们会进行强制管理，要求必须按统一的标准进行更改。当然这个管理手段是向上汇报得来的，依赖于整个组织的架构去完成的。当不符合标准的时候，我们会拒绝上线，符合标准的时候才会通过元数据把相关信息记录下来，再根据元数据去校验其数据质量，是以数据标准为核心，对整个业务系统的数据进行管控。
5. 数据标准落地——指标数据的痛点

目前，指标数据的管理面临几个痛点，

第一是质量堪忧，包括在重要场合口径不一致、同一个指标内容不一致、产出的延迟和数据准确性等一系列问题，造成管理者和分析人员对其可信度产生较大质疑；

第二是开发周期比较长，不能满足业务的需求；
第三是复用率低，例如在报表中，同样指标在多张报表中重复出现，造成大量重复开发的工作；
第四个是管理难度较高，指标是分布于数据仓库、数据集市、报表平台等多个系统中的，因为数据架构的层级较多，我们很难做到统一管理，也就是很难做到一个指标在这些平台、数据仓库中是一致的。但传统 BI 无法解决这些问题。传统 BI 的核心理念是，传统 BI 工具只是对数据集市中数据表的引入，而没有对数仓进行管理，只是在报表层进行管理；有一些工具可能是对数仓层进行管理，也就是说数据集市跟数仓是一体的，报表层就不一样，这种管理是比较割裂的；公司可能很难做到数据口径一致性的保证，因为可能一个指标会出现在多个报表或者多张表中；还有一个问题，当数据分布于不同的表中。
6. 数据标准落地——指标数据的架构

我们怎么来保证数据质量？其实有一个核心理念是“弱集市化”，甚至是没有集市的概念。百信银行的底层是数仓层，查询引擎包括 Kylin、Clickhouse、Hive、MySQL、Presto、Druid 等一系列的查询引擎，我们希望做到分析平台是直接面向数仓的，具体做法是数仓会导入 Clickhouse 中，也就是按照维度建模来进行：实时表、维度表和指标维度会导入到整个平台中，即导入 Clickhouse 这个引擎中；上层是完全没有数据集市的，是通过选取指标维度自动拼装 SQL，再对数仓进行查询操作，完成从集市或从报表到集市到数仓的统计管理，也就是说指标口径是在报表层和数仓层统一发挥作用，而不是割裂的，最后达成效果是完全去集市化的状态。
指标管理，核心是把指标化成了原生指标、衍生指标和计算指标。例如，原生指标是授信用户数，而衍生指标可能是某个产品的授信用户数，计算指标可能是一个或多个指标儿通过某种计算后得来的一个指标。所有指标的定义都是在这套平台中完成的，底层的数仓其实只存原生指标；所有衍生指标、计算指标都是自动生成的。然后就是维度的管理，我们会分成标准维跟杂项维来确定管理；接下来是对于模型的管理，就是在建模型的时候根据指标维度去建立整个模型，这是业内很标准的做法，也是整个数据标准的管理。最后达到的效果是在整个分析的过程中，业务只需要关心维度和指标，完全不会有报表的概念，即业务在分析的时候，只要选出授信户数，我们会告诉业务，授信用户是可以从哪些维度去看；在他选取某一个维度后，我们可以会告诉他，这些维度可以出哪些指标；最后通过保存模板的方式进行即时查询，包括其他项目和报表的需求，也可以通过保存模板的方式去完成发布，包括在大屏上展示。

从管理的角度来说，报表、指标、数仓、集市是一系列完全达成了统一管理的状态；从用户角度来说，用户对于底层的逻辑基本上完全不用关心；从效率角度上来说，基本上不会重复的开发同一个指标，因为指标都是从底层同一个表中取出来的，如果不是从同一个表中取的，我们也会在底层对两个指标进行校验；对衍生指标和计算指标的逻辑来说，当需要衍生指标和计算指标是，直接就在平台上完成配置，大大提升了开发效率。
7. 数据质量落地

这数据质量的落地，主要的还是推动工作。在 EAST 报送的相关工作中会遇到大量的底层明细数据的质量问题，那这些数据质量问题怎么通过“责任到人”来推动问题的整改呢？首先要建立机制，要让业务部门认识数据质量的问题是业务的问题，而不是科技的问题；然后可以开整改单，划分哪些是业务的问题，哪些是科技的问题，落实责任到人，发挥全行的力量去推动。核心上来说，是借助组织的力量去推动整改的工作。

8. 数据安全落地

数据安全的落地，就是以数据标准为核心，把数据安全分级、分类，把安全等级打到数据标准上去，最后以数据标准为核心，采取管理动作，例如增量数据的运营，我们会在增量数据产生的过程中，对这个数据中的字段进行打标操作；存量数据的运营，我们会定期扫描，包括对表中字段的变化，自动按标准打标；必须根据标准对三级以上的数据加密，对四级以上的数据不应该留存的。在数据访问过程中，我们也是根据标准来控制表权限、字段权限以及敏感数据权限的；在数据共享的过程中，因为我们已经知道了数据所属的等级，以及对应等级的防空要求和红线的要求，包括对敏感数据的管控，在共享的时候是可以很容易实现的。以上就是今天的所有分享。

05问答环节
Q1：有没有一套方法论来分辨生死指标、核心指标和普通指标？
A1：其实核心指标和普通指标靠工具是很难去分辨的，例如访问量，都可以用但很难分辨。但是有一套比较好的方法论，也是用的比较多的，就是在行里直接去争取管理力度，与业务部门沟通，定义出行级指标、部门级指标以及临时性分期指标，主要在于梳理，把指标责任到人，例如逾期率这些核心指标，可能最后会落到某一个部门来负责，通过工具来把控数据质量、元数据之类的。生死指标的话，确实不太理解。
Q2：代码字段进行重新标准化后，已下发给下游的数据如何随之变化？如果影响太大的话，是否有必要进行重新标准化？
A2：数据的源头其实是业务系统，在业务系统中的数据如果重新标准化后，有工具的话是最好的，将改动的操作通知到业务系统和数据仓库；如果没有工具，就需要一些监测手段来监测到变化，下发给数据仓库；如果没有监测手段的话，就需要建立机制，首先要划分变动的是不是重要的标准，例如一些银行，普通的数据标准可能有十万个，但在业务系统真正实行管控的可能只有 2000 个，当这 2000 个变化以后，在机制上是要通知到上层的，让上层做相应的改动。如果影响太大的话，就需要一个前置的环节。当已经识别到要改的这个标准是非常重要的，那从安全等级上来说，可能是三级。如果从整个行来说，可能是类似还款方式这种影响业务非常大的数据标准，是需要提前向相关方征求意见再做改动的。
Q3：在指标计算中可能涉及到很多个表之间的 join、聚合，如果在线并发数很高的话，怎么去解决动态计算过程中高并发访问的问题？是否有比较好的实践？
A3：其实这个是二八原则，现在这种做法肯定是有性能问题的，因为它是实时的计算，我们也会模仿 Kylin，在计算会非常多的情况下，我们整个平台是支持 Cube 这种操作的。