金融数据治理场景化实践
导读 数据治理作为一项偏中后台的工作，其价值往往难以得到充分发挥和展现。本文将分享证券行业基于需求驱动的数据治理场景化实践。
主要内容分为四部分：
-
证券数据治理的痛点和建设框架
-
国信证券数据治理实践的场景化落地
-
总结与未来规划
-
问答环节
分享嘉宾｜左银康 国信证券股份有限公司 数据治理负责人
编辑整理｜刘波特
内容校对｜李瑶
出品社区｜DataFun
01证券数据治理的痛点和建设框架
1. 证券行业数据治理建设背景
证券业正式开展数据治理是从 2016 年开始的，当时证券业协会发布了《证券公司全面风险管理规范》，第一次明确提出了证券公司应当建立健全数据治理和质量控制机制。相比之下，银行业数据治理工作开展的更早，管控也更加严格。
从外部看，证券公司开展数据治理，最早是从监管要求开始，比如监管规范，以及每天都要做的反洗钱报送任务。从内部看，证券行业是典型的数据密集型行业，公司要开展经营分析、投资分析、营销服务、监管报送以及风险管理工作，这些都离不开数据。无论从内部还是外部的角度来看，证券公司开展数据治理都是势在必行的。
2. 数据治理是实现数据赋能的基石
数据治理是实现数据价值的基石，下图左侧的金字塔图，是国信证券对数据治理、数据应用以及数据管理的思考与提炼。公司大数据团队也正是按照这个框架来构建的，比如最基础的层面有数据治理团队来做数据治理方面的工作，包括数据标准、数据模型、数据安全、元数据，以及数据质量和数据架构等工作。向上一层是数据平台，对应的团队是数据平台研发和保障团队，负责公司数据交换平台、数据服务平台、数据集成平台等大数据平台的建设工作。第三层是应用研发团队，面向业务，比如经济、自营、代销、投行等，这些业务会由专门的数据应用研发团队来提供支撑。
无论是数据治理团队、数据平台团队，还是数据应用团队，目标都是要实现公司的整体成长，一方面降本增效、提升管理水平，另一方面提升客户体验，促进业务增长。
3. 证券行业数据治理常见痛点
大部分证券公司已经过了 3 年以上的数据治理建设。数据治理偏向中后台，不直接产生业务价值，有一种说法是，数据治理属于下水道工程，然而只有把下水道工作做好，上面的花园成果才能更好地体现。
数据治理仍面临着诸多痛点：
- 数据标准方面，虽然早已建设了基础数据标准、指标数据标准，包含业务属性、技术属性和管理属性等各种信息项，但标准制定后，无人跟进，业务部门也没有关注，只是看报表，并不断提出新需求，并不关心口径是否统一、是否存在重复建设等等。标准缺乏应用和维护。
- 数据质量方面，公司有 290 多套系统，面向不同部门，数据问题层出不穷，缺少抓手，同时研发和业务的配合度也不高。
- 数据模型方面，外购和自运维系统非常多，难以统一和完善公司各种数据模型的规范，模型管控困难。
- 元数据方面，虽然做了元数据采集、元数据版本管理、数据血缘分析，但采集后无人使用，也缺乏持续性的维护和更新，导致数据血缘、数据资产难以产生价值。
- 数据治理平台方面，数据管控平台、数据资产平台、数据分类分级平台虽然都已建好，但使用很少，缺乏驱动力去维护、更新，应用场景较少，难以发挥数据治理的成果价值。
4. 国信证券数据治理体系架构
针对以上痛点和证券行业发展的现状，国信证券构建了三层架构的数据治理框架。顶层成立了公司级的数据治理领导小组和数据治理工作小组，领导小组由总裁挂帅，工作小组由首席信息官 CIO 挂帅。领导小组和工作小组是虚拟化小组，数据治理小组是实体组织，负责具体工作的推进。
在数据治理顶层设计中，制度流程至关重要。数据治理很大程度上是依靠各种流程规范和细则来约束的。除了管理办法，还包括元数据、安全管理细则这类数据治理规范。
公司的数据治理工作主要包括数据标准、元数据、数据架构、数据安全、数据质量、数据模型和数据治理平台域建设七个方面。有三大平台支撑各个领域以及相应的制度和流程规范。比如安全方面，有数据安全运营平台，在元数据方面有数据管控平台，模型方面有数据模型管理平台。
02国信证券数据治理实践的场景化落地
国信证券数据治理的整体思路是从需求管理角度出发，面向业务场景、研发团队收集在数据方面的痛点和需求，再由数据治理团队主导设计流程方案，打通各个平台，比如数据标准的打通、安全和元数据的打通、标准和报表平台的打通，通过平台的打通和流程的设计，最终实现公司数据资产管理的场景化落地。
在数据模型方面，以前是为各个研发团队提供设计工具，现在要求各个开发团队在模型设计时，一方面可以直接引用标准，另一方面也可以做模型比对，比对设计的模型和生产环境的模型的一致性，从而辅助进行合理性的判断。
在数据质量方面，通过常见的监管、反洗钱等报送场景的口径和规则的梳理、质量的监控、问题的跟进和溯源，来提升报送数据的质量。
在数据标准方面，除了基础的数据标准管理，还面向资产管理业务部门，搭建了数据标准应用平台。在资产和应用方面，基于元数据做了数据资产视图和数据集成与应用的工作。
在安全方面，对数据分类分级，进行数据安全风险评估。
1. 数据标准场景化实践
数据标准场景化实践（1）--行业数据标准应用
在数据标准方面，基于行业 DG-SDOM 数据模型，搭建了八大主题的基础数据标准分类框架，建立了 2156 项基础数据标准，以及 1 万多条指标数据标准。基础数据标准分为营销、渠道、主体、账户等八大主题，这些标准目前主要应用在系统的物理模型，要求关键字段强制引用。每个公司都可能建立了上千项标准，但并不是每项标准都需要做强引用，所以我们只对客户、交易、账户、主体相关的数据标准做了强约束。
数据标准的应用流程是在模型设计和模型评审时与标准做打通，实现标准在系统模型中的落地。指标数据标准主要是和公司业务做的一个面向业务的标准应用。
数据标准场景化实践（2）--指标数据标准统筹
指标数据标准分业务线和应用场景开展。比如面向数据应用最典型的监管报送场景，面向 CISP 报送、FISP 报送、OISP 报送开展了指标数据标准的统筹。按业务线开展，比如把资管总部中资管自营的业务报送报表对应的指标标准梳理出来，包括常见的业务属性、技术属性、管理属性的名称、定义、长度、格式，并且明确了指标的归口管理人。
数据标准场景化实践（3）--数据标准的打通与赋能
对于数据标准，除了要梳理、要维护，也要用起来，否则会流于形式。通过数据标准的打通与赋能，我们希望解决用户的两类痛点。
一是同一指标不同业务人员理解不一致的问题。国信证券在全国有 100 多家分支机构和营业网点，比如某个营业网点发现今天平台上的有效开户数和自己的数据不一致，这可能是由于对"有效用户数"指标的理解不一致导致的。数据标准定义是需要用户有效资产到达某个门槛，而业务可能觉得用户注册了就是有效用户了。
另外一个痛点是，数据标准制定后，没人用，也没人维护，所以数据标准的时效性和权威性就丢失了。为了把标准用起来，第一个做法是把管控平台上的数据标准与数据应用平台打通。数据应用平台不是指具体的某个平台，而是包括 SmartBI、帆软这类报表平台，把报表平台上报表的表头、指标与管控平台打通，从而让业务用户、技术用户能够在报表平台的报表上，直接看到每个指标的口径。下图中展示了公司的数据 API 平台，用于做数据 API 的配置和调用。
数据标准场景化实践（4）--资管数据标准门户
与资产管理总部合作的数据标准门户是数据标准的第二个应用场景。在资管数据标准门户中，我们把资管总部用到的平台，比如金融产品管理平台、报表分析平台、运营管理平台、投研平台，上面的各种指标、口径梳理出来，并且把标准和元数据做映射，包括标准是落地到报表平台上哪个报表的哪个字段上，字段对应的血缘关系是怎样的。展示出来的效果是，业务点开一项标准后，会展示标准对应的字段，以及数据血缘链路，可以溯源字段的来源系统，对应的系统负责人是谁，有问题可以找谁。
2. 元数据场景化实践
元数据场景化实践（1）--元数据工作框架
下面介绍元数据，相对于数据标准而言，元数据更偏向技术。目前纳入管理的是各种结构化的技术元数据，比如业务系统、数据仓库、数据集市、资讯库等各种数据库的元数据信息。将元数据采集过来后，会做元数据的版本管理、版本变更以及数据血缘解析。
血缘关系解析分为三类。最传统的血缘关系解析只是解析数仓，因为数仓里有 ODS 层和存储过程，通过存储过程的解析来得到数据血缘关系。第二类是跨系统的，比如金融产品管理平台会把资讯数据库的基金净值的数据通过数据库直接同步来，对于这种数据库同步，会要求研发同事在新增上游数据时，根据血缘关系模板做数据血缘的录入。通过数仓数据脚本的自动解析、数据血缘的手动录入，形成全链路的数据血缘，最后可以基于数据血缘做数据评审以及数据监控的工作。
元数据不直接面向业务，所以我们也做了很多的打通工作。比如元数据与模型打通，将生产环境的元数据和设计态或者测试环境的物理模型做比对。元数据和数据标准打通，做落标比对，给出数据标准落在哪个字段上。元数据的采集也是数据质量管理的基础，只有做了元数据的采集才能做数据质量的监控和比对。
元数据场景化实践（2）--数据库跨环境一致性保障
元数据的一个个性化实践场景是一些问题在测试环境无法复现，只有在生产环境才会出现。典型的原因是生产环境和测试环境的表结构不一致。可能因为一些研发同事在解决一些紧急问题时，在测试环境做了临时的变更，导致了测试和生产的不一致。所以我们把测试环境的元数据和生产环境的元数据做了打通，通过 FTP 文件传输服务器来解决测试生产环境物理隔离的问题，再通过数据管控平台内置的版本对比功能来做差异比对。
最后输出的功能模块包括五个：
第一个是映射管理，因为管控平台不知道生产环境的服务器与测试环境的哪个服务器是对应的，所以需要做生产环境和测试环境的映射。
第二个功能模块是白名单管理，有些元数据或者模型是用于做生产和历史备份的，或者单纯用于测试，并不会生产上线，所以可以把这些表结构或者元数据加入白名单。
第三个功能模块是比对结果查询。测试同事在收到对比结果后会去催促研发同事尽快修改。
第四个功能模块是测试环境元数据查询。因为之前测试环境的元数据无人关心，所以提供了一个辅助性的查询和检索的入口。
最后一个功能模块是差异邮件。目前每周会将发现的一些系统的测试和生产环境表结构差异邮件通知给相应的研发和测试负责人。
我们还实现了元数据的融合打通，比如前文提到的标准与元数据的打通，可以映射出标准具体落地到哪张表哪个字段上，同时可以查看对应的血缘关系，目前主要应用于资管数据标准门户，通过标准看对应的源头系统。
目前在研发流程里嵌入了元数据评审的环节，对变更的表结构进行评审，评审通过后，根据确认结果以及血缘关系去通知下游，如果影响到了下游 10 张表，那 10 张表对应的负责人就会收到通知，完成影响分析。模型上线后，也会将模型与上线后的元数据做对比，如果发现某些自运维系统没有做模型评审就生产发布了，就会被认定为不合规，会发出邮件通告。
3. 数据质量场景化实践
数据质量场景化实践（1）--数据质量管理框架
接下来是数据质量方面，首先介绍数据质量管理框架。基于六西格玛 DMAIC 框架，建立了数据问题跟进流程，对数据质量进行全流程把控，持续改善数据问题。当然流程并不是形式化的，整个流程分为五个阶段，第一是定义一些规则；第二是通过这些规则发现数据问题；第三是分析阶段，联合业务、系统研发团队或者报送系统的开发团队，分析问题究竟发生在哪个系统；第四是联合源头系统，做数据质量整改方案设计，有的整改方案可能很简单，就是脏数据的清理，有的方案可能是一些接口的改造或者调用的改造；最后治理团队做整体的跟进和控制。
举一个典型的例子，比如我们作为证券公司会和支付宝、微信做一些营销合作，通过引流来引导客户的开户。之前发生过，某个渠道的服务数大于了注册数。后面通过层层监控以及分析，发现是在注册时有一个接口存在漏调用的现象，最后通过接口的改造修复了问题。这是国信内部的一个典型的数据质量问题跟进流程。
数据质量场景化实践（2）--数据质量检核
在数据质量检核方面，我们有管控平台可以做到数据质量规则的统一配置和部署，以及定期的监控和检核，最后会按月度或者季度生成专项的报告。比如客户信息专项的数据质量检核会分为不同的模板，规范性检查、数据词典检查，一致性比对等模板。
公司会购买很多外部机构的数据，但会发现有些不同来源的数据存在不一致的问题，例如基金代码一样，基金公司送给我们的净值却不一样，这就会引发很大的问题。各个研发团队把这些检核规则按模板提供给我们，我们会配置在平台上。
数据质量场景化实践（3）--监管报送数据全链路监控
数据质量的一个典型场景就是监管报送。监管报送是每个证券公司都要做的，并且监管报送涉及到的数据来源众多，我们梳理出来有五六十套系统。报送数据有客户的开户数据、交易数据，客户又分个人客户、机构客户，交易分股票、基金、债券，这些都对应不同的来源系统。常常在报送的前一天晚上才发现某个任务跑不下去了，而第二天就要报送，带来很大麻烦。所以我们选择了监管报送这样一个系统来源多、数据关联性复杂、数据量大，同时对数据质量要求又非常高的场景，实施数据质量专项提升。
数据质量场景化实践（4）--监管报送数据全链路监控
第一，针对证监会的要求梳理重要字段对应的数据来源和数据流向，形成数据血缘关系，并在平台上落地。第二，针对报送的关键节点、关键任务做数据认责。第三，在报送规范制定方面，虽然有公司级的办法，但是由于报送工作本身比较敏感，公司内部也发布了公司级的规范制度，明确了报送的跟进人、接口人。第四，在数据 ETL、源头数据的产生，以及最终的指标和报送数据这三个阶段分别做了数据质量监控，完成了全链路的梳理，实现了全链路的数据质量监控。
证监会发布的报送规范里明确了报送周期、报送字段、报送规则以及对接证监会的报送系统。同时针对报送数据的范围，我们明确了报送数据接口以及对应业务部门的负责人。通过报送专项，现在公司数据报送时，如新增或者改动报送需求，报送团队会在采集数据时，将报送数据血缘关系维护到数据管控平台上，并维护对应的系统负责人。同时如果发生元数据变更，也会有元数据变更通知。下面的 PPT 中描述的是从源系统到报送，再到管控平台的数据血缘维护的实例。这个实例是 6 层的血缘关系，最复杂的血缘关系会到 20 多层。这样可以保证报送数据链路的清晰，发现问题可以快速定位。并且上游发生变更，也可以及时通知给下游，以便下游进行及时的改造。
这里的监控不是按数据质量的一致性、规范性、完整性、及时性来设立的，而是针对报送数据从数据源到最终报送数据的不同阶段来设立监控的。比如 ETL 过程，我们会对数据同步任务做实时监控，例如任务是 8 点之前必须完成，不然会影响报送，这类任务做一些数据任务监控。基础数据监控，针对五六十个源头系统，对其字段做规范性、完整性等方面的监控。对于报送指标，根据报送规范，分别找不同业务部门或者接口人，明确业务规则，建立相应的监控任务，这里的监控任务可能有的是波动比值型的，比如业务开户上个月是 100 万，这个月突然变成了 200 万，波动比达到了 100%，也有的是数值不能为负值，比如交易金额。
数据质量检核规则都是在数据管控平台上配置的。第一个是检核模板，五六十个系统的配置模板是通用的，通过替换表、字段变量来进行便捷的配置。第二是执行计划，也就是检核周期是可配置的。第三个是可配置的检核规则，像刚才提到的系统库、表字段，这些是可替换的。第四个是检核常量，检核常量主要是针对指标类型，比如刚刚提到的波动比。
数据质量场景化实践（5）--跨库双源对比
除了监管报送的数据质量监控，还有其它一些数据质量相关的工作。我们会从外部采购一些数据，比如基金行情数据，会同时采购万德、聚源或者同花顺的数据，有时不同来源的数据会不一致，这个时候投行部门或者经济研究所就没法开展业务了。下图展示的是一个典型的跨库双源对比的示例，比如我们发现一个基金代码净值是 1.0，但另外一个数据来源的同一基金净值是 1.1，这导致没办法去做基金的后续核算，所以这类监控需要常态化地建立起来。
早期的管控平台不支持这类对比，因为涉及到跨库，并且可能是异构的数据源，数据量也可能非常大，所以进行了改造，以支撑不同数据源或者不同系统之间的数据一致性比对。
4. 数据模型场景化实践
数据模型场景化实践（1）--数据模型全流程管控
数据模型从制度和工具两个方面入手。
一方面是制度，比如开发规范和管理细则。同时把模型评审过程中的流程嵌入到公司的 DevOps，也就是整体的研发理念中，以避免冗余以及流程过于复杂。分事前、事中和事后三个阶段进行数据模型从设计到应用的管控。
事前有模型平台，同时自研类系统的开发团队可以在平台上做逻辑模型和物理模型的拖拉拽的设计，导出 DDL 脚本，用于测试和上线。对于外购系统，要求在上线前，把测试环境或者 UAT 环境的模型逆向到模型平台上，比如物理模型表要有索引、主键、中文注释、数据字典，只有通过了这些规范性检查后，才能做模型的发布。
事中，基于开发团队提交的模型评审方案，数据治理团队会在实施和上线前评审，在模型平台上发布审核报告。比如发布报告要符合刚才提到的规范性检查的规则，同时如果影响了下游，要做同步的通知。
最后是事后的监控，由于自研自运维团队较多，我们把生产环境和测试环境的模型做了打通，如果发现模型在生产环境变更了，但没有经过评审就在生产环境发布了，会进行通告。同时也会比对测试环境与生产环境模型的一致性，去发现是否有团队私下做了模型的变更和发布。
在工具方面，数据模型平台提供模型的设计、逆向建模、模型检查、模型规范等功能。外购系统不支持模型设计，但可以使用数据模型平台的逆向建模、模型检查、模型规范化这些功能。另外模型平台也有一个看板，可以把测试、生产的存量模型都纳管进来，形成企业模型库，供所有的研发团队查看和引用，并且支持模型分析、规范性检查、评审。
数据模型场景化实践（2）--数据模型设计检查
模型平台的数据模型设计、模型管理功能，也会和数据标准模块打通。比如"客户编码"这些基础标准会支持模型平台的引用，从而避免了重复设计字段。如果缺少统一的标准，比如"客户编码"，a 系统设计为 18 位，b 系统设计成 20 位，客户编码难以统一，后续数据应用也会难以开展。影响分析是和元数据侧打通，比如修改了用户账户信息表，下游很多用户都用这张表，这时模型平台会把改动的表通知给管控平台，再基于管控平台的血缘关系通知给对应的下游。
生产环境模型的比对是和公司的元数据模块打通，我们的模型平台也没必要重新采集200 多套物理模型。常用的模型功能有模型设计、DDL 脚本生成、逆向工程、词根管理、模型复用，比如客户相关的物理模型已经建立，其它系统就可直接复用，也保证了跨系统的数据模型的一致性。模型比对、模型标签、规范性检查，是在模型评审和发布模型报告时用到的功能。
5. 数据安全场景化实践
数据安全场景化实践（1）--数据安全治理
近两年，随着国家数据安全法和个保法的发布，数据安全也逐渐得到重视。公司数据安全的主要痛点，一方面是随着外部监管以及法律法规越来越多，内部的制度和要求难以满足政策要求；第二是以前没有分类分级的工具来支撑数据安全的流程；第三是对于敏感数据的申请使用，缺乏统一的管理，跨部门的数据共享场景缺乏流程管控与合规依据。
基础的数据安全治理框架融合在公司级的数据管理办法中。组织架构沿用了数据治理领导小组和数据治理工作小组的形式，但在其中丰富了数据安全责任人。制度规范方面，单独发布了公司级的管理办法、分类分级细则和数据传输对接管理细则。在技术体系方面，进行了分类分级、敏感数据识别、数据库的防泄漏、数据库的防护以及其他团队做的隐私计算的工作。在运营体系方面，我们与运维团队一起做数据安全的风险监控和应急事件响应、应急演练，这些也是行业监管要求。此外还包括个人信息保护和数安法的宣贯。同时这些工具和流程在要求上也都是贯穿数据全生命周期的。
数据安全场景化实践（2）--数据分类分级
分类分级是数据安全的基础。基于行业规范，比如人行的个人信息保护规范，以及证券行业 22 年 11 月发布的证券期货行业的数据安全分类分级指引，我们构建了数据分级分类的框架，同时将其固化到了平台上，通过平台对客户数据进行分类分级。比如根据人行的个人金融信息保护规范，个人信息分为 C1、C2、C3 三个等级，C3 比较敏感，我们会要求管控力度比较高，识别出来就可以用于后面的敏感数据申请。在平台自动识别之外，我们也会做人工校验，因为即使是个人客户数据也很复杂，比如公司个人投资者信息、机构客户信息，以及与公募基金、私募基金合作时，会有他们的法人信息、联系人信息、员工信息。手机号识别，难以分辨是个人投资者、法人，还是员工的信息，所以我们会做人工的辅助校验，并优化这些规则，通过优化后的规则，平台再次识别，最后形成数据归类定级的最终结果。
下图中展示了分类分级的整个流程。现在的分类分级规则，大致可以分为三类，一类是通过正则表达式识别的，比如手机号、证件类型、证件编码；一类是通过元数据识别的，比如字段名称、字段类型、字段长度；还有一类是通过数据字典，典型的比如客户风险等级，整个行业是通用 R1、R2、R3，一直到 R5，通过数据字典就能准确定位"风险等级"这个数据列。也可以根据数据内容来识别，即通过数据内容里的一些关键字，比如说姓氏、住址，这些反而通过内容关键字识别会比较准确。当然有的字段也可能需要结合多种规则来识别。
数据安全运营平台的大屏实现了数据分级分类的统筹和概览，展示的敏感数据占比为2%，目前识别了 305 个库，敏感数据有按系统分级的，也有按敏感性分级的，都可以通过大屏统览。
03总结与未来规划
1. 数据治理场景化实践的价值
前文中分别从数据模型、元数据、数据质量、数据标准、数据安全五个方面介绍了国信证券个性化的、探索性的实践，其带来的价值可以总结为如下四个方面：
- 首先，通过这些工作实现了数据一致性和准确性的提升，比如通过资管数据标准门户的建设，对一些业务线的数据标准实现了统一管理和展示，并且确实将数据标准用了起来，而不是流于形式。
- 第二方面是合规保障能力的加强，通过监管报送数据质量的专项工作，明确了监管报送的口径、源头、链路、责任人，实施全链路质量监控，从而提升了报送数据的合规保障水平，避免了报送风险，并能够及时发现问题、及时改进。
- 第三方面是数据资产的价值化，元数据、标准、模型，以及涉及的报表等应用平台，或者领域的资产，这些合起来就形成了公司整体的数据资产视图，这些数据资产视图可以更好地辅助研发，并且为业务决策或规划提供更准确的支持。
- 第四方面是业务效率的提升。我们会跨团队跟进数据问题，高效解决数据质量问题和口径的标准化，既可以提升业务数据准确性，又能够提高业务处理的效率，进而提升公司整体的业务运营效果。
2. 数据治理场景化实践总结
数据治理场景化实践可以总结为 3 个方面：
第一是数据能力一体化，虽然公司开展数据治理较早，但是以前模型、标准、质量、元数据这些都是独立建设的，现在通过前文介绍的各种方式打通，包括平台的打通、标准和元数据的打通、模型和元数据的打通、模型和数据质量的打通，以及流程的设计，实现了数据治理各个能力域的融合，从而更好地建设一体化的数据治理、管理以及应用能力。
第二是治理体系的标准化，这也是整个行业的一个特点。以前的数据治理是根据国外DAMA 这种国际数据管理协会发布的方法论来开展的，2018 年国内发布了DCMM，数据管理能力评估模型的国标，我们也开始对标国标，以更体系化、更成熟的方式去完善公司对内和对外的数据处理能力，因而实现了治理体系标准化的提升。
第三是数据资产服务化。数据资产服务化和数据能力一体化是相辅相成的。比如跨系统环境的比对、资管数据标准门户的建设，为业务团队和研发团队提供支撑，通过这些支撑来真正实现数据治理能力和数据资产的服务化，从管控走向服务。
3. 未来规划
我们未来会向两个方向做更深一步的探索。
第一个方向是数据治理的智能化，本次分享中没有提到大模型，一方面是因为公司自研能力并不像互联网那么充足，另一方面如果引入大模型，面临的并不是怎么去用，或者使用效果怎么样，更大的痛点是要考虑安全合规。我们不能引入公有云或者混合云这些部署的模型，所以如何利用大模型去实现数据治理和应用能力的智能化，会是我们下一步探索的方向。
第二个方向是数据治理能力的可量化。虽然我们做了数据质量、数据标准、元数据的工作，但数据质量监控的效果怎么样呢？监控之前发现问题，解决周期是 7 个工作日，现在变成了 5 个工作日，数据质量监控规则现在运行有 2000 条左右，但 2000 条是不是都有用？有没有人看，看了之后有没有效果？这些数据治理能力的量化，也会是我们下一步提升的重点。
以上就是本次分享的全部内容，谢谢大家。
04问答环节
Q1：在监管报送过程中，数据质量出现了问题，目前是自动化还是人工的手段去发现？如果是自动化，是借助什么样的工具或者流程去做。
A1：以前人工更多，现在自动化是因为我们全流程的数据质量监控，能做到提前发现问题。比如 8 点需要跑的任务还没跑完，报送和经营分析平台的数据口径不一致，但如果等到下个月再整改，监管发现是会扣分的。现在更多是通过全链路的监控，提前发现问题，通知业务和技术负责人，他们再人工去判断怎么解决。解决问题本身还是人工，不过通知和发现问题实现了自动化。之所以没提报送平台，是因为我们报送平台本身具备规则勾稽能力，比如有 3 套报送接口，涉及几十张报表，有分公司和总公司报表，分公司报表指标值求总等于总公司报表，这种勾稽本身是具备的。但另外一些源头的 ETL 过程，我们管控平台会做得更多。
Q2：数据治理可以制定一些规则和标准，但业务过程中有些字段的变动可能会比较频繁，比如枚举值变动会影响下游的数据使用。刚才提到通过数据血缘来通知相关方，并且涉及数据字典等文件的维护，这个过程是自动化的吗？时效性怎么样？
A2：这个很典型。我们血缘关系分为三大类。自动化解析只能做到数仓里的存储过程，通过脚本加工的数据链路。通过接口将数据传给报送平台或者跨库查询的血缘关系，管控平台没法直接解析，为此我们面向各个研发团队，梳理了血缘关系模板，让研发团队自己把血缘关系维护上来。之所以只能靠人工维护，一是我们公司历史存量的系统比较多，不可能短时间内迁移到数仓，再到报送平台，链路也反而更长了。通过血缘关系的批量梳理和维护，把跨系统的血缘关系也维护进来，从而做到基于全链路血缘关系的通知。通知与其讲时效性，更讲的是事前还是事后，刚才提到模型和元数据对比评审是做到事前的通知，发布模型评审报告时会通知下游，通知给报送负责人。
Q3：关于数据融合，同一个公司不同的产品是竞合关系，强势产品的数据量或者价值更大，怎样说服业务参与到元数据或者模型打通，有什么机制可以消除他们数据被泄露或者滥用的担忧。
A3：第一是数据滥用，第二个是怎么推动业务参与数据治理工作。在业务方面，数据治理一直都面临着这些痛点，业务参与度积极性不高，应用场景不够多，所以今天介绍也特意挑一些场景，比如报送，涉及到的业务部门有风险管理总部、经纪事业部。经纪事业部是公司个人客户最大头，在报送数据的过程中做了认责、口径明确，参与做了标准制定、问题跟进的工作。
敏感数据的申请。总部不同的业务部门会找数据团队要数据，比如监管机构临时检查，需要数据。很典型，比如 a 部门找数据开发团队要数据，把经纪事业部花了大价钱和微信合作拉过来的客户数据要走了，导致经纪事业部有很大意见。后面我们制定了敏感数据的统一申请和使用流程。敏感数据的归口和业务方是谁，无论哪个部门提申请，都要到这个业务部门，业务主管以及业务领导批了，对应的技术部门才可接这个需求。这样的流程，我们没有固化到的管控平台、数据安全运营平台上，而是固化到我们内部 it 需求管理平台，其中的敏感数据申请流程。
Q4：在做数据标准时，有参考数据标准的相关文档吗？做数据标准的迭代方向是什么？是做大而全还是小而精？
A4：我们是分为基础数据标准和指标数据标准模板。基础数据标准是参考了证券业协会在 2018 年发布的 DG-SDOM 证券数据模型，涉及 8 大主题，去梳理 8 大主题对应的基础数据标准。指标数据标准梳有 14000 多条，我们在监管报送专项中把对应的标准全都梳理了出来。
第二个问题是迭代。目前没有做到全部，报送项目因为有规范、有制度让业务部门明确参与进来；资产管理总部的数据标准门户，因为业务部门本身有需求，需要看指标对应的负责人是谁，如果想改或者想提需求应该找谁，他们自己也有动力去维护和更新。
以上就是本次分享的内容，谢谢大家。
