[[409412]]

本文轉載自微信公眾號「曉陽的數據小站」，作者曉陽的數據小站。轉載本文請聯系曉陽的數據小站公眾號。

0x00 什么是數據倉庫的坑

“填坑”是一個新人剛加入團隊，或者是接手一個新業務，所以經常需要面對的事情。

“坑”的出現，與歷史業務的發展，密切相關。通常體現在：業務快速變動、人員快速流動、系統化建設能力弱、強行上馬面子工程等情況。雖然數據開發人員能夠意識到數據倉庫規范性的重要，但迫于日常的數據開發壓力，往往只能匆忙的制訂一份規范，在實際開發過過程中，往往又無法完全照搬落實，因此形成了一個“不成熟”的數據倉庫體系。

這種數據倉庫體系，最典型的特征，是找數據只能給表，無法通過規范自主查找;看邏輯只能問人，無法通過模型設計快速了解;問業務只能靠求，別人管不過來自己的事情了，哪有時間來管你?

但是!我們不能坐以待斃，面對“理想”與“現實”的差距，我們必須有一套成熟的應對方法，才能在紛亂的業務中，找到不變的哪條主線。

“對標!對標!再對標!”只有標桿有了，做事才能有章法，數據才能不錯誤。

0x01 理想的數據倉庫是什么樣子

這個標桿是什么?就是一個理想的數據倉庫模板。

做過數據倉庫的通過，基本上都了解，一個數據倉庫從0到1的過程中，會經過三個階段：

• 第一個階段：簡單報表 + 數據庫階段;
• 第二個階段：數據集市 + 產品功能階段;
• 第三個階段：數據倉庫 + 主題劃分階段。

而相對成熟的數據倉庫，則有如下幾個發展的方向：

• 數據產品，通過產品化方式來輔助決策，服務業務方;
• 數據運營，革新公司的運作方式，通過數據來運營業務，常見于電商行業;
• 實時數倉，通過前沿的數據技術，來革新數據使用方式，帶來技術競爭力;
• 數據分析，通過配合分析師，貼近業務并發現問題，指導產品或業務迭代;
• 數據挖掘，通過算法的力量，來給業務帶來智能化的色彩。

具體每個階段就不展開描述了，但我們可以比較清楚的看出來，數據倉庫是業務從混沌走向數字化的關鍵環節，是承上啟下的樞紐，雖說沒有數據倉庫同樣能夠進行啟下的工作，但是其投入與產出終會因投入產出不成正比而無法持續的進行下去。

數據倉庫的建設，是一項系統化的工程，但核心點就在三處：

第一處，規范層，比如表命名規范、刷新策略規范、數據存儲生命周期、字段命名規范、指標命名規范、時間維度規范、SQL編碼規范，等等，舊的業務可以不改造，但新的業務必須按照新的規范來。

第二處，主題域，也可以根據主題域，再細分為數據域，當前很多大公司普遍開展比較廣的業務范圍，僅電商就包括B2C、C2C、B2B、B2B2C等多種不同的業務模式，每種模式都具有自己的特點。同時，ToB的企業服務市場也正在蓬勃發展，因此企業級市場又面臨人力、行政、法務、場地、財務等多種不同的主題組合，因此找公司業務負責人聊一聊，先把公司的業務范圍是什么、系統有哪些、數據庫有多少分類、數據同步的方式如何，這些關鍵因素搞清楚，主題域才能夠做到合理劃分，避免后續大規模大范圍的調整。

第三處，數據分層規范，通常情況下，數據是分為ODS/DWD/DWS/ADS四層，一致性維度放在DIM中。這里再強調一下各層不同的地方。

ODS：源系統數據接入的地方，也是數據倉庫沉淀數據的核心，通常只存儲、不改造;

DWD：數據明細層，可以遵循三范式關系模型，也可以按照維度建模針對事實表做設計，對生產數據進行各種經營分析口徑的加工轉換;

DWS：數據匯總層，主要是為了日常運營中快速反映各業務部門的數據需求，建立各種數據模型，對明細類數據進行分主題、分維度的聚合匯總;

ADS：數據出口層，面向需求做設計，是支撐需求和應用的數據重要出口，針對諸如行列轉換、數據剪裁、數據加密等實際的業務場景;

DIM：一致性維度，不再贅述。

以上是一個理想數據倉庫的“雛形”。

0x02 我們有哪些方法來填坑

我們識別出了業務的問題，也有了建設的目標，下一步就是找策略、講打法的階段了。

首先，針對數據倉庫的改造，要有一套清晰的主線邏輯，大致包括如下幾個部分：

• 識別環境：包括外部環境和企業內部資產;
• 尋找問題：發現并標記當前業務中存在的問題;
• 整理業務：找熟悉公司業務的人，整理業務大圖;
• 制定標準：按照理想數據倉庫的規范，整理團隊自己的標準;
• 建立流程：將日常的開發行為，不斷的與規范進行對焦;
• 執行落地：通過監控、CodeReview等方法，強力落地;
• 總結思考：階段性的總結問題，并進行改進。

