柚子快報激活碼778899分享：【大數(shù)據(jù)專題】數(shù)據(jù)倉庫

http://yzkb.51969.com/

1. 簡述數(shù)據(jù)倉庫架構(gòu) ？

數(shù)據(jù)倉庫的核心功能從源系統(tǒng)抽取數(shù)據(jù)，通過清洗、轉(zhuǎn)換、標(biāo)準(zhǔn)化，將數(shù)據(jù)加載到BI平臺，進而滿足業(yè) 務(wù)用戶的數(shù)據(jù)分析和決策支持。 數(shù)據(jù)倉庫架構(gòu)包含三個部分：數(shù)據(jù)架構(gòu)、應(yīng)用程序架構(gòu)、底層設(shè)施

1）底層設(shè)施 底層設(shè)施為架構(gòu)提供了基礎(chǔ)，底層設(shè)施包括硬件、數(shù)據(jù)庫平臺、網(wǎng)絡(luò)和桌面系統(tǒng)。 （1）硬件 硬件主要指服務(wù)器硬件，主要有數(shù)據(jù)庫服務(wù)器、ETL服務(wù)器、調(diào)度服務(wù)器、報表服務(wù)器、BI門戶服務(wù) 器、接口服務(wù)器。 （2）數(shù)據(jù)庫平臺 數(shù)據(jù)庫平臺分為二大類：聯(lián)機事務(wù)處理OLTP（on-line transaction processing）、聯(lián)機分析處理OLAP（On-Line Analytical Processing），主要有Oracel，MySQL。OLAP是為數(shù)據(jù)分析而設(shè)計的數(shù)據(jù)庫管理系統(tǒng)。主要有Teradata, Greenplum，Hive，Kudu。 （3）桌面系統(tǒng) 數(shù)據(jù)倉庫不同的應(yīng)用對桌面系統(tǒng)也有不同的要求，開發(fā)工具主要有Window、Mac面系統(tǒng)，部署服務(wù)器主 要有Unix桌面系統(tǒng)，系統(tǒng)BI應(yīng)用程序主要有Window、Mac、移動設(shè)備桌面系統(tǒng)。 （4）網(wǎng)絡(luò) 網(wǎng)絡(luò)是底層設(shè)施的基礎(chǔ)，特別是大數(shù)據(jù)時代對網(wǎng)絡(luò)的要求越來越高。

2）BI應(yīng)用程序架構(gòu) 數(shù)據(jù)倉庫是數(shù)據(jù)處理的后臺，業(yè)務(wù)用戶并不關(guān)心后臺怎么處理。BI應(yīng)用是數(shù)據(jù)呈現(xiàn)的前臺，是業(yè)務(wù)用戶 進行查詢的入口。BI應(yīng)用程序的體驗也是衡量數(shù)據(jù)倉庫是否成功的主要因素。 （1） BI分析周期 業(yè)務(wù)分析從監(jiān)視活動開始識別某個問題或時機，進而采取行動，最終回到監(jiān)視該活動產(chǎn)生的結(jié)果上來， 達到數(shù)據(jù)驅(qū)動業(yè)務(wù)增長的目的。分析周期把這個過程分為五個不同的階段。 （2） BI應(yīng)用分類接口查詢 數(shù)據(jù)以接口的形式提供給上下游系統(tǒng)，供上下業(yè)務(wù)系統(tǒng)進行查詢。主要有推和拉二種模式。 即席查詢 業(yè)務(wù)用戶根據(jù)自己的需求，自定義查詢請求，后臺自動組織SQL語句訪問維度模型。 標(biāo)準(zhǔn)報表 根據(jù)業(yè)務(wù)用戶的需求，進行定制報表。儀表盤 它是向企業(yè)展示度量信息和關(guān)鍵業(yè)務(wù)指標(biāo)現(xiàn)狀的數(shù)據(jù)可視化工具。數(shù)據(jù)挖掘 為數(shù)據(jù)挖掘工具提供標(biāo)準(zhǔn)基礎(chǔ)數(shù)據(jù)。運營查詢 為了減少業(yè)務(wù)系統(tǒng)的大數(shù)據(jù)量查詢壓力，數(shù)據(jù)倉庫為業(yè)務(wù)系統(tǒng)提供實時的查詢。 （3）數(shù)據(jù)存儲 為了提高查詢性能，BI工具需要把數(shù)據(jù)存儲在本地服務(wù)器上 OLAP多維模型需要把數(shù)據(jù)存儲成Cube格式把數(shù)據(jù)存儲成文件格式，放在其他服務(wù)器上 3）數(shù)據(jù)結(jié)構(gòu) 數(shù)據(jù)架構(gòu)主要描述數(shù)據(jù)從源系統(tǒng)抽取數(shù)據(jù)，然后經(jīng)過清洗、規(guī)范化、提交形成標(biāo)準(zhǔn)模型，最終提交給業(yè) 務(wù)用戶，以及對數(shù)據(jù)的管理。 （1）源系統(tǒng) 數(shù)據(jù)倉庫一般會面臨多個、異構(gòu)數(shù)據(jù)源的問題，主要分為結(jié)構(gòu)化，半結(jié)構(gòu)化以及非結(jié)構(gòu)化數(shù)據(jù)。為了便 于管理需要對源系統(tǒng)建立元數(shù)據(jù)信息。 （2）抽取 因為源系統(tǒng)的多樣性，源抽取階段一般選擇使用工具。在抽取之前還要做以下工作：

數(shù)據(jù)剖析是對數(shù)據(jù)的技術(shù)性分析，對數(shù)據(jù)的內(nèi)容、一致性和結(jié)構(gòu)進行描述。對源系統(tǒng)的數(shù)據(jù)質(zhì)量進行評 估。 數(shù)據(jù)剖析 變化數(shù)據(jù)捕獲策略 為了減少對源系統(tǒng)的影響，一般只抽取變化的數(shù)據(jù)，也需要識別物理刪除的數(shù)據(jù)。CDC策略主要有： 添加審計列 在源系統(tǒng)追加日期字段，當(dāng)數(shù)據(jù)發(fā)生變化的時候，系統(tǒng)會自動更新該值。如果由后臺人員手工修改 數(shù)據(jù)，可能就發(fā)生遺漏。 數(shù)據(jù)比較 比較源系統(tǒng)和數(shù)據(jù)倉庫的數(shù)據(jù)，只抽取變化的數(shù)據(jù)。這種方法需要全量的數(shù)據(jù)，比較耗費資源?？?以視數(shù)據(jù)量的大小而定。 讀取日志 讀取數(shù)據(jù)庫操作日志信息，同步到數(shù)據(jù)倉庫中。一般日志的有效期比較短，一旦發(fā)生要重跑的情 況，可能以前的日志已經(jīng)被清空了。 消息隊列 把事務(wù)信息放到消息隊列里，以流的形式同步到數(shù)據(jù)倉庫。這種方式即可以減輕源系統(tǒng)的壓力，又 能做到實時同步。

（3）數(shù)據(jù)轉(zhuǎn)換 數(shù)據(jù)從源系統(tǒng)抽取過來之后，就要進入數(shù)據(jù)轉(zhuǎn)換階段。 這一階段是數(shù)據(jù)倉庫開發(fā)核心階段。主要有以下步驟： 清洗 數(shù)據(jù)清洗是制定轉(zhuǎn)換規(guī)則，篩選數(shù)據(jù)并糾正數(shù)據(jù)的過程。清洗的目的是改進源系統(tǒng)的數(shù)據(jù)質(zhì)量，但是不 要在數(shù)據(jù)倉庫做過多的清洗，源系統(tǒng)的數(shù)據(jù)質(zhì)量應(yīng)該在源頭處理。清洗的主要內(nèi)容包括： 制定數(shù)據(jù)轉(zhuǎn)換規(guī)則提交錯誤事實表 規(guī)范化 規(guī)范化就是整合各個源系統(tǒng)的數(shù)據(jù)，把數(shù)據(jù)統(tǒng)一命名，統(tǒng)一取值，建立企業(yè)標(biāo)準(zhǔn)版本數(shù)據(jù)。主要內(nèi)容包 括： 數(shù)據(jù)標(biāo)準(zhǔn)化刪除重復(fù)數(shù)據(jù)數(shù)據(jù)共存策略 （4）提交 提交就要根據(jù)維度模型生成維度表和事實表。 提交主要內(nèi)容包括： 選擇合適的緩慢變化維類型 為維表生成代理鍵 管理不同粒度的層次維管理專項維 生成維度橋接表生成代理鍵管道 選擇合適的事實表類型處理延遲到達的事實

生成維度表生成事實表 （5）聚集 聚集是指根據(jù)事務(wù)事實表進行更高粒度的聚合以及生成相對應(yīng)的維度表。主要內(nèi)容包括： 數(shù)據(jù)聚合 縮小維度表 生成OLAP多維數(shù)據(jù)集 （6）數(shù)據(jù)存儲 數(shù)據(jù)存儲是指在在數(shù)據(jù)的生命周期內(nèi)對數(shù)據(jù)的管理，主要內(nèi)容包括： 數(shù)據(jù)備份 歷史數(shù)據(jù)歸檔 ETL過程中數(shù)據(jù)分層存儲

2. 簡述數(shù)倉架構(gòu)設(shè)計的方法和原則 ？

1）數(shù)據(jù)設(shè)計方法 數(shù)據(jù)倉庫建立之前，就必須考慮其實現(xiàn)方法，通常有自頂向下、自底向上和兩者結(jié)合進行的這樣三種實 現(xiàn)方案。 （1）自頂向下實現(xiàn) 自頂向下的實現(xiàn)需要在項目開始時完成更多計劃和設(shè)計工作，這就需要涉及參與數(shù)據(jù)倉庫實現(xiàn)的每個工 作組、部門或業(yè)務(wù)線中的人員。要使用的數(shù)據(jù)源、安全性、數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)質(zhì)量、數(shù)據(jù)標(biāo)準(zhǔn)和整個數(shù)據(jù) 模型的有關(guān)決策一般需要在真正的實現(xiàn)開始之前就完成。 （2）自底向上實現(xiàn) 自底向上的實現(xiàn)包含數(shù)據(jù)倉庫的規(guī)劃和設(shè)計，無需等待安置好更大業(yè)務(wù)范圍的數(shù)據(jù)倉庫設(shè)計。這并不意 味著不會開發(fā)更大業(yè)務(wù)范圍的數(shù)據(jù)倉庫設(shè)計；隨著初始數(shù)據(jù)倉庫實現(xiàn)的擴展，將逐漸增加對它的構(gòu)建。 現(xiàn)在，該方法得到了比自頂向下方法更廣泛的接受，因為數(shù)據(jù)倉庫的直接結(jié)果可以實現(xiàn)，并可以用作擴 展更大業(yè)務(wù)范圍實現(xiàn)的證明。 （3）兩者結(jié)合的折中實現(xiàn) 每種實現(xiàn)方法都有利弊。在許多情況下，最好的方法可能是某兩種的組合。該方法的關(guān)鍵之一就是確定 業(yè)務(wù)范圍的架構(gòu)需要用于支持集成的計劃和設(shè)計的程度，因為數(shù)據(jù)倉庫是用自底向上的方法進行構(gòu)建。 在使用自底向上或階段性數(shù)據(jù)倉庫項目模型來構(gòu)建業(yè)務(wù)范圍架構(gòu)中的一系列數(shù)據(jù)集市時，您可以一個接 一個地集成不同業(yè)務(wù)主題領(lǐng)域中的數(shù)據(jù)集市，從而形成設(shè)計良好的業(yè)務(wù)數(shù)據(jù)倉庫。這樣的方法可以極好 地適用于業(yè)務(wù)。在這種方法中，可以把數(shù)據(jù)集市理解為整個數(shù)據(jù)倉庫系統(tǒng)的邏輯子集，換句話說數(shù)據(jù)倉 庫就是一致化了的數(shù)據(jù)集市的集合。 2）數(shù)倉架構(gòu)爭論 關(guān)于Inmon 和 Kimball的大辯論：Ralph Kimball 和 Bill Inmon 一直是商業(yè)智能領(lǐng)域中的革新者，開發(fā)并測試了新的技術(shù)和體系結(jié)構(gòu)。在BI/DW領(lǐng)域中，圍繞“哪一種數(shù)據(jù)倉庫架構(gòu)（Data Warehouse Architecture）最佳？”的爭論一直沒有休止，這個問題同時也是企業(yè)在建立DW時需要決策的關(guān)鍵問題： Bill Inmon的集線器架構(gòu)/企業(yè)信息工廠架構(gòu)（Hub and Spoke / CIF – Corporate Information Factory）與Ralph Kimball的數(shù)據(jù)集市/數(shù)據(jù)倉庫總線架構(gòu)（Data Mart Bus Architecture/Data Warehouse Bus Architecture）則是DW架構(gòu)的爭論焦點。

Bill Inmon 將數(shù)據(jù)倉庫定義為“一個面向主題的、集成的、非易變的、隨時間變化的用于支持管理的決策過程的數(shù)據(jù)集合”；他通過“面向主題”表示應(yīng)該圍繞主題來組織數(shù)據(jù)倉庫中的數(shù)據(jù)，例如客戶、銷售、產(chǎn) 品等等。每個主題區(qū)域僅僅包含該主題相關(guān)的信息。數(shù)據(jù)倉庫應(yīng)該一次增加一個主題，并且當(dāng)需要容易 地訪問多個主題時，應(yīng)該創(chuàng)建以數(shù)據(jù)倉庫為來源的數(shù)據(jù)集市。換言之，某個特定數(shù)據(jù)集市中的所有數(shù)據(jù) 都應(yīng)該來自于面向主題的數(shù)據(jù)存儲。 Inmon 的方法包含了更多上述工作而減少了對于信息的初始訪問。但他認(rèn)為這個集中式的體系結(jié)構(gòu)持續(xù)下去將提供更強的一致性和靈活性，并且從長遠來看將真正節(jié)省資 源和工作

3）數(shù)倉架構(gòu)選型 數(shù)據(jù)倉庫架構(gòu)的選取，與其所處的企業(yè)環(huán)境和業(yè)務(wù)的發(fā)展有著密切的關(guān)系：Inmon提倡的數(shù)據(jù)倉庫建設(shè) 方法，需要數(shù)據(jù)倉庫建設(shè)人員自頂向下進行建設(shè)，數(shù)據(jù)倉庫開發(fā)人員需要在數(shù)據(jù)倉庫建設(shè)之前對企業(yè)各 業(yè)務(wù)線進行深入的調(diào)研，有著非常全面的了解，然后根據(jù)企業(yè)各業(yè)務(wù)特點進行主題域劃分。這種建設(shè)方 式建設(shè)周期比較長，規(guī)劃設(shè)計比較復(fù)雜，但是一旦建成，這個集中式的體系結(jié)構(gòu)將提供更強的一致性和 靈活性，并且從長遠來看將真正節(jié)省資源和工作；Kimball提倡的數(shù)據(jù)倉庫僅僅是構(gòu)成它的數(shù)據(jù)集市的聯(lián) 合，各部門或業(yè)務(wù)可以根據(jù)自身的發(fā)展，建設(shè)符合自身主題的數(shù)據(jù)集市，并持續(xù)豐富完善這些數(shù)據(jù)集 市。在應(yīng)對企業(yè)級數(shù)據(jù)需求時，將這些數(shù)據(jù)集市的維度信息進行統(tǒng)一整理規(guī)范，然后通過一致的維度信 息，將這些數(shù)據(jù)集市連接起來，使數(shù)據(jù)集市形成一個覆蓋企業(yè)所有部門或業(yè)務(wù)的數(shù)據(jù)倉庫，對外提供服務(wù)。 根據(jù)企業(yè)發(fā)展階段和業(yè)務(wù)發(fā)展的速度建議：傳統(tǒng)的、業(yè)務(wù)成熟的企業(yè)可以考慮采用Inmon方法建設(shè)數(shù)據(jù) 倉庫；業(yè)務(wù)復(fù)雜而且差異較大、發(fā)展速度又非?？斓钠髽I(yè)可以考慮Kimball方法建設(shè)數(shù)據(jù)倉庫。

