此篇內(nèi)容主要以數(shù)據(jù)倉庫的介紹說明為主，并展開了10個基礎(chǔ)問題與關(guān)鍵問題的問答分析。

寫此篇的原因是因?yàn)殛P(guān)于數(shù)據(jù)倉庫這方面的單個書籍翻譯不夠友好，書寫結(jié)構(gòu)不夠清晰以及當(dāng)前現(xiàn)實(shí)環(huán)境的數(shù)據(jù)倉庫搭建并非僅來自某個架構(gòu)思想。

同時單單看一本書很難對數(shù)據(jù)倉庫方面的知識進(jìn)行全面的理解吸收。因此我想通過主動提問的方式從多本書籍結(jié)合自身經(jīng)驗(yàn)以及與數(shù)倉專業(yè)人員的咨詢請教中獲取的知識進(jìn)行理解、思考，最終得出結(jié)論來，并且一一回答數(shù)據(jù)倉庫方面的知識內(nèi)容。

此篇內(nèi)容主要以數(shù)據(jù)倉庫的介紹說明為主。也可以理解為語文中的說明文，幾乎不涉及具體數(shù)據(jù)倉庫搭建的方法論和技術(shù)細(xì)節(jié)。并且本篇文章為數(shù)據(jù)倉庫方面知識的一個開始，后續(xù)遵循循序漸進(jìn)，由淺入深的原則，對數(shù)據(jù)倉庫進(jìn)行深入了解和掌握。

此篇文章的撰寫視角定位在對數(shù)據(jù)倉庫客觀的描述和說明，不涉及面向特定群體的說服而展開。

問題一： 數(shù)據(jù)倉庫是什么？

數(shù)據(jù)倉庫是對業(yè)務(wù)系統(tǒng)的數(shù)據(jù)進(jìn)行同步接入、歷史存儲、清洗加工、關(guān)聯(lián)打通、有效管理、分層建設(shè)、貼合需求；最終以提供滿足業(yè)務(wù)場景數(shù)據(jù)使用需求的一種數(shù)據(jù)庫。

參見數(shù)據(jù)倉庫整個作業(yè)圖便可進(jìn)一步理解：

以下為每個環(huán)節(jié)的概述：

1. 同步接入

同步接入是指從各個業(yè)務(wù)系統(tǒng)抽取數(shù)據(jù)存入數(shù)倉。

一般分為離線抽取和實(shí)時抽取。抽取的數(shù)據(jù)來自多個業(yè)務(wù)系統(tǒng)和多種數(shù)據(jù)類型，關(guān)系型數(shù)據(jù)用sqoop來抽取，非關(guān)系型用kafka來抽取。

比如：一家金融公司的業(yè)務(wù)流程有 用戶注冊、貸款申請、風(fēng)控審核、放款、貸后還款、催收等，這些業(yè)務(wù)環(huán)節(jié)的事務(wù)會在不同的系統(tǒng)完成；催收有催收系統(tǒng)，貸款申請有CRM系統(tǒng)等；這些圍繞業(yè)務(wù)主線，涉及用戶，內(nèi)部員工，三方機(jī)構(gòu)從而產(chǎn)生的業(yè)務(wù)數(shù)據(jù)，行為數(shù)據(jù)等都會通過每天定時或者實(shí)時存入數(shù)倉系統(tǒng)。

2. 歷史存儲

歷史存儲是指數(shù)倉會存儲公司內(nèi)所有保存的歷史數(shù)據(jù)（前提是數(shù)據(jù)有接入數(shù)倉且之前有保存歷史），可方便商業(yè)分析應(yīng)用和其他業(yè)務(wù)訴求對歷史數(shù)據(jù)的洞察。

比如：電商的物流數(shù)據(jù)，從下單到收貨期間的運(yùn)輸狀態(tài)可能每天都會不一樣，那么數(shù)倉就會保存該訂單物流每天的狀態(tài)數(shù)據(jù)。

3. 清洗加工

清洗加工是指數(shù)倉會通過ETL（抽取、轉(zhuǎn)換、加載）操作對業(yè)務(wù)系統(tǒng)的原始數(shù)據(jù)進(jìn)行清洗，根據(jù)數(shù)據(jù)使用的便捷，干凈，和業(yè)務(wù)訴求通過去重亂碼，填補(bǔ)空值，維度拆分，行列轉(zhuǎn)換等一系列操作。

