「數據中臺」的再思考

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

1、傳說與誤解

    在爭論什麼是「數據中臺」前，咱們應該意識到「數據中臺」只是解決方案，關鍵在於經過「數據中臺」解決什麼問題？在我看來，中臺要解決的核心問題是在短期內搭建或變動前臺系統，從而快速響應用戶需求、把握市場機會。

    首先咱們梳理下有關「中臺」的傳說。

    做爲這一波「中臺」概念的源頭，第一個傳說必須來自阿里。「遊戲公司」的傳說，大體是這樣，阿里的馬老師帶隊參觀了一家厲害的遊戲公司 Supercell，它有不少成功的遊戲產品，其獨特優點是可以快速推出新產品，而依靠的就是中臺系統。馬老師受到了啓發，回到阿里開始推動中臺建設，在組織架構層面成立了單獨的中臺部門即「共享業務事業部」，系統層面建設了用戶中心、支付中心等共享服務同時支持淘寶、天貓、1688 等業務條線，最終也實現了快速的前臺產品研發。這些中臺服務被統稱爲「業務中臺」。經過這個故事，咱們能夠得出第一個結論。中臺應該提供「共享服務能力」，這種共享源於對業務場景的抽象、提煉、沉澱。

    關於中臺的第二個傳說是「變速齒輪」，相對技術化和抽象一些。當前的IT 架構一般是由前臺和後臺組成，前臺系統接觸用戶，後臺系統提供基礎服務。二者一個須要靈活快速，一個須要穩定高效，二者在變動速率上不匹配，制約了對用戶需求的快速響應。中臺的誕生銜接了先後臺系統，保證後臺穩定的同時又支持了前臺的靈活。

    這樣咱們有了第二個結論，中臺意味着了前中後的三層體系架構，三者的變動速率能夠實現更平緩的過渡，從而兼顧整個體系的靈活與穩定。但有一個問題始終困擾着我，基於前兩個結論，可知是存在「業務後臺」和「數據後臺」的，那又是指什麼呢？這個概念不澄清，體系就是不完整的。帶着這個疑問，咱們來看看具體案例。首先是阿里的雙中臺架構[1]。

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

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

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

    看過兩家銀行架構，咱們彷佛能夠獲得一個推論，後臺是技術平臺或基礎設施。但這二者一般是與業務無關的，會制約前臺業務的靈活性嗎？基礎設施和技術平臺同時支持了前臺和中臺，在層級並非一個遞進關係呀？這個分層彷佛有點奇怪，有點牽強。

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

    前臺部門直接面對用戶和創造利潤；阿里「共享服務事業部」更多參與到了業務中，很是適合中臺的定位。然後臺主要是輔助做用，一般也就不會受到用戶需求的影響，企業甚至行業間的差別都比較小，所以在以快速響應爲核心的方案中將其忽略也就瓜熟蒂落的事了。進一步研究發現，本文觀點與網易對中臺的見解較爲接近。對於數據中臺，網易杭州研究院執行院長汪源給出的定義以下，「全部的中臺都是業務中臺，數據中臺是業務中臺的特殊形式。中臺是區別於平臺的，具有業務屬性、支撐多個前臺業務的產品，其本質是公司業務能力的沉澱。」

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

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

    本文的後續討論將從這個兩個層面展開。從企業能力層面，「數據中臺」與前臺構成了二元架構，各自歸屬於具體經營業務部門和共享能力主管部門，本文將其稱爲「數據中臺」。從企業架構的層面， 若是把「數據中臺」建設成一個巨大的系統，顯然違背了「變速齒輪」的思想，要適應前臺的靈活變化，必須進一步分拆，就出現了「數據中臺系統」和若干「數據後臺」系統。咱們把這個層面的「數據中臺系統」簡稱爲「小中臺」

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

    從架構的視角看，前臺與「大中臺」組成的二元架構實質就是先後臺架構。前臺系統是直接實現業務需求的各種數據分析系統，或者聯機系統的查詢分析模塊，前臺系統緊隨業務而變化。中臺歸屬於科技部門，從而下降與業務部門的關聯性，能夠從企業全局視角進行優化。中臺的核心思想就是複用，將不一樣業務場景的通用能力抽離出來，下沉到一個共享平臺，更好的支持前臺系統的靈活變化。

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

傳統數據倉庫（數據中臺 1.0）

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

    不幸的是，工程實踐中存在不少問題。首先，判別業務穩定與否是個不小的挑戰，充斥着各類主觀標準，難以在大範圍達成共識；其次，即便那些穩定的需求，當其成爲某個數據集市的核心需求時，考慮到對該集市其餘功能的支撐做用，將該功能歸入數據倉庫意味着整個集市的下沉，於是不具可行性；此外即使是易變的需求，當確認了需求的權威性後，也會出如今集市之間共享的狀況，數據集市之間聯繫也就天然發生了。

    因爲上述緣由，集市規模愈來愈大，邏輯越發複雜，橫向聯繫逐漸增多，數據倉庫則發展緩慢。

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

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

互聯網數據中臺（數據中臺 1.5）

    最初，互聯網企業和不少中小規模的傳統企業同樣，是沒有數據倉庫的，每每以效率優先的原則建設特定系統知足數據應用需求，這類系統實質就是「數據集市」。

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

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

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

    二元數據中臺架構還停留在概念層面，複雜問題只是被轉移到 「數據中臺」，並無獲得解決。正如「變速齒輪」論，先後臺的二元架構難以平衡靈活與穩定的矛盾。咱們進入架構層面的討論，其拆分爲三層架構，以下圖所示。

「服務聯邦層」位於三層架構的中間地帶，是咱們前文中提到的「數據中臺系統」，即「小中臺」。「小中臺」整合「粗粒度服務」支持前臺系統。

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

技術可行性

    「小中臺」的主要工做是進行數據集合運算，實現原有集市沉降下來的業務邏輯。「小中臺」與數據後臺基於 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 雲棲大會