數據倉庫模型中度量是什麼

A. 什麼是指標、維度、度量

維度是描述事情的角度，依賴於指標，例如：年份是時間維度，北京是地理維度，月活是業務維度。
指標是一數值或者比例，通過某種計算得到的，用來衡量業務。例如好評量、好評率、增長率。
維度是用來說明數據，即對象的描述性屬性或特徵。例如，寬度指的是用戶群的覆蓋范圍大小。
1、指標
指標，用於衡量事物發展程度的單位或方法，它還有個IT上常用的名字，也就是度量。例如：人口數、GDP、收入、用戶數、利潤率、留存率、覆蓋率等。很多公司都有自己的KPI指標體系，就是通過幾個關鍵指標來衡量公司業務運營情況的好壞。
指標需要經過加和、平均等匯總計算方式得到，並且是需要在一定的前提條件進行匯總計算，如時間、地點、范圍，也就是我們常說的統計口徑與范圍。
指標可以分為絕對數指標和相對數指標，絕對數指標反映的是規模大小的指標，如人口數、GDP、收入、用戶數，而相對數指標主要用來反映質量好壞的指標，如利潤率、留存率、覆蓋率等。我們分析一個事物發展程度就可以從數量跟質量兩個角度入手分析，以全面衡量事物發展程度。
剛才說過，指標用於衡量事物發展程度，那這個程度是好還是壞，這就需要通過不同維度來對比，才能知道是好還是壞。
2、維度
維度：是事物或現象的某種特徵，如性別、地區、時間等都是維度。其中時間是一種常用、特殊的維度，通過時間前後的對比，就可以知道事物的發展是好了還是壞了，如用戶數環比上月增長10%、同比去年同期增長20%，這就是時間上的對比，也稱為縱比;
另一個比較就是橫比，如不同國家人口數、GDP的比較，不同省份收入、用戶數的比較、不同公司、不同部門之間的比較，這些都是同級單位之間的比較，簡稱橫比;
維度可以分為定性維度跟定量維度，也就是根據數據類型來劃分，數據類型為字元型(文本型)數據，就是定性維度，如地區、性別都是定性維度;數據類型 為數值型數據的，就為定量維度，如收入、年齡、消費等，一般我們對定量維度需要做數值分組處理，也就是數值型數據離散化，這樣做的目的是為了使規律更加明 顯，因為分組越細，規律就越不明顯，最後細到成最原始的流水數據，那就無規律可循。
最後強調一點，只有通過事物發展的數量、質量兩大方面，從橫比、縱比角度進行全方位的比較，我們才能夠全面的了解事物發展的好壞。

B. 淺析數據倉庫的構建方法

