數(shù)倉建模分層理論

分層建設(shè)理論

簡單點(diǎn)兒，直接ODS+DM就可以了，將所有數(shù)據(jù)同步過來，然后直接開發(fā)些應(yīng)用層的報表，這是最簡單的了；當(dāng)DM層的內(nèi)容多了以后，想要重用，就會再拆分一個公共層出來，變成3層架構(gòu),這個過程有點(diǎn)類似代碼重構(gòu)，就是在實(shí)踐中不斷的進(jìn)行抽象、總結(jié)。

數(shù)倉的建?；蛘叻謱?，其實(shí)都是為了更好的去組織、管理、維護(hù)數(shù)據(jù),所以當(dāng)你站在更高的維度去看的話，所有的劃分都是為了更好的管理。小到JVM 內(nèi)存區(qū)域的劃分，JVM 中堆空間的劃分(年輕代、老年代、方法區(qū)等)，大到國家的省市區(qū)的劃分，無一例外的都是為了更好的組織管理。

所以數(shù)倉分層是數(shù)據(jù)倉庫設(shè)計(jì)中十分重要的一個環(huán)節(jié)，優(yōu)秀的分層設(shè)計(jì)能夠讓整個數(shù)據(jù)體系更容易理解和使用。

這一節(jié)，我們主要是從整體上出發(fā)進(jìn)行分析和介紹，就和上一節(jié)數(shù)倉建模方法論一樣，進(jìn)度對比分析，更多細(xì)節(jié)的東西我們后面會單獨(dú)拆分出來，用案例進(jìn)行演示，例如維度建模，維度表的設(shè)計(jì)，事實(shí)表的設(shè)計(jì)、以及如何設(shè)計(jì)標(biāo)簽、如何管理標(biāo)簽等等。

分層的意義

清晰數(shù)據(jù)結(jié)構(gòu)體系

每一個數(shù)據(jù)分層都有它的作用域，這樣在使用表的時候能更方便的定位和理解。

數(shù)據(jù)血緣追蹤

由于最終給業(yè)務(wù)呈現(xiàn)的是一個能直接使用的業(yè)務(wù)表，但是表的數(shù)據(jù)來源有很多，如果有一張來源表出問題了，我們希望能夠快速準(zhǔn)確的定位到問題，并清楚它的影響范圍，從而及時給到業(yè)務(wù)方反饋，從而將損失降到最低。

減少重復(fù)開發(fā)和資源浪費(fèi)

  • 規(guī)范數(shù)據(jù)分層，開發(fā)一些通用的中間層數(shù)據(jù)，能夠減少極大的重復(fù)計(jì)算；
  • 清晰明了的結(jié)構(gòu)使得開發(fā)、維護(hù)的成本降低；
  • 減少重復(fù)計(jì)算和存儲的資源浪費(fèi)；

復(fù)雜問題簡單化

將一個復(fù)雜的任務(wù)分解成多個步驟來完成，每一層只處理單一的步驟，比較簡單和容易理解。而且便于維護(hù)數(shù)據(jù)的準(zhǔn)確性，當(dāng)數(shù)據(jù)出現(xiàn)問題之后，可以不用修復(fù)所有的數(shù)據(jù)，只需要從有問題的步驟開始修復(fù)。

在實(shí)際的建設(shè)過程中，由于業(yè)務(wù)使用數(shù)據(jù)非常緊急以及統(tǒng)一數(shù)倉層建設(shè)跟不上業(yè)務(wù)的需要，所以DIM和ADS層可能直接使用ODS層進(jìn)行快速的業(yè)務(wù)響應(yīng)，但是這種不規(guī)范的操作可能導(dǎo)致數(shù)據(jù)口徑不一致，所以待數(shù)倉建設(shè)完畢，要切換到統(tǒng)一數(shù)倉層和DIM層。

統(tǒng)一數(shù)據(jù)口徑

