資料中臺設計方法論
資料中臺建設方針:橫向規劃,各個擊破,
橫向規劃即在資料中臺規劃初期,需要打通企業各個業務系,打破資料孤島現象,其實就是我們建設資料倉庫的階段,比如電信業務,我們要把客戶、賬務、客服、營銷等業務板塊打通資料,全盤考慮,融通資料形成資料資產,
資料中臺建設程序中涉及到大資料平臺建設、資料倉庫建設、模型演算法、資料治理、資料服務等一系列工程,不可能一蹴而就,我們需要梳理業務場景,看他們需要什么樣的服務先找一個業務場景,搭建起資料中臺的服務能力,然后依次迭代,各個擊破,
一、總體規劃
資料集成
首先我們需要確認平臺接入哪些資料,確認資料接入的方式是實時接入還是離線抽取,離線抽取的話是全量抽取還是增量抽取,抽取頻次數每天抽取還是每小時抽取,
實時接入可以使用kafka實時寫入資料到HDFS集群上,
離線資料可以使用Sqoop抽取關系型資料庫到HDFS,
模型建設
模型建設是資料中臺的重要部分,可以說資料中臺的成敗在于模型建設的好壞,模型分為我們常指的資料倉庫的分析模型和我們的一些通用演算法模型,
分析模型
資料接入到資料倉庫中,我們需要對資料進行加工,按照我們規劃的業務域,對各個業務的資料匯總聚合,形成我們的資料模型,
這其中涉及到資料倉庫建設,在這簡單說下,
這是一個簡單的資料分層結構,原始資料ODS,經過清洗成為數倉中的明細資料DWS和維度資料DIM,各個業務的明細資料按照業務域和維度資料關聯形成我們的資料模型DW,不同的DW經過聚合形成各個業務指標資料APP層,
在數倉的建設中我們宣告業務粒度,粒度能夠精確的表明業務含義,同時還要確定維度,是用戶維度還是商品維度等,最終形成我們的主資料,也就是模型資料的基礎,
演算法模型
我們在業務開發程序中會形成一些通用的演算法,可以是封裝好的隨機森林、回歸等通用演算法,也可以是我們業務演算法,比如用戶商品推薦演算法等,通過把這些演算法總結,形成我們的演算法模型,供各個業務直接呼叫,
ETL平臺
在開發資料模型時,我們必須有一個統一的平臺,能夠像流水線一樣,把資料一步步加工成資料模型,這其中涉及到資料萃取、資料聚合、作業調度等,
與業務研發不同,資料研發一般很少寫詳細的需求涉及檔案,通常就是和業務人員簡單的溝通,但是慢慢的你會發現開發完的任務會一改再改,為了避免此種現象,我們可以根據自己的實際業務整理一份需求模板,其中包括資料來源欄位,資料口徑,任務調度周期,欄位mapping,
資料資產
通俗的來說,我們在數倉中開發的模型就是資料資產,資料資產需要規范的管控和治理,
資產管理最基礎的作業是做好元資料的管理,元資料包含了資料的口徑,資料模型的釋義,模型之間的血緣等等,詳細的可以看之前的元資料文章《資料倉庫元資料》,將元資料和資料模型統一有序的管理起來形成企業的資料資產,
資料資產治理不是在事后管控的,在我們建設模型的程序中需要形成一套自己的數倉開發規范進行管理,
資料服務
俗話說,酒香也怕巷子深,我們做好資料資產后,要推銷我們的資產,為更多部門使用,這也是資料中臺建設的初衷,因此提供一套資料服務能力,對外統一對接是一件很重要的作業,
資料服務標準:資料結構標準化、在線查詢實時化、資料開發可視化,
資料結構標準化
針對資料互動,我們需要提供統一的介面視圖,可進行資料的查詢、權限管控,
在線查詢實時化
針對各業務的呼叫,我們需要提供指標級資料口徑統一的實時資料結果,
資料開發可視化
提供資料介面的可視化統一管理頁面,開發人員通過通過可視化管理API,降低介面理解的難度,易于維護,
討論
關于資料中臺的建設,最初是阿里提出來的,但是這之前,很多企業其實已經有了類似的想法,也實施了部分,對于大型集團企業,中臺方法論很實用,打破了集團各版塊的資料孤島,形成了統一的資料服務能力,但是慢慢的很多人提出了,對于中小企業,中臺方法論是不是太繁瑣了,對于他們來說是負擔,中小企業需要的也許是更快捷的迭代形式的資料服務,
那么關于中臺建設,你怎么看呢?你的企業會選擇中臺嗎?
歡迎關注公眾號:資料社
轉載請註明出處,本文鏈接:https://www.uj5u.com/shujuku/4558.html
標籤:大數據
下一篇:Hive決議多重嵌套JSON陣列
