平安银行数据研发治理一体化平台实践

金融大数据体系错综复杂，随着业务数据爆炸式增长以及公众对数据关注度的不断提高，体系化的数据治理变得至关重要。然而，传统治理方法存在落地难、效果差、难衡量等问题。

在 ArchSummit 全球架构师峰会（深圳站）上，平安银行数据资产管理及研发中心 / 数据及 AI 平台团队负责人廖晓格，深入探讨了金融数据体系的复杂性以及如何有效地进行智能化数据治理。他强调了构建金融级数据研发治理一体化平台的重要性，并分享了如何将数据治理体系落地到研发流程中，实现数据价值最大化的方法。本文为演讲整理，期待对你有所启发。

在 11 月 19-20 日举办的FCon全球金融科技大会上，廖晓格还将带来《金融级数据研发 DataOps 落地实践》的主题分享。敬请关注！

以下是 ArchSummit 深圳站演讲全文（经 InfoQ 进行不改变原意的编辑整理）：

今天分享的主题涵盖了金融行业在数据治理过程中遇到的困难与挑战、开发治理一体化平台体系的构建，以及如何进行数据虚拟化的未来展望。随着数据爆炸式增长，各行各业都面临着庞大而复杂的数据、存储成本的剧增、计算复杂度的增加、数据安全隐患等问题，这些挑战归结起来即安全、提效、降本；安全视角，如何保证数据安全分析和应用，以及敏感数据如何不泄露；提效层面，如何提升数据研发效率、如何打破不同部门、组织间的数据孤岛，提升数据融合价值应用；降本层面，如何精准量化数据成本与价值、如何量化分析数据 ROI 价值；

除此之外，对金融行业来说，大量分析师在工作期间随时会对海量数据进行分析，如何保证大数据平台 7x24 小时稳定运行至关重要；在数据测试方面，传统的方法是将生产数据脱敏后迁移到测试环境，但这一过程复杂高又难以形成闭环，并且可能有数据安全隐患；在数据时效方面，未来实时数仓的需求会日益增长；若希望数据被有效管理，成为有用的资产，形成数据生态，那数据治理就成为重中之重。

数据治理目标

数据治理的目标是希望能在确保数据安全及成本价值最大化的前提下，将数据治理与数据研发过程融合，实现治理线上化、治理标准化、治理智能化；将治理方法论与平台工具相结合，实现治理线上化；将数据治理涉及的多个平台、不同角色、流程、标准等融合并集成统一的数据研发治理能力工具，实现治理标准流程；更进一步，我们追求数据治理的智能化，通过内置规则和策略，实现自动识别安全隐患、敏感数据等，提升数据治理效果。而实现“三化”的同时，也不能忘记降低数据成本。

数据治理的最终目标是实现核心数据资产的自动沉淀，并为内外部提供稳定、高效的数据服务，实现最大化数据价值。

金融机构数据治理体系，即一套标准、一个平台、一套治理、一套资产；

基层是数据治理标准，数据治理团队需要制定相应的治理方案与治理规划。除此之外，数据研发的流程和规范的标准化也是数据治理的重中之重。

数据研发治理一体化平台融合研发全流程，在数据需求阶段，我们通常会进行影响分析和数据架构评审，以确保数据治理标准得以贯彻落实。在数据研发阶段，我们重点关注源数据治理、数据血缘和数据质量治理，以确保数据的质量和一致性。此外，指标研发阶段，我们还定义了指标规范、度量规范和维度属性规范，以提供更简单的数据使用路径，满足业务需求。当进入数据应用阶段时，我们采用统一的报表服务和 OneService 服务，为外部提供统一的数据服务，以提高数据服务效率。

在治理过程中，除了配置规则外，我们的重点是对开发流程进行贯标落地，确保数据质量的可靠性以及数据价值的评估。同时，我们还需要持续跟踪和监控规范的执行情况，关注数据应用的成本和效益，维护数据的健康度，通过评估每个数据表和指标的价值和成本，及时清除低价值或高成本的数据，从而提高数据治理的效率和准确性。

开发治理一体化解决方案

在数据治理方面，数据开发治理一体化平台重视规范与研发过程的融合，为确保统一性和高效性，所有数据研发规范都已纳入我们的数据治理体系中进行集成设计。在制定规范时，我们始终坚持先深入设计，后向外提供服务，以数据服务和数据指标驱动我们的数据研发流程。目前我们的数据开发流程覆盖数据同步集成、批流数据加工、指标研发等，我们致力于将数据治理规范真实落地于每一步的数据研发中，确保数据研发与数据治理的紧密结合。此外，通过全流程的数据研发，我们成功塑造了银行的核心数据资产，其中包括业务元数据、数据模型、数据表、指标和 API 等。

