理論篇 第四章 維度設計

2021-08-09 02:35:05 字數 3433 閱讀 9870

1.1 維度的基本概念

維度是維度建模的基礎和靈魂。在維度建模中,將度量稱為「事實」,將環境描述稱為「維度」,維度是用於分析事實所需要的多樣環境。

維度使用主鍵標識其唯一性,主鍵也是確保與之相連的任何事實表之間存在引用完整性的基礎。主鍵有**鍵和自然鍵,它們都是用來表示某維度的具體值。但**鍵是不具有業務含義的鍵,一般用於處理緩慢變化維;自然鍵是具有業務含義的鍵。比如商品,在etl過程中會生成商品維表唯一標識的**鍵,但沒有業務含義。商品本身的自然鍵是商品id。

1.2 維度的基本設計方法

維度設計過程就是確定維度屬性(維度字段)的過程,如何生成維度屬性,以及所生成的維度屬性的優劣,決定了維度使用的方便性,成為資料倉儲易用性的關鍵。正如kimball所說的,資料倉儲的能力直接與維度屬性的質量和深度成正比。

下面以**的商品維度為例對維度設計方法進行詳細說明。

第一步:選擇維度或新建維度。作為維度建模的核心,在企業級資料倉儲中必須保證維度的唯一性。

第二步:確定主維表。此處的主為表一般是ods表。以**商品維度為例,商品表是與前台商品中心系統同步的,即是主維表。

第四步:確定維度屬性。本步驟主要包括兩個階段,其中第乙個階段是從主維表中選擇維度屬性或生成新的維度屬性;第二個階段是從相關維表中選擇維度屬性或生成新的維度屬性。以**為例,從主維表和類目、spu、賣家、店鋪等相關維表中選擇維度屬性或生成新的維度屬性。

(1)盡可能生成豐富的維度屬性。

(2)盡可能多地給出包括一些富有意義的文本性描述。

(3)區分數值型屬性和事實。

(4)盡量沉澱出通用的維度屬性。

1.3 維度的層次結構

維度中的一些描述屬性以層次方式或一對多的方式相互關聯,可以被理解為包含連續主從關係的屬性層次。可以根據維度的上下關係上鑽或下鑽。

1.4 規範化和反規範化

規範化是指將屬性層次被例項化為一系列維度,而不是單一的維度,也被稱為雪花模式。

反規範化則是與規範化相反,將屬性層次合併到單一的維度。

1.5 一致性維度和交叉探查

kimball的資料倉儲匯流排架構提供了一種分解企業級資料倉儲規劃任務的合理方法,通過構建企業範圍內一致性維度和事實來構建匯流排架構。

在針對不同資料域進行迭代構建或並行構建時,存在很多需求是對於不同資料域的業務過程或者同乙個資料域的不同業務過程合併在一起觀察。比如對於日誌資料域,統計了商品維度的最近一天pv和uv;對於交易資料域,統計了商品維度的最近一天的下單gmv。現在將不同資料域的商品的事實合併在一起進行資料探查,如計算轉化率等,稱為交叉探查。

2.1 維度整合

維表整合的內容:

業務含義相同的表統一,有以下幾種整合方式:

下面看看表級的整合方式:

2.2 水平拆分

維度通常按類別或型別進行細分。在一系列的維表裡,有共同的維度屬性,也有各自獨特的維度屬性,針對這種情況,我們主要有兩種解決方案:方案一是將維度的不同分類例項化為不同的維度,同時在主維度中保留公共屬性;方案二是維護單一維度,包含所有可能的屬性。

選擇哪個方案,需要考慮以下上原則:

2.3 垂直拆分

根據維度屬性的熱度不同、使用頻率不同來垂直拆分維度字段。按可擴充套件性、效能和易用性,設計主從維度。主維表存放穩定、產出時間早、熱度高的屬性;從維表存放變化快、產出晚、熱度低的屬性。

2.4 歷史歸檔

定期將歷史資料歸檔至歷史維表。

3.1 緩慢變化維

資料倉儲的重要特點之一反映歷史變化,所以如何處理維度的變化是維度設計的重要工作之一。

第一種處理方式:重寫維度值。不需要保留歷史資料。

