贝壳金服在构建金融级别大数据平台的实践

PingCAP 2020-01-15

3354

作者介绍

李振环，贝壳金服数据基础架构负责人。

近年来国家不断加大对金融监管，如何构建安全严谨的金融级别大数据平台成为了很多金融公司急需解决的问题。本文将会从技术角度阐述金融级别大数据平台在面对安全合规整改和金融业务迭代时，需要解决的问题以及对应的解决方案。

金融级大数据平台特征

传统的大数据平台主要解决分布式存储和计算问题，更关注大数据平台的可扩展性、高可用性和计算性能等问题。金融级大数据平台在传统大数据平台之上更关注以下问题：

1. 安全性：要确保用户信息安全性，如果用户数据发生泄漏会是重大的安全事故。尽量脱敏或加密用户敏感信息，数据分析师使用数据必须有合规的流程审批和权限控制。审批流程需要依据数据是否敏感，是否跨 BU 进行不同的审批策略。确保所有的数据操作都符合安全需要并记录审计。

2. 严谨性：金融场景有大量金额数据计算和分析，并依据计算后的结果产生实际金融活动。如果数据出现问题可能造成真实的资金损失。所以金融场景需要非常严谨的大数据平台，需要减少上线变更造成的故障，保证数据产出的质量，特别需要保证核心金额数据正确性和一致性。

贝壳金服大数据平台架构

在开始讨论之前先从全局看一下贝壳金服大数据平台的架构，进而讨论相关架构如何解决特定的安全性和严谨性问题。

图 1 贝壳金服大数据平台架构

数据架构图中间是最核心的大数据平台。贝壳金服基于 Spark 和 TiDB 搭建金融级大数据平台，使用工具 Syncer 将业务数据实时同步到 TiDB，Spark 能实时查询 TiDB 和 Spark Table 的数据并做关联分析。经过 Spark ETL Job 数据处理，将报表层和服务层的数据落地到 TiDB，再基于 TiDB 支持报表可视化和数据 API 服务。其它数仓中间层数据都存储在 Spark Table 中。数据开发人员基于 Spark 和 TiDB 进行日常数据开发。

架构图左右两边是基于核心大数据平台衍生出来的平台，左边数据平台提供日常开发和调度功能，贝壳金服基于 Zeppelin 做数据开发，基于 Azkaban 做数据调度。大数据组深度开发定制了 Zeppelin 和 Azkaban，并结合内部自研产品，有效提升了数据平台安全性和易用性。右边是保障数据质量提高大数据平台严谨性的平台。主要用于保证数据准确性和一致性。

分析完数据平台架构，我们再聊一下对应架构是如何解决相关问题。

安全性

首先需要解决的问题是安全性问题：确保用户信息安全性，使用数据必须有合规的流程审批和权限控制。需要依据数据是否敏感，是否跨 BU 进行不同的审批策略。为了满足此需求我们需要达到以下条件：

加密用户敏感数据

数据尽量在业务数据库中加密，使用 Syncer（TiDB 数据同步工具）同步到数据仓库 ODS 层之后会保持业务加密算法和值。如果需要关联分析不同业务加密数据，并且不同业务采用了不同的加密方式和自定义 Key，则需要联系各个业务方拿到对应的解密函数，在内存中解密之后使用数据仓库标准的加密算法再次加密业务数据。再次加密之后就可以进行关联分析了。需要注意不能将业务解密方法直接暴露给用户使用。对于没有加密的业务数据会通过正则表达式扫描标识出来，标识之后优先推动业务上游加密，如果业务系统来不及整改则可以直接采用数据仓库标准加密的方式对数据加密或者脱敏。

数据资产平台

在数据资产平台中定义数据是否属于敏感数据以及数据属于哪一个 BU。在贝壳金服使用自研的 Datamap 平台，此平台会同步所有 TiDB 和 Spark Table 的 DB、Table、Column 等元数据信息。再通过正则表达式扫描程序识别数据中的敏感数据，并将敏感字段打上标签，管理员也可以手动维护字段敏感标签和数据所属 BU。下图为系统截图：

图 2 数据资产平台、借款人和实际收款方为 C3（敏感）字段

数据权限申请审批流程

此流程可以根据数据是否敏感，以及数据是否跨 BU 来路由不通的审批节点。比如 Table A 有 4 个敏感字段，6 个非敏感字段。当用户只申请 6 个非敏感字段时可以进行简单流程审批，如果申请字段中包含敏感字段则需要更多安全合规的同事审批。贝壳金服也是基于数据资产平台之上开发的流程审批功能。用户可以在数据资产平台直接进行权限申请和审批操作。

图 3 贝壳金服数据审批流程

权限管理系统

