互聯(lián)網(wǎng)時代被弱化的數(shù)據(jù)模型

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

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

傳統(tǒng)行業(yè)與互聯(lián)網(wǎng)行業(yè)數(shù)據(jù)平臺用戶特性我只選擇前文章的兩張圖來表示

在傳統(tǒng)數(shù)據(jù)平臺要背后有一個完整數(shù)據(jù)倉庫團隊去服務(wù)業(yè)務(wù)方，業(yè)務(wù)方嗷嗷待哺的等待被動方式去滿足。中低層數(shù)據(jù)基本不會對業(yè)務(wù)方開放，所以不管數(shù)據(jù)模型采用何種建模方式，主要滿足當時數(shù)據(jù)架構(gòu)規(guī)劃即可。

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

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

在互聯(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ì)量逐漸變成一個特別突出的問題。

傳統(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è)備等，傳統(tǒng)行業(yè)原有的數(shù)據(jù)平臺技術(shù)對處理如此復(fù)雜而多樣化的數(shù)據(jù)有些力不從心。

當數(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)變成以其他的曲線救國的方式存在了。

互聯(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ù)抽樣分析給出合適的清洗口徑。

上圖來自我2009年搞數(shù)據(jù)質(zhì)量平臺工具數(shù)據(jù)產(chǎn)品內(nèi)容之一

但是在互聯(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)生就做，從根源上去杜絕數(shù)據(jù)質(zhì)量，但是這種場景比較實用在Log 日志的數(shù)據(jù)源中，比如移動互聯(lián)網(wǎng)最近流行的基于事件模型“Event”模型，在日志產(chǎn)生時就規(guī)定好存儲格式

(備注：大家度娘搜索，“學(xué)習(xí)筆記：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模型、FSDM金融模型，再進一步考慮大數(shù)據(jù)處理特性去進行設(shè)計，所有從Hight Level 數(shù)據(jù)架構(gòu)圖看到主題層次劃分與傳統(tǒng)第三代數(shù)據(jù)倉庫還是很多相似之處，當然模型架構(gòu)也有分三層、四層、五層的。

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

支付寶非常早期數(shù)據(jù)模型

我們常提到的多維模型在大數(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)了來解決類似的問題。

上圖為2012年產(chǎn)品UI之一

上圖是2011-2012年該產(chǎn)品系列背后當時使用的技術(shù)

互聯(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é)放緩與變的低效。

或許適合“敏捷”維度建模在當前是個不錯的選擇，如果一上來就想著建立一套能兼容所有數(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)。

講到互聯(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ù)還是蠻緊密的。

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

Q & A

Q1：傳統(tǒng)做BI的，做數(shù)據(jù)展現(xiàn)會建模后以pivot展現(xiàn)cube數(shù)據(jù)?，F(xiàn)在互聯(lián)網(wǎng)公司數(shù)據(jù)展示如何做的?第三方工具還是用API取數(shù)據(jù)平臺里的數(shù)據(jù)?adhoc報表及靈活更換維度的時候web端一般是怎么做的?

A：剛才文章中提到了比如傳統(tǒng)行業(yè)的多維數(shù)據(jù)模型cube。在互聯(lián)網(wǎng)采用的曲線救國方式解決的。 在分享中我給出了幾個圖。就是通過搜索引擎曲線救國方式實現(xiàn)類似Olap的模擬。

在這塊的模型的處理上采用的是維度退化處理。通過反規(guī)范化，數(shù)據(jù)項、數(shù)據(jù)冗余去處理。在前端做特殊處理。

這個當時產(chǎn)品原型之一：

這是一個2011年-2012年左右的數(shù)據(jù)產(chǎn)品，當時算是即時計算的一種。不過已經(jīng)過去好幾年了，當今新技術(shù)下Olap 引擎應(yīng)該有很好的提升。

目前我知道的家互聯(lián)網(wǎng)公司，在前端展現(xiàn)有使用第三方套件 比如spagoBi、pentaho 等有自己設(shè)計開發(fā)定制化數(shù)據(jù)前端展現(xiàn)。

比如我剛開始分享的那兩個之前在去哪兒網(wǎng)設(shè)計的數(shù)據(jù)平臺內(nèi)部界面之一，當然數(shù)據(jù)產(chǎn)品是另一個話題了，通過對數(shù)據(jù)分析抽象指標、分析模型、用戶使用功能與流程、未來規(guī)劃考慮用戶體驗去設(shè)計。

Q2：互聯(lián)網(wǎng)財經(jīng)類公司，包括財經(jīng)網(wǎng)站、基金、股票、金融等，這類公司的數(shù)據(jù)倉庫模型應(yīng)該如何設(shè)計?特點和注意事項是什么?案例介紹?

A：互聯(lián)網(wǎng)金融起因為業(yè)務(wù)的特性是類金融類的，與銀行有些地方是相似的。比如大約在2012年前支付寶業(yè)務(wù)特點涉及類金融交易：充值、提現(xiàn)、賬務(wù)管理類電子商務(wù)：購物交易過程變更、實際交易(對B機票、對C水電等) 非純電子商務(wù);純金融;個人信用，理財類。系統(tǒng)之間依賴度較為復(fù)雜，垂直依賴(業(yè)務(wù)與核心)跨層依賴(跨過交易到賬務(wù))。

在設(shè)計方法上還是采用維度模型設(shè)計方式。底層是數(shù)據(jù)驅(qū)動為向?qū)ВY(jié)合業(yè)務(wù)需求驅(qū)動，通過簡單、退化維度的方式拉寬表結(jié)構(gòu)。