過數(shù)據(jù)分層提供統(tǒng)一的數(shù)據(jù)出口，統(tǒng)一對外輸出的數(shù)據(jù)口徑，這往往就是我們說的數(shù)據(jù)應(yīng)用層。

關(guān)于分層的一點(diǎn)思考

前面我們說到分層其實(shí)是為了更好更快更準(zhǔn)的組織管理，但是這個是從宏觀上來說的，接下來我們從微觀上也來看一下分層。

越靠上的層次，對應(yīng)用越友好,比如ADS層，基本是完全為應(yīng)用設(shè)計(jì),從數(shù)據(jù)聚合程度來講，越上層的聚合程度越高，當(dāng)然聚合程度越高可理解程度就越低。

數(shù)倉層內(nèi)部的劃分不是為了分層而分層，分層是為了解決 ETL 任務(wù)及工作流的組織、數(shù)據(jù)的流向、讀寫權(quán)限的控制、不同需求的滿足等各類問題，當(dāng)然我們常說的分層也是面向行業(yè)而言的，也是我們常用分層方法，但是你需要注意的是分層僅僅是手段而已。

數(shù)倉的分層

ods 操作數(shù)據(jù)層

ODS 全稱是 OperationalDataStore，操作數(shù)據(jù)層存儲的是面向業(yè)務(wù)系統(tǒng)的數(shù)據(jù)，也是最接近數(shù)據(jù)源中數(shù)據(jù)的一層，數(shù)據(jù)源中的數(shù)據(jù)，經(jīng)過抽取、洗凈、傳輸，也就說傳說中的 ETL 之后，裝入本層。

其實(shí)這里說ETL 有點(diǎn)不合適了，其實(shí)更準(zhǔn)確的是ELT,你可以細(xì)細(xì)品品

本層的數(shù)據(jù)，總體上大多是按照源頭業(yè)務(wù)系統(tǒng)的分類方式而分類的，前面我們說到為什么在數(shù)倉主要用維度建模的情況下，我們依然要學(xué)習(xí)范式建模呢，因?yàn)槲覀兊臄?shù)據(jù)源是范式建模的，所以學(xué)習(xí)范式建?？梢詭椭覀兏玫睦斫鈽I(yè)務(wù)系統(tǒng)，理解業(yè)務(wù)數(shù)據(jù)，所以你可以認(rèn)為我們的ODS 層其實(shí)就是用的實(shí)范式建模。

但是，這一層面的數(shù)據(jù)卻不等同于原始數(shù)據(jù)。在源數(shù)據(jù)裝入這一層時，要進(jìn)行諸如去噪(例如有一條數(shù)據(jù)中人的年齡是300歲，這種屬于異常數(shù)據(jù)，就需要提前做一些處理)、去重(例如在個人資料表中，同一ID卻有兩條重復(fù)數(shù)據(jù)，在接入的時候需要做一步去重)、字段命名規(guī)范等一系列操作。

這里的數(shù)據(jù)處理，并不涉及業(yè)務(wù)邏輯，僅僅是針對數(shù)據(jù)完整性以及重復(fù)值和空值的處理，其實(shí)就是做的是數(shù)據(jù)規(guī)約，數(shù)據(jù)清洗，但是為了考慮后續(xù)可能追溯數(shù)據(jù)源問題，因此對這一層不建議做過多的數(shù)據(jù)清洗工作，原封不動接入源數(shù)據(jù)即可，至于數(shù)據(jù)的去噪，去重，異常值處理等過程可以放在后面的DW層

其實(shí)關(guān)于這一層，很多人的理解不太一樣，那就是是否要進(jìn)行數(shù)據(jù)清洗，其實(shí)還是取決于公司的使用習(xí)慣，其實(shí)有很多公司在這一層之前也會形成一個層，名字千奇百怪，但是它的目的是數(shù)據(jù)緩沖，然后進(jìn)行清洗，清洗之后的數(shù)據(jù)存入ODS ,而這個時候緩沖層數(shù)據(jù)存放一般為一周左右，幾乎不會超過一個月；而ODS則永久存放。

