大年三十除夕的清晨，迎接新年的最后一篇文章來講講大家平時可能很少接觸到的一類數(shù)據(jù)架構(gòu)。

因為這種架構(gòu)少有產(chǎn)品化的落地使用，市面上也沒有很好的參照。而我們在兩年前做我們自己 BI 產(chǎn)品的時候就已經(jīng)把這個概念給產(chǎn)品化了，所以我們把這種架構(gòu)就取了一個名字叫做 BI 的分倉分庫、前置倉。

講這個架構(gòu)之前，我先來講講幾個失敗的案例。具體案例名稱就不在這里提了，就說下這幾個項目比較共性的需求背景。

共性的需求和場景

十四五規(guī)劃，數(shù)字化轉(zhuǎn)型大背景下，一個集團七八十家公司二級單位，二級以下還有三級、四級。集團要求做所謂的數(shù)據(jù)中臺、大數(shù)據(jù) BI，總之最后的要求大概就是做到：拉通數(shù)據(jù)、一企一屏、集團財務(wù)業(yè)務(wù)一體化的可視化分析，實現(xiàn)資產(chǎn)監(jiān)管等等。

聽上去是不是感覺很熟悉，就像身邊的企業(yè)集團一樣？非常正常，太多類似于這樣的需求了。我面對面聊過的這類需求已經(jīng)不下十家，聽到的就更多。

這些案例大概是什么需求背景呢 ？首先要做的就是財務(wù)監(jiān)管方面的各個系統(tǒng)打通。以往是通過數(shù)據(jù)報送看看基本的報表就可以了，現(xiàn)在要求所有二級財務(wù)系統(tǒng)要對接到集團層面，能夠看到更詳細(xì)的、深入的數(shù)據(jù)分析，這個是一期的規(guī)劃。二期就是從業(yè)務(wù)線、業(yè)務(wù)板塊按照同樣的方式，所有的業(yè)務(wù)數(shù)據(jù)都上來，逐步實現(xiàn)一企一屏、集團管控、集團大屏等等，實現(xiàn)集團視角、業(yè)務(wù)板塊視角、企業(yè)視角等可視化分析。

最終的輸出大家注意到了嗎，都是什么? 都是 BI 可視化分析、大屏可視化，所以 BI 在這些項目里面是一個剛需。難的地方在哪里？在底層數(shù)據(jù)上，不僅僅是數(shù)據(jù)清洗、治理，更重要的是數(shù)據(jù)架構(gòu)到底應(yīng)該怎么來構(gòu)建才更加高效。

第一家是怎么做的呢？底層上了一個大數(shù)據(jù)架構(gòu)平臺，對外叫數(shù)據(jù)中臺，把所有的二級企業(yè)集團的數(shù)據(jù)全部同步到集團的云端，然后在云端做數(shù)據(jù)的清洗、合并等等一系列 ETL 加工處理，最后通過 BI 工具做可視化分析。這個實現(xiàn)思路是對的，難就難在只考慮到了數(shù)據(jù)搬過來上云，忽略掉了數(shù)據(jù)處理的復(fù)雜度。上百家企業(yè)的數(shù)據(jù)如何合并，如何抽象出共性指標(biāo)，如何打通這些數(shù)據(jù)。這個項目最終也沒有跑起來，死在抽取之后數(shù)據(jù)加工到出 BI 這個層面，一家企業(yè)數(shù)據(jù)出問題，最后的大數(shù)就是有問題，死活不知道問題出現(xiàn)在哪里。

直接把所有數(shù)據(jù)拿過來放到一個平臺，在一個大平臺里面做清洗處理，組織架構(gòu)、維度科目檔案統(tǒng)一如何做，指標(biāo)口徑如何統(tǒng)一？一個點出問題處處都是問題。

這個是思路對了，實現(xiàn)難度大，沒有考慮到這種復(fù)雜性，沒有針對性的找到復(fù)雜場景下的解決措施。

而下面這個是思路就不對，錯得離譜。

第二家的做法是直接在業(yè)務(wù)系統(tǒng)中對接各個集團財務(wù)系統(tǒng)的數(shù)據(jù)，然后在這個業(yè)務(wù)系統(tǒng)中做合并，最后作為大的數(shù)據(jù)出口、數(shù)據(jù)源為未來集團 BI 所使用。這種架構(gòu)就是從方向、從根上完全錯了，心思就不正。說嚴(yán)重一點，就是很壞。這樣一做，基本上就把甲方給完全綁定了，以后說是什么就是什么。即使財務(wù)數(shù)據(jù)相對標(biāo)準(zhǔn)，集中到一個業(yè)務(wù)平臺上，其他的業(yè)務(wù)數(shù)據(jù)以后要分析怎么辦？