比如：“地址”這個字段的值可能會拆分出多個維度來，國家、省、市、區(qū)、路、小區(qū)等等。 “身份證號”可以拆分出 出生年、月、日、性別等。

4. 關(guān)聯(lián)打通

關(guān)聯(lián)打通是指圍繞業(yè)務(wù)主線及用戶唯一識別，將不同業(yè)務(wù)系統(tǒng)的數(shù)據(jù)進(jìn)行打通關(guān)聯(lián)，將業(yè)務(wù)數(shù)據(jù)和行為數(shù)據(jù)進(jìn)行關(guān)聯(lián)打通；最終可形成完整的用戶生命周期數(shù)據(jù)鏈路追蹤。

5. 有效管理

有效管理是指對數(shù)據(jù)的在整個數(shù)倉內(nèi)作業(yè)生命周期內(nèi)的管理，包括對元數(shù)據(jù)的管理，對數(shù)據(jù)本身的作業(yè)管理，對數(shù)據(jù)關(guān)聯(lián)角色人員的管理等。

比如：元數(shù)據(jù)管理這塊，因?yàn)闃I(yè)務(wù)開發(fā)的人員流動，就會存在某些字段沒有注釋，沒有明確的釋義，當(dāng)人員離開又加上需要了解該數(shù)據(jù)時就會遇到無人可問的情況，需要耗費(fèi)較大的精力去想辦法了解。

6. 分層建設(shè)

分層建設(shè)是指對進(jìn)入數(shù)倉的數(shù)據(jù)進(jìn)行層次劃分（ODS 操作數(shù)據(jù)層、DWD明細(xì)數(shù)據(jù)層、DWS匯總數(shù)據(jù)層、ADS應(yīng)用數(shù)據(jù)層），以滿足數(shù)據(jù)使用便捷，高效，不耦合、符合業(yè)務(wù)需求等問題。（此處關(guān)于各個層次的細(xì)節(jié)介紹先不做說明，因?yàn)椴辉谶@個問題的討論范圍內(nèi)）

7. 貼合需求

貼合需求是指所有的最終都需要業(yè)務(wù)化，為業(yè)務(wù)的分析決策，事務(wù)應(yīng)用提供支持，而并非僅僅數(shù)據(jù)資產(chǎn)化；那么這就需要了解業(yè)務(wù)的數(shù)據(jù)需求來進(jìn)行數(shù)據(jù)的加工開發(fā)，最終實(shí)現(xiàn)數(shù)據(jù)價值最大化。

問題二：數(shù)據(jù)倉庫解決什么問題？

1. 數(shù)據(jù)打通提升數(shù)據(jù)價值

試想，現(xiàn)在某一電商產(chǎn)品做了一個版本迭代后，發(fā)現(xiàn)成交額有所下滑；目前知道成交額這種業(yè)務(wù)數(shù)據(jù)下滑，也知道都改了什么一系列功能，但并不清楚用戶是在哪個環(huán)節(jié)流失的，他們操作了什么？停留了多少時間？ 是產(chǎn)品Bug還是用戶不會用？在這種場景下如果沒有行為數(shù)據(jù)做支撐，則很難定位到原因進(jìn)行精準(zhǔn)優(yōu)化。

再試想下，同樣是某一金融產(chǎn)品用戶張三，其在該金融產(chǎn)品APP申請了一筆貸款，又在該金融產(chǎn)品的三方合作入口申請了一筆貸款；按照規(guī)定是不能進(jìn)行單用戶兩筆貸款的，但因?yàn)橄到y(tǒng)數(shù)據(jù)沒有打通，導(dǎo)致這樣的風(fēng)險問題存在。同時不得不說的是數(shù)據(jù)打通不是只有數(shù)據(jù)倉庫可以解決，業(yè)務(wù)系統(tǒng)之間的數(shù)據(jù)交換也可以解決，只不過這種方式效率更低，更容易導(dǎo)致煙囪式開發(fā)。

2. 數(shù)據(jù)分層和維度建模提升數(shù)據(jù)使用效率

先說數(shù)據(jù)分層如何提升數(shù)據(jù)的使用效率；

如果我們不進(jìn)行數(shù)據(jù)分層（直接ODS或源系統(tǒng)?。┑那闆r下，在加工某一張報表，需要取一組數(shù)據(jù)的話，那么將會及其的復(fù)雜，繁瑣。取一組數(shù)據(jù)需要關(guān)聯(lián)N多表，并且還要了解清楚字段的意思，這種復(fù)雜的操作一般只能依賴BI開發(fā)，業(yè)務(wù)人員很難有能力提取，或者說即使有能力，也沒有那些時間精力用來做這些事項(xiàng)；

