從數據倉庫到大數據，數據平臺這25年是怎樣進化的？

數據產品&數據分析總監，2000年開始從事數據領域，從業傳統制造業、銀行、保險、第三方支付&互聯網金融、在線旅行、移動互聯網行業 。

我是從2000年開始接觸數據倉庫，大約08年開始進入互聯網行業。很多從傳統企業數據平臺轉到互聯網同學是否有感覺：非互聯網企業、互聯網企業的數據平臺所面向用戶群體是不同的。那麼，這兩類的數據平臺的建設、使用用戶又有變化？數據模型設計又有什麼不同呢？我們先從兩張圖來看用戶群體的區別。

用戶群體之非互聯網數據平臺用戶

企業的boss、運營的需求主要是依賴於報表、商業智能團隊的數據分析師去各種分析與挖掘探索；

支撐這些人是ETL開發工程師、數據模型建模、數據架構師、報表設計人員 ，同時這些角色又是數據平臺數據建設與使用方。數據平臺的技術框架與工具實現主要有技術架構師、JAVA 開發等。用戶面對是結構化生產系統數據源。

用戶群體之互聯網數據平臺用戶

互聯網企業中員工年齡比非互聯網企業的要年輕、受教育程度、對計算機的焦慮程度明顯比傳統企業要低、還偶遇其它各方面的緣故，導致了數據平臺所面對用戶群體與非互聯網數據平臺有所差異化；

互聯網數據平臺的使用與建設方是來自各方面的人，數據平臺又是技術、數據產品推進建設的。分析師參與數據平臺直接建設比重增加。原有的數據倉庫開發與模型架構師的職能也從建設平臺轉為服務與諮詢。用戶面對是數據源多樣化，比如日誌、生產數據庫的數據、視頻、音頻等非結構化數據 。從這用戶群體角度來說這非互聯網、互聯網的數據平臺用戶差異性是非常明顯，互聯網數據平臺中很多理論與名詞都是從傳統數據平臺傳遞過來的，本文將會分別闡述非互聯網、互聯網數據平臺區別。

非互聯網時代

自從數據倉庫發展起來到現在，基本上可以分為五個時代、四種架構

• 約在1991年前的全企業集成
• 1991年後的企業數據集成EDW時代
• 1994年-1996年的數據集市
• 1996-1997年左右的兩個架構吵架
• 1998年-2001年左右的合併年代

數據倉庫第一代架構（2001-2002年） 海爾集團的一個BI項目，架構的ETL 使用的是 微軟的數據抽取加工工具 DTS，老人使用過微軟的DTS 知道有哪些弊端，後便給出了幾個DTS的截圖。

① 功能：進銷存分析、閉環控制分析、工貿分析等
② 硬件環境：
· 業務系統數據庫：DB2 for Windows,SQL SERVER2000,ORACLE8I
· 中央數據庫服務器：4*EXON,2G,4*80GSCSI

數據倉庫第二代架構

這是上海通用汽車的一個數據平臺，別看複雜，嚴格意義上來講這是一套EDW的架構、在EDS數據倉庫中採用的是準三範式的建模方式去構建的、大約涉及到十幾種數據源，建模中按照某一條主線把數據都集成起來。

這個數據倉庫平臺計劃三年的時間構建完畢，第一階段計劃構建統統一生性週期視圖、客戶統一視圖的數據，完成對數據質量的摸底與部分實施為業務分析與信息共享提供基礎平臺。第二階段是完成主要業務數據集成與視圖統一，初步實現企業績效管理。第三階段全面完善企業級數據倉庫，實現核心業務的數據統一。

這個是國內某銀行的一套數據集市，這是一個典型數據集市的架構模式、面向客戶經理部門的考慮分析。

數據倉庫混合性架構(Cif)

這是太平洋保險的數據平臺，目前為止我認識的很多人都在該項目中呆過，當然是保險類的項目。

回過頭來看該平臺架構顯然是一個混合型的數據倉庫架構。它有混合數據倉庫的經典結構，每一個層次功能定義的非常明確。

數據模型

“ 數據模型”這個詞只要是跟數據沾邊就會出現的一個詞。在構建過程中，有一個角色理解業務並探索分散在各系統間的數據，並通過某條業務主線把這些分散在各角落的數據串聯並存儲同時讓業務使用，在設計時苦逼的地方除了考慮業務數據結構要素外，還得考慮可操作性、約束性（備註 約束性是完成數據質量提升的一個關鍵要素，未來新話題主題會討論這些），這個既要顧業務、數據源、合理的整合的角色是數據模型設計師，又叫數據模型師。

