作者简介
空歌白石,携程资深研发经理,关注性能和效率提升、架构优化。
团队热招岗位:后端开发
一、背景与挑战
二、原则与目标
三、关键技术实践
3.1 数据一致性
3.2 数据时效性
3.3 系统健壮性
3.4 消费流程优化
3.5 统一数据治理
四、技术架构概览
五、成效
六、未来计划
随着携程国际机票业务的快速发展与全球化战略的深入推进,需要使用的数据种类以及对应的复杂度也随之显著增加。这一增长趋势不仅带来了数据管理的挑战,同样对数据准确性和实时性提出了更高的要求。
接下来,我们从生产者和消费者两个角度具体看下有哪些挑战。
生产者视角下的挑战:对于基础数据的生产者,每一种数据类型都有其独特的业务逻辑,涵盖数据的获取、处理、存储和匹配等环节。数据更新周期长,业务复杂性高,和基础数据相关的应用就达到了几十个,维护成本不断攀升。同时,还存在着数据访问效率低、上云过程复杂、数据回滚困难以及无法应对大规模机器重启或数据刷新等问题。
消费者视角下的挑战:对于基础数据的消费者,每一个应用都或多或少依赖于基础数据。任何一种数据的误差都可能引发广泛的线上问题,而且问题的发现往往滞后,导致生产问题被不断放大。此外,还存在着业务开发接入复杂、测试环境不稳定、服务启动缓慢、垃圾回收频繁、上云过程繁琐以及数据不一致等问题。
二、原则与目标
面对上述问题,构建一套中台化系统是其中一个解决方案,我们希望实现数据资源的高效整合,消除数据孤岛,提高数据处理效率,确保数据质量标准。在系统设计的初期阶段,我们首先从数据生产者和消费者角度出发确立了一系列核心目标:
数据生产者角度:
数据一致性:确保数据在各个环节保持一致性,避免偏差。
数据时效性:保障数据的实时更新,满足业务对数据的即时性需求。
系统健壮性:构建稳定可靠的系统架构,以应对各种运行环境和负载条件。
- 数据可追溯性:实现数据的全流程追踪,便于问题定位和历史分析。
- 数据可回滚性:提供数据版本控制,允许在出现问题时快速回退至稳定状态。
- 监控完善性:建立全面的监控体系,实时监控数据流和系统状态。
降低成本:通过优化资源配置,降低机器和存储的成本;简化系统维护流程,减少人力和时间的投入。
数据消费者角度:
优化消费流程:简化数据消费流程,提高数据处理的便捷性和效率。
- 接入方式简化:提供直观易用的接入方式,降低数据使用的门槛。
- 统一数据模型:建立统一的数据模型,确保数据的一致性和可理解性。
解决环境问题:解决不同运行环境下的数据同步的问题。
- 测试环境完善:提供完善的测试环境,确保数据的准确性和稳定性。
- 云服务便捷性:优化云服务接入,提高数据服务的灵活性和可扩展性。
提升服务性能:通过技术优化,提升服务的响应速度和处理能力。
- 启动耗时降低:减少服务启动时间,提高系统的快速响应能力。
- 减少GC次数:优化内存管理,减少因数据更新引起的垃圾回收(GC)操作,提升系统性能。
三、关键技术实践
在基础数据中台化建设的实践过程中,遇到了一系列的问题,本章节将介绍一些关键的技术实践。
3.1 数据一致性
3.1.1 版本控制
同一集群下不同的机器在更新缓存时由于调度时间不一致,会导致不同机器在同一时间使用的数据不一致,为解决此问题,我们使用数据版本控制策略来解决此问题。每当数据发生变更,我们便认定一个新的数据版本已经诞生。这个新版本可以是包含了变更和未变更数据的完整副本(下文简称为"全量数据"),也可以是仅包含变更内容的更新(以下简称为"增量数据")。不论是全量数据还是增量数据,我们都会将数据记录在BLOB(Binary Large Object)文件中,BLOB文件将作为数据传输的媒介。
实施数据版本控制后,我们能够收获以下收益:
版本追踪:确保每一次数据更新都有迹可循,并且在新版本出现问题时能够迅速恢复到之前的版本。
数据一致性:保证所有数据消费者能访问到相同版本的数据,从而减少因数据版本不一致而引发的问题。
容错与恢复:能够快速识别出问题数据,并利用多种通知机制,促使产品或开发团队及时介入,解决问题。
性能监控:基于数据版本,构建性能监控体系,以评估数据传输和处理的效率。
数据安全:在数据传输和存储过程中,通过加密和访问控制机制,确保数据安全,防止未授权访问。
3.1.2 去中心化
在业界,如果某个服务想要消费基础数据时,主流解决方案是采用直连数据库或调用应用程序接口的方式,如下图1和图2,这两者均属于C/S架构。C/S架构虽被广泛采用,却面临着如数据库承载压力大、数据一致性难以保障、系统扩展性不足、开发与集成过程复杂、硬件成本高昂、缓存穿透、中心服务的读压力,以及难以应对流量高峰等问题。
图1
图2
为了克服以上问题,我们引入了P2P架构(Peer-to-Peer Architecture)。与C/S架构相比,P2P架构实现了去中心化。在P2P网络中,每个节点都具备客户端和服务器的双重身份,能够直接与其他节点进行通信和数据交换,无需依赖中央服务器。同时,P2P架构下的数据查询耗时并不会因为客户端数量的增加而线性增长。图3直观地展示了C/S架构与P2P架构的本质区别。
图3
基于前文提到的BLOB文件版本控制机制,我们选择了BitTorrent协议作为P2P网络中的文件共享与分发标准。BitTorrent以其高效的数据传输能力,特别适用于大规模数据的快速分发,具体架构如图4,客户端可以根据实际需求控制是否要加入Peer网络,如图4中的红色机器就仅仅下载数据,并不分享给其他peer。
图4
3.1.3 数据组合策略优化
在业务实践中,我们有时候会需要处理多种基础数据的组合场景,比如想要在消费国家数据时一同消费国家所在大洲数据,当组合中的数据版本出现不一致时,会导致数据不准确。
为应对这一挑战,我们采取的方法是通过业务规则,将所有相关联的组合数据整合到单一的torrent文件中,消费方可以一次性下载到所有关联数据。这种整合方式的优势在于,它允许消费方一次性获取整个数据集合,而不需要分别从不同来源或版本中收集和协调数据。通过这种方式,我们不仅简化了数据获取过程,而且更重要的是确保了数据的一致性和准确性。
3.1.4 单点数据生成策略
集群内不同的机器间隔几秒钟查询同一数据库,查询结果便可能会有所不同,为保证消费方数据一致性,我们在生成全量和增量数据时采取了单点数据加载模式,如图5。仅有单一的机器负责从数据库中查询数据,这种设计一方面显著降低了数据库的读取压力,其效果相当于将压力分散至消费方机器数量的1/n(n代表消费方机器的总数),另一方面结合版本控制策略,在同一时间内中台系统中仅仅有一个有效的版本数据可以被使用。
图5
此外,不同种类的数据更新频率各异,这通常由具体的业务需求所决定。因此,中台系统提供了自定义数据生成配置的功能,这种灵活性的好处在于:
减少不必要的数据加载:通过精确控制数据生成的频率和时机,避免了资源的浪费。
降低客户端缓存刷新压力:减少了因频繁数据更新导致的客户端垃圾回收(GC)操作,从而提高了客户端的性能。
缓解网络带宽压力:通过优化数据生成和传输策略,减轻了整个网络的带宽负担,确保了数据传输的高效性。
3.2 数据时效性
3.2.1 推拉机制
为确保数据生产至消费的全流程时效性,防止数据更新滞后对业务造成损失,我们在架构设计中引入了推拉接合模式。前序系统完成数据处理后,即通过消息中间件向后续系统发出通知,这一连贯流程在各子系统中依次触发,直至数据被消费。
为提高流程可靠性,我们引入了可配置的基于定时任务中间件的拉状态逻辑,确保了任何环节的延迟或异常都能被及时补偿。
图6
3.2.2 数据云端迁移
随着携程国际业务的不断拓展,我们的系统架构正逐步向混合云模式转型。传统的基础数据上云是复制数据库到云端,虽然可行,但往往会带来成本上升和数据复制延迟等问题。为应对这些挑战,我们将Blob文件分发到不同的Region,避免了对昂贵数据库实例的依赖,在保证数据时效性的前提下成本降低98%以上,榆次同时使用此架构消费方在上云过程中可以做到无缝迁移。具体架构如图7。
图7
3.3 系统健壮性
3.3.1 数据校验和拦截
在数据的生命周期中,无论是业务维护的数据,还是由外部数据提供商提供的数据,数据错误总是一个不可忽视的问题。这些错误表现为非法字符、数据缺失、数据重复等。为有效解决此问题,我们开发了一套数据校验机制,针对数据的每个字段执行严格的合规性检查。系统一旦监测到异常数据,将立即通过TripPal(携程自研的IM系统)、电子邮件、短信等多种通信渠道,向数据负责人发出警报,这样可以迅速响应并处理问题。
在问题未解决前,系统会自动暂停出问题数据的更新,防止错误数据的扩散。此外,为了进一步提升数据校验的准确性,我们结合了统计学算法和人工智能(AI)预测模型,对数据变化进行分析和智能判断。具体的架构如图8。
图8
3.3.2 数据回滚
在生产环境中,面对突发的系统故障,实施回滚操作是最迅速且有效的应对策略。中台系统为此提供了一套数据回滚功能,将回滚版本的数据视为一个完全正常的版本,通过中台的Portal界面,用户可以依据时间戳追溯并查询到所需的历史数据版本。其中,整个回滚过程无需对数据库进行任何数据层面的修改,这一点与依赖于二进制日志(binlog)的回滚方法相比,提高了效率和安全性。如图9。
图9
3.4 消费流程优化
3.4 1 统一数据模型
数据模型会出现新增、修改和删除字段的场景,通常我们会通过编码的方式实现,不仅过程繁琐,而且随着时间推移,会显著增加系统的维护成本。为了降低消费方消费数据的复杂度,需要支持任意数据模型的自动化生产和消费。我们通过脚本化手段实现自动化构建(build)和部署(deploy)jar包,从而简化流程。具体的流程如图10。
图10
3.4.2 简化接入方式
当需要消费某个数据时,引入通过图10流程生成的独立model包,通过以下代码即可获取全量数据集或者按条件查询的数据集。
// 引入客户端
@DataResource
private CityClient cityClient;
// 全量查询
List<City> list = cityClient.queryList();
// 条件查询
List<City> list = cityClient.queryList(cityCode);
在实际的工作中,开发团队和产品团队常常面临一个共同的挑战:如何在种类繁多的基础数据中找到目前生产上实际使用的基础数据?一般会通过口口相传或维护共享文档的方式来解决,但是这种方法不仅效率低,而且容易因人为失误或信息更新不及时导致生产问题,为此,数据中台实现了一个统一的模型入口,简化了数据和模型的搜索和引用过程。用户可以在Portal中按照数据库名、数据表名、接口名等检索条件轻松搜索所需的数据类型,如果存在,可以直接引用;如果不存在,可以根据具体的业务需求新增。
对于新的业务接入中台,我们也进行了流程的优化。优化后,接入中台只需调整数据源,无需进行额外的开发工作。这一改进显著减少了业务接入的复杂性和工作量,最小化了接入流程。与直接连接数据库或调用应用程序接口的方式相比,中台系统在数据接入效率上实现了90%以上的提升。
四、技术架构概览
在前文所述的基础上,本节从宏观的系统架构视角,阐述携程国际机票基础数据中台化建设的关键技术实现。我们的系统精心设计为若干个互相协作的核心模块,每个模块承担着特定的职责,共同构成了数据处理和分发的中台化平台。
1)DataSource 模块:作为数据流的起点,此模块负责数据的初始写入和确保数据一致性。它通过定时任务或消息通知机制触发数据操作流程。
2)BlobGenerator 模块:专注于数据的生产过程,提供全面的服务,包括数据校验、BLOB文件生成、版本控制以及回滚操作的拦截。
3)BlobService 模块:作为数据分发的核心,处理来自DataClient的数据请求,充当BlobGenerator与DataClient之间的桥梁,确保数据流畅、高效地传递。
4)DataClient 模块:负责数据的消费端,提供包括BitTorrent下载、缓存管理、以及支持精确查询等多种功能,满足不同场景下的数据使用需求。
5)DataQuery 模块:为那些无法通过BitTorrent下载方式获取数据的消费者提供了API查询接口,支持全量数据输出、条件筛选输出以及逻辑计算等高级功能。
6)Dispatcher 模块:作为系统的调度协调中心,确保DataSource、BlobGenerator、BlobService等模块的任务有序执行,保障整个数据处理流程的顺畅和同步。
通过这些模块的紧密协作,我们的技术架构不仅提升了数据处理的效率和准确性,还增强了系统的可扩展性和可维护性。
图11
五、成效
数据中台实现了从数据生成到消费的全生命周期覆盖。系统化的数据治理举措提升了数据系统在治理、成本控制、安全性和运营效率方面的性能。
数据生产者角度:我们对分散的业务流程进行了梳理和优化,根据优先级分批整合至中台。在这一过程中,我们不仅重构了业务流程,还通过重写和优化,挖掘并解决了多个之前未被发现的问题。数据分发的效率实现了质的飞跃,平均分发时间降至23秒,对于小规模数据,我们更是实现了5秒内的端到端快速传输,极大提升了数据的实时性和新鲜度;整体服务器成本降低了95%以上;系统的维护成本降低66%。
数据消费者角度:新数据源的接入效率提升了90%,上云过程无需进行特殊改造,加快了研发进度,提高了开发效率。解决不同运行环境下的数据同步的问题,减少了对生产环境的依赖。优化了调度策略,减少了98%以上的无效调度任务,降低了GC的频率。
六、未来计划
国际机票数据中台在上线体现了一些在研发效能、数据治理、性能优化、业务提升、降低成本等方面优势,未来我们计划从以下几个关键方面对数据中台进行深入迭代和优化:
1)自动化:进一步提升数据处理流程的自动化程度,减少人工干预,提高整体效率,特别会利用大语言模型等技术进行数据校验以及,增强数据准确性。
2)稳定性:加强系统的稳定性,确保数据中台在高并发和大数据量处理场景下的可靠性。
3)健壮性:构建更加健壮的系统架构,提高系统对异常情况的容错能力和自我恢复能力。
4)时效性:优化数据更新和分发机制,确保数据的实时性和时效性。
5)可视化:通过可视化技术,直观展示数据流动和处理过程,提高数据可读性和易用性。
- 更友好的Portal界面:设计和实现更加人性化的Portal界面,提升用户体验,简化用户操作。
- 处理流程可视化:实现数据处理流程的可视化展示,使用户能够清晰地追踪数据处理的每个环节。