為什麼要建資料倉儲，而不是直連資料來源？

各位資料的朋友，大家好，我是老周道資料，和你一起，用常人思維+資料分析，透過資料講故事。

 

今天和大家聊一個話題： 為什麼BI軟體要用構建資料倉儲，而不是直連資料來源的方式開發報表 ？

在與企業IT的交流過程中，經常會討論到一個話題，就是做 BI資料視覺化分析 報表時，是 建資料倉儲好，還是直連資料來源好。這個話題，在很多年前非常普遍，近幾年少了許多，但仍然會有一些客戶會問：“奧威BI軟體支援在同一個報表中訪問不同的資料來源嗎？ ”

可以肯定地 回答，奧威BI軟體在技術上是支援的。但是，我們強烈反對使用這種方式來開發報表，我們建議大家先將不同資料來源的資料，轉換到同一個資料倉儲中，進行必要的清洗與規範，再進行開發。很多IT會反對說，這樣不是很麻煩嗎？

是的，這樣相對來說，是麻煩了一點。但，很多事情在複雜的演化過程中，麻煩變成了主流。

我們來對比一下，農村建房子和城市建房子有什麼不同？農村建房子，一般建個兩三層，所以，壘幾塊磚做地基，就開始往上建，是很快，但是，大家都知道，這樣的房子建不高，如果想再加高，就得推倒重建。而城市裡建房子，則是一塊地，一圍就是半年一年甚至更長，這是在幹什麼呢？這是在挖地基，樓建的越高，地基挖的就越深。

前一段時間 ， 我經常開車經過的一段路， 開通了 紅綠燈。本來車流量不大，沒有紅綠燈的情況下，通行效率會更高，所以，對此頗為不解。後來看到通行的行人，才明白，這個紅綠燈雖然降低了車的通行效率，卻提高了行人的安全保障。

曾經有一個段子，說一個軟體公司請了一個開發高手，老闆問他，你一個人開發完這個專案需要多長時間？高手說2個月，老闆心裡想，這個專案很著急，需要1個月完成，於是說，如果給你增加2個人，你需要多少時間？高手回答：4個月？老闆瘋了，為什麼啊？人不是越多幹活越快嗎？高手說，給我增加2個人，我還得和他們溝通，要檢查他們的程式碼，還不如我一個人開發來得快。

其實，奧威也是一樣，研發剛開始就幾個人，1個人就要承擔一個大的產品模組的開發，包括需求梳理、程式碼開發、功能測試等。但是，當產品的功能、客戶的需求以及使用量越來越多 的時候，很多問題就開始暴露出來，特別是產品的效能與穩定性，而這些問題非常影響客戶的正常使用。於是，慢慢的就開始進行分工，將架構設計、需求規劃、程式碼開發、產品測試都獨立開來，再後來，程式碼開發還區分後臺開發與前端開發，再後來，從物件導向開發跨向微服務開發……就像剛才段子裡說的那樣，人一多，溝通的成本就增加，程式碼的複雜度也在增加，整個開發的進度明顯變慢。但是，奧威BI軟體經過幾次的技術迭代之後，產品的效能不會因為功能的增加而變慢，也不會因為功能的增加而變得不穩定，也大幅減少了修復了一個bug，又帶出三個新bug的情況。很難想像，如果我們還按以前作坊式的開發方式，奧威BI軟體是否還能生存下來。

再看我們現在的 交通網路，城際主幹網為飛機或高鐵，市內主要是地鐵或公交，最後一公里則是共享單車或步行。我經常出差，200公里內，一般採取自駕的方式，200-1500公里，則通常用高鐵，1500公里以上，則採取飛行的方式。我最喜歡的是自駕的方式在珠三角出差，因為這樣方便且高效。但是，一旦超過200公里，我就只能選擇其他方式了，因為其他方式雖然麻煩一些，但卻變得更高效。通常我在有地鐵的城市見客戶，也基本不叫車，雖然坐地鐵麻煩，但比叫車在時間上更可靠。

講了這麼多，就是想說，BI的建設我們不能圖一時之快，能省事就省事，而要圖長遠，這個平臺可以支撐起未來公司3-5年甚至更長時間的持續最佳化，深入應用，那麼，這個時候，就必須要用略顯麻煩的方式去滿足未來複雜場景下的高效，穩定執行。所謂的複雜場景，就是指越來越多的人使用，越來越多的需求場景，越來越多的資料量。其實，現在更大型的企業已經在資料倉儲的基礎上，衍生的更復雜，包括資料中臺、資料湖等等。這些高大上的概念，大家有興趣的話，可以自行去百度，簡單的說來， 資料倉儲主要是為決策提供資料支援，資料中臺則不僅包含為決策提供資料支援，還多了為不同業務系統提供資料支援；而資料湖呢，它更強調保持資料的原汁原味，包含很多非結構資料，也不強調資料治理，更多是希望藉助AI技術進行深度資料價值挖掘。那對於我們這些非網際網路企業來說， 構建好資料倉儲就已經足夠應對未來5-10年的複雜需求場景了。

 

說了半天，好像都沒有搞明白，為什麼直連資料來源就像是農村一樣建房，而構建資料倉儲則是建高樓大廈的地基呢？

舉例說明：

假如我們需要從ERP、MES、HR、CRM中取數製作一張老闆要的大屏，分別展示財務、生產、人力與客戶的情況，可以按不同時間篩選 。

1、 直連資料來源

小強用直連資料來源並分別將老闆關心的資料用寫SQL的方式獲得，並在BI軟體上製作出大屏。這 肯定是最快的。但是，當大屏做好之後，老闆突然覺得這還不夠，希望能按組織篩選不同事業部或分公司的資料。這個時候，小強就傻眼了。為什麼呢？因為ERP、MES、HR、CRM中組織這個基礎資料都不一樣，同一個事業部或分公司，在不同的系統裡編碼不一樣，名稱叫法可能都不一樣，甚至組織劃分的方式都不同。最後，沒辦法，只好透過一系列複雜的操作，想辦法在前端實現篩選時，可以得到一致的結果，加了幾個通宵班，才勉強交差。

又過了一段時間，老闆又有了新的想法，希望能往下鑽取，分別要看到不同事業部或分公司的更多維度的資料。這下可慘了，小強又得折騰一段時間，並且瑟瑟發抖，祈禱老闆不要有新的想法。

2、資料倉儲：

用資料倉儲的方法就不會出現上述這種情況。 只要打好了資料倉儲這個地基，後面老闆有任何的想法，都可以基於資料倉儲與分析模型，前端拖拽即可實現，立等可取！

到底怎麼構建資料倉儲呢？

奧威BI軟體根據近20年的經驗，開發出一套適用於絕大多數企業的通用資料底座，不管企業用的是用友金蝶ERP，還是其他的MES或HR，都可以按這個資料底座進行對接，將構建資料倉儲的時間大幅壓縮。

 

 

 

構建資料倉儲，打好堅實的地基，BI大廈才能越建越高！

 

老周道資料，和你一起，用常人思維+資料分析，透過資料講故事，我們下一講再見！