chinesefreesexvideos高潮,欧美极品少妇性运交,久久久国产一区二区三区,99久久婷婷国产综合精品,成人国产一区二区三区

本文主要圍繞架構(gòu)、分層、建模三個方面，進一步加深對數(shù)倉的了解。

從整體上來看，數(shù)據(jù)倉庫體系架構(gòu)可分為：數(shù)據(jù)采集層、數(shù)據(jù)計算層、數(shù)據(jù)服務(wù)層和數(shù)據(jù)應(yīng)用層，如下圖。

1）數(shù)據(jù)采集層

數(shù)據(jù)采集層的任務(wù)就是把數(shù)據(jù)從各種數(shù)據(jù)源中采集和存儲到數(shù)據(jù)庫上，期間有可能會做一些 ETL（即抽取、轉(zhuǎn)換、裝載）操作。

其中，日志所占份額最大，存儲在備份服務(wù)器上的業(yè)務(wù)數(shù)據(jù)庫中，如 Mysql 中的數(shù)據(jù)。其他數(shù)據(jù)的話，如 Excel 等需要手工錄入的數(shù)據(jù)。

實時采集不是一條一條采集，而是根據(jù)一些限制條件，一般是數(shù)據(jù)大小限制（如 512KB 寫一批）、時間閾值限制（如 30 秒寫一批）。

采集的數(shù)據(jù)需要數(shù)據(jù)采集系統(tǒng)分發(fā)給下游，一般選取 Flume、Sqoop 等。

2）數(shù)據(jù)處理層

從數(shù)據(jù)采集系統(tǒng)出來的數(shù)據(jù)，分發(fā)給下游的數(shù)據(jù)處理平臺，一般有 Hive、MapReduce、Spark Streaming、Storm 以及新興的 Flink 等，阿里巴巴內(nèi)部使用的是 StreamCompute。

3）數(shù)據(jù)服務(wù)層

數(shù)據(jù)服務(wù)層，通過接口服務(wù)化方式對外提供數(shù)據(jù)服務(wù)，以保證更好的性能和體驗。針對不同的需求和數(shù)據(jù)應(yīng)用場景，數(shù)據(jù)服務(wù)層的數(shù)據(jù)源架構(gòu)在不同的數(shù)據(jù)庫上，如 Mysql、HBase、MongoDB 等。實時的存儲且需要支持高并發(fā)的話，就選擇 HBase。

數(shù)據(jù)服務(wù)層可以使應(yīng)用對底層數(shù)據(jù)存儲透明，將海量數(shù)據(jù)方便高效地開放給各業(yè)務(wù)使用。

4）數(shù)據(jù)應(yīng)用層

數(shù)據(jù)已經(jīng)準備好，需要通過合適的應(yīng)用提供給用戶，讓數(shù)據(jù)最大化地發(fā)揮價值。數(shù)據(jù)應(yīng)用表現(xiàn)在各個方面，如報表展示、數(shù)據(jù)分析、數(shù)據(jù)挖掘、數(shù)據(jù)可視化等。

二、數(shù)據(jù)倉庫分層

作為一名數(shù)據(jù)產(chǎn)品經(jīng)理，筆者肯定希望自己的數(shù)據(jù)能夠有秩序地流轉(zhuǎn)，數(shù)據(jù)的整個生命周期能夠清晰明確地被設(shè)計者和使用者感知到。但是，隨著業(yè)務(wù)的發(fā)展，頻繁迭代和跨部門的業(yè)務(wù)變得越來越多。這就容易導(dǎo)致數(shù)據(jù)倉庫出現(xiàn)如下問題：

1）缺乏統(tǒng)一的業(yè)務(wù)和技術(shù)標準，如：開發(fā)規(guī)范、指標口徑不統(tǒng)一。

2）缺乏統(tǒng)一數(shù)據(jù)質(zhì)量監(jiān)控，如：字段數(shù)據(jù)不完整和不準確等。

3）業(yè)務(wù)知識體系散亂，導(dǎo)致數(shù)據(jù)研發(fā)人員開發(fā)成本增加。

