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

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

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

3、數據倉庫公共層經常會由于積重難返而被推道重來，比如5年一次，對于公共層的投資似乎并不是很劃算的生意。

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

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

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

數倉公共層的理想很好，但大多數據團隊實際并不具備什么公共層的運營能力，為什么呢？

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

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

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

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

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

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

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

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

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

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

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

那這個度在哪里呢？

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

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

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

第三種是業務驅動，就是那些被存量業務馴化出來的高復用公共模型（比如項目建設時期總結提煉出來的寬表），或者已經被業務多次投訴并確認為可以通過建立或優化公共層模型來解決的。

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

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