數(shù)倉理論基礎(chǔ)

引用：尚硅谷電商數(shù)倉

為樂東黎族等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計制作服務(wù)，及樂東黎族網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為網(wǎng)站設(shè)計制作、網(wǎng)站制作、樂東黎族網(wǎng)站設(shè)計，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會得到認(rèn)可，從而選擇與我們長期合作。這樣，我們也可以走得更遠(yuǎn)！

什么是數(shù)倉？

存儲數(shù)據(jù)、具備管理 分析能力，為企業(yè)做決策提供數(shù)據(jù)依據(jù)。

數(shù)據(jù)倉庫的主體 hive

兩種建模方式： ER和維度

ER模型

實體關(guān)系模型： 將復(fù)雜的數(shù)據(jù)抽象為 實體和關(guān)系。實體表示一個對象，關(guān)系指的是兩個實體之間的關(guān)系，比如學(xué)生和班級之間的從屬關(guān)系。

舉例：學(xué)生管理系統(tǒng) 管理學(xué)生和班級的信息

1.抽取實體： 學(xué)生、班級

2.實體關(guān)系模型 一對多 畫圖 ER圖

3.建表，通常一個實體對應(yīng)一張表，通過外鍵進(jìn)行關(guān)聯(lián)，通常在多的一側(cè)加外鍵，比如在學(xué)生一側(cè)加上班級信息

多對多關(guān)系模型，比如說又加了一個學(xué)生選課信息

學(xué)生表和選課表是多對多的關(guān)系，一個學(xué)生可以選多門課，一門課可以被多個學(xué)生選。

處理多對多的表一般需要加一個中間表。 學(xué)生id 和選課id

數(shù)據(jù)庫規(guī)范化

范式：normal form 有6種

函數(shù)：一個x對應(yīng)一個y

• 完全函數(shù)依賴：f(x,y)=z 必須通過x，y得到一個z，z完全依賴于x y
• 部分函數(shù)依賴 f(x,y)=z z部分函數(shù)依賴于 x y k
• 傳遞函數(shù)依賴

第一范式

屬性不可切割，指的是實體的屬性。（也就是列不可再分）

比如5臺電腦 可以被拆成數(shù)量5 和電腦

第二范式

不能存在 非主鍵字段 部分函數(shù)依賴于主鍵字段

比如上面這張表中 聯(lián)合主鍵字段是 學(xué)號+課名，分?jǐn)?shù)完全依賴于學(xué)號+課名，但是姓名部分依賴于學(xué)號，所以不滿足第二范式。解決方案是把表拆成兩個。能夠部分減少函數(shù)冗余。

但也存在冗余 比如說 經(jīng)濟(jì)系和王強(qiáng)存儲了兩份數(shù)據(jù)了。

第三范式

不能存在非主鍵字段傳遞函數(shù)依賴于主鍵字段

學(xué)號能夠推出系名—系名能夠推出系主任

這種數(shù)據(jù)建模的主要目的主要是減少數(shù)據(jù)冗余，保證數(shù)據(jù)的一致性并不適合用于分析統(tǒng)計。

維度模型

通過事實和維度進(jìn)行呈現(xiàn)。

事實通常對應(yīng)業(yè)務(wù)過程，例如下單、支付、加入購物車等

維度：業(yè)務(wù)過程發(fā)生時所處的環(huán)境，客觀的事物（時間、地點等）、用戶信息

如上圖所示，中間的是事實表，旁邊的一圈是維度表

事實表

事實表：包含兩個維度外鍵和度量值

維度外鍵：和其他表關(guān)聯(lián)的外鍵id

度量：（量化業(yè)務(wù)過程 比如下單金額 下單數(shù)量）

事實表的特點是細(xì)長，因為記錄了一些事實信息，會有很多，行的增速會比較快。

事實表分類：事務(wù)型事實表、周期型快照事實表、累積型快照事實表

事務(wù)型事實表

• 事務(wù)型事實表：對應(yīng)一個過程，保存最細(xì)粒度操作時間

最細(xì)粒度，能滿足更多的需求。如何理解呢？ 如果訂單事實表中只有支付金額，沒有具體購買數(shù)量，那么就無法滿足統(tǒng)計購買總量的需求。

設(shè)計流程

