我所經歷的大數據平臺發展史（四）：互聯網時代 • 下篇[轉]

編者按：本文是松子（李博源）的大數據平臺發展史系列文章的第四篇（共四篇），本系列以獨特的視角，比較了非互聯網和互聯網兩個時代以及傳統行業與非傳統行業。是對數據平臺發展的一個回憶，對非互聯網、互聯網，從數據平臺的用戶角度、數據架構演進、模型等進行了闡述。

在互聯網時代被弱化的數據模型

談起數據模型就不得不提傳統數據平臺架構發展，我相信很多朋友都曉得傳統數據平臺的知識，其架構演進簡單一句話說“基本上可以分為五個時代、四種架構”，但是到了互聯網時代因為大數據快速膨脹與數據源類型多樣化特點，從高階架構上來看大約從傳統數據平臺第三代架構開始延續的，但是往後的發展從我自己的這一點知識上很難對互聯網的數據平臺做架構歸類。

但是從數據平臺建設與服務角色上還是有章可循的。就像上篇分享到那樣，類比兩個行業，互聯網企業中員工年齡比非互聯網企業的要年輕、受教育程度、對計算機的焦慮程度明顯比傳統企業要低、還偶遇其它各方面的緣故，導致了數據平臺所面對用戶群體與非互聯網數據平臺有所差異化。

傳統行業與互聯網行業數據平臺用戶特性我只選擇前文章的兩張圖來表示

(點擊放大圖像)

(點擊放大圖像)

在傳統數據平臺要背後有一個完整數據倉庫團隊去服務業務方，業務方嗷嗷待哺的等待被動方式去滿足。中低層數據基本不會對業務方開放，所以不管數據模型採用何種建模方式，主要滿足當時數據架構規劃即可。

互聯網業務的快速發展使得大家已經從經營、分析的訴求重點轉為數據化的精細運營上，如何做好精細化運營問題上來，當資源不夠時用戶就叫喊，甚至有的業務方會挽起袖子來自己參與到從數據整理、加工、分析階段。

此時呢，原有建設數據平臺的多個角色（數據開發、模型設計）可能轉為對其它非專業使用數據方，做培訓、諮詢與落地，寫更加適合當前企業數據應用的一些方案與開發些數據產品等。

在互聯網數據平臺由於數據平臺變為自由開放，大家使用數據的人也參與到數據的體系建設時，基本會因為不專業性，導致數據質量問題、重複對分數據浪費存儲與資源、口徑多樣化、編碼不統一、命名問題等等原因。數據質量逐漸變成一個特別突出的問題。

傳統企業的數據源基本來自 excel、表格、DB 系統等，但在互聯網有網站點擊流日誌、視頻、音頻、圖片數據等很多非結構化快速產生與保存。移動互聯網除了互聯網那些外還含有大量定位數據、自動化傳感器、嵌入式設備、自動化設備等，傳統行業原有的數據平臺技術對處理如此複雜而多樣化的數據有些力不從心。

當數據模型逐漸被弱化後，數據架構導航圖少了、難以建立業務系統與數據之間的映射與轉換關係。數據描述經常不一致性。如：同名異義、同物異名。大量冗餘的存在。數據模型被弱化（數據倉庫模型）是傳統企業與互聯網企業一個蠻大的差異。但是呢，互聯網企業也有自己特點，傳統行業所涉及數據模型這個領域涉及的很多內容在互聯網變成以其他的曲線救國的方式存在了。

在互聯網曲線救國新解決

回顧在傳統行業數據平臺中，不管兩位大師爭論點數據模型的設計採用那種範式（Bill Inmon 的 EDW 的原則是準三範式的設計、Ralph kilmbal 是星型結構）但是都要非常重視數據源的質量問題。所以傳統行業的數據模型會全盤考慮數據質量問題，並通過數據抽樣分析給出合適的清洗口徑。

(點擊放大圖像)

上圖來自我 2009 年搞數據質量平臺工具數據產品內容之一。

但是在互聯網呢，數據質量在互聯網數據平臺變成了一種心病。（ps：我瞭解過一個公司，能讓數據平臺 + 數據分析師 + 業務多人“對數”對一年的還是不準的）。在應對數據的質量問題，目前互聯網有些做法是把數據標準化前置到業務數據產生就做，從根源上去杜絕數據質量，但是這種場景比較實用在 Log 日誌的數據源中，比如移動互聯網最近流行的基於事件模型“Event”模型，在日誌產生時就規定好存儲格式（備註：大家度娘搜索，“學習筆記：The Log（我所讀過的最好的一篇分佈式技術文章）” 對這個講解很詳細）。

在傳統行業，目前還是以混合模型設計方式為主。在互聯網的我所接觸的一些業務，在參照傳統數據模型方法論基礎上逐步演進適合互聯網數據的數據模型方法。

