本文目錄：
一、模型設計
1.1 維度建模或實體關係建模
1.2 星型模型和雪花模型
1.3 資料分層
1.4 資料基礎層
1.5 資料中間層
1.6 資料集市層
二、資料架構
2.1 資料整合
2.2 資料服務化
2.3 架構設計中一些實用的點
三、資料治理
3.1 資料質量
3.2 資料生命週期管理
隨著網際網路規模不斷的擴大，資料也在爆炸式地增長，各種結構化、半結構化、非結構化資料的產生，越來越多的企業開始在大資料平臺下進行資料處理。本文主要從總體思路、模型設計、資料架構、資料治理四個方面介紹瞭如何利用大資料平臺的特性，構建更貼合大資料應用的資料倉庫。
新環境下的資料應用呈現業務變化快、資料來源多、系統耦合多、應用深度深等特徵。那麼基於這些特徵，該如何構建資料倉庫呢？我認為應該從穩定、可信、豐富、透明四個關鍵詞入手。其中，穩定要求資料的產出穩定、有保障；可信意味著資料的質量要足夠高；豐富是指資料涵蓋的業務面要足夠豐富；透明要求資料構成流程體系是透明，讓使用者放心使用。
我們之所以選擇基於大資料平臺構建資料倉庫，是由大資料平臺豐富的特徵決定的：
- 強大的計算和儲存能力，使得更扁平化的資料流程設計成為可能，簡化計算過程；
- 多樣的程式設計介面和框架，豐富了資料加工的手段；
- 豐富的資料採集通道，能夠實現非結構化資料和半結構化資料的採集；
- 各種安全和管理措施，保障了平臺的可用性。
倉庫架構設計原則包括四點：第一自下而上結合自上而下的方式，保障資料蒐集的全面性；第二高容錯性，隨著系統耦合度的增加，任何一個系統出現問題都會對數倉服務產生影響，因此在數倉構建時，高容錯性是必不可少的因素；第三資料質量監控需要貫穿整個資料流程，毫不誇張地說，資料質量監控消耗的資源可以等同於資料倉庫構建的資源；第四無需擔心資料冗餘，充分利用儲存換易用。
一、模型設計
構建數倉的首要步驟就是進行模型設計。
1.1 維度建模或實體關係建模
常見的模型設計思路包括維度建模和實體關係建模。維度建模實施簡單，便於實時資料分析，適用於業務分析報表和BI；實體關係建模結構較複雜，但它便於主體資料打通，適合複雜資料內容的深度挖掘。
每個企業在構建自己數倉時，應該根據業務形態和需求場景選擇合適的建模方式。對於應用複雜性企業，可以採用多種建模結合的方式，例如在基礎層採用維度建模的方式，讓維度更加清晰；中間層採用實體關係建模方式，使得中間層更容易被上層應用使用。
1.2 星型模型和雪花模型
除了建模方式之外，在星型模型和雪花模型的選擇上也有可能讓使用者左右為難。事實上，兩種模型是並存的，星型是雪花模型的一種。理論上真實資料的模型都是雪花模型；實際資料倉庫中兩種模型是並存的。
由於星型模型相對結構簡單，我們可以在資料中間層利用資料冗餘將雪花模型轉換成星型模型，從而有利於資料應用和減少計算資源消耗。
1.3 資料分層
在確定建模思路和模型型別之後，下一步的工作是資料分層。資料分層可以使得資料構建體系更加清晰，便於資料使用者快速對資料進行定位；同時資料分層也可以簡化資料加工處理流程，降低計算複雜度。
我們常用的資料倉庫的資料分層通常分為集市層、中間層、基礎資料層上下三層結構。由傳統的多層結構減少到上下三層結構的目的是為了壓縮整體資料處理流程的長度，同時扁平化的資料處理流程有助於資料質量控制和資料運維。
在上下三層的結構的右側，我們增加了流式資料，將其新增成資料體系的一部分。這是因為當前的資料應用方向會越來越關注資料的時效性，越實時的資料價值度越高。
但是，由於流式資料集的採集、加工和管理的成本較高，一般都會按照需求驅動的方式建設；此外，考慮到成本因素，流式資料體系的結構更加扁平化，通常不會設計中間層。
下面來具體看下每一層的作用。
1.4 資料基礎層
資料基礎層主要完成的工作包括以下幾點：
- 資料採集：把不同資料來源的資料統一採集到一個平臺上；
- 資料清洗，清洗不符合質量要求的資料，避免髒資料參與後續資料計算；
- 資料歸類，建立資料目錄，在基礎層一般按照來源系統和業務域進行分類；
- 資料結構化，對於半結構化和非結構化的資料，進行結構化；
- 資料規範化，包括規範維度標識、統一計量單位等規範化操作。
1.5 資料中間層
資料中間層最為重要的目標就是把同一實體不同來源的資料打通起來，這是因為當前業務形態下，同一實體的資料可能分散在不同的系統和來源，且這些資料對同一實體的識別符號可能不同。此外，資料中間層還可以從行為中抽象關係。從行為中抽象出來的基礎關係，會是未來上層應用一個很重要的資料依賴。例如抽象出的興趣、偏好、習慣等關係資料是推薦、個性化的基礎生產資料。
在中間層，為了保證主題的完整性或提高資料的易用性，經常會進行適當的資料冗餘。比如某一實事資料和兩個主題相關但自身又沒有成為獨立主題，則會放在兩個主題庫中；為了提高單資料表的複用性和減少計算關聯，通常會在事實表中冗餘部分維度資訊。
1.6 資料集市層
資料集市層是上下三層架構的最上層，通常是由需求場景驅動建設的，並且各集市間垂直構造。在資料集市層，我們可以深度挖掘資料價值。值得注意的是，資料集市層需要能夠快速試錯。
二、資料架構
資料架構包括資料整合、資料體系、資料服務三部分。其中，資料整合又可以分為結構化、半結構化、非結構化三類。
2.1 資料整合
結構化資料採集又可細分為全量採集、增量採集、實時採集三類。三種採集方式的各自特點和適應場合如上圖所示，其中全量採集的方式最為簡單；實時採集的採集質量最難控制。
在傳統的架構中，日誌的結構化處理是放在數倉體系之外的。在大資料平臺倉庫架構中，日誌在採集到平臺之前不做結構化處理；在大資料平臺上按行符分割每條日誌，整條日誌儲存在一個數據表字段；後續，透過UDF或MR計算框架實現日誌結構化。
在我們看來，日誌結構越規範，解析成本越低。在日誌結構化的過程中，並不一定需要完全平鋪資料內容，只需結構化出重要常用欄位；同時，為了保障擴充套件性，我們可以利用資料冗餘儲存原始符合欄位（如useragent欄位）。
非結構化的資料需要結構化才能使用。非結構化資料特徵提取包括語音轉文字、圖片識別、自然語言處理、圖片達標、影片識別等方式。儘管目前數倉架構體系中並不包含非結構化資料特徵提取操作，但在未來，這將成為可能。
2.2 資料服務化
資料服務化包括統計服務、分析服務和標籤服務：
- 統計服務主要是偏傳統的報表服務，利用大資料平臺將資料加工後的結果放入關係型資料庫中，供前端的報表系統或業務系統查詢；
- 分析服務用來提供明細的事實資料，利用大資料平臺的實時計算能力，允許操作人員自主靈活的進行各種維度的交叉組合查詢。分析服務的能力類似於傳統cube提供的內容，但是在大資料平臺下不需要預先建好cube，更靈活、更節省成本；
- 標籤服務，大資料的應用場景下，經常會對主體進行特徵刻畫，比如客戶的消費能力、興趣習慣、物理特徵等等，這些資料透過打標籤轉換成KV的資料服務，用於前端應用查詢。
2.3 架構設計中一些實用的點
在架構設計中有一些實用的點，這裡給大家分享一下：
第一，透過巧用虛擬節點實現多系統資料來源同步，實現跨系統間的資料傳輸，實現多應用間資料互動。透過巧用虛擬節點減少運維人員在實際出現問題時的運維成本。
第二，採用強制分割槽，在所有的表都上都加上時間分割槽。透過分割槽，保證每個任務都能夠獨立重跑，而不產生資料質量問題，降低了資料修復成本；此外透過分割槽裁剪，還可以降低計算成本。
第三，應用計算框架完成日誌結構化、同類資料計算過程等操作，減輕了開發人員的負擔，同時更容易維護。
第四，最佳化關鍵路徑。最佳化關鍵路徑中耗時最長的任務是最有效的保障資料產出時間的手段。
三、資料治理
資料治理不是獨立於系統之外的保障，它應該貫穿在數倉架構內部和資料處理的流程之中。
3.1 資料質量
保障資料質量，可以從事前、事中、事後入手。事前，我們可以透過制定每份資料的資料質量監控規則，越重要的資料對應的監控規則應該越多；事中，透過監控和影響資料生產過程，對不符合質量要求的資料進行干預，使其不影響下流資料的質量；事後，透過對資料質量情況進行分析和打分，將一些不足和改進反饋資料監控體系，推動整體的資料質量提升。
3.2 資料生命週期管理
出於成本等因素的考慮，在大資料平臺上我們依然需要對資料生命週期進行管理。根據使用頻率將資料分為冰、冷、溫、熱四類。一個合理的資料生命週期管理要保證溫熱資料佔整個資料體系大部分；同時為了保障資料資產的完整性，對於重要的基礎資料會長久保留。
對於資料中間計算過程資料，在保障滿足絕大部分應用訪問歷史資料需要的前提下，縮短資料保留週期，有助於降低儲存成本；最後一點值得注意的是，冷備已經成為歷史，在大資料平臺下不需要單獨的冷備裝置。
— END —
※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※
更多精彩內容，按讚我的臉書 IT Value 研討社，獲得24個行業240份企業數位轉型資料喔！等你來看喔 😃
