企業如何選擇數據分析架構？——談談3種架構的利弊

在以前的文章《講透大數據，我只須要一頓飯》裏，我用作飯這件你們身邊的事情來介紹了大數據及數據分析工程，應該可以讓你們對數據分析這件看上去很專業的行業有了必定的認識，很高興的是文章也獲得了不少數據圈專業人士的共鳴和互動。

這篇文章咱們會順着以前的思路，稍微深刻一點，聊聊數據分析架構。

什麼叫數據分析架構，說的通俗點，其實就是數據採集（買菜）、數據建模（配菜）、數據加工（炒菜）、數據分析（吃菜）這些數據分析流程應該如何劃分功能模塊（專業化分工），才能方便靈活、規模化、最大化的知足廣大數據消費者（吃貨）的數據分析（美食）需求。

就比如吃飯這件事，咱們能夠本身在廚房裏作，去飯店吃，或者叫外賣等不一樣方式，這幾種吃飯方式是人類生活方式的一種進化，更是經過不一樣的專業化分工知足了吃貨們不一樣時期、不一樣層次的需求。

而數據分析做爲一件相對來講比吃飯更專業的事情，也一樣須要經過流程設計和專業化分工來知足更普遍的數據消費需求，咱們一般叫作架構設計。

閒話少說，先直接上圖，我把迄今爲止的數據分析架構的歷史簡單分爲三個階段：

企業如何選擇數據分析架構？——談談3種架構的利弊
數據分析1.0階段：業務報表
這個階段是數據分析的初始階段。隨着數據庫技術的出現，企業紛紛開始信息化建設，業務流程信息化沉澱了大量數字化的業務數據，而數據分析的需求其實你們一直都有，既然有了數據沉澱，經過這些數據進行報表統計和數據分析的需求天然就出現了。

1.0階段，數據分析開始萌芽，數據加工、報表統計都在業務系統裏直接進行的（數據產生和數據分析都在同一個系統裏進行，因此這個時候尚未數據採集一說）。這就比如本身在家裏作飯吃，能夠想象，因爲食材（數據）、廚房（數據庫資源）、手藝（專業能力）等方面的限制，吃飯的體驗不會太好，主要知足吃飽（報表統計）的需求。

固然現代業務報表有了很大的改變，好比帆軟finereport一類的報表工具，能夠跨業務系統、跨數據庫取數作報表作分析，甚至對接數據集市、數據倉庫（接下來我正要說）。

企業如何選擇數據分析架構？——談談3種架構的利弊
finereport製做的dashboard

數據分析2.0階段：數據集市
因爲在業務系統裏直接作數據分析體驗很差，還可能會影響正常的業務流程，而企業數據分析的需求愈來愈完善，業務人員天然而然的但願在業務系統以外專門搭建一個用於數據分析的獨立新系統，既能用於支持數據分析，又能夠不影響正常的業務流程，因而，數據集市應運而生。

從數據集市開始，數據分析開始做爲一個正式的行業出現，出現了從業務系統到數據集市的數據採集和傳輸（買菜）需求，另外，數據加工，數據分析等專業崗位和從業人員開始出現。

這就比如飯店的出現使得在吃飯這件事上出現了專業化分工，同時也開創了餐飲行業。飯店裏有人專門買菜，配菜，炒菜，大廚開始出現，這一方式很好的知足了廣大吃貨在省事、美食選擇、口感方面的需求，體驗天然是棒棒的。

數據分析2.5階段：數據倉庫
隨着企業數據分析活動如火如荼的開展，數據集市開始越建越多，一樣的數據加工邏輯、指標等不免在分散的數據集市裏被重複計算，浪費計算資源不說，常常就會出現數據統計口徑不一致的問題，讓領導們不知道本身該相信哪一個數據。

這就比如飯店開的多了，一樣的菜品在不一樣的飯店裏不免會雷同，可是同一個「魚香肉絲」不一樣飯店作出來的的口味不免會不同，吃貨們確定會迷惑哪家纔是最正宗的，也但願知道哪一個纔是最好吃的。

這個時候，數據倉庫概念應運而生。

數據倉庫爲了解決數據集市分散建設帶來的數據不一致、重複計算浪費資源等問題，提倡以一個集中式平臺來統一進行數據採集、數據清洗、數據加工，而且向外部提供各類數據分析產品和服務。

數據倉庫算是開創了數據分析史真正意義上的一個時代，對數據分析行業的發展和成熟有着不可磨滅的貢獻：

誕生了專門的數據倉庫技術（MPP，massively parallel processing）以及一大批相關的專業廠商，來解決大量數據須要集中進行存儲、加工和分析的技術難題
發展了體系化的數據倉庫系統建設方法論和最佳實踐
培養了一大批數據倉庫從業人員(DWer)
既然，數據倉庫時代在數據分析史上有着如此重要的地位，而且在今天仍然有着深遠的影響，那麼，問題來了。

爲何數據倉庫階段只是2.5而不是3.0呢？
首先，從架構的角度來看，我的認爲數據倉庫相對於數據集市並無本質的區別，這個從上面的「數據分析架構發展的三個階段」圖中也能看出來，數據集市和數據倉庫的架構是很是類似的，數據倉庫能夠簡單的認爲是一個超級數據集市，區別只在於規模，這就比如爲了規範菜品質量，讓你們可以一站式吃到各類五花八門的菜品，咱們開了個超級大飯店，雖然這個飯店很大，但仍然是個飯店。

