[[318978]]

本文旨在探討通用的數(shù)據(jù)中臺(tái)架構(gòu)設(shè)計(jì)方法，產(chǎn)出物為數(shù)據(jù)中臺(tái)的邏輯架構(gòu)。當(dāng)然，考慮到業(yè)界對(duì)于數(shù)據(jù)中臺(tái)的定義千差萬別，可以預(yù)見大家不一定認(rèn)同本文設(shè)想的中臺(tái)架構(gòu)，但我覺得每個(gè)步驟中的推演過程或許會(huì)大家給帶來一點(diǎn)啟發(fā)，還是最終成文，大家權(quán)當(dāng)是疫情期間做了一次腦力體操吧。

1. 明確中臺(tái)邊界

首先，我們面對(duì)的問題域是整個(gè)數(shù)據(jù)體系，這個(gè)體系是指?jìng)鹘y(tǒng)上有數(shù)據(jù)倉庫、數(shù)據(jù)集市構(gòu)成的生態(tài)環(huán)境，不包含聯(lián)機(jī)交易系統(tǒng)（如核心系統(tǒng)、理財(cái)銷售系統(tǒng)）和純粹的流程管理系統(tǒng)（如業(yè)務(wù)審批系統(tǒng)）。

隨著技術(shù)的發(fā)展，這個(gè)體系增加大數(shù)據(jù)和 AI 的元素，更加智能化，但依然是以戰(zhàn)略和戰(zhàn)術(shù)層面的數(shù)據(jù)能力供給為核心，可以作為業(yè)務(wù)變更的權(quán)威依據(jù)和決定性因素，但不直接改變業(yè)務(wù)狀態(tài)。

第一次分解，我們按照是否具有業(yè)務(wù)屬性作為標(biāo)準(zhǔn)，可以先拆出技術(shù)平臺(tái)和“其余部分”。這樣從整體架構(gòu)層面看，后續(xù)無論“其余部分”分解為多少個(gè)系統(tǒng)，這些系統(tǒng)與技術(shù)平臺(tái)的關(guān)系都是一致的，即技術(shù)平臺(tái)提供與業(yè)務(wù)無關(guān)的支撐能力，這種能力包括數(shù)據(jù)的存儲(chǔ)、加工，甚至可以涵蓋可視化層面，前提是這種技術(shù)能力有進(jìn)行平臺(tái)化的必要。

第二次分解，我們從“其余部分”拆分出前臺(tái)和中臺(tái)。支持這次分拆的理由自然是“小前臺(tái)、大中臺(tái)”，也是中臺(tái)建設(shè)熱潮的 Slogan。前臺(tái)注重靈活性，中臺(tái)注重穩(wěn)定性，兩者構(gòu)成類似“變速齒輪”的關(guān)系。

怎么理解靈活與穩(wěn)定呢？我覺得一條重要的標(biāo)準(zhǔn)就是系統(tǒng)的投產(chǎn)頻率。面對(duì)需求變更，前臺(tái)與中臺(tái)的投產(chǎn)頻率至少達(dá)到 2：1，才能體現(xiàn)出中臺(tái)的穩(wěn)定。反之，如果每次需求變更中臺(tái)都要受到影響，那這個(gè)中臺(tái)就是不成功的。

面對(duì)數(shù)據(jù)體系，我們通過明確中臺(tái)邊界，形成了前臺(tái)、中臺(tái)、技術(shù)平臺(tái)三分天下的格局，如下圖所示。

2. 細(xì)化中臺(tái)外部接口

目前我們描述的邊界仍然是概念上的，比較寬泛，也就會(huì)造成理解上的很多分歧。細(xì)化接口可以幫助我們更深刻得描述對(duì)中臺(tái)的期望，從而在組織內(nèi)達(dá)成一致，所以我們第二步就來做這項(xiàng)工作。