平臺中模型設計所關注的是企業分散在各角落數據、未知的商業模式與未知的分析報表，通過模型的步驟，理解業務並結合數據整合分析，建立數據模型為Data cleaning 指定清洗規則、為源數據與目標提供ETL mapping （備註：ETL 代指數據從不同源到數據平臺的整個過程，ETL Mapping 可理解為 數據加工算法，給數碼看的，互聯網與非互聯網此處差異性也較為明顯，非互聯網數據平臺對ETL定義與架構較為複雜）支持、 理清數據與數據之間的關係。

大家來看一張較為嚴謹的數據模型關係圖：

數據模型是整個數據平臺的數據建設過程的導航圖。

· 有利於數據的整合。數據模型是整合各種數據源指導圖，對現有業務與數據從邏輯層角度進行了全面描述，通過數據模型，可以建立業務系統與數據之間的映射與轉換關係。排除數據描述的不一致性。如：同名異義、同物異名..。
· 減少多餘冗餘數據，因為了解數據之間的關係，以及數據的作用。在數據平臺中根據需求採集那些用於分析的數據，而不需要那些純粹用於操作的數據。
· 數據模型在數據平臺的數據倉庫中是一個統稱，嚴格上來講分為概念模型、邏輯模型、物理模型。

Bill Inmon對EDW 的定義是面向事物處理、面向數據管理，從數據的特徵上需要堅持維護最細粒度的數據、維護最微觀層次的數據關係、保存數據歷史。所以在構建完畢的數據平臺中可以從中映射並檢查業務信息的完整性（同時也是養數據過程中的重要反饋點），這種方式還可以找出多個系統相關和重合的信息，減少多個系統之間數據的重複定義和不一致性，減小了應用集成的難度。

Ralph kilmball 對DM（備註：數據集市，非挖掘模型）的定義是面向分析過程的(Analytical Process oriented)，因為這個模型對業務用戶非常容易理解，同時為了查詢也是做了專門的性能優化。所以星型、雪花模型很直觀比較高性能為用戶提供查詢分析。

該方式的建模首先確定用戶需求問題與業務需求數據粒度，構建分析所需要的維度、與度量值形成星型模型；（備註 涉及的複雜維度、退化維度等不在這個討論範圍）。

數據模型的業務建模階段、領域概念模型階段、邏輯模型階段、物理模型階段是超級學術與複雜的話題，而且在模型領域根據特點又分主數據(MDM)、CIF（企業級統一視圖） 、通用模型(IBM 的金融、保險行業通用模型、 Terdata的 金融通用模型、 電信移動通用模型等)，鎖涉及到術語”擴展“、”扁平化“、”裁剪“等眼花繚亂的建模手法，數據模型不同層次ODS、DWD。DWD、DW、ST的分層目的不同導致模型設計方法又不同。相信業界有很多大牛能講的清楚的，以後有機會再交流。

互聯網時代

數據源做數據的人，從非互聯網進入到互聯網最顯著的特點是面對的數據源類型忽然多了起來，在傳統企業數據人員面對的是結構化存儲數據，基本來自excel、表格、DB系統等，在數據的處理技術上與架構上是非常容易總結的，但是在互聯網因為業務獨特性導致了所接觸到的數據源特性多樣化，網站點擊日誌、視頻、音頻、圖片數據等很多非結構化快速產生與保存，在這樣的數據源的多樣化與容量下采用傳統數據平臺技術來處理當然是有些力不從心了這裡我整理了一個表格不同時代數據源的差異性：

數據平臺的用戶：總結下來互聯網的數據平臺“服務”方式迭代演進大約可以分為三個階段。階段一 ： 約在2008年-2011年初的互聯網數據平臺，那時建設與使用上與非互聯網數據平臺有這蠻大的相似性，主要相似點在數據平臺的建設角色、與使用到的技術上。

