“數據中臺”的再思考

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

一、傳說與誤解

????在爭論什么是“數據中臺”前,我們應該意識到“數據中臺”只是解決方案,關鍵在于通過“數據中臺”解決什么問題?在我看來,中臺要解決的核心問題是在短時間內搭建或變更前臺系統,從而快速響應用戶需求、把握市場機會。

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

????作為這一波“中臺”概念的源頭,第一個傳說必須來自阿里。“游戲公司”的傳說,大致是這樣,阿里的馬老師帶隊參觀了一家厲害的游戲公司 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 云棲大會

posted @ 2019-12-04 09:13  海邊的Ivan  閱讀(...)  評論(...編輯  收藏
七乐彩2011年走势图南方双彩