技術(shù)平臺(tái)與中臺(tái)的接口各種各樣，但因?yàn)槭菢I(yè)務(wù)無關(guān)的，不容易有歧義，所以我們重點(diǎn)談?wù)勄芭_(tái)和中臺(tái)的接口。傳統(tǒng)上，數(shù)據(jù)體系的系統(tǒng)接口主要是以批量文件形式為主，前臺(tái)和中臺(tái)是否要延續(xù)這種接口呢？我的觀點(diǎn)是，應(yīng)該最大程度的避免使用批量文件作為接口，更多的使用 API 服務(wù)方式。具體原因有以下幾點(diǎn)。

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

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

久而久之，治理系統(tǒng)中“元數(shù)據(jù)”不再被使用，就成了死數(shù)據(jù)。

相對(duì)而言，服務(wù)的自描述要好很多，我們甚至可以在組織范圍內(nèi)約定更豐富的元數(shù)據(jù)，將其與服務(wù)發(fā)布融合在一起?；诩軜?gòu)設(shè)計(jì)上的服務(wù)注冊(cè)與發(fā)現(xiàn)機(jī)制，這些服務(wù)會(huì)受到更強(qiáng)有力的約束，從而保證元數(shù)據(jù)的質(zhì)量。

前臺(tái)的靈活性是源自其輕、薄的設(shè)計(jì)約束，業(yè)務(wù)功能更多依托中臺(tái)的復(fù)用能力來實(shí)現(xiàn)，而文件接口會(huì)增加前臺(tái)數(shù)據(jù)累積數(shù)據(jù)的可能性，從而為前臺(tái)的邊界無序擴(kuò)展創(chuàng)造土壤。

我們?cè)谙到y(tǒng)建設(shè)中常?？梢杂^察到一個(gè)現(xiàn)象，系統(tǒng)會(huì)自我驅(qū)動(dòng)，業(yè)務(wù)會(huì)越來越復(fù)雜和發(fā)散。究其原因，大概是系統(tǒng)的主要利益相關(guān)方更傾向于在系統(tǒng)中拓展功能，可以降低與外部（科技、業(yè)務(wù)等）的協(xié)調(diào)成本。從局部，尤其是某個(gè)特定需求上看，這可能是更快、更好的選擇，但從全局而言就是一種傷害。在哲學(xué)上層面，這個(gè)問題就是局部最優(yōu)解不一定是全局最優(yōu)解。

追求局部最優(yōu)解的后果就是建設(shè)大量豎井式系統(tǒng)，無法沉淀可復(fù)用的能力。中臺(tái)的使命恰恰是要從全局角度，破除或者削弱這種建設(shè)模式。

前臺(tái)盡量不積累數(shù)據(jù)，也就杜絕或者控制了其邏輯向復(fù)雜化、發(fā)散化演進(jìn)的可能。我們可以在更高階的管理層面，以更低的成本洞察到這種演化的趨勢(shì)，從而采取相應(yīng)的措施。

服務(wù)方式天然滿足了控制前臺(tái)系統(tǒng)積累數(shù)據(jù)的目標(biāo)。

依托于批量文件的“數(shù)據(jù)搬家”削弱了整個(gè)數(shù)據(jù)體系的魯棒性

數(shù)據(jù)倉庫方法論是秉承“以空間換時(shí)間”的思路，通過 ETL（SQL 處理）預(yù)加工來降低用戶查詢報(bào)表時(shí)的計(jì)算負(fù)載，從而實(shí)現(xiàn)低延時(shí)交互。為了統(tǒng)籌提升整體加工效率，并不會(huì)將單張報(bào)表依次加工，而是合并報(bào)表的加工層次，先共性后個(gè)性逐層推進(jìn)，一個(gè)批次（一天可能會(huì)存在 2-3 個(gè)批量加工批次，通常不會(huì)太多）的加工結(jié)果大致會(huì)在同一個(gè)時(shí)間段完成。