淺析數據倉庫的構建方法
隨著不同的管理信息系統（MIS）在企業不同部門的大規模應用及企業對數據管理不斷提出新的要求，不僅要求能實現傳統的聯機事務處理，而且越來越多的要求是各種應用系統能夠在企業不斷積累的以及從企業外部獲取的豐富信息資源的基礎上，把這些分散的、不一致的、凌亂的信息資源加以利用，即更多地參與數據分析和決策支持，盯寬配由此出現了一種用於數據分析處理和決策支持的數據存儲和組織技術，即數據倉庫技術。
1、什麼是數據倉庫
數據倉庫是面向主題的、集成的、具有時間特徵的、穩定的數據集合，用以支持經營管理中的決策制定過程。數據倉庫提供用戶用於決策支持的當前和歷史數據，這些數據在傳統的操作型資料庫中很難或不能得到。
面向主題是指數據倉庫中的數據是按照一定的主題域進行組織。主題是一個抽象的概念，是指用戶使用數據倉庫進行決策時所關心的重點方面，一個主題通常與多個操作型信息系統相關。集成的是指數據倉庫中的數據是在對原有分散的資料庫數據抽取、清理的基礎上經過系統加工、匯總和整理得到的，必須消除源數據中的不一致性，以保證數據倉庫內的信息是關於整個企業的一致的全局信息。
數據倉庫的體系結構分數據源、數據轉換、數據倉庫、數據集市和用戶幾部分。數據源，包括企業內部的業務數據、遺留數據、其它業務系統數據及相關WEB數據等；數據轉換是數據倉庫構建的重要環節，主要是對各種復雜的數據源進行抽取、轉換、裝載及其他處理，同時要實現數據質量跟蹤監控以及元數據抽取與創建等工作；數據倉庫主要實現對各種數據的組織、存儲及管理等；數據集市是為不同業務而單獨設計的數據倉庫系統，即開發者為企業內部的不同用戶群定製特殊的數據倉庫子系統。用戶部分，即具體面向使用者的應用部分，主要是指數據倉庫存取與檢索為用戶提供了訪問數據倉庫或數據集市的功能，其中分析與報告為用戶使用數據倉庫提供了一組工具，用於幫助用戶對數據倉庫或數據集市進行聯機分析或數據挖掘等。
2、數據倉庫構建方法
2.1 普通數據倉庫構建方法。對於普通數據倉庫的構建，企業在對整個系統的建設綜合各種因素的基礎上，將整個項目的實施分階段、分步驟實施，可以在每一階段建設的基礎上分階段納入不同的業務系統，逐步建立起一個綜合的、專題較為完善的、適合部門、子單位使用的完整的數據倉庫系統，從而才能使投資盡快獲得收益。
在數據倉庫的構建過程中，利用模糊數學可實現數據倉庫內數據的語義表示，豐富數據加工的手段，提高分析處理的能力。數據倉庫的構建，一般採取先構建數據集市，最後將各個數據集市整合在一起形成數據倉庫的漸進模式；通過概念層、邏輯層、物理層建模，確定相關主題域的數據集市並對其進行聯機分析處理。構建數據倉庫模型一般採用以下幾種：
2.1.1 星型模型：凱指星型模型是最常用的數據倉庫設計結構的實現模式。使數據倉庫形成了一個集成系統，為用戶提供分析服務對象。該模型的核心是事實表，圍繞事實表的是維度表。通過事實表將各種不同的維度表連接起來，各個維度表都連接到中央事實表。[page] 2.1.2 星系模型（也稱雪花模型）：雪花模型對星型模型的維度表進一步標准化，對星型模型中的維度表進行了規范化處理。同時也是對星型模型的擴展，每一個維巧升度都可以向外連接到多個詳細類別表。在實際應用中，用戶的需求多種多樣，數據來源可能為多個事實表，故可採用多個事實表共存，之間通過公用的維表相關聯的星系模型，也稱為事實星座。
2.1.3 原子級數據模型和匯總級數據模型並存：堅持原子級數據模型和匯總級數據模型並存，而且要盡可能地細化原子級數據。
2.1.4 設立代理鍵：代理鍵是維表中一些沒有業務含義的欄位，只是一個由數據倉庫載入程序時建立的數字。
2.2 空間數據倉庫構建方法。隨著GIS（地理信息系統）在各行業的廣泛應用，最初面向事務處理為主的空間資料庫信息系統已不能滿足需要，信息系統開始從管理轉向決策處理，空間數據倉庫就是為滿足這種新的需求而提出的空間信息集成系統。尤其是地理信息決策支持系統中，空間數據倉庫系統顯得尤為重要。
空間數據倉庫具有普通數據倉庫的普遍特徵，但其本身有一些特殊性。並且空間數據倉也並不是空間資料庫的簡單集合。與空間資料庫比，空間數據倉除支持資料庫外，還支持數據文件、文本文件、應用程序等眾多數據源；另外空間數據倉庫中的數據有時間數據、空間數據、屬性數據及異構數據等多種數據；其次空間數據倉庫中還包括了數據處理規則、演算法等；再次空間數據倉庫的數據是對原始數據進行加工、處理、集成等轉換，是對數據的增值和統一；空間資料庫還引入了時間縱的概念，它是以時間為基準來管理數據，可以截取不同時間尺度上的信息，從瞬態到區段時間直到全體，空間數據倉庫是依賴於時間維的數據結構，它可以根據不同的需要劃分不同的時間粒度等級，以便進行各種復雜的趨勢分析。當然，不言而喻，它還包含了空間維的方位數據。正因為空間數據倉庫與普通數據倉庫的不同，並且它以空間數據倉庫完全不是相同的概念，一般空間數據倉庫以如下體系結構分為四大功能模塊，分別是源數據、數據變換工具、空間數據倉庫、客戶端分析工具。源數據它不僅指那些常見的空間資料庫，還包括文件、網頁、知識庫、遺留系統等各種數據源。數據變換工具與具有普通數據倉庫數據變換相同的提取轉換功能，但它還包括了特有的空間變換等。空間數據倉庫以立體、多維的方式來組織和顯示數據。但最基本的空間維和時間維是其反映客觀世界動態變化的基礎，空間數據倉庫技術最關鍵要點也就是時間維和空間維數據組織方式。目前空間數據倉庫已成為國、內外GIS（地理信息系統）研究的熱點並取得了較大進展。要把空間信息融合進企業現有的數據倉庫中，在原有系統不作較大改動的前提下，一般採用三種模式構建企業空間數據倉庫：（1）把空間信息作為多維模型中的空間維引入；（2）把空間信息作為研究主題引入；（3）在維和度量中都包含空間信息。因此，計算並存儲所有空間度量是不現實的。一般使用空間索引樹（如R-tree）在最細空間粒度上構建分組層次，作為空間維的分層，每個空間維需要建立一棵空間索引樹。
3、結束語
總之，數據倉庫構建是數據倉庫技術的關鍵，數據倉庫技術是一項基於數據管理和利用的綜合性技術和解決方案，尤其是現在空間數據倉庫在GIS 中的廣泛應用，它成為資料庫市場的新一輪增長點，同時也成為下一代信息系統的重要組成部分。