4）企業(yè)發(fā)展中的數(shù)據(jù)倉庫建設(shè)變遷 企業(yè)或新部門，在初期發(fā)展過程中業(yè)務(wù)量少、組織形式相對簡單。使得數(shù)倉建設(shè)人員可以站在全局的高 度，俯視整個公司的業(yè)務(wù)流程，對其進行梳理歸類，并抽取數(shù)據(jù)模型。以自上而下的方式建設(shè)數(shù)據(jù)倉 庫。所以在初期數(shù)據(jù)倉庫建設(shè)的過程中基本采用了Inmon提倡的數(shù)據(jù)倉庫建設(shè)方法，采用了DataSource–

ODS→EDW→DM–>APP的結(jié)構(gòu)。即由ODS層完成各部門數(shù)據(jù)源的集成，在ODS的基礎(chǔ)上建設(shè)了覆蓋公司 所有業(yè)務(wù)的包含眾多主題的統(tǒng)一的數(shù)據(jù)倉庫，然后由這個統(tǒng)一的數(shù)據(jù)倉庫作為唯一的數(shù)據(jù)源，為各部門 的數(shù)據(jù)集市提供數(shù)據(jù)支持

但是一旦企業(yè)或部門發(fā)展速度非?？?，業(yè)務(wù)量急劇增大，而且業(yè)務(wù)的組織形式趨于復(fù)雜，不同的業(yè)務(wù)之 間可能存在巨大的差距。數(shù)據(jù)倉庫的建設(shè)如果再繼續(xù)沿用自傷而下的方式就會帶來很多困難，例如在 Inmon模式下EDW規(guī)劃復(fù)雜、建設(shè)周期長，不能非?？焖俚捻憫?yīng)各部門的需求，所以該方案逐步不能適 應(yīng)公司的發(fā)展。為了適應(yīng)企業(yè)的發(fā)展，經(jīng)過數(shù)倉開發(fā)人員的不斷探索嘗試，基本上傾向于采用混合模式 建設(shè)數(shù)據(jù)倉庫，即采用Inmon+Kimball的變種模式

3. 簡述數(shù)據(jù)倉庫分層（層級劃分），每層做什么？分層的好處 ？

首先，我要知道數(shù)據(jù)倉庫分層架構(gòu)的目標(biāo)是什么？是為了實現(xiàn)維度建模，進而支撐決策分析目標(biāo)。 數(shù)據(jù)分層從關(guān)系型在線交易系統(tǒng)到面向主題的數(shù)據(jù)倉庫系統(tǒng)，從范式建模到維度建模的必經(jīng)之路。 數(shù)據(jù)分層是一套讓我們的數(shù)據(jù)體系更有序的行之有效的數(shù)據(jù)組織和管理方法。數(shù)據(jù)分層不是銀彈，也沒 有絕對標(biāo)準(zhǔn)，當(dāng)然也不能包治百病，不能解決所有的數(shù)據(jù)問題，但是，數(shù)據(jù)分層卻可以給我們帶來如下 的好處：

隔離原始數(shù)據(jù)：不論是數(shù)據(jù)的異常還是數(shù)據(jù)敏感度，使真實數(shù)據(jù)與統(tǒng)計數(shù)據(jù)解耦開。 數(shù)據(jù)結(jié)構(gòu)化更清晰：每一個數(shù)據(jù)分層都有它的作用域和職責(zé)，在使用表的時候能更方便地定位和理解。 數(shù)據(jù)血緣追蹤：提供給外界使用的是一張業(yè)務(wù)表，但是這張業(yè)務(wù)表可能來源很多張表。如果有一張來源 表出問題了，我們可以快速準(zhǔn)確的定位到問題，并清楚每張表的作用范圍。 增強數(shù)據(jù)復(fù)用能力：減少重復(fù)開發(fā)，通過數(shù)據(jù)分層規(guī)范化，開發(fā)一些通用的中間層數(shù)據(jù)，能夠減少重復(fù) 計算，提高單張業(yè)務(wù)表的使用率，提升系統(tǒng)的執(zhí)行效率。 簡化復(fù)雜的問題：把一個復(fù)雜的業(yè)務(wù)分成多個步驟實現(xiàn)，每一層只處理單一的步驟，比較簡單和容易理 解。而且便于維護數(shù)據(jù)的準(zhǔn)確性，當(dāng)數(shù)據(jù)出現(xiàn)問題之后，可以不用修復(fù)所有的數(shù)據(jù)，只需要從有問題的 步驟開始修復(fù)。 減少業(yè)務(wù)的影響：業(yè)務(wù)可能會經(jīng)常變化，這樣做就不必改一次業(yè)務(wù)就需要重新接入數(shù)據(jù)。 減少重復(fù)開發(fā)：規(guī)范數(shù)據(jù)分層，開發(fā)一些通用的中間層數(shù)據(jù)，能夠減少極大的重復(fù)計算。 統(tǒng)一數(shù)據(jù)口徑：通過數(shù)據(jù)分層，提供統(tǒng)一的數(shù)據(jù)出口，統(tǒng)一對外輸出的數(shù)據(jù)口徑。 分層的核心思想就是解耦，再解耦，把復(fù)雜的問題簡單化。

一個公司可能有多個業(yè)務(wù)系統(tǒng)，而數(shù)據(jù)倉庫就是將所有的業(yè)務(wù)系統(tǒng)按照某種組織架構(gòu)整合 起來，形成一個倉儲平臺，也就是數(shù)倉。

1、四層分層 第一層： ODS——原始數(shù)據(jù)層：存放原始數(shù)據(jù) ODS層即操作數(shù)據(jù)存儲，是最接近數(shù)據(jù)源中數(shù)據(jù)的一層，數(shù)據(jù)源中的數(shù)據(jù)，經(jīng)過抽取、洗凈、傳輸，也 就說傳說中的ETL之后，裝入本層；一般來說ODS層的數(shù)據(jù)和源系統(tǒng)的數(shù)據(jù)是同構(gòu)的，主要目的是簡化 后續(xù)數(shù)據(jù)加工處理的工作。從數(shù)據(jù)粒度上來說ODS層的數(shù)據(jù)粒度是最細的。ODS層的表通常包括兩類， 一個用于存儲當(dāng)前需要加載的數(shù)據(jù)，一個用于存儲處理完后的歷史數(shù)據(jù)。歷史數(shù)據(jù)一般保存3-6個月后需 要清除，以節(jié)省空間。但不同的項目要區(qū)別對待，如果源系統(tǒng)的數(shù)據(jù)量不大，可以保留更長的時間，甚 至全量保存；數(shù)據(jù)在裝入本層前需要做以下工作：去噪、去重、提臟、業(yè)務(wù)提取、單位統(tǒng)一、砍字段、 業(yè)務(wù)判別。 第二層： DWD——數(shù)據(jù)明細層：對ODS層數(shù)據(jù)進行清洗、維度退化、脫敏等。覆蓋所有系統(tǒng)的、完整的、干凈的、具有一致性的數(shù)據(jù)層。 該層一般保持和ODS層一樣的數(shù)據(jù)粒度，并且提供一定的數(shù)據(jù)質(zhì)量保證，在ODS的基礎(chǔ)上對數(shù)據(jù)進行加 工處理，提供更干凈的數(shù)據(jù)。同時，為了提高數(shù)據(jù)明細層的易用性，該層會采用一些維度退化手法，當(dāng) 一個維度沒有數(shù)據(jù)倉庫需要的任何數(shù)據(jù)時，就可以退化維度，將維度退化至事實表中，減少事實表和維 表的關(guān)聯(lián)。例如：訂單id,這種量級很大的維度，沒必要用一張維度表來進行存儲，而我們一般在進行數(shù) 據(jù)分析時訂單id又非常重要，所以我們將訂單id冗余在事實表中，這種維度就是退化維度。 第三層： DWS——數(shù)據(jù)服務(wù)層： 對DWD層數(shù)據(jù)進行一個輕度的匯總。 DWS層為公共匯總層，會進行輕度匯總，粒度比明細數(shù)據(jù)稍粗，會針對度量值進行匯總，目的是避免重 復(fù)計算。該層數(shù)據(jù)表會相對比較少，大多都是寬表(一張表會涵蓋比較多的業(yè)務(wù)內(nèi)容，表中的字段較 多)。按照主題劃分，如訂單、用戶等，生成字段比較多的寬表，用于提供后續(xù)的業(yè)務(wù)查詢，OLAP分 析，數(shù)據(jù)分發(fā)等。 第四層： DM——數(shù)據(jù)集市層：為各種統(tǒng)計報表提供數(shù)據(jù)。 存放的是輕度聚合的數(shù)據(jù)，也可以稱為數(shù)據(jù)應(yīng)用層，基于DWD、DWS上的基礎(chǔ)數(shù)據(jù)，整合匯總成分析某 一個主題域的報表數(shù)據(jù)。主要是提供給數(shù)據(jù)產(chǎn)品和數(shù)據(jù)分析使用的數(shù)據(jù)，通常根據(jù)業(yè)務(wù)需求，劃分成流 量、訂單、用戶等，生成字段比較多的寬表，用于提供后續(xù)的業(yè)務(wù)查詢，OLAP分析，數(shù)據(jù)分發(fā)等。從數(shù) 據(jù)粒度來說，這層的數(shù)據(jù)是匯總級的數(shù)據(jù)，也包括部分明細數(shù)據(jù)。從數(shù)據(jù)的時間跨度來說，通常是DW 層的一部分，主要的目的是為了滿足用戶分析的需求，而從分析的角度來說，用戶通常只需要分析近幾 年的即可。從數(shù)據(jù)的廣度來說，仍然覆蓋了所有業(yè)務(wù)數(shù)據(jù)。

2、三層分層 上述四層數(shù)倉，如果是問的三層數(shù)倉，就相當(dāng)于是把DWD、DWS合并成DW層，往細的方面分，DW還包括DWM層（數(shù)據(jù)中間層），三層分層如下： 第一層： ODS——原始數(shù)據(jù)層：存放原始數(shù)據(jù)第二層： DW——數(shù)據(jù)倉庫層：數(shù)據(jù)清洗，初步匯總 本層將從 ODS 層中獲得的數(shù)據(jù)按照主題建立各種數(shù)據(jù)模型，每一個主題對應(yīng)一個宏觀的分析領(lǐng)域，數(shù)據(jù)倉庫層排除對決策無用的數(shù)據(jù)，提供特定主題的簡明視圖。在DW層會保存BI系統(tǒng)中所有的歷史數(shù)據(jù)， 例如保存10年的數(shù)據(jù)。 第三層： DM——數(shù)據(jù)集市層

3、五層分層 五層分層如下： 第一層： ODS——原始數(shù)據(jù)層：存放原始數(shù)據(jù)第二層： DWD——數(shù)據(jù)明細層：對ODS層數(shù)據(jù)進行清洗、維度退化、脫敏等。第三層： DWS——數(shù)據(jù)匯總層： 對DWD層數(shù)據(jù)進行一個輕度的匯總。第四層： ADS——數(shù)據(jù)應(yīng)用層：為各種統(tǒng)計報表提供數(shù)據(jù) 該層是基于DW層的數(shù)據(jù)，整合匯總成主題域的服務(wù)數(shù)據(jù)，用于提供后續(xù)的業(yè)務(wù)查詢等。第五層： DIM——維表層：基于維度建模理念思想，建立整個企業(yè)的一致性維度。維表層主要包含兩部分?jǐn)?shù)據(jù)： 高基數(shù)維度數(shù)據(jù)：一般是用戶資料表、商品資料表類似的資料表。數(shù)據(jù)量可能是千萬級或者上億級別。 低基數(shù)維度數(shù)據(jù)：一般是配置表，比如枚舉值對應(yīng)的中文含義，或者日期維表。數(shù)據(jù)量可能是個位數(shù)或 者幾千幾萬。

4. 簡述數(shù)據(jù)分層是根據(jù)什么 ？

數(shù)據(jù)分層沒有標(biāo)準(zhǔn)，數(shù)據(jù)分層要結(jié)合當(dāng)下的技術(shù)，當(dāng)前的數(shù)據(jù)量，業(yè)務(wù)的復(fù)雜度通盤考量。操作型數(shù)據(jù) 存儲（ODS）、數(shù)據(jù)倉庫（DW）、數(shù)據(jù)集市（DM）其實就是數(shù)據(jù)分層的原始的指導(dǎo)建議，其中操作型 數(shù)據(jù)存儲是滿足多個業(yè)務(wù)系統(tǒng)獲取數(shù)據(jù)并制作操作型報表的需求，保留半年以內(nèi)的明細準(zhǔn)實時數(shù)據(jù)；數(shù) 據(jù)倉庫是為了管理決策、戰(zhàn)略分析和計劃提供單一整合點，保留長期的明細和匯總數(shù)據(jù)；數(shù)據(jù)集市是用 于特定部門或公共分析需求并定制的，采用維度建模方式保留中期的明細和匯總數(shù)據(jù)

5. 簡述數(shù)倉分層的原則與思路 ？

數(shù)據(jù)倉庫分層沒有絕對的規(guī)范，適合的就是最好的，至于分幾層，建議按照目前的業(yè)務(wù)和建設(shè)現(xiàn)狀，進 行合理解構(gòu)和分層設(shè)計，一般剛開始做，建議3、4層。規(guī)劃1-1.5年的架構(gòu)，然后不斷的建設(shè)、優(yōu)化、再 優(yōu)化。不斷逼近滿足所有需求。 下面針對一些場景說下分層的想法： 場景一：時間緊任務(wù)重，急于看結(jié)果

這種場景，直接連各個業(yè)務(wù)數(shù)據(jù)庫，抽取數(shù)據(jù)到大數(shù)據(jù)平臺，根據(jù)需求組合join或者匯總count、sum就 行，就不要分層了，有的公司項目就是將各個業(yè)務(wù)系統(tǒng)數(shù)據(jù)抽取到oracle，你看都沒有大數(shù)據(jù)平臺就做 了。 場景二：公司業(yè)務(wù)簡單，且相對比較固定，數(shù)據(jù)來源不多，結(jié)構(gòu)也很清晰，需求也不多 直接使用通用的數(shù)倉架構(gòu)就行，ODS起到解耦業(yè)務(wù)數(shù)據(jù)庫+異構(gòu)數(shù)據(jù)源的問題，DWD解決數(shù)據(jù)臟亂差的 問題，DWS服用的指標(biāo)計算，ADS直接面向前臺業(yè)務(wù)需求。 場景三：公司業(yè)務(wù)復(fù)雜，業(yè)務(wù)變化較快 可以考慮多一層DWT層做匯總，多一層解耦，業(yè)務(wù)變化的時候，我們只改DWS層就好了，最多穿透到 DWT層。業(yè)務(wù)變化的時候調(diào)整一下，工作量也不會太大，最重要的是能保證底層結(jié)構(gòu)的穩(wěn)定和數(shù)據(jù)分析 的可持續(xù)性。 場景四：公司業(yè)務(wù)較為復(fù)雜，集團性公司，下轄多個部門業(yè)務(wù)部門事業(yè)線，業(yè)務(wù)部門間業(yè)務(wù)內(nèi)容交叉不 大 可以在數(shù)倉通用分層架構(gòu)上，增加一層DM層，也就是數(shù)據(jù)集市層，各個數(shù)據(jù)集市層，單獨供數(shù)，甚至 有單獨的計算資源，這樣可以避免因為計算任務(wù)代碼混在一起、數(shù)據(jù)權(quán)限拆分等問題帶來的數(shù)據(jù)變更成 本。 一個好的數(shù)倉模型分層，應(yīng)該具備的要素 一個好的數(shù)倉模型分層，應(yīng)該具備的要素是數(shù)據(jù)模型可復(fù)用，完善且規(guī)范的。 完善度： DWD： 跨 層 引 用 率 DWS/ADS/DM：匯總數(shù)據(jù)查詢比例 復(fù)用度： DWD/DWS：模型引用系數(shù) 規(guī)范度： 有多少表沒有主題域、業(yè)務(wù)過程歸屬模型命名不規(guī)范 字段命名不規(guī)范 好的數(shù)倉設(shè)計標(biāo)準(zhǔn)：數(shù)據(jù)比較豐富完善、數(shù)據(jù)復(fù)用性強、規(guī)范性強。 從完善度上來講，主要衡量DWD層和匯總層兩塊的完善度，DWD層完善度，主要是希望DWD等盡可能被匯總層引用，ODS層被除了DWD層外的盡可能少的引用，最好是沒有。 從復(fù)用度上來講，我們希望80%需求由20%的表來支持。直接點講，就是大部分（80%以上）的需求， 都用DWS的表來支持。 從規(guī)范度上來講，主要從表名、字段名來看，一個規(guī)范的表名應(yīng)該包括層級、主題域、分區(qū)規(guī)則，抽取 類型等信息。字段規(guī)范應(yīng)該是和詞根一致，同字段同名等。 數(shù)據(jù)倉庫分層沒有絕對的規(guī)范，適合的就是最好的，數(shù)據(jù)倉庫分層的核心邏輯是解耦，在有限時間、資 源等條件下滿足業(yè)務(wù)需求，同時又要兼顧業(yè)務(wù)的快速變化。所以我們作為數(shù)據(jù)架構(gòu)師，需要兼顧業(yè)務(wù)的 復(fù)雜變化，以及開發(fā)的復(fù)雜度和可維護性，在兩者之間做一個平衡和取舍，選擇合適的分層架構(gòu)。 另外分層架構(gòu)是需要不斷的優(yōu)化調(diào)整的，不能超前太多，也不能脫離業(yè)務(wù)。按照Inmon和Kimball吵了十 幾年的經(jīng)驗上看，建議架構(gòu)設(shè)計時，按超越當(dāng)前實際情況1~1.5年的設(shè)計是比較合適的。

