問題：為什么傳統(tǒng)BI沒有達到今天互聯(lián)網數(shù)據(jù)應用的高度呢?

在之前的傳統(tǒng)BI可能因為這些因素，所以沒有達到今天的數(shù)據(jù)在高度，可能是互聯(lián)網本身發(fā)展的因素，數(shù)據(jù)對于互聯(lián)網企業(yè)價值。但其中有一個很大的因素，可能是傳統(tǒng)的BI，更多是偏重數(shù)據(jù)倉庫的架構，根據(jù)需求來幫報表。在數(shù)據(jù)部門沒有一批主動去思考業(yè)務，思考業(yè)務與數(shù)據(jù)關系的人。這種人很可能都是在業(yè)務方，他們更多把業(yè)務問題轉為要看的報表，然后與數(shù)據(jù)部門溝通報表開發(fā)，數(shù)據(jù)部門收集需求溝通后，進行排期，進入比較慢長的等待期。

在一個企業(yè)中，可能數(shù)據(jù)部門在一個公司中組織架構中的位置，決定了部門的定位和一些做的事情，所以個人認為數(shù)據(jù)部門所處的組織架構對數(shù)據(jù)價值實現(xiàn)是一個很重要因素。這也是今天我也來談一談的主題。

我先把數(shù)據(jù)部門分成二個部門：一個我們就叫前端，例如：數(shù)據(jù)分析，數(shù)據(jù)挖掘，數(shù)據(jù)產品等;一個我們叫后端：數(shù)據(jù)倉庫，大數(shù)據(jù)平臺等;

***種形式，分散式

數(shù)據(jù)平臺由技術部建設，技術沒有數(shù)據(jù)分析/業(yè)務分析人員;這部分人員都分到各個業(yè)務塊中。

技術部負責搭建大數(shù)據(jù)平臺(在傳統(tǒng)主要叫數(shù)據(jù)倉庫)

目前大數(shù)據(jù)平臺，如果比較大型的公司基本上會包括幾塊內容：

1. 分布式：hadoop 平臺;
2. 實時計算: storm平臺
3. 內存計算：spark 平臺
4. 傳統(tǒng)關系數(shù)據(jù)庫

業(yè)務分析人員怎么得到數(shù)據(jù)：

方式一：向數(shù)據(jù)平臺接口人提需求，在傳統(tǒng)的BI部門中一定會有一種叫：需求分析/數(shù)據(jù)PD這種角度;這種角度就是把業(yè)務方的進行轉化，轉為PRD文檔，讓ETL開發(fā)工程師，報表開發(fā)工程師實現(xiàn) ?！緲I(yè)務人員是沒有訪問數(shù)據(jù)倉庫的權限的】

方式二：當一些業(yè)務方比較強勢，或者對響應速度比較有意見的時候，可能會開放所有或者部分給業(yè)務人員進行去訪問，業(yè)務可以自己去寫SQL去取數(shù)據(jù)。

這種在一些業(yè)務變化不快，或者業(yè)務相對不那么復雜的公司可能比較好。但是如果是一些業(yè)務復雜，業(yè)務變化非?？斓目赡芫筒贿m合。為什么?

1. 數(shù)據(jù)平臺/倉庫建議跟不上業(yè)務變化。造成數(shù)據(jù)倉庫效率低，數(shù)據(jù)口徑混亂。因為數(shù)據(jù)倉庫架構離業(yè)務比較遠，對業(yè)務理解不深。
2. 業(yè)務數(shù)據(jù)分析師很多人的知識不能很有效沉淀下來。

這會導致業(yè)務要求為各個業(yè)務建議自己 “數(shù)據(jù)集市”，當這種數(shù)據(jù)集市我的時候，又會造成數(shù)據(jù)倉庫負擔中，各個業(yè)務方的數(shù)據(jù)“各大自為政”。

最終公司數(shù)據(jù)混亂，后面大家對數(shù)據(jù)都搖頭。

第二種形式，集權式

就是公司所有的數(shù)據(jù)相關都歸到一個部門中。業(yè)務方有任何需要都會向數(shù)據(jù)部門提出，數(shù)據(jù)部門會在內部對這些需求和報表進行溝通，避免重復開發(fā)，也便于對需求進行總結。

這種架構的好處是，所有的數(shù)據(jù)都是一個部門出，相對來說數(shù)據(jù)的口徑會比較統(tǒng)一;

這個架構的壞處，如果部門組織的不好。會造成數(shù)據(jù)部門離業(yè)務比較遠 ;有時候對于數(shù)據(jù)的思考不夠深入，造成與業(yè)務部門的溝通成本上升。同時會存在技術部的對于數(shù)據(jù)***層平臺建設的分工,造成與技術部存在一定溝通成本。

第三種：混合式

大數(shù)據(jù)平臺建設由技術負責，他們核心是把數(shù)據(jù)平臺建設的足夠強大。

有一個比較大的數(shù)據(jù)部門，負責數(shù)據(jù)分析，挖掘，數(shù)據(jù)統(tǒng)一工作。一般來說這個部門會直接像管理層匯報，主要服務公司管理層;同時也會和業(yè)務方的數(shù)據(jù)分析師合作一起解決某個具體問題。

在業(yè)務方也會有自己的小數(shù)據(jù)分析團隊。這個數(shù)據(jù)團隊主要服務由自己這個業(yè)務團隊，同時也會和公司的數(shù)據(jù)部門有溝通和合作?！居械墓緯驑I(yè)務團隊開放數(shù)據(jù)訪問權限，有的可能還是需要他們通過前端的報表獲取數(shù)據(jù)】

在這種情況下，可能存在主要問題是會"搶"活干。

每個方式都有各自的優(yōu)點與缺點，沒有對與錯之分;還是要結合公司具體的業(yè)務情況，公司規(guī)模等來決定，如果一個公司的數(shù)據(jù)部門從小公司發(fā)展到大公司過程中組織架構都沒有什么變化，可能這不是一個適合有想法的數(shù)據(jù)人去的公司。哈哈

我個人觀點是：小公司適合分散式;公司發(fā)展中間階段：合適集權式;公司大的時候合適：混合式;