如果我們進(jìn)行數(shù)倉分層（ODS/DWD/DWS/ADS）的情況下，在加工一張應(yīng)用層的表或者臨時取一組數(shù)的話，僅僅是對兩張報表進(jìn)行關(guān)聯(lián)；幾乎不需要開發(fā)進(jìn)行操作，直接在BI工具層即可實(shí)現(xiàn)。

用時間來量化衡量的話，沒有數(shù)倉分層在對數(shù)據(jù)有所了解的情況下取數(shù)可能要1-2小時，有數(shù)倉分層分鐘級即可搞定。

以下圖為例，結(jié)合上邊的論述和下邊的圖片可視化效果，以此來感受不分層與分層的區(qū)別：

再說維度建模提升數(shù)據(jù)使用效率；

?由于維度模型的設(shè)計(jì)簡單，基本遵照星型模型的設(shè)計(jì)規(guī)范，而大多數(shù)關(guān)系數(shù)據(jù)庫的優(yōu)化器是為星型模型設(shè)計(jì)的，這樣就帶來了維度建模的數(shù)據(jù)查詢效率很高；此處待舉例說明維度建模比雪花的能快多少；需要找開發(fā)求證

?3. 降低運(yùn)營成本

不搭建數(shù)倉（前提是企業(yè)業(yè)務(wù)驗(yàn)證成功，進(jìn)入增長期有搭建數(shù)倉的必要）的情況下，數(shù)據(jù)報表的加工，臨時數(shù)據(jù)的提取，數(shù)據(jù)接口封裝對外輸出都是需要不斷的重復(fù)開發(fā)，并且耦合嚴(yán)重，這就導(dǎo)致了人力成本的上升；

比如： 數(shù)據(jù)報表的加工，每次類似需求都需要涉及業(yè)務(wù)人員，BI開發(fā)，測試，產(chǎn)品等，產(chǎn)品需要了解業(yè)務(wù)的數(shù)據(jù)需求目的，使用的場景，產(chǎn)生的價值，衡量的指標(biāo)等針對這些問題與業(yè)務(wù)展開討論，開發(fā)需要梳理數(shù)據(jù)來自哪些表，怎么取，怎么加工等。 一個報表的開發(fā)隨便也要4個角色參與，7天+的工時；

而這些在數(shù)倉里可能只是根據(jù)業(yè)務(wù)通過BI進(jìn)行表關(guān)聯(lián)或者數(shù)倉開發(fā)根據(jù)業(yè)務(wù)應(yīng)用數(shù)據(jù)從匯總層大寬表進(jìn)行加工即可，人數(shù)縮減為2人參與，時間縮短為10分鐘至1天。

問題三：數(shù)據(jù)倉庫與業(yè)務(wù)源系統(tǒng)數(shù)據(jù)庫有什么區(qū)別？

數(shù)據(jù)倉庫主要是面向分析決策與業(yè)務(wù)應(yīng)用支持的。

比如：從數(shù)據(jù)中分析用戶為什么流失，交易量為什么下降，近些天的交易趨勢是怎樣的；從而滿足分析性質(zhì)的需求

比如：講數(shù)倉的數(shù)據(jù)推給CRM系統(tǒng)供客服進(jìn)行電話營銷或者短信營銷；趣頭條那種根據(jù)用戶激勵模式，對用戶的關(guān)鍵數(shù)據(jù)進(jìn)行排名，展示等，也可從數(shù)倉輸出原始數(shù)據(jù)，業(yè)務(wù)端再根據(jù)業(yè)務(wù)規(guī)則進(jìn)行加工

源系統(tǒng)數(shù)據(jù)庫是面向事務(wù)處理的，針對具體的業(yè)務(wù)操作進(jìn)行數(shù)據(jù)的查詢修改。

比如：電商用戶選了一個衣服支付購買，那么訂單系統(tǒng)就會插入一條該訂單事務(wù)的數(shù)據(jù)。

更多區(qū)別如下所示：

?問題四：數(shù)據(jù)倉庫的架構(gòu)都有哪些？它們之間的區(qū)別、優(yōu)缺點(diǎn)、應(yīng)用場景都是什么？