設(shè)計(jì)原則

表名的設(shè)計(jì) ODS_業(yè)務(wù)系統(tǒng)_表名_標(biāo)記，這樣的設(shè)計(jì)可以保持與業(yè)務(wù)表名一致，又可以有清晰的層次，還可以區(qū)分來源。標(biāo)記一般指的是其他數(shù)倉特有的屬性，例如表是天級的還是小時的，是全量的還是增量的。

  • ods 層不做字段名歸一和字段類型統(tǒng)一的操作，如果需要則使用兼容的數(shù)據(jù)類型
  • 對于增量表，需要設(shè)計(jì)增量表(ODS_業(yè)務(wù)系統(tǒng)_表名_delta)和全量表,然后將增量表合并成全量表數(shù)據(jù)；
  • 對于半結(jié)構(gòu)化數(shù)據(jù)需要設(shè)計(jì)解析；
  • 由于業(yè)務(wù)數(shù)據(jù)庫（OLTP）基本按照維度模型建模，因此ODS層中的建模方式也是維度模型；

ods 的設(shè)計(jì)可以保證所有的數(shù)據(jù)按照統(tǒng)一的規(guī)范進(jìn)行存儲。

DW 統(tǒng)一數(shù)倉層

DW是數(shù)據(jù)倉庫的核心，從ODS層中獲得的數(shù)據(jù)按照主題建立各種數(shù)據(jù)模型。DW又細(xì)分?jǐn)?shù)據(jù)明細(xì)層DWD 和輕度匯總層DWS

這一層和維度建模會有比較深的聯(lián)系，業(yè)務(wù)數(shù)據(jù)是按照業(yè)務(wù)流程方便操作的角度來組織數(shù)據(jù)的，而統(tǒng)一數(shù)倉層是按照業(yè)務(wù)易理解的角度或者是業(yè)務(wù)分析的角度進(jìn)行數(shù)據(jù)組織的，定義了一致的指標(biāo)、維度，各業(yè)務(wù)板塊、數(shù)據(jù)域都是按照統(tǒng)一的規(guī)范來建設(shè)，從而形成統(tǒng)一規(guī)范的標(biāo)準(zhǔn)業(yè)務(wù)數(shù)據(jù)體系，它們通常都是基于Kimball的維度建模理論來構(gòu)建的，并通過一致性維度和數(shù)據(jù)總線來保證各個子主題的維度一致性。

如果 ods 層的數(shù)據(jù)就非常規(guī)整，基本能滿足我們絕大部分的需求，這當(dāng)然是好的，這時候dwd層其實(shí)就簡單了很多，但是現(xiàn)實(shí)中接觸的情況是 ods 層的數(shù)據(jù)很難保證質(zhì)量，畢竟數(shù)據(jù)的來源多種多樣，推送方也會有自己的推送邏輯，在這種情況下，我們就需要通過額外的一層 dwd 來屏蔽一些底層的差異。有沒有很像JVM。

設(shè)計(jì)原則

一致性維度規(guī)范

公共層的維度表中相同維度屬性在不同物理表中的字段名稱、數(shù)據(jù)類型、數(shù)據(jù)內(nèi)容必須保持一致，因?yàn)檫@樣可以降低我們在使用過程中犯錯誤的概率，例如使用了不正確的字段，或者因?yàn)閿?shù)據(jù)類型的原因?qū)е铝艘恍┢婀值腻e誤

維度的組合與拆分

將維度所描述業(yè)務(wù)相關(guān)性強(qiáng)的字段在一個物理維表實(shí)現(xiàn)。相關(guān)性強(qiáng)是指經(jīng)常需要一起查詢或進(jìn)行報表展現(xiàn)、兩個維度屬性間是否存在天然的關(guān)系等。例如，商品基本屬性和所屬品牌。

DWD 明細(xì)數(shù)據(jù)層

公告明細(xì)數(shù)據(jù)層，可以說是我們數(shù)倉建設(shè)的核心了。

