今天，中臺已經成為架構轉型的里程碑，從網際網路到傳統企業談架構必有中臺。雖然各種中臺概念層出不窮，但“資料中臺”和“業務中臺”作為中颱概念的起始源頭，被視為最純正的中臺，也是企業架構轉型的重要目標。我所在的銀行正籌備“資料中臺”的建設，為此在內外部組織了多次技術研討，每個人都有不同的想法，共同點僅限於希望自己的解決方案命名為“資料中臺”。我想這種認識的差異是源於“資料中臺”尚處在概念萌芽期，需要更多探討與碰撞。本文借鑑了網際網路公司和兩家同業銀行的案例，嘗試對“資料中臺”建設思路進行總結，所提出的架構方案僅供探討，尚未應用於實際系統建設。

傳說與誤解

在爭論什麼是“資料中臺”前，我們應該意識到“資料中臺”只是解決方案，討論的關鍵在於我們希望通過“資料中臺”解決什麼問題？這裡先給答案，在我看來，中臺要解決的核心問題是在短時間內搭建或變更前臺系統，從而快速響應使用者需求、把握市場機會。

首先我們梳理下有關“中臺”的傳說。

作為這一波“中臺”概念的源頭，第一個傳說必須來自阿里。“遊戲公司”的傳說，大致是這樣，阿里的馬老師帶隊參觀了一家厲害的遊戲公司 Supercell，它有很多成功的遊戲產品，其獨特優勢是能夠快速推出新產品，而依靠的就是中臺系統。馬老師受到了啟發，回到阿里開始推進中臺建設，在組織架構層面成立了單獨的中臺部門即“共享業務事業部”，系統層面建設了使用者中心、支付中心等共享服務同時支援淘寶、天貓、1688 等業務條線，最終也實現了快速的前臺產品研發。這些中臺服務被統稱為“業務中臺”。

通過這個故事，我們可以得出第一個結論。中臺應該提供“共享服務能力”，這種共享源於對業務場景的抽象、提煉、沉澱。
關於中臺的第二個傳說是“變速齒輪”，相對技術化和抽象一些。當前的IT 架構通常是由前臺和後臺組成，前臺系統接觸使用者，後臺系統提供基礎服務。兩者一個需要靈活快速，一個需要穩定高效，兩者在變更速率上不匹配，制約了對使用者需求的快速響應。中臺的誕生銜接了前後臺系統，保證後臺穩定的同時又支援了前臺的靈活。

這樣我們有了第二個結論，中臺意味著了前中後的三層體系架構，三者的變更速率可以實現更平緩的過渡，從而兼顧整個體系的靈活與穩定。

但有一個問題始終困擾著我，基於前兩個結論，可知是存在“業務後臺”和“資料後臺”的，那又是指什麼呢？這個概念不澄清，體系就是不完整的。

帶著這個疑問，我們來看看具體案例。首先是阿里的雙中臺架構[1]。

圖中標註了組織架構層面的前臺、中臺和後臺，但並沒有給出業務後臺和資料後臺的邊界與定義，從字面上看後臺與中臺的關聯性也較弱。

民生銀行的資料中臺體系技術方案[2]給出了上面的架構圖，明確了“資料後臺”的範圍，其涵蓋了 Hadoop 平臺、實時分析平臺等，有點技術平臺的味道。

農行“薄前臺、厚中臺、強後臺”IT 架構體系 [3] 中對前中後三個層次描述得更為明確，將大資料平臺和 PAAS、IAAS 基礎設施劃入了後臺。

看過兩家銀行架構，我們似乎可以得到一個推論，後臺是技術平臺或基礎設施。但這兩者通常是與業務無關的，會制約前臺業務的靈活性嗎？基礎設施和技術平臺同時支援了前臺和中臺，在層級並不是一個遞進關係呀？這個分層似乎有點奇怪，有點牽強。

反覆思考後，我認為阿里提出的“使用者中心”、“支付中心”所代表的“業務中臺”是指企業組織層面的中臺，更準確說法是“由業務中臺部門所主導的業務能力共享平臺”。

前臺部門直接面對使用者和創造利潤；阿里“共享服務事業部”更多參與到了業務中，非常適合中臺的定位。而後臺主要是輔助作用，通常也就不會受到使用者需求的影響，企業甚至行業間的差異都比較小，因此在以快速響應為核心的方案中將其忽略也就順理成章的事了。進一步研究發現，本文觀點與網易對中臺的看法較為接近。對於資料中臺，網易杭州研究院執行院長汪源給出的定義如下，“所有的中臺都是業務中臺，資料中臺是業務中臺的特殊形式。中臺是區別於平臺的，具備業務屬性、支撐多個前臺業務的產品，其本質是公司業務能力的沉澱。”