审批通过之后用户可以在数据开发和调度平台编写 Spark-shell、Spark SQL、PySpark 和 TiDB SQL 来查询数据。正常情况无论是 Scala 还是 Python 都会通过 SQL 来获取 TiDB 和 Spark Table 的数据。只需要拦截所有 SQL 入口并调用权限系统进行权限认证。

SQL 解析平台

权限管理系统会将用户和 SQL 发送给权限认证系统。在权限认证系统中会通过 SQL 解析拿到 SQL 中的 Table 和 Column，并校验此用户是否有对应的权限，如果没有权限则提示用户申请权限，验证通过之后则继续执行 SQL。贝壳金服在 Spark Catalyst 之上进行二次开发，实现了 Spark SQL 和 TiDB SQL 的解析。上述过程具体流程如图：

图 4 权限管理流程

严谨性

聊完了数据安全性再来说说金融级别数据平台的严谨性。严谨性主要包含以下方面：

数据血缘平台

数据血缘平台可以降低业务变更对大数据平台数据正确性影响。业务 DDL 变更可能会导致报表数据不正确，而部分金融活动是依赖报表数据运作的。

在贝壳金服的业务系统上线都会经过 DBA 的管理平台上线。大数据资产平台管理了表的元数据信息，还会将表、任务、报表、服务和数据开发的关系打通。当一个表的数据结构发生变化时，通过上述的关系能直接发出相关报警给数据开发人员，提醒数据开发人员及时和业务沟通关注对应的业务变化。具体过程说明：例如业务人员修改了 ODS（数据仓库原始数据层）的数据，删除了一个 Column。通过表与表的数据血缘关系发现此 ODS 的 Job 会导致报表层表数据不正确，再由报表层表和报表的血缘关系推算出会影响到哪些报表，并及时发出相关报警邮件。

图 5 数据血缘展示

血缘平台目前能分析出所有通过 SQL 产生的关系，包括 Scala 和 Python 代码中执行的 SQL。所有 SQL 在执行之前都会调用贝壳金服自研的 SQL 解析平台提供的 SQL 解析接口。SQL 解析接口可以传入 SQL、UserID、JobID 等参数。SQL 解析完成后会将 SQL 中 Source Table、Target Table（比如 insert into t1 as select xxx from t2，则 Source Table 为 t2，Target Table 为 t1）、UserID 和 JobID 等信息记录上血缘日志表中。通过血缘日志表自关联分析可以得到某个表对应的父亲表、儿子表、表维护人和对应任务链接。再通过递归分析可以得到所有的表与表、表与人、表与任务之间的关系并最终展示在血缘系统中。

报表和服务则是通过分析对应元数据，拿到报表和服务对应的 SQL 和人，解析 SQL 之后拿到报表或者服务与表之前的关系。在通过表的关系打通和任务之间的关系。具体流程见下图：

图 6 血缘实现分析

数据质量平台

数据质量平台保证产生的数据是符合基础的逻辑。比如今天的数据总量应该大于昨天的数据量，比如利息应该在合理的区间。

大数据平台采用了自研的数据质量平台，在数据质量平台配置 Spark SQL 或者 TiDB SQL 来校验数据是否正确。并通过将数据质量平台服务化与调度系统打通来管理数据校验逻辑之间的依赖关系。例如可以在核心日报邮件发送之前检验重要的数据是否为空，是否大于 0。另外数据质量平台支持强弱规则，如果是强规则数据校验失败则直接当前 Job 运行失败并发出相关报警，下游 Job 则会继续等待。如果是弱规则数据校验失败则只发出报警邮件下游 Job 继续运行。

图 7 数据质量平台

对账平台

对账平台保证有逻辑上对应关系金额数据上下游能完整匹配，确保核心金额数据正确性和一致性。比如业务收款、放款数据和支付系统有逻辑上上下游的关系，则需要保证对应数据的一致性。

图 8 对账平台

总结

目前贝壳金服通过大数据平台每日运行 Job 数 3W+，每日运行数据分析类 SQL 7W+，每日 TiDB 运行 SQL 数接近 3 亿，为所有 BU 提供数据分析和数据服务。构建金融级别大数据平台最重要的是保证数据平台的安全性和严谨性。通过数据资产管理平台，数据权限审批和管理平台，SQL 解析平台以及开发和调度平台的协作共同保障数据安全。通过 DDL 监控平台，数据质量平台和对账平台来确保数据业务数据正确性，尽量减少业务损失，要时刻对金融数据保持敬畏之心。

延展阅读：

贝壳金服 TiDB 在线跨机房迁移实践

tidb

文章转载自PingCAP，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

贝壳金服在构建金融级别大数据平台的实践

贝壳金服 TiDB 在线跨机房迁移实践

评论