1. 數(shù)據(jù)倉庫的架構(gòu)目前主要分為

• 以Kimball集團(tuán)為代表的一致性維度的企業(yè)總線架構(gòu)
• 獨(dú)立數(shù)據(jù)集市架構(gòu)
• 以Inmon為代表的規(guī)范化建模Inmon架構(gòu)

2. 它們之間的主要區(qū)別

?Kimball?

采用自下而上的建設(shè)思路；先選擇業(yè)務(wù)主線需要使用的數(shù)據(jù)，再向上獲取數(shù)據(jù)，形成數(shù)據(jù)集市，最終數(shù)據(jù)集市的合集形成了數(shù)據(jù)倉庫。

獨(dú)立數(shù)據(jù)集市

架構(gòu)不需要考慮企業(yè)級別的信息共享和集成，只是為了滿足部門的數(shù)據(jù)需求，針對部門的業(yè)務(wù)規(guī)則展開的數(shù)據(jù)建設(shè)；可以采用自上而下也可以采用自下而上。

?Inmon

采用自上而下的建設(shè)思路；先從源業(yè)務(wù)系統(tǒng)獲取數(shù)據(jù)進(jìn)入數(shù)倉，然后再抽象數(shù)據(jù)主題，劃分?jǐn)?shù)據(jù)的層次，數(shù)據(jù)集市被包含在內(nèi)，最終呈現(xiàn)給業(yè)務(wù)使用；

具體如下圖所示：

3. 幾種架構(gòu)之間的優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：

• Kimball：快速迭代，實(shí)施成本低，可快速響應(yīng)業(yè)務(wù)需求。?因?yàn)镵imball采用的思路是自下而上的建設(shè)方法，它首先選取重要的業(yè)務(wù)一個業(yè)務(wù)單元進(jìn)行切入，滿足部分業(yè)務(wù)需求，后期還可以與數(shù)據(jù)倉庫其他數(shù)據(jù)進(jìn)行打通關(guān)聯(lián)；比如： 金融業(yè)務(wù)現(xiàn)在最重要的是風(fēng)控環(huán)節(jié)，風(fēng)控環(huán)節(jié)的數(shù)據(jù)應(yīng)用可以帶來很大的商業(yè)價值，那么就可以先切入風(fēng)控的去做，先隨后根據(jù)調(diào)研評估，切入申請，貸后等環(huán)節(jié)。
• Inmon ：系統(tǒng)性的滿足企業(yè)需求。?因?yàn)镮nmon采用的思路是自上而下的的建設(shè)方法，統(tǒng)一接入系統(tǒng)元數(shù)據(jù)，統(tǒng)一根據(jù)業(yè)務(wù)部門需求建設(shè)數(shù)據(jù)集市；
• 數(shù)據(jù)集市 ：快速響應(yīng)部門的數(shù)據(jù)需求。因?yàn)樗魂P(guān)注部門使用的數(shù)據(jù)，無需考慮公司內(nèi)其他部門，因此使用的數(shù)據(jù)表、人、需求都會少。所以相對能快速響應(yīng)。

缺點(diǎn)：

• Kimball： 造成重復(fù)建設(shè)，需求調(diào)研和滿足各個業(yè)務(wù)需求時比較困難。?主要問題是根據(jù)某一環(huán)節(jié)的搭建，牽扯到對各個環(huán)節(jié)需求的調(diào)研，考慮多方的需求和真實(shí)能產(chǎn)生的價值。這里邊會有博弈和真實(shí)需求的挖掘是否到位的難點(diǎn)。
• Inmon ：瀑布式建設(shè)，前期時間、人力等投入大。?由于它的思路是從數(shù)據(jù)源頭進(jìn)行系統(tǒng)性的全面建設(shè)，一次性接入所有數(shù)據(jù)，打通所有數(shù)據(jù)，建好所有模型，因此這樣的代價不言而喻。
• 數(shù)據(jù)集市：只能適用于單部門，對公司是一種資源浪費(fèi)，并且無法獲取到其他部門數(shù)據(jù)，對自己業(yè)務(wù)補(bǔ)充也是一種缺失。?試想下公司有10個業(yè)務(wù)部門都各自搞一套數(shù)據(jù)集市，這樣造成多大的人力浪費(fèi)和其他資源浪費(fèi)；在試想下自身可以拿到其他業(yè)務(wù)的數(shù)據(jù)，重疊用戶可以對他們更全面的了解，非重疊用戶可以進(jìn)行拉新轉(zhuǎn)化。

