97人妻一区二区三区免费,色欲精品久久人妻av中文字幕,无码视频一区二区三区

//
我所經歷的大數據平臺發展史（四）：互聯網時代 ? 下篇
http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-internet-age

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

編者按：本文是松子（李博源）的大數據平臺發展史系列文章的第四篇（共四篇），本系列以獨特的視角，比較了非互聯網和互聯網兩個時代以及傳統行業與非傳統行業。是對數據平臺發展的一個回憶，對非互聯網、互聯網，從數據平臺的用戶角度、數據架構演進、模型等進行了闡述。
在互聯網時代被弱化的數據模型
談起數據模型就不得不提傳統數據平臺架構發展，我相信很多朋友都曉得傳統數據平臺的知識，其架構演進簡單一句話說“基本上可以分為五個時代、四種架構”，但是到了互聯網時代因為大數據快速膨脹與數據源類型多樣化特點，從高階架構上來看大約從傳統數據平臺第三代架構開始延續的，但是往后的發展從我自己的這一點知識上很難對互聯網的數據平臺做架構歸類。
但是從數據平臺建設與服務角色上還是有章可循的。就像上篇分享到那樣，類比兩個行業，互聯網企業中員工年齡比非互聯網企業的要年輕、受教育程度、對計算機的焦慮程度明顯比傳統企業要低、還偶遇其它各方面的緣故，導致了數據平臺所面對用戶群體與非互聯網數據平臺有所差異化。
傳統行業與互聯網行業數據平臺用戶特性我只選擇前文章的兩張圖來表示
(點擊放大圖像)

(點擊放大圖像)

在傳統數據平臺要背后有一個完整數據倉庫團隊去服務業務方，業務方嗷嗷待哺的等待被動方式去滿足。中低層數據基本不會對業務方開放，所以不管數據模型采用何種建模方式，主要滿足當時數據架構規劃即可。
互聯網業務的快速發展使得大家已經從經營、分析的訴求重點轉為數據化的精細運營上，如何做好精細化運營問題上來，當資源不夠時用戶就叫喊，甚至有的業務方會挽起袖子來自己參與到從數據整理、加工、分析階段。
此時呢，原有建設數據平臺的多個角色（數據開發、模型設計）可能轉為對其它非專業使用數據方，做培訓、咨詢與落地，寫更加適合當前企業數據應用的一些方案與開發些數據產品等。
在互聯網數據平臺由于數據平臺變為自由開放，大家使用數據的人也參與到數據的體系建設時，基本會因為不專業性，導致數據質量問題、重復對分數據浪費存儲與資源、口徑多樣化、編碼不統一、命名問題等等原因。數據質量逐漸變成一個特別突出的問題。
傳統企業的數據源基本來自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，但是這些業務數據都是保存傳統的關系型數據庫中如DB2、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年到現在的幾組數據產品的例子
(點擊放大圖像)