Tapdata 技术博客
Tapdata 技术博客

如何高效整合分散数据,构建统一的实时数据平台?

2024-07-05 16:13 TapData

主题网络研讨会上,TapData 创始人兼 CEO 唐建法(TJ)与在场嘉宾及观众共同探讨了实时数据平台的建设与应用。以下为本次分享的核心内容(>>>完整视频回放,指路 TapData 视频号观看)

数据孤岛一直是企业数字化历程的瓶颈,面临信息缺漏、业务流程难以优化、业务创新备受阻碍几大难题,传统数据平台无法支撑企业数据的按需按时使用,导致多交互场景完全无法支持。本文从实时数据技术与实际案例展开说明,探究为企业关键业务提供实时数据支撑的高效技术。

为企业使用数据提供方便易用的工具,随时简单用到新鲜数据是团队的愿景,我们希望把企业的数据用水管连接起来,变成基础架构,想用的时候数据就能过来。我们的使命也是解决企业数据孤岛问题。

从统计来看,大型企业平均业务系统有 315 套,中型企业平均 52 套。最近十几年,有很多企业在做数字化举措,涉及到洞察,对业务、客户、生产过程的理解,提高效率。近几年, AI 赛道火热,大家通过新技术为企业赋能,提高竞争力,但意识到离不开企业核心的数据资产,而这些数据目前都存在,二三十年前设计的架构。单体式架构封装在孤岛式的系统之内,导致获取数据困难,这对新的业务创新、洞察带来非常大的挑战。

01.jpg

各类数据平台是目前主流的解决方案,从 20 年前的数据仓库到 10 年前的数据湖,最近五、六年的数据中台,都是比较常见的、主流的方案,能够把企业各个业务系统的数据,采集放到中央化的分布式存储里面,在上面做数据分析计算,为洞察型业务分析提供能力。

1.jpg

其中的核心点是把数据从各个源系统中采集过来,进行加工处理,形成模型。核心技术是定时采集和批量处理。数据中台为什么不能做到很好的业务支撑。一是组织架构的问题,二是技术工具的不匹配度。数据中台号称支撑业务,但它采用了市面上常规的批量业务或定时采集能力,导致数据并不新鲜,无法为实时要求较高的业务场景,比如实时BI、实时Dashboard,或是交互式、跟客户、状态、订单相关的场景就不能起到支持作用。

什么类型的业务是实时业务场景,跟传统的业务系统有什么区别。我们说的业务,涉及到已有系统之外,利用企业的数据做新的事情,比如说实时驾驶舱等都在企业内常见的,便于让管理层第一时间了解企业情况。实时数据的获取和使用对此非常重要。

另一个典型场景是金融反欺诈,常见的信用卡,比如获取贷款,或刷信用卡。现在在金融行业,当一笔钱刷下去,会马上调取该卡号发生了什么交易,时间、地理区域,当发现不正常现象,马上停止交易,这就是实时数据引导的支持反欺诈行为的业务场景。

在产线上当生产设备出现问题时,若不及时发现,会导致今日生产都是瑕疵品。如果有实时的预警,则可以马上停止,降低损失。

在服务、金融、保险等行业,以前的客户画像是静态的,现在要求知道客户当下在做什么?下过什么类型的订单?对什么产品感兴趣?这样能增强客户的消费体验,同时提高对客户的实时数据进行采集的要求。

2.jpg

以上场景都需要数据的产生和使用,一个是源头,另一个是在新的场景使用,不是在源系统上做,要在新的地方做新业务,问题难点在于怎样在不改变运行多年系统的基础上做创新,涉及到数据要从已有的业务系统中实时传输到新库里,客户交互业务,要确保数据是准确的、一致的。但是因为异构分库是两套系统,在没有数据库事务的保证基础上达到数据准确是非常困难的事。新业务使用的模型要通过预计算的方式才能真正有效。这涉及到对数据在变化、采集时,实时地把它建成想要的业务模型。这两项技术在近几年都在尝试解决,但还没有前沿的解决方案,因为技术上确实比较困难。

对于实时业务场景的常见方案能否解决这些问题,几种主流实时数据流通企业级解决方案。

3.jpg

