Categories
程式開發

設計一個數據中台,總共分幾步?


本文旨在探討通用的數據中台架構設計方法,產出物為數據中台的邏輯架構。當然,考慮到業界對於數據中台的定義千差萬別,可以預見大家不一定認同本文設想的中台架構,但我覺得每個步驟中的推演過程或許會大家給帶來一點啟發,還是最終成文,大家權當是疫情期間做了一次腦力體操吧。

第一步:明確中台邊界

首先,我們面對的問題域是整個數據體系,這個體係是指傳統上有數據倉庫、數據集市構成的生態環境,不包含聯機交易系統(如核心系統、理財銷售系統)和純粹的流程管理系統(如業務審批系統)。

隨著技術的發展,這個體系增加大數據和AI的元素,更加智能化,但依然是以戰略和戰術層面的數據能力供給為核心,可以作為業務變更的權威依據和決定性因素,但不直接改變業務狀態。

第一次分解,我們按照是否具有業務屬性作為標準,可以先拆出技術平台和“其餘部分”。這樣從整體架構層面看,後續無論“其餘部分”分解為多少個系統,這些系統與技術平台的關係都是一致的,即技術平台提供與業務無關的支撐能力,這種能力包括數據的存儲、加工,甚至可以涵蓋可視化層面,前提是這種技術能力有進行平台化的必要。

第二次分解,我們從“其餘部分”拆分出前台和中台。支持這次分拆的理由自然是“小前台、大中台”,也是中台建設熱潮的Slogan。前台注重靈活性,中台注重穩定性,兩者構成類似“變速齒輪”的關係。

怎麼理解靈活與穩定呢?我覺得一條重要的標準就是系統的投產頻率。面對需求變更,前台與中台的投產頻率至少達到2:1,才能體現出中台的穩定。反之,如果每次需求變更中台都要受到影響,那這個中台就是不成功的。

面對數據體系,我們通過明確中台邊界,形成了前台、中台、技術平台三分天下的格局,如下圖所示。

設計一個數據中台,總共分幾步? 1

第二步:細化中台外部接口

目前我們描述的邊界仍然是概念上的,比較寬泛,也就會造成理解上的很多分歧。細化接口可以幫助我們更深刻得描述對中台的期望,從而在組織內達成一致,所以我們第二步就來做這項工作。

技術平台與中台的接口各種各樣,但因為是業務無關的,不容易有歧義,所以我們重點談談前台和中台的接口。傳統上,數據體系的系統接口主要是以批量文件形式為主,前台和中台是否要延續這種接口呢?我的觀點是,應該最大程度的避免使用批量文件作為接口,更多的使用API​​服務方式。具體原因有以下幾點。

批量文件的自解釋性差、可治理性差

工程實踐中,批量文件的數據與元數據常常是分離的,甚至乾脆省略掉元數據。具體來說,批量文件通常是僅包含數據的平面文件,在源系統中(可能存在於數據庫中)的“數據項標識”、“名稱”、“數據類型”、“備註”這些內容,很少在接口中看到。當然,如果做得好些,我們也可以在數據治理系統中登記這個接口,但問題是治理系統中“元數據”的正確性與系統運行是完全無關的,它們從來沒被真正驗證過,也無法確定是否隨著業務變更被即時更新,當我們需要依據這些“元數據”做出決策時往往信心不足。

久而久之,治理系統中“元數據”不再被使用,就成了死數據。

相對而言,服務的自描述要好很多,我們甚至可以在組織範圍內約定更豐富的元數據,將其與服務發布融合在一起。基於架構設計上的服務註冊與發現機制,這些服務會受到更強有力的約束,從而保證元數據的質量。

前台的靈活性是源自其輕、薄的設計約束,業務功能更多依託中台的複用能力來實現,而文件接口會增加前台數據累積數據的可能性,從而為前台的邊界無序擴展創造土壤。

我們在系統建設中常常可以觀察到一個現象,系統會自我驅動,業務會越來越複雜和發散。究其原因,大概是系統的主要利益相關方更傾向於在系統中拓展功能,可以降低與外部(科技、業務等)的協調成本。從局部,尤其是某個特定需求上看,這可能是更快、更好的選擇,但從全局而言就是一種傷害。在哲學上層面,這個問題就是局部最優解不一定是全局最優解。

追求局部最優解的後果就是建設大量豎井式系統,無法沉澱可複用的能力。中台的使命恰恰是要從全局角度,破除或者削弱這種建設模式。

前台盡量不積累數據,也就杜絕或者控制了其邏輯向複雜化、發散化演進的可能。我們可以在更高階的管理層面,以更低的成本洞察到這種演化的趨勢,從而採取相應的措施。

服務方式天然滿足了控制前台系統積累數據的目標。

依託於批量文件的“數據搬家”削弱了整個數據體系的魯棒性

