數(shù)據(jù)倉庫是存放收集來的數(shù)據(jù)的地方，做數(shù)據(jù)分析現(xiàn)在一般盡量不在業(yè)務數(shù)據(jù)上直接取數(shù)，因為對業(yè)務數(shù)據(jù)庫的壓力太大，影響線上業(yè)務的穩(wěn)定。
數(shù)據(jù)產(chǎn)品的工作比較雜，從數(shù)據(jù)倉庫建模，指標體系建立，到數(shù)據(jù)產(chǎn)品工具的設計，再到偶爾一些數(shù)據(jù)分析報告的撰寫，甚至一些機器學習的預測模型都要有所了解。大公司可能每個職能都有專門的崗位來負責，小公司的話可能真的要你一條龍了。
其實數(shù)據(jù)產(chǎn)品從頭到尾做的事情就是幫公司收集數(shù)據(jù)、存儲數(shù)據(jù)、呈現(xiàn)數(shù)據(jù)、預測數(shù)據(jù)，拆分到具體的工作中，將會在下面介紹。
數(shù)據(jù)倉庫是存放收集來的數(shù)據(jù)的地方，做數(shù)據(jù)分析現(xiàn)在一般盡量不在業(yè)務數(shù)據(jù)上直接取數(shù)，因為對業(yè)務數(shù)據(jù)庫的壓力太大，影響線上業(yè)務的穩(wěn)定。
1. 數(shù)據(jù)收集的時間間隔
數(shù)據(jù)倉庫里的數(shù)據(jù)按照數(shù)據(jù)收集的時間間隔大致分為兩類：
一類是可以進行離線處理的數(shù)據(jù)，一般包括內(nèi)部業(yè)務數(shù)據(jù)庫及外部數(shù)據(jù)（比如：爬蟲或第三方API）；
一類是需要實時處理的數(shù)據(jù)，比如：內(nèi)部業(yè)務日志數(shù)據(jù)。
對于第一類一般的處理多數(shù)要求在“天”級別，比如說：一天從業(yè)務數(shù)據(jù)庫更新一次數(shù)據(jù)就足夠了，一般采用MapReduce等批處理框架來處理數(shù)據(jù)，批處理框架在進行大量數(shù)據(jù)的計算的時候有計算資源比較廉價等優(yōu)勢。
而第二類實時數(shù)據(jù)處理，需要采用一些流處理框架，例如：Storm、Spark等，來處理數(shù)據(jù)，當業(yè)務發(fā)展到一定階段，業(yè)務人員對數(shù)據(jù)的實時性要求會越來越高，也就對大數(shù)據(jù)技術團隊提出了更高的要求，當然實時處理數(shù)據(jù)所需要付出的代價也是更高的。
我們要分辨清楚，哪些數(shù)據(jù)采用批處理就可以了，哪些數(shù)據(jù)是有實時處理的價值的，并不是說所有數(shù)據(jù)都實時處理就是更好，畢竟集群資源是有限的，要合理利用計算資源。
2. 數(shù)據(jù)的分層存儲
另外數(shù)據(jù)倉庫的數(shù)據(jù)存儲是分層級的，這個架構(gòu)一方面跟數(shù)據(jù)拉取方式有關，一方面也是為了對數(shù)據(jù)進行層級的抽象處理。
一般來說數(shù)據(jù)倉庫會至少分為ODS、MID、DW三個層級，當然層級的名稱每個公司可能不同，這里主要是在作用上進行區(qū)分解釋。
ODS層存儲的是業(yè)務數(shù)據(jù)庫在一個時間范圍內(nèi)新增或更新的數(shù)據(jù)，它的存儲是線性增長的，有數(shù)據(jù)發(fā)生變化，ODS才會存儲數(shù)據(jù)。
MID層是經(jīng)由ODS層數(shù)據(jù)計算得出的最新的完整版數(shù)據(jù)，相當于是業(yè)務數(shù)據(jù)庫的一個拷貝，只不過是截止到某一個時間的。
DW層是對MID層進行業(yè)務模型的抽象之后的合并層，將一些冗余的庫表簡化，做成比較利于數(shù)據(jù)抽取的庫表。
因為MID層和DW層存儲的都是完整的數(shù)據(jù)，業(yè)務數(shù)據(jù)庫數(shù)據(jù)會不斷增長，導致這兩個層級里的數(shù)據(jù)每個切片的數(shù)據(jù)都是在增長，相當于是指數(shù)增長。
3. 數(shù)據(jù)的切片存儲
數(shù)據(jù)庫的存儲是分時間戳的，相當于是把數(shù)據(jù)按照快照的方式存了n個版本，當你想追溯在某天某時間的數(shù)據(jù)的時候，就可以通過定位特定的時間戳，追溯到相關的數(shù)據(jù)。
這種設計避免了業(yè)務庫數(shù)據(jù)會不斷覆蓋的問題，相當于是在數(shù)據(jù)分析的時候加了一個時間維度，提升了一個維度，看問題解決問題的角度也就被升華了。
4. 數(shù)據(jù)倉庫建模
MID層向DW層抽象的過程，需要數(shù)據(jù)產(chǎn)品對業(yè)務庫表進行建模。首先要清楚了解，你所要進行抽象的業(yè)務系統(tǒng)是什么樣的（感覺數(shù)據(jù)產(chǎn)品好累，還要去了解別人的系統(tǒng)是怎么玩的。
比如：你所要負責的是A業(yè)務系統(tǒng)的DW設計，那么首先你要把A業(yè)務系統(tǒng)的系統(tǒng)邏輯搞清楚，然后它所涉及的庫表都了解清楚，包括業(yè)務本身的庫表以及它所依賴的中后臺系統(tǒng)的庫表，以及各個數(shù)據(jù)庫之間的關系是怎樣，比如：是一對一還是一對多，當前庫表是否是最細粒度的數(shù)據(jù)。
一般來說建模要做到模塊互相獨立，粒度統(tǒng)一。因為考慮到后期做指標和取數(shù)的方便，在不同粒度上都有表是比較好的。
比如：一個電商分期業(yè)務，可能在訂單粒度上才能取到放款等數(shù)據(jù)，但是品類等維度又只能在商品粒度上取到（考慮到購物車，一個訂單可能對應多個商品），這時候就需要兩個粒度都建立對應的表才能滿足不同的取數(shù)需求。
