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

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

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

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

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

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

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

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

1、大多公司的業(yè)務(wù)團隊比較強勢，數(shù)據(jù)團隊很難堅持一些數(shù)據(jù)架構(gòu)的原則

2、業(yè)務(wù)部門提需求沒有什么成本，大量低質(zhì)量的需求把數(shù)據(jù)團隊有限的資源耗光了，數(shù)據(jù)團隊很難有時間去考慮公共層的優(yōu)化

3、公共層的價值體現(xiàn)很慢，大家更多的精力還是投在了應(yīng)用建模上

4、公共層對于業(yè)務(wù)、技術(shù)、數(shù)據(jù)的綜合要求很高，數(shù)據(jù)團隊普遍缺乏此類人才

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

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

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

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

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

但現(xiàn)在是數(shù)字化時代，數(shù)據(jù)的應(yīng)用場景逐漸向復(fù)雜數(shù)據(jù)（比如非結(jié)構(gòu)化數(shù)據(jù)）的快速探索、分析、推薦和預(yù)測等方向延伸，這些場景不確定性很強，數(shù)據(jù)的維度很多，導(dǎo)致公共層很難提前準(zhǔn)備，數(shù)據(jù)湖顯然更適應(yīng)了這些數(shù)據(jù)和應(yīng)用的特點。

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

那這個度在哪里呢？

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

第一種是技術(shù)驅(qū)動，就是某些數(shù)據(jù)量特別大的表如果各個應(yīng)用單獨匯總會嚴重影響整個系統(tǒng)穩(wěn)定的，這些表需通過匯總等手段構(gòu)成公共層然后統(tǒng)一對外提供。

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

第三種是業(yè)務(wù)驅(qū)動，就是那些被存量業(yè)務(wù)馴化出來的高復(fù)用公共模型（比如項目建設(shè)時期總結(jié)提煉出來的寬表），或者已經(jīng)被業(yè)務(wù)多次投訴并確認為可以通過建立或優(yōu)化公共層模型來解決的。

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

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