实时关键业务场景快速增长,我们需要什么样的数据平台来支持?

实时关键业务场景快速增长,我们需要什么样的数据平台来支持?
2024年07月18日 19:17 爱分析ifenxi

引言

经过多年的数据基础设施建设,企业已经完成从“有数”到“用数”的过渡,数据驱动成为常态。进一步,面对激烈的市场竞争和快速变化的客户需求,如何提高“用数”效率,以实时或准实时的数据处理速度进行决策、开展服务以及优化运营,正成为企业获取竞争优势的关键,催生实时数据业务场景快速增长。

面对日益增长的实时数据业务场景,传统的实时数据集成解决方案如点到点实时同步、ESB企业总线、Kafka消息队列等均存在各种局限性,促使新一代实时数据集成解决方案应运而生。

本文将重点阐述实时数据业务场景的定义、增长驱动因素,并通过多种实时数据集成解决方案的对比,阐释新一代实时数据集成解决方案为什么代表着未来发展趋势。

01

实时数据业务场景的定义

实时数据业务场景指企业在经营过程中,对新数据进行实时传输、处理、分析、查询和响应的业务场景,支持实时决策和实时操作。其中实时指的是从数据产生端到消费端跨系统传输或处理过程实现毫秒或秒级延迟。

图1:实时数据业务场景分类示意图

按照消费端的数据处理模式,实时数据业务场景包含TP场景下的实时交互型业务场景和AP场景下的实时运营分析场景。

TP场景下的实时交互型业务场景

实时交互型业务场景指消费端的应用程序需要跨系统实时查询生产端系统信息的场景,如统一订单中心、实时风控、CDP平台等。这些场景是企业的关键任务,对于保障企业正常经营有决定性影响,一旦出现延迟或数据错误将导致严重的经营事故,因此对数据时效性和数据准确性要求极高。

需要强调的是,与传统基于Oracle数据库实现的TP场景不同,实时交互型业务场景往往涉及异构的数据源,需要解决源系统和目标系统之间跨系统的数据一致性,数据传输处理和集成等问题。而传统的OLTP场景虽然也强调实时响应,但在单一Oracle数据库中实现数据集成、完成业务的事务性操作以及保障数据一致性,其技术实现的路径和复杂度与实时交互型业务场景截然不同。

AP场景下的实时运营分析场景

实时运营分析场景需指融合业务最新数据和历史数据进行实时复杂分析的场景,如实时BI、实时数据分析、实时决策等,在客户体验改善、生产效率提升、个性化产品和服务推荐等方面发挥着重要作用。

表1:实时相关概念对比

02

内外部环境因素驱动实时数据业务场景快速增加

历史IT建设遗留的数据孤岛使跨系统数据集成成为数据利用常态,面向未来竞争的数据能力建设需求驱动跨系统的实时数据业务场景快速增加。

2.1历史IT建设形成数据孤岛,数据集成成企业用数必要步骤

企业在历史的IT建设过程中,为满足各业务管理需求,搭建起诸如CRM、ERP、财务、人力、供应链等多种系统。由于建设的时期较早,这些系统多为应用程序和数据库紧密耦合的单体式架构,系统相互之间各自独立、无法联通,形成企业数据孤岛。据不完全统计,大型企业的业务系统平均数量为315套,中小型企业的业务系统数量为52套。数据孤岛使得跨系统的数据消费成为常态,数据集成成为企业用数首先要解决的问题。

2.2市场变化、经营效率、客户体验共同催生广泛的TP和AP实时场景

外部市场和客户变化,以及内部企业对经营效率、客户体验的提升诉求,共同驱动企业实时数据业务场景快速增加。

一方面,企业业务模式创新以及运营秩序的维系驱动实时交互型业务场景快速增加。如高速发展中的企业往往通过创新业务形态增加营收。企业在拓展新业务形态时必然带来跨系统的交互型事务操作场景。某知识付费平台在核心课程基础上增加读书、听书等新业态,由于用户的会员界面中需要实时呈现课程、读书、听书等业态权益,该平台需要为新业态开发实时交互数据应用。