這種方式的弊端是，一旦上游數(shù)據(jù)或基礎(chǔ)層加工出錯(cuò)，發(fā)現(xiàn)錯(cuò)誤的時(shí)點(diǎn)會(huì)大幅延后。原本通過單進(jìn)程查詢就可以發(fā)現(xiàn)的錯(cuò)誤，現(xiàn)在必須預(yù)支大量的批量計(jì)算成本后才能看到。這個(gè)過程浪費(fèi)了大量的計(jì)算資源和時(shí)間資源（ETL 必須在當(dāng)日完成，因此時(shí)間資源也是受限的），甚至導(dǎo)致無法在剩余的時(shí)間窗口內(nèi)完成糾錯(cuò)和任務(wù)重跑，造成業(yè)務(wù)的重大影響。

我們應(yīng)該看到“以空間換時(shí)間”的策略是基于若干年前的即時(shí)計(jì)算能力而做的權(quán)衡。今天，分布式技術(shù)發(fā)展帶來了即時(shí)計(jì)算能力的大幅提升，是時(shí)候在 ETL 處理和即時(shí)計(jì)算之間尋找更優(yōu)的平衡點(diǎn)了。

我的建議是將一些計(jì)算負(fù)載遷移到服務(wù)中來，用分布式計(jì)算框架代替部分 ETL。中臺(tái)與前臺(tái)的接口處位于整體 ETL 的末端，所以這里也就更適合采用服務(wù)接口。

此外，還要說說第三種接口方式 JDBC，我個(gè)人也是不推薦的。一個(gè)原因是 JDBC 暴露了數(shù)據(jù)源的數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)，強(qiáng)化了前臺(tái)與中臺(tái)的耦合，既然我們?cè)诩軜?gòu)層面希望兩者松耦合，那具體接口上也應(yīng)該選擇匹配的技術(shù)。第二個(gè)原因是業(yè)務(wù)語義上的差異，RESTFUL 服務(wù)有一個(gè)“有趣（Interesting）”原則，服務(wù)要有業(yè)務(wù)語義。直接對(duì)一張表的訪問顯然不夠“有趣”，那么 JDBC 也就不能稱為服務(wù)了。

數(shù)據(jù)中臺(tái)的外部接口主要是 API 服務(wù)。

3. 梳理中臺(tái)內(nèi)部結(jié)構(gòu)

我們繼續(xù)探討數(shù)據(jù)中臺(tái)的內(nèi)部結(jié)構(gòu)，按照我們?cè)诘谝徊皆O(shè)定的邊界，“數(shù)據(jù)倉庫”與“數(shù)據(jù)湖”必然是中臺(tái)的一部分。兩者是不是中臺(tái)的全部呢？我認(rèn)為并不是全部。

數(shù)據(jù)中臺(tái)不只是數(shù)據(jù)倉庫

數(shù)據(jù)倉庫方法論有 Inmon 和 Kimball 兩個(gè)流派，國內(nèi)數(shù)據(jù)倉庫的實(shí)施多數(shù)采用 Inmon 的方法。

具體來說，在數(shù)據(jù)倉庫與數(shù)據(jù)集市的二元結(jié)構(gòu)中，數(shù)據(jù)倉庫對(duì)接上游各類業(yè)務(wù)系統(tǒng)，按照企業(yè)級(jí)模型重組數(shù)據(jù)以消除源系統(tǒng)的特異性，這個(gè)模型按照若干主題進(jìn)行組織，是數(shù)據(jù)倉庫理論體系的核心；數(shù)據(jù)集市在此基礎(chǔ)上，根據(jù)具體的應(yīng)用場(chǎng)景進(jìn)一步加工數(shù)據(jù)，實(shí)現(xiàn)最終的功能交付。

可以看出兩者的指導(dǎo)思想不同，數(shù)據(jù)倉庫是“面向主題”的，數(shù)據(jù)集市是“面向應(yīng)用”的。

有些企業(yè)以前是豎井式的數(shù)據(jù)集市，現(xiàn)在把集市中的共性部分下沉，節(jié)省了加工成本，認(rèn)為這就是數(shù)據(jù)中臺(tái)。如果籠統(tǒng)得用“能力復(fù)用”作為標(biāo)準(zhǔn)，似乎數(shù)據(jù)倉庫與數(shù)據(jù)集市就是中臺(tái)和前臺(tái)了。

那么數(shù)據(jù)中臺(tái)是在炒概念嗎？我認(rèn)為并不是。

