[[152620]]

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

在之前的傳統(tǒng)BI可能因為這些因素，所以沒有達到今天的數(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è)務，思考業(yè)務與數(shù)據(jù)關(guān)系的人。這種人很可能都是在業(yè)務方，他們更多把業(yè)務問題轉(zhuǎn)為要看的報表，然后與數(shù)據(jù)部門溝通報表開發(fā)，數(shù)據(jù)部門收集需求溝通后，進行排期，進入比較慢長的等待期。

在一個企業(yè)中，可能數(shù)據(jù)部門在一個公司中組織架構(gòu)中的位置，決定了部門的定位和一些做的事情，所以個人認為數(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è)務分析人員；這部分人員都分到各個業(yè)務塊中。

技術(shù)部負責搭建大數(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è)務分析人員怎么得到數(shù)據(jù)：

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

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

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

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

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

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

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

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

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

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

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

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

第三種：混合式

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

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

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

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

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

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