應(yīng)用場景：

• Kimball：適用于企業(yè)高速成長，需要通過數(shù)據(jù)倉庫減低成本，增強(qiáng)運(yùn)營能力且內(nèi)部可以達(dá)成建設(shè)迭代優(yōu)先級共識的場景下。
• Inmon ：適用于企業(yè)穩(wěn)定，業(yè)務(wù)模式比較固定的場景；比如： 銀行，政府機(jī)構(gòu)等。
• 數(shù)據(jù)集市：適用于企業(yè)內(nèi)部沒有達(dá)成共識，戰(zhàn)略層面不關(guān)注數(shù)據(jù)打通的價值只需專注部門內(nèi)部作業(yè)或者業(yè)務(wù)早期需要快速高效的獲取數(shù)據(jù)，還沒有建設(shè)數(shù)倉的必要。

但，就如萬事沒有非黑即白，非此即彼一樣；數(shù)倉建設(shè)也不是一定要用Kimball還是Inmon ，兩者是可以相結(jié)合的。

問題五：數(shù)據(jù)倉庫搭建的整個流程是怎樣的？

參照下圖：

以下關(guān)于上述流程做簡單說明：（該流程主要參照Kimball的架構(gòu)思路）

1. 項(xiàng)目/項(xiàng)目群規(guī)劃

在公司有眾多業(yè)務(wù)領(lǐng)域的情況下，要搭建數(shù)倉就需要在頂層確認(rèn)先切入哪個業(yè)務(wù)的優(yōu)先級選擇。 這個環(huán)節(jié)主要要針對業(yè)務(wù)高層關(guān)于他們的未來商業(yè)計(jì)劃，目前的度量業(yè)務(wù)變化的指標(biāo)以及確定數(shù)據(jù)建設(shè)對業(yè)務(wù)的影響價值進(jìn)行探討確定。

2. 業(yè)務(wù)需求調(diào)研

此環(huán)節(jié)主要是收集業(yè)務(wù)的數(shù)據(jù)需求，他們關(guān)注的業(yè)務(wù)過程，衡量指標(biāo)以及數(shù)據(jù)建設(shè)帶來的價值評估，以確定切入的具體業(yè)務(wù)環(huán)節(jié)。這個環(huán)節(jié)主要需要和具體的業(yè)務(wù)人員及業(yè)務(wù)小負(fù)責(zé)人進(jìn)行溝通，因?yàn)樗麄儗儆趫?zhí)行層面，他們對數(shù)據(jù)的應(yīng)用價值認(rèn)識比較透徹。

3. 技術(shù)架構(gòu)設(shè)計(jì)

根據(jù)需求的了解和數(shù)據(jù)量、類型的了解技術(shù)需要評估所有采用的服務(wù)器配置、數(shù)據(jù)接入技術(shù)、ETL技術(shù)、OLAP技術(shù)等。以完成數(shù)據(jù)倉庫建設(shè)做好準(zhǔn)備

4. 維度建模

維度建模是一種將數(shù)據(jù)結(jié)構(gòu)化的邏輯設(shè)計(jì)方法。 數(shù)據(jù)被分為維度（分類型數(shù)據(jù)，一般以文字為主）和度量（連續(xù)型一般為數(shù)值為主），這樣做能夠提供較快的查詢性能，以及對業(yè)務(wù)用戶比較直觀。

5. 物理設(shè)計(jì)

物理設(shè)計(jì)就是數(shù)據(jù)倉庫的邏輯模型（即維度設(shè)計(jì)）在物理系統(tǒng)中的實(shí)現(xiàn)模式。其中包括邏輯模型中各種實(shí)體表的具體化，比如：表的數(shù)據(jù)結(jié)構(gòu)類型，索引策略，存儲位置，存放分配等

6. ETL設(shè)計(jì)與開發(fā)

此處主要的工作在于基于ETL 34 個子系統(tǒng)選擇或搭建，并且根據(jù)各個源系統(tǒng)的數(shù)據(jù)類型、邏輯模型設(shè)計(jì)，數(shù)據(jù)需求進(jìn)行ETL的設(shè)計(jì)。

7. 數(shù)據(jù)輸出

數(shù)據(jù)輸出是指數(shù)據(jù)對外的使用，當(dāng)前常見的前端使用一般為 BI分析系統(tǒng)、畫像系統(tǒng)、API接口等。