以商品所屬類目變化情況為例,具體描述:

變化前商品表和訂單表

商品key

商品id

商品標題

所屬類目

其他維度屬性

1sp001

title1

類目1...

訂單key

日期key

商品key

交易金額

其他事實

d12017-10-01

sp001

1000.0

....

變化後商品表和訂單表

商品key

商品id

商品標題

所屬類目

其他維度屬性

1sp001

title1

類目2....

訂單key

日期key

商品key

交易金額

其他事實

d12017-10-01

sp001

1000.0

...d1

2017-10-02

sp001

2000.0

...

第二種處理方式:插入新的維度行。

第三種處理方式:新增維度列。

3.2 快照維表

資料倉儲對**表進行全量或增量資料抽取,不做任何變動。

3.3 極限儲存

歷史拉鍊儲存就是處理維度模型中緩慢變化的一種方式,通過新增兩個時間戳字段(start_dt和end_dt),將所有以天為粒度的變更資料記錄下來。通常分割槽欄位也是時間戳字段。這種儲存方式存在下游資料使用方理解障礙,而且使用start_dt和end_dt做分割槽,隨著時間的推移,分割槽數量會極度膨脹,而現行的資料庫體系都有分割槽數量限制。

針對上述兩個問題,阿里提出採用極限儲存方式處理,分月做歷史拉鍊表,及每月月初重現開始做歷史拉鍊表。(極限儲存有侷限性,不太適合高變化率的資料,不太建議使用)

3.4 微型維度

微型維度的建立是通過將一部不穩定的屬性從主維度中移除,並將它們放置到擁有自己**鍵的新錶中來實現。(不建議使用,etl加工邏輯複雜)

4.1 遞迴層次

維度遞迴層次,按照層次是否固定分為均衡層次結構和非均衡層次結構。例如:地區,分別是鄉鎮/街道、區縣、城市、省份、國家,這類有固定層次為均衡層次結構;公司之間的關係,每個公司可能存在乙個母公司,但可能沒有一級、二級等層級關係,對這種沒有固定層次為非均衡層次結構。

在遞迴層次中進行上鑽和下鑽,會使用到遞迴。而在很多資料倉儲系統和商業智慧型工具不支援遞迴sql,且使用者使用遞迴sql的成本較高。所以,建議對層次結構進行處理:

1 層次結構扁平化            

通過建立維度固定數量級別的屬性來實現,可以一定程度上解決上鑽和下鑽的問題。 但可能存在以下上方面問題:

(1)針對上鑽和下鑽之前,必須知道所屬的類目層次。

(2)所此層次為葉子層(即沒有下層),則無法下鑽和上鑽。針對這個問題,可以此層次的上層或下層填本層科目,虛擬科目。

(3)扁平化僅包含固定數量的級別,對均衡層次結構,可以通過預留級別的方式解決,但擴充套件性較差。

2 層次橋接表

針對扁平化所存在的問題,可以使用橋接表的方式解決,即中間設定中間對照表,關聯兩者。該方法適合解決更寬泛的分析問題,靈活性好;但複雜性高,使用成本高。

4.2 行為維度

省略4.3 多值維度

省略4.4 多值屬性

省略4.5 雜項維度

省略

js 設計模式 第四章

繼承 why?多個類公用的功能,如果重複拷貝,一方面,工作量大,另一方面,如果公用功能需要修改,則需要修改所有類中的這個功能,重複工作量大。為了減少複製以及帶來的不利於修改的問題,我們需要繼承 how?三種方法 classical inheritance prototypal inheritance...

第四章 繼承

一 為什麼要繼承 在物件導向中我們將具有很多重複內容的類中的內容提取出來,寫成乙個單獨的類 其他類只需要繼承就能取得這些功能,同時可以在自己類中寫入獨特的自定義方法 二 繼承語法 inte ce circle nsobject 繼承是在介面中定義的 冒號後的類名是要整合的類,nsobject 是co...

第四章 物件

三個特性 身份 型別 值 每個物件都有唯一的身份來標識自己,使用內建函式id 得到。例子 usr bin env python coding utf 8 a 32 print a b a print id a id b 結果 d python27 python.exe e workp python ...