证券行业开展数据治理的背景可以从外部和内部两方面来看。从外部监管来看，一方面在制度规范上，比如《证券基金经营机构信息技术管理办法》里面有单独章节，规定了证券基金经营机构应当建立和健全有效的数据治理体系架构，切实保障数据安全、数据质量等工作。从内部来看，整个证券基金经营机构每天、每周、每个季度以及每年都面临着各种各样的监管报送场景，对数据质量是非常重视的。从以上两方面综合来看，整个证券行业以及证券基金的经营机构必须做数据质量的提升和数据安全的管控，最终实现数据价值创造。

1.3 证券行业数据治理目标

证券行业数据治理的三个具体目标：

监管合规

作为一个强监管行业，我们必须密切关注国际、国家和行业的各种法律法规和监管要求，从而制定和完善公司内部的制度和流程，并确保它们的执行和落地，从而做到合法合规。

隐私保护和数据安全

近两三年，无论从国家层面还是行业层面都特别重视隐私保护和数据安全。国家层面有数安法和个保法；我们行业层面，去年11月证监会发布了数据安全管理规范指引，今年证券协会发布了网络和信息安全三年提升计划。

可信任的数据

可信任的数据，意味着要开展数据模型，建设数据标准，持续提升数据质量，并实现数据质量和数据标准的落地，从而提供准确、及时、可信任的、一致性的数据。

1.4 证券行业数据治理痛点

证券行业开展数据治理，也是为了解决以下典型痛点。

第一个痛点，数据问题不断发生。业务部门经常投诉，比如经营分析、经营化指标不一致或者不准确，导致业务对数据缺乏信任，从而影响内部的绩效考核、客户体验还有营销活动。同时我们公司大概有 300 多套系统，各个系统和团队的数据问题不断发生，他们分别独立处理、解决各种数据问题，难以进行统一跟进和量化评估。

第二个痛点是业务部门的参与度不高。我们公司 2023 年上半年以前数据需求和问题是没有进行版本化管理和分类管理的。在组织架构上，虽然各个业务部门都有数据治理专员，但数据治理专员没有归口管理起来本部门的一些数据标准和问题。总结起来，就是参与度不高，管理方式比较零散，缺乏持续性的线上化的机制和场景。

第三个痛点是数据模型难以规范和统一。证券行业的机构有很多外采系统，就是外购系统和比较老旧的历史存量系统，特别是一些交易系统和账户系统。这些系统不能轻易动，即使制定了数据标准也难以落地。同时由于这些自运维系统和外购系统比较多，因此它们遵循的开发规范和模型也不统一。

第四个痛点，数据资产平台难以应用。我们公司虽然建设了数据管控平台、数据资产门户这些典型的数据资产平台，但是业务用户却缺少使用这些平台的动力。业务用户日常主要依赖经营分析报表，管理驾驶舱这些报表平台，数据资产平台的应用场景比较少，难以发挥数据治理的价值。无论是数据模型、数据标准、数据质量，还是数据分类分级，都难以发挥其应有的价值。

二、证券数据治理服务化实践

2.1 国信证券数据治理建设框架

2018 年来以来，国信证券开展了数据治理建设的探索和实践。

我们公司整体的数据治理框架：在顶层设计上成立了数据治理领导小组和工作小组。在战略和目标上，21 年基于领导小组以及数据治理公司的整体管理办法已经发布了公司十四五数据治理的战略和目标。在制度和流程上，我们有公司级的数据管理办法，同时我们发布了相应的数据标准细则、数据质量细则，数据安全管理办法和数据全生命周期管理细则以及元数据管理细则等各类细则和流程。