問題六：數(shù)據(jù)倉庫與數(shù)據(jù)中臺有什么區(qū)別？

綠色高亮的為區(qū)別之處。根據(jù)Kimball 自身撰寫的數(shù)據(jù)倉庫書籍描述，他對數(shù)據(jù)倉庫的應(yīng)用主要定義為BI；但根據(jù)當(dāng)前的現(xiàn)實(shí)場景的應(yīng)用來看，并不是數(shù)倉只是用做報表，它已經(jīng)包含了畫像，輸出業(yè)務(wù)系統(tǒng)以及通過API網(wǎng)關(guān)的形式對外提供服務(wù)。比如：針對CRM營銷系統(tǒng)需要的用戶信息可以從數(shù)倉通過接口的形式進(jìn)行輸出。

因此，兩者之間在實(shí)際層面幾乎沒有什么區(qū)別；只是概念層面前者具有較高的戰(zhàn)略期望：

問題七：數(shù)據(jù)倉庫分層是什么？都包含哪些層次？不同層次之間的區(qū)別與關(guān)聯(lián)又是什么？

1. 模型分層是什么

數(shù)據(jù)倉庫分層是通過對數(shù)據(jù)從無序到有序，從明細(xì)到匯總，從匯總到應(yīng)用的設(shè)計(jì)。 主要是為了提升數(shù)據(jù)使用效率，方便問題定位，減少重復(fù)開發(fā)，統(tǒng)一數(shù)據(jù)口徑等問題。

2. 包含哪些層次

• ODS層（Operational Data Store）：數(shù)據(jù)運(yùn)營層；把操作系統(tǒng)的數(shù)據(jù)直接抽取存放到數(shù)倉系統(tǒng)中，基本不做什么加工；這樣方便后續(xù)數(shù)據(jù)問題定位時，可以找到源數(shù)據(jù)。
• DWD層（Data Warehouse Detail）：數(shù)據(jù)明細(xì)層；該層的數(shù)據(jù)粒度與ODS層一致，都是原子級別的數(shù)據(jù)。 在基于維度建模方法的設(shè)計(jì)基礎(chǔ)，講維度退化至事實(shí)表，方便數(shù)據(jù)使用的效率。
• DWM層（Data WareHouse Middle）：數(shù)據(jù)中間層；該層的數(shù)據(jù)是基于DWD層的數(shù)據(jù)做輕度匯總，生成一系列公共指標(biāo)，減少重復(fù)開發(fā)。也可以理解為對關(guān)鍵維度進(jìn)行聚合。
• DWS層（Data WareHouse Servce）：數(shù)據(jù)服務(wù)層；又稱做數(shù)據(jù)集市或者大寬表，比如：用戶表、流量表、訂單表、發(fā)貨表等。一個表就會包含多個很多字段，涉及多個業(yè)務(wù)過程。
• ADS層：數(shù)據(jù)應(yīng)用層；該層的數(shù)據(jù)主要是基于業(yè)務(wù)的個性化需求生成的數(shù)據(jù)表；上邊幾個層次更多的是基于業(yè)務(wù)過程的加工和聚合，而ADS層更多的關(guān)注的實(shí)際業(yè)務(wù)部門需要關(guān)注的個性化數(shù)據(jù)表的使用。數(shù)據(jù)來源一般也都是來自DWS層的再次加工。

3. 區(qū)別與關(guān)聯(lián)主要為

ODS層沒有進(jìn)行ETL和維度建模結(jié)構(gòu)化，后續(xù)分層都進(jìn)行了這些操作；ODS和DWD是原子級數(shù)據(jù)而DWM和ADS是匯總數(shù)據(jù)；ADS是基于業(yè)務(wù)部門的個性需求產(chǎn)生的數(shù)據(jù)，而其他層是基于業(yè)務(wù)過程進(jìn)行處理和主題劃分。底層的數(shù)據(jù)支撐上層數(shù)據(jù)的建設(shè)，每個層次之間相互關(guān)聯(lián)，相互依賴。

參見下圖的數(shù)倉分層：

問題八：數(shù)據(jù)倉庫分層都有什么價值？

1. 減少重復(fù)建設(shè)，提升數(shù)據(jù)應(yīng)用效率

