*> 文｜曾力 众安稳妥大数据开发高级专家
编辑整理｜ 曾辉*
前语
众安稳妥从2023年4月就开端了数据集成服务的预研作业，意在经过该服务处理当时数据同步场景下的两大痛点，服务化才能单薄和无分布式同步才能。咱们对多种开源数据同步中间件的调研和功用测验，终究挑选Apache SeaTunnel 及其新的Zeta引擎，进行服务化包装。
2023年10月，咱们 依据2.3.3版别，开端进行二次开发。主要是完善服务化接口、适配衔接器特性相关作业。2024年元旦前后，咱们完成了数据集成服务的开发，并开端依据MaxCompute到ClickHouse的同步场景开端批量替换存量DataX作业，现在已切换数百个，作业平稳运转，并达到预期的功用提高效果。
后续咱们将在实际运用中不断收集反应、优化和完善服务，并向社区提交迭代和优化建议。
数据集成的痛点
众安稳妥在2015年左右就开端经过DataX来作为数据集成的同步东西，从淘宝内部的2.0版别到后续社区的3.0版别，其安稳性和功率得到了验证。
但随着时间的推移，咱们每日的数据同步作业量由最初的几千个提高3.4万个，面临每天20TB的数据入仓数据量和15TB的数据出仓数据量，以及与流媒体交互场景下单日最大40亿条记载的增量同步场景，DataX展示出了其局限性。
DataX作为一款经典单机多线程的数据集成东西，其作业装备化、多并发、插件可插拔、内存数据传递的规划思想是优异的，为后续许多集成中间件的规划指明晰道路。可是其缺少服务化及分布式处理才能，这约束了其在大规模数据同步场景下的运用。
降低耦合：内部场景中，DataX服务化的局限性，导致其与内部研发、调度平台的严峻耦合。 这导致DataX作业运转时的资源耗费(CPU)，会严峻影响服务功用。
才能扩展：面临未来存算别离和云原生等技能趋势，咱们意识到需要一种能够供给服务化才能，支撑不同的集成中间件，并适配快速的装备替换。
资源阻隔及弹性扩展：咱们期望数据同步资源能够更加弹性地被操控和办理，特别是面临咱们的3.4万个DataX使命，这些使命被部署在6台装备为16核64GB内存的ECS上，经过逻辑上的三个集群完成部门与子公司之间的阻隔。但是，资源运用的不均匀性，尤其是在夜间使命高峰期资源负载或许极高的状况下，强化了对资源弹性可控运用的需求。
面临未来存算别离和云原生等技能趋势，咱们意识到需要一种能够供给服务化才能，支撑不同履行中间件，并能适应快速开展需求的数据集成东西。
Apache SeaTunnel正是在这样的布景下被选中，它不仅能帮助咱们处理现有的数据集成应战，还能为咱们供给一个滑润搬迁的途径，确保数据同步使命的高效和安稳履行。此外，Apache SeaTunnel在CDC实时同步方面的才能，以及削减数据同步回流时间的特性，也是咱们挑选它的重要考虑因素。
为什么挑选Zeta
简略易用
- 多形式部署：支撑单进程/集群两种形式，支撑容器化Kubernetes/Docke部署；
- 衔接器丰厚：社区已供给几十种类型的衔接器，并供给了相对完善的功用。社区经过几个版别的迭代，现已能够掩盖DataX的主要功用；
- 转化器：供给DAG等级的转化器，相关于DataX行级转化器是一个很大的进步；
- 服务化才能：供给体系RestApi、客户端署理等多种形式接入服务；
- 支撑场景：离线/实时同步，整库同步等；
- 依赖较少：zeta standalone形式能够不依赖第三方组件完成分布式数据同步；
扩展性
- 衔接器：可插拔规划，能够轻松地支撑更多的数据源，而且能够依据需要扩展形式；
- 多引擎：一起支撑Zeta、Flink、Spark三种引擎，并供给一致的翻译层进行对接扩展；众安现在的基础架构主要是依据MaxCompute，咱们没有Hadoop这类的大数据集群，因而Zeta的分布式才能能够很好的处理该问题。一起若未来进行大数据基座搬迁(搬迁其他云EMR或自建集群)，能够完成作业的无缝衔接。
- Zeta多资源办理器：现在仅支撑Standalone，未来社区会支撑yarn/k8s形式；
高效安稳
- 更快速：在相同资源装备下，相比于DataX能够供给15%~30%的功用提高；
- 资源节约：咱们测验经过优化装备极限压榨内存资源，成果发现在保持同步速度不变的状况下，相比DataX，SeaTunnel能够节约30%到40%以上的内存。这意味着一旦SeaTunnel支撑在Kubernetes上运转，对内存的全体耗费将大大削减。SeaTunnel运用共享线程技能削减了上下文切换的开支，然后进一步提高了数据同步的速度。
- 容错康复：作业等级完成了pipeline等级的checkpoint，集群等级完成了Hazecast内存网络IMAP的异常康复。依据内部oss存储场景，咱们扩展了相关插件。
社区活跃度
Apache SeaTunnel的社区活跃度十分高，作为一个由国内开发者主导的社区，咱们与社区的其他成员，包含高教师和海林教师等，有着十分顺畅的交流和协作，他们供给的及时指导和问题剖析对咱们帮助巨大。社区还定时举办周会，为大家供给了一个讨论规划形式、分享问题处理方案的平台。
一致数据集成服务
当时规划
咱们打造了一个一致的数据服务平台，这一平台将数据源办理和数据集成的装备进程简化，支撑数据开发流程从开发到测验再到发布的全进程。咱们经过在IDE中办理数据源和集成装备，然后经过调度体系在夜间分配作业到履行节点，进一步提高了数据处理的主动化和功率。
这种方式尽管有用，但咱们意识到在服务化方面还有提高空间，特别是考虑到在高负载状况下CPU资源的高耗费和对监控和作业办理的需求。
服务化规划
为了处理这些应战，咱们决定将部分功用从调度体系中独立出来，使得调度更加朴实和高效。咱们的方针是将数据集成服务转变为SaaS形式，以便更好地集成进咱们内部的各种体系中，并快速接入集成服务才能（例如如CDP体系和自助报表平台）。
该服务相似于Apache SeaTunnel Web，能够装备作业、设置调度形式、查看履行记载以及办理数据源。为了提高灵活性和便利未来的集群升级，咱们引入了名为“quota”的虚拟资源组概念，咱们的规划包含两种集群：主履行集群和备用履行集群，用以支撑作业的主动降级。
在抱负状况下，主履行集群运用SeaTunnel，而在备用履行集群中运用Data X。这种规划仿照了如B站等公司内部选用的Data X和Apache SeaTunnel并行体系，意图是在单一体系内完成作业的无缝降级，例如当SeaTunnel作业失利时，体系会测验在Data X集群上重新调度履行该作业。
为了办理这一杂乱的流程，咱们规划了中心服务和履行服务。中心服务担任作业的调度、降级、日志整理、回调服务以及装备和资源办理。履行服务则专注于作业的实际履行和监控，包含作业履行线程和协调线程。
在作业履行前，咱们会依据作业装备和集群资源状况来决定作业在哪个集群上履行，并确保有满足资源来履行作业。
Datax作业搬迁
咱们还侧重进行了Data X到SeaTunnel的搬迁作业。
插件兼容性
这包含比照社区供给的衔接器和咱们内部运用的插件功用，确保它们之间的兼容性，并对最常用的数据回流场景进行了特别关注，即从MC到ClickHouse（CK）的数据回流使命。咱们有大约3.4万个使命，其中约1.4万个使命专门用于将自助剖析报表的底层元数据日常推送至CK，针对这些场景咱们进行了特定的兼容性开发。
作业切换接口
为了支撑作业的滑润搬迁和开发，咱们完成了一个作业开发切换接口。这答应咱们依据作业号和衔接器的适配状况，灵活地进行作业搬迁。搬迁完成后，新使命会被注册到集成服务中，并以公共装备格式保存，然后便于在办理服务端经过脚本形式或页面引导化装备进行操作。
装备抽象
咱们制定了一套内部公共装备标准，旨在兼容Apache SeaTunnel和Data X作业的装备方式。这一做法不仅简化了多环境数据源的替换进程，还增强了安全性，避免了在装备中直接露出灵敏信息如用户名和密码。
咱们在作业履行前进行作业装备翻译，这种规划参阅了Seatunnel的翻译层规划，包含本地变量和数据源参数的替换，以及针对不同引擎的装备翻译。这种双层翻译机制，一层担任将特定中间件插件装备转化为公共装备（Pre transform），另一层则将公共装备转化为指定引擎装备（正常的transform），极大地增强了作业装备的灵活性和兼容性。 一个公共层的存在是必要的，因为它答应在不同数据集成东西之间进行灵活的翻译和装备转化，然后完成数据服务履行在多引擎间的履行降级；
Zeta 集群资源管控
问题：Zeta资源办理Slot现在仅是逻辑阻隔，若选用动态slot形式，会创建很多线程进行资源争抢，必定程度会拖慢多并发作业的全体速度，或导致集群OOM。该形式比较适合于CDC实时同步多批次，少数据量分片的场景。
处理方案
- 运用静态slot形式
关于离线批处理使命，该形式更为适宜，其能够必定程度的操控资源耗费，避免因很多数据缓存导致的内存溢出（OM）问题。 依据集群的CPU/内存大小进行评价，适当的CPU超卖，并装备适宜的资源槽数量，以确保数据处理作业的功率和集群资源的有用运用。
- 新增集群slot服务RestApi
经过扩展SlotService和ResourceManager，在Hazelcast中扩展存储集群全slot和已分配slot状况 ，并完善集群发动、节点上下线、作业提交、作业释放时的slot资源状况处理，并供给RestApi查询。
- 作业slot核算
早期，咱们测验依据物理履行计划来评价作业的并发度，但后来的版别变更要求咱们依据作业装备来进行slot资源核算。 在并发度一致的状况下，作业资源占用核算公式如下：
该办法能够适用于大多数端到端数据同步场景，但在更杂乱的作业装备中，这种办法或许不够灵活。咱们也等待社区内部完成一个相似SQL explain的API进行资源核算。
- 作业操控
作业提交前依据装备核算耗费的slot资源； 作业提交前会校验集群slot资源总数和可用资源是否能够满足作业资源耗费，若能够则经过RestApi提交；
Zeta RestAPI 对接问题
问题
集群http服务地址挂载阿里云slb之后，发现集群很多衔接被远程封闭的过错。 原因：slb开启健康检查后，建议探测会发送syn包，后端响应syn ack，然后会重置衔接。 处理方案：在测验hazelcast组网形式和slb装备均未有用的状况下，咱们再服务端经过集群装备信息，在http请求前进行了一次随机路由处理；
问题
非Master节点无法处理作业提交、停止、集群slot获取等操作 原因：2.3.3版别经过HazelcastInstance在非master节点上无法获取Master服务的相关实例；
Hazelcast.getAllHazelcastInstances() 并没有多个，是还需要有额外的代码来修正么，无法跨节点提交作业。
处理方案：一个通用的想法是模仿SlotService，将计算信息带给Master，经过hazelCast的Operation机制，参阅HeartbeadHealthOperation机制，经过存量的GetMetricsOperation去Master节点进行获取。
后期咱们把该思路供给给了社区，社区相关同学也完善了作业提交、停止等接口的修正。
Connector 支撑pre/post sql
在Apache SeaTunnel的实践中，特别是在处理ClickHouse (CK) 报表数据时，衔接器的Pre和Post SQL功用展示了其对杂乱数据处理场景的高度适应性。这些功用答应在数据同步使命履行前后，履行特定的SQL句子，为数据处理供给了更大的灵活性和准确操控。
运用场景
主要运用场景包含数据同步前的准备作业和同步后的整理或重组作业。例如，在推送数据到CK报表前，而不是直接掩盖或删去当时表，数据或许首先写入一个临时表中。完成数据写入后，能够经过履行Post SQL句子对local表进行重命名操作，并将其挂载到分区表中，这种办法有用避免了数据同步进程中的数据丢掉或不一致问题。
PreSql实践
问题：前期版别不支撑，仅能经过XxxSink中prepare办法完成，但该接口后续会被取消；
处理方案：Apache SeaTunnel社区版别2.3.4提出了schema save mode和data save mode的组协作为一种处理方案，支撑在数据同步前履行SQL句子（Pre SQL）。这种办法的引入大大增强了Apache SeaTunnel在数据同步场景中的灵活性和可用性。咱们经过data save mode中的CUSTOM_PROCESSING形式完成preSql履行，并扩展至可支撑履行多段SQL；
PostSql实践
问题：在XxxSink或XxxSinkWriter中close办法完成，会出现多并发抵触问题；
处理方案：关于Post SQL的支撑，尤其在多线程环境中确保数据完整性和一致性的应战更为杂乱。经过在二阶段提交的close办法中履行Post SQL句子，供给了一种可行的处理方案。这种办法开始完成了在数据同步使命完成后进行必要的后处理操作的才能。
咱们也遇到的一个应战是处理Post SQL履行失利的状况。这个问题在1月4日的发版前测验中被发现，测验团队仔细检查了当Post SQL履行失利时的体系行为。
发现履行失利后，Subplan的重试机制（reApache SeaTunnelore处理）导致作业状况办理存在问题，作业无法正常停止。作为临时处理方案，将Subplan的pipeline最大重试次数（Max reApache SeaTunnelore number）设置为0（默许值为3），这意味着在离线批处理场景下，一旦出现过错，体系将直接报错并停止作业。
这个措施尽管能够暂时处理问题，但需要进一步与社区协作探讨更根本的处理方案。
一起咱们也等待社区会有更好的做法来完成PostSql，因为二阶段提交close办法履行SQL意味着作业checkpoint现已改写完毕，这时出现异常，或许对现有机制发生必定影响。
Connector 列隐式转化
问题
在数据同步和集成进程中，数据源与方针存储之间的数据类型匹配和转化是一个常见的问题。Apache SeaTunnel中的衔接器和结构层级或许没有进行充分的列隐式转化处理，导致无法有用地将数据写入到方针数据源的对应字段中。咱们在衔接器适配DataX特性改造时，发现在衔接器和结构层面均未进行列隐式转化。
例如SeatunnelRowType对应的榜首列是String类型，数据为2023-12-01 11:12:13，其无法写入字段为Datetime类型的Maxcompute字段傍边。
处理方案
衔接器等级完成了一个简略的RowConverter, 将结合SeatunnelRowType中的字段类型、对应的Maxcompute字段类型进行映射转化。后期考虑接入社区常用类型默许转化特性。
pull request地址：github.com/apache/seat…
Connector 部排列同步
问题
咱们在衔接器适配DataX特性改造时，DataX支撑部排列回流及部排列写入；Seatunnel衔接器现在在source端部分衔接器有完成，sink端基本是全字段写入；
处理方案
Source端：咱们能够将自定义列(而非全表列)设置在CatalogTable傍边，同理DataX傍边相似分区列、常量列的回流也能够经过相同的方式得以完成，并透传到履行计划傍边，为Sink端所获取；jdbc衔接器能够经过query sql挑选适宜的列；
Sink端：现在能够依据SeaTunnelRow的index位置和自定义列中的index进行对齐，完成部分写入；jdbc衔接器能够经过insert指定列进行处理。
随着Apache SeaTunnel的成功施行，众安稳妥在数据集成范畴迈出了坚实的步伐。咱们等待在不断变化的技能环境中持续优化咱们的数据流程，以支撑事务的快速开展和创新需求。
众安稳妥的这一实践案例，证明晰开源技能在企业级运用中的潜力和价值，展示了敞开协作精神关于推动行业开展的重要性，也期望能够给大家带来一些启示！
本文由 白鲸开源科技 供给发布支撑！