底層采用松耦合設(shè)計。主題之間是松耦合方式。至體內(nèi)采用細粒度退化維度。

在主題域上的的設(shè)計基本參考了OMG的數(shù)據(jù)倉庫元數(shù)據(jù)設(shè)計CWM模型、IBM 的fsdm金融模型、還有新巴塞爾資本協(xié)議(Basel II Capital Accord)需提供數(shù)據(jù)規(guī)范去的設(shè)計。所以數(shù)據(jù)模型是五層的結(jié)構(gòu)。

在細節(jié)處理上，增量ODS層數(shù)據(jù)和前一天DWD相關(guān)表進行 merge處理。

在一些層次上，基本聚合、匯總增加派生事實表(簡單一句話退化為度打?qū)?。然后按照業(yè)務(wù)主體合并信息等。

在維度模型退化處理時，要注意最細粒度數(shù)據(jù)保留、不同層次的數(shù)據(jù)支持數(shù)據(jù)重新生成。同時一定要注意互聯(lián)網(wǎng)數(shù)據(jù)業(yè)務(wù)特性，數(shù)據(jù)質(zhì)量是大心病。有可能一天某些表會重跑很多遍。在互聯(lián)網(wǎng)的做法有可能一天會重跑好幾次數(shù)據(jù)。

所以曲線救國的病態(tài)的產(chǎn)生出了一種通過元數(shù)據(jù)驅(qū)動的數(shù)據(jù)模型。

Q3：互聯(lián)網(wǎng)企業(yè)大數(shù)據(jù)平臺的發(fā)展歷程是怎樣的?

A：傳統(tǒng)行業(yè)數(shù)據(jù)平臺架構(gòu)演進我總結(jié)簡單一句話說“基本上可以分為五個時代、四種架構(gòu)”，但是到了互聯(lián)網(wǎng)時代因為大數(shù)據(jù)快速膨脹與類型暴增的特點，從高階架構(gòu)上來看大約從第三代架構(gòu)開始延續(xù)的，但是從我自己的知識上很難對互聯(lián)網(wǎng)的數(shù)據(jù)平臺做架構(gòu)歸類。

所以我從互聯(lián)網(wǎng)數(shù)據(jù)平臺的建設(shè)、用戶使用變化特征去做了總結(jié)。互聯(lián)網(wǎng)數(shù)據(jù)平臺基本是從傳統(tǒng)數(shù)據(jù)平臺的第三代開始的。那是我們總結(jié)下來用戶特點：

Q4：有沒有好的元數(shù)據(jù)管理工具推薦?主要偏向數(shù)據(jù)字典與血統(tǒng)等。

