一、數據倉庫現狀

小 A 公司創建時間比較短，才剛過完兩周歲生日沒多久；業務增長速度快，數據迅速增加，同時取數需求激增與數據應用場景對數據質量、響應速度、數據時效性與穩定要求越來越高；但技術能力滯后業務增長，如實時數倉技術能力、高可用穩定保障能力、流程規范缺少等，這些能力嚴重滯后業務發展，甚至有些還是停留在公司創建初期 case by case 階段。小 A 根據數據在數倉流向（以下圖），從上游的業務系統測到數倉內部最后到下游數據應用梳理數據倉庫建設存在問題。

業務系統側【上游】

數據倉庫首先需要對業務系統結構化業務數據、日志數據與埋點數據進行歸集；數倉與上游業務系統對接主要存在以下問題:

缺失業務系統數據模型清單與變更同步：沒有對已歸集到數倉業務系統數據模型記錄，業務系統數據模型發送變更也沒有對數倉知會，更多是出現問題后或者是數據使用者事后告知數倉。

缺少統一枚舉值編碼與變更同步：業務系統沒有統一枚舉值編碼，如訂單狀態有：下單、接單、成單，沒有統一對這些枚舉值進行管理；如果后面對訂單狀態再增加一個：取消單狀態，這種變更也沒有對數倉進行知會。

業務部門搭建各自小數倉：有些部門繞過數倉直接接入上游數據源，搭建各自的小數倉，從而導致數據孤島、重復計算、口徑不一致。

存在業務盲區：有些業務需要專業知識背景如：財務；有些業務規則保密級別高，無法對非業務相關員公開業務邏輯，如風控；因此無法系統梳理這些業務實體與實體之間關系，提煉指標，共享數據。

數倉內部

公司創建初期，數據量比較小、數據需求也不多、數據應用場景也比較單一更多是為了滿足一下簡單報表，因此數倉主要是以接單方式驅動工作，來一個需求做一個，case by case，主要是為了快速響應需求。但隨著業務迅速增加，數據量暴漲，數據應用場景多樣化，慢慢暴露出以下問題：

流程規范缺少：沒有流程與規范指引數據開發者根據流程對數據進行規范化建設，導致數據分層分類不清晰，數據混亂；命名不規范，同義不同名，同名不同義；數據重復建設，冗余數據多。

沒有體系化技術設計：無論是離線或實時數據采集、處理與分發都缺少體系化設計與搭建，更多是在前期 case by case 上面修修補補；例如在離線與實時對同一數據源進行采集；無差別對所有數據源每次全量抽取與 DWD 到 DWS 層無差別全量計算；T+1 與每小時批處理煙囪開發，同一寬表離線與實時煙囪開發、重復計算與存儲；對不同應用場景無差別使用相同存儲與計算等等；

影響無互相隔離：數倉數據存儲與計算，沒有與數據應用服務存儲與技術隔離，存在互相之間資源搶占與問題被放大情況；同時也存在數倉底層模型設計很難兼容數據應用層模型設計需求

數據應用測【下游】

數倉需要為不同數據應用場景（風控、C 端、業務運營等）提供數據，不同數據應用需求是不一致的，存在很多差異；同時數據在不同應用場景價值也是不一樣的。因此需要清楚了解下游數據應用場景與存在問題才可以更好服務數據應用方，下游主要存在以下問題：

對數據應用場景不了解：對下游數據需求應用場景不了解或者沒有深入了解，沒有針對不同場景評估技術選型，簡單粗暴使用一招打天下，對不同場景使用一套計算與存儲。

不知道數據被哪些應用訪問：沒有對下游應用對數據使用監控與記錄，無法對數據使用情況與價值進行量化

沒有量化數據需求優先級：對下游數據需求沒有優先級評估機制，沒有量化數據需求優先級

沒有自助取數工具：下游沒有取數能力，導致大部分的取數工作還是依賴數據開發來完成。數據開發大部分的時間都被臨時取數的需求占據，根本無法專注在數倉模型的構建和集市層數據的建設，最終形成了一個惡性循環，一方面是數據不完善，另一方面是數據開發忙于各種臨時取數需求。

數據接入方式多樣，接入效率低：每個數據應用都要根據不同的中間存儲，開發對應的代碼，如果涉及多個中間存儲，還需要開發多套代碼，數據接入效率很低。

數據質量問題：數據經常因為 BUG 導致計算結果錯誤，最終導致錯誤的商業決策。

二、如何解決問題

與業務系統側協同需要跨部門溝通與合作，因此需要溝通流程與標準，讓雙方聚焦在公共目標；同時也要維護好你好我好的共存關系。主要是針對事前、事中、事后提出解決方案。

事前：與上游建立知會機制與協同流程，及時同步業務與模型變更；接管 ODS 層，控制源頭，ODS 是業務數據進入數倉的第一站，是所有數據加工的源頭，控制住源頭，才能從根本上防止一個重復的數據體系的出現。