帶著這個觀點，我們重新解讀兩個故事。在“遊戲公司”的故事中，業務中臺是指企業能力層面的中臺，“中”是指所屬部門在組織架構的位置。“變速齒輪”的故事，符合我們在系統設計方面的經驗，更適合指導企業架構層面的中臺系統建設。

兩個結論都是正確的，但不在同一個平面，我們不必將基礎設施拉進來湊數。

本文的後續討論將從這個兩個層面展開。

從企業能力層面，“資料中臺”與前臺構成了二元架構，各自歸屬於具體經營業務部門和共享能力主管部門，本文將其稱為“資料中臺”。從企業架構的層面， 如果把“資料中臺”建設成一個巨大的系統，顯然違背了“變速齒輪”的思想，要適應前臺的靈活變化，必須進一步分拆，就出現了“資料中臺系統”和若干“資料後臺”系統。我們把這個層面的“資料中臺系統”簡稱為“小中臺”

企業能力層面（二元架構）

從架構的視角看，前臺與“大中臺”組成的二元架構實質就是前後臺架構。

前臺系統是直接實現業務需求的各類資料分析系統，或者聯機系統的查詢分析模組，前臺系統緊隨業務而變化。中臺歸屬於科技部門，從而降低與業務部門的關聯性，可以從企業全域性視角進行優化。中臺的核心思想就是複用，將不同業務場景的通用能力抽離出來，下沉到一個共享平臺，更好的支援前臺系統的靈活變化。

這種架構思想的經典案例就是資料倉庫。

傳統資料倉庫（資料中臺 1.0）

理論上，資料倉庫實現複用的核心是企業資料模型，以諮詢公司的先驗模型為基礎，在業務發展過程中逐漸提煉出共性、穩定的需求豐富資料倉庫，消除加工邏輯和儲存上的冗餘；而資料集市實現個性化、易變的需求。從這個意義上來講，資料倉庫就是資料中臺的 1.0 版本。

不幸的是，工程實踐中存在很多問題。首先，判別業務穩定與否是個不小的挑戰，充斥著各種主觀標準，難以在大範圍達成共識；其次，即使那些穩定的需求，當其成為某個資料集市的核心需求時，考慮到對該集市其他功能的支撐作用，將該功能納入資料倉庫意味著整個集市的下沉，因而不具可行性；此外即便是易變的需求，當確認了需求的權威性後，也會出現在集市之間共享的情況，資料集市之間聯絡也就自然發生了。

由於上述原因，集市規模越來越大，邏輯愈加複雜，橫向聯絡逐漸增多，資料倉庫則發展緩慢。

這種架構最大的問題不是集市體量大，而在於它的不穩定性。因為其直接服務於業務部門，任何組織架構上的調整都會帶來集市的合併分拆，甚至在組織架構不變的情況下，部門經營策略的更改也會成為新建或分拆系統的動力。
當某類產品成為企業發展重點時，會出現為產品建立獨立分析系統的訴求，例如網際網路信貸產品分析系統；當某個渠道的關注度提升時，又會希望按照渠道彙總各類資訊，例如對電子銀行分析系統；再或者對某個客戶群體的重視，將催生以客戶特徵為邊界的集市，例如私人銀行客戶分析系統。

一個問題常常困擾我們，銀行到底應該建設多少個數據集市? 我想，正如康威定律的核心思想，“組織形式等同系統設計”，這個答案永遠都在隨著組織形式而改變。作為架構師，我們不希望存在複雜而需求易變的系統，因此我們選擇接受易變性，寄希望於降低系統的複雜度，阿里所提出的“大中臺、小前臺”成為一個不錯的選擇。

網際網路資料中臺（資料中臺 1.5）

最初，網際網路企業和很多中小規模的傳統企業一樣，是沒有資料倉庫的，往往以效率優先的原則建設特定系統滿足資料應用需求，這類系統實質就是“資料集市”。

企業規模擴大，“資料集市”數量不斷增加，這時重複加工、口徑不統一、成本不經濟的問題就會浮現出來，當然最更要的是對快速交付的期待。
2017 年，阿里提出的資料中臺 [4] 維持了資料倉庫架構的基本二元結構；垂直資料中心、公共資料中心、萃取資料中心是在資料處理邏輯上的分層，與傳統資料倉庫的分層有相近之處；統一資料服務中介軟體（OneService）是新增部分，體現了 DT 時代對資料價值的重視，需要更直接的方式使用資料。