C. 數據倉庫度量值

成為STRING之後怎麼SUM？為什麼非要存為STRING呢 難道數據相當大？

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

作者 | 傅一平

來源 | 與數據同行

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

一、數據倉庫建模的意義

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

數據模型就是數據組織和存儲方法，它強調從業務、數據存取和使用角度合理存儲數據。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、標准化的推進：數據倉庫建模的任何實體都需要標准化命名，否則未來的管理成本巨大，也是後續數據有效治理的基礎，以下是我們的一個命名規范示例：

五、推薦三本書

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

E. 數倉建模 - 維度 vs 關系

數據管理一直在演進，從早期的電子表格、蛛網系統到架構式數據倉庫。發展至今以維度建模和關系建模為主，而隨著互聯網的發展，數據從GB到PB的裱花，企業業務迭代更新亦是瞬息萬變，對維度模型的偏愛漸漸有統一互聯網數倉建模標準的趨勢。

數倉模型不分高下，都是一種觀察現實的角度。維度模型以實體與實體之間發生的事務/實為切入，而關系建模則以實體與實體之間的關系來組織數據。在當前的環境下，互聯網更傾向於維度建模，而傳統行業則較多沿用關系建模。

個人先後經歷金融、互聯網數倉建設，有多個0到1的項目經歷，對於數倉建設仍在持續學習中。如有錯誤之處，還請多指出交流。

以事實表為核心，多個維度表作為手臂形成的星型模型，是維度建模的典型實現方式。

事實表，記錄業務過程中發生的可度量事件，如訂單中的消費金額，喊櫻雀折扣金額或是庫存數量等，在實際業務中事實表占據主要的存儲，如訂單表；而維度表，則是對業務過程度量有關的文本環境，描述「誰、什麼、哪裡、何時、如何、為什麼」，常用的維度表有日期、產品、用戶、地址等。一般維度表會冗餘信息，有超過100個列的維度表，這樣的不規范化帶來數據鄭早組織上的簡單。