每個層次的粒度不同，需要新開發(fā)一個應(yīng)用層的表直接根據(jù)現(xiàn)有的匯總層進(jìn)行抽取即可。避免了一些數(shù)據(jù)重復(fù)的通過底層數(shù)據(jù)進(jìn)行計(jì)算，浪費(fèi)人力成本、時間成本和服務(wù)器資源成本。

試想下，要開發(fā)一個性化應(yīng)用層的表，如果只有ODS層，數(shù)據(jù)分散，涉及表多，口徑不一致，命名重復(fù)等問題都存在，這樣開發(fā)出一張應(yīng)用表，需要耗費(fèi)多少時間周期，并且還不一定準(zhǔn)確。 如果做了分層，直接通過匯總層根據(jù)需要進(jìn)行連接即可。

2. 方便數(shù)據(jù)血緣追蹤

當(dāng)有應(yīng)用層表的數(shù)據(jù)出現(xiàn)問題時，我們可以通過血緣追蹤快速定位到其關(guān)聯(lián)的表，因?yàn)閷哟谓Y(jié)構(gòu)清晰，所有很好追蹤到；如果沒有分層，則可能會想蜘蛛網(wǎng)一樣。

問題九：數(shù)據(jù)倉庫中的主題是什么？解決什么問題？

數(shù)據(jù)倉庫主題是從較高層次上對數(shù)倉數(shù)據(jù)業(yè)務(wù)含義和需求的理解進(jìn)行歸類抽象劃分的一種方式。最終會產(chǎn)生比如：訂單主題、用戶主題、營銷主題、財(cái)務(wù)主題等。

舉個超市的例子： 超市一般都有劃分生鮮區(qū)、凍品區(qū)、食品區(qū)、糧油區(qū)、家電區(qū)、服飾區(qū)等，這些區(qū)域的分類也是根據(jù)商品的特有屬性進(jìn)行的區(qū)分，當(dāng)我們有很明確的需求是要購買電視機(jī)，那么我們可以直接去家電區(qū)，而不用去生鮮區(qū)之類的；當(dāng)我們的需求是在家做一頓豐盛的晚飯，那么我們可能會去 生鮮區(qū)、凍品區(qū)、食品區(qū)，但一定不用去服飾區(qū)。

反過來看數(shù)倉也是一樣的，如果要看的是用戶數(shù)據(jù)，直接拉用戶主題的就可以，如果要分析用戶的不同購買時段的購買情況及物流效率，那么數(shù)據(jù)加工時就可以很容易的確定出需要拉用戶主題、事件主題、訂單主題、物流主題的數(shù)據(jù)。

主要解決的問題是對數(shù)據(jù)分門別類的區(qū)分，方便業(yè)務(wù)使用數(shù)據(jù)以及方便數(shù)倉根據(jù)數(shù)據(jù)需求進(jìn)行數(shù)據(jù)加工；

試想下，如果超市的東西放的亂七八糟的，家電區(qū)有食品，食品區(qū)與凍品等等，這樣當(dāng)我們要購買目標(biāo)商品的時候要多麻煩；數(shù)倉如果我們有一個數(shù)據(jù)需求，卻不知道數(shù)據(jù)都來自哪些表，并且會有很多表。這樣的會多麻煩，做不做主題的效率差可能至少是5倍。

主題在物理上存在的形態(tài)會出現(xiàn)，數(shù)據(jù)耦合情況，具體如下所示：

問題十：產(chǎn)品經(jīng)理在數(shù)倉建設(shè)中能發(fā)揮什么作用？

首先回到數(shù)據(jù)倉庫建設(shè)的整個生命周期流程：項(xiàng)目/項(xiàng)目群規(guī)劃—業(yè)務(wù)需求調(diào)研—技術(shù)架構(gòu)設(shè)計(jì)—維度建模—物理設(shè)計(jì)—ETL設(shè)計(jì)與開發(fā)—數(shù)據(jù)輸出。

產(chǎn)品經(jīng)理發(fā)揮的作用也是圍繞這個生命周期展開。主要為以下方面：

1. 項(xiàng)目/項(xiàng)目群規(guī)劃

這個環(huán)節(jié)產(chǎn)品經(jīng)理主要起到的作用是向上建設(shè)和立項(xiàng)調(diào)研。

