數(shù)據(jù)倉庫,對從事IT行業(yè)的從業(yè)者來說并不是個陌生的名詞,這個概念由數(shù)據(jù)倉庫之父Bill Inmon在1991年出版的“Building the Data Warehouse”中定義的——面向主題的、集成的、相對穩(wěn)定的、反映歷史變化的數(shù)據(jù)集合,用于支持決策管理。從定義可以了解到,數(shù)據(jù)倉庫具有以下關鍵特性:
面向主題
數(shù)據(jù)倉庫歸集全行數(shù)據(jù)并按特定主題梳理,方便使用者按主題編目快速查找到所需數(shù)據(jù)并使用;
數(shù)據(jù)集成
數(shù)據(jù)倉庫歸集全行數(shù)據(jù),打破系統(tǒng)間數(shù)據(jù)孤島的局面,從而為后續(xù)的決策管理與數(shù)據(jù)服務提供強大的數(shù)據(jù)支撐;
相對穩(wěn)定
建設數(shù)據(jù)應用時,最擔憂是源系統(tǒng)的數(shù)據(jù)模型變更導致“牽一發(fā)而動全身”。每次模型變更都伴隨著數(shù)據(jù)應用的影響分析和變更開發(fā),既對開發(fā)團隊造成極大的工作負擔,又影響數(shù)據(jù)應用的穩(wěn)定性。數(shù)據(jù)倉庫可通過分層架構“內(nèi)部消化”源系統(tǒng)模型變更帶來的影響,且無需變更數(shù)據(jù)服務接口,保證數(shù)據(jù)應用的穩(wěn)定性;
反映歷史變化
數(shù)據(jù)倉庫會記錄數(shù)據(jù)的歷史軌跡,用于查詢?nèi)我鈺r點的數(shù)據(jù)快照從而分析特定時間范圍的數(shù)據(jù)趨勢,為決策管理提供數(shù)據(jù)支持。
理解了數(shù)據(jù)倉庫的關鍵特性,相當于了解了建設數(shù)據(jù)倉庫的正確方向,但是,并不代表就清楚數(shù)據(jù)倉庫的建設目標和建設路徑。特別對于銀行機構,對數(shù)據(jù)的穩(wěn)定性、準確性與時效性要求都比一般企業(yè)要高。那么,銀行數(shù)據(jù)倉庫的建設目標與建設路徑分別是什么,接下來將分為三個章節(jié)去闡述。
銀行數(shù)據(jù)倉庫畫像
互聯(lián)網(wǎng)對于傳統(tǒng)行業(yè)的沖擊是全方位的,無論是百貨、商場、菜市場等零售行業(yè),還是銀行、財務公司等金融行業(yè),都對其經(jīng)營模式進行“降維打擊”,迫使傳統(tǒng)行業(yè)業(yè)務進行線上化轉型。尤其是銀行,在互聯(lián)網(wǎng)發(fā)展前,基本都是躺著賺錢,是大家眼中的金飯碗,結果在互聯(lián)網(wǎng)發(fā)展后,尤其是互聯(lián)網(wǎng)金融逐漸的壯大,都被迫喊出“銀行是弱勢群體”的話語,其程度可想而知?;ヂ?lián)網(wǎng)經(jīng)營模式對比銀行傳統(tǒng)的經(jīng)營模式領先是多方面的,以下列表僅從數(shù)據(jù)的角度進行分析。
上述對比的結果,揭示了互聯(lián)網(wǎng)經(jīng)營模式領先的要點之一是數(shù)字化的業(yè)務運營,所以銀行經(jīng)營模式想要跟上時代的步伐,關鍵點是數(shù)字化轉型。
在銀行逐漸認識到數(shù)據(jù)價值后,也開展了自身的數(shù)字化轉型之路。然而在邁向的過程中,卻發(fā)現(xiàn)猶如進入迷宮一樣,資源是大力投入了,成效卻遠遠未達到預期想象,甚至還影響到原有業(yè)務開展。
業(yè)務數(shù)據(jù)仍以數(shù)據(jù)孤島的方式存在,大量的數(shù)據(jù)仍未形成合力,難以產(chǎn)生巨大的價值;
由于數(shù)據(jù)孤島的存在,數(shù)據(jù)應用只能局限于系統(tǒng)內(nèi),可發(fā)揮的空間不大;
數(shù)據(jù)孤島的各自為政,造成各個系統(tǒng)的數(shù)據(jù)都擁有一套獨立的標準,使得系統(tǒng)間的數(shù)據(jù)聯(lián)系更加復雜與困難。且標準各異的數(shù)據(jù)難以測量數(shù)據(jù)質(zhì)量,數(shù)據(jù)治理勢必成為下一階段的工作重心;
缺乏統(tǒng)一的數(shù)據(jù)管理,無法有效發(fā)揮數(shù)據(jù)的使用價值,也無法互相分享數(shù)據(jù)成果,從而導致另一個問題——煙囪式建設。
解決上述數(shù)字化轉型遇到的痛點,需要打破數(shù)據(jù)孤島、形成數(shù)據(jù)合力、建設數(shù)據(jù)質(zhì)量體系,這時就需要一個數(shù)據(jù)管理核心,來支撐全行數(shù)據(jù)應用。這個數(shù)據(jù)管理核心就是數(shù)據(jù)倉庫。
細化數(shù)據(jù)倉庫目標,描繪出數(shù)據(jù)倉庫的畫像。
全行數(shù)據(jù)歸集
將全行數(shù)據(jù)歸集到數(shù)據(jù)倉庫中,從而打破數(shù)據(jù)孤島,實現(xiàn)數(shù)據(jù)集中管理及關聯(lián)分析,產(chǎn)生1+1>2的價值;
數(shù)據(jù)質(zhì)量體系
主要分為兩個方面,其一是建設數(shù)據(jù)統(tǒng)一標準。標準各異的數(shù)據(jù)會對數(shù)據(jù)梳理整合造成巨大的阻礙,數(shù)據(jù)統(tǒng)一標準應從業(yè)務屬性、技術屬性及操作屬性三方面進行。其二是做好元數(shù)據(jù)管理,元數(shù)據(jù)是系統(tǒng)建設過程產(chǎn)生的描述數(shù)據(jù),包含系統(tǒng)設計、數(shù)據(jù)模型、數(shù)據(jù)字典、運行日志等,管理好元數(shù)據(jù)有助于系統(tǒng)維護及可持續(xù)發(fā)展;
數(shù)據(jù)價值挖掘
基于全行數(shù)據(jù)的關聯(lián)與分析,挖掘數(shù)據(jù)間的聯(lián)系與價值,實現(xiàn)智能營銷與風控;
商業(yè)智能決策
使用可視化的數(shù)據(jù)分析工具把數(shù)據(jù)圖形化、直觀化呈現(xiàn),幫助業(yè)務人員了解數(shù)據(jù)的變化與趨勢,從而快速高效形成決策;
數(shù)據(jù)服務支撐
提供統(tǒng)一、共享的數(shù)據(jù)接口滿足全行應用系統(tǒng)的數(shù)據(jù)服務需求;
數(shù)據(jù)資產(chǎn)管理
數(shù)據(jù)倉庫既屬于數(shù)據(jù)管理核心,也屬于數(shù)據(jù)資產(chǎn)核心。對內(nèi)而言,數(shù)據(jù)倉庫將全行數(shù)據(jù)進行歸集并整合,為全行業(yè)務應用提供數(shù)據(jù)服務;對外而言,涉及營銷與風控的價值數(shù)據(jù),比如客戶畫像、欺詐名單、老賴名單,對其他銀行具有強大的吸引力,可通過有償查詢的方式形成創(chuàng)新業(yè)務。
銀行數(shù)據(jù)倉庫的畫像清晰了,建設目標也明確了,但,該如何構建數(shù)據(jù)倉庫?
淺談數(shù)據(jù)倉庫建設
宏觀理解銀行數(shù)據(jù)倉庫的整體架構,有利于下一步理解數(shù)據(jù)倉庫的建設路徑。從整體架構,主體模塊的功能說明與職責分工如下所示:
數(shù)據(jù)總線
數(shù)據(jù)倉庫作為數(shù)據(jù)管理核心,必須擁有統(tǒng)一標準的數(shù)據(jù)輸入接口與數(shù)據(jù)輸出通道,才能保證數(shù)據(jù)輸入輸出的穩(wěn)定性。但是數(shù)據(jù)輸入輸出會造成數(shù)據(jù)倉庫的資源損耗,尤其是IO與網(wǎng)絡,所以建設數(shù)據(jù)總線系統(tǒng)可把數(shù)據(jù)輸入輸出功能與數(shù)據(jù)倉庫解耦,讓數(shù)據(jù)倉庫專注于數(shù)據(jù)的整合與計算任務。
數(shù)據(jù)倉庫分層
數(shù)據(jù)倉庫分層架構為ODM層、SDM層、FDM層及ADM層。對上述分層方式可能有童鞋會有這樣的疑問:為什么沒有共性模型層?每個數(shù)據(jù)層的定義與職責,以及共性模型層的疑問將在下文逐步介紹,有興趣的童鞋也可以查閱作者的文章《淺談銀行的數(shù)據(jù)倉庫:分層架構篇》;
數(shù)據(jù)服務
分為SOA接口與文件接口兩種方式,分別提供實時與離線的數(shù)據(jù)服務。由于應用系統(tǒng)調(diào)用數(shù)據(jù)服務接口同樣會造成數(shù)據(jù)倉庫的IO與網(wǎng)絡資源損耗,所以建設數(shù)據(jù)服務系統(tǒng)可把調(diào)用數(shù)據(jù)服務功能與數(shù)據(jù)倉庫解耦,同時也避免應用系統(tǒng)直接訪問數(shù)據(jù)倉庫所造成的數(shù)據(jù)安全風險;
調(diào)度管理
負責數(shù)據(jù)倉庫所有作業(yè)(含數(shù)據(jù)總線的ETL作業(yè))的調(diào)度配置、依賴配置、日切機制及執(zhí)行監(jiān)控;
元數(shù)據(jù)管理
負責對元數(shù)據(jù)的錄入與查詢。對數(shù)據(jù)倉庫而言,比較重要的元數(shù)據(jù)有數(shù)據(jù)字典、血緣關系、指標口徑、數(shù)據(jù)映射(mapping)及參考數(shù)據(jù)(碼表與系統(tǒng)參數(shù));
質(zhì)量管理
負責兩大功能——數(shù)據(jù)核檢及質(zhì)量評分。
數(shù)據(jù)核檢分為表內(nèi)核檢與表間核檢兩種方式。表內(nèi)核檢主要是數(shù)據(jù)格式核檢,依據(jù)數(shù)據(jù)標準對數(shù)據(jù)的長度、格式、范圍、非空等維度進行檢查。除了數(shù)據(jù)格式核檢外,還有表內(nèi)數(shù)據(jù)勾稽關系核檢,保證表內(nèi)統(tǒng)計結果的一致性。表間核檢主要是檢查跨系統(tǒng)的數(shù)據(jù)勾稽關系,比如總賬科目與交易明細的總分核對。所有的核檢結果均以日志的方式輸出,便于數(shù)據(jù)治理團隊推進數(shù)據(jù)質(zhì)量提升的工作。
質(zhì)量評分依賴數(shù)據(jù)核檢結果,對各個源系統(tǒng)的數(shù)據(jù)質(zhì)量進行綜合評分,主要用于考核源系統(tǒng)的數(shù)據(jù)質(zhì)量完善程度,并對開發(fā)團隊實施獎懲機制,推進數(shù)據(jù)質(zhì)量提升的工作。
安全管理
負責兩大功能——數(shù)據(jù)生命周期管理及數(shù)據(jù)安全策略。
數(shù)據(jù)生命周期管理主要是設定數(shù)據(jù)的有效期及自動處理策略。當數(shù)據(jù)達到有效期時,會自動把過期數(shù)據(jù)進行文本導出、分表、清理等操作,避免數(shù)據(jù)存儲過大造成的一系列系統(tǒng)問題。
數(shù)據(jù)安全策略主要設定數(shù)據(jù)的權限,包括查詢、下載、分享、補錄等權限,避免敏感數(shù)據(jù)泄露。
數(shù)據(jù)總線
在整體架構的分享中,已說明數(shù)據(jù)總線會作為數(shù)據(jù)倉庫統(tǒng)一標準的數(shù)據(jù)輸入與數(shù)據(jù)輸出的通道;
數(shù)據(jù)交互建議使用文本方式進行,解除數(shù)據(jù)倉庫與上下游系統(tǒng)端對端的強耦合,使數(shù)據(jù)交互專注在接口標準和數(shù)據(jù)結構,同時也避免上下游系統(tǒng)直連帶來的奇奇怪怪問題;
無論是數(shù)據(jù)加載還是數(shù)據(jù)抽取,其執(zhí)行流程基本是固定的。比如數(shù)據(jù)加載的執(zhí)行流程為:
所以可以設計通用程序實現(xiàn)標準化的數(shù)據(jù)加載與數(shù)據(jù)抽取,既可大大減輕開發(fā)團隊的工作量,也可以增強數(shù)據(jù)總線的穩(wěn)定性。
數(shù)據(jù)倉庫ODM層
ODM的英文全稱是Origin Data Manager,即數(shù)據(jù)倉庫的貼源層,顧名思義,數(shù)據(jù)層的數(shù)據(jù)結構跟源系統(tǒng)的數(shù)據(jù)結構一致。數(shù)據(jù)總線把每日采集的源系統(tǒng)增量數(shù)據(jù)文本加載到ODM層中;
ODM層由于僅保留源系統(tǒng)當日增量數(shù)據(jù),且數(shù)據(jù)結構與源系統(tǒng)一致,故數(shù)據(jù)加載速度是極快的,無需擔心貼源層的數(shù)據(jù)加載對數(shù)據(jù)倉庫性能造成影響;
由于ODM層的數(shù)據(jù)結構與源系統(tǒng)一致,所以排查數(shù)據(jù)質(zhì)量問題時可通過ODM層溯源排查。當然,ODM層僅保留當日增量數(shù)據(jù)的設計會限制溯源的范圍,這是使用關系型數(shù)據(jù)庫搭建數(shù)據(jù)倉庫造成存儲成本極高的緣故。當前使用大數(shù)據(jù)技術框架搭建數(shù)據(jù)倉庫,可使用普通磁盤存儲數(shù)據(jù),使得存儲成本大幅降低,所以也保留ODM層貼源數(shù)據(jù)的歷史軌跡。從很多銀行搭建歷史數(shù)據(jù)查詢平臺來看也能說明這一點;
雖然ODM層只是加載源系統(tǒng)的每日增量數(shù)據(jù),且數(shù)據(jù)結構與源系統(tǒng)一致,無任何復雜加工,但很多開發(fā)團隊會因不重視導致底層數(shù)據(jù)加載出錯,引發(fā)連鎖的數(shù)據(jù)問題。解決方案可參考數(shù)據(jù)總線,關鍵是做好監(jiān)控保證數(shù)據(jù)加載的準確性與穩(wěn)定性。
數(shù)據(jù)倉庫SDM層
SDM的英文全稱是Standard Data Manager,即數(shù)據(jù)倉庫的標準數(shù)據(jù)層,顧名思義,該數(shù)據(jù)層主要用于數(shù)據(jù)標準落地。除了數(shù)據(jù)貫標的職責外,還要負責記錄數(shù)據(jù)歷史軌跡,合成歷史快照;
在合成歷史快照之前,首先對ODM層的增量數(shù)據(jù)按照數(shù)據(jù)標準進行清洗與貫標,保證數(shù)據(jù)標準的一致性;
合成歷史快照需要對應源系統(tǒng)的供數(shù)策略,分別為:
1、源系統(tǒng)全量供數(shù)時,數(shù)據(jù)表只需把全表數(shù)據(jù)清空并加載即可,但這樣只能查詢到最新的數(shù)據(jù)快照。為了記錄數(shù)據(jù)歷史軌跡,且節(jié)約數(shù)據(jù)庫使用空間,一般只保留特殊時點的歷史數(shù)據(jù)快照,比如每月末、存款起息、信用卡賬單日等。
2、源系統(tǒng)增量流水供數(shù)時,由于增量數(shù)據(jù)不會影響到歷史數(shù)據(jù),故只需把增量數(shù)據(jù)加載到歷史數(shù)據(jù)快照形成最新數(shù)據(jù)快照即可。
3、源系統(tǒng)增量歷史供數(shù)時,由于增量數(shù)據(jù)可能會影響到歷史數(shù)據(jù),故需要使用拉鏈算法既插入新增數(shù)據(jù)又保留歷史數(shù)據(jù)。
4、使用拉鏈算法記錄數(shù)據(jù)歷史軌跡時,隨著時間的增長數(shù)據(jù)量很可能會指數(shù)級增長,比如賬戶表這類變化極其頻繁的源數(shù)據(jù)。當拉鏈數(shù)據(jù)成長到一個數(shù)據(jù)級時,拉鏈算法反而會成為累贅,既導致合成歷史快照的時間越來越長,又導致數(shù)據(jù)查詢的效率越來越慢。根據(jù)八二原則,大部分數(shù)據(jù)加工僅依賴當前數(shù)據(jù),所以,建議把拉鏈表的歷史數(shù)據(jù)與當前數(shù)據(jù)分表存儲。由于當前數(shù)據(jù)的量級小,所以無論是使用拉鏈算法合成歷史快照,還是查詢數(shù)據(jù),上述問題都獲得解決。
數(shù)據(jù)倉庫FDM層
FDM的英文全稱是Finance Data Manager,即數(shù)據(jù)倉庫的金融主題層。當然,金融主題層是針對銀行而言,對一般企業(yè),稱為主題模型層會更加合適。由于銀行業(yè)務系統(tǒng)是繁多且復雜的,基于源系統(tǒng)數(shù)據(jù)模型加工數(shù)據(jù)應用時,必須要對其熟悉才行,而且源系統(tǒng)數(shù)量還不少(至少80個以上),要熟練掌握所有源系統(tǒng)數(shù)據(jù)模型并靈活運用的學習成本極高。對源系統(tǒng)數(shù)據(jù)模型按照一定的主題進行梳理與整合后,數(shù)據(jù)應用開發(fā)只需學習主題模型即可,大大降低開發(fā)門檻與學習成本;
主題劃分是一門藝術。劃分主題少了,數(shù)據(jù)過度整合反而使數(shù)據(jù)模型更加不好理解,且強硬整合不同業(yè)務種類的源數(shù)據(jù)會出現(xiàn)各種奇奇怪怪的數(shù)據(jù)問題。劃分主題多了,數(shù)據(jù)模型簡化達不到效果,使用時跟源系統(tǒng)的數(shù)據(jù)模型差異不大。所以劃分主題建議找業(yè)務知識深厚、實施經(jīng)驗豐富的建模專家主導設計,讓FDM層建設少踩點坑;
FDM層位于原始數(shù)據(jù)(ODM層,SDM層數(shù)據(jù)結構基本與源系統(tǒng)一致,所以可統(tǒng)稱為原始數(shù)據(jù))與應用數(shù)據(jù)之間,起到緩沖地帶的作用。一旦源系統(tǒng)數(shù)據(jù)模型發(fā)生變更,數(shù)據(jù)倉庫只需調(diào)整SDM層與FDM層的數(shù)據(jù)映射即可,而FDM層與ADM層的數(shù)據(jù)映射是基本不變的,保證了ADM層的穩(wěn)定性。
數(shù)據(jù)倉庫ADM層
ADM的英文全稱為Application Data Manager,即數(shù)據(jù)倉庫的數(shù)據(jù)應用層,主要為數(shù)據(jù)服務而產(chǎn)生的。由于數(shù)據(jù)服務一般具備特定業(yè)務場景,所以ADM層以服務特定業(yè)務場景的數(shù)據(jù)集市形態(tài)存在。然而,有兩類數(shù)據(jù)集市對于ADM層來說相對異類,一個是共性寬表,另一個是指標體系,因為這兩類數(shù)據(jù)集市并非針對特定業(yè)務場景,而是針對共性業(yè)務場景;
共性寬表由日常數(shù)據(jù)分析使用頻繁的,共性的元素,按業(yè)務主鍵關聯(lián)并整合的明細數(shù)據(jù)。共性寬表主要為了業(yè)務人員進行自助數(shù)據(jù)分析,業(yè)務人員可根據(jù)共性寬表的維度自由組合篩選及對表內(nèi)元素編輯計算邏輯從而快速設計報表;
指標體系由日常數(shù)據(jù)分析使用頻繁的,共性的統(tǒng)計指標,按相同的統(tǒng)計維度關聯(lián)并整合的匯總數(shù)據(jù)。指標體系主要為了讓業(yè)務人員快速查詢統(tǒng)計數(shù)據(jù)及自由編輯指標計算邏輯來衍生新指標,從而快速了解業(yè)務的經(jīng)營情況。對比共性寬表,指標體系少了靈活性(因指標統(tǒng)計口徑是固化在代碼中,只能靠技術人員維護),但能極大提升查詢效率。
共性寬表與指標體系可結合成為業(yè)務人員的自助統(tǒng)計工具,既幫助業(yè)務人員快速獲取想要的數(shù)據(jù),又能大大解放開發(fā)團隊的工作量。
很多童鞋可能對共性寬表與指標體系抱有疑問:為什么不把這兩類的數(shù)據(jù)模型做成數(shù)據(jù)倉庫的共性模型層?這里分享一下作者的觀點:
1、共性寬表與指標體系都是針對日常數(shù)據(jù)分析使用頻繁的,共性的內(nèi)容進行整合,達到數(shù)據(jù)共享的效果。實際上,數(shù)據(jù)應用的統(tǒng)計指標都具備特定業(yè)務場景特色,而非共性統(tǒng)計指標可以滿足,比如有效賬戶數(shù)統(tǒng)計,共性統(tǒng)計指標口徑是要求非注銷的賬戶,而A部門的口徑是要求賬戶非注銷,且賬戶余額不為0,這樣實際共性統(tǒng)計指標的共享性會大打折扣。
2、共性寬表與指標體系無法覆蓋所有的源數(shù)據(jù),也就是說數(shù)據(jù)應用會從金融主題層與共性模型層取數(shù)加工,會導致血緣關系的絮亂。
3、一些基礎的共性統(tǒng)計指標也可以落地到金融主題層,這樣既滿足數(shù)據(jù)共享,也滿足清晰的血緣關系。
銀行既是營銷金融產(chǎn)品的機構,也是風險運營的機構,所以營銷集市與風險集市對業(yè)務支撐作用極大;
營銷集市核心是建設客戶標簽體系,由客戶標簽構成客戶畫像助力營銷;
風險集市核心是建設風險評分體系及風險預警體系。風險評分體系貫穿整個信貸業(yè)務的生命周期,為快速業(yè)務決策提供數(shù)據(jù)支持。風險預警體系通過統(tǒng)計與展示全行機構的風險運營的數(shù)據(jù),讓領導層及時識別經(jīng)營風險及采取相應措施;
無論是營銷集市的客戶畫像體系還是風險集市的風險評分體系,都需要形成業(yè)務數(shù)據(jù)閉環(huán)來不斷迭代與優(yōu)化。
數(shù)據(jù)服務
數(shù)據(jù)服務應建設獨立系統(tǒng)進行運營。理想狀態(tài)下,所有的數(shù)據(jù)服務都展現(xiàn)在系統(tǒng)界面上,如超市一樣,應用系統(tǒng)在系統(tǒng)界面自助注冊所需的數(shù)據(jù)服務即可使用。
數(shù)據(jù)服務主要分文件接口與SOA接口。文件接口針對數(shù)據(jù)量大、固定時間間隔、允許離線更新的數(shù)據(jù)交互;SOA接口針對數(shù)據(jù)量小、頻繁且不定時、必須實時讀取的數(shù)據(jù)交互。
由于SOA接口需要實時查詢數(shù)據(jù),建議單獨部署關系型數(shù)據(jù)庫作為SOA接口的數(shù)據(jù)存儲,既提升查詢效率,又避免應用系統(tǒng)直接訪問數(shù)據(jù)倉庫。
本章節(jié)主要闡述了數(shù)據(jù)倉庫的整體架構與建設路徑的關鍵點,從技術層面上已經(jīng)基本了解數(shù)據(jù)倉庫如何實施。然而,建設數(shù)據(jù)倉庫,不僅是系統(tǒng)的建設,還是項目的運營。不懂得項目運營,系統(tǒng)建設必定困難重重。
數(shù)據(jù)倉庫項目管理
數(shù)據(jù)倉庫屬于不斷迭代更新系統(tǒng),數(shù)據(jù)服務能力應隨著迭代過程變得越來越強。但,為什么很多企業(yè)的數(shù)據(jù)倉庫喜歡每隔幾年就推到重建呢?本章節(jié)從項目管理的角度闡述數(shù)據(jù)倉庫的建設,不過限于篇幅,僅分享項目管理的主要痛點,未來有機會會編寫項目管理的實施流程與規(guī)范的文章跟大家作分享。
從作者的經(jīng)驗來說,數(shù)據(jù)倉庫項目痛點主要有四個:
缺乏規(guī)范管理:項目管理的重點之一是規(guī)范化。對內(nèi)而言,規(guī)范化有助于提升開發(fā)團隊的工作效率,系統(tǒng)建設過程中技術文檔的沉淀也有助于系統(tǒng)的可持續(xù)發(fā)展;對外而言,規(guī)范化有助于系統(tǒng)間的交互,并且有效地降低溝通成本。缺乏規(guī)范管理,容易導致數(shù)據(jù)倉庫模型愈加混亂,最終數(shù)據(jù)倉庫變成數(shù)據(jù)沼澤,被迫要推倒重做;
缺乏穩(wěn)定團隊:數(shù)據(jù)倉庫對全行的數(shù)據(jù)進行歸集并梳理整合成主題模型,最終加工成數(shù)據(jù)集市為各類應用系統(tǒng)提供數(shù)據(jù)服務,所以數(shù)據(jù)倉庫是一個數(shù)據(jù)關系十分復雜的系統(tǒng),哪怕已經(jīng)模型簡化。這樣的系統(tǒng)依賴開發(fā)團隊不斷地沉淀與迭代才能挖掘與發(fā)揮更大的性能。不穩(wěn)定的開發(fā)團隊會導致技術沉淀出現(xiàn)斷層,隨著系統(tǒng)的復雜程度上升會讓新成員越來越難理解數(shù)據(jù)關系的邏輯及背景;
缺乏高管支持:數(shù)據(jù)倉庫項目建設是一個緩慢的過程且價值體現(xiàn)不明顯,這類項目在高管的眼中就是源源不斷投入資源的無底洞。假如高管并不了解數(shù)據(jù)倉庫的本質(zhì)與價值,很可能會慢慢把資源投入到其他容易產(chǎn)生價值的項目去。一旦數(shù)據(jù)倉庫缺乏資源的支撐,慢慢速度就跟不上數(shù)據(jù)服務的迫切需求,最終變得邊緣化;
缺乏有效打法:數(shù)據(jù)倉庫的迭代優(yōu)化主要體現(xiàn)在主題模型與數(shù)據(jù)集市,假如開發(fā)團隊不懂或者不敢操作,老舊的數(shù)據(jù)模型會成為數(shù)據(jù)服務能力的嚴重阻礙。
項目管理都是有套路的,所以上述的痛點也是有方法去解決。
獲取高管的支持承諾
1、在項目建設前,必須跟高管分析數(shù)據(jù)倉庫建設的利與弊,明確告知建設路徑是一個緩慢的過程,讓高管形成心理預期與具備一定的認知。同時要宣揚同業(yè)數(shù)據(jù)倉庫建設的成功案例,特別是每個里程碑的成效,讓高管明確了解項目帶來的好處,自然就容易獲得支持了。
2、在項目建設過程中,要懂得向高管“邀功”,這樣才能獲得更多的信任與支持。
進行規(guī)范化管理
1、建立需求實施流程,管理需求生命周期,讓整個需求實施過程都是有跡可循。
2、做好元數(shù)據(jù)管理,哪怕缺乏元數(shù)據(jù)管理系統(tǒng),也要用文檔沉淀下重要的元數(shù)據(jù),比如架構文檔、模型文檔、數(shù)據(jù)映射文檔、指標口徑文檔。
3、維護好技術文檔,寧可犧牲一定的開發(fā)時間,也必須維護好項目過程的資料。這樣系統(tǒng)出現(xiàn)異?;蛘咝枰唤禹椖繒r,就能發(fā)揮重大的作用。
打造階梯型開發(fā)團隊
1、開發(fā)團隊哪怕規(guī)模小,也要做到麻雀雖小五臟俱全,至少要具備項目經(jīng)理、架構師/模型師、需求分析師、研發(fā)骨干、研發(fā)工程師、測試工程師的角色。
2、重要角色必須要有AB角,避免重要角色突然流失造成的項目風險與技術斷層。
3、最好能主動培養(yǎng)人才而非一味依賴通過社招來招募人才。雖然主動培養(yǎng)人才花費成本比較高,而且存在流失的風險,但一旦能留下來,基本都是骨干角色而且對團隊有極高的歸屬感,更不用說社招來的人才一樣存在流失的風險。
多、好、新的打法
1、允許試錯并鼓勵嘗試,在合適范圍內(nèi)對模型進行增刪改,甚至推到重構,培養(yǎng)能建模的能力。
2、在建模能力培養(yǎng)過程中,所涉及的模型肯定會出現(xiàn)效果特別好的機會。以此機會作為標桿,復盤設計思路并形成方法論沉淀。
3、待到模型建設基本成熟后,再從宏觀的角度觀察模型,結合業(yè)務場景持續(xù)思考可優(yōu)化地方并落地。這樣就會回到“多”階段,不斷試錯從而產(chǎn)生新的建模能力及方法論。