DWD層要做的就是將數(shù)據(jù)清理、整合、規(guī)范化、臟數(shù)據(jù)、垃圾數(shù)據(jù)、規(guī)范不一致的、狀態(tài)定義不一致的、命名不規(guī)范的數(shù)據(jù)都會被處理。然后加工成面向數(shù)倉的基礎(chǔ)明細(xì)表，這個時候可以加工一些面向分析的大寬表。

DWD層應(yīng)該是覆蓋所有系統(tǒng)的、完整的、干凈的、具有一致性的數(shù)據(jù)層。在DWD層會根據(jù)維度模型，設(shè)計(jì)事實(shí)表和維度表，也就是說DWD層是一個非常規(guī)范的、高質(zhì)量的、可信的數(shù)據(jù)明細(xì)層。

DWS 輕度匯總層

DWS層為公共匯總層，這一層會進(jìn)行輕度匯總，粒度比明細(xì)數(shù)據(jù)稍粗，基于DWD層上的基礎(chǔ)數(shù)據(jù)，整合匯總成分析某一個主題域的服務(wù)數(shù)據(jù)，一般是也是面向分析寬表或者是面向某個注意的匯總表。DWS層應(yīng)覆蓋80%的應(yīng)用場景，這樣我們才能快速響應(yīng)數(shù)據(jù)需求，否則的話，如果很多需求都要從ods開始做的話，那說明我們的數(shù)倉建設(shè)是不完善的。

例如按照業(yè)務(wù)劃分，例如流量，訂單，用戶等，生成字段比較多的寬表，用于后續(xù)的業(yè)務(wù)查詢，OLAP分析，數(shù)據(jù)分析等。

一般采用維度模型方法作為理論基礎(chǔ)，更多的采用一些維度退化手法，將維度退化至事實(shí)表中，減少維度表與事實(shí)表的關(guān)聯(lián)，提高明細(xì)數(shù)據(jù)表的易用性；同時在匯總數(shù)據(jù)層要加強(qiáng)指標(biāo)的維度退化，采用更多的寬表化手段構(gòu)建公共指標(biāo)數(shù)據(jù)層，提升公共指標(biāo)的復(fù)用性，減少重復(fù)加工。

DIM 維度層

維表層，所以其實(shí)維度層就是大量維表構(gòu)成的，為了統(tǒng)一管理這些維度表，所以我們就建設(shè)維度層，維度表本身也有很多類型，例如穩(wěn)定維度維表，漸變維度維表。

維度指的是觀察事物的角度，提供某一業(yè)務(wù)過程事件涉及用什么過濾和分類的描述屬性，"誰、什么時候、什么地點(diǎn)、為什么、如何"干了什么，維度表示維度建模的基礎(chǔ)和靈魂。

比如，"小王早上在小賣部花費(fèi)5元錢購買了包子"，時間維度——早上，地點(diǎn)維度——小賣部，商品維度——包子 那么事實(shí)表呢？

所以可以看出，維度表包含了業(yè)務(wù)過程記錄的業(yè)務(wù)過程度量的上下文和環(huán)境。維度表都包含單一的主鍵列，維度表設(shè)計(jì)的核心是確定維度字段，維度字段是查詢約束條件(where)、分組條件(group)、排序(order)，與報表標(biāo)簽的基本來源。

維度表一般為單一主鍵，在ER模型中，實(shí)體為客觀存在的事務(wù)，會帶有自己的描述性屬性，屬性一般為文本性、描述性的，這些描述被稱為維度。維度建模的核心是數(shù)據(jù)可以抽象為事實(shí)和維度，維度即觀察事物的角度，事實(shí)某一粒度下的度量詞，維度一定是針對實(shí)體而言的。

