⑴ 銆愭荤粨銆戠淮搴︽暟鎹寤烘ā杩囩▼鍙婁妇渚
鏈鏂囦粙缁嶆暟鎹浠撳簱涓缁村害鏁版嵁寤烘ā鐨勮繃绋嬫弿杩帮紝骞朵妇涓涓绀轰緥浠ュ姞娣卞圭浉鍏虫傚康鐨勭悊瑙ｃ
缁村害妯″瀷鏄鏁版嵁浠撳簱棰嗗煙澶у笀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、数据仓库搭建中最繁杂的事情是什么，最容易缺失的是哪一块?
一直觉得数据仓库的核心不在于数据集成，当然数据集成是数据仓库实现价值的前提，数据仓库真正的价值体现在数据的有效应用，数据源于业务反作用于业务。而搭建数据仓库的核心在于数据仓库的架构和数据模型的设计，怎么权衡数据的存储和数据获取效率之间的矛盾是数据仓库管理上的难点，这个难点任何数据仓库都会存在，而大数据增大了这种权衡中的难度。而数据的集成和数据质量控制是数据仓库搭建中最繁杂的事情，尤其是数据清洗的过程，我之前也写过几篇数据质量控制的文章，但现实中这个过程还要复杂得多，而且为了上层数据产出的准确性和有效性，这项工作又不得不做，而且要做得尽量细致。
搭建数据仓库中最容易缺失的就是对元数据的管理，很少有数据仓库团队具备完整的元数据，当然搭建数据仓库的工程师本身就是活的元数据，但无论是为了用数据的人还是数据仓库自身的团队着想，元数据都不可或缺。一方面元数据为数据需求方提供了完整的数据仓库使用文档，帮助他们能自主地快速获取数据，另一方面数据仓库团队成员可以从日常的数据解释中解脱出来，无论是对后期的不断迭代更新和维护还是培训新的员工，都非常有好处，元数据可以让数据仓库的应用和维护更加高效。