一、翼支付公司与业务介绍
?天翼电子商务有限公司（以下简称“翼支付”）是中国电信集团有限公司的成员企业，是国资委双百改革和发改委第四批混改“双试点”企业，也是“双试点”企业中唯一的金融科技公司。公司以翼支付 APP 为载体，面向 7000 万月活用户，提供民生缴费、消费购物、金融理财等服务内容，依托区块链、云计算、大数据、人工智能等技术，赋能超 1000 万家线下商户门店及 170 余家线上知名电商。秉持“响应监管、服务民生、资源共享、合作多赢”的理念，聚焦“开放、安全、便捷”的核心产品力，翼支付坚持通过服务投入与产品升级，构建贴合需求的管理与业务体系，以交流融合的业务实践，推动产业各方实现数字化转型。
构建数据开发与治理平台的业务场景：满足数仓、各业务部门快速开发、离线计算、数据集成、实时数据开发、数据服务等功能，提升数据开发与治理效率。
我们的目标：构建先枢-数据开发与治理平台，集成数据集成、离线计算、实时计算、数据服务，提供一个一体的集成化开发平台，一站式满足数据开发人员研发诉求。
我们所面对的挑战：海量数据处理、高并发请求、低延迟时效性?、业务多样性、场景复杂性。
二、数据开发与治理平台介绍
1、任务开发流程
任务开发首先需要创建业务流程，这里的业务流程（Flow）用来管理一组任务，任务主要是数仓的离线调度，涉及到数据集成、发布以及 SparkSQL 的离线任务。在开发完任务脚本之后，再进行任务核心参数的设置，比如运行的优先级队列、任务的相互依赖关系、运行参数，在配置完参数后，接着对任务可以测试执行，测试运行通过后可以对任务进行上线。这里任务以业务流程（Flow）为单位进行上线，上线完成后，交给管理员的任务审核，审核主要检查任务消耗资源、并行度、开发规范等，审核通过后发布到生产环境中。发布到生产环境后，通过提交到调度引擎进行日常定时调度工作。
数据开发中包含了一些功能，在画布中新建业务流程，拖拽相关任务节点到画布上，进行任务节点依赖配置。根据业务分类，提供了一系列任务开发功能，包含了五种任务类型：
① 数据同步：包含像 Oracle、OceanBase、Mysql、SFTP、Hbase 的数据接入与发布；
② Spark任务：SparkSQL 的离线计算；
③?机器学习：AI 模型任务；
④?Kylin 任务：调度 Kylin 数仓 job；
⑤?触发型任务：满足外部平台的接口触发数据治理平台启动数据任务，比如外部系统进行人群圈选数据推送、其他数据加工相关工作。
SparkSQL 任务开发编辑器页面，包含的功能有：
①?新建 SparkSQL 任务：通过拖拽建立 SparkSQL 任务节点并编写脚本，完成编辑后，可通过语法校验，提示 SQL 编写报错问题；
②?单次执行：Spark 任务提交到集群运行，测试通过后，可以进行提交，最终保存，经过任务审核后，即可部署到生产进行运行；
③?自动任务依赖配置：系统会自动通过 SQL 语法解析到任务来源表，数仓按照统一开发规范，每一个任务有唯一的去向表，做到任务之间最细粒度统一，便于管理，来源表可以有多个，通过 SQL 解析拿到对应源表，通过任务解析，找到上下游节点，自动生成边关系；
④?手动添加依赖：通过手动搜索任务，添加任务到依赖上；
⑤?SparkSQL 权限解析：根据从元数据配置的用户相关权限，进行用户对应数据库表的操作权限；
⑥?血缘关系：如图展示一个任务流程 Flow 下面的所有任务跨 Flow 血缘关系。
早期数据开发与治理平台是单环境架构，但在平台任务上线时，会遇到一些偶发问题，比如线上任务紧急修复上线时，SQL 脚本未经过审核，导致任务会占用过多资源，还有 SQL 相关代码不规范等问题，因此使用了双环境上线流程解决脚本流程规范。
所有的 Flow 在开发和生产各有一份，通过镜像的操作，每个 Flow 和 Task 有相关的 code 标识一一对应，唯一区别是开发环境的 Flow 的 code 有 dev 前缀，比如开发环境任务 code 为 dev0001，那么生产环境的任务 code 对应为 0001，方便系统和用户区分。
在调度层面，这样的区分方式可以避免底层调度引擎、数仓层感受到上层的变化，比如 dev 环境的 Flow 有相关任务在运行，而其对应的生产任务也在运行，但是通过唯一的任务 code 进行区分，能使这些任务同时运行在两个环境，生产正常调度，开发环境并行开发。
在底层设计层面，开发环境去掉前缀，即可映射到生产环境任务，同时在应用层可以统一存储，也就是生产环境和开发环境的 Flow 和 Task，可以分别在一张 Flow 表和 Task 表中进行存储，简化设计，令底层数仓和调度层无感知。
版本管理为了满足数仓开发脚本的、任务之间依赖、业务流程配置、调度更改的版本回溯的需求，针对所有 Task 和 Flow 进行版本管理，再发布到生产，生产同步到开发环境，都可选择任意版本进行发布和回滚。
三、平台技术架构实践
1、整体架构概述
上图展示了整体系统架构：上面模块是应用层，下面是调度层。
配置管理：包含业务空间管理、成员管理和库映射管理。空间、成员管理是对应部门人员之间的资源、数据权限隔离；库映射管理，适用于解决来源库与去向库映射关系，比如数据接入时，落到哪些仓库，可以通过配置进行管理；
数据开发：包含数据集成、离线开发、数据发布、实时作业和 FlinkSQL 指标开发。
任务管理：包含业务流程管理、任务上下线、任务重跑补数操作以及任务的血缘依赖管理。
外部服务：元数据功能，主要用于在用户创建表后，对表详情进行查看，以及从中获取所有表、库、权限；用户中心功能，主要用于配置相关平台用户账户管理和各子平台的权限管理；AI 服务功能，主要用于管理机器学习模型任务，通过接口调用该机器学习服务；质量作业功能，主要用于在数据任务开发完成后，核验数据的质量。
调度层：Airflow 是调度的核心模块，橙色部分为围绕 Airflow 扩展开发的组件，包括任务管理，自定义 Operator（支持 SparkSQL 和数据交换相关的任务提交）。
2、调度引擎
关于调度引擎，最初对比的有 Zeus、Airflow、Azkaban。Zeus 支持分布式调度，但对 Hadoop、Spark、数据交换调度不完善，社区活跃度下降；Airflow 的 Python 扩展方便，功能完善稳定，2.X 支持多 Master 分布式调度，社区活跃；Azkaban，由 Java 开发，但调度任务功能相对简单；最终选择 Airflow1.10（技术选型时 2.x 版本还未稳定）作为生产离线调度引擎。
Airflow 目前仅提供一些 Web 界面上的管理操作，没有提供相关 Rest 接口，用户将 Airflow 的 DAG 文件放在 DAG Directory，Scheduler 进行扫描，会把对应的 DAG 的元数据存储到 MetaData 的 DataBase，DAG 对应上层应用的业务流程 Flow，管理了一组任务。Workers 支持扩展，分布式部署多节点。在生产环境中 Airflow 主要适合使用 CalaryExector 部署，本地环境使用 LocalExector 进行任务的调度。在翼支付生产中使用 Redis 作为 Celery 任务缓存队列，来加速任务调度性能。
Airflow 1.10 提供的 WebApi 比较少，在原生功能中使用 Git 或 Ceph 进行 DAG 文件存储，用户需要自己生成 DAG 文件放到集群节点，从流程来看引入对应组件，复杂性会提高，用户侧需要涉及生成对应的 DAG，上层应用生成 DAG 及业务流程管理工作。为了解决这些问题，通过扩展开发 Rest 接口功能，管理 DAG 的生成和 DAG 任务元数据，上面应用层通过 Rest 参数传递，帮助屏蔽底层调度引擎相关工作。DAG 文件上传到对应 Scheduler 和 Worker 节点后，Scheduler 会以 5 分钟为周期扫描，扫描到任务 DAG，才能完成任务的上线，之后进行 Dag 上线的回调动作，通过底层完成上线回调上层应用，避免了上层应用对上线的任务定期轮询状态，DagWorker 等待 DAG 上线成功进行回调完成任务的上线。
对于 DAG 文件的生成如上图所示。
external_task：对应外部任务，task >> task2，表示任务 2 依赖任务 1，同时也依赖了外部任务?ExternalTask1。整个?Python?文件就是?Airflow?调度的?DAG，AirFlow?内部会解析其中的?DAG?及其依赖关系，生成调度的元数据。
3、数据总线
我们使用?Datax?作为数据总线的核心模块，基于以上模板文件来执行任务，其调度是单机运行，但是 Datax 扩展性很好，并且预留了任务调度器接口，扩展 Source、Sink 以及数据转换逻辑、过滤开发，基于 Datax 封装了数据总线的任务管理功能。用户在页面输入参数，通过 Reader、Writer 插件来渲染生成 Datax 模板文件，Datahub 模块将文件通过 Yarn api 提交给对应的 Yarn 集群，之所以选用 Yarn 调度，是因为 Datax 是单机运行，不能做好多节点任务的调度。对比了 YarnCluster 与 K8S，暂时离线计算任务没有完全 K8S 容器化，采用 Yarn 的统一大数据离线调度任务提交到 Yarn 集群离线计算。
4、资源隔离、计算优化
资源隔离主要是对实时离线、不同任务之间集群隔离，比如数仓之间的业务转换、推数、任务分发不同类型作业。
数仓核心任务置于一级队列，其他部门基于其上，划分了子任务队列，有核心、重要、普通，三级优先级队列的资源隔离。
动态限流低优先级任务保障核心任务并发，当任务队列满了，先不提交普通任务，普通任务大多凌晨调度，新任务的限流可以保障普通任务的并发限制，避免普通任务优先调度，占用资源，核心任务需要等待计算资源。
在凌晨之前做普通任务的监控，避免普通任务调度之前被其他日常任务运行资源占满。
Spark 任务的优化包括：小文件治理，任务优化主要是资源优化、数据倾斜、Join 优化，以及任务拆分。
5、数据质量监控
质量监控主要在五大方面：及时性、准确性、完整性、一致性以及数据有效性进行分析改进。
数据质量监控的架构如上图所示，上面会配置相关的质量监控规则以及监控任务，质量规则分为强规则和弱规则，针对强规则进行任务熔断，对于弱规则进行事后分析改进。规则通过 SQL 对任务的数据一致性校验，整个规则任务以 SparkSQL 作业提交上进行计算生成规则报告，最后进行分析改进任务。
上面是作业的运行详情，质量作业通过 SQL 模板生成任务、作业名称，每条模板生成一条规则与记录，针对单个表会启动多个规则进行校验，单表的多字段校验，输出规则。若针对一张表有十个规则，第一个优先规则不满足，就会中断校验，直接返回流程。
6、云原生实践
数据开发平台流程涉及到实时、离线、数据总线、质量作业、监控、先觉 AI 模型，平台服务基于微服务架构进行拆分到不同子服务，满足业务快速迭代，从开发初期一直到最后上线经过多版本开发，模块变动对其他服务影响比较大，传统的大后端服务开发模式进行开发，模块的耦合影响重，通过对各个服务的拆分很好的解决了这些问题。
通过公司 KCS 的 CI/CD 平台提供服务的快速测试，迭代，部署上线。基础设施配有统一监控告警功能及自动扩容能力，提升服务稳定性。
整个开发平台迭代中，也伴随着数据治理流程，工作成效比较显著。整体计算成本降低 87%，模型特征计算时效提前 7.5 小时，看板数据查询时效提升 40 倍。
四、未来展望
数据开发与治理平台拆分的服务较多，与离线调度紧密相关，需要更好的性能与扩展。
可观测性：可以及时发现服务的不稳定性问题。比如当任务越来越多，任务之间状态会有并发冲突，带来的性能问题需要及时解决。
计算效率：目前有比较多的 SparkSQL 作业，需要根据专家经验和实际场景针不断优化离线 SQL。
异地容灾：现在的大数据集群部署在同一个机房，包括离线、实时计算。单机房会有异地备份诉求，需要多机房进行数据灾备，以及实时计算跨集群、在线数据服务应用实现跨机房容灾。
五、问答环节
Q1：数据权限是怎样管控和实现的？
A1：数据权限分为两块，用户在平台所属组织的权限与空间管理的那块进行了部分绑定，用户所属部门的操作权限限定了平台的数据权限；在元数据模块有设置用户对库表的相关权限，UDF 的需要加解密的敏感数据也会关联到用户，用户新建任务，其 SQL 解析后会涉及相关的表，与相关表的操作权限进行校验绑定。
Q2：数据治理是怎样做的，如何提升效果？
A2：早期的烟囱式的开发，计算成本相对高，计算性能较低，数仓针对其任务，伴随着数仓数据治理过程的需求，平台迭代研发满足数仓的开发作业的流程，平台针对调度任务的性能以及计算任务的性能优化作了相关支持，整体计算资源可以达到更好的效果。
0 留言