每個維度表都包含單一的主鍵列。維度表的主鍵可以作為與之關(guān)聯(lián)的任何事實(shí)表的外鍵，當(dāng)然，維度表行的描述環(huán)境應(yīng)與事實(shí)表行完全對應(yīng)。 維度表通常比較寬，是扁平型非規(guī)范表，包含大量的低粒度的文本屬性。例如customer（客戶表）、goods(商品表)、d_time(時間表)這些都屬于維度表，這些表都有一個唯一的主鍵，然后在表中存放了詳細(xì)的數(shù)據(jù)信息。

設(shè)計(jì)原則

維度表通常比較寬，包含多個屬性、是扁平的規(guī)范表，實(shí)際應(yīng)用中包含幾十個或者上百個屬性的維度并不少見，所以維度表應(yīng)該包括一些有意義的描述，方便下游使用。

維度表的維度屬性，應(yīng)該盡可能的豐富，所以維度表中，經(jīng)常出現(xiàn)一些反范式的設(shè)計(jì)，把其他維度屬性并到主維度屬性中，達(dá)到易用少關(guān)聯(lián)的效果。

維度表的設(shè)計(jì)包括維度選擇，主維表的確定，梳理關(guān)聯(lián)維度，定義維度屬性的過程。

維度的選擇一般從報表需求和從業(yè)務(wù)人員的交談中發(fā)現(xiàn)，主要用于過濾、分組、排序，主維度表一般從業(yè)務(wù)庫直接同步，比如用戶表，但是數(shù)倉的本身也會有自己的維度，這是因?yàn)閿?shù)倉是面向分析的，所以會有很多從分析的角度出發(fā)的維度。

關(guān)聯(lián)維度主要是不同業(yè)務(wù)系統(tǒng)或者同一業(yè)務(wù)系統(tǒng)的表之間存在關(guān)聯(lián)性(范式建模)，根據(jù)對業(yè)務(wù)表的梳理，確定哪些表和主維度表之間存在關(guān)聯(lián)關(guān)系，并選擇其中的某些表用于生成維度屬性。

TDM 標(biāo)簽數(shù)據(jù)層

隨著互聯(lián)網(wǎng)的普及，獲客成本越來越高，這也使得公司對用戶運(yùn)營提出了更高的要求，不僅需要精細(xì)化更需要個性化。解決這一問題的辦法之一就是建立相對完備的標(biāo)簽系統(tǒng)，而數(shù)倉的標(biāo)簽層對于標(biāo)簽系統(tǒng)而言就像數(shù)據(jù)倉庫對于數(shù)據(jù)系統(tǒng)一樣，有著舉足輕重的地位，這樣的標(biāo)簽系統(tǒng)需要與業(yè)務(wù)進(jìn)行緊密結(jié)合，從業(yè)務(wù)中獲取養(yǎng)分—用戶標(biāo)簽，同時也要服務(wù)于業(yè)務(wù)—給用戶提供更加精準(zhǔn)和個性的服務(wù)。

底層的標(biāo)簽系統(tǒng)就像一個索引，層層展示大千世界，而用戶就從這大千世界中不斷選擇一些東西表明自己的身份和喜好，也不斷反哺，使得這個大千世界更加豐富多彩。其實(shí)到最后用戶就是一些標(biāo)簽的集合。

對跨業(yè)務(wù)板塊、跨數(shù)據(jù)域的特定對象進(jìn)行數(shù)據(jù)整合，通過統(tǒng)一的ID-Mapping 把各個業(yè)務(wù)板塊，各個業(yè)務(wù)過程中同一對象的數(shù)據(jù)打通，形成對象的全域數(shù)據(jù)標(biāo)簽體系，方便深度分析、挖掘、應(yīng)用。ID-Mapping 可以認(rèn)為是通過對象的標(biāo)識對不同數(shù)據(jù)體系下相同對象進(jìn)行關(guān)聯(lián)和識別。 對象的標(biāo)識可以標(biāo)識一個對象，一般是對象的ID,比如手機(jī)號，身份證，登錄賬號

