實時關(guān)鍵業(yè)務場景快速增長我們需要什么樣的數(shù)據(jù)平臺來支持

經(jīng)過多年的數(shù)據(jù)基礎(chǔ)設施建設,企業(yè)已經(jīng)完成從"有數(shù)"到"用數(shù)"的過渡,數(shù)據(jù)驅(qū)動成為常態(tài)。進一步,面對激烈的市場競爭和快速變化的客戶需求,如何提高"用數(shù)"效率,以實時或準實時的數(shù)據(jù)處理速度進行決策、開展服務以及優(yōu)化運營,正成為企業(yè)獲取競爭優(yōu)勢的關(guān)鍵,催生實時數(shù)據(jù)業(yè)務場景快速增長。面對日益增長的實時數(shù)據(jù)業(yè)務場景,傳統(tǒng)的實時數(shù)據(jù)集成解決方案如點到點實時同步、ESB企業(yè)總線、kafka消息隊列等均存在各種局限性,促使新一代實時數(shù)據(jù)集成解決方案應運而生。本文將重點闡述實時數(shù)據(jù)業(yè)務場景的定義、增長驅(qū)動因素,并通過多種實時數(shù)據(jù)集成解決方案的對比,闡釋新一代實時數(shù)據(jù)集成解決方案為什么代表著未來發(fā)展趨勢。01實時數(shù)據(jù)業(yè)務場景的定義實時數(shù)據(jù)業(yè)務場景指企業(yè)在經(jīng)營過程中,對新數(shù)據(jù)進行實時傳輸、處理、分析、查詢和響應的業(yè)務場景,支持實時決策和實時操作。其中實時指的是從數(shù)據(jù)產(chǎn)生端到消費端跨系統(tǒng)傳輸或處理過程實現(xiàn)毫秒或秒級延遲。圖1:實時數(shù)據(jù)業(yè)務場景分類示意圖按照消費端的數(shù)據(jù)處理模式,實時數(shù)據(jù)業(yè)務場景包含TP場景下的實時交互型業(yè)務場景和AP場景下的實時運營分析場景。TP場景下的實時交互型業(yè)務場景實時交互型業(yè)務場景指消費端的應用程序需要跨系統(tǒng)實時查詢生產(chǎn)端系統(tǒng)信息的場景,如統(tǒng)一訂單中心、實時風控、CDP平臺等。這些場景是企業(yè)的關(guān)鍵任務,對于保障企業(yè)正常經(jīng)營有決定性影響,一旦出現(xiàn)延遲或數(shù)據(jù)錯誤將導致嚴重的經(jīng)營事故,因此對數(shù)據(jù)時效性和數(shù)據(jù)準確需要強調(diào)的是,與傳統(tǒng)基于oracle數(shù)據(jù)庫實現(xiàn)的TP場景不同,實時交互型業(yè)務場景往往涉及異構(gòu)的數(shù)據(jù)源,需要解決源系統(tǒng)和目標系統(tǒng)之間跨系統(tǒng)的數(shù)據(jù)一致性,數(shù)據(jù)傳輸處理和集成等問題。而傳統(tǒng)的OLTP場景雖然也強調(diào)實時響應,但在單一oracle數(shù)據(jù)庫中實現(xiàn)數(shù)據(jù)集成、完成業(yè)務的事務性操作以及保障數(shù)據(jù)一致性,其技術(shù)實現(xiàn)的路徑和復雜度與實時交互型業(yè)務場景截然不同。AP場景下的實時運營分析場景實時運營分析場景需指融合業(yè)務最新數(shù)據(jù)和歷史數(shù)據(jù)進行實時復雜分析的場景,如實時BIl、實時數(shù)據(jù)分析、實時決策等,在客戶體驗改善、生產(chǎn)效率提升、個性化產(chǎn)品和服務推薦等方面表1:實時相關(guān)概念對比02內(nèi)外部環(huán)境因素驅(qū)動實時數(shù)據(jù)業(yè)務場景快速增加歷史It建設遺留的數(shù)據(jù)孤島使跨系統(tǒng)數(shù)據(jù)集成成為數(shù)據(jù)利用常態(tài),面向未來競爭的數(shù)據(jù)能力建設需求驅(qū)動跨系統(tǒng)的實時數(shù)據(jù)業(yè)務場景快速增加。2.1歷史It建設形成數(shù)據(jù)孤島,數(shù)據(jù)集成成企業(yè)用數(shù)必要步驟企業(yè)在歷史的It建設過程中,為滿足各業(yè)務管理需求,搭建起諸如CRMERP、財務、人力、供應鏈等多種系統(tǒng)。由于建設的時期較早,這些系統(tǒng)多為應用程序和數(shù)據(jù)庫緊密耦合的單體式架構(gòu),系統(tǒng)相互之間各自獨立、無法聯(lián)通,形成企業(yè)數(shù)據(jù)孤島。據(jù)不完全統(tǒng)計,大型企業(yè)的業(yè)務系統(tǒng)平均數(shù)量為315套,中小型企業(yè)的業(yè)務系統(tǒng)數(shù)量為52套。數(shù)據(jù)孤島使得跨系統(tǒng)的數(shù)據(jù)消費成為常態(tài),數(shù)據(jù)集成成為企業(yè)用數(shù)首先要解決的問題。外部市場和客戶變化,以及內(nèi)部企業(yè)對經(jīng)營效率、客戶體驗的提升訴求,共同驅(qū)動企業(yè)實時數(shù)據(jù)業(yè)務場景快速增加。一方面,企業(yè)業(yè)務模式創(chuàng)新以及運營秩序的維系驅(qū)動實時交互型業(yè)務場景快速增加。如高速發(fā)展中的企業(yè)往往通過創(chuàng)新業(yè)務形態(tài)增加營收。企業(yè)在拓展新業(yè)務形態(tài)時型事務操作場景。某知識付費平臺在核心課程基礎(chǔ)上增加讀書、聽書等新業(yè)態(tài),由于用戶的會員界面中需要實時呈現(xiàn)課程、讀書、聽書等業(yè)態(tài)權(quán)益,該平臺需要為新業(yè)態(tài)開發(fā)實時交互數(shù)據(jù)對于存量競爭下開展精益管理的企業(yè),整合企業(yè)多系統(tǒng)內(nèi)的商品、客戶、庫存等核心信息,持續(xù)開發(fā)交互式業(yè)務應用,對于維持業(yè)務正常運轉(zhuǎn)非常重要。如對于多品牌大型零售企業(yè),統(tǒng)一庫存查詢能實時展示商品數(shù)量,滿足企業(yè)內(nèi)外部用戶即時商品查詢需求,保障一線員工正常開展銷售和服務活動,避免因商品信息錯誤丟失商機。另一方面,對整體運營效率的持續(xù)提升和客戶體驗的持續(xù)改善推動企業(yè)實時運營分析場景快速以金融行業(yè)信用卡交易的反欺詐場景為例,在信用卡發(fā)生交易的第一時間,銀行會融合近期的交易時間、地理位置、交易金額等多維信息,實時監(jiān)控交易行為,一旦識別出異常模式立即觸發(fā)警報,在秒級內(nèi)中止交易,保證交易安全性。又如制造業(yè)生產(chǎn)線中的實時監(jiān)控能對產(chǎn)品質(zhì)量進行實時監(jiān)測,對于生產(chǎn)中的異常狀態(tài)進行及時提醒甚至停止產(chǎn)線,能提升生產(chǎn)效率、降低潛在損失。03傳統(tǒng)數(shù)據(jù)集成解決方案弊端漸顯,TapData定義新一代實時數(shù)據(jù)集成平臺3.1實時數(shù)據(jù)業(yè)務解決方案的技術(shù)難點圖2:實時數(shù)據(jù)業(yè)務解決方案的技術(shù)難點面對以上快速增長的TP、AP實時數(shù)據(jù)業(yè)務場景,愛分析認為一個完善的實時數(shù)據(jù)解決方案應實現(xiàn)跨系統(tǒng)的實時數(shù)據(jù)集成,并解決兩個技術(shù)難點和一個開發(fā)運維難點:標系統(tǒng)都可能涉及數(shù)據(jù)庫表數(shù)據(jù)和消息隊列流數(shù)據(jù),因此解決方案應同時具備表到流以及流到表的轉(zhuǎn)換技術(shù)。效率的優(yōu)化方式,對實時數(shù)據(jù)進行預計算才能保證實時運營分析場景的高時效性。實時運營分析的預計算的困難在于如何在實時數(shù)據(jù)采集、在數(shù)據(jù)每秒數(shù)百數(shù)千次更新的情況下,基于原始數(shù)據(jù)構(gòu)建新的業(yè)務模型,完成實時預計算過程。3.2傳統(tǒng)數(shù)據(jù)集成解決方案的局限性目前市場中實現(xiàn)數(shù)據(jù)集成的方式包括批量集成和實時集成。典型的批量集成解決方案如大數(shù)據(jù)平臺、數(shù)據(jù)中臺,雖然解決了數(shù)據(jù)孤島問題,但時效性難以滿足實時數(shù)據(jù)業(yè)務場景需求,不贅當前主流的實時數(shù)據(jù)集成方案包括點到點數(shù)據(jù)同步、ESB企業(yè)總線和kafka消息隊列,這三種方案代表了實時數(shù)據(jù)集成方案的迭代歷程,但在解決實時業(yè)務場景技術(shù)難點、控制運維成本方面均存在不同程度的局限性。相較主流實時數(shù)據(jù)集成方案,愛分析觀察到,市場中已經(jīng)出現(xiàn)更為前沿的實時數(shù)據(jù)集成解決方題,其低代碼簡單易用、中央化數(shù)據(jù)資產(chǎn)復用的特征更是受到市場廣泛認可,代表著新一代實時數(shù)據(jù)平臺演進方向。點到點實時數(shù)據(jù)同步點到點實時數(shù)據(jù)同步是最簡單、直接的實時數(shù)據(jù)集成方式,可實現(xiàn)數(shù)據(jù)一對一的從源系統(tǒng)到目標系統(tǒng)的數(shù)據(jù)同步。但擴展性弱,開發(fā)運維成本高,每增加一個系統(tǒng)需要配置新的連接,系統(tǒng)之間強依賴緊耦合。隨著系統(tǒng)數(shù)量的增加,數(shù)據(jù)鏈路的數(shù)量和復雜性呈指數(shù)增長,且缺乏系統(tǒng)管理中心,導致系統(tǒng)維護和運維非常困難。在多源數(shù)據(jù)輸入時,點到點數(shù)據(jù)同步存在處理數(shù)據(jù)沖突和一致性問題,無預計算能力。ESB企業(yè)服務總線ESB企業(yè)服務總線提供了一種中心化的、松耦合的軟件架構(gòu)模式,支持不同應用程序之間的實時數(shù)據(jù)集成和交換,具備高度的靈活性和可擴展性。ESB支持復雜的事務管理和協(xié)調(diào),雖然提供了集中化管理工具對流程和服務健康進行實時監(jiān)測,但整體的學習成本高昂,要求開發(fā)人員具備極強的專業(yè)性,對消息路由、轉(zhuǎn)換、事務管理、安全性、以及不同系統(tǒng)之間的兼容、性能調(diào)優(yōu)等多方面進行配置和管理。ESB中心化的處理架構(gòu)在大規(guī)模的并發(fā)請求時性能受限,延遲較高,且商業(yè)化成本高昂,在互kafka消息隊列kafka是一個開源免費的分布式消息隊列系統(tǒng),能夠提供高吞吐量和低延遲的實時數(shù)據(jù)傳輸和集成,并且其本身具有高可用性、可擴展性、高效查詢、高并發(fā)寫入、支持事件驅(qū)動架構(gòu)等特征,是企業(yè)構(gòu)建實時數(shù)據(jù)管道的最常用的工具。kafka引進成本低,但對開發(fā)人員專業(yè)能力要求非常高,后續(xù)的開發(fā)運維的復雜性和成本將隨企業(yè)實時應用數(shù)量的增加而顯著增長。一方面,kafka不支持分布式事務,分布式架構(gòu)下,企一方面,從實時數(shù)據(jù)全鏈路來看,kafka僅是一個中間件,除kafka外,上游業(yè)務系統(tǒng)對kafka的事件推送,下游數(shù)據(jù)消費者對kafka的事件提取等工作,仍需要企業(yè)承擔。此外,游業(yè)務系統(tǒng)中數(shù)據(jù)屬性變化、下游數(shù)據(jù)應用的差異化數(shù)據(jù)需求,都將帶來從業(yè)務系統(tǒng)到消費應用建法創(chuàng)建,其核心團隊對各類數(shù)據(jù)庫內(nèi)存、事務實現(xiàn)、日志格式等底層技術(shù)實現(xiàn)具備豐富經(jīng)年研發(fā),2022年,TapData率先在業(yè)內(nèi)推出可解決數(shù)據(jù)孤島的、同時支持TP和AP實時數(shù)平臺,具有多架構(gòu)支持、低代碼開發(fā)、全鏈路實時等特點。圖3:TapDataLDP平臺架構(gòu)和場景示意圖數(shù)據(jù)采集層:LDP支持豐富的數(shù)據(jù)源類型,包括主流的開源數(shù)據(jù)庫、國產(chǎn)信創(chuàng)、離線文件、業(yè)務應用API、湖倉等。通過CDC實時采集源系統(tǒng)數(shù)據(jù)變化,進入流處理框架。的數(shù)據(jù)模型,建立統(tǒng)一的數(shù)據(jù)標準,支持下游按需取用。服務層:服務層支持pull和push兩種服務模式,支持低代碼發(fā)布API。也支持REVERSEETL反向把經(jīng)過整理的數(shù)據(jù)推送給下游。低開發(fā)運維成本。場景一:實時采集CDC機制實現(xiàn)點對點的實時數(shù)據(jù)同步這是最簡單的實時數(shù)據(jù)同步場景。CDC機制能對數(shù)據(jù)庫日志文件進行解析,將數(shù)據(jù)變化標準化成事件流后進入流處理框架加工,加工后的數(shù)據(jù)通過目標連接器寫入目標數(shù)據(jù)庫或應用。整持將源系統(tǒng)的表數(shù)據(jù)變成流以push模式推送給kafka或是對接應用業(yè)務流程,適應時效性要求高的TP型場景,也支持將流數(shù)據(jù)轉(zhuǎn)化成表,推送給各種數(shù)據(jù)庫供AP場景使用。場景二:實時數(shù)據(jù)處理+中央化存儲支撐實現(xiàn)實時運營分析場景針對企業(yè)用戶更高級、更復雜的實時運營分析場景,在采集源系統(tǒng)數(shù)據(jù)進入流處理模塊后,享挖掘等高級數(shù)據(jù)處理操作,可無代碼完成實時數(shù)據(jù)的預處理。計算后的結(jié)果存儲在數(shù)據(jù)倉庫中,供實時Bl、實時駕駛艙、實時決策等場景以pull數(shù)據(jù)服務模式使用。場景三:實時數(shù)據(jù)處理+中央化存儲+數(shù)據(jù)服務支撐實現(xiàn)實時交互型業(yè)務場景為下游交互型應用提供實時數(shù)據(jù)服務,實現(xiàn)數(shù)據(jù)查詢的實時更新。周為單位縮短到分鐘級。對于實時數(shù)據(jù)的采集,在LDPCDC機制下,用戶只需提供源庫賬LDP提供零代碼界面,用戶可通過拖拽完成任務編排,極大降低了同步任務流定義的復雜度。在數(shù)據(jù)服務環(huán)節(jié),LDP支持無代碼快速發(fā)布APII.04某銀行通過TapData升級實時數(shù)據(jù)交換平臺汽、中芯國際、周生生、富邦銀行等數(shù)十家行業(yè)標桿企業(yè),實時數(shù)據(jù)交換平臺的變革性價值廣受企業(yè)認同。某銀行針對業(yè)務數(shù)據(jù)庫種類多、數(shù)據(jù)量級大的特點,基于開源的云原生的kafka解決方案自主研發(fā)了實時數(shù)據(jù)同步系統(tǒng),業(yè)務側(cè)的實時數(shù)據(jù)應用均采用容器技術(shù)封裝、運行,并自研了kafka管控平臺,對集群進行指標監(jiān)控和運維。目前該銀行主要面臨三個挑戰(zhàn):實現(xiàn)實時數(shù)據(jù)集中緩存,支持實時運營分析場景:該銀行實時運營監(jiān)控、客戶360視圖等場景對實時數(shù)據(jù)查詢需求增加,原系統(tǒng)在業(yè)務進行實時數(shù)據(jù)查詢時以點到點的形式實現(xiàn),數(shù)據(jù)鏈路需重復開發(fā),數(shù)據(jù)資產(chǎn)難以復用。為提高數(shù)據(jù)利用效率,該銀行希望實現(xiàn)實時數(shù)據(jù)集中緩存,為下游提供表查詢服務。開發(fā)維護成本高:由于云原生實時數(shù)據(jù)同步系統(tǒng)完全基于自主開發(fā),所有實時數(shù)據(jù)同步鏈路的開發(fā)、維護、監(jiān)控、運維都需要IT團隊完成,隨著下游業(yè)務側(cè)實時數(shù)據(jù)應用數(shù)量的快速增長,開發(fā)運維的難度和成本均快速增長,且開發(fā)周期長難以滿足業(yè)務需求,該銀行需要尋求更需符合信創(chuàng)要求:信創(chuàng)背景下,銀行業(yè)數(shù)據(jù)庫國產(chǎn)化替換進度加快,已經(jīng)進入核心業(yè)務數(shù)據(jù)庫替換階段。該銀行在對傳統(tǒng)和互聯(lián)網(wǎng)核心業(yè)務數(shù)據(jù)庫替換時,由于開源的實時數(shù)據(jù)同步方案對國產(chǎn)化數(shù)據(jù)庫不支持,影響該銀行核心系統(tǒng)國產(chǎn)化改造進程。在以上背景下,考慮到對云原生架構(gòu)的支持、對國產(chǎn)數(shù)據(jù)庫的支持以及易用性等多方面因素,該銀行最終與TapData達成合作,采用本地部署"TapDataLiveDataplatform"方案對數(shù)據(jù)采集、消息同步到kafka兩部分架構(gòu)進行替換,下游消費側(cè)保持不動。替換后的實時數(shù)據(jù)同步系統(tǒng)具有以下特點:統(tǒng)一的實時數(shù)據(jù)資產(chǎn),以實時表的形式支持下游業(yè)務系統(tǒng)查詢。大幅度減少了實時數(shù)據(jù)管道建設的數(shù)量建實時鏈路,以及通過可視化運維界面,實時監(jiān)控數(shù)據(jù)任務狀態(tài),以及進行實時數(shù)據(jù)同步驗等,無論是業(yè)務端用戶還是開發(fā)運維人員均能在既有系統(tǒng)中通過調(diào)用Apl完成實時數(shù)據(jù)同步,可復用性:一套基礎(chǔ)實時數(shù)據(jù)平臺,支持多個實時數(shù)據(jù)業(yè)務模式:實時同步與復制,實時分析數(shù)倉,實時數(shù)據(jù)服務等該銀行更新后的實時數(shù)據(jù)同步系統(tǒng),其簡易的使用體驗使得實時數(shù)據(jù)鏈路的開發(fā)運維不再依賴專業(yè)開發(fā)人員,釋放人力,開發(fā)人員能專注于業(yè)務賦能。更新后的實時數(shù)據(jù)鏈路開發(fā)效率也得到大幅提升,開發(fā)周期從1-2周