網上已有很多對阿里資料中臺的解讀，這裡不再贅述，只重點談下一對 OneService 的理解。通過公開資料可知，OneService 並不是單純的 API 服務，同時涵蓋了 SQL 查詢、資料批量等方式。是否保留這些方式，我有一些不同的理解。
首先是資料批量方式，從資料倉庫的實施經驗來看，集市通常會有自我閉環趨勢，力圖減少對其他系統的依賴，其積累資料後必然進一步擴充功能，批量資料整合方式事實上是能夠為前臺的膨脹提供了基礎。約束“小前臺”最操作性的方式，AIP 服務呼叫方式替換資料整合，由於資料不落地，前臺不易積累資料以獨自完成業務需求，必須依賴中臺的支援。
再來看 SQL 查詢介面，其主要用於支援 BI 工具。SQL 直接體現了服務端的資料表結構，與物理模型設計和具體技術產品形成緊密耦合，降低了“大中臺”後續發展的彈性，甚至造成對單一資料庫產品的繫結。使用 API 可以降低這種耦合，付出的代價是弱化了前臺系統對資料加工能力。隨著 Json 介面成為 BI 工具的標準功能，API 替代 SQL 介面也具有很高的可行性。
因此，我認為依賴統一的 API 服務打通前臺與中臺的聯絡，前臺系統之間不再有直接聯絡，整體保持星型架構，能夠保證“大中臺、小前臺”架構的持續性，如下圖所示。

企業架構層面（三層架構）

二元資料中臺架構還停留在概念層面，複雜問題只是被轉移到 “資料中臺”，並沒有得到解決。正如“變速齒輪”論，前後臺的二元架構難以平衡靈活與穩定的矛盾。我們進入架構層面的討論，其拆分為三層架構，如下圖所示。

“服務聯邦層”位於三層架構的中間地帶，是我們前文中提到的“資料中臺系統”，即“小中臺”。“小中臺”整合“粗粒度服務”支援前臺系統。

資料後臺提供穩定的“細粒度服務”作為“小中臺”的整合素材，我將一類主要的服務提供方稱為“資料服務群”。“資料服務群”是資料服務的集合，業務相關性是一個重要整合維度，但同時也可以根據效能需求使用不同的底層技術平臺而剝離為不同的服務群，服務群本身是有落地資料儲存的，不同服務群之間可能存在一定冗餘，比如客戶、機構等資料。同時資料倉庫（強模型資料）、資料湖（弱模型資料）、文字檢索系統（非結構化資料）、歷史資料查詢系統（冷資料），也可提供一般效能需求的服務，與“資料服務群組”共同構成了資料後臺。技術平臺僅提供支撐作用，不歸屬於中臺或後臺。

技術可行性

“小中臺”的主要工作是進行資料集合運算，實現原有集市沉降下來的業務邏輯。“小中臺”與資料後臺基於 API 進行非同步非阻塞通訊，目的是為了解耦具體技術產品和資料模型。“小中臺”要基於後臺服務返回結果集完成各類 SQL 等效操作，有些同學可能會懷疑技術可行性。其實，今天 NewSQL 資料庫廣為所採用的資料庫引擎與 KV 儲存引擎分離的設計模式，同樣使用了服務介面進行通訊。“小中臺”不涉及資料的寫入、更改，幾乎沒有事務處理，技術難度會大幅降低。

壓縮 SQL 使用範圍

相比阿里的資料中臺，本文提出的整體架構最大程度降低了 SQL 的使用。一個敏捷的架構必然是可治理的，而資料倉庫難以治理的頑疾正在於以 SQL 為核心的 ETL 工作。

SQL是一種領域特定語言（DSL），雖然很強大但並不是很好的工程語言。由於它不能在記憶體中定義和操作複雜的資料結構，如果要做模組化的邏輯封裝，模組的輸入輸出必須是資料庫表，這就帶來了 I/O 損耗，大量的模組化，必然帶來導致 I/O 效能的顯著下降。而這些模組存在的方式只是指令碼，缺少治理工具，大量零散的模組如何管理也是一個難題。系統實施者必須在模組化和效能間權衡，效能是顯性的，直接影響使用者體驗且有明確的度量指標；模組化是隱形的，而且缺少度量工具。因此實際工程中，很少真正做到邏輯的模組化，資料庫表的層次不規範，甚至出現數千行 SQL 語句從源表加工資料直接寫入結果表。由於缺少治理工具，規範難以執行，久而久之大家也就默認了這樣的事實。

