數倉公共層，還有存在的必要嗎？

自我接觸數倉以來，數倉建模就是最為核心的工作，而數倉建模的主要目的是建立公共層，公共層主要起到兩個作用，第一個是遮蔽底層的變動對上層應用的影響，第二個作用是透過複用沉澱的公共層來提升應用支撐的效率，但在長期的數倉公共層運營實踐中中，我發現公共層的表現不總是沿著我們設想的軌跡演進。

1、無論數倉公共層開始的時候設計的多麼完美，數倉公共層最後的使用比例2/8現象明顯，大量的公共層模型是沒人使用的，專案投入的80%都被浪費了。

2、當前的數倉公共層和5年前的數倉公共層差別不是很大，意味著新業務沒必要用新的公共層去支撐，間接否認了公共層存在的必然性。

3、資料倉儲公共層經常會由於積重難返而被推道重來，比如5年一次，對於公共層的投資似乎並不是很划算的生意。

我們當然不能否認公共層的價值，但其價值也許的確被高估了，設想一種場景，假如不預先做數倉公共層的建模，我們對業務的支援真的會變得很糟糕嗎?恰好，我也有實踐。

1、在遙遠的報表時代，為了實現報表會做大量的臨時彙總表，那個時候沒怎麼考慮複用，但似乎也沒什麼大問題。在報表時代過度到資料倉儲時代的時候，其實並沒有什麼強烈的業務驅動要做什麼公共層，但由於那個時候數倉關係建模已經興起，大家都覺得做公共層成了理所當然的事情，畢竟複用是很先進的理念，但其實大多就是把臨時彙總表搞成了公共層而已。

2、在大資料時代，我們在hadoop上開出了很多租戶，雖然主租戶做了大量公共層模型，但各個部門的租戶基本上是隨著應用的需要建立起的一堆中間表和寬表，複用主租戶的公共模型並不是很多，但大多卻活得很好，我們經常指責租戶沒用複用意識，導致大量的計算資源浪費，但要說浪費，我們80%的公共模型沒人使用何嘗不是更大的浪費呢?事實上，各個部門租戶的資源是有限的，但各部門還是靠自己的運營保證了基本的生產需要。

數倉公共層的理想很好，但大多資料團隊實際並不具備什麼公共層的運營能力，為什麼呢?

1、大多公司的業務團隊比較強勢，資料團隊很難堅持一些資料架構的原則

2、業務部門提需求沒有什麼成本，大量低質量的需求把資料團隊有限的資源耗光了，資料團隊很難有時間去考慮公共層的最佳化

3、公共層的價值體現很慢，大家更多的精力還是投在了應用建模上

4、公共層對於業務、技術、資料的綜合要求很高，資料團隊普遍缺乏此類人才

與此同時，資料湖、湖倉一體等新技術的出現都對數倉公共層的建設必要性提出挑戰，技術的趨勢似乎都在朝著數倉公共層的反面進行，即強調原始資料分析的所見即所得，強調對不可知資料和不可知業務的探索分析。

資料倉儲通常預先定義 schema，外部資料需要按照標準寫入(比如清洗轉化等)並對外提供資料服務查詢介面，數倉公共層進一步延伸了這種設計思想，透過事先的生成和約束來確保良好的資料效能，所謂先建模再使用，強調的是未來的成長性。

資料湖則是反過來的，外部資料幾乎不受限制的進入資料湖，只有在需要使用的時候才明確 schema來建模，資料湖也不存在所謂的公共層，應用需要就即席建模，強調的是靈活性。

10年前資料倉儲是主流，因為業務需求主要就是循規蹈矩、按部就班的報表和BI，這種計劃性很強的應用場景非常適合資料倉儲的技術特點，數倉公共層更是讓報表和BI如虎添翼。

靈活性和成長性，對於處於不同時期的企業來說，重要性也是不同的，數倉公共層對於業務成熟的企業來講比較適用，對於初創企業或初創資料團隊來講必要性就很低了，想想自己也是這麼過來的，只不過那個時候公司的資料量不是很大，資料結構簡單，ORACLE就是那個時候的資料湖。

但現在是數字化時代，資料的應用場景逐漸向複雜資料(比如非結構化資料)的快速探索、分析、推薦和預測等方向延伸，這些場景不確定性很強，資料的維度很多，導致公共層很難提前準備，資料湖顯然更適應了這些資料和應用的特點。

但我們也知道，數倉公共層必然還是需要的，因為穩定的報表不會消失，問題只在於度的問題，數倉公共層不要過度設計，也許30%的公共層比例是合理的，未來也許更低，當你家的公共層模型比例超過60%的時候，就要想想是否出現了問題。

那這個度在哪裡呢?

至少不能簡單的使用公共層模型覆蓋度、複用度這種技術指標來指導公共層模型的建設，因為複用度高並不意味著全域性價值最大，甚至較大影響業務的擴充，這裡給出公共層模型建設的三個策略：

第一種是技術驅動，就是某些資料量特別大的表如果各個應用單獨彙總會嚴重影響整個系統穩定的，這些表需透過彙總等手段構成公共層然後統一對外提供。

第二種是管理驅動，就是由於資料一致性等經營管理需要必需確保資料的源頭唯一的，這個時候公共層的建設也很有必要。

第三種是業務驅動，就是那些被存量業務馴化出來的高複用公共模型(比如專案建設時期總結提煉出來的寬表)，或者已經被業務多次投訴並確認為可以透過建立或最佳化公共層模型來解決的。

面對新的業務場景，當沒法確認到底是最佳化公共層模型支撐好還是另起爐灶好的時候，可以先讓子彈飛一會兒，直到以上三種情況的出現為止。當然如果你的團隊有很厲害的架構師並且願意做公共層模型的工作，那的確可以隨心所欲，因為有足夠的能力來進行全域性最優的判斷，但大多時候，我們並不具備這種條件。

我還有一種大膽的設想，就是除了嚴肅的報表，所有的應用支撐都不要搞什麼公共層模型複用，自己管自己的就可以了，也許也可以活得很好。