數據倉庫方法論是秉承“以空間換時間”的思路,通過ETL(SQL處理)預加工來降低用戶查詢報表時的計算負載,從而實現低延時交互。為了統籌提升整體加工效率,並不會將單張報表依次加工,而是合併報表的加工層次,先共性後個性逐層推進,一個批次(一天可能會存在2-3個批量加工批次,通常不會太多)的加工結果大致會在同一個時間段完成。

這種方式的弊端是,一旦上游數據或基礎層加工出錯,發現錯誤的時點會大幅延後。原本通過單進程查詢就可以發現的錯誤,現在必須預支大量的批量計算成本後才能看到。這個過程浪費了大量的計算資源和時間資源(ETL必須在當日完成,因此時間資源也是受限的),甚至導致無法在剩餘的時間窗口內完成糾錯和任務重跑,造成業務的重大影響。

我們應該看到“以空間換時間”的策略是基於若干年前的即時計算能力而做的權衡。今天,分佈式技術發展帶來了即時計算能力的大幅提升,是時候在ETL處理和即時計算之間尋找更優的平衡點了。

我的建議是將一些計算負載遷移到服務中來,用分佈式計算框架代替部分ETL。中台與前台的接口處位於整體ETL的末端,所以這裡也就更適合採用服務接口。

此外,還要說說第三種接口方式JDBC,我個人也是不推薦的。一個原因是JDBC暴露了數據源的數據存儲結構,強化了前台與中台的耦合,既然我們在架構層面希望兩者松耦合,那具體接口上也應該選擇匹配的技術。第二個原因是業務語義上的差異,RESTFUL服務有一個“有趣(Interesting)”原則,服務要有業務語義。直接對一張表的訪問顯然不夠“有趣”,那麼JDBC也就不能稱為服務了。

數據中台的外部接口主要是API服務。

第三步:梳理中台內部結構

我們繼續探討數據中台的內部結構,按照我們在第一步設定的邊界,“數據倉庫”與“數據湖”必然是中台的一部分。兩者是不是中台的全部呢?我認為並不是全部。

數據中台不只是數據倉庫

數據倉庫方法論有Inmon和Kimball兩個流派,國內數據倉庫的實施多數採用Inmon的方法。

具體來說,在數據倉庫與數據集市的二元結構中,數據倉庫對接上游各類業務系統,按照企業級模型重組數據以消除源系統的特異性,這個模型按照若干主題進行組織,是數據倉庫理論體系的核心;數據集市在此基礎上,根據具體的應用場景進一步加工數據,實現最終的功能交付。

可以看出兩者的指導思想不同,數據倉庫是“面向主題”的,數據集市是“面向應用”的。

有些企業以前是豎井式的數據集市,現在把集市中的共性部分下沉,節省了加工成本,認為這就是數據中台。如果籠統得用“能力復用”作為標準,似乎數據倉庫與數據集市就是中台和前台了。

那麼數據中台是在炒概念嗎?我認為並不是。

數據中台與數據倉庫的差別不是有沒有能力復用,而是因為數據集市仍然太重不符合前台的靈活性要求。同樣是二元結構,因為數據集市不等於前台,所以數據倉庫也就不等於中台。

前台碎片化

理論上數據集市是滿足一個“業務單元”的數據分析需求,實踐中這個“業務單元”往往對應到“業務部門”,因為這樣業務管控職責明確,能夠快速需求邊界,和財務管理制度也有直接的關係,項目操作較簡便。

但是,今天這種方式遇到了挑戰。隨著數據應用的深入,需求越來越具體,同一部門的不同團隊的需求也各有側重,都希望保證各自的靈活性,又不希望自身的穩定性受到其他團隊靈活性的影響,“業務單元”呈現明顯的“碎片化”。

跟隨著業務的“碎片化”,數據集市不斷裂變,底層邏輯大量重複。顯然,該做架構層面的調整了。這就說到前台,其服務的“業務單元”更小,但邏輯相比數據集市要更加輕薄,將原有針對“業務部門”的加工要沉澱到數據中台,沉澱的部分也有再次重組的機會。

數據中台既“面向主題”也“面向應用”

數據中台“面向主題”是因為包含了數據倉庫,“面向應用”則是因為包含了數據集市下沉部分。這裡的新問題是如何重組數據集市下沉到中台的部分,重組方式依賴設計者的經驗,其實沒有統一方法。我的建議是按“價值鏈”和“產品線”兩個維度分解,兩者正交構成若干單元,這些單元稱為“業務域”。

同樣是數據沉澱,為什麼不使用數據倉庫的主題,而要新建“業務域”呢?數據倉庫的主題是數據層面的高度抽象,基本不體現業務流程。今天,數據應用的大趨勢是強化對“一線操作”數據賦能,必然更加關注業務流程,而價值鏈正是業務流程的起點;產品則是銜接企業與用戶的橋樑,同時也是業務操作的核心。