6. 數(shù)倉建模常用模型嗎？區(qū)別、優(yōu)缺點？

數(shù)據(jù)倉庫建模的目標(biāo)是通過建模的方法更好的組織、存儲數(shù)據(jù)，以便在性能、成本、效率和數(shù)據(jù)質(zhì)量之 間找到最佳平衡點。 現(xiàn)在數(shù)據(jù)處理大致可以分為兩大類： 操作型處理，叫聯(lián)機事務(wù)處理 OLTP（On-Line Transaction Processing），也可以稱面向交易的處理系統(tǒng)，它是針對具體業(yè)務(wù)在數(shù)據(jù)庫聯(lián)機的日常操作，通常對少數(shù)記錄進行查詢、修改。用戶較為關(guān)心操作 的響應(yīng)時間、數(shù)據(jù)的安全性、完整性和并發(fā)支持的用戶數(shù)等問題。傳統(tǒng)的數(shù)據(jù)庫系統(tǒng)作為數(shù)據(jù)管理的主 要手段，主要用于操作型處理。 分析型處理，叫聯(lián)機分析處理 OLAP（On-Line Analytical Processing），一般針對某些主題的歷史數(shù)據(jù)進行分析，支持管理決策。 OLTP與OLAP的主要異同如下表：

操作型處理 分析型處理 細節(jié)的 綜合的或提煉的 實體-關(guān)系（ER）模型 星型或雪花模型 存取瞬間數(shù)據(jù) 存儲歷史數(shù)據(jù)，不包含最近的數(shù)據(jù) 可更新的 只讀，只追加 一次操作一個單元 一次操作一個集合 性能要求高，響應(yīng)時間短 性能要求寬松 面向事務(wù) 面向分析 一次操作數(shù)據(jù)量小 一次操作數(shù)據(jù)量大 支持日常操作 支持決策需求 數(shù)據(jù)量小 數(shù)據(jù)量大 客戶訂單、庫存水平和銀行賬戶等 客戶收益分析、市場細分等

1、關(guān)系（ER實體）建模 嚴(yán)格遵循第三范式，從圖中可以看出，較為松散、零碎，物理表數(shù)量多，而數(shù)據(jù)冗 余程度低。由于數(shù)據(jù)分布于眾多的表中，這些數(shù)據(jù)可以更為靈活地被應(yīng)用，功能性較強。關(guān)系模型主要 應(yīng)用與OLTP系統(tǒng)中，為了保證數(shù)據(jù)的一致性以及避免冗余，所以大部分業(yè)務(wù)系統(tǒng)的表都是遵循第三范式 的。 這是數(shù)據(jù)倉庫之父Bill Inmon提出的建模方法，即實體關(guān)系（Entity Relationship，ER）模型。這是從全企業(yè)的高度設(shè)計一個3NF模型，用實體關(guān)系模型來描述企業(yè)業(yè)務(wù)，在范式理論上符合3NF。 關(guān)系模型主要應(yīng)用于OLTP系統(tǒng)中，為了保證數(shù)據(jù)的一致性以及避免冗余，所以大部分業(yè)務(wù)系統(tǒng)的表都是 遵循第三范式的。 特點：設(shè)計思路自上而下，適合上游基礎(chǔ)數(shù)據(jù)存儲，同一份數(shù)據(jù)只存儲一份，沒有數(shù)據(jù)冗余，方便解 耦，易維護，缺點是開發(fā)周期一般比較長，維護成本高。 范式理論： 范式可以理解為設(shè)計一張數(shù)據(jù)表的表結(jié)構(gòu)，符合的標(biāo)準(zhǔn)級別，也就是規(guī)范和要求。 優(yōu)點：關(guān)系型數(shù)據(jù)庫設(shè)計時，遵照一定的規(guī)范要求，目的在于降低數(shù)據(jù)的冗余性。缺點：范式的缺點是獲取數(shù)據(jù)時，需要通過Join拼接出最后的數(shù)據(jù)。 分類：目前業(yè)界范式有第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四 范式(4NF)、第五范式(5NF)。 2、維度建模

維度模型主要應(yīng)用于OLAP系統(tǒng)中，通常以某一個事實表為中心進行表的組織，主要面向業(yè) 務(wù)，特征是可能存在數(shù)據(jù)的冗余，但是能方便的得到數(shù)據(jù)。 關(guān)系模型雖然冗余少，但是在大規(guī)模數(shù)據(jù)，跨表分析統(tǒng)計查詢過程中，會造成多表關(guān)聯(lián)，這會大大降低 執(zhí)行效率。所以一般都會采用維度模型建模，把相關(guān)各種表整理成兩種：事實表和維度表兩種。 在維度建模的基礎(chǔ)上又可分為三種模型：星型模型、雪花模型、星座模型。 維度建模是從分析決策的需求出發(fā)構(gòu)建模型，為分析需求服務(wù)，因此它重點關(guān)注用戶如何更快速的完成 需求分析，同事具有較好的大規(guī)模復(fù)雜查詢的相應(yīng)能力。其典型的代表是星型模型，以及在一些特殊場 景下使用的雪花模型。 維度建模設(shè)計分為以下步驟： 選擇需要進行分析決策的業(yè)務(wù)過程定義粒度 識別維度確認(rèn)事實

1）星型模型 星型模式是維度模型中最簡單的形式，也是數(shù)據(jù)倉庫以及數(shù)據(jù)集市開發(fā)中使用最廣泛的形式。星型模式 由事實表和維度表組成，一個星型模式中可以有一個或多個事實表，每個事實表引用任意數(shù)量的維度 表。 星型模型與雪花模型的區(qū)別主要在于維度的層級，標(biāo)準(zhǔn)的星型模型維度只有一層，而雪花模型可能會涉 及多層。

2）雪花模型 雪花模式是一種多維模型中表的邏輯布局，與星型模式相同，雪花模式也是由事實表和維度表所組成。 所謂的“雪花化”就是將星型模型中的維度表進行規(guī)范化處理。當(dāng)所有的維度表完成規(guī)范化后，就形成了 以事實表為中心的雪花型結(jié)構(gòu)，即雪花模式。

3）星座模型 數(shù)據(jù)倉庫由多個主題構(gòu)成，包含多個事實表，而維表是公共的，可以共享（例如兩張事實表共用一些維 度表時，就叫做星型模型），這種模式可以看做星型模式的匯集，因而稱作星系模式或者事實星座模 式。 4）模型選擇 在數(shù)據(jù)倉庫建模時，會涉及到模式的選擇，我們要根據(jù)不同模式的特點選擇適合具體業(yè)務(wù)的模式。 星型還是雪花，取決于性能優(yōu)先，還是靈活更優(yōu)先。 在實際開發(fā)中，不會絕對選擇一種，根據(jù)情況靈活組合，甚至并存（一層維度和多層維度都保存）。但 是整體看來，更傾向于維度更少的星型模型。 3、建模方法總結(jié) ER模型以及維度模型是當(dāng)前主流的建模方法。 ER模型常用于OLTP數(shù)據(jù)庫建模，應(yīng)用到構(gòu)建數(shù)倉時更偏重數(shù)據(jù)整合，站在企業(yè)整體考慮，將各個系統(tǒng) 的數(shù)據(jù)按相似性、一致性合并處理，為數(shù)據(jù)分析、決策服務(wù)，但并不便于直接用來支持分析。 ER模型的特點如下： 需要全面梳理企業(yè)所有的業(yè)務(wù)和數(shù)據(jù)流； 實施周期長； 對建模人員要求高。 維度建模是面向分析場景而生，針對分析場景構(gòu)建數(shù)倉模型；重點關(guān)注快速、靈活的解決分析需求，同 時能夠提供大規(guī)模數(shù)據(jù)的快速響應(yīng)性能。針對性強，主要應(yīng)用于數(shù)據(jù)倉庫構(gòu)建和OLAP引擎低層數(shù)據(jù)模 型。 不需要完整的梳理企業(yè)業(yè)務(wù)流程和數(shù)據(jù)； 實施周期根據(jù)主題邊界而定，容易快速實現(xiàn) demo。

7. 簡述星型模型和雪花模型的區(qū)別？應(yīng)用場景 ？

隨著大數(shù)據(jù)時代的到來，數(shù)據(jù)倉庫的技術(shù)和模型也越來越受到關(guān)注。在數(shù)據(jù)倉庫中，星型模型和雪花模型是兩種常用的數(shù)據(jù)建模方式。這兩種模型在結(jié)構(gòu)上存在一定的差異，同時也具有各自的優(yōu)缺點。下面我們來詳細了解一下這兩種模型的區(qū)別以及優(yōu)缺點。

一、星型模型

星型模型是一種基于事實表的模型，它的特點是將事實表與其他維度表相連，形成一個放射形結(jié)構(gòu)。在星型模型中，所有的維度表都與事實表相連，因此它的查詢效率比較高，易于理解和維護。

星型模型的優(yōu)點主要有以下幾個方面： 查詢效率高。由于星型模型的結(jié)構(gòu)比較簡單，因此在查詢時可以快速定位到需要的數(shù)據(jù)。 易于理解和維護。星型模型的結(jié)構(gòu)比較清晰，易于理解和維護，能夠大大降低維護成本。 可擴展性好。星型模型的結(jié)構(gòu)比較松散，因此在擴展時比較靈活。 維度分析能力強。星型模型適合進行維度分析，能夠快速地進行數(shù)據(jù)分析和數(shù)據(jù)挖掘。

二、雪花模型

雪花模型是一種基于事實表的模型，它的特點是將維度表之間的關(guān)系變得更加復(fù)雜。在雪花模型中，維度表之間存在多對多的關(guān)系，因此它的結(jié)構(gòu)比較復(fù)雜，查詢效率比較低。

雪花模型的優(yōu)點主要有以下幾個方面： 容納更多維度。由于雪花模型的結(jié)構(gòu)比較復(fù)雜，因此可以容納更多的維度，使得數(shù)據(jù)分析更加全面。 避免冗余數(shù)據(jù)。雪花模型中的維度表之間存在多對多的關(guān)系，因此可以避免數(shù)據(jù)的冗余。 減少計算量。由于雪花模型的結(jié)構(gòu)比較復(fù)雜，因此在查詢時需要進行更多的計算，但是這樣可以減少數(shù)據(jù)的冗余，從而減少計算量。

三、數(shù)據(jù)倉庫的星型模型和雪花模型的區(qū)別以及優(yōu)缺點對比

下面我們來對比一下數(shù)據(jù)倉庫的星型模型和雪花模型的區(qū)別以及優(yōu)缺點：

結(jié)構(gòu)方面：星型模型的結(jié)構(gòu)比較簡單，呈放射形；雪花模型的結(jié)構(gòu)比較復(fù)雜，呈雪花狀。 查詢效率方面：星型模型的查詢效率比較高，而雪花模型的查詢效率比較低。 數(shù)據(jù)冗余方面：星型模型的數(shù)據(jù)冗余比較少，而雪花模型的數(shù)據(jù)冗余比較多。 可擴展性方面：星型模型的可擴展性比較好，而雪花模型的可擴展性比較差。 綜上所述，數(shù)據(jù)倉庫的星型模型和雪花模型各有優(yōu)缺點。在實際應(yīng)用中，應(yīng)根據(jù)具體的應(yīng)用場景和需求來選擇合適的建模方式，以達到最優(yōu)的效果。

8. 簡述數(shù)倉建模有哪些方式 ？

1、維度建模 維度建模按數(shù)據(jù)組織類型劃分可分為星型模型、雪花模型、星座模型。 1）星型模型 星型模型主要是維表和事實表，以事實表為中心，所有維度直接關(guān)聯(lián)在事實表上，呈星型分布。 2）雪花模型 雪花模型，在星型模型的基礎(chǔ)上，維度表上又關(guān)聯(lián)了其他維度表。這種模型維護成本高，性能方面也較 差，所以一般不建議使用。尤其是基于hadoop體系構(gòu)建數(shù)倉，減少join就是減少shuule，性能差距會很 大。 星型模型可以理解為，一個事實表關(guān)聯(lián)多個維度表，雪花模型可以理解為一個事實表關(guān)聯(lián)多個維度表， 維度表再關(guān)聯(lián)維度表。 3）星座模型 數(shù)據(jù)倉庫由多個主題構(gòu)成，包含多個事實表，而維表是公共的，可以共享（例如兩張事實表共用一些維 度表時，就叫做星型模型），這種模式可以看做星型模式的匯集，因而稱作星系模式或者事實星座模式。

2、范式建模（ER建模） 從全企業(yè)的高度設(shè)計一個3NF模型，用實體加關(guān)系描述的數(shù)據(jù)模型描述企業(yè)業(yè)務(wù)架構(gòu)，在范式理論上符 合3NF。此建模方法，對建模人員的能力要求非常高。 特點：設(shè)計思路自上而下，適合上游基礎(chǔ)數(shù)據(jù)存儲，同一份數(shù)據(jù)只存儲一份，沒有數(shù)據(jù)冗余，方便解 耦，易維護，缺點是開發(fā)周期一般比較長，維護成本高。

3、Data Vault模型 DataVault由Hub（關(guān)鍵核心業(yè)務(wù)實體）、Link（關(guān)系）、Satellite（實體屬性） 三部分組成 ，是Dan Linstedt發(fā)起創(chuàng)建的一種模型方法論，它是在ER關(guān)系模型上的衍生，同時設(shè)計的出發(fā)點也是為了實現(xiàn)數(shù) 據(jù)的整合，并非為數(shù)據(jù)決策分析直接使用。

4、Anchor模型 Anchor模型是對Data Vault模型做了進一步規(guī)范化處理，它是一個高度可擴展的模型，所有的擴展只是添加而不是修改，因此它將模型規(guī)范到6NF，基本變成了K-V結(jié)構(gòu)模型。企業(yè)很少使用

9. 簡述數(shù)倉建模的流程 ？