细化到各个领域，我们主要是从六个领域去开展数据治理工作的：数据标准、元数据、数据架构是开展比较早的；数据安全、数据质量和数据模型是从 2021 年以来持续丰富和建设的。在平台支撑方面，我们有三个比较重要的数据治理平台。第一个是数据安全运营平台，开展数据的分级、数据安全风险监测和数据安全风险评估等数据安全方面的工作。第二个是数据管控平台，它集成了元数据、数据质量、数据标准、数据资产门户以及数据架构等数据治理集成性领域工作。第三个是数据模型平台，它会和我们公司内部的一些 Devops、JIRA 等流程和工具打通，进行数据模型在上线前的线上化设计和管理。

2.2 国信证券数据治理建设思路

我们从服务化和需求管理的角度出发，面向资产管理总部、风险管理总部等业务部门，以及研发团队、测试团队等不同的开发团队，收集他们在实际工作中遇到的数据问题和数据治理的痛点，剖析他们的需求，结合数据治理的成果和工具做方案设计，打通数据治理、数据应用和数据安全等各类平台，实现数据资产管理的服务化和场景化的落地。

在模型方面，有模型的开发、模型评审、模型的比对；在数据质量方面，会结合监管报送和全链路这些典型的业务痛点和重要的场景，做数据质量的提升；在数据标准方面，会进行标准口径梳理、标准管理和数据标准面向业务的应用；在数据架构和元数据方面，我们会有元数据的资产视图，并与数据集成平台 ETL 任务等应用平台打通；在数据安全方面，我们会从分类分级、安全评估、动态脱敏和静态脱敏等场景出发做提升和建设。

2.3 数据模型管理

下面介绍具体每个领域的思路或者实践。在模型管理上，我们主要是从制度和工具两方面来强化数据模型能力建设。首先我们发布数据模型制度和模型开发的规范和细则，一开始的规范可能比较笼统。然后我们和 DBA 探讨一些研发痛点及曾出现过的数据问题。比如，源头系统数据库的物理模型 MySQL，当时它使用的字符集和下游系统 SQL Server 字符集不一致，导致上线前测试环境没有发现问题，上线后才发现下游数据同步出现了问题。

此类问题，我们从数据模型规范和检查入手，做字符集的检查，规定所有系统在上线时必须使用统一的字符集 UTF-8。我们把这些细则和规范在内部的模型工具里落地，保障工具可以支持各个研发团队以及数据治理团队在做数据库物理模型研发以及物理模型评审的时候，可以进行字符集检查、索引的检查、中文备注和数据标准的检查，把这些具体的检查落地。这是制度规范和规则的检查方面。

2.4 数据模型平台建设

具体的模型工具的功能框架，主要分模型设计、模型管理和模型分析几大功能。模型工具与公司管控平台的数据标准和元数据打通，例如生产环境采集的元数据，和我们在模型平台上设计的物理模型比对，检查生产库是否与设计评审发布的设计态物理模型一致。因为会有很多自研系统操作不规范，未经设计评审就上线了。通过和生产环境的比对，可以发现到底哪些团队不按规范做了上线，这些不合规操作需要进行公告或者警示。同时模型设计节点会和公司 Devops 研发流程打通，通过 JIRA 评审节点，如果没有通过评审，模型是不可以做发布的。

数据模型的三大块主要功能：

在模型设计方面，可以支持概念模型、逻辑模型、物理模型的设计，此外，还支持数据标准的引用，能够进行脚本的生成和逆向工程。逆向工程这个功能主要是针对采购类系统。证券公司，特别是中小型证券公司，自研能力没那么强，会购买各类采购系统，比如集中交易、柜台、万得、聚源以及监管报送类等。

在模型管理方面，主要是做模型的合并、词根库的管理和模型的版本管理。版本管理就是开发团队自己做版本和权限的管理。

在模型分析方面，我们会和生产环境的模型做比对，提供模型的标签、规范性检查规则的管理。以上就是我们公司数据模型在制度和平台两方面的建设。

2.5 数据模型服务化实践

