問題：為什么傳統BI沒有達到今天互聯網數據應用的高度呢?

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

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

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

第一種形式，分散式

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

技術部負責搭建大數據平臺(在傳統主要叫數據倉庫)

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

分布式：hadoop 平臺;

實時計算: storm平臺

內存計算：spark 平臺

傳統關系數據庫

業務分析人員怎么得到數據：

方式一：向數據平臺接口人提需求，在傳統的BI部門中一定會有一種叫：需求分析/數據PD這種角度;這種角度就是把業務方的進行轉化，轉為PRD文檔，讓ETL開發工程師，報表開發工程師實現 。【業務人員是沒有訪問數據倉庫的權限的】

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

這種在一些業務變化不快，或者業務相對不那么復雜的公司可能比較好。但是如果是一些業務復雜，業務變化非常快的可能就不適合。為什么?

數據平臺/倉庫建議跟不上業務變化。造成數據倉庫效率低，數據口徑混亂。因為數據倉庫架構離業務比較遠，對業務理解不深。

業務數據分析師很多人的知識不能很有效沉淀下來。

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

最終公司數據混亂，后面大家對數據都搖頭。