4）數(shù)據(jù)架構(gòu)不合理，數(shù)據(jù)層之間分工不明顯，數(shù)據(jù)流向混亂。

5）缺失統(tǒng)一維度和指標管理。

因此，筆者需要一套行之有效的方法來讓自己的數(shù)據(jù)倉庫更有秩序，這就需要對數(shù)據(jù)進行分層，如下圖。

按照數(shù)據(jù)操作的流程，筆者將數(shù)據(jù)模型分為三層：數(shù)據(jù)操作層（ODS）、數(shù)據(jù)倉庫層（DW）和數(shù)據(jù)應(yīng)用層（APP），如下圖。簡單來講，ODS 層存放的是接入的原始數(shù)據(jù)，DW 層存放的是數(shù)據(jù)倉庫中的數(shù)據(jù)，APP 層存放的是面向業(yè)務(wù)定制的應(yīng)用數(shù)據(jù)。

1）數(shù)據(jù)操作層（ODS）

數(shù)據(jù)操作層又叫數(shù)據(jù)運營層，英文：Opertional Data Source。數(shù)據(jù)操作層是最接近數(shù)據(jù)源中數(shù)據(jù)的一層，數(shù)據(jù)源中的數(shù)據(jù)，經(jīng)過 ETL（即抽取、轉(zhuǎn)換、裝載），裝入本層。本層中的數(shù)據(jù)，大多是按照源業(yè)務(wù)系統(tǒng)的分類方式而分類的。

由于該層是最接近數(shù)據(jù)源的，所以不建議對該層數(shù)據(jù)做過多的數(shù)據(jù)清洗工作，原封不動地接入原始數(shù)據(jù)就行，至于數(shù)據(jù)的去噪、去重、去異常值等操作可以放在后面的 DWD 層來做。

2）數(shù)據(jù)倉庫層（DW）

數(shù)據(jù)倉庫層，英文：Data Warehouse，是筆者在設(shè)計數(shù)據(jù)倉庫時要核心設(shè)計的一層。在這里，從 ODS 層獲得的數(shù)據(jù)按照主題建立各種的數(shù)據(jù)模型。DW 層又要細分為 DWD（Data Warehouse Detail）層、DWM（Data Warehouse Middle）層和 DWS（Data Warehouse Service）層，如下圖。

（1）數(shù)據(jù)明細層（DWD）

數(shù)據(jù)明細層，英文：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）

數(shù)據(jù)中間層，英文：Data Warehouse Middle，該層會在 DWD 層的數(shù)據(jù)基礎(chǔ)上，對數(shù)據(jù)做輕度的聚合，生成一系列的中間表，提升公共指標的復(fù)用性，減少重復(fù)加工。直觀來講，就是對通用的核心維度進行聚合操作，算出相應(yīng)的統(tǒng)計指標。

（3）數(shù)據(jù)服務(wù)層（DWS）

數(shù)據(jù)服務(wù)層又叫數(shù)據(jù)集市或?qū)挶?，英文：Data Warehouse Service。按照業(yè)務(wù)劃分，如流量、訂單、用戶等，生成字段比較多的寬表，用于提供后續(xù)的業(yè)務(wù)查詢、OLAP 分析、數(shù)據(jù)分發(fā)等。

一般來講，該層的數(shù)據(jù)表會相對比較少，一張表會涵蓋比較多的業(yè)務(wù)內(nèi)容，由于其字段較多，因此一般也會稱為該層的表為寬表。

在實際計算中，如果直接從 DWD 或者 ODS 計算出寬表的統(tǒng)計指標，會存在計算量太大并且維度太少的問題，因此一般的做法是，在 DWM 層先計算出多個小的中間表，然后再拼接成一張 DWS 的寬表。由于寬和窄的界限不易界定，也可以去掉 DWM 這一層，只留 DWS 層，將所有的數(shù)據(jù)放在 DWS 亦可。

3）數(shù)據(jù)應(yīng)用層（APP）

