本文旨在探討通用的數據中臺架構設計方法，產出物爲數據中臺的邏輯架構。當然，考慮到業界對於數據中臺的定義千差萬別，可以預見大家不一定認同本文設想的中臺架構，但我覺得每個步驟中的推演過程或許會大家給帶來一點啓發，還是最終成文，大家權當是疫情期間做了一次腦力體操吧。
第一步：明確中臺邊界
首先，我們面對的問題域是整個數據體系，這個體系是指傳統上有數據倉庫、數據集市構成的生態環境，不包含聯機交易系統（如核心系統、理財銷售系統）和純粹的流程管理系統（如業務審批系統）。
隨着技術的發展，這個體系增加大數據和AI的元素，更加智能化，但依然是以戰略和戰術層面的數據能力供給爲核心，可以作爲業務變更的權威依據和決定性因素，但不直接改變業務狀態。
第一次分解，我們按照是否具有業務屬性作爲標準，可以先拆出技術平臺和“其餘部分”。這樣從整體架構層面看，後續無論“其餘部分”分解爲多少個系統，這些系統與技術平臺的關係都是一致的，即技術平臺提供與業務無關的支撐能力，這種能力包括數據的存儲、加工，甚至可以涵蓋可視化層面，前提是這種技術能力有進行平臺化的必要。
第二次分解，我們從“其餘部分”拆分出前臺和中臺。支持這次分拆的理由自然是“小前臺、大中臺”，也是中臺建設熱潮的Slogan。前臺注重靈活性，中臺注重穩定性，兩者構成類似“變速齒輪”的關係。
怎麼理解靈活與穩定呢？我覺得一條重要的標準就是系統的投產頻率。面對需求變更，前臺與中臺的投產頻率至少達到2：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。
最後還會存在一些特殊情況，跨業務域但通過服務拼接無法性能要求，必須通過批量加工完成，我們要專門建立一個區域隔離這種跨域數據加工，稱爲“數據隔離區”。這裏可以匯聚多個業務域的數據，但僅向上層的“數據聯邦層”輸出。業務域與“數據隔離區”保持單向數據流動，維護業務域的穩定性。
這樣，我們得到一個完整的邏輯架構圖。
結語
整個架構設計過程中應用了一些基本原則，也是我個人對數據中臺的理解，包括以下幾點：
-
中臺一定是有業務屬性的，中臺要比前臺更穩定；
-
儘量減少ETL加工，引入分佈式技術進行即時運算，提升系統的魯棒性；
-
API服務接口優於文件和JDBC接口。
-
中臺內部多層次提供API服務，通過服務集成的方式減少跨域的數據集成。
一家之言，希望和大家多多交流切磋。
作者介紹
王磊，光大銀行企業架構師，Pharos架構設計和主要開發者，曾任職於IBM全球諮詢服務部從事技術諮詢工作。目前負責全行數據領域系統的關鍵架構設計、評審及內部研發等工作，對分佈式數據庫、Hadoop等基礎架構研究有濃厚興趣。個人公衆號：金融數士