导读 大家好，我分享的主题是“中小银行的数据治理探索与实践”。与之前几位嘉宾从企业视角切入不同，我个人的经历有些特殊：自毕业后一直在银行体系内工作，从头部股份制银行到如今的外资银行，长期从事系统开发与数据管理。我的职业起点是电子银行与支付渠道开发，后来逐步深入至风控、核心业务及总账系统，整体走向是沿数据链路逐渐“下沉”。这种从数据生产到消费的全流程视角，使我对业务与数据的结合有了更深刻的理解，也希望能为大家带来一些不同的思考与启发。
主要介绍了以下八个模块的内容：
1. 数据治理行业的痛点
2. 高质量数据集
3. 数据治理路径
4. 数据标准定义数据质量的开始
5. 元数据作为治理的关键抓手
6. 主数据
7. 业务数据建模
8. 大数据平台技术架构
9. 大数据平台技术架构
10. 数据治理成熟度评估体系
分享嘉宾｜范彬彬 外资行 大数据研发团队负责人
编辑整理｜徐建峰
内容校对｜郭慧敏
出品社区｜DataFun
01
数据治理行业的痛点
在数据治理方面，银行业尤其面临几个跨行业共通的痛点，整体呈现“冰山特征”——既有可见的数据应用与价值实现，更依赖大量底层、长期的工程化基础工作。
结合技术与业务视角，我们总结了四个主要痛点：
1. 数据架构层面，共性整合不足
例如，ODS 层缺乏有效的技术校验与整合，模型层缺少业务校验与主题化梳理。各部门数据集市一度“野蛮生长”，导致系统间存在大量冗余与交集，却缺乏统一的数据核对与需求更新机制，严重影响数据准确性与一致性。
2. 共性需求供给不足，资产沉淀薄弱
以报表开发为例，个性化需求源源不断、开发周期长，本质上是由于共性需求提取不足，可复用的数据资产积累不够，难以支撑高效响应。
3. 数据标准难以统一，系统历史包袱重
中小银行普遍存在新老系统并存、技术栈不一的状况。系统更替受制于强监管、高可用的要求，无法像互联网企业那样“停机重构”。同时，数据治理往往见效周期长，在短期项目中易被忽视。背后深层原因还包括成本约束——这是中小银行决策中的重要考量。
4. 数据开发工具与认知存在局限
在传统银行机构中，数据开发常被狭义理解为“SQL 开发”，缺乏对数据量级、性能与时效的重视。例如 1 万条和 1 亿条数据用同一方式处理，必然导致效率低下，最终无法支撑业务应用。
针对这些问题，我们的解决思路是从两个方向入手：
改善存量，逐步优化现有架构与流程；严控增量，以更高标准规范新项目与数据需求。02
高质量数据集
高质量数据集的概念，虽然源自大数据技术标准委员会为AI训练所制定的标准，但其核心思想同样适用于传统的数据治理领域——无论是结构化、非结构化数据，还是大模型应用，高质量数据始终是共同的基础。
该标准所涵盖的核心环节，贯穿于研发全生命周期，包括：需求管理、架构设计、数据加工、测试发布、运维运营，以及资源管理（如计算存储分离）等方面。这些环节通用而关键，也是我们推进数据治理、建设大数据平台时尤为重视的维度。
03
数据治理路径
我们为数据治理梳理了一套完整的实施路径，并将其概括为三个核心环节：“收数”、“整數”和“管数”。这三个概念简洁清晰，便于内部管理和向上汇报。
收数，即数据采集，负责从各类业务系统（如支付、信贷、借记卡、核心系统等）获取数据。整数，指数据的编排与整合，形成可用的数据资产。管数，即对数据进行持续管理，确保安全、规范和质量。这一流程由多方面的需求共同推动：
一方面来自消费侧，如监管报送、营销、风控、内部运营及 BI 分析等；
另一方面来自生产侧，即各业务系统产生的数据及其标准要求。
路径中的关键治理环节包括：
数据安全（含分类分级）、数据标准、元数据与主数据管理、数据质量校验
我们以数据质量规则为抓手，对标准、模型及观测点进行持续维护，并基于良好的数据资产梳理，构建可复用的数据模型，最终通过统一服务实现数据价值对外输出。
接下来，我将针对这一路径中的各关键环节展开详细分享。
04
数据标准定义数据质量的开始
在数据治理中，数据标准是起点和基础。我们重点关注其来源与目标，并始终注重解释和打磨标准的合理性，因为这直接关系到实施成本与可行性。
1. 数据标准的四大来源
外部标准：包括国际标准、行业规范及国家标准，并及时跟踪更新；
内部制度：涵盖行内制度、部门规范、岗位操作手册（如柜员 OP、客户经理流程等），以及外资行环境下需遵循的母行制度，确保不与上层规则冲突；
源系统现状：尊重现有系统的实际情况。若无法让源系统完全适配下游标准，则采取折中策略，以数据字典整理为抓手，推动双向妥协；
参考资料：借鉴行业权威机构发布的标准，作为制定和汇报时的重要依据。
2. 数据标准的目标
可概括为六个字：同名、同义、同值。
同一名称的数据，其含义必须一致；
同一含义的数据，其取值也应相同。
达成这一目标，即可认为数据标准基本实现。尽管逻辑并不复杂，却是一项需长期坚持的工作，既要维护存量，也要持续纳入新的数据需求。
05
元数据作为治理的关键抓手
我们重点关注元数据的三个方面：结构、内容与变化。无论按基础、业务、管理或是操作元数据来分类，通过这三个维度，都足以有效还原和穿透数据的底层逻辑，支撑治理目标的实现。
1. 结构（Structural Metadata）
结构元数据用于描述数据的组织方式和技术属性，主要包括：
约束信息、关联关系、业务主键；
字段名称、数据类型、字段长度等表结构基础信息；
数据更新频率：传统银行业务数据多以 T+1 方式更新，这与银行独特的“账务日期”概念密切相关。值得注意的是，银行的账务日期并不等同于自然日期（不以午夜 12 点为界），而是按实际业务切日时间确定。
然而，随着非结构化数据和大模型应用逐渐增多，许多场景（如实时风控、客户洞察等）对数据更新频率的要求不断提高，甚至需趋向准实时或流式更新。此外，权限管理信息也属于结构元数据的重要组成部分。
2. 内容（Business Metadata）
内容元数据侧重于从业务视角理解数据，主要包括：
业务术语和行业特定命名（“黑话”）的统一定义，这类信息需通过知识库进行持续整理；
业务规则与语义定义：尤其在处理结构化与非结构化数据融合时，语义统一尤为关键；
数据质量规则：在与业务部门进行需求对接时，我们明确要求其不仅提出业务规则，也需一并提供基于业务真实性的数据质量校验规则（技术实现则由科技团队负责）。近年来，内外审及监管机构对数据质量规则的核查要求显著提高，缺乏明确定义的质量规则极易导致审计缺陷。
为有效管理以上元数据，我们引入了多种工具（包括开源及商业方案），用于可视化展示数据血缘关系、技术依赖和演化逻辑。典型应用包括 SQL 解析、ETL 流程可视化、Python/Java 代码级血缘解析等。然而，元数据管理的长期挑战在于解析工具的适应能力，以及后续维护所需投入的持续资源。
数据血缘是数据治理中的关键环节，其核心逻辑可归纳为三个方向：
（1）向前追溯（Upstream）
明确数据是由哪些源系统或加工过程产生的，即“谁创造了我”。
（2）向后追踪（Downstream）
识别数据被哪些下游流程或应用使用，即“我影响了谁”。例如，某张表 A 与其他数据结合后生成了报表 B，则需清晰记录该转化关系。
（3）历史变化（Lineage History）
完整记录所有数据资产的历史版本与变更详情。这一点在实际中尤为重要：
若字段名称发生变化，相对容易识别和调整；
但若名称未变而业务含义发生改变（如某一数据范围扩大或缩小），则会导致下游消费逻辑必须进行重大调整，甚至需要重新关联或过滤数据。
因此我们建立严格的变更评审机制，要求每一次结构或语义的变更都必须经过审核，杜绝随意修改，确保变更仅发生于业务场景扩展或原有设计缺陷修正等必要情况。
为实现血缘管理，我们结合了开源工具与商业解决方案，构建起覆盖 SQL、ETL、程序代码（如 Python/Java）的可视化血缘分析能力。
06
主数据
此外，主数据（Master Data）作为另一项核心基础，指的是跨系统、跨部门重复使用的高价值共享数据，例如银行业的产品、客户、账户等。这类数据具有高度共享性和稳定性，不同于互联网行业中以订单为核心的模式，银行更倾向于以“产品-客户-账户-交易流水”为主题划分数据域。主数据的统一管理是打破系统壁垒、保障数据一致性的重要前提。
主数据之所以在银行数据治理中占据核心地位，关键在于其具备以下四个“超越”特性：
1. 超越业务边界
主数据能够在不同业务条线中保持标识与含义的一致。例如，同一客户无论是在理财、信贷或存款业务中，其客户 ID 必须唯一，所用账户也须为同一实体，从而确保跨业务数据的一致性。
2. 超越部门壁垒
银行前、中、后台各部门（如交易操作、风险审批、资金结算及监管报送）均可能使用同一主数据。必须打破部门间的数据隔阂，在跨职能协同中始终保持核心数据的唯一性与识别有效性。
3. 超越系统边界
通常，资产规模在三千亿至五千亿之间的银行，其系统数量约在 100 个左右（不含强业务属性系统）。由于监管要求全面且严格（如岗位设置需满足经办、复核等最小权限单元），银行需建设并维护众多系统，如官网、手机银行等。这些系统无论实际使用频率如何，均成为主数据的来源与消费方，须在多系统间实现数据的统一识别与共享。
4. 超越技术栈差异
主数据管理需克服不同系统间技术架构与版本的差异，实现在异构环境中的一致性整合与使用。
主数据管理的根本目标是实现核心业务对象（如客户、产品、账户）在多元、复杂的银行环境中的唯一识别和全局一致，从而为业务流程协同和风险控制提供坚实基础。
主数据管理需有效应对银行系统在技术栈层面的复杂性，主要体现在：
银行普遍存在新老系统并存、多供应商技术异构的局面。采购与招投标通常引入多家主流供应商，导致行内系统在数据架构、技术版本上存在差异。在落地实施阶段（如 POC 验证或系统集成），往往面临两种选择：要么统一技术栈，要么在数据层实现整合。在这种情况下，主数据的管理就显得尤为关键。
我们将那些可复用、与核心资产紧密相关的基础数据定义为主数据，并为其明确唯一的业务管理单位，落实“人到字段级”的管理责任。例如在客户主数据中，我们进一步区分为：
个人客户与企业客户；
个人客户中再细分Ⅰ类户、Ⅱ 类户；
信用卡分为贷记账户与借记账户等。
通过细分主数据类别并明确管理归属，我们实现了“每一类数据有主可寻”，有效避免了数据问题无论大小都堆积到科技部门的情况。业务单位承担起主数据的管理职责，科技部门则聚焦于技术实现与支持，二者协同保障数据的准确性与一致性。
07
业务数据建模
在数据建模方面，我们的实践可总结为两大重点：严格的评审管控与持续的逻辑分层与共性提取，以此推动数据资产的有序建设和高效复用。
1. 逻辑分层与共性提取
数据建模分为技术域与业务域两层，分别由科技与业务部门主导：
技术域（科技主导）：基于行内现有业务流程与结果进行建模，核心是厘清“我们有什么”，负责整合多源异构数据、处理历史明细及指标加工，确保数据可溯与技术实现；业务域（业务主导）：聚焦“我要用什么”，面向监管审计、风险管理、经营分析、精准营销等需求开展个性化建模，并将共性需求下沉至技术域进行一次性开发，实现多场景复用。通过这种分工，我们在尊重业务灵活性的同时，持续提炼共性数据需求，避免重复开发，提升数据服务的效率与一致性。在建模方法上，我们融合了多种行业方法论（如 ERwin、Kimball），因中小银行自由度相对较高，可在标准框架下灵活调整。
2. 严格评审与流程管控
为保障数据模型质量与长期可维护性，我们建立了闭环评审与发布流程：
模型设计：新增需求触发设计流程，首先判断是否涉及新标准——若涉及，则启动标准制定流程；协同评审：组织跨角色评审，重点关注模型合理性、标准符合度及下游影响；开发与 DataOps：依托开发运维一体化机制，实现高效部署与测试；发布管理：明确版本、公告时间与影响范围，及时向下游集市（如经营集市、回单处理、管理驾驶舱等）同步变更信息。这一流程确保了模型发布前充分评估、发布后平稳落地。只要设计合理、评审严谨、沟通到位，后续开发与测试便可按计划推进，大幅降低投产风险。
数据建模不仅是技术活动，更是管理工程。通过分层协作与流程管控，我们实现了数据资产的自主可控与持续优化，为业务创新与合规经营奠定了坚实基础。
08
大数据平台技术架构
我们的大数据平台采用 Greenplum + Hadoop 混搭架构，这一设计主要基于两方面考虑：成本约束与系统建设的历史路径。由于银行信息系统往往存在遗留架构与分阶段建设的特点，我们必须在现有基础上进行优化与整合，而非完全推倒重来。
该平台作为整体数据治理体系的底层支撑，核心分为三层：
数据采集与交换：实现多源数据的接入与集成；
数据存储与计算：基于 Greenplum 和 Hadoop 构建混合存储与计算能力；
统一数据服务总线：通过权限控制、流量管理与服务网关，对外提供安全、可控的数据服务。
在数据应用层，我们逐步引入多种分析工具（如图计算、机器学习等），目前多数仍处于试点探索阶段。
架构设计上的关键考量：
为满足监管数据对安全与时效的严格要求，我们将监管类数据独立部署于 Greenplum 中，以物理隔离保障安全，其 T+1 的时效性完全满足监管需求；
非监管类数据（如营销、风险、内部运营等）部署于 Hadoop 集群，在成本与性能间取得平衡，同时这类数据对时效性的要求正在不断提高；
此外，我们还扩展了对象存储与文件存储系统，将其作为数据仓库与大数据平台的外部扩展存储，类似于“外接移动硬盘”，用于存放非结构化数据与历史归档数据。
该架构虽源于历史与成本限制，但通过清晰的分层设计与应用隔离，我们实现了数据管理的可控、安全与可扩展，有效支撑了行内多类数据应用的需求。
09
大数据平台技术架构
在数据治理中，我们借鉴了自动化领域的“能观性”概念，强调对数据流程的全面观测与度量。具体到数据质量管控，我们重点关注数据观测点的设计，并致力于在覆盖度与系统性能间取得平衡：
观测点布局的策略性：观测点既不宜过多（避免因频繁执行 SELECT 操作拖累系统性能），也不宜过少（需保障规则覆盖度）。关键在于确定哪些节点必须埋点、何时埋点，以及如何规避跨系统边界带来的管理复杂度。
构建数仓层质量监测体系：为提升效率并降低人工消耗，我们自主研发了一套基于数仓模型的数据质量监测方法。该方法以校验前置为原则，在归集后的模型层集中实施质量规则检查，并生成每日质量报告。目前该系统已沉淀并运行约 1,200 余条规则。
以监管规则为核心抓手：银行及金融机构的质量规则很大程度上源于监管要求（如 IST、征信、“一表通”等报送规范）。这些外部规则为我们提供了权威、明确的依据，成为我们推进内部数据质量建设的重要基础。
通过将监管规则与内部技术实践相结合，我们建立起一套兼顾权威性、效率性和可落地在数据质量规则的分类上，我们将其明确划分为技术合法性校验与业务合理性校验两大类。这一划分既有助于对规则进行分类分级管理，也便于在科技部门与业务部门之间厘清权责边界。以下是两类规则的具体内容：
1. 技术合法性校验
该类规则由科技部门主导制定与实施，侧重于数据的技术合规性与结构正确性，主要包括：
空值检测：对指定字段进行非空校验，尤其对高风险字段加强监控；
极值检查：检测数值型字段的极大/极小值，如金额不可为负、小数位数符合约定等；
重复数据识别：基于联合主键或全字段对比，发现完全一致的重复记录，并将其归入异常队列进行后续分析。重复数据极易导致下游加工出现数据膨胀与逻辑错误；
值域校验：检查码值合法性，排除非法或未定义的枚举值。
2. 业务合理性校验
该类规则需业务部门深度参与，侧重于数据在业务场景下的逻辑正确性与一致性，主要包括：
总分核对：检查汇总数据与明细数据的一致性；
跨期连续性：确保时间序列数据在周期切换时的连贯与完整；
表间交叉验证：在不同数据实体间进行逻辑关联性校验，确保业务逻辑的完整性。
通过这一分类框架，我们不仅实现了数据质量规则的清晰化管理，也促进了科技与业务部门在数据治理中的协同合作。
10
数据治理成熟度评估体系
在数据质量监控中，我们还建立了异动预警机制，其设计参考了监管要求（如金融数据日报中的异动分析），但在阈值设置上更为严格：监管通常要求 30% 的波动预警，而行内设定为 10%。
例如，某科目日常余额稳定在 1,000 万左右，若某日突然变为 8,000 万或降为 0，则触发预警阈值。此时系统会自动发出告警，由相关业务部门介入进行人工核查与异常处理，实现问题的早期发现与快速响应。
最后，为形成数据治理的完整闭环，我们引入了成熟度评估体系。目前采用的是国家标准《数据管理能力成熟度评估模型》（GB/T 36073-2018），通过该框架对行内数据管理能力进行持续评估与迭代优化，确保治理工作系统化、可持续地推进。
数据治理的闭环与持续优化离不开系统化的成熟度评估和科学的资源管理机制。我们以国家标准《数据管理能力成熟度模型》（GB/T 36073-2018）为核心框架，围绕数据战略、治理体系、架构设计、应用服务、安全管理、质量控制和全生命周期管理等能力域，定期（如按季度）开展行内评估：
1. 成熟度评估的核心目标
跟踪外部标准与行业最佳实践的更新动态，确保行内治理方向与行业发展同步；
对照先进标准检视内部执行情况，识别是否存在方向偏差、执行松懈或资源投入不足的环节。数据治理本质上是一项需长期坚持、持续优化的工作，必须通过机制化评估避免中途松懈或资源错配。
2. 资源管理的现实挑战
数据治理的成效与资源投入强度密切相关，且银行业数据工作具有显著的周期性特征。例如：
月初因监管报送、月结、报表生成等高强度需求，资源高度紧张，开发人力需求可达平时的两倍；至月中及月末，资源需求逐步回落，人力投入可相应缩减。
这种波动要求我们建立精细化的资源调度机制，实现成本可控前提下的高效运作。
数据治理不仅依赖于方法论和标准体系，更是一项需要持续资源投入与动态管理能力的系统工程。通过成熟度评估，我们将战略制定、执行落实与资源保障串联成闭环，推动数据治理能力持续提升。
以上就是本次分享的内容，谢谢大家。
