數(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)生新的建模能力及方法論。