關系建模，被稱為「實體-關系」模型，以一種「標准化」的方式存在，強調數據之間非冗頌差余，滿足3NF。在建設過程中，將數據標准化到細節級數據，如用戶主題下，會有用戶與姓名、用戶與年齡、用戶與住址等。在傳統行業中，成熟的關系建模有ls-ldm模型，面向金融行業形成10大主題。

維度建模 ： 從實際的需求出發進行數據建設，一般面向部門/業務形成獨立的數據集市，這樣的方式帶來鮮明的特點，高效。但由於基於需求出發，往往導致頻繁的需求迭代帶來的維護成本較高，一旦業務過程發生調整，模型有可能會重來的風險。

關系建模 ：面向企業進行模型建設，具有較強的抽象性。建設時以3NF的方式建設無冗餘的數據，使模型具有很高的靈活性，但由於不能直接面向需求，效率上不如維度模型。另外面向企業建設，周期相比於維度建模，要長的多，但也有個好處：企業數據集成更容易。

在企業內，這兩種建模方式往往同時存在，基礎數據倉庫的建設使用關系建模，技術的優雅換來了數據的精簡，保證高度抽象、高度一致性，要求業務穩定；往上維度建模更合適一些，偏向於直接面對業務，靠數據的冗餘帶來了可用性，保證查詢效率。兩者優勢互補

在大數據的環境下，數據存儲和發展已發生很大變化，曾經的維度建模和關系建模在當前的場景下都有各自的不足之處。那數據倉庫在大數據環境下如何發展、成熟？Inmon等就提出了data vault模型

data valult是一個面向細節的、歷史追溯的並且唯一鏈接的規范化表集，能給支持一個或者多個業務功能區；是一種中心輻射式模型，其設計重點圍繞著業務鍵的集成模式。data vault有三種基本的實體(結構)

從建模風格上看，它採用了一種由第三範式方法與維度建模方法混合而成的方式，以二者的獨特組合來滿足企業需求。

F. 01.數倉常見概念術語

前兩天看了大魚先生寫了一篇數倉中指標-標簽、維度-度量、自然鍵-代理鍵的文章，對於數倉中的各種概念又有新的理解和認識。寫一篇做備忘。本文主要從三組概念來進行對比說明；
先來看幾個單獨的概念，這幾個也是數倉模型構建的前提准備

舉一個例子：比如某個商店賀笑中有海爾電視、海信電視、索尼電視等，這念拍御些數據共同組成了一個電視實體表，並表中不含有可度量的數據。商店某天出售5台海爾電視、10台海信電視、1台索尼電視，這些電視銷售數據就組成了一個事實表。這樣從時間維度仔岩就可以對該商店的銷售量進行統計分析了。

舉個例子：某家庭，客廳中有一個立櫃空調、卧室有一個掛機空調，兩種空調即為兩種分類，對於空調來說也是它的屬性。某個月份，該家庭用電180千瓦時，高於70%家庭用電量劃分為高用電量家庭，其中180千瓦時就是指標，高用電量用戶，為該家庭打上的標簽。

參考 大魚的數據人生 、 五分鍾學大數據

G. 請天才指教什麼是度量數據

統計學:指用一定的工具或一定的標准測量所得的數據

H. 數據倉庫建模概念

匯流排矩陣是一個二維表格，每一行對應一個 業務線 ，每一列對應一個 維度 ，每一個交叉點對應了業務和維度的聯系

我們在業務分析時使用雪花模型，最終存儲到數據倉庫中的是星型模型。

事實表由度量值和維度值組成，度好櫻笑量值反應了該業務過程涉及的數字指標，維度值反應了該業務過程的維度信息。

原子粒度，聚集事實表。

一定要頌扒從原子粒度開始設計。

存儲外鍵關聯維度

退化維度（DD, Degradation dimension）

Operational Data Store，數據運營層。從其他業務系統抽取的數據，直接存儲。

Data Warehouse，數據倉庫層，內部又劃分為3層。

維度表