遵循以下4個步驟

選擇業(yè)務(wù)過程→聲明粒度→確認(rèn)維度→確認(rèn)事實

1.選擇業(yè)務(wù)過程

根據(jù)業(yè)務(wù)需求，比如下單、付款、退單等

2.聲明粒度

粒度要盡可能細(xì)，即每行數(shù)據(jù)表示什么。比如訂單表中最細(xì)粒度要到一行數(shù)據(jù)表示一個sku

3.確定維度

確定每張事務(wù)型事實表相關(guān)的維度有哪些。即時間、地點、人物等信息

維度的豐富程度決定了指標(biāo)的豐富程度，比如按時間統(tǒng)計、按地點統(tǒng)計等

4.確認(rèn)事實

事實就是每個業(yè)務(wù)過程的度量值，比如金額、個數(shù)、次數(shù)等可累加的值

不足

• 存量型指標(biāo)的統(tǒng)計效率較低

  如何理解？ 什么是存量型指標(biāo)，比如說京東的京豆，主要包括獲取京豆和消費京豆，設(shè)計到兩張事實表。A表示獲取京豆的事實表，B表示消費京豆的事實表。

  需求：統(tǒng)計截止當(dāng)日所有用戶的剩余京豆的數(shù)量。

  思路：需要關(guān)聯(lián)兩張事實表A.B，做一個聚合操作，事實表通常是比較大的，所以效率比較低。

• 多事務(wù)關(guān)聯(lián)統(tǒng)計

  需求：統(tǒng)計近30天用戶從下單到支付的平均時間間隔。

  思路：關(guān)聯(lián)下單事實表和支付事實表，按照訂單id進(jìn)行join，支付時間減去下單時間，再求平均值。需要大表join大表，效率也會比較低。

周期快照事實表

周期性打快照，保存某一個表（mysql 中的表）的當(dāng)前狀態(tài)，通常是一個分區(qū)表，一天一個分區(qū)。直接同步現(xiàn)有的結(jié)果，從結(jié)果中拿數(shù)據(jù)。

典型指標(biāo)：

• 存量型：如賬戶余額 商品庫存等。業(yè)務(wù)系統(tǒng)中會有對應(yīng)的此表，直接同步過來即可，以滿足存量型指標(biāo)的統(tǒng)計。
• 狀態(tài)型：溫度、形式速度等。變化的值通常是連續(xù)的，無法捕獲原子事務(wù)操作，只能定期采樣。

設(shè)計流程

確定粒度→確認(rèn)事實

1.確定粒度

采樣周期和維度確定粒度。

采樣周期一般是天

維度是要統(tǒng)計的指標(biāo)，例：統(tǒng)計每個倉庫每種商品的庫存。

這樣就能確定粒度：每天的每個倉庫的商品庫存

2.確認(rèn)事實

根據(jù)統(tǒng)計指標(biāo)確定，如商品、倉庫

事實類型

可加事實：可按照維度表進(jìn)行累加。

半可加事實：只能按照一部分維度累加是有意義的，周期快照事實表都是半可加事實。 日期+倉庫+商品維度 放的是存量信息 按照日期累加是沒有意義的。

不可加事實：比率型事實。比率相加會超過1，但是比率不可能會超過1，一般要避免這種表的出現(xiàn)。可以把比率轉(zhuǎn)換成分子和分母。

累積型快照事實表

基于一個業(yè)務(wù)流程的多個業(yè)務(wù)過程。

通常具有多個日期字段。數(shù)據(jù)不是一次性寫完的，如下表

訂單id	用戶id	下單日期	支付日期	發(fā)貨日期	確認(rèn)收貨日期	訂單金額	支付金額
1001	1234	2020-06-14	2020-06-15	2020-06-16	2020-06-17	1000	1000

發(fā)貨、收獲日期等都是后來才寫入的。主要是用戶滿足時間間隔需求，比如前文提到的平均時間。

設(shè)計流程

選擇業(yè)務(wù)過程→ 確認(rèn)粒度 →確認(rèn)維度 → 確認(rèn)事實

1.選擇業(yè)務(wù)過程

對應(yīng)了多個業(yè)務(wù)過程，例如上表中的下單-支付-發(fā)貨-確認(rèn)收貨

2.確認(rèn)粒度

