原文鏈接： https://blog.csdn.net/winterPassing/article/details/105929303
概念
根據事實表和維度表的關係，可將常見的模型分爲星型模型和雪花模型。在數據倉庫的建設中，一般都會圍繞着這兩種模型來設計表關係或者結構。那麼什麼是事實表和維度表呢？在維度建模中，將度量稱爲“事實” ，將環境描述爲“維度”。維度是用於分析事實所需要的多樣環境。例如，在分析交易過程時，可以通過買家、賣家、商品和時間等維度描述交易發生的環境。事實則緊緊圍繞着業務過程來設計，通過獲取描述業務過程的度量來表達業務過程，包含了引用的維度和與業務過程有關的度量。例如訂單作爲交易行爲的核心載體，直觀反映了交易的狀況。訂單的流轉會產生很多業務過程，而下單、支付和成功完結三個業務過程是整個訂單的關鍵節點。獲取這三個業務過程的筆數、金額以及轉化率是日常數據統計分析的重點，事務事實表設計可以很好地滿足這個需求。
當所有維表都直接連接到事實表上時，整個圖解就像星星一樣，故將該模型稱爲星型模型。
星型架構是一種非正規化的結構，多維數據集的每一個維度都直接與事實表相連接，不存在漸變維度，所以數據有一點的冗餘。如在地域維度表中，存在國家 A 省 B 的城市 C 以及國家 A 省 B 的城市 D 兩條記錄，那麼國家 A 和省 B 的信息分別存儲了兩次，即存在冗餘。
星型模型強調的是對維度進行預處理，將多個維度集合到一個事實表，形成一個寬表。這也是我們在使用hive時，經常會看到一些大寬表的原因，大寬表一般都是事實表，包含了維度關聯的主鍵和一些度量信息，而維度表則是事實表裏面維度的具體信息，使用時候一般通過join來組合數據，相對來說對OLAP的分析比較方便。
當有一個或多個維表沒有直接連接到事實表上，而是通過其他維度表連接到事實表上時，其圖解就像多個雪花連接在一起，故稱雪花模型。
雪花模型是對星型模型的擴展，它對星型模型的維表進一步層次化，原有的各維表可能被擴展爲小的事實表，形成一些局部的 "層次 " 區域，這些被分解的表都連接到主維度表而不是事實表。如將地域維表分解爲國家，省份，城市等維表。它的優點是：通過最大限度地減少數據存儲量以及聯合較小的維表來改善查詢性能，去除了數據冗餘，但是在分析數據的時候，操作比較複雜，需要join的表比較多所以其性能並不一定比星型模型高。
區別及優缺點
星型模型因爲數據的冗餘所以很多統計查詢不需要做外部的連接，因此一般情況下效率比雪花模型要高。
星型模型不用考慮很多正規化的因素，設計與實現都比較簡單。
雪花模型由於去除了冗餘，有些統計就需要通過表的連接才能產生，所以效率不一定有星型模型高。
正規化也是一種比較複雜的過程，相應的數據庫結構設計、數據的ETL、以及後期的維護都要複雜一些。因此在冗餘可以接受的前提下，實際運用中星型模型使用更多，也更有效率。
什麼時候使用雪花模型
Ralph Kimball，數據倉庫大師，講述了三個例子。對於三個例子，使用雪花模型不僅僅是可接受的，而且可能是一個成功設計的關鍵。
1、一個用戶維度表且數據量較大。其中，80%的事實度量表是匿名訪問者，僅包含少數詳細信息。20%的是可靠的註冊用戶，且這些註冊用戶有較爲詳細的信息，與多個維度表中的數據相連。
2、例如一個金融產品維度表，且這些金融產品有銀行類的，保險類等等區別。因此不同種類的產品有自己一系列的特殊屬性，且這些屬性並非是所有產品共享的。
3、多個企業共用的日曆維度表。但每個企業的財政週期不同，節假日不同等等。在數據倉庫的環境中用雪花模型，降低儲存的空間，到了具體某個主題的數據集市再用星型模型。
雪花模型使得維度分析更加容易，比如“針對特定的廣告主，有哪些客戶或者公司是在線的?”，星形模型用來做指標分析更適合，比如“給定的一個客戶他們的收入是多少?”
總結
通過上面的對比我們可以發現，在數據倉庫建設中大多時候比較適合使用星型模型構建底層數據Hive表，通過大量的冗餘來提升查詢效率，星型模型對OLAP的分析引擎支持比較友好，這一點在Kylin中比較能體現。而雪花模型在關係型數據庫中如MySQL，Oracle中非常常見，尤其像電商的數據庫表。在數據倉庫中雪花模型的應用場景比較少，但也不是沒有，所以在具體設計的時候，可以考慮是不是能結合兩者的優點參與設計，以此達到設計的最優化目的。
參考文檔：
《數據倉庫工具箱》
什麼時候用雪花模型：https://blog.csdn.net/rav009/article/details/70666289
星型模型和雪花型模型比較：https://blog.csdn.net/nisjlvhudy/article/details/7889422
理解數據倉庫中星型模型和雪花模型：https://www.iteye.com/blog/qindongliang-2383473