商業(yè)智能BI在面向報表和模型開發(fā)時,有什么不同?
企業(yè)在面試商業(yè)智能BI技術開發(fā)人員,發(fā)現(xiàn)基本上90%的人分不清什么是面向報表開發(fā),什么是面向模型開發(fā),不明白這個問題背后的意思。10%左右的人稍微暗示一下,大概就懂你想了解的是什么了,這10%的是真正有過完整的數(shù)據(jù)倉庫設計開發(fā)經(jīng)驗的人。
所以,企業(yè)在以后招聘的商業(yè)智能BI開發(fā)人員的時候也可以拿這個問題問的試試看,可以很容易篩選出來候選人之前做BI是什么做的,或者到底有沒有數(shù)據(jù)倉庫設計開發(fā)經(jīng)驗。?

這個差異就在于面向報表開發(fā)的形式基本上就是用戶給什么報表,就寫SQL拼接數(shù)據(jù)集去展現(xiàn)什么樣的報表。在底層數(shù)據(jù)架構中大概率就是將各個業(yè)務系統(tǒng)數(shù)據(jù)源的數(shù)據(jù)拉通整合到一個數(shù)據(jù)庫中,該清洗的還是會清洗,但是在架構上考慮的很少。這一類的商業(yè)智能BI開發(fā)人員的經(jīng)驗大概率做的都是報表取數(shù)、報表開發(fā)一類的工作。
通常會有兩個明顯的短板:
第一,業(yè)務敏感度不高。即使做了很多的報表開發(fā),但是讓講下具體的業(yè)務是講不出來的,或者講的很散、深度不夠,非體系化輸出。這就是因為業(yè)務報表本身就是一張一張甩過來的,看完表樣就取數(shù)開發(fā)了,是以報表結果為導向的,很少從整體上去思考業(yè)務的關聯(lián)性,自然也就不會注意到業(yè)務本身。
第二,不太懂底層數(shù)據(jù)架構,對數(shù)據(jù)倉庫有了解但不會很深入。這個并不是因為大家不努力或者技術真的就不行,而是因為身邊的人做BI報表開發(fā)都是這么做的,從入行開始接觸的就是這種方式,所以在經(jīng)驗上很難有所突破。?

在面試工作五六年、七八年、上十年的,都會碰到這樣的一類人,SQL寫的很溜,報表出的也很快,但讓體系化的講講這些業(yè)務就很難,對底層數(shù)據(jù)倉庫架構理解的不夠深入,碰到一些大項目、長周期的項目還是會有一些認知上的盲區(qū)和瓶頸。
面試的時候覺得自己的技術怎么著都很牛了,做了那么多的項目,開發(fā)了那么多的報表。但是過來一面試,把一些實際的場景一擺出來,10個問題可能只能答上2個。知道自己還有不會的東西,想學習。其實,技術上一般問題都不會太大,只是看問題的思維層次、面上夠不夠的問題。
就像面向模型開發(fā),這就是一種思維方式。只是把用戶給的報表作為梳理指標和維度的參考,在實際設計底層數(shù)據(jù)架構的時候,除了數(shù)據(jù)的拉通和清洗之外,重點考慮的是數(shù)據(jù)分析模型的通用性和可擴展性。
?

換句話說,在設計底層數(shù)據(jù)倉庫架構的時候根本就不受用戶報表的影響。怎么出報表這是以后的事,這個階段不考慮這個問題。我們要考慮的是怎么樣用一個模型或者幾個模型支撐到更多的分析報表,而不是一個SQL一個數(shù)據(jù)集的去支撐用戶的報表。
這兩者的思維方式差別是非常大的,BI項目落地的結果自然也是完全不同的。特別是體現(xiàn)在BI項目的二期、三期,差別會非常的明顯。按照面向報表開發(fā)思維的設計方式,BI項目大概率是很難繼續(xù)下去的,因為架構不具備高度的擴展性,底層模型不規(guī)范,復用度低,基本上是以用戶提出的報表為引導進行開發(fā)的。就跟裝修房子一樣,用戶想要什么效果就設計裝修成什么效果,但是忽略了底層的架構。當用戶的需求在二期、三期不斷增加的時候、經(jīng)常性調整的時候,這種架構就很難支撐起來,一動底層架構就是破壞性的。?

還有一點也是我們商業(yè)智能BI開發(fā)人員需要注意的:就算很多商業(yè)智能BI開發(fā)人員在設計數(shù)據(jù)倉庫的時候是按照Kimball維度建模架構去搭建的,但是仍然很容易受到業(yè)務人員給到的報表的影響,做著做著數(shù)據(jù)倉庫的底層模型就又變成了跟業(yè)務報表字段對應的報表開發(fā)模式,這種做法也是錯的。
記住一點:在Kimball維度建模中,對事實表的設計是完全依賴于業(yè)務物理活動的度量事件,不會受到可能產生的最終報表的影響,這就是面向模型開發(fā)思維的核心思想之一。所以在標準的DW層,事實表的設計一定是描述最基礎性的事實動作,構建基礎的事實表。在DM數(shù)據(jù)集市層,可以為了一些查詢性能、便利性等原因建立一些表來適配一些報表要求。?

在標準DW層,事實表按業(yè)務還原分拆,根據(jù)需要在DM層進行事實表的組合合并。這樣在架構上既能夠保證底層基礎事實表的穩(wěn)健性、靈活性和可擴展性,又保證了DM層往前端BI報表供數(shù)的高性能和便捷性。
?