摘要： 在之前的文章《講透大數據，我只需要一頓飯》里，用做飯這件大家身邊的事情來介紹了大數據及資料分析工程，應該能夠讓大家對資料分析這件看上去很專業的行業有了一定的認識，很高興的是文章也得到了很多資料圈專業人士的共鳴和互動。 這篇文章我們會順著之前的思路，稍微深入一點，聊聊資料分析架構。
什麼叫資料分析架構，說的通俗點，其實就是資料採集（買菜）、資料建模（配菜）、資料加工（炒菜）、資料分析（吃菜）這些資料分析流程應該如何劃分功能模塊（專業化分工），才能方便靈活、規模化、最大化的滿足廣大數據消費者（吃貨）的資料分析（美食）需求。
就好比吃飯這件事，我們可以自己在廚房裡做，去飯店吃，或者叫外賣等不同方式，這幾種吃飯方式是人類生活方式的一種進化，更是通過不同的專業化分工滿足了吃貨們不同時期、不同層次的需求。
而資料分析作為一件相對來說比吃飯更專業的事情，也同樣需要通過流程設計和專業化分工來滿足更廣泛的資料消費需求，我們通常叫做架構設計。
閑話少說，先直接上圖，我把迄今為止的資料分析架構的歷史簡單分為三個階段：
資料分析1.0階段：業務報表
業務報表階段是資料分析的初始階段。隨著資料庫技術的出現，企業紛紛開始資訊化建設，業務流程資訊化沉澱了大量數字化的業務資料，而資料分析的需求其實大家一直都有，既然有了資料沉澱，通過這些資料進行報表統計和資料分析的需求自然就出現了。
1.0階段，資料分析開始萌芽，資料加工、報表統計都在業務系統里直接進行的（資料產生和資料分析都在同一個系統里進行，所以這個時候還沒有資料採集一說）。這就好比自己在家裡做飯吃，可以想像，由於食材（資料）、廚房（資料庫資源）、手藝（專業能力）等方面的限制，吃飯的體驗不會太好，主要滿足吃飽（報表統計）的需求。
當然現代業務報表有了很大的改變，比如帆軟finereport一類的報表製作工具，可以跨業務系統、跨資料庫取數做報表做分析，甚至對接資料超市、資料倉儲（接下來我正要說）。
finereport製作的dashboard
資料分析2.0階段：資料超市（Data Mart）
由於在業務系統里直接做資料分析體驗不好，還可能會影響正常的業務流程，而企業資料分析的需求越來越完善，業務人員自然而然的希望在業務系統之外專門搭建一個用於資料分析的獨立新系統，既能用於支持資料分析，又可以不影響正常的業務流程，於是，資料超市應運而生。
從資料超市開始，資料分析開始作為一個正式的行業出現，出現了從業務系統到資料超市的資料採集和傳輸（買菜）需求，另外，資料加工，資料分析等專業崗位和從業人員開始出現。
這就好比飯店的出現使得在吃飯這件事上出現了專業化分工，同時也開創了餐飲行業。飯店裡有人專門買菜，配菜，炒菜，大廚開始出現，這一方式很好的滿足了廣大吃貨在省事、美食選擇、口感方面的需求，體驗自然是棒棒的。
資料分析2.5階段：資料倉儲（Data Warehouse）
隨著企業資料分析活動如火如荼的開展，資料超市開始越建越多，同樣的資料加工邏輯、指標等難免在分散的資料超市裡被重複計算，浪費計算資源不說，經常就會出現資料統計口徑不一致的問題，讓管理者們不知道自己該相信哪個資料。
這就好比飯店開的多了，同樣的菜品在不同的飯店裡難免會雷同，也就是同一個「魚香肉絲」不同飯店做出來的的口味難免會不一樣，吃貨們肯定會迷惑哪家才是最正宗的，也希望知道哪個才是最好吃的。
這個時候，資料倉儲概念應運而生。
資料倉儲為了解決資料超市分散建設帶來的資料不一致、重複計算浪費資源等問題，提倡以一個集中式平台來統一進行資料採集、資料清理、資料加工，並且向外部提供各種資料分析產品和服務。
資料倉儲算是開創了資料分析史真正意義上的一個時代，對資料分析行業的發展和成熟有著不可磨滅的貢獻：
誕生了專門的資料倉儲技術（MPP，massively parallel processing）以及一大批相關的專業廠商，來解決大量資料需要集中進行存儲、加工和分析的技術難題
發展了體系化的資料倉儲系統建設方法論和最佳實踐
培養了一大批資料倉儲從業人員(DWer)
既然，資料倉儲時代在資料分析史上有著如此重要的地位，並且在今天仍然有著深遠的影響，那麼，問題來了。
為什麼資料倉儲階段只是2.5而不是3.0呢？
首先，從架構的角度來看，個人認為資料倉儲相對於資料超市並沒有本質的區別，這個從上面的「資料分析架構發展的三個階段」圖中也能看出來，資料超市和資料倉儲的架構是非常相似的，資料倉儲可以簡單的認為是一個超級資料超市，區別只在於規模，這就好比為了規範菜品質量，讓大家能夠一站式吃到各種五花八門的菜品，我們開了個超級大飯店，雖然這個飯店很大，但仍然是個飯店。
其次，資料倉儲以解決資料超市資料分散、資料口徑不統一為目標，提出了打造企業級統一業務視圖的願景（The single view of business ），其建設方法強調資料採集規範化，資料管理標準化以及資料加工流程化，這種建設思路從資料管理的角度來說是非常有價值的，產出了很多成熟的資料管理規範和資料治理方法論。
但……是……
從資料分析的角度來看，雖然數倉系統的建設的確一定程度上滿足了業務部門的資料分析需求，然而，傳統資料倉儲建設方法在靈活的支援各種資料需求、敏捷的響應分析請求、普及企業資料驅動的分析文化方面，卻始終心有餘而力不足。
造成這種情況，雖然有著技術、成本方面的原因，但架構耦合性高、建設方法過於僵化也是重要原因，比如：
資料倉儲集中式的平台架構方式，將資料加工和資料服務都通過一個平台來支援，必然會造成資源競爭，無法兼顧。這就好比一個飯店裡，後廚佔得地方太大，堂食的空間就小了，能夠同時響應的消費者數量必然受到限制。
資料倉儲的資料加工是層層遞進、環環相扣的方式，有著嚴格的加工流程，並且涉及到多個角色的互相配合，任何一個資料分析需求，從需求的提出到最終實現，快的要好幾周，慢的要好幾個月，自然是跟不上業務的快速變化。客戶到了飯店，只要是想點個菜單上沒有的菜品，飯店都需要把買菜、洗菜、配菜、炒菜這些環節都走一遍，上菜起碼得等2、3個小時甚至是第二天才有，沒有哪個食客能忍受的了吧。
很多數倉採用資料驅動的建設方式，不管是不是需要的資料，先往倉庫里放，總覺得以後會用的上，導致倉庫規模極速膨脹，並且存在大量無產出資料，運維成本和難度非常大。就好像開個飯店不管客人喜歡吃什麼，先把能買到的菜都買來，拋開成本不說，光是運輸、清洗、倉儲的工作量就能把人給耗死。
數倉建設有著成熟完善的資料治理配套理論，什麼元資料管理、資料標準管理、資料質量管理等等，但是這些理論的落地往往最走變成了一紙規範，卻沒法和資料倉儲建設過程有機的結合，最後變成了你定你的規範，我建我的系統，或者是我先建系統，你再定規範，隨著系統越來越龐大，沒人能夠很清楚的知道倉庫里到底有什麼，整個數倉自然就變的難以管理和使用。
於是，雖然資料倉儲進行了數十年的發展，很多企業也是花了大量的人力和成本來進行資料倉儲系統的建設，但缺乏敏捷性的平台建設方式，自主選擇少，服務響應慢，各類資料消費者的滿意度始終都不高。
因此，慢慢的，很多企業中的資料倉儲系統，開始變得有點古代皇宮御膳房的味道，彙集各種食材，對於食材、流程、樣式有著嚴格的加工規範，充分保證了菜品的質量和水準，但是其上菜速度、翻台率以及能夠服務的食客數量都受到了極大的限制，所以只有能力為特定群體（皇家）提供各種特定的菜品。
所以，雖然資料倉儲對於資料存儲、資料採集、資料加工、資料清理這些方面發展了成熟的方法論（相當於專業的飯店後廚管理理論），但對於滿足各種靈活、敏捷、普及的資料分析需求，其作用一直是被詬病的。
而進入到今天的大數據應用時代，這個弊病就更加的明顯。
大數據浪潮帶來的挑戰不僅僅是資料量的爆髮式增長，更重要的是把個人、企業、政府對資料、資料分析的重視性提升到了前所未有的高度，整個社會對資料分析的需求也呈現爆髮式的增長。所以，Gartner提出了平民資料科學家（citizen data scientist）的概念，更有廠商和業內大牛喊出了「人人都是資料分析師」的口號。
企業如何滿足成千上萬的內部員工對於資料分析的需求？企業如何滿足千萬級以上的外部客戶對於資料分析的需求？政府如何滿足上億的社會大眾對於資料分析的需求？這成了大數據時代的資料架構師們需要去回答的問題。
可以說，用戶日益增長的資料分析需求與落後的資料服務能力之間的矛盾已經成為大數據時代的主要矛盾。
所以，資料倉儲強調資料加工流程而忽視資料服務效率，過於嚴苛、繁瑣的建設方法，資料開發與資料治理脫節的問題，使得其難以快速進行規模化擴展，也就無法應對爆髮式的資料分析和資料服務需求，拋開技術、成本上的限制不說，傳統數倉的建設方法論顯然也是無法解決大數據時代的主要矛盾的。
資料分析1.0階段：業務報表
業務報表階段是資料分析的初始階段。隨著資料庫技術的出現，企業紛紛開始資訊化建設，業務流程資訊化沉澱了大量數字化的業務資料，而資料分析的需求其實大家一直都有，既然有了資料沉澱，通過這些資料進行報表統計和資料分析的需求自然就出現了。
1.0階段，資料分析開始萌芽，資料加工、報表統計都在業務系統里直接進行的（資料產生和資料分析都在同一個系統里進行，所以這個時候還沒有資料採集一說）。這就好比自己在家裡做飯吃，可以想像，由於食材（資料）、廚房（資料庫資源）、手藝（專業能力）等方面的限制，吃飯的體驗不會太好，主要滿足吃飽（報表統計）的需求。
當然現代業務報表有了很大的改變，比如帆軟finereport一類的報表製作工具，可以跨業務系統、跨資料庫取數做報表做分析，甚至對接資料超市、資料倉儲（接下來我正要說）。
finereport製作的dashboard
資料分析2.0階段：資料超市（Data Mart）
由於在業務系統里直接做資料分析體驗不好，還可能會影響正常的業務流程，而企業資料分析的需求越來越完善，業務人員自然而然的希望在業務系統之外專門搭建一個用於資料分析的獨立新系統，既能用於支持資料分析，又可以不影響正常的業務流程，於是，資料超市應運而生。
從資料超市開始，資料分析開始作為一個正式的行業出現，出現了從業務系統到資料超市的資料採集和傳輸（買菜）需求，另外，資料加工，資料分析等專業崗位和從業人員開始出現。
這就好比飯店的出現使得在吃飯這件事上出現了專業化分工，同時也開創了餐飲行業。飯店裡有人專門買菜，配菜，炒菜，大廚開始出現，這一方式很好的滿足了廣大吃貨在省事、美食選擇、口感方面的需求，體驗自然是棒棒的。
資料分析2.5階段：資料倉儲（Data Warehouse）
隨著企業資料分析活動如火如荼的開展，資料超市開始越建越多，同樣的資料加工邏輯、指標等難免在分散的資料超市裡被重複計算，浪費計算資源不說，經常就會出現資料統計口徑不一致的問題，讓管理者們不知道自己該相信哪個資料。
這就好比飯店開的多了，同樣的菜品在不同的飯店裡難免會雷同，也就是同一個「魚香肉絲」不同飯店做出來的的口味難免會不一樣，吃貨們肯定會迷惑哪家才是最正宗的，也希望知道哪個才是最好吃的。
這個時候，資料倉儲概念應運而生。
資料倉儲為了解決資料超市分散建設帶來的資料不一致、重複計算浪費資源等問題，提倡以一個集中式平台來統一進行資料採集、資料清理、資料加工，並且向外部提供各種資料分析產品和服務。
資料倉儲算是開創了資料分析史真正意義上的一個時代，對資料分析行業的發展和成熟有著不可磨滅的貢獻：
誕生了專門的資料倉儲技術（MPP，massively parallel processing）以及一大批相關的專業廠商，來解決大量資料需要集中進行存儲、加工和分析的技術難題
發展了體系化的資料倉儲系統建設方法論和最佳實踐
培養了一大批資料倉儲從業人員(DWer)
既然，資料倉儲時代在資料分析史上有著如此重要的地位，並且在今天仍然有著深遠的影響，那麼，問題來了。
為什麼資料倉儲階段只是2.5而不是3.0呢？
首先，從架構的角度來看，個人認為資料倉儲相對於資料超市並沒有本質的區別，這個從上面的「資料分析架構發展的三個階段」圖中也能看出來，資料超市和資料倉儲的架構是非常相似的，資料倉儲可以簡單的認為是一個超級資料超市，區別只在於規模，這就好比為了規範菜品質量，讓大家能夠一站式吃到各種五花八門的菜品，我們開了個超級大飯店，雖然這個飯店很大，但仍然是個飯店。
其次，資料倉儲以解決資料超市資料分散、資料口徑不統一為目標，提出了打造企業級統一業務視圖的願景（The single view of business ），其建設方法強調資料採集規範化，資料管理標準化以及資料加工流程化，這種建設思路從資料管理的角度來說是非常有價值的，產出了很多成熟的資料管理規範和資料治理方法論。
但……是……
從資料分析的角度來看，雖然數倉系統的建設的確一定程度上滿足了業務部門的資料分析需求，然而，傳統資料倉儲建設方法在靈活的支援各種資料需求、敏捷的響應分析請求、普及企業資料驅動的分析文化方面，卻始終心有餘而力不足。
造成這種情況，雖然有著技術、成本方面的原因，但架構耦合性高、建設方法過於僵化也是重要原因，比如：
資料倉儲集中式的平台架構方式，將資料加工和資料服務都通過一個平台來支援，必然會造成資源競爭，無法兼顧。這就好比一個飯店裡，後廚佔得地方太大，堂食的空間就小了，能夠同時響應的消費者數量必然受到限制。
資料倉儲的資料加工是層層遞進、環環相扣的方式，有著嚴格的加工流程，並且涉及到多個角色的互相配合，任何一個資料分析需求，從需求的提出到最終實現，快的要好幾周，慢的要好幾個月，自然是跟不上業務的快速變化。客戶到了飯店，只要是想點個菜單上沒有的菜品，飯店都需要把買菜、洗菜、配菜、炒菜這些環節都走一遍，上菜起碼得等2、3個小時甚至是第二天才有，沒有哪個食客能忍受的了吧。
很多數倉採用資料驅動的建設方式，不管是不是需要的資料，先往倉庫里放，總覺得以後會用的上，導致倉庫規模極速膨脹，並且存在大量無產出資料，運維成本和難度非常大。就好像開個飯店不管客人喜歡吃什麼，先把能買到的菜都買來，拋開成本不說，光是運輸、清洗、倉儲的工作量就能把人給耗死。
數倉建設有著成熟完善的資料治理配套理論，什麼元資料管理、資料標準管理、資料質量管理等等，但是這些理論的落地往往最走變成了一紙規範，卻沒法和資料倉儲建設過程有機的結合，最後變成了你定你的規範，我建我的系統，或者是我先建系統，你再定規範，隨著系統越來越龐大，沒人能夠很清楚的知道倉庫里到底有什麼，整個數倉自然就變的難以管理和使用。
於是，雖然資料倉儲進行了數十年的發展，很多企業也是花了大量的人力和成本來進行資料倉儲系統的建設，但缺乏敏捷性的平台建設方式，自主選擇少，服務響應慢，各類資料消費者的滿意度始終都不高。
因此，慢慢的，很多企業中的資料倉儲系統，開始變得有點古代皇宮御膳房的味道，彙集各種食材，對於食材、流程、樣式有著嚴格的加工規範，充分保證了菜品的質量和水準，但是其上菜速度、翻台率以及能夠服務的食客數量都受到了極大的限制，所以只有能力為特定群體（皇家）提供各種特定的菜品。
所以，雖然資料倉儲對於資料存儲、資料採集、資料加工、資料清理這些方面發展了成熟的方法論（相當於專業的飯店後廚管理理論），但對於滿足各種靈活、敏捷、普及的資料分析需求，其作用一直是被詬病的。
而進入到今天的大數據應用時代，這個弊病就更加的明顯。
大數據浪潮帶來的挑戰不僅僅是資料量的爆髮式增長，更重要的是把個人、企業、政府對資料、資料分析的重視性提升到了前所未有的高度，整個社會對資料分析的需求也呈現爆髮式的增長。所以，Gartner提出了平民資料科學家（citizen data scientist）的概念，更有廠商和業內大牛喊出了「人人都是資料分析師」的口號。
企業如何滿足成千上萬的內部員工對於資料分析的需求？企業如何滿足千萬級以上的外部客戶對於資料分析的需求？政府如何滿足上億的社會大眾對於資料分析的需求？這成了大數據時代的資料架構師們需要去回答的問題。
可以說，用戶日益增長的資料分析需求與落後的資料服務能力之間的矛盾已經成為大數據時代的主要矛盾。
所以，資料倉儲強調資料加工流程而忽視資料服務效率，過於嚴苛、繁瑣的建設方法，資料開發與資料治理脫節的問題，使得其難以快速進行規模化擴展，也就無法應對爆髮式的資料分析和資料服務需求，拋開技術、成本上的限制不說，傳統數倉的建設方法論顯然也是無法解決大數據時代的主要矛盾的。
轉貼自： FineReport
留下你的回應
以訪客張貼回應