數(shù)據(jù)倉庫的發(fā)展大致經(jīng)歷了這樣的三個過程： 簡單報表階段：這個階段，系統(tǒng)的主要目標(biāo)是解決一些日常的工作中業(yè)務(wù)人員需要的報表，以及生成一 些簡單的能夠幫助領(lǐng)導(dǎo)進行決策所需要的匯總數(shù)據(jù)。大部分表現(xiàn)形式為數(shù)據(jù)庫和前端報表工具。 數(shù)據(jù)集市階段：這個階段，主要是根據(jù)某個業(yè)務(wù)部門的需要，進行一定的數(shù)據(jù)的采集，整理，按照業(yè)務(wù) 人員的需要，進行多維報表的展現(xiàn)，能夠提供對特定業(yè)務(wù)指導(dǎo)的數(shù)據(jù)，并且能夠提供特定的領(lǐng)導(dǎo)決策數(shù) 據(jù)。 數(shù)據(jù)倉庫階段：這個階段，主要是按照一定的數(shù)據(jù)模型，對整個企業(yè)的數(shù)據(jù)進行采集，整理，并且能夠 按照各個業(yè)務(wù)部門的需要，提供跨部門的，完全一致的業(yè)務(wù)報表數(shù)據(jù)，能夠通過數(shù)據(jù)倉庫生成對對業(yè)務(wù) 具有指導(dǎo)性的數(shù)據(jù)，同時，為領(lǐng)導(dǎo)決策提供全面的數(shù)據(jù)支持。 通過數(shù)據(jù)倉庫建設(shè)的發(fā)展階段，可以看出，數(shù)據(jù)倉庫的建設(shè)和數(shù)據(jù)集市的建設(shè)的重要區(qū)別就在于數(shù)據(jù)模 型的支持。因此，數(shù)據(jù)模型的建設(shè)，對于我們數(shù)據(jù)倉庫的建設(shè)，有著決定性的意義。 一般來說，數(shù)據(jù)模型的建設(shè)主要能夠幫助我們解決以下的一些問題： 1）進行全面的業(yè)務(wù)梳理，改進業(yè)務(wù)流程 在業(yè)務(wù)模型建設(shè)的階段，能夠幫助我們的企業(yè)或者是管理機關(guān)對本單位的業(yè)務(wù)進行全面的梳理。 通過業(yè)務(wù)模型的建設(shè)，我們應(yīng)該能夠全面了解該單位的業(yè)務(wù)架構(gòu)圖和整個業(yè)務(wù)的運行情況，能夠?qū)?業(yè)務(wù)按照特定的規(guī)律進行分門別類和程序化。 同時，幫助我們進一步的改進業(yè)務(wù)的流程，提高業(yè)務(wù)效率，指導(dǎo)我們的業(yè)務(wù)部門的生產(chǎn)。 2）建立全方位的數(shù)據(jù)視角，消滅信息孤島和數(shù)據(jù)差異 通過數(shù)據(jù)倉庫的模型建設(shè)，能夠為企業(yè)提供一個整體的數(shù)據(jù)視角，不再是各個部門只是關(guān)注自己的 數(shù)據(jù)。 而且通過模型的建設(shè)，勾勒出了部門之間內(nèi)在的聯(lián)系，幫助消滅各個部門之間的信息孤島的問題。 更為重要的是，通過數(shù)據(jù)模型的建設(shè)，能夠保證整個企業(yè)的數(shù)據(jù)的一致性，各個部門之間數(shù)據(jù)的差 異將會得到有效解決。 3）解決業(yè)務(wù)的變動和數(shù)據(jù)倉庫的靈活性 通過數(shù)據(jù)模型的建設(shè)，能夠很好的分離出底層技術(shù)的實現(xiàn)和上層業(yè)務(wù)的展現(xiàn)。 當(dāng)上層業(yè)務(wù)發(fā)生變化時，通過數(shù)據(jù)模型，底層的技術(shù)實現(xiàn)可以非常輕松的完成業(yè)務(wù)的變動，從而達 到整個數(shù)據(jù)倉庫系統(tǒng)的靈活性。 4）幫助數(shù)據(jù)倉庫系統(tǒng)本身的建設(shè)

通過數(shù)據(jù)倉庫的模型建設(shè)，開發(fā)人員和業(yè)務(wù)人員能夠很容易的達成系統(tǒng)建設(shè)范圍的界定，以及長期 目標(biāo)的規(guī)劃，從而能夠使整個項目組明確當(dāng)前的任務(wù)，加快整個系統(tǒng)建設(shè)的速度。 1、建模流程 就是業(yè)務(wù)模型->概念模型->邏輯模型->物理模型的這樣一個流程，下面我們詳細解釋一下各個模型階段 都要做什么。 1）業(yè)務(wù)建模：需求溝通 劃分整個單位的業(yè)務(wù)，一般按照業(yè)務(wù)部門的劃分，進行各個部分之間業(yè)務(wù)工作的界定，理清各業(yè)務(wù) 部門之間的關(guān)系。 深入了解各個業(yè)務(wù)部門的內(nèi)具體業(yè)務(wù)流程并將其程序化。提出修改和改進業(yè)務(wù)部門工作流程的方法并程序化。 數(shù)據(jù)建模的范圍界定，整個數(shù)據(jù)倉庫項目的目標(biāo)和階段劃分。 業(yè)務(wù)建模階段其實是一次和業(yè)務(wù)人員梳理業(yè)務(wù)的過程，在這個過程中，不僅能幫助我們技術(shù)人員更好的 理解業(yè)務(wù)，另一方面，也能夠發(fā)現(xiàn)業(yè)務(wù)流程中的一些不合理的環(huán)節(jié)，加以改善和改進。 2）領(lǐng)域（概念）建模：畫圖想好怎么做 抽取關(guān)鍵業(yè)務(wù)概念，并將之抽象化。 將業(yè)務(wù)概念分組，按照業(yè)務(wù)主線聚合類似的分組概念。細化分組概念，理清分組概念內(nèi)的業(yè)務(wù)流程并抽象化。理清分組概念之間的關(guān)聯(lián)，形成完整的領(lǐng)域概念模型。

領(lǐng)域概念建模就是運用了實體建模法，從紛繁的業(yè)務(wù)表象背后通過實體建模法，抽象出實體，事件，說 明等抽象的實體，從而找出業(yè)務(wù)表象后抽象實體間的相互的關(guān)聯(lián)性，保證了我們數(shù)據(jù)倉庫數(shù)據(jù)按照數(shù)據(jù) 模型所能達到的一致性和關(guān)聯(lián)性。 3）邏輯建模：表設(shè)計 業(yè)務(wù)概念實體化，并考慮其具體的屬性。 事件實體化，也就是所謂的事實，并考慮其屬性內(nèi)容。說明實體化，也就是所謂的維度，并考慮其屬性內(nèi)容。邏輯模型具體要求如下：

總體來說就是建表，前面已經(jīng)畫出了關(guān)系圖，這里只要將表里頭有哪些字段考慮出來就可以，如果是事 實表就考慮事實字段和業(yè)務(wù)主鍵，如果是維度表就考慮維度屬性，SCD策略等等。在這里需要確定數(shù)據(jù) 粒度，如果多個指標(biāo)都用到一個字段，則取粒度最小的指標(biāo)。如果不確定指標(biāo)的量度，則取毫秒級作為 粒度。 4）物理建模：建表 針對特定物理化平臺，做出相應(yīng)的技術(shù)調(diào)整。 針對模型的性能考慮，對特定平臺作出相應(yīng)的調(diào)整。針對管理的需要，結(jié)合特定的平臺，做出相應(yīng)的調(diào)整。生成最后的執(zhí)行腳本，并完善。 物理模型具體要求如下：

綜合現(xiàn)實的大數(shù)據(jù)平臺、采集工具、etl工具、數(shù)倉組件、性能要求、管理要求等多方面因素，設(shè)計出具 體的項目代碼，完成數(shù)倉的搭建。 總結(jié)來說，上面的模型設(shè)計流程大部分應(yīng)用于DWD層，也就是事實維度層。通過建模，捋清邏輯，把業(yè) 務(wù)落實到一張張表，并梳理表于表之間的關(guān)系。

2、建模過程 假設(shè)現(xiàn)在在構(gòu)建一張訂單表 從多個維度進行統(tǒng)計組合，形成多維度數(shù)據(jù)集，來從多個角度觀察業(yè)務(wù)過程的好壞 1）選擇業(yè)務(wù)過程 確認(rèn)哪些業(yè)務(wù)處理流程是數(shù)據(jù)倉庫應(yīng)該覆蓋的，是維度方法的基礎(chǔ)。因此，建模的第一個步驟是描 述需要建模的業(yè)務(wù)流程。例如，需要了解和分析一個零售店的銷售情況，那么與該零售店銷售相關(guān) 的所有業(yè)務(wù)流程都是需要關(guān)注的。為了描述業(yè)務(wù)流程，可以簡單地使用純文本將相關(guān)內(nèi)容記錄下 來，或者使用“業(yè)務(wù)流程建模標(biāo)注”（BPMN）方法，也可以使用統(tǒng)一建模語言（UML）或其他類似 的方法。 業(yè)務(wù)過程就是需要那種業(yè)務(wù)場景下產(chǎn)生的訂單表(劃分到那個業(yè)務(wù)線和數(shù)據(jù)域) 業(yè)務(wù)過程就是用戶下單的訂單記錄表

2）選擇數(shù)據(jù)域 （1）申明粒度 粒度就是確認(rèn)一條記錄代表的含義或者是細化到何種程度(一條記錄代表一個訂單還是多個訂單， 如拼團的時候團長的單) 在選擇維度和事實前必須聲明粒度，因為每個候選維度或事實必須與定義的粒度保持一致。在一個 事實所對應(yīng)的所有維度設(shè)計中強制實行粒度一致性是保證數(shù)據(jù)倉庫應(yīng)用性能和易用性的關(guān)鍵。 從給定的業(yè)務(wù)流程獲取數(shù)據(jù)時，原始粒度是最低級別的粒度。建議從原始粒度數(shù)據(jù)開始設(shè)計，因為 原始記錄能夠滿足無法預(yù)期的用戶查詢。匯總后的數(shù)據(jù)粒度對優(yōu)化查詢性能很重要，但這樣的粒度 往往不能滿足對細節(jié)數(shù)據(jù)的查詢需求。 不同的事實可以有不同的粒度，但同一事實中不要混用多種不同的粒度。維度模型建立完成之后， 還有可能因為獲取了新的信息，而回到這步修改粒度級別。 （2）確認(rèn)維度 維度的粒度必須和第二步所聲明的粒度一致。 維度表是事實表的基礎(chǔ)，也說明了事實表的數(shù)據(jù)是從哪里采集來的。 典型的維度都是名詞，如日期、商店、庫存等。維度表存儲了某一維度的所有相關(guān)數(shù)據(jù)，例如，日 期維度應(yīng)該包括年、季度、月、周、日等數(shù)據(jù)。 （3）確認(rèn)事實 這一步識別數(shù)字化的度量，構(gòu)成事實表的記錄。它是和系統(tǒng)的業(yè)務(wù)用戶密切相關(guān)的，因為用戶正是 通過對事實表的訪問獲取數(shù)據(jù)倉庫存儲的數(shù)據(jù)。大部分事實表的度量都是數(shù)字類型的，可累加，可 計算，如成本、數(shù)量、金額等。 3、模型設(shè)計的思路 業(yè)務(wù)需求驅(qū)動，數(shù)據(jù)驅(qū)動，構(gòu)造數(shù)據(jù)倉庫有兩種方式：一是自上而下，一是自下而上。 1）自上而下 Bill Inmon先生推崇“自上而下”的方式，即一個企業(yè)建立唯一的數(shù)據(jù)中心，就像一個數(shù)據(jù)的倉庫，其中數(shù)據(jù)是經(jīng)過整合、經(jīng)過清洗、去掉臟數(shù)據(jù)的、標(biāo)準(zhǔn)的，能夠提供統(tǒng)一的視圖。要建立這樣的數(shù)據(jù)倉庫，并 不從它需要支持哪些應(yīng)用入手，而是要從整個企業(yè)的環(huán)境入手，分析其中的概念，應(yīng)該有什么樣的數(shù) 據(jù)，達成整體概念。 2）自下而上 Ralph Kimball先生推崇“自下而上”的方式，他認(rèn)為建設(shè)數(shù)據(jù)倉庫應(yīng)該按照實際的應(yīng)用需求，加載需要的數(shù)據(jù)，不需要的數(shù)據(jù)不要加載到數(shù)據(jù)倉庫中。這種方式建設(shè)周期較短，客戶能夠很快看到結(jié)果。（針對 客戶的需求，需求要什么就做什么）

4、模型落地實現(xiàn) 按照命名規(guī)范創(chuàng)建表 開發(fā)生成維表和事實表的代碼 進行代碼邏輯測試，驗證數(shù)據(jù)加工邏輯的正確性 代碼發(fā)布，加入調(diào)度并配置相應(yīng)的質(zhì)量監(jiān)控和報警機制

10. 簡述維度建模的步驟，如何確定這些維度的 ？

維度建模主要有4個步驟：選取業(yè)務(wù)過程、定義粒度、確定維度和確定事實。這4個步驟貫穿了維度建模 的整個過程和環(huán)節(jié)。 1、選取業(yè)務(wù) 過程業(yè)務(wù)過程即企業(yè)和組織的業(yè)務(wù)活動，它們一般都有相應(yīng)的源頭業(yè)務(wù)系統(tǒng)支持。對于一個超市來說， 其最基本的業(yè)務(wù)活動就是用戶收銀臺付款；對于一個保險公司來說，最基本的業(yè)務(wù)活動是理賠和保單 等。當(dāng)然在實際操作中，業(yè)務(wù)活動有可能并不是那么簡單直接，此時聽取用戶的意見通常是這一環(huán)節(jié)最 為高效的方式。 需要注意的是，這里談到的業(yè)務(wù)過程并不是指業(yè)務(wù)部門或者職能。模型設(shè)計中，應(yīng)將注意力集中放在業(yè) 務(wù)過程而不是業(yè)務(wù)部門，如果建立的維度模型是同部門捆綁在一起的，就無法避免出現(xiàn)數(shù)據(jù)不一致的情 況（如業(yè)務(wù)編碼、含義等）。因此，確保數(shù)據(jù)一致性的最佳辦法是從企業(yè)和公司全局與整體角度，對于 某一個業(yè)務(wù)過程建立單一的、一致的維度模型。 2、定義粒度 定義粒度意味著對事實表行實際代表的內(nèi)容和含義給出明確的說明。粒度傳遞了事實表度量值相聯(lián)系的 細節(jié)所達到的程度的信息。其實質(zhì)就是如何描述事實表的單個行。 典型的粒度定義包括： 超市顧客小票的每一個子項； 醫(yī)院收費單的明細子項； 個人銀行賬戶的每一次存款或者取款行為； 個人銀行賬戶每個月的余額快照。 對于維度設(shè)計來說，在事實表粒度上達成一致非常重要，如果沒有明確的粒度定義，則不能進入后面的 環(huán)節(jié)。如果在后面的環(huán)節(jié)中發(fā)現(xiàn)粒度的定義不夠或者是錯誤的，那么也必須返回這一環(huán)節(jié)重新定義粒 度。 在定義粒度過程中，應(yīng)該最大限度地選擇業(yè)務(wù)過程中最為原子性的粒度，這樣可以帶來后續(xù)的最大靈活 度，也可以滿足業(yè)務(wù)用戶的任何粒度的分析需求。 3、確認(rèn)維度 定義了粒度之后，相關(guān)業(yè)務(wù)過程的細節(jié)也就確定了，對應(yīng)的維度就很容易確定。正如前文所述，維度是 對度量的上下文和環(huán)境的描述。通過維度，業(yè)務(wù)過程度量與事實就會變得豐富和豐滿起來。對于訂單來 說，常見的維度會包含商品、日期、買家、賣家、門店等而每一個維度還可以包含大量的描述信息，比 如商品維度表會包含商品名稱、標(biāo)簽價、商品品牌、商品類目、商品上線時間等。 4、確認(rèn)事實 確定事實通過業(yè)務(wù)過程分析可能要分析什么來確定。定義粒度之后，事實和度量一般也很容易確定，比 如超市的訂單活動，相關(guān)的度量顯然是銷售數(shù)量和銷售金額。

在實際維度事實設(shè)計中，可能還會碰到度量拆分的問題，比如超市開展單個小票滿10減10元的活動，如 果小票金額超過10元，這10元的優(yōu)惠額如何分配到每一個小票子項實際設(shè)計中，可以和業(yè)務(wù)方具體討論 并制訂具體的拆分分配算法。

11. 簡述維度建模和范式建模區(qū)別 ？

1、范式建模 Inmon提出的集線器的自上而下（EDW-DM）的數(shù)據(jù)倉庫架構(gòu)。操作型或事務(wù)型系統(tǒng)的數(shù)據(jù)源，通過ETL 抽取轉(zhuǎn)換和加載到數(shù)據(jù)倉庫的ODS層，然后通過ODS的數(shù)據(jù)建設(shè)原子數(shù)據(jù)的數(shù)據(jù)倉庫EDW，EDW不是多 維格式的，不方便上層應(yīng)用做數(shù)據(jù)分析，所以需要通過匯總建設(shè)成多維格式的數(shù)據(jù)集市層。 優(yōu)勢：易于維護，高度集成； 劣勢：結(jié)構(gòu)死板，部署周期較長。范式建模應(yīng)用在EDW層 一個符合第三范式的關(guān)系必須具有以下三個條件： 每個屬性的值唯一，不具有多義性； 每個非主屬性必須完全依賴于整個主鍵，而非主鍵的一部分； 每個非主屬性不能依賴于其他關(guān)系中的屬性，因為這樣的話，這種屬性應(yīng)該歸到其他關(guān)系中去。 但是由于EDW的數(shù)據(jù)是原子粒度的，數(shù)據(jù)量比較大，完全規(guī)范的3范式在數(shù)據(jù)的交互的時候效率比較低 下，所以通常會根據(jù)實際情況在事實表上做一些冗余，減少過多的數(shù)據(jù)交互。

