數(shù)據(jù)倉庫多維數(shù)據(jù)模型的設計x_第1頁
數(shù)據(jù)倉庫多維數(shù)據(jù)模型的設計x_第2頁
數(shù)據(jù)倉庫多維數(shù)據(jù)模型的設計x_第3頁
數(shù)據(jù)倉庫多維數(shù)據(jù)模型的設計x_第4頁
數(shù)據(jù)倉庫多維數(shù)據(jù)模型的設計x_第5頁
已閱讀5頁,還剩9頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領

文檔簡介

1、1、數(shù)據(jù)倉庫基本概念1.1、主題(Subject )主題就是指我們所要分析的具體方面。例如:某年某月某地區(qū)某機型某款App的安裝情況。主題有兩個元素:一是各個分析角度(維度),如時間位置;二是要分析的具體量度,該量度一般通過數(shù)值體現(xiàn),如 App安裝量。1.2、維(Dimension )維是用于從不同角度描述事物特征的,一般維都會有多層(Level:級別),每個Level都會包含一些共有的或特有的屬性(Attribute),可以用下圖來展示下維的結(jié)構(gòu)和組成:以時間維為例,時間維一般會包含年、季、月、日這幾個Level,每個Level 一般都會有ID、NAME、DESCRIPTION這幾個公共屬性

2、,這幾個公共屬性不僅適用于時間維,也同 樣表現(xiàn)在其它各種不同類型的維。1.3、分層(Hierarchy )OLAP需要基于有層級的自上而下的鉆取,或者自下而上地聚合。所以我們一般會在維 的基礎上再次進行分層,維、分層、層級的關系如下圖:1.4、量度量度就是我們要分析的具體的技術(shù)指標,諸如年銷售額之類。它們一般為數(shù)值型數(shù)據(jù)。我們或者將該數(shù)據(jù)匯總,或者將該數(shù)據(jù)取次數(shù)、獨立次數(shù)或取最大最小值等,這樣的數(shù)據(jù)稱為量 度。1.5、粒度數(shù)據(jù)的細分層度,例如按天分按小時分。1.6、事實表和維表事實表是用來記錄分析的容的全量信息的,包含了每個事件的具體要素,以及具體發(fā)生的事情。事實表中存儲數(shù)字型ID以及度量信息

3、。維表則是對事實表中事件的要素的描述信息,就是你觀察該事務的角度,是從哪個角度去觀察這個容的。事實表和維表通過ID相關聯(lián),如圖所示:HK.FK1PKrFK2PKJK3PK.FK,PK.FK51.7、星形/雪花形/事實星座這三者就是數(shù)據(jù)倉庫多維數(shù)據(jù)模型建模的模式上圖所示就是一個標準的星形模型。雪花形就是在維度下面又細分出維度,這樣切分是為了使表結(jié)構(gòu)更加規(guī)化。雪花模式可以減少冗余,但是減少的那點空間和事實表的容量相比實在是微不足道,而且多個表聯(lián)結(jié)操作會 降低性能,所以一般不用雪花模式設計數(shù)據(jù)倉庫。事實星座模式就是星形模式的集合,包含星形模式,也就包含多個事實表。1.8、企業(yè)級數(shù)據(jù)倉庫/數(shù)據(jù)集市企業(yè)

4、級數(shù)據(jù)倉庫:突出大而全,不論是細致數(shù)據(jù)和聚合數(shù)據(jù)它全都有,設計時使用事實星座模式數(shù)據(jù)集市:可以看做是企業(yè)級數(shù)據(jù)倉庫的一個子集,它是針對某一方面的數(shù)據(jù)設計的數(shù)據(jù)倉庫,例如為公司的支付業(yè)務設計一個單獨的數(shù)據(jù)集市。由于數(shù)據(jù)集市沒有進行企業(yè)級的設計和規(guī)劃,所以長期來看,它本身的集成將會極其復雜。其數(shù)據(jù)來源有兩種,一種是直接 從原生數(shù)據(jù)源得到,另一種是從企業(yè)數(shù)據(jù)倉庫得到。設計時使用星形模型2、數(shù)據(jù)倉庫設計步驟2.1、確定主題主題與業(yè)務密切相關,所以設計數(shù)倉之前應當充分了解業(yè)務有哪些方面的需求,據(jù)此確定主 題。2.2、確定量度在確定了主題以后,我們將考慮要分析的技術(shù)指標,諸如年銷售額之類。量度是要統(tǒng)計的指

