前段時間，一個搞信息化的朋友找到我，說今年老闆安排要上數倉和BI的項目，但他自己對兩者之間的配合細節還沒想的很清楚，想讓我給他展開講講。所以今天想借朋友的這個問題，來跟大家聊聊BI與數據倉庫之間的關係。
企業是如何處理數據的？
BI和數倉在這中間各自起什麼作用開始前，咱們先通過一個做菜的例子，來簡單瞭解企業是如何處理數據的，並從中正確理解BI與數倉的作用與關係。大家都去過餐館喫飯，你知道喫到的菜肯定不是廚師從菜市場買回來，就直接上給你喫。菜很髒，需要加工處理。那，廚師是怎麼做出可口的菜品？就像企業數據是如何從業務系統的雜亂數據到最終整潔易懂的可視化報表數據？
很簡單，兩者都可以分爲三步：
第一步：根據要做的菜品去不同的菜市場採購食材 VS 根據數據需求去不同的業務系統數據庫取數。例如我要做西紅柿炒蛋，我要先去A菜市場買雞蛋，再去B市場買西紅柿，有點“東市買駿馬，西市買鞍韉”的意思在，因爲我要的東西只有這兩個地方能給到我。這就像數據，有的數據只能在A業務數據庫裏取，有的只能在B業務數據庫裏取，數據來源是不一樣的。在這裏，我們可以認爲菜市場=業務系統數據庫，食材=數據。
第二步：把買回來的食材集中起來，放在廚房裏完成備菜 VS 通過ETL取數到數據倉庫中做清洗轉換工作在這個廚房中，廚師要完成備菜，爲後續的炒菜做好食材準備，而這個廚房，就是數據倉庫：把數據（食材）從不同的業務數據庫中取過來集中處理，其中備菜過程就是數據的ETL過程，對數據做清洗轉換，將其轉變成可以被展現分析的數據。此處，廚房=數據倉庫，備菜=ETL過程。
第三步：將備好的菜放入鍋中，製作出可口的菜品 VS 利用BI前端工具，製作出易於理解的可視化報表我們備完菜後，就需要開始炒菜，要用到炒菜工具，這時BI前端工具就是炒菜用到的工具，把備好的菜拿出來，相當於選擇合適的數據來做可視化分析，最終的可視化報表就是餐廳裏可口的菜品。每個人都要喫不同的菜，那就要到不同的數據庫裏去找不同的數據，這就是臨時報表需求。到此，我們用一張圖來回顧上面三步，左右對應來理解做菜&企業數據處理間的巧妙對照關係：
再看上圖右邊，不難看出BI與數據倉庫之間的關係爲：BI將來自不同業務系統數據庫中的數據進行提取，取出有分析價值的數據做清洗、轉換和加載（ETL過程），再合併到數據倉庫中進行建模，最終在這個基礎上形成可視化分析報表，從而爲企業的管理決策層提供數據決策支撐。也就是說，雖然最終領導只看到了他們想要的分析報表，但這一套系統是需要數據倉庫和ETL在背後做數據支撐。到此，我們能得出初步結論：數據倉庫理論上是BI運行的基礎，BI需依賴數據倉庫去做數據分析。
再思考：國內數倉建設高成本現狀下，先數倉後BI還是唯一出路嗎？
讀到這你肯定會想問，既然都得出這個結論了，你標題還取“BI的建設是否一定離不開數據倉庫”幹嗎？這不是明擺着一定離不開嗎。誒，話先別說早，在上方我們確實得出初步結論：數據倉庫理論上是BI運行的基礎，BI需依賴數據倉庫做數據分析。但迴歸現實，從帆軟對國內近萬家企業的數據基礎調研結果來看，會發現理論再美好，現實還是給了企業當頭一棒。站在企業角度出發，數據倉庫從規劃到落地通常需要花費高昂的經濟成本和時間成本，但其創造的價值較難提前量化。所以許多有BI需求的企業會找到帆軟表示，他們在數倉巨大的投入成本以及未知的投入產出比的風險面前，沒法下定決心去建數倉，也導致其不敢上BI來滿足自身的數據需求。因此，當客戶帶着這個“先後難題”來找到我們時，也倒逼着我們不斷去思考：在國內數倉建設高成本現狀下，先數倉後BI還是唯一出路嗎？帆軟是否能給這些企業其他的解決方法？
先給結論，帆軟認爲：
數倉是BI的數據來源，因此先數倉後BI仍是唯一出路。但企業可根據自身數據情況建設適合自己的數倉，並非要建設完“完整數倉”，才能上BI。此處，我們分情況來說明：1、企業BI建設建立在完整的數據倉庫基礎上爲最佳。BI可直接連接數據倉庫梳理好的DWS層，將其作爲公共數據集，即可以讓業務同事基於相對規範的公共數據，無需代碼，自己可通過拖拉拽的方式進行自助數據分析/簡單報表的製作，從而通過數據去發現問題，解決問題。2、若企業並未建有完整數倉，帆軟建議這些想上BI、但無數倉基礎的公司，可藉助帆軟幫其快速建設輕量級的數倉，分階段完成BI與數倉的建設。
具體來說，即在企業數倉尚未搭建或分析思路尚未成型時，可先在帆軟BI平臺內抽取業務系統數據庫表，做輕量級的數據處理當中間數據庫，快速構建當下企業裏最緊急且重要的分析需求應用。在分析結果得到業務部門的初步認可驗證後，再拉通各部門認知，統一數據維度事實。最後將數據和複雜分析邏輯逐步沉澱固化到數據倉庫/BI平臺內，分層建模開發項目。
終總結：BI與數據倉庫的關係，BI的建設一定離不開數據倉庫嗎？
BI與數據倉庫的關係：
BI將來自不同業務系統數據庫中的數據進行提取，取出有分析價值的數據進行清洗、轉換和加載（ETL過程），再合併到數據倉庫中建模，最終在這個基礎上形成可視化分析報表，從而爲企業的管理決策層提供數據決策支撐。
BI的建設一定離不開數據倉庫嗎：
一個長遠優秀的BI項目建設一定離不開數據倉庫，但企業可根據自己的實際數據及預算情況來綜合考慮。在完善的數倉基礎上建設BI是錦上添花，但如果沒有數倉，也可通過“倒推”的方式，從前端最緊急的數據報表需求/自助分析數據需求來倒推中間數據庫的建設，等到後續企業數據及業務體系化上來，再將數據量擴容，搭建標準化數倉。這種“MVP”方法，能最大程度上確保企業分析決策的建設方向正確，實現真正有利於公司的商業價值，將試錯成本最小化。
在本文，主要講明瞭BI與數據倉庫之間的關係。而目前，帆軟已在BI商業智能領域深耕了17年，在國內BI市場佔有率連續五年第一。在爲用戶提供真正有價值的數據服務路上，我們一直保持初心，踏踏實實打磨數據產品，虛心也希望多接收大家的疑問和建議，因此如果想了解更多BI項目建設，可點擊下方鏈接，獲取更多BI與數倉建設相關資料。
※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※※
文章推薦
◆跟資料打交道的人都得會的這8種資料模型，滿足工作中95%的需求
關注數據君的臉書：
我是「數據分析那些事」。常年分享數據分析乾貨，不定期分享好用的職場技能工具。按贊我的臉書，會有豐富資料包贈送唷！