比较典型的服务化实践，就是以前各个系统使用模型工具做模型设计，但没有统一的规范或者词根。和标准库打通之后，研发团队就可以直接引用标准库。比如，基于账户系统设计的账户编码的数据标准，下游数据仓库或者数据报表平台想再建设账户编码，就不用再设计了，可以直接引用这个标准，包括字段长度、字段类型、字段内容等信息，这样确保了上下游系统的账户编码字段的一致性。

通过这样的方式，确保上下游的数据质量和数据应用的一致性。研发团队通过数据模型工具修改表的时候，由于工具和管控平台的元数据模块打通，通过影响分析功能，可以看到这个表对数据仓库或者报送系统的影响，研发人员可以及时同步通知下游和下游负责人。

2.6 数据质量框架

为了支撑数据质量管理，我们基于管控平台，建设了数据质量管理平台。它包括：

（1）问题管理：包括数据问题的新建和分发、数据问题的分类定级、问题业务域、问题紧急程度，还有数据工单的跟进。

（2）工单管理：数据质量问题工单提出之后，要有问题的转判、问题的分析、问题的整改、方案的制定以及问题的上线，最后还有工单的关闭。工单跟进之后要有数据质量知识库的管理。

（3）数据质量监控。按照数据问题的全流程分为了5大类监控：基础数据监控、指标数据监控、表结构数据监控、跨系统数据监控和数据任务监控。

基于这些问题管理、工单管理和监控管理的工作，我们要做数据质量的量化，包括数据质量看板、数据质量评分和数据质量报告。通过这些量化工作来向业务和领导层展示，哪些系统经常出问题，出问题频率是多少？哪些系统的监控比较丰富，告警率是多少？监控的有效性是怎样的？我们的数据质量管理平台，要基于交易柜台、账户系统、报送系统等数据源去做数据质量的监控和提升。

2.7 数据质量保障机制

数据质量的保障机制包括机制和工具两方面。机制方面，事前我们要做流程的设计和分工，业务团队和研发团队要定义自己的数据质量的口径和以及数据质量的监控规则。事中，我们数据治理团队和研发团队，要做问题的收集、数据监控任务和告警任务的调度，要做数据问题的分类定级，并跟进数据问题。事后就是通过问题的月报、问题看板以及问题持续性监控和丰富等量化手段，来对事后的数据质量做持续性的保障和提升。

2.8 数据质量管理平台

在平台方面，数据质量管理平台有以下功能：

在数据层或者存储层，汇集账户数据、产品数据、投研数据、报送数据等数据源。

在配置层和计算层，支持质检规则的配置、数据质量任务和质量规则告警人员的配置。根据质检配置和调度计划，每周/每月/每隔一小时，质检任务或者监控任务会自动检测数据质量问题。在问题管理上，我们会细分各种问题标签，比如报送数据、外部数据和客户数、客户主数据、产品主数据等问题标签，在季度或年度汇报，或者总结的时候看是哪些业务域和数据域经常出现问题。在告警渠道方面，我们支持一些邮件告警、短信告警等，目前主要是这两类告警渠道。在问题定级方面，分为高中低三大类。

在应用层，我们面向研发团队和数据治理团队或者业务团队，支持问题的录入分析、整改方案的制定、整改进度的跟踪，还有问题关闭。通过数据质量看板，量化数据问题的统计、监控任务的统计，提供监控告警、监控有效性的统计和问题分布概览。

2.9 数据质量监控实践

在数据问题监控方面，通过数据问题监控量化和提前发现数据问题，是避免数据问题重复发生的最主要手段，我们非常重视这项工作并大力推进。

我们希望数据质量监控覆盖我们公司的 300 多个系统，包括 OLAP 和 OLTP 类系统，涵盖从源头系统到目标系统，最后到数据上线和管理驾驶舱。

数据质量监控分为5大类，第一大类，主要针对客户数据、交易数据、产品数据这些基础数据，他们对应 OLTP 类业务系统，我们从完整性、一致性、准确性、真实性做技术数据的监控。

