文：李博源

從「數據倉庫」一詞到現在的「大數據」，中間經歷了太多的知識、架構模式的演進與變革。數據平臺這25年究竟是怎樣進化的？

我是從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

OLAP 服務器：2*PIV1GHZ,2G,2*40GSCSI

• 開發環境：VISUAL BASIC,ASP,SQL SERVER 2000

?

數據倉庫第二代架構

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

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

數據集市架構

?

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

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

?

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

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

新一代架構OPDM 操作型數據集市(倉庫)

OPDM大約是在2011年提出來的，嚴格上來說，OPDM 操作型數據集市（倉庫）是實時數據倉庫的一種，他更多的是面向操作型數據而非歷史數據查詢與分析。

數據模型

”數據模型“ 這個詞只要是跟數據沾邊就會出現的一個詞。

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

?

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

（備注：Data cleaning 是指的數據清洗 數據質量相關不管是在哪個行業，是最令人頭痛的問題，分業務域、技術域的數據質量問題，需要通過事前盤點、事中監控、事后調養，有機會在闡述）。

?

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

• 有利于數據的整合。數據模型是整合各種數據源指導圖，對現有業務與數據從邏輯層角度進行了全面描述，通過數據模型，可以建立業務系統與數據之間的映射與轉換關系。排除數據描述的不一致性。如：同名異義、同物異名..。

• 減少多余冗余數據，因為了解數據之間的關系，以及數據的作用。在數據平臺中根據需求采集那些用于分析的數據，而不需要那些純粹用于操作的數據。

數據模型在數據平臺的數據倉庫中是一個統稱，嚴格上來講分為概念模型、邏輯模型、物理模型。(備注：四類模型如何去詳細構建文本不深講，關于非互聯網企業的數據模型網上非常多)

?

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

轉存失敗重新上傳取消

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

轉存失敗重新上傳取消

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

數 據模型的業務建模階段、領域概念模型階段、邏輯模型階段、物理模型階段是超級學術與復雜的話題，而且在模型領域根據特點又分主數據(MDM)、CIF（企 業級統一視圖） 、通用模型(IBM 的金融、保險行業通用模型、 Terdata的 金融通用模型、 電信移動通用模型等)，鎖涉及到術語”擴展“、”扁平化“、”裁剪“等眼花繚亂的建模手法，數據模型不同層次ODS、DWD

DWD、DW、ST的分層目的不同導致模型設計方法又不同。相信業界有很多大牛能講的清楚的，以后有機會再交流。

?

?

互聯網時代數據源

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

（備注：IBM的科學家分析員道格.萊尼的一份數據增長報告基礎上提出了大數據的4V特性 大數據4v特性網上概念很多大家可以問度娘）。

我在這里整理一個表格不同時代數據源的差異性（備注可能整理的有點不全）：

數據平臺的用戶：

總結下來互聯網的數據平臺“服務”方式迭代演進大約可以分為三個階段。

階段一 ：

約在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吞吐量以及有限的任務并發安排到了網站日志的處理以及給分析師提供的數據分析服務。

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

階段二：

互聯網的數據平臺除了受到技術、數據量的驅動外，同時還來自數據產品經理梳理用戶的需求按照產品的思維去構建并部署在了數據的平臺上。互聯網是一個擅長制造流程新概念的行業。

約 在2011年到2014 年左右，隨著數據平臺的建設逐漸的進入快速迭代期，數據產品、數據產品經理這兩個詞逐漸的升溫以及被廣泛得到認可（備注：數據產品相關內容個人會在數據產 品系列中做深入分享），同時數據產品也隨著需求、平臺特性分為面向用戶級數據產品、面向平臺工具型產品兩個維度分別去建設數據平臺。

?

• 企業各個主要角色都是數據平臺用戶。

• 各類數據產品經理（偏業務數據產品、偏工具平臺數據產品）推進數據平臺的建設。

• 分析師參與數據平臺直接建設比重增加。

• 數據開發、數據模型角色都是數據平臺的建設者與使用者（備注：相對與傳統數據平臺的數據開發來說，逐漸忽略了數據質量的關注度，數據模型設計角色逐漸被弱化）。

• 用戶面對是數據源多樣化，比如日志、生產數據庫的數據、視頻、音頻等非結構化數據 。
• 原有ETL中部分數據轉換功能逐漸前置化，放到業務系統端進行（備注：部分原有在ETL階段需要數據標準化一些過程前置在業務系統數據產生階段進行，比如Log 日志。 移動互聯網的日志標準化。

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

?

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

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

?

階段三：

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

?

• 給用戶提供的各類豐富的分析、取數的產品，簡單上手的可以使用。

• 原有ETL、數據模型角色轉為給用戶提供平臺、產品、數據培訓與使用咨詢。

• 數據分析師直接參與到數據平臺過程、數據產品的建設中去。
• 用戶面對是數據源多樣化，比如日志、生產數據庫的數據、視頻、音頻等非結構化數據 。

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

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

總結

以上是生活随笔為你收集整理的从数据仓库到大数据，数据平台这25年是怎样进化的？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。