//
我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史（三）：互聯(lián)網(wǎng)時代 ? 上篇
http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-paet02
編者按：本文是松子（李博源）的大數(shù)據(jù)平臺發(fā)展史系列文章的第二篇（共四篇）漾月，本系列以獨(dú)特的視角救斑，比較了非互聯(lián)網(wǎng)和互聯(lián)網(wǎng)兩個時代以及傳統(tǒng)與非傳統(tǒng)兩個行業(yè)世落。是對數(shù)據(jù)平臺發(fā)展的一個回憶尖飞，對非互聯(lián)網(wǎng)锭部、互聯(lián)網(wǎng)捏顺，從數(shù)據(jù)平臺的用戶角度、數(shù)據(jù)架構(gòu)演進(jìn)椿浓、模型等進(jìn)行了闡述太援。
前言，本篇幅將進(jìn)入大家熟知的互聯(lián)網(wǎng)時代扳碍，數(shù)據(jù)平臺發(fā)展史僅是自己經(jīng)歷過由傳統(tǒng)數(shù)據(jù)平臺到互聯(lián)網(wǎng)數(shù)據(jù)平臺發(fā)展一些簡單回憶提岔，在這一篇章中將引用部分互聯(lián)網(wǎng)數(shù)據(jù)平臺架構(gòu)，在這里僅作案例笋敞。
我相信很多從傳統(tǒng)行業(yè)轉(zhuǎn)到互聯(lián)網(wǎng)時是各種不適應(yīng)碱蒙，適應(yīng)短則幾個月，長則一年以上。進(jìn)入到互聯(lián)網(wǎng)有種感覺赛惩，它是一個擅長制造流行新概念的行業(yè)哀墓，“數(shù)據(jù)平臺“，”數(shù)據(jù)產(chǎn)品“也不幸免喷兼。數(shù)據(jù)平臺這詞Data PlatForm 也無從考究是從什么時間點(diǎn)被提出的篮绰，僅知道自己剛進(jìn)互聯(lián)網(wǎng)時”數(shù)據(jù)平臺“ 這個詞狹義代指數(shù)據(jù)倉庫了。
08年左右的Data Platform還泛指數(shù)據(jù)倉庫季惯，那時互聯(lián)網(wǎng)企業(yè)的數(shù)據(jù)倉庫剛興起沒幾年吠各，在建設(shè)思路上還是以傳統(tǒng)數(shù)據(jù)平臺的第二、三代架構(gòu)為參照物實(shí)施建設(shè)的勉抓。自己猜測那時很多互聯(lián)網(wǎng)企業(yè)也是使用Oracle贾漏、IBM、EMC 的軟硬件區(qū)做的各類系統(tǒng)的實(shí)施藕筋，自然數(shù)據(jù)平臺建設(shè)者都是來給電信纵散、移動、制造業(yè)等各大數(shù)據(jù)倉庫實(shí)施的甲方念逞、乙方各類牛人困食。
行業(yè)的差異性導(dǎo)致業(yè)務(wù)不同，影響到數(shù)據(jù)平臺源（數(shù)據(jù)源）的差異性翎承、隨著信息化共享與服務(wù)的這個“神奇”互聯(lián)網(wǎng)行業(yè)快速發(fā)展硕盹，互聯(lián)網(wǎng)業(yè)務(wù)逐漸的重視數(shù)據(jù)，所以互聯(lián)網(wǎng)的從業(yè)者在看數(shù)據(jù)叨咖、使用數(shù)據(jù)的方式每一年也不同瘩例、大數(shù)據(jù)的各種技術(shù)也在快速更新中，各方面因素導(dǎo)致了互聯(lián)網(wǎng)數(shù)據(jù)平臺的建設(shè)甸各、服務(wù)用戶特點(diǎn)垛贤、數(shù)據(jù)模型與非互聯(lián)網(wǎng)數(shù)據(jù)平臺有較為顯著差異墨状。
數(shù)據(jù)源
做數(shù)據(jù)的人城舞，從非互聯(lián)網(wǎng)進(jìn)入到互聯(lián)網(wǎng)最顯著的特點(diǎn)是面對的數(shù)據(jù)源類型忽然多了起來柒竞，在傳統(tǒng)企業(yè)數(shù)據(jù)人員面對的是結(jié)構(gòu)化存儲數(shù)據(jù)剥险，基本來自excel、表格蟀俊、DB系統(tǒng)等旗扑，在數(shù)據(jù)的處理技術(shù)上與架構(gòu)上是非常容易總結(jié)的捎谨，但是在互聯(lián)網(wǎng)因?yàn)闃I(yè)務(wù)獨(dú)特性導(dǎo)致了所接觸到的數(shù)據(jù)源特性多樣化诫尽，網(wǎng)站點(diǎn)擊日志禀酱、視頻、音頻牧嫉、圖片數(shù)據(jù)等很多非結(jié)構(gòu)化快速產(chǎn)生與保存剂跟，在這樣的數(shù)據(jù)源的多樣化與容量下采用傳統(tǒng)數(shù)據(jù)平臺技術(shù)來處理當(dāng)然是有些力不從心了（備注：IBM的科學(xué)家分析員道格.萊尼的一份數(shù)據(jù)增長報(bào)告基礎(chǔ)上提出了大數(shù)據(jù)的4V特性 大數(shù)據(jù)4v特性網(wǎng)上概念很多大家可以問度娘）减途。
目前最火熱的移動互聯(lián)網(wǎng),大家都在通過自己的手機(jī)、平板去訪問網(wǎng)站曹洽、購物等所以每個人都是數(shù)據(jù)的生產(chǎn)者鳍置，移動用戶在使用習(xí)慣上呈現(xiàn)移動化、碎片化送淆，以至于業(yè)務(wù)特性墓捻、商業(yè)模式比傳統(tǒng)互聯(lián)網(wǎng)又有顯著差別, 用戶在不同位置需求是不同的、使用APP 也是不同的坊夫、手機(jī)終端類型也是多樣化。這些差異性比較導(dǎo)致移動互聯(lián)網(wǎng)的數(shù)據(jù)與傳統(tǒng)的互聯(lián)網(wǎng)時代又產(chǎn)生顯著差異性撤卢。
例如買家通過Pc購物從瀏覽物品到支付可能在很短時間內(nèi)完成环凿，但是通過手購物碎片化就顯得多一些，可能在某個空余時間瀏覽物品放吩，保存或放入購物車智听，等有時間在去做支付。大約在2009年到2012年之間做用戶行為分析感覺很多原有網(wǎng)頁端拍下物品去支付渡紫，逐漸轉(zhuǎn)為PC端下單通過移動端支付到推。
我在這里整理一個表格不同時代數(shù)據(jù)源的差異性（備注可能整理的有點(diǎn)不全）：
行業(yè)域
非互聯(lián)網(wǎng)
互聯(lián)網(wǎng)
移動互聯(lián)網(wǎng)
數(shù)據(jù)來源(相對于數(shù)據(jù)平臺來講)
結(jié)構(gòu)化各類數(shù)據(jù)庫(DB系統(tǒng))、結(jié)構(gòu)化文本惕澎、Excel表格等莉测，少量word
Web、自定義唧喉、系統(tǒng)的日志捣卤，各類結(jié)構(gòu)化DB數(shù)據(jù)、長文本八孝、視頻 主要是來自網(wǎng)頁
除了互聯(lián)網(wǎng)那些外還含有大量定位數(shù)據(jù)、自動化傳感器、嵌入式設(shè)備婚被、自動化設(shè)備等
數(shù)據(jù)包含信息
CRM客戶信息酝润、事務(wù)性 ERP/MRPII 數(shù)據(jù)、資金賬務(wù)數(shù)據(jù) 等楼入。
除了傳統(tǒng)企業(yè)數(shù)據(jù)信息外哥捕，還含有用戶各類點(diǎn)擊日志、社交數(shù)據(jù)浅辙、多媒體扭弧、搜索、電郵數(shù)據(jù)等等
除了傳統(tǒng)互聯(lián)網(wǎng)的數(shù)據(jù)外记舆，還含有Gps鸽捻、穿戴設(shè)備、傳感器各類采集數(shù)據(jù)、自動化傳感器采集數(shù)據(jù)等等
數(shù)據(jù)結(jié)構(gòu)特性
幾乎都是結(jié)構(gòu)化數(shù)據(jù)
非結(jié)構(gòu)化數(shù)據(jù)居多
非結(jié)構(gòu)化數(shù)據(jù)居多
數(shù)據(jù)存儲/數(shù)據(jù)量
主要以DB結(jié)構(gòu)化存儲為主御蒲，從幾百兆到 百G級別
文件形式衣赶、DB形式，流方式厚满、 從TB 到PB
文件形式府瞄、流方式、DB范式碘箍，非結(jié)構(gòu)化 從TB 到PB
產(chǎn)生周期
慢遵馆，幾天甚至周為單位
秒或更小為單位
秒或更小為單位
對消費(fèi)者行為采集與還原
粒度粗
粒度較細(xì)
粒度非常細(xì)
數(shù)據(jù)價值
長期有效
隨著時間衰減
隨著時間快速衰減
單位時間內(nèi)數(shù)據(jù)聚合度
高度聚合
聚合度低
聚合度很低
該圖引用2013年“中國數(shù)據(jù)庫大會大數(shù)據(jù)的實(shí)踐與應(yīng)用”
數(shù)據(jù)平臺的用戶
總結(jié)下來互聯(lián)網(wǎng)的數(shù)據(jù)平臺“服務(wù)”方式迭代演進(jìn)大約可以分為三個階段。
階段一 ：
約在2008年-2011年初的互聯(lián)網(wǎng)數(shù)據(jù)平臺丰榴，那時建設(shè)與使用上與非互聯(lián)網(wǎng)數(shù)據(jù)平臺有這蠻大的相似性货邓，主要相似點(diǎn)在數(shù)據(jù)平臺的建設(shè)角色、與使用到的技術(shù)上四濒。
老板們换况、運(yùn)營的需求主要是依賴于報(bào)表、分析報(bào)告盗蟆、臨時需求戈二、商業(yè)智能團(tuán)隊(duì)的數(shù)據(jù)分析師去各種分析、臨時需求喳资、挖掘觉吭，這些角色是數(shù)據(jù)平臺的適用方。
ETL開發(fā)工程師仆邓、數(shù)據(jù)模型建模亏栈、數(shù)據(jù)架構(gòu)師、報(bào)表設(shè)計(jì)人員 宏赘，同時這些角色又是數(shù)據(jù)平臺數(shù)據(jù)建設(shè)與使用方绒北。
數(shù)據(jù)平臺的技術(shù)框架與工具實(shí)現(xiàn)主要有技術(shù)架構(gòu)師潭流、JAVA 開發(fā)等沿后。
用戶面對是結(jié)構(gòu)化的生產(chǎn)數(shù)據(jù)、PC端非結(jié)構(gòu)化log等 數(shù)據(jù)烙样。
ELT的數(shù)據(jù)處理方式（備注在數(shù)據(jù)處理的方式上贴汪，由傳統(tǒng)企業(yè)的ETL 基本進(jìn)化為ELT）脐往。
現(xiàn)在的淘寶是從2004年開始構(gòu)建自己的數(shù)據(jù)倉庫，2004年是采用DELL 的6650單節(jié)點(diǎn)扳埂、到2005年更換為 IBM 的P550 再到2008年的12節(jié)點(diǎn) Rac 環(huán)境业簿。在這段時間的在IBM、EMC阳懂、Oracle 身上的投入巨大(備注：對這段歷史有興趣可以去度娘：“【深度】解密阿里巴巴的技術(shù)發(fā)展路徑“)梅尤，同時淘寶的數(shù)據(jù)集群也變?yōu)閲鴥?nèi)最大的數(shù)據(jù)倉庫集群柜思。
我當(dāng)時用Oracle 搭建的數(shù)據(jù)倉庫做臨時需求時，一個經(jīng)過反復(fù)優(yōu)化的SQL語句在晚上9點(diǎn)放入能夠Running 凌晨4點(diǎn)多而被電話中狂吼的DBA給kill掉巷燥，痛不欲生赡盘。
因?yàn)榭焖倥蛎浀臄?shù)據(jù)量，在2010年開始考慮引進(jìn)Greenplum 最為主平臺提供強(qiáng)大的計(jì)算能力缰揪，但沒想到快速爆炸的數(shù)據(jù)量讓我們在POC測試階段就把Greenplum的適合業(yè)務(wù)場景定位清楚了陨享。
隨著2010年引入了hadoop&hive平臺進(jìn)行新一代的數(shù)據(jù)平臺的構(gòu)建，此時的Greenplum 因?yàn)閮?yōu)秀的IO吞吐量以及有限的任務(wù)并發(fā)安排到了網(wǎng)站日志的處理以及給分析師提供的數(shù)據(jù)分析服務(wù)钝腺。
該階段的數(shù)據(jù)模型是根據(jù)業(yè)務(wù)的特性采用退化抛姑、扁平化的模型設(shè)計(jì)方式去構(gòu)建的（備注：將會在模型篇章詳細(xì)講解）。
階段二：
互聯(lián)網(wǎng)的數(shù)據(jù)平臺除了受到技術(shù)艳狐、數(shù)據(jù)量的驅(qū)動外途戒，同時還來自數(shù)據(jù)產(chǎn)品經(jīng)理梳理用戶的需求按照產(chǎn)品的思維去構(gòu)建并部署在了數(shù)據(jù)的平臺上〗┏郏互聯(lián)網(wǎng)是一個擅長制造流程新概念的行業(yè)。約在2011年到2014 年左右唁毒，隨著數(shù)據(jù)平臺的建設(shè)逐漸的進(jìn)入快速迭代期蒜茴，數(shù)據(jù)產(chǎn)品、數(shù)據(jù)產(chǎn)品經(jīng)理這兩個詞逐漸的升溫以及被廣泛得到認(rèn)可（備注：數(shù)據(jù)產(chǎn)品相關(guān)內(nèi)容個人會在數(shù)據(jù)產(chǎn)品系列中做深入分享）浆西，同時數(shù)據(jù)產(chǎn)品也隨著需求粉私、平臺特性分為面向用戶級數(shù)據(jù)產(chǎn)品、面向平臺工具型產(chǎn)品兩個維度分別去建設(shè)數(shù)據(jù)平臺近零。
企業(yè)各個主要角色都是數(shù)據(jù)平臺用戶诺核。
各類數(shù)據(jù)產(chǎn)品經(jīng)理（偏業(yè)務(wù)數(shù)據(jù)產(chǎn)品、偏工具平臺數(shù)據(jù)產(chǎn)品）推進(jìn)數(shù)據(jù)平臺的建設(shè)久信。
分析師參與數(shù)據(jù)平臺直接建設(shè)比重增加窖杀。
數(shù)據(jù)開發(fā)、數(shù)據(jù)模型角色都是數(shù)據(jù)平臺的建設(shè)者與使用者（備注：相對與傳統(tǒng)數(shù)據(jù)平臺的數(shù)據(jù)開發(fā)來說裙士，逐漸忽略了數(shù)據(jù)質(zhì)量的關(guān)注度究珊，數(shù)據(jù)模型設(shè)計(jì)角色逐漸被弱化）沼琉。
用戶面對是數(shù)據(jù)源多樣化，比如日志、生產(chǎn)數(shù)據(jù)庫的數(shù)據(jù)初婆、視頻、音頻等非結(jié)構(gòu)化數(shù)據(jù)畦娄。
原有ETL中部分?jǐn)?shù)據(jù)轉(zhuǎn)換功能逐漸前置化加派，放到業(yè)務(wù)系統(tǒng)端進(jìn)行（備注：部分原有在ETL階段需要數(shù)據(jù)標(biāo)準(zhǔn)化一些過程前置在業(yè)務(wù)系統(tǒng)數(shù)據(jù)產(chǎn)生階段進(jìn)行，比如Log 日志南用。 移動互聯(lián)網(wǎng)的日志標(biāo)準(zhǔn)化膀钠。
互聯(lián)網(wǎng)企業(yè)隨著數(shù)據(jù)更加逐漸被重視掏湾，分析師、數(shù)據(jù)開發(fā)在面對大量的數(shù)據(jù)需求托修、海量的臨時需求疲憊不堪忘巧，變成了資源的瓶頸，在當(dāng)時的狀態(tài)傳統(tǒng)的各類的Report睦刃、Olap 工具都無法滿足互聯(lián)網(wǎng)行業(yè)個性化的數(shù)據(jù)需求砚嘴。開始考慮把需求固定化變?yōu)橐粋€面向最終用戶自助式、半自助的產(chǎn)品來滿足快速獲取數(shù)據(jù)&分析的結(jié)果涩拙，當(dāng)總結(jié)出的指標(biāo)际长、分析方法（模型）、使用流程與工具有機(jī)的結(jié)合在一起時數(shù)據(jù)產(chǎn)品就誕生了（備注：當(dāng)時為了設(shè)計(jì)一個數(shù)據(jù)產(chǎn)品曾經(jīng)閱讀了某個部門的2000多個臨時需求與相關(guān)SQL）兴泥。
數(shù)據(jù)產(chǎn)品按照面向的功能與業(yè)務(wù)可以劃分為面向平臺級別的工具型產(chǎn)品工育、面向用戶端的業(yè)務(wù)級數(shù)據(jù)產(chǎn)品。按照用戶分類可以分為面向內(nèi)部用戶數(shù)據(jù)產(chǎn)品搓彻，面向外部用戶個人數(shù)據(jù)產(chǎn)品如绸、商戶（企業(yè)）數(shù)據(jù)產(chǎn)品。
面向平臺級別有數(shù)據(jù)質(zhì)量旭贬、元數(shù)據(jù)怔接、調(diào)度、資管配置稀轨、數(shù)據(jù)同步分發(fā)等等扼脐。（備注：關(guān)于數(shù)據(jù)產(chǎn)品的發(fā)展與數(shù)據(jù)產(chǎn)品體系更多內(nèi)容，請關(guān)注個人寫作“數(shù)據(jù)產(chǎn)品系列”）奋刽。
約2010-2012年的平臺結(jié)構(gòu)
約2012-2013年的平臺結(jié)構(gòu)
//
我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史（二）：非互聯(lián)網(wǎng)時代 ? 下篇
http://www.infoq.com/cn/articles/the-development-history-of-big-data-platfor2-part01
編者按：本文是松子（李博源）的大數(shù)據(jù)平臺發(fā)展史系列文章的第二篇（共四篇）瓦侮，本系列以獨(dú)特的視角，比較了非互聯(lián)網(wǎng)和互聯(lián)網(wǎng)兩個時代以及傳統(tǒng)與非傳統(tǒng)兩個行業(yè)佣谐。是對數(shù)據(jù)平臺發(fā)展的一個回憶肚吏，對非互聯(lián)網(wǎng)、互聯(lián)網(wǎng)狭魂，從數(shù)據(jù)平臺的用戶角度寞酿、數(shù)據(jù)架構(gòu)演進(jìn)滑黔、模型等進(jìn)行了闡述椿每。
前言然低，”數(shù)據(jù)模型“ 這個詞只要是跟數(shù)據(jù)沾邊就會出現(xiàn)的一個詞，在數(shù)據(jù)庫設(shè)計(jì)掷伙、數(shù)據(jù)倉庫是己、數(shù)據(jù)挖掘上、業(yè)務(wù)里都存在任柜，聚焦一下卒废，這里提到的是數(shù)據(jù)平臺中的”數(shù)據(jù)模型“沛厨。 這是一個非常的抽象詞，個人也很難用簡單語言把他描述出來摔认，這一章也是整個系列中較為抽象的一章節(jié)逆皮，同時這個章節(jié)將會回答非互聯(lián)網(wǎng)數(shù)據(jù)平臺數(shù)據(jù)模型是什么？如何需要數(shù)據(jù)模型参袱？如何簡單的建設(shè)电谣？
在“我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史 上篇 非互聯(lián)網(wǎng)時代”曾經(jīng)提到Bill inmon與 Ralph kilmball兩位大師的設(shè)計(jì)理念，對業(yè)務(wù)的數(shù)據(jù)按照某種規(guī)則進(jìn)行有效組織并滿足業(yè)務(wù)需求抹蚀。
相關(guān)廠商內(nèi)容
關(guān)于紅包剿牺、SSD云盤等核心技術(shù)集錦！
Cloudant DBaaS技術(shù)概述
下一代 DB2更加突出 BLU Acceleration
小邪：阿里8屆雙11容量規(guī)劃這樣設(shè)計(jì)
在構(gòu)建過程中郑现，有一個角色理解業(yè)務(wù)并探索分散在各系統(tǒng)間的數(shù)據(jù)湃崩，并通過某條業(yè)務(wù)主線把這些分散在各角落的數(shù)據(jù)串聯(lián)并存儲同時讓業(yè)務(wù)使用，在設(shè)計(jì)時苦逼的地方除了考慮業(yè)務(wù)數(shù)據(jù)結(jié)構(gòu)要素外接箫，還得考慮可操作性攒读、約束性（備注 約束性是完成數(shù)據(jù)質(zhì)量提升的一個關(guān)鍵要素，未來新話題主題會討論這些）列牺，這個既要顧業(yè)務(wù)、數(shù)據(jù)源拗窃、合理的整合的角色是數(shù)據(jù)模型設(shè)計(jì)師瞎领，又叫數(shù)據(jù)模型師。
非互聯(lián)網(wǎng)時代的數(shù)據(jù)模型是一個高度智慧業(yè)務(wù)抽象結(jié)晶随夸，數(shù)據(jù)模型是整個系統(tǒng)建設(shè)過程的導(dǎo)航圖九默。
(點(diǎn)擊放大圖像)
[圖片上傳中。宾毒。驼修。（2）]
平臺中模型設(shè)計(jì)所關(guān)注的是企業(yè)分散在各角落數(shù)據(jù)正罢、未知的商業(yè)模式與未知的分析報(bào)表肴楷，通過模型的步驟库正，理解業(yè)務(wù)并結(jié)合數(shù)據(jù)整合分析傻寂，建立數(shù)據(jù)模型為Data cleaning 指定清洗規(guī)則运提、為源數(shù)據(jù)與目標(biāo)提供ETL mapping （備注：ETL 代指數(shù)據(jù)從不同源到數(shù)據(jù)平臺的整個過程妖爷，ETL Mapping 可理解為 數(shù)據(jù)加工算法霞玄，給數(shù)碼看的窜司，互聯(lián)網(wǎng)與非互聯(lián)網(wǎng)此處差異性也較為明顯焕毫，非互聯(lián)網(wǎng)數(shù)據(jù)平臺對ETL定義與架構(gòu)較為復(fù)雜）支持蹲坷、 理清數(shù)據(jù)與數(shù)據(jù)之間的關(guān)系驶乾。（備注：Data cleaning 是指的數(shù)據(jù)清洗 數(shù)據(jù)質(zhì)量相關(guān)不管是在哪個行業(yè)，是最令人頭痛的問題循签，分業(yè)務(wù)域级乐、技術(shù)域的數(shù)據(jù)質(zhì)量問題，需要通過事前盤點(diǎn)县匠、事中監(jiān)控风科、事后調(diào)養(yǎng)，有機(jī)會在闡述）聚唐。
大家來看一張較為嚴(yán)謹(jǐn)?shù)臄?shù)據(jù)模型關(guān)系圖：
(點(diǎn)擊放大圖像)
[圖片上傳中丐重。。杆查。（3）]
數(shù)據(jù)模型是整個數(shù)據(jù)平臺的數(shù)據(jù)建設(shè)過程的導(dǎo)航圖扮惦。
有利于數(shù)據(jù)的整合。數(shù)據(jù)模型是整合各種數(shù)據(jù)源指導(dǎo)圖亲桦，對現(xiàn)有業(yè)務(wù)與數(shù)據(jù)從邏輯層角度進(jìn)行了全面描述崖蜜，通過數(shù)據(jù)模型，可以建立業(yè)務(wù)系統(tǒng)與數(shù)據(jù)之間的映射與轉(zhuǎn)換關(guān)系客峭。排除數(shù)據(jù)描述的不一致性豫领。如：同名異義、同物異名..舔琅。
減少多余冗余數(shù)據(jù)等恐，因?yàn)榱私鈹?shù)據(jù)之間的關(guān)系，以及數(shù)據(jù)的作用备蚓。在數(shù)據(jù)平臺中根據(jù)需求采集那些用于分析的數(shù)據(jù)课蔬，而不需要那些純粹用于操作的數(shù)據(jù)。
在面對企業(yè)復(fù)雜業(yè)務(wù)與成千上萬的數(shù)據(jù)項(xiàng)進(jìn)行設(shè)計(jì)時郊尝，沒有哪個牛逼的人都記得住的二跋，所以出現(xiàn)了按照某種層次規(guī)則去有組織并抽象與管理易用蛾扇，由此誕生了概念模型烂瘫、邏輯模型、物理模型 (備注 數(shù)據(jù)平臺數(shù)據(jù)模型供置，而非數(shù)據(jù)挖掘的模型)况凉。
數(shù)據(jù)模型在數(shù)據(jù)平臺的數(shù)據(jù)倉庫中是一個統(tǒng)稱谚鄙，嚴(yán)格上來講分為概念模型、邏輯模型刁绒、物理模型襟锐。(備注：四類模型如何去詳細(xì)構(gòu)建文本不深講，關(guān)于非互聯(lián)網(wǎng)企業(yè)的數(shù)據(jù)模型網(wǎng)上非常多)
(點(diǎn)擊放大圖像)
[圖片上傳中膛锭。粮坞。蚊荣。（4）]
在“我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史 上篇 非互聯(lián)網(wǎng)時代“提到兩位大師的架構(gòu)與爭論，進(jìn)一步聚焦來說莫杈，爭論點(diǎn)我的認(rèn)為其實(shí)是在數(shù)據(jù)模型的支持上互例，Bill Inmon的EDW的原則是準(zhǔn)三范式的設(shè)計(jì)、Ralph kilmbal是星型結(jié)構(gòu)筝闹。
Bill Inmon對EDW 的定義是面向事物處理媳叨、面向數(shù)據(jù)管理，從數(shù)據(jù)的特征上需要堅(jiān)持維護(hù)最細(xì)粒度的數(shù)據(jù)关顷、維護(hù)最微觀層次的數(shù)據(jù)關(guān)系糊秆、保存數(shù)據(jù)歷史。所以在構(gòu)建完畢的數(shù)據(jù)平臺中可以從中映射并檢查業(yè)務(wù)信息的完整性（同時也是養(yǎng)數(shù)據(jù)過程中的重要反饋點(diǎn)）议双，這種方式還可以找出多個系統(tǒng)相關(guān)和重合的信息痘番，減少多個系統(tǒng)之間數(shù)據(jù)的重復(fù)定義和不一致性，減小了應(yīng)用集成的難度平痰。
(點(diǎn)擊放大圖像)
[//
我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史（四）：互聯(lián)網(wǎng)時代 ? 下篇
http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-internet-age
編者按：本文是松子（李博源）的大數(shù)據(jù)平臺發(fā)展史系列文章的第四篇（共四篇）汞舱，本系列以獨(dú)特的視角，比較了非互聯(lián)網(wǎng)和互聯(lián)網(wǎng)兩個時代以及傳統(tǒng)行業(yè)與非傳統(tǒng)行業(yè)宗雇。是對數(shù)據(jù)平臺發(fā)展的一個回憶昂芜，對非互聯(lián)網(wǎng)、互聯(lián)網(wǎng)赔蒲，從數(shù)據(jù)平臺的用戶角度泌神、數(shù)據(jù)架構(gòu)演進(jìn)、模型等進(jìn)行了闡述舞虱。
在互聯(lián)網(wǎng)時代被弱化的數(shù)據(jù)模型
談起數(shù)據(jù)模型就不得不提傳統(tǒng)數(shù)據(jù)平臺架構(gòu)發(fā)展欢际，我相信很多朋友都曉得傳統(tǒng)數(shù)據(jù)平臺的知識，其架構(gòu)演進(jìn)簡單一句話說“基本上可以分為五個時代砾嫉、四種架構(gòu)”幼苛，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與數(shù)據(jù)源類型多樣化特點(diǎn)串塑，從高階架構(gòu)上來看大約從傳統(tǒng)數(shù)據(jù)平臺第三代架構(gòu)開始延續(xù)的恢氯，但是往后的發(fā)展從我自己的這一點(diǎn)知識上很難對互聯(lián)網(wǎng)的數(shù)據(jù)平臺做架構(gòu)歸類轿塔。
但是從數(shù)據(jù)平臺建設(shè)與服務(wù)角色上還是有章可循的。就像上篇分享到那樣配并，類比兩個行業(yè)，互聯(lián)網(wǎng)企業(yè)中員工年齡比非互聯(lián)網(wǎng)企業(yè)的要年輕高镐、受教育程度溉旋、對計(jì)算機(jī)的焦慮程度明顯比傳統(tǒng)企業(yè)要低、還偶遇其它各方面的緣故嫉髓，導(dǎo)致了數(shù)據(jù)平臺所面對用戶群體與非互聯(lián)網(wǎng)數(shù)據(jù)平臺有所差異化观腊。
傳統(tǒng)行業(yè)與互聯(lián)網(wǎng)行業(yè)數(shù)據(jù)平臺用戶特性我只選擇前文章的兩張圖來表示
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
在傳統(tǒng)數(shù)據(jù)平臺要背后有一個完整數(shù)據(jù)倉庫團(tuán)隊(duì)去服務(wù)業(yè)務(wù)方邑闲，業(yè)務(wù)方嗷嗷待哺的等待被動方式去滿足。中低層數(shù)據(jù)基本不會對業(yè)務(wù)方開放梧油，所以不管數(shù)據(jù)模型采用何種建模方式苫耸，主要滿足當(dāng)時數(shù)據(jù)架構(gòu)規(guī)劃即可。
互聯(lián)網(wǎng)業(yè)務(wù)的快速發(fā)展使得大家已經(jīng)從經(jīng)營儡陨、分析的訴求重點(diǎn)轉(zhuǎn)為數(shù)據(jù)化的精細(xì)運(yùn)營上褪子，如何做好精細(xì)化運(yùn)營問題上來，當(dāng)資源不夠時用戶就叫喊骗村，甚至有的業(yè)務(wù)方會挽起袖子來自己參與到從數(shù)據(jù)整理嫌褪、加工、分析階段胚股。
此時呢笼痛，原有建設(shè)數(shù)據(jù)平臺的多個角色（數(shù)據(jù)開發(fā)、模型設(shè)計(jì)）可能轉(zhuǎn)為對其它非專業(yè)使用數(shù)據(jù)方信轿，做培訓(xùn)晃痴、咨詢與落地，寫更加適合當(dāng)前企業(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àn)椴粚I(yè)性即彪，導(dǎo)致數(shù)據(jù)質(zhì)量問題紧唱、重復(fù)對分?jǐn)?shù)據(jù)浪費(fèi)存儲與資源、口徑多樣化隶校、編碼不統(tǒng)一漏益、命名問題等等原因。數(shù)據(jù)質(zhì)量逐漸變成一個特別突出的問題深胳。
傳統(tǒng)企業(yè)的數(shù)據(jù)源基本來自excel绰疤、表格、DB系統(tǒng)等舞终，但在互聯(lián)網(wǎng)有網(wǎng)站點(diǎn)擊流日志摔癣、視頻贾虽、音頻、圖片數(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ù)有些力不從心。
當(dāng)數(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è)也有自己特點(diǎn)，傳統(tǒng)行業(yè)所涉及數(shù)據(jù)模型這個領(lǐng)域涉及的很多內(nèi)容在互聯(lián)網(wǎng)變成以其他的曲線救國的方式存在了醉途。
在互聯(lián)網(wǎng)曲線救國新解決
回顧在傳統(tǒng)行業(yè)數(shù)據(jù)平臺中矾瑰，不管兩位大師爭論點(diǎn)數(shù)據(jù)模型的設(shè)計(jì)采用那種范式（Bill Inmon的EDW的原則是準(zhǔn)三范式的設(shè)計(jì)、Ralph kilmbal是星型結(jié)構(gòu)）但是都要非常重視數(shù)據(jù)源的質(zhì)量問題隘擎。所以傳統(tǒng)行業(yè)的數(shù)據(jù)模型會全盤考慮數(shù)據(jù)質(zhì)量問題殴穴，并通過數(shù)據(jù)抽樣分析給出合適的清洗口徑。
(點(diǎn)擊放大圖像)
上圖來自我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ù)”對一年的還是不準(zhǔn)的）休傍。在應(yīng)對數(shù)據(jù)的質(zhì)量問題，目前互聯(lián)網(wǎng)有些做法是把數(shù)據(jù)標(biāo)準(zhǔn)化前置到業(yè)務(wù)數(shù)據(jù)產(chǎn)生就做蹲姐，從根源上去杜絕數(shù)據(jù)質(zhì)量磨取，但是這種場景比較實(shí)用在Log 日志的數(shù)據(jù)源中，比如移動互聯(lián)網(wǎng)最近流行的基于事件模型“Event”模型柴墩，在日志產(chǎn)生時就規(guī)定好存儲格式（備注：大家度娘搜索忙厌，“學(xué)習(xí)筆記：The Log（我所讀過的最好的一篇分布式技術(shù)文章）” 對這個講解很詳細(xì)）。
在傳統(tǒng)行業(yè)江咳，目前還是以混合模型設(shè)計(jì)方式為主逢净。在互聯(lián)網(wǎng)的我所接觸的一些業(yè)務(wù)，在參照傳統(tǒng)數(shù)據(jù)模型方法論基礎(chǔ)上逐步演進(jìn)適合互聯(lián)網(wǎng)數(shù)據(jù)的數(shù)據(jù)模型方法歼指。
比如互聯(lián)網(wǎng)金融等一些業(yè)務(wù)會參考傳統(tǒng)金融行業(yè)對主題域的劃分肴楷、OMG數(shù)據(jù)倉庫元數(shù)據(jù)管理CWM模型潘拱、FSDM金融模型牢裳，再進(jìn)一步考慮大數(shù)據(jù)處理特性去進(jìn)行設(shè)計(jì)参咙，所有從Hight Level 數(shù)據(jù)架構(gòu)圖看到主題層次劃分與傳統(tǒng)第三代數(shù)據(jù)倉庫還是很多相似之處犀农，當(dāng)然模型架構(gòu)也有分三層惰赋、四層、五層的。
不同的地方模型細(xì)節(jié)處理上已經(jīng)完全不一樣赁濒，比如數(shù)據(jù)的多樣性轨奄、拉寬事實(shí)表、度量值單獨(dú)存儲拒炎、滿足數(shù)據(jù)快速重生挪拟、維度的二次降維處理等、增加大量冗余列击你、增加大量派生列玉组，結(jié)合自動化元數(shù)據(jù)來耦合、合并等相關(guān)管理丁侄。
(點(diǎn)擊放大圖像)
[圖片上傳中惯雳。。鸿摇。（4）]
上圖是支付寶非常早期數(shù)據(jù)模型
(點(diǎn)擊放大圖像)
上圖是支付寶非常早期數(shù)據(jù)模型
我們常提到的多維模型在大數(shù)據(jù)處理下進(jìn)行了退化維度處理石景。大家知道Olap多維模型，隨著維度的增加事實(shí)表的數(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è)計(jì)多維挖掘分析數(shù)據(jù)產(chǎn)品背后的技術(shù)就是搜索引擎實(shí)現(xiàn)的）筷黔，現(xiàn)在應(yīng)該也有新技術(shù)出現(xiàn)了來解決類似的問題往史。
(點(diǎn)擊放大圖像)
上圖為2012年產(chǎn)品UI之一。
(點(diǎn)擊放大圖像)
[圖片上傳中佛舱。怠堪。。（7）]
上圖是2011-2012年該產(chǎn)品系列背后當(dāng)時使用的技術(shù)
互聯(lián)網(wǎng)業(yè)務(wù)特點(diǎn)業(yè)務(wù)垂直拆分非常細(xì)名眉，比如一個用戶注冊粟矿、密碼找回的流程有可能存在好幾個產(chǎn)品負(fù)責(zé)同一個業(yè)務(wù)流程不同環(huán)節(jié)，相關(guān)的一個策略损拢、產(chǎn)品feature快速迭代上線等等都要數(shù)據(jù)評估陌粹。數(shù)據(jù)從前端埋點(diǎn)到采集然后再由各個環(huán)節(jié)到數(shù)據(jù)平臺，再有數(shù)據(jù)分析師或各業(yè)務(wù)部門去使用福压，基本拉長了時間周期掏秩。需求部門與實(shí)施部門能力和經(jīng)驗(yàn)有千差萬別的需求该镣，造成了懂技術(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ù)特點(diǎn)是變化非常迅速的抒和，能穩(wěn)定的業(yè)務(wù)達(dá)到65%算對數(shù)據(jù)平臺是個福音了（根據(jù)對某寶寶的印象）剩余的業(yè)務(wù)變化迅速矫渔，必然導(dǎo)致數(shù)據(jù)模型快速上下線。
Kimball老人家提出的維度建模（備注摧莽，在本系列發(fā)展史得第一篇有介紹）圍繞業(yè)務(wù)模型能夠非常直觀的表達(dá)出業(yè)務(wù)的數(shù)據(jù)關(guān)系庙洼，但是在互聯(lián)網(wǎng)NOSQL犧牲掉了關(guān)系型數(shù)據(jù)庫的一致性、完整性等等很多東西镊辕。維度數(shù)據(jù)模型又基于這些大數(shù)據(jù)技術(shù)的油够，所以進(jìn)化的更加輕量級與基于細(xì)節(jié)數(shù)據(jù)的維度退化建模（原有的緩慢變化維、快速變化維征懈、大維叠聋、迷你維、父子維受裹、雪花維為了適應(yīng)互聯(lián)網(wǎng)的大數(shù)據(jù)Nosql處理技術(shù)進(jìn)行反規(guī)范化碌补、化&數(shù)據(jù)冗余設(shè)計(jì)。
退化維度的反規(guī)范化設(shè)計(jì)一方面可以把一條查詢語句所需要的所有數(shù)據(jù)組合起來放到一個地方存儲 Key values 的方式（比如說商品有不同類型棉饶，每一種類型商品又有自己的不同屬性厦章，可以采用一對多、多對多的方式存儲照藻，例如把一個多維映射為一個Key value）袜啃。
講到互聯(lián)網(wǎng)數(shù)據(jù)平臺就要提數(shù)據(jù)模型，提了數(shù)據(jù)模型就要提Nosql技術(shù)幸缕，
(點(diǎn)擊放大圖像)
上圖來自Nosql文檔系列的一幅圖
Nosql 是大數(shù)據(jù)處理的特征之一群发。互聯(lián)網(wǎng)數(shù)據(jù)平臺數(shù)據(jù)模型與NoSql技術(shù)還是蠻緊密的发乔。這里有外文講解Nosql Data modeling technigues 從技術(shù)角度講解非常詳（https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/）熟妓。
因?yàn)榍斑吿岬降拇髷?shù)據(jù)平臺技術(shù)特性決定了傳統(tǒng)edw模型、維度模型直接在互聯(lián)網(wǎng)數(shù)據(jù)大數(shù)據(jù)平臺部署或許還有“好些未知”障礙等待大家去克服栏尚。同時在傳統(tǒng)數(shù)據(jù)建模用到的一些方法經(jīng)過互聯(lián)網(wǎng)熏陶或許演進(jìn)成一種新的數(shù)據(jù)產(chǎn)品或方案吧起愈。
到此為止“我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史”上下共四篇與大家分享完畢，這個寫作前后經(jīng)歷剛好一個月左右译仗，算是對自己數(shù)據(jù)從業(yè)經(jīng)歷回顧之一吧抬虽。在知識的整理中很多都是蜻蜓點(diǎn)水，每個知識域都是一個非常深的專業(yè)方向，自己涉足很膚淺，在文章中分享不足之處請各位讀者見諒＜呛小！
個人郵箱是5592094@qq.com 歡迎電郵交流廊遍。
接下來我會進(jìn)入數(shù)據(jù)產(chǎn)品這個領(lǐng)域的分享已艰，當(dāng)年車品覺老師自豪的作品之一“黃金策”捻勉，我是數(shù)據(jù)產(chǎn)品經(jīng)理骚勘。（ps：自己躲在墻角拿車品覺老師往自己臉上貼金了）隘膘。
后記
有一次數(shù)據(jù)產(chǎn)品神策的創(chuàng)始人兼好友@桑文鋒＠SensorsData跟我說來做次分享吧，我當(dāng)時出了幾個題目杠览，最后就選擇了“我所經(jīng)歷的大數(shù)據(jù)平臺“弯菊，就形成了大家看到的”我所經(jīng)歷的大數(shù)據(jù)平臺“系列文章.
在整理期間得到了死黨@周愛民、@神策-桑文峰踱阿、 InfoQ小編@Tina Du 管钳、@betty zhou @Laurel大力協(xié)助，在這里感謝Ｈ砩唷２牌帷！
番外篇
這一篇是在24日舉行的分享大家提到的一些問題佛点，經(jīng)過整理算是對正文的補(bǔ)充吧醇滥，從互聯(lián)網(wǎng)敏捷數(shù)據(jù)模型等角度做了較深入的細(xì)節(jié)介紹。同時在數(shù)據(jù)產(chǎn)品方面的回答包含了一點(diǎn)未來寫作篇“數(shù)據(jù)產(chǎn)品”系列的一點(diǎn)內(nèi)容超营。
1****鸳玩，傳統(tǒng)我們做BI的，做數(shù)據(jù)展現(xiàn)會建模后以pivot展現(xiàn)cube數(shù)據(jù)演闭，不知道現(xiàn)在互聯(lián)網(wǎng)公司數(shù)據(jù)展示如何做的不跟？第三方工具還是用API取數(shù)據(jù)平臺里的數(shù)據(jù)？adhoc報(bào)表及靈活更換維度的時候web端一般是怎么做的米碰？
松子老師：剛才文章中提到了比如傳統(tǒng)行業(yè)的多維數(shù)據(jù)模型cube窝革。在互聯(lián)網(wǎng)采用的曲線救國方式解決的。 在分享中我給出了幾個圖吕座。就是通過搜索引擎曲線救國方式實(shí)現(xiàn)類似Olap的模擬虐译。
在這塊的模型的處理上采用的是維度退化處理。通過反規(guī)范化吴趴，數(shù)據(jù)項(xiàng)菱蔬、數(shù)據(jù)冗余去處理。在前端做特殊處理史侣。
這個當(dāng)時產(chǎn)品原型之一：
(點(diǎn)擊放大圖像)
這是一個2011年-2012年左右的數(shù)據(jù)產(chǎn)品拴泌，當(dāng)時算是即時計(jì)算的一種。不過已經(jīng)過去好幾年了惊橱，當(dāng)今新技術(shù)下Olap 引擎應(yīng)該有很好的提升蓬豁。
目前我知道的家互聯(lián)網(wǎng)公司，在前端展現(xiàn)有使用第三方套件比如spagoBi怠惶、pentaho 等 有自己設(shè)計(jì)開發(fā)定制化數(shù)據(jù)前端展現(xiàn)。比如我剛開始分享的那兩個之前在去哪兒網(wǎng)設(shè)計(jì)的數(shù)據(jù)平臺內(nèi)部界面之一家制，當(dāng)然數(shù)據(jù)產(chǎn)品是另一個話題了，通過對數(shù)據(jù)分析抽象指標(biāo)泡一、分析模型颤殴、用戶使用功能與流程、未來規(guī)劃考慮用戶體驗(yàn)去設(shè)計(jì)鼻忠。
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
[圖片上傳中涵但。。帖蔓。（11）]
(點(diǎn)擊放大圖像)
2****矮瘟，互聯(lián)網(wǎng)財(cái)經(jīng)類公司，業(yè)務(wù)包括財(cái)經(jīng)網(wǎng)站塑娇、基金澈侠、股票、金融等埋酬，這類公司的數(shù)據(jù)倉庫模型應(yīng)該如何設(shè)計(jì)哨啃？特點(diǎn)和注意事項(xiàng)是什么？案例介紹写妥？十分感謝棘催。
松子老師：我自己經(jīng)歷過的是互聯(lián)網(wǎng)金融以及移動互聯(lián)網(wǎng)行。對這兩塊比較清楚耳标〈及樱互聯(lián)網(wǎng)金融起因?yàn)闃I(yè)務(wù)的特性是類金融類的，與銀行有些地方是相似的次坡。
比如大約在2012年前支付寶業(yè)務(wù)特點(diǎn)涉及類金融交易：充值呼猪、提現(xiàn)、賬務(wù)管理類電子商務(wù)：購物交易過程變更砸琅、實(shí)際交易（對B機(jī)票宋距、對C水電等） 非純電子商務(wù)；純金融症脂；個人信用谚赎，理財(cái)類。系統(tǒng)之間依賴度較為復(fù)雜诱篷，垂直依賴（業(yè)務(wù)與核心）跨層依賴（跨過交易到賬務(wù)）壶唤。
在設(shè)計(jì)方法上還是采用維度模型設(shè)計(jì)方式。底層是數(shù)據(jù)驅(qū)動為向?qū)ё厮Y(jié)合業(yè)務(wù)需求驅(qū)動闸盔，通過簡單、退化維度的方式拉寬表結(jié)構(gòu)。
底層采用松耦合設(shè)計(jì)试躏。主題之間是松耦合方式士飒。至體內(nèi)采用細(xì)粒度退化維度奕锌。
在主題域上的的設(shè)計(jì)基本參考了OMG的數(shù)據(jù)倉庫元數(shù)據(jù)設(shè)計(jì)CWM模型、IBM 的fsdm金融模型烹困、還有新巴塞爾資本協(xié)議（Basel II Capital Accord）需提供數(shù)據(jù)規(guī)范去的設(shè)計(jì)楞遏。所以數(shù)據(jù)模型是五層的結(jié)構(gòu)搔预。
在細(xì)節(jié)處理上蔫巩，增量ODS層數(shù)據(jù)和前一天DWD相關(guān)表進(jìn)行 merge處理谆棱。
在一些層次上，基本聚合批幌、匯總增加派生事實(shí)表（簡單一句話退化為度打?qū)挘┐∪瘛Ｈ缓蟀凑諛I(yè)務(wù)主體合并信息等嗓节。
比如開始給大家分享的那張圖：
(點(diǎn)擊放大圖像)
[圖片上傳中荧缘。。拦宣。（13）]
在維度模型退化處理時截粗，要注意最細(xì)粒度數(shù)據(jù)保留、不同層次的數(shù)據(jù)支持?jǐn)?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ù)模型。
這種元數(shù)據(jù)驅(qū)動工具型數(shù)據(jù)產(chǎn)品我會在未來數(shù)據(jù)產(chǎn)品系列中做詳細(xì)介紹的外驱。
3****育灸，互聯(lián)網(wǎng)企業(yè)大數(shù)據(jù)平臺的發(fā)展歷程是怎樣的？
松子老師：這個我相信應(yīng)該是傳統(tǒng)數(shù)據(jù)平臺朋友提到的昵宇。傳統(tǒng)行業(yè)數(shù)據(jù)平臺架構(gòu)演進(jìn)我總結(jié)簡單一句話說“基本上可以分為五個時代磅崭、四種架構(gòu)”，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與類型暴增的特點(diǎn)瓦哎，從高階架構(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é)下來用戶特點(diǎn)：
(點(diǎn)擊放大圖像)
[圖片上傳中犯助。蜂桶。。（14）]
更加詳細(xì)的每一代數(shù)據(jù)平臺建設(shè)也切、服務(wù)角色特點(diǎn)您可以看我這個系列文章的第三篇，http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-paet02
4****蟹瘾，有沒有好的元數(shù)據(jù)管理工具推薦察净？主要偏向數(shù)據(jù)字典與血統(tǒng)等。
松子老師：元數(shù)據(jù)以前目前沒有太多的好管理工具费坊。以前是在支付寶是我自己設(shè)計(jì)的一個數(shù)據(jù)產(chǎn)品。第一版自己用Delphi 開發(fā)的旬痹。
（圖很多：）
(點(diǎn)擊放大圖像)
[圖片上傳中附井。。两残。（15）]
(點(diǎn)擊放大圖像)
[圖片上傳中永毅。。人弓。（16）]
(點(diǎn)擊放大圖像)
[圖片上傳中沼死。。崔赌。（17）]
(點(diǎn)擊放大圖像)
[圖片上傳中意蛀。。健芭。（18）]
(點(diǎn)擊放大圖像)
[圖片上傳中县钥。。慈迈。（19）]
以前被逼的自己寫了一個若贮，通過解析，實(shí)現(xiàn)了字段級的血緣影響分析痒留。這只是第二步谴麦，后來又把running 信息給搞了進(jìn)來。還有分享時提到的模型信息狭瞎、整個閉環(huán)的分類信息细移。
這是一個分支：
(點(diǎn)擊放大圖像)
[圖片上傳中。熊锭。弧轧。（20）]
但是我們實(shí)現(xiàn)了字段級解析準(zhǔn)確率達(dá)到了94%左右。有細(xì)微的錯誤就人工revew一遍碗殷。
5. ****松子老師精绎，數(shù)據(jù)管控的數(shù)據(jù)質(zhì)量部分是怎么處理的呢？
松子老師： 數(shù)據(jù)管控锌妻， 這方面我不太懂的代乃，但是數(shù)據(jù)質(zhì)量，這玩意可大可小的。比如像在分享時說過的搁吓，在移動互聯(lián)網(wǎng)的數(shù)據(jù)質(zhì)量處理方式可以由原有的ETL(ELT)階段前置到業(yè)務(wù)系統(tǒng)去解決原茅，比如移動互聯(lián)網(wǎng)的App log 日志菇民，日志標(biāo)準(zhǔn)化后事件模型”存儲來解決雾家。那非app 日志類如何解決呢比如Payment、order等寞埠，數(shù)據(jù)質(zhì)量比較考慮的可以只做到監(jiān)控摩骨。
我來分享個圖通贞。剛好是我設(shè)計(jì)數(shù)據(jù)質(zhì)量產(chǎn)品時搞的，理清數(shù)據(jù)質(zhì)量的問題：
(點(diǎn)擊放大圖像)
[圖片上傳中恼五。昌罩。。（21）]
(點(diǎn)擊放大圖像)
[圖片上傳中灾馒。茎用。。（22）]
(點(diǎn)擊放大圖像)
[圖片上傳中你虹。绘搞。彤避。（23）]
只要數(shù)據(jù)進(jìn)入倉庫與應(yīng)用體系傅物，處理起來就比較困難了，所以在數(shù)據(jù)平臺階段最好是通過監(jiān)控琉预、前置去解決董饰。目前數(shù)據(jù)質(zhì)量確實(shí)難以100%由事后搞到事前去處理。我對數(shù)據(jù)平臺與數(shù)據(jù)產(chǎn)品的建設(shè)就是實(shí)用為主圆米。怎么實(shí)用怎么來卒暂。我是比較現(xiàn)實(shí)的實(shí)用主義者。
6. ****能否分享一些數(shù)據(jù)產(chǎn)品種類及實(shí)例：
松子老師：在前邊五個問題娄帖、以及文章中又都涉及數(shù)據(jù)產(chǎn)品實(shí)力的一些分享也祠。
提到數(shù)據(jù)產(chǎn)品的分類我就想把這個圖發(fā)出來。
自己認(rèn)為沒有特別明確的劃分線近速，但是數(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工具首繁、資源管控等等作郭。
面向用戶功能有報(bào)表型陨囊、多維型數(shù)據(jù)產(chǎn)品、定制化數(shù)據(jù)產(chǎn)品、挖掘型數(shù)據(jù)產(chǎn)品。
面向內(nèi)部用戶巫糙、外部個人用戶市袖、外部企業(yè)用戶又有不同的分類。
根據(jù)業(yè)務(wù)又可以劃分很多蜈敢，面向C類用戶、面向B類商戶、金融風(fēng)險(xiǎn)等等
從近幾年的數(shù)據(jù)產(chǎn)品來看无蜂，是更好的輔助用戶的做決策的一種產(chǎn)品形態(tài)，在用戶的決策與行動中充當(dāng)信息的分析者與價值使用者蒙谓；數(shù)據(jù)產(chǎn)品有個自己的共性：由解決的一個實(shí)際的業(yè)務(wù)問題出發(fā)斥季，分解出的分析指標(biāo)，分析模型累驮，分析流程組成酣倾，再考慮到功能易用性，未來功能擴(kuò)展谤专，考慮用戶對數(shù)據(jù)易用性（比如數(shù)據(jù)的呈現(xiàn)層次躁锡，不可能一次把所有數(shù)據(jù)的呈現(xiàn)給用戶）來組成的。
(點(diǎn)擊放大圖像)
[圖片上傳中置侍。映之。。（24）]
7. ****銀行業(yè)從傳統(tǒng)的ods到edw再到大數(shù)據(jù)平臺這塊過渡蜡坊，模型如何建設(shè)杠输？平臺優(yōu)勢如何發(fā)揮？
松子老師：這個問題還是有些難度的秕衙，自己回答的可能有些片面蠢甲。首先我們清醒的清楚“大數(shù)據(jù)”是什么？再次不同的場景可以采用不同的技術(shù)去解決据忘。
“大數(shù)據(jù)”鹦牛，拆開來看大、數(shù)據(jù)若河，大可以是指的數(shù)據(jù)源結(jié)構(gòu)簡單（ps 如果了解過當(dāng)代對大數(shù)據(jù)的定義就知道四個特性）但是量級夠大能岩，比如清算、結(jié)算萧福、對公拉鹃、對私、中間業(yè)務(wù)等等每一個拿出來都是幾十T，但是這些業(yè)務(wù)數(shù)據(jù)都是保存?zhèn)鹘y(tǒng)的關(guān)系型數(shù)據(jù)庫中如DB2膏燕、Oracle钥屈、MSsql中，因?yàn)樵跀?shù)據(jù)平臺存儲是通過準(zhǔn)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ù)的去演進(jìn)解決邦邦。（最早時我的是中信銀行、光大銀行在2011年左右開始考慮Hadoop技術(shù)未辆，后來不知道如何了）。
但是互聯(lián)網(wǎng)的數(shù)據(jù)平臺技術(shù)大都是NOSQL模式锯玛，犧牲掉了傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)一致性咐柜、完整性、唯一索引等等攘残，只干性能的事情（當(dāng)然除了性能拙友、可擴(kuò)展性也是的）.
原有在傳統(tǒng)數(shù)據(jù)平臺模型設(shè)計(jì)上可以考慮的一些通過主外鍵、唯一索引做一些業(yè)務(wù)約束的方法歼郭，在nosql上統(tǒng)統(tǒng)的都沒有了遗契，這些約束必須放到數(shù)據(jù)加工階段去想辦法做檢查。傳統(tǒng)數(shù)據(jù)平臺如果在Insert实撒、update數(shù)據(jù)時違反了業(yè)務(wù)約束可以做報(bào)警或異常處理姊途，但是在Nosql的平臺上要求ETL 去手動遵守這些規(guī)則檢查涉瘾。但是有時ETL開發(fā)根本不遵守的知态，僅僅是兩個表關(guān)聯(lián)起來，也可能忘記按照某一個業(yè)務(wù)唯一索引做去重操作立叛。簡單說负敏，原有靠關(guān)系型數(shù)據(jù)庫本身機(jī)制去做檢查一些規(guī)則變?yōu)槿斯ぃ優(yōu)槿斯ぞ蜁稿e秘蛇。
從關(guān)系型數(shù)據(jù)平臺往Nosql數(shù)據(jù)平臺遷移時其做，尤其是對傳統(tǒng)行業(yè)的業(yè)務(wù)來說，在模型設(shè)計(jì)階段赁还、以及給出的ETL口徑要考慮更多的業(yè)務(wù)規(guī)則檢查妖泄，其次要考慮更多的維度退化、多冗余艘策、表打?qū)捥幚淼负：唵握f就是發(fā)揮數(shù)據(jù)平臺的計(jì)算能力同時要更加的各方面確保數(shù)據(jù)準(zhǔn)確安全可靠。
數(shù)據(jù)模型ODS 到EDW 這塊的設(shè)計(jì)方法百度上留下的文檔資料太多的了，請這位提問的老師百度吧罚渐。
**8****．大數(shù)據(jù)****倉庫****中如何做快速****維處****理却汉？互****聯(lián)****網(wǎng)數(shù)****倉****數(shù)據(jù)****質(zhì)****量不好如何****對****數(shù)，如何確立****標(biāo)****準(zhǔn)的****對****數(shù)口徑荷并？******
松子老師：快速變化維度可以轉(zhuǎn)化為緩慢變化為來出來合砂，我自己理解的快速維度是相對于緩慢維度參照的來說的。
舉個例子源织，年齡-轉(zhuǎn)化為天數(shù)可以是定義快速變化維度翩伪，因?yàn)槊刻於荚谧兓Ｎ覀兛梢园涯挲g退化為區(qū)間維度來處理谈息，還可以把年齡做成動態(tài)維度來處理弄捕，事實(shí)表中保存的就是實(shí)際的出生年月并打?qū)挶恚挲g(天)通過計(jì)算方式來處理噩茄。還有種方法通過對代理鍵的方式來處理炉峰。
我目前也不知道對數(shù)據(jù)的標(biāo)準(zhǔn)是什么。但是我自己用的方法傅瞻，把一個指標(biāo)的整個數(shù)據(jù)流向切出幾個關(guān)鍵點(diǎn)通過SQL去實(shí)現(xiàn)對數(shù)踢代，看波動振幅，波動曲線嗅骄。同時還會比如發(fā)不通的版本的小流量測試的方式來做數(shù)據(jù)校對胳挎。
9****． 做為數(shù)據(jù)行業(yè)從業(yè)者，需要掌握哪些重要的基礎(chǔ)知識溺森？另：如果從零開始建立一個數(shù)據(jù)平臺慕爬，需要哪些資源配置（人，財(cái)屏积，物医窿，技術(shù)）？大致總投資額度多少炊林？如果同行產(chǎn)品間多種來源的數(shù)據(jù)姥卢，可有成熟的解決方案？謝謝…
松子老師：這個問題太宏觀了渣聚。作為數(shù)據(jù)行業(yè)從業(yè)者独榴，需要掌握哪些重要基礎(chǔ)知識，這個是要看從事具體數(shù)據(jù)域的垂直行業(yè)奕枝。
比如說 數(shù)據(jù)開發(fā)棺榔、數(shù)據(jù)模型、數(shù)據(jù)產(chǎn)品隘道、數(shù)據(jù)分析師症歇、數(shù)據(jù)運(yùn)營捞烟、數(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ù)目標(biāo)不太明確下壹置，難以確定方案竞思，人員配置上選用不同技術(shù)方案去搭建的配置是不太一樣的，比如說傳統(tǒng)平臺來講钞护，運(yùn)維悔据、DBA探越、數(shù)據(jù)開發(fā)、數(shù)據(jù)模型、報(bào)表人員兴猩。
從互聯(lián)網(wǎng)數(shù)據(jù)平臺基本配置上介陶，數(shù)據(jù)架構(gòu)師鞠呈、運(yùn)維藐唠、底層大數(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ù)泉哈。
10. Standalone****模式下，Model.save(Path)怎么一直提示錯誤破讨，是不是配置Spark時需要將Hdfs的配置引進(jìn)來啊～？表示初學(xué)Spark
松子老師：這個問題有點(diǎn)超出我的能力范圍了奕纫，所以對不起回答不了提陶。
我本身不是做技術(shù)的。僅知道一點(diǎn)技術(shù)名詞匹层。
11. ****傳統(tǒng)銀行業(yè)數(shù)據(jù)模型什么時候會走向互聯(lián)網(wǎng)模式呢隙笆？目前在傳統(tǒng)銀行數(shù)據(jù)平臺的產(chǎn)品是不是特別多锌蓄？
松子老師：這個問題我自己就不知道了，或許是傳統(tǒng)銀行在數(shù)據(jù)平臺的實(shí)施上全面用互聯(lián)網(wǎng)的Nosql大數(shù)據(jù)處理技術(shù)吧撑柔。至于說傳統(tǒng)銀行數(shù)據(jù)模型用現(xiàn)有的互聯(lián)網(wǎng)數(shù)據(jù)模型理念去設(shè)計(jì)是否完全可行瘸爽，數(shù)據(jù)一致性、高準(zhǔn)確性通過更多的方案去保證铅忿。
首先我需要確定一下這個產(chǎn)品是否指的“數(shù)據(jù)產(chǎn)品”剪决。
如果是數(shù)據(jù)產(chǎn)品，那其實(shí)傳統(tǒng)行業(yè)數(shù)據(jù)平臺本身就有一些數(shù)據(jù)產(chǎn)品了檀训，而且也都是存在的柑潦。數(shù)據(jù)產(chǎn)品自從數(shù)據(jù)倉庫出現(xiàn)以來它其實(shí)一直都存在的，只不過是近幾年因?yàn)榛ヂ?lián)網(wǎng)特別愛制造“流行詞“把數(shù)據(jù)產(chǎn)品這個詞給放大了峻凫∩恚互聯(lián)網(wǎng)是得數(shù)據(jù)產(chǎn)品從早期的重量級逐漸進(jìn)化為輕量級、從大而全的解決方案逐漸演進(jìn)為因小而美。
我來給出幾組例子托呕，大約從2004年到現(xiàn)在的幾組數(shù)據(jù)產(chǎn)品的例子
(點(diǎn)擊放大圖像)
[圖片上傳中磕蛇。。银择。（25）]
(點(diǎn)擊放大圖像)
[圖片上傳中。累舷。浩考。（26）]
(點(diǎn)擊放大圖像)
[圖片上傳中。被盈。析孽。（27）]
(點(diǎn)擊放大圖像)
[圖片上傳中。只怎。袜瞬。（28）]
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
[圖片上傳中。身堡。邓尤。（30）]
(點(diǎn)擊放大圖像)
[圖片上傳中。贴谎。汞扎。（31）]
你可以分類一下，這些數(shù)據(jù)產(chǎn)品的特點(diǎn)是什么擅这？滿足了用戶怎么樣的痛點(diǎn)需求澈魄？滿足了用戶怎么樣的使用流程。
12 ****仲翎。傳統(tǒng)行業(yè)的數(shù)據(jù)倉庫從業(yè)人員痹扇，如果轉(zhuǎn)到互聯(lián)網(wǎng)行業(yè)铛漓，應(yīng)該學(xué)習(xí)哪些技能？
松子老師：這個問題你可以百度搜索“大數(shù)據(jù)職位所需要的數(shù)據(jù)技能” http://blog.jobbole.com/99039/ 這篇文章鲫构。自己覺得人家回答的比我專業(yè)浓恶。//
我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史（四）：互聯(lián)網(wǎng)時代 ? 下篇
http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-internet-age
編者按：本文是松子（李博源）的大數(shù)據(jù)平臺發(fā)展史系列文章的第四篇（共四篇），本系列以獨(dú)特的視角结笨，比較了非互聯(lián)網(wǎng)和互聯(lián)網(wǎng)兩個時代以及傳統(tǒng)行業(yè)與非傳統(tǒng)行業(yè)包晰。是對數(shù)據(jù)平臺發(fā)展的一個回憶，對非互聯(lián)網(wǎng)禀梳、互聯(lián)網(wǎng)杜窄，從數(shù)據(jù)平臺的用戶角度、數(shù)據(jù)架構(gòu)演進(jìn)算途、模型等進(jìn)行了闡述塞耕。
在互聯(lián)網(wǎng)時代被弱化的數(shù)據(jù)模型
談起數(shù)據(jù)模型就不得不提傳統(tǒng)數(shù)據(jù)平臺架構(gòu)發(fā)展，我相信很多朋友都曉得傳統(tǒng)數(shù)據(jù)平臺的知識嘴瓤，其架構(gòu)演進(jìn)簡單一句話說“基本上可以分為五個時代扫外、四種架構(gòu)”锨能，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與數(shù)據(jù)源類型多樣化特點(diǎn)伤为，從高階架構(gòu)上來看大約從傳統(tǒng)數(shù)據(jù)平臺第三代架構(gòu)開始延續(xù)的腌且，但是往后的發(fā)展從我自己的這一點(diǎn)知識上很難對互聯(lián)網(wǎng)的數(shù)據(jù)平臺做架構(gòu)歸類惋嚎。
但是從數(shù)據(jù)平臺建設(shè)與服務(wù)角色上還是有章可循的。就像上篇分享到那樣顶岸，類比兩個行業(yè)色难，互聯(lián)網(wǎng)企業(yè)中員工年齡比非互聯(lián)網(wǎng)企業(yè)的要年輕沿癞、受教育程度席赂、對計(jì)算機(jī)的焦慮程度明顯比傳統(tǒng)企業(yè)要低吮铭、還偶遇其它各方面的緣故，導(dǎo)致了數(shù)據(jù)平臺所面對用戶群體與非互聯(lián)網(wǎng)數(shù)據(jù)平臺有所差異化颅停。
傳統(tǒng)行業(yè)與互聯(lián)網(wǎng)行業(yè)數(shù)據(jù)平臺用戶特性我只選擇前文章的兩張圖來表示
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
在傳統(tǒng)數(shù)據(jù)平臺要背后有一個完整數(shù)據(jù)倉庫團(tuán)隊(duì)去服務(wù)業(yè)務(wù)方谓晌，業(yè)務(wù)方嗷嗷待哺的等待被動方式去滿足。中低層數(shù)據(jù)基本不會對業(yè)務(wù)方開放癞揉，所以不管數(shù)據(jù)模型采用何種建模方式纸肉，主要滿足當(dāng)時數(shù)據(jù)架構(gòu)規(guī)劃即可。
互聯(lián)網(wǎng)業(yè)務(wù)的快速發(fā)展使得大家已經(jīng)從經(jīng)營喊熟、分析的訴求重點(diǎn)轉(zhuǎn)為數(shù)據(jù)化的精細(xì)運(yùn)營上柏肪，如何做好精細(xì)化運(yùn)營問題上來，當(dāng)資源不夠時用戶就叫喊逊移，甚至有的業(yè)務(wù)方會挽起袖子來自己參與到從數(shù)據(jù)整理预吆、加工、分析階段胳泉。
此時呢拐叉，原有建設(shè)數(shù)據(jù)平臺的多個角色（數(shù)據(jù)開發(fā)、模型設(shè)計(jì)）可能轉(zhuǎn)為對其它非專業(yè)使用數(shù)據(jù)方扇商，做培訓(xùn)凤瘦、咨詢與落地，寫更加適合當(dāng)前企業(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àn)椴粚I(yè)性控汉，導(dǎo)致數(shù)據(jù)質(zhì)量問題笔诵、重復(fù)對分?jǐn)?shù)據(jù)浪費(fèi)存儲與資源、口徑多樣化姑子、編碼不統(tǒng)一乎婿、命名問題等等原因。數(shù)據(jù)質(zhì)量逐漸變成一個特別突出的問題街佑。
傳統(tǒng)企業(yè)的數(shù)據(jù)源基本來自excel谢翎、表格梗顺、DB系統(tǒng)等遍愿，但在互聯(lián)網(wǎng)有網(wǎng)站點(diǎn)擊流日志、視頻簿煌、音頻磁携、圖片數(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ù)有些力不從心鳞上。
當(dāng)數(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è)也有自己特點(diǎn)舟误，傳統(tǒng)行業(yè)所涉及數(shù)據(jù)模型這個領(lǐng)域涉及的很多內(nèi)容在互聯(lián)網(wǎng)變成以其他的曲線救國的方式存在了。
在互聯(lián)網(wǎng)曲線救國新解決
回顧在傳統(tǒng)行業(yè)數(shù)據(jù)平臺中姻乓，不管兩位大師爭論點(diǎn)數(shù)據(jù)模型的設(shè)計(jì)采用那種范式（Bill Inmon的EDW的原則是準(zhǔn)三范式的設(shè)計(jì)嵌溢、Ralph kilmbal是星型結(jié)構(gòu)）但是都要非常重視數(shù)據(jù)源的質(zhì)量問題眯牧。所以傳統(tǒng)行業(yè)的數(shù)據(jù)模型會全盤考慮數(shù)據(jù)質(zhì)量問題，并通過數(shù)據(jù)抽樣分析給出合適的清洗口徑赖草。
(點(diǎn)擊放大圖像)
上圖來自我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ù)”對一年的還是不準(zhǔn)的）。在應(yīng)對數(shù)據(jù)的質(zhì)量問題乎折，目前互聯(lián)網(wǎng)有些做法是把數(shù)據(jù)標(biāo)準(zhǔn)化前置到業(yè)務(wù)數(shù)據(jù)產(chǎn)生就做绒疗，從根源上去杜絕數(shù)據(jù)質(zhì)量，但是這種場景比較實(shí)用在Log 日志的數(shù)據(jù)源中骂澄，比如移動互聯(lián)網(wǎng)最近流行的基于事件模型“Event”模型吓蘑，在日志產(chǎn)生時就規(guī)定好存儲格式（備注：大家度娘搜索，“學(xué)習(xí)筆記：The Log（我所讀過的最好的一篇分布式技術(shù)文章）” 對這個講解很詳細(xì)）酗洒。
在傳統(tǒng)行業(yè)士修，目前還是以混合模型設(shè)計(jì)方式為主。在互聯(lián)網(wǎng)的我所接觸的一些業(yè)務(wù)樱衷，在參照傳統(tǒng)數(shù)據(jù)模型方法論基礎(chǔ)上逐步演進(jìn)適合互聯(lián)網(wǎng)數(shù)據(jù)的數(shù)據(jù)模型方法鲤氢。
比如互聯(lián)網(wǎng)金融等一些業(yè)務(wù)會參考傳統(tǒng)金融行業(yè)對主題域的劃分瘫筐、OMG數(shù)據(jù)倉庫元數(shù)據(jù)管理CWM模型阳啥、FSDM金融模型床牧，再進(jìn)一步考慮大數(shù)據(jù)處理特性去進(jìn)行設(shè)計(jì)，所有從Hight Level 數(shù)據(jù)架構(gòu)圖看到主題層次劃分與傳統(tǒng)第三代數(shù)據(jù)倉庫還是很多相似之處侄榴，當(dāng)然模型架構(gòu)也有分三層雹锣、四層、五層的癞蚕。
不同的地方模型細(xì)節(jié)處理上已經(jīng)完全不一樣蕊爵，比如數(shù)據(jù)的多樣性、拉寬事實(shí)表桦山、度量值單獨(dú)存儲攒射、滿足數(shù)據(jù)快速重生、維度的二次降維處理等恒水、增加大量冗余列会放、增加大量派生列，結(jié)合自動化元數(shù)據(jù)來耦合钉凌、合并等相關(guān)管理咧最。
(點(diǎn)擊放大圖像)
[圖片上傳中。。矢沿。（4）]
上圖是支付寶非常早期數(shù)據(jù)模型
(點(diǎn)擊放大圖像)
上圖是支付寶非常早期數(shù)據(jù)模型
我們常提到的多維模型在大數(shù)據(jù)處理下進(jìn)行了退化維度處理滥搭。大家知道Olap多維模型，隨著維度的增加事實(shí)表的數(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è)計(jì)多維挖掘分析數(shù)據(jù)產(chǎn)品背后的技術(shù)就是搜索引擎實(shí)現(xiàn)的）摄狱，現(xiàn)在應(yīng)該也有新技術(shù)出現(xiàn)了來解決類似的問題。
(點(diǎn)擊放大圖像)
上圖為2012年產(chǎn)品UI之一无午。
(點(diǎn)擊放大圖像)
[圖片上傳中媒役。。宪迟。（7）]
上圖是2011-2012年該產(chǎn)品系列背后當(dāng)時使用的技術(shù)
互聯(lián)網(wǎng)業(yè)務(wù)特點(diǎn)業(yè)務(wù)垂直拆分非常細(xì)酣衷，比如一個用戶注冊、密碼找回的流程有可能存在好幾個產(chǎn)品負(fù)責(zé)同一個業(yè)務(wù)流程不同環(huán)節(jié)次泽，相關(guān)的一個策略穿仪、產(chǎn)品feature快速迭代上線等等都要數(shù)據(jù)評估。數(shù)據(jù)從前端埋點(diǎn)到采集然后再由各個環(huán)節(jié)到數(shù)據(jù)平臺意荤，再有數(shù)據(jù)分析師或各業(yè)務(wù)部門去使用啊片，基本拉長了時間周期。需求部門與實(shí)施部門能力和經(jīng)驗(yàn)有千差萬別的需求，造成了懂技術(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ù)特點(diǎn)是變化非常迅速的瞒窒，能穩(wěn)定的業(yè)務(wù)達(dá)到65%算對數(shù)據(jù)平臺是個福音了（根據(jù)對某寶寶的印象）剩余的業(yè)務(wù)變化迅速，必然導(dǎo)致數(shù)據(jù)模型快速上下線乡洼。
Kimball老人家提出的維度建模（備注崇裁，在本系列發(fā)展史得第一篇有介紹）圍繞業(yè)務(wù)模型能夠非常直觀的表達(dá)出業(yè)務(wù)的數(shù)據(jù)關(guān)系，但是在互聯(lián)網(wǎng)NOSQL犧牲掉了關(guān)系型數(shù)據(jù)庫的一致性就珠、完整性等等很多東西寇壳。維度數(shù)據(jù)模型又基于這些大數(shù)據(jù)技術(shù)的，所以進(jìn)化的更加輕量級與基于細(xì)節(jié)數(shù)據(jù)的維度退化建模（原有的緩慢變化維妻怎、快速變化維壳炎、大維、迷你維、父子維匿辩、雪花維為了適應(yīng)互聯(lián)網(wǎng)的大數(shù)據(jù)Nosql處理技術(shù)進(jìn)行反規(guī)范化腰耙、化&數(shù)據(jù)冗余設(shè)計(jì)。
退化維度的反規(guī)范化設(shè)計(jì)一方面可以把一條查詢語句所需要的所有數(shù)據(jù)組合起來放到一個地方存儲 Key values 的方式（比如說商品有不同類型铲球，每一種類型商品又有自己的不同屬性挺庞，可以采用一對多、多對多的方式存儲稼病，例如把一個多維映射為一個Key value）选侨。
講到互聯(lián)網(wǎng)數(shù)據(jù)平臺就要提數(shù)據(jù)模型，提了數(shù)據(jù)模型就要提Nosql技術(shù)然走，
(點(diǎn)擊放大圖像)
上圖來自Nosql文檔系列的一幅圖
Nosql 是大數(shù)據(jù)處理的特征之一援制。互聯(lián)網(wǎng)數(shù)據(jù)平臺數(shù)據(jù)模型與NoSql技術(shù)還是蠻緊密的芍瑞。這里有外文講解Nosql Data modeling technigues 從技術(shù)角度講解非常詳（https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/）晨仑。
因?yàn)榍斑吿岬降拇髷?shù)據(jù)平臺技術(shù)特性決定了傳統(tǒng)edw模型、維度模型直接在互聯(lián)網(wǎng)數(shù)據(jù)大數(shù)據(jù)平臺部署或許還有“好些未知”障礙等待大家去克服拆檬。同時在傳統(tǒng)數(shù)據(jù)建模用到的一些方法經(jīng)過互聯(lián)網(wǎng)熏陶或許演進(jìn)成一種新的數(shù)據(jù)產(chǎn)品或方案吧洪己。
到此為止“我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史”上下共四篇與大家分享完畢，這個寫作前后經(jīng)歷剛好一個月左右竟贯，算是對自己數(shù)據(jù)從業(yè)經(jīng)歷回顧之一吧答捕。在知識的整理中很多都是蜻蜓點(diǎn)水，每個知識域都是一個非常深的專業(yè)方向澄耍，自己涉足很膚淺噪珊，在文章中分享不足之處請各位讀者見諒！！
個人郵箱是5592094@qq.com 歡迎電郵交流。
接下來我會進(jìn)入數(shù)據(jù)產(chǎn)品這個領(lǐng)域的分享鳍怨，當(dāng)年車品覺老師自豪的作品之一“黃金策”，我是數(shù)據(jù)產(chǎn)品經(jīng)理阵难。（ps：自己躲在墻角拿車品覺老師往自己臉上貼金了）。
后記
有一次數(shù)據(jù)產(chǎn)品神策的創(chuàng)始人兼好友@桑文鋒＠SensorsData跟我說來做次分享吧芒填，我當(dāng)時出了幾個題目呜叫，最后就選擇了“我所經(jīng)歷的大數(shù)據(jù)平臺“，就形成了大家看到的”我所經(jīng)歷的大數(shù)據(jù)平臺“系列文章.
在整理期間得到了死黨@周愛民殿衰、@神策-桑文峰朱庆、 InfoQ小編@Tina Du 、@betty zhou @Laurel大力協(xié)助闷祥，在這里感謝Ｓ榧铡！！
番外篇
這一篇是在24日舉行的分享大家提到的一些問題箱硕，經(jīng)過整理算是對正文的補(bǔ)充吧拴竹，從互聯(lián)網(wǎng)敏捷數(shù)據(jù)模型等角度做了較深入的細(xì)節(jié)介紹。同時在數(shù)據(jù)產(chǎn)品方面的回答包含了一點(diǎn)未來寫作篇“數(shù)據(jù)產(chǎn)品”系列的一點(diǎn)內(nèi)容剧罩。
1****栓拜，傳統(tǒng)我們做BI的，做數(shù)據(jù)展現(xiàn)會建模后以pivot展現(xiàn)cube數(shù)據(jù)惠昔，不知道現(xiàn)在互聯(lián)網(wǎng)公司數(shù)據(jù)展示如何做的幕与？第三方工具還是用API取數(shù)據(jù)平臺里的數(shù)據(jù)？adhoc報(bào)表及靈活更換維度的時候web端一般是怎么做的舰罚？
松子老師：剛才文章中提到了比如傳統(tǒng)行業(yè)的多維數(shù)據(jù)模型cube纽门。在互聯(lián)網(wǎng)采用的曲線救國方式解決的。 在分享中我給出了幾個圖营罢。就是通過搜索引擎曲線救國方式實(shí)現(xiàn)類似Olap的模擬。
在這塊的模型的處理上采用的是維度退化處理饼齿。通過反規(guī)范化饲漾，數(shù)據(jù)項(xiàng)、數(shù)據(jù)冗余去處理缕溉。在前端做特殊處理考传。
這個當(dāng)時產(chǎn)品原型之一：
(點(diǎn)擊放大圖像)
這是一個2011年-2012年左右的數(shù)據(jù)產(chǎn)品，當(dāng)時算是即時計(jì)算的一種证鸥。不過已經(jīng)過去好幾年了僚楞，當(dāng)今新技術(shù)下Olap 引擎應(yīng)該有很好的提升。
目前我知道的家互聯(lián)網(wǎng)公司枉层，在前端展現(xiàn)有使用第三方套件比如spagoBi泉褐、pentaho 等 有自己設(shè)計(jì)開發(fā)定制化數(shù)據(jù)前端展現(xiàn)。比如我剛開始分享的那兩個之前在去哪兒網(wǎng)設(shè)計(jì)的數(shù)據(jù)平臺內(nèi)部界面之一鸟蜡，當(dāng)然數(shù)據(jù)產(chǎn)品是另一個話題了膜赃，通過對數(shù)據(jù)分析抽象指標(biāo)拖云、分析模型领猾、用戶使用功能與流程、未來規(guī)劃考慮用戶體驗(yàn)去設(shè)計(jì)每聪。
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
[圖片上傳中泣矛。疲眷。。（11）]
(點(diǎn)擊放大圖像)
2****您朽，互聯(lián)網(wǎng)財(cái)經(jīng)類公司狂丝，業(yè)務(wù)包括財(cái)經(jīng)網(wǎng)站、基金、股票美侦、金融等产舞，這類公司的數(shù)據(jù)倉庫模型應(yīng)該如何設(shè)計(jì)？特點(diǎn)和注意事項(xiàng)是什么菠剩？案例介紹易猫？十分感謝。
松子老師：我自己經(jīng)歷過的是互聯(lián)網(wǎng)金融以及移動互聯(lián)網(wǎng)行具壮。對這兩塊比較清楚准颓。互聯(lián)網(wǎng)金融起因?yàn)闃I(yè)務(wù)的特性是類金融類的棺妓，與銀行有些地方是相似的攘已。
比如大約在2012年前支付寶業(yè)務(wù)特點(diǎn)涉及類金融交易：充值、提現(xiàn)怜跑、賬務(wù)管理類電子商務(wù)：購物交易過程變更样勃、實(shí)際交易（對B機(jī)票、對C水電等） 非純電子商務(wù)峡眶；純金融；個人信用植锉，理財(cái)類辫樱。系統(tǒng)之間依賴度較為復(fù)雜，垂直依賴（業(yè)務(wù)與核心）跨層依賴（跨過交易到賬務(wù)）俊庇。
在設(shè)計(jì)方法上還是采用維度模型設(shè)計(jì)方式狮暑。底層是數(shù)據(jù)驅(qū)動為向?qū)ВY(jié)合業(yè)務(wù)需求驅(qū)動辉饱，通過簡單搬男、退化維度的方式拉寬表結(jié)構(gòu)。
底層采用松耦合設(shè)計(jì)鞋囊。主題之間是松耦合方式止后。至體內(nèi)采用細(xì)粒度退化維度。
在主題域上的的設(shè)計(jì)基本參考了OMG的數(shù)據(jù)倉庫元數(shù)據(jù)設(shè)計(jì)CWM模型溜腐、IBM 的fsdm金融模型括勺、還有新巴塞爾資本協(xié)議（Basel II Capital Accord）需提供數(shù)據(jù)規(guī)范去的設(shè)計(jì)涎才。所以數(shù)據(jù)模型是五層的結(jié)構(gòu)。
在細(xì)節(jié)處理上，增量ODS層數(shù)據(jù)和前一天DWD相關(guān)表進(jìn)行 merge處理碘橘。
在一些層次上辱魁，基本聚合谤碳、匯總增加派生事實(shí)表（簡單一句話退化為度打?qū)挘Ｈ缓蟀凑諛I(yè)務(wù)主體合并信息等伞辛。
比如開始給大家分享的那張圖：
(點(diǎn)擊放大圖像)
[圖片上傳中。夯缺。蚤氏。（13）]
在維度模型退化處理時，要注意最細(xì)粒度數(shù)據(jù)保留踊兜、不同層次的數(shù)據(jù)支持?jǐn)?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ù)模型垫言。
這種元數(shù)據(jù)驅(qū)動工具型數(shù)據(jù)產(chǎn)品我會在未來數(shù)據(jù)產(chǎn)品系列中做詳細(xì)介紹的贰剥。
3****，互聯(lián)網(wǎng)企業(yè)大數(shù)據(jù)平臺的發(fā)展歷程是怎樣的筷频？
松子老師：這個我相信應(yīng)該是傳統(tǒng)數(shù)據(jù)平臺朋友提到的蚌成。傳統(tǒng)行業(yè)數(shù)據(jù)平臺架構(gòu)演進(jìn)我總結(jié)簡單一句話說“基本上可以分為五個時代、四種架構(gòu)”截驮，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與類型暴增的特點(diǎn)笑陈，從高階架構(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é)下來用戶特點(diǎn)：
(點(diǎn)擊放大圖像)
[圖片上傳中。窒所。鹉勒。（14）]
更加詳細(xì)的每一代數(shù)據(jù)平臺建設(shè)、服務(wù)角色特點(diǎn)您可以看我這個系列文章的第三篇吵取，http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-paet02
4****禽额，有沒有好的元數(shù)據(jù)管理工具推薦？主要偏向數(shù)據(jù)字典與血統(tǒng)等皮官。
松子老師：元數(shù)據(jù)以前目前沒有太多的好管理工具脯倒。以前是在支付寶是我自己設(shè)計(jì)的一個數(shù)據(jù)產(chǎn)品。第一版自己用Delphi 開發(fā)的捺氢。
（圖很多：）
(點(diǎn)擊放大圖像)
[圖片上傳中。。法希。（15）]
(點(diǎn)擊放大圖像)
[圖片上傳中嗤军。残黑。。（16）]
(點(diǎn)擊放大圖像)
[圖片上傳中斋否。梨水。。（17）]
(點(diǎn)擊放大圖像)
[圖片上傳中茵臭。疫诽。。（18）]
(點(diǎn)擊放大圖像)
[圖片上傳中笼恰。踊沸。。（19）]
以前被逼的自己寫了一個社证，通過解析逼龟，實(shí)現(xiàn)了字段級的血緣影響分析。這只是第二步追葡，后來又把running 信息給搞了進(jìn)來腺律。還有分享時提到的模型信息、整個閉環(huán)的分類信息宜肉。
這是一個分支：
(點(diǎn)擊放大圖像)
[圖片上傳中匀钧。。谬返。（20）]
但是我們實(shí)現(xiàn)了字段級解析準(zhǔn)確率達(dá)到了94%左右之斯。有細(xì)微的錯誤就人工revew一遍。
5. ****松子老師遣铝，數(shù)據(jù)管控的數(shù)據(jù)質(zhì)量部分是怎么處理的呢佑刷？
松子老師： 數(shù)據(jù)管控， 這方面我不太懂的酿炸，但是數(shù)據(jù)質(zhì)量瘫絮，這玩意可大可小的。比如像在分享時說過的填硕，在移動互聯(lián)網(wǎng)的數(shù)據(jù)質(zhì)量處理方式可以由原有的ETL(ELT)階段前置到業(yè)務(wù)系統(tǒng)去解決麦萤，比如移動互聯(lián)網(wǎng)的App log 日志，日志標(biāo)準(zhǔn)化后事件模型”存儲來解決扁眯。那非app 日志類如何解決呢比如Payment壮莹、order等，數(shù)據(jù)質(zhì)量比較考慮的可以只做到監(jiān)控恋拍。
我來分享個圖垛孔。剛好是我設(shè)計(jì)數(shù)據(jù)質(zhì)量產(chǎn)品時搞的，理清數(shù)據(jù)質(zhì)量的問題：
(點(diǎn)擊放大圖像)
[圖片上傳中。崔梗。击狮。（21）]
(點(diǎn)擊放大圖像)
[圖片上傳中往产。廓八。亡哄。（22）]
(點(diǎn)擊放大圖像)
[圖片上傳中。。晨横。（23）]
只要數(shù)據(jù)進(jìn)入倉庫與應(yīng)用體系，處理起來就比較困難了箫柳，所以在數(shù)據(jù)平臺階段最好是通過監(jiān)控手形、前置去解決。目前數(shù)據(jù)質(zhì)量確實(shí)難以100%由事后搞到事前去處理悯恍。我對數(shù)據(jù)平臺與數(shù)據(jù)產(chǎn)品的建設(shè)就是實(shí)用為主库糠。怎么實(shí)用怎么來。我是比較現(xiàn)實(shí)的實(shí)用主義者涮毫。
6. ****能否分享一些數(shù)據(jù)產(chǎn)品種類及實(shí)例：
松子老師：在前邊五個問題瞬欧、以及文章中又都涉及數(shù)據(jù)產(chǎn)品實(shí)力的一些分享。
提到數(shù)據(jù)產(chǎn)品的分類我就想把這個圖發(fā)出來罢防。
自己認(rèn)為沒有特別明確的劃分線艘虎，但是數(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工具唯鸭、資源管控等等。
面向用戶功能有報(bào)表型硅确、多維型數(shù)據(jù)產(chǎn)品肿孵、定制化數(shù)據(jù)產(chǎn)品、挖掘型數(shù)據(jù)產(chǎn)品疏魏。
面向內(nèi)部用戶、外部個人用戶晤愧、外部企業(yè)用戶又有不同的分類大莫。
根據(jù)業(yè)務(wù)又可以劃分很多，面向C類用戶官份、面向B類商戶只厘、金融風(fēng)險(xiǎn)等等
從近幾年的數(shù)據(jù)產(chǎn)品來看烙丛，是更好的輔助用戶的做決策的一種產(chǎn)品形態(tài)锰什，在用戶的決策與行動中充當(dāng)信息的分析者與價值使用者紊搪；數(shù)據(jù)產(chǎn)品有個自己的共性：由解決的一個實(shí)際的業(yè)務(wù)問題出發(fā)，分解出的分析指標(biāo)舌界，分析模型赋元，分析流程組成忘蟹，再考慮到功能易用性，未來功能擴(kuò)展搁凸，考慮用戶對數(shù)據(jù)易用性（比如數(shù)據(jù)的呈現(xiàn)層次媚值，不可能一次把所有數(shù)據(jù)的呈現(xiàn)給用戶）來組成的。
(點(diǎn)擊放大圖像)
7. ****銀行業(yè)從傳統(tǒng)的ods到edw再到大數(shù)據(jù)平臺這塊過渡护糖，模型如何建設(shè)褥芒？平臺優(yōu)勢如何發(fā)揮？
松子老師：這個問題還是有些難度的赞哗，自己回答的可能有些片面茵休。首先我們清醒的清楚“大數(shù)據(jù)”是什么？再次不同的場景可以采用不同的技術(shù)去解決手蝎。
“大數(shù)據(jù)”榕莺，拆開來看大、數(shù)據(jù)棵介，大可以是指的數(shù)據(jù)源結(jié)構(gòu)簡單（ps 如果了解過當(dāng)代對大數(shù)據(jù)的定義就知道四個特性）但是量級夠大钉鸯，比如清算、結(jié)算邮辽、對公唠雕、對私、中間業(yè)務(wù)等等每一個拿出來都是幾十T吨述，但是這些業(yè)務(wù)數(shù)據(jù)都是保存?zhèn)鹘y(tǒng)的關(guān)系型數(shù)據(jù)庫中如DB2岩睁、Oracle、MSsql中锐极，因?yàn)樵跀?shù)據(jù)平臺存儲是通過準(zhǔn)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ù)的去演進(jìn)解決翎迁。（最早時我的是中信銀行栋猖、光大銀行在2011年左右開始考慮Hadoop技術(shù)，后來不知道如何了）汪榔。
但是互聯(lián)網(wǎng)的數(shù)據(jù)平臺技術(shù)大都是NOSQL模式蒲拉，犧牲掉了傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)一致性、完整性、唯一索引等等雌团，只干性能的事情（當(dāng)然除了性能仑嗅、可擴(kuò)展性也是的）.
原有在傳統(tǒng)數(shù)據(jù)平臺模型設(shè)計(jì)上可以考慮的一些通過主外鍵、唯一索引做一些業(yè)務(wù)約束的方法蹋艺，在nosql上統(tǒng)統(tǒng)的都沒有了湖笨，這些約束必須放到數(shù)據(jù)加工階段去想辦法做檢查。傳統(tǒng)數(shù)據(jù)平臺如果在Insert灵寺、update數(shù)據(jù)時違反了業(yè)務(wù)約束可以做報(bào)警或異常處理曼库，但是在Nosql的平臺上要求ETL 去手動遵守這些規(guī)則檢查。但是有時ETL開發(fā)根本不遵守的略板，僅僅是兩個表關(guān)聯(lián)起來毁枯，也可能忘記按照某一個業(yè)務(wù)唯一索引做去重操作。簡單說叮称，原有靠關(guān)系型數(shù)據(jù)庫本身機(jī)制去做檢查一些規(guī)則變?yōu)槿斯ぶ致辏優(yōu)槿斯ぞ蜁稿e。
從關(guān)系型數(shù)據(jù)平臺往Nosql數(shù)據(jù)平臺遷移時颅拦，尤其是對傳統(tǒng)行業(yè)的業(yè)務(wù)來說蒂誉，在模型設(shè)計(jì)階段、以及給出的ETL口徑要考慮更多的業(yè)務(wù)規(guī)則檢查距帅，其次要考慮更多的維度退化右锨、多冗余、表打?qū)捥幚砺到铡：唵握f就是發(fā)揮數(shù)據(jù)平臺的計(jì)算能力同時要更加的各方面確保數(shù)據(jù)準(zhǔn)確安全可靠绍移。
數(shù)據(jù)模型ODS 到EDW 這塊的設(shè)計(jì)方法百度上留下的文檔資料太多的了，請這位提問的老師百度吧讥电。
**8****．大數(shù)據(jù)****倉庫****中如何做快速****維處****理蹂窖？互****聯(lián)****網(wǎng)數(shù)****倉****數(shù)據(jù)****質(zhì)****量不好如何****對****數(shù)，如何確立****標(biāo)****準(zhǔn)的****對****數(shù)口徑恩敌？******
松子老師：快速變化維度可以轉(zhuǎn)化為緩慢變化為來出來瞬测，我自己理解的快速維度是相對于緩慢維度參照的來說的。
舉個例子纠炮，年齡-轉(zhuǎn)化為天數(shù)可以是定義快速變化維度月趟，因?yàn)槊刻於荚谧兓Ｎ覀兛梢园涯挲g退化為區(qū)間維度來處理恢口，還可以把年齡做成動態(tài)維度來處理孝宗，事實(shí)表中保存的就是實(shí)際的出生年月并打?qū)挶恚挲g(天)通過計(jì)算方式來處理耕肩。還有種方法通過對代理鍵的方式來處理因妇。
我目前也不知道對數(shù)據(jù)的標(biāo)準(zhǔn)是什么问潭。但是我自己用的方法，把一個指標(biāo)的整個數(shù)據(jù)流向切出幾個關(guān)鍵點(diǎn)通過SQL去實(shí)現(xiàn)對數(shù)婚被，看波動振幅狡忙，波動曲線。同時還會比如發(fā)不通的版本的小流量測試的方式來做數(shù)據(jù)校對址芯。
9****． 做為數(shù)據(jù)行業(yè)從業(yè)者绩蜻，需要掌握哪些重要的基礎(chǔ)知識年鸳？另：如果從零開始建立一個數(shù)據(jù)平臺拱撵，需要哪些資源配置（人株灸，財(cái)堤结，物芦劣，技術(shù)）鸽捻？大致總投資額度多少旧烧？如果同行產(chǎn)品間多種來源的數(shù)據(jù)特咆，可有成熟的解決方案季惩？謝謝…
松子老師：這個問題太宏觀了。作為數(shù)據(jù)行業(yè)從業(yè)者腻格，需要掌握哪些重要基礎(chǔ)知識画拾，這個是要看從事具體數(shù)據(jù)域的垂直行業(yè)。
比如說 數(shù)據(jù)開發(fā)菜职、數(shù)據(jù)模型青抛、數(shù)據(jù)產(chǎn)品、數(shù)據(jù)分析師酬核、數(shù)據(jù)運(yùn)營蜜另、數(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ù)目標(biāo)不太明確下旧巾，難以確定方案耸序，人員配置上選用不同技術(shù)方案去搭建的配置是不太一樣的，比如說傳統(tǒng)平臺來講菠齿，運(yùn)維佑吝、DBA、數(shù)據(jù)開發(fā)绳匀、數(shù)據(jù)模型芋忿、報(bào)表人員炸客。
從互聯(lián)網(wǎng)數(shù)據(jù)平臺基本配置上，數(shù)據(jù)架構(gòu)師戈钢、運(yùn)維痹仙、底層大數(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ù)滨达。
10. Standalone****模式下，Model.save(Path)怎么一直提示錯誤俯艰，是不是配置Spark時需要將Hdfs的配置引進(jìn)來啊～捡遍？表示初學(xué)Spark
松子老師：這個問題有點(diǎn)超出我的能力范圍了，所以對不起回答不了竹握。
我本身不是做技術(shù)的画株。僅知道一點(diǎn)技術(shù)名詞。
11. ****傳統(tǒng)銀行業(yè)數(shù)據(jù)模型什么時候會走向互聯(lián)網(wǎng)模式呢涩搓？目前在傳統(tǒng)銀行數(shù)據(jù)平臺的產(chǎn)品是不是特別多污秆？
松子老師：這個問題我自己就不知道了，或許是傳統(tǒng)銀行在數(shù)據(jù)平臺的實(shí)施上全面用互聯(lián)網(wǎng)的Nosql大數(shù)據(jù)處理技術(shù)吧昧甘。至于說傳統(tǒng)銀行數(shù)據(jù)模型用現(xiàn)有的互聯(lián)網(wǎng)數(shù)據(jù)模型理念去設(shè)計(jì)是否完全可行良拼，數(shù)據(jù)一致性、高準(zhǔn)確性通過更多的方案去保證充边。
首先我需要確定一下這個產(chǎn)品是否指的“數(shù)據(jù)產(chǎn)品”庸推。
如果是數(shù)據(jù)產(chǎn)品，那其實(shí)傳統(tǒng)行業(yè)數(shù)據(jù)平臺本身就有一些數(shù)據(jù)產(chǎn)品了浇冰，而且也都是存在的贬媒。數(shù)據(jù)產(chǎn)品自從數(shù)據(jù)倉庫出現(xiàn)以來它其實(shí)一直都存在的，只不過是近幾年因?yàn)榛ヂ?lián)網(wǎng)特別愛制造“流行詞“把數(shù)據(jù)產(chǎn)品這個詞給放大了肘习〖食耍互聯(lián)網(wǎng)是得數(shù)據(jù)產(chǎn)品從早期的重量級逐漸進(jìn)化為輕量級、從大而全的解決方案逐漸演進(jìn)為因小而美漂佩。
我來給出幾組例子脖含，大約從2004年到現(xiàn)在的幾組數(shù)據(jù)產(chǎn)品的例子
(點(diǎn)擊放大圖像)
[圖片上傳中罪塔。。养葵。（25）]
(點(diǎn)擊放大圖像)
[圖片上傳中征堪。。关拒。（26）]
(點(diǎn)擊放大圖像)
[圖片上傳中佃蚜。。着绊。（27）]
(點(diǎn)擊放大圖像)
[圖片上傳中微驶。铸豁。跳芳。（28）]
(點(diǎn)擊放大圖像)
[圖片上傳中捍掺。。靶擦。（29）]
(點(diǎn)擊放大圖像)
[圖片上傳中。雇毫。玄捕。（30）]
(點(diǎn)擊放大圖像)
[圖片上傳中。棚放。枚粘。（31）]
你可以分類一下，這些數(shù)據(jù)產(chǎn)品的特點(diǎn)是什么飘蚯？滿足了用戶怎么樣的痛點(diǎn)需求馍迄？滿足了用戶怎么樣的使用流程。
12 ****局骤。傳統(tǒng)行業(yè)的數(shù)據(jù)倉庫從業(yè)人員攀圈，如果轉(zhuǎn)到互聯(lián)網(wǎng)行業(yè)，應(yīng)該學(xué)習(xí)哪些技能峦甩？
松子老師：這個問題你可以百度搜索“大數(shù)據(jù)職位所需要的數(shù)據(jù)技能” http://blog.jobbole.com/99039/ 這篇文章赘来。自己覺得人家回答的比我專業(yè)。](http://cdn4.infoqstatic.com/statics_s2_20170208-0257_3/resource/articles/the-development-history-of-big-data-platfor2-part01/zh/resources/0218033.png)
(點(diǎn)擊放大圖像)
[圖片上傳中凯傲。犬辰。。（6）]
該建設(shè)方式的要點(diǎn)是首先建立各個數(shù)據(jù)源業(yè)務(wù)的實(shí)體關(guān)系冰单、然后再根據(jù)保存的主子實(shí)體關(guān)系幌缝、存儲性能做優(yōu)化。
Ralph kilmball 對DM（備注：數(shù)據(jù)集市诫欠，非挖掘模型）的定義是面向分析過程的(Analytical Process oriented)涵卵，因?yàn)檫@個模型對業(yè)務(wù)用戶非常容易理解浴栽，同時為了查詢也是做了專門的性能優(yōu)化。所以星型缘厢、雪花模型很直觀比較高性能為用戶提供查詢分析吃度。
(點(diǎn)擊放大圖像)
[圖片上傳中。贴硫。椿每。（7）]
該方式的建模首先確定用戶需求問題與業(yè)務(wù)需求數(shù)據(jù)粒度，構(gòu)建分析所需要的維度英遭、與度量值形成星型模型间护；（備注 涉及的復(fù)雜維度、退化維度等不在這個討論范圍）挖诸。
數(shù)據(jù)模型的業(yè)務(wù)建模階段茅糜、領(lǐng)域概念模型階段疟呐、邏輯模型階段、物理模型階段是超級學(xué)術(shù)與復(fù)雜的話題，而且在模型領(lǐng)域根據(jù)特點(diǎn)又分主數(shù)據(jù)(MDM)辩昆、CIF（企業(yè)級統(tǒng)一視圖） 、通用模型(IBM 的金融宅粥、保險(xiǎn)行業(yè)通用模型闽寡、 Teradata的 金融通用模型、 電信移動通用模型等)相味，鎖涉及到術(shù)語”擴(kuò)展“拾积、”扁平化“、”裁剪“等眼花繚亂的建模手法丰涉，數(shù)據(jù)模型不同層次ODS拓巧、DWDDWD、DW一死、ST的分層目的不同導(dǎo)致模型設(shè)計(jì)方法又不同肛度。相信業(yè)界有很多大牛能講的清楚的，以后有機(jī)會再交流投慈。
(點(diǎn)擊放大圖像)
[圖片上傳中贤斜。。逛裤。（8）]
(點(diǎn)擊放大圖像)
[圖片上傳中瘩绒。。带族。（9）]
(點(diǎn)擊放大圖像)
[圖片上傳中锁荔。。蝙砌。（10）]
(點(diǎn)擊放大圖像)
[圖片上傳中阳堕。跋理。。（11）]
本文帶大家回憶了歷史非互聯(lián)網(wǎng)的數(shù)據(jù)平臺發(fā)展與核心模型特點(diǎn)恬总，當(dāng)然數(shù)據(jù)平臺的發(fā)展不是一步到位的前普，是經(jīng)過無數(shù)人的智慧、努力反復(fù)迭代而逐漸演進(jìn)的壹堰。
非互聯(lián)網(wǎng)企業(yè)的數(shù)據(jù)平臺發(fā)展拭卿，每一代的平臺架構(gòu)中的結(jié)構(gòu)都是及其復(fù)雜的，比如ETL架構(gòu)贱纠、數(shù)據(jù)模型架構(gòu)峻厚、BD的架構(gòu)、前端展現(xiàn)谆焊、元數(shù)據(jù)惠桃、數(shù)據(jù)質(zhì)量等各方面座硕，每一部分展開都是一個很深的話題办绝，有機(jī)會再分享給大家。
下篇章將分享給大家互聯(lián)網(wǎng)時代的數(shù)據(jù)平臺撕瞧，互聯(lián)網(wǎng)的數(shù)據(jù)平臺也就是在07年-08年左右開始迅猛發(fā)展的罐孝，在發(fā)展的初期也是從傳統(tǒng)數(shù)據(jù)平臺的第三代架構(gòu)開始演進(jìn)的誓禁，互聯(lián)網(wǎng)產(chǎn)品發(fā)展特點(diǎn)是“糙、快肾档、猛”，同時數(shù)據(jù)量的超快速膨脹所帶來的技術(shù)變革辫继，從數(shù)據(jù)倉庫->海量數(shù)據(jù)->大數(shù)據(jù)膨脹必然原有的技術(shù)無法支撐高IO吞吐怒见、密集型計(jì)算，從而發(fā)展了合適互聯(lián)網(wǎng)大數(shù)據(jù)平臺姑宽。
關(guān)于作者
松子（李博源）遣耍，自由撰稿人，數(shù)據(jù)產(chǎn)品&數(shù)據(jù)分析總監(jiān)炮车。2000年開始數(shù)據(jù)領(lǐng)域舵变，從業(yè)傳統(tǒng)制造業(yè)、銀行瘦穆、保險(xiǎn)纪隙、第三方支付&互聯(lián)網(wǎng)金融、在線旅行扛或、移動互聯(lián)網(wǎng)行業(yè) 绵咱； 個人沉淀在大數(shù)據(jù)產(chǎn)品、大數(shù)據(jù)分析熙兔、數(shù)據(jù)模型領(lǐng)域悲伶；歡迎關(guān)注個人微信訂閱號：songzi2016艾恼。
階段三：
互聯(lián)網(wǎng)業(yè)務(wù)的快速發(fā)展、大家已經(jīng)從經(jīng)營麸锉、分析的訴求重點(diǎn)轉(zhuǎn)為數(shù)據(jù)化的精細(xì)運(yùn)營上钠绍，隨之而來的面臨創(chuàng)新壓力、如何做好精細(xì)化運(yùn)營花沉，數(shù)據(jù)平臺的用戶其聚焦在無法快速的響應(yīng)日常需求其表現(xiàn)為做數(shù)據(jù)的已經(jīng)無法滿足當(dāng)前業(yè)務(wù)日益增長的數(shù)據(jù)需求柳爽、運(yùn)營上精細(xì)化已經(jīng)對數(shù)據(jù)的粒度要求由高匯總逐漸轉(zhuǎn)為過程化細(xì)粒度明細(xì)數(shù)據(jù)。
隨著數(shù)據(jù)應(yīng)用的深入主穗，用數(shù)據(jù)往往不知道數(shù)據(jù)的口徑與來源泻拦，加工數(shù)據(jù)的不知道業(yè)務(wù)含義，不同部門口徑又是不一樣忽媒，有的從交易來争拐、有的從賬務(wù)來。這里數(shù)據(jù)使用與數(shù)據(jù)加工上就出現(xiàn)了”斷層”晦雨。有時在層級與功能部門前邊也可能存在一個斷層架曹，對數(shù)據(jù)價值的內(nèi)在衡量是不一樣的份殿，角色不一樣梧疲，對于數(shù)據(jù)價值的的看法也就不同殖氏。
由于以上的種種問題烘苹，用數(shù)據(jù)的一些角色（分析師嘶是、運(yùn)營或產(chǎn)品）會自己參與到從數(shù)據(jù)整理闻丑、加工关顷、分析階段邢享。當(dāng)數(shù)據(jù)平臺變?yōu)樽杂扇_放洽腺，使用數(shù)據(jù)的人也參與到數(shù)據(jù)的體系建設(shè)時脚粟，基本會因?yàn)椴粚I(yè)型，導(dǎo)致數(shù)據(jù)質(zhì)量問題蘸朋、重復(fù)對分?jǐn)?shù)據(jù)浪費(fèi)存儲與資源核无、口徑多樣化等等原因。此時原有建設(shè)數(shù)據(jù)平臺的多個角色可能轉(zhuǎn)為對其它非專業(yè)做數(shù)據(jù)人員的培訓(xùn)藕坯、咨詢與落地寫更加適合當(dāng)前企業(yè)數(shù)據(jù)應(yīng)用的一些方案等团南。例如原有的數(shù)據(jù)產(chǎn)品會加入更多的在原有的數(shù)據(jù)建設(shè)中才有的一些流程讓用戶來遵守（統(tǒng)一的數(shù)據(jù)搜集、數(shù)據(jù)標(biāo)準(zhǔn)化的前置）炼彪。舉例Log 埋點(diǎn)產(chǎn)品化吐根、自動Report 的過程規(guī)范化（舉例說明：原有一些運(yùn)營自己建立的一些報(bào)表可能sql有問題就直接放入報(bào)表生成器中了。更改流程第一步現(xiàn)在MQ中驗(yàn)證完畢口徑后辐马，通過元數(shù)據(jù)解析進(jìn)入到報(bào)表生成器中）佑惠、基于元數(shù)據(jù)驅(qū)動的ETL流程化等等，因?yàn)槠灾健⒎?wù)化的一些數(shù)據(jù)產(chǎn)品建立也將會導(dǎo)致數(shù)據(jù)平臺迭代的演進(jìn)膜楷。
給用戶提供的各類豐富的分析旭咽、取數(shù)的產(chǎn)品，簡單上手的可以使用赌厅。
原有ETL穷绵、數(shù)據(jù)模型角色轉(zhuǎn)為給用戶提供平臺、產(chǎn)品特愿、數(shù)據(jù)培訓(xùn)與使用咨詢仲墨。
數(shù)據(jù)分析師直接參與到數(shù)據(jù)平臺過程、數(shù)據(jù)產(chǎn)品的建設(shè)中去揍障。
用戶面對是數(shù)據(jù)源多樣化目养，比如日志、生產(chǎn)數(shù)據(jù)庫的數(shù)據(jù)毒嫡、視頻癌蚁、音頻等非結(jié)構(gòu)化數(shù)據(jù)。
在互聯(lián)網(wǎng)這個大數(shù)據(jù)浪潮下兜畸，2016年以后數(shù)據(jù)平臺是如何去建設(shè)努释？如何服務(wù)業(yè)務(wù)栋齿？
企業(yè)的不同發(fā)展階段數(shù)據(jù)平臺該如何去建設(shè)的蔑穴？這個大家是可以思考的。但是我相信互聯(lián)網(wǎng)企業(yè)是非常務(wù)實(shí)的拆吆，基本不會采用傳統(tǒng)企業(yè)的自上而下的建設(shè)方式肛鹏，互聯(lián)網(wǎng)企業(yè)的業(yè)務(wù)快速變與迭代要求快速分析到數(shù)據(jù)逸邦，必須新業(yè)務(wù)數(shù)據(jù)迭代，老業(yè)務(wù)數(shù)據(jù)快速去雜在扰。敏捷數(shù)據(jù)平臺或許是種不錯的選擇方法之一吧缕减！
下一篇將是本系列的最后一篇，互聯(lián)網(wǎng)數(shù)據(jù)平臺下的數(shù)據(jù)建模（備注：是數(shù)據(jù)倉庫模型）健田。
關(guān)于作者
松子（李博源） ，自由撰稿人佛纫，數(shù)據(jù)產(chǎn)品&數(shù)據(jù)分析總監(jiān)妓局。2000年開始數(shù)據(jù)領(lǐng)域，從業(yè)傳統(tǒng)制造業(yè)呈宇、銀行好爬、保險(xiǎn)、第三方支付&互聯(lián)網(wǎng)金融甥啄、在線旅行存炮、移動互聯(lián)網(wǎng)行業(yè) ； 個人沉淀在大數(shù)據(jù)產(chǎn)品、大數(shù)據(jù)分析穆桂、數(shù)據(jù)模型領(lǐng)域宫盔；歡迎關(guān)注個人微信訂閱號：songzi2016。//
我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史（四）：互聯(lián)網(wǎng)時代 ? 下篇
http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-internet-age
編者按：本文是松子（李博源）的大數(shù)據(jù)平臺發(fā)展史系列文章的第四篇（共四篇）享完，本系列以獨(dú)特的視角灼芭，比較了非互聯(lián)網(wǎng)和互聯(lián)網(wǎng)兩個時代以及傳統(tǒng)行業(yè)與非傳統(tǒng)行業(yè)。是對數(shù)據(jù)平臺發(fā)展的一個回憶般又，對非互聯(lián)網(wǎng)彼绷、互聯(lián)網(wǎng)，從數(shù)據(jù)平臺的用戶角度茴迁、數(shù)據(jù)架構(gòu)演進(jìn)寄悯、模型等進(jìn)行了闡述。
在互聯(lián)網(wǎng)時代被弱化的數(shù)據(jù)模型
談起數(shù)據(jù)模型就不得不提傳統(tǒng)數(shù)據(jù)平臺架構(gòu)發(fā)展堕义，我相信很多朋友都曉得傳統(tǒng)數(shù)據(jù)平臺的知識猜旬，其架構(gòu)演進(jìn)簡單一句話說“基本上可以分為五個時代、四種架構(gòu)”胳螟，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與數(shù)據(jù)源類型多樣化特點(diǎn)昔馋，從高階架構(gòu)上來看大約從傳統(tǒng)數(shù)據(jù)平臺第三代架構(gòu)開始延續(xù)的，但是往后的發(fā)展從我自己的這一點(diǎn)知識上很難對互聯(lián)網(wǎng)的數(shù)據(jù)平臺做架構(gòu)歸類糖耸。
但是從數(shù)據(jù)平臺建設(shè)與服務(wù)角色上還是有章可循的秘遏。就像上篇分享到那樣，類比兩個行業(yè)，互聯(lián)網(wǎng)企業(yè)中員工年齡比非互聯(lián)網(wǎng)企業(yè)的要年輕抖苦、受教育程度捕犬、對計(jì)算機(jī)的焦慮程度明顯比傳統(tǒng)企業(yè)要低、還偶遇其它各方面的緣故倦蚪，導(dǎo)致了數(shù)據(jù)平臺所面對用戶群體與非互聯(lián)網(wǎng)數(shù)據(jù)平臺有所差異化。
傳統(tǒng)行業(yè)與互聯(lián)網(wǎng)行業(yè)數(shù)據(jù)平臺用戶特性我只選擇前文章的兩張圖來表示
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
在傳統(tǒng)數(shù)據(jù)平臺要背后有一個完整數(shù)據(jù)倉庫團(tuán)隊(duì)去服務(wù)業(yè)務(wù)方边苹，業(yè)務(wù)方嗷嗷待哺的等待被動方式去滿足陵且。中低層數(shù)據(jù)基本不會對業(yè)務(wù)方開放，所以不管數(shù)據(jù)模型采用何種建模方式个束，主要滿足當(dāng)時數(shù)據(jù)架構(gòu)規(guī)劃即可慕购。
互聯(lián)網(wǎng)業(yè)務(wù)的快速發(fā)展使得大家已經(jīng)從經(jīng)營、分析的訴求重點(diǎn)轉(zhuǎn)為數(shù)據(jù)化的精細(xì)運(yùn)營上茬底，如何做好精細(xì)化運(yùn)營問題上來沪悲，當(dāng)資源不夠時用戶就叫喊，甚至有的業(yè)務(wù)方會挽起袖子來自己參與到從數(shù)據(jù)整理阱表、加工殿如、分析階段贡珊。
此時呢，原有建設(shè)數(shù)據(jù)平臺的多個角色（數(shù)據(jù)開發(fā)涉馁、模型設(shè)計(jì)）可能轉(zhuǎn)為對其它非專業(yè)使用數(shù)據(jù)方门岔，做培訓(xùn)、咨詢與落地谨胞，寫更加適合當(dāng)前企業(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àn)椴粚I(yè)性牢裳，導(dǎo)致數(shù)據(jù)質(zhì)量問題、重復(fù)對分?jǐn)?shù)據(jù)浪費(fèi)存儲與資源叶沛、口徑多樣化蒲讯、編碼不統(tǒng)一、命名問題等等原因灰署。數(shù)據(jù)質(zhì)量逐漸變成一個特別突出的問題判帮。
傳統(tǒng)企業(yè)的數(shù)據(jù)源基本來自excel、表格溉箕、DB系統(tǒng)等晦墙，但在互聯(lián)網(wǎng)有網(wǎng)站點(diǎn)擊流日志、視頻肴茄、音頻晌畅、圖片數(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ù)有些力不從心店展。
當(dāng)數(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è)也有自己特點(diǎn)郑气，傳統(tǒng)行業(yè)所涉及數(shù)據(jù)模型這個領(lǐng)域涉及的很多內(nèi)容在互聯(lián)網(wǎng)變成以其他的曲線救國的方式存在了幅垮。
在互聯(lián)網(wǎng)曲線救國新解決
回顧在傳統(tǒng)行業(yè)數(shù)據(jù)平臺中腰池，不管兩位大師爭論點(diǎn)數(shù)據(jù)模型的設(shè)計(jì)采用那種范式（Bill Inmon的EDW的原則是準(zhǔn)三范式的設(shè)計(jì)、Ralph kilmbal是星型結(jié)構(gòu)）但是都要非常重視數(shù)據(jù)源的質(zhì)量問題。所以傳統(tǒng)行業(yè)的數(shù)據(jù)模型會全盤考慮數(shù)據(jù)質(zhì)量問題示弓，并通過數(shù)據(jù)抽樣分析給出合適的清洗口徑讳侨。
(點(diǎn)擊放大圖像)
上圖來自我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ù)”對一年的還是不準(zhǔn)的）囱皿。在應(yīng)對數(shù)據(jù)的質(zhì)量問題勇婴，目前互聯(lián)網(wǎng)有些做法是把數(shù)據(jù)標(biāo)準(zhǔn)化前置到業(yè)務(wù)數(shù)據(jù)產(chǎn)生就做，從根源上去杜絕數(shù)據(jù)質(zhì)量嘱腥，但是這種場景比較實(shí)用在Log 日志的數(shù)據(jù)源中耕渴，比如移動互聯(lián)網(wǎng)最近流行的基于事件模型“Event”模型，在日志產(chǎn)生時就規(guī)定好存儲格式（備注：大家度娘搜索齿兔，“學(xué)習(xí)筆記：The Log（我所讀過的最好的一篇分布式技術(shù)文章）” 對這個講解很詳細(xì)）橱脸。
在傳統(tǒng)行業(yè)，目前還是以混合模型設(shè)計(jì)方式為主分苇。在互聯(lián)網(wǎng)的我所接觸的一些業(yè)務(wù)添诉，在參照傳統(tǒng)數(shù)據(jù)模型方法論基礎(chǔ)上逐步演進(jìn)適合互聯(lián)網(wǎng)數(shù)據(jù)的數(shù)據(jù)模型方法。
比如互聯(lián)網(wǎng)金融等一些業(yè)務(wù)會參考傳統(tǒng)金融行業(yè)對主題域的劃分医寿、OMG數(shù)據(jù)倉庫元數(shù)據(jù)管理CWM模型栏赴、FSDM金融模型，再進(jìn)一步考慮大數(shù)據(jù)處理特性去進(jìn)行設(shè)計(jì)糟红，所有從Hight Level 數(shù)據(jù)架構(gòu)圖看到主題層次劃分與傳統(tǒng)第三代數(shù)據(jù)倉庫還是很多相似之處艾帐，當(dāng)然模型架構(gòu)也有分三層、四層盆偿、五層的柒爸。
不同的地方模型細(xì)節(jié)處理上已經(jīng)完全不一樣宇智，比如數(shù)據(jù)的多樣性轮纫、拉寬事實(shí)表、度量值單獨(dú)存儲拥褂、滿足數(shù)據(jù)快速重生今野、維度的二次降維處理等、增加大量冗余列罐农、增加大量派生列条霜，結(jié)合自動化元數(shù)據(jù)來耦合、合并等相關(guān)管理涵亏。
(點(diǎn)擊放大圖像)
[圖片上傳中宰睡。蒲凶。。（4）]
上圖是支付寶非常早期數(shù)據(jù)模型
(點(diǎn)擊放大圖像)
上圖是支付寶非常早期數(shù)據(jù)模型
我們常提到的多維模型在大數(shù)據(jù)處理下進(jìn)行了退化維度處理拆内。大家知道Olap多維模型旋圆，隨著維度的增加事實(shí)表的數(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è)計(jì)多維挖掘分析數(shù)據(jù)產(chǎn)品背后的技術(shù)就是搜索引擎實(shí)現(xiàn)的），現(xiàn)在應(yīng)該也有新技術(shù)出現(xiàn)了來解決類似的問題抹沪。
(點(diǎn)擊放大圖像)
上圖為2012年產(chǎn)品UI之一。
(點(diǎn)擊放大圖像)
[圖片上傳中兰吟。通惫。。（7）]
上圖是2011-2012年該產(chǎn)品系列背后當(dāng)時使用的技術(shù)
互聯(lián)網(wǎng)業(yè)務(wù)特點(diǎn)業(yè)務(wù)垂直拆分非常細(xì)混蔼，比如一個用戶注冊履腋、密碼找回的流程有可能存在好幾個產(chǎn)品負(fù)責(zé)同一個業(yè)務(wù)流程不同環(huán)節(jié)，相關(guān)的一個策略惭嚣、產(chǎn)品feature快速迭代上線等等都要數(shù)據(jù)評估遵湖。數(shù)據(jù)從前端埋點(diǎn)到采集然后再由各個環(huán)節(jié)到數(shù)據(jù)平臺，再有數(shù)據(jù)分析師或各業(yè)務(wù)部門去使用晚吞，基本拉長了時間周期延旧。需求部門與實(shí)施部門能力和經(jīng)驗(yàn)有千差萬別的需求，造成了懂技術(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ù)特點(diǎn)是變化非常迅速的牡整，能穩(wěn)定的業(yè)務(wù)達(dá)到65%算對數(shù)據(jù)平臺是個福音了（根據(jù)對某寶寶的印象）剩余的業(yè)務(wù)變化迅速，必然導(dǎo)致數(shù)據(jù)模型快速上下線溺拱。
Kimball老人家提出的維度建模（備注，在本系列發(fā)展史得第一篇有介紹）圍繞業(yè)務(wù)模型能夠非常直觀的表達(dá)出業(yè)務(wù)的數(shù)據(jù)關(guān)系氯材，但是在互聯(lián)網(wǎng)NOSQL犧牲掉了關(guān)系型數(shù)據(jù)庫的一致性变过、完整性等等很多東西。維度數(shù)據(jù)模型又基于這些大數(shù)據(jù)技術(shù)的泥从，所以進(jìn)化的更加輕量級與基于細(xì)節(jié)數(shù)據(jù)的維度退化建模（原有的緩慢變化維、快速變化維沪摄、大維躯嫉、迷你維、父子維杨拐、雪花維為了適應(yīng)互聯(lián)網(wǎng)的大數(shù)據(jù)Nosql處理技術(shù)進(jìn)行反規(guī)范化哄陶、化&數(shù)據(jù)冗余設(shè)計(jì)帆阳。
退化維度的反規(guī)范化設(shè)計(jì)一方面可以把一條查詢語句所需要的所有數(shù)據(jù)組合起來放到一個地方存儲 Key values 的方式（比如說商品有不同類型，每一種類型商品又有自己的不同屬性屋吨，可以采用一對多蜒谤、多對多的方式存儲，例如把一個多維映射為一個Key value）至扰。
講到互聯(lián)網(wǎng)數(shù)據(jù)平臺就要提數(shù)據(jù)模型芭逝，提了數(shù)據(jù)模型就要提Nosql技術(shù)，
(點(diǎn)擊放大圖像)
上圖來自Nosql文檔系列的一幅圖
Nosql 是大數(shù)據(jù)處理的特征之一渊胸⊙ⅲ互聯(lián)網(wǎng)數(shù)據(jù)平臺數(shù)據(jù)模型與NoSql技術(shù)還是蠻緊密的。這里有外文講解Nosql Data modeling technigues 從技術(shù)角度講解非常詳（https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/）翎猛。
因?yàn)榍斑吿岬降拇髷?shù)據(jù)平臺技術(shù)特性決定了傳統(tǒng)edw模型胖翰、維度模型直接在互聯(lián)網(wǎng)數(shù)據(jù)大數(shù)據(jù)平臺部署或許還有“好些未知”障礙等待大家去克服。同時在傳統(tǒng)數(shù)據(jù)建模用到的一些方法經(jīng)過互聯(lián)網(wǎng)熏陶或許演進(jìn)成一種新的數(shù)據(jù)產(chǎn)品或方案吧切厘。
到此為止“我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史”上下共四篇與大家分享完畢萨咳，這個寫作前后經(jīng)歷剛好一個月左右，算是對自己數(shù)據(jù)從業(yè)經(jīng)歷回顧之一吧疫稿。在知識的整理中很多都是蜻蜓點(diǎn)水培他，每個知識域都是一個非常深的專業(yè)方向，自己涉足很膚淺遗座，在文章中分享不足之處請各位讀者見諒Ｒ荨！
個人郵箱是5592094@qq.com 歡迎電郵交流途蒋。
接下來我會進(jìn)入數(shù)據(jù)產(chǎn)品這個領(lǐng)域的分享猛遍，當(dāng)年車品覺老師自豪的作品之一“黃金策”，我是數(shù)據(jù)產(chǎn)品經(jīng)理。（ps：自己躲在墻角拿車品覺老師往自己臉上貼金了）懊烤。
后記
有一次數(shù)據(jù)產(chǎn)品神策的創(chuàng)始人兼好友@桑文鋒＠SensorsData跟我說來做次分享吧梯醒，我當(dāng)時出了幾個題目，最后就選擇了“我所經(jīng)歷的大數(shù)據(jù)平臺“腌紧，就形成了大家看到的”我所經(jīng)歷的大數(shù)據(jù)平臺“系列文章.
在整理期間得到了死黨@周愛民茸习、@神策-桑文峰刻炒、 InfoQ小編@Tina Du 茂嗓、@betty zhou @Laurel大力協(xié)助驹暑，在這里感謝Ｋ硗痢！化撕！
番外篇
這一篇是在24日舉行的分享大家提到的一些問題，經(jīng)過整理算是對正文的補(bǔ)充吧，從互聯(lián)網(wǎng)敏捷數(shù)據(jù)模型等角度做了較深入的細(xì)節(jié)介紹乙帮。同時在數(shù)據(jù)產(chǎn)品方面的回答包含了一點(diǎn)未來寫作篇“數(shù)據(jù)產(chǎn)品”系列的一點(diǎn)內(nèi)容。
1****极景，傳統(tǒng)我們做BI的察净，做數(shù)據(jù)展現(xiàn)會建模后以pivot展現(xiàn)cube數(shù)據(jù)，不知道現(xiàn)在互聯(lián)網(wǎng)公司數(shù)據(jù)展示如何做的盼樟？第三方工具還是用API取數(shù)據(jù)平臺里的數(shù)據(jù)氢卡？adhoc報(bào)表及靈活更換維度的時候web端一般是怎么做的？
松子老師：剛才文章中提到了比如傳統(tǒng)行業(yè)的多維數(shù)據(jù)模型cube晨缴。在互聯(lián)網(wǎng)采用的曲線救國方式解決的译秦。 在分享中我給出了幾個圖。就是通過搜索引擎曲線救國方式實(shí)現(xiàn)類似Olap的模擬击碗。
在這塊的模型的處理上采用的是維度退化處理筑悴。通過反規(guī)范化，數(shù)據(jù)項(xiàng)稍途、數(shù)據(jù)冗余去處理阁吝。在前端做特殊處理。
這個當(dāng)時產(chǎn)品原型之一：
(點(diǎn)擊放大圖像)
這是一個2011年-2012年左右的數(shù)據(jù)產(chǎn)品械拍，當(dāng)時算是即時計(jì)算的一種突勇。不過已經(jīng)過去好幾年了，當(dāng)今新技術(shù)下Olap 引擎應(yīng)該有很好的提升坷虑。
目前我知道的家互聯(lián)網(wǎng)公司甲馋，在前端展現(xiàn)有使用第三方套件比如spagoBi、pentaho 等 有自己設(shè)計(jì)開發(fā)定制化數(shù)據(jù)前端展現(xiàn)迄损。比如我剛開始分享的那兩個之前在去哪兒網(wǎng)設(shè)計(jì)的數(shù)據(jù)平臺內(nèi)部界面之一摔刁，當(dāng)然數(shù)據(jù)產(chǎn)品是另一個話題了，通過對數(shù)據(jù)分析抽象指標(biāo)、分析模型共屈、用戶使用功能與流程绑谣、未來規(guī)劃考慮用戶體驗(yàn)去設(shè)計(jì)。
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
[圖片上傳中拗引。借宵。。（11）]
(點(diǎn)擊放大圖像)
2****矾削，互聯(lián)網(wǎng)財(cái)經(jīng)類公司壤玫，業(yè)務(wù)包括財(cái)經(jīng)網(wǎng)站、基金、股票萝勤、金融等沸呐，這類公司的數(shù)據(jù)倉庫模型應(yīng)該如何設(shè)計(jì)？特點(diǎn)和注意事項(xiàng)是什么猎贴？案例介紹？十分感謝蝴光。
松子老師：我自己經(jīng)歷過的是互聯(lián)網(wǎng)金融以及移動互聯(lián)網(wǎng)行她渴。對這兩塊比較清楚∶锼睿互聯(lián)網(wǎng)金融起因?yàn)闃I(yè)務(wù)的特性是類金融類的趁耗，與銀行有些地方是相似的。
比如大約在2012年前支付寶業(yè)務(wù)特點(diǎn)涉及類金融交易：充值疆虚、提現(xiàn)苛败、賬務(wù)管理類電子商務(wù)：購物交易過程變更、實(shí)際交易（對B機(jī)票径簿、對C水電等） 非純電子商務(wù)著拭；純金融；個人信用牍帚，理財(cái)類儡遮。系統(tǒng)之間依賴度較為復(fù)雜，垂直依賴（業(yè)務(wù)與核心）跨層依賴（跨過交易到賬務(wù)）暗赶。
在設(shè)計(jì)方法上還是采用維度模型設(shè)計(jì)方式鄙币。底層是數(shù)據(jù)驅(qū)動為向?qū)ВY(jié)合業(yè)務(wù)需求驅(qū)動蹂随，通過簡單十嘿、退化維度的方式拉寬表結(jié)構(gòu)。
底層采用松耦合設(shè)計(jì)岳锁。主題之間是松耦合方式绩衷。至體內(nèi)采用細(xì)粒度退化維度。
在主題域上的的設(shè)計(jì)基本參考了OMG的數(shù)據(jù)倉庫元數(shù)據(jù)設(shè)計(jì)CWM模型、IBM 的fsdm金融模型咳燕、還有新巴塞爾資本協(xié)議（Basel II Capital Accord）需提供數(shù)據(jù)規(guī)范去的設(shè)計(jì)勿决。所以數(shù)據(jù)模型是五層的結(jié)構(gòu)。
在細(xì)節(jié)處理上招盲，增量ODS層數(shù)據(jù)和前一天DWD相關(guān)表進(jìn)行 merge處理低缩。
在一些層次上，基本聚合曹货、匯總增加派生事實(shí)表（簡單一句話退化為度打?qū)挘┡胤薄Ｈ缓蟀凑諛I(yè)務(wù)主體合并信息等。
比如開始給大家分享的那張圖：
(點(diǎn)擊放大圖像)
在維度模型退化處理時顶籽，要注意最細(xì)粒度數(shù)據(jù)保留玩般、不同層次的數(shù)據(jù)支持?jǐn)?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ù)模型恤溶。
這種元數(shù)據(jù)驅(qū)動工具型數(shù)據(jù)產(chǎn)品我會在未來數(shù)據(jù)產(chǎn)品系列中做詳細(xì)介紹的荒辕。
3****掐暮，互聯(lián)網(wǎng)企業(yè)大數(shù)據(jù)平臺的發(fā)展歷程是怎樣的芹助？
松子老師：這個我相信應(yīng)該是傳統(tǒng)數(shù)據(jù)平臺朋友提到的洪囤。傳統(tǒng)行業(yè)數(shù)據(jù)平臺架構(gòu)演進(jìn)我總結(jié)簡單一句話說“基本上可以分為五個時代跑慕、四種架構(gòu)”万皿，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與類型暴增的特點(diǎn)，從高階架構(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é)下來用戶特點(diǎn)：
(點(diǎn)擊放大圖像)
[圖片上傳中。惩系。位岔。（14）]
更加詳細(xì)的每一代數(shù)據(jù)平臺建設(shè)、服務(wù)角色特點(diǎn)您可以看我這個系列文章的第三篇堡牡，http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-paet02
4****抒抬，有沒有好的元數(shù)據(jù)管理工具推薦？主要偏向數(shù)據(jù)字典與血統(tǒng)等晤柄。
松子老師：元數(shù)據(jù)以前目前沒有太多的好管理工具擦剑。以前是在支付寶是我自己設(shè)計(jì)的一個數(shù)據(jù)產(chǎn)品。第一版自己用Delphi 開發(fā)的。
（圖很多：）
(點(diǎn)擊放大圖像)
[圖片上傳中惠勒。赚抡。捉撮。（15）]
(點(diǎn)擊放大圖像)
[圖片上傳中怕品。。巾遭。（16）]
(點(diǎn)擊放大圖像)
[圖片上傳中肉康。。灼舍。（17）]
(點(diǎn)擊放大圖像)
[圖片上傳中吼和。。骑素。（18）]
(點(diǎn)擊放大圖像)
[圖片上傳中炫乓。。献丑。（19）]
以前被逼的自己寫了一個挤悉，通過解析，實(shí)現(xiàn)了字段級的血緣影響分析汹粤。這只是第二步虫腋，后來又把running 信息給搞了進(jìn)來。還有分享時提到的模型信息妥畏、整個閉環(huán)的分類信息邦邦。
這是一個分支：
(點(diǎn)擊放大圖像)
[圖片上傳中。醉蚁。燃辖。（20）]
但是我們實(shí)現(xiàn)了字段級解析準(zhǔn)確率達(dá)到了94%左右。有細(xì)微的錯誤就人工revew一遍网棍。
5. ****松子老師黔龟，數(shù)據(jù)管控的數(shù)據(jù)質(zhì)量部分是怎么處理的呢？
松子老師： 數(shù)據(jù)管控滥玷， 這方面我不太懂的氏身，但是數(shù)據(jù)質(zhì)量，這玩意可大可小的罗捎。比如像在分享時說過的观谦，在移動互聯(lián)網(wǎng)的數(shù)據(jù)質(zhì)量處理方式可以由原有的ETL(ELT)階段前置到業(yè)務(wù)系統(tǒng)去解決，比如移動互聯(lián)網(wǎng)的App log 日志桨菜，日志標(biāo)準(zhǔn)化后事件模型”存儲來解決豁状。那非app 日志類如何解決呢比如Payment捉偏、order等，數(shù)據(jù)質(zhì)量比較考慮的可以只做到監(jiān)控泻红。
我來分享個圖夭禽。剛好是我設(shè)計(jì)數(shù)據(jù)質(zhì)量產(chǎn)品時搞的，理清數(shù)據(jù)質(zhì)量的問題：
(點(diǎn)擊放大圖像)
[圖片上傳中谊路。。缠劝。（21）]
(點(diǎn)擊放大圖像)
[圖片上傳中潮梯。。惨恭。（22）]
(點(diǎn)擊放大圖像)
[圖片上傳中秉馏。。脱羡。（23）]
只要數(shù)據(jù)進(jìn)入倉庫與應(yīng)用體系萝究，處理起來就比較困難了，所以在數(shù)據(jù)平臺階段最好是通過監(jiān)控锉罐、前置去解決帆竹。目前數(shù)據(jù)質(zhì)量確實(shí)難以100%由事后搞到事前去處理。我對數(shù)據(jù)平臺與數(shù)據(jù)產(chǎn)品的建設(shè)就是實(shí)用為主脓规。怎么實(shí)用怎么來栽连。我是比較現(xiàn)實(shí)的實(shí)用主義者献雅。
6. ****能否分享一些數(shù)據(jù)產(chǎn)品種類及實(shí)例：
松子老師：在前邊五個問題邪媳、以及文章中又都涉及數(shù)據(jù)產(chǎn)品實(shí)力的一些分享。
提到數(shù)據(jù)產(chǎn)品的分類我就想把這個圖發(fā)出來。
自己認(rèn)為沒有特別明確的劃分線态罪，但是數(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工具帜讲、資源管控等等。
面向用戶功能有報(bào)表型椒拗、多維型數(shù)據(jù)產(chǎn)品似将、定制化數(shù)據(jù)產(chǎn)品获黔、挖掘型數(shù)據(jù)產(chǎn)品。
面向內(nèi)部用戶在验、外部個人用戶玷氏、外部企業(yè)用戶又有不同的分類。
根據(jù)業(yè)務(wù)又可以劃分很多腋舌，面向C類用戶盏触、面向B類商戶、金融風(fēng)險(xiǎn)等等
從近幾年的數(shù)據(jù)產(chǎn)品來看块饺，是更好的輔助用戶的做決策的一種產(chǎn)品形態(tài)赞辩，在用戶的決策與行動中充當(dāng)信息的分析者與價值使用者；數(shù)據(jù)產(chǎn)品有個自己的共性：由解決的一個實(shí)際的業(yè)務(wù)問題出發(fā)授艰，分解出的分析指標(biāo)诗宣，分析模型，分析流程組成想诅，再考慮到功能易用性召庞，未來功能擴(kuò)展，考慮用戶對數(shù)據(jù)易用性（比如數(shù)據(jù)的呈現(xiàn)層次来破，不可能一次把所有數(shù)據(jù)的呈現(xiàn)給用戶）來組成的篮灼。
(點(diǎn)擊放大圖像)
[圖片上傳中。徘禁。诅诱。（24）]
7. ****銀行業(yè)從傳統(tǒng)的ods到edw再到大數(shù)據(jù)平臺這塊過渡，模型如何建設(shè)送朱？平臺優(yōu)勢如何發(fā)揮娘荡？
松子老師：這個問題還是有些難度的，自己回答的可能有些片面。首先我們清醒的清楚“大數(shù)據(jù)”是什么？再次不同的場景可以采用不同的技術(shù)去解決丈冬。
“大數(shù)據(jù)”穗泵，拆開來看大、數(shù)據(jù)，大可以是指的數(shù)據(jù)源結(jié)構(gòu)簡單（ps 如果了解過當(dāng)代對大數(shù)據(jù)的定義就知道四個特性）但是量級夠大，比如清算、結(jié)算翔试、對公、對私复旬、中間業(yè)務(wù)等等每一個拿出來都是幾十T垦缅，但是這些業(yè)務(wù)數(shù)據(jù)都是保存?zhèn)鹘y(tǒng)的關(guān)系型數(shù)據(jù)庫中如DB2、Oracle驹碍、MSsql中壁涎，因?yàn)樵跀?shù)據(jù)平臺存儲是通過準(zhǔn)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ù)的去演進(jìn)解決。（最早時我的是中信銀行履婉、光大銀行在2011年左右開始考慮Hadoop技術(shù)煤篙，后來不知道如何了）。
但是互聯(lián)網(wǎng)的數(shù)據(jù)平臺技術(shù)大都是NOSQL模式毁腿，犧牲掉了傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)一致性辑奈、完整性、唯一索引等等已烤，只干性能的事情（當(dāng)然除了性能鸠窗、可擴(kuò)展性也是的）.
原有在傳統(tǒng)數(shù)據(jù)平臺模型設(shè)計(jì)上可以考慮的一些通過主外鍵、唯一索引做一些業(yè)務(wù)約束的方法胯究，在nosql上統(tǒng)統(tǒng)的都沒有了稍计，這些約束必須放到數(shù)據(jù)加工階段去想辦法做檢查。傳統(tǒng)數(shù)據(jù)平臺如果在Insert裕循、update數(shù)據(jù)時違反了業(yè)務(wù)約束可以做報(bào)警或異常處理臣嚣，但是在Nosql的平臺上要求ETL 去手動遵守這些規(guī)則檢查净刮。但是有時ETL開發(fā)根本不遵守的，僅僅是兩個表關(guān)聯(lián)起來硅则，也可能忘記按照某一個業(yè)務(wù)唯一索引做去重操作淹父。簡單說，原有靠關(guān)系型數(shù)據(jù)庫本身機(jī)制去做檢查一些規(guī)則變?yōu)槿斯ぴ醭妫優(yōu)槿斯ぞ蜁稿e弹灭。
從關(guān)系型數(shù)據(jù)平臺往Nosql數(shù)據(jù)平臺遷移時，尤其是對傳統(tǒng)行業(yè)的業(yè)務(wù)來說揪垄，在模型設(shè)計(jì)階段穷吮、以及給出的ETL口徑要考慮更多的業(yè)務(wù)規(guī)則檢查取刃，其次要考慮更多的維度退化京办、多冗余、表打?qū)捥幚砗辽睢：唵握f就是發(fā)揮數(shù)據(jù)平臺的計(jì)算能力同時要更加的各方面確保數(shù)據(jù)準(zhǔn)確安全可靠酷愧。
數(shù)據(jù)模型ODS 到EDW 這塊的設(shè)計(jì)方法百度上留下的文檔資料太多的了驾诈，請這位提問的老師百度吧。
**8****．大數(shù)據(jù)****倉庫****中如何做快速****維處****理溶浴？互****聯(lián)****網(wǎng)數(shù)****倉****數(shù)據(jù)****質(zhì)****量不好如何****對****數(shù)乍迄，如何確立****標(biāo)****準(zhǔn)的****對****數(shù)口徑？******
松子老師：快速變化維度可以轉(zhuǎn)化為緩慢變化為來出來士败，我自己理解的快速維度是相對于緩慢維度參照的來說的闯两。
舉個例子，年齡-轉(zhuǎn)化為天數(shù)可以是定義快速變化維度谅将，因?yàn)槊刻於荚谧兓恰Ｎ覀兛梢园涯挲g退化為區(qū)間維度來處理，還可以把年齡做成動態(tài)維度來處理饥臂，事實(shí)表中保存的就是實(shí)際的出生年月并打?qū)挶硌吩辏挲g(天)通過計(jì)算方式來處理。還有種方法通過對代理鍵的方式來處理。
我目前也不知道對數(shù)據(jù)的標(biāo)準(zhǔn)是什么囚戚。但是我自己用的方法酵熙，把一個指標(biāo)的整個數(shù)據(jù)流向切出幾個關(guān)鍵點(diǎn)通過SQL去實(shí)現(xiàn)對數(shù)，看波動振幅弯淘，波動曲線绿店。同時還會比如發(fā)不通的版本的小流量測試的方式來做數(shù)據(jù)校對。
9****． 做為數(shù)據(jù)行業(yè)從業(yè)者庐橙，需要掌握哪些重要的基礎(chǔ)知識假勿？另：如果從零開始建立一個數(shù)據(jù)平臺，需要哪些資源配置（人态鳖，財(cái)转培，物，技術(shù)）浆竭？大致總投資額度多少浸须？如果同行產(chǎn)品間多種來源的數(shù)據(jù)，可有成熟的解決方案邦泄？謝謝…
松子老師：這個問題太宏觀了删窒。作為數(shù)據(jù)行業(yè)從業(yè)者，需要掌握哪些重要基礎(chǔ)知識顺囊，這個是要看從事具體數(shù)據(jù)域的垂直行業(yè)肌索。
比如說 數(shù)據(jù)開發(fā)、數(shù)據(jù)模型特碳、數(shù)據(jù)產(chǎn)品诚亚、數(shù)據(jù)分析師俐镐、數(shù)據(jù)運(yùn)營霜瘪、數(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ù)目標(biāo)不太明確下，難以確定方案枣接，人員配置上選用不同技術(shù)方案去搭建的配置是不太一樣的颂暇，比如說傳統(tǒng)平臺來講，運(yùn)維但惶、DBA耳鸯、數(shù)據(jù)開發(fā)、數(shù)據(jù)模型膀曾、報(bào)表人員县爬。
從互聯(lián)網(wǎng)數(shù)據(jù)平臺基本配置上，數(shù)據(jù)架構(gòu)師添谊、運(yùn)維财喳、底層大數(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ù)修壕。
10. Standalone****模式下愈捅，Model.save(Path)怎么一直提示錯誤，是不是配置Spark時需要將Hdfs的配置引進(jìn)來啊～慈鸠？表示初學(xué)Spark
松子老師：這個問題有點(diǎn)超出我的能力范圍了蓝谨，所以對不起回答不了。
我本身不是做技術(shù)的林束。僅知道一點(diǎn)技術(shù)名詞像棘。
11. ****傳統(tǒng)銀行業(yè)數(shù)據(jù)模型什么時候會走向互聯(lián)網(wǎng)模式呢？目前在傳統(tǒng)銀行數(shù)據(jù)平臺的產(chǎn)品是不是特別多壶冒？
松子老師：這個問題我自己就不知道了缕题，或許是傳統(tǒng)銀行在數(shù)據(jù)平臺的實(shí)施上全面用互聯(lián)網(wǎng)的Nosql大數(shù)據(jù)處理技術(shù)吧追迟。至于說傳統(tǒng)銀行數(shù)據(jù)模型用現(xiàn)有的互聯(lián)網(wǎng)數(shù)據(jù)模型理念去設(shè)計(jì)是否完全可行官脓，數(shù)據(jù)一致性颗品、高準(zhǔn)確性通過更多的方案去保證铐拐。
首先我需要確定一下這個產(chǎn)品是否指的“數(shù)據(jù)產(chǎn)品”。
如果是數(shù)據(jù)產(chǎn)品浙值，那其實(shí)傳統(tǒng)行業(yè)數(shù)據(jù)平臺本身就有一些數(shù)據(jù)產(chǎn)品了酣衷，而且也都是存在的涯捻。數(shù)據(jù)產(chǎn)品自從數(shù)據(jù)倉庫出現(xiàn)以來它其實(shí)一直都存在的记罚，只不過是近幾年因?yàn)榛ヂ?lián)網(wǎng)特別愛制造“流行詞“把數(shù)據(jù)產(chǎn)品這個詞給放大了墅诡。互聯(lián)網(wǎng)是得數(shù)據(jù)產(chǎn)品從早期的重量級逐漸進(jìn)化為輕量級桐智、從大而全的解決方案逐漸演進(jìn)為因小而美末早。
我來給出幾組例子，大約從2004年到現(xiàn)在的幾組數(shù)據(jù)產(chǎn)品的例子
(點(diǎn)擊放大圖像)
[圖片上傳中说庭。然磷。。（25）]
(點(diǎn)擊放大圖像)
[圖片上傳中刊驴。姿搜。寡润。（26）]
(點(diǎn)擊放大圖像)
[圖片上傳中。舅柜。梭纹。（27）]
(點(diǎn)擊放大圖像)
[圖片上傳中。业踢。栗柒。（28）]
(點(diǎn)擊放大圖像)
[圖片上傳中礁扮。知举。。（29）]
(點(diǎn)擊放大圖像)
[圖片上傳中太伊。雇锡。。（30）]
(點(diǎn)擊放大圖像)
[圖片上傳中僚焦。锰提。。（31）]
你可以分類一下芳悲，這些數(shù)據(jù)產(chǎn)品的特點(diǎn)是什么立肘？滿足了用戶怎么樣的痛點(diǎn)需求？滿足了用戶怎么樣的使用流程名扛。
12 ****。傳統(tǒng)行業(yè)的數(shù)據(jù)倉庫從業(yè)人員肮韧，如果轉(zhuǎn)到互聯(lián)網(wǎng)行業(yè)，應(yīng)該學(xué)習(xí)哪些技能？
松子老師：這個問題你可以百度搜索“大數(shù)據(jù)職位所需要的數(shù)據(jù)技能” http://blog.jobbole.com/99039/ 這篇文章决瞳。自己覺得人家回答的比我專業(yè)固逗。//
我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史（四）：互聯(lián)網(wǎng)時代 ? 下篇
http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-internet-age
編者按：本文是松子（李博源）的大數(shù)據(jù)平臺發(fā)展史系列文章的第四篇（共四篇），本系列以獨(dú)特的視角拘领，比較了非互聯(lián)網(wǎng)和互聯(lián)網(wǎng)兩個時代以及傳統(tǒng)行業(yè)與非傳統(tǒng)行業(yè)意乓。是對數(shù)據(jù)平臺發(fā)展的一個回憶，對非互聯(lián)網(wǎng)约素、互聯(lián)網(wǎng)届良，從數(shù)據(jù)平臺的用戶角度、數(shù)據(jù)架構(gòu)演進(jìn)业汰、模型等進(jìn)行了闡述伙窃。
在互聯(lián)網(wǎng)時代被弱化的數(shù)據(jù)模型
談起數(shù)據(jù)模型就不得不提傳統(tǒng)數(shù)據(jù)平臺架構(gòu)發(fā)展，我相信很多朋友都曉得傳統(tǒng)數(shù)據(jù)平臺的知識样漆，其架構(gòu)演進(jìn)簡單一句話說“基本上可以分為五個時代为障、四種架構(gòu)”，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與數(shù)據(jù)源類型多樣化特點(diǎn)，從高階架構(gòu)上來看大約從傳統(tǒng)數(shù)據(jù)平臺第三代架構(gòu)開始延續(xù)的鳍怨，但是往后的發(fā)展從我自己的這一點(diǎn)知識上很難對互聯(lián)網(wǎng)的數(shù)據(jù)平臺做架構(gòu)歸類呻右。
但是從數(shù)據(jù)平臺建設(shè)與服務(wù)角色上還是有章可循的。就像上篇分享到那樣鞋喇，類比兩個行業(yè)声滥，互聯(lián)網(wǎng)企業(yè)中員工年齡比非互聯(lián)網(wǎng)企業(yè)的要年輕、受教育程度侦香、對計(jì)算機(jī)的焦慮程度明顯比傳統(tǒng)企業(yè)要低落塑、還偶遇其它各方面的緣故，導(dǎo)致了數(shù)據(jù)平臺所面對用戶群體與非互聯(lián)網(wǎng)數(shù)據(jù)平臺有所差異化罐韩。
傳統(tǒng)行業(yè)與互聯(lián)網(wǎng)行業(yè)數(shù)據(jù)平臺用戶特性我只選擇前文章的兩張圖來表示
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
在傳統(tǒng)數(shù)據(jù)平臺要背后有一個完整數(shù)據(jù)倉庫團(tuán)隊(duì)去服務(wù)業(yè)務(wù)方憾赁，業(yè)務(wù)方嗷嗷待哺的等待被動方式去滿足。中低層數(shù)據(jù)基本不會對業(yè)務(wù)方開放散吵，所以不管數(shù)據(jù)模型采用何種建模方式龙考，主要滿足當(dāng)時數(shù)據(jù)架構(gòu)規(guī)劃即可。
互聯(lián)網(wǎng)業(yè)務(wù)的快速發(fā)展使得大家已經(jīng)從經(jīng)營矾睦、分析的訴求重點(diǎn)轉(zhuǎn)為數(shù)據(jù)化的精細(xì)運(yùn)營上晦款，如何做好精細(xì)化運(yùn)營問題上來，當(dāng)資源不夠時用戶就叫喊枚冗，甚至有的業(yè)務(wù)方會挽起袖子來自己參與到從數(shù)據(jù)整理缓溅、加工、分析階段官紫。
此時呢肛宋，原有建設(shè)數(shù)據(jù)平臺的多個角色（數(shù)據(jù)開發(fā)、模型設(shè)計(jì)）可能轉(zhuǎn)為對其它非專業(yè)使用數(shù)據(jù)方束世，做培訓(xùn)酝陈、咨詢與落地议蟆，寫更加適合當(dāng)前企業(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àn)椴粚I(yè)性，導(dǎo)致數(shù)據(jù)質(zhì)量問題坤按、重復(fù)對分?jǐn)?shù)據(jù)浪費(fèi)存儲與資源考传、口徑多樣化招拙、編碼不統(tǒng)一其屏、命名問題等等原因喇勋。數(shù)據(jù)質(zhì)量逐漸變成一個特別突出的問題。
傳統(tǒng)企業(yè)的數(shù)據(jù)源基本來自excel偎行、表格川背、DB系統(tǒng)等贰拿，但在互聯(lián)網(wǎng)有網(wǎng)站點(diǎn)擊流日志、視頻熄云、音頻膨更、圖片數(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ù)有些力不從心矗漾。
當(dāng)數(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è)也有自己特點(diǎn)，傳統(tǒng)行業(yè)所涉及數(shù)據(jù)模型這個領(lǐng)域涉及的很多內(nèi)容在互聯(lián)網(wǎng)變成以其他的曲線救國的方式存在了法希。
在互聯(lián)網(wǎng)曲線救國新解決
回顧在傳統(tǒng)行業(yè)數(shù)據(jù)平臺中枷餐，不管兩位大師爭論點(diǎn)數(shù)據(jù)模型的設(shè)計(jì)采用那種范式（Bill Inmon的EDW的原則是準(zhǔn)三范式的設(shè)計(jì)、Ralph kilmbal是星型結(jié)構(gòu)）但是都要非常重視數(shù)據(jù)源的質(zhì)量問題苫亦。所以傳統(tǒng)行業(yè)的數(shù)據(jù)模型會全盤考慮數(shù)據(jù)質(zhì)量問題毛肋，并通過數(shù)據(jù)抽樣分析給出合適的清洗口徑。
(點(diǎn)擊放大圖像)
上圖來自我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ù)”對一年的還是不準(zhǔn)的）冤荆。在應(yīng)對數(shù)據(jù)的質(zhì)量問題，目前互聯(lián)網(wǎng)有些做法是把數(shù)據(jù)標(biāo)準(zhǔn)化前置到業(yè)務(wù)數(shù)據(jù)產(chǎn)生就做肄鸽，從根源上去杜絕數(shù)據(jù)質(zhì)量，但是這種場景比較實(shí)用在Log 日志的數(shù)據(jù)源中油啤，比如移動互聯(lián)網(wǎng)最近流行的基于事件模型“Event”模型典徘，在日志產(chǎn)生時就規(guī)定好存儲格式（備注：大家度娘搜索，“學(xué)習(xí)筆記：The Log（我所讀過的最好的一篇分布式技術(shù)文章）” 對這個講解很詳細(xì)）益咬。
在傳統(tǒng)行業(yè)逮诲，目前還是以混合模型設(shè)計(jì)方式為主。在互聯(lián)網(wǎng)的我所接觸的一些業(yè)務(wù)幽告，在參照傳統(tǒng)數(shù)據(jù)模型方法論基礎(chǔ)上逐步演進(jìn)適合互聯(lián)網(wǎng)數(shù)據(jù)的數(shù)據(jù)模型方法梅鹦。
比如互聯(lián)網(wǎng)金融等一些業(yè)務(wù)會參考傳統(tǒng)金融行業(yè)對主題域的劃分、OMG數(shù)據(jù)倉庫元數(shù)據(jù)管理CWM模型冗锁、FSDM金融模型齐唆，再進(jìn)一步考慮大數(shù)據(jù)處理特性去進(jìn)行設(shè)計(jì)，所有從Hight Level 數(shù)據(jù)架構(gòu)圖看到主題層次劃分與傳統(tǒng)第三代數(shù)據(jù)倉庫還是很多相似之處冻河，當(dāng)然模型架構(gòu)也有分三層箍邮、四層茉帅、五層的。
不同的地方模型細(xì)節(jié)處理上已經(jīng)完全不一樣锭弊，比如數(shù)據(jù)的多樣性堪澎、拉寬事實(shí)表、度量值單獨(dú)存儲味滞、滿足數(shù)據(jù)快速重生全封、維度的二次降維處理等、增加大量冗余列烁焙、增加大量派生列，結(jié)合自動化元數(shù)據(jù)來耦合丁频、合并等相關(guān)管理杉允。
(點(diǎn)擊放大圖像)
上圖是支付寶非常早期數(shù)據(jù)模型
(點(diǎn)擊放大圖像)
上圖是支付寶非常早期數(shù)據(jù)模型
我們常提到的多維模型在大數(shù)據(jù)處理下進(jìn)行了退化維度處理。大家知道Olap多維模型限府，隨著維度的增加事實(shí)表的數(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è)計(jì)多維挖掘分析數(shù)據(jù)產(chǎn)品背后的技術(shù)就是搜索引擎實(shí)現(xiàn)的），現(xiàn)在應(yīng)該也有新技術(shù)出現(xiàn)了來解決類似的問題独旷。
(點(diǎn)擊放大圖像)
上圖為2012年產(chǎn)品UI之一署穗。
(點(diǎn)擊放大圖像)
[圖片上傳中。嵌洼。案疲。（7）]
上圖是2011-2012年該產(chǎn)品系列背后當(dāng)時使用的技術(shù)
互聯(lián)網(wǎng)業(yè)務(wù)特點(diǎn)業(yè)務(wù)垂直拆分非常細(xì)，比如一個用戶注冊彪杉、密碼找回的流程有可能存在好幾個產(chǎn)品負(fù)責(zé)同一個業(yè)務(wù)流程不同環(huán)節(jié)捣染，相關(guān)的一個策略猜丹、產(chǎn)品feature快速迭代上線等等都要數(shù)據(jù)評估卤唉。數(shù)據(jù)從前端埋點(diǎn)到采集然后再由各個環(huán)節(jié)到數(shù)據(jù)平臺备畦，再有數(shù)據(jù)分析師或各業(yè)務(wù)部門去使用低飒，基本拉長了時間周期。需求部門與實(shí)施部門能力和經(jīng)驗(yàn)有千差萬別的需求懂盐，造成了懂技術(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ù)特點(diǎn)是變化非常迅速的，能穩(wěn)定的業(yè)務(wù)達(dá)到65%算對數(shù)據(jù)平臺是個福音了（根據(jù)對某寶寶的印象）剩余的業(yè)務(wù)變化迅速捶惜，必然導(dǎo)致數(shù)據(jù)模型快速上下線田藐。
Kimball老人家提出的維度建模（備注，在本系列發(fā)展史得第一篇有介紹）圍繞業(yè)務(wù)模型能夠非常直觀的表達(dá)出業(yè)務(wù)的數(shù)據(jù)關(guān)系售躁，但是在互聯(lián)網(wǎng)NOSQL犧牲掉了關(guān)系型數(shù)據(jù)庫的一致性坞淮、完整性等等很多東西。維度數(shù)據(jù)模型又基于這些大數(shù)據(jù)技術(shù)的陪捷，所以進(jìn)化的更加輕量級與基于細(xì)節(jié)數(shù)據(jù)的維度退化建模（原有的緩慢變化維回窘、快速變化維、大維市袖、迷你維啡直、父子維、雪花維為了適應(yīng)互聯(lián)網(wǎng)的大數(shù)據(jù)Nosql處理技術(shù)進(jìn)行反規(guī)范化苍碟、化&數(shù)據(jù)冗余設(shè)計(jì)酒觅。
退化維度的反規(guī)范化設(shè)計(jì)一方面可以把一條查詢語句所需要的所有數(shù)據(jù)組合起來放到一個地方存儲 Key values 的方式（比如說商品有不同類型，每一種類型商品又有自己的不同屬性微峰，可以采用一對多舷丹、多對多的方式存儲，例如把一個多維映射為一個Key value）蜓肆。
講到互聯(lián)網(wǎng)數(shù)據(jù)平臺就要提數(shù)據(jù)模型颜凯，提了數(shù)據(jù)模型就要提Nosql技術(shù)，
(點(diǎn)擊放大圖像)
上圖來自Nosql文檔系列的一幅圖
Nosql 是大數(shù)據(jù)處理的特征之一仗扬≈⒏牛互聯(lián)網(wǎng)數(shù)據(jù)平臺數(shù)據(jù)模型與NoSql技術(shù)還是蠻緊密的。這里有外文講解Nosql Data modeling technigues 從技術(shù)角度講解非常詳（https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/）早芭。
因?yàn)榍斑吿岬降拇髷?shù)據(jù)平臺技術(shù)特性決定了傳統(tǒng)edw模型彼城、維度模型直接在互聯(lián)網(wǎng)數(shù)據(jù)大數(shù)據(jù)平臺部署或許還有“好些未知”障礙等待大家去克服。同時在傳統(tǒng)數(shù)據(jù)建模用到的一些方法經(jīng)過互聯(lián)網(wǎng)熏陶或許演進(jìn)成一種新的數(shù)據(jù)產(chǎn)品或方案吧踱卵。
到此為止“我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史”上下共四篇與大家分享完畢尿瞭，這個寫作前后經(jīng)歷剛好一個月左右豫喧，算是對自己數(shù)據(jù)從業(yè)經(jīng)歷回顧之一吧限书。在知識的整理中很多都是蜻蜓點(diǎn)水砖织，每個知識域都是一個非常深的專業(yè)方向余境，自己涉足很膚淺肿孵，在文章中分享不足之處請各位讀者見諒＠菔帧习柠！
個人郵箱是5592094@qq.com 歡迎電郵交流匀谣。
接下來我會進(jìn)入數(shù)據(jù)產(chǎn)品這個領(lǐng)域的分享，當(dāng)年車品覺老師自豪的作品之一“黃金策”资溃，我是數(shù)據(jù)產(chǎn)品經(jīng)理武翎。（ps：自己躲在墻角拿車品覺老師往自己臉上貼金了）。
后記
有一次數(shù)據(jù)產(chǎn)品神策的創(chuàng)始人兼好友@桑文鋒＠SensorsData跟我說來做次分享吧溶锭，我當(dāng)時出了幾個題目宝恶，最后就選擇了“我所經(jīng)歷的大數(shù)據(jù)平臺“，就形成了大家看到的”我所經(jīng)歷的大數(shù)據(jù)平臺“系列文章.
在整理期間得到了死黨@周愛民趴捅、@神策-桑文峰垫毙、 InfoQ小編@Tina Du 、@betty zhou @Laurel大力協(xié)助拱绑，在這里感謝Ｗ劢妗！猎拨！
番外篇
這一篇是在24日舉行的分享大家提到的一些問題膀藐，經(jīng)過整理算是對正文的補(bǔ)充吧，從互聯(lián)網(wǎng)敏捷數(shù)據(jù)模型等角度做了較深入的細(xì)節(jié)介紹红省。同時在數(shù)據(jù)產(chǎn)品方面的回答包含了一點(diǎn)未來寫作篇“數(shù)據(jù)產(chǎn)品”系列的一點(diǎn)內(nèi)容额各。
1****，傳統(tǒng)我們做BI的吧恃，做數(shù)據(jù)展現(xiàn)會建模后以pivot展現(xiàn)cube數(shù)據(jù)虾啦，不知道現(xiàn)在互聯(lián)網(wǎng)公司數(shù)據(jù)展示如何做的？第三方工具還是用API取數(shù)據(jù)平臺里的數(shù)據(jù)痕寓？adhoc報(bào)表及靈活更換維度的時候web端一般是怎么做的缸逃？
松子老師：剛才文章中提到了比如傳統(tǒng)行業(yè)的多維數(shù)據(jù)模型cube。在互聯(lián)網(wǎng)采用的曲線救國方式解決的厂抽。 在分享中我給出了幾個圖。就是通過搜索引擎曲線救國方式實(shí)現(xiàn)類似Olap的模擬丁眼。
在這塊的模型的處理上采用的是維度退化處理筷凤。通過反規(guī)范化，數(shù)據(jù)項(xiàng)、數(shù)據(jù)冗余去處理藐守。在前端做特殊處理挪丢。
這個當(dāng)時產(chǎn)品原型之一：
(點(diǎn)擊放大圖像)
這是一個2011年-2012年左右的數(shù)據(jù)產(chǎn)品保屯，當(dāng)時算是即時計(jì)算的一種扒最。不過已經(jīng)過去好幾年了，當(dāng)今新技術(shù)下Olap 引擎應(yīng)該有很好的提升壁榕。
目前我知道的家互聯(lián)網(wǎng)公司慎恒，在前端展現(xiàn)有使用第三方套件比如spagoBi任内、pentaho 等 有自己設(shè)計(jì)開發(fā)定制化數(shù)據(jù)前端展現(xiàn)。比如我剛開始分享的那兩個之前在去哪兒網(wǎng)設(shè)計(jì)的數(shù)據(jù)平臺內(nèi)部界面之一融柬，當(dāng)然數(shù)據(jù)產(chǎn)品是另一個話題了死嗦，通過對數(shù)據(jù)分析抽象指標(biāo)、分析模型粒氧、用戶使用功能與流程越除、未來規(guī)劃考慮用戶體驗(yàn)去設(shè)計(jì)。
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
[圖片上傳中外盯。摘盆。。（11）]
(點(diǎn)擊放大圖像)
2****饱苟，互聯(lián)網(wǎng)財(cái)經(jīng)類公司孩擂，業(yè)務(wù)包括財(cái)經(jīng)網(wǎng)站、基金掷空、股票肋殴、金融等，這類公司的數(shù)據(jù)倉庫模型應(yīng)該如何設(shè)計(jì)坦弟？特點(diǎn)和注意事項(xiàng)是什么护锤？案例介紹？十分感謝酿傍。
松子老師：我自己經(jīng)歷過的是互聯(lián)網(wǎng)金融以及移動互聯(lián)網(wǎng)行烙懦。對這兩塊比較清楚〕喑矗互聯(lián)網(wǎng)金融起因?yàn)闃I(yè)務(wù)的特性是類金融類的氯析，與銀行有些地方是相似的。
比如大約在2012年前支付寶業(yè)務(wù)特點(diǎn)涉及類金融交易：充值莺褒、提現(xiàn)掩缓、賬務(wù)管理類電子商務(wù)：購物交易過程變更、實(shí)際交易（對B機(jī)票遵岩、對C水電等） 非純電子商務(wù)你辣；純金融巡通；個人信用，理財(cái)類舍哄。系統(tǒng)之間依賴度較為復(fù)雜宴凉，垂直依賴（業(yè)務(wù)與核心）跨層依賴（跨過交易到賬務(wù)）。
在設(shè)計(jì)方法上還是采用維度模型設(shè)計(jì)方式表悬。底層是數(shù)據(jù)驅(qū)動為向?qū)殖Y(jié)合業(yè)務(wù)需求驅(qū)動益缎，通過簡單驶臊、退化維度的方式拉寬表結(jié)構(gòu)。
底層采用松耦合設(shè)計(jì)芯杀。主題之間是松耦合方式饥追。至體內(nèi)采用細(xì)粒度退化維度图仓。
在主題域上的的設(shè)計(jì)基本參考了OMG的數(shù)據(jù)倉庫元數(shù)據(jù)設(shè)計(jì)CWM模型、IBM 的fsdm金融模型但绕、還有新巴塞爾資本協(xié)議（Basel II Capital Accord）需提供數(shù)據(jù)規(guī)范去的設(shè)計(jì)救崔。所以數(shù)據(jù)模型是五層的結(jié)構(gòu)。
在細(xì)節(jié)處理上捏顺，增量ODS層數(shù)據(jù)和前一天DWD相關(guān)表進(jìn)行 merge處理六孵。
在一些層次上，基本聚合幅骄、匯總增加派生事實(shí)表（簡單一句話退化為度打?qū)挘┙僦稀Ｈ缓蟀凑諛I(yè)務(wù)主體合并信息等。
比如開始給大家分享的那張圖：
(點(diǎn)擊放大圖像)
[圖片上傳中拆座。主巍。。（13）]
在維度模型退化處理時挪凑，要注意最細(xì)粒度數(shù)據(jù)保留孕索、不同層次的數(shù)據(jù)支持?jǐn)?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ù)模型肄渗。
這種元數(shù)據(jù)驅(qū)動工具型數(shù)據(jù)產(chǎn)品我會在未來數(shù)據(jù)產(chǎn)品系列中做詳細(xì)介紹的。
3****咬最，互聯(lián)網(wǎng)企業(yè)大數(shù)據(jù)平臺的發(fā)展歷程是怎樣的翎嫡？
松子老師：這個我相信應(yīng)該是傳統(tǒng)數(shù)據(jù)平臺朋友提到的。傳統(tǒng)行業(yè)數(shù)據(jù)平臺架構(gòu)演進(jìn)我總結(jié)簡單一句話說“基本上可以分為五個時代永乌、四種架構(gòu)”钝的，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與類型暴增的特點(diǎn)翁垂，從高階架構(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é)下來用戶特點(diǎn)：
(點(diǎn)擊放大圖像)
[圖片上傳中。橄妆。衙伶。（14）]
更加詳細(xì)的每一代數(shù)據(jù)平臺建設(shè)、服務(wù)角色特點(diǎn)您可以看我這個系列文章的第三篇害碾，http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-paet02
4****窘哈，有沒有好的元數(shù)據(jù)管理工具推薦叹誉？主要偏向數(shù)據(jù)字典與血統(tǒng)等。
松子老師：元數(shù)據(jù)以前目前沒有太多的好管理工具。以前是在支付寶是我自己設(shè)計(jì)的一個數(shù)據(jù)產(chǎn)品瓜晤。第一版自己用Delphi 開發(fā)的。
（圖很多：）
(點(diǎn)擊放大圖像)
[圖片上傳中士聪。某饰。。（15）]
(點(diǎn)擊放大圖像)
[圖片上傳中剃袍。黄刚。。（16）]
(點(diǎn)擊放大圖像)
[圖片上傳中民效。憔维。。（17）]
(點(diǎn)擊放大圖像)
[圖片上傳中畏邢。业扒。。（18）]
(點(diǎn)擊放大圖像)
[圖片上傳中棵红。凶赁。。（19）]
以前被逼的自己寫了一個逆甜，通過解析虱肄，實(shí)現(xiàn)了字段級的血緣影響分析。這只是第二步交煞，后來又把running 信息給搞了進(jìn)來咏窿。還有分享時提到的模型信息、整個閉環(huán)的分類信息素征。
這是一個分支：
(點(diǎn)擊放大圖像)
[圖片上傳中集嵌。萝挤。。（20）]
但是我們實(shí)現(xiàn)了字段級解析準(zhǔn)確率達(dá)到了94%左右根欧。有細(xì)微的錯誤就人工revew一遍怜珍。
5. ****松子老師，數(shù)據(jù)管控的數(shù)據(jù)質(zhì)量部分是怎么處理的呢凤粗？
松子老師： 數(shù)據(jù)管控酥泛， 這方面我不太懂的，但是數(shù)據(jù)質(zhì)量嫌拣，這玩意可大可小的柔袁。比如像在分享時說過的，在移動互聯(lián)網(wǎng)的數(shù)據(jù)質(zhì)量處理方式可以由原有的ETL(ELT)階段前置到業(yè)務(wù)系統(tǒng)去解決异逐，比如移動互聯(lián)網(wǎng)的App log 日志捶索，日志標(biāo)準(zhǔn)化后事件模型”存儲來解決。那非app 日志類如何解決呢比如Payment灰瞻、order等腥例，數(shù)據(jù)質(zhì)量比較考慮的可以只做到監(jiān)控窃植。
我來分享個圖积蜻。剛好是我設(shè)計(jì)數(shù)據(jù)質(zhì)量產(chǎn)品時搞的，理清數(shù)據(jù)質(zhì)量的問題：
(點(diǎn)擊放大圖像)
[圖片上傳中闲询。袍祖。底瓣。（21）]
(點(diǎn)擊放大圖像)
[圖片上傳中。蕉陋。捐凭。（22）]
(點(diǎn)擊放大圖像)
[圖片上傳中。凳鬓。茁肠。（23）]
只要數(shù)據(jù)進(jìn)入倉庫與應(yīng)用體系，處理起來就比較困難了缩举，所以在數(shù)據(jù)平臺階段最好是通過監(jiān)控垦梆、前置去解決。目前數(shù)據(jù)質(zhì)量確實(shí)難以100%由事后搞到事前去處理仅孩。我對數(shù)據(jù)平臺與數(shù)據(jù)產(chǎn)品的建設(shè)就是實(shí)用為主托猩。怎么實(shí)用怎么來。我是比較現(xiàn)實(shí)的實(shí)用主義者辽慕。
6. ****能否分享一些數(shù)據(jù)產(chǎn)品種類及實(shí)例：
松子老師：在前邊五個問題京腥、以及文章中又都涉及數(shù)據(jù)產(chǎn)品實(shí)力的一些分享。
提到數(shù)據(jù)產(chǎn)品的分類我就想把這個圖發(fā)出來溅蛉。
自己認(rèn)為沒有特別明確的劃分線公浪，但是數(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工具卫旱、資源管控等等。
面向用戶功能有報(bào)表型围段、多維型數(shù)據(jù)產(chǎn)品顾翼、定制化數(shù)據(jù)產(chǎn)品、挖掘型數(shù)據(jù)產(chǎn)品奈泪。
面向內(nèi)部用戶适贸、外部個人用戶、外部企業(yè)用戶又有不同的分類涝桅。
根據(jù)業(yè)務(wù)又可以劃分很多拜姿，面向C類用戶、面向B類商戶冯遂、金融風(fēng)險(xiǎn)等等
從近幾年的數(shù)據(jù)產(chǎn)品來看蝌数，是更好的輔助用戶的做決策的一種產(chǎn)品形態(tài)慨代，在用戶的決策與行動中充當(dāng)信息的分析者與價值使用者；數(shù)據(jù)產(chǎn)品有個自己的共性：由解決的一個實(shí)際的業(yè)務(wù)問題出發(fā)，分解出的分析指標(biāo)语卤，分析模型，分析流程組成脚乡，再考慮到功能易用性柜思，未來功能擴(kuò)展，考慮用戶對數(shù)據(jù)易用性（比如數(shù)據(jù)的呈現(xiàn)層次炒俱，不可能一次把所有數(shù)據(jù)的呈現(xiàn)給用戶）來組成的盐肃。
(點(diǎn)擊放大圖像)
[圖片上傳中。权悟。砸王。（24）]
7. ****銀行業(yè)從傳統(tǒng)的ods到edw再到大數(shù)據(jù)平臺這塊過渡，模型如何建設(shè)僵芹？平臺優(yōu)勢如何發(fā)揮处硬？
松子老師：這個問題還是有些難度的，自己回答的可能有些片面拇派。首先我們清醒的清楚“大數(shù)據(jù)”是什么荷辕？再次不同的場景可以采用不同的技術(shù)去解決凿跳。
“大數(shù)據(jù)”，拆開來看大疮方、數(shù)據(jù)控嗜，大可以是指的數(shù)據(jù)源結(jié)構(gòu)簡單（ps 如果了解過當(dāng)代對大數(shù)據(jù)的定義就知道四個特性）但是量級夠大，比如清算骡显、結(jié)算疆栏、對公、對私惫谤、中間業(yè)務(wù)等等每一個拿出來都是幾十T壁顶，但是這些業(yè)務(wù)數(shù)據(jù)都是保存?zhèn)鹘y(tǒng)的關(guān)系型數(shù)據(jù)庫中如DB2、Oracle溜歪、MSsql中若专，因?yàn)樵跀?shù)據(jù)平臺存儲是通過準(zhǔn)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ù)的去演進(jìn)解決嚎莉。（最早時我的是中信銀行、光大銀行在2011年左右開始考慮Hadoop技術(shù)沛豌，后來不知道如何了）趋箩。
但是互聯(lián)網(wǎng)的數(shù)據(jù)平臺技術(shù)大都是NOSQL模式，犧牲掉了傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)一致性琼懊、完整性阁簸、唯一索引等等道盏，只干性能的事情（當(dāng)然除了性能吆寨、可擴(kuò)展性也是的）.
原有在傳統(tǒng)數(shù)據(jù)平臺模型設(shè)計(jì)上可以考慮的一些通過主外鍵、唯一索引做一些業(yè)務(wù)約束的方法托修，在nosql上統(tǒng)統(tǒng)的都沒有了醉旦，這些約束必須放到數(shù)據(jù)加工階段去想辦法做檢查饶米。傳統(tǒng)數(shù)據(jù)平臺如果在Insert、update數(shù)據(jù)時違反了業(yè)務(wù)約束可以做報(bào)警或異常處理车胡，但是在Nosql的平臺上要求ETL 去手動遵守這些規(guī)則檢查檬输。但是有時ETL開發(fā)根本不遵守的，僅僅是兩個表關(guān)聯(lián)起來匈棘，也可能忘記按照某一個業(yè)務(wù)唯一索引做去重操作丧慈。簡單說，原有靠關(guān)系型數(shù)據(jù)庫本身機(jī)制去做檢查一些規(guī)則變?yōu)槿斯ぃ優(yōu)槿斯ぞ蜁稿e逃默。
從關(guān)系型數(shù)據(jù)平臺往Nosql數(shù)據(jù)平臺遷移時鹃愤，尤其是對傳統(tǒng)行業(yè)的業(yè)務(wù)來說，在模型設(shè)計(jì)階段完域、以及給出的ETL口徑要考慮更多的業(yè)務(wù)規(guī)則檢查软吐，其次要考慮更多的維度退化、多冗余吟税、表打?qū)捥幚戆及摇：唵握f就是發(fā)揮數(shù)據(jù)平臺的計(jì)算能力同時要更加的各方面確保數(shù)據(jù)準(zhǔn)確安全可靠。
數(shù)據(jù)模型ODS 到EDW 這塊的設(shè)計(jì)方法百度上留下的文檔資料太多的了肠仪，請這位提問的老師百度吧肖抱。
**8****．大數(shù)據(jù)****倉庫****中如何做快速****維處****理？互****聯(lián)****網(wǎng)數(shù)****倉****數(shù)據(jù)****質(zhì)****量不好如何****對****數(shù)异旧，如何確立****標(biāo)****準(zhǔn)的****對****數(shù)口徑虐沥？******
松子老師：快速變化維度可以轉(zhuǎn)化為緩慢變化為來出來，我自己理解的快速維度是相對于緩慢維度參照的來說的泽艘。
舉個例子，年齡-轉(zhuǎn)化為天數(shù)可以是定義快速變化維度镐依，因?yàn)槊刻於荚谧兓ヤ獭Ｎ覀兛梢园涯挲g退化為區(qū)間維度來處理，還可以把年齡做成動態(tài)維度來處理槐壳，事實(shí)表中保存的就是實(shí)際的出生年月并打?qū)挶砣坏停挲g(天)通過計(jì)算方式來處理。還有種方法通過對代理鍵的方式來處理务唐。
我目前也不知道對數(shù)據(jù)的標(biāo)準(zhǔn)是什么雳攘。但是我自己用的方法，把一個指標(biāo)的整個數(shù)據(jù)流向切出幾個關(guān)鍵點(diǎn)通過SQL去實(shí)現(xiàn)對數(shù)枫笛，看波動振幅吨灭，波動曲線。同時還會比如發(fā)不通的版本的小流量測試的方式來做數(shù)據(jù)校對刑巧。
9****． 做為數(shù)據(jù)行業(yè)從業(yè)者，需要掌握哪些重要的基礎(chǔ)知識？另：如果從零開始建立一個數(shù)據(jù)平臺闽寡，需要哪些資源配置（人电谣，財(cái)，物恭理，技術(shù)）拯辙？大致總投資額度多少？如果同行產(chǎn)品間多種來源的數(shù)據(jù)颜价，可有成熟的解決方案涯保？謝謝…
松子老師：這個問題太宏觀了诉濒。作為數(shù)據(jù)行業(yè)從業(yè)者，需要掌握哪些重要基礎(chǔ)知識遭赂，這個是要看從事具體數(shù)據(jù)域的垂直行業(yè)循诉。
比如說 數(shù)據(jù)開發(fā)、數(shù)據(jù)模型撇他、數(shù)據(jù)產(chǎn)品茄猫、數(shù)據(jù)分析師、數(shù)據(jù)運(yùn)營困肩、數(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ù)目標(biāo)不太明確下，難以確定方案盆犁，人員配置上選用不同技術(shù)方案去搭建的配置是不太一樣的命咐，比如說傳統(tǒng)平臺來講，運(yùn)維谐岁、DBA醋奠、數(shù)據(jù)開發(fā)、數(shù)據(jù)模型伊佃、報(bào)表人員窜司。
從互聯(lián)網(wǎng)數(shù)據(jù)平臺基本配置上，數(shù)據(jù)架構(gòu)師航揉、運(yùn)維塞祈、底層大數(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ù)猎荠。
10. Standalone****模式下，Model.save(Path)怎么一直提示錯誤，是不是配置Spark時需要將Hdfs的配置引進(jìn)來啊～？表示初學(xué)Spark
松子老師：這個問題有點(diǎn)超出我的能力范圍了衷笋，所以對不起回答不了。
我本身不是做技術(shù)的矩屁。僅知道一點(diǎn)技術(shù)名詞辟宗。
11. ****傳統(tǒng)銀行業(yè)數(shù)據(jù)模型什么時候會走向互聯(lián)網(wǎng)模式呢？目前在傳統(tǒng)銀行數(shù)據(jù)平臺的產(chǎn)品是不是特別多吝秕？
松子老師：這個問題我自己就不知道了泊脐，或許是傳統(tǒng)銀行在數(shù)據(jù)平臺的實(shí)施上全面用互聯(lián)網(wǎng)的Nosql大數(shù)據(jù)處理技術(shù)吧。至于說傳統(tǒng)銀行數(shù)據(jù)模型用現(xiàn)有的互聯(lián)網(wǎng)數(shù)據(jù)模型理念去設(shè)計(jì)是否完全可行烁峭，數(shù)據(jù)一致性容客、高準(zhǔn)確性通過更多的方案去保證。
首先我需要確定一下這個產(chǎn)品是否指的“數(shù)據(jù)產(chǎn)品”约郁。
如果是數(shù)據(jù)產(chǎn)品缩挑，那其實(shí)傳統(tǒng)行業(yè)數(shù)據(jù)平臺本身就有一些數(shù)據(jù)產(chǎn)品了，而且也都是存在的鬓梅。數(shù)據(jù)產(chǎn)品自從數(shù)據(jù)倉庫出現(xiàn)以來它其實(shí)一直都存在的调煎，只不過是近幾年因?yàn)榛ヂ?lián)網(wǎng)特別愛制造“流行詞“把數(shù)據(jù)產(chǎn)品這個詞給放大了〖喊梗互聯(lián)網(wǎng)是得數(shù)據(jù)產(chǎn)品從早期的重量級逐漸進(jìn)化為輕量級、從大而全的解決方案逐漸演進(jìn)為因小而美悲关。
我來給出幾組例子谎僻，大約從2004年到現(xiàn)在的幾組數(shù)據(jù)產(chǎn)品的例子
(點(diǎn)擊放大圖像)
[圖片上傳中。寓辱。艘绍。（25）]
(點(diǎn)擊放大圖像)
[圖片上傳中。秫筏。诱鞠。（26）]
(點(diǎn)擊放大圖像)
[圖片上傳中。这敬。航夺。（27）]
(點(diǎn)擊放大圖像)
[圖片上傳中。崔涂。阳掐。（28）]
(點(diǎn)擊放大圖像)
[圖片上傳中。。缭保。（29）]
(點(diǎn)擊放大圖像)
[圖片上傳中汛闸。侈净。齐婴。（30）]
(點(diǎn)擊放大圖像)
[圖片上傳中。宗雇。钳恕。（31）]
你可以分類一下别伏，這些數(shù)據(jù)產(chǎn)品的特點(diǎn)是什么？滿足了用戶怎么樣的痛點(diǎn)需求苞尝？滿足了用戶怎么樣的使用流程畸肆。
12 ****。傳統(tǒng)行業(yè)的數(shù)據(jù)倉庫從業(yè)人員宙址，如果轉(zhuǎn)到互聯(lián)網(wǎng)行業(yè)轴脐，應(yīng)該學(xué)習(xí)哪些技能？
松子老師：這個問題你可以百度搜索“大數(shù)據(jù)職位所需要的數(shù)據(jù)技能” http://blog.jobbole.com/99039/ 這篇文章抡砂。自己覺得人家回答的比我專業(yè)大咱。//
我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史（四）：互聯(lián)網(wǎng)時代 ? 下篇
http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-internet-age
編者按：本文是松子（李博源）的大數(shù)據(jù)平臺發(fā)展史系列文章的第四篇（共四篇），本系列以獨(dú)特的視角注益，比較了非互聯(lián)網(wǎng)和互聯(lián)網(wǎng)兩個時代以及傳統(tǒng)行業(yè)與非傳統(tǒng)行業(yè)碴巾。是對數(shù)據(jù)平臺發(fā)展的一個回憶，對非互聯(lián)網(wǎng)丑搔、互聯(lián)網(wǎng)厦瓢，從數(shù)據(jù)平臺的用戶角度、數(shù)據(jù)架構(gòu)演進(jìn)啤月、模型等進(jìn)行了闡述煮仇。
在互聯(lián)網(wǎng)時代被弱化的數(shù)據(jù)模型
談起數(shù)據(jù)模型就不得不提傳統(tǒng)數(shù)據(jù)平臺架構(gòu)發(fā)展，我相信很多朋友都曉得傳統(tǒng)數(shù)據(jù)平臺的知識谎仲，其架構(gòu)演進(jìn)簡單一句話說“基本上可以分為五個時代浙垫、四種架構(gòu)”，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與數(shù)據(jù)源類型多樣化特點(diǎn)郑诺，從高階架構(gòu)上來看大約從傳統(tǒng)數(shù)據(jù)平臺第三代架構(gòu)開始延續(xù)的夹姥，但是往后的發(fā)展從我自己的這一點(diǎn)知識上很難對互聯(lián)網(wǎng)的數(shù)據(jù)平臺做架構(gòu)歸類。
但是從數(shù)據(jù)平臺建設(shè)與服務(wù)角色上還是有章可循的辙诞。就像上篇分享到那樣辙售，類比兩個行業(yè)，互聯(lián)網(wǎng)企業(yè)中員工年齡比非互聯(lián)網(wǎng)企業(yè)的要年輕飞涂、受教育程度圾亏、對計(jì)算機(jī)的焦慮程度明顯比傳統(tǒng)企業(yè)要低十拣、還偶遇其它各方面的緣故，導(dǎo)致了數(shù)據(jù)平臺所面對用戶群體與非互聯(lián)網(wǎng)數(shù)據(jù)平臺有所差異化志鹃。
傳統(tǒng)行業(yè)與互聯(lián)網(wǎng)行業(yè)數(shù)據(jù)平臺用戶特性我只選擇前文章的兩張圖來表示
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
在傳統(tǒng)數(shù)據(jù)平臺要背后有一個完整數(shù)據(jù)倉庫團(tuán)隊(duì)去服務(wù)業(yè)務(wù)方夭问，業(yè)務(wù)方嗷嗷待哺的等待被動方式去滿足。中低層數(shù)據(jù)基本不會對業(yè)務(wù)方開放曹铃，所以不管數(shù)據(jù)模型采用何種建模方式缰趋，主要滿足當(dāng)時數(shù)據(jù)架構(gòu)規(guī)劃即可。
互聯(lián)網(wǎng)業(yè)務(wù)的快速發(fā)展使得大家已經(jīng)從經(jīng)營、分析的訴求重點(diǎn)轉(zhuǎn)為數(shù)據(jù)化的精細(xì)運(yùn)營上，如何做好精細(xì)化運(yùn)營問題上來奶卓，當(dāng)資源不夠時用戶就叫喊，甚至有的業(yè)務(wù)方會挽起袖子來自己參與到從數(shù)據(jù)整理灰粮、加工、分析階段忍坷。
此時呢粘舟，原有建設(shè)數(shù)據(jù)平臺的多個角色（數(shù)據(jù)開發(fā)、模型設(shè)計(jì)）可能轉(zhuǎn)為對其它非專業(yè)使用數(shù)據(jù)方佩研，做培訓(xùn)柑肴、咨詢與落地，寫更加適合當(dāng)前企業(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àn)椴粚I(yè)性绊序，導(dǎo)致數(shù)據(jù)質(zhì)量問題硕舆、重復(fù)對分?jǐn)?shù)據(jù)浪費(fèi)存儲與資源、口徑多樣化骤公、編碼不統(tǒng)一岗宣、命名問題等等原因。數(shù)據(jù)質(zhì)量逐漸變成一個特別突出的問題淋样。
傳統(tǒng)企業(yè)的數(shù)據(jù)源基本來自excel、表格胁住、DB系統(tǒng)等趁猴，但在互聯(lián)網(wǎng)有網(wǎng)站點(diǎn)擊流日志、視頻彪见、音頻儡司、圖片數(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ù)有些力不從心碉碉。
當(dāng)數(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è)也有自己特點(diǎn)元潘，傳統(tǒng)行業(yè)所涉及數(shù)據(jù)模型這個領(lǐng)域涉及的很多內(nèi)容在互聯(lián)網(wǎng)變成以其他的曲線救國的方式存在了。
在互聯(lián)網(wǎng)曲線救國新解決
回顧在傳統(tǒng)行業(yè)數(shù)據(jù)平臺中君仆，不管兩位大師爭論點(diǎn)數(shù)據(jù)模型的設(shè)計(jì)采用那種范式（Bill Inmon的EDW的原則是準(zhǔn)三范式的設(shè)計(jì)甚纲、Ralph kilmbal是星型結(jié)構(gòu)）但是都要非常重視數(shù)據(jù)源的質(zhì)量問題痰腮。所以傳統(tǒng)行業(yè)的數(shù)據(jù)模型會全盤考慮數(shù)據(jù)質(zhì)量問題，并通過數(shù)據(jù)抽樣分析給出合適的清洗口徑。
(點(diǎn)擊放大圖像)
上圖來自我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ù)”對一年的還是不準(zhǔn)的）。在應(yīng)對數(shù)據(jù)的質(zhì)量問題楞艾，目前互聯(lián)網(wǎng)有些做法是把數(shù)據(jù)標(biāo)準(zhǔn)化前置到業(yè)務(wù)數(shù)據(jù)產(chǎn)生就做参咙，從根源上去杜絕數(shù)據(jù)質(zhì)量，但是這種場景比較實(shí)用在Log 日志的數(shù)據(jù)源中硫眯，比如移動互聯(lián)網(wǎng)最近流行的基于事件模型“Event”模型蕴侧，在日志產(chǎn)生時就規(guī)定好存儲格式（備注：大家度娘搜索，“學(xué)習(xí)筆記：The Log（我所讀過的最好的一篇分布式技術(shù)文章）” 對這個講解很詳細(xì)）两入。
在傳統(tǒng)行業(yè)净宵，目前還是以混合模型設(shè)計(jì)方式為主。在互聯(lián)網(wǎng)的我所接觸的一些業(yè)務(wù)裹纳，在參照傳統(tǒng)數(shù)據(jù)模型方法論基礎(chǔ)上逐步演進(jìn)適合互聯(lián)網(wǎng)數(shù)據(jù)的數(shù)據(jù)模型方法择葡。
比如互聯(lián)網(wǎng)金融等一些業(yè)務(wù)會參考傳統(tǒng)金融行業(yè)對主題域的劃分、OMG數(shù)據(jù)倉庫元數(shù)據(jù)管理CWM模型剃氧、FSDM金融模型敏储，再進(jìn)一步考慮大數(shù)據(jù)處理特性去進(jìn)行設(shè)計(jì)，所有從Hight Level 數(shù)據(jù)架構(gòu)圖看到主題層次劃分與傳統(tǒng)第三代數(shù)據(jù)倉庫還是很多相似之處朋鞍，當(dāng)然模型架構(gòu)也有分三層已添、四層妥箕、五層的。
不同的地方模型細(xì)節(jié)處理上已經(jīng)完全不一樣更舞，比如數(shù)據(jù)的多樣性畦幢、拉寬事實(shí)表、度量值單獨(dú)存儲疏哗、滿足數(shù)據(jù)快速重生呛讲、維度的二次降維處理等、增加大量冗余列返奉、增加大量派生列贝搁，結(jié)合自動化元數(shù)據(jù)來耦合、合并等相關(guān)管理芽偏。
(點(diǎn)擊放大圖像)
[圖片上傳中雷逆。。污尉。（4）]
上圖是支付寶非常早期數(shù)據(jù)模型
(點(diǎn)擊放大圖像)
上圖是支付寶非常早期數(shù)據(jù)模型
我們常提到的多維模型在大數(shù)據(jù)處理下進(jìn)行了退化維度處理膀哲。大家知道Olap多維模型，隨著維度的增加事實(shí)表的數(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è)計(jì)多維挖掘分析數(shù)據(jù)產(chǎn)品背后的技術(shù)就是搜索引擎實(shí)現(xiàn)的）皆串，現(xiàn)在應(yīng)該也有新技術(shù)出現(xiàn)了來解決類似的問題。
(點(diǎn)擊放大圖像)
上圖為2012年產(chǎn)品UI之一蒙幻。
(點(diǎn)擊放大圖像)
[圖片上傳中焚志。衣迷。。（7）]
上圖是2011-2012年該產(chǎn)品系列背后當(dāng)時使用的技術(shù)
互聯(lián)網(wǎng)業(yè)務(wù)特點(diǎn)業(yè)務(wù)垂直拆分非常細(xì)酱酬，比如一個用戶注冊壶谒、密碼找回的流程有可能存在好幾個產(chǎn)品負(fù)責(zé)同一個業(yè)務(wù)流程不同環(huán)節(jié)，相關(guān)的一個策略膳沽、產(chǎn)品feature快速迭代上線等等都要數(shù)據(jù)評估汗菜。數(shù)據(jù)從前端埋點(diǎn)到采集然后再由各個環(huán)節(jié)到數(shù)據(jù)平臺，再有數(shù)據(jù)分析師或各業(yè)務(wù)部門去使用挑社，基本拉長了時間周期陨界。需求部門與實(shí)施部門能力和經(jīng)驗(yàn)有千差萬別的需求，造成了懂技術(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ù)特點(diǎn)是變化非常迅速的动猬，能穩(wěn)定的業(yè)務(wù)達(dá)到65%算對數(shù)據(jù)平臺是個福音了（根據(jù)對某寶寶的印象）剩余的業(yè)務(wù)變化迅速，必然導(dǎo)致數(shù)據(jù)模型快速上下線表箭。
Kimball老人家提出的維度建模（備注赁咙，在本系列發(fā)展史得第一篇有介紹）圍繞業(yè)務(wù)模型能夠非常直觀的表達(dá)出業(yè)務(wù)的數(shù)據(jù)關(guān)系，但是在互聯(lián)網(wǎng)NOSQL犧牲掉了關(guān)系型數(shù)據(jù)庫的一致性免钻、完整性等等很多東西彼水。維度數(shù)據(jù)模型又基于這些大數(shù)據(jù)技術(shù)的，所以進(jìn)化的更加輕量級與基于細(xì)節(jié)數(shù)據(jù)的維度退化建模（原有的緩慢變化維极舔、快速變化維凤覆、大維、迷你維拆魏、父子維盯桦、雪花維為了適應(yīng)互聯(lián)網(wǎng)的大數(shù)據(jù)Nosql處理技術(shù)進(jìn)行反規(guī)范化、化&數(shù)據(jù)冗余設(shè)計(jì)渤刃。
退化維度的反規(guī)范化設(shè)計(jì)一方面可以把一條查詢語句所需要的所有數(shù)據(jù)組合起來放到一個地方存儲 Key values 的方式（比如說商品有不同類型拥峦，每一種類型商品又有自己的不同屬性，可以采用一對多卖子、多對多的方式存儲略号，例如把一個多維映射為一個Key value）。
講到互聯(lián)網(wǎng)數(shù)據(jù)平臺就要提數(shù)據(jù)模型揪胃，提了數(shù)據(jù)模型就要提Nosql技術(shù)翔忽，
(點(diǎn)擊放大圖像)
上圖來自Nosql文檔系列的一幅圖
Nosql 是大數(shù)據(jù)處理的特征之一闪水。互聯(lián)網(wǎng)數(shù)據(jù)平臺數(shù)據(jù)模型與NoSql技術(shù)還是蠻緊密的。這里有外文講解Nosql Data modeling technigues 從技術(shù)角度講解非常詳（https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/）乍丈。
因?yàn)榍斑吿岬降拇髷?shù)據(jù)平臺技術(shù)特性決定了傳統(tǒng)edw模型、維度模型直接在互聯(lián)網(wǎng)數(shù)據(jù)大數(shù)據(jù)平臺部署或許還有“好些未知”障礙等待大家去克服虹茶。同時在傳統(tǒng)數(shù)據(jù)建模用到的一些方法經(jīng)過互聯(lián)網(wǎng)熏陶或許演進(jìn)成一種新的數(shù)據(jù)產(chǎn)品或方案吧疑故。
到此為止“我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史”上下共四篇與大家分享完畢，這個寫作前后經(jīng)歷剛好一個月左右俏讹，算是對自己數(shù)據(jù)從業(yè)經(jīng)歷回顧之一吧当宴。在知識的整理中很多都是蜻蜓點(diǎn)水，每個知識域都是一個非常深的專業(yè)方向泽疆，自己涉足很膚淺户矢，在文章中分享不足之處請各位讀者見諒！殉疼！
個人郵箱是5592094@qq.com 歡迎電郵交流梯浪。
接下來我會進(jìn)入數(shù)據(jù)產(chǎn)品這個領(lǐng)域的分享捌年，當(dāng)年車品覺老師自豪的作品之一“黃金策”，我是數(shù)據(jù)產(chǎn)品經(jīng)理挂洛。（ps：自己躲在墻角拿車品覺老師往自己臉上貼金了）礼预。
后記
有一次數(shù)據(jù)產(chǎn)品神策的創(chuàng)始人兼好友@桑文鋒＠SensorsData跟我說來做次分享吧，我當(dāng)時出了幾個題目虏劲，最后就選擇了“我所經(jīng)歷的大數(shù)據(jù)平臺“托酸，就形成了大家看到的”我所經(jīng)歷的大數(shù)據(jù)平臺“系列文章.
在整理期間得到了死黨@周愛民、@神策-桑文峰柒巫、 InfoQ小編@Tina Du 励堡、@betty zhou @Laurel大力協(xié)助，在這里感謝Ｎ怯Ｄ钛怼！
番外篇
這一篇是在24日舉行的分享大家提到的一些問題布疼，經(jīng)過整理算是對正文的補(bǔ)充吧摊趾，從互聯(lián)網(wǎng)敏捷數(shù)據(jù)模型等角度做了較深入的細(xì)節(jié)介紹。同時在數(shù)據(jù)產(chǎn)品方面的回答包含了一點(diǎn)未來寫作篇“數(shù)據(jù)產(chǎn)品”系列的一點(diǎn)內(nèi)容游两。
1****砾层，傳統(tǒng)我們做BI的，做數(shù)據(jù)展現(xiàn)會建模后以pivot展現(xiàn)cube數(shù)據(jù)贱案，不知道現(xiàn)在互聯(lián)網(wǎng)公司數(shù)據(jù)展示如何做的肛炮？第三方工具還是用API取數(shù)據(jù)平臺里的數(shù)據(jù)？adhoc報(bào)表及靈活更換維度的時候web端一般是怎么做的宝踪？
松子老師：剛才文章中提到了比如傳統(tǒng)行業(yè)的多維數(shù)據(jù)模型cube侨糟。在互聯(lián)網(wǎng)采用的曲線救國方式解決的。 在分享中我給出了幾個圖瘩燥。就是通過搜索引擎曲線救國方式實(shí)現(xiàn)類似Olap的模擬秕重。
在這塊的模型的處理上采用的是維度退化處理纺讲。通過反規(guī)范化婿着，數(shù)據(jù)項(xiàng)、數(shù)據(jù)冗余去處理鼻忠。在前端做特殊處理服鹅。
這個當(dāng)時產(chǎn)品原型之一：
(點(diǎn)擊放大圖像)
這是一個2011年-2012年左右的數(shù)據(jù)產(chǎn)品凳兵，當(dāng)時算是即時計(jì)算的一種。不過已經(jīng)過去好幾年了企软，當(dāng)今新技術(shù)下Olap 引擎應(yīng)該有很好的提升庐扫。
目前我知道的家互聯(lián)網(wǎng)公司，在前端展現(xiàn)有使用第三方套件比如spagoBi、pentaho 等 有自己設(shè)計(jì)開發(fā)定制化數(shù)據(jù)前端展現(xiàn)形庭。比如我剛開始分享的那兩個之前在去哪兒網(wǎng)設(shè)計(jì)的數(shù)據(jù)平臺內(nèi)部界面之一杰妓，當(dāng)然數(shù)據(jù)產(chǎn)品是另一個話題了，通過對數(shù)據(jù)分析抽象指標(biāo)碘勉、分析模型、用戶使用功能與流程桩卵、未來規(guī)劃考慮用戶體驗(yàn)去設(shè)計(jì)验靡。
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
[圖片上傳中。雏节。胜嗓。（11）]
(點(diǎn)擊放大圖像)
2****，互聯(lián)網(wǎng)財(cái)經(jīng)類公司钩乍，業(yè)務(wù)包括財(cái)經(jīng)網(wǎng)站辞州、基金、股票寥粹、金融等变过，這類公司的數(shù)據(jù)倉庫模型應(yīng)該如何設(shè)計(jì)？特點(diǎn)和注意事項(xiàng)是什么涝涤？案例介紹媚狰？十分感謝。
松子老師：我自己經(jīng)歷過的是互聯(lián)網(wǎng)金融以及移動互聯(lián)網(wǎng)行阔拳。對這兩塊比較清楚崭孤。互聯(lián)網(wǎng)金融起因?yàn)闃I(yè)務(wù)的特性是類金融類的糊肠，與銀行有些地方是相似的辨宠。
比如大約在2012年前支付寶業(yè)務(wù)特點(diǎn)涉及類金融交易：充值、提現(xiàn)货裹、賬務(wù)管理類電子商務(wù)：購物交易過程變更嗤形、實(shí)際交易（對B機(jī)票、對C水電等） 非純電子商務(wù)泪酱；純金融派殷；個人信用，理財(cái)類墓阀。系統(tǒng)之間依賴度較為復(fù)雜毡惜，垂直依賴（業(yè)務(wù)與核心）跨層依賴（跨過交易到賬務(wù)）未舟。
在設(shè)計(jì)方法上還是采用維度模型設(shè)計(jì)方式浇揩。底層是數(shù)據(jù)驅(qū)動為向?qū)ВY(jié)合業(yè)務(wù)需求驅(qū)動嗓节，通過簡單、退化維度的方式拉寬表結(jié)構(gòu)帕膜。
底層采用松耦合設(shè)計(jì)枣氧。主題之間是松耦合方式。至體內(nèi)采用細(xì)粒度退化維度垮刹。
在主題域上的的設(shè)計(jì)基本參考了OMG的數(shù)據(jù)倉庫元數(shù)據(jù)設(shè)計(jì)CWM模型达吞、IBM 的fsdm金融模型、還有新巴塞爾資本協(xié)議（Basel II Capital Accord）需提供數(shù)據(jù)規(guī)范去的設(shè)計(jì)荒典。所以數(shù)據(jù)模型是五層的結(jié)構(gòu)酪劫。
在細(xì)節(jié)處理上，增量ODS層數(shù)據(jù)和前一天DWD相關(guān)表進(jìn)行 merge處理寺董。
在一些層次上覆糟，基本聚合、匯總增加派生事實(shí)表（簡單一句話退化為度打?qū)挘┱诳АＨ缓蟀凑諛I(yè)務(wù)主體合并信息等滩字。
比如開始給大家分享的那張圖：
(點(diǎn)擊放大圖像)
[圖片上傳中。御吞。麦箍。（13）]
在維度模型退化處理時，要注意最細(xì)粒度數(shù)據(jù)保留陶珠、不同層次的數(shù)據(jù)支持?jǐn)?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ù)模型寝姿。
這種元數(shù)據(jù)驅(qū)動工具型數(shù)據(jù)產(chǎn)品我會在未來數(shù)據(jù)產(chǎn)品系列中做詳細(xì)介紹的交排。
3****，互聯(lián)網(wǎng)企業(yè)大數(shù)據(jù)平臺的發(fā)展歷程是怎樣的饵筑？
松子老師：這個我相信應(yīng)該是傳統(tǒng)數(shù)據(jù)平臺朋友提到的埃篓。傳統(tǒng)行業(yè)數(shù)據(jù)平臺架構(gòu)演進(jìn)我總結(jié)簡單一句話說“基本上可以分為五個時代、四種架構(gòu)”根资，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與類型暴增的特點(diǎn)架专，從高階架構(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é)下來用戶特點(diǎn)：
(點(diǎn)擊放大圖像)
[圖片上傳中委刘。。。（14）]
更加詳細(xì)的每一代數(shù)據(jù)平臺建設(shè)锡移、服務(wù)角色特點(diǎn)您可以看我這個系列文章的第三篇扇住，http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-paet02
4****技潘，有沒有好的元數(shù)據(jù)管理工具推薦？主要偏向數(shù)據(jù)字典與血統(tǒng)等畏线。
松子老師：元數(shù)據(jù)以前目前沒有太多的好管理工具冯键。以前是在支付寶是我自己設(shè)計(jì)的一個數(shù)據(jù)產(chǎn)品沥寥。第一版自己用Delphi 開發(fā)的与境。
（圖很多：）
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
[圖片上傳中吟榴。。操刀。（16）]
(點(diǎn)擊放大圖像)
[圖片上傳中。婴洼。骨坑。（17）]
(點(diǎn)擊放大圖像)
[圖片上傳中。柬采。欢唾。（18）]
(點(diǎn)擊放大圖像)
[圖片上傳中。粉捻。礁遣。（19）]
以前被逼的自己寫了一個，通過解析肩刃，實(shí)現(xiàn)了字段級的血緣影響分析祟霍。這只是第二步，后來又把running 信息給搞了進(jìn)來盈包。還有分享時提到的模型信息沸呐、整個閉環(huán)的分類信息。
這是一個分支：
(點(diǎn)擊放大圖像)
[圖片上傳中呢燥。崭添。。（20）]
但是我們實(shí)現(xiàn)了字段級解析準(zhǔn)確率達(dá)到了94%左右叛氨。有細(xì)微的錯誤就人工revew一遍呼渣。
5. ****松子老師，數(shù)據(jù)管控的數(shù)據(jù)質(zhì)量部分是怎么處理的呢寞埠？
松子老師： 數(shù)據(jù)管控屁置， 這方面我不太懂的，但是數(shù)據(jù)質(zhì)量仁连，這玩意可大可小的缰犁。比如像在分享時說過的，在移動互聯(lián)網(wǎng)的數(shù)據(jù)質(zhì)量處理方式可以由原有的ETL(ELT)階段前置到業(yè)務(wù)系統(tǒng)去解決，比如移動互聯(lián)網(wǎng)的App log 日志帅容，日志標(biāo)準(zhǔn)化后事件模型”存儲來解決颇象。那非app 日志類如何解決呢比如Payment、order等并徘，數(shù)據(jù)質(zhì)量比較考慮的可以只做到監(jiān)控遣钳。
我來分享個圖袍镀。剛好是我設(shè)計(jì)數(shù)據(jù)質(zhì)量產(chǎn)品時搞的境肾，理清數(shù)據(jù)質(zhì)量的問題：
(點(diǎn)擊放大圖像)
[圖片上傳中。董饰。姐直。（21）]
(點(diǎn)擊放大圖像)
[圖片上傳中倦淀。。声畏。（22）]
(點(diǎn)擊放大圖像)
[圖片上傳中撞叽。。插龄。（23）]
只要數(shù)據(jù)進(jìn)入倉庫與應(yīng)用體系愿棋，處理起來就比較困難了，所以在數(shù)據(jù)平臺階段最好是通過監(jiān)控均牢、前置去解決糠雨。目前數(shù)據(jù)質(zhì)量確實(shí)難以100%由事后搞到事前去處理。我對數(shù)據(jù)平臺與數(shù)據(jù)產(chǎn)品的建設(shè)就是實(shí)用為主徘跪。怎么實(shí)用怎么來甘邀。我是比較現(xiàn)實(shí)的實(shí)用主義者。
6. ****能否分享一些數(shù)據(jù)產(chǎn)品種類及實(shí)例：
松子老師：在前邊五個問題垮庐、以及文章中又都涉及數(shù)據(jù)產(chǎn)品實(shí)力的一些分享鹃答。
提到數(shù)據(jù)產(chǎn)品的分類我就想把這個圖發(fā)出來。
自己認(rèn)為沒有特別明確的劃分線突硝，但是數(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工具腐宋、資源管控等等紊服。
面向用戶功能有報(bào)表型檀轨、多維型數(shù)據(jù)產(chǎn)品、定制化數(shù)據(jù)產(chǎn)品欺嗤、挖掘型數(shù)據(jù)產(chǎn)品参萄。
面向內(nèi)部用戶、外部個人用戶煎饼、外部企業(yè)用戶又有不同的分類讹挎。
根據(jù)業(yè)務(wù)又可以劃分很多，面向C類用戶吆玖、面向B類商戶筒溃、金融風(fēng)險(xiǎn)等等
從近幾年的數(shù)據(jù)產(chǎn)品來看，是更好的輔助用戶的做決策的一種產(chǎn)品形態(tài)沾乘，在用戶的決策與行動中充當(dāng)信息的分析者與價值使用者晚缩；數(shù)據(jù)產(chǎn)品有個自己的共性：由解決的一個實(shí)際的業(yè)務(wù)問題出發(fā)股冗，分解出的分析指標(biāo)档礁，分析模型算色，分析流程組成，再考慮到功能易用性怎顾，未來功能擴(kuò)展，考慮用戶對數(shù)據(jù)易用性（比如數(shù)據(jù)的呈現(xiàn)層次漱贱，不可能一次把所有數(shù)據(jù)的呈現(xiàn)給用戶）來組成的槐雾。
(點(diǎn)擊放大圖像)
[圖片上傳中。幅狮。募强。（24）]
7. ****銀行業(yè)從傳統(tǒng)的ods到edw再到大數(shù)據(jù)平臺這塊過渡，模型如何建設(shè)崇摄？平臺優(yōu)勢如何發(fā)揮擎值？
松子老師：這個問題還是有些難度的，自己回答的可能有些片面逐抑。首先我們清醒的清楚“大數(shù)據(jù)”是什么鸠儿？再次不同的場景可以采用不同的技術(shù)去解決。
“大數(shù)據(jù)”厕氨，拆開來看大进每、數(shù)據(jù)，大可以是指的數(shù)據(jù)源結(jié)構(gòu)簡單（ps 如果了解過當(dāng)代對大數(shù)據(jù)的定義就知道四個特性）但是量級夠大命斧，比如清算田晚、結(jié)算、對公国葬、對私贤徒、中間業(yè)務(wù)等等每一個拿出來都是幾十T芹壕，但是這些業(yè)務(wù)數(shù)據(jù)都是保存?zhèn)鹘y(tǒng)的關(guān)系型數(shù)據(jù)庫中如DB2、Oracle接奈、MSsql中踢涌，因?yàn)樵跀?shù)據(jù)平臺存儲是通過準(zhǔn)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ù)的去演進(jìn)解決堡僻。（最早時我的是中信銀行、光大銀行在2011年左右開始考慮Hadoop技術(shù)疫剃，后來不知道如何了）钉疫。
但是互聯(lián)網(wǎng)的數(shù)據(jù)平臺技術(shù)大都是NOSQL模式，犧牲掉了傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)一致性巢价、完整性寄猩、唯一索引等等癌别，只干性能的事情（當(dāng)然除了性能、可擴(kuò)展性也是的）.
原有在傳統(tǒng)數(shù)據(jù)平臺模型設(shè)計(jì)上可以考慮的一些通過主外鍵、唯一索引做一些業(yè)務(wù)約束的方法状答，在nosql上統(tǒng)統(tǒng)的都沒有了，這些約束必須放到數(shù)據(jù)加工階段去想辦法做檢查菩彬。傳統(tǒng)數(shù)據(jù)平臺如果在Insert赁还、update數(shù)據(jù)時違反了業(yè)務(wù)約束可以做報(bào)警或異常處理，但是在Nosql的平臺上要求ETL 去手動遵守這些規(guī)則檢查漏麦。但是有時ETL開發(fā)根本不遵守的客税，僅僅是兩個表關(guān)聯(lián)起來，也可能忘記按照某一個業(yè)務(wù)唯一索引做去重操作撕贞。簡單說更耻，原有靠關(guān)系型數(shù)據(jù)庫本身機(jī)制去做檢查一些規(guī)則變?yōu)槿斯ぃ優(yōu)槿斯ぞ蜁稿e捏膨。
從關(guān)系型數(shù)據(jù)平臺往Nosql數(shù)據(jù)平臺遷移時秧均，尤其是對傳統(tǒng)行業(yè)的業(yè)務(wù)來說，在模型設(shè)計(jì)階段号涯、以及給出的ETL口徑要考慮更多的業(yè)務(wù)規(guī)則檢查熬北，其次要考慮更多的維度退化、多冗余诚隙、表打?qū)捥幚硌纫：唵握f就是發(fā)揮數(shù)據(jù)平臺的計(jì)算能力同時要更加的各方面確保數(shù)據(jù)準(zhǔn)確安全可靠畏妖。
數(shù)據(jù)模型ODS 到EDW 這塊的設(shè)計(jì)方法百度上留下的文檔資料太多的了王悍，請這位提問的老師百度吧痘绎。
**8****．大數(shù)據(jù)****倉庫****中如何做快速****維處****理诉字？互****聯(lián)****網(wǎng)數(shù)****倉****數(shù)據(jù)****質(zhì)****量不好如何****對****數(shù)冗荸，如何確立****標(biāo)****準(zhǔn)的****對****數(shù)口徑尸曼？******
松子老師：快速變化維度可以轉(zhuǎn)化為緩慢變化為來出來淮摔，我自己理解的快速維度是相對于緩慢維度參照的來說的。
舉個例子，年齡-轉(zhuǎn)化為天數(shù)可以是定義快速變化維度，因?yàn)槊刻於荚谧兓钼伞Ｎ覀兛梢园涯挲g退化為區(qū)間維度來處理，還可以把年齡做成動態(tài)維度來處理舰涌，事實(shí)表中保存的就是實(shí)際的出生年月并打?qū)挶聿危挲g(天)通過計(jì)算方式來處理。還有種方法通過對代理鍵的方式來處理瓷耙。
我目前也不知道對數(shù)據(jù)的標(biāo)準(zhǔn)是什么朱躺。但是我自己用的方法，把一個指標(biāo)的整個數(shù)據(jù)流向切出幾個關(guān)鍵點(diǎn)通過SQL去實(shí)現(xiàn)對數(shù)搁痛，看波動振幅长搀，波動曲線。同時還會比如發(fā)不通的版本的小流量測試的方式來做數(shù)據(jù)校對。
9****． 做為數(shù)據(jù)行業(yè)從業(yè)者，需要掌握哪些重要的基礎(chǔ)知識馏臭？另：如果從零開始建立一個數(shù)據(jù)平臺谁尸，需要哪些資源配置（人，財(cái)纽甘，物良蛮，技術(shù)）？大致總投資額度多少悍赢？如果同行產(chǎn)品間多種來源的數(shù)據(jù)决瞳，可有成熟的解決方案货徙？謝謝…
松子老師：這個問題太宏觀了。作為數(shù)據(jù)行業(yè)從業(yè)者皮胡，需要掌握哪些重要基礎(chǔ)知識痴颊，這個是要看從事具體數(shù)據(jù)域的垂直行業(yè)。
比如說 數(shù)據(jù)開發(fā)胸囱、數(shù)據(jù)模型祷舀、數(shù)據(jù)產(chǎn)品瀑梗、數(shù)據(jù)分析師烹笔、數(shù)據(jù)運(yùn)營、數(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ù)目標(biāo)不太明確下饶套，難以確定方案，人員配置上選用不同技術(shù)方案去搭建的配置是不太一樣的垒探，比如說傳統(tǒng)平臺來講妓蛮，運(yùn)維、DBA圾叼、數(shù)據(jù)開發(fā)蛤克、數(shù)據(jù)模型、報(bào)表人員夷蚊。
從互聯(lián)網(wǎng)數(shù)據(jù)平臺基本配置上构挤，數(shù)據(jù)架構(gòu)師、運(yùn)維惕鼓、底層大數(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ù)酝陈。
10. Standalone****模式下营罢，Model.save(Path)怎么一直提示錯誤豺型，是不是配置Spark時需要將Hdfs的配置引進(jìn)來啊～仲智？表示初學(xué)Spark
松子老師：這個問題有點(diǎn)超出我的能力范圍了，所以對不起回答不了姻氨。
我本身不是做技術(shù)的钓辆。僅知道一點(diǎn)技術(shù)名詞。
11. ****傳統(tǒng)銀行業(yè)數(shù)據(jù)模型什么時候會走向互聯(lián)網(wǎng)模式呢肴焊？目前在傳統(tǒng)銀行數(shù)據(jù)平臺的產(chǎn)品是不是特別多前联？
松子老師：這個問題我自己就不知道了，或許是傳統(tǒng)銀行在數(shù)據(jù)平臺的實(shí)施上全面用互聯(lián)網(wǎng)的Nosql大數(shù)據(jù)處理技術(shù)吧娶眷。至于說傳統(tǒng)銀行數(shù)據(jù)模型用現(xiàn)有的互聯(lián)網(wǎng)數(shù)據(jù)模型理念去設(shè)計(jì)是否完全可行似嗤，數(shù)據(jù)一致性、高準(zhǔn)確性通過更多的方案去保證届宠。
首先我需要確定一下這個產(chǎn)品是否指的“數(shù)據(jù)產(chǎn)品”烁落。
如果是數(shù)據(jù)產(chǎn)品，那其實(shí)傳統(tǒng)行業(yè)數(shù)據(jù)平臺本身就有一些數(shù)據(jù)產(chǎn)品了豌注，而且也都是存在的伤塌。數(shù)據(jù)產(chǎn)品自從數(shù)據(jù)倉庫出現(xiàn)以來它其實(shí)一直都存在的，只不過是近幾年因?yàn)榛ヂ?lián)網(wǎng)特別愛制造“流行詞“把數(shù)據(jù)產(chǎn)品這個詞給放大了轧铁∶看希互聯(lián)網(wǎng)是得數(shù)據(jù)產(chǎn)品從早期的重量級逐漸進(jìn)化為輕量級、從大而全的解決方案逐漸演進(jìn)為因小而美属桦。
我來給出幾組例子熊痴，大約從2004年到現(xiàn)在的幾組數(shù)據(jù)產(chǎn)品的例子
(點(diǎn)擊放大圖像)
[圖片上傳中。聂宾。果善。（25）]
(點(diǎn)擊放大圖像)
[圖片上傳中。系谐。巾陕。（26）]
(點(diǎn)擊放大圖像)
[圖片上傳中。纪他。艳馒。（27）]
(點(diǎn)擊放大圖像)
[圖片上傳中狡相。匾旭。哈蝇。（28）]
(點(diǎn)擊放大圖像)
[圖片上傳中。薪寓。亡资。（29）]
(點(diǎn)擊放大圖像)
[圖片上傳中澜共。。锥腻。（30）]
(點(diǎn)擊放大圖像)
[圖片上傳中嗦董。。瘦黑。（31）]
你可以分類一下京革，這些數(shù)據(jù)產(chǎn)品的特點(diǎn)是什么？滿足了用戶怎么樣的痛點(diǎn)需求幸斥？滿足了用戶怎么樣的使用流程匹摇。
12 ****。傳統(tǒng)行業(yè)的數(shù)據(jù)倉庫從業(yè)人員睡毒，如果轉(zhuǎn)到互聯(lián)網(wǎng)行業(yè)来惧，應(yīng)該學(xué)習(xí)哪些技能冗栗？
松子老師：這個問題你可以百度搜索“大數(shù)據(jù)職位所需要的數(shù)據(jù)技能” http://blog.jobbole.com/99039/ 這篇文章演顾。自己覺得人家回答的比我專業(yè)。//
我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史（四）：互聯(lián)網(wǎng)時代 ? 下篇
http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-internet-age
編者按：本文是松子（李博源）的大數(shù)據(jù)平臺發(fā)展史系列文章的第四篇（共四篇）隅居，本系列以獨(dú)特的視角钠至，比較了非互聯(lián)網(wǎng)和互聯(lián)網(wǎng)兩個時代以及傳統(tǒng)行業(yè)與非傳統(tǒng)行業(yè)。是對數(shù)據(jù)平臺發(fā)展的一個回憶胎源，對非互聯(lián)網(wǎng)棉钧、互聯(lián)網(wǎng)，從數(shù)據(jù)平臺的用戶角度涕蚤、數(shù)據(jù)架構(gòu)演進(jìn)宪卿、模型等進(jìn)行了闡述。
在互聯(lián)網(wǎng)時代被弱化的數(shù)據(jù)模型
談起數(shù)據(jù)模型就不得不提傳統(tǒng)數(shù)據(jù)平臺架構(gòu)發(fā)展万栅，我相信很多朋友都曉得傳統(tǒng)數(shù)據(jù)平臺的知識佑钾，其架構(gòu)演進(jìn)簡單一句話說“基本上可以分為五個時代、四種架構(gòu)”烦粒，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與數(shù)據(jù)源類型多樣化特點(diǎn)，從高階架構(gòu)上來看大約從傳統(tǒng)數(shù)據(jù)平臺第三代架構(gòu)開始延續(xù)的，但是往后的發(fā)展從我自己的這一點(diǎn)知識上很難對互聯(lián)網(wǎng)的數(shù)據(jù)平臺做架構(gòu)歸類搓茬。
但是從數(shù)據(jù)平臺建設(shè)與服務(wù)角色上還是有章可循的竿滨。就像上篇分享到那樣，類比兩個行業(yè)徒役，互聯(lián)網(wǎng)企業(yè)中員工年齡比非互聯(lián)網(wǎng)企業(yè)的要年輕孽尽、受教育程度、對計(jì)算機(jī)的焦慮程度明顯比傳統(tǒng)企業(yè)要低忧勿、還偶遇其它各方面的緣故杉女，導(dǎo)致了數(shù)據(jù)平臺所面對用戶群體與非互聯(lián)網(wǎng)數(shù)據(jù)平臺有所差異化艇拍。
傳統(tǒng)行業(yè)與互聯(lián)網(wǎng)行業(yè)數(shù)據(jù)平臺用戶特性我只選擇前文章的兩張圖來表示
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
在傳統(tǒng)數(shù)據(jù)平臺要背后有一個完整數(shù)據(jù)倉庫團(tuán)隊(duì)去服務(wù)業(yè)務(wù)方，業(yè)務(wù)方嗷嗷待哺的等待被動方式去滿足宠纯。中低層數(shù)據(jù)基本不會對業(yè)務(wù)方開放卸夕，所以不管數(shù)據(jù)模型采用何種建模方式，主要滿足當(dāng)時數(shù)據(jù)架構(gòu)規(guī)劃即可婆瓜。
互聯(lián)網(wǎng)業(yè)務(wù)的快速發(fā)展使得大家已經(jīng)從經(jīng)營快集、分析的訴求重點(diǎn)轉(zhuǎn)為數(shù)據(jù)化的精細(xì)運(yùn)營上，如何做好精細(xì)化運(yùn)營問題上來廉白，當(dāng)資源不夠時用戶就叫喊个初，甚至有的業(yè)務(wù)方會挽起袖子來自己參與到從數(shù)據(jù)整理、加工猴蹂、分析階段院溺。
此時呢，原有建設(shè)數(shù)據(jù)平臺的多個角色（數(shù)據(jù)開發(fā)磅轻、模型設(shè)計(jì)）可能轉(zhuǎn)為對其它非專業(yè)使用數(shù)據(jù)方珍逸，做培訓(xùn)、咨詢與落地聋溜，寫更加適合當(dāng)前企業(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àn)椴粚I(yè)性漱病，導(dǎo)致數(shù)據(jù)質(zhì)量問題、重復(fù)對分?jǐn)?shù)據(jù)浪費(fèi)存儲與資源把曼、口徑多樣化杨帽、編碼不統(tǒng)一、命名問題等等原因嗤军。數(shù)據(jù)質(zhì)量逐漸變成一個特別突出的問題注盈。
傳統(tǒng)企業(yè)的數(shù)據(jù)源基本來自excel硬爆、表格愧薛、DB系統(tǒng)等软瞎，但在互聯(lián)網(wǎng)有網(wǎng)站點(diǎn)擊流日志扎阶、視頻秘蛔、音頻、圖片數(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ù)有些力不從心奶段。
當(dāng)數(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è)也有自己特點(diǎn)辫呻，傳統(tǒng)行業(yè)所涉及數(shù)據(jù)模型這個領(lǐng)域涉及的很多內(nèi)容在互聯(lián)網(wǎng)變成以其他的曲線救國的方式存在了清钥。
在互聯(lián)網(wǎng)曲線救國新解決
回顧在傳統(tǒng)行業(yè)數(shù)據(jù)平臺中琼锋，不管兩位大師爭論點(diǎn)數(shù)據(jù)模型的設(shè)計(jì)采用那種范式（Bill Inmon的EDW的原則是準(zhǔn)三范式的設(shè)計(jì)放闺、Ralph kilmbal是星型結(jié)構(gòu)）但是都要非常重視數(shù)據(jù)源的質(zhì)量問題。所以傳統(tǒng)行業(yè)的數(shù)據(jù)模型會全盤考慮數(shù)據(jù)質(zhì)量問題缕坎，并通過數(shù)據(jù)抽樣分析給出合適的清洗口徑怖侦。
(點(diǎn)擊放大圖像)
上圖來自我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ù)”對一年的還是不準(zhǔn)的）荷腊。在應(yīng)對數(shù)據(jù)的質(zhì)量問題艳悔，目前互聯(lián)網(wǎng)有些做法是把數(shù)據(jù)標(biāo)準(zhǔn)化前置到業(yè)務(wù)數(shù)據(jù)產(chǎn)生就做，從根源上去杜絕數(shù)據(jù)質(zhì)量女仰，但是這種場景比較實(shí)用在Log 日志的數(shù)據(jù)源中，比如移動互聯(lián)網(wǎng)最近流行的基于事件模型“Event”模型，在日志產(chǎn)生時就規(guī)定好存儲格式（備注：大家度娘搜索渡紫，“學(xué)習(xí)筆記：The Log（我所讀過的最好的一篇分布式技術(shù)文章）” 對這個講解很詳細(xì)）横媚。
在傳統(tǒng)行業(yè)，目前還是以混合模型設(shè)計(jì)方式為主一罩。在互聯(lián)網(wǎng)的我所接觸的一些業(yè)務(wù)杨幼，在參照傳統(tǒng)數(shù)據(jù)模型方法論基礎(chǔ)上逐步演進(jìn)適合互聯(lián)網(wǎng)數(shù)據(jù)的數(shù)據(jù)模型方法。
比如互聯(lián)網(wǎng)金融等一些業(yè)務(wù)會參考傳統(tǒng)金融行業(yè)對主題域的劃分聂渊、OMG數(shù)據(jù)倉庫元數(shù)據(jù)管理CWM模型差购、FSDM金融模型，再進(jìn)一步考慮大數(shù)據(jù)處理特性去進(jìn)行設(shè)計(jì)汉嗽，所有從Hight Level 數(shù)據(jù)架構(gòu)圖看到主題層次劃分與傳統(tǒng)第三代數(shù)據(jù)倉庫還是很多相似之處欲逃，當(dāng)然模型架構(gòu)也有分三層、四層诊胞、五層的暖夭。
不同的地方模型細(xì)節(jié)處理上已經(jīng)完全不一樣，比如數(shù)據(jù)的多樣性撵孤、拉寬事實(shí)表迈着、度量值單獨(dú)存儲、滿足數(shù)據(jù)快速重生邪码、維度的二次降維處理等裕菠、增加大量冗余列、增加大量派生列闭专，結(jié)合自動化元數(shù)據(jù)來耦合奴潘、合并等相關(guān)管理旧烧。
(點(diǎn)擊放大圖像)
[圖片上傳中。画髓。掘剪。（4）]
上圖是支付寶非常早期數(shù)據(jù)模型
(點(diǎn)擊放大圖像)
上圖是支付寶非常早期數(shù)據(jù)模型
我們常提到的多維模型在大數(shù)據(jù)處理下進(jìn)行了退化維度處理。大家知道Olap多維模型奈虾，隨著維度的增加事實(shí)表的數(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è)計(jì)多維挖掘分析數(shù)據(jù)產(chǎn)品背后的技術(shù)就是搜索引擎實(shí)現(xiàn)的）匾鸥，現(xiàn)在應(yīng)該也有新技術(shù)出現(xiàn)了來解決類似的問題。
(點(diǎn)擊放大圖像)
上圖為2012年產(chǎn)品UI之一碉纳。
(點(diǎn)擊放大圖像)
[圖片上傳中勿负。缴川。收壕。（7）]
上圖是2011-2012年該產(chǎn)品系列背后當(dāng)時使用的技術(shù)
互聯(lián)網(wǎng)業(yè)務(wù)特點(diǎn)業(yè)務(wù)垂直拆分非常細(xì)，比如一個用戶注冊嘶居、密碼找回的流程有可能存在好幾個產(chǎn)品負(fù)責(zé)同一個業(yè)務(wù)流程不同環(huán)節(jié)厚者，相關(guān)的一個策略躁劣、產(chǎn)品feature快速迭代上線等等都要數(shù)據(jù)評估。數(shù)據(jù)從前端埋點(diǎn)到采集然后再由各個環(huán)節(jié)到數(shù)據(jù)平臺库菲，再有數(shù)據(jù)分析師或各業(yè)務(wù)部門去使用账忘，基本拉長了時間周期。需求部門與實(shí)施部門能力和經(jīng)驗(yàn)有千差萬別的需求熙宇，造成了懂技術(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ù)特點(diǎn)是變化非常迅速的，能穩(wěn)定的業(yè)務(wù)達(dá)到65%算對數(shù)據(jù)平臺是個福音了（根據(jù)對某寶寶的印象）剩余的業(yè)務(wù)變化迅速互躬，必然導(dǎo)致數(shù)據(jù)模型快速上下線播赁。
Kimball老人家提出的維度建模（備注，在本系列發(fā)展史得第一篇有介紹）圍繞業(yè)務(wù)模型能夠非常直觀的表達(dá)出業(yè)務(wù)的數(shù)據(jù)關(guān)系吼渡，但是在互聯(lián)網(wǎng)NOSQL犧牲掉了關(guān)系型數(shù)據(jù)庫的一致性容为、完整性等等很多東西。維度數(shù)據(jù)模型又基于這些大數(shù)據(jù)技術(shù)的，所以進(jìn)化的更加輕量級與基于細(xì)節(jié)數(shù)據(jù)的維度退化建模（原有的緩慢變化維坎背、快速變化維替劈、大維、迷你維得滤、父子維陨献、雪花維為了適應(yīng)互聯(lián)網(wǎng)的大數(shù)據(jù)Nosql處理技術(shù)進(jìn)行反規(guī)范化、化&數(shù)據(jù)冗余設(shè)計(jì)耿戚。
退化維度的反規(guī)范化設(shè)計(jì)一方面可以把一條查詢語句所需要的所有數(shù)據(jù)組合起來放到一個地方存儲 Key values 的方式（比如說商品有不同類型湿故，每一種類型商品又有自己的不同屬性，可以采用一對多膜蛔、多對多的方式存儲，例如把一個多維映射為一個Key value）脖阵。
講到互聯(lián)網(wǎng)數(shù)據(jù)平臺就要提數(shù)據(jù)模型蚁阳，提了數(shù)據(jù)模型就要提Nosql技術(shù)榕茧，
(點(diǎn)擊放大圖像)
上圖來自Nosql文檔系列的一幅圖
Nosql 是大數(shù)據(jù)處理的特征之一。互聯(lián)網(wǎng)數(shù)據(jù)平臺數(shù)據(jù)模型與NoSql技術(shù)還是蠻緊密的区丑。這里有外文講解Nosql Data modeling technigues 從技術(shù)角度講解非常詳（https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/）。
因?yàn)榍斑吿岬降拇髷?shù)據(jù)平臺技術(shù)特性決定了傳統(tǒng)edw模型茧彤、維度模型直接在互聯(lián)網(wǎng)數(shù)據(jù)大數(shù)據(jù)平臺部署或許還有“好些未知”障礙等待大家去克服常侦。同時在傳統(tǒng)數(shù)據(jù)建模用到的一些方法經(jīng)過互聯(lián)網(wǎng)熏陶或許演進(jìn)成一種新的數(shù)據(jù)產(chǎn)品或方案吧。
到此為止“我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史”上下共四篇與大家分享完畢坠宴，這個寫作前后經(jīng)歷剛好一個月左右洋魂，算是對自己數(shù)據(jù)從業(yè)經(jīng)歷回顧之一吧。在知識的整理中很多都是蜻蜓點(diǎn)水喜鼓，每個知識域都是一個非常深的專業(yè)方向副砍，自己涉足很膚淺，在文章中分享不足之處請各位讀者見諒Ｗ豁翎！
個人郵箱是5592094@qq.com 歡迎電郵交流。
接下來我會進(jìn)入數(shù)據(jù)產(chǎn)品這個領(lǐng)域的分享隅忿，當(dāng)年車品覺老師自豪的作品之一“黃金策”心剥，我是數(shù)據(jù)產(chǎn)品經(jīng)理。（ps：自己躲在墻角拿車品覺老師往自己臉上貼金了）背桐。
后記
有一次數(shù)據(jù)產(chǎn)品神策的創(chuàng)始人兼好友@桑文鋒＠SensorsData跟我說來做次分享吧优烧，我當(dāng)時出了幾個題目，最后就選擇了“我所經(jīng)歷的大數(shù)據(jù)平臺“牢撼，就形成了大家看到的”我所經(jīng)歷的大數(shù)據(jù)平臺“系列文章.
在整理期間得到了死黨@周愛民匙隔、@神策-桑文峰、 InfoQ小編@Tina Du 、@betty zhou @Laurel大力協(xié)助纷责，在這里感謝：床簟！再膳！
番外篇
這一篇是在24日舉行的分享大家提到的一些問題挺勿，經(jīng)過整理算是對正文的補(bǔ)充吧，從互聯(lián)網(wǎng)敏捷數(shù)據(jù)模型等角度做了較深入的細(xì)節(jié)介紹喂柒。同時在數(shù)據(jù)產(chǎn)品方面的回答包含了一點(diǎn)未來寫作篇“數(shù)據(jù)產(chǎn)品”系列的一點(diǎn)內(nèi)容不瓶。
1****，傳統(tǒng)我們做BI的灾杰，做數(shù)據(jù)展現(xiàn)會建模后以pivot展現(xiàn)cube數(shù)據(jù)蚊丐，不知道現(xiàn)在互聯(lián)網(wǎng)公司數(shù)據(jù)展示如何做的谭胚？第三方工具還是用API取數(shù)據(jù)平臺里的數(shù)據(jù)檀葛？adhoc報(bào)表及靈活更換維度的時候web端一般是怎么做的？
松子老師：剛才文章中提到了比如傳統(tǒng)行業(yè)的多維數(shù)據(jù)模型cube攀圈。在互聯(lián)網(wǎng)采用的曲線救國方式解決的昭娩。 在分享中我給出了幾個圖凛篙。就是通過搜索引擎曲線救國方式實(shí)現(xiàn)類似Olap的模擬。
在這塊的模型的處理上采用的是維度退化處理栏渺。通過反規(guī)范化呛梆，數(shù)據(jù)項(xiàng)、數(shù)據(jù)冗余去處理磕诊。在前端做特殊處理填物。
這個當(dāng)時產(chǎn)品原型之一：
(點(diǎn)擊放大圖像)
這是一個2011年-2012年左右的數(shù)據(jù)產(chǎn)品，當(dāng)時算是即時計(jì)算的一種秀仲。不過已經(jīng)過去好幾年了融痛，當(dāng)今新技術(shù)下Olap 引擎應(yīng)該有很好的提升。
目前我知道的家互聯(lián)網(wǎng)公司神僵，在前端展現(xiàn)有使用第三方套件比如spagoBi雁刷、pentaho 等 有自己設(shè)計(jì)開發(fā)定制化數(shù)據(jù)前端展現(xiàn)。比如我剛開始分享的那兩個之前在去哪兒網(wǎng)設(shè)計(jì)的數(shù)據(jù)平臺內(nèi)部界面之一保礼，當(dāng)然數(shù)據(jù)產(chǎn)品是另一個話題了沛励，通過對數(shù)據(jù)分析抽象指標(biāo)、分析模型炮障、用戶使用功能與流程目派、未來規(guī)劃考慮用戶體驗(yàn)去設(shè)計(jì)。
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
[圖片上傳中胁赢。企蹭。。（11）]
(點(diǎn)擊放大圖像)
2****，互聯(lián)網(wǎng)財(cái)經(jīng)類公司谅摄，業(yè)務(wù)包括財(cái)經(jīng)網(wǎng)站徒河、基金、股票送漠、金融等顽照，這類公司的數(shù)據(jù)倉庫模型應(yīng)該如何設(shè)計(jì)？特點(diǎn)和注意事項(xiàng)是什么闽寡？案例介紹代兵？十分感謝瞬痘。
松子老師：我自己經(jīng)歷過的是互聯(lián)網(wǎng)金融以及移動互聯(lián)網(wǎng)行祝峻。對這兩塊比較清楚挤安《什纾互聯(lián)網(wǎng)金融起因?yàn)闃I(yè)務(wù)的特性是類金融類的，與銀行有些地方是相似的宾抓。
比如大約在2012年前支付寶業(yè)務(wù)特點(diǎn)涉及類金融交易：充值饵较、提現(xiàn)玲销、賬務(wù)管理類電子商務(wù)：購物交易過程變更土辩、實(shí)際交易（對B機(jī)票、對C水電等） 非純電子商務(wù)抢野；純金融拷淘；個人信用，理財(cái)類指孤。系統(tǒng)之間依賴度較為復(fù)雜启涯，垂直依賴（業(yè)務(wù)與核心）跨層依賴（跨過交易到賬務(wù)）。
在設(shè)計(jì)方法上還是采用維度模型設(shè)計(jì)方式恃轩。底層是數(shù)據(jù)驅(qū)動為向?qū)Ы嵬荩Y(jié)合業(yè)務(wù)需求驅(qū)動，通過簡單叉跛、退化維度的方式拉寬表結(jié)構(gòu)松忍。
底層采用松耦合設(shè)計(jì)。主題之間是松耦合方式筷厘。至體內(nèi)采用細(xì)粒度退化維度鸣峭。
在主題域上的的設(shè)計(jì)基本參考了OMG的數(shù)據(jù)倉庫元數(shù)據(jù)設(shè)計(jì)CWM模型、IBM 的fsdm金融模型酥艳、還有新巴塞爾資本協(xié)議（Basel II Capital Accord）需提供數(shù)據(jù)規(guī)范去的設(shè)計(jì)摊溶。所以數(shù)據(jù)模型是五層的結(jié)構(gòu)。
在細(xì)節(jié)處理上充石，增量ODS層數(shù)據(jù)和前一天DWD相關(guān)表進(jìn)行 merge處理莫换。
在一些層次上，基本聚合、匯總增加派生事實(shí)表（簡單一句話退化為度打?qū)挘├辍Ｈ缓蟀凑諛I(yè)務(wù)主體合并信息等坷剧。
比如開始給大家分享的那張圖：
(點(diǎn)擊放大圖像)
[圖片上傳中。膛薛。听隐。（13）]
在維度模型退化處理時，要注意最細(xì)粒度數(shù)據(jù)保留、不同層次的數(shù)據(jù)支持?jǐn)?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ù)模型锌半。
這種元數(shù)據(jù)驅(qū)動工具型數(shù)據(jù)產(chǎn)品我會在未來數(shù)據(jù)產(chǎn)品系列中做詳細(xì)介紹的禽车。
3****，互聯(lián)網(wǎng)企業(yè)大數(shù)據(jù)平臺的發(fā)展歷程是怎樣的刊殉？
松子老師：這個我相信應(yīng)該是傳統(tǒng)數(shù)據(jù)平臺朋友提到的殉摔。傳統(tǒng)行業(yè)數(shù)據(jù)平臺架構(gòu)演進(jìn)我總結(jié)簡單一句話說“基本上可以分為五個時代、四種架構(gòu)”记焊，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與類型暴增的特點(diǎn)逸月，從高階架構(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é)下來用戶特點(diǎn)：
(點(diǎn)擊放大圖像)
[圖片上傳中恩尾。。挽懦。（14）]
更加詳細(xì)的每一代數(shù)據(jù)平臺建設(shè)翰意、服務(wù)角色特點(diǎn)您可以看我這個系列文章的第三篇，http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-paet02
4****巾兆，有沒有好的元數(shù)據(jù)管理工具推薦猎物？主要偏向數(shù)據(jù)字典與血統(tǒng)等。
松子老師：元數(shù)據(jù)以前目前沒有太多的好管理工具角塑。以前是在支付寶是我自己設(shè)計(jì)的一個數(shù)據(jù)產(chǎn)品蔫磨。第一版自己用Delphi 開發(fā)的。
（圖很多：）
(點(diǎn)擊放大圖像)
[圖片上傳中圃伶。堤如。蒲列。（15）]
(點(diǎn)擊放大圖像)
[圖片上傳中。搀罢。蝗岖。（16）]
(點(diǎn)擊放大圖像)
[圖片上傳中。榔至。亏娜。（17）]
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
[圖片上傳中粗井。筝闹。奥邮。（19）]
以前被逼的自己寫了一個，通過解析枫弟，實(shí)現(xiàn)了字段級的血緣影響分析邢享。這只是第二步，后來又把running 信息給搞了進(jìn)來淡诗。還有分享時提到的模型信息骇塘、整個閉環(huán)的分類信息。
這是一個分支：
(點(diǎn)擊放大圖像)
[圖片上傳中韩容。款违。。（20）]
但是我們實(shí)現(xiàn)了字段級解析準(zhǔn)確率達(dá)到了94%左右群凶。有細(xì)微的錯誤就人工revew一遍奠货。
5. ****松子老師，數(shù)據(jù)管控的數(shù)據(jù)質(zhì)量部分是怎么處理的呢座掘？
松子老師： 數(shù)據(jù)管控， 這方面我不太懂的柔滔，但是數(shù)據(jù)質(zhì)量溢陪，這玩意可大可小的。比如像在分享時說過的睛廊，在移動互聯(lián)網(wǎng)的數(shù)據(jù)質(zhì)量處理方式可以由原有的ETL(ELT)階段前置到業(yè)務(wù)系統(tǒng)去解決形真，比如移動互聯(lián)網(wǎng)的App log 日志，日志標(biāo)準(zhǔn)化后事件模型”存儲來解決超全。那非app 日志類如何解決呢比如Payment咆霜、order等，數(shù)據(jù)質(zhì)量比較考慮的可以只做到監(jiān)控嘶朱。
我來分享個圖蛾坯。剛好是我設(shè)計(jì)數(shù)據(jù)質(zhì)量產(chǎn)品時搞的，理清數(shù)據(jù)質(zhì)量的問題：
(點(diǎn)擊放大圖像)
[圖片上傳中疏遏。脉课。救军。（21）]
(點(diǎn)擊放大圖像)
[圖片上傳中。倘零。唱遭。（22）]
(點(diǎn)擊放大圖像)
[圖片上傳中。。。（23）]
只要數(shù)據(jù)進(jìn)入倉庫與應(yīng)用體系丰介，處理起來就比較困難了旱易，所以在數(shù)據(jù)平臺階段最好是通過監(jiān)控、前置去解決走触。目前數(shù)據(jù)質(zhì)量確實(shí)難以100%由事后搞到事前去處理。我對數(shù)據(jù)平臺與數(shù)據(jù)產(chǎn)品的建設(shè)就是實(shí)用為主。怎么實(shí)用怎么來蚌吸。我是比較現(xiàn)實(shí)的實(shí)用主義者。
6. ****能否分享一些數(shù)據(jù)產(chǎn)品種類及實(shí)例：
松子老師：在前邊五個問題砌庄、以及文章中又都涉及數(shù)據(jù)產(chǎn)品實(shí)力的一些分享羹唠。
提到數(shù)據(jù)產(chǎn)品的分類我就想把這個圖發(fā)出來。
自己認(rèn)為沒有特別明確的劃分線娄昆，但是數(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工具撼玄、資源管控等等夺姑。
面向用戶功能有報(bào)表型、多維型數(shù)據(jù)產(chǎn)品掌猛、定制化數(shù)據(jù)產(chǎn)品盏浙、挖掘型數(shù)據(jù)產(chǎn)品。
面向內(nèi)部用戶荔茬、外部個人用戶废膘、外部企業(yè)用戶又有不同的分類。
根據(jù)業(yè)務(wù)又可以劃分很多慕蔚，面向C類用戶丐黄、面向B類商戶、金融風(fēng)險(xiǎn)等等
從近幾年的數(shù)據(jù)產(chǎn)品來看坊萝，是更好的輔助用戶的做決策的一種產(chǎn)品形態(tài)孵稽，在用戶的決策與行動中充當(dāng)信息的分析者與價值使用者许起；數(shù)據(jù)產(chǎn)品有個自己的共性：由解決的一個實(shí)際的業(yè)務(wù)問題出發(fā)，分解出的分析指標(biāo)菩鲜，分析模型园细，分析流程組成割以，再考慮到功能易用性肛真，未來功能擴(kuò)展，考慮用戶對數(shù)據(jù)易用性（比如數(shù)據(jù)的呈現(xiàn)層次秘遏，不可能一次把所有數(shù)據(jù)的呈現(xiàn)給用戶）來組成的蛛勉。
(點(diǎn)擊放大圖像)
[圖片上傳中鹿寻。。诽凌。（24）]
7. ****銀行業(yè)從傳統(tǒng)的ods到edw再到大數(shù)據(jù)平臺這塊過渡毡熏，模型如何建設(shè)躬络？平臺優(yōu)勢如何發(fā)揮？
松子老師：這個問題還是有些難度的俊扭，自己回答的可能有些片面。首先我們清醒的清楚“大數(shù)據(jù)”是什么腾誉？再次不同的場景可以采用不同的技術(shù)去解決茄螃。
“大數(shù)據(jù)”冠蒋，拆開來看大刀脏、數(shù)據(jù)，大可以是指的數(shù)據(jù)源結(jié)構(gòu)簡單（ps 如果了解過當(dāng)代對大數(shù)據(jù)的定義就知道四個特性）但是量級夠大溪胶，比如清算粉臊、結(jié)算、對公辉巡、對私毛仪、中間業(yè)務(wù)等等每一個拿出來都是幾十T埋泵，但是這些業(yè)務(wù)數(shù)據(jù)都是保存?zhèn)鹘y(tǒng)的關(guān)系型數(shù)據(jù)庫中如DB2民假、Oracle、MSsql中冀墨，因?yàn)樵跀?shù)據(jù)平臺存儲是通過準(zhǔn)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ù)的去演進(jìn)解決虫腋。（最早時我的是中信銀行骄酗、光大銀行在2011年左右開始考慮Hadoop技術(shù)，后來不知道如何了）悦冀。
但是互聯(lián)網(wǎng)的數(shù)據(jù)平臺技術(shù)大都是NOSQL模式趋翻，犧牲掉了傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)一致性屋群、完整性住闯、唯一索引等等，只干性能的事情（當(dāng)然除了性能郭赐、可擴(kuò)展性也是的）.
原有在傳統(tǒng)數(shù)據(jù)平臺模型設(shè)計(jì)上可以考慮的一些通過主外鍵茁影、唯一索引做一些業(yè)務(wù)約束的方法，在nosql上統(tǒng)統(tǒng)的都沒有了丧凤，這些約束必須放到數(shù)據(jù)加工階段去想辦法做檢查募闲。傳統(tǒng)數(shù)據(jù)平臺如果在Insert、update數(shù)據(jù)時違反了業(yè)務(wù)約束可以做報(bào)警或異常處理愿待，但是在Nosql的平臺上要求ETL 去手動遵守這些規(guī)則檢查浩螺。但是有時ETL開發(fā)根本不遵守的，僅僅是兩個表關(guān)聯(lián)起來仍侥，也可能忘記按照某一個業(yè)務(wù)唯一索引做去重操作要出。簡單說，原有靠關(guān)系型數(shù)據(jù)庫本身機(jī)制去做檢查一些規(guī)則變?yōu)槿斯づ┰ǎ優(yōu)槿斯ぞ蜁稿e患蹂。
從關(guān)系型數(shù)據(jù)平臺往Nosql數(shù)據(jù)平臺遷移時，尤其是對傳統(tǒng)行業(yè)的業(yè)務(wù)來說砸紊，在模型設(shè)計(jì)階段传于、以及給出的ETL口徑要考慮更多的業(yè)務(wù)規(guī)則檢查，其次要考慮更多的維度退化醉顽、多冗余沼溜、表打?qū)捥幚怼：唵握f就是發(fā)揮數(shù)據(jù)平臺的計(jì)算能力同時要更加的各方面確保數(shù)據(jù)準(zhǔn)確安全可靠游添。
數(shù)據(jù)模型ODS 到EDW 這塊的設(shè)計(jì)方法百度上留下的文檔資料太多的了系草，請這位提問的老師百度吧通熄。
**8****．大數(shù)據(jù)****倉庫****中如何做快速****維處****理？互****聯(lián)****網(wǎng)數(shù)****倉****數(shù)據(jù)****質(zhì)****量不好如何****對****數(shù)找都，如何確立****標(biāo)****準(zhǔn)的****對****數(shù)口徑唇辨？******
松子老師：快速變化維度可以轉(zhuǎn)化為緩慢變化為來出來，我自己理解的快速維度是相對于緩慢維度參照的來說的檐嚣。
舉個例子助泽，年齡-轉(zhuǎn)化為天數(shù)可以是定義快速變化維度，因?yàn)槊刻於荚谧兓烤Ｎ覀兛梢园涯挲g退化為區(qū)間維度來處理嗡贺，還可以把年齡做成動態(tài)維度來處理，事實(shí)表中保存的就是實(shí)際的出生年月并打?qū)挶恚挲g(天)通過計(jì)算方式來處理。還有種方法通過對代理鍵的方式來處理没炒。
我目前也不知道對數(shù)據(jù)的標(biāo)準(zhǔn)是什么场刑。但是我自己用的方法，把一個指標(biāo)的整個數(shù)據(jù)流向切出幾個關(guān)鍵點(diǎn)通過SQL去實(shí)現(xiàn)對數(shù)蝎宇，看波動振幅，波動曲線。同時還會比如發(fā)不通的版本的小流量測試的方式來做數(shù)據(jù)校對亲澡。
9****． 做為數(shù)據(jù)行業(yè)從業(yè)者，需要掌握哪些重要的基礎(chǔ)知識纫版？另：如果從零開始建立一個數(shù)據(jù)平臺床绪，需要哪些資源配置（人，財(cái)其弊，物癞己，技術(shù)）？大致總投資額度多少梭伐？如果同行產(chǎn)品間多種來源的數(shù)據(jù)痹雅，可有成熟的解決方案？謝謝…
松子老師：這個問題太宏觀了糊识。作為數(shù)據(jù)行業(yè)從業(yè)者绩社，需要掌握哪些重要基礎(chǔ)知識，這個是要看從事具體數(shù)據(jù)域的垂直行業(yè)赂苗。
比如說 數(shù)據(jù)開發(fā)铃将、數(shù)據(jù)模型、數(shù)據(jù)產(chǎn)品哑梳、數(shù)據(jù)分析師劲阎、數(shù)據(jù)運(yùn)營、數(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ù)目標(biāo)不太明確下货岭，難以確定方案路操，人員配置上選用不同技術(shù)方案去搭建的配置是不太一樣的，比如說傳統(tǒng)平臺來講千贯，運(yùn)維屯仗、DBA脐嫂、數(shù)據(jù)開發(fā)橘沥、數(shù)據(jù)模型、報(bào)表人員炮沐。
從互聯(lián)網(wǎng)數(shù)據(jù)平臺基本配置上敦第，數(shù)據(jù)架構(gòu)師峰弹、運(yùn)維、底層大數(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ù)空镜。
10. Standalone****模式下浩淘，Model.save(Path)怎么一直提示錯誤，是不是配置Spark時需要將Hdfs的配置引進(jìn)來啊～吴攒？表示初學(xué)Spark
松子老師：這個問題有點(diǎn)超出我的能力范圍了张抄，所以對不起回答不了。
我本身不是做技術(shù)的洼怔。僅知道一點(diǎn)技術(shù)名詞署惯。
11. ****傳統(tǒng)銀行業(yè)數(shù)據(jù)模型什么時候會走向互聯(lián)網(wǎng)模式呢？目前在傳統(tǒng)銀行數(shù)據(jù)平臺的產(chǎn)品是不是特別多镣隶？
松子老師：這個問題我自己就不知道了极谊，或許是傳統(tǒng)銀行在數(shù)據(jù)平臺的實(shí)施上全面用互聯(lián)網(wǎng)的Nosql大數(shù)據(jù)處理技術(shù)吧诡右。至于說傳統(tǒng)銀行數(shù)據(jù)模型用現(xiàn)有的互聯(lián)網(wǎng)數(shù)據(jù)模型理念去設(shè)計(jì)是否完全可行，數(shù)據(jù)一致性轻猖、高準(zhǔn)確性通過更多的方案去保證帆吻。
首先我需要確定一下這個產(chǎn)品是否指的“數(shù)據(jù)產(chǎn)品”。
如果是數(shù)據(jù)產(chǎn)品咙边，那其實(shí)傳統(tǒng)行業(yè)數(shù)據(jù)平臺本身就有一些數(shù)據(jù)產(chǎn)品了猜煮，而且也都是存在的。數(shù)據(jù)產(chǎn)品自從數(shù)據(jù)倉庫出現(xiàn)以來它其實(shí)一直都存在的败许，只不過是近幾年因?yàn)榛ヂ?lián)網(wǎng)特別愛制造“流行詞“把數(shù)據(jù)產(chǎn)品這個詞給放大了罩阵∽钋罚互聯(lián)網(wǎng)是得數(shù)據(jù)產(chǎn)品從早期的重量級逐漸進(jìn)化為輕量級、從大而全的解決方案逐漸演進(jìn)為因小而美。
我來給出幾組例子晦溪，大約從2004年到現(xiàn)在的幾組數(shù)據(jù)產(chǎn)品的例子
(點(diǎn)擊放大圖像)
[圖片上傳中。儿礼。板祝。（25）]
(點(diǎn)擊放大圖像)
[圖片上傳中。甥桂。柿究。（26）]
(點(diǎn)擊放大圖像)
[圖片上傳中。黄选。蝇摸。（27）]
(點(diǎn)擊放大圖像)
[圖片上傳中。办陷。貌夕。（28）]
(點(diǎn)擊放大圖像)
[圖片上傳中。民镜。啡专。（29）]
(點(diǎn)擊放大圖像)
[圖片上傳中。制圈。们童。（30）]
(點(diǎn)擊放大圖像)
[圖片上傳中。鲸鹦。慧库。（31）]
你可以分類一下，這些數(shù)據(jù)產(chǎn)品的特點(diǎn)是什么馋嗜？滿足了用戶怎么樣的痛點(diǎn)需求齐板？滿足了用戶怎么樣的使用流程。
12 ****。傳統(tǒng)行業(yè)的數(shù)據(jù)倉庫從業(yè)人員覆积，如果轉(zhuǎn)到互聯(lián)網(wǎng)行業(yè)听皿，應(yīng)該學(xué)習(xí)哪些技能？
松子老師：這個問題你可以百度搜索“大數(shù)據(jù)職位所需要的數(shù)據(jù)技能” http://blog.jobbole.com/99039/ 這篇文章宽档。自己覺得人家回答的比我專業(yè)尉姨。//
我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史（四）：互聯(lián)網(wǎng)時代 ? 下篇
http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-internet-age
編者按：本文是松子（李博源）的大數(shù)據(jù)平臺發(fā)展史系列文章的第四篇（共四篇），本系列以獨(dú)特的視角吗冤，比較了非互聯(lián)網(wǎng)和互聯(lián)網(wǎng)兩個時代以及傳統(tǒng)行業(yè)與非傳統(tǒng)行業(yè)又厉。是對數(shù)據(jù)平臺發(fā)展的一個回憶趟畏，對非互聯(lián)網(wǎng)败晴、互聯(lián)網(wǎng)，從數(shù)據(jù)平臺的用戶角度望抽、數(shù)據(jù)架構(gòu)演進(jìn)肺蔚、模型等進(jìn)行了闡述煌妈。
在互聯(lián)網(wǎng)時代被弱化的數(shù)據(jù)模型
談起數(shù)據(jù)模型就不得不提傳統(tǒng)數(shù)據(jù)平臺架構(gòu)發(fā)展，我相信很多朋友都曉得傳統(tǒng)數(shù)據(jù)平臺的知識宣羊，其架構(gòu)演進(jìn)簡單一句話說“基本上可以分為五個時代璧诵、四種架構(gòu)”，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與數(shù)據(jù)源類型多樣化特點(diǎn)仇冯，從高階架構(gòu)上來看大約從傳統(tǒng)數(shù)據(jù)平臺第三代架構(gòu)開始延續(xù)的之宿，但是往后的發(fā)展從我自己的這一點(diǎn)知識上很難對互聯(lián)網(wǎng)的數(shù)據(jù)平臺做架構(gòu)歸類。
但是從數(shù)據(jù)平臺建設(shè)與服務(wù)角色上還是有章可循的苛坚。就像上篇分享到那樣比被，類比兩個行業(yè)，互聯(lián)網(wǎng)企業(yè)中員工年齡比非互聯(lián)網(wǎng)企業(yè)的要年輕泼舱、受教育程度等缀、對計(jì)算機(jī)的焦慮程度明顯比傳統(tǒng)企業(yè)要低、還偶遇其它各方面的緣故娇昙，導(dǎo)致了數(shù)據(jù)平臺所面對用戶群體與非互聯(lián)網(wǎng)數(shù)據(jù)平臺有所差異化尺迂。
傳統(tǒng)行業(yè)與互聯(lián)網(wǎng)行業(yè)數(shù)據(jù)平臺用戶特性我只選擇前文章的兩張圖來表示
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
在傳統(tǒng)數(shù)據(jù)平臺要背后有一個完整數(shù)據(jù)倉庫團(tuán)隊(duì)去服務(wù)業(yè)務(wù)方，業(yè)務(wù)方嗷嗷待哺的等待被動方式去滿足涯贞。中低層數(shù)據(jù)基本不會對業(yè)務(wù)方開放枪狂，所以不管數(shù)據(jù)模型采用何種建模方式危喉，主要滿足當(dāng)時數(shù)據(jù)架構(gòu)規(guī)劃即可宋渔。
互聯(lián)網(wǎng)業(yè)務(wù)的快速發(fā)展使得大家已經(jīng)從經(jīng)營、分析的訴求重點(diǎn)轉(zhuǎn)為數(shù)據(jù)化的精細(xì)運(yùn)營上辜限，如何做好精細(xì)化運(yùn)營問題上來皇拣，當(dāng)資源不夠時用戶就叫喊，甚至有的業(yè)務(wù)方會挽起袖子來自己參與到從數(shù)據(jù)整理、加工氧急、分析階段颗胡。
此時呢钉寝，原有建設(shè)數(shù)據(jù)平臺的多個角色（數(shù)據(jù)開發(fā)嵌纲、模型設(shè)計(jì)）可能轉(zhuǎn)為對其它非專業(yè)使用數(shù)據(jù)方险胰，做培訓(xùn)蛀蜜、咨詢與落地，寫更加適合當(dāng)前企業(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àn)椴粚I(yè)性屡萤，導(dǎo)致數(shù)據(jù)質(zhì)量問題膊夹、重復(fù)對分?jǐn)?shù)據(jù)浪費(fèi)存儲與資源沪袭、口徑多樣化、編碼不統(tǒng)一樟氢、命名問題等等原因冈绊。數(shù)據(jù)質(zhì)量逐漸變成一個特別突出的問題。
傳統(tǒng)企業(yè)的數(shù)據(jù)源基本來自excel埠啃、表格死宣、DB系統(tǒng)等，但在互聯(lián)網(wǎng)有網(wǎng)站點(diǎn)擊流日志碴开、視頻毅该、音頻、圖片數(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ù)有些力不從心静盅。
當(dāng)數(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è)也有自己特點(diǎn)溯革，傳統(tǒng)行業(yè)所涉及數(shù)據(jù)模型這個領(lǐng)域涉及的很多內(nèi)容在互聯(lián)網(wǎng)變成以其他的曲線救國的方式存在了。
在互聯(lián)網(wǎng)曲線救國新解決
回顧在傳統(tǒng)行業(yè)數(shù)據(jù)平臺中谷醉，不管兩位大師爭論點(diǎn)數(shù)據(jù)模型的設(shè)計(jì)采用那種范式（Bill Inmon的EDW的原則是準(zhǔn)三范式的設(shè)計(jì)致稀、Ralph kilmbal是星型結(jié)構(gòu)）但是都要非常重視數(shù)據(jù)源的質(zhì)量問題。所以傳統(tǒng)行業(yè)的數(shù)據(jù)模型會全盤考慮數(shù)據(jù)質(zhì)量問題俱尼，并通過數(shù)據(jù)抽樣分析給出合適的清洗口徑胞锰。
(點(diǎn)擊放大圖像)
上圖來自我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ù)”對一年的還是不準(zhǔn)的）蛤迎。在應(yīng)對數(shù)據(jù)的質(zhì)量問題，目前互聯(lián)網(wǎng)有些做法是把數(shù)據(jù)標(biāo)準(zhǔn)化前置到業(yè)務(wù)數(shù)據(jù)產(chǎn)生就做，從根源上去杜絕數(shù)據(jù)質(zhì)量羊精，但是這種場景比較實(shí)用在Log 日志的數(shù)據(jù)源中，比如移動互聯(lián)網(wǎng)最近流行的基于事件模型“Event”模型囚玫，在日志產(chǎn)生時就規(guī)定好存儲格式（備注：大家度娘搜索园匹，“學(xué)習(xí)筆記：The Log（我所讀過的最好的一篇分布式技術(shù)文章）” 對這個講解很詳細(xì)）。
在傳統(tǒng)行業(yè)劫灶，目前還是以混合模型設(shè)計(jì)方式為主裸违。在互聯(lián)網(wǎng)的我所接觸的一些業(yè)務(wù)，在參照傳統(tǒng)數(shù)據(jù)模型方法論基礎(chǔ)上逐步演進(jìn)適合互聯(lián)網(wǎng)數(shù)據(jù)的數(shù)據(jù)模型方法本昏。
比如互聯(lián)網(wǎng)金融等一些業(yè)務(wù)會參考傳統(tǒng)金融行業(yè)對主題域的劃分供汛、OMG數(shù)據(jù)倉庫元數(shù)據(jù)管理CWM模型、FSDM金融模型涌穆，再進(jìn)一步考慮大數(shù)據(jù)處理特性去進(jìn)行設(shè)計(jì)怔昨，所有從Hight Level 數(shù)據(jù)架構(gòu)圖看到主題層次劃分與傳統(tǒng)第三代數(shù)據(jù)倉庫還是很多相似之處，當(dāng)然模型架構(gòu)也有分三層宿稀、四層趁舀、五層的。
不同的地方模型細(xì)節(jié)處理上已經(jīng)完全不一樣祝沸，比如數(shù)據(jù)的多樣性矮烹、拉寬事實(shí)表、度量值單獨(dú)存儲罩锐、滿足數(shù)據(jù)快速重生奉狈、維度的二次降維處理等、增加大量冗余列涩惑、增加大量派生列仁期，結(jié)合自動化元數(shù)據(jù)來耦合、合并等相關(guān)管理竭恬。
(點(diǎn)擊放大圖像)
[圖片上傳中跛蛋。。痊硕。（4）]
上圖是支付寶非常早期數(shù)據(jù)模型
(點(diǎn)擊放大圖像)
上圖是支付寶非常早期數(shù)據(jù)模型
我們常提到的多維模型在大數(shù)據(jù)處理下進(jìn)行了退化維度處理赊级。大家知道Olap多維模型的圆，隨著維度的增加事實(shí)表的數(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è)計(jì)多維挖掘分析數(shù)據(jù)產(chǎn)品背后的技術(shù)就是搜索引擎實(shí)現(xiàn)的），現(xiàn)在應(yīng)該也有新技術(shù)出現(xiàn)了來解決類似的問題挡鞍。
(點(diǎn)擊放大圖像)
上圖為2012年產(chǎn)品UI之一骑歹。
(點(diǎn)擊放大圖像)
[圖片上傳中。墨微。道媚。（7）]
上圖是2011-2012年該產(chǎn)品系列背后當(dāng)時使用的技術(shù)
互聯(lián)網(wǎng)業(yè)務(wù)特點(diǎn)業(yè)務(wù)垂直拆分非常細(xì)，比如一個用戶注冊翘县、密碼找回的流程有可能存在好幾個產(chǎn)品負(fù)責(zé)同一個業(yè)務(wù)流程不同環(huán)節(jié)最域，相關(guān)的一個策略、產(chǎn)品feature快速迭代上線等等都要數(shù)據(jù)評估锈麸。數(shù)據(jù)從前端埋點(diǎn)到采集然后再由各個環(huán)節(jié)到數(shù)據(jù)平臺镀脂，再有數(shù)據(jù)分析師或各業(yè)務(wù)部門去使用，基本拉長了時間周期忘伞。需求部門與實(shí)施部門能力和經(jīng)驗(yàn)有千差萬別的需求薄翅，造成了懂技術(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ù)特點(diǎn)是變化非常迅速的育勺，能穩(wěn)定的業(yè)務(wù)達(dá)到65%算對數(shù)據(jù)平臺是個福音了（根據(jù)對某寶寶的印象）剩余的業(yè)務(wù)變化迅速但荤，必然導(dǎo)致數(shù)據(jù)模型快速上下線。
Kimball老人家提出的維度建模（備注怀大，在本系列發(fā)展史得第一篇有介紹）圍繞業(yè)務(wù)模型能夠非常直觀的表達(dá)出業(yè)務(wù)的數(shù)據(jù)關(guān)系纱兑，但是在互聯(lián)網(wǎng)NOSQL犧牲掉了關(guān)系型數(shù)據(jù)庫的一致性呀闻、完整性等等很多東西化借。維度數(shù)據(jù)模型又基于這些大數(shù)據(jù)技術(shù)的，所以進(jìn)化的更加輕量級與基于細(xì)節(jié)數(shù)據(jù)的維度退化建模（原有的緩慢變化維捡多、快速變化維蓖康、大維、迷你維垒手、父子維、雪花維為了適應(yīng)互聯(lián)網(wǎng)的大數(shù)據(jù)Nosql處理技術(shù)進(jìn)行反規(guī)范化、化&數(shù)據(jù)冗余設(shè)計(jì)晤愧。
退化維度的反規(guī)范化設(shè)計(jì)一方面可以把一條查詢語句所需要的所有數(shù)據(jù)組合起來放到一個地方存儲 Key values 的方式（比如說商品有不同類型武翎，每一種類型商品又有自己的不同屬性鳖悠，可以采用一對多、多對多的方式存儲优妙，例如把一個多維映射為一個Key value）乘综。
講到互聯(lián)網(wǎng)數(shù)據(jù)平臺就要提數(shù)據(jù)模型，提了數(shù)據(jù)模型就要提Nosql技術(shù)套硼，
(點(diǎn)擊放大圖像)
上圖來自Nosql文檔系列的一幅圖
Nosql 是大數(shù)據(jù)處理的特征之一卡辰。互聯(lián)網(wǎng)數(shù)據(jù)平臺數(shù)據(jù)模型與NoSql技術(shù)還是蠻緊密的邪意。這里有外文講解Nosql Data modeling technigues 從技術(shù)角度講解非常詳（https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/）九妈。
因?yàn)榍斑吿岬降拇髷?shù)據(jù)平臺技術(shù)特性決定了傳統(tǒng)edw模型、維度模型直接在互聯(lián)網(wǎng)數(shù)據(jù)大數(shù)據(jù)平臺部署或許還有“好些未知”障礙等待大家去克服雾鬼。同時在傳統(tǒng)數(shù)據(jù)建模用到的一些方法經(jīng)過互聯(lián)網(wǎng)熏陶或許演進(jìn)成一種新的數(shù)據(jù)產(chǎn)品或方案吧萌朱。
到此為止“我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史”上下共四篇與大家分享完畢，這個寫作前后經(jīng)歷剛好一個月左右策菜，算是對自己數(shù)據(jù)從業(yè)經(jīng)歷回顧之一吧嚷兔。在知識的整理中很多都是蜻蜓點(diǎn)水，每個知識域都是一個非常深的專業(yè)方向做入，自己涉足很膚淺冒晰，在文章中分享不足之處請各位讀者見諒！竟块！
個人郵箱是5592094@qq.com 歡迎電郵交流壶运。
接下來我會進(jìn)入數(shù)據(jù)產(chǎn)品這個領(lǐng)域的分享，當(dāng)年車品覺老師自豪的作品之一“黃金策”浪秘，我是數(shù)據(jù)產(chǎn)品經(jīng)理蒋情。（ps：自己躲在墻角拿車品覺老師往自己臉上貼金了）。
后記
有一次數(shù)據(jù)產(chǎn)品神策的創(chuàng)始人兼好友@桑文鋒＠SensorsData跟我說來做次分享吧耸携，我當(dāng)時出了幾個題目棵癣，最后就選擇了“我所經(jīng)歷的大數(shù)據(jù)平臺“，就形成了大家看到的”我所經(jīng)歷的大數(shù)據(jù)平臺“系列文章.
在整理期間得到了死黨@周愛民夺衍、@神策-桑文峰狈谊、 InfoQ小編@Tina Du 、@betty zhou @Laurel大力協(xié)助沟沙，在這里感謝：尤啊！！
番外篇
這一篇是在24日舉行的分享大家提到的一些問題，經(jīng)過整理算是對正文的補(bǔ)充吧埃仪，從互聯(lián)網(wǎng)敏捷數(shù)據(jù)模型等角度做了較深入的細(xì)節(jié)介紹腾降。同時在數(shù)據(jù)產(chǎn)品方面的回答包含了一點(diǎn)未來寫作篇“數(shù)據(jù)產(chǎn)品”系列的一點(diǎn)內(nèi)容。
1****举哟，傳統(tǒng)我們做BI的呜袁，做數(shù)據(jù)展現(xiàn)會建模后以pivot展現(xiàn)cube數(shù)據(jù)越除，不知道現(xiàn)在互聯(lián)網(wǎng)公司數(shù)據(jù)展示如何做的敞临？第三方工具還是用API取數(shù)據(jù)平臺里的數(shù)據(jù)催享？adhoc報(bào)表及靈活更換維度的時候web端一般是怎么做的？
松子老師：剛才文章中提到了比如傳統(tǒng)行業(yè)的多維數(shù)據(jù)模型cube哟绊。在互聯(lián)網(wǎng)采用的曲線救國方式解決的因妙。 在分享中我給出了幾個圖。就是通過搜索引擎曲線救國方式實(shí)現(xiàn)類似Olap的模擬票髓。
在這塊的模型的處理上采用的是維度退化處理攀涵。通過反規(guī)范化，數(shù)據(jù)項(xiàng)洽沟、數(shù)據(jù)冗余去處理以故。在前端做特殊處理。
這個當(dāng)時產(chǎn)品原型之一：
(點(diǎn)擊放大圖像)
這是一個2011年-2012年左右的數(shù)據(jù)產(chǎn)品裆操，當(dāng)時算是即時計(jì)算的一種怒详。不過已經(jīng)過去好幾年了，當(dāng)今新技術(shù)下Olap 引擎應(yīng)該有很好的提升踪区。
目前我知道的家互聯(lián)網(wǎng)公司昆烁，在前端展現(xiàn)有使用第三方套件比如spagoBi、pentaho 等 有自己設(shè)計(jì)開發(fā)定制化數(shù)據(jù)前端展現(xiàn)缎岗。比如我剛開始分享的那兩個之前在去哪兒網(wǎng)設(shè)計(jì)的數(shù)據(jù)平臺內(nèi)部界面之一静尼，當(dāng)然數(shù)據(jù)產(chǎn)品是另一個話題了，通過對數(shù)據(jù)分析抽象指標(biāo)传泊、分析模型鼠渺、用戶使用功能與流程、未來規(guī)劃考慮用戶體驗(yàn)去設(shè)計(jì)眷细。
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
[圖片上傳中拦盹。。溪椎。（11）]
(點(diǎn)擊放大圖像)
2****普舆，互聯(lián)網(wǎng)財(cái)經(jīng)類公司，業(yè)務(wù)包括財(cái)經(jīng)網(wǎng)站池磁、基金穆咐、股票码邻、金融等，這類公司的數(shù)據(jù)倉庫模型應(yīng)該如何設(shè)計(jì)窘行？特點(diǎn)和注意事項(xiàng)是什么芯杀？案例介紹端考？十分感謝雅潭。
松子老師：我自己經(jīng)歷過的是互聯(lián)網(wǎng)金融以及移動互聯(lián)網(wǎng)行。對這兩塊比較清楚却特》龉互聯(lián)網(wǎng)金融起因?yàn)闃I(yè)務(wù)的特性是類金融類的，與銀行有些地方是相似的裂明。
比如大約在2012年前支付寶業(yè)務(wù)特點(diǎn)涉及類金融交易：充值椿浓、提現(xiàn)、賬務(wù)管理類電子商務(wù)：購物交易過程變更闽晦、實(shí)際交易（對B機(jī)票扳碍、對C水電等） 非純電子商務(wù)；純金融仙蛉；個人信用笋敞，理財(cái)類。系統(tǒng)之間依賴度較為復(fù)雜荠瘪，垂直依賴（業(yè)務(wù)與核心）跨層依賴（跨過交易到賬務(wù)）夯巷。
在設(shè)計(jì)方法上還是采用維度模型設(shè)計(jì)方式。底層是數(shù)據(jù)驅(qū)動為向?qū)О梗Y(jié)合業(yè)務(wù)需求驅(qū)動趁餐，通過簡單、退化維度的方式拉寬表結(jié)構(gòu)篮绰。
底層采用松耦合設(shè)計(jì)澎怒。主題之間是松耦合方式。至體內(nèi)采用細(xì)粒度退化維度阶牍。
在主題域上的的設(shè)計(jì)基本參考了OMG的數(shù)據(jù)倉庫元數(shù)據(jù)設(shè)計(jì)CWM模型喷面、IBM 的fsdm金融模型、還有新巴塞爾資本協(xié)議（Basel II Capital Accord）需提供數(shù)據(jù)規(guī)范去的設(shè)計(jì)走孽。所以數(shù)據(jù)模型是五層的結(jié)構(gòu)惧辈。
在細(xì)節(jié)處理上，增量ODS層數(shù)據(jù)和前一天DWD相關(guān)表進(jìn)行 merge處理磕瓷。
在一些層次上盒齿，基本聚合、匯總增加派生事實(shí)表（簡單一句話退化為度打?qū)挘├场Ｈ缓蟀凑諛I(yè)務(wù)主體合并信息等猴誊。
比如開始給大家分享的那張圖：
(點(diǎn)擊放大圖像)
[圖片上傳中教届。。。（13）]
在維度模型退化處理時卫漫，要注意最細(xì)粒度數(shù)據(jù)保留、不同層次的數(shù)據(jù)支持?jǐn)?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ù)模型趣倾。
這種元數(shù)據(jù)驅(qū)動工具型數(shù)據(jù)產(chǎn)品我會在未來數(shù)據(jù)產(chǎn)品系列中做詳細(xì)介紹的。
3****某饰，互聯(lián)網(wǎng)企業(yè)大數(shù)據(jù)平臺的發(fā)展歷程是怎樣的儒恋？
松子老師：這個我相信應(yīng)該是傳統(tǒng)數(shù)據(jù)平臺朋友提到的。傳統(tǒng)行業(yè)數(shù)據(jù)平臺架構(gòu)演進(jìn)我總結(jié)簡單一句話說“基本上可以分為五個時代黔漂、四種架構(gòu)”诫尽，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與類型暴增的特點(diǎn)，從高階架構(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é)下來用戶特點(diǎn)：
(點(diǎn)擊放大圖像)
[圖片上傳中。观蜗。臊恋。（14）]
更加詳細(xì)的每一代數(shù)據(jù)平臺建設(shè)、服務(wù)角色特點(diǎn)您可以看我這個系列文章的第三篇墓捻，http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-paet02
4****抖仅，有沒有好的元數(shù)據(jù)管理工具推薦？主要偏向數(shù)據(jù)字典與血統(tǒng)等砖第。
松子老師：元數(shù)據(jù)以前目前沒有太多的好管理工具撤卢。以前是在支付寶是我自己設(shè)計(jì)的一個數(shù)據(jù)產(chǎn)品。第一版自己用Delphi 開發(fā)的梧兼。
（圖很多：）
(點(diǎn)擊放大圖像)
[圖片上傳中放吩。。羽杰。（15）]
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
[圖片上傳中渡紫。。。（17）]
(點(diǎn)擊放大圖像)
[圖片上傳中。灯蝴。。（18）]
(點(diǎn)擊放大圖像)
[圖片上傳中唧喉。。。（19）]
以前被逼的自己寫了一個欣喧，通過解析腌零，實(shí)現(xiàn)了字段級的血緣影響分析梯找。這只是第二步唆阿，后來又把running 信息給搞了進(jìn)來。還有分享時提到的模型信息锈锤、整個閉環(huán)的分類信息驯鳖。
這是一個分支：
(點(diǎn)擊放大圖像)
[圖片上傳中。久免。浅辙。（20）]
但是我們實(shí)現(xiàn)了字段級解析準(zhǔn)確率達(dá)到了94%左右。有細(xì)微的錯誤就人工revew一遍阎姥。
5. ****松子老師记舆，數(shù)據(jù)管控的數(shù)據(jù)質(zhì)量部分是怎么處理的呢？
松子老師： 數(shù)據(jù)管控呼巴， 這方面我不太懂的，但是數(shù)據(jù)質(zhì)量衣赶，這玩意可大可小的诊赊。比如像在分享時說過的，在移動互聯(lián)網(wǎng)的數(shù)據(jù)質(zhì)量處理方式可以由原有的ETL(ELT)階段前置到業(yè)務(wù)系統(tǒng)去解決府瞄，比如移動互聯(lián)網(wǎng)的App log 日志碧磅，日志標(biāo)準(zhǔn)化后事件模型”存儲來解決。那非app 日志類如何解決呢比如Payment遵馆、order等鲸郊，數(shù)據(jù)質(zhì)量比較考慮的可以只做到監(jiān)控。
我來分享個圖货邓。剛好是我設(shè)計(jì)數(shù)據(jù)質(zhì)量產(chǎn)品時搞的秆撮，理清數(shù)據(jù)質(zhì)量的問題：
(點(diǎn)擊放大圖像)
[圖片上傳中。逻恐。像吻。（21）]
(點(diǎn)擊放大圖像)
[圖片上傳中。复隆。拨匆。（22）]
(點(diǎn)擊放大圖像)
[圖片上傳中济似。呈队。。（23）]
只要數(shù)據(jù)進(jìn)入倉庫與應(yīng)用體系围段，處理起來就比較困難了，所以在數(shù)據(jù)平臺階段最好是通過監(jiān)控台腥、前置去解決宏赘。目前數(shù)據(jù)質(zhì)量確實(shí)難以100%由事后搞到事前去處理。我對數(shù)據(jù)平臺與數(shù)據(jù)產(chǎn)品的建設(shè)就是實(shí)用為主黎侈。怎么實(shí)用怎么來察署。我是比較現(xiàn)實(shí)的實(shí)用主義者。
6. ****能否分享一些數(shù)據(jù)產(chǎn)品種類及實(shí)例：
松子老師：在前邊五個問題峻汉、以及文章中又都涉及數(shù)據(jù)產(chǎn)品實(shí)力的一些分享贴汪。
提到數(shù)據(jù)產(chǎn)品的分類我就想把這個圖發(fā)出來。
自己認(rèn)為沒有特別明確的劃分線休吠，但是數(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工具酝蜒、資源管控等等誊辉。
面向用戶功能有報(bào)表型、多維型數(shù)據(jù)產(chǎn)品亡脑、定制化數(shù)據(jù)產(chǎn)品堕澄、挖掘型數(shù)據(jù)產(chǎn)品。
面向內(nèi)部用戶霉咨、外部個人用戶蛙紫、外部企業(yè)用戶又有不同的分類。
根據(jù)業(yè)務(wù)又可以劃分很多途戒，面向C類用戶坑傅、面向B類商戶、金融風(fēng)險(xiǎn)等等
從近幾年的數(shù)據(jù)產(chǎn)品來看喷斋，是更好的輔助用戶的做決策的一種產(chǎn)品形態(tài)唁毒，在用戶的決策與行動中充當(dāng)信息的分析者與價值使用者；數(shù)據(jù)產(chǎn)品有個自己的共性：由解決的一個實(shí)際的業(yè)務(wù)問題出發(fā)星爪，分解出的分析指標(biāo)哀卫，分析模型往扔，分析流程組成，再考慮到功能易用性叉庐，未來功能擴(kuò)展究珊，考慮用戶對數(shù)據(jù)易用性（比如數(shù)據(jù)的呈現(xiàn)層次，不可能一次把所有數(shù)據(jù)的呈現(xiàn)給用戶）來組成的。
(點(diǎn)擊放大圖像)
[圖片上傳中。窖杀。。（24）]
7. ****銀行業(yè)從傳統(tǒng)的ods到edw再到大數(shù)據(jù)平臺這塊過渡裙士，模型如何建設(shè)入客？平臺優(yōu)勢如何發(fā)揮？
松子老師：這個問題還是有些難度的潮售，自己回答的可能有些片面痊项。首先我們清醒的清楚“大數(shù)據(jù)”是什么锅风？再次不同的場景可以采用不同的技術(shù)去解決酥诽。
“大數(shù)據(jù)”，拆開來看大皱埠、數(shù)據(jù)肮帐，大可以是指的數(shù)據(jù)源結(jié)構(gòu)簡單（ps 如果了解過當(dāng)代對大數(shù)據(jù)的定義就知道四個特性）但是量級夠大，比如清算边器、結(jié)算训枢、對公、對私忘巧、中間業(yè)務(wù)等等每一個拿出來都是幾十T恒界，但是這些業(yè)務(wù)數(shù)據(jù)都是保存?zhèn)鹘y(tǒng)的關(guān)系型數(shù)據(jù)庫中如DB2、Oracle砚嘴、MSsql中十酣，因?yàn)樵跀?shù)據(jù)平臺存儲是通過準(zhǔn)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ù)的去演進(jìn)解決虾宇。（最早時我的是中信銀行、光大銀行在2011年左右開始考慮Hadoop技術(shù)如绸，后來不知道如何了）嘱朽。
但是互聯(lián)網(wǎng)的數(shù)據(jù)平臺技術(shù)大都是NOSQL模式，犧牲掉了傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)一致性怔接、完整性教届、唯一索引等等，只干性能的事情（當(dāng)然除了性能泣洞、可擴(kuò)展性也是的）.
原有在傳統(tǒng)數(shù)據(jù)平臺模型設(shè)計(jì)上可以考慮的一些通過主外鍵使兔、唯一索引做一些業(yè)務(wù)約束的方法，在nosql上統(tǒng)統(tǒng)的都沒有了，這些約束必須放到數(shù)據(jù)加工階段去想辦法做檢查凛膏。傳統(tǒng)數(shù)據(jù)平臺如果在Insert杨名、update數(shù)據(jù)時違反了業(yè)務(wù)約束可以做報(bào)警或異常處理，但是在Nosql的平臺上要求ETL 去手動遵守這些規(guī)則檢查猖毫。但是有時ETL開發(fā)根本不遵守的台谍，僅僅是兩個表關(guān)聯(lián)起來，也可能忘記按照某一個業(yè)務(wù)唯一索引做去重操作吁断。簡單說趁蕊，原有靠關(guān)系型數(shù)據(jù)庫本身機(jī)制去做檢查一些規(guī)則變?yōu)槿斯ぃ優(yōu)槿斯ぞ蜁稿e仔役。
從關(guān)系型數(shù)據(jù)平臺往Nosql數(shù)據(jù)平臺遷移時掷伙，尤其是對傳統(tǒng)行業(yè)的業(yè)務(wù)來說，在模型設(shè)計(jì)階段又兵、以及給出的ETL口徑要考慮更多的業(yè)務(wù)規(guī)則檢查任柜，其次要考慮更多的維度退化、多冗余沛厨、表打?qū)捥幚碇娴亍：唵握f就是發(fā)揮數(shù)據(jù)平臺的計(jì)算能力同時要更加的各方面確保數(shù)據(jù)準(zhǔn)確安全可靠。
數(shù)據(jù)模型ODS 到EDW 這塊的設(shè)計(jì)方法百度上留下的文檔資料太多的了逆皮，請這位提問的老師百度吧宅粥。
**8****．大數(shù)據(jù)****倉庫****中如何做快速****維處****理？互****聯(lián)****網(wǎng)數(shù)****倉****數(shù)據(jù)****質(zhì)****量不好如何****對****數(shù)电谣，如何確立****標(biāo)****準(zhǔn)的****對****數(shù)口徑秽梅？******
松子老師：快速變化維度可以轉(zhuǎn)化為緩慢變化為來出來，我自己理解的快速維度是相對于緩慢維度參照的來說的辰企。
舉個例子风纠，年齡-轉(zhuǎn)化為天數(shù)可以是定義快速變化維度，因?yàn)槊刻於荚谧兓蚊场Ｎ覀兛梢园涯挲g退化為區(qū)間維度來處理竹观，還可以把年齡做成動態(tài)維度來處理，事實(shí)表中保存的就是實(shí)際的出生年月并打?qū)挶砬彼鳎挲g(天)通過計(jì)算方式來處理臭增。還有種方法通過對代理鍵的方式來處理。
我目前也不知道對數(shù)據(jù)的標(biāo)準(zhǔn)是什么竹习。但是我自己用的方法派继，把一個指標(biāo)的整個數(shù)據(jù)流向切出幾個關(guān)鍵點(diǎn)通過SQL去實(shí)現(xiàn)對數(shù)赠潦，看波動振幅带族，波動曲線。同時還會比如發(fā)不通的版本的小流量測試的方式來做數(shù)據(jù)校對瞎领。
9****． 做為數(shù)據(jù)行業(yè)從業(yè)者，需要掌握哪些重要的基礎(chǔ)知識随夸？另：如果從零開始建立一個數(shù)據(jù)平臺九默，需要哪些資源配置（人，財(cái)宾毒，物驼修，技術(shù)）？大致總投資額度多少诈铛？如果同行產(chǎn)品間多種來源的數(shù)據(jù)乙各，可有成熟的解決方案？謝謝…
松子老師：這個問題太宏觀了幢竹。作為數(shù)據(jù)行業(yè)從業(yè)者耳峦，需要掌握哪些重要基礎(chǔ)知識，這個是要看從事具體數(shù)據(jù)域的垂直行業(yè)妨退。
比如說 數(shù)據(jù)開發(fā)妇萄、數(shù)據(jù)模型、數(shù)據(jù)產(chǎn)品咬荷、數(shù)據(jù)分析師、數(shù)據(jù)運(yùn)營轻掩、數(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ù)目標(biāo)不太明確下，難以確定方案扮惦，人員配置上選用不同技術(shù)方案去搭建的配置是不太一樣的臀蛛，比如說傳統(tǒng)平臺來講，運(yùn)維崖蜜、DBA浊仆、數(shù)據(jù)開發(fā)、數(shù)據(jù)模型豫领、報(bào)表人員兔沃。
從互聯(lián)網(wǎng)數(shù)據(jù)平臺基本配置上嗤瞎，數(shù)據(jù)架構(gòu)師、運(yùn)維、底層大數(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ù)。
10. Standalone****模式下衫哥，Model.save(Path)怎么一直提示錯誤茎刚，是不是配置Spark時需要將Hdfs的配置引進(jìn)來啊～？表示初學(xué)Spark
松子老師：這個問題有點(diǎn)超出我的能力范圍了撤逢，所以對不起回答不了膛锭。
我本身不是做技術(shù)的。僅知道一點(diǎn)技術(shù)名詞蚊荣。
11. ****傳統(tǒng)銀行業(yè)數(shù)據(jù)模型什么時候會走向互聯(lián)網(wǎng)模式呢初狰？目前在傳統(tǒng)銀行數(shù)據(jù)平臺的產(chǎn)品是不是特別多？
松子老師：這個問題我自己就不知道了互例，或許是傳統(tǒng)銀行在數(shù)據(jù)平臺的實(shí)施上全面用互聯(lián)網(wǎng)的Nosql大數(shù)據(jù)處理技術(shù)吧奢入。至于說傳統(tǒng)銀行數(shù)據(jù)模型用現(xiàn)有的互聯(lián)網(wǎng)數(shù)據(jù)模型理念去設(shè)計(jì)是否完全可行，數(shù)據(jù)一致性媳叨、高準(zhǔn)確性通過更多的方案去保證腥光。
首先我需要確定一下這個產(chǎn)品是否指的“數(shù)據(jù)產(chǎn)品”。
如果是數(shù)據(jù)產(chǎn)品糊秆，那其實(shí)傳統(tǒng)行業(yè)數(shù)據(jù)平臺本身就有一些數(shù)據(jù)產(chǎn)品了武福，而且也都是存在的。數(shù)據(jù)產(chǎn)品自從數(shù)據(jù)倉庫出現(xiàn)以來它其實(shí)一直都存在的痘番，只不過是近幾年因?yàn)榛ヂ?lián)網(wǎng)特別愛制造“流行詞“把數(shù)據(jù)產(chǎn)品這個詞給放大了捉片。互聯(lián)網(wǎng)是得數(shù)據(jù)產(chǎn)品從早期的重量級逐漸進(jìn)化為輕量級夫偶、從大而全的解決方案逐漸演進(jìn)為因小而美界睁。
我來給出幾組例子，大約從2004年到現(xiàn)在的幾組數(shù)據(jù)產(chǎn)品的例子
(點(diǎn)擊放大圖像)
[圖片上傳中兵拢。往扔。入挣。（25）]
(點(diǎn)擊放大圖像)
[圖片上傳中霹购。。嘹履。（26）]
(點(diǎn)擊放大圖像)
[圖片上傳中。债热。砾嫉。（27）]
(點(diǎn)擊放大圖像)
[圖片上傳中。窒篱。焕刮。（28）]
(點(diǎn)擊放大圖像)
[圖片上傳中。墙杯。配并。（29）]
(點(diǎn)擊放大圖像)
[圖片上傳中。高镐。溉旋。（30）]
(點(diǎn)擊放大圖像)
[圖片上傳中。嫉髓。观腊。（31）]
你可以分類一下，這些數(shù)據(jù)產(chǎn)品的特點(diǎn)是什么算行？滿足了用戶怎么樣的痛點(diǎn)需求梧油？滿足了用戶怎么樣的使用流程。
12 ****纱意。傳統(tǒng)行業(yè)的數(shù)據(jù)倉庫從業(yè)人員婶溯，如果轉(zhuǎn)到互聯(lián)網(wǎng)行業(yè)，應(yīng)該學(xué)習(xí)哪些技能偷霉？
松子老師：這個問題你可以百度搜索“大數(shù)據(jù)職位所需要的數(shù)據(jù)技能” http://blog.jobbole.com/99039/ 這篇文章。自己覺得人家回答的比我專業(yè)褐筛。//
我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史（四）：互聯(lián)網(wǎng)時代 ? 下篇
http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-internet-age
編者按：本文是松子（李博源）的大數(shù)據(jù)平臺發(fā)展史系列文章的第四篇（共四篇）类少，本系列以獨(dú)特的視角，比較了非互聯(lián)網(wǎng)和互聯(lián)網(wǎng)兩個時代以及傳統(tǒng)行業(yè)與非傳統(tǒng)行業(yè)渔扎。是對數(shù)據(jù)平臺發(fā)展的一個回憶硫狞，對非互聯(lián)網(wǎng)、互聯(lián)網(wǎng)晃痴，從數(shù)據(jù)平臺的用戶角度残吩、數(shù)據(jù)架構(gòu)演進(jìn)、模型等進(jìn)行了闡述倘核。
在互聯(lián)網(wǎng)時代被弱化的數(shù)據(jù)模型
談起數(shù)據(jù)模型就不得不提傳統(tǒng)數(shù)據(jù)平臺架構(gòu)發(fā)展井氢，我相信很多朋友都曉得傳統(tǒng)數(shù)據(jù)平臺的知識羽德，其架構(gòu)演進(jìn)簡單一句話說“基本上可以分為五個時代、四種架構(gòu)”苫纤，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與數(shù)據(jù)源類型多樣化特點(diǎn)，從高階架構(gòu)上來看大約從傳統(tǒng)數(shù)據(jù)平臺第三代架構(gòu)開始延續(xù)的唆缴，但是往后的發(fā)展從我自己的這一點(diǎn)知識上很難對互聯(lián)網(wǎng)的數(shù)據(jù)平臺做架構(gòu)歸類。
但是從數(shù)據(jù)平臺建設(shè)與服務(wù)角色上還是有章可循的。就像上篇分享到那樣深胳，類比兩個行業(yè)，互聯(lián)網(wǎng)企業(yè)中員工年齡比非互聯(lián)網(wǎng)企業(yè)的要年輕铜犬、受教育程度舞终、對計(jì)算機(jī)的焦慮程度明顯比傳統(tǒng)企業(yè)要低、還偶遇其它各方面的緣故癣猾，導(dǎo)致了數(shù)據(jù)平臺所面對用戶群體與非互聯(lián)網(wǎng)數(shù)據(jù)平臺有所差異化敛劝。
傳統(tǒng)行業(yè)與互聯(lián)網(wǎng)行業(yè)數(shù)據(jù)平臺用戶特性我只選擇前文章的兩張圖來表示
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
在傳統(tǒng)數(shù)據(jù)平臺要背后有一個完整數(shù)據(jù)倉庫團(tuán)隊(duì)去服務(wù)業(yè)務(wù)方，業(yè)務(wù)方嗷嗷待哺的等待被動方式去滿足煎谍。中低層數(shù)據(jù)基本不會對業(yè)務(wù)方開放攘蔽，所以不管數(shù)據(jù)模型采用何種建模方式，主要滿足當(dāng)時數(shù)據(jù)架構(gòu)規(guī)劃即可呐粘。
互聯(lián)網(wǎng)業(yè)務(wù)的快速發(fā)展使得大家已經(jīng)從經(jīng)營满俗、分析的訴求重點(diǎn)轉(zhuǎn)為數(shù)據(jù)化的精細(xì)運(yùn)營上，如何做好精細(xì)化運(yùn)營問題上來作岖，當(dāng)資源不夠時用戶就叫喊唆垃，甚至有的業(yè)務(wù)方會挽起袖子來自己參與到從數(shù)據(jù)整理、加工痘儡、分析階段辕万。
此時呢，原有建設(shè)數(shù)據(jù)平臺的多個角色（數(shù)據(jù)開發(fā)沉删、模型設(shè)計(jì)）可能轉(zhuǎn)為對其它非專業(yè)使用數(shù)據(jù)方渐尿，做培訓(xùn)、咨詢與落地矾瑰，寫更加適合當(dāng)前企業(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àn)椴粚I(yè)性凉夯，導(dǎo)致數(shù)據(jù)質(zhì)量問題、重復(fù)對分?jǐn)?shù)據(jù)浪費(fèi)存儲與資源采幌、口徑多樣化劲够、編碼不統(tǒng)一、命名問題等等原因。數(shù)據(jù)質(zhì)量逐漸變成一個特別突出的問題。
傳統(tǒng)企業(yè)的數(shù)據(jù)源基本來自excel获洲、表格绍些、DB系統(tǒng)等炒瘸，但在互聯(lián)網(wǎng)有網(wǎng)站點(diǎn)擊流日志淤堵、視頻、音頻顷扩、圖片數(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ù)有些力不從心婶芭。
當(dāng)數(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è)也有自己特點(diǎn)拒炎，傳統(tǒng)行業(yè)所涉及數(shù)據(jù)模型這個領(lǐng)域涉及的很多內(nèi)容在互聯(lián)網(wǎng)變成以其他的曲線救國的方式存在了。
在互聯(lián)網(wǎng)曲線救國新解決
回顧在傳統(tǒng)行業(yè)數(shù)據(jù)平臺中挨务，不管兩位大師爭論點(diǎn)數(shù)據(jù)模型的設(shè)計(jì)采用那種范式（Bill Inmon的EDW的原則是準(zhǔn)三范式的設(shè)計(jì)击你、Ralph kilmbal是星型結(jié)構(gòu)）但是都要非常重視數(shù)據(jù)源的質(zhì)量問題。所以傳統(tǒng)行業(yè)的數(shù)據(jù)模型會全盤考慮數(shù)據(jù)質(zhì)量問題谎柄，并通過數(shù)據(jù)抽樣分析給出合適的清洗口徑丁侄。
(點(diǎn)擊放大圖像)
上圖來自我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ù)”對一年的還是不準(zhǔn)的）。在應(yīng)對數(shù)據(jù)的質(zhì)量問題鸵钝，目前互聯(lián)網(wǎng)有些做法是把數(shù)據(jù)標(biāo)準(zhǔn)化前置到業(yè)務(wù)數(shù)據(jù)產(chǎn)生就做糙臼，從根源上去杜絕數(shù)據(jù)質(zhì)量，但是這種場景比較實(shí)用在Log 日志的數(shù)據(jù)源中恩商，比如移動互聯(lián)網(wǎng)最近流行的基于事件模型“Event”模型变逃，在日志產(chǎn)生時就規(guī)定好存儲格式（備注：大家度娘搜索墙歪，“學(xué)習(xí)筆記：The Log（我所讀過的最好的一篇分布式技術(shù)文章）” 對這個講解很詳細(xì)）柠并。
在傳統(tǒng)行業(yè)腰池，目前還是以混合模型設(shè)計(jì)方式為主弦讽。在互聯(lián)網(wǎng)的我所接觸的一些業(yè)務(wù)，在參照傳統(tǒng)數(shù)據(jù)模型方法論基礎(chǔ)上逐步演進(jìn)適合互聯(lián)網(wǎng)數(shù)據(jù)的數(shù)據(jù)模型方法凰棉。
比如互聯(lián)網(wǎng)金融等一些業(yè)務(wù)會參考傳統(tǒng)金融行業(yè)對主題域的劃分损拢、OMG數(shù)據(jù)倉庫元數(shù)據(jù)管理CWM模型、FSDM金融模型撒犀，再進(jìn)一步考慮大數(shù)據(jù)處理特性去進(jìn)行設(shè)計(jì)福压，所有從Hight Level 數(shù)據(jù)架構(gòu)圖看到主題層次劃分與傳統(tǒng)第三代數(shù)據(jù)倉庫還是很多相似之處，當(dāng)然模型架構(gòu)也有分三層或舞、四層荆姆、五層的。
不同的地方模型細(xì)節(jié)處理上已經(jīng)完全不一樣映凳，比如數(shù)據(jù)的多樣性胆筒、拉寬事實(shí)表、度量值單獨(dú)存儲诈豌、滿足數(shù)據(jù)快速重生仆救、維度的二次降維處理等、增加大量冗余列队询、增加大量派生列派桩，結(jié)合自動化元數(shù)據(jù)來耦合、合并等相關(guān)管理蚌斩。
(點(diǎn)擊放大圖像)
[圖片上傳中铆惑。。送膳。（4）]
上圖是支付寶非常早期數(shù)據(jù)模型
(點(diǎn)擊放大圖像)
上圖是支付寶非常早期數(shù)據(jù)模型
我們常提到的多維模型在大數(shù)據(jù)處理下進(jìn)行了退化維度處理员魏。大家知道Olap多維模型，隨著維度的增加事實(shí)表的數(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è)計(jì)多維挖掘分析數(shù)據(jù)產(chǎn)品背后的技術(shù)就是搜索引擎實(shí)現(xiàn)的）碌补，現(xiàn)在應(yīng)該也有新技術(shù)出現(xiàn)了來解決類似的問題虏束。
(點(diǎn)擊放大圖像)
上圖為2012年產(chǎn)品UI之一。
(點(diǎn)擊放大圖像)
[圖片上傳中厦章。镇匀。。（7）]
上圖是2011-2012年該產(chǎn)品系列背后當(dāng)時使用的技術(shù)
互聯(lián)網(wǎng)業(yè)務(wù)特點(diǎn)業(yè)務(wù)垂直拆分非常細(xì)袜啃，比如一個用戶注冊盟庞、密碼找回的流程有可能存在好幾個產(chǎn)品負(fù)責(zé)同一個業(yè)務(wù)流程不同環(huán)節(jié)盒卸，相關(guān)的一個策略种樱、產(chǎn)品feature快速迭代上線等等都要數(shù)據(jù)評估压彭。數(shù)據(jù)從前端埋點(diǎn)到采集然后再由各個環(huán)節(jié)到數(shù)據(jù)平臺，再有數(shù)據(jù)分析師或各業(yè)務(wù)部門去使用，基本拉長了時間周期。需求部門與實(shí)施部門能力和經(jīng)驗(yàn)有千差萬別的需求，造成了懂技術(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ù)特點(diǎn)是變化非常迅速的，能穩(wěn)定的業(yè)務(wù)達(dá)到65%算對數(shù)據(jù)平臺是個福音了（根據(jù)對某寶寶的印象）剩余的業(yè)務(wù)變化迅速缰猴，必然導(dǎo)致數(shù)據(jù)模型快速上下線产艾。
Kimball老人家提出的維度建模（備注，在本系列發(fā)展史得第一篇有介紹）圍繞業(yè)務(wù)模型能夠非常直觀的表達(dá)出業(yè)務(wù)的數(shù)據(jù)關(guān)系滑绒，但是在互聯(lián)網(wǎng)NOSQL犧牲掉了關(guān)系型數(shù)據(jù)庫的一致性闷堡、完整性等等很多東西。維度數(shù)據(jù)模型又基于這些大數(shù)據(jù)技術(shù)的疑故，所以進(jìn)化的更加輕量級與基于細(xì)節(jié)數(shù)據(jù)的維度退化建模（原有的緩慢變化維杠览、快速變化維、大維纵势、迷你維踱阿、父子維、雪花維為了適應(yīng)互聯(lián)網(wǎng)的大數(shù)據(jù)Nosql處理技術(shù)進(jìn)行反規(guī)范化钦铁、化&數(shù)據(jù)冗余設(shè)計(jì)软舌。
退化維度的反規(guī)范化設(shè)計(jì)一方面可以把一條查詢語句所需要的所有數(shù)據(jù)組合起來放到一個地方存儲 Key values 的方式（比如說商品有不同類型，每一種類型商品又有自己的不同屬性牛曹，可以采用一對多佛点、多對多的方式存儲，例如把一個多維映射為一個Key value）黎比。
講到互聯(lián)網(wǎng)數(shù)據(jù)平臺就要提數(shù)據(jù)模型超营，提了數(shù)據(jù)模型就要提Nosql技術(shù)，
(點(diǎn)擊放大圖像)
上圖來自Nosql文檔系列的一幅圖
Nosql 是大數(shù)據(jù)處理的特征之一阅虫≡忝瑁互聯(lián)網(wǎng)數(shù)據(jù)平臺數(shù)據(jù)模型與NoSql技術(shù)還是蠻緊密的。這里有外文講解Nosql Data modeling technigues 從技術(shù)角度講解非常詳（https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/）。
因?yàn)榍斑吿岬降拇髷?shù)據(jù)平臺技術(shù)特性決定了傳統(tǒng)edw模型、維度模型直接在互聯(lián)網(wǎng)數(shù)據(jù)大數(shù)據(jù)平臺部署或許還有“好些未知”障礙等待大家去克服受啥。同時在傳統(tǒng)數(shù)據(jù)建模用到的一些方法經(jīng)過互聯(lián)網(wǎng)熏陶或許演進(jìn)成一種新的數(shù)據(jù)產(chǎn)品或方案吧。
到此為止“我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史”上下共四篇與大家分享完畢见间，這個寫作前后經(jīng)歷剛好一個月左右，算是對自己數(shù)據(jù)從業(yè)經(jīng)歷回顧之一吧工猜。在知識的整理中很多都是蜻蜓點(diǎn)水米诉，每個知識域都是一個非常深的專業(yè)方向，自己涉足很膚淺篷帅，在文章中分享不足之處請各位讀者見諒Ｊ仿隆！
個人郵箱是5592094@qq.com 歡迎電郵交流魏身。
接下來我會進(jìn)入數(shù)據(jù)產(chǎn)品這個領(lǐng)域的分享惊橱，當(dāng)年車品覺老師自豪的作品之一“黃金策”，我是數(shù)據(jù)產(chǎn)品經(jīng)理箭昵。（ps：自己躲在墻角拿車品覺老師往自己臉上貼金了）税朴。
后記
有一次數(shù)據(jù)產(chǎn)品神策的創(chuàng)始人兼好友@桑文鋒＠SensorsData跟我說來做次分享吧，我當(dāng)時出了幾個題目家制，最后就選擇了“我所經(jīng)歷的大數(shù)據(jù)平臺“正林，就形成了大家看到的”我所經(jīng)歷的大數(shù)據(jù)平臺“系列文章.
在整理期間得到了死黨@周愛民、@神策-桑文峰颤殴、 InfoQ小編@Tina Du 觅廓、@betty zhou @Laurel大力協(xié)助，在這里感謝：ｈ境瘛！
番外篇
這一篇是在24日舉行的分享大家提到的一些問題贤笆，經(jīng)過整理算是對正文的補(bǔ)充吧蝇棉，從互聯(lián)網(wǎng)敏捷數(shù)據(jù)模型等角度做了較深入的細(xì)節(jié)介紹。同時在數(shù)據(jù)產(chǎn)品方面的回答包含了一點(diǎn)未來寫作篇“數(shù)據(jù)產(chǎn)品”系列的一點(diǎn)內(nèi)容芥永。
1****篡殷，傳統(tǒng)我們做BI的，做數(shù)據(jù)展現(xiàn)會建模后以pivot展現(xiàn)cube數(shù)據(jù)埋涧，不知道現(xiàn)在互聯(lián)網(wǎng)公司數(shù)據(jù)展示如何做的板辽？第三方工具還是用API取數(shù)據(jù)平臺里的數(shù)據(jù)？adhoc報(bào)表及靈活更換維度的時候web端一般是怎么做的棘催？
松子老師：剛才文章中提到了比如傳統(tǒng)行業(yè)的多維數(shù)據(jù)模型cube劲弦。在互聯(lián)網(wǎng)采用的曲線救國方式解決的。 在分享中我給出了幾個圖醇坝。就是通過搜索引擎曲線救國方式實(shí)現(xiàn)類似Olap的模擬邑跪。
在這塊的模型的處理上采用的是維度退化處理族铆。通過反規(guī)范化，數(shù)據(jù)項(xiàng)逃贝、數(shù)據(jù)冗余去處理寥粹。在前端做特殊處理。
這個當(dāng)時產(chǎn)品原型之一：
(點(diǎn)擊放大圖像)
這是一個2011年-2012年左右的數(shù)據(jù)產(chǎn)品轴踱，當(dāng)時算是即時計(jì)算的一種症脂。不過已經(jīng)過去好幾年了，當(dāng)今新技術(shù)下Olap 引擎應(yīng)該有很好的提升淫僻。
目前我知道的家互聯(lián)網(wǎng)公司诱篷，在前端展現(xiàn)有使用第三方套件比如spagoBi、pentaho 等 有自己設(shè)計(jì)開發(fā)定制化數(shù)據(jù)前端展現(xiàn)雳灵。比如我剛開始分享的那兩個之前在去哪兒網(wǎng)設(shè)計(jì)的數(shù)據(jù)平臺內(nèi)部界面之一棕所，當(dāng)然數(shù)據(jù)產(chǎn)品是另一個話題了，通過對數(shù)據(jù)分析抽象指標(biāo)细办、分析模型橙凳、用戶使用功能與流程、未來規(guī)劃考慮用戶體驗(yàn)去設(shè)計(jì)笑撞。
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
2****岛啸，互聯(lián)網(wǎng)財(cái)經(jīng)類公司，業(yè)務(wù)包括財(cái)經(jīng)網(wǎng)站茴肥、基金坚踩、股票、金融等瓤狐，這類公司的數(shù)據(jù)倉庫模型應(yīng)該如何設(shè)計(jì)瞬铸？特點(diǎn)和注意事項(xiàng)是什么？案例介紹础锐？十分感謝嗓节。
松子老師：我自己經(jīng)歷過的是互聯(lián)網(wǎng)金融以及移動互聯(lián)網(wǎng)行。對這兩塊比較清楚皆警±剐互聯(lián)網(wǎng)金融起因?yàn)闃I(yè)務(wù)的特性是類金融類的，與銀行有些地方是相似的信姓。
比如大約在2012年前支付寶業(yè)務(wù)特點(diǎn)涉及類金融交易：充值鸵隧、提現(xiàn)、賬務(wù)管理類電子商務(wù)：購物交易過程變更意推、實(shí)際交易（對B機(jī)票豆瘫、對C水電等） 非純電子商務(wù)；純金融菊值；個人信用外驱，理財(cái)類坛掠。系統(tǒng)之間依賴度較為復(fù)雜徒扶，垂直依賴（業(yè)務(wù)與核心）跨層依賴（跨過交易到賬務(wù)）瘫里。
在設(shè)計(jì)方法上還是采用維度模型設(shè)計(jì)方式媒殉。底層是數(shù)據(jù)驅(qū)動為向?qū)┪校Y(jié)合業(yè)務(wù)需求驅(qū)動梦湘，通過簡單贱枣、退化維度的方式拉寬表結(jié)構(gòu)魄藕。
底層采用松耦合設(shè)計(jì)典徊。主題之間是松耦合方式杭煎。至體內(nèi)采用細(xì)粒度退化維度。
在主題域上的的設(shè)計(jì)基本參考了OMG的數(shù)據(jù)倉庫元數(shù)據(jù)設(shè)計(jì)CWM模型卒落、IBM 的fsdm金融模型羡铲、還有新巴塞爾資本協(xié)議（Basel II Capital Accord）需提供數(shù)據(jù)規(guī)范去的設(shè)計(jì)。所以數(shù)據(jù)模型是五層的結(jié)構(gòu)儡毕。
在細(xì)節(jié)處理上也切，增量ODS層數(shù)據(jù)和前一天DWD相關(guān)表進(jìn)行 merge處理。
在一些層次上腰湾，基本聚合雷恃、匯總增加派生事實(shí)表（簡單一句話退化為度打?qū)挘Ｈ缓蟀凑諛I(yè)務(wù)主體合并信息等费坊。
比如開始給大家分享的那張圖：
(點(diǎn)擊放大圖像)
[圖片上傳中倒槐。。附井。（13）]
在維度模型退化處理時讨越，要注意最細(xì)粒度數(shù)據(jù)保留、不同層次的數(shù)據(jù)支持?jǐn)?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ù)模型。
這種元數(shù)據(jù)驅(qū)動工具型數(shù)據(jù)產(chǎn)品我會在未來數(shù)據(jù)產(chǎn)品系列中做詳細(xì)介紹的漫雕。
3****滨嘱，互聯(lián)網(wǎng)企業(yè)大數(shù)據(jù)平臺的發(fā)展歷程是怎樣的？
松子老師：這個我相信應(yīng)該是傳統(tǒng)數(shù)據(jù)平臺朋友提到的浸间。傳統(tǒng)行業(yè)數(shù)據(jù)平臺架構(gòu)演進(jìn)我總結(jié)簡單一句話說“基本上可以分為五個時代太雨、四種架構(gòu)”送巡，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與類型暴增的特點(diǎn)芦圾，從高階架構(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é)下來用戶特點(diǎn)：
(點(diǎn)擊放大圖像)
[圖片上傳中。搏予。熊锭。（14）]
更加詳細(xì)的每一代數(shù)據(jù)平臺建設(shè)、服務(wù)角色特點(diǎn)您可以看我這個系列文章的第三篇雪侥，http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-paet02
4****碗殷，有沒有好的元數(shù)據(jù)管理工具推薦？主要偏向數(shù)據(jù)字典與血統(tǒng)等速缨。
松子老師：元數(shù)據(jù)以前目前沒有太多的好管理工具锌妻。以前是在支付寶是我自己設(shè)計(jì)的一個數(shù)據(jù)產(chǎn)品。第一版自己用Delphi 開發(fā)的旬牲。
（圖很多：）
(點(diǎn)擊放大圖像)
[圖片上傳中仿粹。。原茅。（15）]
(點(diǎn)擊放大圖像)
[圖片上傳中吭历。。员咽。（16）]
(點(diǎn)擊放大圖像)
[圖片上傳中毒涧。。贝室。（17）]
(點(diǎn)擊放大圖像)
[圖片上傳中契讲。。滑频。（18）]
(點(diǎn)擊放大圖像)
[圖片上傳中捡偏。。峡迷。（19）]
以前被逼的自己寫了一個银伟，通過解析，實(shí)現(xiàn)了字段級的血緣影響分析绘搞。這只是第二步彤避，后來又把running 信息給搞了進(jìn)來。還有分享時提到的模型信息夯辖、整個閉環(huán)的分類信息琉预。
這是一個分支：
(點(diǎn)擊放大圖像)
[圖片上傳中圈膏。冠场。。（20）]
但是我們實(shí)現(xiàn)了字段級解析準(zhǔn)確率達(dá)到了94%左右春贸。有細(xì)微的錯誤就人工revew一遍顿仇。
5. ****松子老師裁奇，數(shù)據(jù)管控的數(shù)據(jù)質(zhì)量部分是怎么處理的呢季蚂？
松子老師： 數(shù)據(jù)管控插龄， 這方面我不太懂的，但是數(shù)據(jù)質(zhì)量近速，這玩意可大可小的诈嘿。比如像在分享時說過的，在移動互聯(lián)網(wǎng)的數(shù)據(jù)質(zhì)量處理方式可以由原有的ETL(ELT)階段前置到業(yè)務(wù)系統(tǒng)去解決削葱，比如移動互聯(lián)網(wǎng)的App log 日志永淌，日志標(biāo)準(zhǔn)化后事件模型”存儲來解決。那非app 日志類如何解決呢比如Payment佩耳、order等，數(shù)據(jù)質(zhì)量比較考慮的可以只做到監(jiān)控谭跨。
我來分享個圖干厚。剛好是我設(shè)計(jì)數(shù)據(jù)質(zhì)量產(chǎn)品時搞的，理清數(shù)據(jù)質(zhì)量的問題：
(點(diǎn)擊放大圖像)
[圖片上傳中螃宙。蛮瞄。。（21）]
(點(diǎn)擊放大圖像)
[圖片上傳中谆扎。挂捅。。（22）]
(點(diǎn)擊放大圖像)
[圖片上傳中堂湖。闲先。。（23）]
只要數(shù)據(jù)進(jìn)入倉庫與應(yīng)用體系无蜂，處理起來就比較困難了伺糠，所以在數(shù)據(jù)平臺階段最好是通過監(jiān)控、前置去解決斥季。目前數(shù)據(jù)質(zhì)量確實(shí)難以100%由事后搞到事前去處理训桶。我對數(shù)據(jù)平臺與數(shù)據(jù)產(chǎn)品的建設(shè)就是實(shí)用為主。怎么實(shí)用怎么來酣倾。我是比較現(xiàn)實(shí)的實(shí)用主義者舵揭。
6. ****能否分享一些數(shù)據(jù)產(chǎn)品種類及實(shí)例：
松子老師：在前邊五個問題、以及文章中又都涉及數(shù)據(jù)產(chǎn)品實(shí)力的一些分享躁锡。
提到數(shù)據(jù)產(chǎn)品的分類我就想把這個圖發(fā)出來午绳。
自己認(rèn)為沒有特別明確的劃分線区赵，但是數(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工具灾梦、資源管控等等。
面向用戶功能有報(bào)表型妓笙、多維型數(shù)據(jù)產(chǎn)品若河、定制化數(shù)據(jù)產(chǎn)品、挖掘型數(shù)據(jù)產(chǎn)品寞宫。
面向內(nèi)部用戶萧福、外部個人用戶、外部企業(yè)用戶又有不同的分類辈赋。
根據(jù)業(yè)務(wù)又可以劃分很多鲫忍，面向C類用戶、面向B類商戶钥屈、金融風(fēng)險(xiǎn)等等
從近幾年的數(shù)據(jù)產(chǎn)品來看悟民，是更好的輔助用戶的做決策的一種產(chǎn)品形態(tài)，在用戶的決策與行動中充當(dāng)信息的分析者與價值使用者篷就；數(shù)據(jù)產(chǎn)品有個自己的共性：由解決的一個實(shí)際的業(yè)務(wù)問題出發(fā)射亏，分解出的分析指標(biāo)，分析模型竭业，分析流程組成智润，再考慮到功能易用性，未來功能擴(kuò)展永品，考慮用戶對數(shù)據(jù)易用性（比如數(shù)據(jù)的呈現(xiàn)層次做鹰，不可能一次把所有數(shù)據(jù)的呈現(xiàn)給用戶）來組成的。
(點(diǎn)擊放大圖像)
[圖片上傳中鼎姐。钾麸。。（24）]
7. ****銀行業(yè)從傳統(tǒng)的ods到edw再到大數(shù)據(jù)平臺這塊過渡炕桨，模型如何建設(shè)饭尝？平臺優(yōu)勢如何發(fā)揮？
松子老師：這個問題還是有些難度的献宫，自己回答的可能有些片面祠汇。首先我們清醒的清楚“大數(shù)據(jù)”是什么顷窒？再次不同的場景可以采用不同的技術(shù)去解決桨菜。
“大數(shù)據(jù)”，拆開來看大知态、數(shù)據(jù)，大可以是指的數(shù)據(jù)源結(jié)構(gòu)簡單（ps 如果了解過當(dāng)代對大數(shù)據(jù)的定義就知道四個特性）但是量級夠大立叛，比如清算负敏、結(jié)算、對公秘蛇、對私其做、中間業(yè)務(wù)等等每一個拿出來都是幾十T，但是這些業(yè)務(wù)數(shù)據(jù)都是保存?zhèn)鹘y(tǒng)的關(guān)系型數(shù)據(jù)庫中如DB2赁还、Oracle妖泄、MSsql中，因?yàn)樵跀?shù)據(jù)平臺存儲是通過準(zhǔn)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ù)的去演進(jìn)解決。（最早時我的是中信銀行斑举、光大銀行在2011年左右開始考慮Hadoop技術(shù)，后來不知道如何了）病涨。
但是互聯(lián)網(wǎng)的數(shù)據(jù)平臺技術(shù)大都是NOSQL模式富玷，犧牲掉了傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)一致性、完整性既穆、唯一索引等等赎懦，只干性能的事情（當(dāng)然除了性能、可擴(kuò)展性也是的）.
原有在傳統(tǒng)數(shù)據(jù)平臺模型設(shè)計(jì)上可以考慮的一些通過主外鍵幻工、唯一索引做一些業(yè)務(wù)約束的方法励两，在nosql上統(tǒng)統(tǒng)的都沒有了，這些約束必須放到數(shù)據(jù)加工階段去想辦法做檢查囊颅。傳統(tǒng)數(shù)據(jù)平臺如果在Insert当悔、update數(shù)據(jù)時違反了業(yè)務(wù)約束可以做報(bào)警或異常處理，但是在Nosql的平臺上要求ETL 去手動遵守這些規(guī)則檢查踢代。但是有時ETL開發(fā)根本不遵守的盲憎，僅僅是兩個表關(guān)聯(lián)起來，也可能忘記按照某一個業(yè)務(wù)唯一索引做去重操作胳挎。簡單說饼疙，原有靠關(guān)系型數(shù)據(jù)庫本身機(jī)制去做檢查一些規(guī)則變?yōu)槿斯ぐ媸觯優(yōu)槿斯ぞ蜁稿e眼俊。
從關(guān)系型數(shù)據(jù)平臺往Nosql數(shù)據(jù)平臺遷移時，尤其是對傳統(tǒng)行業(yè)的業(yè)務(wù)來說，在模型設(shè)計(jì)階段午磁、以及給出的ETL口徑要考慮更多的業(yè)務(wù)規(guī)則檢查，其次要考慮更多的維度退化糊识、多冗余彩倚、表打?qū)捥幚怼：唵握f就是發(fā)揮數(shù)據(jù)平臺的計(jì)算能力同時要更加的各方面確保數(shù)據(jù)準(zhǔn)確安全可靠更胖。
數(shù)據(jù)模型ODS 到EDW 這塊的設(shè)計(jì)方法百度上留下的文檔資料太多的了铛铁，請這位提問的老師百度吧。
**8****．大數(shù)據(jù)****倉庫****中如何做快速****維處****理却妨？互****聯(lián)****網(wǎng)數(shù)****倉****數(shù)據(jù)****質(zhì)****量不好如何****對****數(shù)饵逐，如何確立****標(biāo)****準(zhǔn)的****對****數(shù)口徑？******
松子老師：快速變化維度可以轉(zhuǎn)化為緩慢變化為來出來彪标，我自己理解的快速維度是相對于緩慢維度參照的來說的倍权。
舉個例子，年齡-轉(zhuǎn)化為天數(shù)可以是定義快速變化維度捞烟，因?yàn)槊刻於荚谧兓∩Ｎ覀兛梢园涯挲g退化為區(qū)間維度來處理，還可以把年齡做成動態(tài)維度來處理题画，事實(shí)表中保存的就是實(shí)際的出生年月并打?qū)挶砟妫挲g(天)通過計(jì)算方式來處理。還有種方法通過對代理鍵的方式來處理苍息。
我目前也不知道對數(shù)據(jù)的標(biāo)準(zhǔn)是什么缩幸。但是我自己用的方法，把一個指標(biāo)的整個數(shù)據(jù)流向切出幾個關(guān)鍵點(diǎn)通過SQL去實(shí)現(xiàn)對數(shù)竞思，看波動振幅表谊，波動曲線。同時還會比如發(fā)不通的版本的小流量測試的方式來做數(shù)據(jù)校對盖喷。
9****． 做為數(shù)據(jù)行業(yè)從業(yè)者爆办，需要掌握哪些重要的基礎(chǔ)知識？另：如果從零開始建立一個數(shù)據(jù)平臺课梳，需要哪些資源配置（人距辆，財(cái)，物暮刃，技術(shù)）挑格？大致總投資額度多少？如果同行產(chǎn)品間多種來源的數(shù)據(jù)沾歪，可有成熟的解決方案淆储？謝謝…
松子老師：這個問題太宏觀了慨削。作為數(shù)據(jù)行業(yè)從業(yè)者赢底，需要掌握哪些重要基礎(chǔ)知識，這個是要看從事具體數(shù)據(jù)域的垂直行業(yè)立润。
比如說 數(shù)據(jù)開發(fā)、數(shù)據(jù)模型媳板、數(shù)據(jù)產(chǎn)品桑腮、數(shù)據(jù)分析師、數(shù)據(jù)運(yùn)營蛉幸、數(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ù)目標(biāo)不太明確下，難以確定方案升筏，人員配置上選用不同技術(shù)方案去搭建的配置是不太一樣的撑柔，比如說傳統(tǒng)平臺來講，運(yùn)維您访、DBA铅忿、數(shù)據(jù)開發(fā)、數(shù)據(jù)模型灵汪、報(bào)表人員辆沦。
從互聯(lián)網(wǎng)數(shù)據(jù)平臺基本配置上，數(shù)據(jù)架構(gòu)師识虚、運(yùn)維、底層大數(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ù)诡宗。
10. Standalone****模式下，Model.save(Path)怎么一直提示錯誤虏等，是不是配置Spark時需要將Hdfs的配置引進(jìn)來啊～乍桂？表示初學(xué)Spark
松子老師：這個問題有點(diǎn)超出我的能力范圍了，所以對不起回答不了怜俐。
我本身不是做技術(shù)的身堡。僅知道一點(diǎn)技術(shù)名詞。
11. ****傳統(tǒng)銀行業(yè)數(shù)據(jù)模型什么時候會走向互聯(lián)網(wǎng)模式呢拍鲤？目前在傳統(tǒng)銀行數(shù)據(jù)平臺的產(chǎn)品是不是特別多贴谎？
松子老師：這個問題我自己就不知道了，或許是傳統(tǒng)銀行在數(shù)據(jù)平臺的實(shí)施上全面用互聯(lián)網(wǎng)的Nosql大數(shù)據(jù)處理技術(shù)吧季稳。至于說傳統(tǒng)銀行數(shù)據(jù)模型用現(xiàn)有的互聯(lián)網(wǎng)數(shù)據(jù)模型理念去設(shè)計(jì)是否完全可行擅这，數(shù)據(jù)一致性、高準(zhǔn)確性通過更多的方案去保證绞幌。
首先我需要確定一下這個產(chǎn)品是否指的“數(shù)據(jù)產(chǎn)品”蕾哟。
如果是數(shù)據(jù)產(chǎn)品，那其實(shí)傳統(tǒng)行業(yè)數(shù)據(jù)平臺本身就有一些數(shù)據(jù)產(chǎn)品了莲蜘，而且也都是存在的谭确。數(shù)據(jù)產(chǎn)品自從數(shù)據(jù)倉庫出現(xiàn)以來它其實(shí)一直都存在的，只不過是近幾年因?yàn)榛ヂ?lián)網(wǎng)特別愛制造“流行詞“把數(shù)據(jù)產(chǎn)品這個詞給放大了票渠≈鸸互聯(lián)網(wǎng)是得數(shù)據(jù)產(chǎn)品從早期的重量級逐漸進(jìn)化為輕量級、從大而全的解決方案逐漸演進(jìn)為因小而美问顷。
我來給出幾組例子昂秃，大約從2004年到現(xiàn)在的幾組數(shù)據(jù)產(chǎn)品的例子
(點(diǎn)擊放大圖像)
[圖片上傳中。杜窄。肠骆。（25）]
(點(diǎn)擊放大圖像)
[圖片上傳中。塞耕。蚀腿。（26）]
(點(diǎn)擊放大圖像)
[圖片上傳中。扫外。莉钙。（27）]
(點(diǎn)擊放大圖像)
[圖片上傳中。筛谚。磁玉。（28）]
(點(diǎn)擊放大圖像)
[圖片上傳中。驾讲。蚊伞。（29）]
(點(diǎn)擊放大圖像)
[圖片上傳中席赂。窃页。便脊。（30）]
(點(diǎn)擊放大圖像)
[圖片上傳中匆绣。因悲。剿配。（31）]
你可以分類一下恃逻，這些數(shù)據(jù)產(chǎn)品的特點(diǎn)是什么枪狂？滿足了用戶怎么樣的痛點(diǎn)需求桂躏？滿足了用戶怎么樣的使用流程碳想。
12 ****烧董。傳統(tǒng)行業(yè)的數(shù)據(jù)倉庫從業(yè)人員，如果轉(zhuǎn)到互聯(lián)網(wǎng)行業(yè)胧奔，應(yīng)該學(xué)習(xí)哪些技能逊移？
松子老師：這個問題你可以百度搜索“大數(shù)據(jù)職位所需要的數(shù)據(jù)技能” http://blog.jobbole.com/99039/ 這篇文章。自己覺得人家回答的比我專業(yè)龙填。//
我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史（四）：互聯(lián)網(wǎng)時代 ? 下篇
http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-internet-age
編者按：本文是松子（李博源）的大數(shù)據(jù)平臺發(fā)展史系列文章的第四篇（共四篇）胳泉，本系列以獨(dú)特的視角，比較了非互聯(lián)網(wǎng)和互聯(lián)網(wǎng)兩個時代以及傳統(tǒng)行業(yè)與非傳統(tǒng)行業(yè)岩遗。是對數(shù)據(jù)平臺發(fā)展的一個回憶扇商，對非互聯(lián)網(wǎng)、互聯(lián)網(wǎng)宿礁，從數(shù)據(jù)平臺的用戶角度案铺、數(shù)據(jù)架構(gòu)演進(jìn)、模型等進(jìn)行了闡述梆靖。
在互聯(lián)網(wǎng)時代被弱化的數(shù)據(jù)模型
談起數(shù)據(jù)模型就不得不提傳統(tǒng)數(shù)據(jù)平臺架構(gòu)發(fā)展控汉，我相信很多朋友都曉得傳統(tǒng)數(shù)據(jù)平臺的知識，其架構(gòu)演進(jìn)簡單一句話說“基本上可以分為五個時代返吻、四種架構(gòu)”姑子，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與數(shù)據(jù)源類型多樣化特點(diǎn)，從高階架構(gòu)上來看大約從傳統(tǒng)數(shù)據(jù)平臺第三代架構(gòu)開始延續(xù)的测僵，但是往后的發(fā)展從我自己的這一點(diǎn)知識上很難對互聯(lián)網(wǎng)的數(shù)據(jù)平臺做架構(gòu)歸類街佑。
但是從數(shù)據(jù)平臺建設(shè)與服務(wù)角色上還是有章可循的。就像上篇分享到那樣恨课，類比兩個行業(yè)，互聯(lián)網(wǎng)企業(yè)中員工年齡比非互聯(lián)網(wǎng)企業(yè)的要年輕岳服、受教育程度剂公、對計(jì)算機(jī)的焦慮程度明顯比傳統(tǒng)企業(yè)要低、還偶遇其它各方面的緣故吊宋，導(dǎo)致了數(shù)據(jù)平臺所面對用戶群體與非互聯(lián)網(wǎng)數(shù)據(jù)平臺有所差異化。
傳統(tǒng)行業(yè)與互聯(lián)網(wǎng)行業(yè)數(shù)據(jù)平臺用戶特性我只選擇前文章的兩張圖來表示
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
在傳統(tǒng)數(shù)據(jù)平臺要背后有一個完整數(shù)據(jù)倉庫團(tuán)隊(duì)去服務(wù)業(yè)務(wù)方倾哺，業(yè)務(wù)方嗷嗷待哺的等待被動方式去滿足吉懊。中低層數(shù)據(jù)基本不會對業(yè)務(wù)方開放，所以不管數(shù)據(jù)模型采用何種建模方式鳞上，主要滿足當(dāng)時數(shù)據(jù)架構(gòu)規(guī)劃即可。
互聯(lián)網(wǎng)業(yè)務(wù)的快速發(fā)展使得大家已經(jīng)從經(jīng)營吊档、分析的訴求重點(diǎn)轉(zhuǎn)為數(shù)據(jù)化的精細(xì)運(yùn)營上篙议，如何做好精細(xì)化運(yùn)營問題上來，當(dāng)資源不夠時用戶就叫喊怠硼，甚至有的業(yè)務(wù)方會挽起袖子來自己參與到從數(shù)據(jù)整理鬼贱、加工、分析階段香璃。
此時呢这难，原有建設(shè)數(shù)據(jù)平臺的多個角色（數(shù)據(jù)開發(fā)、模型設(shè)計(jì)）可能轉(zhuǎn)為對其它非專業(yè)使用數(shù)據(jù)方葡秒，做培訓(xùn)姻乓、咨詢與落地，寫更加適合當(dāng)前企業(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àn)椴粚I(yè)性炸站，導(dǎo)致數(shù)據(jù)質(zhì)量問題星澳、重復(fù)對分?jǐn)?shù)據(jù)浪費(fèi)存儲與資源、口徑多樣化旱易、編碼不統(tǒng)一禁偎、命名問題等等原因。數(shù)據(jù)質(zhì)量逐漸變成一個特別突出的問題阀坏。
傳統(tǒng)企業(yè)的數(shù)據(jù)源基本來自excel如暖、表格、DB系統(tǒng)等忌堂，但在互聯(lián)網(wǎng)有網(wǎng)站點(diǎn)擊流日志盒至、視頻、音頻士修、圖片數(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ù)有些力不從心沸移。
當(dāng)數(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è)也有自己特點(diǎn)选侨，傳統(tǒng)行業(yè)所涉及數(shù)據(jù)模型這個領(lǐng)域涉及的很多內(nèi)容在互聯(lián)網(wǎng)變成以其他的曲線救國的方式存在了殿衰。
在互聯(lián)網(wǎng)曲線救國新解決
回顧在傳統(tǒng)行業(yè)數(shù)據(jù)平臺中吃型，不管兩位大師爭論點(diǎn)數(shù)據(jù)模型的設(shè)計(jì)采用那種范式（Bill Inmon的EDW的原則是準(zhǔn)三范式的設(shè)計(jì)准颓、Ralph kilmbal是星型結(jié)構(gòu)）但是都要非常重視數(shù)據(jù)源的質(zhì)量問題。所以傳統(tǒng)行業(yè)的數(shù)據(jù)模型會全盤考慮數(shù)據(jù)質(zhì)量問題，并通過數(shù)據(jù)抽樣分析給出合適的清洗口徑鹉勒。
(點(diǎn)擊放大圖像)
上圖來自我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ù)”對一年的還是不準(zhǔn)的）。在應(yīng)對數(shù)據(jù)的質(zhì)量問題浴讯，目前互聯(lián)網(wǎng)有些做法是把數(shù)據(jù)標(biāo)準(zhǔn)化前置到業(yè)務(wù)數(shù)據(jù)產(chǎn)生就做朵夏，從根源上去杜絕數(shù)據(jù)質(zhì)量，但是這種場景比較實(shí)用在Log 日志的數(shù)據(jù)源中榆纽，比如移動互聯(lián)網(wǎng)最近流行的基于事件模型“Event”模型仰猖，在日志產(chǎn)生時就規(guī)定好存儲格式（備注：大家度娘搜索捏肢，“學(xué)習(xí)筆記：The Log（我所讀過的最好的一篇分布式技術(shù)文章）” 對這個講解很詳細(xì)）。
在傳統(tǒng)行業(yè)饥侵，目前還是以混合模型設(shè)計(jì)方式為主鸵赫。在互聯(lián)網(wǎng)的我所接觸的一些業(yè)務(wù)，在參照傳統(tǒng)數(shù)據(jù)模型方法論基礎(chǔ)上逐步演進(jìn)適合互聯(lián)網(wǎng)數(shù)據(jù)的數(shù)據(jù)模型方法躏升。
比如互聯(lián)網(wǎng)金融等一些業(yè)務(wù)會參考傳統(tǒng)金融行業(yè)對主題域的劃分辩棒、OMG數(shù)據(jù)倉庫元數(shù)據(jù)管理CWM模型、FSDM金融模型膨疏，再進(jìn)一步考慮大數(shù)據(jù)處理特性去進(jìn)行設(shè)計(jì)一睁，所有從Hight Level 數(shù)據(jù)架構(gòu)圖看到主題層次劃分與傳統(tǒng)第三代數(shù)據(jù)倉庫還是很多相似之處，當(dāng)然模型架構(gòu)也有分三層佃却、四層者吁、五層的。
不同的地方模型細(xì)節(jié)處理上已經(jīng)完全不一樣饲帅，比如數(shù)據(jù)的多樣性傲须、拉寬事實(shí)表梁肿、度量值單獨(dú)存儲键痛、滿足數(shù)據(jù)快速重生碌上、維度的二次降維處理等、增加大量冗余列丘逸、增加大量派生列单鹿，結(jié)合自動化元數(shù)據(jù)來耦合掀宋、合并等相關(guān)管理深纲。
(點(diǎn)擊放大圖像)
[圖片上傳中。劲妙。湃鹊。（4）]
上圖是支付寶非常早期數(shù)據(jù)模型
(點(diǎn)擊放大圖像)
上圖是支付寶非常早期數(shù)據(jù)模型
我們常提到的多維模型在大數(shù)據(jù)處理下進(jìn)行了退化維度處理。大家知道Olap多維模型镣奋，隨著維度的增加事實(shí)表的數(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è)計(jì)多維挖掘分析數(shù)據(jù)產(chǎn)品背后的技術(shù)就是搜索引擎實(shí)現(xiàn)的）余赢，現(xiàn)在應(yīng)該也有新技術(shù)出現(xiàn)了來解決類似的問題。
(點(diǎn)擊放大圖像)
上圖為2012年產(chǎn)品UI之一哈垢。
(點(diǎn)擊放大圖像)
[圖片上傳中妻柒。。耘分。（7）]
上圖是2011-2012年該產(chǎn)品系列背后當(dāng)時使用的技術(shù)
互聯(lián)網(wǎng)業(yè)務(wù)特點(diǎn)業(yè)務(wù)垂直拆分非常細(xì)举塔，比如一個用戶注冊绑警、密碼找回的流程有可能存在好幾個產(chǎn)品負(fù)責(zé)同一個業(yè)務(wù)流程不同環(huán)節(jié)，相關(guān)的一個策略央渣、產(chǎn)品feature快速迭代上線等等都要數(shù)據(jù)評估计盒。數(shù)據(jù)從前端埋點(diǎn)到采集然后再由各個環(huán)節(jié)到數(shù)據(jù)平臺，再有數(shù)據(jù)分析師或各業(yè)務(wù)部門去使用芽丹，基本拉長了時間周期北启。需求部門與實(shí)施部門能力和經(jīng)驗(yàn)有千差萬別的需求，造成了懂技術(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ù)特點(diǎn)是變化非常迅速的跌前，能穩(wěn)定的業(yè)務(wù)達(dá)到65%算對數(shù)據(jù)平臺是個福音了（根據(jù)對某寶寶的印象）剩余的業(yè)務(wù)變化迅速，必然導(dǎo)致數(shù)據(jù)模型快速上下線售躁。
Kimball老人家提出的維度建模（備注正塌，在本系列發(fā)展史得第一篇有介紹）圍繞業(yè)務(wù)模型能夠非常直觀的表達(dá)出業(yè)務(wù)的數(shù)據(jù)關(guān)系，但是在互聯(lián)網(wǎng)NOSQL犧牲掉了關(guān)系型數(shù)據(jù)庫的一致性呛每、完整性等等很多東西踩窖。維度數(shù)據(jù)模型又基于這些大數(shù)據(jù)技術(shù)的，所以進(jìn)化的更加輕量級與基于細(xì)節(jié)數(shù)據(jù)的維度退化建模（原有的緩慢變化維晨横、快速變化維洋腮、大維、迷你維手形、父子維啥供、雪花維為了適應(yīng)互聯(lián)網(wǎng)的大數(shù)據(jù)Nosql處理技術(shù)進(jìn)行反規(guī)范化、化&數(shù)據(jù)冗余設(shè)計(jì)库糠。
退化維度的反規(guī)范化設(shè)計(jì)一方面可以把一條查詢語句所需要的所有數(shù)據(jù)組合起來放到一個地方存儲 Key values 的方式（比如說商品有不同類型伙狐，每一種類型商品又有自己的不同屬性，可以采用一對多瞬欧、多對多的方式存儲贷屎，例如把一個多維映射為一個Key value）。
講到互聯(lián)網(wǎng)數(shù)據(jù)平臺就要提數(shù)據(jù)模型艘虎，提了數(shù)據(jù)模型就要提Nosql技術(shù)唉侄，
(點(diǎn)擊放大圖像)
上圖來自Nosql文檔系列的一幅圖
Nosql 是大數(shù)據(jù)處理的特征之一∏晏互聯(lián)網(wǎng)數(shù)據(jù)平臺數(shù)據(jù)模型與NoSql技術(shù)還是蠻緊密的美旧。這里有外文講解Nosql Data modeling technigues 從技術(shù)角度講解非常詳（https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/）渤滞。
因?yàn)榍斑吿岬降拇髷?shù)據(jù)平臺技術(shù)特性決定了傳統(tǒng)edw模型、維度模型直接在互聯(lián)網(wǎng)數(shù)據(jù)大數(shù)據(jù)平臺部署或許還有“好些未知”障礙等待大家去克服榴嗅。同時在傳統(tǒng)數(shù)據(jù)建模用到的一些方法經(jīng)過互聯(lián)網(wǎng)熏陶或許演進(jìn)成一種新的數(shù)據(jù)產(chǎn)品或方案吧妄呕。
到此為止“我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史”上下共四篇與大家分享完畢，這個寫作前后經(jīng)歷剛好一個月左右嗽测，算是對自己數(shù)據(jù)從業(yè)經(jīng)歷回顧之一吧绪励。在知識的整理中很多都是蜻蜓點(diǎn)水，每個知識域都是一個非常深的專業(yè)方向唠粥，自己涉足很膚淺疏魏，在文章中分享不足之處請各位讀者見諒！晤愧！
個人郵箱是5592094@qq.com 歡迎電郵交流大莫。
接下來我會進(jìn)入數(shù)據(jù)產(chǎn)品這個領(lǐng)域的分享，當(dāng)年車品覺老師自豪的作品之一“黃金策”官份，我是數(shù)據(jù)產(chǎn)品經(jīng)理只厘。（ps：自己躲在墻角拿車品覺老師往自己臉上貼金了）杈曲。
后記
有一次數(shù)據(jù)產(chǎn)品神策的創(chuàng)始人兼好友@桑文鋒＠SensorsData跟我說來做次分享吧疏虫，我當(dāng)時出了幾個題目航瞭，最后就選擇了“我所經(jīng)歷的大數(shù)據(jù)平臺“牵啦，就形成了大家看到的”我所經(jīng)歷的大數(shù)據(jù)平臺“系列文章.
在整理期間得到了死黨@周愛民、@神策-桑文峰艾蓝、 InfoQ小編@Tina Du 九妈、@betty zhou @Laurel大力協(xié)助泰演，在這里感謝ｌ俊８橥埂！
番外篇
這一篇是在24日舉行的分享大家提到的一些問題情屹，經(jīng)過整理算是對正文的補(bǔ)充吧坪仇，從互聯(lián)網(wǎng)敏捷數(shù)據(jù)模型等角度做了較深入的細(xì)節(jié)介紹杂腰。同時在數(shù)據(jù)產(chǎn)品方面的回答包含了一點(diǎn)未來寫作篇“數(shù)據(jù)產(chǎn)品”系列的一點(diǎn)內(nèi)容垃你。
1****，傳統(tǒng)我們做BI的喂很，做數(shù)據(jù)展現(xiàn)會建模后以pivot展現(xiàn)cube數(shù)據(jù)惜颇，不知道現(xiàn)在互聯(lián)網(wǎng)公司數(shù)據(jù)展示如何做的？第三方工具還是用API取數(shù)據(jù)平臺里的數(shù)據(jù)少辣？adhoc報(bào)表及靈活更換維度的時候web端一般是怎么做的凌摄？
松子老師：剛才文章中提到了比如傳統(tǒng)行業(yè)的多維數(shù)據(jù)模型cube。在互聯(lián)網(wǎng)采用的曲線救國方式解決的漓帅。 在分享中我給出了幾個圖锨亏。就是通過搜索引擎曲線救國方式實(shí)現(xiàn)類似Olap的模擬痴怨。
在這塊的模型的處理上采用的是維度退化處理。通過反規(guī)范化器予，數(shù)據(jù)項(xiàng)浪藻、數(shù)據(jù)冗余去處理。在前端做特殊處理乾翔。
這個當(dāng)時產(chǎn)品原型之一：
(點(diǎn)擊放大圖像)
這是一個2011年-2012年左右的數(shù)據(jù)產(chǎn)品爱葵，當(dāng)時算是即時計(jì)算的一種。不過已經(jīng)過去好幾年了反浓，當(dāng)今新技術(shù)下Olap 引擎應(yīng)該有很好的提升萌丈。
目前我知道的家互聯(lián)網(wǎng)公司，在前端展現(xiàn)有使用第三方套件比如spagoBi雷则、pentaho 等 有自己設(shè)計(jì)開發(fā)定制化數(shù)據(jù)前端展現(xiàn)辆雾。比如我剛開始分享的那兩個之前在去哪兒網(wǎng)設(shè)計(jì)的數(shù)據(jù)平臺內(nèi)部界面之一，當(dāng)然數(shù)據(jù)產(chǎn)品是另一個話題了月劈，通過對數(shù)據(jù)分析抽象指標(biāo)崔梗、分析模型、用戶使用功能與流程靠欢、未來規(guī)劃考慮用戶體驗(yàn)去設(shè)計(jì)放妈。
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
[圖片上傳中。湿右。诅妹。（11）]
(點(diǎn)擊放大圖像)
2****，互聯(lián)網(wǎng)財(cái)經(jīng)類公司毅人，業(yè)務(wù)包括財(cái)經(jīng)網(wǎng)站吭狡、基金、股票丈莺、金融等划煮，這類公司的數(shù)據(jù)倉庫模型應(yīng)該如何設(shè)計(jì)？特點(diǎn)和注意事項(xiàng)是什么缔俄？案例介紹弛秋？十分感謝。
松子老師：我自己經(jīng)歷過的是互聯(lián)網(wǎng)金融以及移動互聯(lián)網(wǎng)行俐载。對這兩塊比較清楚蟹略。互聯(lián)網(wǎng)金融起因?yàn)闃I(yè)務(wù)的特性是類金融類的遏佣，與銀行有些地方是相似的挖炬。
比如大約在2012年前支付寶業(yè)務(wù)特點(diǎn)涉及類金融交易：充值、提現(xiàn)状婶、賬務(wù)管理類電子商務(wù)：購物交易過程變更意敛、實(shí)際交易（對B機(jī)票馅巷、對C水電等） 非純電子商務(wù)；純金融草姻；個人信用令杈，理財(cái)類。系統(tǒng)之間依賴度較為復(fù)雜碴倾，垂直依賴（業(yè)務(wù)與核心）跨層依賴（跨過交易到賬務(wù)）逗噩。
在設(shè)計(jì)方法上還是采用維度模型設(shè)計(jì)方式。底層是數(shù)據(jù)驅(qū)動為向?qū)У疲Y(jié)合業(yè)務(wù)需求驅(qū)動异雁，通過簡單、退化維度的方式拉寬表結(jié)構(gòu)僧须。
底層采用松耦合設(shè)計(jì)纲刀。主題之間是松耦合方式。至體內(nèi)采用細(xì)粒度退化維度担平。
在主題域上的的設(shè)計(jì)基本參考了OMG的數(shù)據(jù)倉庫元數(shù)據(jù)設(shè)計(jì)CWM模型炬太、IBM 的fsdm金融模型琉挖、還有新巴塞爾資本協(xié)議（Basel II Capital Accord）需提供數(shù)據(jù)規(guī)范去的設(shè)計(jì)捏顺。所以數(shù)據(jù)模型是五層的結(jié)構(gòu)偶芍。
在細(xì)節(jié)處理上，增量ODS層數(shù)據(jù)和前一天DWD相關(guān)表進(jìn)行 merge處理取胎。
在一些層次上，基本聚合薪棒、匯總增加派生事實(shí)表（簡單一句話退化為度打?qū)挘┦中Ｈ缓蟀凑諛I(yè)務(wù)主體合并信息等。
比如開始給大家分享的那張圖：
(點(diǎn)擊放大圖像)
[圖片上傳中蒂誉。竖螃。疾棵。（13）]
在維度模型退化處理時，要注意最細(xì)粒度數(shù)據(jù)保留、不同層次的數(shù)據(jù)支持?jǐn)?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ù)模型椭盏。
這種元數(shù)據(jù)驅(qū)動工具型數(shù)據(jù)產(chǎn)品我會在未來數(shù)據(jù)產(chǎn)品系列中做詳細(xì)介紹的。
3****吻商，互聯(lián)網(wǎng)企業(yè)大數(shù)據(jù)平臺的發(fā)展歷程是怎樣的掏颊？
松子老師：這個我相信應(yīng)該是傳統(tǒng)數(shù)據(jù)平臺朋友提到的。傳統(tǒng)行業(yè)數(shù)據(jù)平臺架構(gòu)演進(jìn)我總結(jié)簡單一句話說“基本上可以分為五個時代、四種架構(gòu)”乌叶，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與類型暴增的特點(diǎn)盆偿，從高階架構(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é)下來用戶特點(diǎn)：
(點(diǎn)擊放大圖像)
[圖片上傳中求橄。。葡公。（14）]
更加詳細(xì)的每一代數(shù)據(jù)平臺建設(shè)罐农、服務(wù)角色特點(diǎn)您可以看我這個系列文章的第三篇，http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-paet02
4****催什，有沒有好的元數(shù)據(jù)管理工具推薦涵亏？主要偏向數(shù)據(jù)字典與血統(tǒng)等妈踊。
松子老師：元數(shù)據(jù)以前目前沒有太多的好管理工具猜扮。以前是在支付寶是我自己設(shè)計(jì)的一個數(shù)據(jù)產(chǎn)品浸赫。第一版自己用Delphi 開發(fā)的席揽。
（圖很多：）
(點(diǎn)擊放大圖像)
[圖片上傳中与学。第股。浪蹂。（15）]
(點(diǎn)擊放大圖像)
[圖片上傳中萎庭。臂聋。光稼。（16）]
(點(diǎn)擊放大圖像)
[圖片上傳中。孩等。艾君。（17）]
(點(diǎn)擊放大圖像)
[圖片上傳中。肄方。冰垄。（18）]
(點(diǎn)擊放大圖像)
以前被逼的自己寫了一個，通過解析权她，實(shí)現(xiàn)了字段級的血緣影響分析虹茶。這只是第二步，后來又把running 信息給搞了進(jìn)來隅要。還有分享時提到的模型信息蝴罪、整個閉環(huán)的分類信息。
這是一個分支：
(點(diǎn)擊放大圖像)
[圖片上傳中步清。要门。虏肾。（20）]
但是我們實(shí)現(xiàn)了字段級解析準(zhǔn)確率達(dá)到了94%左右。有細(xì)微的錯誤就人工revew一遍欢搜。
5. ****松子老師封豪，數(shù)據(jù)管控的數(shù)據(jù)質(zhì)量部分是怎么處理的呢？
松子老師： 數(shù)據(jù)管控炒瘟， 這方面我不太懂的吹埠，但是數(shù)據(jù)質(zhì)量，這玩意可大可小的唧领。比如像在分享時說過的藻雌，在移動互聯(lián)網(wǎng)的數(shù)據(jù)質(zhì)量處理方式可以由原有的ETL(ELT)階段前置到業(yè)務(wù)系統(tǒng)去解決，比如移動互聯(lián)網(wǎng)的App log 日志斩个，日志標(biāo)準(zhǔn)化后事件模型”存儲來解決胯杭。那非app 日志類如何解決呢比如Payment、order等，數(shù)據(jù)質(zhì)量比較考慮的可以只做到監(jiān)控。
我來分享個圖淤井。剛好是我設(shè)計(jì)數(shù)據(jù)質(zhì)量產(chǎn)品時搞的，理清數(shù)據(jù)質(zhì)量的問題：
(點(diǎn)擊放大圖像)
[圖片上傳中居暖。。藤肢。（21）]
(點(diǎn)擊放大圖像)
[圖片上傳中太闺。。嘁圈。（22）]
(點(diǎn)擊放大圖像)
[圖片上傳中省骂。。最住。（23）]
只要數(shù)據(jù)進(jìn)入倉庫與應(yīng)用體系钞澳，處理起來就比較困難了，所以在數(shù)據(jù)平臺階段最好是通過監(jiān)控涨缚、前置去解決轧粟。目前數(shù)據(jù)質(zhì)量確實(shí)難以100%由事后搞到事前去處理。我對數(shù)據(jù)平臺與數(shù)據(jù)產(chǎn)品的建設(shè)就是實(shí)用為主脓魏。怎么實(shí)用怎么來兰吟。我是比較現(xiàn)實(shí)的實(shí)用主義者。
6. ****能否分享一些數(shù)據(jù)產(chǎn)品種類及實(shí)例：
松子老師：在前邊五個問題茂翔、以及文章中又都涉及數(shù)據(jù)產(chǎn)品實(shí)力的一些分享揽祥。
提到數(shù)據(jù)產(chǎn)品的分類我就想把這個圖發(fā)出來。
自己認(rèn)為沒有特別明確的劃分線檩电，但是數(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工具烹卒、資源管控等等闷盔。
面向用戶功能有報(bào)表型、多維型數(shù)據(jù)產(chǎn)品旅急、定制化數(shù)據(jù)產(chǎn)品逢勾、挖掘型數(shù)據(jù)產(chǎn)品。
面向內(nèi)部用戶藐吮、外部個人用戶溺拱、外部企業(yè)用戶又有不同的分類。
根據(jù)業(yè)務(wù)又可以劃分很多谣辞，面向C類用戶澎现、面向B類商戶砸民、金融風(fēng)險(xiǎn)等等
從近幾年的數(shù)據(jù)產(chǎn)品來看，是更好的輔助用戶的做決策的一種產(chǎn)品形態(tài)，在用戶的決策與行動中充當(dāng)信息的分析者與價值使用者编整；數(shù)據(jù)產(chǎn)品有個自己的共性：由解決的一個實(shí)際的業(yè)務(wù)問題出發(fā)，分解出的分析指標(biāo)壶唤，分析模型琢唾，分析流程組成，再考慮到功能易用性和敬，未來功能擴(kuò)展凹炸，考慮用戶對數(shù)據(jù)易用性（比如數(shù)據(jù)的呈現(xiàn)層次，不可能一次把所有數(shù)據(jù)的呈現(xiàn)給用戶）來組成的昼弟。
(點(diǎn)擊放大圖像)
[圖片上傳中啤它。。舱痘。（24）]
7. ****銀行業(yè)從傳統(tǒng)的ods到edw再到大數(shù)據(jù)平臺這塊過渡变骡，模型如何建設(shè)？平臺優(yōu)勢如何發(fā)揮芭逝？
松子老師：這個問題還是有些難度的塌碌，自己回答的可能有些片面。首先我們清醒的清楚“大數(shù)據(jù)”是什么旬盯？再次不同的場景可以采用不同的技術(shù)去解決台妆。
“大數(shù)據(jù)”翎猛，拆開來看大、數(shù)據(jù)接剩，大可以是指的數(shù)據(jù)源結(jié)構(gòu)簡單（ps 如果了解過當(dāng)代對大數(shù)據(jù)的定義就知道四個特性）但是量級夠大切厘，比如清算、結(jié)算懊缺、對公疫稿、對私、中間業(yè)務(wù)等等每一個拿出來都是幾十T鹃两，但是這些業(yè)務(wù)數(shù)據(jù)都是保存?zhèn)鹘y(tǒng)的關(guān)系型數(shù)據(jù)庫中如DB2遗座、Oracle、MSsql中俊扳，因?yàn)樵跀?shù)據(jù)平臺存儲是通過準(zhǔn)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ù)的去演進(jìn)解決抗果。（最早時我的是中信銀行擦秽、光大銀行在2011年左右開始考慮Hadoop技術(shù)沃暗，后來不知道如何了）魄藕。
但是互聯(lián)網(wǎng)的數(shù)據(jù)平臺技術(shù)大都是NOSQL模式颤专，犧牲掉了傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)一致性、完整性逮光、唯一索引等等代箭，只干性能的事情（當(dāng)然除了性能、可擴(kuò)展性也是的）.
原有在傳統(tǒng)數(shù)據(jù)平臺模型設(shè)計(jì)上可以考慮的一些通過主外鍵涕刚、唯一索引做一些業(yè)務(wù)約束的方法嗡综，在nosql上統(tǒng)統(tǒng)的都沒有了，這些約束必須放到數(shù)據(jù)加工階段去想辦法做檢查杜漠。傳統(tǒng)數(shù)據(jù)平臺如果在Insert极景、update數(shù)據(jù)時違反了業(yè)務(wù)約束可以做報(bào)警或異常處理，但是在Nosql的平臺上要求ETL 去手動遵守這些規(guī)則檢查驾茴。但是有時ETL開發(fā)根本不遵守的盼樟，僅僅是兩個表關(guān)聯(lián)起來，也可能忘記按照某一個業(yè)務(wù)唯一索引做去重操作锈至。簡單說晨缴，原有靠關(guān)系型數(shù)據(jù)庫本身機(jī)制去做檢查一些規(guī)則變?yōu)槿斯ぃ優(yōu)槿斯ぞ蜁稿e峡捡。
從關(guān)系型數(shù)據(jù)平臺往Nosql數(shù)據(jù)平臺遷移時击碗，尤其是對傳統(tǒng)行業(yè)的業(yè)務(wù)來說筑悴，在模型設(shè)計(jì)階段、以及給出的ETL口徑要考慮更多的業(yè)務(wù)規(guī)則檢查延都，其次要考慮更多的維度退化雷猪、多冗余、表打?qū)捥幚砦俊：唵握f就是發(fā)揮數(shù)據(jù)平臺的計(jì)算能力同時要更加的各方面確保數(shù)據(jù)準(zhǔn)確安全可靠。
數(shù)據(jù)模型ODS 到EDW 這塊的設(shè)計(jì)方法百度上留下的文檔資料太多的了射沟，請這位提問的老師百度吧殊者。
**8****．大數(shù)據(jù)****倉庫****中如何做快速****維處****理？互****聯(lián)****網(wǎng)數(shù)****倉****數(shù)據(jù)****質(zhì)****量不好如何****對****數(shù)验夯，如何確立****標(biāo)****準(zhǔn)的****對****數(shù)口徑猖吴？******
松子老師：快速變化維度可以轉(zhuǎn)化為緩慢變化為來出來，我自己理解的快速維度是相對于緩慢維度參照的來說的挥转。
舉個例子海蔽，年齡-轉(zhuǎn)化為天數(shù)可以是定義快速變化維度，因?yàn)槊刻於荚谧兓笠ァＮ覀兛梢园涯挲g退化為區(qū)間維度來處理党窜，還可以把年齡做成動態(tài)維度來處理旅赢，事實(shí)表中保存的就是實(shí)際的出生年月并打?qū)挶碥窈挲g(天)通過計(jì)算方式來處理。還有種方法通過對代理鍵的方式來處理郎逃。
我目前也不知道對數(shù)據(jù)的標(biāo)準(zhǔn)是什么壤玫。但是我自己用的方法豁护，把一個指標(biāo)的整個數(shù)據(jù)流向切出幾個關(guān)鍵點(diǎn)通過SQL去實(shí)現(xiàn)對數(shù)，看波動振幅欲间，波動曲線楚里。同時還會比如發(fā)不通的版本的小流量測試的方式來做數(shù)據(jù)校對。
9****． 做為數(shù)據(jù)行業(yè)從業(yè)者猎贴，需要掌握哪些重要的基礎(chǔ)知識班缎？另：如果從零開始建立一個數(shù)據(jù)平臺，需要哪些資源配置（人嘱能，財(cái)吝梅，物，技術(shù)）惹骂？大致總投資額度多少苏携？如果同行產(chǎn)品間多種來源的數(shù)據(jù)，可有成熟的解決方案对粪？謝謝…
松子老師：這個問題太宏觀了右冻。作為數(shù)據(jù)行業(yè)從業(yè)者装蓬，需要掌握哪些重要基礎(chǔ)知識，這個是要看從事具體數(shù)據(jù)域的垂直行業(yè)纱扭。
比如說 數(shù)據(jù)開發(fā)牍帚、數(shù)據(jù)模型、數(shù)據(jù)產(chǎn)品乳蛾、數(shù)據(jù)分析師暗赶、數(shù)據(jù)運(yùn)營、數(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ù)目標(biāo)不太明確下激率，難以確定方案，人員配置上選用不同技術(shù)方案去搭建的配置是不太一樣的勿决，比如說傳統(tǒng)平臺來講乒躺，運(yùn)維、DBA、數(shù)據(jù)開發(fā)、數(shù)據(jù)模型档泽、報(bào)表人員开财。
從互聯(lián)網(wǎng)數(shù)據(jù)平臺基本配置上，數(shù)據(jù)架構(gòu)師、運(yùn)維、底層大數(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ù)。
10. Standalone****模式下，Model.save(Path)怎么一直提示錯誤核行，是不是配置Spark時需要將Hdfs的配置引進(jìn)來啊～牢硅？表示初學(xué)Spark
松子老師：這個問題有點(diǎn)超出我的能力范圍了，所以對不起回答不了芝雪。
我本身不是做技術(shù)的减余。僅知道一點(diǎn)技術(shù)名詞。
11. ****傳統(tǒng)銀行業(yè)數(shù)據(jù)模型什么時候會走向互聯(lián)網(wǎng)模式呢惩系？目前在傳統(tǒng)銀行數(shù)據(jù)平臺的產(chǎn)品是不是特別多位岔？
松子老師：這個問題我自己就不知道了，或許是傳統(tǒng)銀行在數(shù)據(jù)平臺的實(shí)施上全面用互聯(lián)網(wǎng)的Nosql大數(shù)據(jù)處理技術(shù)吧蛆挫。至于說傳統(tǒng)銀行數(shù)據(jù)模型用現(xiàn)有的互聯(lián)網(wǎng)數(shù)據(jù)模型理念去設(shè)計(jì)是否完全可行赃承，數(shù)據(jù)一致性、高準(zhǔn)確性通過更多的方案去保證悴侵。
首先我需要確定一下這個產(chǎn)品是否指的“數(shù)據(jù)產(chǎn)品”。
如果是數(shù)據(jù)產(chǎn)品拭嫁，那其實(shí)傳統(tǒng)行業(yè)數(shù)據(jù)平臺本身就有一些數(shù)據(jù)產(chǎn)品了可免，而且也都是存在的。數(shù)據(jù)產(chǎn)品自從數(shù)據(jù)倉庫出現(xiàn)以來它其實(shí)一直都存在的做粤，只不過是近幾年因?yàn)榛ヂ?lián)網(wǎng)特別愛制造“流行詞“把數(shù)據(jù)產(chǎn)品這個詞給放大了浇借。互聯(lián)網(wǎng)是得數(shù)據(jù)產(chǎn)品從早期的重量級逐漸進(jìn)化為輕量級怕品、從大而全的解決方案逐漸演進(jìn)為因小而美妇垢。
我來給出幾組例子，大約從2004年到現(xiàn)在的幾組數(shù)據(jù)產(chǎn)品的例子
(點(diǎn)擊放大圖像)
[圖片上傳中肉康。。。（25）]
(點(diǎn)擊放大圖像)
[圖片上傳中崇摄。窘疮。。（26）]
(點(diǎn)擊放大圖像)
[圖片上傳中炫乓。刚夺。。（27）]
(點(diǎn)擊放大圖像)
[圖片上傳中末捣。侠姑。。（28）]
(點(diǎn)擊放大圖像)
[圖片上傳中箩做。莽红。。（29）]
(點(diǎn)擊放大圖像)
[圖片上傳中卒茬。船老。咖熟。（30）]
(點(diǎn)擊放大圖像)
[圖片上傳中。柳畔。馍管。（31）]
你可以分類一下，這些數(shù)據(jù)產(chǎn)品的特點(diǎn)是什么薪韩？滿足了用戶怎么樣的痛點(diǎn)需求确沸？滿足了用戶怎么樣的使用流程。
12 ****俘陷。傳統(tǒng)行業(yè)的數(shù)據(jù)倉庫從業(yè)人員罗捎，如果轉(zhuǎn)到互聯(lián)網(wǎng)行業(yè)，應(yīng)該學(xué)習(xí)哪些技能拉盾？
松子老師：這個問題你可以百度搜索“大數(shù)據(jù)職位所需要的數(shù)據(jù)技能” http://blog.jobbole.com/99039/ 這篇文章桨菜。自己覺得人家回答的比我專業(yè)。//
我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史（四）：互聯(lián)網(wǎng)時代 ? 下篇
http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-internet-age
編者按：本文是松子（李博源）的大數(shù)據(jù)平臺發(fā)展史系列文章的第四篇（共四篇）捉偏，本系列以獨(dú)特的視角倒得，比較了非互聯(lián)網(wǎng)和互聯(lián)網(wǎng)兩個時代以及傳統(tǒng)行業(yè)與非傳統(tǒng)行業(yè)。是對數(shù)據(jù)平臺發(fā)展的一個回憶夭禽，對非互聯(lián)網(wǎng)霞掺、互聯(lián)網(wǎng)，從數(shù)據(jù)平臺的用戶角度讹躯、數(shù)據(jù)架構(gòu)演進(jìn)菩彬、模型等進(jìn)行了闡述。
在互聯(lián)網(wǎng)時代被弱化的數(shù)據(jù)模型
談起數(shù)據(jù)模型就不得不提傳統(tǒng)數(shù)據(jù)平臺架構(gòu)發(fā)展潮梯，我相信很多朋友都曉得傳統(tǒng)數(shù)據(jù)平臺的知識骗灶，其架構(gòu)演進(jìn)簡單一句話說“基本上可以分為五個時代忿族、四種架構(gòu)”绵患，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與數(shù)據(jù)源類型多樣化特點(diǎn)，從高階架構(gòu)上來看大約從傳統(tǒng)數(shù)據(jù)平臺第三代架構(gòu)開始延續(xù)的悄但，但是往后的發(fā)展從我自己的這一點(diǎn)知識上很難對互聯(lián)網(wǎng)的數(shù)據(jù)平臺做架構(gòu)歸類沃饶。
但是從數(shù)據(jù)平臺建設(shè)與服務(wù)角色上還是有章可循的母廷。就像上篇分享到那樣，類比兩個行業(yè)糊肤，互聯(lián)網(wǎng)企業(yè)中員工年齡比非互聯(lián)網(wǎng)企業(yè)的要年輕琴昆、受教育程度、對計(jì)算機(jī)的焦慮程度明顯比傳統(tǒng)企業(yè)要低馆揉、還偶遇其它各方面的緣故业舍，導(dǎo)致了數(shù)據(jù)平臺所面對用戶群體與非互聯(lián)網(wǎng)數(shù)據(jù)平臺有所差異化。
傳統(tǒng)行業(yè)與互聯(lián)網(wǎng)行業(yè)數(shù)據(jù)平臺用戶特性我只選擇前文章的兩張圖來表示
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
在傳統(tǒng)數(shù)據(jù)平臺要背后有一個完整數(shù)據(jù)倉庫團(tuán)隊(duì)去服務(wù)業(yè)務(wù)方，業(yè)務(wù)方嗷嗷待哺的等待被動方式去滿足舷暮。中低層數(shù)據(jù)基本不會對業(yè)務(wù)方開放态罪，所以不管數(shù)據(jù)模型采用何種建模方式，主要滿足當(dāng)時數(shù)據(jù)架構(gòu)規(guī)劃即可下面。
互聯(lián)網(wǎng)業(yè)務(wù)的快速發(fā)展使得大家已經(jīng)從經(jīng)營复颈、分析的訴求重點(diǎn)轉(zhuǎn)為數(shù)據(jù)化的精細(xì)運(yùn)營上，如何做好精細(xì)化運(yùn)營問題上來沥割，當(dāng)資源不夠時用戶就叫喊耗啦，甚至有的業(yè)務(wù)方會挽起袖子來自己參與到從數(shù)據(jù)整理、加工机杜、分析階段帜讲。
此時呢，原有建設(shè)數(shù)據(jù)平臺的多個角色（數(shù)據(jù)開發(fā)椒拗、模型設(shè)計(jì)）可能轉(zhuǎn)為對其它非專業(yè)使用數(shù)據(jù)方似将，做培訓(xùn)、咨詢與落地蚀苛，寫更加適合當(dāng)前企業(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àn)椴粚I(yè)性，導(dǎo)致數(shù)據(jù)質(zhì)量問題预茄、重復(fù)對分?jǐn)?shù)據(jù)浪費(fèi)存儲與資源兴溜、口徑多樣化、編碼不統(tǒng)一耻陕、命名問題等等原因拙徽。數(shù)據(jù)質(zhì)量逐漸變成一個特別突出的問題。
傳統(tǒng)企業(yè)的數(shù)據(jù)源基本來自excel诗宣、表格膘怕、DB系統(tǒng)等惧磺，但在互聯(lián)網(wǎng)有網(wǎng)站點(diǎn)擊流日志左敌、視頻度宦、音頻敲董、圖片數(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ù)有些力不從心髓堪。
當(dāng)數(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è)也有自己特點(diǎn)鹉戚，傳統(tǒng)行業(yè)所涉及數(shù)據(jù)模型這個領(lǐng)域涉及的很多內(nèi)容在互聯(lián)網(wǎng)變成以其他的曲線救國的方式存在了。
在互聯(lián)網(wǎng)曲線救國新解決
回顧在傳統(tǒng)行業(yè)數(shù)據(jù)平臺中专控，不管兩位大師爭論點(diǎn)數(shù)據(jù)模型的設(shè)計(jì)采用那種范式（Bill Inmon的EDW的原則是準(zhǔn)三范式的設(shè)計(jì)抹凳、Ralph kilmbal是星型結(jié)構(gòu)）但是都要非常重視數(shù)據(jù)源的質(zhì)量問題。所以傳統(tǒng)行業(yè)的數(shù)據(jù)模型會全盤考慮數(shù)據(jù)質(zhì)量問題伦腐，并通過數(shù)據(jù)抽樣分析給出合適的清洗口徑赢底。
(點(diǎn)擊放大圖像)
上圖來自我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ù)”對一年的還是不準(zhǔn)的）咳焚。在應(yīng)對數(shù)據(jù)的質(zhì)量問題洽损，目前互聯(lián)網(wǎng)有些做法是把數(shù)據(jù)標(biāo)準(zhǔn)化前置到業(yè)務(wù)數(shù)據(jù)產(chǎn)生就做，從根源上去杜絕數(shù)據(jù)質(zhì)量革半，但是這種場景比較實(shí)用在Log 日志的數(shù)據(jù)源中碑定，比如移動互聯(lián)網(wǎng)最近流行的基于事件模型“Event”模型，在日志產(chǎn)生時就規(guī)定好存儲格式（備注：大家度娘搜索又官，“學(xué)習(xí)筆記：The Log（我所讀過的最好的一篇分布式技術(shù)文章）” 對這個講解很詳細(xì)）延刘。
在傳統(tǒng)行業(yè)，目前還是以混合模型設(shè)計(jì)方式為主六敬。在互聯(lián)網(wǎng)的我所接觸的一些業(yè)務(wù)龟梦，在參照傳統(tǒng)數(shù)據(jù)模型方法論基礎(chǔ)上逐步演進(jìn)適合互聯(lián)網(wǎng)數(shù)據(jù)的數(shù)據(jù)模型方法漂坏。
比如互聯(lián)網(wǎng)金融等一些業(yè)務(wù)會參考傳統(tǒng)金融行業(yè)對主題域的劃分鲜结、OMG數(shù)據(jù)倉庫元數(shù)據(jù)管理CWM模型域那、FSDM金融模型，再進(jìn)一步考慮大數(shù)據(jù)處理特性去進(jìn)行設(shè)計(jì)典勇，所有從Hight Level 數(shù)據(jù)架構(gòu)圖看到主題層次劃分與傳統(tǒng)第三代數(shù)據(jù)倉庫還是很多相似之處劫哼，當(dāng)然模型架構(gòu)也有分三層、四層割笙、五層的权烧。
不同的地方模型細(xì)節(jié)處理上已經(jīng)完全不一樣眯亦，比如數(shù)據(jù)的多樣性、拉寬事實(shí)表般码、度量值單獨(dú)存儲妻率、滿足數(shù)據(jù)快速重生、維度的二次降維處理等板祝、增加大量冗余列宫静、增加大量派生列，結(jié)合自動化元數(shù)據(jù)來耦合券时、合并等相關(guān)管理孤里。
(點(diǎn)擊放大圖像)
[圖片上傳中。橘洞。捌袜。（4）]
上圖是支付寶非常早期數(shù)據(jù)模型
(點(diǎn)擊放大圖像)
上圖是支付寶非常早期數(shù)據(jù)模型
我們常提到的多維模型在大數(shù)據(jù)處理下進(jìn)行了退化維度處理。大家知道Olap多維模型炸枣，隨著維度的增加事實(shí)表的數(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è)計(jì)多維挖掘分析數(shù)據(jù)產(chǎn)品背后的技術(shù)就是搜索引擎實(shí)現(xiàn)的）霍衫，現(xiàn)在應(yīng)該也有新技術(shù)出現(xiàn)了來解決類似的問題。
(點(diǎn)擊放大圖像)
上圖為2012年產(chǎn)品UI之一侯养。
(點(diǎn)擊放大圖像)
[圖片上傳中敦跌。。逛揩。（7）]
上圖是2011-2012年該產(chǎn)品系列背后當(dāng)時使用的技術(shù)
互聯(lián)網(wǎng)業(yè)務(wù)特點(diǎn)業(yè)務(wù)垂直拆分非常細(xì)峰髓，比如一個用戶注冊、密碼找回的流程有可能存在好幾個產(chǎn)品負(fù)責(zé)同一個業(yè)務(wù)流程不同環(huán)節(jié)息尺，相關(guān)的一個策略、產(chǎn)品feature快速迭代上線等等都要數(shù)據(jù)評估疾掰。數(shù)據(jù)從前端埋點(diǎn)到采集然后再由各個環(huán)節(jié)到數(shù)據(jù)平臺搂誉，再有數(shù)據(jù)分析師或各業(yè)務(wù)部門去使用抚岗，基本拉長了時間周期媳禁。需求部門與實(shí)施部門能力和經(jīng)驗(yàn)有千差萬別的需求亩鬼，造成了懂技術(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ù)特點(diǎn)是變化非常迅速的愈涩，能穩(wěn)定的業(yè)務(wù)達(dá)到65%算對數(shù)據(jù)平臺是個福音了（根據(jù)對某寶寶的印象）剩余的業(yè)務(wù)變化迅速，必然導(dǎo)致數(shù)據(jù)模型快速上下線加矛。
Kimball老人家提出的維度建模（備注履婉，在本系列發(fā)展史得第一篇有介紹）圍繞業(yè)務(wù)模型能夠非常直觀的表達(dá)出業(yè)務(wù)的數(shù)據(jù)關(guān)系，但是在互聯(lián)網(wǎng)NOSQL犧牲掉了關(guān)系型數(shù)據(jù)庫的一致性斟览、完整性等等很多東西毁腿。維度數(shù)據(jù)模型又基于這些大數(shù)據(jù)技術(shù)的，所以進(jìn)化的更加輕量級與基于細(xì)節(jié)數(shù)據(jù)的維度退化建模（原有的緩慢變化維苛茂、快速變化維已烤、大維、迷你維妓羊、父子維胯究、雪花維為了適應(yīng)互聯(lián)網(wǎng)的大數(shù)據(jù)Nosql處理技術(shù)進(jìn)行反規(guī)范化、化&數(shù)據(jù)冗余設(shè)計(jì)侍瑟。
退化維度的反規(guī)范化設(shè)計(jì)一方面可以把一條查詢語句所需要的所有數(shù)據(jù)組合起來放到一個地方存儲 Key values 的方式（比如說商品有不同類型唐片，每一種類型商品又有自己的不同屬性，可以采用一對多涨颜、多對多的方式存儲费韭，例如把一個多維映射為一個Key value）。
講到互聯(lián)網(wǎng)數(shù)據(jù)平臺就要提數(shù)據(jù)模型庭瑰，提了數(shù)據(jù)模型就要提Nosql技術(shù)星持，
(點(diǎn)擊放大圖像)
上圖來自Nosql文檔系列的一幅圖
Nosql 是大數(shù)據(jù)處理的特征之一〉穑互聯(lián)網(wǎng)數(shù)據(jù)平臺數(shù)據(jù)模型與NoSql技術(shù)還是蠻緊密的督暂。這里有外文講解Nosql Data modeling technigues 從技術(shù)角度講解非常詳（https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/）。
因?yàn)榍斑吿岬降拇髷?shù)據(jù)平臺技術(shù)特性決定了傳統(tǒng)edw模型穷吮、維度模型直接在互聯(lián)網(wǎng)數(shù)據(jù)大數(shù)據(jù)平臺部署或許還有“好些未知”障礙等待大家去克服逻翁。同時在傳統(tǒng)數(shù)據(jù)建模用到的一些方法經(jīng)過互聯(lián)網(wǎng)熏陶或許演進(jìn)成一種新的數(shù)據(jù)產(chǎn)品或方案吧。
到此為止“我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史”上下共四篇與大家分享完畢捡鱼，這個寫作前后經(jīng)歷剛好一個月左右蝉衣，算是對自己數(shù)據(jù)從業(yè)經(jīng)歷回顧之一吧惭婿。在知識的整理中很多都是蜻蜓點(diǎn)水控轿，每個知識域都是一個非常深的專業(yè)方向哑蔫，自己涉足很膚淺，在文章中分享不足之處請各位讀者見諒Ｕ管引！
個人郵箱是5592094@qq.com 歡迎電郵交流。
接下來我會進(jìn)入數(shù)據(jù)產(chǎn)品這個領(lǐng)域的分享闯两，當(dāng)年車品覺老師自豪的作品之一“黃金策”褥伴，我是數(shù)據(jù)產(chǎn)品經(jīng)理谅将。（ps：自己躲在墻角拿車品覺老師往自己臉上貼金了）。
后記
有一次數(shù)據(jù)產(chǎn)品神策的創(chuàng)始人兼好友@桑文鋒＠SensorsData跟我說來做次分享吧噩翠，我當(dāng)時出了幾個題目戏自，最后就選擇了“我所經(jīng)歷的大數(shù)據(jù)平臺“，就形成了大家看到的”我所經(jīng)歷的大數(shù)據(jù)平臺“系列文章.
在整理期間得到了死黨@周愛民伤锚、@神策-桑文峰擅笔、 InfoQ小編@Tina Du 、@betty zhou @Laurel大力協(xié)助屯援，在這里感謝Ｃ兔恰！狞洋！
番外篇
這一篇是在24日舉行的分享大家提到的一些問題弯淘，經(jīng)過整理算是對正文的補(bǔ)充吧，從互聯(lián)網(wǎng)敏捷數(shù)據(jù)模型等角度做了較深入的細(xì)節(jié)介紹吉懊。同時在數(shù)據(jù)產(chǎn)品方面的回答包含了一點(diǎn)未來寫作篇“數(shù)據(jù)產(chǎn)品”系列的一點(diǎn)內(nèi)容庐橙。
1****，傳統(tǒng)我們做BI的借嗽，做數(shù)據(jù)展現(xiàn)會建模后以pivot展現(xiàn)cube數(shù)據(jù)态鳖，不知道現(xiàn)在互聯(lián)網(wǎng)公司數(shù)據(jù)展示如何做的？第三方工具還是用API取數(shù)據(jù)平臺里的數(shù)據(jù)恶导？adhoc報(bào)表及靈活更換維度的時候web端一般是怎么做的浆竭？
松子老師：剛才文章中提到了比如傳統(tǒng)行業(yè)的多維數(shù)據(jù)模型cube。在互聯(lián)網(wǎng)采用的曲線救國方式解決的惨寿。 在分享中我給出了幾個圖邦泄。就是通過搜索引擎曲線救國方式實(shí)現(xiàn)類似Olap的模擬。
在這塊的模型的處理上采用的是維度退化處理裂垦。通過反規(guī)范化顺囊，數(shù)據(jù)項(xiàng)、數(shù)據(jù)冗余去處理蕉拢。在前端做特殊處理包蓝。
這個當(dāng)時產(chǎn)品原型之一：
(點(diǎn)擊放大圖像)
這是一個2011年-2012年左右的數(shù)據(jù)產(chǎn)品瘾蛋，當(dāng)時算是即時計(jì)算的一種别威。不過已經(jīng)過去好幾年了俄周，當(dāng)今新技術(shù)下Olap 引擎應(yīng)該有很好的提升。
目前我知道的家互聯(lián)網(wǎng)公司届巩，在前端展現(xiàn)有使用第三方套件比如spagoBi、pentaho 等 有自己設(shè)計(jì)開發(fā)定制化數(shù)據(jù)前端展現(xiàn)份乒。比如我剛開始分享的那兩個之前在去哪兒網(wǎng)設(shè)計(jì)的數(shù)據(jù)平臺內(nèi)部界面之一恕汇，當(dāng)然數(shù)據(jù)產(chǎn)品是另一個話題了腕唧，通過對數(shù)據(jù)分析抽象指標(biāo)、分析模型瘾英、用戶使用功能與流程枣接、未來規(guī)劃考慮用戶體驗(yàn)去設(shè)計(jì)。
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
[圖片上傳中缺谴。但惶。。（11）]
(點(diǎn)擊放大圖像)
2****湿蛔，互聯(lián)網(wǎng)財(cái)經(jīng)類公司膀曾，業(yè)務(wù)包括財(cái)經(jīng)網(wǎng)站、基金阳啥、股票添谊、金融等，這類公司的數(shù)據(jù)倉庫模型應(yīng)該如何設(shè)計(jì)察迟？特點(diǎn)和注意事項(xiàng)是什么斩狱？案例介紹？十分感謝扎瓶。
松子老師：我自己經(jīng)歷過的是互聯(lián)網(wǎng)金融以及移動互聯(lián)網(wǎng)行所踊。對這兩塊比較清楚±醯埽互聯(lián)網(wǎng)金融起因?yàn)闃I(yè)務(wù)的特性是類金融類的污筷，與銀行有些地方是相似的。
比如大約在2012年前支付寶業(yè)務(wù)特點(diǎn)涉及類金融交易：充值乍赫、提現(xiàn)瓣蛀、賬務(wù)管理類電子商務(wù)：購物交易過程變更、實(shí)際交易（對B機(jī)票雷厂、對C水電等） 非純電子商務(wù)惋增；純金融；個人信用改鲫，理財(cái)類诈皿。系統(tǒng)之間依賴度較為復(fù)雜，垂直依賴（業(yè)務(wù)與核心）跨層依賴（跨過交易到賬務(wù)）像棘。
在設(shè)計(jì)方法上還是采用維度模型設(shè)計(jì)方式檐迟。底層是數(shù)據(jù)驅(qū)動為向?qū)矸悖Y(jié)合業(yè)務(wù)需求驅(qū)動，通過簡單、退化維度的方式拉寬表結(jié)構(gòu)厢绝。
底層采用松耦合設(shè)計(jì)参淹。主題之間是松耦合方式。至體內(nèi)采用細(xì)粒度退化維度。
在主題域上的的設(shè)計(jì)基本參考了OMG的數(shù)據(jù)倉庫元數(shù)據(jù)設(shè)計(jì)CWM模型咸作、IBM 的fsdm金融模型、還有新巴塞爾資本協(xié)議（Basel II Capital Accord）需提供數(shù)據(jù)規(guī)范去的設(shè)計(jì)宵睦。所以數(shù)據(jù)模型是五層的結(jié)構(gòu)记罚。
在細(xì)節(jié)處理上，增量ODS層數(shù)據(jù)和前一天DWD相關(guān)表進(jìn)行 merge處理壳嚎。
在一些層次上桐智，基本聚合、匯總增加派生事實(shí)表（簡單一句話退化為度打?qū)挘┪鼙病Ｈ缓蟀凑諛I(yè)務(wù)主體合并信息等酵使。
比如開始給大家分享的那張圖：
(點(diǎn)擊放大圖像)
[圖片上傳中。焙糟。口渔。（13）]
在維度模型退化處理時，要注意最細(xì)粒度數(shù)據(jù)保留穿撮、不同層次的數(shù)據(jù)支持?jǐn)?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ù)模型栗柒。
這種元數(shù)據(jù)驅(qū)動工具型數(shù)據(jù)產(chǎn)品我會在未來數(shù)據(jù)產(chǎn)品系列中做詳細(xì)介紹的礁扮。
3****，互聯(lián)網(wǎng)企業(yè)大數(shù)據(jù)平臺的發(fā)展歷程是怎樣的瞬沦？
松子老師：這個我相信應(yīng)該是傳統(tǒng)數(shù)據(jù)平臺朋友提到的太伊。傳統(tǒng)行業(yè)數(shù)據(jù)平臺架構(gòu)演進(jìn)我總結(jié)簡單一句話說“基本上可以分為五個時代、四種架構(gòu)”逛钻，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與類型暴增的特點(diǎn)僚焦，從高階架構(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é)下來用戶特點(diǎn)：
(點(diǎn)擊放大圖像)
更加詳細(xì)的每一代數(shù)據(jù)平臺建設(shè)名扛、服務(wù)角色特點(diǎn)您可以看我這個系列文章的第三篇囱怕，http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-paet02
4****抚岗，有沒有好的元數(shù)據(jù)管理工具推薦？主要偏向數(shù)據(jù)字典與血統(tǒng)等塑崖。
松子老師：元數(shù)據(jù)以前目前沒有太多的好管理工具。以前是在支付寶是我自己設(shè)計(jì)的一個數(shù)據(jù)產(chǎn)品惹苗。第一版自己用Delphi 開發(fā)的。
（圖很多：）
(點(diǎn)擊放大圖像)
[圖片上傳中耸峭。桩蓉。。（15）]
(點(diǎn)擊放大圖像)
[圖片上傳中劳闹。院究。。（16）]
(點(diǎn)擊放大圖像)
[圖片上傳中本涕。业汰。。（17）]
(點(diǎn)擊放大圖像)
[圖片上傳中菩颖。样漆。。（18）]
(點(diǎn)擊放大圖像)
[圖片上傳中晦闰。放祟。。（19）]
以前被逼的自己寫了一個呻右，通過解析跪妥，實(shí)現(xiàn)了字段級的血緣影響分析。這只是第二步声滥，后來又把running 信息給搞了進(jìn)來眉撵。還有分享時提到的模型信息、整個閉環(huán)的分類信息落塑。
這是一個分支：
(點(diǎn)擊放大圖像)
[圖片上傳中纽疟。。芜赌。（20）]
但是我們實(shí)現(xiàn)了字段級解析準(zhǔn)確率達(dá)到了94%左右仰挣。有細(xì)微的錯誤就人工revew一遍。
5. ****松子老師缠沈，數(shù)據(jù)管控的數(shù)據(jù)質(zhì)量部分是怎么處理的呢膘壶？
松子老師： 數(shù)據(jù)管控， 這方面我不太懂的洲愤，但是數(shù)據(jù)質(zhì)量颓芭，這玩意可大可小的。比如像在分享時說過的柬赐，在移動互聯(lián)網(wǎng)的數(shù)據(jù)質(zhì)量處理方式可以由原有的ETL(ELT)階段前置到業(yè)務(wù)系統(tǒng)去解決亡问，比如移動互聯(lián)網(wǎng)的App log 日志闷尿，日志標(biāo)準(zhǔn)化后事件模型”存儲來解決。那非app 日志類如何解決呢比如Payment微谓、order等憨栽，數(shù)據(jù)質(zhì)量比較考慮的可以只做到監(jiān)控。
我來分享個圖床玻。剛好是我設(shè)計(jì)數(shù)據(jù)質(zhì)量產(chǎn)品時搞的毁涉，理清數(shù)據(jù)質(zhì)量的問題：
(點(diǎn)擊放大圖像)
[圖片上傳中。锈死。贫堰。（21）]
(點(diǎn)擊放大圖像)
[圖片上傳中。待牵。其屏。（22）]
(點(diǎn)擊放大圖像)
[圖片上傳中。缨该。偎行。（23）]
只要數(shù)據(jù)進(jìn)入倉庫與應(yīng)用體系，處理起來就比較困難了压彭，所以在數(shù)據(jù)平臺階段最好是通過監(jiān)控睦优、前置去解決。目前數(shù)據(jù)質(zhì)量確實(shí)難以100%由事后搞到事前去處理壮不。我對數(shù)據(jù)平臺與數(shù)據(jù)產(chǎn)品的建設(shè)就是實(shí)用為主汗盘。怎么實(shí)用怎么來。我是比較現(xiàn)實(shí)的實(shí)用主義者询一。
6. ****能否分享一些數(shù)據(jù)產(chǎn)品種類及實(shí)例：
松子老師：在前邊五個問題隐孽、以及文章中又都涉及數(shù)據(jù)產(chǎn)品實(shí)力的一些分享。
提到數(shù)據(jù)產(chǎn)品的分類我就想把這個圖發(fā)出來健蕊。
自己認(rèn)為沒有特別明確的劃分線菱阵，但是數(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工具蛛倦、資源管控等等。
面向用戶功能有報(bào)表型啦桌、多維型數(shù)據(jù)產(chǎn)品溯壶、定制化數(shù)據(jù)產(chǎn)品、挖掘型數(shù)據(jù)產(chǎn)品。
面向內(nèi)部用戶且改、外部個人用戶丰捷、外部企業(yè)用戶又有不同的分類歧寺。
根據(jù)業(yè)務(wù)又可以劃分很多挚歧，面向C類用戶视事、面向B類商戶梢杭、金融風(fēng)險(xiǎn)等等
從近幾年的數(shù)據(jù)產(chǎn)品來看另凌，是更好的輔助用戶的做決策的一種產(chǎn)品形態(tài)看幼，在用戶的決策與行動中充當(dāng)信息的分析者與價值使用者席覆；數(shù)據(jù)產(chǎn)品有個自己的共性：由解決的一個實(shí)際的業(yè)務(wù)問題出發(fā)直砂，分解出的分析指標(biāo)菌仁，分析模型，分析流程組成静暂，再考慮到功能易用性济丘，未來功能擴(kuò)展，考慮用戶對數(shù)據(jù)易用性（比如數(shù)據(jù)的呈現(xiàn)層次洽蛀，不可能一次把所有數(shù)據(jù)的呈現(xiàn)給用戶）來組成的摹迷。
(點(diǎn)擊放大圖像)
[圖片上傳中。郊供。峡碉。（24）]
7. ****銀行業(yè)從傳統(tǒng)的ods到edw再到大數(shù)據(jù)平臺這塊過渡，模型如何建設(shè)驮审？平臺優(yōu)勢如何發(fā)揮鲫寄？
松子老師：這個問題還是有些難度的，自己回答的可能有些片面疯淫。首先我們清醒的清楚“大數(shù)據(jù)”是什么地来？再次不同的場景可以采用不同的技術(shù)去解決。
“大數(shù)據(jù)”熙掺，拆開來看大未斑、數(shù)據(jù)，大可以是指的數(shù)據(jù)源結(jié)構(gòu)簡單（ps 如果了解過當(dāng)代對大數(shù)據(jù)的定義就知道四個特性）但是量級夠大币绩，比如清算蜡秽、結(jié)算、對公类浪、對私载城、中間業(yè)務(wù)等等每一個拿出來都是幾十T，但是這些業(yè)務(wù)數(shù)據(jù)都是保存?zhèn)鹘y(tǒng)的關(guān)系型數(shù)據(jù)庫中如DB2费就、Oracle诉瓦、MSsql中，因?yàn)樵跀?shù)據(jù)平臺存儲是通過準(zhǔn)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ù)的去演進(jìn)解決膊夹。（最早時我的是中信銀行、光大銀行在2011年左右開始考慮Hadoop技術(shù)昔脯，后來不知道如何了）啄糙。
但是互聯(lián)網(wǎng)的數(shù)據(jù)平臺技術(shù)大都是NOSQL模式，犧牲掉了傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)一致性云稚、完整性隧饼、唯一索引等等，只干性能的事情（當(dāng)然除了性能静陈、可擴(kuò)展性也是的）.
原有在傳統(tǒng)數(shù)據(jù)平臺模型設(shè)計(jì)上可以考慮的一些通過主外鍵燕雁、唯一索引做一些業(yè)務(wù)約束的方法，在nosql上統(tǒng)統(tǒng)的都沒有了鲸拥，這些約束必須放到數(shù)據(jù)加工階段去想辦法做檢查拐格。傳統(tǒng)數(shù)據(jù)平臺如果在Insert、update數(shù)據(jù)時違反了業(yè)務(wù)約束可以做報(bào)警或異常處理刑赶，但是在Nosql的平臺上要求ETL 去手動遵守這些規(guī)則檢查捏浊。但是有時ETL開發(fā)根本不遵守的，僅僅是兩個表關(guān)聯(lián)起來撞叨，也可能忘記按照某一個業(yè)務(wù)唯一索引做去重操作呛伴。簡單說，原有靠關(guān)系型數(shù)據(jù)庫本身機(jī)制去做檢查一些規(guī)則變?yōu)槿斯ぺ怂優(yōu)槿斯ぞ蜁稿e热康。
從關(guān)系型數(shù)據(jù)平臺往Nosql數(shù)據(jù)平臺遷移時，尤其是對傳統(tǒng)行業(yè)的業(yè)務(wù)來說劣领，在模型設(shè)計(jì)階段姐军、以及給出的ETL口徑要考慮更多的業(yè)務(wù)規(guī)則檢查，其次要考慮更多的維度退化尖淘、多冗余奕锌、表打?qū)捥幚怼：唵握f就是發(fā)揮數(shù)據(jù)平臺的計(jì)算能力同時要更加的各方面確保數(shù)據(jù)準(zhǔn)確安全可靠村生。
數(shù)據(jù)模型ODS 到EDW 這塊的設(shè)計(jì)方法百度上留下的文檔資料太多的了惊暴，請這位提問的老師百度吧。
**8****．大數(shù)據(jù)****倉庫****中如何做快速****維處****理趁桃？互****聯(lián)****網(wǎng)數(shù)****倉****數(shù)據(jù)****質(zhì)****量不好如何****對****數(shù)辽话，如何確立****標(biāo)****準(zhǔn)的****對****數(shù)口徑肄鸽？******
松子老師：快速變化維度可以轉(zhuǎn)化為緩慢變化為來出來，我自己理解的快速維度是相對于緩慢維度參照的來說的油啤。
舉個例子典徘，年齡-轉(zhuǎn)化為天數(shù)可以是定義快速變化維度，因?yàn)槊刻於荚谧兓Ｎ覀兛梢园涯挲g退化為區(qū)間維度來處理，還可以把年齡做成動態(tài)維度來處理井濒，事實(shí)表中保存的就是實(shí)際的出生年月并打?qū)挶恚挲g(天)通過計(jì)算方式來處理神凑。還有種方法通過對代理鍵的方式來處理。
我目前也不知道對數(shù)據(jù)的標(biāo)準(zhǔn)是什么。但是我自己用的方法，把一個指標(biāo)的整個數(shù)據(jù)流向切出幾個關(guān)鍵點(diǎn)通過SQL去實(shí)現(xiàn)對數(shù)帘瞭，看波動振幅，波動曲線蒿讥。同時還會比如發(fā)不通的版本的小流量測試的方式來做數(shù)據(jù)校對。
9****． 做為數(shù)據(jù)行業(yè)從業(yè)者抛腕，需要掌握哪些重要的基礎(chǔ)知識芋绸？另：如果從零開始建立一個數(shù)據(jù)平臺，需要哪些資源配置（人担敌，財(cái)摔敛，物，技術(shù)）全封？大致總投資額度多少马昙？如果同行產(chǎn)品間多種來源的數(shù)據(jù)，可有成熟的解決方案刹悴？謝謝…
松子老師：這個問題太宏觀了行楞。作為數(shù)據(jù)行業(yè)從業(yè)者，需要掌握哪些重要基礎(chǔ)知識土匀，這個是要看從事具體數(shù)據(jù)域的垂直行業(yè)子房。
比如說 數(shù)據(jù)開發(fā)、數(shù)據(jù)模型就轧、數(shù)據(jù)產(chǎn)品证杭、數(shù)據(jù)分析師、數(shù)據(jù)運(yùn)營妒御、數(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ù)目標(biāo)不太明確下揭保，難以確定方案，人員配置上選用不同技術(shù)方案去搭建的配置是不太一樣的魄宏，比如說傳統(tǒng)平臺來講秸侣，運(yùn)維、DBA宠互、數(shù)據(jù)開發(fā)味榛、數(shù)據(jù)模型寝志、報(bào)表人員灼伤。
從互聯(lián)網(wǎng)數(shù)據(jù)平臺基本配置上，數(shù)據(jù)架構(gòu)師明垢、運(yùn)維券册、底層大數(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ù)岔激。
10. Standalone****模式下勒极，Model.save(Path)怎么一直提示錯誤，是不是配置Spark時需要將Hdfs的配置引進(jìn)來啊～虑鼎？表示初學(xué)Spark
松子老師：這個問題有點(diǎn)超出我的能力范圍了河质，所以對不起回答不了。
我本身不是做技術(shù)的震叙。僅知道一點(diǎn)技術(shù)名詞掀鹅。
11. ****傳統(tǒng)銀行業(yè)數(shù)據(jù)模型什么時候會走向互聯(lián)網(wǎng)模式呢？目前在傳統(tǒng)銀行數(shù)據(jù)平臺的產(chǎn)品是不是特別多媒楼？
松子老師：這個問題我自己就不知道了乐尊，或許是傳統(tǒng)銀行在數(shù)據(jù)平臺的實(shí)施上全面用互聯(lián)網(wǎng)的Nosql大數(shù)據(jù)處理技術(shù)吧。至于說傳統(tǒng)銀行數(shù)據(jù)模型用現(xiàn)有的互聯(lián)網(wǎng)數(shù)據(jù)模型理念去設(shè)計(jì)是否完全可行划址，數(shù)據(jù)一致性扔嵌、高準(zhǔn)確性通過更多的方案去保證限府。
首先我需要確定一下這個產(chǎn)品是否指的“數(shù)據(jù)產(chǎn)品”。
如果是數(shù)據(jù)產(chǎn)品痢缎，那其實(shí)傳統(tǒng)行業(yè)數(shù)據(jù)平臺本身就有一些數(shù)據(jù)產(chǎn)品了胁勺，而且也都是存在的。數(shù)據(jù)產(chǎn)品自從數(shù)據(jù)倉庫出現(xiàn)以來它其實(shí)一直都存在的独旷，只不過是近幾年因?yàn)榛ヂ?lián)網(wǎng)特別愛制造“流行詞“把數(shù)據(jù)產(chǎn)品這個詞給放大了署穗。互聯(lián)網(wǎng)是得數(shù)據(jù)產(chǎn)品從早期的重量級逐漸進(jìn)化為輕量級嵌洼、從大而全的解決方案逐漸演進(jìn)為因小而美案疲。
我來給出幾組例子，大約從2004年到現(xiàn)在的幾組數(shù)據(jù)產(chǎn)品的例子
(點(diǎn)擊放大圖像)
[圖片上傳中。。猜丹。（25）]
(點(diǎn)擊放大圖像)
[圖片上傳中。备畦。。（26）]
(點(diǎn)擊放大圖像)
[圖片上傳中许昨。懂盐。。（27）]
(點(diǎn)擊放大圖像)
[圖片上傳中车要。。崭倘。（28）]
(點(diǎn)擊放大圖像)
[圖片上傳中翼岁。。司光。（29）]
(點(diǎn)擊放大圖像)
[圖片上傳中琅坡。。残家。（30）]
(點(diǎn)擊放大圖像)
[圖片上傳中榆俺。。坞淮。（31）]
你可以分類一下茴晋，這些數(shù)據(jù)產(chǎn)品的特點(diǎn)是什么？滿足了用戶怎么樣的痛點(diǎn)需求回窘？滿足了用戶怎么樣的使用流程诺擅。
12 ****。傳統(tǒng)行業(yè)的數(shù)據(jù)倉庫從業(yè)人員啡直，如果轉(zhuǎn)到互聯(lián)網(wǎng)行業(yè)烁涌，應(yīng)該學(xué)習(xí)哪些技能苍碟？
松子老師：這個問題你可以百度搜索“大數(shù)據(jù)職位所需要的數(shù)據(jù)技能” http://blog.jobbole.com/99039/ 這篇文章。自己覺得人家回答的比我專業(yè)撮执。//
我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史（四）：互聯(lián)網(wǎng)時代 ? 下篇
http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-internet-age
編者按：本文是松子（李博源）的大數(shù)據(jù)平臺發(fā)展史系列文章的第四篇（共四篇）微峰，本系列以獨(dú)特的視角，比較了非互聯(lián)網(wǎng)和互聯(lián)網(wǎng)兩個時代以及傳統(tǒng)行業(yè)與非傳統(tǒng)行業(yè)抒钱。是對數(shù)據(jù)平臺發(fā)展的一個回憶蜓肆，對非互聯(lián)網(wǎng)、互聯(lián)網(wǎng)继效，從數(shù)據(jù)平臺的用戶角度症杏、數(shù)據(jù)架構(gòu)演進(jìn)、模型等進(jìn)行了闡述瑞信。
在互聯(lián)網(wǎng)時代被弱化的數(shù)據(jù)模型
談起數(shù)據(jù)模型就不得不提傳統(tǒng)數(shù)據(jù)平臺架構(gòu)發(fā)展厉颤，我相信很多朋友都曉得傳統(tǒng)數(shù)據(jù)平臺的知識，其架構(gòu)演進(jìn)簡單一句話說“基本上可以分為五個時代凡简、四種架構(gòu)”踱卵，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與數(shù)據(jù)源類型多樣化特點(diǎn)尿瞭，從高階架構(gòu)上來看大約從傳統(tǒng)數(shù)據(jù)平臺第三代架構(gòu)開始延續(xù)的，但是往后的發(fā)展從我自己的這一點(diǎn)知識上很難對互聯(lián)網(wǎng)的數(shù)據(jù)平臺做架構(gòu)歸類。
但是從數(shù)據(jù)平臺建設(shè)與服務(wù)角色上還是有章可循的砖织。就像上篇分享到那樣，類比兩個行業(yè)肿孵，互聯(lián)網(wǎng)企業(yè)中員工年齡比非互聯(lián)網(wǎng)企業(yè)的要年輕垒手、受教育程度、對計(jì)算機(jī)的焦慮程度明顯比傳統(tǒng)企業(yè)要低匀谣、還偶遇其它各方面的緣故照棋，導(dǎo)致了數(shù)據(jù)平臺所面對用戶群體與非互聯(lián)網(wǎng)數(shù)據(jù)平臺有所差異化。
傳統(tǒng)行業(yè)與互聯(lián)網(wǎng)行業(yè)數(shù)據(jù)平臺用戶特性我只選擇前文章的兩張圖來表示
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
在傳統(tǒng)數(shù)據(jù)平臺要背后有一個完整數(shù)據(jù)倉庫團(tuán)隊(duì)去服務(wù)業(yè)務(wù)方武翎，業(yè)務(wù)方嗷嗷待哺的等待被動方式去滿足烈炭。中低層數(shù)據(jù)基本不會對業(yè)務(wù)方開放，所以不管數(shù)據(jù)模型采用何種建模方式宝恶，主要滿足當(dāng)時數(shù)據(jù)架構(gòu)規(guī)劃即可符隙。
互聯(lián)網(wǎng)業(yè)務(wù)的快速發(fā)展使得大家已經(jīng)從經(jīng)營、分析的訴求重點(diǎn)轉(zhuǎn)為數(shù)據(jù)化的精細(xì)運(yùn)營上垫毙，如何做好精細(xì)化運(yùn)營問題上來霹疫，當(dāng)資源不夠時用戶就叫喊，甚至有的業(yè)務(wù)方會挽起袖子來自己參與到從數(shù)據(jù)整理综芥、加工更米、分析階段。
此時呢毫痕，原有建設(shè)數(shù)據(jù)平臺的多個角色（數(shù)據(jù)開發(fā)征峦、模型設(shè)計(jì)）可能轉(zhuǎn)為對其它非專業(yè)使用數(shù)據(jù)方迟几，做培訓(xùn)、咨詢與落地栏笆，寫更加適合當(dāng)前企業(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àn)椴粚I(yè)性蚜枢，導(dǎo)致數(shù)據(jù)質(zhì)量問題、重復(fù)對分?jǐn)?shù)據(jù)浪費(fèi)存儲與資源针饥、口徑多樣化厂抽、編碼不統(tǒng)一、命名問題等等原因丁眼。數(shù)據(jù)質(zhì)量逐漸變成一個特別突出的問題筷凤。
傳統(tǒng)企業(yè)的數(shù)據(jù)源基本來自excel、表格苞七、DB系統(tǒng)等藐守，但在互聯(lián)網(wǎng)有網(wǎng)站點(diǎn)擊流日志、視頻、音頻、圖片數(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ù)有些力不從心融柬。
當(dāng)數(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è)也有自己特點(diǎn)骡澈，傳統(tǒng)行業(yè)所涉及數(shù)據(jù)模型這個領(lǐng)域涉及的很多內(nèi)容在互聯(lián)網(wǎng)變成以其他的曲線救國的方式存在了锅纺。
在互聯(lián)網(wǎng)曲線救國新解決
回顧在傳統(tǒng)行業(yè)數(shù)據(jù)平臺中，不管兩位大師爭論點(diǎn)數(shù)據(jù)模型的設(shè)計(jì)采用那種范式（Bill Inmon的EDW的原則是準(zhǔn)三范式的設(shè)計(jì)肋殴、Ralph kilmbal是星型結(jié)構(gòu)）但是都要非常重視數(shù)據(jù)源的質(zhì)量問題囤锉。所以傳統(tǒng)行業(yè)的數(shù)據(jù)模型會全盤考慮數(shù)據(jù)質(zhì)量問題坦弟，并通過數(shù)據(jù)抽樣分析給出合適的清洗口徑。
(點(diǎn)擊放大圖像)
上圖來自我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ù)”對一年的還是不準(zhǔn)的）赤炒。在應(yīng)對數(shù)據(jù)的質(zhì)量問題，目前互聯(lián)網(wǎng)有些做法是把數(shù)據(jù)標(biāo)準(zhǔn)化前置到業(yè)務(wù)數(shù)據(jù)產(chǎn)生就做亏较，從根源上去杜絕數(shù)據(jù)質(zhì)量莺褒，但是這種場景比較實(shí)用在Log 日志的數(shù)據(jù)源中，比如移動互聯(lián)網(wǎng)最近流行的基于事件模型“Event”模型雪情，在日志產(chǎn)生時就規(guī)定好存儲格式（備注：大家度娘搜索遵岩，“學(xué)習(xí)筆記：The Log（我所讀過的最好的一篇分布式技術(shù)文章）” 對這個講解很詳細(xì)）。
在傳統(tǒng)行業(yè)旺罢，目前還是以混合模型設(shè)計(jì)方式為主旷余。在互聯(lián)網(wǎng)的我所接觸的一些業(yè)務(wù)，在參照傳統(tǒng)數(shù)據(jù)模型方法論基礎(chǔ)上逐步演進(jìn)適合互聯(lián)網(wǎng)數(shù)據(jù)的數(shù)據(jù)模型方法扁达。
比如互聯(lián)網(wǎng)金融等一些業(yè)務(wù)會參考傳統(tǒng)金融行業(yè)對主題域的劃分正卧、OMG數(shù)據(jù)倉庫元數(shù)據(jù)管理CWM模型、FSDM金融模型跪解，再進(jìn)一步考慮大數(shù)據(jù)處理特性去進(jìn)行設(shè)計(jì)益缎，所有從Hight Level 數(shù)據(jù)架構(gòu)圖看到主題層次劃分與傳統(tǒng)第三代數(shù)據(jù)倉庫還是很多相似之處，當(dāng)然模型架構(gòu)也有分三層瑰艘、四層芯杀、五層的。
不同的地方模型細(xì)節(jié)處理上已經(jīng)完全不一樣图仓，比如數(shù)據(jù)的多樣性罐盔、拉寬事實(shí)表、度量值單獨(dú)存儲救崔、滿足數(shù)據(jù)快速重生惶看、維度的二次降維處理等、增加大量冗余列六孵、增加大量派生列纬黎，結(jié)合自動化元數(shù)據(jù)來耦合、合并等相關(guān)管理劫窒。
(點(diǎn)擊放大圖像)
[圖片上傳中本今。。。（4）]
上圖是支付寶非常早期數(shù)據(jù)模型
(點(diǎn)擊放大圖像)
上圖是支付寶非常早期數(shù)據(jù)模型
我們常提到的多維模型在大數(shù)據(jù)處理下進(jìn)行了退化維度處理冠息。大家知道Olap多維模型挪凑，隨著維度的增加事實(shí)表的數(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è)計(jì)多維挖掘分析數(shù)據(jù)產(chǎn)品背后的技術(shù)就是搜索引擎實(shí)現(xiàn)的），現(xiàn)在應(yīng)該也有新技術(shù)出現(xiàn)了來解決類似的問題瓮孙。
(點(diǎn)擊放大圖像)
上圖為2012年產(chǎn)品UI之一唐断。
(點(diǎn)擊放大圖像)
[圖片上傳中。杭抠。脸甘。（7）]
上圖是2011-2012年該產(chǎn)品系列背后當(dāng)時使用的技術(shù)
互聯(lián)網(wǎng)業(yè)務(wù)特點(diǎn)業(yè)務(wù)垂直拆分非常細(xì)，比如一個用戶注冊偏灿、密碼找回的流程有可能存在好幾個產(chǎn)品負(fù)責(zé)同一個業(yè)務(wù)流程不同環(huán)節(jié)丹诀，相關(guān)的一個策略、產(chǎn)品feature快速迭代上線等等都要數(shù)據(jù)評估翁垂。數(shù)據(jù)從前端埋點(diǎn)到采集然后再由各個環(huán)節(jié)到數(shù)據(jù)平臺铆遭，再有數(shù)據(jù)分析師或各業(yè)務(wù)部門去使用，基本拉長了時間周期沿猜。需求部門與實(shí)施部門能力和經(jīng)驗(yàn)有千差萬別的需求枚荣，造成了懂技術(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ù)特點(diǎn)是變化非常迅速的，能穩(wěn)定的業(yè)務(wù)達(dá)到65%算對數(shù)據(jù)平臺是個福音了（根據(jù)對某寶寶的印象）剩余的業(yè)務(wù)變化迅速战秋，必然導(dǎo)致數(shù)據(jù)模型快速上下線骇窍。
Kimball老人家提出的維度建模（備注望蜡，在本系列發(fā)展史得第一篇有介紹）圍繞業(yè)務(wù)模型能夠非常直觀的表達(dá)出業(yè)務(wù)的數(shù)據(jù)關(guān)系燃领，但是在互聯(lián)網(wǎng)NOSQL犧牲掉了關(guān)系型數(shù)據(jù)庫的一致性聘惦、完整性等等很多東西。維度數(shù)據(jù)模型又基于這些大數(shù)據(jù)技術(shù)的笋籽，所以進(jìn)化的更加輕量級與基于細(xì)節(jié)數(shù)據(jù)的維度退化建模（原有的緩慢變化維蹦漠、快速變化維椭员、大維车海、迷你維、父子維、雪花維為了適應(yīng)互聯(lián)網(wǎng)的大數(shù)據(jù)Nosql處理技術(shù)進(jìn)行反規(guī)范化侍芝、化&數(shù)據(jù)冗余設(shè)計(jì)研铆。
退化維度的反規(guī)范化設(shè)計(jì)一方面可以把一條查詢語句所需要的所有數(shù)據(jù)組合起來放到一個地方存儲 Key values 的方式（比如說商品有不同類型，每一種類型商品又有自己的不同屬性州叠，可以采用一對多棵红、多對多的方式存儲，例如把一個多維映射為一個Key value）咧栗。
講到互聯(lián)網(wǎng)數(shù)據(jù)平臺就要提數(shù)據(jù)模型逆甜，提了數(shù)據(jù)模型就要提Nosql技術(shù)，
(點(diǎn)擊放大圖像)
上圖來自Nosql文檔系列的一幅圖
Nosql 是大數(shù)據(jù)處理的特征之一致板〗簧罚互聯(lián)網(wǎng)數(shù)據(jù)平臺數(shù)據(jù)模型與NoSql技術(shù)還是蠻緊密的。這里有外文講解Nosql Data modeling technigues 從技術(shù)角度講解非常詳（https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/）斟或。
因?yàn)榍斑吿岬降拇髷?shù)據(jù)平臺技術(shù)特性決定了傳統(tǒng)edw模型素征、維度模型直接在互聯(lián)網(wǎng)數(shù)據(jù)大數(shù)據(jù)平臺部署或許還有“好些未知”障礙等待大家去克服。同時在傳統(tǒng)數(shù)據(jù)建模用到的一些方法經(jīng)過互聯(lián)網(wǎng)熏陶或許演進(jìn)成一種新的數(shù)據(jù)產(chǎn)品或方案吧萝挤。
到此為止“我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史”上下共四篇與大家分享完畢御毅，這個寫作前后經(jīng)歷剛好一個月左右，算是對自己數(shù)據(jù)從業(yè)經(jīng)歷回顧之一吧怜珍。在知識的整理中很多都是蜻蜓點(diǎn)水端蛆，每個知識域都是一個非常深的專業(yè)方向，自己涉足很膚淺酥泛，在文章中分享不足之處請各位讀者見諒Ｆ鬯啊！
個人郵箱是5592094@qq.com 歡迎電郵交流揭璃。
接下來我會進(jìn)入數(shù)據(jù)產(chǎn)品這個領(lǐng)域的分享晚凿，當(dāng)年車品覺老師自豪的作品之一“黃金策”，我是數(shù)據(jù)產(chǎn)品經(jīng)理。（ps：自己躲在墻角拿車品覺老師往自己臉上貼金了）饥漫。
后記
有一次數(shù)據(jù)產(chǎn)品神策的創(chuàng)始人兼好友@桑文鋒＠SensorsData跟我說來做次分享吧莲组，我當(dāng)時出了幾個題目，最后就選擇了“我所經(jīng)歷的大數(shù)據(jù)平臺“燥筷，就形成了大家看到的”我所經(jīng)歷的大數(shù)據(jù)平臺“系列文章.
在整理期間得到了死黨@周愛民、@神策-桑文峰院崇、 InfoQ小編@Tina Du 肆氓、@betty zhou @Laurel大力協(xié)助，在這里感謝５装辍Ｐ痪尽！
番外篇
這一篇是在24日舉行的分享大家提到的一些問題，經(jīng)過整理算是對正文的補(bǔ)充吧拨扶，從互聯(lián)網(wǎng)敏捷數(shù)據(jù)模型等角度做了較深入的細(xì)節(jié)介紹凳鬓。同時在數(shù)據(jù)產(chǎn)品方面的回答包含了一點(diǎn)未來寫作篇“數(shù)據(jù)產(chǎn)品”系列的一點(diǎn)內(nèi)容。
1****患民，傳統(tǒng)我們做BI的缩举，做數(shù)據(jù)展現(xiàn)會建模后以pivot展現(xiàn)cube數(shù)據(jù)，不知道現(xiàn)在互聯(lián)網(wǎng)公司數(shù)據(jù)展示如何做的匹颤？第三方工具還是用API取數(shù)據(jù)平臺里的數(shù)據(jù)仅孩？adhoc報(bào)表及靈活更換維度的時候web端一般是怎么做的？
松子老師：剛才文章中提到了比如傳統(tǒng)行業(yè)的多維數(shù)據(jù)模型cube印蓖。在互聯(lián)網(wǎng)采用的曲線救國方式解決的杠氢。 在分享中我給出了幾個圖。就是通過搜索引擎曲線救國方式實(shí)現(xiàn)類似Olap的模擬另伍。
在這塊的模型的處理上采用的是維度退化處理鼻百。通過反規(guī)范化，數(shù)據(jù)項(xiàng)摆尝、數(shù)據(jù)冗余去處理温艇。在前端做特殊處理。
這個當(dāng)時產(chǎn)品原型之一：
(點(diǎn)擊放大圖像)
這是一個2011年-2012年左右的數(shù)據(jù)產(chǎn)品堕汞，當(dāng)時算是即時計(jì)算的一種勺爱。不過已經(jīng)過去好幾年了，當(dāng)今新技術(shù)下Olap 引擎應(yīng)該有很好的提升讯检。
目前我知道的家互聯(lián)網(wǎng)公司琐鲁，在前端展現(xiàn)有使用第三方套件比如spagoBi、pentaho 等 有自己設(shè)計(jì)開發(fā)定制化數(shù)據(jù)前端展現(xiàn)人灼。比如我剛開始分享的那兩個之前在去哪兒網(wǎng)設(shè)計(jì)的數(shù)據(jù)平臺內(nèi)部界面之一围段，當(dāng)然數(shù)據(jù)產(chǎn)品是另一個話題了，通過對數(shù)據(jù)分析抽象指標(biāo)投放、分析模型奈泪、用戶使用功能與流程、未來規(guī)劃考慮用戶體驗(yàn)去設(shè)計(jì)灸芳。
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
[圖片上傳中僻族。舔痕。。（11）]
(點(diǎn)擊放大圖像)
2****批糟，互聯(lián)網(wǎng)財(cái)經(jīng)類公司唆貌，業(yè)務(wù)包括財(cái)經(jīng)網(wǎng)站膘茎、基金众弓、股票、金融等壁却，這類公司的數(shù)據(jù)倉庫模型應(yīng)該如何設(shè)計(jì)？特點(diǎn)和注意事項(xiàng)是什么寻定？案例介紹？十分感謝精耐。
松子老師：我自己經(jīng)歷過的是互聯(lián)網(wǎng)金融以及移動互聯(lián)網(wǎng)行狼速。對這兩塊比較清楚∝酝＃互聯(lián)網(wǎng)金融起因?yàn)闃I(yè)務(wù)的特性是類金融類的向胡，與銀行有些地方是相似的。
比如大約在2012年前支付寶業(yè)務(wù)特點(diǎn)涉及類金融交易：充值惊完、提現(xiàn)僵芹、賬務(wù)管理類電子商務(wù)：購物交易過程變更、實(shí)際交易（對B機(jī)票小槐、對C水電等） 非純電子商務(wù)拇派；純金融；個人信用凿跳，理財(cái)類件豌。系統(tǒng)之間依賴度較為復(fù)雜，垂直依賴（業(yè)務(wù)與核心）跨層依賴（跨過交易到賬務(wù)）控嗜。
在設(shè)計(jì)方法上還是采用維度模型設(shè)計(jì)方式茧彤。底層是數(shù)據(jù)驅(qū)動為向?qū)ВY(jié)合業(yè)務(wù)需求驅(qū)動疆栏，通過簡單曾掂、退化維度的方式拉寬表結(jié)構(gòu)。
底層采用松耦合設(shè)計(jì)壁顶。主題之間是松耦合方式珠洗。至體內(nèi)采用細(xì)粒度退化維度。
在主題域上的的設(shè)計(jì)基本參考了OMG的數(shù)據(jù)倉庫元數(shù)據(jù)設(shè)計(jì)CWM模型若专、IBM 的fsdm金融模型险污、還有新巴塞爾資本協(xié)議（Basel II Capital Accord）需提供數(shù)據(jù)規(guī)范去的設(shè)計(jì)。所以數(shù)據(jù)模型是五層的結(jié)構(gòu)富岳。
在細(xì)節(jié)處理上蛔糯，增量ODS層數(shù)據(jù)和前一天DWD相關(guān)表進(jìn)行 merge處理。
在一些層次上，基本聚合袜香、匯總增加派生事實(shí)表（簡單一句話退化為度打?qū)挘└於摹Ｈ缓蟀凑諛I(yè)務(wù)主體合并信息等。
比如開始給大家分享的那張圖：
(點(diǎn)擊放大圖像)
[圖片上傳中淮逻。琼懊。。（13）]
在維度模型退化處理時爬早，要注意最細(xì)粒度數(shù)據(jù)保留哼丈、不同層次的數(shù)據(jù)支持?jǐn)?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ù)模型车胡。
這種元數(shù)據(jù)驅(qū)動工具型數(shù)據(jù)產(chǎn)品我會在未來數(shù)據(jù)產(chǎn)品系列中做詳細(xì)介紹的。
3****照瘾，互聯(lián)網(wǎng)企業(yè)大數(shù)據(jù)平臺的發(fā)展歷程是怎樣的匈棘？
松子老師：這個我相信應(yīng)該是傳統(tǒng)數(shù)據(jù)平臺朋友提到的。傳統(tǒng)行業(yè)數(shù)據(jù)平臺架構(gòu)演進(jìn)我總結(jié)簡單一句話說“基本上可以分為五個時代析命、四種架構(gòu)”主卫，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與類型暴增的特點(diǎn)，從高階架構(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é)下來用戶特點(diǎn)：
(點(diǎn)擊放大圖像)
[圖片上傳中。关噪。鸟蟹。（14）]
更加詳細(xì)的每一代數(shù)據(jù)平臺建設(shè)、服務(wù)角色特點(diǎn)您可以看我這個系列文章的第三篇使兔，http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-paet02
4****建钥，有沒有好的元數(shù)據(jù)管理工具推薦？主要偏向數(shù)據(jù)字典與血統(tǒng)等虐沥。
松子老師：元數(shù)據(jù)以前目前沒有太多的好管理工具熊经。以前是在支付寶是我自己設(shè)計(jì)的一個數(shù)據(jù)產(chǎn)品。第一版自己用Delphi 開發(fā)的欲险。
（圖很多：）
(點(diǎn)擊放大圖像)
[圖片上傳中镐依。。天试。（15）]
(點(diǎn)擊放大圖像)
[圖片上傳中槐壳。。喜每。（16）]
(點(diǎn)擊放大圖像)
[圖片上傳中。。智末。（17）]
(點(diǎn)擊放大圖像)
[圖片上傳中。吨灭。。（18）]
(點(diǎn)擊放大圖像)
[圖片上傳中刑巧。喧兄。。（19）]
以前被逼的自己寫了一個海诲，通過解析繁莹，實(shí)現(xiàn)了字段級的血緣影響分析檩互。這只是第二步特幔，后來又把running 信息給搞了進(jìn)來。還有分享時提到的模型信息闸昨、整個閉環(huán)的分類信息蚯斯。
這是一個分支：
(點(diǎn)擊放大圖像)
[圖片上傳中。饵较。拍嵌。（20）]
但是我們實(shí)現(xiàn)了字段級解析準(zhǔn)確率達(dá)到了94%左右。有細(xì)微的錯誤就人工revew一遍循诉。
5. ****松子老師横辆，數(shù)據(jù)管控的數(shù)據(jù)質(zhì)量部分是怎么處理的呢？
松子老師： 數(shù)據(jù)管控茄猫， 這方面我不太懂的狈蚤，但是數(shù)據(jù)質(zhì)量，這玩意可大可小的划纽。比如像在分享時說過的脆侮，在移動互聯(lián)網(wǎng)的數(shù)據(jù)質(zhì)量處理方式可以由原有的ETL(ELT)階段前置到業(yè)務(wù)系統(tǒng)去解決，比如移動互聯(lián)網(wǎng)的App log 日志勇劣，日志標(biāo)準(zhǔn)化后事件模型”存儲來解決靖避。那非app 日志類如何解決呢比如Payment、order等比默，數(shù)據(jù)質(zhì)量比較考慮的可以只做到監(jiān)控幻捏。
我來分享個圖。剛好是我設(shè)計(jì)數(shù)據(jù)質(zhì)量產(chǎn)品時搞的命咐，理清數(shù)據(jù)質(zhì)量的問題：
(點(diǎn)擊放大圖像)
[圖片上傳中粘咖。。侈百。（21）]
(點(diǎn)擊放大圖像)
[圖片上傳中瓮下。翰铡。。（22）]
(點(diǎn)擊放大圖像)
只要數(shù)據(jù)進(jìn)入倉庫與應(yīng)用體系讽坏，處理起來就比較困難了闯团，所以在數(shù)據(jù)平臺階段最好是通過監(jiān)控格二、前置去解決。目前數(shù)據(jù)質(zhì)量確實(shí)難以100%由事后搞到事前去處理。我對數(shù)據(jù)平臺與數(shù)據(jù)產(chǎn)品的建設(shè)就是實(shí)用為主专酗。怎么實(shí)用怎么來。我是比較現(xiàn)實(shí)的實(shí)用主義者誓禁。
6. ****能否分享一些數(shù)據(jù)產(chǎn)品種類及實(shí)例：
松子老師：在前邊五個問題唇牧、以及文章中又都涉及數(shù)據(jù)產(chǎn)品實(shí)力的一些分享。
提到數(shù)據(jù)產(chǎn)品的分類我就想把這個圖發(fā)出來抵屿。
自己認(rèn)為沒有特別明確的劃分線庆锦，但是數(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工具芳杏、資源管控等等。
面向用戶功能有報(bào)表型辟宗、多維型數(shù)據(jù)產(chǎn)品爵赵、定制化數(shù)據(jù)產(chǎn)品、挖掘型數(shù)據(jù)產(chǎn)品慢蜓。
面向內(nèi)部用戶亚再、外部個人用戶、外部企業(yè)用戶又有不同的分類晨抡。
根據(jù)業(yè)務(wù)又可以劃分很多氛悬，面向C類用戶、面向B類商戶耘柱、金融風(fēng)險(xiǎn)等等
從近幾年的數(shù)據(jù)產(chǎn)品來看如捅，是更好的輔助用戶的做決策的一種產(chǎn)品形態(tài)，在用戶的決策與行動中充當(dāng)信息的分析者與價值使用者调煎；數(shù)據(jù)產(chǎn)品有個自己的共性：由解決的一個實(shí)際的業(yè)務(wù)問題出發(fā)镜遣，分解出的分析指標(biāo)，分析模型士袄，分析流程組成悲关，再考慮到功能易用性谎僻，未來功能擴(kuò)展，考慮用戶對數(shù)據(jù)易用性（比如數(shù)據(jù)的呈現(xiàn)層次寓辱，不可能一次把所有數(shù)據(jù)的呈現(xiàn)給用戶）來組成的艘绍。
(點(diǎn)擊放大圖像)
[圖片上傳中。。。（24）]
7. ****銀行業(yè)從傳統(tǒng)的ods到edw再到大數(shù)據(jù)平臺這塊過渡欺劳，模型如何建設(shè)？平臺優(yōu)勢如何發(fā)揮航夺？
松子老師：這個問題還是有些難度的，自己回答的可能有些片面崔涂。首先我們清醒的清楚“大數(shù)據(jù)”是什么阳掐？再次不同的場景可以采用不同的技術(shù)去解決。
“大數(shù)據(jù)”堪伍，拆開來看大锚烦、數(shù)據(jù)觅闽，大可以是指的數(shù)據(jù)源結(jié)構(gòu)簡單（ps 如果了解過當(dāng)代對大數(shù)據(jù)的定義就知道四個特性）但是量級夠大帝雇，比如清算、結(jié)算蛉拙、對公尸闸、對私、中間業(yè)務(wù)等等每一個拿出來都是幾十T孕锄，但是這些業(yè)務(wù)數(shù)據(jù)都是保存?zhèn)鹘y(tǒng)的關(guān)系型數(shù)據(jù)庫中如DB2吮廉、Oracle、MSsql中畸肆，因?yàn)樵跀?shù)據(jù)平臺存儲是通過準(zhǔn)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ù)的去演進(jìn)解決大咱。（最早時我的是中信銀行恬涧、光大銀行在2011年左右開始考慮Hadoop技術(shù)，后來不知道如何了）碴巾。
但是互聯(lián)網(wǎng)的數(shù)據(jù)平臺技術(shù)大都是NOSQL模式溯捆，犧牲掉了傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)一致性、完整性厦瓢、唯一索引等等提揍，只干性能的事情（當(dāng)然除了性能啤月、可擴(kuò)展性也是的）.
原有在傳統(tǒng)數(shù)據(jù)平臺模型設(shè)計(jì)上可以考慮的一些通過主外鍵、唯一索引做一些業(yè)務(wù)約束的方法劳跃，在nosql上統(tǒng)統(tǒng)的都沒有了顽冶，這些約束必須放到數(shù)據(jù)加工階段去想辦法做檢查。傳統(tǒng)數(shù)據(jù)平臺如果在Insert售碳、update數(shù)據(jù)時違反了業(yè)務(wù)約束可以做報(bào)警或異常處理强重，但是在Nosql的平臺上要求ETL 去手動遵守這些規(guī)則檢查。但是有時ETL開發(fā)根本不遵守的贸人，僅僅是兩個表關(guān)聯(lián)起來间景，也可能忘記按照某一個業(yè)務(wù)唯一索引做去重操作公给。簡單說晦譬，原有靠關(guān)系型數(shù)據(jù)庫本身機(jī)制去做檢查一些規(guī)則變?yōu)槿斯ぃ優(yōu)槿斯ぞ蜁稿e类少。
從關(guān)系型數(shù)據(jù)平臺往Nosql數(shù)據(jù)平臺遷移時十拣，尤其是對傳統(tǒng)行業(yè)的業(yè)務(wù)來說封拧，在模型設(shè)計(jì)階段、以及給出的ETL口徑要考慮更多的業(yè)務(wù)規(guī)則檢查夭问，其次要考慮更多的維度退化泽西、多冗余、表打?qū)捥幚礴智鳌：唵握f就是發(fā)揮數(shù)據(jù)平臺的計(jì)算能力同時要更加的各方面確保數(shù)據(jù)準(zhǔn)確安全可靠捧杉。
數(shù)據(jù)模型ODS 到EDW 這塊的設(shè)計(jì)方法百度上留下的文檔資料太多的了，請這位提問的老師百度吧秘血。
**8****．大數(shù)據(jù)****倉庫****中如何做快速****維處****理味抖？互****聯(lián)****網(wǎng)數(shù)****倉****數(shù)據(jù)****質(zhì)****量不好如何****對****數(shù)，如何確立****標(biāo)****準(zhǔn)的****對****數(shù)口徑灰粮？******
松子老師：快速變化維度可以轉(zhuǎn)化為緩慢變化為來出來仔涩，我自己理解的快速維度是相對于緩慢維度參照的來說的。
舉個例子粘舟，年齡-轉(zhuǎn)化為天數(shù)可以是定義快速變化維度熔脂，因?yàn)槊刻於荚谧兓Ｎ覀兛梢园涯挲g退化為區(qū)間維度來處理蓖乘，還可以把年齡做成動態(tài)維度來處理锤悄，事實(shí)表中保存的就是實(shí)際的出生年月并打?qū)挶恚挲g(天)通過計(jì)算方式來處理嘉抒。還有種方法通過對代理鍵的方式來處理零聚。
我目前也不知道對數(shù)據(jù)的標(biāo)準(zhǔn)是什么。但是我自己用的方法，把一個指標(biāo)的整個數(shù)據(jù)流向切出幾個關(guān)鍵點(diǎn)通過SQL去實(shí)現(xiàn)對數(shù)隶症，看波動振幅政模，波動曲線。同時還會比如發(fā)不通的版本的小流量測試的方式來做數(shù)據(jù)校對蚂会。
9****． 做為數(shù)據(jù)行業(yè)從業(yè)者淋样，需要掌握哪些重要的基礎(chǔ)知識？另：如果從零開始建立一個數(shù)據(jù)平臺胁住，需要哪些資源配置（人趁猴，財(cái)，物彪见，技術(shù)）儡司？大致總投資額度多少？如果同行產(chǎn)品間多種來源的數(shù)據(jù)余指，可有成熟的解決方案捕犬？謝謝…
松子老師：這個問題太宏觀了级零。作為數(shù)據(jù)行業(yè)從業(yè)者峦剔，需要掌握哪些重要基礎(chǔ)知識衬衬，這個是要看從事具體數(shù)據(jù)域的垂直行業(yè)玛痊。
比如說 數(shù)據(jù)開發(fā)、數(shù)據(jù)模型窗慎、數(shù)據(jù)產(chǎn)品个束、數(shù)據(jù)分析師恍涂、數(shù)據(jù)運(yùn)營缸濒、數(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ù)目標(biāo)不太明確下柬批，難以確定方案啸澡，人員配置上選用不同技術(shù)方案去搭建的配置是不太一樣的，比如說傳統(tǒng)平臺來講氮帐，運(yùn)維嗅虏、DBA、數(shù)據(jù)開發(fā)上沐、數(shù)據(jù)模型皮服、報(bào)表人員。
從互聯(lián)網(wǎng)數(shù)據(jù)平臺基本配置上，數(shù)據(jù)架構(gòu)師龄广、運(yùn)維硫眯、底層大數(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ù)她我。
10. Standalone****模式下，Model.save(Path)怎么一直提示錯誤迫横，是不是配置Spark時需要將Hdfs的配置引進(jìn)來啊～嚣潜？表示初學(xué)Spark
松子老師：這個問題有點(diǎn)超出我的能力范圍了，所以對不起回答不了畅姊。
我本身不是做技術(shù)的鸵钝。僅知道一點(diǎn)技術(shù)名詞。
11. ****傳統(tǒng)銀行業(yè)數(shù)據(jù)模型什么時候會走向互聯(lián)網(wǎng)模式呢呛讲？目前在傳統(tǒng)銀行數(shù)據(jù)平臺的產(chǎn)品是不是特別多禾怠？
松子老師：這個問題我自己就不知道了，或許是傳統(tǒng)銀行在數(shù)據(jù)平臺的實(shí)施上全面用互聯(lián)網(wǎng)的Nosql大數(shù)據(jù)處理技術(shù)吧贝搁。至于說傳統(tǒng)銀行數(shù)據(jù)模型用現(xiàn)有的互聯(lián)網(wǎng)數(shù)據(jù)模型理念去設(shè)計(jì)是否完全可行吗氏，數(shù)據(jù)一致性、高準(zhǔn)確性通過更多的方案去保證雷逆。
首先我需要確定一下這個產(chǎn)品是否指的“數(shù)據(jù)產(chǎn)品”弦讽。
如果是數(shù)據(jù)產(chǎn)品，那其實(shí)傳統(tǒng)行業(yè)數(shù)據(jù)平臺本身就有一些數(shù)據(jù)產(chǎn)品了膀哲，而且也都是存在的往产。數(shù)據(jù)產(chǎn)品自從數(shù)據(jù)倉庫出現(xiàn)以來它其實(shí)一直都存在的，只不過是近幾年因?yàn)榛ヂ?lián)網(wǎng)特別愛制造“流行詞“把數(shù)據(jù)產(chǎn)品這個詞給放大了某宪》麓澹互聯(lián)網(wǎng)是得數(shù)據(jù)產(chǎn)品從早期的重量級逐漸進(jìn)化為輕量級、從大而全的解決方案逐漸演進(jìn)為因小而美兴喂。
我來給出幾組例子蔼囊，大約從2004年到現(xiàn)在的幾組數(shù)據(jù)產(chǎn)品的例子
(點(diǎn)擊放大圖像)
[圖片上傳中包颁。。压真。（25）]
(點(diǎn)擊放大圖像)
[圖片上傳中娩嚼。。滴肿。（26）]
(點(diǎn)擊放大圖像)
[圖片上傳中岳悟。。泼差。（27）]
(點(diǎn)擊放大圖像)
[圖片上傳中贵少。。堆缘。（28）]
(點(diǎn)擊放大圖像)
[圖片上傳中滔灶。。吼肥。（29）]
(點(diǎn)擊放大圖像)
[圖片上傳中录平。。缀皱。（30）]
(點(diǎn)擊放大圖像)
[圖片上傳中斗这。。啤斗。（31）]
你可以分類一下硬梁，這些數(shù)據(jù)產(chǎn)品的特點(diǎn)是什么镰烧？滿足了用戶怎么樣的痛點(diǎn)需求？滿足了用戶怎么樣的使用流程旁涤。
12 ****外莲。傳統(tǒng)行業(yè)的數(shù)據(jù)倉庫從業(yè)人員凭语，如果轉(zhuǎn)到互聯(lián)網(wǎng)行業(yè)催什，應(yīng)該學(xué)習(xí)哪些技能群发？
松子老師：這個問題你可以百度搜索“大數(shù)據(jù)職位所需要的數(shù)據(jù)技能” http://blog.jobbole.com/99039/ 這篇文章。自己覺得人家回答的比我專業(yè)握童。//
我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史（四）：互聯(lián)網(wǎng)時代 ? 下篇
http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-internet-age
編者按：本文是松子（李博源）的大數(shù)據(jù)平臺發(fā)展史系列文章的第四篇（共四篇）姆怪，本系列以獨(dú)特的視角，比較了非互聯(lián)網(wǎng)和互聯(lián)網(wǎng)兩個時代以及傳統(tǒng)行業(yè)與非傳統(tǒng)行業(yè)澡绩。是對數(shù)據(jù)平臺發(fā)展的一個回憶，對非互聯(lián)網(wǎng)俺附、互聯(lián)網(wǎng)肥卡，從數(shù)據(jù)平臺的用戶角度、數(shù)據(jù)架構(gòu)演進(jìn)事镣、模型等進(jìn)行了闡述步鉴。
在互聯(lián)網(wǎng)時代被弱化的數(shù)據(jù)模型
談起數(shù)據(jù)模型就不得不提傳統(tǒng)數(shù)據(jù)平臺架構(gòu)發(fā)展，我相信很多朋友都曉得傳統(tǒng)數(shù)據(jù)平臺的知識，其架構(gòu)演進(jìn)簡單一句話說“基本上可以分為五個時代氛琢、四種架構(gòu)”喊递，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與數(shù)據(jù)源類型多樣化特點(diǎn)，從高階架構(gòu)上來看大約從傳統(tǒng)數(shù)據(jù)平臺第三代架構(gòu)開始延續(xù)的阳似，但是往后的發(fā)展從我自己的這一點(diǎn)知識上很難對互聯(lián)網(wǎng)的數(shù)據(jù)平臺做架構(gòu)歸類骚勘。
但是從數(shù)據(jù)平臺建設(shè)與服務(wù)角色上還是有章可循的。就像上篇分享到那樣撮奏，類比兩個行業(yè)俏讹，互聯(lián)網(wǎng)企業(yè)中員工年齡比非互聯(lián)網(wǎng)企業(yè)的要年輕、受教育程度畜吊、對計(jì)算機(jī)的焦慮程度明顯比傳統(tǒng)企業(yè)要低泽疆、還偶遇其它各方面的緣故，導(dǎo)致了數(shù)據(jù)平臺所面對用戶群體與非互聯(lián)網(wǎng)數(shù)據(jù)平臺有所差異化玲献。
傳統(tǒng)行業(yè)與互聯(lián)網(wǎng)行業(yè)數(shù)據(jù)平臺用戶特性我只選擇前文章的兩張圖來表示
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
在傳統(tǒng)數(shù)據(jù)平臺要背后有一個完整數(shù)據(jù)倉庫團(tuán)隊(duì)去服務(wù)業(yè)務(wù)方殉疼，業(yè)務(wù)方嗷嗷待哺的等待被動方式去滿足。中低層數(shù)據(jù)基本不會對業(yè)務(wù)方開放捌年，所以不管數(shù)據(jù)模型采用何種建模方式株依，主要滿足當(dāng)時數(shù)據(jù)架構(gòu)規(guī)劃即可。
互聯(lián)網(wǎng)業(yè)務(wù)的快速發(fā)展使得大家已經(jīng)從經(jīng)營延窜、分析的訴求重點(diǎn)轉(zhuǎn)為數(shù)據(jù)化的精細(xì)運(yùn)營上恋腕，如何做好精細(xì)化運(yùn)營問題上來，當(dāng)資源不夠時用戶就叫喊逆瑞，甚至有的業(yè)務(wù)方會挽起袖子來自己參與到從數(shù)據(jù)整理骆撇、加工、分析階段脓恕。
此時呢躬拢，原有建設(shè)數(shù)據(jù)平臺的多個角色（數(shù)據(jù)開發(fā)、模型設(shè)計(jì)）可能轉(zhuǎn)為對其它非專業(yè)使用數(shù)據(jù)方念秧，做培訓(xùn)淤井、咨詢與落地，寫更加適合當(dāng)前企業(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àn)椴粚I(yè)性砾层，導(dǎo)致數(shù)據(jù)質(zhì)量問題漩绵、重復(fù)對分?jǐn)?shù)據(jù)浪費(fèi)存儲與資源、口徑多樣化肛炮、編碼不統(tǒng)一止吐、命名問題等等原因宝踪。數(shù)據(jù)質(zhì)量逐漸變成一個特別突出的問題。
傳統(tǒng)企業(yè)的數(shù)據(jù)源基本來自excel碍扔、表格瘩燥、DB系統(tǒng)等，但在互聯(lián)網(wǎng)有網(wǎng)站點(diǎn)擊流日志不同、視頻厉膀、音頻、圖片數(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ù)有些力不從心。
當(dāng)數(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è)也有自己特點(diǎn)倍宾，傳統(tǒng)行業(yè)所涉及數(shù)據(jù)模型這個領(lǐng)域涉及的很多內(nèi)容在互聯(lián)網(wǎng)變成以其他的曲線救國的方式存在了雏节。
在互聯(lián)網(wǎng)曲線救國新解決
回顧在傳統(tǒng)行業(yè)數(shù)據(jù)平臺中，不管兩位大師爭論點(diǎn)數(shù)據(jù)模型的設(shè)計(jì)采用那種范式（Bill Inmon的EDW的原則是準(zhǔn)三范式的設(shè)計(jì)高职、Ralph kilmbal是星型結(jié)構(gòu)）但是都要非常重視數(shù)據(jù)源的質(zhì)量問題钩乍。所以傳統(tǒng)行業(yè)的數(shù)據(jù)模型會全盤考慮數(shù)據(jù)質(zhì)量問題，并通過數(shù)據(jù)抽樣分析給出合適的清洗口徑怔锌。
(點(diǎn)擊放大圖像)
上圖來自我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ù)”對一年的還是不準(zhǔn)的）淫僻。在應(yīng)對數(shù)據(jù)的質(zhì)量問題亚情，目前互聯(lián)網(wǎng)有些做法是把數(shù)據(jù)標(biāo)準(zhǔn)化前置到業(yè)務(wù)數(shù)據(jù)產(chǎn)生就做妄痪，從根源上去杜絕數(shù)據(jù)質(zhì)量，但是這種場景比較實(shí)用在Log 日志的數(shù)據(jù)源中楞件，比如移動互聯(lián)網(wǎng)最近流行的基于事件模型“Event”模型衫生，在日志產(chǎn)生時就規(guī)定好存儲格式（備注：大家度娘搜索，“學(xué)習(xí)筆記：The Log（我所讀過的最好的一篇分布式技術(shù)文章）” 對這個講解很詳細(xì)）土浸。
在傳統(tǒng)行業(yè)罪针，目前還是以混合模型設(shè)計(jì)方式為主。在互聯(lián)網(wǎng)的我所接觸的一些業(yè)務(wù)黄伊，在參照傳統(tǒng)數(shù)據(jù)模型方法論基礎(chǔ)上逐步演進(jìn)適合互聯(lián)網(wǎng)數(shù)據(jù)的數(shù)據(jù)模型方法泪酱。
比如互聯(lián)網(wǎng)金融等一些業(yè)務(wù)會參考傳統(tǒng)金融行業(yè)對主題域的劃分、OMG數(shù)據(jù)倉庫元數(shù)據(jù)管理CWM模型还最、FSDM金融模型墓阀，再進(jìn)一步考慮大數(shù)據(jù)處理特性去進(jìn)行設(shè)計(jì)，所有從Hight Level 數(shù)據(jù)架構(gòu)圖看到主題層次劃分與傳統(tǒng)第三代數(shù)據(jù)倉庫還是很多相似之處拓轻，當(dāng)然模型架構(gòu)也有分三層斯撮、四層、五層的扶叉。
不同的地方模型細(xì)節(jié)處理上已經(jīng)完全不一樣勿锅，比如數(shù)據(jù)的多樣性、拉寬事實(shí)表枣氧、度量值單獨(dú)存儲溢十、滿足數(shù)據(jù)快速重生、維度的二次降維處理等达吞、增加大量冗余列张弛、增加大量派生列，結(jié)合自動化元數(shù)據(jù)來耦合酪劫、合并等相關(guān)管理吞鸭。
(點(diǎn)擊放大圖像)
[圖片上傳中。契耿。瞒大。（4）]
上圖是支付寶非常早期數(shù)據(jù)模型
(點(diǎn)擊放大圖像)
上圖是支付寶非常早期數(shù)據(jù)模型
我們常提到的多維模型在大數(shù)據(jù)處理下進(jìn)行了退化維度處理。大家知道Olap多維模型搪桂，隨著維度的增加事實(shí)表的數(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è)計(jì)多維挖掘分析數(shù)據(jù)產(chǎn)品背后的技術(shù)就是搜索引擎實(shí)現(xiàn)的）酗电，現(xiàn)在應(yīng)該也有新技術(shù)出現(xiàn)了來解決類似的問題。
(點(diǎn)擊放大圖像)
上圖為2012年產(chǎn)品UI之一内列。
(點(diǎn)擊放大圖像)
[圖片上傳中撵术。。话瞧。（7）]
上圖是2011-2012年該產(chǎn)品系列背后當(dāng)時使用的技術(shù)
互聯(lián)網(wǎng)業(yè)務(wù)特點(diǎn)業(yè)務(wù)垂直拆分非常細(xì)嫩与，比如一個用戶注冊寝姿、密碼找回的流程有可能存在好幾個產(chǎn)品負(fù)責(zé)同一個業(yè)務(wù)流程不同環(huán)節(jié)，相關(guān)的一個策略划滋、產(chǎn)品feature快速迭代上線等等都要數(shù)據(jù)評估饵筑。數(shù)據(jù)從前端埋點(diǎn)到采集然后再由各個環(huán)節(jié)到數(shù)據(jù)平臺租幕，再有數(shù)據(jù)分析師或各業(yè)務(wù)部門去使用秉宿，基本拉長了時間周期柄沮。需求部門與實(shí)施部門能力和經(jīng)驗(yàn)有千差萬別的需求迷郑，造成了懂技術(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ù)特點(diǎn)是變化非常迅速的案狠，能穩(wěn)定的業(yè)務(wù)達(dá)到65%算對數(shù)據(jù)平臺是個福音了（根據(jù)對某寶寶的印象）剩余的業(yè)務(wù)變化迅速服傍，必然導(dǎo)致數(shù)據(jù)模型快速上下線。
Kimball老人家提出的維度建模（備注骂铁，在本系列發(fā)展史得第一篇有介紹）圍繞業(yè)務(wù)模型能夠非常直觀的表達(dá)出業(yè)務(wù)的數(shù)據(jù)關(guān)系吹零，但是在互聯(lián)網(wǎng)NOSQL犧牲掉了關(guān)系型數(shù)據(jù)庫的一致性、完整性等等很多東西拉庵。維度數(shù)據(jù)模型又基于這些大數(shù)據(jù)技術(shù)的灿椅，所以進(jìn)化的更加輕量級與基于細(xì)節(jié)數(shù)據(jù)的維度退化建模（原有的緩慢變化維、快速變化維钞支、大維茫蛹、迷你維、父子維烁挟、雪花維為了適應(yīng)互聯(lián)網(wǎng)的大數(shù)據(jù)Nosql處理技術(shù)進(jìn)行反規(guī)范化婴洼、化&數(shù)據(jù)冗余設(shè)計(jì)。
退化維度的反規(guī)范化設(shè)計(jì)一方面可以把一條查詢語句所需要的所有數(shù)據(jù)組合起來放到一個地方存儲 Key values 的方式（比如說商品有不同類型撼嗓，每一種類型商品又有自己的不同屬性柬采，可以采用一對多、多對多的方式存儲且警，例如把一個多維映射為一個Key value）粉捻。
講到互聯(lián)網(wǎng)數(shù)據(jù)平臺就要提數(shù)據(jù)模型，提了數(shù)據(jù)模型就要提Nosql技術(shù)斑芜，
(點(diǎn)擊放大圖像)
上圖來自Nosql文檔系列的一幅圖
Nosql 是大數(shù)據(jù)處理的特征之一肩刃。互聯(lián)網(wǎng)數(shù)據(jù)平臺數(shù)據(jù)模型與NoSql技術(shù)還是蠻緊密的。這里有外文講解Nosql Data modeling technigues 從技術(shù)角度講解非常詳（https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/）盈包。
因?yàn)榍斑吿岬降拇髷?shù)據(jù)平臺技術(shù)特性決定了傳統(tǒng)edw模型沸呐、維度模型直接在互聯(lián)網(wǎng)數(shù)據(jù)大數(shù)據(jù)平臺部署或許還有“好些未知”障礙等待大家去克服。同時在傳統(tǒng)數(shù)據(jù)建模用到的一些方法經(jīng)過互聯(lián)網(wǎng)熏陶或許演進(jìn)成一種新的數(shù)據(jù)產(chǎn)品或方案吧续语。
到此為止“我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史”上下共四篇與大家分享完畢垂谢，這個寫作前后經(jīng)歷剛好一個月左右厦画，算是對自己數(shù)據(jù)從業(yè)經(jīng)歷回顧之一吧疮茄。在知識的整理中很多都是蜻蜓點(diǎn)水，每個知識域都是一個非常深的專業(yè)方向根暑，自己涉足很膚淺力试，在文章中分享不足之處請各位讀者見諒！排嫌！
個人郵箱是5592094@qq.com 歡迎電郵交流畸裳。
接下來我會進(jìn)入數(shù)據(jù)產(chǎn)品這個領(lǐng)域的分享，當(dāng)年車品覺老師自豪的作品之一“黃金策”淳地，我是數(shù)據(jù)產(chǎn)品經(jīng)理怖糊。（ps：自己躲在墻角拿車品覺老師往自己臉上貼金了）辨绊。
后記
有一次數(shù)據(jù)產(chǎn)品神策的創(chuàng)始人兼好友@桑文鋒＠SensorsData跟我說來做次分享吧够庙，我當(dāng)時出了幾個題目，最后就選擇了“我所經(jīng)歷的大數(shù)據(jù)平臺“绘搞，就形成了大家看到的”我所經(jīng)歷的大數(shù)據(jù)平臺“系列文章.
在整理期間得到了死黨@周愛民遣钳、@神策-桑文峰扰魂、 InfoQ小編@Tina Du 、@betty zhou @Laurel大力協(xié)助蕴茴，在這里感謝Ｈ捌馈！倦淀！
番外篇
這一篇是在24日舉行的分享大家提到的一些問題蒋畜，經(jīng)過整理算是對正文的補(bǔ)充吧，從互聯(lián)網(wǎng)敏捷數(shù)據(jù)模型等角度做了較深入的細(xì)節(jié)介紹撞叽。同時在數(shù)據(jù)產(chǎn)品方面的回答包含了一點(diǎn)未來寫作篇“數(shù)據(jù)產(chǎn)品”系列的一點(diǎn)內(nèi)容姻成。
1****，傳統(tǒng)我們做BI的能扒，做數(shù)據(jù)展現(xiàn)會建模后以pivot展現(xiàn)cube數(shù)據(jù)佣渴，不知道現(xiàn)在互聯(lián)網(wǎng)公司數(shù)據(jù)展示如何做的？第三方工具還是用API取數(shù)據(jù)平臺里的數(shù)據(jù)初斑？adhoc報(bào)表及靈活更換維度的時候web端一般是怎么做的辛润？
松子老師：剛才文章中提到了比如傳統(tǒng)行業(yè)的多維數(shù)據(jù)模型cube。在互聯(lián)網(wǎng)采用的曲線救國方式解決的。 在分享中我給出了幾個圖砂竖。就是通過搜索引擎曲線救國方式實(shí)現(xiàn)類似Olap的模擬真椿。
在這塊的模型的處理上采用的是維度退化處理。通過反規(guī)范化乎澄，數(shù)據(jù)項(xiàng)突硝、數(shù)據(jù)冗余去處理。在前端做特殊處理置济。
這個當(dāng)時產(chǎn)品原型之一：
(點(diǎn)擊放大圖像)
這是一個2011年-2012年左右的數(shù)據(jù)產(chǎn)品解恰，當(dāng)時算是即時計(jì)算的一種。不過已經(jīng)過去好幾年了浙于，當(dāng)今新技術(shù)下Olap 引擎應(yīng)該有很好的提升护盈。
目前我知道的家互聯(lián)網(wǎng)公司，在前端展現(xiàn)有使用第三方套件比如spagoBi羞酗、pentaho 等 有自己設(shè)計(jì)開發(fā)定制化數(shù)據(jù)前端展現(xiàn)腐宋。比如我剛開始分享的那兩個之前在去哪兒網(wǎng)設(shè)計(jì)的數(shù)據(jù)平臺內(nèi)部界面之一，當(dāng)然數(shù)據(jù)產(chǎn)品是另一個話題了檀轨，通過對數(shù)據(jù)分析抽象指標(biāo)胸竞、分析模型、用戶使用功能與流程参萄、未來規(guī)劃考慮用戶體驗(yàn)去設(shè)計(jì)卫枝。
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
[圖片上傳中。拧揽。剃盾。（11）]
(點(diǎn)擊放大圖像)
2****，互聯(lián)網(wǎng)財(cái)經(jīng)類公司淤袜，業(yè)務(wù)包括財(cái)經(jīng)網(wǎng)站痒谴、基金、股票铡羡、金融等积蔚，這類公司的數(shù)據(jù)倉庫模型應(yīng)該如何設(shè)計(jì)媳危？特點(diǎn)和注意事項(xiàng)是什么牡拇？案例介紹？十分感謝螟够。
松子老師：我自己經(jīng)歷過的是互聯(lián)網(wǎng)金融以及移動互聯(lián)網(wǎng)行读慎。對這兩塊比較清楚漱贱。互聯(lián)網(wǎng)金融起因?yàn)闃I(yè)務(wù)的特性是類金融類的夭委，與銀行有些地方是相似的幅狮。
比如大約在2012年前支付寶業(yè)務(wù)特點(diǎn)涉及類金融交易：充值、提現(xiàn)、賬務(wù)管理類電子商務(wù)：購物交易過程變更崇摄、實(shí)際交易（對B機(jī)票擎值、對C水電等） 非純電子商務(wù)；純金融逐抑；個人信用鸠儿，理財(cái)類。系統(tǒng)之間依賴度較為復(fù)雜厕氨，垂直依賴（業(yè)務(wù)與核心）跨層依賴（跨過交易到賬務(wù)）进每。
在設(shè)計(jì)方法上還是采用維度模型設(shè)計(jì)方式。底層是數(shù)據(jù)驅(qū)動為向?qū)Ц玻Y(jié)合業(yè)務(wù)需求驅(qū)動品追，通過簡單、退化維度的方式拉寬表結(jié)構(gòu)冯丙。
底層采用松耦合設(shè)計(jì)。主題之間是松耦合方式遭京。至體內(nèi)采用細(xì)粒度退化維度胃惜。
在主題域上的的設(shè)計(jì)基本參考了OMG的數(shù)據(jù)倉庫元數(shù)據(jù)設(shè)計(jì)CWM模型、IBM 的fsdm金融模型哪雕、還有新巴塞爾資本協(xié)議（Basel II Capital Accord）需提供數(shù)據(jù)規(guī)范去的設(shè)計(jì)船殉。所以數(shù)據(jù)模型是五層的結(jié)構(gòu)。
在細(xì)節(jié)處理上斯嚎，增量ODS層數(shù)據(jù)和前一天DWD相關(guān)表進(jìn)行 merge處理利虫。
在一些層次上，基本聚合堡僻、匯總增加派生事實(shí)表（簡單一句話退化為度打?qū)挘┛繁埂Ｈ缓蟀凑諛I(yè)務(wù)主體合并信息等。
比如開始給大家分享的那張圖：
(點(diǎn)擊放大圖像)
[圖片上傳中钉疫。硼讽。。（13）]
在維度模型退化處理時牲阁，要注意最細(xì)粒度數(shù)據(jù)保留固阁、不同層次的數(shù)據(jù)支持?jǐn)?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ù)模型并齐。
這種元數(shù)據(jù)驅(qū)動工具型數(shù)據(jù)產(chǎn)品我會在未來數(shù)據(jù)產(chǎn)品系列中做詳細(xì)介紹的。
3****，互聯(lián)網(wǎng)企業(yè)大數(shù)據(jù)平臺的發(fā)展歷程是怎樣的冀膝？
松子老師：這個我相信應(yīng)該是傳統(tǒng)數(shù)據(jù)平臺朋友提到的唁奢。傳統(tǒng)行業(yè)數(shù)據(jù)平臺架構(gòu)演進(jìn)我總結(jié)簡單一句話說“基本上可以分為五個時代、四種架構(gòu)”窝剖，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與類型暴增的特點(diǎn)教沾，從高階架構(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é)下來用戶特點(diǎn)：
(點(diǎn)擊放大圖像)
[圖片上傳中馆揉。既穆。。（14）]
更加詳細(xì)的每一代數(shù)據(jù)平臺建設(shè)起胰、服務(wù)角色特點(diǎn)您可以看我這個系列文章的第三篇久又，http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-paet02
4****，有沒有好的元數(shù)據(jù)管理工具推薦效五？主要偏向數(shù)據(jù)字典與血統(tǒng)等地消。
松子老師：元數(shù)據(jù)以前目前沒有太多的好管理工具。以前是在支付寶是我自己設(shè)計(jì)的一個數(shù)據(jù)產(chǎn)品畏妖。第一版自己用Delphi 開發(fā)的脉执。
（圖很多：）
(點(diǎn)擊放大圖像)
[圖片上傳中。戒劫。半夷。（15）]
(點(diǎn)擊放大圖像)
[圖片上傳中。迅细。巫橄。（16）]
(點(diǎn)擊放大圖像)
[圖片上傳中。疯攒。嗦随。（17）]
(點(diǎn)擊放大圖像)
[圖片上傳中。敬尺。枚尼。（18）]
(點(diǎn)擊放大圖像)
[圖片上傳中。砂吞。署恍。（19）]
以前被逼的自己寫了一個，通過解析蜻直，實(shí)現(xiàn)了字段級的血緣影響分析盯质。這只是第二步袁串，后來又把running 信息給搞了進(jìn)來。還有分享時提到的模型信息呼巷、整個閉環(huán)的分類信息囱修。
這是一個分支：
(點(diǎn)擊放大圖像)
但是我們實(shí)現(xiàn)了字段級解析準(zhǔn)確率達(dá)到了94%左右。有細(xì)微的錯誤就人工revew一遍王悍。
5. ****松子老師破镰，數(shù)據(jù)管控的數(shù)據(jù)質(zhì)量部分是怎么處理的呢？
松子老師： 數(shù)據(jù)管控压储， 這方面我不太懂的鲜漩，但是數(shù)據(jù)質(zhì)量，這玩意可大可小的集惋。比如像在分享時說過的孕似，在移動互聯(lián)網(wǎng)的數(shù)據(jù)質(zhì)量處理方式可以由原有的ETL(ELT)階段前置到業(yè)務(wù)系統(tǒng)去解決，比如移動互聯(lián)網(wǎng)的App log 日志刮刑，日志標(biāo)準(zhǔn)化后事件模型”存儲來解決喉祭。那非app 日志類如何解決呢比如Payment、order等为朋，數(shù)據(jù)質(zhì)量比較考慮的可以只做到監(jiān)控臂拓。
我來分享個圖彰导。剛好是我設(shè)計(jì)數(shù)據(jù)質(zhì)量產(chǎn)品時搞的羊苟，理清數(shù)據(jù)質(zhì)量的問題：
(點(diǎn)擊放大圖像)
[圖片上傳中垮卓。。霞溪。（21）]
(點(diǎn)擊放大圖像)
[圖片上傳中。中捆。鸯匹。（22）]
(點(diǎn)擊放大圖像)
[圖片上傳中。泄伪。殴蓬。（23）]
只要數(shù)據(jù)進(jìn)入倉庫與應(yīng)用體系，處理起來就比較困難了蟋滴，所以在數(shù)據(jù)平臺階段最好是通過監(jiān)控染厅、前置去解決。目前數(shù)據(jù)質(zhì)量確實(shí)難以100%由事后搞到事前去處理津函。我對數(shù)據(jù)平臺與數(shù)據(jù)產(chǎn)品的建設(shè)就是實(shí)用為主肖粮。怎么實(shí)用怎么來。我是比較現(xiàn)實(shí)的實(shí)用主義者尔苦。
6. ****能否分享一些數(shù)據(jù)產(chǎn)品種類及實(shí)例：
松子老師：在前邊五個問題涩馆、以及文章中又都涉及數(shù)據(jù)產(chǎn)品實(shí)力的一些分享行施。
提到數(shù)據(jù)產(chǎn)品的分類我就想把這個圖發(fā)出來。
自己認(rèn)為沒有特別明確的劃分線魂那，但是數(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工具划乖、資源管控等等贬养。
面向用戶功能有報(bào)表型、多維型數(shù)據(jù)產(chǎn)品琴庵、定制化數(shù)據(jù)產(chǎn)品误算、挖掘型數(shù)據(jù)產(chǎn)品。
面向內(nèi)部用戶迷殿、外部個人用戶儿礼、外部企業(yè)用戶又有不同的分類。
根據(jù)業(yè)務(wù)又可以劃分很多庆寺，面向C類用戶蚊夫、面向B類商戶、金融風(fēng)險(xiǎn)等等
從近幾年的數(shù)據(jù)產(chǎn)品來看懦尝，是更好的輔助用戶的做決策的一種產(chǎn)品形態(tài)知纷，在用戶的決策與行動中充當(dāng)信息的分析者與價值使用者；數(shù)據(jù)產(chǎn)品有個自己的共性：由解決的一個實(shí)際的業(yè)務(wù)問題出發(fā)陵霉，分解出的分析指標(biāo)琅轧，分析模型，分析流程組成踊挠，再考慮到功能易用性乍桂，未來功能擴(kuò)展，考慮用戶對數(shù)據(jù)易用性（比如數(shù)據(jù)的呈現(xiàn)層次效床，不可能一次把所有數(shù)據(jù)的呈現(xiàn)給用戶）來組成的贰您。
(點(diǎn)擊放大圖像)
[圖片上傳中乏矾。。。（24）]
7. ****銀行業(yè)從傳統(tǒng)的ods到edw再到大數(shù)據(jù)平臺這塊過渡植兰，模型如何建設(shè)经宏？平臺優(yōu)勢如何發(fā)揮傻寂？
松子老師：這個問題還是有些難度的，自己回答的可能有些片面甥绿。首先我們清醒的清楚“大數(shù)據(jù)”是什么？再次不同的場景可以采用不同的技術(shù)去解決则披。
“大數(shù)據(jù)”共缕，拆開來看大、數(shù)據(jù)士复，大可以是指的數(shù)據(jù)源結(jié)構(gòu)簡單（ps 如果了解過當(dāng)代對大數(shù)據(jù)的定義就知道四個特性）但是量級夠大图谷，比如清算、結(jié)算阱洪、對公便贵、對私、中間業(yè)務(wù)等等每一個拿出來都是幾十T冗荸，但是這些業(yè)務(wù)數(shù)據(jù)都是保存?zhèn)鹘y(tǒng)的關(guān)系型數(shù)據(jù)庫中如DB2承璃、Oracle、MSsql中蚌本，因?yàn)樵跀?shù)據(jù)平臺存儲是通過準(zhǔn)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ù)的去演進(jìn)解決嵌莉。（最早時我的是中信銀行进萄、光大銀行在2011年左右開始考慮Hadoop技術(shù)，后來不知道如何了）锐峭。
但是互聯(lián)網(wǎng)的數(shù)據(jù)平臺技術(shù)大都是NOSQL模式垮斯，犧牲掉了傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)一致性、完整性只祠、唯一索引等等，只干性能的事情（當(dāng)然除了性能扰肌、可擴(kuò)展性也是的）.
原有在傳統(tǒng)數(shù)據(jù)平臺模型設(shè)計(jì)上可以考慮的一些通過主外鍵抛寝、唯一索引做一些業(yè)務(wù)約束的方法，在nosql上統(tǒng)統(tǒng)的都沒有了曙旭，這些約束必須放到數(shù)據(jù)加工階段去想辦法做檢查盗舰。傳統(tǒng)數(shù)據(jù)平臺如果在Insert、update數(shù)據(jù)時違反了業(yè)務(wù)約束可以做報(bào)警或異常處理桂躏，但是在Nosql的平臺上要求ETL 去手動遵守這些規(guī)則檢查钻趋。但是有時ETL開發(fā)根本不遵守的，僅僅是兩個表關(guān)聯(lián)起來剂习，也可能忘記按照某一個業(yè)務(wù)唯一索引做去重操作蛮位。簡單說较沪，原有靠關(guān)系型數(shù)據(jù)庫本身機(jī)制去做檢查一些規(guī)則變?yōu)槿斯ぃ優(yōu)槿斯ぞ蜁稿e失仁。
從關(guān)系型數(shù)據(jù)平臺往Nosql數(shù)據(jù)平臺遷移時尸曼，尤其是對傳統(tǒng)行業(yè)的業(yè)務(wù)來說，在模型設(shè)計(jì)階段萄焦、以及給出的ETL口徑要考慮更多的業(yè)務(wù)規(guī)則檢查控轿，其次要考慮更多的維度退化穗熬、多冗余柄瑰、表打?qū)捥幚怼：唵握f就是發(fā)揮數(shù)據(jù)平臺的計(jì)算能力同時要更加的各方面確保數(shù)據(jù)準(zhǔn)確安全可靠梆靖。
數(shù)據(jù)模型ODS 到EDW 這塊的設(shè)計(jì)方法百度上留下的文檔資料太多的了冒签，請這位提問的老師百度吧在抛。
**8****．大數(shù)據(jù)****倉庫****中如何做快速****維處****理？互****聯(lián)****網(wǎng)數(shù)****倉****數(shù)據(jù)****質(zhì)****量不好如何****對****數(shù)镣衡，如何確立****標(biāo)****準(zhǔn)的****對****數(shù)口徑霜定？******
松子老師：快速變化維度可以轉(zhuǎn)化為緩慢變化為來出來，我自己理解的快速維度是相對于緩慢維度參照的來說的廊鸥。
舉個例子望浩，年齡-轉(zhuǎn)化為天數(shù)可以是定義快速變化維度，因?yàn)槊刻於荚谧兓杷怠Ｎ覀兛梢园涯挲g退化為區(qū)間維度來處理磨德，還可以把年齡做成動態(tài)維度來處理，事實(shí)表中保存的就是實(shí)際的出生年月并打?qū)挶磉菏樱挲g(天)通過計(jì)算方式來處理典挑。還有種方法通過對代理鍵的方式來處理。
我目前也不知道對數(shù)據(jù)的標(biāo)準(zhǔn)是什么啦吧。但是我自己用的方法您觉，把一個指標(biāo)的整個數(shù)據(jù)流向切出幾個關(guān)鍵點(diǎn)通過SQL去實(shí)現(xiàn)對數(shù)，看波動振幅授滓，波動曲線琳水。同時還會比如發(fā)不通的版本的小流量測試的方式來做數(shù)據(jù)校對。
9****． 做為數(shù)據(jù)行業(yè)從業(yè)者般堆，需要掌握哪些重要的基礎(chǔ)知識在孝？另：如果從零開始建立一個數(shù)據(jù)平臺，需要哪些資源配置（人淮摔，財(cái)私沮，物，技術(shù)）和橙？大致總投資額度多少仔燕？如果同行產(chǎn)品間多種來源的數(shù)據(jù)造垛，可有成熟的解決方案？謝謝…
松子老師：這個問題太宏觀了涨享。作為數(shù)據(jù)行業(yè)從業(yè)者筋搏，需要掌握哪些重要基礎(chǔ)知識，這個是要看從事具體數(shù)據(jù)域的垂直行業(yè)厕隧。
比如說 數(shù)據(jù)開發(fā)奔脐、數(shù)據(jù)模型、數(shù)據(jù)產(chǎn)品吁讨、數(shù)據(jù)分析師髓迎、數(shù)據(jù)運(yùn)營、數(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ù)目標(biāo)不太明確下争舞，難以確定方案，人員配置上選用不同技術(shù)方案去搭建的配置是不太一樣的，比如說傳統(tǒng)平臺來講，運(yùn)維抵知、DBA、數(shù)據(jù)開發(fā)委乌、數(shù)據(jù)模型、報(bào)表人員荣回。
從互聯(lián)網(wǎng)數(shù)據(jù)平臺基本配置上遭贸，數(shù)據(jù)架構(gòu)師、運(yùn)維心软、底層大數(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ù)阎肝。
10. Standalone****模式下挤渔，Model.save(Path)怎么一直提示錯誤，是不是配置Spark時需要將Hdfs的配置引進(jìn)來啊～风题？表示初學(xué)Spark
松子老師：這個問題有點(diǎn)超出我的能力范圍了判导，所以對不起回答不了。
我本身不是做技術(shù)的沛硅。僅知道一點(diǎn)技術(shù)名詞眼刃。
11. ****傳統(tǒng)銀行業(yè)數(shù)據(jù)模型什么時候會走向互聯(lián)網(wǎng)模式呢？目前在傳統(tǒng)銀行數(shù)據(jù)平臺的產(chǎn)品是不是特別多摇肌？
松子老師：這個問題我自己就不知道了擂红，或許是傳統(tǒng)銀行在數(shù)據(jù)平臺的實(shí)施上全面用互聯(lián)網(wǎng)的Nosql大數(shù)據(jù)處理技術(shù)吧。至于說傳統(tǒng)銀行數(shù)據(jù)模型用現(xiàn)有的互聯(lián)網(wǎng)數(shù)據(jù)模型理念去設(shè)計(jì)是否完全可行围小，數(shù)據(jù)一致性昵骤、高準(zhǔn)確性通過更多的方案去保證。
首先我需要確定一下這個產(chǎn)品是否指的“數(shù)據(jù)產(chǎn)品”肯适。
如果是數(shù)據(jù)產(chǎn)品变秦，那其實(shí)傳統(tǒng)行業(yè)數(shù)據(jù)平臺本身就有一些數(shù)據(jù)產(chǎn)品了，而且也都是存在的疹娶。數(shù)據(jù)產(chǎn)品自從數(shù)據(jù)倉庫出現(xiàn)以來它其實(shí)一直都存在的伴栓，只不過是近幾年因?yàn)榛ヂ?lián)網(wǎng)特別愛制造“流行詞“把數(shù)據(jù)產(chǎn)品這個詞給放大了∮杲龋互聯(lián)網(wǎng)是得數(shù)據(jù)產(chǎn)品從早期的重量級逐漸進(jìn)化為輕量級钳垮、從大而全的解決方案逐漸演進(jìn)為因小而美。
我來給出幾組例子额港，大約從2004年到現(xiàn)在的幾組數(shù)據(jù)產(chǎn)品的例子
(點(diǎn)擊放大圖像)
[圖片上傳中饺窿。。移斩。（25）]
(點(diǎn)擊放大圖像)
[圖片上傳中肚医。。向瓷。（26）]
(點(diǎn)擊放大圖像)
[圖片上傳中肠套。。猖任。（27）]
(點(diǎn)擊放大圖像)
[圖片上傳中疙渣。锚赤。音诈。（28）]
(點(diǎn)擊放大圖像)
[圖片上傳中昔园。。。（29）]
(點(diǎn)擊放大圖像)
[圖片上傳中。。鸡典。（30）]
(點(diǎn)擊放大圖像)
[圖片上傳中。枪芒。彻况。（31）]
你可以分類一下，這些數(shù)據(jù)產(chǎn)品的特點(diǎn)是什么病苗？滿足了用戶怎么樣的痛點(diǎn)需求疗垛？滿足了用戶怎么樣的使用流程。
12 ****硫朦。傳統(tǒng)行業(yè)的數(shù)據(jù)倉庫從業(yè)人員贷腕，如果轉(zhuǎn)到互聯(lián)網(wǎng)行業(yè)，應(yīng)該學(xué)習(xí)哪些技能咬展？
松子老師：這個問題你可以百度搜索“大數(shù)據(jù)職位所需要的數(shù)據(jù)技能” http://blog.jobbole.com/99039/ 這篇文章泽裳。自己覺得人家回答的比我專業(yè)。//
我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史（四）：互聯(lián)網(wǎng)時代 ? 下篇
http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-internet-age
編者按：本文是松子（李博源）的大數(shù)據(jù)平臺發(fā)展史系列文章的第四篇（共四篇）破婆，本系列以獨(dú)特的視角涮总，比較了非互聯(lián)網(wǎng)和互聯(lián)網(wǎng)兩個時代以及傳統(tǒng)行業(yè)與非傳統(tǒng)行業(yè)。是對數(shù)據(jù)平臺發(fā)展的一個回憶祷舀，對非互聯(lián)網(wǎng)瀑梗、互聯(lián)網(wǎng)，從數(shù)據(jù)平臺的用戶角度裳扯、數(shù)據(jù)架構(gòu)演進(jìn)抛丽、模型等進(jìn)行了闡述。
在互聯(lián)網(wǎng)時代被弱化的數(shù)據(jù)模型
談起數(shù)據(jù)模型就不得不提傳統(tǒng)數(shù)據(jù)平臺架構(gòu)發(fā)展饰豺，我相信很多朋友都曉得傳統(tǒng)數(shù)據(jù)平臺的知識亿鲜，其架構(gòu)演進(jìn)簡單一句話說“基本上可以分為五個時代、四種架構(gòu)”冤吨，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與數(shù)據(jù)源類型多樣化特點(diǎn)蒿柳，從高階架構(gòu)上來看大約從傳統(tǒng)數(shù)據(jù)平臺第三代架構(gòu)開始延續(xù)的，但是往后的發(fā)展從我自己的這一點(diǎn)知識上很難對互聯(lián)網(wǎng)的數(shù)據(jù)平臺做架構(gòu)歸類漩蟆。
但是從數(shù)據(jù)平臺建設(shè)與服務(wù)角色上還是有章可循的垒探。就像上篇分享到那樣，類比兩個行業(yè)怠李，互聯(lián)網(wǎng)企業(yè)中員工年齡比非互聯(lián)網(wǎng)企業(yè)的要年輕叛复、受教育程度仔引、對計(jì)算機(jī)的焦慮程度明顯比傳統(tǒng)企業(yè)要低、還偶遇其它各方面的緣故褐奥，導(dǎo)致了數(shù)據(jù)平臺所面對用戶群體與非互聯(lián)網(wǎng)數(shù)據(jù)平臺有所差異化。
傳統(tǒng)行業(yè)與互聯(lián)網(wǎng)行業(yè)數(shù)據(jù)平臺用戶特性我只選擇前文章的兩張圖來表示
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
在傳統(tǒng)數(shù)據(jù)平臺要背后有一個完整數(shù)據(jù)倉庫團(tuán)隊(duì)去服務(wù)業(yè)務(wù)方翘簇，業(yè)務(wù)方嗷嗷待哺的等待被動方式去滿足撬码。中低層數(shù)據(jù)基本不會對業(yè)務(wù)方開放，所以不管數(shù)據(jù)模型采用何種建模方式版保，主要滿足當(dāng)時數(shù)據(jù)架構(gòu)規(guī)劃即可呜笑。
互聯(lián)網(wǎng)業(yè)務(wù)的快速發(fā)展使得大家已經(jīng)從經(jīng)營、分析的訴求重點(diǎn)轉(zhuǎn)為數(shù)據(jù)化的精細(xì)運(yùn)營上彻犁，如何做好精細(xì)化運(yùn)營問題上來叫胁，當(dāng)資源不夠時用戶就叫喊，甚至有的業(yè)務(wù)方會挽起袖子來自己參與到從數(shù)據(jù)整理召噩、加工趣斤、分析階段榨馁。
此時呢，原有建設(shè)數(shù)據(jù)平臺的多個角色（數(shù)據(jù)開發(fā)输钩、模型設(shè)計(jì)）可能轉(zhuǎn)為對其它非專業(yè)使用數(shù)據(jù)方，做培訓(xùn)仲智、咨詢與落地买乃，寫更加適合當(dāng)前企業(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àn)椴粚I(yè)性，導(dǎo)致數(shù)據(jù)質(zhì)量問題前联、重復(fù)對分?jǐn)?shù)據(jù)浪費(fèi)存儲與資源功戚、口徑多樣化、編碼不統(tǒng)一蛀恩、命名問題等等原因疫铜。數(shù)據(jù)質(zhì)量逐漸變成一個特別突出的問題。
傳統(tǒng)企業(yè)的數(shù)據(jù)源基本來自excel双谆、表格壳咕、DB系統(tǒng)等，但在互聯(lián)網(wǎng)有網(wǎng)站點(diǎn)擊流日志顽馋、視頻谓厘、音頻、圖片數(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ù)有些力不從心聂宾。
當(dāng)數(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è)也有自己特點(diǎn)，傳統(tǒng)行業(yè)所涉及數(shù)據(jù)模型這個領(lǐng)域涉及的很多內(nèi)容在互聯(lián)網(wǎng)變成以其他的曲線救國的方式存在了凉馆。
在互聯(lián)網(wǎng)曲線救國新解決
回顧在傳統(tǒng)行業(yè)數(shù)據(jù)平臺中薪寓，不管兩位大師爭論點(diǎn)數(shù)據(jù)模型的設(shè)計(jì)采用那種范式（Bill Inmon的EDW的原則是準(zhǔn)三范式的設(shè)計(jì)、Ralph kilmbal是星型結(jié)構(gòu)）但是都要非常重視數(shù)據(jù)源的質(zhì)量問題句喜。所以傳統(tǒng)行業(yè)的數(shù)據(jù)模型會全盤考慮數(shù)據(jù)質(zhì)量問題预愤，并通過數(shù)據(jù)抽樣分析給出合適的清洗口徑。
(點(diǎn)擊放大圖像)
上圖來自我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ù)”對一年的還是不準(zhǔn)的）销睁。在應(yīng)對數(shù)據(jù)的質(zhì)量問題，目前互聯(lián)網(wǎng)有些做法是把數(shù)據(jù)標(biāo)準(zhǔn)化前置到業(yè)務(wù)數(shù)據(jù)產(chǎn)生就做存崖，從根源上去杜絕數(shù)據(jù)質(zhì)量冻记，但是這種場景比較實(shí)用在Log 日志的數(shù)據(jù)源中利花，比如移動互聯(lián)網(wǎng)最近流行的基于事件模型“Event”模型恋拷，在日志產(chǎn)生時就規(guī)定好存儲格式（備注：大家度娘搜索，“學(xué)習(xí)筆記：The Log（我所讀過的最好的一篇分布式技術(shù)文章）” 對這個講解很詳細(xì)）宵凌。
在傳統(tǒng)行業(yè)供搀，目前還是以混合模型設(shè)計(jì)方式為主隅居。在互聯(lián)網(wǎng)的我所接觸的一些業(yè)務(wù)，在參照傳統(tǒng)數(shù)據(jù)模型方法論基礎(chǔ)上逐步演進(jìn)適合互聯(lián)網(wǎng)數(shù)據(jù)的數(shù)據(jù)模型方法葛虐。
比如互聯(lián)網(wǎng)金融等一些業(yè)務(wù)會參考傳統(tǒng)金融行業(yè)對主題域的劃分胎源、OMG數(shù)據(jù)倉庫元數(shù)據(jù)管理CWM模型、FSDM金融模型屿脐，再進(jìn)一步考慮大數(shù)據(jù)處理特性去進(jìn)行設(shè)計(jì)涕蚤，所有從Hight Level 數(shù)據(jù)架構(gòu)圖看到主題層次劃分與傳統(tǒng)第三代數(shù)據(jù)倉庫還是很多相似之處宪卿，當(dāng)然模型架構(gòu)也有分三層、四層万栅、五層的佑钾。
不同的地方模型細(xì)節(jié)處理上已經(jīng)完全不一樣，比如數(shù)據(jù)的多樣性烦粒、拉寬事實(shí)表次绘、度量值單獨(dú)存儲、滿足數(shù)據(jù)快速重生撒遣、維度的二次降維處理等、增加大量冗余列管跺、增加大量派生列义黎，結(jié)合自動化元數(shù)據(jù)來耦合、合并等相關(guān)管理豁跑。
(點(diǎn)擊放大圖像)
[圖片上傳中廉涕。。艇拍。（4）]
上圖是支付寶非常早期數(shù)據(jù)模型
(點(diǎn)擊放大圖像)
上圖是支付寶非常早期數(shù)據(jù)模型
我們常提到的多維模型在大數(shù)據(jù)處理下進(jìn)行了退化維度處理狐蜕。大家知道Olap多維模型，隨著維度的增加事實(shí)表的數(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è)計(jì)多維挖掘分析數(shù)據(jù)產(chǎn)品背后的技術(shù)就是搜索引擎實(shí)現(xiàn)的）快集，現(xiàn)在應(yīng)該也有新技術(shù)出現(xiàn)了來解決類似的問題贡羔。
(點(diǎn)擊放大圖像)
上圖為2012年產(chǎn)品UI之一。
(點(diǎn)擊放大圖像)
[圖片上傳中个初。乖寒。。（7）]
上圖是2011-2012年該產(chǎn)品系列背后當(dāng)時使用的技術(shù)
互聯(lián)網(wǎng)業(yè)務(wù)特點(diǎn)業(yè)務(wù)垂直拆分非常細(xì)院溺，比如一個用戶注冊楣嘁、密碼找回的流程有可能存在好幾個產(chǎn)品負(fù)責(zé)同一個業(yè)務(wù)流程不同環(huán)節(jié)，相關(guān)的一個策略珍逸、產(chǎn)品feature快速迭代上線等等都要數(shù)據(jù)評估逐虚。數(shù)據(jù)從前端埋點(diǎn)到采集然后再由各個環(huán)節(jié)到數(shù)據(jù)平臺，再有數(shù)據(jù)分析師或各業(yè)務(wù)部門去使用弄息，基本拉長了時間周期痊班。需求部門與實(shí)施部門能力和經(jīng)驗(yàn)有千差萬別的需求，造成了懂技術(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ù)特點(diǎn)是變化非常迅速的，能穩(wěn)定的業(yè)務(wù)達(dá)到65%算對數(shù)據(jù)平臺是個福音了（根據(jù)對某寶寶的印象）剩余的業(yè)務(wù)變化迅速，必然導(dǎo)致數(shù)據(jù)模型快速上下線勤揩。
Kimball老人家提出的維度建模（備注，在本系列發(fā)展史得第一篇有介紹）圍繞業(yè)務(wù)模型能夠非常直觀的表達(dá)出業(yè)務(wù)的數(shù)據(jù)關(guān)系村生，但是在互聯(lián)網(wǎng)NOSQL犧牲掉了關(guān)系型數(shù)據(jù)庫的一致性冰木、完整性等等很多東西。維度數(shù)據(jù)模型又基于這些大數(shù)據(jù)技術(shù)的浪慌，所以進(jìn)化的更加輕量級與基于細(xì)節(jié)數(shù)據(jù)的維度退化建模（原有的緩慢變化維冤荆、快速變化維、大維权纤、迷你維钓简、父子維、雪花維為了適應(yīng)互聯(lián)網(wǎng)的大數(shù)據(jù)Nosql處理技術(shù)進(jìn)行反規(guī)范化汹想、化&數(shù)據(jù)冗余設(shè)計(jì)外邓。
退化維度的反規(guī)范化設(shè)計(jì)一方面可以把一條查詢語句所需要的所有數(shù)據(jù)組合起來放到一個地方存儲 Key values 的方式（比如說商品有不同類型，每一種類型商品又有自己的不同屬性古掏，可以采用一對多损话、多對多的方式存儲，例如把一個多維映射為一個Key value）冗茸。
講到互聯(lián)網(wǎng)數(shù)據(jù)平臺就要提數(shù)據(jù)模型席镀，提了數(shù)據(jù)模型就要提Nosql技術(shù)，
(點(diǎn)擊放大圖像)
上圖來自Nosql文檔系列的一幅圖
Nosql 是大數(shù)據(jù)處理的特征之一夏漱『阑澹互聯(lián)網(wǎng)數(shù)據(jù)平臺數(shù)據(jù)模型與NoSql技術(shù)還是蠻緊密的。這里有外文講解Nosql Data modeling technigues 從技術(shù)角度講解非常詳（https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/）挂绰。
因?yàn)榍斑吿岬降拇髷?shù)據(jù)平臺技術(shù)特性決定了傳統(tǒng)edw模型屎篱、維度模型直接在互聯(lián)網(wǎng)數(shù)據(jù)大數(shù)據(jù)平臺部署或許還有“好些未知”障礙等待大家去克服。同時在傳統(tǒng)數(shù)據(jù)建模用到的一些方法經(jīng)過互聯(lián)網(wǎng)熏陶或許演進(jìn)成一種新的數(shù)據(jù)產(chǎn)品或方案吧葵蒂。
到此為止“我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史”上下共四篇與大家分享完畢交播，這個寫作前后經(jīng)歷剛好一個月左右，算是對自己數(shù)據(jù)從業(yè)經(jīng)歷回顧之一吧践付。在知識的整理中很多都是蜻蜓點(diǎn)水秦士，每個知識域都是一個非常深的專業(yè)方向，自己涉足很膚淺永高，在文章中分享不足之處請各位讀者見諒Ｋ硗痢提针！
個人郵箱是5592094@qq.com 歡迎電郵交流。
接下來我會進(jìn)入數(shù)據(jù)產(chǎn)品這個領(lǐng)域的分享曹傀，當(dāng)年車品覺老師自豪的作品之一“黃金策”辐脖，我是數(shù)據(jù)產(chǎn)品經(jīng)理。（ps：自己躲在墻角拿車品覺老師往自己臉上貼金了）皆愉。
后記
有一次數(shù)據(jù)產(chǎn)品神策的創(chuàng)始人兼好友@桑文鋒＠SensorsData跟我說來做次分享吧嗜价，我當(dāng)時出了幾個題目，最后就選擇了“我所經(jīng)歷的大數(shù)據(jù)平臺“幕庐，就形成了大家看到的”我所經(jīng)歷的大數(shù)據(jù)平臺“系列文章.
在整理期間得到了死黨@周愛民久锥、@神策-桑文峰、 InfoQ小編@Tina Du 异剥、@betty zhou @Laurel大力協(xié)助奴拦，在這里感謝！＝煊酢！
番外篇
這一篇是在24日舉行的分享大家提到的一些問題绿鸣，經(jīng)過整理算是對正文的補(bǔ)充吧，從互聯(lián)網(wǎng)敏捷數(shù)據(jù)模型等角度做了較深入的細(xì)節(jié)介紹。同時在數(shù)據(jù)產(chǎn)品方面的回答包含了一點(diǎn)未來寫作篇“數(shù)據(jù)產(chǎn)品”系列的一點(diǎn)內(nèi)容台盯。
1****碍岔，傳統(tǒng)我們做BI的，做數(shù)據(jù)展現(xiàn)會建模后以pivot展現(xiàn)cube數(shù)據(jù)擎厢，不知道現(xiàn)在互聯(lián)網(wǎng)公司數(shù)據(jù)展示如何做的究流？第三方工具還是用API取數(shù)據(jù)平臺里的數(shù)據(jù)？adhoc報(bào)表及靈活更換維度的時候web端一般是怎么做的动遭？
松子老師：剛才文章中提到了比如傳統(tǒng)行業(yè)的多維數(shù)據(jù)模型cube芬探。在互聯(lián)網(wǎng)采用的曲線救國方式解決的。 在分享中我給出了幾個圖厘惦。就是通過搜索引擎曲線救國方式實(shí)現(xiàn)類似Olap的模擬偷仿。
在這塊的模型的處理上采用的是維度退化處理。通過反規(guī)范化宵蕉，數(shù)據(jù)項(xiàng)酝静、數(shù)據(jù)冗余去處理。在前端做特殊處理羡玛。
這個當(dāng)時產(chǎn)品原型之一：
(點(diǎn)擊放大圖像)
這是一個2011年-2012年左右的數(shù)據(jù)產(chǎn)品别智，當(dāng)時算是即時計(jì)算的一種。不過已經(jīng)過去好幾年了稼稿，當(dāng)今新技術(shù)下Olap 引擎應(yīng)該有很好的提升薄榛。
目前我知道的家互聯(lián)網(wǎng)公司讳窟，在前端展現(xiàn)有使用第三方套件比如spagoBi、pentaho 等 有自己設(shè)計(jì)開發(fā)定制化數(shù)據(jù)前端展現(xiàn)蛇数。比如我剛開始分享的那兩個之前在去哪兒網(wǎng)設(shè)計(jì)的數(shù)據(jù)平臺內(nèi)部界面之一挪钓，當(dāng)然數(shù)據(jù)產(chǎn)品是另一個話題了，通過對數(shù)據(jù)分析抽象指標(biāo)耳舅、分析模型碌上、用戶使用功能與流程、未來規(guī)劃考慮用戶體驗(yàn)去設(shè)計(jì)浦徊。
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
[圖片上傳中馏予。。盔性。（11）]
(點(diǎn)擊放大圖像)
2****霞丧，互聯(lián)網(wǎng)財(cái)經(jīng)類公司，業(yè)務(wù)包括財(cái)經(jīng)網(wǎng)站冕香、基金蛹尝、股票、金融等悉尾，這類公司的數(shù)據(jù)倉庫模型應(yīng)該如何設(shè)計(jì)突那？特點(diǎn)和注意事項(xiàng)是什么？案例介紹构眯？十分感謝愕难。
松子老師：我自己經(jīng)歷過的是互聯(lián)網(wǎng)金融以及移動互聯(lián)網(wǎng)行。對這兩塊比較清楚惫霸∶ㄧ裕互聯(lián)網(wǎng)金融起因?yàn)闃I(yè)務(wù)的特性是類金融類的，與銀行有些地方是相似的壹店。
比如大約在2012年前支付寶業(yè)務(wù)特點(diǎn)涉及類金融交易：充值猜丹、提現(xiàn)、賬務(wù)管理類電子商務(wù)：購物交易過程變更硅卢、實(shí)際交易（對B機(jī)票居触、對C水電等） 非純電子商務(wù)；純金融老赤；個人信用妖异，理財(cái)類罚攀。系統(tǒng)之間依賴度較為復(fù)雜，垂直依賴（業(yè)務(wù)與核心）跨層依賴（跨過交易到賬務(wù)）。
在設(shè)計(jì)方法上還是采用維度模型設(shè)計(jì)方式丐枉。底層是數(shù)據(jù)驅(qū)動為向?qū)Ъ旆茫Y(jié)合業(yè)務(wù)需求驅(qū)動，通過簡單、退化維度的方式拉寬表結(jié)構(gòu)误褪。
底層采用松耦合設(shè)計(jì)。主題之間是松耦合方式碾褂。至體內(nèi)采用細(xì)粒度退化維度兽间。
在主題域上的的設(shè)計(jì)基本參考了OMG的數(shù)據(jù)倉庫元數(shù)據(jù)設(shè)計(jì)CWM模型、IBM 的fsdm金融模型正塌、還有新巴塞爾資本協(xié)議（Basel II Capital Accord）需提供數(shù)據(jù)規(guī)范去的設(shè)計(jì)嘀略。所以數(shù)據(jù)模型是五層的結(jié)構(gòu)。
在細(xì)節(jié)處理上乓诽，增量ODS層數(shù)據(jù)和前一天DWD相關(guān)表進(jìn)行 merge處理帜羊。
在一些層次上，基本聚合鸠天、匯總增加派生事實(shí)表（簡單一句話退化為度打?qū)挘┧嫌Ｈ缓蟀凑諛I(yè)務(wù)主體合并信息等。
比如開始給大家分享的那張圖：
(點(diǎn)擊放大圖像)
[圖片上傳中稠集。奶段。。（13）]
在維度模型退化處理時剥纷，要注意最細(xì)粒度數(shù)據(jù)保留忧饭、不同層次的數(shù)據(jù)支持?jǐn)?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ù)模型。
這種元數(shù)據(jù)驅(qū)動工具型數(shù)據(jù)產(chǎn)品我會在未來數(shù)據(jù)產(chǎn)品系列中做詳細(xì)介紹的逆航。
3****鼎文，互聯(lián)網(wǎng)企業(yè)大數(shù)據(jù)平臺的發(fā)展歷程是怎樣的？
松子老師：這個我相信應(yīng)該是傳統(tǒng)數(shù)據(jù)平臺朋友提到的因俐。傳統(tǒng)行業(yè)數(shù)據(jù)平臺架構(gòu)演進(jìn)我總結(jié)簡單一句話說“基本上可以分為五個時代拇惋、四種架構(gòu)”，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與類型暴增的特點(diǎn)抹剩，從高階架構(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é)下來用戶特點(diǎn)：
(點(diǎn)擊放大圖像)
[圖片上傳中钳踊。衷敌。勿侯。（14）]
更加詳細(xì)的每一代數(shù)據(jù)平臺建設(shè)、服務(wù)角色特點(diǎn)您可以看我這個系列文章的第三篇缴罗，http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-paet02
4****助琐，有沒有好的元數(shù)據(jù)管理工具推薦？主要偏向數(shù)據(jù)字典與血統(tǒng)等面氓。
松子老師：元數(shù)據(jù)以前目前沒有太多的好管理工具兵钮。以前是在支付寶是我自己設(shè)計(jì)的一個數(shù)據(jù)產(chǎn)品。第一版自己用Delphi 開發(fā)的侧但。
（圖很多：）
(點(diǎn)擊放大圖像)
[圖片上傳中瓮栗。。抄罕。（15）]
(點(diǎn)擊放大圖像)
[圖片上傳中寒瓦。。柏锄。（16）]
(點(diǎn)擊放大圖像)
[圖片上傳中酿箭。。趾娃。（17）]
(點(diǎn)擊放大圖像)
[圖片上傳中缭嫡。。抬闷。（18）]
(點(diǎn)擊放大圖像)
[圖片上傳中妇蛀。。笤成。（19）]
以前被逼的自己寫了一個评架，通過解析，實(shí)現(xiàn)了字段級的血緣影響分析炕泳。這只是第二步纵诞，后來又把running 信息給搞了進(jìn)來。還有分享時提到的模型信息培遵、整個閉環(huán)的分類信息浙芙。
這是一個分支：
(點(diǎn)擊放大圖像)
[圖片上傳中。籽腕。嗡呼。（20）]
但是我們實(shí)現(xiàn)了字段級解析準(zhǔn)確率達(dá)到了94%左右。有細(xì)微的錯誤就人工revew一遍皇耗。
5. ****松子老師晤锥，數(shù)據(jù)管控的數(shù)據(jù)質(zhì)量部分是怎么處理的呢？
松子老師： 數(shù)據(jù)管控， 這方面我不太懂的矾瘾，但是數(shù)據(jù)質(zhì)量女轿，這玩意可大可小的。比如像在分享時說過的壕翩，在移動互聯(lián)網(wǎng)的數(shù)據(jù)質(zhì)量處理方式可以由原有的ETL(ELT)階段前置到業(yè)務(wù)系統(tǒng)去解決蛉迹，比如移動互聯(lián)網(wǎng)的App log 日志，日志標(biāo)準(zhǔn)化后事件模型”存儲來解決放妈。那非app 日志類如何解決呢比如Payment北救、order等，數(shù)據(jù)質(zhì)量比較考慮的可以只做到監(jiān)控芜抒。
我來分享個圖珍策。剛好是我設(shè)計(jì)數(shù)據(jù)質(zhì)量產(chǎn)品時搞的，理清數(shù)據(jù)質(zhì)量的問題：
(點(diǎn)擊放大圖像)
[圖片上傳中宅倒。攘宙。。（21）]
(點(diǎn)擊放大圖像)
[圖片上傳中拐迁。蹭劈。。（22）]
(點(diǎn)擊放大圖像)
[圖片上傳中线召。铺韧。。（23）]
只要數(shù)據(jù)進(jìn)入倉庫與應(yīng)用體系缓淹，處理起來就比較困難了哈打，所以在數(shù)據(jù)平臺階段最好是通過監(jiān)控、前置去解決讯壶。目前數(shù)據(jù)質(zhì)量確實(shí)難以100%由事后搞到事前去處理空猜。我對數(shù)據(jù)平臺與數(shù)據(jù)產(chǎn)品的建設(shè)就是實(shí)用為主氢架。怎么實(shí)用怎么來或渤。我是比較現(xiàn)實(shí)的實(shí)用主義者太抓。
6. ****能否分享一些數(shù)據(jù)產(chǎn)品種類及實(shí)例：
松子老師：在前邊五個問題淹仑、以及文章中又都涉及數(shù)據(jù)產(chǎn)品實(shí)力的一些分享丙挽。
提到數(shù)據(jù)產(chǎn)品的分類我就想把這個圖發(fā)出來。
自己認(rèn)為沒有特別明確的劃分線匀借，但是數(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工具、資源管控等等李剖。
面向用戶功能有報(bào)表型芒率、多維型數(shù)據(jù)產(chǎn)品、定制化數(shù)據(jù)產(chǎn)品篙顺、挖掘型數(shù)據(jù)產(chǎn)品偶芍。
面向內(nèi)部用戶、外部個人用戶德玫、外部企業(yè)用戶又有不同的分類匪蟀。
根據(jù)業(yè)務(wù)又可以劃分很多，面向C類用戶宰僧、面向B類商戶材彪、金融風(fēng)險(xiǎn)等等
從近幾年的數(shù)據(jù)產(chǎn)品來看，是更好的輔助用戶的做決策的一種產(chǎn)品形態(tài)撒桨，在用戶的決策與行動中充當(dāng)信息的分析者與價值使用者查刻；數(shù)據(jù)產(chǎn)品有個自己的共性：由解決的一個實(shí)際的業(yè)務(wù)問題出發(fā)，分解出的分析指標(biāo)凤类，分析模型穗泵，分析流程組成，再考慮到功能易用性谜疤，未來功能擴(kuò)展佃延，考慮用戶對數(shù)據(jù)易用性（比如數(shù)據(jù)的呈現(xiàn)層次，不可能一次把所有數(shù)據(jù)的呈現(xiàn)給用戶）來組成的夷磕。
(點(diǎn)擊放大圖像)
[圖片上傳中履肃。。坐桩。（24）]
7. ****銀行業(yè)從傳統(tǒng)的ods到edw再到大數(shù)據(jù)平臺這塊過渡尺棋，模型如何建設(shè)？平臺優(yōu)勢如何發(fā)揮绵跷？
松子老師：這個問題還是有些難度的膘螟，自己回答的可能有些片面。首先我們清醒的清楚“大數(shù)據(jù)”是什么碾局？再次不同的場景可以采用不同的技術(shù)去解決荆残。
“大數(shù)據(jù)”，拆開來看大净当、數(shù)據(jù)内斯，大可以是指的數(shù)據(jù)源結(jié)構(gòu)簡單（ps 如果了解過當(dāng)代對大數(shù)據(jù)的定義就知道四個特性）但是量級夠大蕴潦，比如清算、結(jié)算俘闯、對公喊式、對私像捶、中間業(yè)務(wù)等等每一個拿出來都是幾十T，但是這些業(yè)務(wù)數(shù)據(jù)都是保存?zhèn)鹘y(tǒng)的關(guān)系型數(shù)據(jù)庫中如DB2、Oracle譬圣、MSsql中璧函，因?yàn)樵跀?shù)據(jù)平臺存儲是通過準(zhǔn)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ù)的去演進(jìn)解決。（最早時我的是中信銀行肩豁、光大銀行在2011年左右開始考慮Hadoop技術(shù)脊串，后來不知道如何了）。
但是互聯(lián)網(wǎng)的數(shù)據(jù)平臺技術(shù)大都是NOSQL模式清钥，犧牲掉了傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)一致性琼锋、完整性、唯一索引等等祟昭，只干性能的事情（當(dāng)然除了性能缕坎、可擴(kuò)展性也是的）.
原有在傳統(tǒng)數(shù)據(jù)平臺模型設(shè)計(jì)上可以考慮的一些通過主外鍵、唯一索引做一些業(yè)務(wù)約束的方法篡悟，在nosql上統(tǒng)統(tǒng)的都沒有了谜叹，這些約束必須放到數(shù)據(jù)加工階段去想辦法做檢查。傳統(tǒng)數(shù)據(jù)平臺如果在Insert搬葬、update數(shù)據(jù)時違反了業(yè)務(wù)約束可以做報(bào)警或異常處理荷腊，但是在Nosql的平臺上要求ETL 去手動遵守這些規(guī)則檢查。但是有時ETL開發(fā)根本不遵守的急凰，僅僅是兩個表關(guān)聯(lián)起來女仰，也可能忘記按照某一個業(yè)務(wù)唯一索引做去重操作。簡單說抡锈，原有靠關(guān)系型數(shù)據(jù)庫本身機(jī)制去做檢查一些規(guī)則變?yōu)槿斯ぜ踩蹋優(yōu)槿斯ぞ蜁稿e。
從關(guān)系型數(shù)據(jù)平臺往Nosql數(shù)據(jù)平臺遷移時企孩，尤其是對傳統(tǒng)行業(yè)的業(yè)務(wù)來說锭碳，在模型設(shè)計(jì)階段袁稽、以及給出的ETL口徑要考慮更多的業(yè)務(wù)規(guī)則檢查勿璃，其次要考慮更多的維度退化、多冗余、表打?qū)捥幚聿挂伞：唵握f就是發(fā)揮數(shù)據(jù)平臺的計(jì)算能力同時要更加的各方面確保數(shù)據(jù)準(zhǔn)確安全可靠歧沪。
數(shù)據(jù)模型ODS 到EDW 這塊的設(shè)計(jì)方法百度上留下的文檔資料太多的了，請這位提問的老師百度吧莲组。
**8****．大數(shù)據(jù)****倉庫****中如何做快速****維處****理诊胞？互****聯(lián)****網(wǎng)數(shù)****倉****數(shù)據(jù)****質(zhì)****量不好如何****對****數(shù)，如何確立****標(biāo)****準(zhǔn)的****對****數(shù)口徑锹杈？******
松子老師：快速變化維度可以轉(zhuǎn)化為緩慢變化為來出來撵孤，我自己理解的快速維度是相對于緩慢維度參照的來說的。
舉個例子竭望，年齡-轉(zhuǎn)化為天數(shù)可以是定義快速變化維度邪码，因?yàn)槊刻於荚谧兓Ｎ覀兛梢园涯挲g退化為區(qū)間維度來處理咬清，還可以把年齡做成動態(tài)維度來處理闭专，事實(shí)表中保存的就是實(shí)際的出生年月并打?qū)挶恚挲g(天)通過計(jì)算方式來處理旧烧。還有種方法通過對代理鍵的方式來處理。
我目前也不知道對數(shù)據(jù)的標(biāo)準(zhǔn)是什么。但是我自己用的方法衣赶，把一個指標(biāo)的整個數(shù)據(jù)流向切出幾個關(guān)鍵點(diǎn)通過SQL去實(shí)現(xiàn)對數(shù)画拾，看波動振幅，波動曲線杖小。同時還會比如發(fā)不通的版本的小流量測試的方式來做數(shù)據(jù)校對肆汹。
9****． 做為數(shù)據(jù)行業(yè)從業(yè)者，需要掌握哪些重要的基礎(chǔ)知識予权？另：如果從零開始建立一個數(shù)據(jù)平臺昂勉，需要哪些資源配置（人，財(cái)扫腺，物岗照，技術(shù)）？大致總投資額度多少笆环？如果同行產(chǎn)品間多種來源的數(shù)據(jù)攒至，可有成熟的解決方案？謝謝…
松子老師：這個問題太宏觀了躁劣。作為數(shù)據(jù)行業(yè)從業(yè)者迫吐，需要掌握哪些重要基礎(chǔ)知識，這個是要看從事具體數(shù)據(jù)域的垂直行業(yè)账忘。
比如說 數(shù)據(jù)開發(fā)志膀、數(shù)據(jù)模型熙宇、數(shù)據(jù)產(chǎn)品、數(shù)據(jù)分析師溉浙、數(shù)據(jù)運(yùn)營烫止、數(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ù)目標(biāo)不太明確下颂郎，難以確定方案吨铸，人員配置上選用不同技術(shù)方案去搭建的配置是不太一樣的，比如說傳統(tǒng)平臺來講祖秒，運(yùn)維诞吱、DBA、數(shù)據(jù)開發(fā)竭缝、數(shù)據(jù)模型房维、報(bào)表人員。
從互聯(lián)網(wǎng)數(shù)據(jù)平臺基本配置上抬纸，數(shù)據(jù)架構(gòu)師咙俩、運(yùn)維、底層大數(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ù)溪厘。
10. Standalone****模式下星爪，Model.save(Path)怎么一直提示錯誤贬媒，是不是配置Spark時需要將Hdfs的配置引進(jìn)來啊～？表示初學(xué)Spark
松子老師：這個問題有點(diǎn)超出我的能力范圍了绷旗，所以對不起回答不了喜鼓。
我本身不是做技術(shù)的忧设。僅知道一點(diǎn)技術(shù)名詞。
11. ****傳統(tǒng)銀行業(yè)數(shù)據(jù)模型什么時候會走向互聯(lián)網(wǎng)模式呢颠通？目前在傳統(tǒng)銀行數(shù)據(jù)平臺的產(chǎn)品是不是特別多？
松子老師：這個問題我自己就不知道了膀懈，或許是傳統(tǒng)銀行在數(shù)據(jù)平臺的實(shí)施上全面用互聯(lián)網(wǎng)的Nosql大數(shù)據(jù)處理技術(shù)吧顿锰。至于說傳統(tǒng)銀行數(shù)據(jù)模型用現(xiàn)有的互聯(lián)網(wǎng)數(shù)據(jù)模型理念去設(shè)計(jì)是否完全可行，數(shù)據(jù)一致性启搂、高準(zhǔn)確性通過更多的方案去保證硼控。
首先我需要確定一下這個產(chǎn)品是否指的“數(shù)據(jù)產(chǎn)品”。
如果是數(shù)據(jù)產(chǎn)品胳赌，那其實(shí)傳統(tǒng)行業(yè)數(shù)據(jù)平臺本身就有一些數(shù)據(jù)產(chǎn)品了牢撼，而且也都是存在的。數(shù)據(jù)產(chǎn)品自從數(shù)據(jù)倉庫出現(xiàn)以來它其實(shí)一直都存在的疑苫，只不過是近幾年因?yàn)榛ヂ?lián)網(wǎng)特別愛制造“流行詞“把數(shù)據(jù)產(chǎn)品這個詞給放大了熏版。互聯(lián)網(wǎng)是得數(shù)據(jù)產(chǎn)品從早期的重量級逐漸進(jìn)化為輕量級捍掺、從大而全的解決方案逐漸演進(jìn)為因小而美撼短。
我來給出幾組例子，大約從2004年到現(xiàn)在的幾組數(shù)據(jù)產(chǎn)品的例子
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
[圖片上傳中挺勿。曲横。。（26）]
(點(diǎn)擊放大圖像)
[圖片上傳中不瓶。禾嫉。。（27）]
(點(diǎn)擊放大圖像)
[圖片上傳中蚊丐。熙参。。（28）]
(點(diǎn)擊放大圖像)
[圖片上傳中麦备。尊惰。。（29）]
(點(diǎn)擊放大圖像)
[圖片上傳中泥兰。弄屡。。（30）]
(點(diǎn)擊放大圖像)
[圖片上傳中鞋诗。膀捷。。（31）]
你可以分類一下削彬，這些數(shù)據(jù)產(chǎn)品的特點(diǎn)是什么全庸？滿足了用戶怎么樣的痛點(diǎn)需求秀仲？滿足了用戶怎么樣的使用流程。
12 ****壶笼。傳統(tǒng)行業(yè)的數(shù)據(jù)倉庫從業(yè)人員神僵，如果轉(zhuǎn)到互聯(lián)網(wǎng)行業(yè)，應(yīng)該學(xué)習(xí)哪些技能覆劈？
松子老師：這個問題你可以百度搜索“大數(shù)據(jù)職位所需要的數(shù)據(jù)技能” http://blog.jobbole.com/99039/ 這篇文章保礼。自己覺得人家回答的比我專業(yè)。//
我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史（四）：互聯(lián)網(wǎng)時代 ? 下篇
http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-internet-age
編者按：本文是松子（李博源）的大數(shù)據(jù)平臺發(fā)展史系列文章的第四篇（共四篇）责语，本系列以獨(dú)特的視角暖释，比較了非互聯(lián)網(wǎng)和互聯(lián)網(wǎng)兩個時代以及傳統(tǒng)行業(yè)與非傳統(tǒng)行業(yè)沈善。是對數(shù)據(jù)平臺發(fā)展的一個回憶，對非互聯(lián)網(wǎng)、互聯(lián)網(wǎng)式矫，從數(shù)據(jù)平臺的用戶角度婿斥、數(shù)據(jù)架構(gòu)演進(jìn)带兜、模型等進(jìn)行了闡述汁尺。
在互聯(lián)網(wǎng)時代被弱化的數(shù)據(jù)模型
談起數(shù)據(jù)模型就不得不提傳統(tǒng)數(shù)據(jù)平臺架構(gòu)發(fā)展，我相信很多朋友都曉得傳統(tǒng)數(shù)據(jù)平臺的知識徒河，其架構(gòu)演進(jìn)簡單一句話說“基本上可以分為五個時代吹害、四種架構(gòu)”，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與數(shù)據(jù)源類型多樣化特點(diǎn)虚青，從高階架構(gòu)上來看大約從傳統(tǒng)數(shù)據(jù)平臺第三代架構(gòu)開始延續(xù)的它呀，但是往后的發(fā)展從我自己的這一點(diǎn)知識上很難對互聯(lián)網(wǎng)的數(shù)據(jù)平臺做架構(gòu)歸類。
但是從數(shù)據(jù)平臺建設(shè)與服務(wù)角色上還是有章可循的棒厘。就像上篇分享到那樣纵穿，類比兩個行業(yè)，互聯(lián)網(wǎng)企業(yè)中員工年齡比非互聯(lián)網(wǎng)企業(yè)的要年輕奢人、受教育程度谓媒、對計(jì)算機(jī)的焦慮程度明顯比傳統(tǒng)企業(yè)要低、還偶遇其它各方面的緣故何乎，導(dǎo)致了數(shù)據(jù)平臺所面對用戶群體與非互聯(lián)網(wǎng)數(shù)據(jù)平臺有所差異化句惯。
傳統(tǒng)行業(yè)與互聯(lián)網(wǎng)行業(yè)數(shù)據(jù)平臺用戶特性我只選擇前文章的兩張圖來表示
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
在傳統(tǒng)數(shù)據(jù)平臺要背后有一個完整數(shù)據(jù)倉庫團(tuán)隊(duì)去服務(wù)業(yè)務(wù)方，業(yè)務(wù)方嗷嗷待哺的等待被動方式去滿足支救。中低層數(shù)據(jù)基本不會對業(yè)務(wù)方開放抢野，所以不管數(shù)據(jù)模型采用何種建模方式，主要滿足當(dāng)時數(shù)據(jù)架構(gòu)規(guī)劃即可各墨。
互聯(lián)網(wǎng)業(yè)務(wù)的快速發(fā)展使得大家已經(jīng)從經(jīng)營指孤、分析的訴求重點(diǎn)轉(zhuǎn)為數(shù)據(jù)化的精細(xì)運(yùn)營上，如何做好精細(xì)化運(yùn)營問題上來，當(dāng)資源不夠時用戶就叫喊恃轩，甚至有的業(yè)務(wù)方會挽起袖子來自己參與到從數(shù)據(jù)整理结洼、加工、分析階段叉跛。
此時呢松忍，原有建設(shè)數(shù)據(jù)平臺的多個角色（數(shù)據(jù)開發(fā)、模型設(shè)計(jì)）可能轉(zhuǎn)為對其它非專業(yè)使用數(shù)據(jù)方筷厘，做培訓(xùn)鸣峭、咨詢與落地，寫更加適合當(dāng)前企業(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àn)椴粚I(yè)性玖雁，導(dǎo)致數(shù)據(jù)質(zhì)量問題、重復(fù)對分?jǐn)?shù)據(jù)浪費(fèi)存儲與資源盖腕、口徑多樣化赫冬、編碼不統(tǒng)一、命名問題等等原因溃列。數(shù)據(jù)質(zhì)量逐漸變成一個特別突出的問題劲厌。
傳統(tǒng)企業(yè)的數(shù)據(jù)源基本來自excel、表格听隐、DB系統(tǒng)等补鼻，但在互聯(lián)網(wǎng)有網(wǎng)站點(diǎn)擊流日志、視頻雅任、音頻风范、圖片數(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ù)有些力不從心寇漫。
當(dāng)數(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è)也有自己特點(diǎn)捌归，傳統(tǒng)行業(yè)所涉及數(shù)據(jù)模型這個領(lǐng)域涉及的很多內(nèi)容在互聯(lián)網(wǎng)變成以其他的曲線救國的方式存在了。
在互聯(lián)網(wǎng)曲線救國新解決
回顧在傳統(tǒng)行業(yè)數(shù)據(jù)平臺中岭粤，不管兩位大師爭論點(diǎn)數(shù)據(jù)模型的設(shè)計(jì)采用那種范式（Bill Inmon的EDW的原則是準(zhǔn)三范式的設(shè)計(jì)惜索、Ralph kilmbal是星型結(jié)構(gòu)）但是都要非常重視數(shù)據(jù)源的質(zhì)量問題。所以傳統(tǒng)行業(yè)的數(shù)據(jù)模型會全盤考慮數(shù)據(jù)質(zhì)量問題剃浇，并通過數(shù)據(jù)抽樣分析給出合適的清洗口徑巾兆。
(點(diǎn)擊放大圖像)
上圖來自我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ù)”對一年的還是不準(zhǔn)的）淘讥。在應(yīng)對數(shù)據(jù)的質(zhì)量問題圃伶，目前互聯(lián)網(wǎng)有些做法是把數(shù)據(jù)標(biāo)準(zhǔn)化前置到業(yè)務(wù)數(shù)據(jù)產(chǎn)生就做，從根源上去杜絕數(shù)據(jù)質(zhì)量蒲列，但是這種場景比較實(shí)用在Log 日志的數(shù)據(jù)源中窒朋，比如移動互聯(lián)網(wǎng)最近流行的基于事件模型“Event”模型，在日志產(chǎn)生時就規(guī)定好存儲格式（備注：大家度娘搜索蝗岖，“學(xué)習(xí)筆記：The Log（我所讀過的最好的一篇分布式技術(shù)文章）” 對這個講解很詳細(xì)）侥猩。
在傳統(tǒng)行業(yè)，目前還是以混合模型設(shè)計(jì)方式為主抵赢。在互聯(lián)網(wǎng)的我所接觸的一些業(yè)務(wù)欺劳，在參照傳統(tǒng)數(shù)據(jù)模型方法論基礎(chǔ)上逐步演進(jìn)適合互聯(lián)網(wǎng)數(shù)據(jù)的數(shù)據(jù)模型方法。
比如互聯(lián)網(wǎng)金融等一些業(yè)務(wù)會參考傳統(tǒng)金融行業(yè)對主題域的劃分铅鲤、OMG數(shù)據(jù)倉庫元數(shù)據(jù)管理CWM模型杰标、FSDM金融模型，再進(jìn)一步考慮大數(shù)據(jù)處理特性去進(jìn)行設(shè)計(jì)彩匕，所有從Hight Level 數(shù)據(jù)架構(gòu)圖看到主題層次劃分與傳統(tǒng)第三代數(shù)據(jù)倉庫還是很多相似之處腔剂，當(dāng)然模型架構(gòu)也有分三層、四層驼仪、五層的掸犬。
不同的地方模型細(xì)節(jié)處理上已經(jīng)完全不一樣，比如數(shù)據(jù)的多樣性绪爸、拉寬事實(shí)表湾碎、度量值單獨(dú)存儲、滿足數(shù)據(jù)快速重生奠货、維度的二次降維處理等介褥、增加大量冗余列、增加大量派生列，結(jié)合自動化元數(shù)據(jù)來耦合柔滔、合并等相關(guān)管理铣口。
(點(diǎn)擊放大圖像)
[圖片上傳中虎敦。。。（4）]
上圖是支付寶非常早期數(shù)據(jù)模型
(點(diǎn)擊放大圖像)
上圖是支付寶非常早期數(shù)據(jù)模型
我們常提到的多維模型在大數(shù)據(jù)處理下進(jìn)行了退化維度處理痊末。大家知道Olap多維模型秦效，隨著維度的增加事實(shí)表的數(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è)計(jì)多維挖掘分析數(shù)據(jù)產(chǎn)品背后的技術(shù)就是搜索引擎實(shí)現(xiàn)的）嘶朱，現(xiàn)在應(yīng)該也有新技術(shù)出現(xiàn)了來解決類似的問題蛾坯。
(點(diǎn)擊放大圖像)
上圖為2012年產(chǎn)品UI之一。
(點(diǎn)擊放大圖像)
[圖片上傳中疏遏。脉课。。（7）]
上圖是2011-2012年該產(chǎn)品系列背后當(dāng)時使用的技術(shù)
互聯(lián)網(wǎng)業(yè)務(wù)特點(diǎn)業(yè)務(wù)垂直拆分非常細(xì)改览，比如一個用戶注冊下翎、密碼找回的流程有可能存在好幾個產(chǎn)品負(fù)責(zé)同一個業(yè)務(wù)流程不同環(huán)節(jié)缤言，相關(guān)的一個策略宝当、產(chǎn)品feature快速迭代上線等等都要數(shù)據(jù)評估。數(shù)據(jù)從前端埋點(diǎn)到采集然后再由各個環(huán)節(jié)到數(shù)據(jù)平臺胆萧，再有數(shù)據(jù)分析師或各業(yè)務(wù)部門去使用庆揩，基本拉長了時間周期。需求部門與實(shí)施部門能力和經(jīng)驗(yàn)有千差萬別的需求跌穗，造成了懂技術(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ù)特點(diǎn)是變化非常迅速的，能穩(wěn)定的業(yè)務(wù)達(dá)到65%算對數(shù)據(jù)平臺是個福音了（根據(jù)對某寶寶的印象）剩余的業(yè)務(wù)變化迅速佩微，必然導(dǎo)致數(shù)據(jù)模型快速上下線缝彬。
Kimball老人家提出的維度建模（備注，在本系列發(fā)展史得第一篇有介紹）圍繞業(yè)務(wù)模型能夠非常直觀的表達(dá)出業(yè)務(wù)的數(shù)據(jù)關(guān)系哺眯，但是在互聯(lián)網(wǎng)NOSQL犧牲掉了關(guān)系型數(shù)據(jù)庫的一致性谷浅、完整性等等很多東西。維度數(shù)據(jù)模型又基于這些大數(shù)據(jù)技術(shù)的，所以進(jìn)化的更加輕量級與基于細(xì)節(jié)數(shù)據(jù)的維度退化建模（原有的緩慢變化維一疯、快速變化維撼玄、大維、迷你維违施、父子維互纯、雪花維為了適應(yīng)互聯(lián)網(wǎng)的大數(shù)據(jù)Nosql處理技術(shù)進(jìn)行反規(guī)范化、化&數(shù)據(jù)冗余設(shè)計(jì)磕蒲。
退化維度的反規(guī)范化設(shè)計(jì)一方面可以把一條查詢語句所需要的所有數(shù)據(jù)組合起來放到一個地方存儲 Key values 的方式（比如說商品有不同類型留潦，每一種類型商品又有自己的不同屬性，可以采用一對多辣往、多對多的方式存儲兔院，例如把一個多維映射為一個Key value）。
講到互聯(lián)網(wǎng)數(shù)據(jù)平臺就要提數(shù)據(jù)模型站削，提了數(shù)據(jù)模型就要提Nosql技術(shù)坊萝，
(點(diǎn)擊放大圖像)
上圖來自Nosql文檔系列的一幅圖
Nosql 是大數(shù)據(jù)處理的特征之一⌒砥穑互聯(lián)網(wǎng)數(shù)據(jù)平臺數(shù)據(jù)模型與NoSql技術(shù)還是蠻緊密的十偶。這里有外文講解Nosql Data modeling technigues 從技術(shù)角度講解非常詳（https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/）劫侧。
因?yàn)榍斑吿岬降拇髷?shù)據(jù)平臺技術(shù)特性決定了傳統(tǒng)edw模型饭入、維度模型直接在互聯(lián)網(wǎng)數(shù)據(jù)大數(shù)據(jù)平臺部署或許還有“好些未知”障礙等待大家去克服。同時在傳統(tǒng)數(shù)據(jù)建模用到的一些方法經(jīng)過互聯(lián)網(wǎng)熏陶或許演進(jìn)成一種新的數(shù)據(jù)產(chǎn)品或方案吧筹吐。
到此為止“我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史”上下共四篇與大家分享完畢猛频，這個寫作前后經(jīng)歷剛好一個月左右狮崩，算是對自己數(shù)據(jù)從業(yè)經(jīng)歷回顧之一吧。在知識的整理中很多都是蜻蜓點(diǎn)水鹿寻，每個知識域都是一個非常深的專業(yè)方向睦柴，自己涉足很膚淺，在文章中分享不足之處請各位讀者見諒Ｕ毖坦敌！
個人郵箱是5592094@qq.com 歡迎電郵交流。
接下來我會進(jìn)入數(shù)據(jù)產(chǎn)品這個領(lǐng)域的分享痢法，當(dāng)年車品覺老師自豪的作品之一“黃金策”狱窘，我是數(shù)據(jù)產(chǎn)品經(jīng)理。（ps：自己躲在墻角拿車品覺老師往自己臉上貼金了）疯暑。
后記
有一次數(shù)據(jù)產(chǎn)品神策的創(chuàng)始人兼好友@桑文鋒＠SensorsData跟我說來做次分享吧训柴，我當(dāng)時出了幾個題目，最后就選擇了“我所經(jīng)歷的大數(shù)據(jù)平臺“妇拯，就形成了大家看到的”我所經(jīng)歷的大數(shù)據(jù)平臺“系列文章.
在整理期間得到了死黨@周愛民幻馁、@神策-桑文峰洗鸵、 InfoQ小編@Tina Du 、@betty zhou @Laurel大力協(xié)助仗嗦，在這里感謝１毂酢！稀拐！
番外篇
這一篇是在24日舉行的分享大家提到的一些問題火邓，經(jīng)過整理算是對正文的補(bǔ)充吧，從互聯(lián)網(wǎng)敏捷數(shù)據(jù)模型等角度做了較深入的細(xì)節(jié)介紹德撬。同時在數(shù)據(jù)產(chǎn)品方面的回答包含了一點(diǎn)未來寫作篇“數(shù)據(jù)產(chǎn)品”系列的一點(diǎn)內(nèi)容铲咨。
1****，傳統(tǒng)我們做BI的蜓洪，做數(shù)據(jù)展現(xiàn)會建模后以pivot展現(xiàn)cube數(shù)據(jù)纤勒，不知道現(xiàn)在互聯(lián)網(wǎng)公司數(shù)據(jù)展示如何做的？第三方工具還是用API取數(shù)據(jù)平臺里的數(shù)據(jù)隆檀？adhoc報(bào)表及靈活更換維度的時候web端一般是怎么做的摇天？
松子老師：剛才文章中提到了比如傳統(tǒng)行業(yè)的多維數(shù)據(jù)模型cube。在互聯(lián)網(wǎng)采用的曲線救國方式解決的恐仑。 在分享中我給出了幾個圖泉坐。就是通過搜索引擎曲線救國方式實(shí)現(xiàn)類似Olap的模擬。
在這塊的模型的處理上采用的是維度退化處理裳仆。通過反規(guī)范化腕让，數(shù)據(jù)項(xiàng)、數(shù)據(jù)冗余去處理鉴逞。在前端做特殊處理记某。
這個當(dāng)時產(chǎn)品原型之一：
(點(diǎn)擊放大圖像)
這是一個2011年-2012年左右的數(shù)據(jù)產(chǎn)品司训，當(dāng)時算是即時計(jì)算的一種构捡。不過已經(jīng)過去好幾年了，當(dāng)今新技術(shù)下Olap 引擎應(yīng)該有很好的提升壳猜。
目前我知道的家互聯(lián)網(wǎng)公司勾徽，在前端展現(xiàn)有使用第三方套件比如spagoBi、pentaho 等 有自己設(shè)計(jì)開發(fā)定制化數(shù)據(jù)前端展現(xiàn)统扳。比如我剛開始分享的那兩個之前在去哪兒網(wǎng)設(shè)計(jì)的數(shù)據(jù)平臺內(nèi)部界面之一喘帚，當(dāng)然數(shù)據(jù)產(chǎn)品是另一個話題了，通過對數(shù)據(jù)分析抽象指標(biāo)慌洪、分析模型俺抽、用戶使用功能與流程庐镐、未來規(guī)劃考慮用戶體驗(yàn)去設(shè)計(jì)。
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
[圖片上傳中倾鲫。粗合。。（11）]
(點(diǎn)擊放大圖像)
2****乌昔，互聯(lián)網(wǎng)財(cái)經(jīng)類公司隙疚，業(yè)務(wù)包括財(cái)經(jīng)網(wǎng)站、基金磕道、股票供屉、金融等，這類公司的數(shù)據(jù)倉庫模型應(yīng)該如何設(shè)計(jì)溺蕉？特點(diǎn)和注意事項(xiàng)是什么伶丐？案例介紹？十分感謝疯特。
松子老師：我自己經(jīng)歷過的是互聯(lián)網(wǎng)金融以及移動互聯(lián)網(wǎng)行撵割。對這兩塊比較清楚≌奚郑互聯(lián)網(wǎng)金融起因?yàn)闃I(yè)務(wù)的特性是類金融類的啡彬，與銀行有些地方是相似的。
比如大約在2012年前支付寶業(yè)務(wù)特點(diǎn)涉及類金融交易：充值故硅、提現(xiàn)庶灿、賬務(wù)管理類電子商務(wù)：購物交易過程變更、實(shí)際交易（對B機(jī)票吃衅、對C水電等） 非純電子商務(wù)往踢；純金融；個人信用徘层，理財(cái)類峻呕。系統(tǒng)之間依賴度較為復(fù)雜，垂直依賴（業(yè)務(wù)與核心）跨層依賴（跨過交易到賬務(wù)）趣效。
在設(shè)計(jì)方法上還是采用維度模型設(shè)計(jì)方式瘦癌。底層是數(shù)據(jù)驅(qū)動為向?qū)ВY(jié)合業(yè)務(wù)需求驅(qū)動跷敬，通過簡單讯私、退化維度的方式拉寬表結(jié)構(gòu)。
底層采用松耦合設(shè)計(jì)西傀。主題之間是松耦合方式斤寇。至體內(nèi)采用細(xì)粒度退化維度。
在主題域上的的設(shè)計(jì)基本參考了OMG的數(shù)據(jù)倉庫元數(shù)據(jù)設(shè)計(jì)CWM模型拥褂、IBM 的fsdm金融模型娘锁、還有新巴塞爾資本協(xié)議（Basel II Capital Accord）需提供數(shù)據(jù)規(guī)范去的設(shè)計(jì)。所以數(shù)據(jù)模型是五層的結(jié)構(gòu)饺鹃。
在細(xì)節(jié)處理上莫秆，增量ODS層數(shù)據(jù)和前一天DWD相關(guān)表進(jìn)行 merge處理碎税。
在一些層次上，基本聚合馏锡、匯總增加派生事實(shí)表（簡單一句話退化為度打?qū)挘├柞濉Ｈ缓蟀凑諛I(yè)務(wù)主體合并信息等。
比如開始給大家分享的那張圖：
(點(diǎn)擊放大圖像)
[圖片上傳中杯道。匪煌。。（13）]
在維度模型退化處理時党巾，要注意最細(xì)粒度數(shù)據(jù)保留萎庭、不同層次的數(shù)據(jù)支持?jǐn)?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ù)模型磨淌。
這種元數(shù)據(jù)驅(qū)動工具型數(shù)據(jù)產(chǎn)品我會在未來數(shù)據(jù)產(chǎn)品系列中做詳細(xì)介紹的。
3****，互聯(lián)網(wǎng)企業(yè)大數(shù)據(jù)平臺的發(fā)展歷程是怎樣的？
松子老師：這個我相信應(yīng)該是傳統(tǒng)數(shù)據(jù)平臺朋友提到的捻勉。傳統(tǒng)行業(yè)數(shù)據(jù)平臺架構(gòu)演進(jìn)我總結(jié)簡單一句話說“基本上可以分為五個時代、四種架構(gòu)”刀森，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與類型暴增的特點(diǎn)踱启，從高階架構(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é)下來用戶特點(diǎn)：
(點(diǎn)擊放大圖像)
[圖片上傳中冠蒋。。芽隆。（14）]
更加詳細(xì)的每一代數(shù)據(jù)平臺建設(shè)浊服、服務(wù)角色特點(diǎn)您可以看我這個系列文章的第三篇统屈，http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-paet02
4****胚吁，有沒有好的元數(shù)據(jù)管理工具推薦？主要偏向數(shù)據(jù)字典與血統(tǒng)等愁憔。
松子老師：元數(shù)據(jù)以前目前沒有太多的好管理工具腕扶。以前是在支付寶是我自己設(shè)計(jì)的一個數(shù)據(jù)產(chǎn)品。第一版自己用Delphi 開發(fā)的吨掌。
（圖很多：）
(點(diǎn)擊放大圖像)
[圖片上傳中半抱。脓恕。。（15）]
(點(diǎn)擊放大圖像)
[圖片上傳中窿侈。炼幔。。（16）]
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
[圖片上傳中史简。乃秀。。（18）]
(點(diǎn)擊放大圖像)
[圖片上傳中圆兵。跺讯。。（19）]
以前被逼的自己寫了一個殉农，通過解析刀脏，實(shí)現(xiàn)了字段級的血緣影響分析。這只是第二步超凳，后來又把running 信息給搞了進(jìn)來愈污。還有分享時提到的模型信息、整個閉環(huán)的分類信息轮傍。
這是一個分支：
(點(diǎn)擊放大圖像)
[圖片上傳中钙畔。。金麸。（20）]
但是我們實(shí)現(xiàn)了字段級解析準(zhǔn)確率達(dá)到了94%左右擎析。有細(xì)微的錯誤就人工revew一遍。
5. ****松子老師挥下，數(shù)據(jù)管控的數(shù)據(jù)質(zhì)量部分是怎么處理的呢揍魂？
松子老師： 數(shù)據(jù)管控， 這方面我不太懂的棚瘟，但是數(shù)據(jù)質(zhì)量现斋，這玩意可大可小的搜吧。比如像在分享時說過的丧鸯，在移動互聯(lián)網(wǎng)的數(shù)據(jù)質(zhì)量處理方式可以由原有的ETL(ELT)階段前置到業(yè)務(wù)系統(tǒng)去解決，比如移動互聯(lián)網(wǎng)的App log 日志卓箫，日志標(biāo)準(zhǔn)化后事件模型”存儲來解決迷雪。那非app 日志類如何解決呢比如Payment限书、order等，數(shù)據(jù)質(zhì)量比較考慮的可以只做到監(jiān)控章咧。
我來分享個圖倦西。剛好是我設(shè)計(jì)數(shù)據(jù)質(zhì)量產(chǎn)品時搞的，理清數(shù)據(jù)質(zhì)量的問題：
(點(diǎn)擊放大圖像)
[圖片上傳中赁严。扰柠。粉铐。（21）]
(點(diǎn)擊放大圖像)
[圖片上傳中。卤档。蝙泼。（22）]
(點(diǎn)擊放大圖像)
[圖片上傳中。劝枣。踱承。（23）]
只要數(shù)據(jù)進(jìn)入倉庫與應(yīng)用體系，處理起來就比較困難了哨免，所以在數(shù)據(jù)平臺階段最好是通過監(jiān)控茎活、前置去解決。目前數(shù)據(jù)質(zhì)量確實(shí)難以100%由事后搞到事前去處理琢唾。我對數(shù)據(jù)平臺與數(shù)據(jù)產(chǎn)品的建設(shè)就是實(shí)用為主载荔。怎么實(shí)用怎么來。我是比較現(xiàn)實(shí)的實(shí)用主義者采桃。
6. ****能否分享一些數(shù)據(jù)產(chǎn)品種類及實(shí)例：
松子老師：在前邊五個問題懒熙、以及文章中又都涉及數(shù)據(jù)產(chǎn)品實(shí)力的一些分享。
提到數(shù)據(jù)產(chǎn)品的分類我就想把這個圖發(fā)出來普办。
自己認(rèn)為沒有特別明確的劃分線工扎，但是數(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工具拘荡、資源管控等等。
面向用戶功能有報(bào)表型撬陵、多維型數(shù)據(jù)產(chǎn)品珊皿、定制化數(shù)據(jù)產(chǎn)品、挖掘型數(shù)據(jù)產(chǎn)品巨税。
面向內(nèi)部用戶蟋定、外部個人用戶、外部企業(yè)用戶又有不同的分類垢夹。
根據(jù)業(yè)務(wù)又可以劃分很多溢吻，面向C類用戶、面向B類商戶果元、金融風(fēng)險(xiǎn)等等
從近幾年的數(shù)據(jù)產(chǎn)品來看促王，是更好的輔助用戶的做決策的一種產(chǎn)品形態(tài)，在用戶的決策與行動中充當(dāng)信息的分析者與價值使用者而晒；數(shù)據(jù)產(chǎn)品有個自己的共性：由解決的一個實(shí)際的業(yè)務(wù)問題出發(fā)蝇狼，分解出的分析指標(biāo)，分析模型形葬，分析流程組成梦湘，再考慮到功能易用性绽诚，未來功能擴(kuò)展，考慮用戶對數(shù)據(jù)易用性（比如數(shù)據(jù)的呈現(xiàn)層次颤专，不可能一次把所有數(shù)據(jù)的呈現(xiàn)給用戶）來組成的。
(點(diǎn)擊放大圖像)
[圖片上傳中钠乏。栖秕。。（24）]
7. ****銀行業(yè)從傳統(tǒng)的ods到edw再到大數(shù)據(jù)平臺這塊過渡晓避，模型如何建設(shè)簇捍？平臺優(yōu)勢如何發(fā)揮？
松子老師：這個問題還是有些難度的俏拱，自己回答的可能有些片面暑塑。首先我們清醒的清楚“大數(shù)據(jù)”是什么？再次不同的場景可以采用不同的技術(shù)去解決锅必。
“大數(shù)據(jù)”事格，拆開來看大、數(shù)據(jù)搞隐，大可以是指的數(shù)據(jù)源結(jié)構(gòu)簡單（ps 如果了解過當(dāng)代對大數(shù)據(jù)的定義就知道四個特性）但是量級夠大分蓖，比如清算、結(jié)算尔许、對公么鹤、對私、中間業(yè)務(wù)等等每一個拿出來都是幾十T味廊，但是這些業(yè)務(wù)數(shù)據(jù)都是保存?zhèn)鹘y(tǒng)的關(guān)系型數(shù)據(jù)庫中如DB2蒸甜、Oracle、MSsql中余佛，因?yàn)樵跀?shù)據(jù)平臺存儲是通過準(zhǔn)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ù)的去演進(jìn)解決。（最早時我的是中信銀行憔恳、光大銀行在2011年左右開始考慮Hadoop技術(shù)瓤荔，后來不知道如何了）。
但是互聯(lián)網(wǎng)的數(shù)據(jù)平臺技術(shù)大都是NOSQL模式钥组，犧牲掉了傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)一致性输硝、完整性、唯一索引等等程梦，只干性能的事情（當(dāng)然除了性能点把、可擴(kuò)展性也是的）.
原有在傳統(tǒng)數(shù)據(jù)平臺模型設(shè)計(jì)上可以考慮的一些通過主外鍵、唯一索引做一些業(yè)務(wù)約束的方法屿附，在nosql上統(tǒng)統(tǒng)的都沒有了郎逃，這些約束必須放到數(shù)據(jù)加工階段去想辦法做檢查。傳統(tǒng)數(shù)據(jù)平臺如果在Insert挺份、update數(shù)據(jù)時違反了業(yè)務(wù)約束可以做報(bào)警或異常處理褒翰，但是在Nosql的平臺上要求ETL 去手動遵守這些規(guī)則檢查。但是有時ETL開發(fā)根本不遵守的压恒，僅僅是兩個表關(guān)聯(lián)起來影暴，也可能忘記按照某一個業(yè)務(wù)唯一索引做去重操作。簡單說探赫，原有靠關(guān)系型數(shù)據(jù)庫本身機(jī)制去做檢查一些規(guī)則變?yōu)槿斯ば椭妫優(yōu)槿斯ぞ蜁稿e。
從關(guān)系型數(shù)據(jù)平臺往Nosql數(shù)據(jù)平臺遷移時伦吠，尤其是對傳統(tǒng)行業(yè)的業(yè)務(wù)來說妆兑，在模型設(shè)計(jì)階段夯秃、以及給出的ETL口徑要考慮更多的業(yè)務(wù)規(guī)則檢查伟叛，其次要考慮更多的維度退化叛买、多冗余囤萤、表打?qū)捥幚怼：唵握f就是發(fā)揮數(shù)據(jù)平臺的計(jì)算能力同時要更加的各方面確保數(shù)據(jù)準(zhǔn)確安全可靠给涕。
數(shù)據(jù)模型ODS 到EDW 這塊的設(shè)計(jì)方法百度上留下的文檔資料太多的了怖糊，請這位提問的老師百度吧纱扭。
**8****．大數(shù)據(jù)****倉庫****中如何做快速****維處****理衡怀？互****聯(lián)****網(wǎng)數(shù)****倉****數(shù)據(jù)****質(zhì)****量不好如何****對****數(shù)棍矛，如何確立****標(biāo)****準(zhǔn)的****對****數(shù)口徑？******
松子老師：快速變化維度可以轉(zhuǎn)化為緩慢變化為來出來抛杨，我自己理解的快速維度是相對于緩慢維度參照的來說的够委。
舉個例子，年齡-轉(zhuǎn)化為天數(shù)可以是定義快速變化維度怖现，因?yàn)槊刻於荚谧兓旅薄Ｎ覀兛梢园涯挲g退化為區(qū)間維度來處理，還可以把年齡做成動態(tài)維度來處理，事實(shí)表中保存的就是實(shí)際的出生年月并打?qū)挶砼瞬Γ挲g(天)通過計(jì)算方式來處理吊输。還有種方法通過對代理鍵的方式來處理。
我目前也不知道對數(shù)據(jù)的標(biāo)準(zhǔn)是什么战秋。但是我自己用的方法璧亚，把一個指標(biāo)的整個數(shù)據(jù)流向切出幾個關(guān)鍵點(diǎn)通過SQL去實(shí)現(xiàn)對數(shù)讨韭，看波動振幅脂信，波動曲線。同時還會比如發(fā)不通的版本的小流量測試的方式來做數(shù)據(jù)校對透硝。
9****． 做為數(shù)據(jù)行業(yè)從業(yè)者狰闪，需要掌握哪些重要的基礎(chǔ)知識？另：如果從零開始建立一個數(shù)據(jù)平臺濒生，需要哪些資源配置（人埋泵，財(cái)，物罪治，技術(shù)）丽声？大致總投資額度多少？如果同行產(chǎn)品間多種來源的數(shù)據(jù)觉义，可有成熟的解決方案雁社？謝謝…
松子老師：這個問題太宏觀了。作為數(shù)據(jù)行業(yè)從業(yè)者晒骇，需要掌握哪些重要基礎(chǔ)知識霉撵，這個是要看從事具體數(shù)據(jù)域的垂直行業(yè)。
比如說 數(shù)據(jù)開發(fā)洪囤、數(shù)據(jù)模型徒坡、數(shù)據(jù)產(chǎn)品、數(shù)據(jù)分析師瘤缩、數(shù)據(jù)運(yùn)營喇完、數(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ù)目標(biāo)不太明確下富腊，難以確定方案坏逢，人員配置上選用不同技術(shù)方案去搭建的配置是不太一樣的，比如說傳統(tǒng)平臺來講汗洒，運(yùn)維持偏、DBA、數(shù)據(jù)開發(fā)可免、數(shù)據(jù)模型浮入、報(bào)表人員龙优。
從互聯(lián)網(wǎng)數(shù)據(jù)平臺基本配置上，數(shù)據(jù)架構(gòu)師事秀、運(yùn)維彤断、底層大數(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ù)涛贯。
10. Standalone****模式下，Model.save(Path)怎么一直提示錯誤楚堤，是不是配置Spark時需要將Hdfs的配置引進(jìn)來啊～疫蔓？表示初學(xué)Spark
松子老師：這個問題有點(diǎn)超出我的能力范圍了，所以對不起回答不了身冬。
我本身不是做技術(shù)的衅胀。僅知道一點(diǎn)技術(shù)名詞。
11. ****傳統(tǒng)銀行業(yè)數(shù)據(jù)模型什么時候會走向互聯(lián)網(wǎng)模式呢酥筝？目前在傳統(tǒng)銀行數(shù)據(jù)平臺的產(chǎn)品是不是特別多滚躯？
松子老師：這個問題我自己就不知道了，或許是傳統(tǒng)銀行在數(shù)據(jù)平臺的實(shí)施上全面用互聯(lián)網(wǎng)的Nosql大數(shù)據(jù)處理技術(shù)吧嘿歌。至于說傳統(tǒng)銀行數(shù)據(jù)模型用現(xiàn)有的互聯(lián)網(wǎng)數(shù)據(jù)模型理念去設(shè)計(jì)是否完全可行掸掏，數(shù)據(jù)一致性、高準(zhǔn)確性通過更多的方案去保證宙帝。
首先我需要確定一下這個產(chǎn)品是否指的“數(shù)據(jù)產(chǎn)品”丧凤。
如果是數(shù)據(jù)產(chǎn)品，那其實(shí)傳統(tǒng)行業(yè)數(shù)據(jù)平臺本身就有一些數(shù)據(jù)產(chǎn)品了步脓，而且也都是存在的愿待。數(shù)據(jù)產(chǎn)品自從數(shù)據(jù)倉庫出現(xiàn)以來它其實(shí)一直都存在的浩螺，只不過是近幾年因?yàn)榛ヂ?lián)網(wǎng)特別愛制造“流行詞“把數(shù)據(jù)產(chǎn)品這個詞給放大了∪越模互聯(lián)網(wǎng)是得數(shù)據(jù)產(chǎn)品從早期的重量級逐漸進(jìn)化為輕量級要出、從大而全的解決方案逐漸演進(jìn)為因小而美。
我來給出幾組例子农渊，大約從2004年到現(xiàn)在的幾組數(shù)據(jù)產(chǎn)品的例子
(點(diǎn)擊放大圖像)
[圖片上傳中患蹂。。砸紊。（25）]
(點(diǎn)擊放大圖像)
[圖片上傳中传于。。批糟。（26）]
(點(diǎn)擊放大圖像)
[圖片上傳中格了。看铆。徽鼎。（27）]
(點(diǎn)擊放大圖像)
[圖片上傳中。弹惦。务嫡。（28）]
(點(diǎn)擊放大圖像)
[圖片上傳中来氧。。。（29）]
(點(diǎn)擊放大圖像)
[圖片上傳中淌山。。熬北。（30）]
(點(diǎn)擊放大圖像)
[圖片上傳中氓鄙。。嗡贺。（31）]
你可以分類一下隐解，這些數(shù)據(jù)產(chǎn)品的特點(diǎn)是什么？滿足了用戶怎么樣的痛點(diǎn)需求诫睬？滿足了用戶怎么樣的使用流程煞茫。
12 ****。傳統(tǒng)行業(yè)的數(shù)據(jù)倉庫從業(yè)人員摄凡，如果轉(zhuǎn)到互聯(lián)網(wǎng)行業(yè)续徽，應(yīng)該學(xué)習(xí)哪些技能？
松子老師：這個問題你可以百度搜索“大數(shù)據(jù)職位所需要的數(shù)據(jù)技能” http://blog.jobbole.com/99039/ 這篇文章亲澡。自己覺得人家回答的比我專業(yè)钦扭。//
我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史（四）：互聯(lián)網(wǎng)時代 ? 下篇
http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-internet-age
編者按：本文是松子（李博源）的大數(shù)據(jù)平臺發(fā)展史系列文章的第四篇（共四篇），本系列以獨(dú)特的視角床绪，比較了非互聯(lián)網(wǎng)和互聯(lián)網(wǎng)兩個時代以及傳統(tǒng)行業(yè)與非傳統(tǒng)行業(yè)客情。是對數(shù)據(jù)平臺發(fā)展的一個回憶捎琐，對非互聯(lián)網(wǎng)、互聯(lián)網(wǎng)裹匙，從數(shù)據(jù)平臺的用戶角度瑞凑、數(shù)據(jù)架構(gòu)演進(jìn)、模型等進(jìn)行了闡述概页。
在互聯(lián)網(wǎng)時代被弱化的數(shù)據(jù)模型
談起數(shù)據(jù)模型就不得不提傳統(tǒng)數(shù)據(jù)平臺架構(gòu)發(fā)展籽御，我相信很多朋友都曉得傳統(tǒng)數(shù)據(jù)平臺的知識，其架構(gòu)演進(jìn)簡單一句話說“基本上可以分為五個時代惰匙、四種架構(gòu)”技掏，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與數(shù)據(jù)源類型多樣化特點(diǎn)，從高階架構(gòu)上來看大約從傳統(tǒng)數(shù)據(jù)平臺第三代架構(gòu)開始延續(xù)的项鬼，但是往后的發(fā)展從我自己的這一點(diǎn)知識上很難對互聯(lián)網(wǎng)的數(shù)據(jù)平臺做架構(gòu)歸類哑梳。
但是從數(shù)據(jù)平臺建設(shè)與服務(wù)角色上還是有章可循的。就像上篇分享到那樣绘盟，類比兩個行業(yè)鸠真，互聯(lián)網(wǎng)企業(yè)中員工年齡比非互聯(lián)網(wǎng)企業(yè)的要年輕、受教育程度龄毡、對計(jì)算機(jī)的焦慮程度明顯比傳統(tǒng)企業(yè)要低吠卷、還偶遇其它各方面的緣故，導(dǎo)致了數(shù)據(jù)平臺所面對用戶群體與非互聯(lián)網(wǎng)數(shù)據(jù)平臺有所差異化沦零。
傳統(tǒng)行業(yè)與互聯(lián)網(wǎng)行業(yè)數(shù)據(jù)平臺用戶特性我只選擇前文章的兩張圖來表示
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
在傳統(tǒng)數(shù)據(jù)平臺要背后有一個完整數(shù)據(jù)倉庫團(tuán)隊(duì)去服務(wù)業(yè)務(wù)方祭隔，業(yè)務(wù)方嗷嗷待哺的等待被動方式去滿足。中低層數(shù)據(jù)基本不會對業(yè)務(wù)方開放路操，所以不管數(shù)據(jù)模型采用何種建模方式疾渴，主要滿足當(dāng)時數(shù)據(jù)架構(gòu)規(guī)劃即可。
互聯(lián)網(wǎng)業(yè)務(wù)的快速發(fā)展使得大家已經(jīng)從經(jīng)營屯仗、分析的訴求重點(diǎn)轉(zhuǎn)為數(shù)據(jù)化的精細(xì)運(yùn)營上搞坝，如何做好精細(xì)化運(yùn)營問題上來，當(dāng)資源不夠時用戶就叫喊祭钉，甚至有的業(yè)務(wù)方會挽起袖子來自己參與到從數(shù)據(jù)整理瞄沙、加工、分析階段慌核。
此時呢距境，原有建設(shè)數(shù)據(jù)平臺的多個角色（數(shù)據(jù)開發(fā)鞭衩、模型設(shè)計(jì)）可能轉(zhuǎn)為對其它非專業(yè)使用數(shù)據(jù)方腹备，做培訓(xùn)、咨詢與落地专控，寫更加適合當(dāng)前企業(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àn)椴粚I(yè)性，導(dǎo)致數(shù)據(jù)質(zhì)量問題疼鸟、重復(fù)對分?jǐn)?shù)據(jù)浪費(fèi)存儲與資源后控、口徑多樣化、編碼不統(tǒng)一空镜、命名問題等等原因浩淘。數(shù)據(jù)質(zhì)量逐漸變成一個特別突出的問題。
傳統(tǒng)企業(yè)的數(shù)據(jù)源基本來自excel吴攒、表格张抄、DB系統(tǒng)等，但在互聯(lián)網(wǎng)有網(wǎng)站點(diǎn)擊流日志洼怔、視頻署惯、音頻、圖片數(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ù)有些力不從心。
當(dāng)數(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è)也有自己特點(diǎn)束倍，傳統(tǒng)行業(yè)所涉及數(shù)據(jù)模型這個領(lǐng)域涉及的很多內(nèi)容在互聯(lián)網(wǎng)變成以其他的曲線救國的方式存在了。
在互聯(lián)網(wǎng)曲線救國新解決
回顧在傳統(tǒng)行業(yè)數(shù)據(jù)平臺中盟戏，不管兩位大師爭論點(diǎn)數(shù)據(jù)模型的設(shè)計(jì)采用那種范式（Bill Inmon的EDW的原則是準(zhǔn)三范式的設(shè)計(jì)绪妹、Ralph kilmbal是星型結(jié)構(gòu)）但是都要非常重視數(shù)據(jù)源的質(zhì)量問題。所以傳統(tǒng)行業(yè)的數(shù)據(jù)模型會全盤考慮數(shù)據(jù)質(zhì)量問題柿究，并通過數(shù)據(jù)抽樣分析給出合適的清洗口徑邮旷。
(點(diǎn)擊放大圖像)
上圖來自我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ù)”對一年的還是不準(zhǔn)的）。在應(yīng)對數(shù)據(jù)的質(zhì)量問題律歼，目前互聯(lián)網(wǎng)有些做法是把數(shù)據(jù)標(biāo)準(zhǔn)化前置到業(yè)務(wù)數(shù)據(jù)產(chǎn)生就做民镜，從根源上去杜絕數(shù)據(jù)質(zhì)量，但是這種場景比較實(shí)用在Log 日志的數(shù)據(jù)源中险毁，比如移動互聯(lián)網(wǎng)最近流行的基于事件模型“Event”模型殃恒，在日志產(chǎn)生時就規(guī)定好存儲格式（備注：大家度娘搜索，“學(xué)習(xí)筆記：The Log（我所讀過的最好的一篇分布式技術(shù)文章）” 對這個講解很詳細(xì)）辱揭。
在傳統(tǒng)行業(yè)离唐，目前還是以混合模型設(shè)計(jì)方式為主。在互聯(lián)網(wǎng)的我所接觸的一些業(yè)務(wù)问窃，在參照傳統(tǒng)數(shù)據(jù)模型方法論基礎(chǔ)上逐步演進(jìn)適合互聯(lián)網(wǎng)數(shù)據(jù)的數(shù)據(jù)模型方法既棺。
比如互聯(lián)網(wǎng)金融等一些業(yè)務(wù)會參考傳統(tǒng)金融行業(yè)對主題域的劃分、OMG數(shù)據(jù)倉庫元數(shù)據(jù)管理CWM模型绞幌、FSDM金融模型疾掰，再進(jìn)一步考慮大數(shù)據(jù)處理特性去進(jìn)行設(shè)計(jì)，所有從Hight Level 數(shù)據(jù)架構(gòu)圖看到主題層次劃分與傳統(tǒng)第三代數(shù)據(jù)倉庫還是很多相似之處听皿，當(dāng)然模型架構(gòu)也有分三層熟呛、四層、五層的尉姨。
不同的地方模型細(xì)節(jié)處理上已經(jīng)完全不一樣庵朝，比如數(shù)據(jù)的多樣性、拉寬事實(shí)表又厉、度量值單獨(dú)存儲九府、滿足數(shù)據(jù)快速重生、維度的二次降維處理等覆致、增加大量冗余列侄旬、增加大量派生列，結(jié)合自動化元數(shù)據(jù)來耦合煌妈、合并等相關(guān)管理儡羔。
(點(diǎn)擊放大圖像)
[圖片上傳中。璧诵。汰蜘。（4）]
上圖是支付寶非常早期數(shù)據(jù)模型
(點(diǎn)擊放大圖像)
上圖是支付寶非常早期數(shù)據(jù)模型
我們常提到的多維模型在大數(shù)據(jù)處理下進(jìn)行了退化維度處理。大家知道Olap多維模型腮猖，隨著維度的增加事實(shí)表的數(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è)計(jì)多維挖掘分析數(shù)據(jù)產(chǎn)品背后的技術(shù)就是搜索引擎實(shí)現(xiàn)的）坪创，現(xiàn)在應(yīng)該也有新技術(shù)出現(xiàn)了來解決類似的問題炕婶。
(點(diǎn)擊放大圖像)
上圖為2012年產(chǎn)品UI之一。
(點(diǎn)擊放大圖像)
[圖片上傳中莱预。柠掂。。（7）]
上圖是2011-2012年該產(chǎn)品系列背后當(dāng)時使用的技術(shù)
互聯(lián)網(wǎng)業(yè)務(wù)特點(diǎn)業(yè)務(wù)垂直拆分非常細(xì)依沮，比如一個用戶注冊涯贞、密碼找回的流程有可能存在好幾個產(chǎn)品負(fù)責(zé)同一個業(yè)務(wù)流程不同環(huán)節(jié)，相關(guān)的一個策略危喉、產(chǎn)品feature快速迭代上線等等都要數(shù)據(jù)評估宋渔。數(shù)據(jù)從前端埋點(diǎn)到采集然后再由各個環(huán)節(jié)到數(shù)據(jù)平臺，再有數(shù)據(jù)分析師或各業(yè)務(wù)部門去使用辜限，基本拉長了時間周期皇拣。需求部門與實(shí)施部門能力和經(jīng)驗(yàn)有千差萬別的需求，造成了懂技術(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ù)特點(diǎn)是變化非常迅速的钉寝，能穩(wěn)定的業(yè)務(wù)達(dá)到65%算對數(shù)據(jù)平臺是個福音了（根據(jù)對某寶寶的印象）剩余的業(yè)務(wù)變化迅速，必然導(dǎo)致數(shù)據(jù)模型快速上下線鸳址。
Kimball老人家提出的維度建模（備注瘩蚪，在本系列發(fā)展史得第一篇有介紹）圍繞業(yè)務(wù)模型能夠非常直觀的表達(dá)出業(yè)務(wù)的數(shù)據(jù)關(guān)系，但是在互聯(lián)網(wǎng)NOSQL犧牲掉了關(guān)系型數(shù)據(jù)庫的一致性稿黍、完整性等等很多東西。維度數(shù)據(jù)模型又基于這些大數(shù)據(jù)技術(shù)的崩哩，所以進(jìn)化的更加輕量級與基于細(xì)節(jié)數(shù)據(jù)的維度退化建模（原有的緩慢變化維弃衍、快速變化維昼接、大維、迷你維、父子維论笔、雪花維為了適應(yīng)互聯(lián)網(wǎng)的大數(shù)據(jù)Nosql處理技術(shù)進(jìn)行反規(guī)范化、化&數(shù)據(jù)冗余設(shè)計(jì)缘回。
退化維度的反規(guī)范化設(shè)計(jì)一方面可以把一條查詢語句所需要的所有數(shù)據(jù)組合起來放到一個地方存儲 Key values 的方式（比如說商品有不同類型猛们，每一種類型商品又有自己的不同屬性，可以采用一對多棚贾、多對多的方式存儲窖维，例如把一個多維映射為一個Key value）榆综。
講到互聯(lián)網(wǎng)數(shù)據(jù)平臺就要提數(shù)據(jù)模型，提了數(shù)據(jù)模型就要提Nosql技術(shù)铸史，
(點(diǎn)擊放大圖像)
上圖來自Nosql文檔系列的一幅圖
Nosql 是大數(shù)據(jù)處理的特征之一鼻疮。互聯(lián)網(wǎng)數(shù)據(jù)平臺數(shù)據(jù)模型與NoSql技術(shù)還是蠻緊密的琳轿。這里有外文講解Nosql Data modeling technigues 從技術(shù)角度講解非常詳（https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/）判沟。
因?yàn)榍斑吿岬降拇髷?shù)據(jù)平臺技術(shù)特性決定了傳統(tǒng)edw模型、維度模型直接在互聯(lián)網(wǎng)數(shù)據(jù)大數(shù)據(jù)平臺部署或許還有“好些未知”障礙等待大家去克服崭篡。同時在傳統(tǒng)數(shù)據(jù)建模用到的一些方法經(jīng)過互聯(lián)網(wǎng)熏陶或許演進(jìn)成一種新的數(shù)據(jù)產(chǎn)品或方案吧挪哄。
到此為止“我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史”上下共四篇與大家分享完畢，這個寫作前后經(jīng)歷剛好一個月左右琉闪，算是對自己數(shù)據(jù)從業(yè)經(jīng)歷回顧之一吧迹炼。在知識的整理中很多都是蜻蜓點(diǎn)水，每個知識域都是一個非常深的專業(yè)方向塘偎，自己涉足很膚淺疗涉，在文章中分享不足之處請各位讀者見諒！吟秩！
個人郵箱是5592094@qq.com 歡迎電郵交流咱扣。
接下來我會進(jìn)入數(shù)據(jù)產(chǎn)品這個領(lǐng)域的分享，當(dāng)年車品覺老師自豪的作品之一“黃金策”涵防，我是數(shù)據(jù)產(chǎn)品經(jīng)理闹伪。（ps：自己躲在墻角拿車品覺老師往自己臉上貼金了）。
后記
有一次數(shù)據(jù)產(chǎn)品神策的創(chuàng)始人兼好友@桑文鋒＠SensorsData跟我說來做次分享吧壮池，我當(dāng)時出了幾個題目偏瓤，最后就選擇了“我所經(jīng)歷的大數(shù)據(jù)平臺“，就形成了大家看到的”我所經(jīng)歷的大數(shù)據(jù)平臺“系列文章.
在整理期間得到了死黨@周愛民椰憋、@神策-桑文峰厅克、 InfoQ小編@Tina Du 、@betty zhou @Laurel大力協(xié)助橙依，在這里感謝Ｖぶ邸！窗骑！
番外篇
這一篇是在24日舉行的分享大家提到的一些問題女责，經(jīng)過整理算是對正文的補(bǔ)充吧，從互聯(lián)網(wǎng)敏捷數(shù)據(jù)模型等角度做了較深入的細(xì)節(jié)介紹创译。同時在數(shù)據(jù)產(chǎn)品方面的回答包含了一點(diǎn)未來寫作篇“數(shù)據(jù)產(chǎn)品”系列的一點(diǎn)內(nèi)容抵知。
1****，傳統(tǒng)我們做BI的，做數(shù)據(jù)展現(xiàn)會建模后以pivot展現(xiàn)cube數(shù)據(jù)刷喜，不知道現(xiàn)在互聯(lián)網(wǎng)公司數(shù)據(jù)展示如何做的残制？第三方工具還是用API取數(shù)據(jù)平臺里的數(shù)據(jù)？adhoc報(bào)表及靈活更換維度的時候web端一般是怎么做的吱肌？
松子老師：剛才文章中提到了比如傳統(tǒng)行業(yè)的多維數(shù)據(jù)模型cube痘拆。在互聯(lián)網(wǎng)采用的曲線救國方式解決的。 在分享中我給出了幾個圖氮墨。就是通過搜索引擎曲線救國方式實(shí)現(xiàn)類似Olap的模擬纺蛆。
在這塊的模型的處理上采用的是維度退化處理币旧。通過反規(guī)范化渴逻，數(shù)據(jù)項(xiàng)、數(shù)據(jù)冗余去處理瓣蛀。在前端做特殊處理猛铅。
這個當(dāng)時產(chǎn)品原型之一：
(點(diǎn)擊放大圖像)
這是一個2011年-2012年左右的數(shù)據(jù)產(chǎn)品字支，當(dāng)時算是即時計(jì)算的一種。不過已經(jīng)過去好幾年了奸忽，當(dāng)今新技術(shù)下Olap 引擎應(yīng)該有很好的提升堕伪。
目前我知道的家互聯(lián)網(wǎng)公司，在前端展現(xiàn)有使用第三方套件比如spagoBi栗菜、pentaho 等 有自己設(shè)計(jì)開發(fā)定制化數(shù)據(jù)前端展現(xiàn)欠雌。比如我剛開始分享的那兩個之前在去哪兒網(wǎng)設(shè)計(jì)的數(shù)據(jù)平臺內(nèi)部界面之一，當(dāng)然數(shù)據(jù)產(chǎn)品是另一個話題了疙筹，通過對數(shù)據(jù)分析抽象指標(biāo)富俄、分析模型、用戶使用功能與流程而咆、未來規(guī)劃考慮用戶體驗(yàn)去設(shè)計(jì)霍比。
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
[圖片上傳中。暴备。悠瞬。（11）]
(點(diǎn)擊放大圖像)
2****，互聯(lián)網(wǎng)財(cái)經(jīng)類公司涯捻，業(yè)務(wù)包括財(cái)經(jīng)網(wǎng)站阁危、基金、股票汰瘫、金融等，這類公司的數(shù)據(jù)倉庫模型應(yīng)該如何設(shè)計(jì)擂煞？特點(diǎn)和注意事項(xiàng)是什么混弥？案例介紹？十分感謝。
松子老師：我自己經(jīng)歷過的是互聯(lián)網(wǎng)金融以及移動互聯(lián)網(wǎng)行蝗拿。對這兩塊比較清楚晾捏。互聯(lián)網(wǎng)金融起因?yàn)闃I(yè)務(wù)的特性是類金融類的哀托，與銀行有些地方是相似的惦辛。
比如大約在2012年前支付寶業(yè)務(wù)特點(diǎn)涉及類金融交易：充值、提現(xiàn)仓手、賬務(wù)管理類電子商務(wù)：購物交易過程變更胖齐、實(shí)際交易（對B機(jī)票、對C水電等） 非純電子商務(wù)嗽冒；純金融呀伙；個人信用，理財(cái)類添坊。系統(tǒng)之間依賴度較為復(fù)雜剿另，垂直依賴（業(yè)務(wù)與核心）跨層依賴（跨過交易到賬務(wù)）。
在設(shè)計(jì)方法上還是采用維度模型設(shè)計(jì)方式贬蛙。底層是數(shù)據(jù)驅(qū)動為向?qū)в昱Y(jié)合業(yè)務(wù)需求驅(qū)動，通過簡單阳准、退化維度的方式拉寬表結(jié)構(gòu)氛堕。
底層采用松耦合設(shè)計(jì)。主題之間是松耦合方式溺职。至體內(nèi)采用細(xì)粒度退化維度岔擂。
在主題域上的的設(shè)計(jì)基本參考了OMG的數(shù)據(jù)倉庫元數(shù)據(jù)設(shè)計(jì)CWM模型、IBM 的fsdm金融模型浪耘、還有新巴塞爾資本協(xié)議（Basel II Capital Accord）需提供數(shù)據(jù)規(guī)范去的設(shè)計(jì)乱灵。所以數(shù)據(jù)模型是五層的結(jié)構(gòu)辟汰。
在細(xì)節(jié)處理上旗们，增量ODS層數(shù)據(jù)和前一天DWD相關(guān)表進(jìn)行 merge處理。
在一些層次上耸峭，基本聚合澜躺、匯總增加派生事實(shí)表（簡單一句話退化為度打?qū)挘┎跷取Ｈ缓蟀凑諛I(yè)務(wù)主體合并信息等。
比如開始給大家分享的那張圖：
(點(diǎn)擊放大圖像)
[圖片上傳中掘鄙。耘戚。。（13）]
在維度模型退化處理時操漠，要注意最細(xì)粒度數(shù)據(jù)保留收津、不同層次的數(shù)據(jù)支持?jǐn)?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ù)模型吻贿。
這種元數(shù)據(jù)驅(qū)動工具型數(shù)據(jù)產(chǎn)品我會在未來數(shù)據(jù)產(chǎn)品系列中做詳細(xì)介紹的串结。
3****，互聯(lián)網(wǎng)企業(yè)大數(shù)據(jù)平臺的發(fā)展歷程是怎樣的舅列？
松子老師：這個我相信應(yīng)該是傳統(tǒng)數(shù)據(jù)平臺朋友提到的肌割。傳統(tǒng)行業(yè)數(shù)據(jù)平臺架構(gòu)演進(jìn)我總結(jié)簡單一句話說“基本上可以分為五個時代、四種架構(gòu)”剧蹂，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與類型暴增的特點(diǎn)声功，從高階架構(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é)下來用戶特點(diǎn)：
(點(diǎn)擊放大圖像)
[圖片上傳中伸蚯。。简烤。（14）]
更加詳細(xì)的每一代數(shù)據(jù)平臺建設(shè)剂邮、服務(wù)角色特點(diǎn)您可以看我這個系列文章的第三篇，http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-paet02
4****横侦，有沒有好的元數(shù)據(jù)管理工具推薦挥萌？主要偏向數(shù)據(jù)字典與血統(tǒng)等。
松子老師：元數(shù)據(jù)以前目前沒有太多的好管理工具枉侧。以前是在支付寶是我自己設(shè)計(jì)的一個數(shù)據(jù)產(chǎn)品引瀑。第一版自己用Delphi 開發(fā)的。
（圖很多：）
(點(diǎn)擊放大圖像)
[圖片上傳中榨馁。憨栽。。（15）]
(點(diǎn)擊放大圖像)
[圖片上傳中翼虫。屑柔。。（16）]
(點(diǎn)擊放大圖像)
[圖片上傳中珍剑。掸宛。。（17）]
(點(diǎn)擊放大圖像)
[圖片上傳中招拙。旁涤。翔曲。（18）]
(點(diǎn)擊放大圖像)
[圖片上傳中。劈愚。。（19）]
以前被逼的自己寫了一個闻妓，通過解析菌羽，實(shí)現(xiàn)了字段級的血緣影響分析乖坠。這只是第二步萄喳，后來又把running 信息給搞了進(jìn)來检碗。還有分享時提到的模型信息邓了、整個閉環(huán)的分類信息助被。
這是一個分支：
(點(diǎn)擊放大圖像)
[圖片上傳中钧大。竟稳。健蕊。（20）]
但是我們實(shí)現(xiàn)了字段級解析準(zhǔn)確率達(dá)到了94%左右舔箭。有細(xì)微的錯誤就人工revew一遍罩缴。
5. ****松子老師，數(shù)據(jù)管控的數(shù)據(jù)質(zhì)量部分是怎么處理的呢层扶？
松子老師： 數(shù)據(jù)管控箫章， 這方面我不太懂的，但是數(shù)據(jù)質(zhì)量镜会，這玩意可大可小的檬寂。比如像在分享時說過的，在移動互聯(lián)網(wǎng)的數(shù)據(jù)質(zhì)量處理方式可以由原有的ETL(ELT)階段前置到業(yè)務(wù)系統(tǒng)去解決戳表，比如移動互聯(lián)網(wǎng)的App log 日志桶至，日志標(biāo)準(zhǔn)化后事件模型”存儲來解決。那非app 日志類如何解決呢比如Payment匾旭、order等镣屹，數(shù)據(jù)質(zhì)量比較考慮的可以只做到監(jiān)控。
我來分享個圖季率。剛好是我設(shè)計(jì)數(shù)據(jù)質(zhì)量產(chǎn)品時搞的野瘦，理清數(shù)據(jù)質(zhì)量的問題：
(點(diǎn)擊放大圖像)
[圖片上傳中。飒泻。鞭光。（21）]
(點(diǎn)擊放大圖像)
[圖片上傳中。泞遗。惰许。（22）]
(點(diǎn)擊放大圖像)
[圖片上傳中。史辙。汹买。（23）]
只要數(shù)據(jù)進(jìn)入倉庫與應(yīng)用體系佩伤，處理起來就比較困難了，所以在數(shù)據(jù)平臺階段最好是通過監(jiān)控晦毙、前置去解決生巡。目前數(shù)據(jù)質(zhì)量確實(shí)難以100%由事后搞到事前去處理。我對數(shù)據(jù)平臺與數(shù)據(jù)產(chǎn)品的建設(shè)就是實(shí)用為主见妒。怎么實(shí)用怎么來孤荣。我是比較現(xiàn)實(shí)的實(shí)用主義者。
6. ****能否分享一些數(shù)據(jù)產(chǎn)品種類及實(shí)例：
松子老師：在前邊五個問題须揣、以及文章中又都涉及數(shù)據(jù)產(chǎn)品實(shí)力的一些分享盐股。
提到數(shù)據(jù)產(chǎn)品的分類我就想把這個圖發(fā)出來。
自己認(rèn)為沒有特別明確的劃分線耻卡，但是數(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工具塑煎、資源管控等等沫换。
面向用戶功能有報(bào)表型岁诉、多維型數(shù)據(jù)產(chǎn)品请唱、定制化數(shù)據(jù)產(chǎn)品、挖掘型數(shù)據(jù)產(chǎn)品诉瓦。
面向內(nèi)部用戶冷尉、外部個人用戶漱挎、外部企業(yè)用戶又有不同的分類。
根據(jù)業(yè)務(wù)又可以劃分很多雀哨，面向C類用戶磕谅、面向B類商戶、金融風(fēng)險(xiǎn)等等
從近幾年的數(shù)據(jù)產(chǎn)品來看雾棺，是更好的輔助用戶的做決策的一種產(chǎn)品形態(tài)膊夹，在用戶的決策與行動中充當(dāng)信息的分析者與價值使用者；數(shù)據(jù)產(chǎn)品有個自己的共性：由解決的一個實(shí)際的業(yè)務(wù)問題出發(fā)捌浩，分解出的分析指標(biāo)放刨，分析模型，分析流程組成尸饺，再考慮到功能易用性进统，未來功能擴(kuò)展助币，考慮用戶對數(shù)據(jù)易用性（比如數(shù)據(jù)的呈現(xiàn)層次，不可能一次把所有數(shù)據(jù)的呈現(xiàn)給用戶）來組成的螟碎。
(點(diǎn)擊放大圖像)
[圖片上傳中眉菱。。抚芦。（24）]
7. ****銀行業(yè)從傳統(tǒng)的ods到edw再到大數(shù)據(jù)平臺這塊過渡倍谜，模型如何建設(shè)？平臺優(yōu)勢如何發(fā)揮叉抡？
松子老師：這個問題還是有些難度的，自己回答的可能有些片面答毫。首先我們清醒的清楚“大數(shù)據(jù)”是什么褥民？再次不同的場景可以采用不同的技術(shù)去解決。
“大數(shù)據(jù)”洗搂，拆開來看大消返、數(shù)據(jù)，大可以是指的數(shù)據(jù)源結(jié)構(gòu)簡單（ps 如果了解過當(dāng)代對大數(shù)據(jù)的定義就知道四個特性）但是量級夠大耘拇，比如清算撵颊、結(jié)算、對公惫叛、對私倡勇、中間業(yè)務(wù)等等每一個拿出來都是幾十T，但是這些業(yè)務(wù)數(shù)據(jù)都是保存?zhèn)鹘y(tǒng)的關(guān)系型數(shù)據(jù)庫中如DB2嘉涌、Oracle妻熊、MSsql中，因?yàn)樵跀?shù)據(jù)平臺存儲是通過準(zhǔn)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ù)的去演進(jìn)解決。（最早時我的是中信銀行预皇、光大銀行在2011年左右開始考慮Hadoop技術(shù)侈玄，后來不知道如何了）。
但是互聯(lián)網(wǎng)的數(shù)據(jù)平臺技術(shù)大都是NOSQL模式深啤，犧牲掉了傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)一致性拗馒、完整性、唯一索引等等溯街，只干性能的事情（當(dāng)然除了性能诱桂、可擴(kuò)展性也是的）.
原有在傳統(tǒng)數(shù)據(jù)平臺模型設(shè)計(jì)上可以考慮的一些通過主外鍵洋丐、唯一索引做一些業(yè)務(wù)約束的方法告嘲，在nosql上統(tǒng)統(tǒng)的都沒有了廓握，這些約束必須放到數(shù)據(jù)加工階段去想辦法做檢查疼燥。傳統(tǒng)數(shù)據(jù)平臺如果在Insert标锄、update數(shù)據(jù)時違反了業(yè)務(wù)約束可以做報(bào)警或異常處理挚赊，但是在Nosql的平臺上要求ETL 去手動遵守這些規(guī)則檢查突雪。但是有時ETL開發(fā)根本不遵守的交播，僅僅是兩個表關(guān)聯(lián)起來摔敛，也可能忘記按照某一個業(yè)務(wù)唯一索引做去重操作辞槐。簡單說掷漱，原有靠關(guān)系型數(shù)據(jù)庫本身機(jī)制去做檢查一些規(guī)則變?yōu)槿斯ぃ優(yōu)槿斯ぞ蜁稿e榄檬。
從關(guān)系型數(shù)據(jù)平臺往Nosql數(shù)據(jù)平臺遷移時卜范，尤其是對傳統(tǒng)行業(yè)的業(yè)務(wù)來說，在模型設(shè)計(jì)階段鹿榜、以及給出的ETL口徑要考慮更多的業(yè)務(wù)規(guī)則檢查海雪，其次要考慮更多的維度退化、多冗余舱殿、表打?qū)捥幚戆侣恪：唵握f就是發(fā)揮數(shù)據(jù)平臺的計(jì)算能力同時要更加的各方面確保數(shù)據(jù)準(zhǔn)確安全可靠。
數(shù)據(jù)模型ODS 到EDW 這塊的設(shè)計(jì)方法百度上留下的文檔資料太多的了沪袭，請這位提問的老師百度吧湾宙。
**8****．大數(shù)據(jù)****倉庫****中如何做快速****維處****理？互****聯(lián)****網(wǎng)數(shù)****倉****數(shù)據(jù)****質(zhì)****量不好如何****對****數(shù)枝恋，如何確立****標(biāo)****準(zhǔn)的****對****數(shù)口徑创倔？******
松子老師：快速變化維度可以轉(zhuǎn)化為緩慢變化為來出來，我自己理解的快速維度是相對于緩慢維度參照的來說的焚碌。
舉個例子畦攘，年齡-轉(zhuǎn)化為天數(shù)可以是定義快速變化維度，因?yàn)槊刻於荚谧兓纭Ｎ覀兛梢园涯挲g退化為區(qū)間維度來處理知押，還可以把年齡做成動態(tài)維度來處理，事實(shí)表中保存的就是實(shí)際的出生年月并打?qū)挶砭槁睿挲g(天)通過計(jì)算方式來處理台盯。還有種方法通過對代理鍵的方式來處理。
我目前也不知道對數(shù)據(jù)的標(biāo)準(zhǔn)是什么畏线。但是我自己用的方法静盅，把一個指標(biāo)的整個數(shù)據(jù)流向切出幾個關(guān)鍵點(diǎn)通過SQL去實(shí)現(xiàn)對數(shù)，看波動振幅寝殴，波動曲線蒿叠。同時還會比如發(fā)不通的版本的小流量測試的方式來做數(shù)據(jù)校對明垢。
9****． 做為數(shù)據(jù)行業(yè)從業(yè)者，需要掌握哪些重要的基礎(chǔ)知識市咽？另：如果從零開始建立一個數(shù)據(jù)平臺痊银，需要哪些資源配置（人，財(cái)施绎，物溯革，技術(shù)）？大致總投資額度多少谷醉？如果同行產(chǎn)品間多種來源的數(shù)據(jù)致稀，可有成熟的解決方案？謝謝…
松子老師：這個問題太宏觀了俱尼。作為數(shù)據(jù)行業(yè)從業(yè)者豺裆，需要掌握哪些重要基礎(chǔ)知識，這個是要看從事具體數(shù)據(jù)域的垂直行業(yè)号显。
比如說 數(shù)據(jù)開發(fā)、數(shù)據(jù)模型也榄、數(shù)據(jù)產(chǎn)品戈次、數(shù)據(jù)分析師染坯、數(shù)據(jù)運(yùn)營、數(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ù)目標(biāo)不太明確下，難以確定方案供汛，人員配置上選用不同技術(shù)方案去搭建的配置是不太一樣的枪汪，比如說傳統(tǒng)平臺來講，運(yùn)維怔昨、DBA雀久、數(shù)據(jù)開發(fā)、數(shù)據(jù)模型趁舀、報(bào)表人員赖捌。
從互聯(lián)網(wǎng)數(shù)據(jù)平臺基本配置上，數(shù)據(jù)架構(gòu)師矮烹、運(yùn)維越庇、底層大數(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ù)悦析。
10. Standalone****模式下寿桨，Model.save(Path)怎么一直提示錯誤，是不是配置Spark時需要將Hdfs的配置引進(jìn)來啊～强戴？表示初學(xué)Spark
松子老師：這個問題有點(diǎn)超出我的能力范圍了亭螟，所以對不起回答不了。
我本身不是做技術(shù)的骑歹。僅知道一點(diǎn)技術(shù)名詞预烙。
11. ****傳統(tǒng)銀行業(yè)數(shù)據(jù)模型什么時候會走向互聯(lián)網(wǎng)模式呢？目前在傳統(tǒng)銀行數(shù)據(jù)平臺的產(chǎn)品是不是特別多道媚？
松子老師：這個問題我自己就不知道了扁掸，或許是傳統(tǒng)銀行在數(shù)據(jù)平臺的實(shí)施上全面用互聯(lián)網(wǎng)的Nosql大數(shù)據(jù)處理技術(shù)吧。至于說傳統(tǒng)銀行數(shù)據(jù)模型用現(xiàn)有的互聯(lián)網(wǎng)數(shù)據(jù)模型理念去設(shè)計(jì)是否完全可行最域，數(shù)據(jù)一致性谴分、高準(zhǔn)確性通過更多的方案去保證。
首先我需要確定一下這個產(chǎn)品是否指的“數(shù)據(jù)產(chǎn)品”镀脂。
如果是數(shù)據(jù)產(chǎn)品牺蹄，那其實(shí)傳統(tǒng)行業(yè)數(shù)據(jù)平臺本身就有一些數(shù)據(jù)產(chǎn)品了，而且也都是存在的狗热。數(shù)據(jù)產(chǎn)品自從數(shù)據(jù)倉庫出現(xiàn)以來它其實(shí)一直都存在的钞馁，只不過是近幾年因?yàn)榛ヂ?lián)網(wǎng)特別愛制造“流行詞“把數(shù)據(jù)產(chǎn)品這個詞給放大了∧涔危互聯(lián)網(wǎng)是得數(shù)據(jù)產(chǎn)品從早期的重量級逐漸進(jìn)化為輕量級僧凰、從大而全的解決方案逐漸演進(jìn)為因小而美。
我來給出幾組例子熟丸，大約從2004年到現(xiàn)在的幾組數(shù)據(jù)產(chǎn)品的例子
(點(diǎn)擊放大圖像)
[圖片上傳中教寂。老翘。顷帖。（25）]
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
[圖片上傳中。怀大。。（27）]
(點(diǎn)擊放大圖像)
[圖片上傳中呀闻。化借。。（28）]
(點(diǎn)擊放大圖像)
[圖片上傳中捡多。蓖康。。（29）]
(點(diǎn)擊放大圖像)
[圖片上傳中垒手。蒜焊。。（30）]
(點(diǎn)擊放大圖像)
[圖片上傳中科贬。泳梆。。（31）]
你可以分類一下榜掌，這些數(shù)據(jù)產(chǎn)品的特點(diǎn)是什么优妙？滿足了用戶怎么樣的痛點(diǎn)需求？滿足了用戶怎么樣的使用流程憎账。
12 ****鳞溉。傳統(tǒng)行業(yè)的數(shù)據(jù)倉庫從業(yè)人員，如果轉(zhuǎn)到互聯(lián)網(wǎng)行業(yè)鼠哥，應(yīng)該學(xué)習(xí)哪些技能？
松子老師：這個問題你可以百度搜索“大數(shù)據(jù)職位所需要的數(shù)據(jù)技能” http://blog.jobbole.com/99039/ 這篇文章看政。自己覺得人家回答的比我專業(yè)朴恳。//
我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史（四）：互聯(lián)網(wǎng)時代 ? 下篇
http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-internet-age
編者按：本文是松子（李博源）的大數(shù)據(jù)平臺發(fā)展史系列文章的第四篇（共四篇），本系列以獨(dú)特的視角允蚣，比較了非互聯(lián)網(wǎng)和互聯(lián)網(wǎng)兩個時代以及傳統(tǒng)行業(yè)與非傳統(tǒng)行業(yè)于颖。是對數(shù)據(jù)平臺發(fā)展的一個回憶，對非互聯(lián)網(wǎng)嚷兔、互聯(lián)網(wǎng)森渐，從數(shù)據(jù)平臺的用戶角度、數(shù)據(jù)架構(gòu)演進(jìn)冒晰、模型等進(jìn)行了闡述同衣。
在互聯(lián)網(wǎng)時代被弱化的數(shù)據(jù)模型
談起數(shù)據(jù)模型就不得不提傳統(tǒng)數(shù)據(jù)平臺架構(gòu)發(fā)展，我相信很多朋友都曉得傳統(tǒng)數(shù)據(jù)平臺的知識壶运，其架構(gòu)演進(jìn)簡單一句話說“基本上可以分為五個時代耐齐、四種架構(gòu)”，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與數(shù)據(jù)源類型多樣化特點(diǎn)，從高階架構(gòu)上來看大約從傳統(tǒng)數(shù)據(jù)平臺第三代架構(gòu)開始延續(xù)的埠况，但是往后的發(fā)展從我自己的這一點(diǎn)知識上很難對互聯(lián)網(wǎng)的數(shù)據(jù)平臺做架構(gòu)歸類耸携。
但是從數(shù)據(jù)平臺建設(shè)與服務(wù)角色上還是有章可循的。就像上篇分享到那樣辕翰，類比兩個行業(yè)夺衍，互聯(lián)網(wǎng)企業(yè)中員工年齡比非互聯(lián)網(wǎng)企業(yè)的要年輕、受教育程度喜命、對計(jì)算機(jī)的焦慮程度明顯比傳統(tǒng)企業(yè)要低沟沙、還偶遇其它各方面的緣故，導(dǎo)致了數(shù)據(jù)平臺所面對用戶群體與非互聯(lián)網(wǎng)數(shù)據(jù)平臺有所差異化渊抄。
傳統(tǒng)行業(yè)與互聯(lián)網(wǎng)行業(yè)數(shù)據(jù)平臺用戶特性我只選擇前文章的兩張圖來表示
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
在傳統(tǒng)數(shù)據(jù)平臺要背后有一個完整數(shù)據(jù)倉庫團(tuán)隊(duì)去服務(wù)業(yè)務(wù)方尝胆，業(yè)務(wù)方嗷嗷待哺的等待被動方式去滿足。中低層數(shù)據(jù)基本不會對業(yè)務(wù)方開放护桦，所以不管數(shù)據(jù)模型采用何種建模方式含衔，主要滿足當(dāng)時數(shù)據(jù)架構(gòu)規(guī)劃即可。
互聯(lián)網(wǎng)業(yè)務(wù)的快速發(fā)展使得大家已經(jīng)從經(jīng)營二庵、分析的訴求重點(diǎn)轉(zhuǎn)為數(shù)據(jù)化的精細(xì)運(yùn)營上贪染，如何做好精細(xì)化運(yùn)營問題上來喉刘，當(dāng)資源不夠時用戶就叫喊打毛，甚至有的業(yè)務(wù)方會挽起袖子來自己參與到從數(shù)據(jù)整理甘有、加工窖张、分析階段刹勃。
此時呢钠导，原有建設(shè)數(shù)據(jù)平臺的多個角色（數(shù)據(jù)開發(fā)芜抒、模型設(shè)計(jì)）可能轉(zhuǎn)為對其它非專業(yè)使用數(shù)據(jù)方锅纺，做培訓(xùn)攀涵、咨詢與落地铣耘，寫更加適合當(dāng)前企業(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àn)椴粚I(yè)性，導(dǎo)致數(shù)據(jù)質(zhì)量問題怒详、重復(fù)對分?jǐn)?shù)據(jù)浪費(fèi)存儲與資源炉媒、口徑多樣化、編碼不統(tǒng)一昆烁、命名問題等等原因吊骤。數(shù)據(jù)質(zhì)量逐漸變成一個特別突出的問題。
傳統(tǒng)企業(yè)的數(shù)據(jù)源基本來自excel静尼、表格水援、DB系統(tǒng)等密强，但在互聯(lián)網(wǎng)有網(wǎng)站點(diǎn)擊流日志、視頻蜗元、音頻或渤、圖片數(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ù)有些力不從心池磁。
當(dāng)數(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è)也有自己特點(diǎn)，傳統(tǒng)行業(yè)所涉及數(shù)據(jù)模型這個領(lǐng)域涉及的很多內(nèi)容在互聯(lián)網(wǎng)變成以其他的曲線救國的方式存在了筛圆。
在互聯(lián)網(wǎng)曲線救國新解決
回顧在傳統(tǒng)行業(yè)數(shù)據(jù)平臺中裂明，不管兩位大師爭論點(diǎn)數(shù)據(jù)模型的設(shè)計(jì)采用那種范式（Bill Inmon的EDW的原則是準(zhǔn)三范式的設(shè)計(jì)、Ralph kilmbal是星型結(jié)構(gòu)）但是都要非常重視數(shù)據(jù)源的質(zhì)量問題太援。所以傳統(tǒng)行業(yè)的數(shù)據(jù)模型會全盤考慮數(shù)據(jù)質(zhì)量問題闽晦，并通過數(shù)據(jù)抽樣分析給出合適的清洗口徑。
(點(diǎn)擊放大圖像)
上圖來自我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ù)”對一年的還是不準(zhǔn)的）。在應(yīng)對數(shù)據(jù)的質(zhì)量問題液样，目前互聯(lián)網(wǎng)有些做法是把數(shù)據(jù)標(biāo)準(zhǔn)化前置到業(yè)務(wù)數(shù)據(jù)產(chǎn)生就做振亮，從根源上去杜絕數(shù)據(jù)質(zhì)量，但是這種場景比較實(shí)用在Log 日志的數(shù)據(jù)源中鞭莽，比如移動互聯(lián)網(wǎng)最近流行的基于事件模型“Event”模型，在日志產(chǎn)生時就規(guī)定好存儲格式（備注：大家度娘搜索，“學(xué)習(xí)筆記：The Log（我所讀過的最好的一篇分布式技術(shù)文章）” 對這個講解很詳細(xì)）帽撑。
在傳統(tǒng)行業(yè)脸甘，目前還是以混合模型設(shè)計(jì)方式為主。在互聯(lián)網(wǎng)的我所接觸的一些業(yè)務(wù)，在參照傳統(tǒng)數(shù)據(jù)模型方法論基礎(chǔ)上逐步演進(jìn)適合互聯(lián)網(wǎng)數(shù)據(jù)的數(shù)據(jù)模型方法星瘾。
比如互聯(lián)網(wǎng)金融等一些業(yè)務(wù)會參考傳統(tǒng)金融行業(yè)對主題域的劃分走孽、OMG數(shù)據(jù)倉庫元數(shù)據(jù)管理CWM模型、FSDM金融模型琳状，再進(jìn)一步考慮大數(shù)據(jù)處理特性去進(jìn)行設(shè)計(jì)磕瓷，所有從Hight Level 數(shù)據(jù)架構(gòu)圖看到主題層次劃分與傳統(tǒng)第三代數(shù)據(jù)倉庫還是很多相似之處，當(dāng)然模型架構(gòu)也有分三層念逞、四層困食、五層的。
不同的地方模型細(xì)節(jié)處理上已經(jīng)完全不一樣翎承，比如數(shù)據(jù)的多樣性硕盹、拉寬事實(shí)表、度量值單獨(dú)存儲叨咖、滿足數(shù)據(jù)快速重生瘩例、維度的二次降維處理等、增加大量冗余列芒澜、增加大量派生列仰剿，結(jié)合自動化元數(shù)據(jù)來耦合、合并等相關(guān)管理痴晦。
(點(diǎn)擊放大圖像)
[圖片上傳中南吮。。誊酌。（4）]
上圖是支付寶非常早期數(shù)據(jù)模型
(點(diǎn)擊放大圖像)
上圖是支付寶非常早期數(shù)據(jù)模型
我們常提到的多維模型在大數(shù)據(jù)處理下進(jìn)行了退化維度處理部凑。大家知道Olap多維模型，隨著維度的增加事實(shí)表的數(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è)計(jì)多維挖掘分析數(shù)據(jù)產(chǎn)品背后的技術(shù)就是搜索引擎實(shí)現(xiàn)的）箱锐，現(xiàn)在應(yīng)該也有新技術(shù)出現(xiàn)了來解決類似的問題比勉。
(點(diǎn)擊放大圖像)
上圖為2012年產(chǎn)品UI之一。
(點(diǎn)擊放大圖像)
[圖片上傳中驹止。浩聋。。（7）]
上圖是2011-2012年該產(chǎn)品系列背后當(dāng)時使用的技術(shù)
互聯(lián)網(wǎng)業(yè)務(wù)特點(diǎn)業(yè)務(wù)垂直拆分非常細(xì)臊恋，比如一個用戶注冊衣洁、密碼找回的流程有可能存在好幾個產(chǎn)品負(fù)責(zé)同一個業(yè)務(wù)流程不同環(huán)節(jié)，相關(guān)的一個策略抖仅、產(chǎn)品feature快速迭代上線等等都要數(shù)據(jù)評估坊夫。數(shù)據(jù)從前端埋點(diǎn)到采集然后再由各個環(huán)節(jié)到數(shù)據(jù)平臺砖第，再有數(shù)據(jù)分析師或各業(yè)務(wù)部門去使用，基本拉長了時間周期环凿。需求部門與實(shí)施部門能力和經(jīng)驗(yàn)有千差萬別的需求梧兼，造成了懂技術(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ù)特點(diǎn)是變化非常迅速的环肘，能穩(wěn)定的業(yè)務(wù)達(dá)到65%算對數(shù)據(jù)平臺是個福音了（根據(jù)對某寶寶的印象）剩余的業(yè)務(wù)變化迅速欲虚，必然導(dǎo)致數(shù)據(jù)模型快速上下線。
Kimball老人家提出的維度建模（備注悔雹，在本系列發(fā)展史得第一篇有介紹）圍繞業(yè)務(wù)模型能夠非常直觀的表達(dá)出業(yè)務(wù)的數(shù)據(jù)關(guān)系痪署，但是在互聯(lián)網(wǎng)NOSQL犧牲掉了關(guān)系型數(shù)據(jù)庫的一致性侨把、完整性等等很多東西折砸。維度數(shù)據(jù)模型又基于這些大數(shù)據(jù)技術(shù)的情组，所以進(jìn)化的更加輕量級與基于細(xì)節(jié)數(shù)據(jù)的維度退化建模（原有的緩慢變化維、快速變化維益涧、大維锈锤、迷你維、父子維闲询、雪花維為了適應(yīng)互聯(lián)網(wǎng)的大數(shù)據(jù)Nosql處理技術(shù)進(jìn)行反規(guī)范化久免、化&數(shù)據(jù)冗余設(shè)計(jì)。
退化維度的反規(guī)范化設(shè)計(jì)一方面可以把一條查詢語句所需要的所有數(shù)據(jù)組合起來放到一個地方存儲 Key values 的方式（比如說商品有不同類型扭弧，每一種類型商品又有自己的不同屬性阎姥，可以采用一對多、多對多的方式存儲鸽捻，例如把一個多維映射為一個Key value）呼巴。
講到互聯(lián)網(wǎng)數(shù)據(jù)平臺就要提數(shù)據(jù)模型，提了數(shù)據(jù)模型就要提Nosql技術(shù)御蒲，
(點(diǎn)擊放大圖像)
上圖來自Nosql文檔系列的一幅圖
Nosql 是大數(shù)據(jù)處理的特征之一衣赶。互聯(lián)網(wǎng)數(shù)據(jù)平臺數(shù)據(jù)模型與NoSql技術(shù)還是蠻緊密的删咱。這里有外文講解Nosql Data modeling technigues 從技術(shù)角度講解非常詳（https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/）。
因?yàn)榍斑吿岬降拇髷?shù)據(jù)平臺技術(shù)特性決定了傳統(tǒng)edw模型豪筝、維度模型直接在互聯(lián)網(wǎng)數(shù)據(jù)大數(shù)據(jù)平臺部署或許還有“好些未知”障礙等待大家去克服痰滋。同時在傳統(tǒng)數(shù)據(jù)建模用到的一些方法經(jīng)過互聯(lián)網(wǎng)熏陶或許演進(jìn)成一種新的數(shù)據(jù)產(chǎn)品或方案吧摘能。
到此為止“我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史”上下共四篇與大家分享完畢，這個寫作前后經(jīng)歷剛好一個月左右敲街，算是對自己數(shù)據(jù)從業(yè)經(jīng)歷回顧之一吧团搞。在知識的整理中很多都是蜻蜓點(diǎn)水，每個知識域都是一個非常深的專業(yè)方向多艇，自己涉足很膚淺逻恐，在文章中分享不足之處請各位讀者見諒！峻黍！
個人郵箱是5592094@qq.com 歡迎電郵交流复隆。
接下來我會進(jìn)入數(shù)據(jù)產(chǎn)品這個領(lǐng)域的分享，當(dāng)年車品覺老師自豪的作品之一“黃金策”姆涩，我是數(shù)據(jù)產(chǎn)品經(jīng)理挽拂。（ps：自己躲在墻角拿車品覺老師往自己臉上貼金了）。
后記
有一次數(shù)據(jù)產(chǎn)品神策的創(chuàng)始人兼好友@桑文鋒＠SensorsData跟我說來做次分享吧骨饿，我當(dāng)時出了幾個題目亏栈，最后就選擇了“我所經(jīng)歷的大數(shù)據(jù)平臺“，就形成了大家看到的”我所經(jīng)歷的大數(shù)據(jù)平臺“系列文章.
在整理期間得到了死黨@周愛民宏赘、@神策-桑文峰绒北、 InfoQ小編@Tina Du 、@betty zhou @Laurel大力協(xié)助察署，在這里感謝Ｃ朴巍！箕母！
番外篇
這一篇是在24日舉行的分享大家提到的一些問題储藐，經(jīng)過整理算是對正文的補(bǔ)充吧，從互聯(lián)網(wǎng)敏捷數(shù)據(jù)模型等角度做了較深入的細(xì)節(jié)介紹嘶是。同時在數(shù)據(jù)產(chǎn)品方面的回答包含了一點(diǎn)未來寫作篇“數(shù)據(jù)產(chǎn)品”系列的一點(diǎn)內(nèi)容钙勃。
1****，傳統(tǒng)我們做BI的聂喇，做數(shù)據(jù)展現(xiàn)會建模后以pivot展現(xiàn)cube數(shù)據(jù)辖源，不知道現(xiàn)在互聯(lián)網(wǎng)公司數(shù)據(jù)展示如何做的？第三方工具還是用API取數(shù)據(jù)平臺里的數(shù)據(jù)希太？adhoc報(bào)表及靈活更換維度的時候web端一般是怎么做的克饶？
松子老師：剛才文章中提到了比如傳統(tǒng)行業(yè)的多維數(shù)據(jù)模型cube。在互聯(lián)網(wǎng)采用的曲線救國方式解決的。 在分享中我給出了幾個圖。就是通過搜索引擎曲線救國方式實(shí)現(xiàn)類似Olap的模擬拆挥。
在這塊的模型的處理上采用的是維度退化處理椎咧。通過反規(guī)范化胎署，數(shù)據(jù)項(xiàng)霹俺、數(shù)據(jù)冗余去處理脖阵。在前端做特殊處理拇派。
這個當(dāng)時產(chǎn)品原型之一：
(點(diǎn)擊放大圖像)
這是一個2011年-2012年左右的數(shù)據(jù)產(chǎn)品拍屑，當(dāng)時算是即時計(jì)算的一種途戒。不過已經(jīng)過去好幾年了，當(dāng)今新技術(shù)下Olap 引擎應(yīng)該有很好的提升僵驰。
目前我知道的家互聯(lián)網(wǎng)公司喷斋，在前端展現(xiàn)有使用第三方套件比如spagoBi、pentaho 等 有自己設(shè)計(jì)開發(fā)定制化數(shù)據(jù)前端展現(xiàn)蒜茴。比如我剛開始分享的那兩個之前在去哪兒網(wǎng)設(shè)計(jì)的數(shù)據(jù)平臺內(nèi)部界面之一星爪，當(dāng)然數(shù)據(jù)產(chǎn)品是另一個話題了，通過對數(shù)據(jù)分析抽象指標(biāo)矮男、分析模型移必、用戶使用功能與流程、未來規(guī)劃考慮用戶體驗(yàn)去設(shè)計(jì)毡鉴。
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
[圖片上傳中崔泵。。猪瞬。（11）]
(點(diǎn)擊放大圖像)
2****憎瘸，互聯(lián)網(wǎng)財(cái)經(jīng)類公司，業(yè)務(wù)包括財(cái)經(jīng)網(wǎng)站陈瘦、基金幌甘、股票、金融等痊项，這類公司的數(shù)據(jù)倉庫模型應(yīng)該如何設(shè)計(jì)锅风？特點(diǎn)和注意事項(xiàng)是什么？案例介紹鞍泉？十分感謝皱埠。
松子老師：我自己經(jīng)歷過的是互聯(lián)網(wǎng)金融以及移動互聯(lián)網(wǎng)行。對這兩塊比較清楚咖驮”咂鳎互聯(lián)網(wǎng)金融起因?yàn)闃I(yè)務(wù)的特性是類金融類的，與銀行有些地方是相似的托修。
比如大約在2012年前支付寶業(yè)務(wù)特點(diǎn)涉及類金融交易：充值忘巧、提現(xiàn)、賬務(wù)管理類電子商務(wù)：購物交易過程變更睦刃、實(shí)際交易（對B機(jī)票砚嘴、對C水電等） 非純電子商務(wù)；純金融；個人信用际长，理財(cái)類婆誓。系統(tǒng)之間依賴度較為復(fù)雜，垂直依賴（業(yè)務(wù)與核心）跨層依賴（跨過交易到賬務(wù)）也颤。
在設(shè)計(jì)方法上還是采用維度模型設(shè)計(jì)方式。底層是數(shù)據(jù)驅(qū)動為向?qū)в羟幔Y(jié)合業(yè)務(wù)需求驅(qū)動翅娶，通過簡單、退化維度的方式拉寬表結(jié)構(gòu)好唯。
底層采用松耦合設(shè)計(jì)竭沫。主題之間是松耦合方式。至體內(nèi)采用細(xì)粒度退化維度骑篙。
在主題域上的的設(shè)計(jì)基本參考了OMG的數(shù)據(jù)倉庫元數(shù)據(jù)設(shè)計(jì)CWM模型蜕提、IBM 的fsdm金融模型、還有新巴塞爾資本協(xié)議（Basel II Capital Accord）需提供數(shù)據(jù)規(guī)范去的設(shè)計(jì)买置。所以數(shù)據(jù)模型是五層的結(jié)構(gòu)哮笆。
在細(xì)節(jié)處理上狮腿，增量ODS層數(shù)據(jù)和前一天DWD相關(guān)表進(jìn)行 merge處理。
在一些層次上脏榆，基本聚合、匯總增加派生事實(shí)表（簡單一句話退化為度打?qū)挘┨ǖＨ缓蟀凑諛I(yè)務(wù)主體合并信息等须喂。
比如開始給大家分享的那張圖：
(點(diǎn)擊放大圖像)
[圖片上傳中。趁蕊。坞生。（13）]
在維度模型退化處理時，要注意最細(xì)粒度數(shù)據(jù)保留掷伙、不同層次的數(shù)據(jù)支持?jǐn)?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ù)模型乘盼。
這種元數(shù)據(jù)驅(qū)動工具型數(shù)據(jù)產(chǎn)品我會在未來數(shù)據(jù)產(chǎn)品系列中做詳細(xì)介紹的升熊。
3****，互聯(lián)網(wǎng)企業(yè)大數(shù)據(jù)平臺的發(fā)展歷程是怎樣的绸栅？
松子老師：這個我相信應(yīng)該是傳統(tǒng)數(shù)據(jù)平臺朋友提到的级野。傳統(tǒng)行業(yè)數(shù)據(jù)平臺架構(gòu)演進(jìn)我總結(jié)簡單一句話說“基本上可以分為五個時代、四種架構(gòu)”，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與類型暴增的特點(diǎn)蓖柔，從高階架構(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é)下來用戶特點(diǎn)：
(點(diǎn)擊放大圖像)
[圖片上傳中镐捧。潜索。。（14）]
更加詳細(xì)的每一代數(shù)據(jù)平臺建設(shè)懂酱、服務(wù)角色特點(diǎn)您可以看我這個系列文章的第三篇竹习，http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-paet02
4****，有沒有好的元數(shù)據(jù)管理工具推薦列牺？主要偏向數(shù)據(jù)字典與血統(tǒng)等整陌。
松子老師：元數(shù)據(jù)以前目前沒有太多的好管理工具。以前是在支付寶是我自己設(shè)計(jì)的一個數(shù)據(jù)產(chǎn)品瞎领。第一版自己用Delphi 開發(fā)的泌辫。
（圖很多：）
(點(diǎn)擊放大圖像)
[圖片上傳中。九默。甥郑。（15）]
(點(diǎn)擊放大圖像)
[圖片上傳中。荤西。澜搅。（16）]
(點(diǎn)擊放大圖像)
[圖片上傳中。邪锌。勉躺。（17）]
(點(diǎn)擊放大圖像)
[圖片上傳中。觅丰。饵溅。（18）]
(點(diǎn)擊放大圖像)
[圖片上傳中。妇萄。蜕企。（19）]
以前被逼的自己寫了一個，通過解析冠句，實(shí)現(xiàn)了字段級的血緣影響分析轻掩。這只是第二步糙捺，后來又把running 信息給搞了進(jìn)來粤剧。還有分享時提到的模型信息捏卓、整個閉環(huán)的分類信息。
這是一個分支：
(點(diǎn)擊放大圖像)
[圖片上傳中憎夷。洛史。硼婿。（20）]
但是我們實(shí)現(xiàn)了字段級解析準(zhǔn)確率達(dá)到了94%左右轧葛。有細(xì)微的錯誤就人工revew一遍。
5. ****松子老師扮惦，數(shù)據(jù)管控的數(shù)據(jù)質(zhì)量部分是怎么處理的呢臀蛛？
松子老師： 數(shù)據(jù)管控， 這方面我不太懂的崖蜜，但是數(shù)據(jù)質(zhì)量掺栅，這玩意可大可小的。比如像在分享時說過的纳猪，在移動互聯(lián)網(wǎng)的數(shù)據(jù)質(zhì)量處理方式可以由原有的ETL(ELT)階段前置到業(yè)務(wù)系統(tǒng)去解決，比如移動互聯(lián)網(wǎng)的App log 日志桃笙，日志標(biāo)準(zhǔn)化后事件模型”存儲來解決氏堤。那非app 日志類如何解決呢比如Payment、order等搏明，數(shù)據(jù)質(zhì)量比較考慮的可以只做到監(jiān)控鼠锈。
我來分享個圖。剛好是我設(shè)計(jì)數(shù)據(jù)質(zhì)量產(chǎn)品時搞的星著，理清數(shù)據(jù)質(zhì)量的問題：
(點(diǎn)擊放大圖像)
[圖片上傳中购笆。。虚循。（21）]
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
[圖片上傳中同欠。。横缔。（23）]
只要數(shù)據(jù)進(jìn)入倉庫與應(yīng)用體系铺遂，處理起來就比較困難了，所以在數(shù)據(jù)平臺階段最好是通過監(jiān)控茎刚、前置去解決襟锐。目前數(shù)據(jù)質(zhì)量確實(shí)難以100%由事后搞到事前去處理。我對數(shù)據(jù)平臺與數(shù)據(jù)產(chǎn)品的建設(shè)就是實(shí)用為主膛锭。怎么實(shí)用怎么來粮坞。我是比較現(xiàn)實(shí)的實(shí)用主義者。
6. ****能否分享一些數(shù)據(jù)產(chǎn)品種類及實(shí)例：
松子老師：在前邊五個問題初狰、以及文章中又都涉及數(shù)據(jù)產(chǎn)品實(shí)力的一些分享莫杈。
提到數(shù)據(jù)產(chǎn)品的分類我就想把這個圖發(fā)出來。
自己認(rèn)為沒有特別明確的劃分線奢入，但是數(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工具、資源管控等等聋伦。
面向用戶功能有報(bào)表型夫偶、多維型數(shù)據(jù)產(chǎn)品、定制化數(shù)據(jù)產(chǎn)品觉增、挖掘型數(shù)據(jù)產(chǎn)品兵拢。
面向內(nèi)部用戶、外部個人用戶逾礁、外部企業(yè)用戶又有不同的分類说铃。
根據(jù)業(yè)務(wù)又可以劃分很多瓤球，面向C類用戶径筏、面向B類商戶、金融風(fēng)險(xiǎn)等等
從近幾年的數(shù)據(jù)產(chǎn)品來看调卑，是更好的輔助用戶的做決策的一種產(chǎn)品形態(tài)砾嫉，在用戶的決策與行動中充當(dāng)信息的分析者與價值使用者幼苛；數(shù)據(jù)產(chǎn)品有個自己的共性：由解決的一個實(shí)際的業(yè)務(wù)問題出發(fā)，分解出的分析指標(biāo)焕刮，分析模型舶沿，分析流程組成，再考慮到功能易用性配并，未來功能擴(kuò)展暑椰，考慮用戶對數(shù)據(jù)易用性（比如數(shù)據(jù)的呈現(xiàn)層次，不可能一次把所有數(shù)據(jù)的呈現(xiàn)給用戶）來組成的荐绝。
(點(diǎn)擊放大圖像)
[圖片上傳中一汽。。低滩。（24）]
7. ****銀行業(yè)從傳統(tǒng)的ods到edw再到大數(shù)據(jù)平臺這塊過渡召夹，模型如何建設(shè)？平臺優(yōu)勢如何發(fā)揮恕沫？
松子老師：這個問題還是有些難度的监憎，自己回答的可能有些片面。首先我們清醒的清楚“大數(shù)據(jù)”是什么婶溯？再次不同的場景可以采用不同的技術(shù)去解決鲸阔。
“大數(shù)據(jù)”偷霉，拆開來看大、數(shù)據(jù)褐筛，大可以是指的數(shù)據(jù)源結(jié)構(gòu)簡單（ps 如果了解過當(dāng)代對大數(shù)據(jù)的定義就知道四個特性）但是量級夠大类少，比如清算、結(jié)算渔扎、對公硫狞、對私、中間業(yè)務(wù)等等每一個拿出來都是幾十T晃痴，但是這些業(yè)務(wù)數(shù)據(jù)都是保存?zhèn)鹘y(tǒng)的關(guān)系型數(shù)據(jù)庫中如DB2残吩、Oracle、MSsql中倘核，因?yàn)樵跀?shù)據(jù)平臺存儲是通過準(zhǔn)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ù)的去演進(jìn)解決琼蚯。（最早時我的是中信銀行、光大銀行在2011年左右開始考慮Hadoop技術(shù)惠况，后來不知道如何了）遭庶。
但是互聯(lián)網(wǎng)的數(shù)據(jù)平臺技術(shù)大都是NOSQL模式，犧牲掉了傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)一致性稠屠、完整性峦睡、唯一索引等等，只干性能的事情（當(dāng)然除了性能权埠、可擴(kuò)展性也是的）.
原有在傳統(tǒng)數(shù)據(jù)平臺模型設(shè)計(jì)上可以考慮的一些通過主外鍵榨了、唯一索引做一些業(yè)務(wù)約束的方法，在nosql上統(tǒng)統(tǒng)的都沒有了攘蔽，這些約束必須放到數(shù)據(jù)加工階段去想辦法做檢查龙屉。傳統(tǒng)數(shù)據(jù)平臺如果在Insert、update數(shù)據(jù)時違反了業(yè)務(wù)約束可以做報(bào)警或異常處理满俗，但是在Nosql的平臺上要求ETL 去手動遵守這些規(guī)則檢查转捕。但是有時ETL開發(fā)根本不遵守的，僅僅是兩個表關(guān)聯(lián)起來唆垃，也可能忘記按照某一個業(yè)務(wù)唯一索引做去重操作。簡單說，原有靠關(guān)系型數(shù)據(jù)庫本身機(jī)制去做檢查一些規(guī)則變?yōu)槿斯っ囟簦優(yōu)槿斯ぞ蜁稿e儡司。
從關(guān)系型數(shù)據(jù)平臺往Nosql數(shù)據(jù)平臺遷移時沉删，尤其是對傳統(tǒng)行業(yè)的業(yè)務(wù)來說，在模型設(shè)計(jì)階段醉途、以及給出的ETL口徑要考慮更多的業(yè)務(wù)規(guī)則檢查矾瑰，其次要考慮更多的維度退化、多冗余结蟋、表打?qū)捥幚砀小：唵握f就是發(fā)揮數(shù)據(jù)平臺的計(jì)算能力同時要更加的各方面確保數(shù)據(jù)準(zhǔn)確安全可靠。
數(shù)據(jù)模型ODS 到EDW 這塊的設(shè)計(jì)方法百度上留下的文檔資料太多的了嵌屎，請這位提問的老師百度吧推正。
**8****．大數(shù)據(jù)****倉庫****中如何做快速****維處****理？互****聯(lián)****網(wǎng)數(shù)****倉****數(shù)據(jù)****質(zhì)****量不好如何****對****數(shù)宝惰，如何確立****標(biāo)****準(zhǔn)的****對****數(shù)口徑植榕？******
松子老師：快速變化維度可以轉(zhuǎn)化為緩慢變化為來出來，我自己理解的快速維度是相對于緩慢維度參照的來說的尼夺。
舉個例子尊残，年齡-轉(zhuǎn)化為天數(shù)可以是定義快速變化維度，因?yàn)槊刻於荚谧兓俣隆Ｎ覀兛梢园涯挲g退化為區(qū)間維度來處理寝衫，還可以把年齡做成動態(tài)維度來處理，事實(shí)表中保存的就是實(shí)際的出生年月并打?qū)挶砉招埃挲g(天)通過計(jì)算方式來處理慰毅。還有種方法通過對代理鍵的方式來處理。
我目前也不知道對數(shù)據(jù)的標(biāo)準(zhǔn)是什么扎阶。但是我自己用的方法汹胃，把一個指標(biāo)的整個數(shù)據(jù)流向切出幾個關(guān)鍵點(diǎn)通過SQL去實(shí)現(xiàn)對數(shù)，看波動振幅东臀，波動曲線着饥。同時還會比如發(fā)不通的版本的小流量測試的方式來做數(shù)據(jù)校對。
9****． 做為數(shù)據(jù)行業(yè)從業(yè)者惰赋，需要掌握哪些重要的基礎(chǔ)知識宰掉？另：如果從零開始建立一個數(shù)據(jù)平臺，需要哪些資源配置（人赁濒，財(cái)贵扰，物，技術(shù)）流部？大致總投資額度多少戚绕？如果同行產(chǎn)品間多種來源的數(shù)據(jù)，可有成熟的解決方案枝冀？謝謝…
松子老師：這個問題太宏觀了舞丛。作為數(shù)據(jù)行業(yè)從業(yè)者耘子，需要掌握哪些重要基礎(chǔ)知識，這個是要看從事具體數(shù)據(jù)域的垂直行業(yè)球切。
比如說 數(shù)據(jù)開發(fā)谷誓、數(shù)據(jù)模型、數(shù)據(jù)產(chǎn)品吨凑、數(shù)據(jù)分析師捍歪、數(shù)據(jù)運(yùn)營、數(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ù)目標(biāo)不太明確下揽乱，難以確定方案群叶，人員配置上選用不同技術(shù)方案去搭建的配置是不太一樣的耙旦，比如說傳統(tǒng)平臺來講璧疗，運(yùn)維舞竿、DBA、數(shù)據(jù)開發(fā)憔晒、數(shù)據(jù)模型贯卦、報(bào)表人員捂齐。
從互聯(lián)網(wǎng)數(shù)據(jù)平臺基本配置上申屹，數(shù)據(jù)架構(gòu)師绘证、運(yùn)維隧膏、底層大數(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ù)铆惑。
10. Standalone****模式下范嘱，Model.save(Path)怎么一直提示錯誤送膳，是不是配置Spark時需要將Hdfs的配置引進(jìn)來啊～？表示初學(xué)Spark
松子老師：這個問題有點(diǎn)超出我的能力范圍了丑蛤，所以對不起回答不了叠聋。
我本身不是做技術(shù)的。僅知道一點(diǎn)技術(shù)名詞受裹。
11. ****傳統(tǒng)銀行業(yè)數(shù)據(jù)模型什么時候會走向互聯(lián)網(wǎng)模式呢碌补？目前在傳統(tǒng)銀行數(shù)據(jù)平臺的產(chǎn)品是不是特別多？
松子老師：這個問題我自己就不知道了棉饶，或許是傳統(tǒng)銀行在數(shù)據(jù)平臺的實(shí)施上全面用互聯(lián)網(wǎng)的Nosql大數(shù)據(jù)處理技術(shù)吧厦章。至于說傳統(tǒng)銀行數(shù)據(jù)模型用現(xiàn)有的互聯(lián)網(wǎng)數(shù)據(jù)模型理念去設(shè)計(jì)是否完全可行，數(shù)據(jù)一致性砰盐、高準(zhǔn)確性通過更多的方案去保證闷袒。
首先我需要確定一下這個產(chǎn)品是否指的“數(shù)據(jù)產(chǎn)品”。
如果是數(shù)據(jù)產(chǎn)品岩梳，那其實(shí)傳統(tǒng)行業(yè)數(shù)據(jù)平臺本身就有一些數(shù)據(jù)產(chǎn)品了囊骤，而且也都是存在的。數(shù)據(jù)產(chǎn)品自從數(shù)據(jù)倉庫出現(xiàn)以來它其實(shí)一直都存在的冀值，只不過是近幾年因?yàn)榛ヂ?lián)網(wǎng)特別愛制造“流行詞“把數(shù)據(jù)產(chǎn)品這個詞給放大了也物。互聯(lián)網(wǎng)是得數(shù)據(jù)產(chǎn)品從早期的重量級逐漸進(jìn)化為輕量級列疗、從大而全的解決方案逐漸演進(jìn)為因小而美滑蚯。
我來給出幾組例子，大約從2004年到現(xiàn)在的幾組數(shù)據(jù)產(chǎn)品的例子
(點(diǎn)擊放大圖像)
[圖片上傳中抵栈。告材。。（25）]
(點(diǎn)擊放大圖像)
[圖片上傳中古劲。斥赋。。（26）]
(點(diǎn)擊放大圖像)
[圖片上傳中产艾。疤剑。。（27）]
(點(diǎn)擊放大圖像)
[圖片上傳中闷堡。隘膘。。（28）]
(點(diǎn)擊放大圖像)
[圖片上傳中。。董济。（29）]
(點(diǎn)擊放大圖像)
[圖片上傳中泽疆。管钳。吨悍。（30）]
(點(diǎn)擊放大圖像)
[圖片上傳中。蹋嵌。育瓜。（31）]
你可以分類一下，這些數(shù)據(jù)產(chǎn)品的特點(diǎn)是什么栽烂？滿足了用戶怎么樣的痛點(diǎn)需求躏仇？滿足了用戶怎么樣的使用流程。
12 ****腺办。傳統(tǒng)行業(yè)的數(shù)據(jù)倉庫從業(yè)人員焰手，如果轉(zhuǎn)到互聯(lián)網(wǎng)行業(yè)，應(yīng)該學(xué)習(xí)哪些技能怀喉？
松子老師：這個問題你可以百度搜索“大數(shù)據(jù)職位所需要的數(shù)據(jù)技能” http://blog.jobbole.com/99039/ 這篇文章书妻。自己覺得人家回答的比我專業(yè)。//
我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史（四）：互聯(lián)網(wǎng)時代 ? 下篇
http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-internet-age
編者按：本文是松子（李博源）的大數(shù)據(jù)平臺發(fā)展史系列文章的第四篇（共四篇）躬拢，本系列以獨(dú)特的視角躲履，比較了非互聯(lián)網(wǎng)和互聯(lián)網(wǎng)兩個時代以及傳統(tǒng)行業(yè)與非傳統(tǒng)行業(yè)。是對數(shù)據(jù)平臺發(fā)展的一個回憶聊闯，對非互聯(lián)網(wǎng)工猜、互聯(lián)網(wǎng)，從數(shù)據(jù)平臺的用戶角度菱蔬、數(shù)據(jù)架構(gòu)演進(jìn)篷帅、模型等進(jìn)行了闡述。
在互聯(lián)網(wǎng)時代被弱化的數(shù)據(jù)模型
談起數(shù)據(jù)模型就不得不提傳統(tǒng)數(shù)據(jù)平臺架構(gòu)發(fā)展拴泌，我相信很多朋友都曉得傳統(tǒng)數(shù)據(jù)平臺的知識魏身，其架構(gòu)演進(jìn)簡單一句話說“基本上可以分為五個時代、四種架構(gòu)”蚪腐，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與數(shù)據(jù)源類型多樣化特點(diǎn)箭昵，從高階架構(gòu)上來看大約從傳統(tǒng)數(shù)據(jù)平臺第三代架構(gòu)開始延續(xù)的，但是往后的發(fā)展從我自己的這一點(diǎn)知識上很難對互聯(lián)網(wǎng)的數(shù)據(jù)平臺做架構(gòu)歸類削茁。
但是從數(shù)據(jù)平臺建設(shè)與服務(wù)角色上還是有章可循的宙枷。就像上篇分享到那樣掉房，類比兩個行業(yè)茧跋，互聯(lián)網(wǎng)企業(yè)中員工年齡比非互聯(lián)網(wǎng)企業(yè)的要年輕、受教育程度卓囚、對計(jì)算機(jī)的焦慮程度明顯比傳統(tǒng)企業(yè)要低瘾杭、還偶遇其它各方面的緣故，導(dǎo)致了數(shù)據(jù)平臺所面對用戶群體與非互聯(lián)網(wǎng)數(shù)據(jù)平臺有所差異化哪亿。
傳統(tǒng)行業(yè)與互聯(lián)網(wǎng)行業(yè)數(shù)據(jù)平臺用戶特性我只選擇前文章的兩張圖來表示
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
在傳統(tǒng)數(shù)據(jù)平臺要背后有一個完整數(shù)據(jù)倉庫團(tuán)隊(duì)去服務(wù)業(yè)務(wù)方粥烁，業(yè)務(wù)方嗷嗷待哺的等待被動方式去滿足贤笆。中低層數(shù)據(jù)基本不會對業(yè)務(wù)方開放，所以不管數(shù)據(jù)模型采用何種建模方式讨阻，主要滿足當(dāng)時數(shù)據(jù)架構(gòu)規(guī)劃即可芥永。
互聯(lián)網(wǎng)業(yè)務(wù)的快速發(fā)展使得大家已經(jīng)從經(jīng)營、分析的訴求重點(diǎn)轉(zhuǎn)為數(shù)據(jù)化的精細(xì)運(yùn)營上钝吮，如何做好精細(xì)化運(yùn)營問題上來埋涧，當(dāng)資源不夠時用戶就叫喊，甚至有的業(yè)務(wù)方會挽起袖子來自己參與到從數(shù)據(jù)整理奇瘦、加工棘催、分析階段。
此時呢耳标，原有建設(shè)數(shù)據(jù)平臺的多個角色（數(shù)據(jù)開發(fā)醇坝、模型設(shè)計(jì)）可能轉(zhuǎn)為對其它非專業(yè)使用數(shù)據(jù)方，做培訓(xùn)次坡、咨詢與落地呼猪，寫更加適合當(dāng)前企業(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àn)椴粚I(yè)性产禾，導(dǎo)致數(shù)據(jù)質(zhì)量問題明棍、重復(fù)對分?jǐn)?shù)據(jù)浪費(fèi)存儲與資源乡革、口徑多樣化、編碼不統(tǒng)一摊腋、命名問題等等原因沸版。數(shù)據(jù)質(zhì)量逐漸變成一個特別突出的問題。
傳統(tǒng)企業(yè)的數(shù)據(jù)源基本來自excel兴蒸、表格视粮、DB系統(tǒng)等，但在互聯(lián)網(wǎng)有網(wǎng)站點(diǎn)擊流日志橙凳、視頻蕾殴、音頻、圖片數(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ù)有些力不從心。
當(dāng)數(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è)也有自己特點(diǎn)，傳統(tǒng)行業(yè)所涉及數(shù)據(jù)模型這個領(lǐng)域涉及的很多內(nèi)容在互聯(lián)網(wǎng)變成以其他的曲線救國的方式存在了桐愉。
在互聯(lián)網(wǎng)曲線救國新解決
回顧在傳統(tǒng)行業(yè)數(shù)據(jù)平臺中财破，不管兩位大師爭論點(diǎn)數(shù)據(jù)模型的設(shè)計(jì)采用那種范式（Bill Inmon的EDW的原則是準(zhǔn)三范式的設(shè)計(jì)、Ralph kilmbal是星型結(jié)構(gòu)）但是都要非常重視數(shù)據(jù)源的質(zhì)量問題从诲。所以傳統(tǒng)行業(yè)的數(shù)據(jù)模型會全盤考慮數(shù)據(jù)質(zhì)量問題左痢，并通過數(shù)據(jù)抽樣分析給出合適的清洗口徑。
(點(diǎn)擊放大圖像)
上圖來自我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ù)”對一年的還是不準(zhǔn)的）定页。在應(yīng)對數(shù)據(jù)的質(zhì)量問題，目前互聯(lián)網(wǎng)有些做法是把數(shù)據(jù)標(biāo)準(zhǔn)化前置到業(yè)務(wù)數(shù)據(jù)產(chǎn)生就做绽诚，從根源上去杜絕數(shù)據(jù)質(zhì)量典徊，但是這種場景比較實(shí)用在Log 日志的數(shù)據(jù)源中，比如移動互聯(lián)網(wǎng)最近流行的基于事件模型“Event”模型恩够，在日志產(chǎn)生時就規(guī)定好存儲格式（備注：大家度娘搜索卒落，“學(xué)習(xí)筆記：The Log（我所讀過的最好的一篇分布式技術(shù)文章）” 對這個講解很詳細(xì)）。
在傳統(tǒng)行業(yè)蜂桶，目前還是以混合模型設(shè)計(jì)方式為主儡毕。在互聯(lián)網(wǎng)的我所接觸的一些業(yè)務(wù)，在參照傳統(tǒng)數(shù)據(jù)模型方法論基礎(chǔ)上逐步演進(jìn)適合互聯(lián)網(wǎng)數(shù)據(jù)的數(shù)據(jù)模型方法扑媚。
比如互聯(lián)網(wǎng)金融等一些業(yè)務(wù)會參考傳統(tǒng)金融行業(yè)對主題域的劃分腰湾、OMG數(shù)據(jù)倉庫元數(shù)據(jù)管理CWM模型、FSDM金融模型疆股，再進(jìn)一步考慮大數(shù)據(jù)處理特性去進(jìn)行設(shè)計(jì)费坊，所有從Hight Level 數(shù)據(jù)架構(gòu)圖看到主題層次劃分與傳統(tǒng)第三代數(shù)據(jù)倉庫還是很多相似之處，當(dāng)然模型架構(gòu)也有分三層押桃、四層微宝、五層的酵熙。
不同的地方模型細(xì)節(jié)處理上已經(jīng)完全不一樣，比如數(shù)據(jù)的多樣性、拉寬事實(shí)表官边、度量值單獨(dú)存儲、滿足數(shù)據(jù)快速重生味廊、維度的二次降維處理等钱雷、增加大量冗余列、增加大量派生列票从，結(jié)合自動化元數(shù)據(jù)來耦合漫雕、合并等相關(guān)管理。
(點(diǎn)擊放大圖像)
[圖片上傳中峰鄙。浸间。。（4）]
上圖是支付寶非常早期數(shù)據(jù)模型
(點(diǎn)擊放大圖像)
上圖是支付寶非常早期數(shù)據(jù)模型
我們常提到的多維模型在大數(shù)據(jù)處理下進(jìn)行了退化維度處理吟榴。大家知道Olap多維模型魁蒜，隨著維度的增加事實(shí)表的數(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è)計(jì)多維挖掘分析數(shù)據(jù)產(chǎn)品背后的技術(shù)就是搜索引擎實(shí)現(xiàn)的），現(xiàn)在應(yīng)該也有新技術(shù)出現(xiàn)了來解決類似的問題狭瞎。
(點(diǎn)擊放大圖像)
上圖為2012年產(chǎn)品UI之一细移。
(點(diǎn)擊放大圖像)
[圖片上傳中。熊锭。弧轧。（7）]
上圖是2011-2012年該產(chǎn)品系列背后當(dāng)時使用的技術(shù)
互聯(lián)網(wǎng)業(yè)務(wù)特點(diǎn)業(yè)務(wù)垂直拆分非常細(xì)，比如一個用戶注冊碗殷、密碼找回的流程有可能存在好幾個產(chǎn)品負(fù)責(zé)同一個業(yè)務(wù)流程不同環(huán)節(jié)劣针，相關(guān)的一個策略、產(chǎn)品feature快速迭代上線等等都要數(shù)據(jù)評估亿扁。數(shù)據(jù)從前端埋點(diǎn)到采集然后再由各個環(huán)節(jié)到數(shù)據(jù)平臺捺典，再有數(shù)據(jù)分析師或各業(yè)務(wù)部門去使用，基本拉長了時間周期从祝。需求部門與實(shí)施部門能力和經(jīng)驗(yàn)有千差萬別的需求襟己，造成了懂技術(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ù)特點(diǎn)是變化非常迅速的，能穩(wěn)定的業(yè)務(wù)達(dá)到65%算對數(shù)據(jù)平臺是個福音了（根據(jù)對某寶寶的印象）剩余的業(yè)務(wù)變化迅速仿吞，必然導(dǎo)致數(shù)據(jù)模型快速上下線滑频。
Kimball老人家提出的維度建模（備注，在本系列發(fā)展史得第一篇有介紹）圍繞業(yè)務(wù)模型能夠非常直觀的表達(dá)出業(yè)務(wù)的數(shù)據(jù)關(guān)系唤冈，但是在互聯(lián)網(wǎng)NOSQL犧牲掉了關(guān)系型數(shù)據(jù)庫的一致性峡迷、完整性等等很多東西。維度數(shù)據(jù)模型又基于這些大數(shù)據(jù)技術(shù)的你虹，所以進(jìn)化的更加輕量級與基于細(xì)節(jié)數(shù)據(jù)的維度退化建模（原有的緩慢變化維绘搞、快速變化維、大維傅物、迷你維夯辖、父子維、雪花維為了適應(yīng)互聯(lián)網(wǎng)的大數(shù)據(jù)Nosql處理技術(shù)進(jìn)行反規(guī)范化董饰、化&數(shù)據(jù)冗余設(shè)計(jì)楼雹。
退化維度的反規(guī)范化設(shè)計(jì)一方面可以把一條查詢語句所需要的所有數(shù)據(jù)組合起來放到一個地方存儲 Key values 的方式（比如說商品有不同類型，每一種類型商品又有自己的不同屬性尖阔，可以采用一對多贮缅、多對多的方式存儲，例如把一個多維映射為一個Key value）介却。
講到互聯(lián)網(wǎng)數(shù)據(jù)平臺就要提數(shù)據(jù)模型叔营，提了數(shù)據(jù)模型就要提Nosql技術(shù)辩诞，
(點(diǎn)擊放大圖像)
上圖來自Nosql文檔系列的一幅圖
Nosql 是大數(shù)據(jù)處理的特征之一剥险〕醢撸互聯(lián)網(wǎng)數(shù)據(jù)平臺數(shù)據(jù)模型與NoSql技術(shù)還是蠻緊密的。這里有外文講解Nosql Data modeling technigues 從技術(shù)角度講解非常詳（https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/）永淌。
因?yàn)榍斑吿岬降拇髷?shù)據(jù)平臺技術(shù)特性決定了傳統(tǒng)edw模型崎场、維度模型直接在互聯(lián)網(wǎng)數(shù)據(jù)大數(shù)據(jù)平臺部署或許還有“好些未知”障礙等待大家去克服。同時在傳統(tǒng)數(shù)據(jù)建模用到的一些方法經(jīng)過互聯(lián)網(wǎng)熏陶或許演進(jìn)成一種新的數(shù)據(jù)產(chǎn)品或方案吧遂蛀。
到此為止“我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史”上下共四篇與大家分享完畢谭跨，這個寫作前后經(jīng)歷剛好一個月左右，算是對自己數(shù)據(jù)從業(yè)經(jīng)歷回顧之一吧李滴。在知識的整理中很多都是蜻蜓點(diǎn)水螃宙，每個知識域都是一個非常深的專業(yè)方向，自己涉足很膚淺所坯，在文章中分享不足之處請各位讀者見諒Ｗ辉！
個人郵箱是5592094@qq.com 歡迎電郵交流芹助。
接下來我會進(jìn)入數(shù)據(jù)產(chǎn)品這個領(lǐng)域的分享堂湖，當(dāng)年車品覺老師自豪的作品之一“黃金策”闲先，我是數(shù)據(jù)產(chǎn)品經(jīng)理。（ps：自己躲在墻角拿車品覺老師往自己臉上貼金了）无蜂。
后記
有一次數(shù)據(jù)產(chǎn)品神策的創(chuàng)始人兼好友@桑文鋒＠SensorsData跟我說來做次分享吧伺糠，我當(dāng)時出了幾個題目，最后就選擇了“我所經(jīng)歷的大數(shù)據(jù)平臺“酱讶，就形成了大家看到的”我所經(jīng)歷的大數(shù)據(jù)平臺“系列文章.
在整理期間得到了死黨@周愛民退盯、@神策-桑文峰彼乌、 InfoQ小編@Tina Du 泻肯、@betty zhou @Laurel大力協(xié)助，在這里感謝Ｎ空铡Ｔ钚！
番外篇
這一篇是在24日舉行的分享大家提到的一些問題毒租，經(jīng)過整理算是對正文的補(bǔ)充吧稚铣，從互聯(lián)網(wǎng)敏捷數(shù)據(jù)模型等角度做了較深入的細(xì)節(jié)介紹。同時在數(shù)據(jù)產(chǎn)品方面的回答包含了一點(diǎn)未來寫作篇“數(shù)據(jù)產(chǎn)品”系列的一點(diǎn)內(nèi)容墅垮。
1****惕医，傳統(tǒng)我們做BI的，做數(shù)據(jù)展現(xiàn)會建模后以pivot展現(xiàn)cube數(shù)據(jù)算色，不知道現(xiàn)在互聯(lián)網(wǎng)公司數(shù)據(jù)展示如何做的抬伺？第三方工具還是用API取數(shù)據(jù)平臺里的數(shù)據(jù)？adhoc報(bào)表及靈活更換維度的時候web端一般是怎么做的灾梦？
松子老師：剛才文章中提到了比如傳統(tǒng)行業(yè)的多維數(shù)據(jù)模型cube峡钓。在互聯(lián)網(wǎng)采用的曲線救國方式解決的。 在分享中我給出了幾個圖若河。就是通過搜索引擎曲線救國方式實(shí)現(xiàn)類似Olap的模擬能岩。
在這塊的模型的處理上采用的是維度退化處理。通過反規(guī)范化萧福，數(shù)據(jù)項(xiàng)拉鹃、數(shù)據(jù)冗余去處理。在前端做特殊處理鲫忍。
這個當(dāng)時產(chǎn)品原型之一：
(點(diǎn)擊放大圖像)
這是一個2011年-2012年左右的數(shù)據(jù)產(chǎn)品毛俏，當(dāng)時算是即時計(jì)算的一種。不過已經(jīng)過去好幾年了饲窿，當(dāng)今新技術(shù)下Olap 引擎應(yīng)該有很好的提升煌寇。
目前我知道的家互聯(lián)網(wǎng)公司，在前端展現(xiàn)有使用第三方套件比如spagoBi逾雄、pentaho 等 有自己設(shè)計(jì)開發(fā)定制化數(shù)據(jù)前端展現(xiàn)阀溶。比如我剛開始分享的那兩個之前在去哪兒網(wǎng)設(shè)計(jì)的數(shù)據(jù)平臺內(nèi)部界面之一腻脏，當(dāng)然數(shù)據(jù)產(chǎn)品是另一個話題了亦镶，通過對數(shù)據(jù)分析抽象指標(biāo)送悔、分析模型套耕、用戶使用功能與流程眶痰、未來規(guī)劃考慮用戶體驗(yàn)去設(shè)計(jì)芍碧。
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
[圖片上傳中虐呻。掸掏。船殉。（11）]
(點(diǎn)擊放大圖像)
2****更振，互聯(lián)網(wǎng)財(cái)經(jīng)類公司炕桨，業(yè)務(wù)包括財(cái)經(jīng)網(wǎng)站、基金肯腕、股票献宫、金融等，這類公司的數(shù)據(jù)倉庫模型應(yīng)該如何設(shè)計(jì)实撒？特點(diǎn)和注意事項(xiàng)是什么姊途？案例介紹？十分感謝知态。
松子老師：我自己經(jīng)歷過的是互聯(lián)網(wǎng)金融以及移動互聯(lián)網(wǎng)行捷兰。對這兩塊比較清楚「好簦互聯(lián)網(wǎng)金融起因?yàn)闃I(yè)務(wù)的特性是類金融類的贡茅，與銀行有些地方是相似的。
比如大約在2012年前支付寶業(yè)務(wù)特點(diǎn)涉及類金融交易：充值原在、提現(xiàn)友扰、賬務(wù)管理類電子商務(wù)：購物交易過程變更、實(shí)際交易（對B機(jī)票庶柿、對C水電等） 非純電子商務(wù)村怪；純金融；個人信用浮庐，理財(cái)類甚负。系統(tǒng)之間依賴度較為復(fù)雜，垂直依賴（業(yè)務(wù)與核心）跨層依賴（跨過交易到賬務(wù)）审残。
在設(shè)計(jì)方法上還是采用維度模型設(shè)計(jì)方式梭域。底層是數(shù)據(jù)驅(qū)動為向?qū)ВY(jié)合業(yè)務(wù)需求驅(qū)動搅轿，通過簡單病涨、退化維度的方式拉寬表結(jié)構(gòu)。
底層采用松耦合設(shè)計(jì)璧坟。主題之間是松耦合方式既穆。至體內(nèi)采用細(xì)粒度退化維度赎懦。
在主題域上的的設(shè)計(jì)基本參考了OMG的數(shù)據(jù)倉庫元數(shù)據(jù)設(shè)計(jì)CWM模型、IBM 的fsdm金融模型幻工、還有新巴塞爾資本協(xié)議（Basel II Capital Accord）需提供數(shù)據(jù)規(guī)范去的設(shè)計(jì)励两。所以數(shù)據(jù)模型是五層的結(jié)構(gòu)。
在細(xì)節(jié)處理上囊颅，增量ODS層數(shù)據(jù)和前一天DWD相關(guān)表進(jìn)行 merge處理当悔。
在一些層次上，基本聚合踢代、匯總增加派生事實(shí)表（簡單一句話退化為度打?qū)挘┟ぴ鳌Ｈ缓蟀凑諛I(yè)務(wù)主體合并信息等。
比如開始給大家分享的那張圖：
(點(diǎn)擊放大圖像)
[圖片上傳中奸鬓。焙畔。掸读。（13）]
在維度模型退化處理時串远，要注意最細(xì)粒度數(shù)據(jù)保留、不同層次的數(shù)據(jù)支持?jǐn)?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ù)模型译红。
這種元數(shù)據(jù)驅(qū)動工具型數(shù)據(jù)產(chǎn)品我會在未來數(shù)據(jù)產(chǎn)品系列中做詳細(xì)介紹的。
3****隔显，互聯(lián)網(wǎng)企業(yè)大數(shù)據(jù)平臺的發(fā)展歷程是怎樣的？
松子老師：這個我相信應(yīng)該是傳統(tǒng)數(shù)據(jù)平臺朋友提到的饵逐。傳統(tǒng)行業(yè)數(shù)據(jù)平臺架構(gòu)演進(jìn)我總結(jié)簡單一句話說“基本上可以分為五個時代括眠、四種架構(gòu)”，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與類型暴增的特點(diǎn)倍权，從高階架構(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é)下來用戶特點(diǎn)：
(點(diǎn)擊放大圖像)
[圖片上傳中默辨。德频。。（14）]
更加詳細(xì)的每一代數(shù)據(jù)平臺建設(shè)缩幸、服務(wù)角色特點(diǎn)您可以看我這個系列文章的第三篇壹置，http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-paet02
4****档叔，有沒有好的元數(shù)據(jù)管理工具推薦？主要偏向數(shù)據(jù)字典與血統(tǒng)等蒸绩。
松子老師：元數(shù)據(jù)以前目前沒有太多的好管理工具衙四。以前是在支付寶是我自己設(shè)計(jì)的一個數(shù)據(jù)產(chǎn)品。第一版自己用Delphi 開發(fā)的患亿。
（圖很多：）
(點(diǎn)擊放大圖像)
[圖片上傳中传蹈。。步藕。（15）]
(點(diǎn)擊放大圖像)
[圖片上傳中惦界。。咙冗。（16）]
(點(diǎn)擊放大圖像)
[圖片上傳中沾歪。。雾消。（17）]
(點(diǎn)擊放大圖像)
[圖片上傳中灾搏。。立润。（18）]
(點(diǎn)擊放大圖像)
[圖片上傳中狂窑。。桑腮。（19）]
以前被逼的自己寫了一個泉哈，通過解析，實(shí)現(xiàn)了字段級的血緣影響分析破讨。這只是第二步丛晦，后來又把running 信息給搞了進(jìn)來。還有分享時提到的模型信息提陶、整個閉環(huán)的分類信息烫沙。
這是一個分支：
(點(diǎn)擊放大圖像)
[圖片上傳中。搁骑。斧吐。（20）]
但是我們實(shí)現(xiàn)了字段級解析準(zhǔn)確率達(dá)到了94%左右。有細(xì)微的錯誤就人工revew一遍仲器。
5. ****松子老師煤率，數(shù)據(jù)管控的數(shù)據(jù)質(zhì)量部分是怎么處理的呢？
松子老師： 數(shù)據(jù)管控乏冀， 這方面我不太懂的蝶糯，但是數(shù)據(jù)質(zhì)量，這玩意可大可小的辆沦。比如像在分享時說過的昼捍，在移動互聯(lián)網(wǎng)的數(shù)據(jù)質(zhì)量處理方式可以由原有的ETL(ELT)階段前置到業(yè)務(wù)系統(tǒng)去解決识虚，比如移動互聯(lián)網(wǎng)的App log 日志亩歹，日志標(biāo)準(zhǔn)化后事件模型”存儲來解決聘裁。那非app 日志類如何解決呢比如Payment、order等儿礼，數(shù)據(jù)質(zhì)量比較考慮的可以只做到監(jiān)控乍钻。
我來分享個圖肛循。剛好是我設(shè)計(jì)數(shù)據(jù)質(zhì)量產(chǎn)品時搞的，理清數(shù)據(jù)質(zhì)量的問題：
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
[圖片上傳中银择。多糠。。（22）]
(點(diǎn)擊放大圖像)
[圖片上傳中浩考。夹孔。。（23）]
只要數(shù)據(jù)進(jìn)入倉庫與應(yīng)用體系析孽，處理起來就比較困難了搭伤，所以在數(shù)據(jù)平臺階段最好是通過監(jiān)控、前置去解決绿淋。目前數(shù)據(jù)質(zhì)量確實(shí)難以100%由事后搞到事前去處理闷畸。我對數(shù)據(jù)平臺與數(shù)據(jù)產(chǎn)品的建設(shè)就是實(shí)用為主尝盼。怎么實(shí)用怎么來吞滞。我是比較現(xiàn)實(shí)的實(shí)用主義者。
6. ****能否分享一些數(shù)據(jù)產(chǎn)品種類及實(shí)例：
松子老師：在前邊五個問題盾沫、以及文章中又都涉及數(shù)據(jù)產(chǎn)品實(shí)力的一些分享裁赠。
提到數(shù)據(jù)產(chǎn)品的分類我就想把這個圖發(fā)出來。
自己認(rèn)為沒有特別明確的劃分線赴精，但是數(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工具逐哈、資源管控等等芬迄。
面向用戶功能有報(bào)表型、多維型數(shù)據(jù)產(chǎn)品昂秃、定制化數(shù)據(jù)產(chǎn)品禀梳、挖掘型數(shù)據(jù)產(chǎn)品杜窄。
面向內(nèi)部用戶、外部個人用戶算途、外部企業(yè)用戶又有不同的分類塞耕。
根據(jù)業(yè)務(wù)又可以劃分很多，面向C類用戶嘴瓤、面向B類商戶荷科、金融風(fēng)險(xiǎn)等等
從近幾年的數(shù)據(jù)產(chǎn)品來看，是更好的輔助用戶的做決策的一種產(chǎn)品形態(tài)纱注，在用戶的決策與行動中充當(dāng)信息的分析者與價值使用者畏浆；數(shù)據(jù)產(chǎn)品有個自己的共性：由解決的一個實(shí)際的業(yè)務(wù)問題出發(fā)，分解出的分析指標(biāo)狞贱，分析模型刻获，分析流程組成，再考慮到功能易用性瞎嬉，未來功能擴(kuò)展蝎毡，考慮用戶對數(shù)據(jù)易用性（比如數(shù)據(jù)的呈現(xiàn)層次，不可能一次把所有數(shù)據(jù)的呈現(xiàn)給用戶）來組成的氧枣。
(點(diǎn)擊放大圖像)
[圖片上傳中沐兵。。便监。（24）]
7. ****銀行業(yè)從傳統(tǒng)的ods到edw再到大數(shù)據(jù)平臺這塊過渡扎谎，模型如何建設(shè)？平臺優(yōu)勢如何發(fā)揮？
松子老師：這個問題還是有些難度的，自己回答的可能有些片面礼华。首先我們清醒的清楚“大數(shù)據(jù)”是什么绣否？再次不同的場景可以采用不同的技術(shù)去解決。
“大數(shù)據(jù)”，拆開來看大、數(shù)據(jù)，大可以是指的數(shù)據(jù)源結(jié)構(gòu)簡單（ps 如果了解過當(dāng)代對大數(shù)據(jù)的定義就知道四個特性）但是量級夠大拐叉，比如清算、結(jié)算扇商、對公凤瘦、對私、中間業(yè)務(wù)等等每一個拿出來都是幾十T钳吟，但是這些業(yè)務(wù)數(shù)據(jù)都是保存?zhèn)鹘y(tǒng)的關(guān)系型數(shù)據(jù)庫中如DB2廷粒、Oracle、MSsql中，因?yàn)樵跀?shù)據(jù)平臺存儲是通過準(zhǔn)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ù)的去演進(jìn)解決。（最早時我的是中信銀行次酌、光大銀行在2011年左右開始考慮Hadoop技術(shù)恨课，后來不知道如何了）。
但是互聯(lián)網(wǎng)的數(shù)據(jù)平臺技術(shù)大都是NOSQL模式岳服，犧牲掉了傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)一致性剂公、完整性、唯一索引等等吊宋，只干性能的事情（當(dāng)然除了性能纲辽、可擴(kuò)展性也是的）.
原有在傳統(tǒng)數(shù)據(jù)平臺模型設(shè)計(jì)上可以考慮的一些通過主外鍵、唯一索引做一些業(yè)務(wù)約束的方法璃搜，在nosql上統(tǒng)統(tǒng)的都沒有了拖吼，這些約束必須放到數(shù)據(jù)加工階段去想辦法做檢查。傳統(tǒng)數(shù)據(jù)平臺如果在Insert这吻、update數(shù)據(jù)時違反了業(yè)務(wù)約束可以做報(bào)警或異常處理吊档，但是在Nosql的平臺上要求ETL 去手動遵守這些規(guī)則檢查。但是有時ETL開發(fā)根本不遵守的唾糯，僅僅是兩個表關(guān)聯(lián)起來怠硼，也可能忘記按照某一個業(yè)務(wù)唯一索引做去重操作。簡單說趾断，原有靠關(guān)系型數(shù)據(jù)庫本身機(jī)制去做檢查一些規(guī)則變?yōu)槿斯ぞ苊優(yōu)槿斯ぞ蜁稿e。
從關(guān)系型數(shù)據(jù)平臺往Nosql數(shù)據(jù)平臺遷移時芋酌，尤其是對傳統(tǒng)行業(yè)的業(yè)務(wù)來說，在模型設(shè)計(jì)階段雁佳、以及給出的ETL口徑要考慮更多的業(yè)務(wù)規(guī)則檢查脐帝，其次要考慮更多的維度退化、多冗余糖权、表打?qū)捥幚矶赂埂：唵握f就是發(fā)揮數(shù)據(jù)平臺的計(jì)算能力同時要更加的各方面確保數(shù)據(jù)準(zhǔn)確安全可靠。
數(shù)據(jù)模型ODS 到EDW 這塊的設(shè)計(jì)方法百度上留下的文檔資料太多的了星澳，請這位提問的老師百度吧疚顷。
**8****．大數(shù)據(jù)****倉庫****中如何做快速****維處****理？互****聯(lián)****網(wǎng)數(shù)****倉****數(shù)據(jù)****質(zhì)****量不好如何****對****數(shù)，如何確立****標(biāo)****準(zhǔn)的****對****數(shù)口徑腿堤？******
松子老師：快速變化維度可以轉(zhuǎn)化為緩慢變化為來出來阀坏，我自己理解的快速維度是相對于緩慢維度參照的來說的。
舉個例子笆檀，年齡-轉(zhuǎn)化為天數(shù)可以是定義快速變化維度忌堂，因?yàn)槊刻於荚谧兓Ｎ覀兛梢园涯挲g退化為區(qū)間維度來處理酗洒，還可以把年齡做成動態(tài)維度來處理士修，事實(shí)表中保存的就是實(shí)際的出生年月并打?qū)挶恚挲g(天)通過計(jì)算方式來處理。還有種方法通過對代理鍵的方式來處理怎燥。
我目前也不知道對數(shù)據(jù)的標(biāo)準(zhǔn)是什么县爬。但是我自己用的方法，把一個指標(biāo)的整個數(shù)據(jù)流向切出幾個關(guān)鍵點(diǎn)通過SQL去實(shí)現(xiàn)對數(shù)封字，看波動振幅，波動曲線耍鬓。同時還會比如發(fā)不通的版本的小流量測試的方式來做數(shù)據(jù)校對阔籽。
9****． 做為數(shù)據(jù)行業(yè)從業(yè)者，需要掌握哪些重要的基礎(chǔ)知識牲蜀？另：如果從零開始建立一個數(shù)據(jù)平臺笆制，需要哪些資源配置（人，財(cái)涣达，物在辆，技術(shù)）？大致總投資額度多少度苔？如果同行產(chǎn)品間多種來源的數(shù)據(jù)匆篓，可有成熟的解決方案？謝謝…
松子老師：這個問題太宏觀了寇窑。作為數(shù)據(jù)行業(yè)從業(yè)者鸦概，需要掌握哪些重要基礎(chǔ)知識，這個是要看從事具體數(shù)據(jù)域的垂直行業(yè)甩骏。
比如說 數(shù)據(jù)開發(fā)窗市、數(shù)據(jù)模型、數(shù)據(jù)產(chǎn)品饮笛、數(shù)據(jù)分析師咨察、數(shù)據(jù)運(yùn)營、數(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ù)目標(biāo)不太明確下刊愚，難以確定方案踊跟，人員配置上選用不同技術(shù)方案去搭建的配置是不太一樣的，比如說傳統(tǒng)平臺來講鸥诽，運(yùn)維商玫、DBA、數(shù)據(jù)開發(fā)牡借、數(shù)據(jù)模型拳昌、報(bào)表人員。
從互聯(lián)網(wǎng)數(shù)據(jù)平臺基本配置上钠龙，數(shù)據(jù)架構(gòu)師炬藤、運(yùn)維、底層大數(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ù)。
10. Standalone****模式下壳炎，Model.save(Path)怎么一直提示錯誤泞歉，是不是配置Spark時需要將Hdfs的配置引進(jìn)來啊～？表示初學(xué)Spark
松子老師：這個問題有點(diǎn)超出我的能力范圍了冕广，所以對不起回答不了璃饱。
我本身不是做技術(shù)的慧妄。僅知道一點(diǎn)技術(shù)名詞。
11. ****傳統(tǒng)銀行業(yè)數(shù)據(jù)模型什么時候會走向互聯(lián)網(wǎng)模式呢巢钓？目前在傳統(tǒng)銀行數(shù)據(jù)平臺的產(chǎn)品是不是特別多涕滋？
松子老師：這個問題我自己就不知道了睬辐，或許是傳統(tǒng)銀行在數(shù)據(jù)平臺的實(shí)施上全面用互聯(lián)網(wǎng)的Nosql大數(shù)據(jù)處理技術(shù)吧。至于說傳統(tǒng)銀行數(shù)據(jù)模型用現(xiàn)有的互聯(lián)網(wǎng)數(shù)據(jù)模型理念去設(shè)計(jì)是否完全可行，數(shù)據(jù)一致性溯饵、高準(zhǔn)確性通過更多的方案去保證侵俗。
首先我需要確定一下這個產(chǎn)品是否指的“數(shù)據(jù)產(chǎn)品”。
如果是數(shù)據(jù)產(chǎn)品丰刊，那其實(shí)傳統(tǒng)行業(yè)數(shù)據(jù)平臺本身就有一些數(shù)據(jù)產(chǎn)品了隘谣，而且也都是存在的。數(shù)據(jù)產(chǎn)品自從數(shù)據(jù)倉庫出現(xiàn)以來它其實(shí)一直都存在的啄巧，只不過是近幾年因?yàn)榛ヂ?lián)網(wǎng)特別愛制造“流行詞“把數(shù)據(jù)產(chǎn)品這個詞給放大了寻歧。互聯(lián)網(wǎng)是得數(shù)據(jù)產(chǎn)品從早期的重量級逐漸進(jìn)化為輕量級秩仆、從大而全的解決方案逐漸演進(jìn)為因小而美码泛。
我來給出幾組例子，大約從2004年到現(xiàn)在的幾組數(shù)據(jù)產(chǎn)品的例子
(點(diǎn)擊放大圖像)
[圖片上傳中澄耍。噪珊。。（25）]
(點(diǎn)擊放大圖像)
[圖片上傳中齐莲。痢站。。（26）]
(點(diǎn)擊放大圖像)
[圖片上傳中选酗。阵难。。（27）]
(點(diǎn)擊放大圖像)
[圖片上傳中星掰。多望。。（28）]
(點(diǎn)擊放大圖像)
[圖片上傳中氢烘。怀偷。。（29）]
(點(diǎn)擊放大圖像)
[圖片上傳中播玖。椎工。。（30）]
(點(diǎn)擊放大圖像)
[圖片上傳中蜀踏。维蒙。。（31）]
你可以分類一下果覆，這些數(shù)據(jù)產(chǎn)品的特點(diǎn)是什么颅痊？滿足了用戶怎么樣的痛點(diǎn)需求？滿足了用戶怎么樣的使用流程局待。
12 ****斑响。傳統(tǒng)行業(yè)的數(shù)據(jù)倉庫從業(yè)人員菱属，如果轉(zhuǎn)到互聯(lián)網(wǎng)行業(yè)，應(yīng)該學(xué)習(xí)哪些技能舰罚？
松子老師：這個問題你可以百度搜索“大數(shù)據(jù)職位所需要的數(shù)據(jù)技能” http://blog.jobbole.com/99039/ 這篇文章纽门。自己覺得人家回答的比我專業(yè)。//
我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史（四）：互聯(lián)網(wǎng)時代 ? 下篇
http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-internet-age
編者按：本文是松子（李博源）的大數(shù)據(jù)平臺發(fā)展史系列文章的第四篇（共四篇）营罢，本系列以獨(dú)特的視角赏陵，比較了非互聯(lián)網(wǎng)和互聯(lián)網(wǎng)兩個時代以及傳統(tǒng)行業(yè)與非傳統(tǒng)行業(yè)。是對數(shù)據(jù)平臺發(fā)展的一個回憶饲漾，對非互聯(lián)網(wǎng)蝙搔、互聯(lián)網(wǎng)，從數(shù)據(jù)平臺的用戶角度能颁、數(shù)據(jù)架構(gòu)演進(jìn)杂瘸、模型等進(jìn)行了闡述。
在互聯(lián)網(wǎng)時代被弱化的數(shù)據(jù)模型
談起數(shù)據(jù)模型就不得不提傳統(tǒng)數(shù)據(jù)平臺架構(gòu)發(fā)展伙菊，我相信很多朋友都曉得傳統(tǒng)數(shù)據(jù)平臺的知識败玉，其架構(gòu)演進(jìn)簡單一句話說“基本上可以分為五個時代靡努、四種架構(gòu)”熬荆，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與數(shù)據(jù)源類型多樣化特點(diǎn)唾戚，從高階架構(gòu)上來看大約從傳統(tǒng)數(shù)據(jù)平臺第三代架構(gòu)開始延續(xù)的杠娱，但是往后的發(fā)展從我自己的這一點(diǎn)知識上很難對互聯(lián)網(wǎng)的數(shù)據(jù)平臺做架構(gòu)歸類。
但是從數(shù)據(jù)平臺建設(shè)與服務(wù)角色上還是有章可循的拟糕。就像上篇分享到那樣注祖，類比兩個行業(yè)谓厘，互聯(lián)網(wǎng)企業(yè)中員工年齡比非互聯(lián)網(wǎng)企業(yè)的要年輕财剖、受教育程度悠夯、對計(jì)算機(jī)的焦慮程度明顯比傳統(tǒng)企業(yè)要低、還偶遇其它各方面的緣故躺坟，導(dǎo)致了數(shù)據(jù)平臺所面對用戶群體與非互聯(lián)網(wǎng)數(shù)據(jù)平臺有所差異化沦补。
傳統(tǒng)行業(yè)與互聯(lián)網(wǎng)行業(yè)數(shù)據(jù)平臺用戶特性我只選擇前文章的兩張圖來表示
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
在傳統(tǒng)數(shù)據(jù)平臺要背后有一個完整數(shù)據(jù)倉庫團(tuán)隊(duì)去服務(wù)業(yè)務(wù)方，業(yè)務(wù)方嗷嗷待哺的等待被動方式去滿足咪橙。中低層數(shù)據(jù)基本不會對業(yè)務(wù)方開放夕膀，所以不管數(shù)據(jù)模型采用何種建模方式，主要滿足當(dāng)時數(shù)據(jù)架構(gòu)規(guī)劃即可美侦。
互聯(lián)網(wǎng)業(yè)務(wù)的快速發(fā)展使得大家已經(jīng)從經(jīng)營产舞、分析的訴求重點(diǎn)轉(zhuǎn)為數(shù)據(jù)化的精細(xì)運(yùn)營上，如何做好精細(xì)化運(yùn)營問題上來菠剩，當(dāng)資源不夠時用戶就叫喊易猫，甚至有的業(yè)務(wù)方會挽起袖子來自己參與到從數(shù)據(jù)整理、加工具壮、分析階段擦囊。
此時呢违霞，原有建設(shè)數(shù)據(jù)平臺的多個角色（數(shù)據(jù)開發(fā)嘴办、模型設(shè)計(jì)）可能轉(zhuǎn)為對其它非專業(yè)使用數(shù)據(jù)方瞬场，做培訓(xùn)、咨詢與落地涧郊，寫更加適合當(dāng)前企業(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àn)椴粚I(yè)性彤灶，導(dǎo)致數(shù)據(jù)質(zhì)量問題、重復(fù)對分?jǐn)?shù)據(jù)浪費(fèi)存儲與資源批旺、口徑多樣化幌陕、編碼不統(tǒng)一、命名問題等等原因汽煮。數(shù)據(jù)質(zhì)量逐漸變成一個特別突出的問題搏熄。
傳統(tǒng)企業(yè)的數(shù)據(jù)源基本來自excel、表格暇赤、DB系統(tǒng)等心例，但在互聯(lián)網(wǎng)有網(wǎng)站點(diǎn)擊流日志、視頻鞋囊、音頻止后、圖片數(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ù)有些力不從心歉糜。
當(dāng)數(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è)也有自己特點(diǎn)，傳統(tǒng)行業(yè)所涉及數(shù)據(jù)模型這個領(lǐng)域涉及的很多內(nèi)容在互聯(lián)網(wǎng)變成以其他的曲線救國的方式存在了费就。
在互聯(lián)網(wǎng)曲線救國新解決
回顧在傳統(tǒng)行業(yè)數(shù)據(jù)平臺中，不管兩位大師爭論點(diǎn)數(shù)據(jù)模型的設(shè)計(jì)采用那種范式（Bill Inmon的EDW的原則是準(zhǔn)三范式的設(shè)計(jì)姐呐、Ralph kilmbal是星型結(jié)構(gòu)）但是都要非常重視數(shù)據(jù)源的質(zhì)量問題。所以傳統(tǒng)行業(yè)的數(shù)據(jù)模型會全盤考慮數(shù)據(jù)質(zhì)量問題典蝌，并通過數(shù)據(jù)抽樣分析給出合適的清洗口徑曙砂。
(點(diǎn)擊放大圖像)
上圖來自我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ù)”對一年的還是不準(zhǔn)的）截驮。在應(yīng)對數(shù)據(jù)的質(zhì)量問題笑陈，目前互聯(lián)網(wǎng)有些做法是把數(shù)據(jù)標(biāo)準(zhǔn)化前置到業(yè)務(wù)數(shù)據(jù)產(chǎn)生就做，從根源上去杜絕數(shù)據(jù)質(zhì)量葵袭，但是這種場景比較實(shí)用在Log 日志的數(shù)據(jù)源中涵妥，比如移動互聯(lián)網(wǎng)最近流行的基于事件模型“Event”模型，在日志產(chǎn)生時就規(guī)定好存儲格式（備注：大家度娘搜索坡锡，“學(xué)習(xí)筆記：The Log（我所讀過的最好的一篇分布式技術(shù)文章）” 對這個講解很詳細(xì)）蓬网。
在傳統(tǒng)行業(yè)，目前還是以混合模型設(shè)計(jì)方式為主娜氏。在互聯(lián)網(wǎng)的我所接觸的一些業(yè)務(wù)拳缠，在參照傳統(tǒng)數(shù)據(jù)模型方法論基礎(chǔ)上逐步演進(jìn)適合互聯(lián)網(wǎng)數(shù)據(jù)的數(shù)據(jù)模型方法。
比如互聯(lián)網(wǎng)金融等一些業(yè)務(wù)會參考傳統(tǒng)金融行業(yè)對主題域的劃分贸弥、OMG數(shù)據(jù)倉庫元數(shù)據(jù)管理CWM模型窟坐、FSDM金融模型，再進(jìn)一步考慮大數(shù)據(jù)處理特性去進(jìn)行設(shè)計(jì)绵疲，所有從Hight Level 數(shù)據(jù)架構(gòu)圖看到主題層次劃分與傳統(tǒng)第三代數(shù)據(jù)倉庫還是很多相似之處哲鸳，當(dāng)然模型架構(gòu)也有分三層、四層盔憨、五層的徙菠。
不同的地方模型細(xì)節(jié)處理上已經(jīng)完全不一樣，比如數(shù)據(jù)的多樣性郁岩、拉寬事實(shí)表婿奔、度量值單獨(dú)存儲、滿足數(shù)據(jù)快速重生问慎、維度的二次降維處理等萍摊、增加大量冗余列、增加大量派生列如叼，結(jié)合自動化元數(shù)據(jù)來耦合冰木、合并等相關(guān)管理。
(點(diǎn)擊放大圖像)
[圖片上傳中。踊沸。歇终。（4）]
上圖是支付寶非常早期數(shù)據(jù)模型
(點(diǎn)擊放大圖像)
上圖是支付寶非常早期數(shù)據(jù)模型
我們常提到的多維模型在大數(shù)據(jù)處理下進(jìn)行了退化維度處理。大家知道Olap多維模型逼龟，隨著維度的增加事實(shí)表的數(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è)計(jì)多維挖掘分析數(shù)據(jù)產(chǎn)品背后的技術(shù)就是搜索引擎實(shí)現(xiàn)的）肥哎，現(xiàn)在應(yīng)該也有新技術(shù)出現(xiàn)了來解決類似的問題。
(點(diǎn)擊放大圖像)
上圖為2012年產(chǎn)品UI之一疾渣。
(點(diǎn)擊放大圖像)
上圖是2011-2012年該產(chǎn)品系列背后當(dāng)時使用的技術(shù)
互聯(lián)網(wǎng)業(yè)務(wù)特點(diǎn)業(yè)務(wù)垂直拆分非常細(xì)，比如一個用戶注冊崖飘、密碼找回的流程有可能存在好幾個產(chǎn)品負(fù)責(zé)同一個業(yè)務(wù)流程不同環(huán)節(jié)榴捡，相關(guān)的一個策略、產(chǎn)品feature快速迭代上線等等都要數(shù)據(jù)評估朱浴。數(shù)據(jù)從前端埋點(diǎn)到采集然后再由各個環(huán)節(jié)到數(shù)據(jù)平臺吊圾，再有數(shù)據(jù)分析師或各業(yè)務(wù)部門去使用，基本拉長了時間周期翰蠢。需求部門與實(shí)施部門能力和經(jīng)驗(yàn)有千差萬別的需求项乒，造成了懂技術(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ù)特點(diǎn)是變化非常迅速的，能穩(wěn)定的業(yè)務(wù)達(dá)到65%算對數(shù)據(jù)平臺是個福音了（根據(jù)對某寶寶的印象）剩余的業(yè)務(wù)變化迅速衔统，必然導(dǎo)致數(shù)據(jù)模型快速上下線提针。
Kimball老人家提出的維度建模（備注，在本系列發(fā)展史得第一篇有介紹）圍繞業(yè)務(wù)模型能夠非常直觀的表達(dá)出業(yè)務(wù)的數(shù)據(jù)關(guān)系施敢，但是在互聯(lián)網(wǎng)NOSQL犧牲掉了關(guān)系型數(shù)據(jù)庫的一致性周荐、完整性等等很多東西。維度數(shù)據(jù)模型又基于這些大數(shù)據(jù)技術(shù)的僵娃，所以進(jìn)化的更加輕量級與基于細(xì)節(jié)數(shù)據(jù)的維度退化建模（原有的緩慢變化維概作、快速變化維、大維悯许、迷你維仆嗦、父子維、雪花維為了適應(yīng)互聯(lián)網(wǎng)的大數(shù)據(jù)Nosql處理技術(shù)進(jìn)行反規(guī)范化先壕、化&數(shù)據(jù)冗余設(shè)計(jì)瘩扼。
退化維度的反規(guī)范化設(shè)計(jì)一方面可以把一條查詢語句所需要的所有數(shù)據(jù)組合起來放到一個地方存儲 Key values 的方式（比如說商品有不同類型谆甜，每一種類型商品又有自己的不同屬性，可以采用一對多集绰、多對多的方式存儲规辱，例如把一個多維映射為一個Key value）。
講到互聯(lián)網(wǎng)數(shù)據(jù)平臺就要提數(shù)據(jù)模型栽燕，提了數(shù)據(jù)模型就要提Nosql技術(shù)罕袋，
(點(diǎn)擊放大圖像)
上圖來自Nosql文檔系列的一幅圖
Nosql 是大數(shù)據(jù)處理的特征之一“恚互聯(lián)網(wǎng)數(shù)據(jù)平臺數(shù)據(jù)模型與NoSql技術(shù)還是蠻緊密的浴讯。這里有外文講解Nosql Data modeling technigues 從技術(shù)角度講解非常詳（https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/）。
因?yàn)榍斑吿岬降拇髷?shù)據(jù)平臺技術(shù)特性決定了傳統(tǒng)edw模型蔼啦、維度模型直接在互聯(lián)網(wǎng)數(shù)據(jù)大數(shù)據(jù)平臺部署或許還有“好些未知”障礙等待大家去克服榆纽。同時在傳統(tǒng)數(shù)據(jù)建模用到的一些方法經(jīng)過互聯(lián)網(wǎng)熏陶或許演進(jìn)成一種新的數(shù)據(jù)產(chǎn)品或方案吧。
到此為止“我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史”上下共四篇與大家分享完畢捏肢，這個寫作前后經(jīng)歷剛好一個月左右奈籽，算是對自己數(shù)據(jù)從業(yè)經(jīng)歷回顧之一吧。在知識的整理中很多都是蜻蜓點(diǎn)水鸵赫，每個知識域都是一個非常深的專業(yè)方向衣屏，自己涉足很膚淺，在文章中分享不足之處請各位讀者見諒１绨簟狼忱！
個人郵箱是5592094@qq.com 歡迎電郵交流。
接下來我會進(jìn)入數(shù)據(jù)產(chǎn)品這個領(lǐng)域的分享盗温，當(dāng)年車品覺老師自豪的作品之一“黃金策”藕赞，我是數(shù)據(jù)產(chǎn)品經(jīng)理。（ps：自己躲在墻角拿車品覺老師往自己臉上貼金了）卖局。
后記
有一次數(shù)據(jù)產(chǎn)品神策的創(chuàng)始人兼好友@桑文鋒＠SensorsData跟我說來做次分享吧斧蜕，我當(dāng)時出了幾個題目，最后就選擇了“我所經(jīng)歷的大數(shù)據(jù)平臺“砚偶，就形成了大家看到的”我所經(jīng)歷的大數(shù)據(jù)平臺“系列文章.
在整理期間得到了死黨@周愛民批销、@神策-桑文峰、 InfoQ小編@Tina Du 染坯、@betty zhou @Laurel大力協(xié)助均芽，在這里感謝！５ヂ埂掀宋！
番外篇
這一篇是在24日舉行的分享大家提到的一些問題，經(jīng)過整理算是對正文的補(bǔ)充吧，從互聯(lián)網(wǎng)敏捷數(shù)據(jù)模型等角度做了較深入的細(xì)節(jié)介紹劲妙。同時在數(shù)據(jù)產(chǎn)品方面的回答包含了一點(diǎn)未來寫作篇“數(shù)據(jù)產(chǎn)品”系列的一點(diǎn)內(nèi)容湃鹊。
1****，傳統(tǒng)我們做BI的镣奋，做數(shù)據(jù)展現(xiàn)會建模后以pivot展現(xiàn)cube數(shù)據(jù)具伍，不知道現(xiàn)在互聯(lián)網(wǎng)公司數(shù)據(jù)展示如何做的檐晕？第三方工具還是用API取數(shù)據(jù)平臺里的數(shù)據(jù)独旷？adhoc報(bào)表及靈活更換維度的時候web端一般是怎么做的构眯？
松子老師：剛才文章中提到了比如傳統(tǒng)行業(yè)的多維數(shù)據(jù)模型cube。在互聯(lián)網(wǎng)采用的曲線救國方式解決的哈垢。 在分享中我給出了幾個圖妻柒。就是通過搜索引擎曲線救國方式實(shí)現(xiàn)類似Olap的模擬。
在這塊的模型的處理上采用的是維度退化處理温赔。通過反規(guī)范化蛤奢，數(shù)據(jù)項(xiàng)、數(shù)據(jù)冗余去處理陶贼。在前端做特殊處理。
這個當(dāng)時產(chǎn)品原型之一：
(點(diǎn)擊放大圖像)
這是一個2011年-2012年左右的數(shù)據(jù)產(chǎn)品待秃，當(dāng)時算是即時計(jì)算的一種拜秧。不過已經(jīng)過去好幾年了，當(dāng)今新技術(shù)下Olap 引擎應(yīng)該有很好的提升章郁。
目前我知道的家互聯(lián)網(wǎng)公司枉氮，在前端展現(xiàn)有使用第三方套件比如spagoBi、pentaho 等 有自己設(shè)計(jì)開發(fā)定制化數(shù)據(jù)前端展現(xiàn)暖庄。比如我剛開始分享的那兩個之前在去哪兒網(wǎng)設(shè)計(jì)的數(shù)據(jù)平臺內(nèi)部界面之一聊替，當(dāng)然數(shù)據(jù)產(chǎn)品是另一個話題了，通過對數(shù)據(jù)分析抽象指標(biāo)培廓、分析模型惹悄、用戶使用功能與流程、未來規(guī)劃考慮用戶體驗(yàn)去設(shè)計(jì)肩钠。
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
[圖片上傳中泣港。。价匠。（11）]
(點(diǎn)擊放大圖像)
2****当纱，互聯(lián)網(wǎng)財(cái)經(jīng)類公司，業(yè)務(wù)包括財(cái)經(jīng)網(wǎng)站踩窖、基金坡氯、股票、金融等，這類公司的數(shù)據(jù)倉庫模型應(yīng)該如何設(shè)計(jì)箫柳？特點(diǎn)和注意事項(xiàng)是什么手形？案例介紹？十分感謝滞时。
松子老師：我自己經(jīng)歷過的是互聯(lián)網(wǎng)金融以及移動互聯(lián)網(wǎng)行叁幢。對這兩塊比較清楚∑夯互聯(lián)網(wǎng)金融起因?yàn)闃I(yè)務(wù)的特性是類金融類的曼玩，與銀行有些地方是相似的。
比如大約在2012年前支付寶業(yè)務(wù)特點(diǎn)涉及類金融交易：充值窒百、提現(xiàn)黍判、賬務(wù)管理類電子商務(wù)：購物交易過程變更、實(shí)際交易（對B機(jī)票篙梢、對C水電等） 非純電子商務(wù)顷帖；純金融；個人信用渤滞，理財(cái)類贬墩。系統(tǒng)之間依賴度較為復(fù)雜，垂直依賴（業(yè)務(wù)與核心）跨層依賴（跨過交易到賬務(wù)）妄呕。
在設(shè)計(jì)方法上還是采用維度模型設(shè)計(jì)方式陶舞。底層是數(shù)據(jù)驅(qū)動為向?qū)ВY(jié)合業(yè)務(wù)需求驅(qū)動绪励，通過簡單肿孵、退化維度的方式拉寬表結(jié)構(gòu)。
底層采用松耦合設(shè)計(jì)疏魏。主題之間是松耦合方式停做。至體內(nèi)采用細(xì)粒度退化維度。
在主題域上的的設(shè)計(jì)基本參考了OMG的數(shù)據(jù)倉庫元數(shù)據(jù)設(shè)計(jì)CWM模型大莫、IBM 的fsdm金融模型纤掸、還有新巴塞爾資本協(xié)議（Basel II Capital Accord）需提供數(shù)據(jù)規(guī)范去的設(shè)計(jì)挎袜。所以數(shù)據(jù)模型是五層的結(jié)構(gòu)后频。
在細(xì)節(jié)處理上吴藻，增量ODS層數(shù)據(jù)和前一天DWD相關(guān)表進(jìn)行 merge處理。
在一些層次上懈凹，基本聚合蜀变、匯總增加派生事實(shí)表（簡單一句話退化為度打?qū)挘Ｈ缓蟀凑諛I(yè)務(wù)主體合并信息等介评。
比如開始給大家分享的那張圖：
(點(diǎn)擊放大圖像)
[圖片上傳中库北。爬舰。。（13）]
在維度模型退化處理時寒瓦，要注意最細(xì)粒度數(shù)據(jù)保留情屹、不同層次的數(shù)據(jù)支持?jǐn)?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ù)模型惜颇。
這種元數(shù)據(jù)驅(qū)動工具型數(shù)據(jù)產(chǎn)品我會在未來數(shù)據(jù)產(chǎn)品系列中做詳細(xì)介紹的。
3****少辣，互聯(lián)網(wǎng)企業(yè)大數(shù)據(jù)平臺的發(fā)展歷程是怎樣的凌摄？
松子老師：這個我相信應(yīng)該是傳統(tǒng)數(shù)據(jù)平臺朋友提到的。傳統(tǒng)行業(yè)數(shù)據(jù)平臺架構(gòu)演進(jìn)我總結(jié)簡單一句話說“基本上可以分為五個時代漓帅、四種架構(gòu)”锨亏，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與類型暴增的特點(diǎn)，從高階架構(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é)下來用戶特點(diǎn)：
(點(diǎn)擊放大圖像)
[圖片上傳中。弓乙。。（14）]
更加詳細(xì)的每一代數(shù)據(jù)平臺建設(shè)钧惧、服務(wù)角色特點(diǎn)您可以看我這個系列文章的第三篇暇韧，http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-paet02
4****，有沒有好的元數(shù)據(jù)管理工具推薦浓瞪？主要偏向數(shù)據(jù)字典與血統(tǒng)等懈玻。
松子老師：元數(shù)據(jù)以前目前沒有太多的好管理工具。以前是在支付寶是我自己設(shè)計(jì)的一個數(shù)據(jù)產(chǎn)品乾颁。第一版自己用Delphi 開發(fā)的涂乌。
（圖很多：）
(點(diǎn)擊放大圖像)
[圖片上傳中。英岭。湾盒。（15）]
(點(diǎn)擊放大圖像)
[圖片上傳中。诅妹。罚勾。（16）]
(點(diǎn)擊放大圖像)
[圖片上傳中毅人。。尖殃。（17）]
(點(diǎn)擊放大圖像)
[圖片上傳中丈莺。。送丰。（18）]
(點(diǎn)擊放大圖像)
[圖片上傳中缔俄。。器躏。（19）]
以前被逼的自己寫了一個俐载，通過解析，實(shí)現(xiàn)了字段級的血緣影響分析邀桑。這只是第二步瞎疼，后來又把running 信息給搞了進(jìn)來辣之。還有分享時提到的模型信息蹄衷、整個閉環(huán)的分類信息谷婆。
這是一個分支：
(點(diǎn)擊放大圖像)
[圖片上傳中案狠。呐能。刘急。（20）]
但是我們實(shí)現(xiàn)了字段級解析準(zhǔn)確率達(dá)到了94%左右奕扣。有細(xì)微的錯誤就人工revew一遍丙挽。
5. ****松子老師令杈，數(shù)據(jù)管控的數(shù)據(jù)質(zhì)量部分是怎么處理的呢走敌？
松子老師： 數(shù)據(jù)管控， 這方面我不太懂的逗噩，但是數(shù)據(jù)質(zhì)量掉丽，這玩意可大可小的。比如像在分享時說過的异雁，在移動互聯(lián)網(wǎng)的數(shù)據(jù)質(zhì)量處理方式可以由原有的ETL(ELT)階段前置到業(yè)務(wù)系統(tǒng)去解決捶障，比如移動互聯(lián)網(wǎng)的App log 日志，日志標(biāo)準(zhǔn)化后事件模型”存儲來解決纲刀。那非app 日志類如何解決呢比如Payment项炼、order等，數(shù)據(jù)質(zhì)量比較考慮的可以只做到監(jiān)控示绊。
我來分享個圖锭部。剛好是我設(shè)計(jì)數(shù)據(jù)質(zhì)量產(chǎn)品時搞的，理清數(shù)據(jù)質(zhì)量的問題：
(點(diǎn)擊放大圖像)
[圖片上傳中面褐。拌禾。。（21）]
(點(diǎn)擊放大圖像)
[圖片上傳中盆耽。蹋砚。扼菠。（22）]
(點(diǎn)擊放大圖像)
[圖片上傳中。坝咐。循榆。（23）]
只要數(shù)據(jù)進(jìn)入倉庫與應(yīng)用體系，處理起來就比較困難了墨坚，所以在數(shù)據(jù)平臺階段最好是通過監(jiān)控秧饮、前置去解決。目前數(shù)據(jù)質(zhì)量確實(shí)難以100%由事后搞到事前去處理泽篮。我對數(shù)據(jù)平臺與數(shù)據(jù)產(chǎn)品的建設(shè)就是實(shí)用為主盗尸。怎么實(shí)用怎么來。我是比較現(xiàn)實(shí)的實(shí)用主義者帽撑。
6. ****能否分享一些數(shù)據(jù)產(chǎn)品種類及實(shí)例：
松子老師：在前邊五個問題泼各、以及文章中又都涉及數(shù)據(jù)產(chǎn)品實(shí)力的一些分享。
提到數(shù)據(jù)產(chǎn)品的分類我就想把這個圖發(fā)出來亏拉。
自己認(rèn)為沒有特別明確的劃分線扣蜻，但是數(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工具亿笤、資源管控等等。
面向用戶功能有報(bào)表型栋猖、多維型數(shù)據(jù)產(chǎn)品责嚷、定制化數(shù)據(jù)產(chǎn)品、挖掘型數(shù)據(jù)產(chǎn)品掂铐。
面向內(nèi)部用戶、外部個人用戶揍异、外部企業(yè)用戶又有不同的分類全陨。
根據(jù)業(yè)務(wù)又可以劃分很多仑嗅，面向C類用戶刁品、面向B類商戶、金融風(fēng)險(xiǎn)等等
從近幾年的數(shù)據(jù)產(chǎn)品來看振诬，是更好的輔助用戶的做決策的一種產(chǎn)品形態(tài)戚嗅，在用戶的決策與行動中充當(dāng)信息的分析者與價值使用者雨涛；數(shù)據(jù)產(chǎn)品有個自己的共性：由解決的一個實(shí)際的業(yè)務(wù)問題出發(fā)枢舶，分解出的分析指標(biāo)，分析模型替久，分析流程組成凉泄，再考慮到功能易用性，未來功能擴(kuò)展蚯根，考慮用戶對數(shù)據(jù)易用性（比如數(shù)據(jù)的呈現(xiàn)層次后众，不可能一次把所有數(shù)據(jù)的呈現(xiàn)給用戶）來組成的。
(點(diǎn)擊放大圖像)
[圖片上傳中颅拦。蒂誉。。（24）]
7. ****銀行業(yè)從傳統(tǒng)的ods到edw再到大數(shù)據(jù)平臺這塊過渡距帅，模型如何建設(shè)右锨？平臺優(yōu)勢如何發(fā)揮？
松子老師：這個問題還是有些難度的碌秸，自己回答的可能有些片面绍移。首先我們清醒的清楚“大數(shù)據(jù)”是什么？再次不同的場景可以采用不同的技術(shù)去解決哮肚。
“大數(shù)據(jù)”登夫，拆開來看大、數(shù)據(jù)允趟，大可以是指的數(shù)據(jù)源結(jié)構(gòu)簡單（ps 如果了解過當(dāng)代對大數(shù)據(jù)的定義就知道四個特性）但是量級夠大恼策，比如清算、結(jié)算潮剪、對公涣楷、對私、中間業(yè)務(wù)等等每一個拿出來都是幾十T抗碰，但是這些業(yè)務(wù)數(shù)據(jù)都是保存?zhèn)鹘y(tǒng)的關(guān)系型數(shù)據(jù)庫中如DB2狮斗、Oracle、MSsql中弧蝇，因?yàn)樵跀?shù)據(jù)平臺存儲是通過準(zhǔn)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ù)的去演進(jìn)解決两芳。（最早時我的是中信銀行摔寨、光大銀行在2011年左右開始考慮Hadoop技術(shù)，后來不知道如何了）怖辆。
但是互聯(lián)網(wǎng)的數(shù)據(jù)平臺技術(shù)大都是NOSQL模式是复，犧牲掉了傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)一致性删顶、完整性、唯一索引等等淑廊，只干性能的事情（當(dāng)然除了性能逗余、可擴(kuò)展性也是的）.
原有在傳統(tǒng)數(shù)據(jù)平臺模型設(shè)計(jì)上可以考慮的一些通過主外鍵、唯一索引做一些業(yè)務(wù)約束的方法蒋纬，在nosql上統(tǒng)統(tǒng)的都沒有了猎荠，這些約束必須放到數(shù)據(jù)加工階段去想辦法做檢查。傳統(tǒng)數(shù)據(jù)平臺如果在Insert蜀备、update數(shù)據(jù)時違反了業(yè)務(wù)約束可以做報(bào)警或異常處理关摇，但是在Nosql的平臺上要求ETL 去手動遵守這些規(guī)則檢查。但是有時ETL開發(fā)根本不遵守的碾阁，僅僅是兩個表關(guān)聯(lián)起來输虱，也可能忘記按照某一個業(yè)務(wù)唯一索引做去重操作。簡單說脂凶，原有靠關(guān)系型數(shù)據(jù)庫本身機(jī)制去做檢查一些規(guī)則變?yōu)槿斯は芏茫優(yōu)槿斯ぞ蜁稿e。
從關(guān)系型數(shù)據(jù)平臺往Nosql數(shù)據(jù)平臺遷移時，尤其是對傳統(tǒng)行業(yè)的業(yè)務(wù)來說，在模型設(shè)計(jì)階段因悲、以及給出的ETL口徑要考慮更多的業(yè)務(wù)規(guī)則檢查，其次要考慮更多的維度退化罪帖、多冗余、表打?qū)捥幚碛势ā：唵握f就是發(fā)揮數(shù)據(jù)平臺的計(jì)算能力同時要更加的各方面確保數(shù)據(jù)準(zhǔn)確安全可靠整袁。
數(shù)據(jù)模型ODS 到EDW 這塊的設(shè)計(jì)方法百度上留下的文檔資料太多的了，請這位提問的老師百度吧佑吝。
**8****．大數(shù)據(jù)****倉庫****中如何做快速****維處****理坐昙？互****聯(lián)****網(wǎng)數(shù)****倉****數(shù)據(jù)****質(zhì)****量不好如何****對****數(shù)，如何確立****標(biāo)****準(zhǔn)的****對****數(shù)口徑芋忿？******
松子老師：快速變化維度可以轉(zhuǎn)化為緩慢變化為來出來炸客，我自己理解的快速維度是相對于緩慢維度參照的來說的。
舉個例子戈钢，年齡-轉(zhuǎn)化為天數(shù)可以是定義快速變化維度嚷量，因?yàn)槊刻於荚谧兓Ｎ覀兛梢园涯挲g退化為區(qū)間維度來處理逆趣，還可以把年齡做成動態(tài)維度來處理，事實(shí)表中保存的就是實(shí)際的出生年月并打?qū)挶硎壤挲g(天)通過計(jì)算方式來處理宣渗。還有種方法通過對代理鍵的方式來處理抖所。
我目前也不知道對數(shù)據(jù)的標(biāo)準(zhǔn)是什么。但是我自己用的方法痕囱，把一個指標(biāo)的整個數(shù)據(jù)流向切出幾個關(guān)鍵點(diǎn)通過SQL去實(shí)現(xiàn)對數(shù)田轧，看波動振幅，波動曲線鞍恢。同時還會比如發(fā)不通的版本的小流量測試的方式來做數(shù)據(jù)校對傻粘。
9****． 做為數(shù)據(jù)行業(yè)從業(yè)者，需要掌握哪些重要的基礎(chǔ)知識帮掉？另：如果從零開始建立一個數(shù)據(jù)平臺弦悉，需要哪些資源配置（人，財(cái)蟆炊，物稽莉，技術(shù)）？大致總投資額度多少涩搓？如果同行產(chǎn)品間多種來源的數(shù)據(jù)污秆，可有成熟的解決方案？謝謝…
松子老師：這個問題太宏觀了昧甘。作為數(shù)據(jù)行業(yè)從業(yè)者良拼，需要掌握哪些重要基礎(chǔ)知識，這個是要看從事具體數(shù)據(jù)域的垂直行業(yè)充边。
比如說 數(shù)據(jù)開發(fā)庸推、數(shù)據(jù)模型、數(shù)據(jù)產(chǎn)品痛黎、數(shù)據(jù)分析師予弧、數(shù)據(jù)運(yùn)營、數(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ù)目標(biāo)不太明確下器赞，難以確定方案，人員配置上選用不同技術(shù)方案去搭建的配置是不太一樣的墓拜，比如說傳統(tǒng)平臺來講港柜，運(yùn)維、DBA、數(shù)據(jù)開發(fā)夏醉、數(shù)據(jù)模型爽锥、報(bào)表人員。
從互聯(lián)網(wǎng)數(shù)據(jù)平臺基本配置上畔柔，數(shù)據(jù)架構(gòu)師氯夷、運(yùn)維忠寻、底層大數(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ù)捞蛋。
10. Standalone****模式下，Model.save(Path)怎么一直提示錯誤柬姚，是不是配置Spark時需要將Hdfs的配置引進(jìn)來啊～拟杉？表示初學(xué)Spark
松子老師：這個問題有點(diǎn)超出我的能力范圍了，所以對不起回答不了量承。
我本身不是做技術(shù)的搬设。僅知道一點(diǎn)技術(shù)名詞。
11. ****傳統(tǒng)銀行業(yè)數(shù)據(jù)模型什么時候會走向互聯(lián)網(wǎng)模式呢撕捍？目前在傳統(tǒng)銀行數(shù)據(jù)平臺的產(chǎn)品是不是特別多拿穴？
松子老師：這個問題我自己就不知道了，或許是傳統(tǒng)銀行在數(shù)據(jù)平臺的實(shí)施上全面用互聯(lián)網(wǎng)的Nosql大數(shù)據(jù)處理技術(shù)吧忧风。至于說傳統(tǒng)銀行數(shù)據(jù)模型用現(xiàn)有的互聯(lián)網(wǎng)數(shù)據(jù)模型理念去設(shè)計(jì)是否完全可行默色，數(shù)據(jù)一致性、高準(zhǔn)確性通過更多的方案去保證狮腿。
首先我需要確定一下這個產(chǎn)品是否指的“數(shù)據(jù)產(chǎn)品”腿宰。
如果是數(shù)據(jù)產(chǎn)品，那其實(shí)傳統(tǒng)行業(yè)數(shù)據(jù)平臺本身就有一些數(shù)據(jù)產(chǎn)品了缘厢，而且也都是存在的吃度。數(shù)據(jù)產(chǎn)品自從數(shù)據(jù)倉庫出現(xiàn)以來它其實(shí)一直都存在的，只不過是近幾年因?yàn)榛ヂ?lián)網(wǎng)特別愛制造“流行詞“把數(shù)據(jù)產(chǎn)品這個詞給放大了贴硫〈幻浚互聯(lián)網(wǎng)是得數(shù)據(jù)產(chǎn)品從早期的重量級逐漸進(jìn)化為輕量級、從大而全的解決方案逐漸演進(jìn)為因小而美。
我來給出幾組例子间护，大約從2004年到現(xiàn)在的幾組數(shù)據(jù)產(chǎn)品的例子
(點(diǎn)擊放大圖像)
[圖片上傳中删壮。。兑牡。（25）]
(點(diǎn)擊放大圖像)
[圖片上傳中。税灌。均函。（26）]
(點(diǎn)擊放大圖像)
[圖片上傳中。菱涤。苞也。（27）]
(點(diǎn)擊放大圖像)
[圖片上傳中。粘秆。如迟。（28）]
(點(diǎn)擊放大圖像)
[圖片上傳中。攻走。殷勘。（29）]
(點(diǎn)擊放大圖像)
[圖片上傳中。昔搂。玲销。（30）]
(點(diǎn)擊放大圖像)
[圖片上傳中。摘符。贤斜。（31）]
你可以分類一下，這些數(shù)據(jù)產(chǎn)品的特點(diǎn)是什么逛裤？滿足了用戶怎么樣的痛點(diǎn)需求瘩绒？滿足了用戶怎么樣的使用流程。
12 ****带族。傳統(tǒng)行業(yè)的數(shù)據(jù)倉庫從業(yè)人員吐句，如果轉(zhuǎn)到互聯(lián)網(wǎng)行業(yè)，應(yīng)該學(xué)習(xí)哪些技能阿浓？
松子老師：這個問題你可以百度搜索“大數(shù)據(jù)職位所需要的數(shù)據(jù)技能” http://blog.jobbole.com/99039/ 這篇文章补君。自己覺得人家回答的比我專業(yè)。//
我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史（四）：互聯(lián)網(wǎng)時代 ? 下篇
http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-internet-age
編者按：本文是松子（李博源）的大數(shù)據(jù)平臺發(fā)展史系列文章的第四篇（共四篇）拍霜，本系列以獨(dú)特的視角嘱丢，比較了非互聯(lián)網(wǎng)和互聯(lián)網(wǎng)兩個時代以及傳統(tǒng)行業(yè)與非傳統(tǒng)行業(yè)。是對數(shù)據(jù)平臺發(fā)展的一個回憶祠饺，對非互聯(lián)網(wǎng)越驻、互聯(lián)網(wǎng)，從數(shù)據(jù)平臺的用戶角度、數(shù)據(jù)架構(gòu)演進(jìn)缀旁、模型等進(jìn)行了闡述记劈。
在互聯(lián)網(wǎng)時代被弱化的數(shù)據(jù)模型
談起數(shù)據(jù)模型就不得不提傳統(tǒng)數(shù)據(jù)平臺架構(gòu)發(fā)展，我相信很多朋友都曉得傳統(tǒng)數(shù)據(jù)平臺的知識并巍，其架構(gòu)演進(jìn)簡單一句話說“基本上可以分為五個時代目木、四種架構(gòu)”，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與數(shù)據(jù)源類型多樣化特點(diǎn)懊渡，從高階架構(gòu)上來看大約從傳統(tǒng)數(shù)據(jù)平臺第三代架構(gòu)開始延續(xù)的刽射，但是往后的發(fā)展從我自己的這一點(diǎn)知識上很難對互聯(lián)網(wǎng)的數(shù)據(jù)平臺做架構(gòu)歸類。
但是從數(shù)據(jù)平臺建設(shè)與服務(wù)角色上還是有章可循的剃执。就像上篇分享到那樣誓禁，類比兩個行業(yè)，互聯(lián)網(wǎng)企業(yè)中員工年齡比非互聯(lián)網(wǎng)企業(yè)的要年輕肾档、受教育程度摹恰、對計(jì)算機(jī)的焦慮程度明顯比傳統(tǒng)企業(yè)要低、還偶遇其它各方面的緣故怒见，導(dǎo)致了數(shù)據(jù)平臺所面對用戶群體與非互聯(lián)網(wǎng)數(shù)據(jù)平臺有所差異化俗慈。
傳統(tǒng)行業(yè)與互聯(lián)網(wǎng)行業(yè)數(shù)據(jù)平臺用戶特性我只選擇前文章的兩張圖來表示
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
在傳統(tǒng)數(shù)據(jù)平臺要背后有一個完整數(shù)據(jù)倉庫團(tuán)隊(duì)去服務(wù)業(yè)務(wù)方，業(yè)務(wù)方嗷嗷待哺的等待被動方式去滿足速种。中低層數(shù)據(jù)基本不會對業(yè)務(wù)方開放姜盈，所以不管數(shù)據(jù)模型采用何種建模方式，主要滿足當(dāng)時數(shù)據(jù)架構(gòu)規(guī)劃即可配阵。
互聯(lián)網(wǎng)業(yè)務(wù)的快速發(fā)展使得大家已經(jīng)從經(jīng)營馏颂、分析的訴求重點(diǎn)轉(zhuǎn)為數(shù)據(jù)化的精細(xì)運(yùn)營上，如何做好精細(xì)化運(yùn)營問題上來棋傍，當(dāng)資源不夠時用戶就叫喊救拉，甚至有的業(yè)務(wù)方會挽起袖子來自己參與到從數(shù)據(jù)整理、加工瘫拣、分析階段亿絮。
此時呢，原有建設(shè)數(shù)據(jù)平臺的多個角色（數(shù)據(jù)開發(fā)麸拄、模型設(shè)計(jì)）可能轉(zhuǎn)為對其它非專業(yè)使用數(shù)據(jù)方派昧，做培訓(xùn)、咨詢與落地拢切，寫更加適合當(dāng)前企業(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àn)椴粚I(yè)性五慈，導(dǎo)致數(shù)據(jù)質(zhì)量問題纳寂、重復(fù)對分?jǐn)?shù)據(jù)浪費(fèi)存儲與資源、口徑多樣化泻拦、編碼不統(tǒng)一毙芜、命名問題等等原因。數(shù)據(jù)質(zhì)量逐漸變成一個特別突出的問題争拐。
傳統(tǒng)企業(yè)的數(shù)據(jù)源基本來自excel腋粥、表格、DB系統(tǒng)等架曹，但在互聯(lián)網(wǎng)有網(wǎng)站點(diǎn)擊流日志灯抛、視頻、音頻音瓷、圖片數(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ù)有些力不從心。
當(dāng)數(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è)也有自己特點(diǎn)已慢，傳統(tǒng)行業(yè)所涉及數(shù)據(jù)模型這個領(lǐng)域涉及的很多內(nèi)容在互聯(lián)網(wǎng)變成以其他的曲線救國的方式存在了。
在互聯(lián)網(wǎng)曲線救國新解決
回顧在傳統(tǒng)行業(yè)數(shù)據(jù)平臺中霹购，不管兩位大師爭論點(diǎn)數(shù)據(jù)模型的設(shè)計(jì)采用那種范式（Bill Inmon的EDW的原則是準(zhǔn)三范式的設(shè)計(jì)佑惠、Ralph kilmbal是星型結(jié)構(gòu)）但是都要非常重視數(shù)據(jù)源的質(zhì)量問題。所以傳統(tǒng)行業(yè)的數(shù)據(jù)模型會全盤考慮數(shù)據(jù)質(zhì)量問題齐疙，并通過數(shù)據(jù)抽樣分析給出合適的清洗口徑膜楷。
(點(diǎn)擊放大圖像)
上圖來自我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ù)”對一年的還是不準(zhǔn)的）忆矛。在應(yīng)對數(shù)據(jù)的質(zhì)量問題察蹲，目前互聯(lián)網(wǎng)有些做法是把數(shù)據(jù)標(biāo)準(zhǔn)化前置到業(yè)務(wù)數(shù)據(jù)產(chǎn)生就做请垛，從根源上去杜絕數(shù)據(jù)質(zhì)量，但是這種場景比較實(shí)用在Log 日志的數(shù)據(jù)源中洽议，比如移動互聯(lián)網(wǎng)最近流行的基于事件模型“Event”模型宗收，在日志產(chǎn)生時就規(guī)定好存儲格式（備注：大家度娘搜索，“學(xué)習(xí)筆記：The Log（我所讀過的最好的一篇分布式技術(shù)文章）” 對這個講解很詳細(xì)）亚兄。
在傳統(tǒng)行業(yè)混稽，目前還是以混合模型設(shè)計(jì)方式為主。在互聯(lián)網(wǎng)的我所接觸的一些業(yè)務(wù)审胚，在參照傳統(tǒng)數(shù)據(jù)模型方法論基礎(chǔ)上逐步演進(jìn)適合互聯(lián)網(wǎng)數(shù)據(jù)的數(shù)據(jù)模型方法匈勋。
比如互聯(lián)網(wǎng)金融等一些業(yè)務(wù)會參考傳統(tǒng)金融行業(yè)對主題域的劃分、OMG數(shù)據(jù)倉庫元數(shù)據(jù)管理CWM模型膳叨、FSDM金融模型洽洁，再進(jìn)一步考慮大數(shù)據(jù)處理特性去進(jìn)行設(shè)計(jì)，所有從Hight Level 數(shù)據(jù)架構(gòu)圖看到主題層次劃分與傳統(tǒng)第三代數(shù)據(jù)倉庫還是很多相似之處菲嘴，當(dāng)然模型架構(gòu)也有分三層饿自、四層、五層的龄坪。
不同的地方模型細(xì)節(jié)處理上已經(jīng)完全不一樣昭雌，比如數(shù)據(jù)的多樣性、拉寬事實(shí)表健田、度量值單獨(dú)存儲烛卧、滿足數(shù)據(jù)快速重生、維度的二次降維處理等妓局、增加大量冗余列总放、增加大量派生列，結(jié)合自動化元數(shù)據(jù)來耦合好爬、合并等相關(guān)管理间聊。
(點(diǎn)擊放大圖像)
[圖片上傳中。抵拘。哎榴。（4）]
上圖是支付寶非常早期數(shù)據(jù)模型
(點(diǎn)擊放大圖像)
上圖是支付寶非常早期數(shù)據(jù)模型
我們常提到的多維模型在大數(shù)據(jù)處理下進(jìn)行了退化維度處理。大家知道Olap多維模型僵蛛，隨著維度的增加事實(shí)表的數(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è)計(jì)多維挖掘分析數(shù)據(jù)產(chǎn)品背后的技術(shù)就是搜索引擎實(shí)現(xiàn)的）飘言，現(xiàn)在應(yīng)該也有新技術(shù)出現(xiàn)了來解決類似的問題。
(點(diǎn)擊放大圖像)
上圖為2012年產(chǎn)品UI之一。
(點(diǎn)擊放大圖像)
[圖片上傳中缀拭。。坊萝。（7）]
上圖是2011-2012年該產(chǎn)品系列背后當(dāng)時使用的技術(shù)
互聯(lián)網(wǎng)業(yè)務(wù)特點(diǎn)業(yè)務(wù)垂直拆分非常細(xì)苛预，比如一個用戶注冊句狼、密碼找回的流程有可能存在好幾個產(chǎn)品負(fù)責(zé)同一個業(yè)務(wù)流程不同環(huán)節(jié)，相關(guān)的一個策略热某、產(chǎn)品feature快速迭代上線等等都要數(shù)據(jù)評估腻菇。數(shù)據(jù)從前端埋點(diǎn)到采集然后再由各個環(huán)節(jié)到數(shù)據(jù)平臺，再有數(shù)據(jù)分析師或各業(yè)務(wù)部門去使用昔馋，基本拉長了時間周期筹吐。需求部門與實(shí)施部門能力和經(jīng)驗(yàn)有千差萬別的需求，造成了懂技術(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ù)特點(diǎn)是變化非常迅速的，能穩(wěn)定的業(yè)務(wù)達(dá)到65%算對數(shù)據(jù)平臺是個福音了（根據(jù)對某寶寶的印象）剩余的業(yè)務(wù)變化迅速妥粟，必然導(dǎo)致數(shù)據(jù)模型快速上下線审丘。
Kimball老人家提出的維度建模（備注，在本系列發(fā)展史得第一篇有介紹）圍繞業(yè)務(wù)模型能夠非常直觀的表達(dá)出業(yè)務(wù)的數(shù)據(jù)關(guān)系勾给，但是在互聯(lián)網(wǎng)NOSQL犧牲掉了關(guān)系型數(shù)據(jù)庫的一致性滩报、完整性等等很多東西。維度數(shù)據(jù)模型又基于這些大數(shù)據(jù)技術(shù)的播急，所以進(jìn)化的更加輕量級與基于細(xì)節(jié)數(shù)據(jù)的維度退化建模（原有的緩慢變化維脓钾、快速變化維、大維桩警、迷你維可训、父子維、雪花維為了適應(yīng)互聯(lián)網(wǎng)的大數(shù)據(jù)Nosql處理技術(shù)進(jìn)行反規(guī)范化捶枢、化&數(shù)據(jù)冗余設(shè)計(jì)握截。
退化維度的反規(guī)范化設(shè)計(jì)一方面可以把一條查詢語句所需要的所有數(shù)據(jù)組合起來放到一個地方存儲 Key values 的方式（比如說商品有不同類型，每一種類型商品又有自己的不同屬性烂叔，可以采用一對多谨胞、多對多的方式存儲，例如把一個多維映射為一個Key value）蒜鸡。
講到互聯(lián)網(wǎng)數(shù)據(jù)平臺就要提數(shù)據(jù)模型胯努，提了數(shù)據(jù)模型就要提Nosql技術(shù)牢裳，
(點(diǎn)擊放大圖像)
上圖來自Nosql文檔系列的一幅圖
Nosql 是大數(shù)據(jù)處理的特征之一∫杜妫互聯(lián)網(wǎng)數(shù)據(jù)平臺數(shù)據(jù)模型與NoSql技術(shù)還是蠻緊密的蒲讯。這里有外文講解Nosql Data modeling technigues 從技術(shù)角度講解非常詳（https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/）。
因?yàn)榍斑吿岬降拇髷?shù)據(jù)平臺技術(shù)特性決定了傳統(tǒng)edw模型恬汁、維度模型直接在互聯(lián)網(wǎng)數(shù)據(jù)大數(shù)據(jù)平臺部署或許還有“好些未知”障礙等待大家去克服伶椿。同時在傳統(tǒng)數(shù)據(jù)建模用到的一些方法經(jīng)過互聯(lián)網(wǎng)熏陶或許演進(jìn)成一種新的數(shù)據(jù)產(chǎn)品或方案吧。
到此為止“我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史”上下共四篇與大家分享完畢氓侧，這個寫作前后經(jīng)歷剛好一個月左右脊另，算是對自己數(shù)據(jù)從業(yè)經(jīng)歷回顧之一吧。在知識的整理中很多都是蜻蜓點(diǎn)水约巷，每個知識域都是一個非常深的專業(yè)方向偎痛，自己涉足很膚淺，在文章中分享不足之處請各位讀者見諒６览伞踩麦！
個人郵箱是5592094@qq.com 歡迎電郵交流。
接下來我會進(jìn)入數(shù)據(jù)產(chǎn)品這個領(lǐng)域的分享氓癌，當(dāng)年車品覺老師自豪的作品之一“黃金策”谓谦，我是數(shù)據(jù)產(chǎn)品經(jīng)理。（ps：自己躲在墻角拿車品覺老師往自己臉上貼金了）贪婉。
后記
有一次數(shù)據(jù)產(chǎn)品神策的創(chuàng)始人兼好友@桑文鋒＠SensorsData跟我說來做次分享吧反粥，我當(dāng)時出了幾個題目，最后就選擇了“我所經(jīng)歷的大數(shù)據(jù)平臺“疲迂，就形成了大家看到的”我所經(jīng)歷的大數(shù)據(jù)平臺“系列文章.
在整理期間得到了死黨@周愛民挟裂、@神策-桑文峰糕珊、 InfoQ小編@Tina Du 贝搁、@betty zhou @Laurel大力協(xié)助萍嬉，在這里感謝！Ｑ亍尾组！
番外篇
這一篇是在24日舉行的分享大家提到的一些問題，經(jīng)過整理算是對正文的補(bǔ)充吧示弓，從互聯(lián)網(wǎng)敏捷數(shù)據(jù)模型等角度做了較深入的細(xì)節(jié)介紹演怎。同時在數(shù)據(jù)產(chǎn)品方面的回答包含了一點(diǎn)未來寫作篇“數(shù)據(jù)產(chǎn)品”系列的一點(diǎn)內(nèi)容。
1****避乏，傳統(tǒng)我們做BI的爷耀，做數(shù)據(jù)展現(xiàn)會建模后以pivot展現(xiàn)cube數(shù)據(jù)，不知道現(xiàn)在互聯(lián)網(wǎng)公司數(shù)據(jù)展示如何做的拍皮？第三方工具還是用API取數(shù)據(jù)平臺里的數(shù)據(jù)歹叮？adhoc報(bào)表及靈活更換維度的時候web端一般是怎么做的跑杭？
松子老師：剛才文章中提到了比如傳統(tǒng)行業(yè)的多維數(shù)據(jù)模型cube。在互聯(lián)網(wǎng)采用的曲線救國方式解決的咆耿。 在分享中我給出了幾個圖德谅。就是通過搜索引擎曲線救國方式實(shí)現(xiàn)類似Olap的模擬。
在這塊的模型的處理上采用的是維度退化處理萨螺。通過反規(guī)范化窄做，數(shù)據(jù)項(xiàng)、數(shù)據(jù)冗余去處理慰技。在前端做特殊處理椭盏。
這個當(dāng)時產(chǎn)品原型之一：
(點(diǎn)擊放大圖像)
這是一個2011年-2012年左右的數(shù)據(jù)產(chǎn)品，當(dāng)時算是即時計(jì)算的一種吻商。不過已經(jīng)過去好幾年了掏颊，當(dāng)今新技術(shù)下Olap 引擎應(yīng)該有很好的提升。
目前我知道的家互聯(lián)網(wǎng)公司艾帐，在前端展現(xiàn)有使用第三方套件比如spagoBi乌叶、pentaho 等 有自己設(shè)計(jì)開發(fā)定制化數(shù)據(jù)前端展現(xiàn)。比如我剛開始分享的那兩個之前在去哪兒網(wǎng)設(shè)計(jì)的數(shù)據(jù)平臺內(nèi)部界面之一柒爸，當(dāng)然數(shù)據(jù)產(chǎn)品是另一個話題了准浴，通過對數(shù)據(jù)分析抽象指標(biāo)、分析模型捎稚、用戶使用功能與流程乐横、未來規(guī)劃考慮用戶體驗(yàn)去設(shè)計(jì)。
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
[圖片上傳中阳藻。。谈撒。（11）]
(點(diǎn)擊放大圖像)
2****腥泥，互聯(lián)網(wǎng)財(cái)經(jīng)類公司，業(yè)務(wù)包括財(cái)經(jīng)網(wǎng)站啃匿、基金蛔外、股票、金融等溯乒，這類公司的數(shù)據(jù)倉庫模型應(yīng)該如何設(shè)計(jì)夹厌？特點(diǎn)和注意事項(xiàng)是什么？案例介紹裆悄？十分感謝矛纹。
松子老師：我自己經(jīng)歷過的是互聯(lián)網(wǎng)金融以及移動互聯(lián)網(wǎng)行。對這兩塊比較清楚光稼』蚰希互聯(lián)網(wǎng)金融起因?yàn)闃I(yè)務(wù)的特性是類金融類的孩等，與銀行有些地方是相似的。
比如大約在2012年前支付寶業(yè)務(wù)特點(diǎn)涉及類金融交易：充值采够、提現(xiàn)肄方、賬務(wù)管理類電子商務(wù)：購物交易過程變更、實(shí)際交易（對B機(jī)票蹬癌、對C水電等） 非純電子商務(wù)权她；純金融；個人信用逝薪，理財(cái)類刑枝。系統(tǒng)之間依賴度較為復(fù)雜藐唠，垂直依賴（業(yè)務(wù)與核心）跨層依賴（跨過交易到賬務(wù)）。
在設(shè)計(jì)方法上還是采用維度模型設(shè)計(jì)方式。底層是數(shù)據(jù)驅(qū)動為向?qū)Ъ艿Y(jié)合業(yè)務(wù)需求驅(qū)動，通過簡單扫茅、退化維度的方式拉寬表結(jié)構(gòu)琐凭。
底層采用松耦合設(shè)計(jì)。主題之間是松耦合方式询微。至體內(nèi)采用細(xì)粒度退化維度崖瞭。
在主題域上的的設(shè)計(jì)基本參考了OMG的數(shù)據(jù)倉庫元數(shù)據(jù)設(shè)計(jì)CWM模型、IBM 的fsdm金融模型撑毛、還有新巴塞爾資本協(xié)議（Basel II Capital Accord）需提供數(shù)據(jù)規(guī)范去的設(shè)計(jì)书聚。所以數(shù)據(jù)模型是五層的結(jié)構(gòu)。
在細(xì)節(jié)處理上藻雌，增量ODS層數(shù)據(jù)和前一天DWD相關(guān)表進(jìn)行 merge處理雌续。
在一些層次上，基本聚合胯杭、匯總增加派生事實(shí)表（簡單一句話退化為度打?qū)挘┭倍拧Ｈ缓蟀凑諛I(yè)務(wù)主體合并信息等。
比如開始給大家分享的那張圖：
(點(diǎn)擊放大圖像)
[圖片上傳中做个。鸽心。。（13）]
在維度模型退化處理時居暖，要注意最細(xì)粒度數(shù)據(jù)保留顽频、不同層次的數(shù)據(jù)支持?jǐn)?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ù)模型莺奸。
這種元數(shù)據(jù)驅(qū)動工具型數(shù)據(jù)產(chǎn)品我會在未來數(shù)據(jù)產(chǎn)品系列中做詳細(xì)介紹的丑孩。
3****，互聯(lián)網(wǎng)企業(yè)大數(shù)據(jù)平臺的發(fā)展歷程是怎樣的灭贷？
松子老師：這個我相信應(yīng)該是傳統(tǒng)數(shù)據(jù)平臺朋友提到的温学。傳統(tǒng)行業(yè)數(shù)據(jù)平臺架構(gòu)演進(jìn)我總結(jié)簡單一句話說“基本上可以分為五個時代、四種架構(gòu)”甚疟，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與類型暴增的特點(diǎn)仗岖，從高階架構(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é)下來用戶特點(diǎn)：
(點(diǎn)擊放大圖像)
[圖片上傳中檩电。。府树。（14）]
更加詳細(xì)的每一代數(shù)據(jù)平臺建設(shè)俐末、服務(wù)角色特點(diǎn)您可以看我這個系列文章的第三篇，http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-paet02
4****奄侠，有沒有好的元數(shù)據(jù)管理工具推薦卓箫？主要偏向數(shù)據(jù)字典與血統(tǒng)等。
松子老師：元數(shù)據(jù)以前目前沒有太多的好管理工具垄潮。以前是在支付寶是我自己設(shè)計(jì)的一個數(shù)據(jù)產(chǎn)品烹卒。第一版自己用Delphi 開發(fā)的。
（圖很多：）
(點(diǎn)擊放大圖像)
[圖片上傳中弯洗。旅急。。（15）]
(點(diǎn)擊放大圖像)
[圖片上傳中牡整。藐吮。。（16）]
(點(diǎn)擊放大圖像)
[圖片上傳中果正。炎码。盟迟。（17）]
(點(diǎn)擊放大圖像)
[圖片上傳中秋泳。。缓待。（18）]
(點(diǎn)擊放大圖像)
[圖片上傳中辈讶。妄痪。琢唾。（19）]
以前被逼的自己寫了一個卓起，通過解析和敬，實(shí)現(xiàn)了字段級的血緣影響分析。這只是第二步戏阅，后來又把running 信息給搞了進(jìn)來昼弟。還有分享時提到的模型信息、整個閉環(huán)的分類信息奕筐。
這是一個分支：
(點(diǎn)擊放大圖像)
[圖片上傳中舱痘。。离赫。（20）]
但是我們實(shí)現(xiàn)了字段級解析準(zhǔn)確率達(dá)到了94%左右芭逝。有細(xì)微的錯誤就人工revew一遍。
5. ****松子老師渊胸，數(shù)據(jù)管控的數(shù)據(jù)質(zhì)量部分是怎么處理的呢旬盯？
松子老師： 數(shù)據(jù)管控， 這方面我不太懂的翎猛，但是數(shù)據(jù)質(zhì)量胖翰，這玩意可大可小的。比如像在分享時說過的办成，在移動互聯(lián)網(wǎng)的數(shù)據(jù)質(zhì)量處理方式可以由原有的ETL(ELT)階段前置到業(yè)務(wù)系統(tǒng)去解決泡态，比如移動互聯(lián)網(wǎng)的App log 日志，日志標(biāo)準(zhǔn)化后事件模型”存儲來解決迂卢。那非app 日志類如何解決呢比如Payment某弦、order等，數(shù)據(jù)質(zhì)量比較考慮的可以只做到監(jiān)控而克。
我來分享個圖靶壮。剛好是我設(shè)計(jì)數(shù)據(jù)質(zhì)量產(chǎn)品時搞的，理清數(shù)據(jù)質(zhì)量的問題：
(點(diǎn)擊放大圖像)
[圖片上傳中员萍。腾降。。（21）]
(點(diǎn)擊放大圖像)
[圖片上傳中碎绎。螃壤。。（22）]
(點(diǎn)擊放大圖像)
[圖片上傳中筋帖。奸晴。。（23）]
只要數(shù)據(jù)進(jìn)入倉庫與應(yīng)用體系日麸，處理起來就比較困難了寄啼，所以在數(shù)據(jù)平臺階段最好是通過監(jiān)控、前置去解決。目前數(shù)據(jù)質(zhì)量確實(shí)難以100%由事后搞到事前去處理墩划。我對數(shù)據(jù)平臺與數(shù)據(jù)產(chǎn)品的建設(shè)就是實(shí)用為主涕刚。怎么實(shí)用怎么來。我是比較現(xiàn)實(shí)的實(shí)用主義者乙帮。
6. ****能否分享一些數(shù)據(jù)產(chǎn)品種類及實(shí)例：
松子老師：在前邊五個問題杜漠、以及文章中又都涉及數(shù)據(jù)產(chǎn)品實(shí)力的一些分享。
提到數(shù)據(jù)產(chǎn)品的分類我就想把這個圖發(fā)出來察净。
自己認(rèn)為沒有特別明確的劃分線碑幅，但是數(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工具棋返、資源管控等等。
面向用戶功能有報(bào)表型雷猪、多維型數(shù)據(jù)產(chǎn)品睛竣、定制化數(shù)據(jù)產(chǎn)品、挖掘型數(shù)據(jù)產(chǎn)品。
面向內(nèi)部用戶、外部個人用戶套蒂、外部企業(yè)用戶又有不同的分類。
根據(jù)業(yè)務(wù)又可以劃分很多验夯，面向C類用戶、面向B類商戶摔刁、金融風(fēng)險(xiǎn)等等
從近幾年的數(shù)據(jù)產(chǎn)品來看挥转，是更好的輔助用戶的做決策的一種產(chǎn)品形態(tài)，在用戶的決策與行動中充當(dāng)信息的分析者與價值使用者共屈；數(shù)據(jù)產(chǎn)品有個自己的共性：由解決的一個實(shí)際的業(yè)務(wù)問題出發(fā)绑谣，分解出的分析指標(biāo)，分析模型拗引，分析流程組成借宵，再考慮到功能易用性，未來功能擴(kuò)展寺擂，考慮用戶對數(shù)據(jù)易用性（比如數(shù)據(jù)的呈現(xiàn)層次暇务，不可能一次把所有數(shù)據(jù)的呈現(xiàn)給用戶）來組成的。
(點(diǎn)擊放大圖像)
[圖片上傳中怔软。垦细。。（24）]
7. ****銀行業(yè)從傳統(tǒng)的ods到edw再到大數(shù)據(jù)平臺這塊過渡挡逼，模型如何建設(shè)括改？平臺優(yōu)勢如何發(fā)揮？
松子老師：這個問題還是有些難度的家坎，自己回答的可能有些片面嘱能。首先我們清醒的清楚“大數(shù)據(jù)”是什么？再次不同的場景可以采用不同的技術(shù)去解決虱疏。
“大數(shù)據(jù)”惹骂，拆開來看大、數(shù)據(jù)做瞪，大可以是指的數(shù)據(jù)源結(jié)構(gòu)簡單（ps 如果了解過當(dāng)代對大數(shù)據(jù)的定義就知道四個特性）但是量級夠大对粪，比如清算、結(jié)算装蓬、對公著拭、對私、中間業(yè)務(wù)等等每一個拿出來都是幾十T牍帚，但是這些業(yè)務(wù)數(shù)據(jù)都是保存?zhèn)鹘y(tǒng)的關(guān)系型數(shù)據(jù)庫中如DB2儡遮、Oracle、MSsql中暗赶，因?yàn)樵跀?shù)據(jù)平臺存儲是通過準(zhǔn)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ù)的去演進(jìn)解決糙及。（最早時我的是中信銀行详幽、光大銀行在2011年左右開始考慮Hadoop技術(shù)，后來不知道如何了）浸锨。
但是互聯(lián)網(wǎng)的數(shù)據(jù)平臺技術(shù)大都是NOSQL模式唇聘，犧牲掉了傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)一致性、完整性柱搜、唯一索引等等迟郎，只干性能的事情（當(dāng)然除了性能、可擴(kuò)展性也是的）.
原有在傳統(tǒng)數(shù)據(jù)平臺模型設(shè)計(jì)上可以考慮的一些通過主外鍵聪蘸、唯一索引做一些業(yè)務(wù)約束的方法宪肖，在nosql上統(tǒng)統(tǒng)的都沒有了表制，這些約束必須放到數(shù)據(jù)加工階段去想辦法做檢查。傳統(tǒng)數(shù)據(jù)平臺如果在Insert控乾、update數(shù)據(jù)時違反了業(yè)務(wù)約束可以做報(bào)警或異常處理么介，但是在Nosql的平臺上要求ETL 去手動遵守這些規(guī)則檢查。但是有時ETL開發(fā)根本不遵守的蜕衡，僅僅是兩個表關(guān)聯(lián)起來壤短，也可能忘記按照某一個業(yè)務(wù)唯一索引做去重操作。簡單說慨仿，原有靠關(guān)系型數(shù)據(jù)庫本身機(jī)制去做檢查一些規(guī)則變?yōu)槿斯ぞ酶優(yōu)槿斯ぞ蜁稿e屈尼。
從關(guān)系型數(shù)據(jù)平臺往Nosql數(shù)據(jù)平臺遷移時蹦玫，尤其是對傳統(tǒng)行業(yè)的業(yè)務(wù)來說淡喜，在模型設(shè)計(jì)階段问裕、以及給出的ETL口徑要考慮更多的業(yè)務(wù)規(guī)則檢查大溜，其次要考慮更多的維度退化织中、多冗余苗缩、表打?qū)捥幚碚覆巍：唵握f就是發(fā)揮數(shù)據(jù)平臺的計(jì)算能力同時要更加的各方面確保數(shù)據(jù)準(zhǔn)確安全可靠相寇。
數(shù)據(jù)模型ODS 到EDW 這塊的設(shè)計(jì)方法百度上留下的文檔資料太多的了慰于，請這位提問的老師百度吧。
**8****．大數(shù)據(jù)****倉庫****中如何做快速****維處****理唤衫？互****聯(lián)****網(wǎng)數(shù)****倉****數(shù)據(jù)****質(zhì)****量不好如何****對****數(shù)婆赠，如何確立****標(biāo)****準(zhǔn)的****對****數(shù)口徑？******
松子老師：快速變化維度可以轉(zhuǎn)化為緩慢變化為來出來佳励，我自己理解的快速維度是相對于緩慢維度參照的來說的休里。
舉個例子，年齡-轉(zhuǎn)化為天數(shù)可以是定義快速變化維度赃承，因?yàn)槊刻於荚谧兓钍颉Ｎ覀兛梢园涯挲g退化為區(qū)間維度來處理，還可以把年齡做成動態(tài)維度來處理瞧剖，事實(shí)表中保存的就是實(shí)際的出生年月并打?qū)挶硎眉蓿挲g(天)通過計(jì)算方式來處理。還有種方法通過對代理鍵的方式來處理抓于。
我目前也不知道對數(shù)據(jù)的標(biāo)準(zhǔn)是什么做粤。但是我自己用的方法，把一個指標(biāo)的整個數(shù)據(jù)流向切出幾個關(guān)鍵點(diǎn)通過SQL去實(shí)現(xiàn)對數(shù)捉撮，看波動振幅怕品，波動曲線。同時還會比如發(fā)不通的版本的小流量測試的方式來做數(shù)據(jù)校對巾遭。
9****． 做為數(shù)據(jù)行業(yè)從業(yè)者肉康，需要掌握哪些重要的基礎(chǔ)知識闯估？另：如果從零開始建立一個數(shù)據(jù)平臺，需要哪些資源配置（人吼和，財(cái)涨薪，物，技術(shù)）纹安？大致總投資額度多少？如果同行產(chǎn)品間多種來源的數(shù)據(jù)砂豌，可有成熟的解決方案厢岂？謝謝…
松子老師：這個問題太宏觀了。作為數(shù)據(jù)行業(yè)從業(yè)者阳距，需要掌握哪些重要基礎(chǔ)知識塔粒，這個是要看從事具體數(shù)據(jù)域的垂直行業(yè)。
比如說 數(shù)據(jù)開發(fā)筐摘、數(shù)據(jù)模型卒茬、數(shù)據(jù)產(chǎn)品、數(shù)據(jù)分析師咖熟、數(shù)據(jù)運(yùn)營圃酵、數(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ù)目標(biāo)不太明確下罗捎，難以確定方案观谦，人員配置上選用不同技術(shù)方案去搭建的配置是不太一樣的，比如說傳統(tǒng)平臺來講桨菜，運(yùn)維豁状、DBA、數(shù)據(jù)開發(fā)倒得、數(shù)據(jù)模型替蔬、報(bào)表人員物邑。
從互聯(lián)網(wǎng)數(shù)據(jù)平臺基本配置上究恤，數(shù)據(jù)架構(gòu)師、運(yùn)維饭宾、底層大數(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ù)糊肤。
10. Standalone****模式下，Model.save(Path)怎么一直提示錯誤氓鄙，是不是配置Spark時需要將Hdfs的配置引進(jìn)來啊～馆揉？表示初學(xué)Spark
松子老師：這個問題有點(diǎn)超出我的能力范圍了，所以對不起回答不了抖拦。
我本身不是做技術(shù)的升酣。僅知道一點(diǎn)技術(shù)名詞。
11. ****傳統(tǒng)銀行業(yè)數(shù)據(jù)模型什么時候會走向互聯(lián)網(wǎng)模式呢态罪？目前在傳統(tǒng)銀行數(shù)據(jù)平臺的產(chǎn)品是不是特別多噩茄？
松子老師：這個問題我自己就不知道了，或許是傳統(tǒng)銀行在數(shù)據(jù)平臺的實(shí)施上全面用互聯(lián)網(wǎng)的Nosql大數(shù)據(jù)處理技術(shù)吧复颈。至于說傳統(tǒng)銀行數(shù)據(jù)模型用現(xiàn)有的互聯(lián)網(wǎng)數(shù)據(jù)模型理念去設(shè)計(jì)是否完全可行巢墅，數(shù)據(jù)一致性、高準(zhǔn)確性通過更多的方案去保證券膀。
首先我需要確定一下這個產(chǎn)品是否指的“數(shù)據(jù)產(chǎn)品”君纫。
如果是數(shù)據(jù)產(chǎn)品，那其實(shí)傳統(tǒng)行業(yè)數(shù)據(jù)平臺本身就有一些數(shù)據(jù)產(chǎn)品了芹彬，而且也都是存在的蓄髓。數(shù)據(jù)產(chǎn)品自從數(shù)據(jù)倉庫出現(xiàn)以來它其實(shí)一直都存在的，只不過是近幾年因?yàn)榛ヂ?lián)網(wǎng)特別愛制造“流行詞“把數(shù)據(jù)產(chǎn)品這個詞給放大了舒帮』岷龋互聯(lián)網(wǎng)是得數(shù)據(jù)產(chǎn)品從早期的重量級逐漸進(jìn)化為輕量級、從大而全的解決方案逐漸演進(jìn)為因小而美玩郊。
我來給出幾組例子肢执，大約從2004年到現(xiàn)在的幾組數(shù)據(jù)產(chǎn)品的例子
(點(diǎn)擊放大圖像)
[圖片上傳中。译红。预茄。（25）]
(點(diǎn)擊放大圖像)
[圖片上傳中。侦厚。耻陕。（26）]
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
[圖片上傳中拙徽。。诗宣。（28）]
(點(diǎn)擊放大圖像)
[圖片上傳中膘怕。。召庞。（29）]
(點(diǎn)擊放大圖像)
[圖片上傳中岛心。。篮灼。（30）]
(點(diǎn)擊放大圖像)
[圖片上傳中忘古。。穿稳。（31）]
你可以分類一下存皂，這些數(shù)據(jù)產(chǎn)品的特點(diǎn)是什么晌坤？滿足了用戶怎么樣的痛點(diǎn)需求逢艘？滿足了用戶怎么樣的使用流程。
12 ****骤菠。傳統(tǒng)行業(yè)的數(shù)據(jù)倉庫從業(yè)人員它改，如果轉(zhuǎn)到互聯(lián)網(wǎng)行業(yè)，應(yīng)該學(xué)習(xí)哪些技能？
松子老師：這個問題你可以百度搜索“大數(shù)據(jù)職位所需要的數(shù)據(jù)技能” http://blog.jobbole.com/99039/ 這篇文章。自己覺得人家回答的比我專業(yè)殷蛇。//
我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史（四）：互聯(lián)網(wǎng)時代 ? 下篇
http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-internet-age
編者按：本文是松子（李博源）的大數(shù)據(jù)平臺發(fā)展史系列文章的第四篇（共四篇）火欧，本系列以獨(dú)特的視角，比較了非互聯(lián)網(wǎng)和互聯(lián)網(wǎng)兩個時代以及傳統(tǒng)行業(yè)與非傳統(tǒng)行業(yè)境钟。是對數(shù)據(jù)平臺發(fā)展的一個回憶，對非互聯(lián)網(wǎng)、互聯(lián)網(wǎng)遏餐，從數(shù)據(jù)平臺的用戶角度、數(shù)據(jù)架構(gòu)演進(jìn)赢底、模型等進(jìn)行了闡述失都。
在互聯(lián)網(wǎng)時代被弱化的數(shù)據(jù)模型
談起數(shù)據(jù)模型就不得不提傳統(tǒng)數(shù)據(jù)平臺架構(gòu)發(fā)展，我相信很多朋友都曉得傳統(tǒng)數(shù)據(jù)平臺的知識幸冻，其架構(gòu)演進(jìn)簡單一句話說“基本上可以分為五個時代粹庞、四種架構(gòu)”，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與數(shù)據(jù)源類型多樣化特點(diǎn)洽损，從高階架構(gòu)上來看大約從傳統(tǒng)數(shù)據(jù)平臺第三代架構(gòu)開始延續(xù)的庞溜，但是往后的發(fā)展從我自己的這一點(diǎn)知識上很難對互聯(lián)網(wǎng)的數(shù)據(jù)平臺做架構(gòu)歸類。
但是從數(shù)據(jù)平臺建設(shè)與服務(wù)角色上還是有章可循的碑定。就像上篇分享到那樣强缘，類比兩個行業(yè)督惰，互聯(lián)網(wǎng)企業(yè)中員工年齡比非互聯(lián)網(wǎng)企業(yè)的要年輕、受教育程度旅掂、對計(jì)算機(jī)的焦慮程度明顯比傳統(tǒng)企業(yè)要低赏胚、還偶遇其它各方面的緣故，導(dǎo)致了數(shù)據(jù)平臺所面對用戶群體與非互聯(lián)網(wǎng)數(shù)據(jù)平臺有所差異化商虐。
傳統(tǒng)行業(yè)與互聯(lián)網(wǎng)行業(yè)數(shù)據(jù)平臺用戶特性我只選擇前文章的兩張圖來表示
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
在傳統(tǒng)數(shù)據(jù)平臺要背后有一個完整數(shù)據(jù)倉庫團(tuán)隊(duì)去服務(wù)業(yè)務(wù)方觉阅，業(yè)務(wù)方嗷嗷待哺的等待被動方式去滿足。中低層數(shù)據(jù)基本不會對業(yè)務(wù)方開放秘车，所以不管數(shù)據(jù)模型采用何種建模方式典勇，主要滿足當(dāng)時數(shù)據(jù)架構(gòu)規(guī)劃即可。
互聯(lián)網(wǎng)業(yè)務(wù)的快速發(fā)展使得大家已經(jīng)從經(jīng)營叮趴、分析的訴求重點(diǎn)轉(zhuǎn)為數(shù)據(jù)化的精細(xì)運(yùn)營上割笙，如何做好精細(xì)化運(yùn)營問題上來，當(dāng)資源不夠時用戶就叫喊眯亦，甚至有的業(yè)務(wù)方會挽起袖子來自己參與到從數(shù)據(jù)整理伤溉、加工、分析階段妻率。
此時呢乱顾，原有建設(shè)數(shù)據(jù)平臺的多個角色（數(shù)據(jù)開發(fā)、模型設(shè)計(jì)）可能轉(zhuǎn)為對其它非專業(yè)使用數(shù)據(jù)方宫静，做培訓(xùn)走净、咨詢與落地，寫更加適合當(dāng)前企業(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àn)椴粚I(yè)性捌袜，導(dǎo)致數(shù)據(jù)質(zhì)量問題说搅、重復(fù)對分?jǐn)?shù)據(jù)浪費(fèi)存儲與資源、口徑多樣化琢蛤、編碼不統(tǒng)一蜓堕、命名問題等等原因。數(shù)據(jù)質(zhì)量逐漸變成一個特別突出的問題博其。
傳統(tǒng)企業(yè)的數(shù)據(jù)源基本來自excel套才、表格、DB系統(tǒng)等慕淡，但在互聯(lián)網(wǎng)有網(wǎng)站點(diǎn)擊流日志背伴、視頻、音頻、圖片數(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ù)有些力不從心。
當(dāng)數(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è)也有自己特點(diǎn)望抽，傳統(tǒng)行業(yè)所涉及數(shù)據(jù)模型這個領(lǐng)域涉及的很多內(nèi)容在互聯(lián)網(wǎng)變成以其他的曲線救國的方式存在了加矛。
在互聯(lián)網(wǎng)曲線救國新解決
回顧在傳統(tǒng)行業(yè)數(shù)據(jù)平臺中，不管兩位大師爭論點(diǎn)數(shù)據(jù)模型的設(shè)計(jì)采用那種范式（Bill Inmon的EDW的原則是準(zhǔn)三范式的設(shè)計(jì)糠聪、Ralph kilmbal是星型結(jié)構(gòu)）但是都要非常重視數(shù)據(jù)源的質(zhì)量問題荒椭。所以傳統(tǒng)行業(yè)的數(shù)據(jù)模型會全盤考慮數(shù)據(jù)質(zhì)量問題谐鼎，并通過數(shù)據(jù)抽樣分析給出合適的清洗口徑舰蟆。
(點(diǎn)擊放大圖像)
上圖來自我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ù)”對一年的還是不準(zhǔn)的）草戈。在應(yīng)對數(shù)據(jù)的質(zhì)量問題塌鸯，目前互聯(lián)網(wǎng)有些做法是把數(shù)據(jù)標(biāo)準(zhǔn)化前置到業(yè)務(wù)數(shù)據(jù)產(chǎn)生就做，從根源上去杜絕數(shù)據(jù)質(zhì)量唐片，但是這種場景比較實(shí)用在Log 日志的數(shù)據(jù)源中丙猬，比如移動互聯(lián)網(wǎng)最近流行的基于事件模型“Event”模型，在日志產(chǎn)生時就規(guī)定好存儲格式（備注：大家度娘搜索费韭，“學(xué)習(xí)筆記：The Log（我所讀過的最好的一篇分布式技術(shù)文章）” 對這個講解很詳細(xì)）茧球。
在傳統(tǒng)行業(yè)，目前還是以混合模型設(shè)計(jì)方式為主星持。在互聯(lián)網(wǎng)的我所接觸的一些業(yè)務(wù)抢埋，在參照傳統(tǒng)數(shù)據(jù)模型方法論基礎(chǔ)上逐步演進(jìn)適合互聯(lián)網(wǎng)數(shù)據(jù)的數(shù)據(jù)模型方法。
比如互聯(lián)網(wǎng)金融等一些業(yè)務(wù)會參考傳統(tǒng)金融行業(yè)對主題域的劃分、OMG數(shù)據(jù)倉庫元數(shù)據(jù)管理CWM模型揪垄、FSDM金融模型穷吮，再進(jìn)一步考慮大數(shù)據(jù)處理特性去進(jìn)行設(shè)計(jì)，所有從Hight Level 數(shù)據(jù)架構(gòu)圖看到主題層次劃分與傳統(tǒng)第三代數(shù)據(jù)倉庫還是很多相似之處饥努，當(dāng)然模型架構(gòu)也有分三層捡鱼、四層、五層的酷愧。
不同的地方模型細(xì)節(jié)處理上已經(jīng)完全不一樣堰汉，比如數(shù)據(jù)的多樣性、拉寬事實(shí)表伟墙、度量值單獨(dú)存儲翘鸭、滿足數(shù)據(jù)快速重生、維度的二次降維處理等戳葵、增加大量冗余列就乓、增加大量派生列，結(jié)合自動化元數(shù)據(jù)來耦合拱烁、合并等相關(guān)管理生蚁。
(點(diǎn)擊放大圖像)
[圖片上傳中。戏自。邦投。（4）]
上圖是支付寶非常早期數(shù)據(jù)模型
(點(diǎn)擊放大圖像)
上圖是支付寶非常早期數(shù)據(jù)模型
我們常提到的多維模型在大數(shù)據(jù)處理下進(jìn)行了退化維度處理。大家知道Olap多維模型擅笔，隨著維度的增加事實(shí)表的數(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è)計(jì)多維挖掘分析數(shù)據(jù)產(chǎn)品背后的技術(shù)就是搜索引擎實(shí)現(xiàn)的）念脯，現(xiàn)在應(yīng)該也有新技術(shù)出現(xiàn)了來解決類似的問題。
(點(diǎn)擊放大圖像)
上圖為2012年產(chǎn)品UI之一弯淘。
(點(diǎn)擊放大圖像)
[圖片上傳中绿店。。庐橙。（7）]
上圖是2011-2012年該產(chǎn)品系列背后當(dāng)時使用的技術(shù)
互聯(lián)網(wǎng)業(yè)務(wù)特點(diǎn)業(yè)務(wù)垂直拆分非常細(xì)假勿，比如一個用戶注冊、密碼找回的流程有可能存在好幾個產(chǎn)品負(fù)責(zé)同一個業(yè)務(wù)流程不同環(huán)節(jié)态鳖，相關(guān)的一個策略转培、產(chǎn)品feature快速迭代上線等等都要數(shù)據(jù)評估绑蔫。數(shù)據(jù)從前端埋點(diǎn)到采集然后再由各個環(huán)節(jié)到數(shù)據(jù)平臺束析，再有數(shù)據(jù)分析師或各業(yè)務(wù)部門去使用，基本拉長了時間周期媚送。需求部門與實(shí)施部門能力和經(jīng)驗(yàn)有千差萬別的需求，造成了懂技術(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ù)特點(diǎn)是變化非常迅速的企量，能穩(wěn)定的業(yè)務(wù)達(dá)到65%算對數(shù)據(jù)平臺是個福音了（根據(jù)對某寶寶的印象）剩余的業(yè)務(wù)變化迅速，必然導(dǎo)致數(shù)據(jù)模型快速上下線亡电。
Kimball老人家提出的維度建模（備注届巩，在本系列發(fā)展史得第一篇有介紹）圍繞業(yè)務(wù)模型能夠非常直觀的表達(dá)出業(yè)務(wù)的數(shù)據(jù)關(guān)系，但是在互聯(lián)網(wǎng)NOSQL犧牲掉了關(guān)系型數(shù)據(jù)庫的一致性份乒、完整性等等很多東西恕汇。維度數(shù)據(jù)模型又基于這些大數(shù)據(jù)技術(shù)的，所以進(jìn)化的更加輕量級與基于細(xì)節(jié)數(shù)據(jù)的維度退化建模（原有的緩慢變化維或辖、快速變化維瘾英、大維、迷你維颂暇、父子維缺谴、雪花維為了適應(yīng)互聯(lián)網(wǎng)的大數(shù)據(jù)Nosql處理技術(shù)進(jìn)行反規(guī)范化、化&數(shù)據(jù)冗余設(shè)計(jì)耳鸯。
退化維度的反規(guī)范化設(shè)計(jì)一方面可以把一條查詢語句所需要的所有數(shù)據(jù)組合起來放到一個地方存儲 Key values 的方式（比如說商品有不同類型湿蛔，每一種類型商品又有自己的不同屬性，可以采用一對多片拍、多對多的方式存儲煌集，例如把一個多維映射為一個Key value）妓肢。
講到互聯(lián)網(wǎng)數(shù)據(jù)平臺就要提數(shù)據(jù)模型捌省，提了數(shù)據(jù)模型就要提Nosql技術(shù)，
(點(diǎn)擊放大圖像)
上圖來自Nosql文檔系列的一幅圖
Nosql 是大數(shù)據(jù)處理的特征之一碉钠「倩海互聯(lián)網(wǎng)數(shù)據(jù)平臺數(shù)據(jù)模型與NoSql技術(shù)還是蠻緊密的。這里有外文講解Nosql Data modeling technigues 從技術(shù)角度講解非常詳（https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/）喊废。
因?yàn)榍斑吿岬降拇髷?shù)據(jù)平臺技術(shù)特性決定了傳統(tǒng)edw模型祝高、維度模型直接在互聯(lián)網(wǎng)數(shù)據(jù)大數(shù)據(jù)平臺部署或許還有“好些未知”障礙等待大家去克服。同時在傳統(tǒng)數(shù)據(jù)建模用到的一些方法經(jīng)過互聯(lián)網(wǎng)熏陶或許演進(jìn)成一種新的數(shù)據(jù)產(chǎn)品或方案吧污筷。
到此為止“我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史”上下共四篇與大家分享完畢工闺，這個寫作前后經(jīng)歷剛好一個月左右，算是對自己數(shù)據(jù)從業(yè)經(jīng)歷回顧之一吧。在知識的整理中很多都是蜻蜓點(diǎn)水陆蟆，每個知識域都是一個非常深的專業(yè)方向雷厂，自己涉足很膚淺，在文章中分享不足之處請各位讀者見諒５蟆改鲫！
個人郵箱是5592094@qq.com 歡迎電郵交流。
接下來我會進(jìn)入數(shù)據(jù)產(chǎn)品這個領(lǐng)域的分享林束，當(dāng)年車品覺老師自豪的作品之一“黃金策”像棘，我是數(shù)據(jù)產(chǎn)品經(jīng)理。（ps：自己躲在墻角拿車品覺老師往自己臉上貼金了）壶冒。
后記
有一次數(shù)據(jù)產(chǎn)品神策的創(chuàng)始人兼好友@桑文鋒＠SensorsData跟我說來做次分享吧缕题，我當(dāng)時出了幾個題目，最后就選擇了“我所經(jīng)歷的大數(shù)據(jù)平臺“胖腾，就形成了大家看到的”我所經(jīng)歷的大數(shù)據(jù)平臺“系列文章.
在整理期間得到了死黨@周愛民避除、@神策-桑文峰、 InfoQ小編@Tina Du 胸嘁、@betty zhou @Laurel大力協(xié)助瓶摆，在這里感謝！Ｐ院辍群井！
番外篇
這一篇是在24日舉行的分享大家提到的一些問題，經(jīng)過整理算是對正文的補(bǔ)充吧毫胜，從互聯(lián)網(wǎng)敏捷數(shù)據(jù)模型等角度做了較深入的細(xì)節(jié)介紹书斜。同時在數(shù)據(jù)產(chǎn)品方面的回答包含了一點(diǎn)未來寫作篇“數(shù)據(jù)產(chǎn)品”系列的一點(diǎn)內(nèi)容浓利。
1****艺普，傳統(tǒng)我們做BI的掀亩，做數(shù)據(jù)展現(xiàn)會建模后以pivot展現(xiàn)cube數(shù)據(jù)绊谭，不知道現(xiàn)在互聯(lián)網(wǎng)公司數(shù)據(jù)展示如何做的掷酗？第三方工具還是用API取數(shù)據(jù)平臺里的數(shù)據(jù)伤极？adhoc報(bào)表及靈活更換維度的時候web端一般是怎么做的碴里？
松子老師：剛才文章中提到了比如傳統(tǒng)行業(yè)的多維數(shù)據(jù)模型cube哀托。在互聯(lián)網(wǎng)采用的曲線救國方式解決的缺脉。 在分享中我給出了幾個圖痪欲。就是通過搜索引擎曲線救國方式實(shí)現(xiàn)類似Olap的模擬。
在這塊的模型的處理上采用的是維度退化處理攻礼。通過反規(guī)范化业踢，數(shù)據(jù)項(xiàng)、數(shù)據(jù)冗余去處理礁扮。在前端做特殊處理知举。
這個當(dāng)時產(chǎn)品原型之一：
(點(diǎn)擊放大圖像)
這是一個2011年-2012年左右的數(shù)據(jù)產(chǎn)品瞬沦，當(dāng)時算是即時計(jì)算的一種。不過已經(jīng)過去好幾年了雇锡，當(dāng)今新技術(shù)下Olap 引擎應(yīng)該有很好的提升蛙埂。
目前我知道的家互聯(lián)網(wǎng)公司，在前端展現(xiàn)有使用第三方套件比如spagoBi遮糖、pentaho 等 有自己設(shè)計(jì)開發(fā)定制化數(shù)據(jù)前端展現(xiàn)绣的。比如我剛開始分享的那兩個之前在去哪兒網(wǎng)設(shè)計(jì)的數(shù)據(jù)平臺內(nèi)部界面之一，當(dāng)然數(shù)據(jù)產(chǎn)品是另一個話題了欲账，通過對數(shù)據(jù)分析抽象指標(biāo)屡江、分析模型、用戶使用功能與流程赛不、未來規(guī)劃考慮用戶體驗(yàn)去設(shè)計(jì)惩嘉。
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
[圖片上傳中。踢故。文黎。（11）]
(點(diǎn)擊放大圖像)
2****，互聯(lián)網(wǎng)財(cái)經(jīng)類公司殿较，業(yè)務(wù)包括財(cái)經(jīng)網(wǎng)站耸峭、基金、股票淋纲、金融等劳闹，這類公司的數(shù)據(jù)倉庫模型應(yīng)該如何設(shè)計(jì)？特點(diǎn)和注意事項(xiàng)是什么洽瞬？案例介紹本涕？十分感謝。
松子老師：我自己經(jīng)歷過的是互聯(lián)網(wǎng)金融以及移動互聯(lián)網(wǎng)行伙窃。對這兩塊比較清楚菩颖。互聯(lián)網(wǎng)金融起因?yàn)闃I(yè)務(wù)的特性是類金融類的为障，與銀行有些地方是相似的晦闰。
比如大約在2012年前支付寶業(yè)務(wù)特點(diǎn)涉及類金融交易：充值、提現(xiàn)产场、賬務(wù)管理類電子商務(wù)：購物交易過程變更鹅髓、實(shí)際交易（對B機(jī)票、對C水電等） 非純電子商務(wù)京景；純金融；個人信用骗奖，理財(cái)類确徙。系統(tǒng)之間依賴度較為復(fù)雜醒串，垂直依賴（業(yè)務(wù)與核心）跨層依賴（跨過交易到賬務(wù)）。
在設(shè)計(jì)方法上還是采用維度模型設(shè)計(jì)方式鄙皇。底層是數(shù)據(jù)驅(qū)動為向?qū)叨模Y(jié)合業(yè)務(wù)需求驅(qū)動，通過簡單伴逸、退化維度的方式拉寬表結(jié)構(gòu)缠沈。
底層采用松耦合設(shè)計(jì)。主題之間是松耦合方式错蝴。至體內(nèi)采用細(xì)粒度退化維度洲愤。
在主題域上的的設(shè)計(jì)基本參考了OMG的數(shù)據(jù)倉庫元數(shù)據(jù)設(shè)計(jì)CWM模型号杠、IBM 的fsdm金融模型奕塑、還有新巴塞爾資本協(xié)議（Basel II Capital Accord）需提供數(shù)據(jù)規(guī)范去的設(shè)計(jì)。所以數(shù)據(jù)模型是五層的結(jié)構(gòu)枉侧。
在細(xì)節(jié)處理上官紫，增量ODS層數(shù)據(jù)和前一天DWD相關(guān)表進(jìn)行 merge處理肛宋。
在一些層次上，基本聚合束世、匯總增加派生事實(shí)表（簡單一句話退化為度打?qū)挘┰统隆Ｈ缓蟀凑諛I(yè)務(wù)主體合并信息等。
比如開始給大家分享的那張圖：
(點(diǎn)擊放大圖像)
[圖片上傳中毁涉。后添。。（13）]
在維度模型退化處理時薪丁，要注意最細(xì)粒度數(shù)據(jù)保留遇西、不同層次的數(shù)據(jù)支持?jǐn)?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ù)模型茄蚯。
這種元數(shù)據(jù)驅(qū)動工具型數(shù)據(jù)產(chǎn)品我會在未來數(shù)據(jù)產(chǎn)品系列中做詳細(xì)介紹的。
3****睦优，互聯(lián)網(wǎng)企業(yè)大數(shù)據(jù)平臺的發(fā)展歷程是怎樣的渗常？
松子老師：這個我相信應(yīng)該是傳統(tǒng)數(shù)據(jù)平臺朋友提到的。傳統(tǒng)行業(yè)數(shù)據(jù)平臺架構(gòu)演進(jìn)我總結(jié)簡單一句話說“基本上可以分為五個時代汗盘、四種架構(gòu)”皱碘，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與類型暴增的特點(diǎn)，從高階架構(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é)下來用戶特點(diǎn)：
(點(diǎn)擊放大圖像)
[圖片上傳中缩功。。都办。（14）]
更加詳細(xì)的每一代數(shù)據(jù)平臺建設(shè)嫡锌、服務(wù)角色特點(diǎn)您可以看我這個系列文章的第三篇，http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-paet02
4****琳钉，有沒有好的元數(shù)據(jù)管理工具推薦势木？主要偏向數(shù)據(jù)字典與血統(tǒng)等。
松子老師：元數(shù)據(jù)以前目前沒有太多的好管理工具槽卫。以前是在支付寶是我自己設(shè)計(jì)的一個數(shù)據(jù)產(chǎn)品跟压。第一版自己用Delphi 開發(fā)的。
（圖很多：）
(點(diǎn)擊放大圖像)
[圖片上傳中歼培。震蒋。。（15）]
(點(diǎn)擊放大圖像)
[圖片上傳中躲庄。查剖。。（16）]
(點(diǎn)擊放大圖像)
[圖片上傳中噪窘。笋庄。。（17）]
(點(diǎn)擊放大圖像)
[圖片上傳中倔监。直砂。。（18）]
(點(diǎn)擊放大圖像)
[圖片上傳中静暂。。谱秽。（19）]
以前被逼的自己寫了一個洽蛀，通過解析，實(shí)現(xiàn)了字段級的血緣影響分析疟赊。這只是第二步郊供，后來又把running 信息給搞了進(jìn)來。還有分享時提到的模型信息近哟、整個閉環(huán)的分類信息驮审。
這是一個分支：
(點(diǎn)擊放大圖像)
[圖片上傳中锅劝。讹剔。乒融。（20）]
但是我們實(shí)現(xiàn)了字段級解析準(zhǔn)確率達(dá)到了94%左右劲赠。有細(xì)微的錯誤就人工revew一遍鼠证。
5. ****松子老師峡竣，數(shù)據(jù)管控的數(shù)據(jù)質(zhì)量部分是怎么處理的呢？
松子老師： 數(shù)據(jù)管控量九， 這方面我不太懂的适掰，但是數(shù)據(jù)質(zhì)量，這玩意可大可小的荠列。比如像在分享時說過的类浪，在移動互聯(lián)網(wǎng)的數(shù)據(jù)質(zhì)量處理方式可以由原有的ETL(ELT)階段前置到業(yè)務(wù)系統(tǒng)去解決，比如移動互聯(lián)網(wǎng)的App log 日志肌似，日志標(biāo)準(zhǔn)化后事件模型”存儲來解決费就。那非app 日志類如何解決呢比如Payment、order等川队，數(shù)據(jù)質(zhì)量比較考慮的可以只做到監(jiān)控力细。
我來分享個圖。剛好是我設(shè)計(jì)數(shù)據(jù)質(zhì)量產(chǎn)品時搞的固额，理清數(shù)據(jù)質(zhì)量的問題：
(點(diǎn)擊放大圖像)
[圖片上傳中眠蚂。。斗躏。（21）]
(點(diǎn)擊放大圖像)
[圖片上傳中逝慧。。啄糙。（22）]
(點(diǎn)擊放大圖像)
[圖片上傳中笛臣。。隧饼。（23）]
只要數(shù)據(jù)進(jìn)入倉庫與應(yīng)用體系沈堡，處理起來就比較困難了，所以在數(shù)據(jù)平臺階段最好是通過監(jiān)控桑李、前置去解決踱蛀。目前數(shù)據(jù)質(zhì)量確實(shí)難以100%由事后搞到事前去處理。我對數(shù)據(jù)平臺與數(shù)據(jù)產(chǎn)品的建設(shè)就是實(shí)用為主贵白。怎么實(shí)用怎么來率拒。我是比較現(xiàn)實(shí)的實(shí)用主義者。
6. ****能否分享一些數(shù)據(jù)產(chǎn)品種類及實(shí)例：
松子老師：在前邊五個問題禁荒、以及文章中又都涉及數(shù)據(jù)產(chǎn)品實(shí)力的一些分享猬膨。
提到數(shù)據(jù)產(chǎn)品的分類我就想把這個圖發(fā)出來。
自己認(rèn)為沒有特別明確的劃分線，但是數(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工具、資源管控等等著觉。
面向用戶功能有報(bào)表型村生、多維型數(shù)據(jù)產(chǎn)品、定制化數(shù)據(jù)產(chǎn)品饼丘、挖掘型數(shù)據(jù)產(chǎn)品趁桃。
面向內(nèi)部用戶、外部個人用戶肄鸽、外部企業(yè)用戶又有不同的分類卫病。
根據(jù)業(yè)務(wù)又可以劃分很多，面向C類用戶贴捡、面向B類商戶忽肛、金融風(fēng)險(xiǎn)等等
從近幾年的數(shù)據(jù)產(chǎn)品來看，是更好的輔助用戶的做決策的一種產(chǎn)品形態(tài)烂斋，在用戶的決策與行動中充當(dāng)信息的分析者與價值使用者屹逛；數(shù)據(jù)產(chǎn)品有個自己的共性：由解決的一個實(shí)際的業(yè)務(wù)問題出發(fā)，分解出的分析指標(biāo)汛骂，分析模型罕模，分析流程組成较坛，再考慮到功能易用性轰异，未來功能擴(kuò)展者甲，考慮用戶對數(shù)據(jù)易用性（比如數(shù)據(jù)的呈現(xiàn)層次叭喜，不可能一次把所有數(shù)據(jù)的呈現(xiàn)給用戶）來組成的。
(點(diǎn)擊放大圖像)
[圖片上傳中喘鸟。项乒。肝劲。（24）]
7. ****銀行業(yè)從傳統(tǒng)的ods到edw再到大數(shù)據(jù)平臺這塊過渡媒殉，模型如何建設(shè)担敌？平臺優(yōu)勢如何發(fā)揮？
松子老師：這個問題還是有些難度的廷蓉，自己回答的可能有些片面全封。首先我們清醒的清楚“大數(shù)據(jù)”是什么？再次不同的場景可以采用不同的技術(shù)去解決。
“大數(shù)據(jù)”刹悴，拆開來看大行楞、數(shù)據(jù)，大可以是指的數(shù)據(jù)源結(jié)構(gòu)簡單（ps 如果了解過當(dāng)代對大數(shù)據(jù)的定義就知道四個特性）但是量級夠大土匀，比如清算子房、結(jié)算、對公恒削、對私池颈、中間業(yè)務(wù)等等每一個拿出來都是幾十T尾序，但是這些業(yè)務(wù)數(shù)據(jù)都是保存?zhèn)鹘y(tǒng)的關(guān)系型數(shù)據(jù)庫中如DB2钓丰、Oracle、MSsql中每币，因?yàn)樵跀?shù)據(jù)平臺存儲是通過準(zhǔn)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ù)的去演進(jìn)解決揭保。（最早時我的是中信銀行肥橙、光大銀行在2011年左右開始考慮Hadoop技術(shù)，后來不知道如何了）秸侣。
但是互聯(lián)網(wǎng)的數(shù)據(jù)平臺技術(shù)大都是NOSQL模式存筏，犧牲掉了傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)一致性、完整性味榛、唯一索引等等椭坚，只干性能的事情（當(dāng)然除了性能、可擴(kuò)展性也是的）.
原有在傳統(tǒng)數(shù)據(jù)平臺模型設(shè)計(jì)上可以考慮的一些通過主外鍵搏色、唯一索引做一些業(yè)務(wù)約束的方法善茎，在nosql上統(tǒng)統(tǒng)的都沒有了，這些約束必須放到數(shù)據(jù)加工階段去想辦法做檢查频轿。傳統(tǒng)數(shù)據(jù)平臺如果在Insert垂涯、update數(shù)據(jù)時違反了業(yè)務(wù)約束可以做報(bào)警或異常處理，但是在Nosql的平臺上要求ETL 去手動遵守這些規(guī)則檢查航邢。但是有時ETL開發(fā)根本不遵守的耕赘，僅僅是兩個表關(guān)聯(lián)起來，也可能忘記按照某一個業(yè)務(wù)唯一索引做去重操作翠忠。簡單說鞠苟，原有靠關(guān)系型數(shù)據(jù)庫本身機(jī)制去做檢查一些規(guī)則變?yōu)槿斯ぃ優(yōu)槿斯ぞ蜁稿e。
從關(guān)系型數(shù)據(jù)平臺往Nosql數(shù)據(jù)平臺遷移時当娱，尤其是對傳統(tǒng)行業(yè)的業(yè)務(wù)來說吃既，在模型設(shè)計(jì)階段、以及給出的ETL口徑要考慮更多的業(yè)務(wù)規(guī)則檢查跨细，其次要考慮更多的維度退化鹦倚、多冗余、表打?qū)捥幚砑讲选：唵握f就是發(fā)揮數(shù)據(jù)平臺的計(jì)算能力同時要更加的各方面確保數(shù)據(jù)準(zhǔn)確安全可靠震叙。
數(shù)據(jù)模型ODS 到EDW 這塊的設(shè)計(jì)方法百度上留下的文檔資料太多的了，請這位提問的老師百度吧散休。
**8****．大數(shù)據(jù)****倉庫****中如何做快速****維處****理媒楼？互****聯(lián)****網(wǎng)數(shù)****倉****數(shù)據(jù)****質(zhì)****量不好如何****對****數(shù)，如何確立****標(biāo)****準(zhǔn)的****對****數(shù)口徑戚丸？******
松子老師：快速變化維度可以轉(zhuǎn)化為緩慢變化為來出來鼓鲁，我自己理解的快速維度是相對于緩慢維度參照的來說的目锭。
舉個例子冕香，年齡-轉(zhuǎn)化為天數(shù)可以是定義快速變化維度供汛，因?yàn)槊刻於荚谧兓Ｎ覀兛梢园涯挲g退化為區(qū)間維度來處理胁勺，還可以把年齡做成動態(tài)維度來處理世澜，事實(shí)表中保存的就是實(shí)際的出生年月并打?qū)挶恚挲g(天)通過計(jì)算方式來處理署穗。還有種方法通過對代理鍵的方式來處理寥裂。
我目前也不知道對數(shù)據(jù)的標(biāo)準(zhǔn)是什么。但是我自己用的方法蛇捌，把一個指標(biāo)的整個數(shù)據(jù)流向切出幾個關(guān)鍵點(diǎn)通過SQL去實(shí)現(xiàn)對數(shù)抚恒，看波動振幅，波動曲線络拌。同時還會比如發(fā)不通的版本的小流量測試的方式來做數(shù)據(jù)校對俭驮。
9****． 做為數(shù)據(jù)行業(yè)從業(yè)者，需要掌握哪些重要的基礎(chǔ)知識春贸？另：如果從零開始建立一個數(shù)據(jù)平臺混萝，需要哪些資源配置（人，財(cái)萍恕，物逸嘀，技術(shù)）？大致總投資額度多少允粤？如果同行產(chǎn)品間多種來源的數(shù)據(jù)崭倘，可有成熟的解決方案翼岁？謝謝…
松子老師：這個問題太宏觀了。作為數(shù)據(jù)行業(yè)從業(yè)者司光，需要掌握哪些重要基礎(chǔ)知識琅坡，這個是要看從事具體數(shù)據(jù)域的垂直行業(yè)。
比如說 數(shù)據(jù)開發(fā)残家、數(shù)據(jù)模型榆俺、數(shù)據(jù)產(chǎn)品、數(shù)據(jù)分析師坞淮、數(shù)據(jù)運(yùn)營茴晋、數(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ù)目標(biāo)不太明確下付枫，難以確定方案，人員配置上選用不同技術(shù)方案去搭建的配置是不太一樣的驰怎，比如說傳統(tǒng)平臺來講阐滩，運(yùn)維、DBA县忌、數(shù)據(jù)開發(fā)掂榔、數(shù)據(jù)模型、報(bào)表人員症杏。
從互聯(lián)網(wǎng)數(shù)據(jù)平臺基本配置上装获，數(shù)據(jù)架構(gòu)師、運(yùn)維厉颤、底層大數(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ù)。
10. Standalone****模式下资溃，Model.save(Path)怎么一直提示錯誤积蜻，是不是配置Spark時需要將Hdfs的配置引進(jìn)來啊～霞玄？表示初學(xué)Spark
松子老師：這個問題有點(diǎn)超出我的能力范圍了，所以對不起回答不了。
我本身不是做技術(shù)的负乡。僅知道一點(diǎn)技術(shù)名詞。
11. ****傳統(tǒng)銀行業(yè)數(shù)據(jù)模型什么時候會走向互聯(lián)網(wǎng)模式呢懈凹？目前在傳統(tǒng)銀行數(shù)據(jù)平臺的產(chǎn)品是不是特別多瘾带？
松子老師：這個問題我自己就不知道了，或許是傳統(tǒng)銀行在數(shù)據(jù)平臺的實(shí)施上全面用互聯(lián)網(wǎng)的Nosql大數(shù)據(jù)處理技術(shù)吧驻售。至于說傳統(tǒng)銀行數(shù)據(jù)模型用現(xiàn)有的互聯(lián)網(wǎng)數(shù)據(jù)模型理念去設(shè)計(jì)是否完全可行露久，數(shù)據(jù)一致性、高準(zhǔn)確性通過更多的方案去保證欺栗。
首先我需要確定一下這個產(chǎn)品是否指的“數(shù)據(jù)產(chǎn)品”毫痕。
如果是數(shù)據(jù)產(chǎn)品，那其實(shí)傳統(tǒng)行業(yè)數(shù)據(jù)平臺本身就有一些數(shù)據(jù)產(chǎn)品了迟几，而且也都是存在的消请。數(shù)據(jù)產(chǎn)品自從數(shù)據(jù)倉庫出現(xiàn)以來它其實(shí)一直都存在的，只不過是近幾年因?yàn)榛ヂ?lián)網(wǎng)特別愛制造“流行詞“把數(shù)據(jù)產(chǎn)品這個詞給放大了类腮‰互聯(lián)網(wǎng)是得數(shù)據(jù)產(chǎn)品從早期的重量級逐漸進(jìn)化為輕量級、從大而全的解決方案逐漸演進(jìn)為因小而美蚜枢。
我來給出幾組例子缸逃，大約從2004年到現(xiàn)在的幾組數(shù)據(jù)產(chǎn)品的例子
(點(diǎn)擊放大圖像)
[圖片上傳中。厂抽。需频。（25）]
(點(diǎn)擊放大圖像)
[圖片上傳中。筷凤。昭殉。（26）]
(點(diǎn)擊放大圖像)
[圖片上傳中。嵌施。饲化。（27）]
(點(diǎn)擊放大圖像)
[圖片上傳中。吗伤。吃靠。（28）]
(點(diǎn)擊放大圖像)
[圖片上傳中。足淆。巢块。（29）]
(點(diǎn)擊放大圖像)
[圖片上傳中礁阁。。族奢。（30）]
(點(diǎn)擊放大圖像)
你可以分類一下姥闭，這些數(shù)據(jù)產(chǎn)品的特點(diǎn)是什么？滿足了用戶怎么樣的痛點(diǎn)需求越走？滿足了用戶怎么樣的使用流程棚品。
12 ****。傳統(tǒng)行業(yè)的數(shù)據(jù)倉庫從業(yè)人員廊敌，如果轉(zhuǎn)到互聯(lián)網(wǎng)行業(yè)铜跑，應(yīng)該學(xué)習(xí)哪些技能？
松子老師：這個問題你可以百度搜索“大數(shù)據(jù)職位所需要的數(shù)據(jù)技能” http://blog.jobbole.com/99039/ 這篇文章骡澈。自己覺得人家回答的比我專業(yè)锅纺。//
我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史（四）：互聯(lián)網(wǎng)時代 ? 下篇
http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-internet-age
編者按：本文是松子（李博源）的大數(shù)據(jù)平臺發(fā)展史系列文章的第四篇（共四篇），本系列以獨(dú)特的視角肋殴，比較了非互聯(lián)網(wǎng)和互聯(lián)網(wǎng)兩個時代以及傳統(tǒng)行業(yè)與非傳統(tǒng)行業(yè)囤锉。是對數(shù)據(jù)平臺發(fā)展的一個回憶，對非互聯(lián)網(wǎng)护锤、互聯(lián)網(wǎng)官地，從數(shù)據(jù)平臺的用戶角度、數(shù)據(jù)架構(gòu)演進(jìn)蔽豺、模型等進(jìn)行了闡述区丑。
在互聯(lián)網(wǎng)時代被弱化的數(shù)據(jù)模型
談起數(shù)據(jù)模型就不得不提傳統(tǒng)數(shù)據(jù)平臺架構(gòu)發(fā)展，我相信很多朋友都曉得傳統(tǒng)數(shù)據(jù)平臺的知識修陡，其架構(gòu)演進(jìn)簡單一句話說“基本上可以分為五個時代、四種架構(gòu)”可霎，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與數(shù)據(jù)源類型多樣化特點(diǎn)魄鸦，從高階架構(gòu)上來看大約從傳統(tǒng)數(shù)據(jù)平臺第三代架構(gòu)開始延續(xù)的，但是往后的發(fā)展從我自己的這一點(diǎn)知識上很難對互聯(lián)網(wǎng)的數(shù)據(jù)平臺做架構(gòu)歸類癣朗。
但是從數(shù)據(jù)平臺建設(shè)與服務(wù)角色上還是有章可循的拾因。就像上篇分享到那樣座慰，類比兩個行業(yè)函荣，互聯(lián)網(wǎng)企業(yè)中員工年齡比非互聯(lián)網(wǎng)企業(yè)的要年輕、受教育程度掌敬、對計(jì)算機(jī)的焦慮程度明顯比傳統(tǒng)企業(yè)要低正卧、還偶遇其它各方面的緣故蠢熄，導(dǎo)致了數(shù)據(jù)平臺所面對用戶群體與非互聯(lián)網(wǎng)數(shù)據(jù)平臺有所差異化。
傳統(tǒng)行業(yè)與互聯(lián)網(wǎng)行業(yè)數(shù)據(jù)平臺用戶特性我只選擇前文章的兩張圖來表示
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
在傳統(tǒng)數(shù)據(jù)平臺要背后有一個完整數(shù)據(jù)倉庫團(tuán)隊(duì)去服務(wù)業(yè)務(wù)方炉旷，業(yè)務(wù)方嗷嗷待哺的等待被動方式去滿足签孔。中低層數(shù)據(jù)基本不會對業(yè)務(wù)方開放叉讥，所以不管數(shù)據(jù)模型采用何種建模方式，主要滿足當(dāng)時數(shù)據(jù)架構(gòu)規(guī)劃即可饥追。
互聯(lián)網(wǎng)業(yè)務(wù)的快速發(fā)展使得大家已經(jīng)從經(jīng)營图仓、分析的訴求重點(diǎn)轉(zhuǎn)為數(shù)據(jù)化的精細(xì)運(yùn)營上，如何做好精細(xì)化運(yùn)營問題上來但绕，當(dāng)資源不夠時用戶就叫喊救崔，甚至有的業(yè)務(wù)方會挽起袖子來自己參與到從數(shù)據(jù)整理、加工捏顺、分析階段六孵。
此時呢，原有建設(shè)數(shù)據(jù)平臺的多個角色（數(shù)據(jù)開發(fā)草丧、模型設(shè)計(jì)）可能轉(zhuǎn)為對其它非專業(yè)使用數(shù)據(jù)方狸臣，做培訓(xùn)、咨詢與落地昌执，寫更加適合當(dāng)前企業(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àn)椴粚I(yè)性煤禽，導(dǎo)致數(shù)據(jù)質(zhì)量問題、重復(fù)對分?jǐn)?shù)據(jù)浪費(fèi)存儲與資源岖赋、口徑多樣化檬果、編碼不統(tǒng)一、命名問題等等原因唐断。數(shù)據(jù)質(zhì)量逐漸變成一個特別突出的問題选脊。
傳統(tǒng)企業(yè)的數(shù)據(jù)源基本來自excel、表格脸甘、DB系統(tǒng)等恳啥，但在互聯(lián)網(wǎng)有網(wǎng)站點(diǎn)擊流日志、視頻丹诀、音頻钝的、圖片數(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ù)有些力不從心碗脊。
當(dāng)數(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è)也有自己特點(diǎn)另绩，傳統(tǒng)行業(yè)所涉及數(shù)據(jù)模型這個領(lǐng)域涉及的很多內(nèi)容在互聯(lián)網(wǎng)變成以其他的曲線救國的方式存在了。
在互聯(lián)網(wǎng)曲線救國新解決
回顧在傳統(tǒng)行業(yè)數(shù)據(jù)平臺中花嘶，不管兩位大師爭論點(diǎn)數(shù)據(jù)模型的設(shè)計(jì)采用那種范式（Bill Inmon的EDW的原則是準(zhǔn)三范式的設(shè)計(jì)笋籽、Ralph kilmbal是星型結(jié)構(gòu)）但是都要非常重視數(shù)據(jù)源的質(zhì)量問題。所以傳統(tǒng)行業(yè)的數(shù)據(jù)模型會全盤考慮數(shù)據(jù)質(zhì)量問題椭员，并通過數(shù)據(jù)抽樣分析給出合適的清洗口徑车海。
(點(diǎn)擊放大圖像)
上圖來自我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ù)”對一年的還是不準(zhǔn)的）埋同。在應(yīng)對數(shù)據(jù)的質(zhì)量問題思币，目前互聯(lián)網(wǎng)有些做法是把數(shù)據(jù)標(biāo)準(zhǔn)化前置到業(yè)務(wù)數(shù)據(jù)產(chǎn)生就做榨惰，從根源上去杜絕數(shù)據(jù)質(zhì)量祟昭，但是這種場景比較實(shí)用在Log 日志的數(shù)據(jù)源中臊恋，比如移動互聯(lián)網(wǎng)最近流行的基于事件模型“Event”模型，在日志產(chǎn)生時就規(guī)定好存儲格式（備注：大家度娘搜索虱肄，“學(xué)習(xí)筆記：The Log（我所讀過的最好的一篇分布式技術(shù)文章）” 對這個講解很詳細(xì)）致板。
在傳統(tǒng)行業(yè)，目前還是以混合模型設(shè)計(jì)方式為主咏窿。在互聯(lián)網(wǎng)的我所接觸的一些業(yè)務(wù)可岂，在參照傳統(tǒng)數(shù)據(jù)模型方法論基礎(chǔ)上逐步演進(jìn)適合互聯(lián)網(wǎng)數(shù)據(jù)的數(shù)據(jù)模型方法。
比如互聯(lián)網(wǎng)金融等一些業(yè)務(wù)會參考傳統(tǒng)金融行業(yè)對主題域的劃分翰灾、OMG數(shù)據(jù)倉庫元數(shù)據(jù)管理CWM模型、FSDM金融模型稚茅，再進(jìn)一步考慮大數(shù)據(jù)處理特性去進(jìn)行設(shè)計(jì)纸淮，所有從Hight Level 數(shù)據(jù)架構(gòu)圖看到主題層次劃分與傳統(tǒng)第三代數(shù)據(jù)倉庫還是很多相似之處，當(dāng)然模型架構(gòu)也有分三層亚享、四層咽块、五層的。
不同的地方模型細(xì)節(jié)處理上已經(jīng)完全不一樣欺税，比如數(shù)據(jù)的多樣性侈沪、拉寬事實(shí)表揭璃、度量值單獨(dú)存儲、滿足數(shù)據(jù)快速重生亭罪、維度的二次降維處理等瘦馍、增加大量冗余列、增加大量派生列应役，結(jié)合自動化元數(shù)據(jù)來耦合情组、合并等相關(guān)管理。
(點(diǎn)擊放大圖像)
[圖片上傳中箩祥。院崇。。（4）]
上圖是支付寶非常早期數(shù)據(jù)模型
(點(diǎn)擊放大圖像)
上圖是支付寶非常早期數(shù)據(jù)模型
我們常提到的多維模型在大數(shù)據(jù)處理下進(jìn)行了退化維度處理袍祖。大家知道Olap多維模型底瓣，隨著維度的增加事實(shí)表的數(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è)計(jì)多維挖掘分析數(shù)據(jù)產(chǎn)品背后的技術(shù)就是搜索引擎實(shí)現(xiàn)的），現(xiàn)在應(yīng)該也有新技術(shù)出現(xiàn)了來解決類似的問題寺滚。
(點(diǎn)擊放大圖像)
上圖為2012年產(chǎn)品UI之一柑营。
(點(diǎn)擊放大圖像)
[圖片上傳中。村视。官套。（7）]
上圖是2011-2012年該產(chǎn)品系列背后當(dāng)時使用的技術(shù)
互聯(lián)網(wǎng)業(yè)務(wù)特點(diǎn)業(yè)務(wù)垂直拆分非常細(xì)，比如一個用戶注冊蚁孔、密碼找回的流程有可能存在好幾個產(chǎn)品負(fù)責(zé)同一個業(yè)務(wù)流程不同環(huán)節(jié)奶赔，相關(guān)的一個策略、產(chǎn)品feature快速迭代上線等等都要數(shù)據(jù)評估杠氢。數(shù)據(jù)從前端埋點(diǎn)到采集然后再由各個環(huán)節(jié)到數(shù)據(jù)平臺站刑，再有數(shù)據(jù)分析師或各業(yè)務(wù)部門去使用，基本拉長了時間周期鼻百。需求部門與實(shí)施部門能力和經(jīng)驗(yàn)有千差萬別的需求绞旅，造成了懂技術(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ù)特點(diǎn)是變化非常迅速的，能穩(wěn)定的業(yè)務(wù)達(dá)到65%算對數(shù)據(jù)平臺是個福音了（根據(jù)對某寶寶的印象）剩余的業(yè)務(wù)變化迅速卫旱，必然導(dǎo)致數(shù)據(jù)模型快速上下線人灼。
Kimball老人家提出的維度建模（備注，在本系列發(fā)展史得第一篇有介紹）圍繞業(yè)務(wù)模型能夠非常直觀的表達(dá)出業(yè)務(wù)的數(shù)據(jù)關(guān)系顾翼，但是在互聯(lián)網(wǎng)NOSQL犧牲掉了關(guān)系型數(shù)據(jù)庫的一致性投放、完整性等等很多東西。維度數(shù)據(jù)模型又基于這些大數(shù)據(jù)技術(shù)的暴构，所以進(jìn)化的更加輕量級與基于細(xì)節(jié)數(shù)據(jù)的維度退化建模（原有的緩慢變化維跪呈、快速變化維甚带、大維崔列、迷你維麸粮、父子維批糟、雪花維為了適應(yīng)互聯(lián)網(wǎng)的大數(shù)據(jù)Nosql處理技術(shù)進(jìn)行反規(guī)范化唆貌、化&數(shù)據(jù)冗余設(shè)計(jì)储狭。
退化維度的反規(guī)范化設(shè)計(jì)一方面可以把一條查詢語句所需要的所有數(shù)據(jù)組合起來放到一個地方存儲 Key values 的方式（比如說商品有不同類型抖所，每一種類型商品又有自己的不同屬性钙勃，可以采用一對多晴埂、多對多的方式存儲究反，例如把一個多維映射為一個Key value）。
講到互聯(lián)網(wǎng)數(shù)據(jù)平臺就要提數(shù)據(jù)模型儒洛，提了數(shù)據(jù)模型就要提Nosql技術(shù)精耐，
(點(diǎn)擊放大圖像)
上圖來自Nosql文檔系列的一幅圖
Nosql 是大數(shù)據(jù)處理的特征之一±哦停互聯(lián)網(wǎng)數(shù)據(jù)平臺數(shù)據(jù)模型與NoSql技術(shù)還是蠻緊密的卦停。這里有外文講解Nosql Data modeling technigues 從技術(shù)角度講解非常詳（https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/）。
因?yàn)榍斑吿岬降拇髷?shù)據(jù)平臺技術(shù)特性決定了傳統(tǒng)edw模型恼蓬、維度模型直接在互聯(lián)網(wǎng)數(shù)據(jù)大數(shù)據(jù)平臺部署或許還有“好些未知”障礙等待大家去克服惊完。同時在傳統(tǒng)數(shù)據(jù)建模用到的一些方法經(jīng)過互聯(lián)網(wǎng)熏陶或許演進(jìn)成一種新的數(shù)據(jù)產(chǎn)品或方案吧。
到此為止“我所經(jīng)歷的大數(shù)據(jù)平臺發(fā)展史”上下共四篇與大家分享完畢处硬，這個寫作前后經(jīng)歷剛好一個月左右小槐，算是對自己數(shù)據(jù)從業(yè)經(jīng)歷回顧之一吧。在知識的整理中很多都是蜻蜓點(diǎn)水荷辕，每個知識域都是一個非常深的專業(yè)方向凿跳，自己涉足很膚淺，在文章中分享不足之處請各位讀者見諒４健拄显！
個人郵箱是5592094@qq.com 歡迎電郵交流。
接下來我會進(jìn)入數(shù)據(jù)產(chǎn)品這個領(lǐng)域的分享案站，當(dāng)年車品覺老師自豪的作品之一“黃金策”，我是數(shù)據(jù)產(chǎn)品經(jīng)理。（ps：自己躲在墻角拿車品覺老師往自己臉上貼金了）蟆盐。
后記
有一次數(shù)據(jù)產(chǎn)品神策的創(chuàng)始人兼好友@桑文鋒＠SensorsData跟我說來做次分享吧承边，我當(dāng)時出了幾個題目，最后就選擇了“我所經(jīng)歷的大數(shù)據(jù)平臺“石挂，就形成了大家看到的”我所經(jīng)歷的大數(shù)據(jù)平臺“系列文章.
在整理期間得到了死黨@周愛民博助、@神策-桑文峰、 InfoQ小編@Tina Du 痹愚、@betty zhou @Laurel大力協(xié)助富岳，在這里感謝！Ｕ窖式！
番外篇
這一篇是在24日舉行的分享大家提到的一些問題，經(jīng)過整理算是對正文的補(bǔ)充吧动壤，從互聯(lián)網(wǎng)敏捷數(shù)據(jù)模型等角度做了較深入的細(xì)節(jié)介紹萝喘。同時在數(shù)據(jù)產(chǎn)品方面的回答包含了一點(diǎn)未來寫作篇“數(shù)據(jù)產(chǎn)品”系列的一點(diǎn)內(nèi)容。
1****琼懊，傳統(tǒng)我們做BI的阁簸，做數(shù)據(jù)展現(xiàn)會建模后以pivot展現(xiàn)cube數(shù)據(jù)，不知道現(xiàn)在互聯(lián)網(wǎng)公司數(shù)據(jù)展示如何做的哼丈？第三方工具還是用API取數(shù)據(jù)平臺里的數(shù)據(jù)启妹？adhoc報(bào)表及靈活更換維度的時候web端一般是怎么做的？
松子老師：剛才文章中提到了比如傳統(tǒng)行業(yè)的多維數(shù)據(jù)模型cube醉旦。在互聯(lián)網(wǎng)采用的曲線救國方式解決的饶米。 在分享中我給出了幾個圖。就是通過搜索引擎曲線救國方式實(shí)現(xiàn)類似Olap的模擬髓抑。
在這塊的模型的處理上采用的是維度退化處理咙崎。通過反規(guī)范化，數(shù)據(jù)項(xiàng)吨拍、數(shù)據(jù)冗余去處理褪猛。在前端做特殊處理。
這個當(dāng)時產(chǎn)品原型之一：
(點(diǎn)擊放大圖像)
這是一個2011年-2012年左右的數(shù)據(jù)產(chǎn)品羹饰，當(dāng)時算是即時計(jì)算的一種伊滋。不過已經(jīng)過去好幾年了，當(dāng)今新技術(shù)下Olap 引擎應(yīng)該有很好的提升队秩。
目前我知道的家互聯(lián)網(wǎng)公司笑旺，在前端展現(xiàn)有使用第三方套件比如spagoBi掂恕、pentaho 等 有自己設(shè)計(jì)開發(fā)定制化數(shù)據(jù)前端展現(xiàn)该押。比如我剛開始分享的那兩個之前在去哪兒網(wǎng)設(shè)計(jì)的數(shù)據(jù)平臺內(nèi)部界面之一，當(dāng)然數(shù)據(jù)產(chǎn)品是另一個話題了骑篙，通過對數(shù)據(jù)分析抽象指標(biāo)、分析模型乌妙、用戶使用功能與流程使兔、未來規(guī)劃考慮用戶體驗(yàn)去設(shè)計(jì)。
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
[圖片上傳中藤韵。虐沥。。（11）]
(點(diǎn)擊放大圖像)
2****泽艘，互聯(lián)網(wǎng)財(cái)經(jīng)類公司欲险，業(yè)務(wù)包括財(cái)經(jīng)網(wǎng)站、基金匹涮、股票天试、金融等，這類公司的數(shù)據(jù)倉庫模型應(yīng)該如何設(shè)計(jì)焕盟？特點(diǎn)和注意事項(xiàng)是什么秋秤？案例介紹？十分感謝脚翘。
松子老師：我自己經(jīng)歷過的是互聯(lián)網(wǎng)金融以及移動互聯(lián)網(wǎng)行灼卢。對這兩塊比較清楚±磁互聯(lián)網(wǎng)金融起因?yàn)闃I(yè)務(wù)的特性是類金融類的鞋真，與銀行有些地方是相似的。
比如大約在2012年前支付寶業(yè)務(wù)特點(diǎn)涉及類金融交易：充值沃于、提現(xiàn)涩咖、賬務(wù)管理類電子商務(wù)：購物交易過程變更、實(shí)際交易（對B機(jī)票繁莹、對C水電等） 非純電子商務(wù)檩互；純金融；個人信用咨演，理財(cái)類闸昨。系統(tǒng)之間依賴度較為復(fù)雜，垂直依賴（業(yè)務(wù)與核心）跨層依賴（跨過交易到賬務(wù)）薄风。
在設(shè)計(jì)方法上還是采用維度模型設(shè)計(jì)方式饵较。底層是數(shù)據(jù)驅(qū)動為向?qū)ВY(jié)合業(yè)務(wù)需求驅(qū)動遭赂，通過簡單循诉、退化維度的方式拉寬表結(jié)構(gòu)。
底層采用松耦合設(shè)計(jì)撇他。主題之間是松耦合方式茄猫。至體內(nèi)采用細(xì)粒度退化維度狈蚤。
在主題域上的的設(shè)計(jì)基本參考了OMG的數(shù)據(jù)倉庫元數(shù)據(jù)設(shè)計(jì)CWM模型、IBM 的fsdm金融模型募疮、還有新巴塞爾資本協(xié)議（Basel II Capital Accord）需提供數(shù)據(jù)規(guī)范去的設(shè)計(jì)炫惩。所以數(shù)據(jù)模型是五層的結(jié)構(gòu)。
在細(xì)節(jié)處理上阿浓，增量ODS層數(shù)據(jù)和前一天DWD相關(guān)表進(jìn)行 merge處理。
在一些層次上蹋绽，基本聚合芭毙、匯總增加派生事實(shí)表（簡單一句話退化為度打?qū)挘Ｈ缓蟀凑諛I(yè)務(wù)主體合并信息等卸耘。
比如開始給大家分享的那張圖：
(點(diǎn)擊放大圖像)
[圖片上傳中退敦。。蚣抗。（13）]
在維度模型退化處理時侈百，要注意最細(xì)粒度數(shù)據(jù)保留、不同層次的數(shù)據(jù)支持?jǐn)?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ù)模型。
這種元數(shù)據(jù)驅(qū)動工具型數(shù)據(jù)產(chǎn)品我會在未來數(shù)據(jù)產(chǎn)品系列中做詳細(xì)介紹的迷捧。
3****织咧，互聯(lián)網(wǎng)企業(yè)大數(shù)據(jù)平臺的發(fā)展歷程是怎樣的？
松子老師：這個我相信應(yīng)該是傳統(tǒng)數(shù)據(jù)平臺朋友提到的漠秋。傳統(tǒng)行業(yè)數(shù)據(jù)平臺架構(gòu)演進(jìn)我總結(jié)簡單一句話說“基本上可以分為五個時代笙蒙、四種架構(gòu)”花枫，但是到了互聯(lián)網(wǎng)時代因?yàn)榇髷?shù)據(jù)快速膨脹與類型暴增的特點(diǎn)考廉，從高階架構(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é)下來用戶特點(diǎn)：
(點(diǎn)擊放大圖像)
[圖片上傳中燕耿。中符。。（14）]
更加詳細(xì)的每一代數(shù)據(jù)平臺建設(shè)誉帅、服務(wù)角色特點(diǎn)您可以看我這個系列文章的第三篇淀散，http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-paet02
4****右莱，有沒有好的元數(shù)據(jù)管理工具推薦？主要偏向數(shù)據(jù)字典與血統(tǒng)等档插。
松子老師：元數(shù)據(jù)以前目前沒有太多的好管理工具慢蜓。以前是在支付寶是我自己設(shè)計(jì)的一個數(shù)據(jù)產(chǎn)品。第一版自己用Delphi 開發(fā)的郭膛。
（圖很多：）
(點(diǎn)擊放大圖像)
[圖片上傳中晨抡。。则剃。（15）]
(點(diǎn)擊放大圖像)
[圖片上傳中耘柱。。棍现。（16）]
(點(diǎn)擊放大圖像)
[圖片上傳中调煎。。己肮。（17）]
(點(diǎn)擊放大圖像)
[圖片上傳中士袄。。谎僻。（18）]
(點(diǎn)擊放大圖像)
[圖片上傳中娄柳。。戈稿。（19）]
以前被逼的自己寫了一個西土，通過解析，實(shí)現(xiàn)了字段級的血緣影響分析鞍盗。這只是第二步需了，后來又把running 信息給搞了進(jìn)來。還有分享時提到的模型信息般甲、整個閉環(huán)的分類信息肋乍。
這是一個分支：
(點(diǎn)擊放大圖像)
[圖片上傳中。敷存。墓造。（20）]
但是我們實(shí)現(xiàn)了字段級解析準(zhǔn)確率達(dá)到了94%左右。有細(xì)微的錯誤就人工revew一遍锚烦。
5. ****松子老師觅闽，數(shù)據(jù)管控的數(shù)據(jù)質(zhì)量部分是怎么處理的呢？
松子老師： 數(shù)據(jù)管控涮俄， 這方面我不太懂的蛉拙，但是數(shù)據(jù)質(zhì)量，這玩意可大可小的彻亲。比如像在分享時說過的孕锄，在移動互聯(lián)網(wǎng)的數(shù)據(jù)質(zhì)量處理方式可以由原有的ETL(ELT)階段前置到業(yè)務(wù)系統(tǒng)去解決吮廉，比如移動互聯(lián)網(wǎng)的App log 日志，日志標(biāo)準(zhǔn)化后事件模型”存儲來解決畸肆。那非app 日志類如何解決呢比如Payment宦芦、order等，數(shù)據(jù)質(zhì)量比較考慮的可以只做到監(jiān)控轴脐。
我來分享個圖调卑。剛好是我設(shè)計(jì)數(shù)據(jù)質(zhì)量產(chǎn)品時搞的，理清數(shù)據(jù)質(zhì)量的問題：
(點(diǎn)擊放大圖像)
[圖片上傳中大咱。令野。。（21）]
(點(diǎn)擊放大圖像)
[圖片上傳中徽级。。聊浅。（22）]
(點(diǎn)擊放大圖像)
[圖片上傳中餐抢。。低匙。（23）]
只要數(shù)據(jù)進(jìn)入倉庫與應(yīng)用體系续扔，處理起來就比較困難了俘种，所以在數(shù)據(jù)平臺階段最好是通過監(jiān)控、前置去解決。目前數(shù)據(jù)質(zhì)量確實(shí)難以100%由事后搞到事前去處理拄踪。我對數(shù)據(jù)平臺與數(shù)據(jù)產(chǎn)品的建設(shè)就是實(shí)用為主。怎么實(shí)用怎么來礼旅。我是比較現(xiàn)實(shí)的實(shí)用主義者纱意。
6. ****能否分享一些數(shù)據(jù)產(chǎn)品種類及實(shí)例：
松子老師：在前邊五個問題、以及文章中又都涉及數(shù)據(jù)產(chǎn)品實(shí)力的一些分享间景。
提到數(shù)據(jù)產(chǎn)品的分類我就想把這個圖發(fā)出來佃声。
自己認(rèn)為沒有特別明確的劃分線，但是數(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工具、資源管控等等尝苇。
面向用戶功能有報(bào)表型铛只、多維型數(shù)據(jù)產(chǎn)品埠胖、定制化數(shù)據(jù)產(chǎn)品、挖掘型數(shù)據(jù)產(chǎn)品淳玩。
面向內(nèi)部用戶直撤、外部個人用戶、外部企業(yè)用戶又有不同的分類蜕着。
根據(jù)業(yè)務(wù)又可以劃分很多谋竖，面向C類用戶、面向B類商戶承匣、金融風(fēng)險(xiǎn)等等
從近幾年的數(shù)據(jù)產(chǎn)品來看蓖乘，是更好的輔助用戶的做決策的一種產(chǎn)品形態(tài)，在用戶的決策與行動中充當(dāng)信息的分析者與價值使用者韧骗；數(shù)據(jù)產(chǎn)品有個自己的共性：由解決的一個實(shí)際的業(yè)務(wù)問題出發(fā)嘉抒，分解出的分析指標(biāo)，分析模型袍暴，分析流程組成些侍，再考慮到功能易用性，未來功能擴(kuò)展政模，考慮用戶對數(shù)據(jù)易用性（比如數(shù)據(jù)的呈現(xiàn)層次岗宣，不可能一次把所有數(shù)據(jù)的呈現(xiàn)給用戶）來組成的。
(點(diǎn)擊放大圖像)
[圖片上傳中淋样。耗式。。（24）]
7. ****銀行業(yè)從傳統(tǒng)的ods到edw再到大數(shù)據(jù)平臺這塊過渡趁猴，模型如何建設(shè)刊咳？平臺優(yōu)勢如何發(fā)揮？
松子老師：這個問題還是有些難度的躲叼，自己回答的可能有些片面芦缰。首先我們清醒的清楚“大數(shù)據(jù)”是什么？再次不同的場景可以采用不同的技術(shù)去解決枫慷。
“大數(shù)據(jù)”让蕾，拆開來看大、數(shù)據(jù)或听，大可以是指的數(shù)據(jù)源結(jié)構(gòu)簡單（ps 如果了解過當(dāng)代對大數(shù)據(jù)的定義就知道四個特性）但是量級夠大探孝，比如清算、結(jié)算誉裆、對公顿颅、對私、中間業(yè)務(wù)等等每一個拿出來都是幾十T足丢，但是這些業(yè)務(wù)數(shù)據(jù)都是保存?zhèn)鹘y(tǒng)的關(guān)系型數(shù)據(jù)庫中如DB2粱腻、Oracle庇配、MSsql中，因?yàn)樵跀?shù)據(jù)平臺存儲是通過準(zhǔn)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ù)的去演進(jìn)解決空厌。（最早時我的是中信銀行德撬、光大銀行在2011年左右開始考慮Hadoop技術(shù)扎阶，后來不知道如何了）。
但是互聯(lián)網(wǎng)的數(shù)據(jù)平臺技術(shù)大都是NOSQL模式上沐，犧牲掉了傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)一致性皮服、完整性、唯一索引等等参咙，只干性能的事情（當(dāng)然除了性能冰更、可擴(kuò)展性也是的）.
原有在傳統(tǒng)數(shù)據(jù)平臺模型設(shè)計(jì)上可以考慮的一些通過主外鍵、唯一索引做一些業(yè)務(wù)約束的方法昂勒，在nosql上統(tǒng)統(tǒng)的都沒有了，這些約束必須放到數(shù)據(jù)加工階段去想辦法做檢查舟铜。傳統(tǒng)數(shù)據(jù)平臺如果在Insert戈盈、update數(shù)據(jù)時違反了業(yè)務(wù)約束可以做報(bào)警或異常處理，但是在Nosql的平臺上要求ETL 去手動遵守這些規(guī)則檢查谆刨。但是有時ETL開發(fā)根本不遵守的塘娶，僅僅是兩個表關(guān)聯(lián)起來，也可能忘記按照某一個業(yè)務(wù)唯一索引做去重操作痊夭。簡單說刁岸，原有靠關(guān)系型數(shù)據(jù)庫本身機(jī)制去做檢查一些規(guī)則變?yōu)槿斯ぃ優(yōu)槿斯ぞ蜁稿e她我。
從關(guān)系型數(shù)據(jù)平臺往Nosql數(shù)據(jù)平臺遷移時虹曙，尤其是對傳統(tǒng)行業(yè)的業(yè)務(wù)來說，在模型設(shè)計(jì)階段番舆、以及給出的ETL口徑要考慮更多的業(yè)務(wù)規(guī)則檢查酝碳，其次要考慮更多的維度退化、多冗余恨狈、表打?qū)捥幚硎杌：唵握f就是發(fā)揮數(shù)據(jù)平臺的計(jì)算能力同時要更加的各方面確保數(shù)據(jù)準(zhǔn)確安全可靠。
數(shù)據(jù)模型ODS 到EDW 這塊的設(shè)計(jì)方法百度上留下的文檔資料太多的了禾怠，請這位提問的老師百度吧返奉。
**8****．大數(shù)據(jù)****倉庫****中如何做快速****維處****理贝搁？互****聯(lián)****網(wǎng)數(shù)****倉****數(shù)據(jù)****質(zhì)****量不好如何****對****數(shù)，如何確立****標(biāo)****準(zhǔn)的****對****數(shù)口徑芽偏？******
松子老師：快速變化維度可以轉(zhuǎn)化為緩慢變化為來出來雷逆，我自己理解的快速維度是相對于緩慢維度參照的來說的。
舉個例子哮针，年齡-轉(zhuǎn)化為天數(shù)可以是定義快速變化維度关面，因?yàn)槊刻於荚谧兓Ｎ覀兛梢园涯挲g退化為區(qū)間維度來處理十厢，還可以把年齡做成動態(tài)維度來處理等太，事實(shí)表中保存的就是實(shí)際的出生年月并打?qū)挶恚挲g(天)通過計(jì)算方式來處理蛮放。還有種方法通過對代理鍵的方式來處理缩抡。
我目前也不知道對數(shù)據(jù)的標(biāo)準(zhǔn)是什么。但是我自己用的方法包颁，把一個指標(biāo)的整個數(shù)據(jù)流向切出幾個關(guān)鍵點(diǎn)通過SQL去實(shí)現(xiàn)對數(shù)瞻想，看波動振幅，波動曲線娩嚼。同時還會比如發(fā)不通的版本的小流量測試的方式來做數(shù)據(jù)校對蘑险。
9****． 做為數(shù)據(jù)行業(yè)從業(yè)者，需要掌握哪些重要的基礎(chǔ)知識岳悟？另：如果從零開始建立一個數(shù)據(jù)平臺佃迄，需要哪些資源配置（人，財(cái)贵少，物呵俏，技術(shù)）？大致總投資額度多少滔灶？如果同行產(chǎn)品間多種來源的數(shù)據(jù)普碎，可有成熟的解決方案？謝謝…
松子老師：這個問題太宏觀了录平。作為數(shù)據(jù)行業(yè)從業(yè)者麻车，需要掌握哪些重要基礎(chǔ)知識，這個是要看從事具體數(shù)據(jù)域的垂直行業(yè)斗这。
比如說 數(shù)據(jù)開發(fā)绪氛、數(shù)據(jù)模型、數(shù)據(jù)產(chǎn)品涝影、數(shù)據(jù)分析師枣察、數(shù)據(jù)運(yùn)營蒙揣、數(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ù)目標(biāo)不太明確下，難以確定方案叛赚，人員配置上選用不同技術(shù)方案去搭建的配置是不太一樣的澡绩，比如說傳統(tǒng)平臺來講，運(yùn)維俺附、DBA肥卡、數(shù)據(jù)開發(fā)、數(shù)據(jù)模型事镣、報(bào)表人員步鉴。
從互聯(lián)網(wǎng)數(shù)據(jù)平臺基本配置上，數(shù)據(jù)架構(gòu)師璃哟、運(yùn)維氛琢、底層大數(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ù)。
10. Standalone****模式下于微，Model.save(Path)怎么一直提示錯誤逗嫡，是不是配置Spark時需要將Hdfs的配置引進(jìn)來啊～？表示初學(xué)Spark
松子老師：這個問題有點(diǎn)超出我的能力范圍了株依，所以對不起回答不了驱证。
我本身不是做技術(shù)的。僅知道一點(diǎn)技術(shù)名詞恋腕。
11. ****傳統(tǒng)銀行業(yè)數(shù)據(jù)模型什么時候會走向互聯(lián)網(wǎng)模式呢抹锄？目前在傳統(tǒng)銀行數(shù)據(jù)平臺的產(chǎn)品是不是特別多？
松子老師：這個問題我自己就不知道了，或許是傳統(tǒng)銀行在數(shù)據(jù)平臺的實(shí)施上全面用互聯(lián)網(wǎng)的Nosql大數(shù)據(jù)處理技術(shù)吧伙单。至于說傳統(tǒng)銀行數(shù)據(jù)模型用現(xiàn)有的互聯(lián)網(wǎng)數(shù)據(jù)模型理念去設(shè)計(jì)是否完全可行获高，數(shù)據(jù)一致性、高準(zhǔn)確性通過更多的方案去保證吻育。
首先我需要確定一下這個產(chǎn)品是否指的“數(shù)據(jù)產(chǎn)品”念秧。
如果是數(shù)據(jù)產(chǎn)品，那其實(shí)傳統(tǒng)行業(yè)數(shù)據(jù)平臺本身就有一些數(shù)據(jù)產(chǎn)品了布疼，而且也都是存在的摊趾。數(shù)據(jù)產(chǎn)品自從數(shù)據(jù)倉庫出現(xiàn)以來它其實(shí)一直都存在的，只不過是近幾年因?yàn)榛ヂ?lián)網(wǎng)特別愛制造“流行詞“把數(shù)據(jù)產(chǎn)品這個詞給放大了游两±悖互聯(lián)網(wǎng)是得數(shù)據(jù)產(chǎn)品從早期的重量級逐漸進(jìn)化為輕量級、從大而全的解決方案逐漸演進(jìn)為因小而美器罐。
我來給出幾組例子梢为，大約從2004年到現(xiàn)在的幾組數(shù)據(jù)產(chǎn)品的例子
(點(diǎn)擊放大圖像)
[圖片上傳中。轰坊。铸董。（25）]
(點(diǎn)擊放大圖像)
[圖片上傳中。肴沫。粟害。（26）]
(點(diǎn)擊放大圖像)
[圖片上傳中。颤芬。悲幅。（27）]
(點(diǎn)擊放大圖像)
[圖片上傳中。站蝠。汰具。（28）]
(點(diǎn)擊放大圖像)
[圖片上傳中。菱魔。冲簿。（29）]
(點(diǎn)擊放大圖像)
(點(diǎn)擊放大圖像)
[圖片上傳中挡篓。偎蘸。篡殷。（31）]
你可以分類一下，這些數(shù)據(jù)產(chǎn)品的特點(diǎn)是什么藻治？滿足了用戶怎么樣的痛點(diǎn)需求碘勉？滿足了用戶怎么樣的使用流程。
12 ****桩卵。傳統(tǒng)行業(yè)的數(shù)據(jù)倉庫從業(yè)人員验靡，如果轉(zhuǎn)到互聯(lián)網(wǎng)行業(yè)倍宾，應(yīng)該學(xué)習(xí)哪些技能？
松子老師：這個問題你可以百度搜索“大數(shù)據(jù)職位所需要的數(shù)據(jù)技能” http://blog.jobbole.com/99039/ 這篇文章晴叨。自己覺得人家回答的比我專業(yè)凿宾。