第二大类是指标数据,主要针对数据仓库以及数据应用和报表平台，针对经营分析数据和统计报送数据等这些加工和指标数据，做同比波动、环比波动、最大值非负等监控。特别是在每月或每季报送前，这些监控要发送给业务，只有监控没出问题，他们才可以进行报送。

第三大类是跨系统数据监控，我们会监控公司的各种外购数据。无论是证券、银行还是各种金融公司，我们都会购买各种外部数据，包括万得的数据、恒生聚源的数据，还有同花顺或者企微数据等，然后针对这种跨系统的数据，建立外部数据一致性的监控。比如，我们购买了恒生聚源的基金净值数据和万得的基金净值数据，那么我们就会比对万得和聚源的基金代码、基金净值是否一致。如果发现不一致，那肯定是很重要的问题，需要及时关注处理。

第四类是数据任务监控。各种报送任务、ETL 任务，以及从业务系统到 ODS、数据仓库和数据湖的任务都有很重要的时点要求。我们从数据及时性的角度出发，针对数据任务做了一个及时性监控。

第五类是表结构监控。从元数据的应用角度出发，我们会监控客户数据、交易数据、产品数据等关键的表结构变动。

2.10 数据标准框架

在数据标准方面，我们基于证券期货行业的行业模型 DG-SDOM，构建了 8 大主题的数据标准框架。在指标数据标准方面，我们构建了几大类，包括经纪业务的、证金业务的、风险管理的、监管报送的，特别是监管报送专项，目前监管报送的指标数据标准有 11800 多项、800 多条。

2.11 数据标准服务化实践

指标数据标准，一般更关注的是建立数据标准，并面向业务或者开发去提供应用和服务。我们把数据管控平台管理的数据标准和数据服务平台以及数据应用平台（比如各种BI 平台、帆软报表或 smartBI、经营分析平台）进行打通，比如，在每一个报表的表头展示出相关的指标数据标准。这样全国各地的分支机构的业务同事看到这些报表时，把鼠标浮上去，就可以看到对应的指标口径以及归属的系统和业务团队。

在数据标准实践上，我们针对资产管理总部集成了资管数据报表门户的页面。当时资产管理总部的业务用户提出这个痛点，也是因为他们资管的源头系统众多，包括报表平台、运营平台、一体化投研平台、金融产品管理平台。他们自己都说不清到底有多少数据指标、口径是否重复或是否有冲突。

当时我们针对平台的报表指标专门做了梳理，集成到管控平台，做了资管数据标准门户，然后面向资管的业务用户和资管的开发团队。这样他们可以比较清晰地看到资管业务条线下到底有多少指标，每一个指标点开之后，它对应的源头系统是金融产品管理平台还是报表分析平台？它对应的开发负责人是谁？它的血缘链路是怎么样的？这也是我们数据标准方面面向业务的典型场景之一。

2.12 元数据框架

元数据比较偏技术化，可能服务化场景没有那么多。首先元数据整体的框架就是我们公司的元数据系统，即基于管控平台，能够采集各类业务系统数据、数据仓库、数据集市、资讯信息等各类元数据信息。同时元数据系统本身会做一些采集版本管理、元数据解析还有预发布库管理。基于这些元数据管理我们会做元数据的影响分析、冷热度分析、成本治理（还处于刚开展的阶段）、跨环境比对，以及数据地图或者数据编织应用。

同时我们的元数据会和数据标准和数据质量打通，比如刚才提到的报送系统的 11000 多条指标，它落地到报送系统是哪些表、哪些字段，这些都是有链路和映射关系的。

2.13 元数据服务化实践

上述提到的测试环境元数据的比对，就是当时我们面向测试团队做数据治理需求研讨的时候，提到的一个典型的应用案例。测试团队之前经常抱怨他们在测试环境根本没发现问题，结果到了生产才发现问题，一部分原因就是生产环境的表结构和测试环境表结构不一致，那在测试环境肯定发现不了问题。