A：元數(shù)據(jù)以前目前沒有太多的好管理工具。以前是在支付寶是我自己設(shè)計的一個數(shù)據(jù)產(chǎn)品。第一版自己用Delphi 開發(fā)的。

以前被逼的自己寫了一個，通過解析，實現(xiàn)了字段級的血緣影響分析。這只是第二步，后來又把running 信息給搞了進來。還有分享時提到的模型信息、整個閉環(huán)的分類信息。

但是我們實現(xiàn)了字段級解析準確率達到了94%左右。有細微的錯誤就人工revew一遍。

Q5：數(shù)據(jù)管控的數(shù)據(jù)質(zhì)量部分是怎么處理的呢?

A： 數(shù)據(jù)管控， 這方面我不太懂的，但是數(shù)據(jù)質(zhì)量，這玩意可大可小的。比如像在分享時說過的，在移動互聯(lián)網(wǎng)的數(shù)據(jù)質(zhì)量處理方式可以由原有的ETL(ELT)階段前置到業(yè)務(wù)系統(tǒng)去解決，比如移動互聯(lián)網(wǎng)的App log 日志，日志標準化后事件模型”存儲來解決。

非app 日志類如何解決呢比如Payment、order等，數(shù)據(jù)質(zhì)量比較考慮的可以只做到監(jiān)控。

只要數(shù)據(jù)進入倉庫與應(yīng)用體系，處理起來就比較困難了，所以在數(shù)據(jù)平臺階段最好是通過監(jiān)控、前置去解決。目前數(shù)據(jù)質(zhì)量確實難以100%由事后搞到事前去處理。我對數(shù)據(jù)平臺與數(shù)據(jù)產(chǎn)品的建設(shè)就是實用為主。怎么實用怎么來。我是比較現(xiàn)實的實用主義者。

Q6：能否分享一些數(shù)據(jù)產(chǎn)品種類及實例?

A：在前邊五個問題、以及文章中又都涉及數(shù)據(jù)產(chǎn)品實力的一些分享。提到數(shù)據(jù)產(chǎn)品的分類我就想把這個圖發(fā)出來。

自己認為沒有特別明確的劃分線，但是數(shù)據(jù)產(chǎn)品從三個維度劃分，面向業(yè)務(wù)、功能、用戶 可以劃分出三個方向的數(shù)據(jù)產(chǎn)品來。

比如面向數(shù)據(jù)平臺工具型數(shù)據(jù)產(chǎn)品:調(diào)度、數(shù)據(jù)質(zhì)量、元數(shù)據(jù)、數(shù)據(jù)建模、ETL工具、資源管控等等。

面向用戶功能有報表型、多維型數(shù)據(jù)產(chǎn)品、定制化數(shù)據(jù)產(chǎn)品、挖掘型數(shù)據(jù)產(chǎn)品。面向內(nèi)部用戶、外部個人用戶、外部企業(yè)用戶又有不同的分類。

根據(jù)業(yè)務(wù)又可以劃分很多，面向C類用戶、面向B類商戶、金融風(fēng)險等等

從近幾年的數(shù)據(jù)產(chǎn)品來看，是更好的輔助用戶的做決策的一種產(chǎn)品形態(tài)，在用戶的決策與行動中充當信息的分析者與價值使用者;數(shù)據(jù)產(chǎn)品有個自己的共性：由解決的一個實際的業(yè)務(wù)問題出發(fā)，分解出的分析指標，分析模型，分析流程組成，再考慮到功能易用性，未來功能擴展，考慮用戶對數(shù)據(jù)易用性(比如數(shù)據(jù)的呈現(xiàn)層次，不可能一次把所有數(shù)據(jù)的呈現(xiàn)給用戶)來組成的。

Q7：銀行業(yè)從傳統(tǒng)的ods到edw再到大數(shù)據(jù)平臺這塊過渡，模型如何建設(shè)?平臺優(yōu)勢如何發(fā)揮?

A：這個問題還是有些難度的，自己回答的可能有些片面。首先我們清醒的清楚“大數(shù)據(jù)”是什么?再次不同的場景可以采用不同的技術(shù)去解決。