5、 標,必須事先選擇恰當,基于不同的量度將直接產(chǎn)生不同的決策結(jié)果。2.3、確定數(shù)據(jù)粒度考慮到量度的聚合程度不同,我們將采用“最小粒度原則”,即將量度的粒度設置到最小。例如如果知道某些數(shù)據(jù)細分到天就好了,那么設置其粒度到天;但是如果不確定的話,就將粒度 設置為最小,即毫秒級別的。2.4、確定維度設計各個維度的主鍵、層次、層級,盡量減少冗余。2.5、創(chuàng)建事實表事實表中將存在維度代理鍵和各量度,而不應該存在描述性信息,即符合“瘦高原則”, 即要求事實表數(shù)據(jù)條數(shù)盡量多(粒度最?。?,而描述性信息盡量少。3、數(shù)據(jù)倉庫-全量表全量表:保存用戶所有的數(shù)據(jù)(包括新增與歷史數(shù)據(jù))增量表:只保留當前新增的數(shù)據(jù)快照表:

6、按日分區(qū),記錄截止數(shù)據(jù)日期的全量數(shù)據(jù)切片表:切片表根據(jù)基礎表,往往只反映某一個維度的相應數(shù)據(jù)。其表結(jié)構(gòu)與基礎表結(jié)構(gòu) 相同,但數(shù)據(jù)往往只有某一維度,或者某一個事實條件的數(shù)據(jù)3.1、更新插入算法更新插入(主表)算法適用于保留最新狀態(tài)表的處理。案例:銀行賬戶余額表,全表表大約8000萬,非結(jié)息日每日變動100萬,結(jié)息日變動2000 萬。非結(jié)息日:它是指根據(jù)主鍵(或指定字段)進行數(shù)據(jù)對比,如果增量表存在記錄,則更新 原全量表,否則插入數(shù)據(jù)。ETL更新的優(yōu)化? Merge?結(jié)息日:新建空表,它是指根據(jù)主鍵(或指定字段)進行數(shù)據(jù)對比,首先插入原全量表與增量表無法匹配的非變更數(shù)據(jù),再次插入可以匹配的增量表數(shù)

7、據(jù),最后補齊增量表與全量表無法 匹配的增量數(shù)據(jù)。3.2、直接追加算法直接追加算法是指增量數(shù)據(jù)直接追加到目標表中,此算法適合流水、交易、事件、話單等增量且不修改的數(shù)據(jù)。由于歷史信息表數(shù)據(jù)量過于龐大,往往在數(shù)據(jù)庫設計中將引入分區(qū)表的邏輯來處理,具體實現(xiàn)邏輯自查。3.3、全量歷史表算法拉鏈表。拉鏈表:數(shù)據(jù)倉庫設計中表存儲數(shù)據(jù)的方式而定義的,顧名思義,所謂拉鏈,就是記錄歷史。記錄一個事物從開始,一直到當前狀態(tài)的所有變化的信息。我們先看一個示例,這就是一拉鏈表,存儲的是用戶的最基本信息以及每條記錄的生命 周期。我們可以使用這表拿到最新的當天的最新數(shù)據(jù)以及之前的歷史數(shù)據(jù)。20:SJB17-0壯1-C用廣抓

8、號碼1111t jtoil17 01tdatt-Q1:end di59U S3tt2017-01-01w2Q117-0120:Idriq:L 12017-017 01-Cn11u01)2)51 J _ 1 11J J _ii 工l| J j JJ20117-01117-01-QJQJ99Ct M娘IT 1j.L2017-01-frtMAdj r r i44417-01-01in ma L7-Cl-0L20:175I rnCMTn43220117-01L7C11-0,1201-CDI4522DH7-01l|Qh Jr_JLI2o17-0)2Cm0555520117-01-02201.7-C11-

