中小型城市商業銀行數字化轉型實踐(三)資料中臺建設思路和路徑

資料資產變現能力一直是困擾中小型城市商業銀行業務運營轉型的關鍵痛點，雖然透過試點引入外部資料，引入實時計算引擎和資料建模，在輔助營銷決策，網貸風控等方面做了一些嘗試，但是還沒有找到為銀行數字化運營賦能的關鍵。

一、現狀和痛點

目前中小型城市商業銀行在資料方面存在以下的痛點：

業務層面

資料研發中心無法快速支援業務資料任務要求

各個系統提供的資料標準規範不一致，主要體現在命名規範不一致、不同的人所跑出來的資料分析結果不一致，資料統計口徑不一致

部分行有資料門戶，但是業務部門無法操作，無法自助快速獲取資料

資料應用大部分面向統計報表和監管報送，面向業務應用支援能力幾乎沒有。

資料孤島現象還是比較嚴重。特別是業務相關資料的融通和價值發掘不夠。

技術層面

城商行煙囪式專案建設模式，給資料建設帶來災難性後果，資料標準、規範無法按預期實施。資料質量提高與預期相去勝遠。

煙囪式專案建設模式很多內容重複建設，資料研發中心處理任務量冗長，處理效率低

不能專注與資料價值發掘的工作，每天疲於應對業務部門的資料任務要求

資料研發中心生產任務繁重，計算資源緊張，資料批次計算慢，時效性不強。

面對這些痛點，部分銀行想透過資料治理專案來解決問題，投入了大量人力，財力之後發現煙囪式的外包專案建設模式下資料治理由於沒有落地抓手，最終只能得到一大堆的文件，成效甚微。所以絕大部分的資料治理專案是失敗的。

二、契機

隨著技術的不斷進步，軟體架構在不斷演進，微服務架構當今大行其到，銀行所採購的業務商用軟體也基本上被java生態覆蓋，資料建模、規範方面也趨於統一。同質化的建設模式，為銀行資料規範化帶來了契機。

資料處理技術也在飛速的發展，lambda架構利用大資料的計算能力對外提供離線+實時資料服務。近兩年以Flink為代表的資料批流一體化模式在計算層面實現了統一的計算框架支撐，批處理僅作為流處理的一個特殊場景納入框架中，使得實時業務分析場景技術可以在銀行業務場景中大量使用，離線計算模式的不斷演進也使得銀行批流處理效能得到質的飛躍。

資料中臺的思想也受到業界熱捧，資料中臺在資料研發中心內部成為一個數據治理落地的抓手，使得資料治理不在停留在表面；也極大的提升了銀行資料資產變現的能力，使得資料能夠為銀行的業務應用提供運營支撐。

引入資料中臺，已經成為銀行數字化轉型途徑上比業務中臺更能讓讓各方達成一致的一個環節。但是資料中臺其實是一個建設模式和方法論，是重新購買一套成熟的資料中臺產品，還是在現有資料倉庫基礎上按照中臺的思路建設，成為資料中臺落地的爭論點。

三、資料中臺建設思路和步驟

1、中小型城商行數倉建設現狀

中小型城商行數倉建設大概有以下幾種：

傳統數倉

主要負責全行報表、經營資料指標供數和監管報送

傳統數倉+大資料平臺

主要服務報表、經營資料指標供數和監管報送

歷史明細整合查詢

客戶360檢視

高管駕駛艙供數

網貸實時授信

智慧營銷支援

大資料平臺

功能同傳統數倉+大資料平臺

2、傳統數倉和資料中臺定位

3、傳統數倉和資料中臺功能邊界

總結一下，資料中臺主要是建立健全全行資料資產管控能力，面向全行業務應用提供資料決策，實時資料分析等資料化運營能力。傳統數倉，是面向行內資料，給報表和決策支援系統供數，並且數倉建設過程中對於資料資產的管控能力較弱，資料管控沒有形成完整意義上的閉環。

四、資料中臺建設思路和路徑

其實不管是傳統數倉和資料中臺，對於資料資產管理的建設思想並沒有太大區別，主要區別是傳統數倉積累了非常多了技術債，所以在資料資產管理上有非常多的痛點。給業務和業務運營提供的能力支撐也非常的弱。

資料中臺主要是為業務轉型和運營提供智慧資料化支撐，深入各類業務場景，並且利用現有先進的架構和技術（主要是先進的資料底盤）對資料資產管理能力進行重構。

資料中臺的能力完全可以覆蓋傳統數倉的能力，但是銀行對業務風險和監管報送的零容忍不可能讓我們擼起袖子就替換，在建設過程中必須考慮傳統業務穩定性、中臺建設過程中短期效能體現的業務目標，資訊科技人員能力匹配程度，以及業務人員的逐步接受適應情況。因此對於中小型城市商業銀行個人認為比較理想的建設路徑和思路是：

最穩路徑（多少有些無奈）

這個實時路徑的整個架構前提是在中臺實施期間儘量保持穩態傳統能力不做功能修改，您可能覺得這個是個很可笑的事情，但是中小型城商行的科技現狀卻是是比較堪憂的，大部分科技人員甚至中層領導是拒接走出舒適圈的。

所以這個是一個最把穩的路徑，如果您所在機構有能力有意願做好資料中臺，又能大量的投入人力物力，那麼可以使用跟激進的一些建設路徑，在建設資料中臺的時候就可以落地實施過度方案，中臺建成後很多能力可以一次性過度到中臺，特別是資料視覺化和降低資料使用門檻的能力可以提前考慮。

五、雙態架構資料中臺技術架構全圖

1、整體技術架構圖（涉及到的開源技術框架，產品就不在這裡詳細描述，後續章節會有詳細描述）

2、最終替換後的資料流圖

六、實施過程中需要關注的技術關鍵點

由於是購買大廠的產品，資料中臺和底盤的技術選型很重要，這裡不便多描述，一旦選定之後其實整體技術框架，產品元件我們是沒法自己再去幹預的，所以這塊不是技術關注的關鍵點。

技術關注關鍵點我認為有一下幾個：

並行期資料中臺和原數倉並且的業務邊界要劃清楚，雖然有了前面的架構設計原則，但是如果您想進一步深入的話就要把邊界劃清楚。

並行期根據您的規劃明確資料中臺和原數倉資料交付方式，特別要明確要從原數倉的哪個層去抽取資料。

涉及到業務中臺使用者、賬戶等資料的支援，需要與原業務系統進行資料同步，優先採用資料庫級別準實時同步，當然關鍵資料需要採用實時同步需要對 OGG/Canal/DTS——>Flume——>kafka——>中臺對應業務庫的流程中詳細設計，業務層面也需要準備查詢不到去穩態拉資料的機制。

關注資料API的定位和使用情況

要明確分散式事情的範圍，不是所有事務都要使用分散式事務。（這個好像跟主題沒多大關係）

資料規範這個關一定要把住

七、最後

有些人會覺得方案很low，但是如果您瞭解城商行的現狀，我想多半會同意我的一些觀點。當然你所供職的機構是土豪，完全可以自研，其實大資料框架，實時計算框架，訊息佇列等等都是都有開源軟體支援，但是要踩多少雷？多少坑真？這種付出是城商行無法承受的。

後續會深入技術細節做一些討論。