數(shù)據(jù)中臺(tái)與數(shù)據(jù)倉庫的差別不是有沒有能力復(fù)用，而是因?yàn)閿?shù)據(jù)集市仍然太重不符合前臺(tái)的靈活性要求。同樣是二元結(jié)構(gòu)，因?yàn)閿?shù)據(jù)集市不等于前臺(tái)，所以數(shù)據(jù)倉庫也就不等于中臺(tái)。

前臺(tái)碎片化

理論上數(shù)據(jù)集市是滿足一個(gè)“業(yè)務(wù)單元”的數(shù)據(jù)分析需求，實(shí)踐中這個(gè)“業(yè)務(wù)單元”往往對(duì)應(yīng)到“業(yè)務(wù)部門”，因?yàn)檫@樣業(yè)務(wù)管控職責(zé)明確，能夠快速需求邊界，和財(cái)務(wù)管理制度也有直接的關(guān)系，項(xiàng)目操作較簡(jiǎn)便。

但是，今天這種方式遇到了挑戰(zhàn)。隨著數(shù)據(jù)應(yīng)用的深入，需求越來越具體，同一部門的不同團(tuán)隊(duì)的需求也各有側(cè)重，都希望保證各自的靈活性，又不希望自身的穩(wěn)定性受到其他團(tuán)隊(duì)靈活性的影響，“業(yè)務(wù)單元”呈現(xiàn)明顯的“碎片化”。

跟隨著業(yè)務(wù)的“碎片化”，數(shù)據(jù)集市不斷裂變，底層邏輯大量重復(fù)。顯然，該做架構(gòu)層面的調(diào)整了。這就說到前臺(tái)，其服務(wù)的“業(yè)務(wù)單元”更小，但邏輯相比數(shù)據(jù)集市要更加輕薄，將原有針對(duì)“業(yè)務(wù)部門”的加工要沉淀到數(shù)據(jù)中臺(tái)，沉淀的部分也有再次重組的機(jī)會(huì)。

數(shù)據(jù)中臺(tái)既“面向主題”也“面向應(yīng)用”

數(shù)據(jù)中臺(tái)“面向主題”是因?yàn)榘藬?shù)據(jù)倉庫，“面向應(yīng)用”則是因?yàn)榘藬?shù)據(jù)集市下沉部分。這里的新問題是如何重組數(shù)據(jù)集市下沉到中臺(tái)的部分，重組方式依賴設(shè)計(jì)者的經(jīng)驗(yàn)，其實(shí)沒有統(tǒng)一方法。我的建議是按“價(jià)值鏈”和“產(chǎn)品線”兩個(gè)維度分解，兩者正交構(gòu)成若干單元，這些單元稱為“業(yè)務(wù)域”。

同樣是數(shù)據(jù)沉淀，為什么不使用數(shù)據(jù)倉庫的主題，而要新建“業(yè)務(wù)域”呢？數(shù)據(jù)倉庫的主題是數(shù)據(jù)層面的高度抽象，基本不體現(xiàn)業(yè)務(wù)流程。今天，數(shù)據(jù)應(yīng)用的大趨勢(shì)是強(qiáng)化對(duì)“一線操作”數(shù)據(jù)賦能，必然更加關(guān)注業(yè)務(wù)流程，而價(jià)值鏈正是業(yè)務(wù)流程的起點(diǎn)；產(chǎn)品則是銜接企業(yè)與用戶的橋梁，同時(shí)也是業(yè)務(wù)操作的核心。

“業(yè)務(wù)域”是對(duì)業(yè)務(wù)流程的抽象，可以說是“面向流程的”，本質(zhì)還是“面向應(yīng)用”的。“業(yè)務(wù)域”數(shù)據(jù)模型不像數(shù)據(jù)倉庫“主題”那樣嚴(yán)格的去冗余，有些維度信息會(huì)重復(fù)出現(xiàn)，比如客戶基本信息、機(jī)構(gòu)信息等。

