⑴ 銆愭葷粨銆戠淮搴︽暟鎹寤烘ā榪囩▼鍙婁婦渚
鏈鏂囦粙緇嶆暟鎹浠撳簱涓緇村害鏁版嵁寤烘ā鐨勮繃紼嬫弿榪幫紝騫朵婦涓涓紺轟緥浠ュ姞娣卞圭浉鍏蟲傚康鐨勭悊瑙ｃ
緇村害妯″瀷鏄鏁版嵁浠撳簱棰嗗煙澶у笀Ralph Kimall鎵鍊″礆紝浠栫殑銆婃暟鎹浠撳簱宸ュ叿綆便嬶紝鏄鏁版嵁浠撳簱宸ョ▼棰嗗煙鏈嫻佽岀殑鏁頒粨寤烘ā緇忓吀銆傜淮搴﹀緩妯′互鍒嗘瀽鍐崇瓥鐨勯渶奼傚嚭鍙戞瀯寤烘ā鍨嬶紝鏋勫緩鐨勬暟鎹妯″瀷涓哄垎鏋愰渶奼傛湇鍔★紝鍥犳ゅ畠閲嶇偣瑙ｅ喅鐢ㄦ埛濡備綍鏇村揩閫熷畬鎴愬垎鏋愰渶奼傦紝鍚屾椂榪樻湁杈冨ソ鐨勫ぇ瑙勬ā澶嶆潅鏌ヨ㈢殑鍝嶅簲鎬ц兘銆
1銆侀氳繃瀵逛笟鍔￠渶奼備互鍙婂彲鐢ㄦ暟鎹婧愮殑緇煎悎鑰冭檻錛岀『瀹氬瑰摢縐嶄笟鍔¤繃紼嬪紑灞曞緩妯″伐浣
2銆佸緩絝嬬殑絎涓涓緇村害妯″瀷搴旇ユ槸涓涓鏈鏈夊獎鍝嶇殑妯″瀷鈥斺斿畠搴旇ュ規渶緔ц揩鐨勪笟鍔￠棶棰樹綔鍑哄洖絳旓紝騫朵笖瀵規暟鎹鐨勬娊鍙栨潵璇存槸鏈瀹規槗鐨勩
娉錛氱矑搴︽槸鎸囨暟鎹浠撳簱鐨勬暟鎹鍗曚綅涓淇濆瓨鏁版嵁鐨勭粏鍖栨垨緇煎悎紼嬪害鐨勭駭鍒錛岀粏鍖栫▼搴﹁秺楂橈紝綺掑害灝辮秺灝
1銆佸簲璇ュ厛浼樺厛鑰冭檻涓轟笟鍔″勭悊鑾峰彇鏈鏈夊師瀛愭х殑淇℃伅鑰屽紑鍙戠淮搴︽ā鍨嬨傚師瀛愬瀷鏁版嵁鏄鎵鏀墮泦鐨勬渶璇︾粏鐨勪俊鎮錛岃繖鏍風殑鏁版嵁涓嶈兘鍐嶅仛鏇磋繘涓姝ョ殑緇嗗垎銆
2銆佹暟鎹浠撳簱鍑犱箮鎬繪槸瑕佹眰鍦ㄦ瘡涓緇村害鍙鑳藉緱鍒扮殑鏈浣庣矑搴︿笂瀵規暟鎹榪涜岃〃紺虹殑鍘熷洜錛屽苟涓嶆槸鍥犱負鏌ヨ㈡兂鐪嬪埌姣忎釜浣庡眰嬈＄殑琛岋紝鑰屾槸鍥犱負鏌ヨ㈠笇鏈涗互寰堢簿紜鐨勬柟寮忓圭粏鑺傜煡璇嗚繘琛屾娊鍙栥
涓涓緇忚繃浠旂粏鑰冭檻鐨勭矑搴﹀畾涔夌『瀹氫簡浜嬪疄琛ㄧ殑鍩烘湰緇村害鐗規с傚悓鏃訛紝緇忓父涔熷彲鑳藉悜浜嬪疄琛ㄧ殑鍩烘湰綺掑害鍔犲叆鏇村氱殑緇村害錛岃岃繖浜涢檮鍔犵殑緇村害浼氬湪鍩烘湰緇村害鐨勬瘡涓緇勫悎鍊兼柟闈㈣嚜鐒跺湴鍙栧緱鍞涓鐨勫箋傚傛灉闄勫姞鐨勭淮搴﹀洜涓哄艱嚧鐢熸垚鍙﹀栫殑浜嬪疄琛岃岃繚鑳屼簡榪欎釜鍩烘湰鐨勭矑搴﹀畾涔夛紝閭ｄ箞蹇呴』瀵圭矑搴﹀畾涔夎繘琛屼慨鏀逛互閫傚簲榪欎釜緇村害鐨勬儏鏅銆
紜瀹氬皢鍝浜涗簨瀹炴斁鍒頒簨瀹炶〃涓銆傜矑搴﹀０鏄庢湁鍔╀簬紼沖畾鐩稿叧鐨勮冭檻銆備簨瀹炲繀欏諱笌綺掑害鍚誨悎銆傚湪鑰冭檻鍙鑳藉瓨鍦ㄧ殑浜嬪疄鏃訛紝鍙鑳戒細鍙戠幇浠嶇劧闇瑕佽皟鏁存棭鏈熺殑綺掑害澹版槑鍜岀淮搴﹂夋嫨
緇村害寤烘ā涓鏈変竴浜涙瘮杈冮噸瑕佺殑姒傚康錛岀悊瑙ｄ簡榪欎簺姒傚康錛屽熀鏈涔熷氨鐞嗚В浜嗕粈涔堟槸緇村害寤烘ā銆
棰濓紝鐪嬩簡榪欎竴鍙ワ紝鍏跺疄鏄涓嶅お瀹規槗鐞嗚В鍒板簳浠涔堟槸浜嬪疄琛ㄧ殑銆
姣斿備竴嬈¤喘涔拌屼負鎴戜滑灝卞彲浠ョ悊瑙ｄ負鏄涓涓浜嬪疄錛屼笅闈㈡垜浠涓婄ず渚嬨
鍥句腑鐨勮㈠崟琛ㄥ氨鏄涓涓浜嬪疄琛錛屼綘鍙浠ョ悊瑙ｄ粬灝辨槸鍦ㄧ幇瀹炰腑鍙戠敓鐨勪竴嬈℃搷浣滃瀷浜嬩歡錛屾垜浠姣忓畬鎴愪竴涓璁㈠崟錛屽氨浼氬湪璁㈠崟涓澧炲姞涓鏉¤板綍銆
鎴戜滑鍙浠ュ洖榪囧ご鍐嶇湅涓涓嬩簨瀹炶〃鐨勭壒寰侊紝鍦ㄧ淮搴﹁〃閲屾病鏈夊瓨鏀懼疄闄呯殑鍐呭癸紝浠栨槸涓鍫嗕富閿鐨勯泦鍚堬紝榪欎簺ID鍒嗗埆鑳藉瑰簲鍒扮淮搴﹁〃涓鐨勪竴鏉¤板綍銆
鎴戜滑鐨勫浘涓鐨勭敤鎴瘋〃銆佸晢瀹惰〃銆佹椂闂磋〃榪欎簺閮藉睘浜庣淮搴﹁〃錛岃繖浜涜〃閮芥湁涓涓鍞涓鐨勪富閿錛岀劧鍚庡湪琛ㄤ腑瀛樻斁浜嗚︾粏鐨勬暟鎹淇℃伅銆
涓嬮潰鎴戜滑灝嗕互鐢靛晢涓轟緥錛岃︾粏璁蹭竴涓嬬淮搴﹀緩妯＄殑寤烘ā鏂瑰紡錛屽苟涓句緥濡傛灉浣跨敤榪欎釜妯″瀷錛堣繖鐐硅繕鏄寰堥噸瑕佺殑錛夈
鍋囪炬垜浠鍦ㄤ竴瀹剁數鍟嗙綉絝欏伐浣滐紝姣斿傛煇瀹濄佹煇涓溿傛垜浠闇瑕佸硅繖閲屼笟鍔¤繘琛屽緩妯°備笅闈㈡垜浠鍒嗘瀽鍑犵偣涓氬姟鍦烘櫙錛
濂斤紝鍩轟簬榪欏嚑鐐癸紝鎴戜滑鏉ヨ捐℃垜浠鐨勬ā鍨嬨
涓嬮潰灝辨槸鎴戜滑璁捐″嚭鏉ョ殑鏁版嵁妯″瀷錛屽拰涔嬪墠鐨勫熀鏈涓鏍鳳紝鍙涓嶈繃鏄鎹㈡垚浜嗚嫳鏂囷紝涓昏佹槸涓轟簡鍚庨潰鍐檚ql鐨勬椂鍊欐潵鐢ㄣ
鎴戝氨涓嶅啀瑙ｉ噴姣忎釜琛ㄧ殑浣滅敤浜嗭紝鐜板湪鍙璇翠竴涓嬩負浠涔堣佽繖鏍瘋捐°
棣栧厛錛屾垜浠鎯充竴涓嬶紝濡傛灉鎴戜滑涓嶈繖鏍瘋捐＄殑璇濓紝鎴戜滑涓鑸浼氭庝箞鍋氾紵
濡傛灉鏄鎴戱紝鎴戜細璁捐′笅闈㈣繖寮犺〃銆備綘淇′笉淇★紝鎴戣兘鍒楀嚭鏉50涓瀛楁碉紒鍏跺疄鎴戜釜浜鴻や負鎬庝箞璁捐¤繖縐嶈〃閮芥湁鍏跺悎鐞嗘э紝鎴戜滑涓嶈哄歸敊錛屽崟璇翠竴涓嬩袱鑰呯殑浼樼己鐐廣
鍏堣存垜浠鐨勭淮搴︽ā鍨嬶細
鍐嶈存垜浠榪欏紶澶ф捐〃鐨勪紭緙虹偣錛
鏁版嵁妯″瀷鐨勫緩絝嬪繀欏昏佷負鏇村ソ鐨勫簲鐢ㄦ潵鏈嶅姟錛屼笅闈㈡垜鍏堜婦涓涓渚嬪瓙錛屾潵鍒囧疄鍦版劅鍙椾竴涓嬫潵鎬庝箞鐢ㄦ垜浠鐨勬ā鍨嬨
闇奼 錛氭眰鍑2016騫村湪甯濋兘鐨勭敺鎬х敤鎴瘋喘涔扮殑LV鍝佺墝鍟嗗搧鐨勬諱環鏍箋
瀹炵幇 錛
緇村害寤烘ā鏄涓縐嶅嶮鍒嗕紭縐鐨勫緩妯℃柟寮忥紝浠栨湁寰堝氱殑浼樼偣錛屼絾鏄鎴戜滑鍦ㄥ疄闄呭伐浣滀腑涔熷緢闅懼畬鍏ㄦ寜鐓у畠鐨勬柟寮忔潵瀹炵幇錛岄兘浼氭湁鎵鍙栬垗錛屾瘮濡傝翠負浜嗕笟鍔℃垜浠榪樻槸浼氶渶瑕佷竴浜涘借〃錛屾湁鏃跺欒繕浼氭湁寰堝氱殑鏁版嵁鍐椾綑銆
⑵ 鎯充簡瑙ｅぇ鏁版嵁綆＄悊涓庡簲鐢ㄥ簲璇ョ湅鍝浜涗功姣旇緝濂斤紵
澶ф暟鎹綆＄悊涓庡簲鐢ㄦ槸涓涓娑夊強澶氫釜棰嗗煙鐨勭患鍚堟у︾戱紝鍖呮嫭鏁版嵁瀛樺偍銆佹暟鎹澶勭悊銆佹暟鎹鍒嗘瀽銆佹暟鎹鍙瑙嗗寲絳夋柟闈銆備互涓嬫槸涓浜涘煎緱鎺ㄨ崘鐨勪功綾嶏紝鍙浠ュ府鍔╀綘娣卞叆浜嗚В澶ф暟鎹綆＄悊涓庡簲鐢錛
1. 銆婂ぇ鏁版嵁鏃朵唬銆嬶細浣滆呯淮鍏嬫墭路榪堝皵-鑸嶆仼浼鏍礆紙Victor Mayer-Schönberger錛夊拰鑲灝兼柉路搴撳厠緗楋紙Kenneth Cukier錛夊悎钁楃殑榪欐湰涔︽槸澶ф暟鎹棰嗗煙鐨勭粡鍏鎬箣浣滐紝浠嬬粛浜嗗ぇ鏁版嵁鐨勬傚康銆佹妧鏈鍜屽簲鐢錛屽苟鎺㈣ㄤ簡澶ф暟鎹瀵圭ぞ浼氬拰緇忔祹鐨勫獎鍝嶃
2. 銆婂ぇ鏁版嵁綆＄悊銆嬶細浣滆呬紛鎮┞蜂酣鐗癸紙Ian H. Witten錛夈佸焹閲屽厠路甯冮噷灝旓紙Erik Brynjolfsson錛夊拰瀹夊痙椴伮烽害鍗¤彶錛圓ndrew McAfee錛夊悎钁楃殑榪欐湰涔﹁︾粏浠嬬粛浜嗗ぇ鏁版嵁綆＄悊鐨勫悇涓鏂歸潰錛屽寘鎷鏁版嵁瀛樺偍銆佹暟鎹澶勭悊銆佹暟鎹鍒嗘瀽絳夛紝騫舵彁渚涗簡瀹為檯妗堜緥鍜屾渶浣沖疄璺點
3. 銆奌adoop鏉冨▉鎸囧崡銆嬶細浣滆呮堡濮喡鋒鐗癸紙Tom White錛夋槸Apache Hadoop欏圭洰鐨勫壋濮嬩漢涔嬩竴錛岃繖鏈涔︽槸Hadoop棰嗗煙鐨勭粡鍏告暀鏉愶紝璇︾粏浠嬬粛浜咹adoop鐨勫師鐞嗐佹灦鏋勫拰浣跨敤鏂規硶錛岄傚悎鍒濆﹁呭叆闂ㄣ
4. 銆奡park蹇閫熷ぇ鏁版嵁鍒嗘瀽銆嬶細浣滆呬簹鍘嗗北澶路璐濆皵錛圓lexander Bell錛夊拰瀹夎開路娉曟柉鎵橈紙Andy Konwinski錛夊悎钁楃殑榪欐湰涔︿粙緇嶄簡Apache Spark鐨勫熀鏈姒傚康銆佺紪紼嬫ā鍨嬪拰搴旂敤鍦烘櫙錛岄氳繃瀹炰緥婕旂ず浜嗗備綍浣跨敤Spark榪涜屽ぇ鏁版嵁鍒嗘瀽鍜屽勭悊銆
5. 銆婃暟鎹浠撳簱宸ュ叿綆便嬶細浣滆匯alph Kimball鏄鏁版嵁浠撳簱棰嗗煙鐨勬潈濞佷笓瀹訛紝榪欐湰涔﹁︾粏浠嬬粛浜嗘暟鎹浠撳簱鐨勮捐°佸緩妯″拰綆＄悊鏂規硶錛屽寘鎷緇村害寤烘ā銆佹槦鍨嬫ā寮忋侀洩鑺辨ā寮忕瓑錛屽逛簬鐞嗚В澶ф暟鎹綆＄悊鍜屽垎鏋愰潪甯告湁甯鍔┿
6. 銆婃暟鎹鎸栨帢錛氭傚康涓庢妧鏈銆嬶細浣滆呮眽鏂路涔屽皵鏂路鏂藉瘑寰鳳紙Hans Peter Moritz錛夊拰褰煎緱路鍝堝凹浠錛圥eter Harrington錛夊悎钁楃殑榪欐湰涔︿粙緇嶄簡鏁版嵁鎸栨帢鐨勫熀鏈姒傚康銆佹妧鏈鍜岀畻娉曪紝鍖呮嫭鑱氱被銆佸垎綾匯佸叧鑱旇勫垯鎸栨帢絳夛紝瀵逛簬榪涜屽ぇ鏁版嵁鍒嗘瀽鍜屾寲鎺橀潪甯告湁甯鍔┿
⑶ 怎麼理解數據倉庫中的面向主題
1、面向主題，是讓你面向主題去分析問題，架構模型，而不是非要物理上回分開，就像答面向對象編程一樣
2、「很多資料中都寫數據倉庫的數據模型是使用「第三範式」，數據集市才使用多維的星型模型」這個是不對的，因為在Inmon 和 Kimball 的書中都沒有表示這種說法
Inmon 表是建數倉需要有個企業級的一致數據模型，並沒有表示非要第三範式，這個第三範式是 Kimball 在自己的書里說 Inmon 的方式用第三範式不好啦啥的，具體自己看書《數據倉庫工具箱-維度建模權威指南》第一種1.5節
數據集市使用維度建模，這個說法Kimball 也沒有說過，而是 Inmon 在自己的書里說維度建模只適合數據集市，具體看《數據倉庫》第5張5.19節（應該是這一節）
PS：其實感覺他倆的觀點差不多，只是根據他們必須得給自己的觀點加油吶喊而已，兩個人互撕很多年了
⑷ 網站數據分析:數據倉庫相關的問題(3)
網站數據分析:數據倉庫相關的問題(3)
之前的文章——網站數據分析的一些問題2中主要整理了BI相關的問題，這篇文章主要想整理一些數據倉庫相關的問題。因為最近重新在看一些數據倉庫的資料和書籍，想把之前以及當前遇到的主要問題提出來(博客中有關數據倉庫的相關內容請參閱網站數據倉庫這個目錄)，同時自己也對數據倉庫方面的知識進行下重新的整理和認識，而且很久沒有在博客發新的文章了，不能讓自己過於懶散了。
之前看過Inmon的《構建數據倉庫》和《DW 2.0》，而另外一位數據倉庫大師Kimball的《數據倉庫生命周期工具箱》一直沒有時間閱讀，最近才有時間看完了大部分，就迫不及待想寫點東西了。其實數據倉庫領域普遍認為Inmon和Kimball的理論是對立的，兩者在構建數據倉庫上方向性的差異一直爭論不休，誰也無法說服誰到底哪種方法更好。我的Evernote的筆記裡面不知什麼時候從哪裡摘錄過來了對兩者觀點的概括性描述，非常簡潔明了而一針見血：
Inmon vs Kimball
Kimball – Let everybody build what they want when they want it, we』ll integrate it all when and if we need to. (BOTTOM-UP APPROACH)
Pros: fast to build, quick ROI, nimble
Cons: harder to maintain as an enterprise resource, often rendant, often difficult to integrate data marts
Inmon – Don』t do anything until you』ve designed everything. (TOP-DOWN APPROACH)
Pros: easy to maitain, tightly integrated
Cons: takes way too long to deliver first projects, rigid
其實看了《數據倉庫生命周期工具箱》之後，發現兩者的觀點沒有那麼大的本質性差異，可能隨著數據倉庫的不斷發展，兩者在整體的架構上慢慢趨同。基本上，構建統一的企業級數據倉庫的方向是一致的，而Inmon偏向於從底層的數據集成出發，而Kimball則趨向於從上層的需求角度出發，這可能跟兩者從事的項目和所處的位置有關。
有了上面這段高質量的概括，第一個問題——你更偏向於以何種方式搭建數據倉庫(BOTTOM-UP or TOP-DOWN)，分別有什麼優劣勢?——其實就不用問了，所以下面主要提幾個在實際中可能經常遇到或者需要想清楚的問題：
Q1、數據倉庫的技術解決方案有哪些，這些解決方案的優勢在哪，瓶頸在哪?
隨著數據倉庫的不斷發展和成熟，「大數據」概念的風靡，有越來越多的相關產品出來，最常見的技術解決方案包括hadoop和hive，oracle，mysql的infobright，greenplum及nosql，或者多個結合使用。
其實歸納起來就兩類：一是用傳統RDBMS為主導的資料庫管理數據，oracle、mysql等都是基於傳統的關系型資料庫，優勢就是有更嚴謹的數據結構，關系型資料庫對數據的管理更加規范，數據處理過程中可能出現的非人為誤差極小，而且標準的SQL介面使數據獲取的成本較低，數據的查詢和獲取更加靈活和高效;但劣勢也很明顯，對海量數據的處理和存儲的能力不足，當數據量達到一定程度的時候就會出現明顯的瓶頸。而是基於文本的分布式處理引擎，hadoop、greenplum和nosql都是基於文本數據的處理和存儲，優勢是強大的數據處理能力，分布式的架構支持並行計算，並且具備超強的擴展延伸能力;劣勢就是上層介面不方便，因此Hadoop上層的hive和greenplum上層的postgreSQL都是為了解決數據介面的問題，並且數據的查詢和獲取很難做到實時響應，靈活性不足。
Q2、數據倉庫是否就應該保存聚合數據，細節數據不應該放入數據倉庫?
其實這個問題基本已經達成共識，如果是構建企業級的數據倉庫，那麼對細節數據的集成和存儲是必不可少的，但現實中還是存在很多直接從外部數據源計算聚合之後導入數據倉庫的實例。如果對數據倉庫只是輕量級的應用，僅存放聚合數據也無可厚非，畢竟沒人規定數據倉庫一定要是怎麼樣的，最終的目的無非就是滿足對數據的支持和需求。
但對於企業的長期發展來看，數據倉庫中存放細節數據有兩方面的好處：一方面從技術層面，數據倉庫存儲細節數據可以釋放前台資料庫的查詢壓力，同時對於文本類數據和外部文檔類數據入庫之後管理更加規范，數據倉庫保留歷史和不可變更的特性可以讓信息不被丟失;另一方面就是從數據的使用上，數據倉庫讓數據的獲取和使用更加簡便，集成細節數據讓大量的文本型數據可查詢，可關聯，而面向主題的設計讓數據的展現和分析更有方向性和目的性，而且細節數據是支持數據分析和數據挖掘應用所必不可少的。所以，如果數據倉庫要不斷地催生出更大的價值，細節數據的存儲是必不可少的。
Q3、你會把數據倉庫分為幾層，每層的數據作用是什麼?
沒有標准答案，根據數據倉庫中數據的復雜性和對數據使用的需求程度，數據倉庫可以有不用的層級劃分。
我一般會把數據倉庫劃成三層：最底層的細節數據，管理策略是優化存儲，一般存儲導入的原始數據，便於進行向上的統計匯總，因為數據量較大所以需要優化存儲;中間層是多維模型，管理策略是優化結構和查詢，面向主題的多維模型的設計，需要滿足OLAP和數據查詢的多樣需求，同時保證查詢的便捷性，關鍵在與維表的設計和維度的選擇及組合，事實表需要關注存儲和索引的優化;最上層是展現數據，管理策略是優化效率，一般會存放每天需要展現的匯總報表，或者根據多維模型拼裝的視圖，展現層的數據需要以最快的速度展現出來，一般用於BI平台的Dashboard和報表。
Q4、數據倉庫搭建中最繁雜的事情是什麼，最容易缺失的是哪一塊?
一直覺得數據倉庫的核心不在於數據集成，當然數據集成是數據倉庫實現價值的前提，數據倉庫真正的價值體現在數據的有效應用，數據源於業務反作用於業務。而搭建數據倉庫的核心在於數據倉庫的架構和數據模型的設計，怎麼權衡數據的存儲和數據獲取效率之間的矛盾是數據倉庫管理上的難點，這個難點任何數據倉庫都會存在，而大數據增大了這種權衡中的難度。而數據的集成和數據質量控制是數據倉庫搭建中最繁雜的事情，尤其是數據清洗的過程，我之前也寫過幾篇數據質量控制的文章，但現實中這個過程還要復雜得多，而且為了上層數據產出的准確性和有效性，這項工作又不得不做，而且要做得盡量細致。
搭建數據倉庫中最容易缺失的就是對元數據的管理，很少有數據倉庫團隊具備完整的元數據，當然搭建數據倉庫的工程師本身就是活的元數據，但無論是為了用數據的人還是數據倉庫自身的團隊著想，元數據都不可或缺。一方面元數據為數據需求方提供了完整的數據倉庫使用文檔，幫助他們能自主地快速獲取數據，另一方面數據倉庫團隊成員可以從日常的數據解釋中解脫出來，無論是對後期的不斷迭代更新和維護還是培訓新的員工，都非常有好處，元數據可以讓數據倉庫的應用和維護更加高效。