數(shù)據(jù)應(yīng)用層，英文：Application，該層主要提供給數(shù)據(jù)產(chǎn)品和數(shù)據(jù)分析使用的數(shù)據(jù)。該層的數(shù)據(jù)一般會存放在 Redis、PostgreSql 等共線上系統(tǒng)使用的系統(tǒng)，也可能會存放在 Hive、Druid 中供數(shù)據(jù)分析和數(shù)據(jù)挖掘使用，比如報表數(shù)據(jù)就可以存放在 Hive 中。

4）維度層（DIM）

維度層，英文：Dimension。建立一致數(shù)據(jù)分析維表，可以降低數(shù)據(jù)計算口徑和算法不統(tǒng)一風險。以維度作為建模驅(qū)動，基于每個維度的業(yè)務(wù)含義，通過定義維度及維度主鍵，添加維度屬性、關(guān)聯(lián)維度等定義計算邏輯和雪花模型，完成屬性定義的過程并建立一致的數(shù)據(jù)分析維表。同時筆者可以定義維度主子關(guān)系，子維度的屬性將合并至主維度使用，進一步保證維度的一致性和便捷使用性。

維度層包含兩個部分：

（1）高基數(shù)維度數(shù)據(jù)：一般是用戶資料表、商品資料表類似的資料表，數(shù)據(jù)量可以上千萬甚至上億。

（2）低基數(shù)維度數(shù)據(jù)：一般是配置表，比如枚舉值對應(yīng)的中文含義，或者日期維度表，數(shù)據(jù)量大概在幾千到幾萬之間。

大數(shù)據(jù)的數(shù)據(jù)倉庫建模需要通過建模的方法更好地組織、存儲數(shù)據(jù)，以便在性能、成本、效率和數(shù)據(jù)質(zhì)量之間找到最佳平衡點。具體的建模目標，如下圖。

接下來，就聊聊數(shù)據(jù)倉庫中幾種經(jīng)典的數(shù)據(jù)模型，如關(guān)系建模、維度建模、DataVault模型。在實際工作中，通常會根據(jù)業(yè)務(wù)場景選擇一種或幾種模型。

3.2.1 關(guān)系建模

關(guān)系建模，是數(shù)據(jù)倉庫之父 Inmon 推崇的，被稱為 “實體-關(guān)系” 模型，以一種 “標準化” 的方式存在，強調(diào)數(shù)據(jù)之間非冗余，滿足 3NF 。關(guān)系建模是站在企業(yè)角度面向主題的抽象，而不是針對某個具體業(yè)務(wù)流程的實體對象關(guān)系抽象。它更多用于數(shù)據(jù)的整合和一致性質(zhì)量。

3.2.2 維度建模

維度建模，Ralph Kimball 博士最先提出這一概念。其最簡單的描述就是，按照事實表、維表來構(gòu)建數(shù)據(jù)倉庫、數(shù)據(jù)集市。這種方法很多人稱之為星形模型。之所以稱為星形模型是因為它的表示方法是以一顆 “星” 為中心，周圍圍繞著其他數(shù)據(jù)結(jié)構(gòu)，如下圖。

星形模型的中心是一張事實表。事實表是包含大量數(shù)據(jù)值的一種結(jié)構(gòu)。事實表的周圍是維表，用來描述事實表的某個重要方面。維表里的數(shù)據(jù)量要比事實表里的少。

星形模型之所以廣泛被使用，在于針對各個維作了大量的預(yù)處理，比如按照維進行了預(yù)先的排序、分類、統(tǒng)計等。通過這些預(yù)處理，能夠極大地提升數(shù)據(jù)倉庫的處理能力。特別是針對 3NF 的建模方法，星形模型在性能上占據(jù)明顯的優(yōu)勢。因此，星形模型僅適用于小范圍數(shù)據(jù)（如一個部門或甚至一個子部門）。

通常星形模型只包含一張事實表。但是在數(shù)據(jù)庫設(shè)計中要創(chuàng)建一種雪花結(jié)構(gòu)的復(fù)合結(jié)構(gòu)，需要多張事實表結(jié)合。如下圖，描繪了一個雪花模型。

