互聯(lián)網(wǎng)的特點就是看中的“用戶體驗”，我也是通過數(shù)據(jù)平臺服務(wù)的用戶變遷來分享的這個系列。

我相信很多同僚都曉得傳統(tǒng)數(shù)據(jù)平臺的知識，其架構(gòu)演進簡單一句話說基本上可以分為“五個時代、四種架構(gòu)”，但是到了互聯(lián)網(wǎng)時代因為大數(shù)據(jù)快速膨脹與類型暴增的特點，從高階架構(gòu)上來看大約從第三代架構(gòu)開始延續(xù)的，但是從我自己的知識上很難對互聯(lián)網(wǎng)的數(shù)據(jù)平臺做架構(gòu)歸類，只有劍走偏鋒。

因為，我發(fā)現(xiàn)互聯(lián)網(wǎng)企業(yè)中員工年齡比非互聯(lián)網(wǎng)企業(yè)的要年輕，受教育程度和對計算機的焦慮程度明顯比傳統(tǒng)企業(yè)要低，還偶遇其它各方面的緣故，導(dǎo)致了數(shù)據(jù)平臺所面對用戶群體與非互聯(lián)網(wǎng)數(shù)據(jù)平臺有所差異化。

意識到用戶對數(shù)據(jù)平臺之間的相互依賴協(xié)作形式，是可以劃分互聯(lián)網(wǎng)數(shù)據(jù)平臺演進的一種不錯的維度。

傳統(tǒng)行業(yè)與互聯(lián)網(wǎng)行業(yè)數(shù)據(jù)平臺，用戶特性我只選擇了兩張圖來表示（大家互聯(lián)網(wǎng)篇章看到，基本也可以分為三個時代）

互聯(lián)網(wǎng)業(yè)務(wù)的快速發(fā)展使得大家已經(jīng)從經(jīng)營、分析的訴求重點轉(zhuǎn)為數(shù)據(jù)化的精細運營上，如何做好精細化運營問題，當(dāng)資源不夠時用戶就叫喊，甚至有的業(yè)務(wù)挽起袖子自己參與到從數(shù)據(jù)整理、加工、分析階段。

此時，原有建設(shè)數(shù)據(jù)平臺的多個角色（數(shù)據(jù)開發(fā)、模型設(shè)計）可能轉(zhuǎn)為對其它非專業(yè)使用數(shù)據(jù)方，做培訓(xùn)、咨詢與落地，更加適合當(dāng)前企業(yè)數(shù)據(jù)應(yīng)用的一些方案與開發(fā)些數(shù)據(jù)產(chǎn)品等。

傳統(tǒng)企業(yè)的數(shù)據(jù)源基本來自excel、表格、DB系統(tǒng)等，但在互聯(lián)網(wǎng)有網(wǎng)站點擊日志、視頻、音頻、圖片數(shù)據(jù)等很多非結(jié)構(gòu)化快速產(chǎn)生與保存。移動互聯(lián)網(wǎng)除了互聯(lián)網(wǎng)那些外還含有大量定位數(shù)據(jù)、自動化傳感器、嵌入式設(shè)備、自動化設(shè)備等。

在互聯(lián)網(wǎng)數(shù)據(jù)平臺由于數(shù)據(jù)平臺變?yōu)樽杂扇_放，使用數(shù)據(jù)的人也參與到數(shù)據(jù)體系建設(shè)時，基本會因為不專業(yè)性導(dǎo)致數(shù)據(jù)質(zhì)量問題，重復(fù)對分數(shù)據(jù)浪費存儲與資源，口徑多樣化，編碼不統(tǒng)一，命名問題等等原因。數(shù)據(jù)質(zhì)量變成了首要的大敵。

數(shù)據(jù)模型被弱化了，數(shù)據(jù)架構(gòu)導(dǎo)航圖少了，難以建立業(yè)務(wù)系統(tǒng)與數(shù)據(jù)之間的映射與轉(zhuǎn)換關(guān)系。數(shù)據(jù)描述經(jīng)常不一致性。（如：同名異義、同物異名、大量冗余的存在）數(shù)據(jù)模型被弱化（數(shù)據(jù)倉庫模型）是傳統(tǒng)企業(yè)與互聯(lián)網(wǎng)企業(yè)一個蠻大的差異，但是互聯(lián)網(wǎng)企業(yè)也有自己特點，傳統(tǒng)行業(yè)所涉及數(shù)據(jù)模型這個領(lǐng)域涉及的很多內(nèi)容在互聯(lián)網(wǎng)變成以其他的曲線救國的方式存在了。

回顧在傳統(tǒng)行業(yè)數(shù)據(jù)平臺中，不管兩位大師爭論點數(shù)據(jù)模型的設(shè)計采用那種范式（Bill Inmon的EDW的原則是準三范式的設(shè)計、Ralph kilmbal是星型結(jié)構(gòu)）但是都要非常重視數(shù)據(jù)源的質(zhì)量問題。所以傳統(tǒng)行業(yè)的數(shù)據(jù)模型會全盤考慮數(shù)據(jù)質(zhì)量問題，并通過數(shù)據(jù)抽樣分析給出合適的清洗口徑。

但是在互聯(lián)網(wǎng)呢，數(shù)據(jù)質(zhì)量在互聯(lián)網(wǎng)數(shù)據(jù)平臺變成了一種心病。（ps：我了解過一個公司，能讓數(shù)據(jù)平臺+數(shù)據(jù)分析師+業(yè)務(wù)多人“對數(shù)”對一年的還是不準的）。在應(yīng)對數(shù)據(jù)的質(zhì)量問題，目前互聯(lián)網(wǎng)有些做法是把數(shù)據(jù)標準化前置到業(yè)務(wù)數(shù)據(jù)產(chǎn)生就做，從根源上去杜絕，但是這種場景比較實用在Log日志的數(shù)據(jù)源中，比如移動互聯(lián)網(wǎng)最近流行的基于事件模型“Event”模型，在日志產(chǎn)生時就規(guī)定好存儲格式。（備注：大家度娘搜索【The Log】（我所讀過的最好的一篇分布式技術(shù)文章）對這個講解很詳細）