事實表的一行的數(shù)據(jù)表示粒度

3.確認(rèn)維度

與業(yè)務(wù)過程相關(guān)的維度，這里每個業(yè)務(wù)過程都有一個日期維度

4.確認(rèn)事實

各業(yè)務(wù)過程的度量值，比如上表中的訂單金額、支付金額。

維度表

事實表周圍得一圈就是維度表，一個維度表得基本組成就是一個主鍵字段和各種維度字段。

設(shè)計步驟

確定維度表->確定主維表和相關(guān)維表->確定維度屬性

1. 確定維度表

與事實相關(guān)得維度都要確定。某些維度比較少，可以直接在事實表中增加字段。比如支付方式 只有微信、支付寶、銀聯(lián)等 可以在事實表中增加響應(yīng)得字段。這個操作叫做維度退化

為什么要維度退化？找到如下的解釋

因為簡單的模式比復(fù)雜的更容易理解，也有更好的查詢性能。

應(yīng)該就是減少了join操作吧。

2. 確定主維表和相關(guān)維表

主維表：

3. 確定維度屬性

就是確定維度表字段，維度屬性就是主維表和相關(guān)維表的一些字段。

需要遵循以下需求：

• 盡可能多的維度屬性
• 盡量不適用編碼，使用文字說明，比如支付方式1表示支付寶，一般存儲支付寶
• 某個經(jīng)常用的維度屬性可以提前拼接

設(shè)計要點

• 規(guī)范化 與反規(guī)范化

星型模型和雪花模型：區(qū)別就是對于維度表是否進(jìn)行規(guī)范化設(shè)計

規(guī)范化設(shè)計得到的是雪花模型。比較接近范式建模，維度表會被拆分的比較細(xì)。

反規(guī)范化設(shè)計得到的是星型模型。

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來直接上傳(img-7vf7go5Z-1669446110255)(數(shù)倉項目.assets/image-20221126144826420.png)]

• 維度變化

  維度會改變的，我們需要保存歷史維度數(shù)據(jù)或者說是狀態(tài)，有兩種方法。全量快照表和拉鏈表

  • 全量快照表

    每天全量同步，保存一份維度數(shù)據(jù)。浪費點存儲空間

  • 拉鏈表

    記錄生命周期，狀態(tài)改變了，就新增一條記錄。如下表

    [外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來直接上傳(img-ilBlbupt-1669446110256)(數(shù)倉項目.assets/image-20221126145247285.png)]

    節(jié)省了存儲空間，比較適合與變化不大的維度表。如下表，手機(jī)號碼變化不大，每天全量快照會浪費比較多的存儲

    [外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來直接上傳(img-49OCYke2-1669446110256)(數(shù)倉項目.assets/image-20221126145336321.png)]

    缺點就是制作起來比較麻煩，在存儲成本較低的今天，更多的是采用全量快照表的方式。

• 多值維度

  一條記錄對應(yīng)多種維度，如一個訂單對應(yīng)多種商品，如何解決呢？

  • 降低事實表的粒度，讓一個訂單對應(yīng)一個商品項
  • 事實表中增加字段，前提是維度個數(shù)固定

• 多值屬性

  維度表的某個屬性有多個值，比如一個手機(jī)可以有 品牌、內(nèi)存、CPU等屬性

  解決辦法

  • 將多值屬性放到一個字段，用key value表示 “k1:v1,k2:v2”
  • 將多值放到多個字段，前提是屬性個數(shù)固定

你是否還在尋找穩(wěn)定的海外服務(wù)器提供商？創(chuàng)新互聯(lián)www.cdcxhl.cn海外機(jī)房具備T級流量清洗系統(tǒng)配攻擊溯源，準(zhǔn)確流量調(diào)度確保服務(wù)器高可用性，企業(yè)級服務(wù)器適合批量采購，新人活動首月15元起，快前往官網(wǎng)查看詳情吧

當(dāng)前標(biāo)題：數(shù)倉理論基礎(chǔ)-創(chuàng)新互聯(lián)
新聞來源：http://aaarwkj.com/article32/copcsc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站設(shè)計、網(wǎng)站排名、網(wǎng)站建設(shè)、移動網(wǎng)站建設(shè)、App設(shè)計、響應(yīng)式網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)