資料倉儲建設--olap和資料立方體概念
2.相關概念
（1）維
是人們觀察資料的特定角度，是考慮問題時的一類屬性集合構成乙個維（如時間維、地理維等）。
（2）級別（level）
人們觀察資料的某個特定角度（即某個維）還可以存在細節程度不同的各個描述方面（如時間維：日期、月份、季度、年）。即維的級別。
（3）成員（member）
維的乙個取值，是資料項在某維中位置的描述。（「某年某月某日」是在時間維上位置的描述）。
（4）度量（measure）
多維陣列的取值，如「某年某月某日的工資」。
（5）鑽取（drill-up和drill-down）
改變維的層次，變化分析的粒度。drill-up是將低層次的資料概括到高層次的彙總資料或者說是減少維度；drill-up則是相反，是將彙總的資料深入到細節，或說是增加新維。
（6）切片和切面
是在一部分維上選定值後，關心度量資料在剩餘維上的分布。如果剩餘的維只有兩個，則是切片；如果有三個或以上，則是切塊。
（7）旋轉
是變換維的方向，即在**中重新安排維的放置（例如行列互換）
根據事實表和維度表的關係，又可將常見的模型分為星型模型和雪花型模型。
星形模型：當所有維度表連線到事實表上的時候，整個圖就像乙個星星，故稱之為星型模型。星型架構是一種非正規化的結構，多維資料集的每乙個維度都直接與事實表相連，不存在漸變維度，所以資料有一定冗餘。因為有冗餘，所以很多統計不需要做外部的關聯查詢，因此一般情況下效率比雪花模型高。維表對應於各個分析的角度，它除了主鍵以外還包含描述和分類資訊。
雪花模型：當有多個維度表沒有直接連線到事實表上，而是通過其他維度表連線到事實表上時，其圖形就像雪花，故稱雪花模型。雪花模型的優點是減少了資料冗餘，所以一般情況下查詢需要關聯其他表。在冗餘可接受的前提下使用星型模型。
星型模型和雪花模型的區別在於：維度表是直接連線到事實表還是其他維度表。
比如按省市縣的維度分析銷量。星形模型的銷量事實表中字段有id,省code,市code,縣code，銷量。事實表直接與省、市、縣關聯。而雪花模型銷量事實表中字段有id,縣code，銷量。在按省分析銷量時，事實表—縣維度—市維度—省維度關聯起來分析。
3.星座模式
星座模式(fact constellations schema)也是星型模式的擴充套件。基於這種思想就有了星座模式：
前面介紹的兩種維度建模方法都是多維表對應單事實表，但在很多時候維度空間內的事實表不止乙個，而乙個維表也可能被多個事實表用到。在業務發展後期，絕大部分維度建模都採用的是星座模式。
在設計大資料處理系統時，首先需要從這兩個層面來考慮，需要考慮的因素包括：1、資料大小有多大；2、資料如何使用；3、資料更新頻率。
從目前來看需要大資料的主要應用領域，也只有兩個：聯機事務處理oltp（on-line
transaction processing）、聯機分析處理olap（on-line analytical processing）。
oltp
分層、分片、分布式事務
olap
是資料倉儲系統的主要應用，支援複雜的分析操作，側重決策支援，並且提供直觀易懂的查詢結果。一般不需要表關聯，直接讀取單錶即可。
olap主要是做離線分析，對時效性要求不高，跑幾個小時到幾天問題都不大，並且機器掛了也沒事，大不了restart一下。但是這種系統往往資料量非常大，維數特別多，基本都需要把歷史資料全部掃瞄1-2遍。在設計olap系統裡主要涉及到技術有：
列儲存、降維、切分
oltp
olap 使用者
操作人員，低層管理人員
決策人員，高階管理人員 功能
日常操作處理
分析決策 設計
面向應用
面向主題 資料
當前的， 最新的細節的， 二維的分立的
歷史的， 聚集的， 多維的，整合的， 統一的 訪問
讀/寫數十條記錄
讀上百萬條記錄
工作單位
簡單的讀寫
複雜查詢
db大小
0-100g
tb-pb級別
oltp做起來相對容易。小型專案用mysql+redis+memcached足夠應付。大型專案在開源社群的支援下，hadoop
+hbase+redis也可以從無到有地應對需求。而大型商業產品推出的分布式資料庫，和一些開源分布式產品，例如**開源的oceanbase都在保證分布式資料庫的acid的原子性上進行了一定程度的嘗試。
olap較為複雜，由於資料是多維的， sql語言hold不住了。在這方面建模和抽象變得很重要，如何解決資料的語義性和查詢的可描述性變得很困難。目前olap主要的開源產品包括hdfs、hive和impala等
總體來看，如何根據需求來設計系統才是乙個技術人員需要考慮的問題，過分的設計和過分的資源消耗都是不合適。下次我們再介紹下oltp裡的分層思想
講解利用vs建立乙個商業智慧型專案->analysis services專案。簡單講解如何建立維度表、事實表和分析報表。
寫的特別好。重點看下。
雖然，維表的資料比事實表更穩定。但不論如何維度在某些時候總會發生一些變化。在之前曾丟擲乙個問題：為什麼維度建模後的關係不是***id，而是***key了。這樣做的目的其實就是為了解決一種被稱為緩慢維度變化(slowly changing dimension)的問題。在維度變化後，一部分歷史資訊就被丟掉了。比如張三是某公司會員。
但僅僅這麼做還是不夠的，**碼需要配合時間戳，以及行識別符號使用才能解決緩慢維度變化的問題。如下customer表使用該方法避免緩慢維度變化：
可以看到使用者張三對應新維度的taxbracket狀態由low變成了high。如果需要統計張三的相關行為，那麼可以讓所有記錄用customerid欄位join事實表；如果要統計當前taxbracket為low的使用者狀態，則可將row indicator欄位為current的記錄用customerkey欄位join事實表；如果要統計歷史taxbracket狀態為low的使用者情況，則只需要將taxbracket屬性為low的使用者記錄的customerkey屬性與事實表關聯。
OLAP學習筆記1
當今的資料處理大致可以分成兩大類 聯機事務處理oltp on line transaction processing 聯機分析處理olap on line analytical processing oltp是傳統的關係型資料庫的主要應用，主要是基本的 日常的事務處理，例如銀行交易。olap是資料倉...
OLAP了解與OLAP引擎
一 olap的基本概念 二 olap的基本內容 1 變數 度量 變數是資料度量的指標，是資料的實際意義，即描述資料 是什麼 像示例中的人數。2 維度 維度是描述與業務主題相關的一組屬性，單個屬性或屬性集合可以構成乙個維。如示例中的學歷 民族 性別等都是維度。3 維的層次 乙個維往往可以具有多個層次，...
資料倉儲與資料探勘學習筆記（三）OLAP技術
學習心得 一 什麼是olap？在以前20世紀60年代末，關係型資料庫與oltp得到了快速發展，隨著時間的延續，全球資料暴增，越來越多的資料被生產，同時人們對資訊的需求也更加發雜，希望盡可能從gb,tb甚至pb資料直觀的連線隱藏在這些資料背後的資訊，傳統的oltp顯得力不從心了，於是資料倉儲跟olap...