今天，中台已經成為架構轉型的里程碑，從互聯網到傳統企業談架構必有中台。雖然各種中台概念層出不窮，但“數據中台”和“業務中台”作為中台概念的起始源頭，被視為最純正的中台，也是企業架構轉型的重要目標。我所在的銀行正籌備“數據中台”的建設，為此在內外部組織了多次技術研討，每個人都有不同的想法，共同點僅限於 ...
今天，中台已經成為架構轉型的里程碑，從互聯網到傳統企業談架構必有中台。雖然各種中台概念層出不窮，但“數據中台”和“業務中台”作為中台概念的起始源頭，被視為最純正的中台，也是企業架構轉型的重要目標。我所在的銀行正籌備“數據中台”的建設，為此在內外部組織了多次技術研討，每個人都有不同的想法，共同點僅限於希望自己的解決方案命名為“數據中台”。我想這種認識的差異是源於“數據中台”尚處在概念萌芽期，需要更多探討與碰撞。本文藉鑒了互聯網公司和兩家同業銀行的案例，嘗試對“數據中台”建設思路進行總結，所提出的架構方案僅供探討，尚未應用於實際系統建設。
傳說與誤解
在爭論什麼是“數據中台”前，我們應該意識到“數據中台”只是解決方案，討論的關鍵在於我們希望通過“數據中台”解決什麼問題？這裡先給答案，在我看來，中台要解決的核心問題是在短時間內搭建或變更前臺系統，從而快速響應用戶需求、把握市場機會。
首先我們梳理下有關“中台”的傳說。
作為這一波“中台”概念的源頭，第一個傳說必須來自阿裡。“游戲公司”的傳說，大致是這樣，阿裡的馬老師帶隊參觀了一家厲害的游戲公司 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 雲棲大會