在雪花模型中，不同的事實表通過共享一個或多個公共維表連接起來。有時稱這些共享的維表為一致維表。

維度建模的最大優(yōu)點在于訪問的高效性。如果設(shè)計適當，通過星形連接將數(shù)據(jù)傳遞給最終用戶是非常高效的。為了提高傳遞信息的效率，必須收集并吸收最終用戶的請求。最終用戶使用數(shù)據(jù)的過程是要定義什么樣的多維結(jié)構(gòu)的核心。一旦清楚了最終用戶的請求，這些請求就可以用來最終確定星形模型，形成最理想的結(jié)構(gòu)。

因此筆者認為，維度建模主要適用于數(shù)據(jù)集市層，它的最大作用其實是為了解決數(shù)據(jù)倉庫建模中的性能問題。維度建模很難提供一個完整地描述真實業(yè)務(wù)實體之間的復(fù)雜關(guān)系的抽象方法。

Data Vault 是另一種數(shù)據(jù)倉庫建模方法，是 Dan Linstedt 在 20 世紀 90 年代提出的，主要用于企業(yè)級的數(shù)據(jù)倉庫建模。

Data Vault 需要跟蹤所有數(shù)據(jù)的來源，因此其中每個數(shù)據(jù)行都要包含數(shù)據(jù)來源和裝載時間屬性，用以審計和跟蹤數(shù)據(jù)值對應(yīng)的源系統(tǒng)。

Data Vault 不區(qū)分數(shù)據(jù)在業(yè)務(wù)層面的正確與錯誤，它保留操作型系統(tǒng)的所有時間的所有數(shù)據(jù)，裝載數(shù)據(jù)時不做數(shù)據(jù)驗證、清洗等工作，這點明顯有別于其他數(shù)據(jù)倉庫建模方法。

Data Vault是對 ER 模型更近一步的規(guī)范化，由于對數(shù)據(jù)的拆解更偏向于基礎(chǔ)數(shù)據(jù)組織，在處理分析類場景時相對復(fù)雜，適合數(shù)據(jù)倉庫底層構(gòu)建，目前實際應(yīng)用場景較少。

1）Data Vault模型定義

Dan Linstedt 將 Data Vault 模型定義為：Data Vault 是面向細節(jié)的，可追蹤歷史的，一組由連接關(guān)系的規(guī)范化的表的集合。這些表可以支持一個或多個業(yè)務(wù)功能。它是一種綜合了第三范式和星型模型特點的建模方法。

Data Vault 只按照業(yè)務(wù)數(shù)據(jù)的原樣保存數(shù)據(jù)，不做任何解釋、過濾、清洗、轉(zhuǎn)換。即使從不同數(shù)據(jù)源來的數(shù)據(jù)是自相矛盾的，比如：同一個客戶有不同的地址，Data Vault 模型會存儲多個不同版本的地址數(shù)據(jù)。

2）Data Vault 模型的特點

（1）所有數(shù)據(jù)都基于時間來存儲，即使數(shù)據(jù)是低質(zhì)量的，也不能在 ETL 過程中處理掉。

（2）與源系統(tǒng)越獨立越好。

（3）可以適應(yīng)源系統(tǒng)中數(shù)據(jù)的各種變化，并可以靈活的實現(xiàn)模型擴展。

（4）數(shù)據(jù)的來源可以完全追蹤，并且數(shù)據(jù)處理作業(yè)可以支持重載。

（5）ETL 作業(yè)可以重復(fù)執(zhí)行。

3）Data Vault 模型組成

Data Vault 模型由中心表（Hub）、鏈接表（Link）、附屬表（Satellite）三個主要組成部分。其中，中心表是核心，用于存儲業(yè)務(wù)主鍵，鏈接表記錄業(yè)務(wù)關(guān)系，附屬表記錄業(yè)務(wù)描述。

（1）中心表

中心表用來存儲企業(yè)每個業(yè)務(wù)實體的業(yè)務(wù)主鍵，業(yè)務(wù)主鍵唯一標識某個業(yè)務(wù)實體。中心表和源系統(tǒng)是相互獨立的，即無論業(yè)務(wù)主鍵是否用于多個業(yè)務(wù)系統(tǒng)，它在 Data Vault 中只保留一份，其他的組件都鏈接到這一個業(yè)務(wù)主鍵上。