为了解决这一问题，我们做了定期的比对。我们目前是每周都会比对，比如账户系统的生产环境 500 张表，而测试环境 490 张表，它的表结构是否一致。此外生产环境可能有一些临时表或者历史表用来备份，测试环境没有也无所谓，这种会纳入白名单管理。通过跨环境的比对，我们会告诉测试负责人和研发团队，这个系统这周又发现了多少表结构不一致的地方，字段或者字段长度是否不一致？测试后发现不了，到了生产才会报错，这种情况就会让测试团队主动督促研发团队在测试环境做一个整改和一致性的比对。这个是从测试团队需求的角度出发做的元数据的应用。

在元数据服务化建设方面，元数据与数据标准做了映射。比如我们监管报送数据有 11000 多条指标，在这里我们可以看到大概的截图示例，就是我们平台会有报送指标和数据库元数据的映射关系。同时在这里点击映射链路的时候，业务同事和研发同事就可以比较方便地看到每一个指标对应的数据链路。如果发现问题也可以及时地跟进和分析。

2.14 数据安全框架

在数据安全方面，从 2021 年起，特别是在国家的数安法和个保法发布之后，我们重新搭建构建了公司整体的数据安全治理框架。整体的思路是以个人客户信息为中心进行客户敏感数据的数据确权、敏感数据的风险评估和数据整体的分类分级。

数据安全治理体系整体分为三大块。首先是数据安全治理的组织架构，我们沿用数据治理的领导小组和工作小组的结构，同时会和内部的数据信息安全团队做一个配合，来构建公司整体的数据安全治理体系。其次在技术体系方面，我们公司内部会有数据库审计、动态脱敏、静态脱敏、隐私计算、分类分级等各种数据安全的工具，支撑整个数据安全的工作。在数据安全的运营体系方面，我们有运营团队和一线运维来跟进数据资产的识别、数据安全风险监测、应急事件的响应以及公司内部整体的数据安全培训等各类工作。

2.15 数据安全服务化实践

数据安全整体的服务化实践成果其实是基于分类分级、数据安全风险监测、动态脱敏、静态脱敏等技术搭建了数据安全运营平台。然后通过大屏的形式展现我们公司数据安全的敏感数据和数据安全风险的成果。

2.16 数据治理服务化的价值

数据治理服务化的价值可以总结为四点。

第一是实现数据一致性和准确性的提升。比如刚才提到的通过标准门户的建设来实现对数据标准的统一管理和展示，面向资产管理总部和分支机构，提供数据口径的统一和标准的应用。

第二就是合规保障能力的提升。比如在监管报送方面我们做了专项的梳理，明确了 1 万多条指标口径、梳理了链路、确定责任人和源头，提升了监管报送工作的合规保障。

第三个就是数据资产的价值化。我们基于数据分类分级、元数据、标准、模型等成果，形成数据资产视图，从而促进内部更好地理解和使用数据资产，也为公司的内部决策和数据应用提供了准确和全面的支持。

第四个就是业务效率的提升。主要指通过有效的资产管理，资产管理总部可以更快地查找和使用数据。在提数据需求的时候，可以更好地评估和细化数据需求，从而提升运营效果和竞争力。

2.17 数据治理总结与展望

最后是总结和展望。国信证券目前具备了比较全面的数据治理的各项基础能力，也进入了常态化管理。计划下一步会走向 DataOps，这也是一个行业的趋势。我们将通过数据质量和治理能力标准化等方面开展更为深入的实践。目前，基于我们现有的各项能力，开始对数据研发流程做敏捷化和一体化的管理。

第二个是数据资产量化。就是通过数据治理各项基础能力来对数据资产和数据质量做量化评估，然后推动冗余数据或者僵尸数据的成本治理工作。

