今天，中臺已經成爲架構轉型的里程碑，從互聯網到傳統企業談架構必有中臺。雖然各種中臺概念層出不窮，但“數據中臺”和“業務中臺”作爲中颱概念的起始源頭，被視爲最純正的中臺爲IT從業者所關注，也是企業架構轉型的重要目標。我所在的銀行正籌備“數據中臺”的建設，爲此在內外部組織了多次技術研討，每個人都有不同的想法，共同點僅限於希望自己的解決方案命名爲“數據中臺”。
我想這種認識的差異是源於“數據中臺”尚處在概念萌芽期，需要更多探討與碰撞。本文借鑑了互聯網公司和兩家同業銀行的案例，嘗試對“數據中臺”建設思路進行總結，所提出的架構方案僅供探討，尚未應用於實際系統建設。
傳說與誤解
在爭論什麼是“數據中臺”前，我們應該意識到“數據中臺”只是解決方案，討論的關鍵在於我們希望通過“數據中臺”解決什麼問題？
這裏先給答案，在我看來，中臺要解決的核心問題是通過能力複用，使企業能在短時間內搭建或變更前臺系統，從而快速響應用戶需求、把握市場機會。
首先我們梳理下有關“中臺”的傳說。
作爲這一波“中臺”概念的源頭，第一個傳說必須來自阿里。
首先是“遊戲公司”的故事，大致是這樣，阿里的馬老師帶隊參觀了一家厲害的遊戲公司Supercell，它有很多成功的遊戲產品，其獨特優勢是能夠快速推出新產品，而依靠的就是中臺系統。馬老師受到了啓發，回到阿里開始推進中臺建設，在組織架構層面成立了單獨的中臺部門即“共享業務事業部”，系統層面建設了用戶中心、支付中心等共享服務同時支持淘寶、天貓、1688等業務條線，最終也實現了快速的前臺產品研發。這些中臺服務被統稱爲“業務中臺”。
通過這個故事，我們可以得出第一個結論。中臺應該提供“共享服務能力”，這種共享源於對業務場景的抽象、提煉、沉澱。
關於中臺的第二個傳說是“變速齒輪”，相對技術化和抽象一些。當前按的IT架構通常是由前臺和後臺組成，前臺系統接觸用戶，後臺系統提供基礎服務。兩者一個需要靈活快速，一個需要穩定高效，兩者在變更速率上不匹配，制約了對用戶需求的快速響應。中臺的誕生銜接了前後臺系統，保證後臺穩定的同時又支持了前臺的靈活。
這樣我們有了第二個結論，中臺意味着了前中後的三層體系架構，三者的變更速率可以實現更平緩的過渡，從而兼顧整個體系的靈活與穩定。
但有一個問題始終困擾着我，基於前兩個結論，可知是存在“業務後臺”和“數據後臺”的，那又是指什麼呢？這個概念不澄清，體系就是不完整的。
帶着這個疑問，我們來看看具體案例。
首先是阿里的雙中臺架構。
圖中標註了組織架構層面的前臺、中臺和後臺，但並沒有給出業務後臺和數據後臺的邊界與定義，從字面上看後臺與中臺的關聯性也較弱。
民生銀行的數據中臺體系技術方案[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雲棲大會
作者介紹：
王磊，光大銀行企業架構師，Pharos架構設計和主要開發者，曾任職於IBM全球諮詢服務部從事技術諮詢工作，具有十餘年數據領域研發及諮詢經驗。目前負責全行數據領域系統的日常架構設計、評審及內部研發等工作，對分佈式數據庫、Hadoop等基礎架構研究有濃厚興趣。