2、維度建模 Kimball提出的總線式的自下而上（DM-DW）的數(shù)據(jù)倉庫架構(gòu)。同樣的，操作型或事務(wù)型系統(tǒng)的數(shù)據(jù) 源，通過ETL抽取轉(zhuǎn)換和加載到數(shù)據(jù)倉庫的ODS層，然后通過ODS的數(shù)據(jù)，利用維度建模方法建設(shè)一致 維度的數(shù)據(jù)集市。通過一致性維度可以將數(shù)據(jù)集市聯(lián)系在一起，由所有的數(shù)據(jù)集市組成數(shù)據(jù)倉庫。 優(yōu)勢：構(gòu)建迅速，最快的看到投資回報率，敏捷靈活； 劣勢：作為企業(yè)資源不太好維護，結(jié)構(gòu)復(fù)雜，數(shù)據(jù)集市集成困難。 在維度建模的基礎(chǔ)上又分為三種模型：星型模型、雪花模型、星座模型。 具體選擇哪種建模模型，目前實際企業(yè)實際開發(fā)中，不會選擇絕對一種，根據(jù)情況靈活組合，甚至并存 （一層維度和多層維度都保存）。但是整體來看，更傾向于維度更少的星型模型。尤其是Hadoop體 系，減少Join就是減少Shuule，性能差距很大。

12. 簡述維度表和事實表的區(qū)別 ？

簡單的說維度表就是我們觀察該事物的角度（維度)；事實表就是我們要關(guān)注的內(nèi)容。 事實表：表格里存儲了能體現(xiàn)實際數(shù)據(jù)或詳細數(shù)值，一般由維度編碼和事實數(shù)據(jù)組成。

表示對分析主題所屬類型的描述。比如”昨天早上張三在京東花費200元購買了一個皮包”。那么以購買 為主題進行分析，可從這段信息中提取三個維度：時間維度(昨天早上)，地點維度(京東), 商品維度(皮包)。通常來說維度表信息比較固定，且數(shù)據(jù)量小。 維度表：表格里存放了具有獨立屬性和層次結(jié)構(gòu)的數(shù)據(jù)，一般由維度編碼和對應(yīng)的維度說明(標(biāo)簽)組 成。 表示對分析主題的度量。比如上面那個例子中，200元就是事實信息。事實表包含了與各維度表相關(guān)聯(lián) 的外碼，并通過JOIN方式與維度表關(guān)聯(lián)。事實表的度量通常是數(shù)值類型，且記錄數(shù)會不斷增加，表規(guī)模 迅速增長。 比如你要分析產(chǎn)品銷售情況, 你可以選擇按類別來進行分析,或按區(qū)域來分析. 這樣的按…分析就構(gòu)成一個維度。前面的示例就可以有兩個維度：類型和區(qū)域。下面是兩個常見的維度表結(jié)構(gòu)： 產(chǎn)品維度表：Prod_id, Product_Name, Category, Color, Size, Price 時間維度表：TimeKey, Season, Year, Month, Date 而事實表是數(shù)據(jù)聚合后依據(jù)某個維度生成的結(jié)果表。它的結(jié)構(gòu)示例如下： 銷售事實表：Prod_id(引用產(chǎn)品維度表), TimeKey(引用時間維度表), SalesAmount(銷售總量，以貨幣計), Unit(銷售量) 事實數(shù)據(jù)和維度數(shù)據(jù)的識別必須依據(jù)具體的主題問題而定。事實表用來存儲事實的度量（measure）及 指向各個維的外鍵值。維表用來保存該維的元數(shù)據(jù)，即維的描述信息，包括維的層次及成員類別等

13. 簡述什么是ER模型 ？

在信息系統(tǒng)中，將事務(wù)抽象為“實體”（Entity）、“屬性”（Property）、“關(guān)系”（Relationship）來表示數(shù)據(jù)關(guān)聯(lián)和事物描述，這種對數(shù)據(jù)的抽象建模通常被稱為ER實體關(guān)系模型。 實體：通常為參與到過程中的主體，客觀存在的，比如商品、倉庫、貨位、汽車，此實體非數(shù)據(jù)庫表的 實體表。 屬性：對主體的描述、修飾即為屬性，比如商品的屬性有商品名稱、顏色、尺寸、重量、產(chǎn)地等。 關(guān)系：現(xiàn)實的物理事件是依附于實體的，比如商品入庫事件，依附實體商品、貨位，就會有“庫存”的屬 性產(chǎn)生；用戶購買商品，依附實體用戶、商品，就會有“購買數(shù)量”、“金額”的屬性產(chǎn)品。 實體之間建立關(guān)系時，存在對照關(guān)系： 1:1：即1對1的關(guān)系 1:n：即1對多的關(guān)系n:m：即多對多的關(guān)系 在日常建模中，“實體”用矩形表示，“關(guān)系”用菱形，“屬性”用橢圓形。ER實體關(guān)系模型也稱為E-R關(guān)系 圖。

14. 簡述OLAP、OLTP解釋 ？

操作型處理，叫聯(lián)機事務(wù)處理 OLTP（On-Line Transaction Processing） 也可以稱面向交易的處理系統(tǒng)，它是針對具體業(yè)務(wù)在數(shù)據(jù)庫聯(lián)機的日常操作，通常對少數(shù)記錄進行查 詢、修改。用戶較為關(guān)心操作的響應(yīng)時間、數(shù)據(jù)的安全性、完整性和并發(fā)支持的用戶數(shù)等問題。傳統(tǒng)的 數(shù)據(jù)庫系統(tǒng)作為數(shù)據(jù)管理的主要手段，主要用于操作型處理。 分析型處理，叫聯(lián)機分析處理 OLAP（On-Line Analytical Processing） 一般針對某些主題的歷史數(shù)據(jù)進行分析，支持管理決策。 OLTP與OLAP的異同如下表所示：

操作型處理 分析型處理 細節(jié)的 綜合的或提煉的 實體-關(guān)系（ER）模型 星型或雪花模型 存取瞬間數(shù)據(jù) 存儲歷史數(shù)據(jù)，不包含最近的數(shù)據(jù) 可更新的 只讀，只追加 一次操作一個單元 一次操作一個集合 性能要求高，響應(yīng)時間短 性能要求寬松 面向事務(wù) 面向分析 一次操作數(shù)據(jù)量小 一次操作數(shù)據(jù)量大 支持日常操作 支持決策需求 數(shù)據(jù)量小 數(shù)據(jù)量大 客戶訂單、庫存水平和銀行賬戶等 客戶收益分析、市場細分等

15. 簡述維度設(shè)計中有整合和拆分，有哪些方法，并詳細說明 ？

1、垂直整合 在不同來源表中可能會包含這相同的數(shù)據(jù)集。只是存儲的信息不同。如電商的會員相關(guān)的表包含了會員 基礎(chǔ)信息表、會員擴展表、會員等級信息表等，依照維度設(shè)計方法，盡量整合到會員維度模型中，豐富 其維度屬性。

2、水平整合 不同來源表包含不同的數(shù)據(jù)集，不同子集之間無交叉，也可以存在部分交叉。如上會員體系中還可能存 在各種類型會員表，如淘寶生態(tài)中 淘寶會員、國際站會員、支付寶會員等水平類型的表。這種情況的整合過程中，首先需要考慮各個會員體系是否有交叉，如果存在交叉，則需要去重；如果不存在交叉，則 需要考慮不同子集的自然鍵是否存在沖突，如果不沖突，則可以考慮將各子集的自然鍵作為整合后的表

的自然鍵；另一種方式是設(shè)置超自然鍵，將來源表各子集的自然鍵加工成個字段作為超自然鍵。

3、水平拆分 維度通?？梢园凑疹悇e和類型細分。如某寶系商品表，根據(jù)業(yè)務(wù)線或行業(yè)等可以對商品進行細分，如淘 寶的商品、天貓的商品、 飛豬旅行的商品、淘寶海外的商品、天貓國際的商品等。不同分類的商品，其維度屬性可能相同，也可能不同。航旅商品想比較于普通商品都有都有商品價格、標(biāo)題、類型、上架時 間、類目等維度屬性。但是航旅的商品除了有這些公共屬性外，還有酒店、點、門票、旅行等自己獨特 的維度屬性。 針對此問題一般有兩種解決方案： 將維度的不同分類實例化為不同的維度，同時在主維度表中保存公共屬性； 維護單一維度，包含所有的可能的屬性。 具體選擇哪種方案，在數(shù)據(jù)模型設(shè)計過程中需要考慮的因素有很多，基本不可能滿足各個特性指標(biāo)的最 優(yōu)化。在設(shè)計過程中需要重點考慮以下幾個原則。 擴展性：當(dāng)源系統(tǒng)、業(yè)務(wù)邏輯變化時，能通過較少的成本快速擴展模型，保持核心模型的相對穩(wěn)定 性。軟件工程中的高內(nèi)聚、低稠合的思想是重要的指導(dǎo)方針。 效能：在性能和成本方面取得平衡。通過犧牲一定的存儲成本，達到性能和邏輯的優(yōu)化。 易用性：模型可理解性高、訪問復(fù)雜度低。用戶能夠方便地從模型中找到對應(yīng)的數(shù)據(jù)表，并能夠方 便地查詢和分析。 根據(jù)數(shù)據(jù)模型的設(shè)計思想我們可以如下考慮和選擇： 第一個是維度不同分類的屬性差異情況。當(dāng)維度屬性隨類型變化較大時，將所有可能的屬性建立在 一個表中時不切合實際的，也沒有必要這樣做。此時建議采用方案一，定義一個主維度用于存放公 共屬性；同時定義多個子維度，其中除了包含公共屬性外，還包含各自的特殊屬性。比如在阿里巴 巴數(shù)據(jù)倉庫維度體系中，依據(jù)此方法，構(gòu)建了商品維度、航旅商品維度等。公共屬性 般比較穩(wěn) 定，通過核心的商品維度，保證了核心維度的穩(wěn)定性；通過擴展子維度的方式，保證了模型的擴展 性。 第二個是業(yè)務(wù)的關(guān)聯(lián)程度。兩個相關(guān)性較低的業(yè)務(wù)，稠合在起弊大于利，對模型的穩(wěn)定性和易用性 影響較大。比如在數(shù)據(jù)倉庫維度體系中，對某寶商品和 *** 商品構(gòu)建兩個維度。業(yè)務(wù)各自發(fā)展在數(shù)據(jù)倉庫層面，屬于不同數(shù)據(jù)集市，一 般不會相互調(diào)用，業(yè)務(wù)分析人員 般只針對本數(shù)據(jù)集市進行統(tǒng)計分析。如果設(shè)計成一個維度，由于不同業(yè)務(wù)各自發(fā)展， 此維度需要變更，淘寶業(yè)務(wù)變更亦然， 穩(wěn)定性很差；在易用性方面，會給數(shù)據(jù)使用方造成困擾。

4、垂直拆分 維度是維度建模的基礎(chǔ)和靈魂，維度屬性的豐富程度直接決定了數(shù)據(jù)倉庫的能力。在進行維度設(shè)計時， 依據(jù)維度設(shè)計的原則，盡可能豐富維度屬性，同時進行反規(guī)范化處理。對于具體實現(xiàn)時可能存在的問題 如下： 一是在“水平拆分”中提到的，由于維度分類的不同而存在特殊的維度屬性，可以通過水平拆分的方 式解決此問題。 二是某些維度屬性的來源表產(chǎn)生時間較早，而某些維度屬性的來表產(chǎn)出時間較晚；或者某些維度屬 性的熱度高、使用頻繁，而某些維度屬性的熱度低、較少使用 或或者某些維度屬性經(jīng)常變化，而某些維度屬性比較穩(wěn)定。在“水平拆分”中提到的模型設(shè)計的三個原則同樣適合解決此問題。 出于擴展性、產(chǎn)出時間、易用性等方面的考慮，設(shè)計主從維度。主維度表存放穩(wěn)定、產(chǎn)出時間早、認(rèn)讀 高的屬性；從表存放變化較快、產(chǎn)出時間較晚、熱度低的屬性。例如在商品維表的設(shè)計中，可以設(shè)計商 品主維度和商品的擴展維度。主商品表時間可以每天1點產(chǎn)生，而擴展維度每天3點才能產(chǎn)生。由于商品 擴展維度有冗余的庫存等變化較快的數(shù)據(jù)，對于主維度進行緩慢變化的處理較為重要。通過存儲的冗余 和計算成本的增加，實現(xiàn)了商品主模型的穩(wěn)定和產(chǎn)出時間的提前，對于整個數(shù)據(jù)倉庫的穩(wěn)定和下游應(yīng)用 的產(chǎn)出都有較大意義。

16. 簡述事實表設(shè)計分幾種，每一種都是如何在業(yè)務(wù)中使用 ？

事實表作為數(shù)據(jù)倉庫維度建模的核心，緊緊圍繞著業(yè)務(wù)過程來設(shè)計，通過獲取描述業(yè)務(wù)過程的度量來表 達業(yè)務(wù)過程，包含了引用的維度 和與業(yè)務(wù)過程有關(guān)的度量。 1、事實表概述 事實表有三種類型 : 事務(wù)事實表、周期快照事實表和累積快照事實表。 1）事務(wù)事實表 也稱原子事實表，描述業(yè)務(wù)過程，跟蹤控件或時間上某點的度量事件，保存的是最原子的數(shù)據(jù)。 類似于mysql binlog日志，每一次相關(guān)的 change 都記錄下來，生成一行新的數(shù)據(jù)。 2）周期快照事實表 以一個周期為時間間隔，來記錄事實，一般周期可以是每天、每周、每月、每年等。 只看某個業(yè)務(wù)過程，比如訂單收貨，數(shù)據(jù)按訂單收貨時間來切分，周期可以為每天、每月等。 3）累積快照事實表 用來描述過程開始和結(jié)束之間的關(guān)鍵步驟事件，覆蓋過程的整個生命周期，通常具有多個日期字段來記 錄關(guān)鍵時間點；當(dāng)過程隨著生命周期不斷變化時，記錄也會隨著過程的變化而被修改。 要看整個生命周期的多個業(yè)務(wù)過程，比如：創(chuàng)建訂單 → 買家付款 → 賣家發(fā)貨 → 買家確認(rèn)收貨。粒度是一個訂單一行數(shù)據(jù)，創(chuàng)建訂單時間，付款時間，發(fā)貨時間，收貨時間，分別作為一個字段，便于計算 不同業(yè)務(wù)過程的時間間隔。

2、事實表設(shè)計原則 原則 1：盡可能包含所有與業(yè)務(wù)過程相關(guān)的事實