对于存量竞争下开展精益管理的企业,整合企业多系统内的商品、客户、库存等核心信息,持续开发交互式业务应用,对于维持业务正常运转非常重要。如对于多品牌大型零售企业,统一库存查询能实时展示商品数量,满足企业内外部用户即时商品查询需求,保障一线员工正常开展销售和服务活动,避免因商品信息错误丢失商机。

另一方面,对整体运营效率的持续提升和客户体验的持续改善推动企业实时运营分析场景快速增加。

以金融行业信用卡交易的反欺诈场景为例,在信用卡发生交易的第一时间,银行会融合近期的交易时间、地理位置、交易金额等多维信息,实时监控交易行为,一旦识别出异常模式立即触发警报,在秒级内中止交易,保证交易安全性。又如制造业生产线中的实时监控能对产品质量进行实时监测,对于生产中的异常状态进行及时提醒甚至停止产线,能提升生产效率、降低潜在损失。

03

传统数据集成解决方案弊端渐显,TapData定义新一代实时数据集成平台

3.1 实时数据业务解决方案的技术难点

图2:实时数据业务解决方案的技术难点

面对以上快速增长的TP、AP实时数据业务场景,爱分析认为一个完善的实时数据解决方案应实现跨系统的实时数据集成,并解决两个技术难点和一个开发运维难点:

  • 技术难点1:保障跨系统数据集成过程中的事务一致性。由于实时数据集成的源系统和目标系统都可能涉及数据库表数据和消息队列流数据,因此解决方案应同时具备表到流以及流到表的转换技术。
  • 技术难点2:支持实时数据的预计算。预计算已经是公认的有效缩短计算时长、提高计算效率的优化方式,对实时数据进行预计算才能保证实时运营分析场景的高时效性。实时运营分析的预计算的困难在于如何在实时数据采集、在数据每秒数百数千次更新的情况下,基于原始数据构建新的业务模型,完成实时预计算过程。
  • 开发运维难点:解决方案应具有低门槛、简单易运维的特点。保证开发运维工作和难度不随企业实时数据业务场景的增加而增加。

3.2传统数据集成解决方案的局限性

目前市场中实现数据集成的方式包括批量集成和实时集成。典型的批量集成解决方案如大数据平台、数据中台,虽然解决了数据孤岛问题,但时效性难以满足实时数据业务场景需求,不赘述。本文重点讨论实时数据集成方案。

当前主流的实时数据集成方案包括点到点数据同步、ESB企业总线和Kafka消息队列,这三种方案代表了实时数据集成方案的迭代历程,但在解决实时业务场景技术难点、控制运维成本方面均存在不同程度的局限性。

相较主流实时数据集成方案,爱分析观察到,市场中已经出现更为前沿的实时数据集成解决方案,由钛铂数据自主研发的端到端实时数据同步解决方案——实时数据平台(TapData Live Data Platform,简称 TapData LDP)不仅能同时解决跨系统数据一致性、实时预计算等问题,其低代码简单易用、中央化数据资产复用的特征更是受到市场广泛认可,代表着新一代实时数据平台演进方向。

表2:点到点数据同步、ESB企业总线、Kafka消息队列以及TapData LDP四种解决方案对比

点到点实时数据同步

点到点实时数据同步是最简单、直接的实时数据集成方式,可实现数据一对一的从源系统到目标系统的数据同步。但扩展性弱,开发运维成本高,每增加一个系统需要配置新的连接,系统之间强依赖紧耦合。随着系统数量的增加,数据链路的数量和复杂性呈指数增长,且缺乏系统管理中心,导致系统维护和运维非常困难。

在多源数据输入时,点到点数据同步存在处理数据冲突和一致性问题,无预计算能力。

ESB企业服务总线

ESB企业服务总线提供了一种中心化的、松耦合的软件架构模式,支持不同应用程序之间的实时数据集成和交换,具备高度的灵活性和可扩展性。ESB支持复杂的事务管理和协调,虽然提供了集中化管理工具对流程和服务健康进行实时监测,但整体的学习成本高昂,要求开发人员具备极强的专业性,对消息路由、转换、事务管理、安全性、以及不同系统之间的兼容、性能调优等多方面进行配置和管理。

ESB中心化的处理架构在大规模的并发请求时性能受限,延迟较高,且商业化成本高昂,在互联网大数据时代逐渐被淘汰。

