信也科技基于 Apache SeaTunnel金融场景的应用实践探索

原创

ApacheSeaTunnel 2024-09-05 17:56:41 ©著作权

文章标签 SeaTunnel 文章分类

©著作权归作者所有：来自51CTO博客作者ApacheSeaTunnel的原创作品，请联系作者获取转载授权，否则将追究法律责任

前言

作者：朱俊，信也科技，数据开发专家

离线开发一直是数据仓库建设中重要的一个环节。信也科技之前基于Azkaban构建了离线任务调度与开发平台，承载了公司90%以上的离线任务调度需求，以及玄策变量平台的每日变量跑批产出任务。

随着时间的积累，任务量级越来越大，Azkaban难以运维与二次开发等问题日渐凸显，给技术同学带来不小的负担。

从2023年下半年开始，借助内部创新项目的机会，开展了调度系统引擎升级的项目立项与调研，希望在新调度系统的基础上，进一步规范任务开发流程，提高运维效率，简化全链路血缘的获取和维护。

在历时大半年的探索与落地过程中，调研了Apache DolphinScheduler与内部自研调度系统DataCloud之后，考虑到公司实际情况与用户使用习惯，最终决定在自研调度系统DataCloud的基础上，借鉴Apache DolphinScheduler的架构思想与插件式设计理念，打造全新的调度引擎，并推出全新的一体化离线任务开发运维平台——千帆。

最终千帆平台成功在生产环境上线，并开始推动历史任务的迁移与迭代工作。

在调研Apache DophinScheduler的过程中，深刻体会了海豚调度结合Apache SeaTunnel打造数据抽取→任务开发→数据推送一体化流程的便捷性与实用性，对DevOps理念在数据工程中的应用也加深了一些理解和认识。

考虑到内部对于数据推送和互导这一场景依然存在着不少的痛点和问题，因此在千帆平台落地的过程中，经过技术选型与调研，决定采用Apache SeaTunnel框架来统一赋能数据集成与推送场景。

现状

在公司发展早期，由于快速迭代等原因，很多内部系统都带有不同程度的数据推送能力。

这种烟囱式的开发虽然带来了灵活适配，快速上线等好处，但随着业务不断成熟，也逐步呈现一些弊端，比如多个平台自成体系，增加了全链路血缘建设的复杂度；权限难以打通与统一管理。

另一方面，作为数据开发的核心调度引擎，Azkaban专注于调度本身，并没有集成数据抽取，数据推送等功能，需要数仓同学自行开发任务脚本实现这类功能，增加了开发成本，且复用性不高。

鉴于这两个原因，希望在千帆里集成统一的，配置化的推数功能，来收口这些分散的推数场景。

以下是我们之前的架构

架构图

从上图可以看到，各种内部平台到各式各样的目标存储系统之间，存在多种操作数据导出的方式或者工具，这些历史遗留问题为后续的开发带来了一些不便之处。

痛点