分析哪些事實與業(yè)務(wù)過程相關(guān)，是設(shè)計過程中非常重要的關(guān)注點； 在事實表中，盡量包含所有與業(yè)務(wù)過程相關(guān)的事實，即使存在冗余，由于事實通常是數(shù)字型，存儲 開銷不會太大； 原則 2：只選擇與業(yè)務(wù)過程相關(guān)的事實 如訂單的下單這個業(yè)務(wù)過程，事實表中不應(yīng)該存在支付金額這個表示支付業(yè)務(wù)過程的事實； 原則 3：分解不可加性事實為可加的組件 如訂單的優(yōu)惠率，應(yīng)分解為訂單原價金額與訂單優(yōu)惠金額兩個事實存儲在事實表中； 原則 4：在選擇維度和事實之前必須先聲明粒度 粒度用于確定事實表中一行所表示業(yè)務(wù)的細節(jié)層次，決定了維度模型的擴展性； 每個維度和事實必須與所定義的粒度保持一致； 設(shè)計事實表時，粒度定義越細越好，一般從最低級別的原子粒度開始； 因為原子粒度提供了最大限度的靈活性，可以支持無法預(yù)期的各種細節(jié)層次的用戶需求； 原則 5：在同一個事實表中不能有多種不同粒度的事實 疑問：怎么判斷不同事實的粒度是否相同？ 粒度為票一級；（實際業(yè)務(wù)中，一個訂單可以同時支付多張票） 票支付金額和票折扣金額，兩個事實的粒度為 “票級”，與定義的粒度一致； 訂單支付金額和訂單票數(shù)，兩個事實的粒度為 “訂單級”，屬于上一層訂單級數(shù)據(jù)，與 “票級” 事實表的粒度不一致，且不能進行匯總； 如果，以訂單金額和訂單票數(shù)這兩個維度匯總總金額和總票數(shù)，會造成大量的重復(fù)計算； 原則 6：事實的單位要保持一致 如訂單金額、訂單優(yōu)惠金額、訂單運費這 3 個事實，應(yīng)該采用統(tǒng)一的計量單位，統(tǒng)一為元或者分， 以方便使用； 原則 7：對事實的 null 值要處理 原因：在數(shù)據(jù)庫中，null 值對常用數(shù)字型字段的 SQL 過濾條件都不生效；如，大于、小于、等于、大于或等于、小于或等于； 處理：用 0 代替 null ； 原則 8：使用退化維度提高事實表的易用性 事實表中存儲各種類型的常用維度信息，較少下游用戶使用時關(guān)聯(lián)多個表的操作； 通過退化維度，可以實現(xiàn)對事實表的過濾查詢、控制聚合層次、排序數(shù)據(jù)、定義主從關(guān)系等； 易用性：對事實表，更較少關(guān)聯(lián)操作、過濾查詢、控制聚合層次、排序數(shù)據(jù)、定義主從關(guān)系等； 在 Kimball 的維度建模中，通常按照星形模型的方式設(shè)計，通過事實表的外鍵關(guān)聯(lián)專門的維表，這種方式來獲取維度，謹(jǐn)慎使用退化維表；這與大數(shù)據(jù)領(lǐng)域的事實表設(shè)計不一樣。 思路：通過增加冗余存儲，減少計算開銷，提高使用效率

3、事實表設(shè)計方法 上上一題也有說過，這里大同小異，也可以看上上一題的 Kimball 的維度模型設(shè)計 4 步法：選擇業(yè)務(wù)過程、聲明粒度、確定維度、確定事實。 當(dāng)前的互聯(lián)網(wǎng)大數(shù)據(jù)環(huán)境，維度模型的設(shè)計，是基于 Kimball 的四步維度建模方法進行了更進一步的改進。 第一步：選擇業(yè)務(wù)過程及確定事實表類型 思路：詳細分析需求，對業(yè)務(wù)的整個生命周期進行分析，明確關(guān)鍵的業(yè)務(wù)步驟，從而選擇與需求有關(guān)的 業(yè)務(wù)過程。 以實例說明：如何選擇業(yè)務(wù)過程？如何確定事實表類型？ 例：淘寶的一個交易訂單 1）分析業(yè)務(wù)的生命周期：如上圖，業(yè)務(wù)過程通常使用行為動詞表示業(yè)務(wù)執(zhí)行的活動； 2）明確關(guān)鍵的業(yè)務(wù)步驟：該訂單流轉(zhuǎn)的業(yè)務(wù)過程有 4 個：創(chuàng)建訂單 → 買家付款 → 賣家發(fā)貨 → 買家確認(rèn)收貨； 3）根據(jù)業(yè)務(wù)需求，選擇與維度建模有關(guān)的業(yè)務(wù)過程； 如是選擇 “買家付款” 這個業(yè)務(wù)過程，還是選擇 “創(chuàng)建訂單” 和 “買家付款” 這兩個業(yè)務(wù)過程，具體根據(jù)業(yè)務(wù)情況來定。 4）根據(jù)所選的業(yè)務(wù)過程確定事實表類型； 如選擇 “買家付款” 這個業(yè)務(wù)過程，則事實表類型應(yīng)為只包含買家付款這一個業(yè)務(wù)過程的 “單事務(wù)事實表”； 如選擇了所有 4 個業(yè)務(wù)過程，并且需要分享各業(yè)務(wù)過程的時間間隔，則事實表類型應(yīng)為包含了所有 4 個業(yè)務(wù)過程的 “累積快照事實表”。 第二步：聲明粒度 粒度的作用： 粒度的聲明，意味著精確定義事實表的每一行所表示的業(yè)務(wù)含義； 明確的粒度能夠確保對實表中行的意思的理解不會產(chǎn)生混淆，保證所有的事實按照同樣的細節(jié)層次 記錄。 粒度的選擇：盡量選擇最細級別的原子粒度，以確保事實表的應(yīng)用具有最大的靈活性。 靈活性：支持無法預(yù)期的各種細節(jié)層次的用戶需求； 對于訂單級別，粒度可以定義為最細的訂單級別。（如，父子訂單，事實表的粒度可以定 “子訂單級別” ；） 第三步：確定維度 完成了粒度聲明，就意味著確定了主鍵，對應(yīng)的維度組合以及相關(guān)的維度字段也可以確定了。 選擇維度的原則：應(yīng)該選擇能夠描述清楚業(yè)務(wù)過程所處的環(huán)境的維度信息； 如淘寶訂單 “付款事務(wù)事實表” 中，粒度為 “子訂單”，相關(guān)的維度有買家、賣家、商品、收貨人信息、業(yè)務(wù)類型、訂單時間等。 第四步：確定事實 確定原則：選擇與業(yè)務(wù)過程有關(guān)的所有事實，且事實的粒度要與所聲明的事實表的粒度一致； 思路：可以通過回答 “過程的度量是什么” 來確定； 注意：將不可加性事實分解為可加的組件；（分解的原則：可以通過分解后的可加的屬性值，計算得到 不可加性事實）

17. 簡述單事務(wù)事實表、多事務(wù)事實表區(qū)別與作用 ？

事務(wù)事實表用于跟蹤定義業(yè)務(wù)過程的個體行為設(shè)計案例場景如下：為交易事務(wù)設(shè)計事實表 1）業(yè)務(wù)分析：交易事務(wù)包括下單、支付、發(fā)貨、完結(jié)四個業(yè)務(wù)過程。 2）確定粒度：同一個訂單中可以包含多個在商品，每個商品對應(yīng)一個子訂單。在上述四個業(yè)務(wù)過程中 下單、支付、完結(jié)選擇子訂單作為粒度，而發(fā)貨業(yè)務(wù)過程包含物流信息，以父訂單為粒度。 3）確定維度：賣家、買家、商品、商品類目、發(fā)貨地區(qū)、收貨地區(qū)、父訂單一級雜項維度。 4）確定事實：每個業(yè)務(wù)過程有自己的事實，如下單過程的下單金額、下單數(shù)量；支付過程的支付金 額、積分金額等。 5）冗余維度：為了提升效率，把常用的維度榮譽到事實表

1、單事務(wù)事實表 一個業(yè)務(wù)過程一張事實表，方便對每個業(yè)務(wù)做獨立分析 2、多事務(wù)事實表 將不同業(yè)務(wù)過程放在同一個事實表中，又可以分為不同業(yè)務(wù)過程使用不同事實字段和不同業(yè)務(wù)過程使用 相同事實字段兩種。 1）不同業(yè)務(wù)過程使用不同事實字段，一般用于業(yè)務(wù)相似，粒度相同但是業(yè)務(wù)過程的度量差異大的場 景。有兩個典型的問題： 在數(shù)據(jù)中遇到不是當(dāng)前業(yè)務(wù)過程的度量，采用零值處理 表中存在多個業(yè)務(wù)，如何標(biāo)記？給每一個數(shù)據(jù)加一個屬性標(biāo)識是否當(dāng)日業(yè)務(wù) 2）不同業(yè)務(wù)過程使用相同事實字段，用一個標(biāo)簽字段標(biāo)識是那種業(yè)務(wù)（如商品的收藏/刪除）。一般用 于業(yè)務(wù)相似，粒度相同同時業(yè)務(wù)過程的度量差異不大的場景。但是有一個問題要注意，因為用同一個字 段標(biāo)識不同業(yè)務(wù)的度量，所以數(shù)據(jù)一個周期內(nèi)會有多條記錄。 3、單事務(wù)事實表與多事務(wù)事實表對比

單事務(wù)事實表 多事務(wù)事實表 粒度 相互不相關(guān) 相同粒度 維度 相互不相關(guān) 一致 事實 只取當(dāng)前業(yè)務(wù)事實 同時保留多個過程事實，非當(dāng)前業(yè)務(wù)的事實用零值處理 冗余維度 多個業(yè)務(wù)過程需要冗余多次 多個業(yè)務(wù)過程只冗余一次 計算成本 較多，每個業(yè)務(wù)單獨計算一次 多個業(yè)務(wù)融合在一張表，只需計算一次

另外，如果一個業(yè)務(wù)過程的事實量巨大，不宜使用多事務(wù)事實表，會造成大量零值

18. 簡述說下一致性維度、一致性事實、總線矩陣 ？

在Kimball的維度建模的數(shù)據(jù)倉庫中，關(guān)于多維體系結(jié)構(gòu)（MD）有三個關(guān)鍵性概念：總線架構(gòu)（Bus Architecture），一致性維度（Conformed Dimension）和一致性事實（Conformed Fact）。

1、總線架構(gòu) 在多維體系結(jié)構(gòu)（MD）（也就是總線架構(gòu)）的數(shù)據(jù)倉庫架構(gòu)中，主導(dǎo)思想是分步建立數(shù)據(jù)倉庫，由數(shù) 據(jù)集市組合成企業(yè)的數(shù)據(jù)倉庫。但是，在建立第一個數(shù)據(jù)集市前，架構(gòu)師首先要做的就是設(shè)計出在整個 企業(yè)內(nèi)具有統(tǒng)一解釋的標(biāo)準(zhǔn)化的維度和事實，即一致性維度和一致性事實。而開發(fā)團隊必須嚴(yán)格的按照 這個體系結(jié)構(gòu)來進行數(shù)據(jù)集市的迭代開發(fā)。 一致性維度就好比企業(yè)范圍內(nèi)的一組總線，不同數(shù)據(jù)集市的事實的就好比插在這組總線上的元件。這也 是稱之為總線架構(gòu)的原因。 實際設(shè)計過程中，我們通常把總線架構(gòu)列表成矩陣的形式，其中列為一致性維度，行為不同的業(yè)務(wù)處理 過程，即事實，在交叉點上打上標(biāo)記表示該業(yè)務(wù)處理過程與該維度相關(guān)。這個矩陣也稱為總線矩陣 （Bus Matrix）。 總線架構(gòu)和一致性維度、一致性事實共同組成了Kimball的多維體系結(jié)構(gòu)的基礎(chǔ)，也建立了一套可以逐步 建立數(shù)據(jù)倉庫的方法論。由于總線架構(gòu)是多維體系結(jié)構(gòu)的核心，所以我們有時就把多維體系結(jié)構(gòu)直接稱 為總線架構(gòu)。

2、價值鏈的意義 每家機構(gòu)都有一個關(guān)鍵業(yè)務(wù)過程組成的潛在價值鏈，這個價值鏈確定機構(gòu)主體活動的自然邏輯流程。數(shù) 據(jù)倉庫建設(shè)就是圍繞著價值鏈建立一致化的維度和事實。

3、數(shù)據(jù)總矩陣 矩陣的每一行對應(yīng)都對應(yīng)機構(gòu)中的一個業(yè)務(wù)過程，每一列都和一個業(yè)務(wù)維度相對應(yīng)，用叉號填充顯示的 是和每一行相關(guān)的列。業(yè)務(wù)過程應(yīng)該先從單個數(shù)據(jù)源系統(tǒng)開始，然后再進行多數(shù)據(jù)源的合并。 企業(yè)數(shù)據(jù)倉庫總線矩陣是DW/BI系統(tǒng)的一個總體數(shù)據(jù)架構(gòu)，提供了一種可用于分解企業(yè)數(shù)據(jù)倉庫規(guī)劃任 務(wù)的合理方法，開發(fā)團隊可以獨立的，異步的完成矩陣的各個業(yè)務(wù)過程，迭代地去建立一個集成的企業(yè) 數(shù)據(jù)倉庫。

4、一致性維度 在多維體系結(jié)構(gòu)中，沒有物理上的數(shù)據(jù)倉庫，由物理上的數(shù)據(jù)集市組合成邏輯上的數(shù)據(jù)倉庫。而且數(shù)據(jù) 集市的建立是可以逐步完成的，最終組合在一起，成為一個數(shù)據(jù)倉庫。如果分步建立數(shù)據(jù)集市的過程出 現(xiàn)了問題，數(shù)據(jù)集市就會變成孤立的集市，不能組合成數(shù)據(jù)倉庫，而一致性維度的提出正式為了解決這 個問題。 一致性維度的范圍是總線架構(gòu)中的維度，即可能會在多個數(shù)據(jù)集市中都存在的維度，這個范圍的選取需 要架構(gòu)師來決定。一致性維度的內(nèi)容和普通維度并沒有本質(zhì)上區(qū)別，都是經(jīng)過數(shù)據(jù)清洗和整合后的結(jié) 果。一致性維度建立的地點是多維體系結(jié)構(gòu)的后臺（Back Room），即數(shù)據(jù)準(zhǔn)備區(qū)。 在多維體系結(jié)構(gòu)的數(shù)據(jù)倉庫項目組內(nèi)需要有專門的維度設(shè)計師，他的職責(zé)就是建立維度和維護維度的一 致性。在后臺建立好的維度同步復(fù)制到各個數(shù)據(jù)集市。這樣所有數(shù)據(jù)集市的這部分維度都是完全相同 的。建立新的數(shù)據(jù)集市時，需要在后臺進行一致性維度處理，根據(jù)情況來決定是否新增和修改一致性維 度，然后同步復(fù)制到各個數(shù)據(jù)集市。這是不同數(shù)據(jù)集市維度保持一致的要點。 在同一個集市內(nèi)，一致性維度的意思是兩個維度如果有關(guān)系，要么就是完全一樣的，要么就是一個維度 在數(shù)學(xué)意義上是另一個維度的子集。 例如，如果建立月維度話，月維度的各種描述必須與日期維度中的完全一致，最常用的做法就是在日期 維度上建立視圖生成月維度。這樣月維度就可以是日期維度的子集，在后續(xù)鉆取等操作時可以保持一 致。如果維度表中的數(shù)據(jù)量較大，出于效率的考慮，應(yīng)該建立物化視圖或者實際的物理表。這樣，維度 保持一致后，事實就可以保存在各個數(shù)據(jù)集市中。雖然在物理上是獨立的，但在邏輯上由一致性維度使 所有的數(shù)據(jù)集市是聯(lián)系在一起，隨時可以進行交叉探察等操作，也就組成了數(shù)據(jù)倉庫。

5、一致性事實 在建立多個數(shù)據(jù)集市時，完成一致性維度的工作就已經(jīng)完成了一致性的80%－90%的工作量。余下的工 作就是建立一致性事實。一致性事實和一致性維度有些不同，一致性維度是由專人維護在后臺（Back Room），發(fā)生修改時同步復(fù)制到每個數(shù)據(jù)集市，而事實表一般不會在多個數(shù)據(jù)集市間復(fù)制。需要查詢 多個數(shù)據(jù)集市中的事實時，一般通過交叉探查（drill across）來實現(xiàn)。

為了能在多個數(shù)據(jù)集市間進行交叉探查，一致性事實主要需要保證兩點：第一個是KPI的定義及計算方 法要一致，第二個是事實的單位要一致性。如果業(yè)務(wù)要求或事實上就不能保持一致的話，建議不同單位 的事實分開建立字段保存。 這樣，一致性維度將多個數(shù)據(jù)集市結(jié)合在一起，一致性事實保證不同數(shù)據(jù)集市間的事實數(shù)據(jù)可以交叉探 查，一個分布式的數(shù)據(jù)倉庫就建成了。

6、小結(jié) 總線矩陣：業(yè)務(wù)過程和維度的交點。 一致性維度：同一集市的維度表，內(nèi)容相同或包含。一致性維度要么是統(tǒng)一的，要么是維度表的一個子 集。 一致性事實：不同集市的同一事實，需保證口徑一致，單位統(tǒng)一。指每個度量在整個數(shù)據(jù)倉庫中都是唯 一的統(tǒng)計口徑，為了避免歧義，一個度量只有唯一的業(yè)務(wù)術(shù)語