服務特定的應用，友含復用性不強，存儲在響應速度較快的存儲引擎。例如報表數據。

I. 大數據分析基礎——維度模型

維度模型的概念出自於數據倉庫領域，是數據倉庫建設中的一種數據建模方法。維度模型主要由事實表和維度表這兩個基本要素構成。

維度是度量的環境，用來反映業務的一類屬性 ， 這類屬性的集合構成一個維度 ， 也可以稱為實體對象。 維度屬於一個數據域，如地理維度(其中包括國家、地區、 省以及城市等級別的內容)、時間維度(其中包括年、季、月、周、日等級別的內容)。

維度是維度建模的基礎和靈魂。在維度建模中，將度量稱為「事實」 ， 將環境描述為「維度」，維度是用於分析事實所需要的多樣環境。例如， 在分析交易過程時，可以通過買家、賣家、商品和時間等維度描述交易發生的環境。

維度所包含的表示維度的列，稱為維度屬性。維度屬性是查詢約束條件、分組和報表標簽生成的基本來源，是數據易用性的關鍵。

事實表是維度模型的基本表，每個數據倉庫都包含一個或者多個事實數據表。事實數據表可能包含業務銷售數據，如銷售商品所產生的數據，與軟體中實際表概念一樣。

事實表作為數據倉庫維度建模的核心，緊緊圍繞著業務過程來設計，通過獲取描述業務過程的度量來表達業務過程，包含了引用的維度和與業務過程有關的度量。

事實表中一條記錄所表達的業務細節程度被稱為粒度。通常粒度可以通過兩種方式來表述:一種是維度屬性組合所表示的細節程度:一種是所表示的具體業務含義。

作為度量業務過程的事實，一般為整型或浮點型的十進制數值，有可加性、半可加性和不可加性三種類型。

相對維度來說，通常事實表要細長，行的增加速度也比維度錶快的多，維度表正好相反。

事實表有三種類型 :

原子指標和度量含義相同，基於某一業務事件行為下的度量，是業務定義中不可 再拆分的指標，具有明確業務含義的名詞 ，如支付金額。

事實表和維度交叉匯聚的點，度量和維度構成OLAP的主要概念，這裡面對於在事實表或者一個多維立方體裡面存放的數頌瞎值型的、連續的欄位，就是度量。

維度表是事實表不可分割的部分。維度表是進入事實表的入口。豐富的維度屬性給出了豐富的分析切割能力。維度給用戶提供了使用數據倉庫的介面。最好的屬性是文本的和離散的。屬性應該是真正的文字而不應是一些編碼簡寫符號。應該通過用更為詳細的文本屬性取代編碼，力求最大限度地減少編碼在維度表中的使用。

維度表和事實表二者的融合也就是「維度模型」，「維度模型」一般採用「星型模式」或者「雪花模式」，「雪花模式」可以看作是「星型模式」的拓展，表現為在維度表中，某個維度屬性可能還存在更細粒度的屬性描述，即維度表的層級關系。

維度屬性也可以存儲到事實表中，裂肢這種存儲到事實表中的維度列被稱為「退化維度」。與其他存儲在維表中的維度一樣 ，退化維度也可以用來進行事實表的過濾查詢、實現聚合操作等。

下表顯示的是一個維度（「城市」）和兩個指標（「會話數」和「每次會話瀏覽頁數」）。

維度中的一些描述屬性以層次方式或野源空一對多的方式相互關聯，可以被理解為包含連續主從關系的屬性層次。比如商品類目的最低級別是葉子類目，葉子類目屬於二級類目，二級類目屬於一級類目。在屬性的層次結構中進行鑽取是數據鑽取的方法之一。

當屬性層次被實例化為一系列維度，而不是單一的維度時，被稱為雪花模式。

大多數聯機事務處理系統( OLTP)的底層數據結構在設計時採用此種規范化技術，通過規范化處理將重復屬性移至其自身所屬的表中，刪除冗餘數據。

