京东科技基于 Apache SeaTunnel 复杂场景适配 #数据集成

作者：宁诚、陈伟强京东科技架构师

技术背景与挑战

技术背景

2023年第一季度，京东科技的营销与数据资产部开始规划数据洞察系统产品，主要服务于京东科技营销体系的业务团队。该系统的分析内容涵盖了京东集团在商城、金融和物流等各个业务系统中的相关数据。

考虑到OLAP领域的复杂场景及系统运维经验，最终选择了ClickHouse集群作为计算和存储引擎，而同步与集成工具则选用Apache SeaTunnel。

具体的实现细节可参考2023年8月撰写的《ClickHouse 和 SeaTunnel 在京东科技的最佳实践》一文。

技术挑战

随着洞察系统的上线使用，业务需求不断迭代，对数据同步的要求也越来越高。

技术挑战主要集中在以下几个方面：

时效性

洞察系统上线初期，90%的数据同步采用T+1的更新粒度，主要是将Hive数仓更新后的数据推送同步到ClickHouse集群。

所有前一日的数据需在每日早上9点前完成更新。在2023年第一季度之前，这项工作由集团自研的JDBC数据管道完成。虽然小数据量的表能够胜任，但对于超过 20亿 的大表来说，已无法满足业务需求，尤其是超大表（超过100亿，最大可达600亿）的时效性，往往要延迟到当日下午甚至第二日。这种情况在大促等极端情况下愈加明显。

在采用Apache SeaTunnel框架并实现文件挂载方式后，所有T+1的数据同步已能在当日中午前完成。这一进展使我们离实现每日9点前完成的最终目标更进一步，同时也为满足实时同步的要求积累了宝贵的技术经验。

准确性

京东科技的洞察系统每日涉及多个业务方的数据同步，日常的数据分析工作对数据的敏感性极高，微小的误差很容易引发业务方的质询。特别是在关键业绩指标、C端用户AB测试和经营收入等数据上，业务同学经常通过多渠道验证数据的准确性。

即使在迭代需求上线并经过测试验证后，仍会持续进行核对。

在2023年洞察系统上线初期，我们曾尝试与业务方沟通，接受万分之一的误差。这一情况凸显了分布式系统在一致性、可用性和分区容错性方面所面临的技术挑战。

复杂需求接入成本

自2023年上线以来，京东科技的洞察系统在两年内共提交了550多个业务开发需求，涵盖了集团商城、金融和物流三大核心业务板块的相关数据，平均1个工作日提交接近1个需求。

系统提供了10多项OLAP分析功能，每日处理超过500个离线数据表。其中，流量库包含商城和金融场曝光、点击日志，按需同步裁剪过后，大促期间的最大日同步量仍达到了2000亿条数据，指标全集超过4300个，涉及人群数量达15000个，标签数量达到4800个。除此之外，系统还需支持复杂的bitmap位图交并差计算和关联查询场景。

日常维护成本

系统上线后，日常维护的复杂性显著增加，尤其是在系统监控方面亟需解决的问题愈发突出。

时效性和准确性对于业务分析至关重要，输出错误的数据结果比不输出更加难以接受。这不仅会影响业务决策，还可能导致公司重大损失和系统信任危机。

在庞大的数据量和复杂的计算逻辑中，如何快速识别出异常数据或处理延迟始终是一个巨大的挑战。

传统的监控手段往往难以满足实时性要求，因此需要引入更智能的监控工具，通过对历史数据和趋势的分析，预测并识别问题。

技术架构演进

上线架构

看过2023年8月《ClickHouse 和 SeaTunnel 在京东科技的最佳实践》的同学应该还记得，上线之初架构选型如图所示：

在上线初期，使用Apache SeaTunnel框架服务成功解决了从无到有的全业务流程跑通问题。特别是通过文件挂载的方式，采用BuckLoad技术显著降低了数据同步对ClickHouse带来的CPU计算压力，确保了业务在资源使用上的充足性。

整体架构设计分为两个阶段，一阶段负责将Hive数据处理为需要的结构并通过SeaTunnel调用Spark和ClickHouse-local生成待挂载文件，同时推送到Oss上；

二阶段则根据ClickHouse集群的部署情况，动态挂载对应的数据文件并更新系统状态，同时计算同步准确率。

文件挂载的优势：通过SeaTunnel生成待挂载文件，ClickHouse系统能够快速获取存储在Oss上的数据文件。这种方式不仅前置了数据同步的计算压力，还减少了数据在同步过程中的延迟，提升了整体工作效率。

BuckLoad技术的应用：BuckLoad技术的引入有效地降低了对ClickHouse的CPU负载，使得系统在处理高并发请求时依然能够保持良好的性能，尽可能避免ClickHouse潜在并发查询劣势。