出于設(shè)計上的考慮，中心表一般由主鍵、業(yè)務(wù)主鍵、裝載時間戳、數(shù)據(jù)來源系統(tǒng)四個字段組成。其中主鍵是系統(tǒng)生成的代理鍵，僅供內(nèi)部使用。

（2）鏈接表

鏈接表是不同中心表的鏈接。一個鏈接表一般在兩個或多個中心表之間有關(guān)聯(lián)。一個鏈接表通常是一個外鍵，表示一種業(yè)務(wù)關(guān)系，比如：交易表、客戶關(guān)聯(lián)賬戶等。

鏈接表主要包括主鍵、外鍵1、……、外鍵n、裝載時間戳、數(shù)據(jù)來源系統(tǒng)等字段構(gòu)成，其中主鍵對應(yīng)多個外鍵的唯一組合，一般是與業(yè)務(wù)無關(guān)的序列數(shù)值。

（3）附屬表

附屬表用來保存中心表和鏈接表的描述屬性，包含所有歷史變化數(shù)據(jù)，附屬表有且僅有一個唯一外鍵關(guān)聯(lián)到中心表或鏈接表。

附屬表主要包括主鍵、外鍵、屬性1、……、屬性n、裝載時間、失效時間、數(shù)據(jù)來源系統(tǒng)，主鍵用于唯一標識附屬表中的一行記錄，一般是與業(yè)務(wù)無關(guān)的序列數(shù)值。

4）Data Vault 模型設(shè)計

根據(jù) Data Vault 模型體系構(gòu)成，Data Vault 模型設(shè)計由此也分成三大部分。

（1）設(shè)計中心表

明確企業(yè)數(shù)據(jù)倉庫要涵蓋的業(yè)務(wù)范圍。

按業(yè)務(wù)范圍劃分為若干原子業(yè)務(wù)實體，比如客戶、產(chǎn)品、品類等。

從各個業(yè)務(wù)實體中抽象出業(yè)務(wù)主鍵，該業(yè)務(wù)主鍵要在整個業(yè)務(wù)的生命周期內(nèi)不會發(fā)生變化。

由該業(yè)務(wù)主鍵生成中心表。

（2）設(shè)計鏈接表

分析各個中心表代表的業(yè)務(wù)實體之間的業(yè)務(wù)關(guān)系，并識別對應(yīng)的中心表，這些業(yè)務(wù)關(guān)系可以是1對1、1對多，或者多對多的。

按業(yè)務(wù)關(guān)系涉及的中心表，提取中心表主鍵，這些主鍵將被加入到鏈接表中，并確定鏈接表的主鍵。

在生成鏈接表的同時，鏈接表內(nèi)可以保存交易數(shù)據(jù)，有兩種方法，一是采用加權(quán)鏈接表，二是給鏈接表加上附屬表來處理交易數(shù)據(jù)。

（3）設(shè)計附屬表

附屬表包含了各個業(yè)務(wù)實體與業(yè)務(wù)關(guān)聯(lián)的詳細的上下文描述信息。主要是從中心表、鏈接表出發(fā)，提取與中心表、鏈接表相關(guān)的上下文描述信息。

由于同一業(yè)務(wù)實體的各個描述信息不具有穩(wěn)定性，會經(jīng)常發(fā)生變化，因此需要按變化頻率不同的信息分割開來，為一個中心表建立幾個附屬表，然后提取主鍵，作為描述該中心表的附屬表的主鍵。

（4）設(shè)計必要的 PIT 表

為了訪問數(shù)據(jù)的方便，可能就用到 PIT 表，PIT 表不是必須的，但如果一個中心表或者鏈接表有多個附屬表，就有可能用到 PIT 表。PIT 表的主鍵是由附屬表關(guān)聯(lián)的中心表提取出來的，有幾個附屬表就會有幾個字段用于記錄附屬表的變化時間戳。

-END-