數倉緩慢變化維深度講解

前言

         維度緩慢變化爲SCD(Slowly Changing Dimensions)一些維度表的數據不是靜態的,而是會隨着時間而緩慢地變化(這裏的緩慢是相對事實表而言,事實表數據變化的速度比維度錶快,若是還不知道什麼是事實表和維度表請看→數倉模型設計詳細講解)把處理維度表數據歷史變化的問題,稱爲緩慢變化維問題,簡稱SCD問題。1e889fdd2c53bc0371b395a093b9cbe3.jpggit

舉例說明

         例如:用根據用戶維度,統計不一樣出生年份的消費金額佔比。(80後、90後、00後)。而期間,用戶可能去修改用戶數據,例如:將出生日期改爲了 1992年。此時,用戶維度表就發生了變化。固然這個變化相對事實表的變換要慢。但這個用戶維度表的變化,就是緩慢變化維。5c7cfdb021f3cf543fad04c8957d4b1d.jpg這個用戶的數據不是一直不變,而是有可能發生變化。例如:用戶修改了出生日期、或者用戶修改了住址。程序員

1、SCD問題的幾種解決方案

如下爲解決緩慢變化維問題的幾種辦法:github

  • 保留原始值
  • 改寫屬性值
  • 增長維度新行
  • 增長維度新列
  • 添加歷史表

1.1 保留原始值

某一個屬性值毫不會變化。事實表始終按照該原始值進行分組。例如:出生日期的數據,始終按照用戶第一次填寫的數據爲準面試

1.2 改變屬性值

  • 對其相應須要重寫維度行中的舊值,以當前值替換。所以其始終反映最近的狀況
  • 當一個維度值的數據源發生變化,而且不須要在維度表中保留變化歷史時,一般用新數據來覆蓋舊數據。這樣的處理使屬性所反映的中是最新的賦值。

用戶維度表 修改前:f19f9c228f0a6a8bef645bc72f36db37.jpgide

修改後:38f88c8995bc153c599b9a667a97b33c.jpgoop

  • 這種方法有個前提,用戶不關心這個數據的變化
  • 這樣處理,易於實現,可是沒有保留歷史數據,沒法分析歷史變化信息

1.3 增長維度新行

         數據倉庫系統的目標之一是正確地表示歷史。典型表明就是拉鍊表        大數據

          保留歷史的數據,並插入新的數據url

用戶維度表 修改前:ded0e168c1f45f16ec1cf7e5f67f9bf4.jpg修改後:fd3fcca37c7a5e68a1a29dace038c2f7.jpgspa

1.4 增長維度新列

         用不一樣的字段來保存不一樣的值,就是在表中增長一個字段,這個字段用來保存變化後的當前值,而原來的值則被稱爲變化前的值。總的來講,這種方法經過添加字段來保存變化後的痕跡。設計

用戶維度表 修改前:a8c74c32d2b4452a38ec60caa579802f.jpg修改後978750a68600d4286525d371ee46692e.jpg

1.5 使用歷史表

         另外建一個表來保存歷史記錄,這種方式就是將歷史數據與當前數據徹底分開來,在維度中只保存當前最新的數據。用戶維度表c5cf05109ca8b9c9772dccbb9fdd3449.jpg用戶維度歷史表4f34bcf976cfb50c0ab2cccaf9fdc9c0.jpg這種方式的優勢是能夠同時分析當前及前一次變化的屬性值,缺點是隻保留了最後一次變化信息。

思考

         我在這裏給你們提個場景題,好比咱們在淘寶上購買一件商品,從下單-支付-發貨-配送-確認收貨這個幾步流。需求:統計出在發送到配置過程當中轉了幾回?

小結

          今天給你們分享了SCD解決方案,可是其實以上的解決方案不是很好,其實數倉有一個很是好的解決緩慢變化維拉鍊表既保留了歷史數據又不會形成數據冗餘,拉鍊表咱們下期講。信本身,努力和汗水總會能獲得回報的。我是大數據老哥,咱們下期見~~~

獲取Flink面試題,Spark面試題,程序員必備軟件,hive面試題,Hadoop面試題,Docker面試題,簡歷模板等資源請去GitHub自行下載 https://github.com/lhh2002/Framework-Of-BigData

相關文章
相關標籤/搜索