具体看一下数据治理融入研发流程在每个阶段中的重点设计。

在设计阶段，对数据标准、数据架构、数据治理、元数据等进行规范化定义；对模型事实表、维度表进行设计 / 注册；在研发阶段，在数据集成时，我们将自动标识敏感字段，并在清洗阶段对其进行加密或逻辑脱敏处理；在数据研发时，需要构建完整的元数据资产，包括基础元数据和业务元数据。在发布阶段会对数据进行全流程自动测试，确保数据质量。而运营阶段的核心则是评估数据的成本与价值，最大化数据的 ROI。

数据模型设计阶段，元数据是基础能力核心，遵循数仓分层、元数据命名规范、数据标准落标等，通过开发治理工具执行。

元数据从产生到应用会经过采集层、逻辑层；其中采集区的作用是能够面向自动构建出技术元数据和业务元数据，为逻辑元数据构建提供基础元数据。业务元数据源于业务逻辑和业务管理诉求，而技术元数据则覆盖库 / 表 / 字段、数据血缘等技术细节。

为方便场景端使用，我们建立了元数据逻辑层，供资产运营人员进行数据目录挂载、资产分类、资产生命周期管理等工作。其中，资产管理环节还包括资产打标、属性标注和业务流程标识，从而形成完整的业务数据地图，并向外部提供元数据服务，确保数据安全、数据权限，并实现元数据考核应用。

在元数据的全生命周期过程中，我们基于行内统一数据标准规范，对元数据进行强制检查，确保元数据可用、可管、可控，包括①数据分层强制约束，包括 ODS 层、DWD 层和 ADS 层，确保数仓的严格管理，防止跨层访问；②我们为业务归宿设定标识；③命名规范自动化。我们设置了特定的词根，使得当用户命名字段时，相关的英文字段能被自动识别；④码值落标线上化。

我们也非常重视血缘治理能力，整个平台 99% 的表级字段级血缘都是通过平台自动生成。在金融数仓体系里，数据加工链路复杂，上下游作业影响，重复链路等都会影响数据研发和运维效率；我们目前在 2 个过程中会进行血缘治理，其一是数据研发过程中的血缘链路治理，主要包括血缘层级依赖检查和分层依赖检查，血缘层级依赖检查包括目标作业与 DW 层作业的血缘层级深度，对于层级链路太深（15 层），禁止上线，调整脚本优化链路关系；分层依赖检查依据 ODS-DWD-ADS 分层规范，禁止进行跨层依赖；

其二是运营过程治理，包括运营时效治理和运营成本治理，运营时效根据高保作业的时效和运行时间要求，依据血缘关系自动线上化链路监测，并分析延迟影响并及时启动异常 noc；运营成本治理通过血缘链路关系计算数据热度，并针对冷数据自动实现下线管理，减少集群存储和计算成本。

另外血缘治理也帮助我们对所有作业的脚本进行自动解析并生成依赖关系，支持数据作业自动调度。

其中值得关注的是，①依赖关系长度：对于那些依赖关系特别长的情况，我们会检查其时效性。如发现依赖过长，我们会对其进行优化。②使用频次：通过血缘分析，我们可以观察到各表的使用情况。对于那些三个月未被访问或访问频次较低的表，我们会进行成本治理。③依赖并发：在调度过程中，我们控制并发并定义调度流程，确保数据开发者不必担心表与表之间的依赖关系。

数据质量治理涵盖事前校验、事中核验、事后复盘的闭环治理；

事前，我们在数据开发流程中支持自动 / 人工为表和字段设置一定监控规则，如唯一键的监测以及字段内容的监控。事中，依据母表跑批执行成果，自动执行监控检查，如发现监控异常直接进行预警，针对数据异常严重可能会造成下游数据应用场景事故的，会直接阻断整个数据处理流程，对于这些异常阻断，平台会自动告警并跟踪。事后，由质量监控平台追踪质量问题并复盘。

开发测试一体化也是数据治理的重要工具。在数据测试验证场景下，很多公司可能会将数据复制到测试环境，但这样就断裂了数据链路，无法形成闭环，数据安全也无法保证。因此，我们希望所有的数据研发都能在生产环境下完成，包括研发、测试、发布等全流程数据研发过程，直接解决测试难点及问题，并且基于平台资源隔离能力以及安全保障，实现数据全线上化开发，提升数据敏捷度的同时又能保证数据质量。研发、验证、测试过程全部基于生产环境数据安全保护伞进行数据使用，确保数据安全的同时兼顾数据的高保测试。