Kafka消息队列

Kafka是一个开源免费的分布式消息队列系统,能够提供高吞吐量和低延迟的实时数据传输和集成,并且其本身具有高可用性、可扩展性、高效查询、高并发写入、支持事件驱动架构等特征,是企业构建实时数据管道的最常用的工具。

Kafka引进成本低,但对开发人员专业能力要求非常高,后续的开发运维的复杂性和成本将随企业实时应用数量的增加而显著增长。一方面,Kafka不支持分布式事务,分布式架构下,企业需要针对网络延迟、节点故障、数据复制以及生产者和消费行为等等因素设计容错机制。另一方面,从实时数据全链路来看,Kafka仅是一个中间件,除Kafka外,上游业务系统对Kafka的事件推送,下游数据消费者对Kafka的事件提取等工作,仍需要企业承担。此外,游业务系统中数据属性变化、下游数据应用的差异化数据需求,都将带来从业务系统到消费应用端到端实时链路的重新开发。

3.3 新一代实时数据集成解决方案:TapData LDP

TapData成立于2019年,由前 MongoDB 大中华区首席架构师、MongoDB 中文社区主席唐建法创建,其核心团队对各类数据库内存、事务实现、日志格式等底层技术实现具备丰富经验。

TapData成立的初衷是希望为企业使用新鲜数据提供一个简便易用的工具,通过“水管”(Tap)一样的基础架构将企业的数据连接起来,提供新鲜数据即用即取的数据服务。经过多年研发,2022年,TapData率先在业内推出可解决数据孤岛的、同时支持TP和AP实时数据业务场景的实时数据交换平台TapData LDP。TapData LDP是一个开源的企业级实时数据平台,具有多架构支持、低代码开发、全链路实时等特点。

图3:TapData LDP平台架构和场景示意图

TapData LDP架构由数据采集层、流数据处理层、数据存储层、数据服务层构成。

  • 数据采集层:LDP支持丰富的数据源类型,包括主流的开源数据库、国产信创、离线文件、业务应用API、湖仓等。通过CDC实时采集源系统数据变化,进入流处理框架。
  • 流数据处理层:流处理框架在实时传输进程中实现流数据处理,包括数据计算、建模和转换。
  • 数据存储层:异构数据源的核心数据同步至统一的平台缓存层存储,形成能够复用的统一的数据模型,建立统一的数据标准,支持下游按需取用。
  • 服务层:服务层支持 Pull 和 Push两种服务模式,支持低代码发布API。也支持REVERSE ETL反向把经过整理的数据推送给下游。

TapData LDP具备领先的实时技术,不仅解决了实时数据业务场景的两个技术难点,更能支持多种实时数据业务场景。同时TapData LDP兼具低门槛开发、简易运维的特征,能显著降低开发运维成本。

1)技术领先,能支持多种实时数据业务场景

TapData可灵活支持多种实时数据业务场景,适应企业用户从简单实时同步需求到复杂实时数据分析、实时数据服务调用等复杂需求的扩增。TapData支持的实时数据业务场景包括:

场景一:实时采集CDC机制实现点对点的实时数据同步

这是最简单的实时数据同步场景。CDC机制能对数据库日志文件进行解析,将数据变化标准化成事件流后进入流处理框架加工,加工后的数据通过目标连接器写入目标数据库或应用。整体CDC机制能实现源系统到目标系统的实时复制、实时同步。在这一过程中,TapData既支持将源系统的表数据变成流以Push模式推送给Kafka或是对接应用业务流程,适应时效性要求高的TP型场景,也支持将流数据转化成表,推送给各种数据库供AP场景使用。

场景二:实时数据处理+中央化存储支撑实现实时运营分析场景

针对企业用户更高级、更复杂的实时运营分析场景,在采集源系统数据进入流处理模块后,TapData LDP的流处理模块以通过物化视图的方式开展多表合并、数据拆分、字段增减、共享挖掘等高级数据处理操作,可无代码完成实时数据的预处理。计算后的结果存储在数据仓库中,供实时BI、实时驾驶舱、实时决策等场景以Pull数据服务模式使用。

场景三:实时数据处理+中央化存储+数据服务支撑实现实时交互型业务场景