接下來分階段闡述：

識別環境：PMP中將項目的外部環境，定位了事業環境因素和組織過程資產，兩大部分。針對事業環境因素，往往公司進行數倉建設時，都是在業務高速發展的大背景下開展的，數據開發與分析師團隊，面對強大的業務需求壓力，會尋求進行可靠的配合，識別團隊中靠譜的人，進行合作并推動項目落地。針對組織過程資產，企業往往會有各種各樣的業務，以及各種不同的文檔，在數倉團隊進行落地的過程中，是需要借鑒并參考大量的公司材料，整理團隊自己的業務大圖，同時盡可能的復用公司已有的技術工具，將精力更加聚焦在數據倉庫本身的業務上。

尋找問題：數據倉庫的建設，本質上“沒有對錯”之分，只有相對合理與否的區別，一個好的數據倉庫工程師，一定能夠發現很多問題，從問題中總結共性的問題出來。這些問題既不會因為公司壯大而消失，因此及時總結的問題，制定合理的應對方法，并將知識傳承給新加入團隊的人員，共同做大做強，是數據倉庫走向成熟的標志之一、

整理業務：整理業務的“輸出”，應該是部門業務大圖、數據流程大圖、數據倉庫地圖、數據文檔集合等內容。我們梳理一個復雜的知識體系，往往要從“點、線、面”三個角度，來串起整體業務。點是指每次做項目的文檔，詳細記錄的需求背景、需求詳情以及數倉的設計思路;線是指我們的數據產品/分析專題/業務環節，將針對某個問題的分析或者剞劂思路展示出來;面是指業務大圖、流程大圖、數倉地圖等不同角度看數據的方式，根據內容不同，提供給數據、業務、分析師等各方使用。“點、線、面”的方式，能夠很好的消除信息不對稱、數據查找、歷史業務理解等問題。

制定標準：規范、主題域、數據分層，因為不同公司的業務千差萬別，成熟的業務，如電商，已經走向了全面算法化、分析化的地步，但也有很多創新型的業務，能夠建設出基本的數據倉庫體系，就算是業務上的一大突破了。因此，雖然面上的事情是大體相同的，但是細節的調整，還是需要開發團隊自己來斟酌衡量。

建立流程：數據開發的流程，分為代碼提交時的CodeReview、數據上線前的自測、數據運行時的監控、項目交付前的測試、以及最終的業務驗收。但很多時候，為了避免數據出問題，我們會定下許許多多繁瑣的標準，這些標準會多多少少的拖累數據開發的進度。注意，不要矯枉過正，過份的追求規范，會影響日常的數倉建設進度。

執行落地：大多數情況下，團隊都是按照項目制的方式，來組織相關的開發工作，因此除了PRD評審外，數據團隊還應該有自己的技術評審，詳細講解業務的背景、E-R關系、模型設計方法、模型開發方式、數據規范與質量保障、數據出口、數據自測方式等內容，你可以不嚴格執行這些過程，但也一定不能完全忽視這些過程。

總結思考：沒有什么規范是永恒的，同時也沒有什么問題是不會新增的，定期 Review團隊的工作過程，在周會、內部分享、外部合作等場景下交流經驗，是很有助益的。

0xFF 避免挖新坑的關鍵因素

避免“新坑”，核心在人，抓手在新人的招聘。

我一直認為，每個人做的選擇，在當時的情景看來，都是最合理的選擇，無論旁人看起來如何的不靠譜。無他，趨利避害的人性使然。

每個人的職業生涯都有各種不同的選擇，或為了一份大廠的經歷、或為了一種輕松的生活、或為了一份賺錢的機會、或為了自己的人生理想。但技術人，由于其職業的特殊性，往往其職業發展都是相似的：【技術達人】 - 【獨當一面】 - 【領域專家】 - 【團隊Leader】 - 【部門領導】。只要認真工作5-7年，成為某個領域的專家，也就是P7的級別，并不難。但是再往后走，講道理，絕大多數團隊，不需要多個Leader，因此就非常講究時運了。

因此，新人的加入，一定要看清楚加入的目的是什么、對于團隊的訴求如何，畢竟我們不希望人員一直是流動的，因為再好的規范和方法，也是需要人來傳承的，但團隊流動性很高時，舊的坑即使填上了，新的坑也會不斷的被挖出來。

這也是HR一直在強調：“我們在招聘自己的同事”，發動大家一同招聘的原因。

有道是：“謀事在人，成事在天”，我們年輕的時候，都有選擇的權利，只是不論是年歲增長、還是職級晉升，往后的選擇，會越來越少。這種選擇，不僅僅是招聘一個新人的公司成本，也是職業發展的個人成本。