數據倉庫是面向主題的敛摘、集成的撑碴、時變的和非易失的有組織的數據集合，支持管理決策制定厕怜。不同于面向OLTP（On-Line Transaction Processing）數據庫建設叠国，數據倉庫為OLAP（On-Line Analytical Processing）而生未檩。
本文著手規(guī)劃cover糖豆全業(yè)務線的數據倉庫建設。先給出糖豆數倉模型粟焊，給出糖豆數倉的理論依據冤狡；再在此基礎上根據糖豆各業(yè)務線的實際需求，給出各個業(yè)務主題的具體數據集市建設模型吆玖。
一筒溃、數據倉庫的分層結構
一般情況下，數據倉庫往往采用三層結構沾乘。底層是數據倉庫服務器，在我們這里就是由hive cover的分布式文件存儲系統(tǒng)浑测。中間層是OLAP服務器翅阵。上層是用戶，包括查詢和報表工具迁央。
聯機分析處理(OLAP)可以在使用多維數據模型的數據倉庫或數據集市上進行掷匠。典型的 OLAP操作包括上卷、下鉆(鉆過岖圈、鉆透)讹语、切片和切塊、轉軸(旋轉)蜂科，以及求等級顽决、計算平均值和增長率等統(tǒng)計操作。使用數據立方體結構导匣，OLAP 操作可以有效地實現才菠。
OLAP服務器可以是關系OLAP(ROLAP)，多維OLAP(MOLAP)贡定，或混合OLAP(HOLAP)赋访。ROLAP服務器使用擴充的關系 DBMS，將多維數據上的 OLAP 操作映射成標準的關系操作。MOLAP 服務器直接將多維數據視圖映射到數組結構蚓耽。HOLAP 是 ROLAP 和 MOLAP 的結合渠牲。例如，它可以對歷史數據使用 ROLAP步悠，而將頻繁訪問的數據放在一個分離的 MOLAP 存儲中嘱兼。
關于這部分內容更多的了解可以參考《數據挖掘概念與技術》中關于數據倉庫的介紹。在本規(guī)劃中著重介紹的是底層——數據倉庫服務器層贤徒，也就是hive數據倉庫的建設芹壕。重點涉及基礎層(ODS)、中間層(EDW)接奈、集市層(ADM)的規(guī)劃建設踢涌。中間層（OLAP服務器層）與頂層（前端可視化層），暫不考慮序宦，將來可能會考慮采用業(yè)界開源/免費的集成解決方案睁壁，如airbnb開源的Superset (之前叫做Caravel / Panoramix)、一直免費的saiku互捌。
hive數據倉庫部分潘明，我們將按傳統(tǒng)數據倉庫分層思想，分為三層：
- ODS(Operation Data Storage)層——操作數據存儲層秕噪，在這里就是原始數據層钳降。主要包括三部分數據，從業(yè)務服務器實時采集的業(yè)務原始日志腌巾、對業(yè)務原始日志解析后結構化的日志寬表遂填、通過sqoop從業(yè)務數據庫導入的業(yè)務數據。這層數據處理原則是不丟失澈蝙，盡量保證數據的原貌吓坚。除了不能解析的異常日志，盡量保證日志條數不丟失灯荧；日志字段不清洗礁击，不care日志字段的具體取值是否合法，只負責字段的結構化存儲逗载。這部分數據需要全量壓縮保存哆窿。這層存儲的是最細粒度的數據。
- EDW(Enterprise Data Warehouse)層——企業(yè)級數據倉庫層撕贞，在這里就是中間基礎數據層更耻。EDW在傳統(tǒng)行業(yè)一般是指整個數倉，甚至包括ODS層捏膨；在大型的集團公司秧均，EDW一般指各獨立業(yè)務線的數倉食侮，如財務數倉，交易數倉目胡，日志數倉锯七。在我們這里，EDW主要是日志數倉明細誉己，也有稱作DWB(DataWare Base)層的眉尸。中間基礎數據層的數據應該是一致的、準確的巨双、干凈的噪猾，它對原始數據層進行了清洗轉換。這層存儲的也是最細粒度的數據筑累，和ODS層相同袱蜡。
- ADM(Aggregative Data Model)層——聚合數據層，在這里就是數據集市層慢宗。數據集市層對EDW層的數據做不同程度的聚合匯總坪蚁，已經不存在明顯數據。這層數據從縱向上講是面向業(yè)務主題來組織的镜沽，用來支撐多維分析敏晤，我們采用星形結構。這層中每張事實表中的一行都是一條用戶操作記錄的聚合缅茉，比如用戶在某個模塊觀看某個視頻的總時長嘴脾。
二、糖豆數倉業(yè)務模型
1宾舅、業(yè)務線梳理
按目前發(fā)展狀況统阿，根據職能梳理的業(yè)務線如下圖所示。其中大部分業(yè)務線需要根據具體業(yè)務需求規(guī)劃數據集市層建設筹我。優(yōu)先挑選重要緊急的業(yè)務線做。
2帆离、業(yè)務主題建模
以推薦業(yè)務為主線舉例：
推薦目前的產品形態(tài)為【猜你喜歡】（包括離線/準實時/實時）與【相關推薦】蔬蕊。推薦業(yè)務目前最重要的數據需求之一就是效果對比評估。
所以對于推薦業(yè)務主題域哥谷，主要的事實表就是用戶在推薦產品模塊內的操作數據岸夯，包括用戶的瀏覽，點擊播放们妥，后續(xù)的關注猜扮、評論等。
在業(yè)務建模階段监婶，我們傾向于使用實體建模法旅赢，實體建某萏遥可以很輕松的完成對現實世界的抽象，把整個業(yè)務劃分成一個個的實體煮盼，而每個實體之間的關系短纵，以及針對這些關系的說明就是我們數據建模需要做的工作。實體建模的具體介紹可以參考鏈接1僵控。在實體建模中香到，任何一個業(yè)務都可以劃分為3個部分，實體报破，事件和說明：
實體悠就，主要指領域模型中特定的概念主體，指發(fā)生業(yè)務關系的對象充易。
事件梗脾，主要指概念主體之間完成一次業(yè)務流程的過程，特指特定的業(yè)務過程蔽氨。
-
說明藐唠，主要是針對實體和事件的特殊說明。
如圖所示鹉究，我們描述了一個簡單的事實：用戶在推薦模塊A宇立，點擊了算法B推薦的視頻。以這個業(yè)務事實為例自赔，我們可以把“用戶”妈嘹，“視頻 ”看成是一個實體，“點擊”描述的是一個業(yè)務過程绍妨，我們在這里可以抽象為一個具體“事件”润脸，而“在推薦模塊A，通過算法B”則可以看成是事件“點擊”的一個說明他去。
該主題域內的實體對象有【視頻】毙驯、【用戶】、【推薦算法】灾测、【推薦模塊】等爆价，事件有【瀏覽/曝光】、【播放/點擊】媳搪。圍繞瀏覽與點擊兩個事件铭段，組合視頻、用戶秦爆、算法序愚、模塊等實體間的關系，就會發(fā)現我們的業(yè)務相當簡單等限，可以梳理出以下推薦業(yè)務事實：
- 用戶在某推薦模塊瀏覽某推薦算法推薦的視頻
- 被某推薦算法推薦的視頻在某推薦模塊被用戶瀏覽
- 用戶在某推薦模塊播放某推薦算法推薦的視頻
- 用戶在某推薦模塊播放某推薦算法推薦的視頻時長
基于上面兩個基礎事實爸吮，我們可以再聚合芬膝。在推薦評估中，我們非常關注某個算法表現或某個推薦模塊的表現拗胜。所以蔗候，以推薦模塊、推薦算法為實體埂软，我們可以梳理出以下事實：
- 推薦模塊內各算法推薦的視頻的曝光/播放
- 推薦算法在不同推薦模塊的推薦視頻的曝光/播放
梳理出這些基礎業(yè)務事實锈遥，我們再來看各業(yè)務實體的屬性/維度。比如勘畔，視頻這個實體所灸，有時長、up主/作者…炫七；用戶實體有是否注冊爬立、UGC/PGC、地域等屬性万哪。在不同的業(yè)務主體域內侠驯，同一實體可能有不同的屬性/維度，比如用戶實體在推薦業(yè)務中奕巍，我們可能會關注他的畫像屬性吟策，如興趣偏好；而在內容編輯業(yè)務中的止，對于用戶實體肯定要知道ta是否是up主檩坚，是UGC還是PGC。
所以在不同的業(yè)務域內诅福，同一實體內的維表可能有不同的字段匾委，這個就是下一步維度建模涉及的問題。維度建模需要手動維護維度表數據的一致性氓润。
三赂乐、糖豆數倉維度建模（事實星座模型）
上面以推薦業(yè)務主線為例，我們分析了推薦主題的業(yè)務模型咖气。上面的建模分析仍處于數據倉庫建模的業(yè)務建亩簦或領域建模階段播瞳，該節(jié)段仍然是對現實業(yè)務的初步抽象分析扛施。數倉建設最重要的步驟是邏輯建模八孝，最終的代碼實施則是物理建模階段可免。邏輯建模直接決定了物理建模的成敗泞坦，它決定物理模型實現的難度與是否能滿足業(yè)務分析需求患整。
糖豆數倉的邏輯建模我們采用最流行的多維分析模型——星形模型溯香。通常砸民，多維數據模型用于數據倉庫和數據集市的設計抵怎。這種模型采用星形模式奋救、雪花模式或事實星座模式。多維數據模型的核心是數據立方體反惕。數據立方體由大量事實(或度量)和許多維度組成尝艘。維度是一個組織想要記錄的實體或透視，是自然分層的姿染。支撐多維分析的關鍵就在于維度建模背亥。
進行維度建模之前，我們首先了解兩個概念：
事實表——發(fā)生在現實世界中的操作型事件悬赏，其所產生的可度量數值狡汉，存儲在事實表中。從最低的粒度級別來看闽颇，事實表行對應一個度量事件盾戴。在上面的業(yè)務建模中，我們已經梳理推薦業(yè)務的業(yè)務事實兵多，對應的尖啡，就是一張張事實表。
維度表/維表——每個維度表都包含單一的主鍵列剩膘。維度表的主鍵可以作為與之關聯的任何事實表的外鍵衅斩，當然，維度表行的描述環(huán)境應與事實表行完全對應援雇。 維度表通常比較寬矛渴，是扁平型非規(guī)范表，包含大量的低粒度的文本屬性惫搏。
還以推薦業(yè)務為例具温，我們來分析推薦主題的維度建模】鹋猓考慮用戶在推薦模塊點擊視頻的事實铣猩。我們建一個大的，包含大量數據茴丰、不含冗余數據的中心表（事實表）——推薦點擊表达皿；一組小的附屬表（維表），每個維度都有一個單獨的維表贿肩。假設推薦點擊事實表有用戶峦椰、地域、版本汰规、視頻汤功、ABTag、模塊溜哮、算法等維度滔金，包含點擊次數一個度量色解。為盡量減小事實表的尺寸，事實表中的維度都用標示id餐茵。每個維表包含一組屬性科阎，這些屬性可能有一定程度的冗余。例如忿族，地域中廣州和深圳都屬于華南地區(qū)一線城市锣笨，區(qū)域和城市級別屬性會有冗余。多個事實表可能需要共享維表肠阱，如推薦點擊事實表和推薦播放事實表就會共享地域票唆、用戶、版本等許多維表屹徘。這種多個事實表可以共享維表的模式可以看做是星形模式的合集走趋，因此被稱作星系模式，或者叫做事實星座模型噪伊。在我們的業(yè)務中簿煌，多維建模就是根據業(yè)務事實，建立這種事實星座模型鉴吹。
圖中示例的推薦點擊事實表是只做了輕度聚合的事實表姨伟，還包含很多細粒度的數據，如用戶diu豆励。在數據集市中夺荒，往往根據業(yè)務主題縱向發(fā)展，做不同層次的聚合良蒸。我們對上述事實表技扼，對用戶做聚合，就能得到視頻被點擊人數和次數的二次聚合事實表嫩痰。對用戶瀏覽視頻的事實表做聚合剿吻，得到視頻被曝光人數和次數的事實表。兩者關聯就得到視頻的點擊率串纺。所以丽旅，這些基礎的、粒度最細的事實表的建設對于面向主題的數據集市的建設非常重要纺棺。在這些大事實表的基礎上榄笙，對各種維度做不同粒度的聚合，就構成了立體式有各種粒度數據的數據集市祷蝌。在聚合的過程總對于次數這種度量办斑，可以做任意維度的組合聚合；而對于人數這種涉及去重的度量，不同維度的聚合只能做獨立的去重計算乡翅。所以對于去重聚合，要事先考慮好需要用到的維度罪郊，再做計算蠕蚜。
四、糖豆數倉規(guī)劃
根據目前糖豆業(yè)務線悔橄，結合目前已有的數據表靶累，糖豆數倉的大體構成如下圖。
參考
1癣疟、淺談數據倉庫建設中的數據建模方法
2挣柬、數據挖掘概念與技術
