企業常見的三種數據部門架構優與劣
問題：為什么傳統BI沒有達到今天互聯網數據應用的高度呢?
在之前的傳統BI可能因為這些因素，所以沒有達到今天的數據在高度，可能是互聯網本身發展的因素，數據對于互聯網企業價值。但其中有一個很大的因素，可能是傳統的BI，更多是偏重數據倉庫的架構，根據需求來幫報表。在數據部門沒有一批主動去思考業務，思考業務與數據關系的人。這種人很可能都是在業務方，他們更多把業務問題轉為要看的報表，然后與數據部門溝通報表開發，數據部門收集需求溝通后，進行排期，進入比較慢長的等待期。
在一個企業中，可能數據部門在一個公司中組織架構中的位置，決定了部門的定位和一些做的事情，所以個人認為數據部門所處的組織架構對數據價值實現是一個很重要因素。這也是今天我也來談一談的主題。
我先把數據部門分成二個部門：一個我們就叫前端，例如：數據分析，數據挖掘，數據產品等;一個我們叫后端：數據倉庫，大數據平臺等;
***種形式，分散式
數據平臺由技術部建設，技術沒有數據分析/業務分析人員;這部分人員都分到各個業務塊中。
技術部負責搭建大數據平臺(在傳統主要叫數據倉庫)
目前大數據平臺，如果比較大型的公司基本上會包括幾塊內容：
- 分布式：hadoop 平臺;
- 實時計算: storm平臺
- 內存計算：spark 平臺
- 傳統關系數據庫
業務分析人員怎么得到數據：
方式一：向數據平臺接口人提需求，在傳統的BI部門中一定會有一種叫：需求分析/數據PD這種角度;這種角度就是把業務方的進行轉化，轉為PRD文檔，讓ETL開發工程師，報表開發工程師實現 。【業務人員是沒有訪問數據倉庫的權限的】
方式二：當一些業務方比較強勢，或者對響應速度比較有意見的時候，可能會開放所有或者部分給業務人員進行去訪問，業務可以自己去寫SQL去取數據。
這種在一些業務變化不快，或者業務相對不那么復雜的公司可能比較好。但是如果是一些業務復雜，業務變化非常快的可能就不適合。為什么?
- 數據平臺/倉庫建議跟不上業務變化。造成數據倉庫效率低，數據口徑混亂。因為數據倉庫架構離業務比較遠，對業務理解不深。
- 業務數據分析師很多人的知識不能很有效沉淀下來。
這會導致業務要求為各個業務建議自己 “數據集市”，當這種數據集市我的時候，又會造成數據倉庫負擔中，各個業務方的數據“各大自為政”。
最終公司數據混亂，后面大家對數據都搖頭。
第二種形式，集權式
就是公司所有的數據相關都歸到一個部門中。業務方有任何需要都會向數據部門提出，數據部門會在內部對這些需求和報表進行溝通，避免重復開發，也便于對需求進行總結。
這種架構的好處是，所有的數據都是一個部門出，相對來說數據的口徑會比較統一;
這個架構的壞處，如果部門組織的不好。會造成數據部門離業務比較遠 ;有時候對于數據的思考不夠深入，造成與業務部門的溝通成本上升。同時會存在技術部的對于數據***層平臺建設的分工,造成與技術部存在一定溝通成本。
第三種：混合式
大數據平臺建設由技術負責，他們核心是把數據平臺建設的足夠強大。
有一個比較大的數據部門，負責數據分析，挖掘，數據統一工作。一般來說這個部門會直接像管理層匯報，主要服務公司管理層;同時也會和業務方的數據分析師合作一起解決某個具體問題。
在業務方也會有自己的小數據分析團隊。這個數據團隊主要服務由自己這個業務團隊，同時也會和公司的數據部門有溝通和合作。【有的公司會向業務團隊開放數據訪問權限，有的可能還是需要他們通過前端的報表獲取數據】
在這種情況下，可能存在主要問題是會"搶"活干。
每個方式都有各自的優點與缺點，沒有對與錯之分;還是要結合公司具體的業務情況，公司規模等來決定，如果一個公司的數據部門從小公司發展到大公司過程中組織架構都沒有什么變化，可能這不是一個適合有想法的數據人去的公司。哈哈
我個人觀點是：小公司適合分散式;公司發展中間階段：合適集權式;公司大的時候合適：混合式;