一個自然人他有身份證號碼進(jìn)行唯一標(biāo)識，但是在醫(yī)保的時候他使用的實(shí)醫(yī)保賬號，繳納水電費(fèi)的時候又是不同的賬號，使用手機(jī)的時候又是設(shè)備賬號，上網(wǎng)的時候是網(wǎng)商賬號。在確認(rèn)對象后，由于同一對象在不同的業(yè)務(wù)體系中的對象標(biāo)識是不一樣的，因此需要將同一對象上的不同ID 標(biāo)識打通，以便所有的業(yè)務(wù)數(shù)據(jù)都能夠在該對象上打通。這就是ID-Mapping。

完成對象的ID 打通需要給對象設(shè)置一個超級ID,需要根據(jù)對象當(dāng)前業(yè)務(wù)體系的ID和獲取得到或者計(jì)算得到超級ID,進(jìn)而完成所有業(yè)務(wù)標(biāo)識的ID打通一般來說ID打通是建設(shè)標(biāo)簽體系的前提，如果沒有ID打通就無法收集到一個對象的全面信息，也就無法對這個對象進(jìn)行全面的標(biāo)簽刻畫。

傳統(tǒng)的計(jì)算方法要有 ID-ID之間的兩兩關(guān)系，例如郵箱和手機(jī)號可以打通，手機(jī)號和身份證號可以打通，那么郵箱就和身份證號可以打通，但是當(dāng)數(shù)據(jù)量非常大，且業(yè)務(wù)板塊非常多的時候，例如有上一個對象，每個對象有數(shù)十種ID,這個時候打通就需要非常漫長的計(jì)算

那么什么是標(biāo)簽?zāi)兀迷紨?shù)據(jù)，通過一定的邏輯加工產(chǎn)出直接能被業(yè)務(wù)所直接使用的、可閱讀的，有價值的數(shù)據(jù)。標(biāo)簽類目，是標(biāo)簽的分類組織方式，是標(biāo)簽信息的一種結(jié)構(gòu)化描述，目的是管理、查找，一般采用多級類目，一般當(dāng)一個對象的標(biāo)簽個數(shù)超過50個的時候，業(yè)務(wù)人員查找標(biāo)簽就會變得非常麻煩，這個時候我們往往會通過標(biāo)簽類目進(jìn)行組織管理

標(biāo)簽的分類

標(biāo)簽按照產(chǎn)生和計(jì)算方式的不同可分為屬性標(biāo)簽，統(tǒng)計(jì)標(biāo)簽，算法標(biāo)簽，關(guān)聯(lián)標(biāo)簽。

屬性標(biāo)簽

對象本身的性質(zhì)就是屬性標(biāo)簽，例如用戶畫像的時候打到用戶身上的標(biāo)簽。

統(tǒng)計(jì)標(biāo)簽

對象在業(yè)務(wù)過程中產(chǎn)生的原子指標(biāo)，通過不同的計(jì)算方法可以生成統(tǒng)計(jì)標(biāo)簽。

算法標(biāo)簽

對象在多個業(yè)務(wù)過程中的特征規(guī)律通過一定的算法產(chǎn)出的標(biāo)簽。

關(guān)聯(lián)標(biāo)簽

對象在特定的業(yè)務(wù)過程會和其他對象關(guān)聯(lián)，關(guān)聯(lián)對象的標(biāo)簽也可以打在主對象上。

設(shè)計(jì)原則

我們的標(biāo)簽一定是針對用戶的，而不是一些虛假、高大上、無用的標(biāo)簽，一定要真實(shí)反映用戶行為喜好的，所以我們不能只依賴人工智能算法的分析，來完成對一個用戶標(biāo)簽的建立與定期維護(hù)，我們需要走出去和用戶交互，引導(dǎo)用戶使用，要抓住用戶痛點(diǎn)，及時獲取用戶反饋，形成閉環(huán)。

如何引導(dǎo)使用呢？這個方式有很多我們就不再這里介紹了，后面我們會專門介紹這一層的建設(shè)細(xì)節(jié)。

ADS 層