“業務域”是對業務流程的抽象,可以說是“面向流程的”,本質還是“面向應用”的。 “業務域”數據模型不像數據倉庫“主題”那樣嚴格的去冗餘,有些維度信息會重複出現,比如客戶基本信息、機構信息等。

以銀行為例,“價值鏈”上的典型環節包括營銷、運營、風控等,“產品線”可以分為零售、對公、同業等,兩者正交則可以得到“零售營銷”、“對公營銷”、“零售風控”等業務域,當然正交得出的業務域也可以適當調整。

數據中台包含一個“面向主題”的數據倉庫(及數據湖)和若干個“面向應用”的業務域。

第四步:針對非功能性需求的設計

目前為止,我們僅在數據結構上討論了中台的構成,並沒有考慮系統的非功能性需求。事實上,在不同應用場景下前台的非功能性需求會有較大的差異,其中最有代表性的是對並發和延時的要求。因為我們已經約定中台與前台的接口是API服務,這些需求會直接傳導到中台。接下來,讓我們談談中台的針對性設計。

第二步中,我給大家的建議是減少“數據搬家”和ETL,因為這會導致削弱系統的魯棒性,對於中台的內部設計我也堅持同樣的觀點。數據應該通過最短的加工路徑,形成API服務向前台交付,所以數據倉庫和業務域都應該具備API服務能力。

數據倉庫原本以批量加工為主,以文件方式輸出,兼顧API服務絕對是個大挑戰。設計一個在行業內廣泛適應的主題模型,在我看來其實是有點玄學的成分,但既然有超多企業的實踐,我們還是先要認同它,但談到改造這個模型,還真是無從下手。

在找到兼顧的方法前,我更願意讓它保留原來的樣子,這樣可以沿用成熟實施方法,畢竟目前在數據倉庫上繼續付出努力還會獲得不錯的收益。我們可以讓數據倉庫在現有的結構上提供一些兼職的API服務,適合那些延時要求不高的應用場景(比如一些報表查詢),一旦不能滿足就在更上層的區域重建這些服務。

業務域的數據結構是“面向應用”的,也就有更好的基礎提供API服務能力。普通查詢場景,可以選擇兼顧批量處理性能和聯機查詢性能的存儲產品,比如MPP數據庫或者HTAP數據庫。

高可靠低延時場景(比如反欺詐、反洗錢,數據查詢結果是會阻斷異常轉賬的依據,對延時有極高的要求),可能是兩種存儲產品的組合,分別提供批量處理和聯機訪問能力。聯機查詢可以選擇是K/V數據庫(比如HBase)或者分佈式數據庫(NewSQL)或者分庫分錶方案(MyCat或者更好的方案),總之是更接近OLTP的存儲系統。存儲產品的組合一定會帶來數據冗餘,這種冗餘雖然也需要數據搬家,但不會帶來業務邏輯層面的重疊,沒有背離我們的設計理念。

業務域的服務和中台最終交付的服務是存在差異的,這種差異是為了保護業務域的穩定性。無論我們按什麼標準劃分業務域,也總會有應用場景需要多個業務域參與。所以,在業務域之上還要增加一層,我將其成為“服務聯邦層”。

通過“服務聯邦層”,我們可以完成服務間的拼接,避免數據複製導致業務域邊界的模糊,這種拼接是數據語義上的關聯。此外還會對單個服務再加工,隔離應用的特異性和存儲數據結構的通用性,這意味著過濾、聚合甚至嵌套子查詢。數據語義的加入使“服務聯邦層”比標準的服務總線更複雜了一些,更像Presto這樣的數據聯邦產品,但接口是API服務而不是SQL。

最後還會存在一些特殊情況,跨業務域但通過服務拼接無法性能要求,必須通過批量加工完成,我們要專門建立一個區域隔離這種跨域數據加工,稱為“數據隔離區”。這裡可以匯聚多個業務域的數據,但僅向上層的“數據聯邦層”輸出。業務域與“數據隔離區”保持單向數據流動,維護業務域的穩定性。

這樣,我們得到一個完整的邏輯架構圖。

設計一個數據中台,總共分幾步? 2

結語

整個架構設計過程中應用了一些基本原則,也是我個人對數據中台的理解,包括以下幾點:

  • 中台一定是有業務屬性的,中台要比前台更穩定;

  • 盡量減少ETL加工,引入分佈式技術進行即時運算,提升系統的魯​​棒性;

  • API服務接口優於文件和JDBC接口。

  • 中台內部多層次提供API服務,通過服務集成的方式減少跨域的數據集成。

一家之言,希望和大家多多交流切磋。

作者介紹

王磊,光大銀行企業架構師,Pharos架構設計和主要開發者,曾任職於IBM全球諮詢服務部從事技術諮詢工作。目前負責全行數據領域系統的關鍵架構設計、評審及內部研發等工作,對分佈式數據庫、Hadoop等基礎架構研究有濃厚興趣。個人公眾號:金融數士