“大數(shù)據(jù)”，拆開來看大、數(shù)據(jù)，大可以是指的數(shù)據(jù)源結(jié)構(gòu)簡單(ps 如果了解過當代對大數(shù)據(jù)的定義就知道四個特性)但是量級夠大，比如清算、結(jié)算、對公、對私、中間業(yè)務(wù)等等每一個拿出來都是幾十T，但是這些業(yè)務(wù)數(shù)據(jù)都是保存?zhèn)鹘y(tǒng)的關(guān)系型數(shù)據(jù)庫中如DB2、Oracle、MSsql中，因為在數(shù)據(jù)平臺存儲是通過準3范式等等結(jié)構(gòu)去保存。

在存儲時可能要比較復(fù)雜的SQL 多表關(guān)聯(lián)的，感覺目前傳統(tǒng)的數(shù)據(jù)平臺技技術(shù)在處理數(shù)據(jù)很讓人著急。想通過互聯(lián)網(wǎng)的大數(shù)據(jù)平臺hadoop、Hive 、Spark 等技術(shù)的去演進解決。(最早時我的是中信銀行、光大銀行在2011年左右開始考慮Hadoop技術(shù)，后來不知道如何了)。

但是互聯(lián)網(wǎng)的數(shù)據(jù)平臺技術(shù)大都是NOSQL模式，犧牲掉了傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)一致性、完整性、唯一索引等等，只干性能的事情(當然除了性能、可擴展性也是的).

原有在傳統(tǒng)數(shù)據(jù)平臺模型設(shè)計上可以考慮的一些通過主外鍵、唯一索引做一些業(yè)務(wù)約束的方法，在nosql上統(tǒng)統(tǒng)的都沒有了，這些約束必須放到數(shù)據(jù)加工階段去想辦法做檢查。傳統(tǒng)數(shù)據(jù)平臺如果在Insert、update數(shù)據(jù)時違反了業(yè)務(wù)約束可以做報警或異常處理，但是在Nosql的平臺上要求ETL 去手動遵守這些規(guī)則檢查。

但是有時ETL開發(fā)根本不遵守的，僅僅是兩個表關(guān)聯(lián)起來，也可能忘記按照某一個業(yè)務(wù)唯一索引做去重操作。簡單說，原有靠關(guān)系型數(shù)據(jù)庫本身機制去做檢查一些規(guī)則變?yōu)槿斯?，變?yōu)槿斯ぞ蜁稿e。

從關(guān)系型數(shù)據(jù)平臺往Nosql數(shù)據(jù)平臺遷移時，尤其是對傳統(tǒng)行業(yè)的業(yè)務(wù)來說，在模型設(shè)計階段、以及給出的ETL口徑要考慮更多的業(yè)務(wù)規(guī)則檢查，其次要考慮更多的維度退化、多冗余、表打?qū)捥幚?。簡單說就是發(fā)揮數(shù)據(jù)平臺的計算能力同時要更加的各方面確保數(shù)據(jù)準確安全可靠。

數(shù)據(jù)模型ODS 到EDW 這塊的設(shè)計方法百度上留下的文檔資料太多的了，請這位提問的老師百度吧。

Q8：大數(shù)據(jù)倉庫中如何做快速維處理?互聯(lián)網(wǎng)數(shù)倉數(shù)據(jù)質(zhì)量不好如何對數(shù)，如何確立標準的對數(shù)口徑?

A：快速變化維度可以轉(zhuǎn)化為緩慢變化為來出來，我自己理解的快速維度是相對于緩慢維度參照的來說的。

舉個例子，年齡-轉(zhuǎn)化為天數(shù)可以是定義快速變化維度，因為每天都在變化。我們可以把年齡退化為區(qū)間維度來處理，還可以把年齡做成動態(tài)維度來處理，事實表中保存的就是實際的出生年月并打?qū)挶?，年齡(天)通過計算方式來處理。還有種方法通過對代理鍵的方式來處理。

我目前也不知道對數(shù)據(jù)的標準是什么。但是我自己用的方法，把一個指標的整個數(shù)據(jù)流向切出幾個關(guān)鍵點通過SQL去實現(xiàn)對數(shù)，看波動振幅，波動曲線。同時還會比如發(fā)不通的版本的小流量測試的方式來做數(shù)據(jù)校對。