9、020P 04-CHas1151152017-01039q_ 1L20:il-C%20117-01*99*gg 1 1在數(shù)據(jù)倉庫的數(shù)據(jù)模型設計過程中,經(jīng)常會遇到下面這種表的設計:1、有一些表的數(shù)據(jù)量很大,比如一用戶表,大約10億條記錄,50個字段,這種表,即使使用ORC壓縮,單表的存儲也會超過100G (在HDFS使用雙備份或者三備份的話就更大一些)。2、 表中的部分字段會被 update 更新操作,如用戶聯(lián)系方式,產(chǎn)品的描述信息,訂單 的狀態(tài)等等。3、需要查看某一個時間點或者時間段的歷史快照信息,比如,查看某一個訂單在歷史 某一個時間點的狀態(tài)。4、表中的記錄變化的比例和頻率不是很大,比如,總

10、共有10億的用戶,每天新增和發(fā)生變 化的有200萬左右,變化的比例占的很小。那么對于這種表我該如何設計呢?下面有幾種方案可選:方案一:每天只留最新的一份(比如我們每天用Sqoop抽取最新的一份全量數(shù)據(jù)到Hive中)。方案二:每天保留一份全量的切片數(shù)據(jù)。方案三:使用拉鏈表。4.1、為什么使用拉鏈表現(xiàn)在我們對前面提到的三種進行逐個的分析。方案一這種方案就不用多說了,實現(xiàn)起來很簡單,每天drop掉前一天的數(shù)據(jù),重新抽一份最新的。優(yōu)點很明顯,節(jié)省空間,一些普通的使用也很方便,不用在選擇表的時候加一個時間分區(qū)什么的。缺點同樣明顯,沒有歷史數(shù)據(jù),先翻翻舊賬只能通過其它方式,比如從流水表里面抽。方案二每天一

11、份全量的切片是一種比較穩(wěn)妥的方案,而且歷史數(shù)據(jù)也在。缺點就是存儲空間占用量太大了,如果對這邊表每天都保留一份全量,那么每次全量中會保存很多不變的信息,對存儲是極大的浪費。當然我們也可以做一些取舍,比如只保留近一個月的數(shù)據(jù)?但是,需無恥的,數(shù)據(jù)的生命周期不是我們能完全左右的。拉鏈表在使用上基本兼顧了我們的需求。首先它在空間上做了一個取舍,雖說不像方案一那樣占用量那么小,但是它每日的增量可能 只有方案二的千分之一甚至是萬分之一。其實它能滿足方案二所能滿足的需求,既能獲取最新的數(shù)據(jù),也能添加篩選條件也獲取歷 史的數(shù)據(jù)。所以我們還是很有必要來使用拉鏈表的。4.2、拉鏈表的實現(xiàn)下面我們來舉個栗子詳細看一

