寫在前面： 博主是一名軟件工程系大數據應用開發專業大二的學生，暱稱來源於《愛麗絲夢遊仙境》中的Alice和自己的暱稱。作爲一名互聯網小白，
寫博客一方面是爲了記錄自己的學習歷程，一方面是希望能夠幫助到很多和自己一樣處於起步階段的萌新。由於水平有限，博客中難免會有一些錯誤，有紕漏之處懇請各位大佬不吝賜教！個人小站:http://alices.ibilibili.xyz/ , 博客主頁:https://alice.blog.csdn.net/
儘管當前水平可能不及各位大佬，但我還是希望自己能夠做得更好，因爲一天的生活就是一生的縮影。我希望在最美的年華，做最好的自己！
之前做過一個大數據離線數倉項目，然後寫下了一篇總結👉大數據實戰【千億級數倉】項目總結。那一篇博客主要針對方向是項目本身，那如果我們把眼光放遠，討論的方向放到數倉設計上面，那該如何總結呢？
不用擔心，本篇博客將告訴你答案！
① 構建數據倉庫的基礎 (前提)
穩定：數據的生產穩定、有保障；
數據倉庫底層有三個系統（a\b\c）
保證ABC能夠穩定生產數據。
高質量：數據質量要足夠高；
儘量保證數據是高質量的。在確定100%沒有意義的數據的情況下，將數據剔除掉。
覆蓋廣：數據涵蓋的業務面要儘可能多；
以解決業務問題爲目標：企業需要提供解決業務問題所需要的所有數據。【理想情況下】
實際上企業內：已有數據能夠解決哪些問題就優先解決哪些問題。能支撐是什麼業務就做着什麼業務。
透明：數據的構成流程要透明，用戶使用放心。
② 基於大數據平臺構建數倉
爲什麼基於大數據平臺構建數據倉庫？[數倉與大數據的結合點]
- 存儲計算能力強，分佈式存儲，存儲空間大，使空間換時間成爲可能，使扁平化數據處理流程成爲可能（簡化計算過程，計算難度）
- 數倉會使計算流程變多，但是每一步和計算的難度都會降低。
- 組件多，編程接口豐富，增加了數據處理的方式方法。
- 大數據平臺組件衆多，每個組件都有自己的特點和用法。
- 同一個問題可以有多種方式方法解決
數據同步：自己寫代碼/sqoop/kettle。
數據預計算：MR/hive/spark。
實時計算：sparkStreanig/structStreaming/flink/storm
- 多種數據採集，能夠實現實時數據、離線數據，非結構化數據和半結構化數據的採集；
- 得益於大數據內的組件衆多，實時數據，離線數據都能夠同步都能夠計算。
- 結構化數據（結合數據庫），非結構化數據採集(flume)
③ 倉庫架構設計原則
1、自下而上與自上而下相結合
自下而上：數據的清洗、過濾、填充、彙總、計算自下而上分步驟計算。
自上而下：數據的查詢、異常追蹤，數據價值密度自上而下。
2、高容錯性
構建數倉的任何一個系統出現故障，都會對數倉服務產生一定的影響，所以在構建數倉時，需保證數倉具備高容錯性。（hive-mysql-kettle-kylin）
3、數據質量監控
數倉最終的結果直接受數據質量的影響。生產中數據質量管理需要貫穿整個數據處理流程
④ 數倉構建步驟
第一步：模型設計
建模方式：維度建模或實體關係建模
1. 維度建模相對實施比較簡單，便於事實數據分析，適用於業務分析報表和BI；
2. 實體關係建模結構相對較複雜，它便於主體與主體之間的數據打通，比較適合複雜數據的深入分析。
模型分類: 星型模型和雪花模型
兩種模型沒必要絕對分開，事實上應該是並存的。星型也屬於雪花模型。
星型模型結構相對簡單，有利於計算，所以若表結構爲雪花型可以在將雪花模型轉換成星型模型，以達到降低計算難度的目的。
第二步：數據分層
數據分層可以使數據構建體系更加清晰，便於數據使用者快速對數據進行定位；同時數據分層也可以簡化數據加工處理流程，降低計算複雜度。
常用的分層爲：集市層（ADS）、中間層(DW)、基礎數據層(ODS)，上下三層結構。
其中：
數據基礎層(ODS)
數據採集：把多種數據源的數據統一採集到一個平臺上；
數據歸類：按照來源系統和業務領域進行分類（目錄）；
數據規範化：包括規範維度標識、統一計量單位等規範化操作。
數據清洗：刪除不符合要求的數據，避免髒數據參與後續數據計算（也可在DW層）；
數據結構化：對於半結構化和非結構化的數據，進行結構化【目前還不在數倉中實現】；
數據中間層（DW）
目標就是把同一實體/主題，不同來源/不同數據表的數據打通（拉寬到一個報表），已方便後續計算業務數據的使用。
用戶行爲數據可以抽象出來一些有用的數據，例如興趣、偏好、習慣等。這些數據可以支撐上層的部分應用（推薦）。
當有一個實事數據和兩個主題相關時
需將該數據放在兩個主題庫中（冗餘兩份或多分）這樣能保證主題的完整性和提高數據的易用性，兩個主題之間相互不影響（單表數據的複用性比較低）。爲了提高單數據表的複用性和減少計算關聯，會在事實表中冗餘部分維度信息。
數據集市層（ADS）
數據集市由需求場景驅動建設，方便需求快速查詢，快速計算。
⑤ 數據架構
數據架構包括數據整合、數據體系、數據服務三部分。
數據整合
數據類型可分爲結構化、半結構化、非結構化三類。
數據整合可分爲全量數據、增量數據、實時數據三類。
| 結構 | 半結構 | 非結構 | |
|---|---|---|---|
| 全量 | 結構全量 | 半結構全量 | 非結構全量 |
| 增量 | 結構增量 | 半結構增量 | 非結構增量 |
| 實時 | 結構實時 | 半結構實時 | 半結構實時 |
半結構化數據/非結構化數據需要經過結構化計算後才能使用。
例如：
微博 - - 博主，時間、狀態、評論數。
圖片 - - 文件名、大小、創建時間、格式。
語音 - - 文件名、時常、大小、格式，創建時間。
視頻 - - 文件名、時長、分類等。
目前數倉架構體系中並不包含非結構化數據特徵提取操作（其他系統提取好後才寄過來）。
數據體系
即數據的計算從入庫開始到寫入數據集市的全部過程。
數據服務化
數據服務化包括統計服務、分析服務、標籤服務：
ADS數據集市包含統計服務、分析服務、標籤服務。
統計服務（用戶）：
主要是偏傳統的報表服務，將計算後的結果存儲到關係型數據庫中，供前端的報表系統或業務系統查詢。
分析服務（分析師）：
用來提供明細數據的即席查詢(即席查詢【想怎麼查就怎麼查】:操作人員可以自主靈活的進行各種維度的交叉組合查詢)。分析服務的能力類似於傳統cube提供的內容。
一個查詢有10個維度。（group by 後面的字段有1-10個）
10個維度任意組合的可能性有多少？？ 2的十次方-1個可能（1023）
用戶的所有查詢可能都在這1023種情況內
標籤服務（推薦）：
在大數據的應用中，經常會對主體進行特徵刻畫。例如：客戶的年齡段、消費性別、消費能力、興趣習慣等。這些數據通過打標籤轉換成KV的數據服務，用於前端應用查詢。
經驗分享
1、採用強制分區，在所有的表都上都加上時間分區。通過分區，保證每個任務都能夠獨立重跑，而不產生數據質量問題，降低了數據修復成本；此外通過分區裁剪，還可以降低計算成本。
2、應用計算框架完成日誌結構化、同類數據計算過程等操作，減輕了開發人員的負擔，同時更容易維護。
3、優化關鍵路徑。優化關鍵路徑中耗時最長的任務是最有效的保障數據產出時間的手段。
⑥ 數據治理
適用場景：
計算量很大，生產中數據質量管理所需要的資源需要與數倉的計算資源對頂或相匹配。
數據治理貫穿在數倉架構內部和數據處理的流程之中。
保障數據質量，可以從事前、事中、事後入手。
事前，可以通過制定每份數據的數據質量監控規則，越重要的數據對應的監控規則應該越多。
事中，通過監控和影響數據生產過程，對不符合質量要求的數據進行干預（刪除/填充/歸0等），使其不影響下流數據的質量。
事後，通過對數據質量情況進行分析和打分，將一些不足和改進反饋數據監控體系，推動整體的數據質量提升。
例如：數據進入ODS層之前數據量是多少條，根據規則刪除掉多少條，剩餘多少條。進入之前=刪除的+剩餘的
數據進入DW層之前多少條，出DW多少條。進入的-輸出的是否是未join上的數據。
編寫質量檢測程序，逐一檢查數據是否符合規則。統計出符合的有多少條，不符合的有多少條（符合的+不符合的=所有的）。
⑦ 數據生命週期
雖然大數據集羣空間大，但不要過量使用空間。出於成本等因素的考慮，在大數據平臺上依然需要對數據生命週期進行管理。
根據使用頻率將數據分爲冰、冷、溫、熱四類。保證數據的生命週期儘量合理（保證溫熱數據佔整個數據體系大部分）。
對於數據中間計算過程數據，在保障滿足絕大部分應用訪問歷史數據需要的前提下，縮短數據保留週期，有助於降低存儲成本。
熱（近1-7天）：存儲在kylin的cube (hbase+預計算)或redis或mysql
溫（近8-14天）：存貯在mysql或oracle或MongoDB
冷（近15-45天）：存儲在hive表(SSD硬盤中)
冰（45+）：冰數據存儲在HDFS的機械硬盤中
結語
關於【大數據】數倉設計的乾貨內容分享就到這裏，後續會爲大家帶來其他類型的項目分析，敬請期待😎
如果以上過程中出現了任何的紕漏錯誤，煩請大佬們指正😅
受益的朋友或對大數據技術感興趣的夥伴記得點贊關注支持一波🙏
