銀行大資料新玩法，構建“一湖兩庫”金融資料湖

　　大資料技術經過近幾年的快速發展，在企業資料中心的基礎設施上已不鮮見，尤其是金融行業，大資料技術應用一直走在其它行業前面，它們在以資料湖、融合數倉、湖內數倉(Data LakeHouse)等一些典型的技術場景中，逐步將大資料生態技術應用到金融企業的風險控制、運營管理、信貸查詢、信用卡徵信和財務分析等領域。

　　另一方面，大資料雲服務化已經提了很多年，但是目前多數大資料平臺的服務能力依舊很弱，很多企業的大資料平臺僅承擔跑批業務，除了IT崗位的使用者之外，其它的業務崗位根本感受不到大資料的存在，更談不上通過從大資料技術設施得到業務的收益。

　　其本質原因是大資料基礎平臺軟體並不具備雲服務化的基礎能力。

　　大資料雲化，提升資料投資回報率 http://ask.baikezh.com/shanxi/

　　大資料的各個元件成為一種服務化的形態，主要是將一個大資料中心的服務能力進行虛擬化，多個使用者群體可共用服務能力，單個使用者群體有類似獨佔的使用體驗，而且隨著使用者群體規模和類別的增加，資源可以輕量化彈性伸縮，自動發放與回收，底層基礎架構的耦合比較輕，甚至解耦。

　　在這種架構下，使用者的需求，可以更快地被響應和實現。

　　因為雲原生技術可以有效地縮短應用交付的週期，讓需求更快落地，最終為使用者服務，動態實現價值。

　　所以，一個本地建設的大資料中心往往需要大量的資金、人力的投入，為單個使用者群體建立專用中心是不現實的，因此大資料服務的雲化在這些場景很有價值，也可能是必須的選擇。

　　在當前的雲端計算產業商業模式下，未來金融企業的大資料基礎設施向公有云或者混合雲部署模式轉變成為必然，隨之而來的是使用者對雲服務提供商的合規和資訊保安的要求會進一步提高。

　　當大資料被賦予雲原生的含義後，大資料的真正業務價值才會逐步綻放，大資料固定資產投資才能真正變現，從而讓更多的領域從大資料中獲益，全面提升大資料的投資回報率。

　　某行大資料服務雲BDSP案例

　　煙囪式的資料平臺，導致“資料孤島”

　　全行各業務線資料量不斷增加，業務側對資料需求非常迫切，舊有的模式是業務提需求給開發中心，開發中心安排開發資源管道，大量的需求積壓，甚至由於開發週期太長導致需求已經沒有了實際意義。

　　另外行內煙囪式的資料平臺建設導致“資料孤島”，給開發人員帶來大量的資料拉取和整合的工作量。耗費了大量的人力物力以及時間，還導致了業務側的投訴和抱怨，工作效率嚴重滯後。從投資成本來看，業務倒逼IT的煙囪式的資料平臺的投資建設，耗費了龐大資金和人力投入，協同效能的提升問題凸顯。

　　資料按照業務歸入“一湖兩庫”

　　通過引入華為雲EI智慧資料湖FusionInsight提供的MRS+DWS大資料雲服務化產品，將行內的基礎資料需求按照業務劃分為資料湖、資料倉儲和集團資訊庫，即“一湖兩庫”為核心，通過不同的資料處理手段將資料持久化;通過華為MRS和DWS產品提供的元件將主流的資料處理引擎整合在大資料服務雲平臺中;再將這些資料服務以租戶渠道方式作為介面開放，例如“資料集市”、“損益預查詢”，最後使用者通過自助或者固定的應用服務渠道來獲得大資料服務，如“分析師工作臺”。

　　平臺全部嘗試採用全國產化技術，基於ARM技術伺服器和華為MRS產品構建了1000+節點的大資料雲化服務叢集。

　　

　　在行內的大資料服務雲場景中，真正提供服務核心的是一個全行共用的大資料基礎平臺(MRS+DWS)，使用服務的是多個不同的使用者群體，各使用者群體以租戶形式互相隔離(租戶渠道層)，單個租戶在限定的範圍內使用大資料的服務。

　　如上圖，大資料服務雲平臺提供使用者自服務的渠道，例如風險計量或者分析師工作臺。使用者自行管理租戶資源池內可用的資源、資料等內容。在使用過程中平臺提供使用者的驗證、訪問的管控、審計，對資源使用的計費等衍生問題的處理。

　　最後

　　將大資料基礎平臺在雲化基礎設施上的部署，使得大資料系統降低了建設、部署、運維等環節的投入，體現在在多個租戶間平攤大資料中心的建設、運維成本，提高大資料中心的使用效率。

　　而且基於存算分離的架構部署，有效的節約了儲存成本，真正做到資源的“按需分配”。

　　對於單租戶，省去了維護大資料系統帶來的龐大資金和人力投入，使得大資料系統降低了建設、部署、運維等環節的使用門檻，助力普通員工輕鬆使用大資料應用。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/30239065/viewspace-2717577/，如需轉載，請註明出處，否則將追究法律責任。