12、下拉鏈表。我們先看一下在Mysql關系型數(shù)據(jù)庫里的user表息變化。在2017-01-01這一天表中的數(shù)據(jù)是:i-Ol144在2017-01-02這一天表中的數(shù)據(jù)是,用戶002和004資料進行了修改,005是新增用戶:anon犒號手機號嗎-EJPIBlJ017 0101002(22222| Th j j 2017-C11.-Q19999- L2jj_0*0443243*2ZBL701*022017-()| Q01004654M2120】L-01-039995T,Ti02QOS5&S5W201L7- 1-0-22017-()L-0.200SHSUS20L7-

13、01-0399g4-1Li m(J3006666666201LXJLQS9999 11 J L添說明t_start_date 表示該條記錄的生命周期開始時間,t_end_date 表示該條記錄的生命周期結(jié)束時間。t_end_date =9999-12-31 表示該條記錄目前處于有效狀態(tài)。如果查詢當前所有有效的記錄,則 select * from user where t_end_date =9999-12-31如果查詢 2017-01-02 的歷史快照,貝I select from user where t_start_date =2017-01-02 。(*此處要好好理解,是拉鏈表比較重要的

14、一塊。*)4.3、拉鏈表在Hive中的實現(xiàn)在現(xiàn)在的大數(shù)據(jù)場景下,大部分的公司都會選擇以Hdfs和Hive為主的數(shù)據(jù)倉庫架構(gòu)。目前的Hdfs版本來講,其文件系統(tǒng)中的文件是不能做改變的,也就是說Hive的表智能進行刪除和添加操作,而不能進行update。基于這個前提,我們來實現(xiàn)拉鏈表。還是以上面的用戶表為例,我們要實現(xiàn)用戶的拉鏈表。在實現(xiàn)它之前,我們需要先確定一下我們有哪些數(shù)據(jù)源可以用。我們需要一 ODS層的用戶全量表。至少需要用它來初始化。每日的用戶更新表。而且我們要確定拉鏈表的時間粒度,比如說拉鏈表每天只取一個狀態(tài),也就是說如果一天有3個狀態(tài)變更,我們只取最后一個狀態(tài),這種天粒度的表其實已經(jīng)能

15、解決大部分的問題 了。ods 層的 user 表現(xiàn)在我們來看一下我們 ods層的用戶資料切片表的結(jié)構(gòu):CREATEEXTERNALTABLEods.user (user_num STRINGCOMMENT 用戶編號,mobile STRING COMMENT 手機,reg_date STRING COMMENT 注冊日期COMMENT 用戶資料表PARTITIONED BY (dt string)ROW FORMAT DELIMITED FIELDSTERMINATED BY t LINESTERMINATED BY nSTOREDAS ORCLOCATION /ods/user;)ods 層

16、的 user_update 表然后我們還需要一用戶每日更新表,前面已經(jīng)分析過該如果得到這表,現(xiàn)在我們假設它已經(jīng) 存在。CREATEEXTERNALTABLEods.user_update (user_num STRINGCOMMENT 用戶編號,mobile STRING COMMENT 手機,reg_date STRING COMMENT 注冊日期COMMENT 每日用戶資料更新表PARTITIONED BY (dt string)ROW FORMAT DELIMITED FIELDSTERMINATED BY t LINESTERMINATED BY nSTOREDAS ORCLOCATI

17、ON /ods/user_update;)拉鏈表現(xiàn)在我們創(chuàng)建一拉鏈表:CREATEEXTERNALTABLEdws.user_his (user_num STRINGCOMMENT 用戶編號,mobile STRING COMMENT 手機,reg_date STRING COMMENT 用戶編號,t_start_date ,t_end_dateCOMMENT 用戶資料拉鏈表ROW FORMAT DELIMITED FIELDSTERMINATED BY t LINESTERMINATED BY nSTOREDAS ORCLOCATION /dws/user_his;)實現(xiàn)sql語句然后初始化

18、的sql就不寫了,其實就相當于是拿一天的ods層用戶表過來就行,我們寫一下每日的更新語句?,F(xiàn)在我們假設我們已經(jīng)已經(jīng)初始化了2017-01-01的日期,然后需要更新2017-01-02那一天的數(shù)據(jù),我們有了下面的Sql。然后把兩個日期設置為變量就可以了。INSERTOVERWRITE TABLEdws.user_hisSELECT* FROM(SELECTA.user_num,A.mobile,A.reg_date,A.t_start_time,CASEWHEN A.t_end_time = 9999-12-31AND B.user_num IS NOT NULL THEN 2017-01-01ELSEA.t_end_timeEND AS t_end_timeFROM dws.user_his ALEFTJOIN ods.user_update BON A.user_num = B.user_numUNIONSELECTC.user_num,C.mobile,C.reg_date,2017-01-02 AS t_start_time,9999-12-31 AS t_end_timeFROM ods.user_update AS C)AST好了,我們分析了拉鏈表的原理、設計思路、

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論