Q9： 做為數(shù)據(jù)行業(yè)從業(yè)者，需要掌握哪些重要的基礎(chǔ)知識?另：如果從零開始建立一個數(shù)據(jù)平臺，需要哪些資源配置(人，財，物，技術(shù))?大致總投資額度多少?如果同行產(chǎn)品間多種來源的數(shù)據(jù)，可有成熟的解決方案?

A：這個問題太宏觀了。作為數(shù)據(jù)行業(yè)從業(yè)者，需要掌握哪些重要基礎(chǔ)知識，這個是要看從事具體數(shù)據(jù)域的垂直行業(yè)。

比如說 數(shù)據(jù)開發(fā)、數(shù)據(jù)模型、數(shù)據(jù)產(chǎn)品、數(shù)據(jù)分析師、數(shù)據(jù)運營、數(shù)據(jù)架構(gòu)師這些更加專業(yè)領(lǐng)域是需要不同的知識的。大家可以去i#cn、百度等去搜索數(shù)據(jù)架構(gòu)等文章能得到更加專業(yè)的答案。

一家公司建設(shè)數(shù)據(jù)平臺是跟公司目前數(shù)據(jù)量、未來數(shù)據(jù)增長、技術(shù)選型、解決業(yè)務(wù)問題有很直接的關(guān)系的。所以在解決業(yè)務(wù)目標不太明確下，難以確定方案，人員配置上選用不同技術(shù)方案去搭建的配置是不太一樣的，比如說傳統(tǒng)平臺來講，運維、DBA、數(shù)據(jù)開發(fā)、數(shù)據(jù)模型、報表人員。

從互聯(lián)網(wǎng)數(shù)據(jù)平臺基本配置上，數(shù)據(jù)架構(gòu)師、運維、底層大數(shù)據(jù)技術(shù)、數(shù)據(jù)開發(fā)兼模型、數(shù)據(jù)分析師、數(shù)據(jù)產(chǎn)品等都有可能需要的。

同行產(chǎn)品間度多種數(shù)據(jù)來源，那就看數(shù)據(jù)源種類，文本的、日志類、視頻影像、爬蟲類的、結(jié)構(gòu)化、非結(jié)構(gòu)化的數(shù)據(jù)源有不同的解決技術(shù)。

Q10：傳統(tǒng)銀行業(yè)數(shù)據(jù)模型什么時候會走向互聯(lián)網(wǎng)模式呢?目前在傳統(tǒng)銀行數(shù)據(jù)平臺的產(chǎn)品是不是特別多?

A：這個問題我自己就不知道了，或許是傳統(tǒng)銀行在數(shù)據(jù)平臺的實施上全面用互聯(lián)網(wǎng)的Nosql大數(shù)據(jù)處理技術(shù)吧。至于說傳統(tǒng)銀行數(shù)據(jù)模型用現(xiàn)有的互聯(lián)網(wǎng)數(shù)據(jù)模型理念去設(shè)計是否完全可行，數(shù)據(jù)一致性、高準確性通過更多的方案去保證。

首先我需要確定一下這個產(chǎn)品是否指的“數(shù)據(jù)產(chǎn)品”。

如果是數(shù)據(jù)產(chǎn)品，那其實傳統(tǒng)行業(yè)數(shù)據(jù)平臺本身就有一些數(shù)據(jù)產(chǎn)品了，而且也都是存在的。數(shù)據(jù)產(chǎn)品自從數(shù)據(jù)倉庫出現(xiàn)以來它其實一直都存在的，只不過是近幾年因為互聯(lián)網(wǎng)特別愛制造“流行詞“把數(shù)據(jù)產(chǎn)品這個詞給放大了?；ヂ?lián)網(wǎng)是得數(shù)據(jù)產(chǎn)品從早期的重量級逐漸進化為輕量級、從大而全的解決方案逐漸演進為因小而美。

你可以分類一下，這些數(shù)據(jù)產(chǎn)品的特點是什么?滿足了用戶怎么樣的痛點需求?滿足了用戶怎么樣的使用流程。

相關(guān)鏈接：我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史（上）

來源：數(shù)據(jù)分析網(wǎng)