o資料庫大師

1. 如何深入淺出理解數據倉庫建模

作者 | 傅一平

來源 | 與數據同行

今天跟著我來學學數據倉庫的基礎知識，希望你結合案例可以把它吃透。

如果把數據看作圖書館里的書，我們希望看到它們在書架上分門別類地放置；如果把數據看作城市的建築，我們希望城市規劃布局合理；如果把數據看作電腦文件和文件夾，我們希望按照自己的習慣有很好的文件夾組織方式，而不是糟糕混亂的桌面，經常為找一個文件而不知所措。

數據模型就是數據組織和存儲方法，它強調從業務、數據存取和使用角度合理存儲數據。Linux的創始人Torvalds有一態旁段關於「什麼才是優秀程序員」的話：「爛程序員關心的是代碼，好程序員關心的是數據結構和它們之間的關系」，最能夠說明數據模型的重要性。

只有數據模型將數據有序的組織和存儲起來之後，大數據才能得到高性能、低成本、高效率、高質量的使用。

性能：幫助我們快速查詢所需要的數據冊缺，減少數據的I/O吞吐，提高使用數據的效率，如寬表。

成本：極大地減少不必要的數據冗餘，也能實現計算結果復用，極大地降低存儲和計算成本。

效率：在業務或系統發生變化時，可以保持穩定或很容易擴展，提高數據穩定性和連續性。

質量：良好的數據模型能改善數據統計口徑的不一致性，減少數據計算錯誤的可能性。數據模型能夠促進業務與技術進行有效溝通，形成對主要業務定義和術語的統一認識，具有跨部門、中性的特徵，可以表達和涵蓋所有的業務。

大數據系統需要數據模型方法來幫助更好地組織和存儲數據，以便在性能、成本、效率和質量之間取得最佳平衡！

下圖是個示例，通過統一數據模型，屏蔽數據源變化對業務的影響，保證業務的穩定，表述了數據倉庫模型的一種價值：

為了實現以上的目的，數據倉庫一般要進行分層的設計，其能帶來五大好處：

清晰數據結構：每一個數據分層都有它的作用域，這樣我們在使用表的時候能更方便地定位和理解。

數據血緣追蹤：能夠快速准確地定位到問題，並清楚它的危害范圍。

減少重復開發：規范數據分層，開發一些通用的中間層數據，能夠減少極大的重復計算。

把復雜問題簡單化：將復雜的任務分解成多個步驟來完成，每一層只處理單一的步驟，比較簡單和容易理解。當數據出現問題之後，不用修復所有的數據，只需要從有問題的步驟開始修復。

屏蔽原始數據的異常：不必改一次業務就需要重新接入數據。

以下是我們的一種分層設計方法，數據緩沖區（ODS）的數據結構與源系統完全一致。基礎數據模型(DWD)和融合數據模型（DWI與DWA）是大數據平台重點建設的數據模型。應用層模型由各應用按需自行建設，其中基礎數據模型一般採用ER模型，融合數據模型採用維度建模思路。

前面的分層設計中你會發現有兩種設計方法，關系建模和維度建模，下面分別簡單介紹其特點和適用場景。

1、維度建模

（1）定義

維度模型是數據倉庫領域另一位大師Ralph Kimball 所倡導的。維度建模以分析決策的需求出發構建模型，構建的數據模型為分析需求服務，因此它重點解決用戶如何更快速完成分析需求，同時還有較好的大規模復雜查詢的響應性能，更直接面向業務。

典型的代表是我們比較熟知的星形模型：

維度退化

星型模型由一個事實表和一組維表組成。每個維表都有一個維作為主鍵，所有這些維的主鍵組合成事實表的主鍵。強調的是對維度進行預處理，將多個維度集合到一個事實表，形成一個寬表。

這也是我們在使用hive時，經常會看到一些大寬表的原因，大寬表一般都是事實表，包含了維度關聯的主鍵和一些度量信息，而維度表則是事實表裡面維度的具體信息，使用時候一般州閉辯通過join來組合數據，相對來說對OLAP的分析比較方便。