(一）全链路血缘难打通

过去，由于推送任务分散在各个系统当中，当上游的离线计算任务数据质量出现问题的时候，各个下游依赖该张离线表产出任务的推送任务无法及时感知数据质量问题，进行阻断或者重跑。

这就导致了数仓同学发现某张离线表数据有问题而重刷了当天分区数据时，需要耗费较长的时间来查下游哪些推数任务需要进行重跑，是一个不小的运维负担。

理论上我们可以开发一个统一的血缘服务来汇总每个系统的血缘数据，构建跨系统的全链路血缘。

但是这需要去理解和统一不同系统的元数据，带来较高的开发成本，不利于数据治理工作的开展。

（二）推送框架难统一

由于历史原因，基于Azkaban的调度平台虽然能满足离线调度的需求，但是Azkaban是以command为任务运行的最小单元，每个command实际上一个或多个shell脚本的功能集合，这就造成了基于Azkaban的任务类型难以划分，同样的功能可能会复用不同的shell脚本，每个脚本对于开发运维同学来说都相当于一个黑盒，需要熟悉其中的逻辑才能把控。

我们在做千帆早期的设计和开发，想对接Azkaban时，就面临这样的问题。为了适配Azkaban底层的不同运行脚本，需要不断的在产品设计上增加Case来满足各种自定义脚本的参数和逻辑分支，来适配推送不同存储（如Mongo和StarRocks）的作业。

而对于其他拥有推送功能的系统来说，由于设计开发的人员不同，整体架构和使用场景不同，也会选择不同的实现方式来完成数据推送（比如采用impala JDBC、MapReduce等实现方式），这就造成了同质化的功能采用不同的技术实现，不仅维护难，出了问题也较难定位，且无法采用统一的产品设计逻辑来覆盖公司内部的业务场景。

（三）推送任务监控与治理难实现

上述问题造成了数据计算流程和数据推送流程之间的割裂，原本数据抽取-数据计算-数据推送应该在逻辑上是一个整体，现在需要开发人员分散地去处理。

当涉及到权限，验数，链路排查等问题时，这种一来二去带来了时间和沟通上的成本。

同样由于实现方式的不统一，对于推送任务的效率和断点续传、Checkpoint、流控、监控Metric等高级功能，难以给出统一的实现方案，不利于整体的数据治理。

技术选型

在新系统调研开发过程中，我们对数据集成底层框架进行技术选型时，参考了其他公司在落地实践中的经验，我们认为针对我司的场景，需要从以下几个关键点来进行衡量：

性能： 数据集成框架需要具备高吞吐、低延迟、可观测的特点
安全部署： 金融场景需要考虑数据的安全性，因此集成框架部署依赖的其他组件越少越好，部署环境与流程简单，易于维护
易用性与扩展性： 数据集成框架应具有良好的扩展性和架构设计，易于针对个性化场景进行二次开发
社区生态： 数据集成框架应支持多种数据源和目标存储，社区活跃度高，拥有丰富的User Case

我们考察了一些较为流行的开源工具，主要集中在使用较为广泛的DataX、Sqoop、SeaTunnel。

以下是这三款产品的横向对比

对比项	Apache SeaTunnel	DataX	Apache Sqoop
运行模式	分布式，支持单机	单机	非分布式框架，依赖Hadoop MR实现分布式
容错机制	无中心化高可用架构，容错机制完善	易受网络、数据源等因素影响	MR模式容错处理不便
部署难度	容易	容易	依赖Hadoop集群部署
支持数据源丰富度	超过100种数据源	20+种数据源	只支持几种数据源
自动建表	支持	不支持	不支持
断点续传	支持	不支持	不支持
单机性能	很好	较好	一般
可扩展性	易扩展	易扩展	扩展性较差
统计信息	有	有	无
与调度系统集成	与DophinScheduler集成，也支持集成到其他调度系统	不支持	不支持
社区	非常活跃，成功案例多	一般	已从Apache退役

结合上面的横向对比（部分参考了社区用户实践经验与官方文档）结论，基于我司的现状和痛点，综合考虑架构设计先进性、灵活性、部署运维成本、社区活跃度等方面，我们最终选择了Apache SeaTunnel作为底层框架来统一任务推送与导出的流程与场景。

实践过程

在调研和落地过程中，我们基于SeaTunnel 2.3.4版本，主要做了以下一些适配和改造，以满足公司内部的导数场景和需求

(一）扩展Sink插件

支持PMQ

在2.3.4的基础上，我们扩展了connector-pmq模块，以接入公司内部的消息队列中间件PMQ。

PMQ是信也科技自研的一款消息系统中间件，在公司内部有广泛应用，支撑了信贷业务各条线的消息传输与上下游数据链路，支撑PMQ打通了数仓到业务系统的最后一环，实现了数据赋能业务的最后一公里。
支持跨集群HBase Kerberos认证

公司已有的一些业务平台依赖于自建的HBase集群存储，与数仓的大数据集群是两套体系，之前由于Kerberos认证的问题，难以从数仓的Hive表将离线计算结果写入业务平台的HBase集群，需要改造一个MapReduce程序去实现跨集群的Kerberos认证，增加了数仓开发同学的维护成本。

千帆平台在SeaTunnel 2.3.4版本的Connector-HBase模块上增加了对Kerberos认证的支持（复用了Connector-file-base-hadoop模块中对Kerberos相关的Config），实现了配置化生成任务读取Hive表跨集群导入标签平台的业务需求，目前这块后端已经实现，产品设计交互和前端页面计划在下个迭代支持。
数据传输流程优化

在信也科技，有一些离线数据经过内网专线跨机房传输的需求，过去由于没有统一的平台工具支持，往往是数据开发同学产出离线报表且验证无误之后，通知下游研发同学进行数据传输任务的启动。

由于数据跨机房传输对于数据质量和网络传输速率都有一定的要求，且有一些特定的处理逻辑，因此当传输失败或者数据错误时，往往需要研发同学人工介入，维护成本较高，且无法做到流程自动化。

考虑到为减少人工维护成本，我们也在积极与数据开发和研发同学沟通需求，通过SeaTunnel来支持这一业务场景，目前整个研发方案在沟通与设计中，计划在未来的版本上线。