其他看到的幾家項目做法介入這兩者之間，處理方式和手段基本上就這些。

面臨的挑戰(zhàn)

這幾家面對同樣的問題主要是：

第一，各個二級企業(yè)（集團) 所用的財務(wù)系統(tǒng)各不相同，有用友NC、用友U8、金蝶 EAS、浪潮、還有用友 T 系列的。很多人問為什么當(dāng)初集團不統(tǒng)一這些系統(tǒng)，大家需要知道一個大型集團的成長都是靠兼并、收購、重組不斷的進化的，IT 信息化不統(tǒng)一非常的正常，IT 信息化建設(shè)很難提前規(guī)劃和預(yù)判。

第二，各個企業(yè)由于自身的業(yè)務(wù)特點，各個業(yè)務(wù)系統(tǒng)也不一樣，非統(tǒng)建類的系統(tǒng)居多。

第三，即使是同業(yè)務(wù)板塊的下屬二級企業(yè)，有的企業(yè)有相應(yīng)的業(yè)務(wù)系統(tǒng)，有的企業(yè)就沒有相關(guān)的業(yè)務(wù)系統(tǒng)支撐。

這里面的共性挑戰(zhàn)是什么？

第一，不同的系統(tǒng)由不同的供應(yīng)商維護，底層數(shù)據(jù)字典、數(shù)據(jù)質(zhì)量的問題，這么多業(yè)務(wù)系統(tǒng)要取數(shù)，有的還做過二開，數(shù)據(jù)怎么取的問題，誰來配合解讀數(shù)據(jù)。

第二，集團到底要看什么數(shù)據(jù)？知道這些數(shù)據(jù)從哪里取嗎？什么時候取哪些數(shù)據(jù)？七八十家企業(yè)，幾百個系統(tǒng)，等你整合完，報表什么時候才能出來？

第一家的實現(xiàn)思路沒有太大的問題，但是第二家的實現(xiàn)思路實在是不可救藥 —— 讓各家業(yè)務(wù)系統(tǒng)供應(yīng)商提供標(biāo)準(zhǔn) API 接口，從各個業(yè)務(wù)系統(tǒng) API 接口取數(shù)全部集中到自身的業(yè)務(wù)平臺中。這里面涉及到多少家供應(yīng)商資源的協(xié)調(diào)，需要多少的二次 API 開發(fā)工作投入。并且最嚴(yán)重的一個問題是，業(yè)務(wù)系統(tǒng)不是數(shù)據(jù)系統(tǒng)、BI 系統(tǒng)，業(yè)務(wù)系統(tǒng)彼此之間應(yīng)該是完全獨立的，只有數(shù)據(jù)系統(tǒng)、BI 系統(tǒng)才能完全基于所有業(yè)務(wù)系統(tǒng)之上，形成各業(yè)務(wù)系統(tǒng)數(shù)據(jù)的打通、建模再到支撐 BI 前端可視化。

所以，這家架構(gòu)從根上就錯了，項目已經(jīng)啟動半年一直無法推進，我上會溝通了一下發(fā)現(xiàn)已經(jīng)無法扭轉(zhuǎn)了，救都救不回來。

集團型 BI 的數(shù)據(jù)架構(gòu)實現(xiàn)思路

像這類項目實現(xiàn)思路到底是什么？有沒有一些優(yōu)化的方案或者架構(gòu)可以供參考借鑒的，這就是我下面接著要說的幾個點：

第一，不管是什么樣的財務(wù)監(jiān)管、一企一屏、集團 BI 可視化，最終大家都需要注意到，BI 都是最終的出口，這個是最終使用用戶唯一能看懂的東西。

第二，一定不會先上來把上百家二級企業(yè)的業(yè)務(wù)系統(tǒng)數(shù)據(jù)先打通一遍，做整體的數(shù)據(jù)建模，一定不能這么干。

有的人說我們集團要求業(yè)務(wù)上云、數(shù)據(jù)上云，所以數(shù)據(jù)全部要搬過來。注意，搬過來和打通是兩回事，搬過來只是數(shù)據(jù)到集團的云端了，打通是真正意義上數(shù)據(jù)的打通、清洗、匯總、合并等一系列的處理。這種打通，不要說上百個系統(tǒng)，就一兩個系統(tǒng)的完整打通，按照 BI 建模的方式走一遍基本上就是幾個月甚至小半年時間。

第三，一定從需求出發(fā)，先梳理分析指標(biāo)，需要什么指標(biāo)就看什么指標(biāo)。不管是財務(wù)的，還是業(yè)務(wù)的，確認(rèn)多少，再抽取多少，這樣可以不用在最初的時候把面鋪的過大。舉個例子，全部系統(tǒng)打通可能涉及到上百個系統(tǒng)，這個工作量太大。