以銀行為例，“價(jià)值鏈”上的典型環(huán)節(jié)包括營銷、運(yùn)營、風(fēng)控等，“產(chǎn)品線”可以分為零售、對(duì)公、同業(yè)等，兩者正交則可以得到“零售營銷”、“對(duì)公營銷”、“零售風(fēng)控”等業(yè)務(wù)域，當(dāng)然正交得出的業(yè)務(wù)域也可以適當(dāng)調(diào)整。

數(shù)據(jù)中臺(tái)包含一個(gè)“面向主題”的數(shù)據(jù)倉庫（及數(shù)據(jù)湖）和若干個(gè)“面向應(yīng)用”的業(yè)務(wù)域。

4. 針對(duì)非功能性需求的設(shè)計(jì)

目前為止，我們僅在數(shù)據(jù)結(jié)構(gòu)上討論了中臺(tái)的構(gòu)成，并沒有考慮系統(tǒng)的非功能性需求。事實(shí)上，在不同應(yīng)用場(chǎng)景下前臺(tái)的非功能性需求會(huì)有較大的差異，其中最有代表性的是對(duì)并發(fā)和延時(shí)的要求。因?yàn)槲覀円呀?jīng)約定中臺(tái)與前臺(tái)的接口是 API 服務(wù)，這些需求會(huì)直接傳導(dǎo)到中臺(tái)。接下來，讓我們談?wù)勚信_(tái)的針對(duì)性設(shè)計(jì)。

第二步中，我給大家的建議是減少“數(shù)據(jù)搬家”和 ETL，因?yàn)檫@會(huì)導(dǎo)致削弱系統(tǒng)的魯棒性，對(duì)于中臺(tái)的內(nèi)部設(shè)計(jì)我也堅(jiān)持同樣的觀點(diǎn)。數(shù)據(jù)應(yīng)該通過最短的加工路徑，形成 API 服務(wù)向前臺(tái)交付，所以數(shù)據(jù)倉庫和業(yè)務(wù)域都應(yīng)該具備 API 服務(wù)能力。

數(shù)據(jù)倉庫原本以批量加工為主，以文件方式輸出，兼顧 API 服務(wù)絕對(duì)是個(gè)大挑戰(zhàn)。設(shè)計(jì)一個(gè)在行業(yè)內(nèi)廣泛適應(yīng)的主題模型，在我看來其實(shí)是有點(diǎn)玄學(xué)的成分，但既然有超多企業(yè)的實(shí)踐，我們還是先要認(rèn)同它，但談到改造這個(gè)模型，還真是無從下手。

在找到兼顧的方法前，我更愿意讓它保留原來的樣子，這樣可以沿用成熟實(shí)施方法，畢竟目前在數(shù)據(jù)倉庫上繼續(xù)付出努力還會(huì)獲得不錯(cuò)的收益。我們可以讓數(shù)據(jù)倉庫在現(xiàn)有的結(jié)構(gòu)上提供一些兼職的 API 服務(wù)，適合那些延時(shí)要求不高的應(yīng)用場(chǎng)景（比如一些報(bào)表查詢），一旦不能滿足就在更上層的區(qū)域重建這些服務(wù)。

業(yè)務(wù)域的數(shù)據(jù)結(jié)構(gòu)是“面向應(yīng)用”的，也就有更好的基礎(chǔ)提供 API 服務(wù)能力。普通查詢場(chǎng)景，可以選擇兼顧批量處理性能和聯(lián)機(jī)查詢性能的存儲(chǔ)產(chǎn)品，比如 MPP 數(shù)據(jù)庫或者 HTAP 數(shù)據(jù)庫。

高可靠低延時(shí)場(chǎng)景（比如反欺詐、反洗錢，數(shù)據(jù)查詢結(jié)果是會(huì)阻斷異常轉(zhuǎn)賬的依據(jù)，對(duì)延時(shí)有極高的要求），可能是兩種存儲(chǔ)產(chǎn)品的組合，分別提供批量處理和聯(lián)機(jī)訪問能力。聯(lián)機(jī)查詢可以選擇是 K/V 數(shù)據(jù)庫（比如 HBase）或者分布式數(shù)據(jù)庫（NewSQL）或者分庫分表方案（MyCat 或者更好的方案），總之是更接近 OLTP 的存儲(chǔ)系統(tǒng)。存儲(chǔ)產(chǎn)品的組合一定會(huì)帶來數(shù)據(jù)冗余，這種冗余雖然也需要數(shù)據(jù)搬家，但不會(huì)帶來業(yè)務(wù)邏輯層面的重疊，沒有背離我們的設(shè)計(jì)理念。

