編輯導語：產品經理這個崗位有非常多的領域，數據產品經理、B端產品經理等不同領域，而且各個領域有著不同的側重點與工作內容；數據產品經理不僅要具備傳統PM要具備的產品設計能力、項目管理能力等技能，更應該具備數據技能；本文作者分享了關于數據產品經理如何推進數據倉庫的落地，我們一起來看一下。

如果放在十年前，數據倉庫的搭建毫無疑問完完全全是開發工程師的活，隨著業務的發展與細分，對產品經理提出了更高的要求，特別是數據產品經理崗位的出現，產品經理懂技術已經是大勢所趨。

今天我們就來聊聊搭建數據倉庫都有哪些工作流程，以及數據產品經理在各個流程中扮演的角色。

01 數據倉庫的重要性

1. 為什么要搭建數據倉庫

這個問題翻譯過來就是，數據倉庫能給我們帶來什么價值。

想象一下，有一天你需要分析一下某個地區哪種商品賣的最好，這時候是不是要通過層層審批，審批完成后開發在各個系統中通過接口導出數據，估計這時候已經過去了幾天時間，所以這個效率是非常低下的；而有了數據倉庫，我們就可以自助取數、分析。

數據倉庫起到的作用就是：匯總數據、整合數據、加工數據并最終輸出能力。

2. 數據產品為什么要懂數據倉庫

數據倉庫最終是要賦能的，而賦能則需要結合業務，開發工程師往往不關心具體業務，所以完全交給開發工程師開發出來的數據倉庫可能不能很好的支持業務；這就需要數據產品經理參與進數據倉庫的開發中，而參與進來就必須要懂數據倉庫。

02 構建數據倉庫

數據倉庫的基本架構如下圖：

1. 數倉需求分析

數據產品經理在接到數據需求后，需要分析這個需求能不能實現，怎么實現，需要哪些資源；針對需求進行統籌規劃，避免為了實現特定需求而開發，盡量提供更豐富的數據以滿足不時之需。

2. 數據源梳理

數據源的梳理也是數據產品的一個工作，需要梳理出整個公司內都有哪些數據源，并爭取到數據源對應持有者的支持，了解數據源的格式以及含義。

常見的數據源有ERP系統、CRM系統、支付系統等等內部系統數據，以及產品埋點的行為數據數據，也可能有一些外部的文檔數據。

3. 數據同步匯總

取得數據持有方的支持后，將各數據源同步到數據倉庫中的ODS層，該層和源數據是同構的，即在ODS層將數據源的數據原封不動的存儲起來，以便后續追溯數據問題；這一層數據粒度是最細的，而且這層的數據保存時間最久。

4. 數倉建模

數據倉庫的設計模式分兩種：自上而下、自下而上，兩種模式對應的方法論分別是Inmon模式和Kimball模式。

1）Inmon模式

Inmon是一種自上向下的設計模式，即先構建數據倉庫再從數據倉庫中衍生出數據市場。

數據倉庫的數據來源往往是異構的，不同數據源對應不同規則的數據清洗，必須先通過ETL將數據進行處理才能放入數據倉庫層，再根據需要組合數據輸出到數據集市層。

Inmon是以數據源為導向，而數據源會經常變化，所以相對于維度建模，實體建模更適合Inmon。

2）Kimball模式

Kimball 是一種自下向上的設計模式，即先構建數據集市再匯總到數據倉庫再到數據源。

Kimball模式的數據源往往是已有的幾張表，數據源較為穩定但表與表之間的關系仍待梳理。Kimball模式在得到數據后根據目標先拆分出不同的表需求再通過ETL進入到數據倉庫層，Kimball使用維度建模。

對比兩種模式可發現，Inmon是規劃型而Kimball是享樂型，Inmon會提前規劃好，開發難度較大周期較長，但是一旦開發好后維護起來相對容易。

Kimball強調先滿足需求后續再規劃，所以Kimball能夠快速滿足需求，適合敏捷開發，同時導致的問題是后期維度難度較大；在互聯網行業中需求往往是快速變化的，因此Inmon好不容易花大力氣實現的需求往往實現后已經意義不大了；相反Kimball不考慮對數據倉庫架構做過多復雜的設計，看起來不規范但是用起來卻很實用，成了互聯網公司建模的主流模式。

5. ETL

ETL的工作將貫穿于整個數據倉庫的建立過程。

ETL是對數據的抽取、轉換、加載的簡稱；它是指將關系型數據庫中的數據抽取出來，并將不同數據源的數據按規則進行轉化和整合，最終加載到數據倉庫中。

在這一系列的操作中將會對元數據的數據格式，拼寫錯誤，多余字段以及缺失值等進行處理，將分散、零亂、標準不統一的數據整合到一起，使數據達到允許加載到數據倉庫的標準。

6. 數據倉庫分層

存儲在ODS層的數據顯然是不能直接使用的，要經過層層處理；如果一步到位計算出各類指標將來業務變化的時候又要重頭開始開發一遍，因此數據倉庫分層是很有必要的。

數據倉庫分層主要有以下幾點好處：