最后，在数据安全方面，对于全行数据安全保护也从事前、事中、事后三个视角进行安全管理。

事前，我们会协同安全 / 风险专员设定一系列安全规范；事中，我们执行多种安全技术措施，如数据加密、数据脱敏、敏感客群保护、数据外发规则以及实施智能阻断措施，确保整体数据受到充分保护；事后，我们设定规则引擎，对平台的所有访问记录进行自动审查。通过这一机制，一旦发现存在安全隐患的访问记录，平台会自动触发报警。例如，若某用户频繁查询某个特定客户，且该客户信息属于敏感字段或敏感客群，我们会立即阻断此类查询。

此外，我们的平台提供统一的 SQL 引擎进行数据查询。在此引擎中，我们执行血缘分析、权限判断等操作。最重要的是，当引擎识别到敏感数据时，会先进行脱敏处理，然后再为用户提供结果。

接下来详细介绍一下敏感数据发现的过程；在数据处理流程中，当业务数据被采集至大数据平台后，通过规则算法和人工标注，能够准确地识别到贴源层中的所有敏感字段，接着在 MID 层进行标准化自动敏感打标，并依赖血缘关系将这些敏感标记向下游传递。应用端查询数据时，根据敏感标识对访问的敏感字段及敏感脱敏类型进行加密、脱敏处理。

举个例子，采集表 A 中存在高度敏感的字段，身份证号、姓名和邮箱，我们会采取物理加密措施；而在数据查询、使用时，我们首先通过内部规则库自动识别并标记敏感字段。随后，我们通过血缘关系将这些标识传递至下游的依赖表中，比如识别到数据表 A 中存在敏感字段，根据下游依赖关系，我们识别到数据表 B 中同样存在敏感字段，并自动完成安全打标和打标继承；在此基础上，我们会进一步通过人工复核确认这些标识是否与业务标准相符。复核结束后，相关数据表便可以上线并对外提供服务。

随着大数据平台的发展，表字段的加密方式可能会发生变化。但是，对于整个平台来说，不可以频繁改变字段的加密方式。如果一个字段在多个表中广泛使用，并且其加密方式更改，这会带来非常大影响。

为解决这一问题，我们通过对元数据标注的方式来进行加密。例如，如果一个手机号最初采用 A 方式加密，但后续这种加密方式改为 B，我们会对每个表的分区进行标注，并在最终的查询结果中，统一所有不同加密方式的数据到最新的加密格式，再对外提供统一的查询能力，这种技术方案将对业务造成的影响降到最低，也不需要对历史数据进行跑批更新，这种能力可以为平台节省巨大的大数据“翻数”成本。

以 MapReduce 为例讲解下基于元数据的加密方案，编译阶段会通过 MapReduceCompiler 访问元数据信息，并将其存储在特定文件中。在运行阶段，每个操作单位会读取这些信息，并根据最新的加密算法加密数据。在 PostExecutionHook 阶段，任何写入操作都会被再次写回到原表，并在元数据上打上标签，标示其元数据的加密方式。

举个例子，当表字段采用特定的加密算法如 IDX 时，我们会在作业执行期间生成相应的元数据信息。这些信息被序列化并存储。在执行作业时，系统会读取并根据最新的加密算法对所有分区进行统一加密，再进行 SQL 统计。执行结果完成后，系统会更新分区的元数据标签，确保数据的完整性和安全性。

金融机构在数据分析和加工过程中，即便数据已经统一脱敏处理，但数据的运营权限仍然由各个业务方独立管理和权限分配。由于不同业务部门间的理解差异或者经营竞争意识等，比如银行内部的信用卡、消金及汽融业务，其借贷产品十分相似，导致很多数据难以自由流通。为了解决这一问题，我们在大数据平台上构建了沙箱安全屋环境。该环境能自动对数据进行抽样，用户可以无需申请权限即可访问所有业务方的数据。为了保证数据安全，我们确保沙箱中的数据只能进入，不能输出，并且将数据分析与应用之间是完全隔离的，这样就能实现数据流通共享，并且加速数据分析的效率。

当用户提交 SQL 执行时，系统首先识别是否为沙箱环境。如果是，该请求无需经过权限控制，即用户无需申请数据权限就可以进行数据分析。当然为确保数据安全，我们会对数据执行统一脱敏采样，并改写提交的 SQL。执行后的结果仅能保存在沙箱环境中。若数据想要迁回到生产环境，系统会自动识别并进行拦截，确保数据只能进入沙箱，不能导出；在跑批流程中，我们首先从生产库读取数据，接着在沙箱中对数据进行脱敏抽样，然后将其写入沙箱环境。