但是這次梳理出來的一部分指標(biāo)，可能只涉及到幾個系統(tǒng)的打通，階段性的工作量一下子就降下來了，難度也就下來了。

把這三個點弄明白，我再來講講下面的這種架構(gòu)就容易很多了。

第一，明確集團層面需要看什么數(shù)據(jù)，看什么數(shù)據(jù)就抽取什么數(shù)據(jù)。這種要看的數(shù)據(jù)從 BI 的視角來說，就是指標(biāo)和維度，所謂的明細(xì)數(shù)據(jù)就是維度的顆粒度，維度顆粒度越細(xì)，數(shù)據(jù)明細(xì)就越細(xì)致，定好了就可以了。

第二，既然是集團層面的統(tǒng)一視角，所以這種數(shù)據(jù)的模板或者格式就是高度統(tǒng)一的，適用于所有的企業(yè)。

因此在某一個階段，二級企業(yè)數(shù)據(jù)到達集團大數(shù)據(jù)倉庫中心之前，因為已經(jīng)知道了需要獲取什么樣的數(shù)據(jù)，所以在二級企業(yè)設(shè)置前置數(shù)據(jù)倉庫。按照規(guī)定的數(shù)據(jù)格式、模板同步到二級企業(yè)的數(shù)據(jù)倉庫中，二級企業(yè)的數(shù)據(jù)清洗過程不是放到集團數(shù)據(jù)倉庫層面，而是在二級企業(yè)的數(shù)據(jù)倉庫中完成。

這個就是 BI 數(shù)據(jù)倉庫的分倉分庫，前置數(shù)據(jù)倉庫的概念。

這個前置數(shù)據(jù)倉庫服務(wù)器可以放到二級企業(yè)本地，也可以放到集團統(tǒng)一管理。位置在哪里并不重要，重要的是要降低數(shù)據(jù)邏輯處理的并發(fā)復(fù)雜度。

什么叫并發(fā)復(fù)雜度？比如我有一個大屋子，大屋子里有十個房間，每個房間放了好多雜亂無章的東西，現(xiàn)在要把東西給清理出來拉到大屋子的大廳擺放整齊。

兩種處理方式，看看哪種更好：

第一種，直接把每個房間的東西全部拉到大廳里面，然后再分門別類的整理。

第二種，在每個房間整理好，然后再拉出來放到大廳擺放。

大廳就是集團的數(shù)據(jù)倉庫，在房間整理好就是前置數(shù)據(jù)倉庫，明顯這種方式更優(yōu)。全部拉到大廳再來整理，容易手忙腳亂，互相打擾，一個錯誤全部就亂。

就如同上面的這幅圖，各二級企業(yè)的數(shù)據(jù)就像各個農(nóng)地里面的菜一樣，就地分倉處理，處理干凈了再合并到總倉中，這種效率非常高。

比如一家集團上百家二級使用的財務(wù)系統(tǒng)各不相同，沒有分倉分庫的話就需要一家一家的進行數(shù)據(jù)對接。有數(shù)據(jù)倉庫模板的話就相當(dāng)于各個版本的財務(wù)系統(tǒng)只需要對接一次，剩余的直接按照模板復(fù)制到各地數(shù)據(jù)倉庫就可以了，七個財務(wù)系統(tǒng)版本就對接七次就可以做到。

數(shù)據(jù)倉庫的模板是什么？分析模型、維度、指標(biāo)、以及維度指標(biāo)的取數(shù)邏輯，這些都可以有效的組織和統(tǒng)一模板，高度復(fù)用。

上面的這些架構(gòu)，我們很早就已經(jīng)落地了，并且是以產(chǎn)品化數(shù)據(jù)倉庫的形式落地。

場景越復(fù)雜、分倉分庫、前置倉架構(gòu)的優(yōu)勢越大

這種架構(gòu)使用的場景非常的多，集團越大越適合，業(yè)務(wù)系統(tǒng)版本越多越適合，足夠大，高度可復(fù)用的效率優(yōu)勢體現(xiàn)的會更加明顯。

這種架構(gòu)具備很強的擴展性和想象力，比如像國資委的國資監(jiān)管、大型集團的多級 BI 架構(gòu)、甚至只要有這種帶有上下級數(shù)據(jù)傳遞整合打通，不管多少級都可以按照這種架構(gòu)思想來實現(xiàn)，可以把每個分倉無限往下擴展成不同的小倉庫，從小倉到大倉，從大倉到總倉。

數(shù)據(jù)架構(gòu)這些東西沒有什么可神秘的，就像一層窗戶紙，一捅就破，關(guān)鍵是在不同的項目中要靈活運用。

本文經(jīng)授權(quán)轉(zhuǎn)載自微信公眾號 呂品聊數(shù)據(jù)  作者 呂品