跟 Amazon 學入門級數據倉庫架構

• 2019 年 12 月 25 日
• 筆記

作者：Lewis Gavin https://medium.com/@lewisdgavin/how-to-architect-the-perfect-data-warehouse-b3af2e01342e

我（Lewis Gavin）目前的工作角色是用 Amazon Redshift 來設計數據倉庫。以我的經驗，無論我們採用的是 Oracle 來搭建數倉，還是以 Hadoop 來搭建 Data Lack(數據湖），基礎型的概念還是沒有變。

雖然不可否認，NoSQL, Hadoop, Spark 代表的確實是先進的生產力，但萬變不離其宗的，還是最底層的那些理論基礎。

Preprocessing

眾所周知，在數據完美入庫之前，都需要經歷一道預處理的過程，它幫助我們清洗掉一些垃圾數據, 將無結構化或半結構化的數據整理成標準維度格式，尤其是數據來源於很多種不同的源頭，比如 web, log 文件, 不同資料庫廠商或者文本文件時，數據格式化規範顯得更為重要。

列舉一些常見的數據預處理場景：

1) 將 excel 數據轉成 csv ;

2) 解析 Json 數據；

3) 清除有錯誤，不符合邏輯的數據

當這些預處理都完成的時候，我們把得到的結果集中地存儲起來，以便完成數據倉庫的數據入庫。

項目中常用的集中處理地，可以是 Amazon S3, 也可以是 Redshift. 兩者都可以靈活地，低成本地與各種技術集成。當然如果是本地伺服器存儲而非採用雲端服務商技術，完全也沒有問題。

Staging

Staging 是任何數據倉庫項目都不可避免的一步。

大型的數據倉庫都將採集多個不同的業務系統數據，而這些數據都有各自的命名風格或者數據格式。Staging 就是負責存儲這些多樣化數據的地方。

與平常卸貨倉一樣，主要負責承載貨物，等貨物卸載完畢之後，還需要被運往最終的目標倉庫或者貨架 https://medium.com/@lewisdgavin/how-to-architect-the-perfect-data-warehouse-b3af2e01342e

Staging 只負責簡單的存儲所有數據倉庫範圍內的初始化數據，進一步做數據處理和建模，並不在這裡實現。

我的個人建議是在 Staging 這一步，我們應該盡量保持數據的原始性（儘管我們可能在預處理的時候，做了一些數據改動），最好表名，表欄位都和源系統一模一樣，以保證可決策或者報表的可追溯性。

為了更夠讓決策數據或者報表更加可靠，給數據邏輯問題留下更多證據，Staging 存儲的數據，其生命周期應當有一個合理的時間範圍，在這個時間範圍內，數據是安全的。比如一個工作日，甚至一個月。之後，Staging 的數據可以清理。整體上來說，Staging 區域是一個非持久化的數據層。

脫離了 Staging 區域，數據開始變得格式化，這種格式更適應數據倉庫模型的變化。

Master

在這一層，數據開始發生一些實質性的轉化。比如 schema 變得更加模型化，表結構命名更加規範，欄位的名字、格式以及數據類型都明確定義正確。

正是這些規範，使得理解這些表以及欄位更加容易，使用這些表也更加得心應手。就像老式的學校里歸檔文案一樣方便高效。

當數據從 Staging 流入到 Master 層時，會經過一系列的清洗，比如：

1）標準化所有的時間格式，採用統一的時區；

2）合理的採用四捨五入法處理小數點；

3）處理字元串的大小寫，或者去掉前後空格；

4）地址格式保持一致；

5）分割連續的字元串，或者解析 Json 數據

有些用作 Join 關係的欄位，我會使他們保持一致。

舉個例子，有些用戶來自網路日誌（ web log），這些用戶數據被存在了 MongoDB 裡面，而真正的用戶廣告行為數據，可能存在業務系統中，那麼把這些用戶抽取到數據倉庫時，就要將各自的用戶標識欄位，命名成一樣的名字，這樣一目了然知道，這兩者的用戶是有關係可尋的。

作為一名數據工程師，這點建模功底是必須配備的，也是終極目標：

你必須確保數據被準確命名成可理解的業務邏輯，且保證你的數據模型可以很容易的被下游數據應用調用與計算。

Reporting

之前的基礎工作已經做完，到此為止，我們已經完成了準備數據，採集數據，清洗數據，以及建立數據模型。接下來我們的目標就是將數據之金展現給世人去批判，把模型挖掘出來的資訊，揭露給讀者。這也就是 Reporting 的價值所在。

假如你採用的是 Oracle 的二維表數據倉庫結構，此時你應該已經建好了事實表，數據集市(data marts).這些數據模型都非常適合用報表工具做展現，相信我你很快就能上手。

大多數的傳統數據倉庫採用 oracle 這樣的產商來實施，因為其性能特別好。這些系統，優點在於 Join 非常出色，但本質上都是基於行做處理。哪怕只要處理其中很少的列（的數據），存儲引擎還是讀取整行數據，實際上浪費了不少性能資源。

如果你把數據倉庫建立在類似 Amazon Redshift 的列式存儲結構上，結果就變了。Redshift 結構下，即使使用寬表（Wide Table）或者多維度與事實共存一表，都能發揮其優秀的性能。

總結下 Redshift 建模的好處：

1）處理寬表的效率比處理複雜Join要高的多；

2）對數據分析師和最終用戶更友好，因為他們不需要處理 Join;

3）所有的數據都在一張表裡，降低了處理難度

假設，我們需要對用戶行為做分析。在 Mastere 層，我們有了 customer, order, marketing log 表，也有了一些日誌分析數據。

在 Redshift 的 Reorting 層，我們只需要建立一張 customer 表。

這張 customer 表可以保存很多客戶數據，比如註冊日期，郵編等（排除那些私人化的資訊，比如不需要的聯繫地址，辦公場地等）；

在這些客戶基礎數據之外，我們還將客戶的註冊渠道囊括進來，比如手機設備，行動電話應用或者桌面應用等；

在這張寬表裡，我們還將客戶的統計事實（即產生購物的統計數字），比如總計消費，第一單事件，最近一單時間或者總訂單數，一起保存；

除此之外，我們還將市場營銷的數據統計事實，比如總共發送的推銷郵件數量，最常聯繫的方式等，一起拉進來保存。

至此，所有的客戶維度資訊，量化事實都存在了一張表裡，藉由 Redshift 的高效列式存儲及計算功能，分析師可以很方便的計算出他想要的答案，比如購買頻次，設備切換次數，是否具有高價值。

不用任何Join, 重活都幹完了。

數據倉庫的目標就是深挖數據來摘取資訊，並不是以便宜的基建或成本取勝。我們要儘可能的用好它，讓它更好的服務於我們的分析師，如果足夠好，不僅是分析師，更多的潛在用戶會選擇使用它。

小結:

上面的步驟，講解了從Preprocessing ( 數據預處理) ，到 Staging, Master, Reporting 的整個數據倉庫的組成流。順著這條路子，你能很容易的建立起一個使用的數據倉庫項目。

但要深知，我們的目的不僅僅是可用，可擴展，還要易於用戶的理解。

上面的講述，Staging, Master, Reporting 是我個人的理解，傾向於把這三個步驟作為隔離的物理層來設計，方便每個階段的輸出可被量化。當然你也可以僅僅把他們當做是邏輯層來設計，只要你心中有數，在幹什麼。