1、数据点到点的同步,告诉取数系统,无论是 ERP、CRM 也好,从源头打通端口,通过工具抓取数据。

2、通过企业总线链接所有系统。

3、基于 MQ 消息队列架构。

列举几种架构的特点。第一种点到点是最传统的,特点在于最简单直接,容易理解、实施。不足点在于重复劳动,往往一个业务需要 10 - 20 条链路,且链路都是临时拉的,没人管理它就会断裂,出了问题后也无法追溯源头,会引起非常多的管理问题,且存在相互依赖,会变得混乱——我们称为像意大利面情况——这在点到点集成中非常常见,特别是对大型企业来说,这是它比较突出的缺点。

ESB 企业总线是中央化架构,跟点对点区别在于可复用,企业所有数据集中到 Hub 上,所有人对接的链路条数跟系统数量是线性关系。线路数量会比较干净、清晰、合理。而且可在基础上按照统一标准的 API 接口、规范接口后不断将新业务持续接入。听上去很理想,但这套解决方案在最近十来年逐渐地被弃用了。有几大问题,一是 SOAP/ XML 的接口方式,开发、对接成本非常大,因为它非常繁琐,机制非常细致,导致会直接影响性能。在互联网时代还没爆发时还在使用。但在数据量爆发后,完全没法跟上时代,这些原因导致了它慢慢退场。

4.jpg

最近几年比较流行的是 Message Queue 方式, Kafka 是主流代表,特点是新一代的分布式架构,解决了性能问题。另一个非常重要的原因是开源,因为引入成本较低,在开始尝试时,不需要额外成本。弊端在于对代码对接要求比较高,架构维护成本高。

在了解到企业客户的痛点后,第一个出发点是简单易用,核心关键要让数据像在水管里流动一样,在这个基础之上,关键考虑希望用户容易使用,开源实时数据平台特点是具有多架构,支持低代码开发。技术架构所有的能力,都是围绕着这个链路开展。

平台多架构只是简单的场景,先做点对点的实时的数据流通。当进一步意识到更多的需求时。我们提供一个中央化的架构,叫实时数据服务。通过该方式把数据中央化,再用 API 的方式给到下游业务,另外一种场景就是用来做数仓的准备、做分析、做报表。分析场景里的实时分析是我们的特别关注,出发点是解决关键型的业务场景。

5.jpg

上图为 TapData 架构。首先最下层是企业已有的业务系统,左边是这些数据库,其中包括数据流。也有一些数据来自于业务系统,没法直接从数据层面对接,但会提供API,这些都是企业已有的数据源的存在。

第一个出发点是提供流式采集模块,基于 CDC 机制,核心是流包表或者表包流,把数据库的表转化成流,记录了源端不断发生的事件。如增加、修改、删除、更新状态,我们把它转化成流的事件,转化成流标准化,可以通过平台里面的复制模块,直接推送到下游的各实时数据库。

最难是采集,对于成熟度更高的客户,希望更优化的方式,比如对数据进行加工处理合并,我们提供的处理模块可做流式转化合并。主要能为两大类的业务场景提供支撑:分析类与业务类。分析类,TapData 数据平台可以配合数据仓库存储关系型用来做分析型场景。另外一大类是业务场景,业务场景指网页应用、手机应用、交互式应用、客户应用,需要核心数据,这是中台概念,我们把经过处理后的数据落地到存储里,直接实现轻量化的实时数据中台,马上为企业提供实时的数据服务。

第一步采集了数据以后核心点可以支撑三大类的业务场景。

1、点到下游的数据库 Kafka。

2、分析类的场景,例如实时湖仓、数据仓库或者数据湖。

3、提供企业级的核心主数据服务,这也是最为核心。

平台内有三大核心技术点,1、无代码实时采集,2、实时的物化视图能力,3、实时数据一致性保障。

6.jpg

实时采集能力也称为 CDC 机制,简单对该机制进行分析。左边是业务源系统,前面有业务应用,但不直接对接业务应用,因为无代码可低成本快速接入,只需要数据库账号,就会监听数据库的日志文件,把数据事件采集、分析,标准化成事件流,经过连锁处理。可以使简单的字段改名、改值或者是用 Python / Javascript 对数据进行自定义的加工,用目标连接器写到指定目标的数据库里,这是无代码采集能力的机制,整个过程部署完后,只需给到账号权限就可以完成数据链路的搭建。