针对Web、手机端实时交互型应用,如客户权益查询、订单查询等场景,TapData在处理模块完成预计算后支持将数据存储在分布式数据库MongoDB中,形成轻量化的实时数据中台,为下游交互型应用提供实时数据服务,实现数据查询的实时更新。

2)简单易用、门槛低,显著降低开发运维成本

TapData LDP支持低门槛完成实时数据全链路开发,开发人员可将数据链路的构建耗时从以周为单位缩短到分钟级。对于实时数据的采集,在LDP CDC机制下,用户只需提供源库账号,LDP即能无代码完成数据采集。针对数据加工环节数据同步任务的编排与设置,TapData LDP 提供零代码界面,用户可通过拖拽完成任务编排,极大降低了同步任务流定义的复杂度。在数据服务环节,LDP支持无代码快速发布API。

在运维中,TapData提供可视化监控管理,能显著减轻运维人员任务负担。

04

某银行通过TapData 升级实时数据交换平台

TapData已经在业内积累了丰富的服务案例,包括中国移动、中国联通、南方电网、中国一汽、中芯国际、周生生、富邦银行等数十家行业标杆企业,实时数据交换平台的变革性价值广受企业认同。

某银行针对业务数据库种类多、数据量级大的特点,基于开源的云原生的Kafka解决方案自主研发了实时数据同步系统,业务侧的实时数据应用均采用容器技术封装、运行,并自研了Kafka管控平台,对集群进行指标监控和运维。目前该银行主要面临三个挑战:

实现实时数据集中缓存,支持实时运营分析场景:该银行实时运营监控、客户360视图等场景对实时数据查询需求增加,原系统在业务进行实时数据查询时以点到点的形式实现,数据链路需重复开发,数据资产难以复用。为提高数据利用效率,该银行希望实现实时数据集中缓存,为下游提供表查询服务。

开发维护成本高:由于云原生实时数据同步系统完全基于自主开发,所有实时数据同步链路的开发、维护、监控、运维都需要IT团队完成,随着下游业务侧实时数据应用数量的快速增长,开发运维的难度和成本均快速增长,且开发周期长难以满足业务需求,该银行需要寻求更高效、更易维护的解决方案进行替代。

需符合信创要求:信创背景下,银行业数据库国产化替换进度加快,已经进入核心业务数据库替换阶段。该银行在对传统和互联网核心业务数据库替换时,由于开源的实时数据同步方案对国产化数据库不支持,影响该银行核心系统国产化改造进程。

在以上背景下,考虑到对云原生架构的支持、对国产数据库的支持以及易用性等多方面因素,该银行最终与TapData达成合作,采用本地部署 “TapData Live Data Platform”方案对数据采集、消息同步到Kafka两部分架构进行替换,下游消费侧保持不动。替换后的实时数据同步系统具有以下特点:

实现实时数据中央化存储:TapData提供流处理框架,对实时数据预计算后进行存储,形成统一的实时数据资产,以实时表的形式支持下游业务系统查询。大幅度减少了实时数据管道建设的数量

简化数据开发与运维:TapData提供零代码开发界面,开发人员可通过拖拉拽的方式快速构建实时链路,以及通过可视化运维界面,实时监控数据任务状态,以及进行实时数据同步验证。

深度集成:TapData 与银行系统深度集成,包括用户登录、运维监控、页面操作的接口对接等,无论是业务端用户还是开发运维人员均能在既有系统中通过调用API 完成实时数据同步,无需改变操作逻辑和习惯。

支持信创:TapData可支持丰富的国产数据库,可满足银行核心系统的国产化替换需求。

可复用性:一套基础实时数据平台,支持多个实时数据业务模式:实时同步与复制,实时分析数仓,实时数据服务等

该银行更新后的实时数据同步系统,其简易的使用体验使得实时数据链路的开发运维不再依赖专业开发人员,释放人力,开发人员能专注于业务赋能。更新后的实时数据链路开发效率也得到大幅提升,开发周期从1-2周缩短为1-2天,能敏捷支持实时数据业务应用需求。此外,实时数据同步系统对国产数据库的支持也将推动该银行完成核心业务系统的国产替代。

财经自媒体联盟更多自媒体作者

新浪首页 语音播报 相关新闻 返回顶部