將維度的屬性層次合並到單個維度中的操作稱為反規范化。分析系 統的主要目的是用於數據分析和統計，如何更方便用戶進行統計分析決 定了分析系統的優劣。採用雪花模式，用戶在統計分析的過程中需要 大 量的關聯操作，使用復雜度高，同時查詢性能很差;而採用反規范化處 理，則方便、易用且性能好。

數據倉庫匯流排架構的重要基石之一就是一致性維度。在針對不同數 據域進行迭代構建或並行構建時，存在很多需求是對於不同數據域的業 務過程或者同 一數據域的不同業務過程合並在 一起觀察。比如對於日誌數據域，統計了商品維度的最近一天的 PV 和 UV; 對於交易數據域， 統計了商品維度的最近一天的下單MV。現在將不同數據域的商品的 事實合並在一起進行數據探查 ，如計算轉化率等，稱為交叉探查。

我們先來看數據倉庫的定義:數據倉庫是一個面向主題的、 集成的 、 非易失的且隨時間變化的數據集合，用來支持管理人員的決策。

數據由面向應用的操作型環境進人數據倉庫後，需要進行數據 集成。將面向應用的數據轉換為面向主題的數據倉庫數據，本身就是一種集成。

具體體現在如下幾個方面:

表級別的整合，有兩種表現形式。

水平拆分
維度通常可以按照類別或類型進行細分。由於維度分類的不同而存在特殊的維度屬性，可以通過水平拆分的方式解決此問題。

在設計過程中需要重點考慮以下三個原則。

根據數據模型設計思想，在對維度進行水平拆分時，主要考慮如下兩個依據。

垂直拆分
在維度設計內容中，我們提到維度是維度建模的基礎和靈魂，維度 屬性的豐富程度直接決定了數據倉庫的能力。在進行維度設計時，依據 維度設計的原則，盡可能豐富維度屬性，同時進行反規范化處理。

某些維度屬性的來源表產出時間較早，而某些維度屬性的來 源 表產出時間較晚;或者某些維度屬性的熱度高、使用頻繁，而某些維度屬性的熱度低、較少使用 ; 或者某些維度屬性經常變化，而某些維度屬性比較穩定。在「水平拆分」中提到的模型設計的三個原則同樣適合解決此問題。

出於擴展性、產出時間、易用性等方面的考慮，設計 主從維度。主 維表存放穩定 、 產出時間早、熱度高的屬性;從維表存放變化較快、產 出時間晚、熱度低的屬性。

參考
《The Data Warehouse Toolkit-The Complete Guide to Dimensional Modeling》
《Google Analytics》
《大數據之路》

歡迎關注 高廣超的博客 與 收藏文章 ！
歡迎關注 頭條號：互聯網技術棧 ！

J. 對於維度建模的理解

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

維度建模是 數據倉庫/商業智能 項目成功的關鍵，為什麼這么說，因為不管我們的數據量從GB到TG還是到PB，雖然數據量越來越大，但是數據展現要獲得成功，就必須建立在簡單性的基礎之上，而維度建模就是時刻考慮如何能夠提供簡單性，以業務為驅動，以用戶理解性和查詢性能為目標。

維度建模：維度建模是專門應用於分析型資料庫、數據倉庫、數據市集建模的方法。數據市集可以理解為一種「小型的數據倉庫」 維度建模指導我們在數據倉庫中如何建表

維度建模分為兩種表：事實表和維度表

• 事實表：必然存在的一些數據，像採集的日誌文件，訂單表，都可以作為事實表
  特徵：是一堆主鍵的集合，每個主鍵對應維度表中的一條記錄，客觀存在的，根據主題確定出需要使用的數據

• 維度局啟表：維度就是所分析的數據的一個量，維度表就是以合適的角度來創建的表，分析問題的一個角度：時間、地域、終端、用戶等角度

維度建模的三種模式

• 星形模式：以事實表為中心，所有的維度表直接連在事實表上，最簡單最常用的一種



• 星座模型：基於多張事實表，而且共享維度信息，即事實表之間可以共享某些維度表