資料倉儲建模案例
資料倉儲建模規範1.0
資料倉儲優化資料分析
資料倉儲的建模方法
資料倉儲維度集定義
寬表的思考
寬表從字面意義上講就是字段比較多的資料庫表。通常是指業務主題相關的指標、維度、屬性關聯在一起的一張資料庫表。由於把不同的內容都放在同一張表儲存，寬表已經不符合三正規化的模型設計規範，隨之帶來的主要壞處就是資料的大量冗餘，與之相對應的好處就是查詢效能的提高與便捷。這種寬表的設計廣泛應用於資料探勘模型訓練前的資料準備，通過把相關字段放在同一張表中，可以大大提高資料探勘模型訓練過程中迭代計算時的效率問題。
1. 寬表淺意上的好處
在當前這個專案中，大量使用了寬表，字段超過一百五十個欄位的寬表有五張，分別是客戶機構級資訊表、客戶客戶經理級資訊表、客戶經理資訊表、集團客戶資訊表、戰略客戶資訊表。
從上面的表名中可以猜到，這是個crm專案，我這裡能列舉出來的優點也是在專案中體現出來的優點。
大量使用寬表究竟給我們帶來了什麼好處？
窺一表知全貌：這個好處很明顯，尤其是收到報表開發人員的歡迎，他們不關心資料如何儲存，只關心這張報表是不是很方便，很快的能開發出來。還有乙個就是資料分析人員，銀行業大部分資料分析人員很討厭做表關聯，他們喜歡一條記錄看到客戶的全貌。
查詢速度快：大多數情況確實如此，大部分sql慢都是由於表關聯造成的，所以大家都在思考不關聯出結果。於是，出現了將一些常用的資訊都做成了大寬表，此處讓我這種正規化強迫症患者很是頭疼……
從乙個etl人員角度講，使用寬表帶給我的痛苦遠遠大於它帶給我的快樂，此處描述一下我們目前面對的系統，從系統出發解釋寬表帶來的問題。
專案是乙個crm系統，以倉庫資料（td）為基礎，進行建模、資料加工，作為倉庫的乙個集市落地後，在將這部分資料，同步到查詢伺服器（db2）上，每日從td到db2的資料量約為16g，同步資料的方式為td匯出資料生成txt，上傳到ftp伺服器後在通過shell載入到db2。
了解了專案的背景，就可以列舉出在使用寬表時有如下不便
因為要在兩個系統中同步兩張表乙份資料，增刪欄位時一定要考慮一致性，同時要考慮歷史資料如何處理。每次都需要經過如下步驟：
1. 修改td表結構
2. 修改td指令碼
3. 修改匯出資料指令碼
4. 修改db2表結構
5. 修改db2載入資料的shell指令碼
每次變動都伴隨這大量的工作，同時還需要因為這個字段載入新的歷史資料或更新這個欄位的內容，此處在專案後期維護中帶來了很大的工作量。
寬表在倉庫的彙總層大量使用，如客戶、存款、貸款等通用的實體都被設計為寬表。這些寬表會面臨我上面提到的問題嗎？
顯然不會，倉庫的表很少因為個人需求而增減字段，同時倉庫大多只負責原始資料的儲存，不會涉及到太複雜的字段加工邏輯，故大多數彙總層的表都被設計為寬表。
要想優雅的使用寬表，我認為需要注意以下這一點：
字段是否會頻繁增減
對於不涉及到事務的表且字段不會頻繁增加，建議設計為寬表，尤其對於bi系統。
當然，這只是乙個最簡單粗暴的原則，真正做的時候，你要考慮對於不同的資料庫產品，寬表中很多字段是否為空等。
針對不用的場景做不同的選擇，這句話，聽起來很虛，其實很實。
資料倉儲 建模
粒度概述 粒度問題時設計資料倉儲的乙個最重要方面。粒度時指資料倉儲的資料單位中儲存資料的細化或綜合成都的級別。細化程度越高，粒度就越小 相反，細化程度越低，粒度級就越大。資料的粒度一直時乙個設計問題。資料倉儲環境中粒度之所以時主要的設計問題，是因為它深深地影響存放在資料倉儲中的資料量的大小。同時影響...
資料倉儲建模
一 資料倉儲建模的意義 如果把資料看作圖書館裡的書，我們希望看到它們在書架上分門別類地放置 如果把資料看作城市的建築，我們希望城市規劃布局合理 如果把資料看作電腦檔案和資料夾，我們希望按照自己的習慣有很好的資料夾組織方式，而不是糟糕混亂的桌面，經常為找乙個檔案而不知所措。資料模型就是資料組織和儲存方...
資料倉儲建模
是原始資料,儲存總hdfs上 lzo壓縮 解壓速度非常快 允許在壓縮部分以損失壓縮速度為代價提高壓縮率，解壓速度不會降低。演算法無損,執行緒安全 需構建維度模型,一般採用星型模型,呈現的狀態一般為星座模型 維度建模的過程 選擇業務 一條業務線對應一張事實表 宣告粒度 精確定義事實表中的一行資料表示什...