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

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

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

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

第一種形式，分散式

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

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

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

1、分布式：hadoop 平臺;

2、實時計算: storm平臺

3、內(nèi)存計算：spark 平臺

4、傳統(tǒng)關(guān)系數(shù)據(jù)庫

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

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

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

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

1、數(shù)據(jù)平臺/倉庫建議跟不上業(yè)務(wù)變化。造成數(shù)據(jù)倉庫效率低，數(shù)據(jù)口徑混亂。因為數(shù)據(jù)倉庫架構(gòu)離業(yè)務(wù)比較遠(yuǎn)，對業(yè)務(wù)理解不深。

2、業(yè)務(wù)數(shù)據(jù)分析師很多人的知識不能很有效沉淀下來。

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

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

第二種形式，集權(quán)式

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

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

這個架構(gòu)的壞處，如果部門組織的不好。會造成數(shù)據(jù)部門離業(yè)務(wù)比較遠(yuǎn) ;有時候?qū)τ跀?shù)據(jù)的思考不夠深入，造成與業(yè)務(wù)部門的溝通成本上升。

同時會存在技術(shù)部的對于數(shù)據(jù)最底層平臺建設(shè)的分工,造成與技術(shù)部存在一定溝通成本。

第三種：混合式

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

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

在業(yè)務(wù)方也會有自己的小數(shù)據(jù)分析團(tuán)隊。這個數(shù)據(jù)團(tuán)隊主要服務(wù)由自己這個業(yè)務(wù)團(tuán)隊，同時也會和公司的數(shù)據(jù)部門有溝通和合作。【有的公司會向業(yè)務(wù)團(tuán)隊開放數(shù)據(jù)訪問權(quán)限，有的可能還是需要他們通過前端的報表獲取數(shù)據(jù)】

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

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

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