編者按：本文是松子（李博源）的大數據平臺發展史系列文章的第四篇（共四篇），本系列以獨特的視角，比較了非互聯網和互聯網兩個時代以及傳統行業與非傳統行業。是對數據平臺發展的一個回憶，對非互聯網、互聯網，從數據平臺的用戶角度、數據架構演進、模型等進行了闡述。前端
在互聯網時代被弱化的數據模型
談起數據模型就不得不提傳統數據平臺架構發展，我相信不少朋友都曉得傳統數據平臺的知識，其架構演進簡單一句話說「基本上能夠分爲五個時代、四種架構」，可是到了互聯網時代由於大數據快速膨脹與數據源類型多樣化特色，從高階架構上來看大約從傳統數據平臺第三代架構開始延續的，可是日後的發展從我本身的這一點知識上很難對互聯網的數據平臺作架構歸類。web
可是從數據平臺建設與服務角色上仍是有章可循的。就像上篇分享到那樣，類比兩個行業，互聯網企業中員工年齡比非互聯網企業的要年輕、受教育程度、對計算機的焦慮程度明顯比傳統企業要低、還偶遇其它各方面的緣故，致使了數據平臺所面對用戶羣體與非互聯網數據平臺有所差別化。sql
傳統行業與互聯網行業數據平臺用戶特性我只選擇前文章的兩張圖來表示數據庫
(點擊放大圖像)api
(點擊放大圖像)安全
在傳統數據平臺要背後有一個完整數據倉庫團隊去服務業務方，業務方嗷嗷待哺的等待被動方式去知足。中低層數據基本不會對業務方開放，因此無論數據模型採用何種建模方式，主要知足當時數據架構規劃便可。微信
互聯網業務的快速發展使得你們已經從經營、分析的訴求重點轉爲數據化的精細運營上，如何作好精細化運營問題上來，當資源不夠時用戶就叫喊，甚至有的業務方會挽起袖子來本身參與到從數據整理、加工、分析階段。架構
此時呢，原有建設數據平臺的多個角色（數據開發、模型設計）可能轉爲對其它非專業使用數據方，作培訓、諮詢與落地，寫更加適合當前企業數據應用的一些方案與開發些數據產品等。app
在互聯網數據平臺因爲數據平臺變爲自由開放，你們使用數據的人也參與到數據的體系建設時，基本會由於不專業性，致使數據質量問題、重複對分數據浪費存儲與資源、口徑多樣化、編碼不統1、命名問題等等緣由。數據質量逐漸變成一個特別突出的問題。運維
傳統企業的數據源基原本自 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 模型、維度模型直接在互聯網數據大數據平臺部署或許還有「好些未知」障礙等待你們去克服。同時在傳統數據建模用到的一些方法通過互聯網薰陶或許演進成一種新的數據產品或方案吧。
到此爲止「我所經歷的大數據平臺發展史」上下共四篇與你們分享完畢，這個寫做先後經歷恰好一個月左右，算是對本身數據從業經歷回顧之一吧。在知識的整理中不少都是走馬觀花，每一個知識域都是一個很是深的專業方向，本身涉足很膚淺，在文章中分享不足之處請各位讀者見諒！！
我的郵箱是 5592094@qq.com 歡迎電郵交流。
接下來我會進入數據產品這個領域的分享，當年車品覺老師自豪的做品之一「黃金策」，我是數據產品經理。（ps：本身躲在牆角拿車品覺老師往本身臉上貼金了）。
後記
有一次數據產品神策的創始人兼好友 @桑文鋒＠SensorsData 跟我說來作次分享吧，我當時出了幾個題目，最後就選擇了「我所經歷的大數據平臺「，就造成了你們看到的」我所經歷的大數據平臺「系列文章.
在整理期間獲得了死黨 @周愛民、@神策 - 桑文峯、 InfoQ 小編 @Tina Du 、@betty zhou @Laurel 大力協助，在這裏感謝！！！
番外篇
這一篇是在 24 日舉行的分享你們提到的一些問題，通過整理算是對正文的補充吧，從互聯網敏捷數據模型等角度作了較深刻的細節介紹。同時在數據產品方面的回答包含了一點將來寫做篇「數據產品」系列的一點內容。
1，傳統咱們作 BI 的，作數據展示會建模後以 pivot 展示 cube 數據，不知道如今互聯網公司數據展現如何作的？第三方工具仍是用 API 取數據平臺裏的數據？adhoc 報表及靈活更換維度的時候 web 端通常是怎麼作的？
松子老師：剛纔文章中提到了好比傳統行業的多維數據模型 cube。在互聯網採用的曲線救國方式解決的。 在分享中我給出了幾個圖。就是經過搜索引擎曲線救國方式實現相似 Olap 的模擬。
在這塊的模型的處理上採用的是維度退化處理。經過反規範化，數據項、數據冗餘去處理。在前端作特殊處理。
這個當時產品原型之一：
(點擊放大圖像)
這是一個 2011 年 -2012 年左右的數據產品，當時算是即時計算的一種。不過已通過去好幾年了，當今新技術下 Olap 引擎應該有很好的提高。
目前我知道的家互聯網公司，在前端展示有使用第三方套件好比 spagoBi、pentaho 等 有本身設計開發定製化數據前端展示。好比我剛開始分享的那兩個以前在去哪兒網設計的數據平臺內部界面之一，固然數據產品是另外一個話題了，經過對數據分析抽象指標、分析模型、用戶使用功能與流程、將來規劃考慮用戶體驗去設計。
(點擊放大圖像)
(點擊放大圖像)
(點擊放大圖像)
2，互聯網財經類公司，業務包括財經網站、基金、股票、金融等，這類公司的數據倉庫模型應該如何設計？特色和注意事項是什麼？案例介紹？十分感謝。
松子老師：我本身經歷過的是互聯網金融以及移動互聯網行。對這兩塊比較清楚。互聯網金融原由爲業務的特性是類金融類的，與銀行有些地方是類似的。
好比大約在 2012 年前支付寶業務特色涉及類金融交易：充值、提現、帳務管理類電子商務：購物交易過程變動、實際交易（對 B 機票、對 C 水電等） 非純電子商務；純金融；我的信用，理財類。系統之間依賴度較爲複雜，垂直依賴（業務與核心）跨層依賴（跨過交易到帳務）。
在設計方法上仍是採用維度模型設計方式。底層是數據驅動爲嚮導，結合業務需求驅動，經過簡單、退化維度的方式拉寬表結構。
底層採用鬆耦合設計。主題之間是鬆耦合方式。至體內採用細粒度退化維度。
在主題域上的的設計基本參考了 OMG 的數據倉庫元數據設計 CWM 模型、IBM 的 fsdm 金融模型、還有新巴塞爾資本協議（Basel II Capital Accord）需提供數據規範去的設計。因此數據模型是五層的結構。
在細節處理上，增量 ODS 層數據和前一天 DWD 相關表進行 merge 處理。
在一些層次上，基本聚合、彙總增長派生事實表（簡單一句話退化爲度打寬）。而後按照業務主體合併信息等。
好比開始給你們分享的那張圖：
(點擊放大圖像)
在維度模型退化處理時，要注意最細粒度數據保留、不一樣層次的數據支持數據從新生成。同時必定要注意互聯網數據業務特性，數據質量是大心病。有可能一天某些表會重跑不少遍。在互聯網的作法有可能一天會重跑好幾回數據。
因此曲線救國的病態的產生出了一種經過元數據驅動的數據模型。
這種元數據驅動工具型數據產品我會在將來數據產品系列中作詳細介紹的。
3，互聯網企業大數據平臺的發展歷程是怎樣的？
松子老師：這個我相信應該是傳統數據平臺朋友提到的。傳統行業數據平臺架構演進我總結簡單一句話說「基本上能夠分爲五個時代、四種架構」，可是到了互聯網時代由於大數據快速膨脹與類型暴增的特色，從高階架構上來看大約從第三代架構開始延續的，可是從我本身的知識上很難對互聯網的數據平臺作架構歸類。因此我從互聯網數據平臺的建設、用戶使用變化特徵去作了總結。話說互聯網數據平臺基本是從傳統數據平臺的第三代開始的。那是咱們總結下來用戶特色：
(點擊放大圖像)
更加詳細的每一代數據平臺建設、服務角色特色您能夠看我這個系列文章的第三篇，http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-paet02
4，有沒有好的元數據管理工具推薦？主要偏向數據字典與血統等。
松子老師：元數據之前目前沒有太多的好管理工具。之前是在支付寶是我本身設計的一個數據產品。初版本身用 Delphi 開發的。
（圖不少：）
(點擊放大圖像)
(點擊放大圖像)
(點擊放大圖像)
(點擊放大圖像)
(點擊放大圖像)
之前被逼的本身寫了一個，經過解析，實現了字段級的血緣影響分析。這只是第二步，後來又把 running 信息給搞了進來。還有分享時提到的模型信息、整個閉環的分類信息。
這是一個分支：
(點擊放大圖像)
可是咱們實現了字段級解析準確率達到了 94% 左右。有細微的錯誤就人工 revew 一遍。
5. 松子老師，數據管控的數據質量部分是怎麼處理的呢？
松子老師： 數據管控， 這方面我不太懂的，可是數據質量，這玩意可大可小的。好比像在分享時說過的，在移動互聯網的數據質量處理方式能夠由原有的 ETL(ELT) 階段前置到業務系統去解決，好比移動互聯網的 App log 日誌，日誌標準化後事件模型」存儲來解決。那非 app 日誌類如何解決呢好比 Payment、order 等，數據質量比較考慮的能夠只作到監控。
我來分享個圖。恰好是我設計數據質量產品時搞的，理清數據質量的問題：
(點擊放大圖像)
(點擊放大圖像)
(點擊放大圖像)
只要數據進入倉庫與應用體系，處理起來就比較困難了，因此在數據平臺階段最好是經過監控、前置去解決。目前數據質量確實難以 100% 由過後搞到事前去處理。我對數據平臺與數據產品的建設就是實用爲主。怎麼實用怎麼來。我是比較現實的實用主義者。
6. 可否分享一些數據產品種類及實例：
松子老師：在前邊五個問題、以及文章中又都涉及數據產品實力的一些分享。
提到數據產品的分類我就想把這個圖發出來。
本身認爲沒有特別明確的劃分線，可是數據產品從三個維度劃分，面向業務、功能、用戶能夠劃分出三個方向的數據產品來。
好比面向數據平臺工具型數據產品: 調度、數據質量、元數據、數據建模、ETL 工具、資源管控等等。
面向用戶功能有報表型、多維型數據產品、定製化數據產品、挖掘型數據產品。
面向內部用戶、外部我的用戶、外部企業用戶又有不一樣的分類。
根據業務又能夠劃分不少，面向 C 類用戶、面向 B 類商戶、金融風險等等
從近幾年的數據產品來看，是更好的輔助用戶的作決策的一種產品形態，在用戶的決策與行動中充當信息的分析者與價值使用者；數據產品有個本身的共性：由解決的一個實際的業務問題出發，分解出的分析指標，分析模型，分析流程組成，再考慮到功能易用性，將來功能擴展，考慮用戶對數據易用性（好比數據的呈現層次，不可能一次把全部數據的呈現給用戶）來組成的。
(點擊放大圖像)
7. 銀行業從傳統的 ods 到 edw 再到大數據平臺這塊過渡，模型如何建設？平臺優點如何發揮？
松子老師：這個問題仍是有些難度的，本身回答的可能有些片面。首先咱們清醒的清楚「大數據」是什麼？再次不一樣的場景能夠採用不一樣的技術去解決。
「大數據」，拆開來看大、數據，大能夠是指的數據源結構簡單（ps 若是瞭解過當代對大數據的定義就知道四個特性）可是量級夠大，好比清算、結算、對公、對私、中間業務等等每個拿出來都是幾十 T，可是這些業務數據都是保存傳統的關係型數據庫中如 DB二、Oracle、MSsql 中，由於在數據平臺存儲是經過準 3 範式等等結構去保存。
在存儲時可能要比較複雜的 SQL 多表關聯的，感受目前傳統的數據平臺技技術在處理數據很讓人着急。想經過互聯網的大數據平臺 hadoop、Hive 、Spark 等技術的去演進解決。（最先時個人是中信銀行、光大銀行在 2011 年左右開始考慮 Hadoop 技術，後來不知道如何了）。
可是互聯網的數據平臺技術大都是 NOSQL 模式，犧牲掉了傳統數據庫的數據一致性、完整性、惟一索引等等，只乾性能的事情（固然除了性能、可擴展性也是的）.
原有在傳統數據平臺模型設計上能夠考慮的一些經過主外鍵、惟一索引作一些業務約束的方法，在 nosql 上通通的都沒有了，這些約束必須放到數據加工階段去想辦法作檢查。傳統數據平臺若是在 Insert、update 數據時違反了業務約束能夠作報警或異常處理，可是在 Nosql 的平臺上要求 ETL 去手動遵照這些規則檢查。可是有時 ETL 開發根本不遵照的，僅僅是兩個表關聯起來，也可能忘記按照某一個業務惟一索引作去重操做。簡單說，原有靠關係型數據庫自己機制去作檢查一些規則變爲人工，變爲人工就會犯錯。
從關係型數據平臺往 Nosql 數據平臺遷移時，尤爲是對傳統行業的業務來講，在模型設計階段、以及給出的 ETL 口徑要考慮更多的業務規則檢查，其次要考慮更多的維度退化、多冗餘、表打寬處理。簡單說就是發揮數據平臺的計算能力同時要更加的各方面確保數據準確安全可靠。
數據模型 ODS 到 EDW 這塊的設計方法百度上留下的文檔資料太多的了，請這位提問的老師百度吧。
8．大數據倉庫中如何作快速維處理？互聯網數倉數據質量很差如何對數，如何確立標準的對數口徑？
松子老師：快速變化維度能夠轉化爲緩慢變化爲來出來，我本身理解的快速維度是相對於緩慢維度參照的來講的。
舉個例子，年齡 - 轉化爲天數能夠是定義快速變化維度，由於天天都在變化。咱們能夠把年齡退化爲區間維度來處理，還能夠把年齡作成動態維度來處理，事實表中保存的就是實際的出生年月並打寬表，年齡 (天) 經過計算方式來處理。還有種方法經過對代理鍵的方式來處理。
我目前也不知道對數據的標準是什麼。可是我本身用的方法，把一個指標的整個數據流向切出幾個關鍵點經過 SQL 去實現對數，看波動振幅，波動曲線。同時還會好比發不通的版本的小流量測試的方式來作數據校對。
9． 作爲數據行業從業者，須要掌握哪些重要的基礎知識？另：若是從零開始創建一個數據平臺，須要哪些資源配置（人，財，物，技術）？大體總投資額度多少？若是同行產品間多種來源的數據，可有成熟的解決方案？謝謝…
松子老師：這個問題太宏觀了。做爲數據行業從業者，須要掌握哪些重要基礎知識，這個是要看從事具體數據域的垂直行業。
好比說 數據開發、數據模型、數據產品、數據分析師、數據運營、數據架構師這些更加專業領域是須要不一樣的知識的。你們能夠去 itongji.cn、百度等去搜索數據架構等文章能獲得更加專業的答案。
一家公司建設數據平臺是跟公司目前數據量、將來數據增加、技術選型、解決業務問題有很直接的關係的。因此在解決業務目標不太明確下，難以肯定方案，人員配置上選用不一樣技術方案去搭建的配置是不太同樣的，好比說傳統平臺來說，運維、DBA、數據開發、數據模型、報表人員。
從互聯網數據平臺基本配置上，數據架構師、運維、底層大數據技術、數據開發兼模型、數據分析師、數據產品等都有可能須要的。
同行產品間度多種數據來源，那就看數據源種類，文本的、日誌類、視頻影像、爬蟲類的、結構化、非結構化的數據源有不一樣的解決技術。
10. Standalone模式下，Model.save(Path) 怎麼一直提示錯誤，是否是配置 Spark 時須要將 Hdfs 的配置引進來啊～？表示初學 Spark
松子老師：這個問題有點超出個人能力範圍了，因此對不起回答不了。
我自己不是作技術的。僅知道一點技術名詞。
11. 傳統銀行業數據模型何時會走向互聯網模式呢？目前在傳統銀行數據平臺的產品是否是特別多？
松子老師：這個問題我本身就不知道了，或許是傳統銀行在數據平臺的實施上全面用互聯網的 Nosql 大數據處理技術吧。至於說傳統銀行數據模型用現有的互聯網數據模型理念去設計是否徹底可行，數據一致性、高準確性經過更多的方案去保證。
首先我須要肯定一下這個產品是否指的「數據產品」。
若是是數據產品，那其實傳統行業數據平臺自己就有一些數據產品了，並且也都是存在的。數據產品自從數據倉庫出現以來它其實一直都存在的，只不過是近幾年由於互聯網特別愛製造「流行詞「把數據產品這個詞給放大了。互聯網是得數據產品從早期的重量級逐漸進化爲輕量級、從大而全的解決方案逐漸演進爲因小而美。
我來給出幾組例子，大約從 2004 年到如今的幾組數據產品的例子
(點擊放大圖像)
(點擊放大圖像)
(點擊放大圖像)
(點擊放大圖像)
(點擊放大圖像)
(點擊放大圖像)
(點擊放大圖像)
你能夠分類一下，這些數據產品的特色是什麼？知足了用戶怎麼樣的痛點需求？知足了用戶怎麼樣的使用流程。
12 。傳統行業的數據倉庫從業人員，若是轉到互聯網行業，應該學習哪些技能？
松子老師：這個問題你能夠百度搜索「大數據職位所須要的數據技能」 http://blog.jobbole.com/99039/ 這篇文章。本身以爲人家回答的比我專業。
感謝杜小芳對本文的審校。
給 InfoQ 中文站投稿或者參與內容翻譯工做，請郵件至editors@cn.infoq.com。也歡迎你們經過新浪微博（@InfoQ，@丁曉昀），微信（微信號：InfoQChina）關注咱們。