数据成本价值管理目前处于探索阶段，现阶段我们是从数据价值和数据成本两方面进行评估管理，逆向推动成本治理；数据价值方面，我们依据表在各个业务流程和标签、模型、报表中的使用情况，如标签调用量及业务场景使用量，来进行系统价值回流和人工标注，基于不同维度进行加权计算，最终输出每个表的价值分。数据成本方面，我们针对大数据底层的每张表都单独计算存储成本和数据计算量化成本，从而确定每张表的数据成本。

最后，让我们看一下数据资产沉淀的过程；在数据研发过程中，依赖元数据治理规范工具检测通过的数据，接口推送至数据资产平台生产数据资产；这些资产再由数据开发人员进行进一步加工和认定；数据资产平台对认定后的资产进行自动分类盘点，资产编目；最终，我们为外部提供数据目录导航、数据资产搜索等，满足数据资产应用需求。

未来展望

尽管进行了大量的数据研发工作，但公司在数据价值最大化的问题上仍存在困难，对于整个大数据平台，数据应用和治理仍是存在很多的疑问点，例如，两张表的内容相似度达到九十几个百分点，我们是否应该合并它们？数据开发工程师和数据架构师负责定义数仓分层，包括 ODS 层、DWD 层、DWS 层等，但这些定义是否真正考虑了用户的需求？对于金融公司的数据标准，有些由咨询公司为其制定了标准，但这些标准是否适用于所有业务场景仍然是未知的。

未来，我们计划借助逻辑数仓的概念，实现数据价值最大化。改变原先从下往上构建数仓的模式，构建以“客户为中心”自动化构建数仓，我们希望通过用户的实际使用行为，自动化生成数据仓库的物化表。我们期望数据开发工程师只需定义业务逻辑，而所有存储的控制权由平台持有。我们希望通过构建逻辑数据仓库来优化大数据平台的 DAG。我们的目标是通过这种方法大幅度解决数据治理的不敏捷问题。

目前，我们的数据仓库主要是物化落地的实体物理表，我们打算将所有物理表转化为虚拟表。通过分析用户访问的日志，我们能够对这些虚拟表进行 SQL 解析和算子转换。基于这些分析，我们会将使用频度较高的虚拟表物化，并将其与原始的虚拟表关联起来，这样对于用户来说体验没有变化，但是实际技术存储方案是最优化的解决。这种策略实质上是依据用户的实际使用模式来构建数据仓库的流程，这意味着，数据开发工程师只需专注于业务指标的处理，平台会自动决定是否将表持久化、是否合并表以及如何持久化。尽管用户端无感，但从平台的角度，表的具体存储位置和数量都是动态的、不确定的；且这种策略确保了用户查询和批处理的时效性，实现真正的自主数据治理。

举例来说，当用户进行 API 查询、标签、指标、特征和报表等行为时，我们首先通过逻辑数据仓库为外部提供服务，同时记录这些逻辑数据仓库的访问频次和标记规则等。试想一下只要在数据仓库中修改一个字段或合并两个相似的表，所需的工作量都是巨大的。但对于逻辑数据仓库来说，其表格可以无限扩展，并且是非常轻量级的，你可以随心所欲地修改它。尽管在初期我们可能会损失一些计算资源，但在后期，我们会通过物化能力，确保时效性并更高效地为外部提供服务。

当符合物化规则后，我们会分析整体的 SQL 依赖关系，并进一步细化这些 SQL 关系，诸如将 SQL 拆分为更小的算子、输出内容、where 条件以及它所依赖的表等。我们将优化这些大型或选定表集的 DAG，并将其物化为物理表。然后，在物理层与逻辑层之间进行映射。对于用户来说，他们访问的表仍然保持不变，但存储的控制权由我们的平台持有。

嘉宾介绍：

廖晓格，平安银行数据资产管理及研发中心 / 数据及 AI 平台团队负责人，大数据及 AI 领域资深专家，十多年大数据及 AI 平台研发经验，曾在 PPTV、eBay、携程、华为负责大数据平台研发及优化工作，开源领域爱好者、熟悉 Hadoop 生态、Kubernetes 开源生态和架构设计、精通大数据相关组件技术，承担大数据基础平台、数据中台及 AI 平台建设等重要项目。

活动推荐：

11 月 19-20 日，首届 FCon 全球金融科技大会将落地上海。届时，廖晓格老师也会到场与大家交流并分享【金融级数据研发 DataOps 落地实践】，诚挚的邀请您参加本次盛会，期待您可以从他们的交流中获得启迪。

目前为 8 折优惠购票最后 3 天，咨询购票请联系：17310043226（微信同手机号）。