數(shù)據(jù)應(yīng)用層ApplicationDataService面向業(yè)務(wù)定制的應(yīng)用數(shù)據(jù)，主要提供給數(shù)據(jù)產(chǎn)品和數(shù)據(jù)分析使用的數(shù)據(jù)，一般會放在ES，MYSQL，Redis等系統(tǒng)供線上系統(tǒng)使用，也可以放在Hive中供數(shù)據(jù)分析和數(shù)據(jù)挖掘使用，或者使用一下其他的大數(shù)據(jù)工具進(jìn)行存儲和使用。

數(shù)倉層，DIM 層，TDM 層是相對穩(wěn)定的，所以無法滿足靈活多變業(yè)務(wù)需求，所以這和數(shù)倉層的規(guī)范和劃分相矛盾，所以我們在此基礎(chǔ)上建立了另外一個層，這就是ADS 層，解決了規(guī)劃穩(wěn)定和靈活多變之間的矛盾。其實(shí)到這里你也就慢慢的看明白了，分層和分類其實(shí)沒多大差別，其實(shí)就是相似的放在一起，有點(diǎn)代碼重構(gòu)的意味啊。

數(shù)據(jù)應(yīng)用層，按照業(yè)務(wù)的需要，然后從統(tǒng)一數(shù)倉層和DIM進(jìn)行取數(shù)，并面向業(yè)務(wù)的特殊需求對數(shù)據(jù)進(jìn)行加工,以滿足業(yè)務(wù)和性能的需求。ADS 層因?yàn)槊嫦虻膶?shí)眾多的需求，所以這一層沒有太多的規(guī)范，只需要按照命名規(guī)范來進(jìn)行就可以了。

設(shè)計(jì)原則

前面也說了，ADS 層因?yàn)槊嫦虻膶?shí)眾多的需求，所以這一層沒有太多的規(guī)范，但是ADS 層的建設(shè)是強(qiáng)業(yè)務(wù)推動的，業(yè)務(wù)部門需要參與到ADS 的建設(shè)中來，至少我們得了解用戶的痛點(diǎn)才能對癥施藥啊。

實(shí)現(xiàn)流程

理清需求，了解業(yè)務(wù)方對數(shù)據(jù)內(nèi)容、使用方式(怎么交互的，報表、接口、即席查詢、在線查詢、指標(biāo)查詢、搜索)、性能的要求。

盤點(diǎn)現(xiàn)有的數(shù)倉表是否可以支持，看以前有沒有類似的需求，有沒有可以復(fù)用的接口、報表什么的。

代碼實(shí)現(xiàn)，選擇合適的存儲引擎和查詢引擎，配置線上監(jiān)控然后交付。

使用場景與性能
  • 針對業(yè)務(wù)方的使用場景，我們需要設(shè)計(jì)出高效，滿足要求的ADS 層表
  • 如果是多維分析，為了減少連接，提升性能，我們一般采用大寬表設(shè)計(jì)，使用高性能引擎支撐
  • 如果是特定指標(biāo)查詢，一般采用KV的形式組織
  • 如果是搜索場景，一般采用搜索引擎

DM 數(shù)據(jù)集市層

主要是提供數(shù)據(jù)產(chǎn)品和數(shù)據(jù)分析的數(shù)據(jù)，一般會存放在ES、Mysql、也可能直接存儲在hive中或者druid供數(shù)據(jù)分析和數(shù)據(jù)挖掘使用。主要解決部門用戶報表和分析需求而建立數(shù)據(jù)庫，數(shù)據(jù)集市就代表數(shù)據(jù)倉庫的主題域。

DM 是面向單個主題的，所以它不會從全局考慮進(jìn)行建設(shè)，只專注于自己的數(shù)據(jù)、往往是某個業(yè)務(wù)線，例如流量主題、社交主題、電商主題等等。





作者：柯廣的網(wǎng)絡(luò)日志

微信公眾號：Java大數(shù)據(jù)與數(shù)據(jù)倉庫