• 支持復用：數據在每一層進行特定的處理，保留了大量的中間層數據，將來業務變更的時候可以從已有的中間層數據重新計算而不需要重頭再來，大大地減少了重復開發；
• 便于管理使用：通過分層可以看到數據在整個倉庫中的流轉，方便掌握數據的生命周期，每一層負責特定的職責，便于使用者理解使用。

數據倉庫分層通常分為以下三層：DWD、DWM、DWS。每一層的功能如下：

1） 數據明細層：DWD（Data Warehouse Detail）

DWD層直接與ODS層接觸，ODS層的數據經過ETL后流向該層，一般保持和ODS層一樣的數據粒度。

DWD層的主要工作有以下幾點：

① 數據質量保證

ODS層的異常值、缺失值等等數據問題在這一層中解決，視具體情況進行數據矯正或者補充默認值或者直接丟棄。

② 維度退化

在本層同時也要開始為后續的數據使用做準備，之前維度建模的事實表和維度表后續使用的話需要進行大量的事實表維度表關聯，顯然效率是非常低下的；在DWD層將一些維度退化至事實表中以減少關聯，即提前關聯好各維度以便后續使用。

③ 數據聚集

ODS層的數據來源各種各樣，有些數據屬于同一個主題的但是來源不同，因此存在于不同表之中，需要將不同來源但是屬于相同主題的數據匯總到同一張表之中。

2）數據中間層：DWM（Data WareHouse Middle）

DWM層的作用是進行數據聚合，即計算出一些公共指標，生成一系列中間表，方便后續使用方直接取數，本層的數據聚合保留較細的維度；這一層視具體業務而定，如果業務比較簡單可以不需要這一層。

3）數據服務層：DWS（Data WareHouse Servce）

DWS層即我們熟知的數據集市或者大寬表。本層將DWM層的指標數據按主題進行匯總，生成一些字段較多的大寬表，即將各個指標都放在一張表中，方便使用方直接從表里面取數不需要進行任何計算。

由于將各種指標都合并到一張表中，DWS層的表不會太多，一張表包含了較多的業務內容，多指標的整合也注定了DWS層的數據表里面的維度不會太多，僅保留各指標共有的常用的一些維度。

DWM層到DWS層的流動示意圖如下：

7. 數據共享層

擁有了DWD、DWM、DWS三層數據后，是不是就可以滿足所有需求了呢？顯然是不可能的，有以下需求三層架構就滿足不了：

① 通常情況下，大部分的數據需求可以從DWS層直接取數，但是總會存在一些需求是DWS層支持不了的，這時候就需要將DWS層數據或者是從DWM、DWD數據進行計算以滿足需求；

② 數據的使用我們講究實時性，三層數據通常存儲在一些比較廉價的存儲介質上，如使用hive進行存儲，這顯然是不能滿足我們的分析查詢實時需求的，需要將有實時需求的數據加載到這一層中支持實時查詢獲取。

總而言之，數據共享層的作用就是支持三層架構滿足不了的需求以及提高數據庫性能，對外提供統一服務。

8. 數據實時需求

三層架構是無法支持實時計算需求的，因此需要有一個數據實時同步實時計算的架構，一般做法是數據源通過kafka實時同步至計算引擎，再由spark streaming或者flink等計算引擎計算出結果，儲存在高效查詢數據庫中，如hbase。

03 數據產品能力與職責

1. 職責

通過以上流程，我們可以知道數據產品在構建數據倉庫中的主要工作有：

① 數據需求對接與分析評估。

② 數據源梳理，爭取到兄弟部門的配合，統一規劃數據的來源去向。

③ 數據建模，根據現有業務對數據進行建模，用指標與維度描述出業務流程，這一塊工作需要熟悉業務，所以非產品莫屬，最終輸出的事實表與維度表不一定是具體落地的物理表，只需將需要的事實與維度交給開發即可，具體怎么落實體表由開發決定。

④ 確定數據處理邏輯，ODS層的數據同步到DWD層需要進行ETL，對一些異常值或者缺失值需要怎么處理，需要數據產品經理與業務方進行協商再將處理邏輯同步給開發。

⑤ 數據庫三層架構處理邏輯，哪些指標需要在DWM層處理哪些指標需要在DWS層處理以及每一層需要保留哪些維度，這些是開發不能確定的，需要數據產品根據業務方的使用需求進行統一規劃，最終目標是提高數據倉庫的易用性、豐富度以及擴展性。

⑥ 整個處理流程以及以后的數據使用，需要數據產品保證數據質量，數據質量除了準確性還需要保證實時性，不能幾天前的數據今天才進入到數據倉庫中。

2. 能力

從數據產品的職責來看，我們不難看出構建數據倉庫對于產品經理最大的難點就是需要懂大數據技術以及數倉架構規劃。

需要懂得構建數倉架構，知道數據怎么在數倉中流通，以及了解每個地方可能使用到的技術；常見的數據組件有Hive、Impala、Hbase、Hadoop、Spark、Flink、Redis、ES、Kafka、Sqoop等，做到了解每個組件是做什么的，有什么特點，最好是能簡單使用。

本文由 @不語 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自?Unsplash，基于 CC0 協議