數(shù)倉建設(shè)畢竟是一個需要投入較多人力成本，資源成本和多方面資源協(xié)調(diào)的事情，不是一個小需求，即時需求了解不透徹，錯了也無關(guān)緊要。 數(shù)倉建設(shè)一旦確定要做，就標(biāo)志著自上而下的影響面很廣，那么就勢必需要對數(shù)倉建設(shè)解決業(yè)務(wù)的問題，投入的成本，產(chǎn)生的價值，具體量化的數(shù)據(jù)和未來的潛在價值等等做一個立項(xiàng)調(diào)研，以說服領(lǐng)導(dǎo)層愿意投入資源進(jìn)行建設(shè)，并且從戰(zhàn)略上推動各個部門人員進(jìn)行支持，否則很難推動建設(shè)。

比如： 我們輸出結(jié)論產(chǎn)生多少的人力成本節(jié)省，折合多少金額；提升了多少的數(shù)據(jù)使用效率，折合多少金額；預(yù)計(jì)帶來多少因數(shù)據(jù)打通而產(chǎn)生的增長機(jī)會，折合多少金額等。

2. 業(yè)務(wù)需求調(diào)研

這個環(huán)節(jié)產(chǎn)品經(jīng)理主要起到的作用是業(yè)務(wù)數(shù)據(jù)需求挖掘。

這個環(huán)節(jié)需要通過刨根問底的方式深入業(yè)務(wù)了解他們的數(shù)據(jù)使用需求，關(guān)注的指標(biāo)，數(shù)倉建設(shè)預(yù)計(jì)產(chǎn)生的價值。通過對各個業(yè)務(wù)關(guān)于數(shù)據(jù)使用的需求強(qiáng)烈程度和價值大小，進(jìn)行綜合評估，選擇切入的業(yè)務(wù)環(huán)節(jié)順序，以便實(shí)現(xiàn)價值盡早體現(xiàn)。

3. 維度建模

這個環(huán)節(jié)產(chǎn)品經(jīng)理主要起到的作用是資源協(xié)調(diào)與推動。

這個環(huán)節(jié)的主要事項(xiàng)是數(shù)倉開發(fā)需要了解清楚業(yè)務(wù)，了解數(shù)據(jù)情況，字段釋義，表之間的依賴關(guān)系，以便進(jìn)行模型設(shè)計(jì)與主題劃分。 這里邊就存在著需要推動多個部門的相關(guān)人員進(jìn)行配合協(xié)助，描述清楚業(yè)務(wù)的流程環(huán)節(jié)，字段的意義，依賴的關(guān)系。 如此消耗資源的事情，就需要產(chǎn)品進(jìn)行協(xié)調(diào)推動各方輸出信息給數(shù)倉。此部分更多是項(xiàng)目經(jīng)理的工作。

4. ETL設(shè)計(jì)與開發(fā)

這個環(huán)節(jié)產(chǎn)品經(jīng)理主要起到的作用是工具的搭建設(shè)計(jì)。

數(shù)倉關(guān)聯(lián)的工具模塊至少包含：元數(shù)據(jù)管理，數(shù)據(jù)接入，數(shù)據(jù)調(diào)度；在往細(xì)的拆又有 數(shù)據(jù)地圖、數(shù)據(jù)血緣、數(shù)據(jù)預(yù)警、數(shù)據(jù)接入配置、可視化清洗的34個子系統(tǒng)等。 這些工具都是在幫助數(shù)倉建設(shè)提升效率，減少錯誤，方便管理等方面做努力。

5. 數(shù)據(jù)輸出

這個環(huán)節(jié)產(chǎn)品經(jīng)理主要起到的作用是業(yè)務(wù)應(yīng)用數(shù)據(jù)需求分析和API網(wǎng)關(guān)產(chǎn)品設(shè)計(jì)。

產(chǎn)品收集日常業(yè)務(wù)提的各種數(shù)據(jù)應(yīng)用需求，通過匯總抽象反饋至數(shù)倉用來完善ADS層；在業(yè)務(wù)系統(tǒng)需要使用的數(shù)據(jù)設(shè)計(jì)公共的API網(wǎng)關(guān)產(chǎn)品用來提供服務(wù)，避免數(shù)據(jù)重復(fù)輸出，嚴(yán)重耦合帶來效率問題。

總體來說，產(chǎn)品在數(shù)倉搭建的事情當(dāng)中，一部分屬于項(xiàng)目經(jīng)理，比如維度建模過程中的多資源協(xié)調(diào)推動與項(xiàng)目推動；一部分屬于產(chǎn)品經(jīng)理，比如立項(xiàng)調(diào)研，管理工具設(shè)計(jì)規(guī)劃等。

本文由 @兩個 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議