事中：通過技術手段捕捉上游元數據與字典值變更，從而方便以后問題追蹤與影響分析

事后：通過事后復盤優化流程與迭代技術

數倉內部

數倉內部主要是要從技術體系、流程規范與數據架構等幾個維度去解決這些問題。

制定流程與規范

數據開發流程：

數據開發規范：

數倉規范主要包括以下內容：

1. 基礎字典【詞根】詞根是企業最細粒度業務術語，是維度和指標管理的基礎，通過詞根可以用來統一表名、字段名、主題域名；建立和維護可收斂的詞根庫，業務域、主題域我們都可以用詞根的方式枚舉清楚，不斷完善，粒度也是同樣的，主要的是時間粒度、日、月、年、周等，使用詞根定義好簡稱，數倉開發的字段命名也可以使用詞根進行組合；劃分為普通詞根與專有詞根

普通詞根：描述事物的最小單元體，如：交易-trade。

專有詞根：具備約定成俗或行業專屬的描述體，如：美元-USD。

詞根示例如下：

2. 基礎規范

數據域：數據縱向分域，如下圖

數據層級：數據橫向分層，如下圖

3. 命名規范對模型命名標準化，規范各層（ODS、DWD、DWS、DM）命名，后期可以考慮借助類似以下命名規范工具提供效率與把控能力。

4. 規范性評估從以下幾個角度去衡量規范度

三、體系化架構設計

一致性維度

一致性維度的意思是兩個維度如果有關系，要么就是完全一樣的，要么就是一個維度在數學意義上是另一個維度的子集。例如，如果建立月維度話，月維度的各種描述必須與日期維度中的完全一致，最常用的做法就是在日期維度上建立視圖生成月維度。這樣月維度就可以是日期維度的子集，在后續鉆取等操作時可以保持一致。如果維度表中的數據量較大，出于效率的考慮，應該建立物化視圖或者實際的物理表。這樣，維度保持一致后，事實就可以保存在各個數據集市中。雖然在物理上是獨立的，但在邏輯上由一致性維度使所有的數據集市是聯系在一起，隨時可以進行交叉探察等操作，也就組成了數據倉庫。

一致性事實

在建立多個數據集市時，完成一致性維度的工作就已經完成了一致性的 80%－90%的工作量。余下的工作就是建立一致性事實。一致性事實和一致性維度有些不同，一致性維度是由專人維護在后臺（Back Room），發生修改時同步復制到每個數據集市，而事實表一般不會在多個數據集市間復制。需要查詢多個數據集市中的事實時，一般通過交叉探查（drill across）來實現。為了能在多個數據集市間進行交叉探查，一致性事實主要需要保證兩點。第一個是 KPI 的定義及計算方法要一致，第二個是事實的單位要一致性。如果業務要求或事實上就不能保持一致的話，建議不同單位的事實分開建立字段保存。這樣，一致性維度將多個數據集市結合在一起，一致性事實保證不同數據集市間的事實數據可以交叉探查。

數據應用側【下游】

針對數據應用側解決思路主要是提高取數效率，減少數據質量問題，數據和接口復用，具體如下。

要想提升數據質量，最重要的就是“早發現，早恢復”：

早發現，是要能夠先于數據使用方發現數據的問題，盡可能在出現問題的源頭發現問題，這樣就為“早恢復”爭取到了大量的時間。主要方法是在數據產出任務運行結束后，啟動稽核校驗任務對數據結果進行掃描計算，判斷是否符合規則（完整性規則、一致性規則、準確性規則）預期。

早恢復，就是要縮短故障恢復的時間，降低故障對數據產出的影響。主要方法是基于數據血緣關系，建立全鏈路數據質量監控。對鏈路中每個表增加稽核校驗規則之后，當其中任何一個節點產出的數據出現異常時，你能夠第一時間發現，并立即修復，做到早發現、早修復。

建設可視化的取數平臺

靠別人取數，會存在大量的溝通和協作的成本，同時因為公共集市層數據不完善，導致無法基于現有的數據，直接完成取數，需要數據開發加工新的數據，所以耗時會非常的長，一般需要一周時間。高昂的取數成本，壓制了取數的需求，也導致探索式的數據分析，根本不可能大規模的使用。通過自助取數平臺，釋放取數效能，將大部分取數由非技術人員的需求方完成。通過以下幾點建設自助取數平臺：

用圖形化的方式，替代了寫 SQL 的方式；

提供了對業務人員比較友好的業務過程、指標、維度的概念，替換了表、字段；

每個指標的業務口徑都能夠直接顯示；

用戶通過選取一些指標和維度，添加一些篩選值，就可以完成取數過程；

界面非常簡潔，使用門檻非常低。