比如互聯網金融等一些業務會參考傳統金融行業對主題域的劃分、OMG 數據倉庫元數據管理 CWM 模型、FSDM 金融模型，再進一步考慮大數據處理特性去進行設計，所有從 Hight Level 數據架構圖看到主題層次劃分與傳統第三代數據倉庫還是很多相似之處，當然模型架構也有分三層、四層、五層的。

不同的地方模型細節處理上已經完全不一樣，比如數據的多樣性、拉寬事實表、度量值單獨存儲、滿足數據快速重生、維度的二次降維處理等、增加大量冗餘列、增加大量派生列，結合自動化元數據來耦合、合併等相關管理。

(點擊放大圖像)

上圖是支付寶非常早期數據模型

(點擊放大圖像)

上圖是支付寶非常早期數據模型

我們常提到的多維模型在大數據處理下進行了退化維度處理。大家知道 Olap 多維模型，隨著維度的增加事實表的數據量會成幾何指數暴增，即使在現有的大數據技術、新的 Olap 引擎對一個 Cube 的數據量要求也要在時間與數據量上需要做到用戶使用容忍度的平衡。

類似 Olap 的應用在互聯網這個奇特思維土壤中我經歷過一個曲線救國方式（2011-2012 年時設計多維挖掘分析數據產品背後的技術就是搜索引擎實現的），現在應該也有新技術出現了來解決類似的問題。

(點擊放大圖像)

上圖為 2012 年產品 UI 之一。

(點擊放大圖像)

上圖是 2011-2012 年該產品系列背後當時使用的技術

互聯網業務特點業務垂直拆分非常細，比如一個用戶註冊、密碼找回的流程有可能存在好幾個產品負責同一個業務流程不同環節，相關的一個策略、產品 feature 快速迭代上線等等都要數據評估。數據從前端埋點到採集然後再由各個環節到數據平臺，再有數據分析師或各業務部門去使用，基本拉長了時間週期。需求部門與實施部門能力和經驗有千差萬別的需求，造成了懂技術部門沒有沒有足夠的精力完全理解業務部門奇形怪狀需求，可能在各環節放緩與變的低效。

或許適合“敏捷”維度建模在當前是個不錯的選擇，如果一上來就想著建立一套能兼容所有數據和業務的數據模型，那就又回到傳統數據倉庫的建設上了，很難滿足對業務變化的快速響應。互聯網企業業務特點是變化非常迅速的，能穩定的業務達到 65% 算對數據平臺是個福音了（根據對某寶寶的印象）剩餘的業務變化迅速，必然導致數據模型快速上下線。

Kimball 老人家提出的維度建模（備註，在本系列發展史得第一篇有介紹）圍繞業務模型能夠非常直觀的表達出業務的數據關係，但是在互聯網 NOSQL 犧牲掉了關係型數據庫的一致性、完整性等等很多東西。維度數據模型又基於這些大數據技術的，所以進化的更加輕量級與基於細節數據的維度退化建模（原有的緩慢變化維、快速變化維、大維、迷你維、父子維、雪花維為了適應互聯網的大數據 Nosql 處理技術進行反規範化、化 & 數據冗餘設計。

退化維度的反規範化設計一方面可以把一條查詢語句所需要的所有數據組合起來放到一個地方存儲 Key values 的方式（比如說商品有不同類型，每一種類型商品又有自己的不同屬性，可以採用一對多、多對多的方式存儲，例如把一個多維映射為一個 Key value）。

講到互聯網數據平臺就要提數據模型，提了數據模型就要提 Nosql 技術，

(點擊放大圖像)

上圖來自 Nosql 文檔系列的一幅圖

Nosql 是大數據處理的特徵之一。互聯網數據平臺數據模型與 NoSql 技術還是蠻緊密的。這裡有外文講解 Nosql Data modeling technigues 從技術角度講解非常詳（ https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/ ）。

因為前邊提到的大數據平臺技術特性決定了傳統 edw 模型、維度模型直接在互聯網數據大數據平臺部署或許還有“好些未知”障礙等待大家去克服。同時在傳統數據建模用到的一些方法經過互聯網薰陶或許演進成一種新的數據產品或方案吧。

到此為止“我所經歷的大數據平臺發展史”上下共四篇與大家分享完畢，這個寫作前後經歷剛好一個月左右，算是對自己數據從業經歷回顧之一吧。在知識的整理中很多都是蜻蜓點水，每個知識域都是一個非常深的專業方向，自己涉足很膚淺，在文章中分享不足之處請各位讀者見諒！！

原文地址：https://www.infoq.cn/article/the-development-history-of-big-data-platform-internet-age

閱讀更多 架構師筆記 的文章

關鍵字: 美好，一直在身邊 Excel 外文