昨天跟同事聊了下目前哪些行業資料倉儲比較領先，各個行業的資料倉儲是怎麼做的，跟網際網路比，差別是什麼東西，前期資源評估，資料庫選型怎麼搞等。有點心得，記錄如下：
1，目前來看，金融，保險，通訊，網際網路，物流這幾個行業的資料倉儲做的比較領先，其中由於金融和通訊的業務模型比較穩定，清晰，所以基本上從業務建模，概念建模，邏輯建模，物理建模這一整套步驟都比較清晰，流程化，難怪ibm，td已經將這些行業的資料倉儲建設給固化了。
2，拋開抽象的，和業務相關的業務層，概念層。從邏輯層來看，基本都是差不多的，通訊行業有stage層，和bdl，然後再是上面的經營分析系統。金融行業有ods,pdm,dm三層模型。網際網路企業有odl,bdl,idl,adl四層。其中stage,ods,odl都是一樣的，源資料層，直接從前台搬資料。bdl層和pdm層，以及idl層是類似的，都是面向主題，從源資料層到主題層都是巨複雜的邏輯，然後主題層之上，就是各種的指標，分析等。感覺都差不多。三層模型基本就適用了，最大的問題：odl-->idl為什麼不解耦？其實這個可能跟業務場景，專案目標有關，計算環境有關。如果業務場景簡單，計算環境並行性高，解耦就沒有多大意思了，如果業務場景複雜，計算環境都是序列的，那可能就要考慮下分層，減少計算消耗。
3，通常做乙個專案是幾千個人日，持續時間都是半年以上，這就是傳統行業的資料倉儲專案。據說這些專案的實施過程都是類似的，主要的消耗就是人力成本，專案都是以架構師帶老人，再加n個新人的方式做的，估計利潤非常可觀啊。。。
4，專案通常以外包的形式完成，自己不養資料倉儲相關的開發人員，目前看起來，除了網際網路企業之後，其他行業基本都是外包的形式在走，每次專案的迭代週期都是以半年期或者1年期。網際網路企業因為業務模式的不靈活性，業務的變動頻繁，所以迭代周期短，必須得養著大批的開發同學。不然等半年後，黃花菜都涼了，但是金融，財務，通訊等確實是可以這麼搞，都是經歷了大半個世紀的沉澱，業務都很穩定了。
5，范氏建模是從資料驅動來看的，維度建模是從業務來看的，業務需要哪些維度，我們就提供哪些維度。兩者都有各自的應用場景，前者多數在倉庫領域，在業務目標不清晰，不明朗的情況下，或者業務目標不唯一的時候，這麼幹的，比如說網際網路；後者在資料集市的領域比較多，因為業務目標清晰，比如財務報表，分析的維度有部門，區域，產品，時間等維度，用維度建模就非常合適了。有的時候，可以將兩者合起來做，因為倉庫是基礎，集市可以作為各種業務展現。
6，資料庫選型怎麼做？oracle；greenplum，mysql怎麼選？一般來說都是跟著業務目標走，穩定性基本上都是第一考慮要素，而且金融和通訊又都不差錢，所以oracle基本上就是第一選擇了，其他新出的資料庫，基本都沒他穩定，沒他的成功案例多。在網際網路企業，因為允許試錯，所以非常樂意嘗試各種新技術，greenplum,mysql,hive等都是選型的範圍，目前在大資料的浪潮中，hive的重要性已經越來越體現了。
8，所有的資料都是圍繞其關鍵路徑，比如通訊的關鍵路徑，就是買**，打**，發簡訊。金融就是存款，取款，理財。網際網路就不說，太多，太雜了，路徑多數是扁平狀，不深。
下次還是要多聊，多想，多積累。
資料倉儲實踐雜談（十九） 資料探勘
目錄 我們經常說，資料統計是根據已有規律的進行計算得到結果，比如特定產品銷量的地區分布或時間分布，因為我們都知道銷量和地區 時間肯定是關聯的。而資料探勘則是發現未知的規律。比如傳說已久的 啤酒與尿布 的故事，就是資料探勘的乙個成功的典型範例。雖然不存在普適性，但針對沃爾瑪在當時特定的場景確實揭露了未...
資料倉儲實踐雜談（八） 去重
目錄 資料重複是乙個比較麻煩的事情。從正常邏輯上來看，如果應用系統和資料卸出的程式沒問題，不應該存在這個問題。但實際情況來看，確又時有發生。一旦確定資料來源的資料會有重複的可能，就需要專門進行去重處理。在資料量很大的情況下，去重很耗時。所以如果可以，盡量先行優化資料來源系統。最直觀的去重可能就是先把...
資料倉儲實踐雜談（十六） 漸變維
目錄 漸變維也叫緩慢漸變維度。這個概念提出來，其實也就直接意味著，我們分析的角度並不是一成不變，而是會變化的。前面談增量 拉鍊的時候，更多討論 事實 資料的變化。業務每天都在發生這個是必然的。但對應的分析維度也一定會變化。比如客戶資訊，某個客戶一開始在a城市，但某時間點之後，搬家到了b城市。在跟蹤這...