19. 簡述從ODS層到DW層的ETL，做了哪些工作 ？

這里，我們將數(shù)據(jù)模型分為三層：數(shù)據(jù)運營層(原始數(shù)據(jù)層)（ ODS ）、數(shù)據(jù)倉庫層（DW）和數(shù)據(jù)應(yīng)用層（APP）。 ODS層存放的是接入的原始數(shù)據(jù)，DW層是存放我們要重點設(shè)計的數(shù)據(jù)倉庫中間層數(shù)據(jù)，APP是面向業(yè)務(wù) 定制的應(yīng)用數(shù)據(jù)。 1、數(shù)據(jù)運營層：ODS（Operational Data Store） “面向主題的”數(shù)據(jù)運營層，也叫ODS層，是最接近數(shù)據(jù)源中數(shù)據(jù)的一層，數(shù)據(jù)源中的數(shù)據(jù)，經(jīng)過抽取、 洗凈、傳輸，也就說傳說中的 ETL 之后，裝入本層。本層的數(shù)據(jù)，總體上大多是按照源頭業(yè)務(wù)系統(tǒng)的分類方式而分類的。 一般來講，為了考慮后續(xù)可能需要追溯數(shù)據(jù)問題，因此對于這一層就不建議做過多的數(shù)據(jù)清洗工作，原 封不動地接入原始數(shù)據(jù)即可，至于數(shù)據(jù)的去噪、去重、異常值處理等過程可以放在后面的DWD層來做。 2、數(shù)據(jù)倉庫層：DW（Data Warehouse） 數(shù)據(jù)倉庫層是我們在做數(shù)據(jù)倉庫時要核心設(shè)計的一層，在這里，從 ODS 層中獲得的數(shù)據(jù)按照主題建立各種數(shù)據(jù)模型。DW層又細分為 DWD（Data Warehouse Detail）層、DWM（Data WareHouse Middle）層和DWS（Data WareHouse Servce）層。 1）數(shù)據(jù)明細層：DWD（Data Warehouse Detail） 該層一般保持和ODS層一樣的數(shù)據(jù)粒度，并且提供一定的數(shù)據(jù)質(zhì)量保證。同時，為了提高數(shù)據(jù)明細層的 易用性，該層會采用一些維度退化手法，將維度退化至事實表中，減少事實表和維表的關(guān)聯(lián)。 另外，在該層也會做一部分的數(shù)據(jù)聚合，將相同主題的數(shù)據(jù)匯集到一張表中，提高數(shù)據(jù)的可用性。 2）數(shù)據(jù)中間層：DWM（Data WareHouse Middle） 該層會在DWD層的數(shù)據(jù)基礎(chǔ)上，對數(shù)據(jù)做輕度的聚合操作，生成一系列的中間表，提升公共指標(biāo)的復(fù)用 性，減少重復(fù)加工。 直觀來講，就是對通用的核心維度進行聚合操作，算出相應(yīng)的統(tǒng)計指標(biāo)。 3）數(shù)據(jù)服務(wù)層：DWS（Data WareHouse Servce）

又稱數(shù)據(jù)集市或?qū)挶?。按照業(yè)務(wù)劃分，如流量、訂單、用戶等，生成字段比較多的寬表，用于提供后續(xù) 的業(yè)務(wù)查詢，OLAP分析，數(shù)據(jù)分發(fā)等。 一般來講，該層的數(shù)據(jù)表會相對比較少，一張表會涵蓋比較多的業(yè)務(wù)內(nèi)容，由于其字段較多，因此一般 也會稱該層的表為寬表。 在實際計算中，如果直接從DWD或者ODS計算出寬表的統(tǒng)計指標(biāo)，會存在計算量太大并且維度太少的問 題，因此一般的做法是，在DWM層先計算出多個小的中間表，然后再拼接成一張DWS的寬表。由于寬和窄的界限不易界定，也可以去掉DWM這一層，只留DWS層，將所有的數(shù)據(jù)在放在DWS亦可。 3、數(shù)據(jù)應(yīng)用層：APP（Application） 在這里，主要是提供給數(shù)據(jù)產(chǎn)品和數(shù)據(jù)分析使用的數(shù)據(jù)，一般會存放在 ES、PostgreSql、Redis等系統(tǒng)中供線上系統(tǒng)使用，也可能會存在 Hive 或者 Druid 中供數(shù)據(jù)分析和數(shù)據(jù)挖掘使用。比如我們經(jīng)常說的報表數(shù)據(jù)，一般就放在這里。

20. 簡述數(shù)據(jù)倉庫與（傳統(tǒng)）數(shù)據(jù)庫的區(qū)別 ？

數(shù)據(jù)庫：傳統(tǒng)的關(guān)系型數(shù)據(jù)庫的主要應(yīng)用，主要是基本的、日常的事務(wù)處理，例如銀行交易。 數(shù)據(jù)倉庫：數(shù)據(jù)倉庫系統(tǒng)的主要應(yīng)用主要是OLAP（On-Line Analytical Processing），支持復(fù)雜的分析操作，側(cè)重決策支持，并且提供直觀易懂的查詢結(jié)果。 業(yè)務(wù)數(shù)據(jù)庫中的數(shù)據(jù)結(jié)構(gòu)是為了完成交易而設(shè)計的，不是為了而查詢和分析的便利設(shè)計的。 業(yè)務(wù)數(shù)據(jù)庫大多是讀寫優(yōu)化的，即又要讀（查看商品信息），也要寫（產(chǎn)生訂單，完成支付）。因 此對于大量數(shù)據(jù)的讀（查詢指標(biāo)，一般是復(fù)雜的只讀類型查詢）是支持不足的。 而怎么解決這個問題，此時我們就需要建立一個數(shù)據(jù)倉庫了，公司也算開始進入信息化階段了。數(shù)據(jù)倉 庫的作用在于： 數(shù)據(jù)結(jié)構(gòu)為了分析和查詢的便利； 只讀優(yōu)化的數(shù)據(jù)庫，即不需要它寫入速度多么快，只要做大量數(shù)據(jù)的復(fù)雜查詢的速度足夠快就行 了。 那么在這里前一種業(yè)務(wù)數(shù)據(jù)庫（讀寫都優(yōu)化）的是業(yè)務(wù)性數(shù)據(jù)庫，后一種是分析性數(shù)據(jù)庫，即數(shù)據(jù)倉 庫。 數(shù)據(jù)庫與數(shù)據(jù)倉庫的區(qū)別實際講的是OLTP與OLAP的區(qū)別： 操作型處理，叫聯(lián)機事務(wù)處理OLTP（On-Line Transaction Processing），也可以稱面向交易的處理系統(tǒng)，它是針對具體業(yè)務(wù)在數(shù)據(jù)庫聯(lián)機的日常操作，通常對少數(shù)記錄進行查詢、修改。用戶較為關(guān) 心操作的響應(yīng)時間、數(shù)據(jù)的安全性、完整性和并發(fā)的支持用戶數(shù)等問題。傳統(tǒng)的數(shù)據(jù)庫系統(tǒng)作為數(shù) 據(jù)管理的主要手段，主要用于操作型處理。 分析型處理，叫聯(lián)機分析處理OLAP（On-Line Analytical Processing）一般針對某些主題歷史數(shù)據(jù)進行分析，支持管理決策。

OLTP與OLAP的異同如下表所示：

操作型處理 分析型處理 細節(jié)的 綜合的或提煉的 實體-關(guān)系（ER）模型 星型或雪花模型 存取瞬間數(shù)據(jù) 存儲歷史數(shù)據(jù)，不包含最近的數(shù)據(jù) 可更新的 只讀，只追加 一次操作一個單元 一次操作一個集合 性能要求高，響應(yīng)時間短 性能要求寬松 面向事務(wù) 面向分析 一次操作數(shù)據(jù)量小 一次操作數(shù)據(jù)量大 支持日常操作 支持決策需求 數(shù)據(jù)量小 數(shù)據(jù)量大 客戶訂單、庫存水平和銀行賬戶等 客戶收益分析、市場細分等

21. 簡述數(shù)據(jù)質(zhì)量是怎么保證的，有哪些方法保證 ？

1）從技術(shù)層面來說，需要構(gòu)建一套高效、健壯的ETL程序，以此保證數(shù)據(jù)清洗、轉(zhuǎn)換后數(shù)據(jù)的正確性和 一致性。 2）從流程上來說，整個ETL是多個任務(wù)，按步驟順序執(zhí)行的一個過程，后置任務(wù)依賴前置任務(wù)，定期執(zhí) 行，整個流程需要自動化，并且哪個環(huán)節(jié)出現(xiàn)了問題，給予預(yù)警，通知相關(guān)維護人員及時處理。 3）從管理層面上來說，數(shù)據(jù)倉庫是構(gòu)建在公司各個業(yè)務(wù)系統(tǒng)之上，它是一面鏡子，很多時候它能反映 出業(yè)務(wù)系統(tǒng)的問題，所以需要管理層的支持和約束，比如通過第一條說的事后自動檢驗機制反映出業(yè)務(wù) 系統(tǒng)的維護錯誤，需要相應(yīng)的業(yè)務(wù)系統(tǒng)維護人員及時處理。

數(shù)據(jù)治理流程如下： 基本流程如下：發(fā)現(xiàn)數(shù)據(jù)質(zhì)量問題 > 定義數(shù)據(jù)質(zhì)量規(guī)則 > 質(zhì)量控制 > 質(zhì)量評估 > 質(zhì)量優(yōu)化。

擴展內(nèi)容： 這里主要是阿里對數(shù)倉的一些數(shù)據(jù)質(zhì)量保證原則 1、數(shù)據(jù)質(zhì)量保障原則 阿里對數(shù)據(jù)倉庫主要從四個方面評估數(shù)據(jù)質(zhì)量 1）完整性 確保數(shù)據(jù)不存在缺失 2）準(zhǔn)確性 確保數(shù)據(jù)不存在異常或錯誤 3）一致性 體現(xiàn)在從業(yè)務(wù)倉庫加工到數(shù)據(jù)倉庫，再到各個消費節(jié)點，必須是同一種類型，長度也需要保持一致。 4）及時性 確保數(shù)據(jù)能及時產(chǎn)出，越來越多的應(yīng)用希望數(shù)據(jù)更快產(chǎn)出。

2、數(shù)據(jù)質(zhì)量方法概述 阿里的業(yè)務(wù)復(fù)雜，種類繁多的產(chǎn)品每天產(chǎn)生數(shù)以億計的數(shù)據(jù)，每天的數(shù)據(jù)量在PB級以上，而數(shù)據(jù)消費端 的應(yīng)用又層出不窮，各類數(shù)據(jù)產(chǎn)品如雨后春筍般出現(xiàn)。為了滿足這些數(shù)據(jù)應(yīng)用，數(shù)據(jù)倉庫的規(guī)模也不斷 膨脹，同時數(shù)據(jù)質(zhì)量的保障也越來越復(fù)雜。 基于上述背景，提出一套數(shù)據(jù)質(zhì)量建設(shè)方法 1）消費場景知曉 主要是通過數(shù)據(jù)資產(chǎn)和基于元數(shù)據(jù)的應(yīng)用鏈路分析解決消費場景知曉的問題。 2）數(shù)據(jù)生成加工各個環(huán)節(jié)卡點效驗 在各個數(shù)據(jù)生成環(huán)節(jié)，格局不同資產(chǎn)等級做出相應(yīng)的處理。 3）風(fēng)險點監(jiān)控在線數(shù)據(jù) 主要是針對在線系統(tǒng)日常運行產(chǎn)出的數(shù)據(jù)進行業(yè)務(wù)規(guī)則的效驗，以保證數(shù)據(jù)質(zhì)量，其主要使用實時 業(yè)務(wù)檢測平臺BCP（Biz-Check-Platform）。 離線數(shù)據(jù)主要是針對離線系統(tǒng)日常運行產(chǎn)出的數(shù)據(jù)進行數(shù)據(jù)質(zhì)量監(jiān)控和實效性監(jiān)控，其中數(shù)據(jù)質(zhì)量監(jiān)控主要 是使用DQC，實效性監(jiān)控主要是使用摩薩德。 4）質(zhì)量衡量 對質(zhì)量的衡量既有事前的衡量，如DQC覆蓋率；又有事后的衡量，主要用于跟進質(zhì)量問題，確定質(zhì)量問 題原因、責(zé)任人、解決情況等，并用于數(shù)據(jù)質(zhì)量的復(fù)盤，避免類似事件再次發(fā)生。根據(jù)質(zhì)量問題對不同 等級資產(chǎn)的影響程度，確定其是屬于低影響的事件還是具有較大影響的故障。質(zhì)量分則是綜合事前和事 后的衡量數(shù)據(jù)進行打分。 5）質(zhì)量配套工具 針對數(shù)據(jù)質(zhì)量的各個方面，都需要相關(guān)的工具進行保證，提高效率。 3、消費場景知曉 在數(shù)據(jù)快速增長，數(shù)據(jù)類產(chǎn)品和日常決策支持等系統(tǒng)層出不窮，數(shù)據(jù)倉庫應(yīng)接不暇，數(shù)據(jù)工程師很難確 定幾百PB的數(shù)據(jù)到底是否都是重要的，是否都要進行保障，是否有一些數(shù)據(jù)已經(jīng)過期了，是否所有需要 精確的進行保障。 基于上述疑問，阿里內(nèi)部提出數(shù)據(jù)資產(chǎn)等級，解決消費場景知曉問題。 1）數(shù)據(jù)等級定義毀滅性質(zhì) 即數(shù)據(jù)一旦出錯，將會引起重大資產(chǎn)損失，導(dǎo)致收益大損。記為A1（Asset） 全局性質(zhì) 即數(shù)據(jù)直接或者間接用于集團級業(yè)務(wù)和效果的評估、重要平臺的運維、對外數(shù)據(jù)產(chǎn)品的透露、影響 用戶在阿里系網(wǎng)站的行為。記為A2 局部性質(zhì) 即數(shù)據(jù)直接或間接用于內(nèi)部一般數(shù)據(jù)產(chǎn)品或者運營/產(chǎn)品報告，如果出現(xiàn)問題會給事業(yè)部或業(yè)務(wù)線 造成影響或者工作效率降低。記為A3 一般性質(zhì) 即數(shù)據(jù)主要用于小二的日常數(shù)據(jù)分析，出現(xiàn)問題不會帶來太大的影響。記為A4 未知性質(zhì) 不能明確說出數(shù)據(jù)的應(yīng)用場景，則標(biāo)注為未知。記為A5 2）數(shù)據(jù)資產(chǎn)等級落地 先給不同數(shù)據(jù)產(chǎn)品或應(yīng)用劃分?jǐn)?shù)據(jù)資產(chǎn)等級，再依托元數(shù)據(jù)的上下游血緣，可以將整個加工消費鏈打上 該數(shù)據(jù)資產(chǎn)等級。 總結(jié)：解決了消費場景知曉的問題，就知道了數(shù)據(jù)的重要等級，針對不同的等級，也將采取不同的保障 措施。 4、數(shù)據(jù)加工過程卡點校驗 1）在線系統(tǒng)卡點效驗 主要是指在線系統(tǒng) 的數(shù)據(jù)生成過程中進行的卡點效驗。要向數(shù)據(jù)保障數(shù)據(jù)準(zhǔn)確性，主要使用工具。 發(fā)布平臺 在業(yè)務(wù)進行重大變更時，訂閱這個發(fā)布過程，然后給到離線開發(fā)人員。當(dāng)然不會頻繁通知離 線開發(fā)人員，會根據(jù)數(shù)據(jù)資產(chǎn)等級通知相應(yīng)人員 數(shù)據(jù)庫表的變化感知 數(shù)據(jù)庫擴容對表的DDL變化，都需要主動通知離線開發(fā)人員。有了開發(fā)工具，開發(fā)人員更重要 須知哪些是重要的核心數(shù)據(jù)資產(chǎn)須知哪些只是內(nèi)部分析數(shù)據(jù)使用