• 老闆們、運營的需求主要是依賴於報表、分析報告、臨時需求、商業智能團隊的數據分析師去各種分析、臨時需求、挖掘，這些角色是數據平臺的適用方。
• ETL開發工程師、數據模型建模、數據架構師、報表設計人員 ，同時這些角色又是數據平臺數據建設與使用方。
• 數據平臺的技術框架與工具實現主要有技術架構師、JAVA開發等。
• 用戶面對是結構化的生產數據、PC端非結構化log等 數據。
• ELT的數據處理方式（備註在數據處理的方式上，由傳統企業的ETL 基本進化為ELT）。

現在的淘寶是從2004年開始構建自己的數據倉庫，2004年是採用DELL 的6650單節點、到2005年更換為 IBM 的P550 再到2008年的12節點 Rac 環境。在這段時間的在IBM、EMC、Oracle 身上的投入巨大，同時淘寶的數據集群也變為國內最大的數據倉庫集群。

隨著2010年引入了hadoop&hive平臺進行新一代的數據平臺的構建，此時的Greenplum 因為優秀的IO吞吐量以及有限的任務併發安排到了網站日誌的處理以及給分析師提供的數據分析服務。

該階段的數據模型是根據業務的特性採用退化、扁平化的模型設計方式去構建的。

• 企業各個主要角色都是數據平臺用戶。
• 各類數據產品經理（偏業務數據產品、偏工具平臺數據產品）推進數據平臺的建設。
• 分析師參與數據平臺直接建設比重增加。
• 數據開發、數據模型角色都是數據平臺的建設者與使用者
• 用戶面對是數據源多樣化，比如日誌、生產數據庫的數據、視頻、音頻等非結構化數據 。
• 原有ETL中部分數據轉換功能逐漸前置化，放到業務系統端進行（備註：部分原有在ETL階段需要數據標準化一些過程前置在業務系統數據產生階段進行，比如Log 日誌。移動互聯網的日誌標準化。

互聯網企業隨著數據更加逐漸被重視，分析師、數據開發在面對大量的數據需求、海量的臨時需求疲憊不堪，變成了資源的瓶頸，在當時的狀態傳統的各類的Report、Olap 工具都無法滿足互聯網行業個性化的數據需求。開始考慮把需求固定化變為一個面向最終用戶自助式、半自助的產品來滿足快速獲取數據&分析的結果，當總結出的指標、分析方法（模型）、使用流程與工具有機的結合在一起時數據產品就誕生了（記得我當時為了設計一個數據產品曾經閱讀了某個部門的2000多個臨時需求與相關SQL）。

數據產品按照面向的功能與業務可以劃分為面向平臺級別的工具型產品、面向用戶端的業務級數據產品。按照用戶分類可以分為面向內部用戶數據產品，面向外部用戶個人數據產品、商戶數據產品。

面向平臺級別有數據質量、元數據、調度、資管配置、數據同步分發等等。

約2010-2012年的平臺結構

約2012-2013年的平臺結構

階段三：用數據的一些角色（分析師、運營或產品）會自己參與到從數據整理、加工、分析階段。當數據平臺變為自由全開放，使用數據的人也參與到數據的體系建設時，基本會因為不專業型，導致數據質量問題、重複對分數據浪費存儲與資源、口徑多樣化等等原因。此時原有建設數據平臺的多個角色可能轉為對其它非專業做數據人員的培訓、諮詢與落地寫更加適合當前企業數據應用的一些方案等。

• 給用戶提供的各類豐富的分析、取數的產品，簡單上手的可以使用。
• 原有ETL、數據模型角色轉為給用戶提供平臺、產品、數據培訓與使用諮詢。
• 數據分析師直接參與到數據平臺過程、數據產品的建設中去。
• 用戶面對是數據源多樣化，比如日誌、生產數據庫的數據、視頻、音頻等非結構化數據 。

在互聯網這個大數據浪潮下，2016年以後數據平臺是如何去建設？如何服務業務？

企業的不同發展階段數據平臺該如何去建設的？這個大家是可以思考的。但是我相信互聯網企業是非常務實的，基本不會採用傳統企業的自上而下的建設方式，互聯網企業的業務快速變與迭代要求快速分析到數據，必須新業務數據迭代，老業務數據快速去雜。敏捷數據平臺或許是種不錯的選擇方法之一吧！

請您 1.關注作者~ 您的關注是我寫作的最大動力

2.私信我“大數據”

我將與您分享一套最新的大數據學習教程和全套開發工具

閱讀更多 阿福班主任 的文章

關鍵字: 支付 Microsoft 數據倉庫