目前，在傳統(tǒng)行業(yè)還是以混合模型設(shè)計方式為主，但是在互聯(lián)網(wǎng)我所接觸的一些業(yè)務(wù)，在參照傳統(tǒng)數(shù)據(jù)模型方法論基礎(chǔ)上，逐步的在演進適合互聯(lián)網(wǎng)數(shù)據(jù)的數(shù)據(jù)模型方法。比如互聯(lián)網(wǎng)金融等一些業(yè)務(wù)會參考傳統(tǒng)金融行業(yè)對主題域的劃分，OMG數(shù)據(jù)倉庫元數(shù)據(jù)管理CWM模型，F(xiàn)SDM金融模型再考慮大數(shù)據(jù)處理的一些特性去進行設(shè)計，所有從Hight Level數(shù)據(jù)架構(gòu)圖看到的劃分與傳統(tǒng)第三代數(shù)據(jù)倉庫還是很多相似之處，也有分三層、四層。

但是在模型細節(jié)處理上已經(jīng)完全不一樣，比如數(shù)據(jù)的多樣性、拉寬事實表、度量值單獨存儲、滿足數(shù)據(jù)快速重生、維度的二次降維處理等，增加大量冗余列，增加大量派生列，結(jié)合自動化元數(shù)據(jù)來耦合，合并等相關(guān)管理。

以上來自支付寶2011年的數(shù)據(jù)模型

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

類似Olap的應(yīng)用在互聯(lián)網(wǎng)這個奇特思維土壤中我經(jīng)歷過一個曲線救國方式（2011-2012年時設(shè)計多維挖掘分析數(shù)據(jù)產(chǎn)品背后的技術(shù)就是搜索引擎實現(xiàn)的），但現(xiàn)在應(yīng)該也有新技術(shù)出現(xiàn)了來解決類似的問題。

互聯(lián)網(wǎng)業(yè)務(wù)特點業(yè)務(wù)垂直拆分非常細，比如一個用戶注冊、密碼找回的流程有可能存在好幾個產(chǎn)品負責(zé)同一個業(yè)務(wù)流程不同環(huán)節(jié)，相關(guān)的一個策略、產(chǎn)品feature快速迭代上線等等都要數(shù)據(jù)評估。

數(shù)據(jù)從前端埋點到采集然后再由各個環(huán)節(jié)到數(shù)據(jù)平臺，再由數(shù)據(jù)分析師或各業(yè) 務(wù)部門去使用，基本拉長了時間周期。需求部門與實施部門能力和經(jīng)驗有千差萬別的需求，造成了懂技術(shù)部門沒有足夠的精力完全理解業(yè)務(wù)部門奇形怪狀需求，可能在各環(huán)節(jié)放緩與變的低效。

或許“適合敏捷”的維度建模在當(dāng)前是個不錯的選擇，如果一上來就想著建立一套能兼容所有數(shù)據(jù)和業(yè)務(wù)的數(shù)據(jù)模型，那就又回到傳統(tǒng)數(shù)據(jù)倉庫的建設(shè)上了，很難滿足對業(yè)務(wù)變化的快速響應(yīng)?；ヂ?lián)網(wǎng)企業(yè)業(yè)務(wù)特點是變化非常迅速的，能穩(wěn)定的業(yè)務(wù)達到65%算對數(shù)據(jù)平臺是個福音了（根據(jù)對某寶的印象）剩余的業(yè)務(wù)變化迅速，必然導(dǎo)致數(shù)據(jù)模型快速上下線。

Kimball老人家提出的維度建模（備注：在本系列發(fā)展史得第一篇有介紹）圍繞業(yè)務(wù)模型能夠非常直觀的表達出業(yè)務(wù)的數(shù)據(jù)關(guān)系，但是在互聯(lián)網(wǎng)NOSQL犧牲掉了關(guān)系型數(shù)據(jù)庫的一致性，完整性等等很多東西。

維度數(shù)據(jù)模型又基于這些大數(shù)據(jù)技術(shù)，所以進化的更加輕量級與基于細節(jié)數(shù)據(jù)的維度退化建模。（備注：原有的緩慢變化維、快速變化維、大維、迷你維、父子維、雪花維為了適應(yīng)互聯(lián)網(wǎng)的大數(shù)據(jù)Nosql處理技術(shù)進行反規(guī)范化、化&數(shù)據(jù)冗余設(shè)計）

退化維度的反規(guī)范化設(shè)計一方面可以把一條查詢語句所需要的所有數(shù)據(jù)組合起來放到一個地方存儲 Key values的方式（比如說商品有不同類型，每一種類型商品又有自己的不同屬性，可以采用一對多和多對多的方式存儲，例如把一個多維映射為一個Key value）。（備注：維度模型設(shè)計在細節(jié)處理太多，后續(xù)有機會在做專題分享）。

講到互聯(lián)網(wǎng)數(shù)據(jù)平臺就要提數(shù)據(jù)模型，提了數(shù)據(jù)模型就要提Nosql技術(shù)，NOSQL是大數(shù)據(jù)處理的特征之一。互聯(lián)網(wǎng)數(shù)據(jù)平臺數(shù)據(jù)模型與NOSql技術(shù)是非常緊密的。這里有外文講解NOSQL Data modeling technigues從技術(shù)角度講解非常詳細。

(https://highlyscalable./2012/03/01/nosql-data-modeling-techniques/）

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