BI進入國內已經有一些年頭了，國內外IT巨頭都紛紛搶灘這個領域，一些中小軟體企業也涉足其中。零售、製造業、快消品、航空、金融、電信等行業都成為BI實施的重要領地。
但是，說句不客氣的話，大部分BI專案都是失敗的，至少是問題重重，根本達不到客戶的要求，資料質量、系統效能是首當其衝的主要問題。
從業人員中，50%以上都嚴重不合格，做出來的東西質量也就可想而知。
1、先說架構和設計。大部分architect看多了人家的架構設計，基本上也能拼湊個architecture出來，無非4層而已：Operational Source Systems; Data Staging Area; Data Presentation Area; Data Access Tools，或者其變異品種，或者名稱稍有不同，實質都差不多。
然後是ETL的架構設計和報表層的架構設計。
看似很簡單是吧。但是，有多少專案組真正做過非常詳盡的調查？資料結構、主外來鍵檢查、引用完整性、值範圍、列長度限制、空值檢查、合法/不合法的值列表、隱含的業務規則等等。
如果有多個源系統，資料一般會出現不一致，不一致有多少？有沒有詳細的清單？如何建立企業主資料？如果這些都沒考慮，或者做得不詳盡，那麼這個專案基本上可以說在忽悠客戶。
源系統這關過了，接下來就是data staging，為何要staging? 如何staging? staging哪些？staging形式? staging效能？staging中要做哪些清洗、轉換、一致性處理、補充、去重？在哪個環節做？先後順序？
然後是資料載入到資料倉儲/資料集市，在載入前，代理鍵的分配，遲到維度資訊的處理，早到事實資料的處理，這些都考驗設計者的智慧和經驗。
但是，根據筆者的從業經驗，很多專案組壓根沒考慮到其中的很多東西，甚至壓根不知道還會有這種問題存在，所以最終做出來的東西資料質量一塌糊塗，也就絲毫不奇怪了。
好了，資料終於裝載到資料倉儲了，下面要做什麼呢？大家都知道要做劇集。
但是，可能的查詢成千上萬，你聚集哪些？聚集太多了，重新整理本身就要耗費太多時間，本來是為了提高查詢效能的，結果客戶左等右等，最後被告知系統還在重新整理聚集。
本來客戶每天早上要看報表的，結果你一個ETL加一個聚集處理，還有其他相關計算花了2天還沒跑完，於是只好忽悠客戶伺服器效能不夠、資料庫記憶體太小，等等亂七八糟的藉口，你還不如干脆建議客戶每週看一次報表好了。
2、資料倉儲建模
大部分建模師也都知道維度建模、去正規化設計，大的方面基本上都知道。但是，建模最考驗人的是細節，我就見過很多資料模型主體上還是去正規化設計的，維度表、事實表都俱在，但是一深入瞭解，就發現建模師骨子裡還是3NF的設計思維，因為除了主體之外的正規化設計比比皆是。
SCD(緩慢變化維)也都知道如何處理，但是對於快速變化維表、巨型維度表、數量眾多的只有很少記錄的維表、複雜的層級關係處理、多對一關係的處理，就往往不知所措了。
更要命的是對於粒度的把握，要麼粗了，導致最終很多查詢實現不了；要麼細了，導致資料太多，影響效能；或者粒度雖然對路了，但是相應的維度表粒度不匹配，於是弄出五花八門的補救辦法。
3、效能調優
當醜媳婦最終見公婆的時候，老底曝光，效能不可能好，於是開始tuning performance，左調右調，效能也改善不了多少。於是又開始忽悠客戶升級伺服器，加記憶體。
按我的觀點，效能根本就不是調出來的，而是設計出來的，你從開始各種設計就有問題，到後期怎麼調也是沒有用的。先把資料倉儲建模、聚集的設計、 ETL的設計做好了，然後再從OS、DBMS、SQL三方面去最佳化，資料庫哪些segment應該放在不同的硬碟上，如何partition，哪些聚集放到哪些partition上，SQL不能只圖寫著方便而不考慮其效能，該建哪些索引，建什麼樣的索引，這些都影響著效能。
所以大部分BI系統最終效能不好絲毫不足為奇，設計的人就不夠專業或者考慮不周詳，效能最佳化的人經驗又不足，ETL開發者、報表開發者往往只會工具，對於SQL和各種指令碼沒有深入的掌握，這樣做出來的東西效能自然好不到哪裡去。
4、從業人員的問題
大部分人只會個工具，ETL工具，報表工具等等，甚至工具都沒有會到很精深，更別談真正領會其內涵。我就曾經做過一個ETL，要抽取的資料在無格式的日誌檔案中，而且該日誌是最好的資料來源。
報表也是，簡單的都會，一到極其複雜的多主題、複雜的統計就瞎了，客戶的需求有時候比較怪異，非要把完全不相干的東西整到一張報表中，你還必須實現。但是從業務上考慮，他那樣的需求有其合理性，你看似不相干的東西，或者認為不必要的跨行計算，他能從中一眼看出東西來。
我就曾經給銀行做過一個超級複雜的報表，把各種不同的信貸全部在一個報表裡統計，有橫向的統計，有縱向的統計，還有小計，逾期的分期的上期的當期的全部在一張表當中，還要分為account-level和customer-level兩種統計方式。
我整整用了4層的subquery來進行各種分組統計，再把結果集作為上一層的源資料，還用了N多的集合操作。寫好了之後，對於一個上千行的SQL我心裡也沒底，結果一執行，效能還不錯，幾分鐘就跑出來了，業務部門的人一核對，資料也都正確。這東西，你要是僅用報表工具來實現是很困難的。
很多公司在招人時，為了節省成本，招幾個水平較高的，再招一大堆剛入門的，以為這樣的搭配就可以提高整體水平。我並不否認新手當中確實有學習能力強、聰明、邏輯思維能力不錯的，這種人很快就能成長起來，但是大部分人你永遠別指望他們能成為一個合格的軟體工程師。
管理也存在很大問題，軟體業就是軟體業，它不是製造業，你拿管理生產線的方式管理軟體開發，只能帶出來一支士氣低落、木訥遲鈍、毫無創造力、實施水平也低下的隊伍來。
客戶呢，比較迷信大公司，因為大公司實力雄厚有保障、有成熟的管理。其實大公司也好，小公司也好，最終做事的還是那麼幾個人，這幾個人的素質、技術水平和責任心決定了專案的成敗，大公司無非是做砸了換一撥人再上，耗得起。
但問題是客戶耗不起，一個好好的專案最後往往以悲劇收場，花了幾百萬幾千萬，最終效能低下，質量堪憂，莫說決策支援了，連裝點個門面都嫌寒磣。