第三个是数据治理能力标准化。从行业或者监管趋势来看，近两年监管层也越来越重视金融科技的标准化工作。去年以来，监管部门发布了《十四五金融科技标准化工作指南》，并发起了多项企业标准的研究课题。因此，我们计划将数据治理在各方面的实践固化为企业标准，并且大力参与和推动团体标准、行业标准的标准建设工作。

三、Q&A

Q1：数据模型有业务部门的参与吗？如何在不同业务条线保证一致性？数据标准和模型设计如何相结合的？

A1：首先数据模型是否有业务部门参与的问题，现在我们数据模型的工具确实只有研发团队在用，而业务团队会参与逻辑模型设计评审。这个和企业架构管理的思路有点类似：架构管理包括企业架构、系统架构、数据架构，但一般业务很少去参与或者主导企业架构。所以我们从落地的角度出发，只是在逻辑模型设计的时候让业务参与评审。而模型数据和数据标准的打通，类似监管报送沉淀的 1 万多条指标数据标准，我们通过模型工具在构建物理模型的时候可以直接引用这些字段。比如，账户系统相关的客户信息、账户编码之类的基础数据标准肯定是要全公司一致的，在模型平台也是可以直接引用的。研发团队、数据治理团队在设计和评审时都是比较便利的。

Q2：数据治理的最佳切入点是什么？是制度和流程强制，还是企业文化的宣贯，资源上有没有相应的倾斜？自下向上推动数据治理很难，其他部门会认为数据治理就是在找茬，有没有比较好的建议？

A2：数据治理最佳切入点有几个角度。首先是数据治理六大领域的工作，确实有一些领域的工作前期不太好推动，比如数据标准和数据架构，有些领域反而相对好推动一点，比如数据质量和数据安全。首先数据安全当时是拉上了合规管理总部和风险管理总部，这些内控部门一起去推动的，所以相对而言力度就比较大，因为内控部门的权力一般比较大，而且像合规部对其他业务部门是有考核权的。另一方面就是监管报送方面，比如刚才提到我们能梳理出 11000 多条指标，而且业务也很配合，就是因为监管报送每一个报表和指标都是明确了责任人的，已经细化到人，而且在公司内部OA 是有发文的，是办公室牵头发文，都不是我们 IT 条线。当时要求每个部门要设置填报人、复核人，要明确口径、明确规则，所以这一方面是比较强有力的。当然这两方面都有一个共同点，就是 IT 条线都会拉上合规管理总部或办公室或风险管理总部，拉上其他部门一起来推动，这样就会更容易推动。

Q3：数据治理平台是外包开发的还是自研的？是什么样的外包资质的公司能做这样的事？数据治理平台、分析平台和业务系统之间的数据流动方向是怎么样的？数据资产管理平台的元数据会流到业务系统吗？数据资产管理平台与业务分析平台之间的数据流动是怎么样的？

A3：第一个是否自研的问题：我们刚才提到的数据管控平台是外购的，在 2020 年做了二期之后，我们把源码买了过来。从 2021 年之后我们属于自研平台，而数据模型平台是完全外购的。

第二个是数据流动的问题：元数据信息来自业务系统、数据仓库、数据报表平台、数据应用系统、监管报送系统。数据从业务系统和报表系统流转到数据资产管理平台，然后数据分析平台会从数据资产管理平台集成标准口径和质量监控规则，不过只集成了一部分，类似分类分级、元数据表结构等，用不到的数据就没有集成。

有一个问题是数据资产管理平台的元数据是否会回流到业务系统？元数据这一块相当于是我们完全统管的，没有回流到业务系统，无论是刚才提到的生产环境和测试环境元数据比对还是告警，还是元数据影响分析的变更，也只是同步到了我们内部的模型平台，对于业务系统而言是没有回流过去或者影响的。所以我们业务研发团队如果想看影响分析，想看元数据比对的结果都是在我们资产管理平台本身去看的。

参考文章：

金融行业大数据治理的方向与实践

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/繁依Fanyi0/article/detail/246370?site