这一技术通过优化数据同步加载过程，减少了资源消耗，确保了业务查询时的流畅性。

低成本对象存储架构：结合SeaTunnel与Oss的低成本对象存储架构，系统能够暂存3天的数据文件。这一设计在初期问题较多、整体失败率较高的情况下，避免了全流程的重跑，节省了大量的时间和资源成本。

避免全流程重跑的策略：在面对数据处理失败和同步误差时，系统可以直接挂载已生成的存在于Oss上的文件，快速恢复数据处理。这种策略不仅提高了效率，还降低了因重跑而可能带来的数据不一致风险。

整体效率的提升：通过上述措施，整体工作效率得到了明显提升。团队能够更快速地响应业务需求，及时处理数据，同时降低了系统维护的复杂性。

架构迭代

随着系统上线后业务使用量的不断增加，需求场景变得愈加复杂，这对现有技术架构带来了巨大的挑战。

面对多样化的业务需求，原有的技术架构显得力不从心，难以满足日益增长的性能和灵活性要求。

举几个典型的需求案例

一对多同步： 为解决查询性能问题，针对大数据量表，进行了按需裁剪，形成多个小表，同步的时候，进行一对多推送。查询的时候，前端进行需求适配，实时选择对应的小表进行查询。

在多个目标表，甚至多个查询引擎之间进行数据同步时，一对多的需求尤为常见。如何高效、准确地将数据从一个源系统分发到多个目标系统，确保数据一致性和实时性，成为了技术架构必须解决的关键问题。为此架构上优化了早期一对一同步流程，在SeaTunnel生成文件的时候，适配了小表的结构和过滤条件，形成多个小表对应的文件组，相应的监控和准确性计算也同时完善。

关联offset推送：针对不同业务数据的关联性，技术架构需要支持offset的推送机制。这意味着在数据处理过程中，必须能够实现即时pin池管理和关联，以确保沉淀到ClickHouse库中的明细表带有对应的offset信息，前端查询时可以通过ClickHouse支持的bitmap语义计算函数，实时关联对应的标签、人群等数据。为此设计了对应的pin池hive表和实时pin池，在SeaTunnel生成文件前，就关联offset信息到对应的数据结构中。

每日数据回刷： 业务需求中常常需要对每日产生的历史变化数据进行回刷操作，比如退款、订单取消等等。这要求系统能够灵活处理历史数据的更新和重载、同步，确保数据的准确性和及时性，同时还需要避免对现有业务流程的干扰，降低每日或实时同步过程中，对主干流程的影响，这类需求是非常个性化的场景，每一个同步工具实现过程中都需要针对自身架构优化实现，很难有普适性的方案。由于洞察使用SeaTunnel分为两个阶段，一般来说越早处理掉系统变化，对整体系统修改影响越低，因此在每日同步流程吊起前，我们设计了动态触发条件，根据预先定义好的不同业务域同步条件，在当日满足同步流程要求时，自动匹配对应同步条件，吊起前15日、10日等不同回刷流程，最终实现了最低成本改动。

自定义表结构： 随着业务的多样化，固定的表结构往往无法满足低存储成本的要求，在业务发展初期，或者某一个业务模块，分析需求需要的字段数据都较少，并不需要全表推送，特别是一些大表，全表推送的存储成本和查询成本较高。

技术架构需要支持自定义按需推送的灵活配置，提升系统的低成本可扩展性。此需求，我们设计了Hive-SQL适配功能和ClickHouse自动建表功能，在业务门户提供字段选择功能，根据选择的字段控制建表和推送数据结构范围。

2024年经过多次架构升级，我们设计并实现了新版数据同步架构：

引入事件中心，采用SeaTunnel动作消息上报机制，解耦上下游系统，降低系统间的耦合度
集成业务系统接口，封装中台和数据系统接口为Service，离线数据推送打通建模工具，优先针对建模表进行推送、人群有更新时主动通知推送服务、约定Hudi表更新通知等
开发类信息查看，日志涵盖推送任务执行日志、接口调用日志，优先使用跳转
系统监控集成ClickHouse集群、定时任务、SeaTunnel任务封装
调参能力接入，例如推送任务排队、限速、修改并行度、SeaTunnel任务调并行度
适配京东内部权限和特殊合规要求，上线自动申请、自动赋权、审批流自动流转
优化文件生成流程，简化中间文件处理时间成本和步骤等

在使用SeaTunnel框架服务的过程中，上述复杂需求仅是我们所面临的很小一部分。我们在文件拉取、文件挂载和文件解压等环节进行了大量细致且自驱的工作，结合ClickHouse集群升级SSD磁盘，最终实现了推送同步性能的大幅提升，并趋于稳定。如下图同步耗时对比所示，架构升级之后，整体数据同步性能提升60%，耗时消峰效果显著。