作者：宁诚、陈伟强 京东科技架构师
技术背景与挑战
技术背景
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%，耗时消峰效果显著。
可以说，我们基于SeaTunnel的数据集成技术架构的升级与业务需求是一个相辅相成、互相完善的过程。在这个过程中，我们探索出了适用于各类型场景的SeaTunnel数据集成技术架构设计和演进的新思路、新方法。
共同成长
使用SeaTunnel的过程不仅是技术实施的过程，更是一个深入学习和与SeaTunnel共同成长的旅程。复杂需求的实现，我们积累了大量经验，解决了很多系统层面的问题，也回馈了社区。
内存分配问题：问题现象非常明显，任务运行异常多，每天值班需要诊断、排错、重试，定时任务作业运行缓慢，YARN报错137、143问题，Keeper偶发异常，影响整个集群等
在SeaTunnel阶段内存模型如下：
137+143问题是由于Spark参数问题，错误的参数设置导致进程外内存预留不足，同时Seatunnel代码问题，16个ClickHouse并行很容易超过YARN限制（极限40G）
在问题解决后，效果非常明显，24年Q3我们实现了9点前作业完成率超过95%，双11期间更是在数据量5倍同时0延迟完成洞察系统数据同步工作。
后续规划
架构整合
在大数据+智能化战略方向，现有洞察系统高效支撑了业务部门复杂需求场景，得到了管理层高度认可，我们计划整合科技集团内部数据集成工具，以SeaTunnel为基础，整合离线、准实时、实时等多场景，简化现有数据集成架构。
统一后的数据集成工具会支撑更多更加复杂的业务需求场景，继续服务于京东科技场数据应用
OLAP技术突破-多计算引擎+存算分离
通过对ClickHouse集群在不同应用场景中的深入分析，我们认识到，在敏感型查询性能场景中，数据量的增加和产品设计的限制是主要挑战。
而在非查询性能敏感场景中，设计统一的数据应用服务技术底座，结合多计算引擎和存算分离的策略，将是实现技术突破的关键。这不仅能够提升系统性能，还能有效降低开发和维护成本，为未来的业务发展提供坚实的基础。
结语
总的来说，使用Apache SeaTunnel的过程是一个不断学习、成长和贡献的过程。我们不仅提升了自身的技术能力，也为SeaTunnel社区的发展贡献了自己的力量。
这种互利共赢的关系将继续推动我们在数据集成领域复杂场景的探索与创新。
本文由 白鲸开源科技 提供发布支持！