关于数据库:众安保险基于Apache-SeaTunnel的生产应用实践

*> 文|曾力 众安保险大数据开发高级专家

编辑整理| 曾辉 *

前言

众安保险从 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 地址：https://github.com/apache/seatunnel/pull/5872

Connector 局部列同步

问题

咱们在连接器适配 DataX 个性革新时，DataX 反对局部列回流及局部列写入；Seatunnel 连接器目前在 source 端局部连接器有实现，sink 端根本是全字段写入；

解决方案

Source 端 ：咱们能够将自定义列(而非全表列) 设置在 CatalogTable 当中，同理 DataX 当中相似分区列、常量列的回流也能够通过雷同的形式得以实现，并透传到执行打算当中，为 Sink 端所获取；jdbc 连接器能够通过 query sql 抉择适合的列；

Sink 端：目前能够依据 SeaTunnelRow 的 index 地位和自定义列中的 index 进行对齐，实现局部写入；jdbc 连接器能够通过 insert 指定列进行解决。

随着 Apache SeaTunnel 的胜利施行，众安保险在数据集成畛域迈出了松软的步调。咱们期待在一直变动的技术环境中持续优化咱们的数据流程，以反对业务的疾速倒退和翻新需要。

众安保险的这一实际案例，证实了开源技术在企业级利用中的后劲和价值，展现了凋谢单干精力对于推动行业倒退的重要性，也心愿可能给大家带来一些启发！

本文由 白鲸开源科技 提供公布反对！