我們付出的代價是可測試性極差，每次邏輯的變化都要通過對程式碼的修改來實現而並不是新增邏輯。試想一段上千行、邏輯縱橫交錯的 SQL 語句，要在其中修改某個單點邏輯，沒有高覆蓋率的單元測試用例，如何確保正確性，最終只能依靠細心和運氣，程式碼質量必定是脆弱的，不能稱為真正的工程化專案，治理和敏捷都無從談起。

降低資料儲存冗餘

整體架構也在最大程度上壓縮資料儲存。三個層次中，只有資料後臺會落地儲存資料，“小中臺”主體由服務組成，僅保留客戶、機構等維度資料，用於提升處理效率。系統間資料冗餘是業務邏輯重複開發的土壤，需要在頂層架構設計中儘量規避。

打個比方，三層架構就像一條汽車產業鏈，“小中臺”是作為龍頭的整車生產廠，後臺是各種配件廠、發動機廠，前臺是 4S 店負責直接接觸客戶和簡單的改裝。整車廠為了避免佔用資金和倉儲，不會囤積過多的配件，而是根據整車訂單量向配件廠動態調配。我們也儘量避免資料的冗餘，降低傳輸和儲存成本，縮短資料批量加工時間。整車廠可能會複用成熟車型的部分配件（比如輪胎、發動機），改變部分配件快速推出新車型，就像我們通過中臺完成業務需求的主要邏輯。前臺的主要功能是產品交付和簡單需求的滿足，比如提供內飾甚至可以給汽車開天窗，但當多數使用者提出該需求時，整車廠會直接推出天窗版，以更標準化的方式完成，也就是前臺功能向中臺的轉移。對於配件廠商，只要保證配件持續穩定供給，如果某款配件使用在多種暢銷車型上，訂單量會大幅提升，就要升級對應的產品線提升產能，生產線的變化並不影響到整車廠。

與之相似的，某些細粒度服務被多個粗粒度服務呼叫時，導致併發訪問的提高，需要改變技術方案以處理併發和控制延時，可能會從 Oracle 切換到 HBase 或分散式資料庫上，但中臺和前臺都不會感知到這些變化。

結語

總的來說，三層架構的核心設計思想是通過 API 服務銜接前中後臺，減少資料搬家造成的冗餘控制前臺的膨脹，以無狀態服務為核心使中臺其具備橫向擴充套件能力，後臺避免鎖定技術產品和資料模型，可以根據需求的變化靈活切換到不同的解決方案；API 服務相對 SQL 指令碼具有更好的工程化特性，更便於治理，能夠形成完善的敏捷體系，從而達到快速交付需求的目標。

“資料中臺”並不是銀彈，也存在不足。以服務為核心的中臺模式並不能做百分之百的需求覆蓋，仍然忽悠一些特殊情況存在，例如一些複雜度高查詢通過“服務聯邦層”實現可能過於繁瑣，效能有明顯損耗；一些批處理任務需要資料檔案形式交付，如營銷名單、催收名單等，需要特定的方式處理。

“資料中臺”實施過程中的挑戰主要體現在“需求控制”和“技術棧變更”兩個方面。中臺是典型的橫向切分方式，必然會削弱業務需求的整體性，需要縱向增強對需求的統一管理，協調前中後臺之間的聯絡。傳統的 SQL 為核心的技能無法支撐本文的架構，開發者技術棧的大幅變更也考驗企業的技術能力和決心。

我相信未來一段時間內“資料中臺”仍然是架構領域的熱議話題，希望更多的小夥伴加入，通過不斷的實踐和探討，使其更加清晰準確，易於落地。本文僅代表個人對“資料中臺”的初步理解，涉及一些企業架構的點評，不當之處還請諒解，水平所限難免有錯漏之處，歡迎大家批評指正。

文獻參考
[1] 鍾華，企業核心業務數字化轉型最佳實踐，2018 雲棲大會
[2] 何鵬，民生銀行資料中臺體系的構建與實踐，民生大資料
[3] 張亮、蔣秀才，農業銀行：銀行業中臺系統的建設思路
[4] 張磊，阿里巴巴全域資料建設，2017 雲棲大