（2）建模方法

通常需要選擇某個業務過程，然後圍繞該過程建立模型，其一般採用自底向上的方法，從明確關鍵業務過程開始，再到明確粒度，再到明確維度，最後明確事實，非常簡單易懂。

以下是阿里的OneData的建模工作流，可以參考。

（3）優缺點

優點：技術要求不高，快速上手，敏捷迭代，快速交付；更快速完成分析需求，較好的大規模復雜查詢的響應性能

缺點：維度表的冗餘會較多，視野狹窄

2、關系建模

（1）定義

是數據倉庫之父Inmon推崇的、從全企業的高度設計一個3NF模型的方法，用實體加關系描述的數據模型描述企業業務架構，在範式理論上符合3NF，站在企業角度面向主題的抽象，而不是針對某個具體業務流程的實體對象關系抽象。

它更多是面向數據的整合和一致性治理，正如Inmon所希望達到的「single version of the truth」。

當有一個或多個維表沒有直接連接到事實表上，而是通過其他維表連接到事實表上時，其圖解就像多個雪花連接在一起，故稱雪花模型。

雪花模型是對星型模型的擴展。它對星型模型的維表進一步層次化，原有的各維表可能被擴展為小的事實表，形成一些局部的 "層次 " 區域，這些被分解的表都連接到主維度表而不是事實表。

雪花模型更加符合資料庫範式，減少數據冗餘，但是在分析數據的時候，操作比較復雜，需要join的表比較多所以其性能並不一定比星型模型高。

（2）建模方法

關系建模常常需要全局考慮，要對上游業務系統的進行信息調研，以做到對其業務和數據的基本了解，要做到主題劃分，讓模型有清晰合理的實體關系體系，以下是方法的示意：

以下是中國移動的概念模型的一種示例，如果沒有自頂向下的視野，基本是總結不出來的：

（3）優缺點

優點：規范性較好，冗餘小，數據集成和數據一致性方面得到重視，比如運營商可以參考國際電信運營業務流程規范（ETOM），有所謂的最佳實踐。

缺點：需要全面了解企業業務、數據和關系；實施周期非常長，成本昂貴；對建模人員的能力要求也非常高，容易爛尾。

3、建模方法比較

一般來講，維度模型簡單直觀，適合業務模式快速變化的行業，關系模型實現復雜，適合業務模式比較成熟的行業，阿里原來用關系建模，現在基本都是維度建模的方式了。

運營商以前都是關系建模，現在其實邊界越來越模糊，很多大數據業務變化很快，採用維度建模也比較方便，不需要頂層設計。

維度建模就不說了，只要能理解業務過程和其中涉及的相關數據、維度就可以，但自頂向下的關系建模難度很大，以下是關系建模的三個建設要點。

1、業務的理解：找到企業內最理解業務和源系統的人，梳理出現狀，比如運營商就要深刻理解三域（O/B/M），概念建模的挑戰就很大，現在做到B域的概念建模已經很不容易。

2、數據及關系的理解：各個域的系統建設的時候沒有統一文檔和規范，要梳理出邏輯模型不容易，比如運營商的事件主題下的邏輯模型就非常復雜。

3、標准化的推進：數據倉庫建模的任何實體都需要標准化命名，否則未來的管理成本巨大，也是後續數據有效治理的基礎，以下是我們的一個命名規范示例：

總而言之，你可以把我的文章當成一個指引，具體還是要結合企業的實際去推進，但做事的時候要不忘建模的初心：即數據如何擺布才能提高支撐應用的效率，手段上不用區分什麼先進不先進，好用就成。

2. php連接oracle資料庫，報錯「 ORA-12154: TNS: 無法解析指定的連接標識符 in C:\NWEB\db.php on line 3

如果我沒猜錯，你是用的win7吧。。。
請用xp系統，或者按http://blog.csdn.net/chewinggum/archive/2010/07/18/5744463.aspx
這個方法試。