物化视图能力非常关键,建数仓或建数据服务时,我们希望提供的数据给 BI 、看板或给 API 应用提供的已经是完整逻辑,直接可用的数据模型。我们平台提供部分能力,可以对几个表合并关联,一键启动,构建新的模型,通过预先计算、预先物化的方式,高效地在下游使用到数据,毫秒级查询,支撑实时交互式的业务。

7.jpg主流的数据同步,现在多用 Kafka ETL ,用来做数据管道。用 Kafka 会涉及到几个模块,改写源端的业务应用,写 consumer 代码,采用 CDC 工具,要两三个方案合在一起才能解决问题,是个非常重开发的业务方案,对源系统也会侵入。TapData 方案是透明的,从已有库里采集增量日志,直接放到想要的地方,完成点对点。

某头部的内容平台最开始使用 Kafka ETL, 虽然目前还保留使用,但发现开发成本、维护成本都很高。当意识到很多业务用这种方案时,打算做小工具,帮助企业内部数据的流转,从已有业务系统搬迁到新业务系统,使用客户数据、会员数据、交互行为数据等等。考虑找实时数据的解决方案。经评估, TapData 使用后一年之内上线了大概接近 200 条数据链路,基本上节省了 70%- 75% 的成本增加,交给业务、开发团队,想要数据时,自助找源头,在获得权限的情况下把数据给接过来。

8.jpg

第二种场景是做中央化架构,作为 ESB 方案的替代,把数据从源头利用 CDC 机制中央化到分布式存储里。分布式数据库存储数据能达到高性能扩展。可为多个业务同时支撑,且数据足够新鲜,完全可以支撑交互式的手机应用或者网页应用。使用便捷,成本非常低。

另外用到表包流和流包表概念,不仅能取到流的数据,也可以在平台里取到表的数据, Kafka 大部分只能取到流的数据。TapData 解决方案提供两种可能性,根据业务场景的不同,按需选择。

9.jpg

以某珠宝零售品牌为例:有核心数据、商品数据、库存数据、客户数据、订单数据,分布在 9 套业务系统支撑门店运行。该品牌希望能有准时的、完整的、准确的系统,供总部知晓整个的商品的信息、库存状态等等。之前他们用 MQ 的方式,但很难管理、容易出错、没有统一监控、无法排查问题原因。利用无缝无代码方案把9套系统集成,在这过程中还形成了直观自然的模型,可以看到完整的商品信息,把属性加工处理好,快速配置API,一天之内给发布到测试环境,交给研发使用,效率提升非常明显。API 的开发生产力从以前的两三个月降到了一两周,流程上需要不断测试,再推到生产场景。那另外最核心的点,是终于有了全渠道商品平台,可交付给前端业务团队拿到所有数据。最大的特点是可以共享、重复使用。

10.jpg最后一个案例是搭建实时数仓。某造船厂是人力密集型的企业,有几万员工,造船工序繁琐,管理难度非常大,内部很多系统投入运行,但相对孤立,没法串通做整体效率的提升。

所以他们试图做数据工作,但批量方式没法满足业务对实时性的要求,最后决定建立统一的数据平台。把业务系统集中到数仓后,主要用于实时 BI 场景,此场景非常关注实时性,因为要看效率分配情况,及时调配产线上的工人,所以只有实时数据有意义。这类分析更偏向经营性分析,所以对数据的时效性要求非常高的。


TapData 架构能为多种实时相关的企业的各种业务场景提供支持。较之当前平台方案,最大的核心区分点在于实时基础平台,可以为做升级的企业服务。升级后,除了已有的离线业务,可进一步地为企业的关键型业务提供实时数据的业务支撑。


产品优势:

  • 开箱即用与低代码可视化操作

  • 内置 100+ 数据连接器,稳定的实时采集和传输能力

  • 秒级响应的数据实时计算能力

  • 稳定易用的数据实时服务能力

【推荐阅读】


推荐阅读