業(yè)務(wù)域的服務(wù)和中臺(tái)最終交付的服務(wù)是存在差異的，這種差異是為了保護(hù)業(yè)務(wù)域的穩(wěn)定性。無論我們按什么標(biāo)準(zhǔn)劃分業(yè)務(wù)域，也總會(huì)有應(yīng)用場(chǎng)景需要多個(gè)業(yè)務(wù)域參與。所以，在業(yè)務(wù)域之上還要增加一層，我將其成為“服務(wù)聯(lián)邦層”。

通過“服務(wù)聯(lián)邦層”，我們可以完成服務(wù)間的拼接，避免數(shù)據(jù)復(fù)制導(dǎo)致業(yè)務(wù)域邊界的模糊，這種拼接是數(shù)據(jù)語義上的關(guān)聯(lián)。此外還會(huì)對(duì)單個(gè)服務(wù)再加工，隔離應(yīng)用的特異性和存儲(chǔ)數(shù)據(jù)結(jié)構(gòu)的通用性，這意味著過濾、聚合甚至嵌套子查詢。數(shù)據(jù)語義的加入使“服務(wù)聯(lián)邦層”比標(biāo)準(zhǔn)的服務(wù)總線更復(fù)雜了一些，更像 Presto 這樣的數(shù)據(jù)聯(lián)邦產(chǎn)品，但接口是 API 服務(wù)而不是 SQL。

最后還會(huì)存在一些特殊情況，跨業(yè)務(wù)域但通過服務(wù)拼接無法性能要求，必須通過批量加工完成，我們要專門建立一個(gè)區(qū)域隔離這種跨域數(shù)據(jù)加工，稱為“數(shù)據(jù)隔離區(qū)”。這里可以匯聚多個(gè)業(yè)務(wù)域的數(shù)據(jù)，但僅向上層的“數(shù)據(jù)聯(lián)邦層”輸出。業(yè)務(wù)域與“數(shù)據(jù)隔離區(qū)”保持單向數(shù)據(jù)流動(dòng)，維護(hù)業(yè)務(wù)域的穩(wěn)定性。

這樣，我們得到一個(gè)完整的邏輯架構(gòu)圖。

5. 結(jié)語

整個(gè)架構(gòu)設(shè)計(jì)過程中應(yīng)用了一些基本原則，也是我個(gè)人對(duì)數(shù)據(jù)中臺(tái)的理解，包括以下幾點(diǎn)：

• 中臺(tái)一定是有業(yè)務(wù)屬性的，中臺(tái)要比前臺(tái)更穩(wěn)定；
• 盡量減少 ETL 加工，引入分布式技術(shù)進(jìn)行即時(shí)運(yùn)算，提升系統(tǒng)的魯棒性；
• API 服務(wù)接口優(yōu)于文件和 JDBC 接口。
• 中臺(tái)內(nèi)部多層次提供 API 服務(wù)，通過服務(wù)集成的方式減少跨域的數(shù)據(jù)集成。

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

6. 作者介紹

王磊，光大銀行企業(yè)架構(gòu)師，Pharos 架構(gòu)設(shè)計(jì)和主要開發(fā)者，曾任職于 IBM 全球咨詢服務(wù)部從事技術(shù)咨詢工作。目前負(fù)責(zé)全行數(shù)據(jù)領(lǐng)域系統(tǒng)的關(guān)鍵架構(gòu)設(shè)計(jì)、評(píng)審及內(nèi)部研發(fā)等工作，對(duì)分布式數(shù)據(jù)庫、Hadoop 等基礎(chǔ)架構(gòu)研究有濃厚興趣。