2）離線系統(tǒng)卡點效驗 首先，代碼提交時的卡點效驗 由于開發(fā)人員素質(zhì)不同，代碼能力也有差異，所以需要工具代碼掃描SQL SCAN，對每次提交代碼進行掃描，將風(fēng)險點提出來。 其次，是任務(wù)發(fā)布上線時卡點效驗 發(fā)布上線前測試，代碼評審和回歸測試 回歸測試：指修改了舊代碼后，重新進行測試以確認(rèn)修改沒引入新的錯誤。冒煙測試：指開發(fā)人員修復(fù)一個bug，測試人員專門針對這個問題測試。 發(fā)布上線后測試：Dry-Run測試或真實環(huán)境運行測試。 Dry-Run：不執(zhí)行代碼，僅運行執(zhí)行計劃，避免由于上線下環(huán)境不一致導(dǎo)致語法錯誤。 最后是節(jié)點變更或數(shù)據(jù)重刷前的變更通知 一般指使用通知中心將變更原因、變更邏輯、變更測試報告和變更時間等自動通知下游，下游對此 次變更沒有異議后，再按約定時間執(zhí)行發(fā)布變更，將變更對下游影響降至最低。

5、風(fēng)險點監(jiān)控 主要是針對數(shù)據(jù)在日常運行過程中容易出現(xiàn)的風(fēng)險進行監(jiān)控并設(shè)置報警機制 1）在線數(shù)據(jù)風(fēng)險點監(jiān)控 采用實時業(yè)務(wù)檢測平臺BCP保障重要數(shù)據(jù)資產(chǎn)的質(zhì)量。BCP：制定效驗規(guī)則用于驗證數(shù)據(jù)的準(zhǔn)確性 2）離線數(shù)據(jù)風(fēng)險監(jiān)控 數(shù)據(jù)準(zhǔn)確性 使用DQC來監(jiān)控數(shù)據(jù)數(shù)據(jù)及時性 需要進行一系列的報警和優(yōu)先級設(shè)置，使得重要的任務(wù)優(yōu)先且正確產(chǎn)出。使用的工具有摩薩德。

6、質(zhì)量衡量 評估各種數(shù)據(jù)倉庫質(zhì)量保障方案，有以下指標(biāo)： 1）數(shù)據(jù)質(zhì)量起夜率，及夜晚處理數(shù)據(jù)問題 2）數(shù)據(jù)質(zhì)量事件 3）數(shù)據(jù)質(zhì)量故障體系：指的是嚴(yán)重的數(shù)據(jù)質(zhì)量事件處理方案： 故障定義

故障等級故障處理故障REview

22. 簡述怎么衡量數(shù)倉的數(shù)據(jù)質(zhì)量，有哪些指標(biāo) ？

1）數(shù)據(jù)的準(zhǔn)確性 數(shù)據(jù)準(zhǔn)確性（Accuracy）是指數(shù)據(jù)采集值或者觀測值和真實值之間的接近程度，也叫做誤差值，誤差越 大，準(zhǔn)確度越低。 指數(shù)據(jù)中記錄的信息和數(shù)據(jù)是否準(zhǔn)確，數(shù)據(jù)記錄的信息是否存在異常或錯誤。準(zhǔn)確性關(guān)注的是數(shù)據(jù)記錄 中存在的錯誤，如字符型數(shù)據(jù)的亂碼現(xiàn)象就存在著準(zhǔn)確性的問題，還有就是異常的數(shù)值：異常大或者異 常小的數(shù)值、不符合有效性要求的數(shù)值等。

2）數(shù)據(jù)的精確性 數(shù)據(jù)的精確性（Precision）是指對同一對象的觀測數(shù)據(jù)在重復(fù)測量時所得到不同數(shù)據(jù)間的接近程度。精 確性，也可以叫精準(zhǔn)性。精確性與我們數(shù)據(jù)采集的精度有關(guān)系。精度高，要求數(shù)據(jù)采集的粒度越細，誤 差的容忍程度越低。 比如測量人的身高，我們可以精確到厘米，多次測量差異只會在厘米級別；測量北京到上海的距離，我 們精確到公里，多次測量結(jié)果間的差異會 在公里級別:采用游標(biāo)卡尺測量一個零件的厚度，可以精確到1/50毫米，多次測量的結(jié)果間的誤差也只會 在1/50毫米間。采用的測量方法和手段直接影響著數(shù)據(jù)的精確性。

3）數(shù)據(jù)的真實性 數(shù)據(jù)的真實性，也叫數(shù)據(jù)的正確性(Rightness)。數(shù)據(jù)的正確性取決于數(shù)據(jù)采集過程的可控程度，可控程 度高，可追溯情況好，數(shù)據(jù)的真實性容易得到保障，而可控程度低或者無法追溯，數(shù)據(jù)造假后無法追 溯，則真實性難以保證。為了提高數(shù)據(jù)的真實性，采用無人進行過程干涉的智能終端直接采集數(shù)據(jù)，能 夠更好地保證所采集數(shù)據(jù)的真實性，減少人為干預(yù)，減少數(shù)據(jù)造假，從而讓數(shù)據(jù)更加正確地反應(yīng)客觀事物。

4）數(shù)據(jù)的及時性 數(shù)據(jù)的及時性（In-time）就是指數(shù)據(jù)能否在需要的時候得到保證。 比如月初會對上個月的經(jīng)營和管理數(shù)據(jù)進行統(tǒng)計匯總，這些數(shù)據(jù)能否及時處理完成，財務(wù)能否在月度關(guān) 賬后及時核算。數(shù)據(jù)的及時性是我們數(shù)據(jù)分析和挖掘及時性的保障。如果公司的財務(wù)核算復(fù)雜，核算速 度緩慢，上個月的數(shù)據(jù)在月中才能統(tǒng)計匯總完成，等需要調(diào)整財務(wù)策略的時候，已經(jīng)到了月底了，一個 月已經(jīng)快過完了。特別是公司做大了之后，業(yè)務(wù)覆蓋多個市場，多個國家，數(shù)據(jù)不能及時匯總，會影響 到高層決策的及時程度，數(shù)據(jù)的及時性與企業(yè)數(shù)據(jù)處理的速度和效率有直接的關(guān)系，為了提高數(shù)據(jù)的及 時性，越來越多的公司采用管理信息系統(tǒng)，并在管理信息系統(tǒng)中附加各種自動數(shù)據(jù)外理功能，能夠在數(shù) 據(jù)上傳系統(tǒng)之后自動完成絕大部分報表，從而保證數(shù)據(jù)外理的效率。計算機自動外理中間層數(shù)據(jù)是提高 企業(yè)數(shù)據(jù)處理效率的有效手段。 除了保證數(shù)據(jù)采集的及時性和數(shù)據(jù)外理的效率問題外，還需要從制度和流程上保證數(shù)據(jù)傳輸?shù)募皶r性， 數(shù)據(jù)報表完成了，要及時或者在要求的時間范圍內(nèi)發(fā)送到指定的部門，或者上傳到指定的存儲空間。

5）數(shù)據(jù)的即時性 指數(shù)據(jù)采集時間節(jié)點和數(shù)據(jù)傳輸?shù)臅r間節(jié)點，一個數(shù)據(jù)在數(shù)據(jù)源頭采集后立即存儲，并立即加工呈現(xiàn)， 就是即時數(shù)據(jù)，而經(jīng)過一段時間之后再傳輸?shù)叫畔⑾到y(tǒng)中，則數(shù)據(jù)即時性就稍差。 比如微博的數(shù)據(jù)采集，當(dāng)用戶發(fā)布了微博，數(shù)據(jù)立即能夠被抓取和加工，會生成即時微博數(shù)據(jù)報告，并 隨著時間推移，數(shù)據(jù)不斷變化，我們可以稱作是即時采集和處理的。一個生產(chǎn)設(shè)備的儀表即時反應(yīng)著設(shè) 備的溫度、電壓、電流、氣壓等數(shù)據(jù)，這些數(shù)據(jù)生成數(shù)據(jù)流，隨時監(jiān)控設(shè)備的運行狀況，這個數(shù)據(jù)可以 看作是即時數(shù)據(jù)。而當(dāng)設(shè)備的即時運行數(shù)據(jù)存儲下來，用來分析設(shè)備運行狀況與設(shè)備壽命的關(guān)系，這些 數(shù)據(jù)就成為歷史數(shù)據(jù)。

6）數(shù)據(jù)的完整性 數(shù)據(jù)的完整性是從數(shù)據(jù)采集到的程度來衡量的，是應(yīng)采集和實際采集到數(shù)據(jù)之間的比例。 比如一條信息采集12個數(shù)據(jù)點，如我們采集員工信息數(shù)據(jù)的時候，要求填寫姓名，出生日期，性別，民 族、籍貫，身高、血型、婚姻狀況，最高學(xué)歷，最高學(xué)歷專業(yè)、最高學(xué)歷畢業(yè)院校、最高學(xué)歷畢業(yè)時間 等12項信息，而某一員工僅僅填寫了部分信息，如只填寫了其中的5項，則該員工所填寫數(shù)據(jù)的完整性 只有一半。 一個公司數(shù)據(jù)的完整性體現(xiàn)著這個公司對數(shù)據(jù)的重視程度。要求采集數(shù)據(jù)而實際上并未完整采集，只采 集了一部分，這就是不完整的，往往是公司對數(shù)據(jù)采集質(zhì)量要求不到位導(dǎo)致的。公司要求每個人都填寫 完整的個人信息表，而有部分員工拒絕填寫，公司2000員工，只有1200人填寫了完整的個人信息表，則 這個數(shù)據(jù)集就是不完整的。 另外，對干動態(tài)數(shù)據(jù)，還要從時間軸上去衡量數(shù)據(jù)采集的完整性。比如，我們要求每小時采集一次數(shù) 據(jù)，每天會形成24個數(shù)據(jù)點，記錄為24條數(shù)據(jù)，但是員工瀆職，只記錄了20次，那么這個數(shù)據(jù)集也是不完整的。

7）數(shù)據(jù)的全面性 數(shù)據(jù)的全面性和完整性不同，完整性衡量的是應(yīng)采集和實際采集的差異。而全面性指的是數(shù)據(jù)采集點的 遺漏情況。 比如說，我們要采集員工行為數(shù)據(jù)，我們只采集了員工上班打卡和下班打卡的數(shù)據(jù)，上班時間的員工行 為數(shù)據(jù)并未采集，或者沒有找到合適的方法來采集。那么，這個數(shù)據(jù)集就是不全面的。 比如描述一個產(chǎn)品的包裝，僅僅描述了產(chǎn)品包裝的正面和背面，沒有記錄產(chǎn)品包裝的側(cè)面，則就是不全 面的。我們記錄一個客戶的交易數(shù)據(jù)，我們只采集了客戶訂單中的產(chǎn)品、訂單中產(chǎn)品的價格和數(shù)量，而 沒有采集客戶送貨地址，采購時間，這個數(shù)據(jù)采集就是不全面的。 比如騰訊OO和微信的用戶數(shù)據(jù)記錄了客戶交流溝通的數(shù)據(jù)；阿里和京東的用戶數(shù)據(jù)記錄了用戶的購買 交易數(shù)據(jù)；百度地圖記錄了用戶出行的數(shù)據(jù)；大眾點評和美團記錄了客戶餐飲娛樂的數(shù)據(jù)。對于全面描 述一個人的生活的衣食住行各方面，這些公司的數(shù)據(jù)都是不全面的，而如果把他們的數(shù)據(jù)整合起來，則 會形成更加全面的數(shù)據(jù)。所以說，數(shù)據(jù)的全面性是一個相對的概念。過度追求數(shù)據(jù)的全面性是不現(xiàn)實的。

8）數(shù)據(jù)的關(guān)聯(lián)性 數(shù)據(jù)的關(guān)聯(lián)性是指各個數(shù)據(jù)集之間的關(guān)聯(lián)關(guān)系。 比如員工工資數(shù)據(jù)和工績效考核數(shù)據(jù)是通過員工這個資源關(guān)聯(lián)在一起來的，而且績效數(shù)據(jù)直接關(guān)系到工 資的多少。采購訂單數(shù)據(jù)與生產(chǎn)訂單數(shù)據(jù)之間通過物料的追溯機制進行關(guān)聯(lián)，而生產(chǎn)訂單又是由員工完 成的，即通過員工作業(yè)數(shù)據(jù)與員工信息數(shù)據(jù)關(guān)聯(lián)起來

23. 簡述什么是增量表、全量表和拉鏈表 ？

在數(shù)據(jù)倉庫中，全量表、增量表和拉鏈表是常見的數(shù)據(jù)存儲方式。它們各自具有不同的特點和應(yīng)用場景，下面將詳細介紹這些數(shù)據(jù)存儲方式的概念和優(yōu)缺點。

一、全量表

全量表是指將數(shù)據(jù)源中的數(shù)據(jù)完全加載到數(shù)據(jù)倉庫中，以便進行分析和查詢。全量表的特點是數(shù)據(jù)完整、詳細，任何查詢都可以在全量表上進行。但是，全量表需要占用較大的存儲空間，數(shù)據(jù)加載和更新也需要較長的時間。

全量表的應(yīng)用場景主要是數(shù)據(jù)倉庫的初始建設(shè)階段，或者是對數(shù)據(jù)源數(shù)據(jù)變化不頻繁的情況。全量表適用于一次性查詢和批量處理，例如數(shù)據(jù)分析、報表生成等。

二、增量表

增量表是指只將數(shù)據(jù)源中發(fā)生變化的數(shù)據(jù)加載到數(shù)據(jù)倉庫中，以減少數(shù)據(jù)倉庫的存儲空間和數(shù)據(jù)加載時間。增量表的特點是數(shù)據(jù)更新快速、存儲空間較小，適用于數(shù)據(jù)源數(shù)據(jù)變化頻繁的情況。但是，增量表無法支持一些復(fù)雜的查詢和數(shù)據(jù)分析操作。

增量表的應(yīng)用場景主要是數(shù)據(jù)源數(shù)據(jù)變化頻繁的情況，例如電商、金融等行業(yè)的交易數(shù)據(jù)。增量表適用于實時查詢和實時數(shù)據(jù)分析，可以為業(yè)務(wù)決策提供快速支持。

三、拉鏈表

拉鏈表是指將數(shù)據(jù)源中的歷史數(shù)據(jù)和當(dāng)前數(shù)據(jù)分別存儲在不同的表中，并通過鏈接字段將它們關(guān)聯(lián)起來。拉鏈表的特點是可以在不刪除歷史數(shù)據(jù)的情況下，對當(dāng)前數(shù)據(jù)進行更新和插入操作。拉鏈表適用于需要保留歷史數(shù)據(jù)的情況，例如訂單管理、商品管理等。

拉鏈表的應(yīng)用場景主要是需要保留歷史數(shù)據(jù)的情況，例如訂單管理、商品管理等。拉鏈表適用于需要分析歷史數(shù)據(jù)和當(dāng)前數(shù)據(jù)的場景，例如銷售分析、產(chǎn)品分析等。

在實際應(yīng)用中，根據(jù)不同的業(yè)務(wù)需求和數(shù)據(jù)特點，可以選擇不同的數(shù)據(jù)存儲方式。全量表、增量表和拉鏈表各有其優(yōu)點和缺點，可以根據(jù)實際需求進行選擇和組合使用。

需要注意的是，數(shù)據(jù)倉庫的建設(shè)是一個長期的過程，需要不斷地完善和優(yōu)化。在建設(shè)數(shù)據(jù)倉庫時，需要考慮數(shù)據(jù)的質(zhì)量、安全性和可操作性等方面的問題，以確保數(shù)據(jù)的準(zhǔn)確性和可靠性。同時，也需要定期對數(shù)據(jù)倉庫進行清理和優(yōu)化，以提高數(shù)據(jù)的處理效率和查詢性能。

總之，數(shù)據(jù)倉庫的全量表、增量表和拉鏈表是數(shù)據(jù)存儲的常見方式，各有其優(yōu)點和缺點。在建設(shè)數(shù)據(jù)倉庫時，需要根據(jù)實際需求和數(shù)據(jù)特點選擇合適的數(shù)據(jù)存儲方式，并注意數(shù)據(jù)的質(zhì)量和安全性。同時，也需要不斷地優(yōu)化和改進數(shù)據(jù)倉庫的建設(shè)，以提高數(shù)據(jù)的處理效率和查詢性能。

柚子快報激活碼778899分享：【大數(shù)據(jù)專題】數(shù)據(jù)倉庫

http://yzkb.51969.com/

精彩鏈接