其次，數據倉庫以解決數據集市數據分散、數據口徑不統一爲目標，提出了打造企業級統一業務視圖的願景（The single view of business ），其建設方法強調數據採集規範化，數據管理標準化以及數據加工流程化，這種建設思路從數據管理的角度來講是很是有價值的，產出了不少成熟的數據管理規範和數據治理方法論。

但......是......

從數據分析的角度來看，雖然數倉系統的建設的確必定程度上知足了業務部門的數據分析需求，然而，傳統數據倉庫建設方法在靈活的支持各類數據需求、敏捷的響應分析請求、普及企業數據驅動的分析文化方面，卻始終愛莫能助。

形成這種狀況，雖然有着技術、成本方面的緣由，但架構耦合性高、建設方法過於僵化也是重要緣由，好比：

數據倉庫集中式的平臺架構方式，將數據加工和數據服務都經過一個平臺來支持，必然會形成資源競爭，沒法兼顧。這就比如一個飯店裏，後廚佔得地方太大，堂食的空間就小了，可以同時響應的消費者數量必然受到限制。
數據倉庫的數據加工是層層遞進、環環相扣的方式，有着嚴格的加工流程，而且涉及到多個角色的互相配合，任何一個數據分析需求，從需求的提出到最終實現，快的要好幾周，慢的要好幾個月，天然是跟不上業務的快速變化。客戶到了飯店，只要是想點個菜單上沒有的菜品，飯店都須要把買菜、洗菜、配菜、炒菜這些環節都走一遍，上菜起碼得等二、3個小時甚至是次日纔有，沒有哪一個消費者能忍受的了吧。
不少數倉採用數據驅動的建設方式，無論是否是須要的數據，先往倉庫裏放，總以爲之後會用的上，致使倉庫規模極速膨脹，而且存在大量無產出數據，運維成本和難度很是大。就好像開個飯店無論客人喜歡吃什麼，先把能買到的菜都買來，拋開成本不說，光是運輸、清洗、倉儲的工做量就能把人給耗死。
數倉建設有着成熟完善的數據治理配套理論，什麼元數據管理、數據標準管理、數據質量管理等等，可是這些理論的落地每每最走變成了一紙規範，卻無法和數據倉庫建設過程有機的結合，最後變成了你定你的規範，我建個人系統，或者是我先建系統，你再定規範，隨着系統愈來愈龐大，沒人可以很清楚的知道倉庫裏到底有什麼，整個數倉天然就變的難以管理和使用。
因而，雖然數據倉庫進行了數十年的發展，不少企業也是花了大量的人力和成原本進行數據倉庫系統的建設，但缺少敏捷性的平臺建設方式，自主選擇少，服務響應慢，各種數據消費者的滿意度始終都不高。

所以，慢慢的，不少企業中的數據倉庫系統，開始變得有點古代皇宮御膳房的味道，聚集各類食材，對於食材、流程、樣式有着嚴格的加工規範，充分保證了菜品的質量和水準，可是其上菜速度、翻檯率以及可以服務的食客數量都受到了極大的限制，因此只有能力爲特定羣體（皇家）提供各類特定的菜品。

企業如何選擇數據分析架構？——談談3種架構的利弊
因此，雖然數據倉庫對於數據存儲、數據採集、數據加工、數據治理這些方面發展了成熟的方法論（至關於專業的飯店後廚管理理論），但對於知足各類靈活、敏捷、普及的數據分析需求，其做用一直是被詬病的。

而進入到今天的大數據時代，這個弊病就更加的明顯。

大數據浪潮帶來的挑戰不只僅是數據量的爆發式增加，更重要的是把我的、企業、政府對數據、數據分析的重視性提高到了史無前例的高度，整個社會對數據分析的需求也呈現爆發式的增加。因此，Gartner提出了平民數據科學家（citizen data scientist）的概念，更有廠商和業內大牛喊出了「人人都是數據分析師」的口號。

企業如何知足成千上萬的內部員工對於數據分析的需求？企業如何知足千萬級以上的外部客戶對於數據分析的需求？政府如何知足上億的社會大衆對於數據分析的需求？這成了大數據時代的數據架構師們須要去回答的問題。

能夠說，用戶日益增加的數據分析需求與落後的數據服務能力之間的矛盾已經成爲大數據時代的主要矛盾。

因此，數據倉庫強調數據加工流程而忽視數據服務效率，過於嚴苛、繁瑣的建設方法，數據開發與數據治理脫節的問題，使得其難以快速進行規模化擴展，也就沒法應對爆發式的數據分析和數據服務需求，拋開技術、成本上的限制不說，傳統數倉的建設方法論顯然也是沒法解決大數據時代的主要矛盾的。

那，大數據時代，大數據分析架構的出路在哪呢？什麼樣的數據平臺建設方法纔是最有效的？是否能夠在數據倉庫成熟的建設方法論上進行改造來應對爆發式的數據分析需求？

轉自：https://www.toutiao.com/i6580...