|0x00 什么是數據倉庫的坑
“填坑”是一個新人剛加入團隊，或者是接手一個新業(yè)務，所以經常需要面對的事情。
“坑”的出現，與歷史業(yè)務的發(fā)展，密切相關。通常體現在：業(yè)務快速變動、人員快速流動、系統(tǒng)化建設能力弱、強行上馬面子工程等情況。雖然數據開發(fā)人員能夠意識到數據倉庫規(guī)范性的重要，但迫于日常的數據開發(fā)壓力，往往只能匆忙的制訂一份規(guī)范，在實際開發(fā)過過程中，往往又無法完全照搬落實，因此形成了一個“不成熟”的數據倉庫體系。
這種數據倉庫體系，最典型的特征，是找數據只能給表，無法通過規(guī)范自主查找；看邏輯只能問人，無法通過模型設計快速了解；問業(yè)務只能靠求，別人管不過來自己的事情了，哪有時間來管你？
但是！我們不能坐以待斃，面對“理想”與“現實”的差距，我們必須有一套成熟的應對方法，才能在紛亂的業(yè)務中，找到不變的哪條主線。
“對標！對標！再對標！”只有標桿有了，做事才能有章法，數據才能不錯誤。
|0x01 理想的數據倉庫是什么樣子
這個標桿是什么？就是一個理想的數據倉庫模板。
做過數據倉庫的通過，基本上都了解，一個數據倉庫從0到1的過程中，會經過三個階段：
第一個階段：簡單報表 + 數據庫階段；
第二個階段：數據集市 + 產品功能階段；
第三個階段：數據倉庫 + 主題劃分階段。
而相對成熟的數據倉庫，則有如下幾個發(fā)展的方向：
數據產品，通過產品化方式來輔助決策，服務業(yè)務方；
數據運營，革新公司的運作方式，通過數據來運營業(yè)務，常見于電商行業(yè)；
實時數倉，通過前沿的數據技術，來革新數據使用方式，帶來技術競爭力；
數據分析，通過配合分析師，貼近業(yè)務并發(fā)現問題，指導產品或業(yè)務迭代；
數據挖掘，通過算法的力量，來給業(yè)務帶來智能化的色彩。
具體每個階段就不展開描述了，但我們可以比較清楚的看出來，數據倉庫是業(yè)務從混沌走向數字化的關鍵環(huán)節(jié)，是承上啟下的樞紐，雖說沒有數據倉庫同樣能夠進行啟下的工作，但是其投入與產出終會因投入產出不成正比而無法持續(xù)的進行下去。
數據倉庫的建設，是一項系統(tǒng)化的工程，但核心點就在三處：
第一處，規(guī)范層，比如表命名規(guī)范、刷新策略規(guī)范、數據存儲生命周期、字段命名規(guī)范、指標命名規(guī)范、時間維度規(guī)范、SQL編碼規(guī)范，等等，舊的業(yè)務可以不改造，但新的業(yè)務必須按照新的規(guī)范來。
第二處，主題域，也可以根據主題域，再細分為數據域，當前很多大公司普遍開展比較廣的業(yè)務范圍，僅電商就包括B2C、C2C、B2B、B2B2C等多種不同的業(yè)務模式，每種模式都具有自己的特點。同時，ToB的企業(yè)服務市場也正在蓬勃發(fā)展，因此企業(yè)級市場又面臨人力、行政、法務、場地、財務等多種不同的主題組合，因此找公司業(yè)務負責人聊一聊，先把公司的業(yè)務范圍是什么、系統(tǒng)有哪些、數據庫有多少分類、數據同步的方式如何，這些關鍵因素搞清楚，主題域才能夠做到合理劃分，避免后續(xù)大規(guī)模大范圍的調整。
第三處，數據分層規(guī)范，通常情況下，數據是分為ODS/DWD/DWS/ADS四層，一致性維度放在DIM中。這里再強調一下各層不同的地方。
ODS：源系統(tǒng)數據接入的地方，也是數據倉庫沉淀數據的核心，通常只存儲、不改造；
DWD：數據明細層，可以遵循三范式關系模型，也可以按照維度建模針對事實表做設計，對生產數據進行各種經營分析口徑的加工轉換；
DWS：數據匯總層，主要是為了日常運營中快速反映各業(yè)務部門的數據需求，建立各種數據模型，對明細類數據進行分主題、分維度的聚合匯總；
ADS：數據出口層，面向需求做設計，是支撐需求和應用的數據重要出口，針對諸如行列轉換、數據剪裁、數據加密等實際的業(yè)務場景；
DIM：一致性維度，不再贅述。
以上是一個理想數據倉庫的“雛形”。
|0x02 我們有哪些方法來填坑
我們識別出了業(yè)務的問題，也有了建設的目標，下一步就是找策略、講打法的階段了。
首先，針對數據倉庫的改造，要有一套清晰的主線邏輯，大致包括如下幾個部分：
識別環(huán)境：包括外部環(huán)境和企業(yè)內部資產；
尋找問題：發(fā)現并標記當前業(yè)務中存在的問題；
整理業(yè)務：找熟悉公司業(yè)務的人，整理業(yè)務大圖；
制定標準：按照理想數據倉庫的規(guī)范，整理團隊自己的標準；
建立流程：將日常的開發(fā)行為，不斷的與規(guī)范進行對焦；
執(zhí)行落地：通過監(jiān)控、CodeReview等方法，強力落地；
總結思考：階段性的總結問題，并進行改進。
接下來分階段闡述：
識別環(huán)境：PMP中將項目的外部環(huán)境，定位了事業(yè)環(huán)境因素和組織過程資產，兩大部分。針對事業(yè)環(huán)境因素，往往公司進行數倉建設時，都是在業(yè)務高速發(fā)展的大背景下開展的，數據開發(fā)與分析師團隊，面對強大的業(yè)務需求壓力，會尋求進行可靠的配合，識別團隊中靠譜的人，進行合作并推動項目落地。針對組織過程資產，企業(yè)往往會有各種各樣的業(yè)務，以及各種不同的文檔，在數倉團隊進行落地的過程中，是需要借鑒并參考大量的公司材料，整理團隊自己的業(yè)務大圖，同時盡可能的復用公司已有的技術工具，將精力更加聚焦在數據倉庫本身的業(yè)務上。
尋找問題：數據倉庫的建設，本質上“沒有對錯”之分，只有相對合理與否的區(qū)別，一個好的數據倉庫工程師，一定能夠發(fā)現很多問題，從問題中總結共性的問題出來。這些問題既不會因為公司壯大而消失，因此及時總結的問題，制定合理的應對方法，并將知識傳承給新加入團隊的人員，共同做大做強，是數據倉庫走向成熟的標志之一、
整理業(yè)務：整理業(yè)務的“輸出”，應該是部門業(yè)務大圖、數據流程大圖、數據倉庫地圖、數據文檔集合等內容。我們梳理一個復雜的知識體系，往往要從“點、線、面”三個角度，來串起整體業(yè)務。點是指每次做項目的文檔，詳細記錄的需求背景、需求詳情以及數倉的設計思路；線是指我們的數據產品/分析專題/業(yè)務環(huán)節(jié)，將針對某個問題的分析或者剞劂思路展示出來；面是指業(yè)務大圖、流程大圖、數倉地圖等不同角度看數據的方式，根據內容不同，提供給數據、業(yè)務、分析師等各方使用?！包c、線、面”的方式，能夠很好的消除信息不對稱、數據查找、歷史業(yè)務理解等問題。
制定標準：規(guī)范、主題域、數據分層，因為不同公司的業(yè)務千差萬別，成熟的業(yè)務，如電商，已經走向了全面算法化、分析化的地步，但也有很多創(chuàng)新型的業(yè)務，能夠建設出基本的數據倉庫體系，就算是業(yè)務上的一大突破了。因此，雖然面上的事情是大體相同的，但是細節(jié)的調整，還是需要開發(fā)團隊自己來斟酌衡量。
建立流程：數據開發(fā)的流程，分為代碼提交時的CodeReview、數據上線前的自測、數據運行時的監(jiān)控、項目交付前的測試、以及最終的業(yè)務驗收。但很多時候，為了避免數據出問題，我們會定下許許多多繁瑣的標準，這些標準會多多少少的拖累數據開發(fā)的進度。注意，不要矯枉過正，過份的追求規(guī)范，會影響日常的數倉建設進度。
執(zhí)行落地：大多數情況下，團隊都是按照項目制的方式，來組織相關的開發(fā)工作，因此除了PRD評審外，數據團隊還應該有自己的技術評審，詳細講解業(yè)務的背景、E-R關系、模型設計方法、模型開發(fā)方式、數據規(guī)范與質量保障、數據出口、數據自測方式等內容，你可以不嚴格執(zhí)行這些過程，但也一定不能完全忽視這些過程。
總結思考：沒有什么規(guī)范是永恒的，同時也沒有什么問題是不會新增的，定期 Review團隊的工作過程，在周會、內部分享、外部合作等場景下交流經驗，是很有助益的。
|0xFF 避免挖新坑的關鍵因素
避免“新坑”，核心在人，抓手在新人的招聘。
我一直認為，每個人做的選擇，在當時的情景看來，都是最合理的選擇，無論旁人看起來如何的不靠譜。無他，趨利避害的人性使然。
每個人的職業(yè)生涯都有各種不同的選擇，或為了一份大廠的經歷、或為了一種輕松的生活、或為了一份賺錢的機會、或為了自己的人生理想。但技術人，由于其職業(yè)的特殊性，往往其職業(yè)發(fā)展都是相似的：【技術達人】 - 【獨當一面】 - 【領域專家】 - 【團隊Leader】 - 【部門領導】。只要認真工作5-7年，成為某個領域的專家，也就是P7的級別，并不難。但是再往后走，講道理，絕大多數團隊，不需要多個Leader，因此就非常講究時運了。
因此，新人的加入，一定要看清楚加入的目的是什么、對于團隊的訴求如何，畢竟我們不希望人員一直是流動的，因為再好的規(guī)范和方法，也是需要人來傳承的，但團隊流動性很高時，舊的坑即使填上了，新的坑也會不斷的被挖出來。
這也是HR一直在強調：“我們在招聘自己的同事”，發(fā)動大家一同招聘的原因。
有道是：“謀事在人，成事在天”，我們年輕的時候，都有選擇的權利，只是不論是年歲增長、還是職級晉升，往后的選擇，會越來越少。這種選擇，不僅僅是招聘一個新人的公司成本，也是職業(yè)發(fā)展的個人成本。
